This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re:


Hello:

Please use the eCos reflector list to everyone can benefit from
the reply.

> The board used is STM3220G-EVAL.I want to download the Matlab_Simulink
> model to the board,and execute the simulink model.

I believe that you are overestimating what the library loader can do.

The object loader was designed as a very simple way to load pieces
of code in memory, relocate them and then execute the code in them.
There is nothing that prevents loading larger pieces of code (and
I know of a couple of companies that are running very sophisticated
libraries with it) but with large code, compiled by agents other than
the eCos toolchain, the chances of stumbling into roadblocks are
increasing very fast. This is your case.

The code that is loaded must be an object file that is compiled but NOT
linked, as detailed in information included in the library.

In your case it is very likely that the Matlab_Simulink library you want to
execute is some sort of executable itself, rather than an object file and
thus not a good choice for the object loader.

> but when i compile the C files under Matlab_Simulink,and link
> the libgcc.a library under the PATH
> \opt\ecos\gnutools\arm-eabi\lib\gcc\arm-eabi\4.3.2\thumb\thumb2 to the
> exectable file, the value of p_rel.r_info will be 10,which will lead
> switch() function execute the default branch and return -1,therefore
> the exectution failed.

Correct. So let's assume for the time being that the file you want to
load is indeed an object file.

The values that appear inside the switch statement have been chosen
among those described in the ARM ELF document:

http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044e/IHI0044E_aaelf.pdf

The possible relocation codes are shown in table 4-8. As you can see
a full fledged linker must support all these types but for a simple object
loader like the one in eCos a far smaller subset is needed to cover the
majority of the cases encountered for sinple libraries comoiled with the
eCos toolchain. The codes you see in the switch() statement are
those that appeared while compiling several programs I tested during
development but the list must not be thought as complete by any
means.

In your case the code 10 corresponds to the R_ARM_THM_CALL
addressing mode (again, see table 4-8), which is a THUMB32 code
(consistent with the fact that you are using a Cortex core).

The objloader code was never tested for Thumb code, although I cannot
think of any reason why it should not work. The 4th column in the table
shows what type of relocation you have to apply for each addressing code.
You will have to add the missing addressing modes to the
cyg_ldr_relocate() function in relocate_arm.c.

Since you are entering uncharted territory here,
one piece of advice I can provide is to start simple: Compile a very
simple library with some test code in Thumb32. Load this library, and
in the process add all missing addressing modes to the cyg_ldr_relocate()
function as they are discovered by the loader (it helps a lot here to
select CYGPKG_SERVICES_OBJLOADER_DEBUG_LEVEL = 2
and let the loader be very verbose in its output so you can see immediately
what goes wrong.) Increase the complexity of the test library until you
are convinced that most required addressing modes have been
taken care of. Then, and only then, you can try the Simulink
library (which might very well require some more addressing modes
to be added.)

Since Cortex processors are very much in use today and many people
could use this, it would be greatly appreciated if you contributed the
resulting work back to the eCos community.

Regards
Anthony Tonizzo

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]