Simple question about RTL

[xuelin.tian at qkmtech.com]

Thanks for your reply. 
Today I tried to build the master version of RTEMS, but failed with some error I have not seen before. So, I build the 4.11-release with some patches posted by Chris instead. It does not work on my Zedboard. 
So, could you send the link of your github that I can check the patch you commit? Thanks.


Best wishes,
Tim Tian
xuelin.tian at qkmtech.com
 
From: Pavel Pisa
Date: 2016-09-05 21:52
To: xuelin.tian at qkmtech.com
CC: users at rtems.org; Chris Johns
Subject: Re: Simple question about RTL
Hello Tim Tian,
 
On Monday 05 of September 2016 15:19:54 xuelin.tian at qkmtech.com wrote:
> Hello Pavel,
> The RTEMS version is 4.11-release.
> Today, I download the latest 4.11-release with "fix cache corruption bugs"
> patch, and build it.
 
no that is not enough. This patch correct symbol cache problems
but not CPU cache problems.
 
More patches has to be applied to 4.11 to make RTL work
on targets with cache. The generic cache manager is +/-
OK on 4.11 to make it work on Zynq and Altera. For other ARM
targets there is even more patches which should be applied
to fix the problems.
 
I can prepare 4.11 branch on my GitHub account and if it is confirmed,
that it works, then discussion about inclusion to yet unreleased 4.11
should start. Other option is to release 4.11 and correct these for
4.11.1.
 
But generally for 4.11, RTL has to be considered as not available
for cache enabled targets which needs explicit instruction
and data cache sync (PowerPC, ARM). master branch is fully OK for
targets with snoopable instruction cache fills, for other targets
in the case when undefined symbols are filled later, there is still
small but real problem possible.
 
Best wishes,
 
 
                 Pavel
 
> I use the new tool-chain and bsp to build my 
> application and the bug remains. And I check my appdl-symbol-table.o via
> arm-rtems4.11-nm, no "hello_world" (which is the function I want to jump
> to) found. Is it correct? I follow your instructions to get .prelink, to
> get symbol table, and to get the final image. Do you have any hints on
> this? Thank you.
>
>
>
> Best wishes,
> Tim Tian
> xuelin.tian at qkmtech.com
>
> From: Pavel Pisa
> Date: 2016-09-04 21:10
> To: xuelin.tian at qkmtech.com
> CC: users at rtems.org; Chris Johns
> Subject: Re: Simple question about RTL
> Hello Tim Tian,
>
> On Sunday 04 of September 2016 14:52:44 xuelin.tian at qkmtech.com wrote:
> > This problem drives me crazy.
> >
> > I can use dlopen to load my object file, this part works fine. When I 
loaded the object file, it showed something like:
> > > handle: 0x2a9bb0 loaded
> >
> > And then I could get the address of this handle via dlsym,
> >
> > > call = dlsym(handle, "hello_world");
> > > if (call == NULL) {
> > > printf("dlsym failed: symbol hello_world not found\n");
> > > return 1;
> > > }
> > > printf("address: %x\n", call);
> >
> > it said like:
> > > address: 2aa3a1
> >
> > But, when I continued to jump to the entry point of call, the system
> > crashed.
>
> what is the RTEMS sources version?
>
> I have tested RTL on Zynq about last week and it worked correctly.
> I use actual RTEMS master git sources.
>
> If you use RTEMS build before next patch then it is highly probable
> that you experience failures on stargets with cache enabled.
>
>   libdl/rtl-obj.c: synchronize cache after code relocation.
>   Pavel Pisa<pisa at cmp.felk.cvut.cz>
>   7/21/16 2:35 AM
>
> There is even another patch which synchronizes and cleans cache during
> startup
>
>   arm/xilinx_zynq: ensure that cache is cleaned and MMU disabled when
> initialization starts. Chris Johns<chrisj at rtems.org>
>   Pavel Pisa<pisa at cmp.felk.cvut.cz>
>   8/31/16 4:49 PM
>
> It should not be crucial for UP (non SMP) use. But it would worth
> to retest your actual RTEMS master version.
>
> If you are working with stable RTEMS 4.11 pre-release branch
> then problems are not fixed there.
>
> I think that it would worth to consider whole cache related
> issues update for 4.11 branch as well.
>
> Best wishes,
>
>                Pavel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20160905/b01ce3fe/attachment-0002.html>