[subexp-daq] Possible problem in Makefile of NURDLIB

Mon Apr 15 13:25:36 CEST 2024

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.

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
> >
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chalmers.se/pipermail/subexp-daq/attachments/20240415/b74a7d20/attachment-0001.html>