[subexp-daq] Possible problem in Makefile of NURDLIB

[Håkan T Johansson]

On Mon, 15 Apr 2024, Weber, Guenter Dr. wrote:

> 
> Dear Håkan,
> 
> 
> does this also mean that I can just do the following
> 
> 
> make fw_1409285e_trlo_build      # choose the vulom4b trlo
> 
> 
> even if I have a VULOM4 instead of VULOM4B in my setup?
> 
> 
> My understanding was that I should use
> 
> 
> make fw_6e4ba1a9_trlo_build    # choose the vulom4 trlo
> 
> instead.

Yes.  find_firmwares.pl  set most directories up as symlinks to each other 
when they have the same register layout.

Cheers,
Håkan



> 
> 
> 
> 
> Thank you very much!
> 
> 
> 
> 
> 
> Best greetings
> 
> Günter
> 
> 
> ____________________________________________________________________________
> Von: subexp-daq <subexp-daq-bounces at lists.chalmers.se> im Auftrag von Håkan
> T Johansson <f96hajo at chalmers.se>
> Gesendet: Montag, 15. April 2024 12:59:46
> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.
> Betreff: Re: [subexp-daq] Possible problem in Makefile of NURDLIB  
> 
> On Mon, 15 Apr 2024, Weber, Guenter Dr. wrote:
> 
> >
> > Dear Håkan,
> >
> >
> > thank you very much for the explanations and the modifications.
> >
> >
> > I see that you updated the automatic determination of the VULOM4_FW
> variable
> > in the NURDLIB Makefile. Just for clarification: it will always come up
> with
> > the VULOM4B version, even though there might be a VULOM4 module in the
> > setup, as the firmware for both modules is identical for the purpose of
> this
> > compilation, right?
> 
> Yes, that is the idea.
> 
> If the trloii/trloctrl/ contain several incompatible versions, it will
> just pick the first, which might not work.  But in that case, at least the
> setup routines will complain about alias not in list, and then one has
> to clean up.  I think we can live with that.
> 
> The rest below is for Hans :-)
> 
> Cheers,
> Håkan
> 
> > Moreover, to make things more comfortable for the user, I added the
> > following code to the Makefile:
> >
> >
> > ifeq (,$(TRLOII_PATH))
> > TRLOII_PATH_TEST:=$(shell pwd)/../trloii
> > ifeq ("$(wildcard $(TRLOII_PATH_TEST))", "")
> > TRLOII_ERROR:=WARNING: Makefile guessed $(TRLOII_PATH_TEST), but folder
> does
> > not exist!
> > $(call infovar,TRLOII_ERROR)
> > else
> > TRLOII_PATH:=$(TRLOII_PATH_TEST)
> > endif
> > endif
> >
> > This assumes that it is unlikey that you want to compile NURDLIB without
> > TRLOII being present. But maybe, if it is desired to decide if NURDLIB
> > should compile with or without TRLOII it is better to have this as an
> > explict option for "make" instead of doing it implicitly by having the
> > TRLOII_PATH variable being set by hand or not.
> >
> >
> >
> >
> >
> >
> > Best greetings
> >
> > Günter
> >
> >
> >
> >___________________________________________________________________________
> _
> > Von: subexp-daq <subexp-daq-bounces at lists.chalmers.se> im Auftrag von
> Håkan
> > T Johansson <f96hajo at chalmers.se>
> > Gesendet: Samstag, 13. April 2024 03:50:36
> > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.
> > Betreff: Re: [subexp-daq] Possible problem in Makefile of NURDLIB  
> >
> > Dear Günter,
> >
> > we think that we have managed to solve the issues at hand (there were
> > multiple):
> >
> > - The missing TRIDI compile: r3bfuser compiles (unconditionally) with both
> >    tridi and vulom support if it compiles with one of them.  (tridi is a
> >    module with similar hardware as the vulom).  Now the compile
> >    instructions also include to get the tridi things compiles.
> >
> > - The VULOM4_FW now only picks one version, which should be enough.
> >    Those named _trlo actually have the same register layout, and
> >    find_firmwares.pl point them to the same, so any should do.
> >
> > (Please see the updated instructions in the other mail.  Only the
> > compilation sequence had additions, not the download parts.  But nurdlib
> > and r3bfuser repositores need to be updated.
> >
> > For this:
> >
> > > Reporting compilation errors when they happen and why they happen would
> > > be really very much appreciated
> >
> > I am not sure what can be done when the issues are within the
> > feature-finding builds.  I.e., when those fail, it just means that
> > certains options are not available.  Problem is when later programs rely
> > on them.
> >
> > if anything, the later programs should then produce more specific errors
> > telling what they are missing.  That might be doable with some #error
> > macros, if they do not have complex makefiles to find features.
> >
> > The other thing might be that 'make showconfig' is too cluttered.  There
> > are essentially two kinds of features.  The uninteresting ones where the
> > systems need to find one working option out of many.  If no option works,
> > things will stop, as it cannot continue.
> >
> > The more interesting selections are the ones where it can get away with no
> > support, i. this case e.g. not compiling tridi support.
> >
> > Perhaps one should have a 'make showconfig_all' which works as the one
> > now, and 'make showconfig' only giving the important ones.
> >
> > Cheers,
> > Håkan
> >
> >
> >
> > On Fri, 12 Apr 2024, Weber, Guenter Dr. wrote:
> >
> > >
> > > Dear friends,
> > >
> > >
> > > on line 108 to 110 of the Makefile there is an automatic setting of the
> > > VULOM4_FW parameter:
> > >
> > >
> > >   ifeq (,$(VULOM4_FW))
> > >    VULOM4_FW:=$(shell ls $(TRLOII_PATH)/trloctrl | grep _trlo | $(SED)
> > > 's,fw_,,;s,_trlo.*,,')
> > >   endif
> > >
> > > However, if I let this run (i.e. VULOM4_FW is not set by hand) the
> outcome
> > > is as follows:
> > >
> > >
> > > VULOM4_FW = "1409285e 68f8955e 6e4ba1a9 a73c5093 af33ed35"
> > >
> > >
> > > My understandig is that there should only be a single number selected
> > > (1409285e for VULOM4B and 6e4ba1a9 for VULOM4). I checked what the "ls"
> > > command produces on two systems:
> > >
> > >
> > > RIO4L-2 mbsdaq > ls $TRLOII_PATH/trloctrl
> > > Makefile  examples/  find_firmwares.pl*  firmwaredirs 
> fw_0866c243_rfx1/ 
> > > fw_1409285e_trlo@  fw_5e8f5ef4_tridi/  fw_68f8955e_trlo_all_in/ 
> > > fw_6e4ba1a9_trlo/  fw_a1729cda_rfx0/  fw_a73c5093_trlo@ 
> > > fw_af33ed35_trlo_big/  trloctrl.sh*  trlolib/
> > >
> > > RIO4-MCAL-1 mbsdaq > ls $TRLOII_PATH/trloctrl
> > > Makefile  examples/  find_firmwares.pl*  firmwaredirs 
> fw_0866c243_rfx1/ 
> > > fw_1409285e_trlo@  fw_5e8f5ef4_tridi/  fw_68f8955e_trlo_all_in/ 
> > > fw_6e4ba1a9_trlo/  fw_a1729cda_rfx0/  fw_a73c5093_trlo@ 
> > > fw_af33ed35_trlo_big/  tridi_log.txt  trloctrl.sh*  trlolib/ 
> > vulom_log.txt
> > >
> > >
> > > RIO4L-2 is the one I am working on right now with the VULOM4, whereas
> > > RIO4-MCAL-1 is the system already running with VULOM4B.
> > >
> > >
> > > To me it looks like the code in the Makefile is not working as intended,
> > > right?
> > >
> > >
> > >
> > >
> > >
> > > Best greetings
> > >
> > > Günter
> > >
> > >
> > >
> > >
> >
> >
> 
>