<div dir="ltr">Thank you so much Heinz and Gedare for the suggestion of using sed instead of patches.<div><br></div><div>The good news is that I worked with them and EPICS 7 was built successfully</div><div>for "xilinx_zynq_a9_qemu" using RSB recipe. </div><div><br></div><div>The changes I made were  as follows:</div><div><br></div><div>```<span style="color:rgb(0,0,0);white-space:pre-wrap">diff --git a/source-builder/config/epics-7-1.cfg b/source-builder/config/epics-7-1.cfg</span></div><pre style="color:rgb(0,0,0);white-space:pre-wrap">index 2398cacf..f51c6582 100644
--- a/source-builder/config/epics-7-1.cfg
+++ b/source-builder/config/epics-7-1.cfg
@@ -31,10 +31,20 @@ URL:          <a href="https://epics.mpg.de/">https://epics.mpg.de/</a>
   source_dir_epics="epics-base-%{epics_version}"
 
   %source setup epics -q -n epics-base-%{epics_version}
-  %patch setup epics -p1
+#
+# Changing the RTEMS Version in epics-base/configure/os/CONFIG_SITE.Common.RTEMS
+#
+sed -i 's/RTEMS_VERSION = .*/RTEMS_VERSION = 5/g' configure/os/CONFIG_SITE.Common.RTEMS
+
+#
+# Changing the RTEMS Base in epics-base/configure/os/CONFIG_SITE.Common.RTEMS
+#
+sed -i "s/^RTEMS_BASE .*/RTEMS_BASE = \/home\/mritunjay\/development\/rtems\/\$\(RTEMS_VERSION\)\-arm/g" configure/os/CONFIG_SITE.Common.RTEMS
 
   cd ${build_top}
 
+
+
 %build
   build_top=$(pwd)
 ```</pre><div>The changes can be observed from here as well: <a href="https://github.com/RTEMS/rtems-source-builder/commit/1e7d7d4237a479dce564711b1080a9b3225e9e9a">https://github.com/RTEMS/rtems-source-builder/commit/1e7d7d4237a479dce564711b1080a9b3225e9e9a</a></div><div><br></div><div>One issue that remains is that even after adding sha512 has for epics-base-7.0.tar.gz, I am getting "no hash found"  warning. </div><div>However, the build is running successfully. </div><div><br></div><div>Now that it is seen that sed can be used, the next step, in my opinion, is to develop a logic for making these changes use-oriented as even now, </div><div>I have to specify my directory in the scripts, the only difference is that I am using sed instead of patch.</div><div><br></div><div>Thank you again, Heinz and Gedare for introducing me to sed and making me revise some regex as well! </div><div><br></div><div>Thanks</div><div>Mritunjay Sharma</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 12, 2020 at 7:07 PM Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Aug 12, 2020 at 1:58 AM Heinz Junkes <<a href="mailto:junkes@fhi-berlin.mpg.de" target="_blank">junkes@fhi-berlin.mpg.de</a>> wrote:<br>
><br>
> I think you should not make a patch for these two changes but a<br>
> simple replacement with e.g. sed.<br>
><br>
> like<br>
><br>
> sed -i ’s/^RTEMS_BASE/RTEMS_BASE = \/home\/mritunjay\/development\/rtems/\$\(RTEMS_VERSION\)-arm\/g’ configure/os/CONFIG_SITE.Common.RTEMS<br>
><br>
> oder so ;-)<br>
><br>
<br>
Yes, great, that was something I think I mentioned before--the patches<br>
are fine to get things hacked, but we should script the configuration<br>
if we can from RSB. A cross-platform python-based approach must be<br>
used.<br>
<br>
><br>
> Viele Grüße<br>
> Heinz Junkes<br>
> --<br>
> Experience directly varies with equipment ruined.<br>
><br>
><br>
><br>
> > On 12. Aug 2020, at 02:13, Mritunjay Sharma <<a href="mailto:mritunjaysharma394@gmail.com" target="_blank">mritunjaysharma394@gmail.com</a>> wrote:<br>
> ><br>
> > Hello Heinz and everyone!<br>
> ><br>
> > Thank you so much for this update. I started to work first by building EPICS by hand<br>
> > for "xilinx_zynq_a9_qemu". Till the time, you gave <a href="https://gitlab.fhi.mpg.de/junkes/epics-base.git" rel="noreferrer" target="_blank">https://gitlab.fhi.mpg.de/junkes/epics-base.git</a>,<br>
> > I had to struggle with lot of errors which cloning into this repo solved.<br>
> ><br>
> > So I started by building "xilinx_zynq_a9_qemu" BSP for RTEMS5 using my own blog with only difference being<br>
> > that  I used '--disable-networking' to use libbsd.<br>
> ><br>
> > After that, I used this blog <a href="https://rmeena840.github.io/Fourth-Post/" rel="noreferrer" target="_blank">https://rmeena840.github.io/Fourth-Post/</a> of a GSoC 19 Student to build and install rtems-libbsd<br>
> > for  "xilinx_zynq_a9_qemu".<br>
> ><br>
> > Everything worked perfectly fine till now. Now I entered the 'epics-base' directory and made<br>
> > the changes in configure/os/CONFIG_SITE.Common.RTEMS as:<br>
> ><br>
> > # FHI:<br>
> > RTEMS_SERIES = 5<br>
> > RTEMS_VERSION = 5<br>
> > RTEMS_BASE = /home/mritunjay/development/rtems/$(RTEMS_VERSION)-arm<br>
> ><br>
> > Also made the change in configure/CONFIG_SITE:<br>
> ><br>
> > CROSS_COMPILER_TARGET_ARCHS=RTEMS-xilinx_zynq_a9_qemu<br>
> ><br>
> > After this I used 'make' command and it worked fine.<br>
> ><br>
> > So, I can say that there were just two changes which I had to make then the previous one.<br>
> ><br>
> > The successful build by hand enabled me to work on the RSB recipe.<br>
> ><br>
> > I worked on them and it can be found here <a href="https://github.com/RTEMS/rtems-source-builder/compare/master...mritunjaysharma394:epics-support-zynq" rel="noreferrer" target="_blank">https://github.com/RTEMS/rtems-source-builder/compare/master...mritunjaysharma394:epics-support-zynq</a>.<br>
> ><br>
> > The patch I am applying can be found here: <a href="https://raw.githubusercontent.com/mritunjaysharma394/epics-mritunjay/master/patches/0001-Added-support-for-RTEMS-xilinx_zynq_a9_qemu.patch" rel="noreferrer" target="_blank">https://raw.githubusercontent.com/mritunjaysharma394/epics-mritunjay/master/patches/0001-Added-support-for-RTEMS-xilinx_zynq_a9_qemu.patch</a><br>
> ><br>
> > However, the problem I am facing is that while building the recipe using:<br>
> > ```.../source-builder/sb-builder --log=log_epics epics-7-1```,<br>
> > the build is failing because it seems that Patch setup in configure file is not getting applied there. I followed the same steps as done for pc<br>
> > but this time the patch is not getting applied.<br>
> ><br>
> > It will be really helpful if you can guide where did I went wrong thist time.<br>
> ><br>
> > I am attaching the log and report file for reference.<br>
> ><br>
> > Thanks<br>
> > Mritunjay<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > On Mon, Aug 10, 2020 at 8:56 PM junkes <<a href="mailto:junkes@fhi-berlin.mpg.de" target="_blank">junkes@fhi-berlin.mpg.de</a>> wrote:<br>
> > Hello Mritunjay,<br>
> ><br>
> > I have now finished an EPICS variant that works with libbsd so far. DHCP and NFS work. NTP I added a primitive reader. This is sufficient for testing.<br>
> ><br>
> > You can find the development here:<br>
> ><br>
> > <a href="https://gitlab.fhi.mpg.de/junkes/epics-base.git" rel="noreferrer" target="_blank">https://gitlab.fhi.mpg.de/junkes/epics-base.git</a><br>
> ><br>
> > It's not perfect yet. The adaptation to the legacy stack and the processing of the environment variables from the flash (u-boot etc.) is still missing.<br>
> ><br>
> > [h1@earth QtC-epics-base (7.0 *+)]$ ./startQemu softIoc<br>
> > Script name: ./startQemu<br>
> > qemu-system-aarch64: warning: nic cadence_gem.1 has no peer<br>
> > WARNING: OS Clock time was read before being set.<br>
> > Using 1990-01-02 00:00:00.000000 UTC<br>
> ><br>
> > initConsole --- Info ---<br>
> > stdin: fileno: 0, ttyname: /dev/ttyS1<br>
> > stdout: fileno: 1, ttyname: /dev/ttyS1<br>
> > stderr: fileno: 2, ttyname: /dev/ttyS1<br>
> > tcsetattr failed: I/O error<br>
> > time set to : 04/14/14 07:30:06.000055589 UTC<br>
> > Startup.<br>
> > epicsThreadSetPriority called by non epics thread<br>
> ><br>
> > ***** RTEMS Version: rtems-5.0.0-m2003 (ARM/ARMv4/xilinx_zynq_a9_qemu) *****<br>
> ><br>
> > ***** Initializing network (dhcp) *****<br>
> > nexus0: <RTEMS Nexus device><br>
> > zy7_slcr0: <Zynq-7000 slcr block> on nexus0<br>
> > cgem0: <Cadence CGEM Gigabit Ethernet Interface> on nexus0<br>
> > miibus0: <MII bus> on cgem0<br>
> > e1000phy0: <Marvell 88E1111 Gigabit PHY> PHY 0 on miibus0<br>
> > e1000phy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto<br>
> > e1000phy1: <Marvell 88E1111 Gigabit PHY> PHY 23 on miibus0<br>
> > e1000phy1:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto<br>
> > info: cgem0: Ethernet address: 52:54:00:12:34:56<br>
> > info: lo0: link state changed to UP<br>
> ><br>
> > ---- Wait for DHCP done ...<br>
> > dhcpcd: unknown option -- pv4only<br>
> > info: version 6.2.1 starting<br>
> > cgem0: cgem_mediachange: could not set ref clk0 to 25000000.<br>
> > info: cgem0: link state changed to UP<br>
> > dhcpcd: unknown option -- pv4only<br>
> > debug: cgem0: executing `ioc boot' PREINIT<br>
> ><br>
> > ***** Primary Network interface : cgem0 *****<br>
> > debug: cgem0: executing `ioc boot' CARRIER<br>
> ><br>
> > ***** Primary Network interface : cgem0 *****<br>
> > info: DUID 00:01:00:01:1a:de:4a:fe:52:54:00:12:34:56<br>
> > info: cgem0: IAID 00:12:34:56<br>
> > info: cgem0: soliciting an IPv6 router<br>
> > debug: cgem0: delaying Router Solicitation for LL address<br>
> > debug: cgem0: using ClientID 00:46:48:49:20:74:65:73:74:20:63:6c:69:65:6e:74<br>
> > info: cgem0: soliciting a DHCP lease<br>
> > debug: cgem0: sending DISCOVER (xid 0x86686938), next in %0.1f seconds<br>
> > info: cgem0: carrier lost<br>
> > debug: cgem0: executing `ioc boot' NOCARRIER<br>
> ><br>
> > ***** Primary Network interface : cgem0 *****<br>
> > info: cgem0: carrier acquired<br>
> > dhcpcd: unknown option -- pv4only<br>
> > debug: cgem0: executing `ioc boot' CARRIER<br>
> ><br>
> > ***** Primary Network interface : cgem0 *****<br>
> > info: cgem0: IAID 00:12:34:56<br>
> > info: cgem0: soliciting an IPv6 router<br>
> > debug: cgem0: delaying Router Solicitation for LL address<br>
> > debug: cgem0: using ClientID 00:46:48:49:20:74:65:73:74:20:63:6c:69:65:6e:74<br>
> > info: cgem0: soliciting a DHCP lease<br>
> > debug: cgem0: sending DISCOVER (xid 0x441a0d89), next in %0.1f seconds<br>
> > debug: cgem0: wrong xid 0x86686938 (expecting 0x441a0d89) from 10.1.0.1<br>
> > debug: cgem0: sending DISCOVER (xid 0x441a0d89), next in %0.1f seconds<br>
> > info: cgem0: offered 10.1.0.104 from 10.1.0.1<br>
> > debug: cgem0: sending REQUEST (xid 0x441a0d89), next in %0.1f seconds<br>
> > debug: cgem0: acknowledged 10.1.0.104 from 10.1.0.1<br>
> > debug: cgem0: checking for 10.1.0.104<br>
> > debug: cgem0: sending ARP probe (1 of 3), next in %0.1f seconds<br>
> > debug: cgem0: sending ARP probe (2 of 3), next in %0.1f seconds<br>
> ><br>
> > ---- Wait for DHCP done ...<br>
> > debug: cgem0: sending ARP probe (3 of 3), next in %0.1f seconds<br>
> > info: cgem0: leased 10.1.0.104 for 6000 seconds<br>
> > debug: cgem0: renew in 3000 seconds, rebind in 5250 seconds<br>
> > debug: cgem0: adding IP address <a href="http://10.1.0.104/24" rel="noreferrer" target="_blank">10.1.0.104/24</a><br>
> > info: cgem0: adding host route to 10.1.0.104 via 127.0.0.1<br>
> > err: cgem0: ipv4_addroute: File exists<br>
> > info: cgem0: adding route to <a href="http://10.1.0.0/24" rel="noreferrer" target="_blank">10.1.0.0/24</a><br>
> > err: cgem0: ipv4_addroute: File exists<br>
> > info: cgem0: adding default route via 10.1.0.1<br>
> > debug: cgem0: writing lease `/var/db/dhcpcd-cgem0.lease'<br>
> > debug: cgem0: executing `ioc boot' BOUND<br>
> ><br>
> > ***** Primary Network interface : cgem0 *****<br>
> > Interface TGP bounded<br>
> > rtems_bsdnet_bootp_server_name : 1001.1001@10.1.0.1:/Volumes/Epics<br>
> > rtems_bsdnet_bootp_boot_file_name : /Volumes/Epics/myExample/bin/RTEMS-xilinx_zynq_a9_qemu/myExample.boot<br>
> > rtems_bsdnet_bootp_cmdline : /Volumes/Epics/myExample/iocBoot/iocmyExample/st.cmd<br>
> > debug: cgem0: sending ARP announce (1 of 2), next in 2.0 seconds<br>
> > -------------- IFCONFIG -----------------<br>
> > cgem0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500<br>
> >        options=80008<VLAN_MTU,LINKSTATE><br>
> >        ether 52:54:00:12:34:56<br>
> >        inet6 fe80::5054:ff:fe12:3456%cgem0 prefixlen 64 scopeid 0x1<br>
> >        inet 10.1.0.104 netmask 0xffffff00 broadcast 10.1.0.255<br>
> >        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL><br>
> >        media: Ethernet autoselect (100baseTX <full-duplex>)<br>
> >        status: active<br>
> > lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384<br>
> >        options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6><br>
> >        inet 127.0.0.1 netmask 0xffffff00<br>
> >        inet6 ::1 prefixlen 128<br>
> >        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2<br>
> >        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL><br>
> >        groups: lo<br>
> > -------------- NETSTAT ------------------<br>
> > Routing tables<br>
> ><br>
> > Internet:<br>
> > Destination        Gateway            Flags     Netif Expire<br>
> > default            10.1.0.1           UGS       cgem0<br>
> > <a href="http://10.1.0.0/24" rel="noreferrer" target="_blank">10.1.0.0/24</a>        link#1             U         cgem0<br>
> > 10.1.0.104         link#1             UHS         lo0<br>
> > 127.0.0.1          link#2             UH          lo0<br>
> ><br>
> > Internet6:<br>
> > Destination                       Gateway                       Flags     Netif Expire<br>
> > ::1                               link#2                        UH          lo0<br>
> > fe80::%cgem0/64                   link#1                        U         cgem0<br>
> > fe80::5054:ff:fe12:3456%cgem0     link#1                        UHS         lo0<br>
> > fe80::%lo0/64                     link#2                        U           lo0<br>
> > fe80::1%lo0                       link#2                        UHS         lo0<br>
> ><br>
> > ***** Until now no NTP support in RTEMS 5 with rtems-libbsd *****<br>
> ><br>
> > ***** Ask ntp server once... *****<br>
> > time from ntp : 08/10/20 15:08:41.000055589 UTC<br>
> ><br>
> > ***** Setting up file system *****<br>
> > ***** Initializing NFS *****<br>
> > rtems_bootp_server_name: 1001.1001@10.1.0.1:/Volumes/Epics<br>
> > nfsMount("<a href="mailto:1001.1001@10.1.0.1" target="_blank">1001.1001@10.1.0.1</a>", "/Volumes/Epics", "/Volumes/Epics")<br>
> > Mount 1001.1001@10.1.0.1:/Volumes/Epics on /Volumes/Epics<br>
> > Warning: EPICS_TIMEZONE (CST6CDT,M3.2.0/2,M11.1.0/2) unrecognizable -- times will be displayed as GMT.<br>
> > check for time registered , C++ initialization ...<br>
> > ***** Preparing EPICS application *****<br>
> > chdir("/Volumes/Epics/myExample/iocBoot/iocmyExample/")<br>
> > ***** Starting EPICS application *****<br>
> > dbLoadDatabase("../../dbd/softIoc.dbd")<br>
> > Can't register 'system' command -- no command interpreter available.<br>
> > softIoc_registerRecordDeviceDriver(pdbbase)<br>
> > # Begin /Volumes/Epics/myExample/iocBoot/iocmyExample/st.cmd<br>
> > iocInit()<br>
> > Starting iocInit<br>
> > ############################################################################<br>
> > ## EPICS R7.0.3.2-DEV<br>
> > ## Rev. R7.0.3.1-105-ge597f8104c18ec7b9fc5-dirty<br>
> > ############################################################################<br>
> > debug: cgem0: sending ARP announce (2 of 2)<br>
> > Warning: RSRV has empty beacon address list<br>
> > epicsThreadRealtimeLock Warning: Unable to lock the virtual address space.<br>
> > VM page faults may harm real-time performance. errno=22<br>
> > iocRun: All initialization complete<br>
> > # End /Volumes/Epics/myExample/iocBoot/iocmyExample/st.cmd<br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > On 2020-08-08 21:58, Mritunjay Sharma wrote:<br>
> ><br>
> >><br>
> >><br>
> >> On Sat, Aug 8, 2020 at 11:10 PM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>> wrote:<br>
> >> On Sat, Aug 8, 2020 at 11:08 AM Mritunjay Sharma<br>
> >> <<a href="mailto:mritunjaysharma394@gmail.com" target="_blank">mritunjaysharma394@gmail.com</a>> wrote:<br>
> >> ><br>
> >> ><br>
> >> ><br>
> >> > On Sat, Aug 8, 2020 at 9:46 PM Heinz Junkes <<a href="mailto:junkes@fhi-berlin.mpg.de" target="_blank">junkes@fhi-berlin.mpg.de</a>> wrote:<br>
> >> >><br>
> >> >> Hallo Mritunjay,<br>
> >> >> everything looks pretty good. I'm commenting on the text. I also send this mail<br>
> >> >> to two EPICS experts (Andrew Johnson and Michael Davidsaver). Maybe they also have some ideas.<br>
> >> ><br>
> >> ><br>
> >> > Thank you so much Heinz! It will be really a great help!<br>
> >> >><br>
> >> >><br>
> >> >><br>
> >> >> ><br>
> >> >> > Current Status:<br>
> >> >> ><br>
> >> >> > 1) Successfully built EPICS7 with RTEMS5 by hand for pc-386<br>
> >> >> > 2) Worked for RSB recipe.<br>
> >> >> >    In its due process, I Wrote:<br>
> >> >> >     i) rsb/rtems/config/epics/epics-7-1.cfg<br>
> >> >> >     ii)rsb/rtems/config/epics/epics-base.bset<br>
> >> >> >     iii)rsb/source-builder/config/epics-7-1.cfg<br>
> >> >> > 3) Added Patch for RTEMS-pc-386 support which made the above recipe work successfully.<br>
> >> >> > 4) Therefore, Successully built EPICS7 with RTEMS5 by using RSB recipe as well for pc-386 as of now.<br>
> >> >> > 5) Sent 4 Patches for review of the same.<br>
> >> >> ><br>
> >> >> > What problems are in the next steps?<br>
> >> >> ><br>
> >> >> > 1) How to make it work across different architectures?<br>
> >> >> > 2) Exisiting EPICS works on the old legacy network stack.<br>
> >> >> > 3) I am not using EPICS upstream branch. It is being built<br>
> >> >> > by Heinz's epics playground.<br>
> >> >> > 4) Doubts in how to start with testing.<br>
> >> >> ><br>
> >> >> > My Resarch work for the Problem no: 1<br>
> >> >> ><br>
> >> >> > I have gone through the EPICS developer guide from here<br>
> >> >> > exhaustively in the past couple of day and here are few interesting things<br>
> >> >> > that I found which can help:<br>
> >> >> ><br>
> >> >> > 1) "The main ingredients of the build system are:<br>
> >> >> > • A set of configuration files and tools provided in the EPICS base/configure directory<br>
> >> >> > • A corresponding set of configuration files in the <top>/configure directory of a non-base <top> directory<br>
> >> >> > structure to be built. The makeBaseApp.pl and makeBaseExt.pl scripts create these configuration files. Many of<br>
> >> >> > these files just include a file of the same name from the base/configure directory.<br>
> >> >> > • Makefiles in each directory of the <top> directory structure to be built<br>
> >> >> > • User created configuration files in build created $(INSTALL_LOCATION)/cfg directories.<br>
> >> >> > "<br>
> >> >> ><br>
> >> >> > Remarks: Now since it is also mentioned in the guide that "makeBaseApp.pl<br>
> >> >> > creates directories and then copies template files into the newly created directories<br>
> >> >> > while expanding macros in the template files. EPICS base provides two sets of template files: simple and example."<br>
> >> >> > Can we think of using makeBaseApp.pl to that end? Making the user allow<br>
> >> >> > to change the configurations from the terminal?<br>
> >> >><br>
> >> >> I don't think that makeBaseApp.pl will help you. This is intended to build an example IOC. It takes the settings from the above mentioned configuration files.<br>
> >> >><br>
> >> >> You "only" need to specify the location of the RTEMS installation in configure/os/CONFIG_SITE.Common.RTEMS.<br>
> >> >> RTEMS_VERSION =<br>
> >> >> RTEMS_BASE =<br>
> >> >><br>
> >> >> Then you have to define the target in configure/CONFIG_SITE:<br>
> >> >> ...<br>
> >> >> # Which target architectures to cross-compile for.<br>
> >> >> #  Definitions in configure/os/CONFIG_SITE.<host>.Common<br>
> >> >> #  may override this setting.<br>
> >> >> CROSS_COMPILER_TARGET_ARCHS=<br>
> >> >> ...<br>
> >> >> e.g. "CROSS_COMPILER_TARGET_ARCHS=RTEMS-xilinx_zynq_a9_qemu"<br>
> >> >><br>
> >> >> And for each target there must be a file in configure/os:<br>
> >> >> e.g. CONFIG_Common.RTEMS-xilinx_zynq_a9_qemu<br>
> >> >> If it is not provided by EPICS, the RSB should install it there (adapted to the target to be used by epics make).<br>
> >> ><br>
> >><br>
> >> Probably they should be provided by EPICS for known-to-work<br>
> >> configurations. If they are not, we should push upstream.<br>
> >><br>
> >> ><br>
> >> > Yes, Heinz. I followed the above steps and created a patch which I applied in the configuration files of RSB recipe.<br>
> >> > The problem with it is that it's made only for pc-386 and I have to hardcode there about location of the RTEMS installation in<br>
> >> > configure/os/CONFIG_SITE.Common.RTEMS. My doubt is how to modify the patch that can it offer user-specific location of the RTEMS<br>
> >> > installation and bsp?<br>
> >> >><br>
> >><br>
> >> I still think this should be done through some kind of pre-processing<br>
> >> (scripting) over these configuration files for a given target, using<br>
> >> some fixed pattern, rather than by patching. A patch is fine for<br>
> >> proof-of-concept, but I don't think we want to have x patches for x<br>
> >> BSP targets of EPICS.  Maybe it is fine, there aren't that many BSP<br>
> >> targets right now, but I can see this kind of patch-based<br>
> >> configuration getting a little unwieldy.<br>
> >><br>
> >> If you proceed with the patch-based approach, you need to figure out<br>
> >> how to pick the right patch to apply based on the target/bsp build. So<br>
> >> that would be your next step. Create a patch for the zynq, and see if<br>
> >> you can dynamically determine which one to apply (zynq or pc386) based<br>
> >> on RSB internal state/variables.<br>
> >><br>
> >> Thank you for the suggestions. I will start working on creating the patch for zynq and will see if<br>
> >> something can be done to dynamically determine them.<br>
> >> >><br>
> >> >> ><br>
> >> >> > 2) "The startup directory in EPICS base contains a perl script, EpicsHostArch.pl, which can be used to define<br>
> >> >> > EPICS_HOST_ARCH. This script can be invoked with a command line parameter defining the alternate compiler (e.g.<br>
> >> >> > if invoking EpicsHostArch.pl yields solaris-sparc, then invoking EpicsHostArch.pl gnu will yield<br>
> >> >> > solaris-sparc-gnu).<br>
> >> >> > The startup directory also contains scripts to help users set the path and other environment variables"<br>
> >> >> This has nothing to do with 2)<br>
> >> ><br>
> >> ><br>
> >> > I am sorry for the misunderstanding. All the 4 points mentioned here are my observations only for the Problem No.1<br>
> >> > `1) How to make it work across different architectures?`<br>
> >> >><br>
> >> >><br>
> >> >> There's no need to adjust anything here. The EPICS make recognizes the architecture on which it is started.<br>
> >> >><br>
> >> >> > Remarks: As EPICS_HOST_ARCH, can we do something similar for CROSS_COMPILER_TARGET_ARCHS?<br>
> >> >> ><br>
> >> >> > 3) ") The following is a summary of targets that can be specified for gnumake:<br>
> >> >> > • <action><br>
> >> >> > • <arch><br>
> >> >> > • <action>.<arch><br>
> >> >> > • <dir><br>
> >> >> > • <dir>.<action><br>
> >> >> > • <dir>.<arch><br>
> >> >> > • <dir>.<action>.<arch><br>
> >> >> > where:<br>
> >> >> > <arch> is an architecture such as solaris-sparc, vxWorks-68040, win32-x86, etc.<br>
> >> >> > <action> is help, clean, realclean, distclean, inc, install, build, rebuild, buildInstall, realuninstall, or uninstall"<br>
> >> >> ><br>
> >> >> > Remarks: Now similar to the above stated, can we work for Cross Compiler target Architecture?<br>
> >> >> ><br>
> >> >><br>
> >> >> But this does not refer to 3) ?<br>
> >> ><br>
> >> ><br>
> >> > No no, this remark is also for the problem 1 only as told above. Slight misunderstanding here :)<br>
> >> >><br>
> >> >><br>
> >> >><br>
> >> >><br>
> >> >> 3) You have to take "my" repo at the moment, because the adaptations to RTEMS5 are not yet included in the official epics-base. This is a hen-and-egg problem because RTEMS is only now in the release phase, so my changes have not been implemented yet.<br>
> >> ><br>
> >> ><br>
> >> > Ok, I hope Dr. Gedare and Chris can help you with that.<br>
> >><br>
> >> We just need to be ready for when RTEMS 5.1 is officially released.<br>
> >> Hopefully soon, but I don't have a timeline. Releases are mostly<br>
> >> volunteer time, so they happen when they happen. We're trying to get<br>
> >> better about that, but it is hard (due to lack of incentives).<br>
> >><br>
> >> I think that makes it clear, Heinz.<br>
> >> >><br>
> >> >><br>
> >> >> 2) I'm just about to figure out in the Epics Makefiles whether the target was built with the legacy-stack or libbsd-stack. It's working already.<br>
> >> >> Now I also have to adjust the rtems_init.c accordingly. Here I have to clean up a little bit. But I hope to have this finished by the middle of the week.<br>
> >> ><br>
> >> ><br>
> >> > Thank you so much for the update!<br>
> >> ><br>
> >> > So I would like to ask my other mentors - what can I do for the time being? What should be the next steps for this week?<br>
> >><br>
> >> Prepare the zynq patch and try to work out the logic of how to select<br>
> >> the right patch to apply.<br>
> >><br>
> >> Then similar logic might be usable to script the configuration changes<br>
> >> of EPICS so we don't need patches.<br>
> >><br>
> >> Sure, I will do and update soon.<br>
> >><br>
> >> > And yes how to begin the testing part?<br>
> >><br>
> >> This was suggested by Heinz earlier to look at the CI test scripts<br>
> >> that EPICS maintainers use.<br>
> >><br>
> >> Yes, it slipped out of my mind. Will check and revert.<br>
> >><br>
> >> Thanks<br>
> >> Mritunjay Sharma<br>
> >><br>
> >> > I have tried to find some resources but I think it will be<br>
> >> > better if you can help somewhere to look at.<br>
> >> ><br>
> >> > Thanks<br>
> >> > Mritunjay Sharma<br>
> >> >><br>
> >> >><br>
> >> >> > These were the little doubts that originated from the research work I did.<br>
> >> >> > I will like the opinion of mentors that what can be the optimal way now to approach the<br>
> >> >> > project after this? What can be some resources for better research work of the<br>
> >> >> > above problems?<br>
> >> >> ><br>
> >> >> > Also, for the reference:<br>
> >> >> > Link to the changes in commits of rsb can be found here: <a href="https://github.com/RTEMS/rtems-source-builder/compare/master...mritunjaysharma394:epics-support" rel="noreferrer" target="_blank">https://github.com/RTEMS/rtems-source-builder/compare/master...mritunjaysharma394:epics-support</a><br>
> >> >> ><br>
> >> >> > The patch for epics can be found here: <a href="https://github.com/mritunjaysharma394/epics-mritunjay/tree/master/patches" rel="noreferrer" target="_blank">https://github.com/mritunjaysharma394/epics-mritunjay/tree/master/patches</a><br>
> >> >> ><br>
> >> >> ><br>
> >> >> > Thanks<br>
> >> >> > Mritunjay Sharma<br>
> >> >> ><br>
> >> >> ><br>
> >> >> ><br>
> >> >> ><br>
> >> >> Heinz<br>
> ><br>
> ><br>
> > <rsb-report-epics-base-7.0-x86_64-linux-gnu-1.txt><log_epics><br>
><br>
</blockquote></div>