Experimental Physics and
Industrial Control System

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.
>>
>