RE: [ECOS] forwarded message from Simpkins, Andy

RE: [ECOS] forwarded message from Simpkins, Andy

[Simpkins, Andy]

Configuration of the system
	Target Platform : Custom board (ARM7TDMI core)
	Development Host: Windows NT 4 sp6, cygwin, eCos 1.3.1, GCC 2.95.2
	
This is the current test file I am using:

main.cpp (entire file)

	/* INCLUDES */
	
	#include <stdio.h>                      /* printf */
	#include <string.h>                     /* strlen */
	#include <cyg/kernel/kapi.h>            /* All the kernel specific
stuff */
	#include <cyg/io/io.h>                  /* I/O functions */
	#include <cyg/hal/hal_arch.h>           /*
CYGNUM_HAL_STACK_SIZE_TYPICAL */
	#include <cyg/infra/diag.h>             /* diag_printf */
	#include <cyg/hal/t3.h>                 /* LED Control */
	#include <stdlib.h>
	
	
	void __attribute__ ((section (".2ram.flash_query"), long_call))
flash_query(void)
	{
	   for (int i=0; i < 0xffff; i++);
	}
	
	
	extern "C" int main(void)
	{   
	   flash_query();
	 
	   return 0;
	}

the build process (with errors returned)

	$ cd /z/TMCB/Build/ARM/eCos/app/testFLASH
	$ rm *.o
	$ arm-elf-gcc -c -I /i/eCOSbuilds/a161_install/include/
../../../../../source/app/testFLASH/*.cpp -fno-rtti -fno-exceptions
	../../../../../source/app/testFLASH/main.cpp: In function `void
flash_query()':
	../../../../../source/app/testFLASH/main.cpp:14: warning:
`long_call' attribute directive ignored
	$ arm-elf-gcc *.o -L /i/eCOSbuilds/a161_install/lib/ -Ttarget.ld
-nostdlib -Xlinker -Map -Xlinker mapfile.txt
	main.o: In function `main':
	main.o(.text+0x10): relocation truncated to fit: R_ARM_PC24
flash_query(void)
	collect2: ld returned 1 exit status

and to round things off the mods to arm.ld (extract) as suggested by
Jesper...

	#define SECTION_data(_region_,  _vma_, _lma_) \
	    .data _vma_ : _lma_ \
	    { __ram_data_start = ABSOLUTE (.); *(.data*) *(.data1)
MERGE_IN_RODATA \
	    _GOT1_START_ = ABSOLUTE (.); *(.got1) _GOT1_END_ = ABSOLUTE (.);
\
	    _GOT2_START_ = ABSOLUTE (.); *(.got2) _GOT2_END_ = ABSOLUTE (.);
\
	    . = ALIGN (4); \
	    __DEVTAB__ = ABSOLUTE (.); KEEP (*(SORT (.devtab*)))
__DEVTAB_END__ = ABSOLUTE (.); \
	    __NETDEVTAB__ = ABSOLUTE (.); KEEP (*(SORT (.netdevtab*)))
__NETDEVTAB_END__ = ABSOLUTE (.); \
	    __CTOR_LIST__ = ABSOLUTE (.); KEEP (*(SORT (.ctors*)))
__CTOR_END__ = ABSOLUTE (.); \
	    __DTOR_LIST__ = ABSOLUTE (.); KEEP (*(SORT (.dtors*)))
__DTOR_END__ = ABSOLUTE (.); \
	    *(.dynamic) *(.sdata*) *(.sbss*)  \
	    . = ALIGN (4); *(.2ram.*) } \
	    > _region_ \
	    __rom_data_start = LOADADDR (.data); \
	    __ram_data_end = .; PROVIDE (__ram_data_end = .); _edata = .;
PROVIDE (edata = .); \
	    PROVIDE (__rom_data_end = LOADADDR (.data) + SIZEOF(.data));



---
Transcomm UK Ltd.   DDI : +44 (0)23 80662155
Yeoman Park         Fax : +44 (0)23 80662120
Test Lane 
Southampton         www.transcomm.uk.com
SO16 9JX 

Re: [ECOS] forwarded message from Simpkins, Andy

[Jonathan Larmour]

"Simpkins, Andy" wrote:
> 
> Configuration of the system
>         Target Platform : Custom board (ARM7TDMI core)
>         Development Host: Windows NT 4 sp6, cygwin, eCos 1.3.1, GCC 2.95.2
[snip]

Perhaps just compile the whole file with -mlong-calls instead of the
attribute.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

RE: [ECOS] forwarded message from Simpkins, Andy

[Simpkins, Andy]

OK thanks for the advice,

I have a workaround at the moment and shall try gcc 3.0.1 when available on 
general release..

Thank you for your time

Andy

> -----Original Message-----
> From: Jonathan Larmour [ mailto:jlarmour@redhat.com ]
> Sent: 20 August 2001 14:25
> To: Simpkins, Andy
> Cc: ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] forwarded message from Simpkins, Andy
> 
> 
> "Simpkins, Andy" wrote:
> > 
> > Hi there,
> > 
> > You suggested using GCC 3.0.1, obviously this is available, 
> however the GNU
> > website doesn't appear to have links to it!  It was due for release
> > 01-08-2001 but has been delayed - is there any other way to 
> get a copy?
> 
> It was meant to be out this weekend but has been delayed. And 
> it look like
> their snapshot generation is currently broken :-|. That means the only
> thing to do right now hs check out of their CVS:
> http://gcc.gnu.org/cvs.html
> 
> Remember to check out using "-r gcc-v3_0-branch" to get the 
> 3.0 release
> branch (where 3.0.1 is coming from) rather than the trunk.
> 
> Jifl
> -- 
> Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 
> (1223) 271062
> Maybe this world is another planet's Hell -Aldous Huxley || 
> Opinions==mine
> 

Re: [ECOS] forwarded message from Simpkins, Andy

[Jonathan Larmour]

"Simpkins, Andy" wrote:
> 
> Hi there,
> 
> You suggested using GCC 3.0.1, obviously this is available, however the GNU
> website doesn't appear to have links to it!  It was due for release
> 01-08-2001 but has been delayed - is there any other way to get a copy?

It was meant to be out this weekend but has been delayed. And it look like
their snapshot generation is currently broken :-|. That means the only
thing to do right now hs check out of their CVS:
http://gcc.gnu.org/cvs.html

Remember to check out using "-r gcc-v3_0-branch" to get the 3.0 release
branch (where 3.0.1 is coming from) rather than the trunk.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

RE: [ECOS] forwarded message from Simpkins, Andy

[Simpkins, Andy]

Hi there,

You suggested using GCC 3.0.1, obviously this is available, however the GNU
website doesn't appear to have links to it!  It was due for release
01-08-2001 but has been delayed - is there any other way to get a copy?

Andy

> -----Original Message-----
> From: Jonathan Larmour [ mailto:jlarmour@redhat.com ]
> Sent: 17 August 2001 17:31
> To: Simpkins, Andy
> Cc: ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] forwarded message from Simpkins, Andy
> 
> 
> "Simpkins, Andy" wrote:
> > 
> > Nope that gives the same result :-(
> > 
> > $ arm-elf-gcc *.o -L /i/eCOSbuilds/a163_install/lib/ 
> -Ttarget.ld -nostdlib
> > -Xlinker -Map -Xlinker mapfile.txt -mlong-calls
> > main.o: In function `main':
> > main.o(.text+0x10): relocation truncated to fit: R_ARM_PC24
> > flash_query(void)
> > collect2: ld returned 1 exit status
> > 
> > what is ld trying to tell me with the truncated error 
> message?  I note that
> > this is in the function main NOT flash_query, is this significant?
> 
> Because that's where the call to flash_query happens.
> 
> Perhaps this just wasn't possible with gcc 2.95.2, in which 
> case your only
> choice is to move to gcc 3.0.1.
> 
> Jifl
> -- 
> Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 
> (1223) 271062
> Maybe this world is another planet's Hell -Aldous Huxley || 
> Opinions==mine
> 

Re: [ECOS] forwarded message from Simpkins, Andy

[Mark Salter]

>>>>> Simpkins, Andy writes:

> main.o: In function `main':
> main.o(.text+0x10): relocation truncated to fit: R_ARM_PC24
> flash_query(void)
> collect2: ld returned 1 exit status

> what is ld trying to tell me with the truncated error message?  I note that
> this is in the function main NOT flash_query, is this significant?

The linker is being asked to patch an opcode with the difference between
the PC and an address. The R_ARM_PC24 indicates the opcode needs a 24-bit
pc-relative offset. The long_call attribute should force gcc/gas to ask
for a 32-bit absolute address instead of pc-relative.

Here's what the gcc manual says:

`-mlong-calls'
`-mno-long-calls'
     Tells the compiler to perform function calls by first loading the
     address of the function into a register and then performing a
     subroutine call on this register.  This switch is needed if the
     target function will lie outside of the 64 megabyte addressing
     range of the offset based version of subroutine call instruction.

     Even if this switch is enabled, not all function calls will be
     turned into long calls.  The heuristic is that static functions,
     functions which have the `short-call' attribute, functions that
     are inside the scope of a `#pragma no_long_calls' directive and
     functions whose definitions have already been compiled within the
     current compilation unit, will not be turned into long calls.  The
     exception to this rule is that weak function definitions,
     functions with the `long-call' attribute or the `section'
     attribute, and functions that are within the scope of a `#pragma
     long_calls' directive, will always be turned into long calls.

--Mark

RE: [ECOS] forwarded message from Simpkins, Andy

[Simpkins, Andy]

I shall try GCC 3.0.1 and let you know

Have a good weekend 

Andy

> -----Original Message-----
> From: Jonathan Larmour [ mailto:jlarmour@redhat.com ]
> Sent: 17 August 2001 17:31
> To: Simpkins, Andy
> Cc: ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] forwarded message from Simpkins, Andy
> 
> 
> "Simpkins, Andy" wrote:
> > 
> > Nope that gives the same result :-(
> > 
> > $ arm-elf-gcc *.o -L /i/eCOSbuilds/a163_install/lib/ 
> -Ttarget.ld -nostdlib
> > -Xlinker -Map -Xlinker mapfile.txt -mlong-calls
> > main.o: In function `main':
> > main.o(.text+0x10): relocation truncated to fit: R_ARM_PC24
> > flash_query(void)
> > collect2: ld returned 1 exit status
> > 
> > what is ld trying to tell me with the truncated error 
> message?  I note that
> > this is in the function main NOT flash_query, is this significant?
> 
> Because that's where the call to flash_query happens.
> 
> Perhaps this just wasn't possible with gcc 2.95.2, in which 
> case your only
> choice is to move to gcc 3.0.1.
> 
> Jifl
> -- 
> Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 
> (1223) 271062
> Maybe this world is another planet's Hell -Aldous Huxley || 
> Opinions==mine
> 

Re: [ECOS] forwarded message from Simpkins, Andy

[Jonathan Larmour]

"Simpkins, Andy" wrote:
> 
> Nope that gives the same result :-(
> 
> $ arm-elf-gcc *.o -L /i/eCOSbuilds/a163_install/lib/ -Ttarget.ld -nostdlib
> -Xlinker -Map -Xlinker mapfile.txt -mlong-calls
> main.o: In function `main':
> main.o(.text+0x10): relocation truncated to fit: R_ARM_PC24
> flash_query(void)
> collect2: ld returned 1 exit status
> 
> what is ld trying to tell me with the truncated error message?  I note that
> this is in the function main NOT flash_query, is this significant?

Because that's where the call to flash_query happens.

Perhaps this just wasn't possible with gcc 2.95.2, in which case your only
choice is to move to gcc 3.0.1.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

RE: [ECOS] forwarded message from Simpkins, Andy

[Simpkins, Andy]

> -----Original Message-----
> From: Jonathan Larmour [ mailto:jlarmour@redhat.com ]
> Sent: 17 August 2001 17:10
> To: Simpkins, Andy
> Cc: ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] forwarded message from Simpkins, Andy
> 
> 
> "Simpkins, Andy" wrote:
> > 
> > Configuration of the system
> >         Target Platform : Custom board (ARM7TDMI core)
> >         Development Host: Windows NT 4 sp6, cygwin, eCos 
> 1.3.1, GCC 2.95.2
> [snip]
> 
> Perhaps just compile the whole file with -mlong-calls instead of the
> attribute.

Nope that gives the same result :-(

$ arm-elf-gcc *.o -L /i/eCOSbuilds/a163_install/lib/ -Ttarget.ld -nostdlib
-Xlinker -Map -Xlinker mapfile.txt -mlong-calls
main.o: In function `main':
main.o(.text+0x10): relocation truncated to fit: R_ARM_PC24
flash_query(void)
collect2: ld returned 1 exit status

what is ld trying to tell me with the truncated error message?  I note that
this is in the function main NOT flash_query, is this significant?

Andy

> 
> Jifl
> -- 
> Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 
> (1223) 271062
> Maybe this world is another planet's Hell -Aldous Huxley || 
> Opinions==mine
> 

RE: [ECOS] forwarded message from Simpkins, Andy

[David Airlie]

Do you have any forward declarations to it? i.e. declare function at top
of file to avoid warnings?

Dave.

On Fri, 17 Aug 2001, Simpkins, Andy wrote:

> Nope there are no header files associated with this - to keep bad header
> files out of the equation all of the code is resident in the file main.cpp
> (Although I did originally start with the function in a separate file!)
> 
> Andy
> 
> > -----Original Message-----
> > From: Mark Salter [ mailto:msalter@redhat.com ]
> > Sent: 17 August 2001 15:36
> > To: Andy.Simpkins@Transcomm.uk.com
> > Cc: ecos-discuss@sources.redhat.com
> > Subject: Re: [ECOS] forwarded message from Simpkins, Andy
> > 
> > 
> > >>>>> Simpkins, Andy writes:
> > 
> > > Sorry no go...
> > > it ignores the long_call statment and gives the same error 
> > in the linker...
> > 
> > Do you also have the __attribute__() on any extern declarations in
> > header files? If so, then I'm all out of suggestions.
> > 
> > --Mark
> > 
> 

-- 
      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] forwarded message from Simpkins, Andy

[Mark Salter]

>>>>> Simpkins, Andy writes:

> Nope there are no header files associated with this - to keep bad header
> files out of the equation all of the code is resident in the file main.cpp
> (Although I did originally start with the function in a separate file!)

You might try breaking it out into a seperate compilation unit.
Gcc may be ignoring the long_call attribute for calls made from
within the same compilation unit. But that is just a WAG.

--Mark

RE: [ECOS] forwarded message from Simpkins, Andy

[Simpkins, Andy]

Nope there are no header files associated with this - to keep bad header
files out of the equation all of the code is resident in the file main.cpp
(Although I did originally start with the function in a separate file!)

Andy

> -----Original Message-----
> From: Mark Salter [ mailto:msalter@redhat.com ]
> Sent: 17 August 2001 15:36
> To: Andy.Simpkins@Transcomm.uk.com
> Cc: ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] forwarded message from Simpkins, Andy
> 
> 
> >>>>> Simpkins, Andy writes:
> 
> > Sorry no go...
> > it ignores the long_call statment and gives the same error 
> in the linker...
> 
> Do you also have the __attribute__() on any extern declarations in
> header files? If so, then I'm all out of suggestions.
> 
> --Mark
> 

Re: [ECOS] forwarded message from Simpkins, Andy

[Mark Salter]

>>>>> Simpkins, Andy writes:

> Sorry no go...
> it ignores the long_call statment and gives the same error in the linker...

Do you also have the __attribute__() on any extern declarations in
header files? If so, then I'm all out of suggestions.

--Mark

RE: [ECOS] forwarded message from Simpkins, Andy

[Simpkins, Andy]

Sorry no go...

it ignores the long_call statment and gives the same error in the linker...

$ arm-elf-gcc -c -DMINIMAL_IOSTREAM -DECOS -DCLED -DDEBUGBLD -I
../../../../../source/header/ -I ../../../../../source/header/additionals/
-I ./../../../../source/API/Ivory/parser -I
/i/eCOSbuilds/a161_install/include/
../../../../../source/app/ecosIvory/*.cpp -fno-rtti -fno-exceptions
../../../../../source/app/ecosIvory/main.cpp: In function `void
flash_query()':
../../../../../source/app/ecosIvory/main.cpp:63: warning: `long_call'
attribute directive ignored

$ arm-elf-gcc *.o ../../API/*/*.o -L /i/eCOSbuilds/a161_install/lib/
-Ttarget.ld -nostdlib -Xlinker -Map -Xlinker mapfile.txt
main.o: In function `main':
main.o(.text+0x1c8): relocation truncated to fit: R_ARM_PC24
flash_query(void)
collect2: ld returned 1 exit status


Andy


> -----Original Message-----
> From: Mark Salter [ mailto:msalter@redhat.com ]
> Sent: 17 August 2001 15:18
> To: Andy.Simpkins@Transcomm.uk.com
> Cc: ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] forwarded message from Simpkins, Andy
> 
> 
> >>>>> Simpkins, Andy writes:
> 
> > OK that stops the compiler error but I now get 
> > arm-elf-gcc *.o ../../API/*/*.o -L /i/eCOSbuilds/a161_install/lib/
> > -Ttarget.ld -nostdlib -Xlinker -Map -Xlinker mapfile.txt
> > main.o: In function `main':
> > main.o(.text+0x1cc): relocation truncated to fit: R_ARM_PC24
> > flash_query(void *)
> 
> > collect2: ld returned 1 exit status
> 
> > any ideas? 
> 
> Yup. Try:
> 
> void __attribute__ ((section (".2ram.flash_query"), long_call)) 
> flash_query(void* data) 
> {
> }
> 
> --Mark
> 

Re: [ECOS] forwarded message from Simpkins, Andy

[Mark Salter]

>>>>> Simpkins, Andy writes:

> OK that stops the compiler error but I now get 
> arm-elf-gcc *.o ../../API/*/*.o -L /i/eCOSbuilds/a161_install/lib/
> -Ttarget.ld -nostdlib -Xlinker -Map -Xlinker mapfile.txt
> main.o: In function `main':
> main.o(.text+0x1cc): relocation truncated to fit: R_ARM_PC24
> flash_query(void *)

> collect2: ld returned 1 exit status

> any ideas? 

Yup. Try:

void __attribute__ ((section (".2ram.flash_query"), long_call)) 
flash_query(void* data) 
{
}

--Mark

RE: [ECOS] forwarded message from Simpkins, Andy

[Simpkins, Andy]

OK that stops the compiler error but I now get 

arm-elf-gcc *.o ../../API/*/*.o -L /i/eCOSbuilds/a161_install/lib/
-Ttarget.ld -nostdlib -Xlinker -Map -Xlinker mapfile.txt
main.o: In function `main':
main.o(.text+0x1cc): relocation truncated to fit: R_ARM_PC24
flash_query(void *)

collect2: ld returned 1 exit status

any ideas? 

Andy


> -----Original Message-----
> From: Mark Salter [ mailto:msalter@redhat.com ]
> Sent: 17 August 2001 14:56
> To: jskov@redhat.com
> Cc: ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] forwarded message from Simpkins, Andy
> 
> 
> >>>>> Jesper Skov writes:
> 
> >> void flash_query(void* data) __attribute__ ((section 
> >> (".2ram.flash_query")));
> >> 
> 
> > this always gives a compiler error : 
> 
> >  parse error before `{'
> 
> > when I have the following function
> 
> > void flash_query(void* data) __attribute__ ((section 
> (".2ram.flash_query")))
> > {
> > 	// do something
> > }
> 
> The attribute has to come before the function name, right. This 
> should work:
> 
> void __attribute__ ((section (".2ram.flash_query"))) 
> flash_query(void* data) 
> {
> 	// do something
> }
> 
> --Mark
> 

Re: [ECOS] forwarded message from Simpkins, Andy

[Mark Salter]

>>>>> Jesper Skov writes:

>> void flash_query(void* data) __attribute__ ((section 
>> (".2ram.flash_query")));
>> 

> this always gives a compiler error : 

>  parse error before `{'

> when I have the following function

> void flash_query(void* data) __attribute__ ((section (".2ram.flash_query")))
> {
> 	// do something
> }

The attribute has to come before the function name, right. This 
should work:

void __attribute__ ((section (".2ram.flash_query"))) flash_query(void* data) 
{
	// do something
}

--Mark

[ECOS] forwarded message from Simpkins, Andy

[Jesper Skov]

To : Jesper Skov <jskov at redhat dot com>
Subject : RE: [ECOS] running code from RAM / Memory Regions
From : "Simpkins, Andy" <Andy dot Simpkins at Transcomm dot uk dot com>
Date : Fri, 17 Aug 2001 14:36:52 +0100

Hi there,

Thanks for the pointers, I am afraid that I still need a little more help
though

Thanks

Andy


> -----Original Message-----
> From: Jesper Skov [ mailto:jskov@redhat.com ]
> Sent: 17 August 2001 10:58
> To: Simpkins, Andy
> Cc: ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] running code from RAM / Memory Regions
> 
> 
> >>>>> "Simpkins," == Simpkins, Andy 
> <Andy.Simpkins@Transcomm.uk.com> writes:
> 
> Simpkins,> Am I approaching this the write way?  Are there any
> Simpkins,> pitfalls I should watch out for?  Has this already been
> Simpkins,> done (obviously it has) but is the code available?
> 
> Simply mark the function to be located in .2ram and it will
> automagically do the right thing:
> 
> void flash_query(void* data) __attribute__ ((section 
> (".2ram.flash_query")));
> 

this always gives a compiler error : 

 parse error before `{'

when I have the following function

void flash_query(void* data) __attribute__ ((section (".2ram.flash_query")))
{
	// do something
}


> 
> That is, assuming you are using eCos from CVS. Otherwise you'll need
> to hack the arm.ld file so it contains a .data rule like this:

No I am not using a CVS snapshot so shall need the following...
> 
> #define SECTION_data(_region_,  _vma_, _lma_) \
>     .data _vma_ : _lma_ \
>     { __ram_data_start = ABSOLUTE (.); *(.data*) *(.data1) 
> MERGE_IN_RODATA \
>     _GOT1_START_ = ABSOLUTE (.); *(.got1) _GOT1_END_ = ABSOLUTE (.); \
>     _GOT2_START_ = ABSOLUTE (.); *(.got2) _GOT2_END_ = ABSOLUTE (.); \
>     . = ALIGN (4); \
>     KEEP(*( SORT (.ecos.table.*))) ;            \
>     . = ALIGN (4); \
>     __CTOR_LIST__ = ABSOLUTE (.); KEEP (*(SORT (.ctors*))) 
> __CTOR_END__ = ABSOLUTE (.); \
>     __DTOR_LIST__ = ABSOLUTE (.); KEEP (*(SORT (.dtors*))) 
> __DTOR_END__ = ABSOLUTE (.); \
>     *(.dynamic) *(.sdata*) *(.sbss*) \
>     . = ALIGN (4); *(.2ram.*) } \
>     > _region_ \
>     __rom_data_start = LOADADDR (.data); \
>     __ram_data_end = .; PROVIDE (__ram_data_end = .); _edata 
> = .; PROVIDE (edata = .); \
>     PROVIDE (__rom_data_end = LOADADDR (.data) + SIZEOF(.data));


I couldn't use your example directly because I also needed the section for
__DEVTAB__ but have been able to get this part working...

> 
> Cheers,
> Jesper
>