Re: [GSoC 2020] : BSP Buildset for EPICS (next steps)

2020-08-08 Thread Heinz Junkes
Hallo Mritunjay,
everything looks pretty good. I'm commenting on the text. I also send this mail
to two EPICS experts (Andrew Johnson and Michael Davidsaver). Maybe they also 
have some ideas.


> 
> Current Status: 
> 
> 1) Successfully built EPICS7 with RTEMS5 by hand for pc-386
> 2) Worked for RSB recipe. 
>In its due process, I Wrote:  
> i) rsb/rtems/config/epics/epics-7-1.cfg 
> ii)rsb/rtems/config/epics/epics-base.bset 
> iii)rsb/source-builder/config/epics-7-1.cfg
> 3) Added Patch for RTEMS-pc-386 support which made the above recipe work 
> successfully. 
> 4) Therefore, Successully built EPICS7 with RTEMS5 by using RSB recipe as 
> well for pc-386 as of now. 
> 5) Sent 4 Patches for review of the same. 
> 
> What problems are in the next steps?
> 
> 1) How to make it work across different architectures?
> 2) Exisiting EPICS works on the old legacy network stack.
> 3) I am not using EPICS upstream branch. It is being built
> by Heinz's epics playground. 
> 4) Doubts in how to start with testing. 
> 
> My Resarch work for the Problem no: 1
> 
> I have gone through the EPICS developer guide from here
> exhaustively in the past couple of day and here are few interesting things
> that I found which can help: 
> 
> 1) "The main ingredients of the build system are:
> • A set of configuration files and tools provided in the EPICS base/configure 
> directory
> • A corresponding set of configuration files in the /configure directory 
> of a non-base  directory
> structure to be built. The makeBaseApp.pl and makeBaseExt.pl scripts create 
> these configuration files. Many of
> these files just include a file of the same name from the base/configure 
> directory.
> • Makefiles in each directory of the  directory structure to be built
> • User created configuration files in build created $(INSTALL_LOCATION)/cfg 
> directories.
> "
> 
> Remarks: Now since it is also mentioned in the guide that "makeBaseApp.pl 
> creates directories and then copies template files into the newly created 
> directories 
> while expanding macros in the template files. EPICS base provides two sets of 
> template files: simple and example."
> Can we think of using makeBaseApp.pl to that end? Making the user allow 
> to change the configurations from the terminal? 

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.

You "only" need to specify the location of the RTEMS installation in 
configure/os/CONFIG_SITE.Common.RTEMS.
RTEMS_VERSION =
RTEMS_BASE =

Then you have to define the target in configure/CONFIG_SITE:
...
# Which target architectures to cross-compile for.
#  Definitions in configure/os/CONFIG_SITE..Common
#  may override this setting.
CROSS_COMPILER_TARGET_ARCHS=
…
e.g. “CROSS_COMPILER_TARGET_ARCHS=RTEMS-xilinx_zynq_a9_qemu"

And for each target there must be a file in configure/os:
e.g. CONFIG_Common.RTEMS-xilinx_zynq_a9_qemu
If it is not provided by EPICS, the RSB should install it there (adapted to the 
target to be used by epics make).

> 
> 2) "The startup directory in EPICS base contains a perl script, 
> EpicsHostArch.pl, which can be used to define
> EPICS_HOST_ARCH. This script can be invoked with a command line parameter 
> defining the alternate compiler (e.g.
> if invoking EpicsHostArch.pl yields solaris-sparc, then invoking 
> EpicsHostArch.pl gnu will yield
> solaris-sparc-gnu).
> The startup directory also contains scripts to help users set the path and 
> other environment variables”
This has nothing to do with 2)

There's no need to adjust anything here. The EPICS make recognizes the 
architecture on which it is started.

> Remarks: As EPICS_HOST_ARCH, can we do something similar for 
> CROSS_COMPILER_TARGET_ARCHS?
> 
> 3) ") The following is a summary of targets that can be specified for gnumake:
> • 
> • 
> • .
> • 
> • .
> • .
> • ..
> where:
>  is an architecture such as solaris-sparc, vxWorks-68040, win32-x86, 
> etc.
>  is help, clean, realclean, distclean, inc, install, build, rebuild, 
> buildInstall, realuninstall, or uninstall"
> 
> Remarks: Now similar to the above stated, can we work for Cross Compiler 
> target Architecture? 
> 

But this does not refer to 3) ?

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. 

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

> These were the little doubts that originated from the research work I did. 
> I will like the opinion of mentors that what can be the optimal way now to 
> appro

Re: [GSoC 2020] : BSP Buildset for EPICS (next steps)

2020-08-08 Thread Mritunjay Sharma
On Sat, Aug 8, 2020 at 9:46 PM Heinz Junkes 
wrote:

> Hallo Mritunjay,
> everything looks pretty good. I'm commenting on the text. I also send this
> mail
> to two EPICS experts (Andrew Johnson and Michael Davidsaver). Maybe they
> also have some ideas.
>

Thank you so much Heinz! It will be really a great help!

>
>
> >
> > Current Status:
> >
> > 1) Successfully built EPICS7 with RTEMS5 by hand for pc-386
> > 2) Worked for RSB recipe.
> >In its due process, I Wrote:
> > i) rsb/rtems/config/epics/epics-7-1.cfg
> > ii)rsb/rtems/config/epics/epics-base.bset
> > iii)rsb/source-builder/config/epics-7-1.cfg
> > 3) Added Patch for RTEMS-pc-386 support which made the above recipe work
> successfully.
> > 4) Therefore, Successully built EPICS7 with RTEMS5 by using RSB recipe
> as well for pc-386 as of now.
> > 5) Sent 4 Patches for review of the same.
> >
> > What problems are in the next steps?
> >
> > 1) How to make it work across different architectures?
> > 2) Exisiting EPICS works on the old legacy network stack.
> > 3) I am not using EPICS upstream branch. It is being built
> > by Heinz's epics playground.
> > 4) Doubts in how to start with testing.
> >
> > My Resarch work for the Problem no: 1
> >
> > I have gone through the EPICS developer guide from here
> > exhaustively in the past couple of day and here are few interesting
> things
> > that I found which can help:
> >
> > 1) "The main ingredients of the build system are:
> > • A set of configuration files and tools provided in the EPICS
> base/configure directory
> > • A corresponding set of configuration files in the /configure
> directory of a non-base  directory
> > structure to be built. The makeBaseApp.pl and makeBaseExt.pl scripts
> create these configuration files. Many of
> > these files just include a file of the same name from the base/configure
> directory.
> > • Makefiles in each directory of the  directory structure to be
> built
> > • User created configuration files in build created
> $(INSTALL_LOCATION)/cfg directories.
> > "
> >
> > Remarks: Now since it is also mentioned in the guide that
> "makeBaseApp.pl
> > creates directories and then copies template files into the newly
> created directories
> > while expanding macros in the template files. EPICS base provides two
> sets of template files: simple and example."
> > Can we think of using makeBaseApp.pl to that end? Making the user allow
> > to change the configurations from the terminal?
>
> 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.
>
> You "only" need to specify the location of the RTEMS installation in
> configure/os/CONFIG_SITE.Common.RTEMS.
> RTEMS_VERSION =
> RTEMS_BASE =
>
> Then you have to define the target in configure/CONFIG_SITE:
> ...
> # Which target architectures to cross-compile for.
> #  Definitions in configure/os/CONFIG_SITE..Common
> #  may override this setting.
> CROSS_COMPILER_TARGET_ARCHS=
> …
> e.g. “CROSS_COMPILER_TARGET_ARCHS=RTEMS-xilinx_zynq_a9_qemu"
>
> And for each target there must be a file in configure/os:
> e.g. CONFIG_Common.RTEMS-xilinx_zynq_a9_qemu
> If it is not provided by EPICS, the RSB should install it there (adapted
> to the target to be used by epics make).
>

Yes, Heinz. I followed the above steps and created a patch which I applied
in the configuration files of RSB recipe.
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
configure/os/CONFIG_SITE.Common.RTEMS. My doubt is how to modify the patch
that can it offer user-specific location of the RTEMS
installation and bsp?

>
> >
> > 2) "The startup directory in EPICS base contains a perl script,
> EpicsHostArch.pl, which can be used to define
> > EPICS_HOST_ARCH. This script can be invoked with a command line
> parameter defining the alternate compiler (e.g.
> > if invoking EpicsHostArch.pl yields solaris-sparc, then invoking
> EpicsHostArch.pl gnu will yield
> > solaris-sparc-gnu).
> > The startup directory also contains scripts to help users set the path
> and other environment variables”
> This has nothing to do with 2)
>

I am sorry for the misunderstanding. All the 4 points mentioned here are my
observations only for the Problem No.1
`1) How to make it work across different architectures?`

>
> There's no need to adjust anything here. The EPICS make recognizes the
> architecture on which it is started.
>
> > Remarks: As EPICS_HOST_ARCH, can we do something similar for
> CROSS_COMPILER_TARGET_ARCHS?
> >
> > 3) ") The following is a summary of targets that can be specified for
> gnumake:
> > • 
> > • 
> > • .
> > • 
> > • .
> > • .
> > • ..
> > where:
> >  is an architecture such as solaris-sparc, vxWorks-68040,
> win32-x86, etc.
> >  is help, clean, realclean, distclean, inc, install, build,
> rebuild, buildInstall, realuninstall, or uninstall"
> >
> > Remarks: Now similar 

Re: [GSoC 2020] : BSP Buildset for EPICS (next steps)

2020-08-08 Thread Gedare Bloom
On Sat, Aug 8, 2020 at 11:08 AM Mritunjay Sharma
 wrote:
>
>
>
> On Sat, Aug 8, 2020 at 9:46 PM Heinz Junkes  wrote:
>>
>> Hallo Mritunjay,
>> everything looks pretty good. I'm commenting on the text. I also send this 
>> mail
>> to two EPICS experts (Andrew Johnson and Michael Davidsaver). Maybe they 
>> also have some ideas.
>
>
> Thank you so much Heinz! It will be really a great help!
>>
>>
>>
>> >
>> > Current Status:
>> >
>> > 1) Successfully built EPICS7 with RTEMS5 by hand for pc-386
>> > 2) Worked for RSB recipe.
>> >In its due process, I Wrote:
>> > i) rsb/rtems/config/epics/epics-7-1.cfg
>> > ii)rsb/rtems/config/epics/epics-base.bset
>> > iii)rsb/source-builder/config/epics-7-1.cfg
>> > 3) Added Patch for RTEMS-pc-386 support which made the above recipe work 
>> > successfully.
>> > 4) Therefore, Successully built EPICS7 with RTEMS5 by using RSB recipe as 
>> > well for pc-386 as of now.
>> > 5) Sent 4 Patches for review of the same.
>> >
>> > What problems are in the next steps?
>> >
>> > 1) How to make it work across different architectures?
>> > 2) Exisiting EPICS works on the old legacy network stack.
>> > 3) I am not using EPICS upstream branch. It is being built
>> > by Heinz's epics playground.
>> > 4) Doubts in how to start with testing.
>> >
>> > My Resarch work for the Problem no: 1
>> >
>> > I have gone through the EPICS developer guide from here
>> > exhaustively in the past couple of day and here are few interesting things
>> > that I found which can help:
>> >
>> > 1) "The main ingredients of the build system are:
>> > • A set of configuration files and tools provided in the EPICS 
>> > base/configure directory
>> > • A corresponding set of configuration files in the /configure 
>> > directory of a non-base  directory
>> > structure to be built. The makeBaseApp.pl and makeBaseExt.pl scripts 
>> > create these configuration files. Many of
>> > these files just include a file of the same name from the base/configure 
>> > directory.
>> > • Makefiles in each directory of the  directory structure to be built
>> > • User created configuration files in build created 
>> > $(INSTALL_LOCATION)/cfg directories.
>> > "
>> >
>> > Remarks: Now since it is also mentioned in the guide that "makeBaseApp.pl
>> > creates directories and then copies template files into the newly created 
>> > directories
>> > while expanding macros in the template files. EPICS base provides two sets 
>> > of template files: simple and example."
>> > Can we think of using makeBaseApp.pl to that end? Making the user allow
>> > to change the configurations from the terminal?
>>
>> 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.
>>
>> You "only" need to specify the location of the RTEMS installation in 
>> configure/os/CONFIG_SITE.Common.RTEMS.
>> RTEMS_VERSION =
>> RTEMS_BASE =
>>
>> Then you have to define the target in configure/CONFIG_SITE:
>> ...
>> # Which target architectures to cross-compile for.
>> #  Definitions in configure/os/CONFIG_SITE..Common
>> #  may override this setting.
>> CROSS_COMPILER_TARGET_ARCHS=
>> …
>> e.g. “CROSS_COMPILER_TARGET_ARCHS=RTEMS-xilinx_zynq_a9_qemu"
>>
>> And for each target there must be a file in configure/os:
>> e.g. CONFIG_Common.RTEMS-xilinx_zynq_a9_qemu
>> If it is not provided by EPICS, the RSB should install it there (adapted to 
>> the target to be used by epics make).
>

Probably they should be provided by EPICS for known-to-work
configurations. If they are not, we should push upstream.

>
> Yes, Heinz. I followed the above steps and created a patch which I applied in 
> the configuration files of RSB recipe.
> 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
> configure/os/CONFIG_SITE.Common.RTEMS. My doubt is how to modify the patch 
> that can it offer user-specific location of the RTEMS
> installation and bsp?
>>

I still think this should be done through some kind of pre-processing
(scripting) over these configuration files for a given target, using
some fixed pattern, rather than by patching. A patch is fine for
proof-of-concept, but I don't think we want to have x patches for x
BSP targets of EPICS.  Maybe it is fine, there aren't that many BSP
targets right now, but I can see this kind of patch-based
configuration getting a little unwieldy.

If you proceed with the patch-based approach, you need to figure out
how to pick the right patch to apply based on the target/bsp build. So
that would be your next step. Create a patch for the zynq, and see if
you can dynamically determine which one to apply (zynq or pc386) based
on RSB internal state/variables.

>>
>> >
>> > 2) "The startup directory in EPICS base contains a perl script, 
>> > EpicsHostArch.pl, which can be used to define
>> > EPICS_HOST_ARCH. This script can be invoked with a command line parame

Re: [GSoC 2020] : BSP Buildset for EPICS (next steps)

2020-08-08 Thread Mritunjay Sharma
On Sat, Aug 8, 2020 at 11:10 PM Gedare Bloom  wrote:

> On Sat, Aug 8, 2020 at 11:08 AM Mritunjay Sharma
>  wrote:
> >
> >
> >
> > On Sat, Aug 8, 2020 at 9:46 PM Heinz Junkes 
> wrote:
> >>
> >> Hallo Mritunjay,
> >> everything looks pretty good. I'm commenting on the text. I also send
> this mail
> >> to two EPICS experts (Andrew Johnson and Michael Davidsaver). Maybe
> they also have some ideas.
> >
> >
> > Thank you so much Heinz! It will be really a great help!
> >>
> >>
> >>
> >> >
> >> > Current Status:
> >> >
> >> > 1) Successfully built EPICS7 with RTEMS5 by hand for pc-386
> >> > 2) Worked for RSB recipe.
> >> >In its due process, I Wrote:
> >> > i) rsb/rtems/config/epics/epics-7-1.cfg
> >> > ii)rsb/rtems/config/epics/epics-base.bset
> >> > iii)rsb/source-builder/config/epics-7-1.cfg
> >> > 3) Added Patch for RTEMS-pc-386 support which made the above recipe
> work successfully.
> >> > 4) Therefore, Successully built EPICS7 with RTEMS5 by using RSB
> recipe as well for pc-386 as of now.
> >> > 5) Sent 4 Patches for review of the same.
> >> >
> >> > What problems are in the next steps?
> >> >
> >> > 1) How to make it work across different architectures?
> >> > 2) Exisiting EPICS works on the old legacy network stack.
> >> > 3) I am not using EPICS upstream branch. It is being built
> >> > by Heinz's epics playground.
> >> > 4) Doubts in how to start with testing.
> >> >
> >> > My Resarch work for the Problem no: 1
> >> >
> >> > I have gone through the EPICS developer guide from here
> >> > exhaustively in the past couple of day and here are few interesting
> things
> >> > that I found which can help:
> >> >
> >> > 1) "The main ingredients of the build system are:
> >> > • A set of configuration files and tools provided in the EPICS
> base/configure directory
> >> > • A corresponding set of configuration files in the /configure
> directory of a non-base  directory
> >> > structure to be built. The makeBaseApp.pl and makeBaseExt.pl scripts
> create these configuration files. Many of
> >> > these files just include a file of the same name from the
> base/configure directory.
> >> > • Makefiles in each directory of the  directory structure to be
> built
> >> > • User created configuration files in build created
> $(INSTALL_LOCATION)/cfg directories.
> >> > "
> >> >
> >> > Remarks: Now since it is also mentioned in the guide that
> "makeBaseApp.pl
> >> > creates directories and then copies template files into the newly
> created directories
> >> > while expanding macros in the template files. EPICS base provides two
> sets of template files: simple and example."
> >> > Can we think of using makeBaseApp.pl to that end? Making the user
> allow
> >> > to change the configurations from the terminal?
> >>
> >> 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.
> >>
> >> You "only" need to specify the location of the RTEMS installation in
> configure/os/CONFIG_SITE.Common.RTEMS.
> >> RTEMS_VERSION =
> >> RTEMS_BASE =
> >>
> >> Then you have to define the target in configure/CONFIG_SITE:
> >> ...
> >> # Which target architectures to cross-compile for.
> >> #  Definitions in configure/os/CONFIG_SITE..Common
> >> #  may override this setting.
> >> CROSS_COMPILER_TARGET_ARCHS=
> >> …
> >> e.g. “CROSS_COMPILER_TARGET_ARCHS=RTEMS-xilinx_zynq_a9_qemu"
> >>
> >> And for each target there must be a file in configure/os:
> >> e.g. CONFIG_Common.RTEMS-xilinx_zynq_a9_qemu
> >> If it is not provided by EPICS, the RSB should install it there
> (adapted to the target to be used by epics make).
> >
>
> Probably they should be provided by EPICS for known-to-work
> configurations. If they are not, we should push upstream.
>
> >
> > Yes, Heinz. I followed the above steps and created a patch which I
> applied in the configuration files of RSB recipe.
> > 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
> > configure/os/CONFIG_SITE.Common.RTEMS. My doubt is how to modify the
> patch that can it offer user-specific location of the RTEMS
> > installation and bsp?
> >>
>
> I still think this should be done through some kind of pre-processing
> (scripting) over these configuration files for a given target, using
> some fixed pattern, rather than by patching. A patch is fine for
> proof-of-concept, but I don't think we want to have x patches for x
> BSP targets of EPICS.  Maybe it is fine, there aren't that many BSP
> targets right now, but I can see this kind of patch-based
> configuration getting a little unwieldy.
>
> If you proceed with the patch-based approach, you need to figure out
> how to pick the right patch to apply based on the target/bsp build. So
> that would be your next step. Create a patch for the zynq, and see if
> you can dynamically determine which one to apply (zynq or pc386) based
> on RSB internal state/varia

Re: [GSoC 2020] : BSP Buildset for EPICS (next steps)

2020-08-10 Thread junkes
Hello Mritunjay, 


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. 

You can find the development here:  

https://gitlab.fhi.mpg.de/junkes/epics-base.git 


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. 

[h1@earth QtC-epics-base (7.0 *+)]$ ./startQemu softIoc 
Script name: ./startQemu 
qemu-system-aarch64: warning: nic cadence_gem.1 has no peer 
WARNING: OS Clock time was read before being set. 
Using 1990-01-02 00:00:00.00 UTC 

initConsole --- Info --- 
stdin: fileno: 0, ttyname: /dev/ttyS1 
stdout: fileno: 1, ttyname: /dev/ttyS1 
stderr: fileno: 2, ttyname: /dev/ttyS1 
tcsetattr failed: I/O error 
time set to : 04/14/14 07:30:06.55589 UTC 
Startup. 
epicsThreadSetPriority called by non epics thread 


* RTEMS Version: rtems-5.0.0-m2003 (ARM/ARMv4/xilinx_zynq_a9_qemu)
* 

* Initializing network (dhcp) * 
nexus0:  
zy7_slcr0:  on nexus0 
cgem0:  on nexus0 
miibus0:  on cgem0 
e1000phy0:  PHY 0 on miibus0 
e1000phy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX,
1000baseT-FDX, 1000baseT-FDX-master, auto 
e1000phy1:  PHY 23 on miibus0 
e1000phy1:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX,
1000baseT-FDX, 1000baseT-FDX-master, auto 
info: cgem0: Ethernet address: 52:54:00:12:34:56 
info: lo0: link state changed to UP 

 Wait for DHCP done ... 
dhcpcd: unknown option -- pv4only 
info: version 6.2.1 starting 
cgem0: cgem_mediachange: could not set ref clk0 to 2500. 
info: cgem0: link state changed to UP 
dhcpcd: unknown option -- pv4only 
debug: cgem0: executing `ioc boot' PREINIT 

* Primary Network interface : cgem0 * 
debug: cgem0: executing `ioc boot' CARRIER 

* Primary Network interface : cgem0 * 
info: DUID 00:01:00:01:1a:de:4a:fe:52:54:00:12:34:56 
info: cgem0: IAID 00:12:34:56 
info: cgem0: soliciting an IPv6 router 
debug: cgem0: delaying Router Solicitation for LL address 
debug: cgem0: using ClientID
00:46:48:49:20:74:65:73:74:20:63:6c:69:65:6e:74 
info: cgem0: soliciting a DHCP lease 
debug: cgem0: sending DISCOVER (xid 0x86686938), next in %0.1f seconds 
info: cgem0: carrier lost 
debug: cgem0: executing `ioc boot' NOCARRIER 

* Primary Network interface : cgem0 * 
info: cgem0: carrier acquired 
dhcpcd: unknown option -- pv4only 
debug: cgem0: executing `ioc boot' CARRIER 

* Primary Network interface : cgem0 * 
info: cgem0: IAID 00:12:34:56 
info: cgem0: soliciting an IPv6 router 
debug: cgem0: delaying Router Solicitation for LL address 
debug: cgem0: using ClientID
00:46:48:49:20:74:65:73:74:20:63:6c:69:65:6e:74 
info: cgem0: soliciting a DHCP lease 
debug: cgem0: sending DISCOVER (xid 0x441a0d89), next in %0.1f seconds 
debug: cgem0: wrong xid 0x86686938 (expecting 0x441a0d89) from 10.1.0.1 
debug: cgem0: sending DISCOVER (xid 0x441a0d89), next in %0.1f seconds 
info: cgem0: offered 10.1.0.104 from 10.1.0.1 
debug: cgem0: sending REQUEST (xid 0x441a0d89), next in %0.1f seconds 
debug: cgem0: acknowledged 10.1.0.104 from 10.1.0.1 
debug: cgem0: checking for 10.1.0.104 
debug: cgem0: sending ARP probe (1 of 3), next in %0.1f seconds 
debug: cgem0: sending ARP probe (2 of 3), next in %0.1f seconds 

 Wait for DHCP done ... 
debug: cgem0: sending ARP probe (3 of 3), next in %0.1f seconds 
info: cgem0: leased 10.1.0.104 for 6000 seconds 
debug: cgem0: renew in 3000 seconds, rebind in 5250 seconds 
debug: cgem0: adding IP address 10.1.0.104/24 
info: cgem0: adding host route to 10.1.0.104 via 127.0.0.1 
err: cgem0: ipv4_addroute: File exists 
info: cgem0: adding route to 10.1.0.0/24 
err: cgem0: ipv4_addroute: File exists 
info: cgem0: adding default route via 10.1.0.1 
debug: cgem0: writing lease `/var/db/dhcpcd-cgem0.lease' 
debug: cgem0: executing `ioc boot' BOUND 

* Primary Network interface : cgem0 * 
Interface TGP bounded 
rtems_bsdnet_bootp_server_name : 1001.1001@10.1.0.1:/Volumes/Epics 
rtems_bsdnet_bootp_boot_file_name :
/Volumes/Epics/myExample/bin/RTEMS-xilinx_zynq_a9_qemu/myExample.boot 
rtems_bsdnet_bootp_cmdline :
/Volumes/Epics/myExample/iocBoot/iocmyExample/st.cmd 
debug: cgem0: sending ARP announce (1 of 2), next in 2.0 seconds 
-- IFCONFIG - 
cgem0: flags=8843 metric 0 mtu
1500 
  options=80008 
  ether 52:54:00:12:34:56 
  inet6 fe80::5054:ff:fe12:3456%cgem0 prefixlen 64 scopeid 0x1 
  inet 10.1.0.104 netmask 0xff00 broadcast 10.1.0.255 
  nd6 options=21 
  media: Ethernet autoselect (100baseTX ) 
  status: active 
lo0: flags=8049 metric 0 mtu 16384 
  options=680003 
  inet 127.0.0.1 netmask 0xff00 
  inet6 ::1 prefixlen 128 
  inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 
  nd6 options=21 
  groups: lo 
-- NETSTAT -- 
Routing tables 

Internet: 
Destination 

Re: [GSoC 2020] : BSP Buildset for EPICS (next steps)

2020-08-12 Thread Heinz Junkes
I think you should not make a patch for these two changes but a 
simple replacement with e.g. sed.

like

sed -i ’s/^RTEMS_BASE/RTEMS_BASE = 
\/home\/mritunjay\/development\/rtems/\$\(RTEMS_VERSION\)-arm\/g’ 
configure/os/CONFIG_SITE.Common.RTEMS

oder so ;-)


Viele Grüße
Heinz Junkes
--
Experience directly varies with equipment ruined.



> On 12. Aug 2020, at 02:13, Mritunjay Sharma  
> wrote:
> 
> Hello Heinz and everyone!
> 
> Thank you so much for this update. I started to work first by building EPICS 
> by hand
> for "xilinx_zynq_a9_qemu". Till the time, you gave 
> https://gitlab.fhi.mpg.de/junkes/epics-base.git, 
> I had to struggle with lot of errors which cloning into this repo solved.  
> 
> So I started by building "xilinx_zynq_a9_qemu" BSP for RTEMS5 using my own 
> blog with only difference being 
> that  I used '--disable-networking' to use libbsd. 
> 
> After that, I used this blog https://rmeena840.github.io/Fourth-Post/ of a 
> GSoC 19 Student to build and install rtems-libbsd
> for  "xilinx_zynq_a9_qemu".
> 
> Everything worked perfectly fine till now. Now I entered the 'epics-base' 
> directory and made
> the changes in configure/os/CONFIG_SITE.Common.RTEMS as: 
> 
> # FHI:
> RTEMS_SERIES = 5
> RTEMS_VERSION = 5
> RTEMS_BASE = /home/mritunjay/development/rtems/$(RTEMS_VERSION)-arm
> 
> Also made the change in configure/CONFIG_SITE:
> 
> CROSS_COMPILER_TARGET_ARCHS=RTEMS-xilinx_zynq_a9_qemu
> 
> After this I used 'make' command and it worked fine. 
> 
> So, I can say that there were just two changes which I had to make then the 
> previous one. 
> 
> The successful build by hand enabled me to work on the RSB recipe. 
> 
> I worked on them and it can be found here 
> https://github.com/RTEMS/rtems-source-builder/compare/master...mritunjaysharma394:epics-support-zynq.
> 
> The patch I am applying can be found here: 
> https://raw.githubusercontent.com/mritunjaysharma394/epics-mritunjay/master/patches/0001-Added-support-for-RTEMS-xilinx_zynq_a9_qemu.patch
> 
> However, the problem I am facing is that while building the recipe using:
> ```.../source-builder/sb-builder --log=log_epics epics-7-1```, 
> 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
> but this time the patch is not getting applied. 
> 
> It will be really helpful if you can guide where did I went wrong thist time. 
> 
> I am attaching the log and report file for reference. 
> 
> Thanks
> Mritunjay
> 
> 
> 
> 
> On Mon, Aug 10, 2020 at 8:56 PM junkes  wrote:
> Hello Mritunjay,
> 
> 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.
> 
> You can find the development here: 
> 
> https://gitlab.fhi.mpg.de/junkes/epics-base.git
> 
> 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.
> 
> [h1@earth QtC-epics-base (7.0 *+)]$ ./startQemu softIoc 
> Script name: ./startQemu 
> qemu-system-aarch64: warning: nic cadence_gem.1 has no peer 
> WARNING: OS Clock time was read before being set. 
> Using 1990-01-02 00:00:00.00 UTC 
> 
> initConsole --- Info --- 
> stdin: fileno: 0, ttyname: /dev/ttyS1 
> stdout: fileno: 1, ttyname: /dev/ttyS1 
> stderr: fileno: 2, ttyname: /dev/ttyS1 
> tcsetattr failed: I/O error 
> time set to : 04/14/14 07:30:06.55589 UTC 
> Startup. 
> epicsThreadSetPriority called by non epics thread 
> 
> * RTEMS Version: rtems-5.0.0-m2003 (ARM/ARMv4/xilinx_zynq_a9_qemu) * 
> 
> * Initializing network (dhcp) * 
> nexus0:  
> zy7_slcr0:  on nexus0 
> cgem0:  on nexus0 
> miibus0:  on cgem0 
> e1000phy0:  PHY 0 on miibus0 
> e1000phy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 
> 1000baseT-FDX, 1000baseT-FDX-master, auto 
> e1000phy1:  PHY 23 on miibus0 
> e1000phy1:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 
> 1000baseT-FDX, 1000baseT-FDX-master, auto 
> info: cgem0: Ethernet address: 52:54:00:12:34:56 
> info: lo0: link state changed to UP 
> 
>  Wait for DHCP done ... 
> dhcpcd: unknown option -- pv4only 
> info: version 6.2.1 starting 
> cgem0: cgem_mediachange: could not set ref clk0 to 2500. 
> info: cgem0: link state changed to UP 
> dhcpcd: unknown option -- pv4only 
> debug: cgem0: executing `ioc boot' PREINIT 
> 
> * Primary Network interface : cgem0 * 
> debug: cgem0: executing `ioc boot' CARRIER 
> 
> * Primary Network interface : cgem0 * 
> info: DUID 00:01:00:01:1a:de:4a:fe:52:54:00:12:34:56 
> info: cgem0: IAID 00:12:34:56 
> info: cgem0: soliciting an IPv6 router 
> debug: cgem0: delaying Router Solicitation for LL address 
> debug: cgem0: using ClientID 00:46:48:49:20:74:65:73:74:20:63:6c:69:65:6e:74 
> info: cgem0: soliciting a DHCP lease 
> debug: cgem0: sending DISCOVER (xid 0x86686938), next in %0.1f seconds 
> info: cgem0: carr

Re: [GSoC 2020] : BSP Buildset for EPICS (next steps)

2020-08-12 Thread Gedare Bloom
On Wed, Aug 12, 2020 at 1:58 AM Heinz Junkes  wrote:
>
> I think you should not make a patch for these two changes but a
> simple replacement with e.g. sed.
>
> like
>
> sed -i ’s/^RTEMS_BASE/RTEMS_BASE = 
> \/home\/mritunjay\/development\/rtems/\$\(RTEMS_VERSION\)-arm\/g’ 
> configure/os/CONFIG_SITE.Common.RTEMS
>
> oder so ;-)
>

Yes, great, that was something I think I mentioned before--the patches
are fine to get things hacked, but we should script the configuration
if we can from RSB. A cross-platform python-based approach must be
used.

>
> Viele Grüße
> Heinz Junkes
> --
> Experience directly varies with equipment ruined.
>
>
>
> > On 12. Aug 2020, at 02:13, Mritunjay Sharma  
> > wrote:
> >
> > Hello Heinz and everyone!
> >
> > Thank you so much for this update. I started to work first by building 
> > EPICS by hand
> > for "xilinx_zynq_a9_qemu". Till the time, you gave 
> > https://gitlab.fhi.mpg.de/junkes/epics-base.git,
> > I had to struggle with lot of errors which cloning into this repo solved.
> >
> > So I started by building "xilinx_zynq_a9_qemu" BSP for RTEMS5 using my own 
> > blog with only difference being
> > that  I used '--disable-networking' to use libbsd.
> >
> > After that, I used this blog https://rmeena840.github.io/Fourth-Post/ of a 
> > GSoC 19 Student to build and install rtems-libbsd
> > for  "xilinx_zynq_a9_qemu".
> >
> > Everything worked perfectly fine till now. Now I entered the 'epics-base' 
> > directory and made
> > the changes in configure/os/CONFIG_SITE.Common.RTEMS as:
> >
> > # FHI:
> > RTEMS_SERIES = 5
> > RTEMS_VERSION = 5
> > RTEMS_BASE = /home/mritunjay/development/rtems/$(RTEMS_VERSION)-arm
> >
> > Also made the change in configure/CONFIG_SITE:
> >
> > CROSS_COMPILER_TARGET_ARCHS=RTEMS-xilinx_zynq_a9_qemu
> >
> > After this I used 'make' command and it worked fine.
> >
> > So, I can say that there were just two changes which I had to make then the 
> > previous one.
> >
> > The successful build by hand enabled me to work on the RSB recipe.
> >
> > I worked on them and it can be found here 
> > https://github.com/RTEMS/rtems-source-builder/compare/master...mritunjaysharma394:epics-support-zynq.
> >
> > The patch I am applying can be found here: 
> > https://raw.githubusercontent.com/mritunjaysharma394/epics-mritunjay/master/patches/0001-Added-support-for-RTEMS-xilinx_zynq_a9_qemu.patch
> >
> > However, the problem I am facing is that while building the recipe using:
> > ```.../source-builder/sb-builder --log=log_epics epics-7-1```,
> > 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
> > but this time the patch is not getting applied.
> >
> > It will be really helpful if you can guide where did I went wrong thist 
> > time.
> >
> > I am attaching the log and report file for reference.
> >
> > Thanks
> > Mritunjay
> >
> >
> >
> >
> > On Mon, Aug 10, 2020 at 8:56 PM junkes  wrote:
> > Hello Mritunjay,
> >
> > 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.
> >
> > You can find the development here:
> >
> > https://gitlab.fhi.mpg.de/junkes/epics-base.git
> >
> > 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.
> >
> > [h1@earth QtC-epics-base (7.0 *+)]$ ./startQemu softIoc
> > Script name: ./startQemu
> > qemu-system-aarch64: warning: nic cadence_gem.1 has no peer
> > WARNING: OS Clock time was read before being set.
> > Using 1990-01-02 00:00:00.00 UTC
> >
> > initConsole --- Info ---
> > stdin: fileno: 0, ttyname: /dev/ttyS1
> > stdout: fileno: 1, ttyname: /dev/ttyS1
> > stderr: fileno: 2, ttyname: /dev/ttyS1
> > tcsetattr failed: I/O error
> > time set to : 04/14/14 07:30:06.55589 UTC
> > Startup.
> > epicsThreadSetPriority called by non epics thread
> >
> > * RTEMS Version: rtems-5.0.0-m2003 (ARM/ARMv4/xilinx_zynq_a9_qemu) *
> >
> > * Initializing network (dhcp) *
> > nexus0: 
> > zy7_slcr0:  on nexus0
> > cgem0:  on nexus0
> > miibus0:  on cgem0
> > e1000phy0:  PHY 0 on miibus0
> > e1000phy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 
> > 1000baseT-FDX, 1000baseT-FDX-master, auto
> > e1000phy1:  PHY 23 on miibus0
> > e1000phy1:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 
> > 1000baseT-FDX, 1000baseT-FDX-master, auto
> > info: cgem0: Ethernet address: 52:54:00:12:34:56
> > info: lo0: link state changed to UP
> >
> >  Wait for DHCP done ...
> > dhcpcd: unknown option -- pv4only
> > info: version 6.2.1 starting
> > cgem0: cgem_mediachange: could not set ref clk0 to 2500.
> > info: cgem0: link state changed to UP
> > dhcpcd: unknown option -- pv4only
> > debug: cgem0: executing `ioc boot' PREINIT
> >
> > * Primary Network interface : cgem0 *
> > debug: cgem0: executing `ioc boot' CARR

Re: [GSoC 2020] : BSP Buildset for EPICS (next steps)

2020-08-12 Thread Mritunjay Sharma
Thank you so much Heinz and Gedare for the suggestion of using sed instead
of patches.

The good news is that I worked with them and EPICS 7 was built successfully
for "xilinx_zynq_a9_qemu" using RSB recipe.

The changes I made were  as follows:

```diff --git a/source-builder/config/epics-7-1.cfg
b/source-builder/config/epics-7-1.cfg

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:  https://epics.mpg.de/
   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)
 ```

The changes can be observed from here as well:
https://github.com/RTEMS/rtems-source-builder/commit/1e7d7d4237a479dce564711b1080a9b3225e9e9a

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.
However, the build is running successfully.

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,
I have to specify my directory in the scripts, the only difference is that
I am using sed instead of patch.

Thank you again, Heinz and Gedare for introducing me to sed and making me
revise some regex as well!

Thanks
Mritunjay Sharma


On Wed, Aug 12, 2020 at 7:07 PM Gedare Bloom  wrote:

> On Wed, Aug 12, 2020 at 1:58 AM Heinz Junkes 
> wrote:
> >
> > I think you should not make a patch for these two changes but a
> > simple replacement with e.g. sed.
> >
> > like
> >
> > sed -i ’s/^RTEMS_BASE/RTEMS_BASE =
> \/home\/mritunjay\/development\/rtems/\$\(RTEMS_VERSION\)-arm\/g’
> configure/os/CONFIG_SITE.Common.RTEMS
> >
> > oder so ;-)
> >
>
> Yes, great, that was something I think I mentioned before--the patches
> are fine to get things hacked, but we should script the configuration
> if we can from RSB. A cross-platform python-based approach must be
> used.
>
> >
> > Viele Grüße
> > Heinz Junkes
> > --
> > Experience directly varies with equipment ruined.
> >
> >
> >
> > > On 12. Aug 2020, at 02:13, Mritunjay Sharma <
> mritunjaysharma...@gmail.com> wrote:
> > >
> > > Hello Heinz and everyone!
> > >
> > > Thank you so much for this update. I started to work first by building
> EPICS by hand
> > > for "xilinx_zynq_a9_qemu". Till the time, you gave
> https://gitlab.fhi.mpg.de/junkes/epics-base.git,
> > > I had to struggle with lot of errors which cloning into this repo
> solved.
> > >
> > > So I started by building "xilinx_zynq_a9_qemu" BSP for RTEMS5 using my
> own blog with only difference being
> > > that  I used '--disable-networking' to use libbsd.
> > >
> > > After that, I used this blog https://rmeena840.github.io/Fourth-Post/
> of a GSoC 19 Student to build and install rtems-libbsd
> > > for  "xilinx_zynq_a9_qemu".
> > >
> > > Everything worked perfectly fine till now. Now I entered the
> 'epics-base' directory and made
> > > the changes in configure/os/CONFIG_SITE.Common.RTEMS as:
> > >
> > > # FHI:
> > > RTEMS_SERIES = 5
> > > RTEMS_VERSION = 5
> > > RTEMS_BASE = /home/mritunjay/development/rtems/$(RTEMS_VERSION)-arm
> > >
> > > Also made the change in configure/CONFIG_SITE:
> > >
> > > CROSS_COMPILER_TARGET_ARCHS=RTEMS-xilinx_zynq_a9_qemu
> > >
> > > After this I used 'make' command and it worked fine.
> > >
> > > So, I can say that there were just two changes which I had to make
> then the previous one.
> > >
> > > The successful build by hand enabled me to work on the RSB recipe.
> > >
> > > I worked on them and it can be found here
> https://github.com/RTEMS/rtems-source-builder/compare/master...mritunjaysharma394:epics-support-zynq
> .
> > >
> > > The patch I am applying can be found here:
> https://raw.githubusercontent.com/mritunjaysharma394/epics-mritunjay/master/patches/0001-Added-support-for-RTEMS-xilinx_zynq_a9_qemu.patch
> > >
> > > However, the problem I am facing is that while building the recipe
> using:
> > > ```.../source-builder/sb-builder --log=log_epics epics-7-1```,
> > > 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
> > > but this time the patch is not getting applied.
> > >
> > > It will be really helpful if you can guide where did I went wrong
> thist time.
> > >
> > > I am attaching the log and report file for reference.
> > >
> > > Thanks
> > > Mritunjay
> > >
> > >
> > >
> > >
> > > On Mon, Aug 10, 2020 at 8:56 PM junkes 
> wrote:
> > 

Re: [GSoC 2020] : BSP Buildset for EPICS (next steps)

2020-08-12 Thread Gedare Bloom
On Wed, Aug 12, 2020 at 9:20 AM Mritunjay Sharma
 wrote:
>
> Thank you so much Heinz and Gedare for the suggestion of using sed instead of 
> patches.
>
> The good news is that I worked with them and EPICS 7 was built successfully
> for "xilinx_zynq_a9_qemu" using RSB recipe.
>
> The changes I made were  as follows:
>
> ```diff --git a/source-builder/config/epics-7-1.cfg 
> b/source-builder/config/epics-7-1.cfg
>
> 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:  https://epics.mpg.de/
>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)
>  ```
>
> The changes can be observed from here as well: 
> https://github.com/RTEMS/rtems-source-builder/commit/1e7d7d4237a479dce564711b1080a9b3225e9e9a
>
> 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.
> However, the build is running successfully.
>
> 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,
> I have to specify my directory in the scripts, the only difference is that I 
> am using sed instead of patch.
>

sed is not cross-platform. you need to find something in Python you can use.

> Thank you again, Heinz and Gedare for introducing me to sed and making me 
> revise some regex as well!
>
> Thanks
> Mritunjay Sharma
>
>
> On Wed, Aug 12, 2020 at 7:07 PM Gedare Bloom  wrote:
>>
>> On Wed, Aug 12, 2020 at 1:58 AM Heinz Junkes  
>> wrote:
>> >
>> > I think you should not make a patch for these two changes but a
>> > simple replacement with e.g. sed.
>> >
>> > like
>> >
>> > sed -i ’s/^RTEMS_BASE/RTEMS_BASE = 
>> > \/home\/mritunjay\/development\/rtems/\$\(RTEMS_VERSION\)-arm\/g’ 
>> > configure/os/CONFIG_SITE.Common.RTEMS
>> >
>> > oder so ;-)
>> >
>>
>> Yes, great, that was something I think I mentioned before--the patches
>> are fine to get things hacked, but we should script the configuration
>> if we can from RSB. A cross-platform python-based approach must be
>> used.
>>
>> >
>> > Viele Grüße
>> > Heinz Junkes
>> > --
>> > Experience directly varies with equipment ruined.
>> >
>> >
>> >
>> > > On 12. Aug 2020, at 02:13, Mritunjay Sharma 
>> > >  wrote:
>> > >
>> > > Hello Heinz and everyone!
>> > >
>> > > Thank you so much for this update. I started to work first by building 
>> > > EPICS by hand
>> > > for "xilinx_zynq_a9_qemu". Till the time, you gave 
>> > > https://gitlab.fhi.mpg.de/junkes/epics-base.git,
>> > > I had to struggle with lot of errors which cloning into this repo solved.
>> > >
>> > > So I started by building "xilinx_zynq_a9_qemu" BSP for RTEMS5 using my 
>> > > own blog with only difference being
>> > > that  I used '--disable-networking' to use libbsd.
>> > >
>> > > After that, I used this blog https://rmeena840.github.io/Fourth-Post/ of 
>> > > a GSoC 19 Student to build and install rtems-libbsd
>> > > for  "xilinx_zynq_a9_qemu".
>> > >
>> > > Everything worked perfectly fine till now. Now I entered the 
>> > > 'epics-base' directory and made
>> > > the changes in configure/os/CONFIG_SITE.Common.RTEMS as:
>> > >
>> > > # FHI:
>> > > RTEMS_SERIES = 5
>> > > RTEMS_VERSION = 5
>> > > RTEMS_BASE = /home/mritunjay/development/rtems/$(RTEMS_VERSION)-arm
>> > >
>> > > Also made the change in configure/CONFIG_SITE:
>> > >
>> > > CROSS_COMPILER_TARGET_ARCHS=RTEMS-xilinx_zynq_a9_qemu
>> > >
>> > > After this I used 'make' command and it worked fine.
>> > >
>> > > So, I can say that there were just two changes which I had to make then 
>> > > the previous one.
>> > >
>> > > The successful build by hand enabled me to work on the RSB recipe.
>> > >
>> > > I worked on them and it can be found here 
>> > > https://github.com/RTEMS/rtems-source-builder/compare/master...mritunjaysharma394:epics-support-zynq.
>> > >
>> > > The patch I am applying can be found here: 
>> > > https://raw.githubusercontent.com/mritunjaysharma394/epics-mritunjay/master/patches/0001-Added-support-for-RTEMS-xilinx_zynq_a9_qemu.patch
>> > >
>> > > However, the problem I am facing is that while building the recipe using:
>> > > ```.../source-builder/sb-builder --log=log_epics epics-7-1```,
>> > > the build is failing because it seems that Patch setup in configure file 
>> > > is not getting applied there. I followed the same step