1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 <2021> 2022 2023 2024 2025 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 <2021> 2022 2023 2024 2025 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: linking in IOC makefile for RTEMS |
From: | "Siddons, David via Tech-talk" <tech-talk at aps.anl.gov> |
To: | Michael Davidsaver <mdavidsaver at gmail.com> |
Cc: | EPICS tech-talk <tech-talk at aps.anl.gov> |
Date: | Mon, 19 Jul 2021 12:34:40 +0000 |
Hi Michael,
OK, thanks for the clarification. I'll try that.
What I want to do is make EPICS-aware detectors which are as self-contained as possible, and as easy to deploy as possible. Ideally, one would turn on the detector, plug it into any ethernet and be ready to go. A detector appliance, if you wish. Requiring NFS
mounts or TFTP servers goes against that goal. Using Linux on Zynq we have succeeded in this goal for some time. In fact, many years ago I built an RTEMS / EPICS system for the Coldfire uC5272, which was the basis for Eric's uC5282 BSP, and which used Eric's
tarball approach. Those systems were deployed to several institutions and, as far as I know, are still going. Recently I read that RTEMS had significantly improved in capabilities and ease of deployment, so I wanted to see if those Linux apps could be ported.
I'm convinced that is possible using remote filesystems, but I would really like them to be stand-alone.
Pete.
From: Michael Davidsaver <mdavidsaver at gmail.com>
Sent: Sunday, July 18, 2021 9:56 PM To: Siddons, David <siddons at bnl.gov> Cc: EPICS tech-talk <tech-talk at aps.anl.gov>; Johnson, Andrew N. <anj at anl.gov>; joel at rtems.org <joel at rtems.org> Subject: Re: linking in IOC makefile for RTEMS Hi Pete,
On 7/18/21 11:41 AM, Siddons, David wrote: > Hi Michael, > OK, you are right. That fixed the symbol problem and it now tries to mount the filesystem. Booting the resultant image I get: ... > The image was generated using the attached script, make-tarball.sh, and the current Makefile is also attached. I think you are confusing the two different ways which the rtems_init.c code in Base has for populating an in memory file system. The 'epicsRtemsFSImage' weak symbol can only be used with code generated by the 'epicsMakeMemFs.pl' script. The output of this script is _not_ a tar file. So linking in a tar file will not work (as you find). For example: > $(EPICS_BASE)/bin/linux-x86_64/epicsMakeMemFs.pl nottarball.c epicsRtemsFSImage README Makefile test.c The resulting nottarball.c will contain the three files README Makefile test.c, which will be unpacked into '/'. The other weak symbol '_DownloadLocation' is meant to be a tar file, although as I found, this probably only worked for the uC5282 target. Without changes to Base, this probably won't be useful for you with any other RTEMS target. https://epics.anl.gov/core-talk/2021/msg00880.php Maybe we should revisit why you aren't able to use a network file system? Being an IOC, I assume you target will have network access? > Pete. > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > *From:* Michael Davidsaver <mdavidsaver at gmail.com> > *Sent:* Saturday, July 17, 2021 2:44 PM > *To:* Siddons, David <siddons at bnl.gov> > *Cc:* EPICS tech-talk <tech-talk at aps.anl.gov>; Johnson, Andrew N. <anj at anl.gov> > *Subject:* Re: linking in IOC makefile for RTEMS > > On 7/16/21 12:47 PM, Siddons, David via Tech-talk wrote: >> Hi Andrew, >> It doesn't seem to. The file is clearly compiled and included in the support library: >> >> /home/peter/quick-start/rtems/5/bin/arm-rtems5-ar rc libmyexampleSupport.a xxxRecord.o devXxxSoft.o dbSubExample.o devmyexampleVersion.o myexampleHello.o initTrace.o tarball.o > > I'm not sure my 'epicsRtemsFSImage' trick will work from a library. > > Try moving tarball.c to myexample_SRCS. > >> myexample_SRCS += tarball.c > > And I think you can just remove '..._SRCS += tarball.h'. > It's probably not doing anything helpful. > > >> arm-rtems5-nm libmyexampleSupport.a |grep epicsRtems >> 00000000 R epicsRtemsFSImage >> 00000000 R epicsRtemsFSImage_size >> >> but not in the myexample executable: >> >> peter@peter-OptiPlex-7070:~/test_ioc/bin/RTEMS-beagleboneblack$ arm-rtems5-nm myexample |grep epicsRtems >> 8060306c V epicsRtemsFSImage >> >> which is the weak symbol. >> Pete. >> >> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ >> *From:* Johnson, Andrew N. <anj at anl.gov> >> *Sent:* Friday, July 16, 2021 3:21 PM >> *To:* Siddons, David <siddons at bnl.gov> >> *Cc:* EPICS tech-talk <tech-talk at aps.anl.gov> >> *Subject:* Re: linking in IOC makefile for RTEMS >> >> Hi Pete, >> >> Just an idea, does it make any difference if you remove the tarball.h file from your _SRCS variable (you shouldn’t include .h files in _SRCS anyway, if you want to install them they go into INC instead)? >> >> - Andrew >> >> >>> On Jul 16, 2021, at 2:08 PM, Siddons, David via Tech-talk <tech-talk at aps.anl.gov <mailto:tech-talk at aps.anl.gov <mailto:tech-talk at aps.anl.gov>>> wrote: >>> >>> I have an RTEMS test IOC (generated using makeBaseApp) to which I've added a source file which declares a large array (actually, a compiled-in file system). The Makefile has: >>> >>> ...... >>> # rather than directly into the IOC application, that >>> # causes problems on Windows DLL builds >>> myexampleSupport_SRCS += dbSubExample.c >>> myexampleSupport_SRCS += devmyexampleVersion.c >>> myexampleSupport_SRCS += myexampleHello.c >>> myexampleSupport_SRCS += initTrace.c >>> myexampleSupport_SRCS += tarball.h >>> myexampleSupport_SRCS += tarball.c >>> >>> where the tarball files are my additions. The C file contains: >>> >>> /* >>> * Declarations for C structure representing binary file epicsRtemsFSImage >>> * >>> * WARNING: Automatically generated -- do not edit! >>> */ >>> >>> #include <sys/types.h> >>> >>> const unsigned char epicsRtemsFSImage[] = { >>> 0x74, 0x61, 0x72, 0x62, 0x61, 0x6c, 0x6c, 0x2f, 0x00, 0x00, 0x00, 0x00, >>> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, >>> .....etc, then: >>> >>> const size_t epicsRtemsFSImage_size = sizeof(epicsRtemsFSImage); >>> >>> >>> The EPICS base libraries contain a weak reference to this same symbol (from libcom/RTEMS/init.c) , and I expected this definition to overwrite the weak one, but inspection of the executable only shows the weak one, and the size variable is not referenced at all. What am I missing? It seems that the tarball file is compiled, but not linked. >>> >>> Pete. >> >> -- >> Complexity comes for free, simplicity you have to work for. >> > |