Re: llvm on ubuntu 18.04 LTS
On 24/9/19 7:30 am, Gedare Bloom wrote: > > I'm trying out the rtems-llvm.bset on Ubuntu 18.04. > > The first error I encountered was during cmake configuration for llvm, > it can't find swig. That is strange as it should be built for you under the `swig_prefix`. I wonder if it is being built but is not being seen by llvm's cmake. I had to add building swig for MacOS. ON FreeBSD the package was all that was needed. > So, I built the devel/swig.bset inside of bare, > and tried again. It got past that error, but it is picking up the > installed swig and not the swig that is built by the RSB. I think at this point in time this is fine. It would be good have this dependency properly managed but this moves us into the issues in the other thread about packages and the dependencies. > I saw this in my rsb log. I'm not sure if it is important, but it > doesn't seem to affect anything: > -- Found Git: /usr/bin/git (found version "2.17.1") > -- git Version: v0.0.0 > -- Version: 0.0.0 Is this the LLVM git version and as the source is not in git the version is '0.0.0', ie no version? > The second error I encountered comes from missing libedit_INCLUDE_DIRS > I had a few options, but I went with: apt-get install libedit-dev OK. This looks like a dependency. Do you know which tool in LLVM needed this? > This got me past the configuration stages and into building, which > finished successfully. Great. > I have previously built llvm by hand on this machine, so I don't know > if I would encounter other problems in a vanilla environment. I may > try that out in a few days. We are building lldb and I suspect it is adding these extra dependencies. Thank you for taking the time to test and report what you have found. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: llvm on CentOS 7
On 24/9/19 6:08 am, Gedare Bloom wrote: > On Mon, Sep 16, 2019 at 4:16 PM Chris Johns wrote: >> >> On 17/9/19 12:36 am, Joel Sherrill wrote: >>> Running log as I work through this. >> >> Thanks, it is appreciated. >> >>> Build failed because I didn't have cmake. Double-checked and sb-check >>> wouldn't >>> have reported this. Not sure we should report it missing unless we can >>> designate >>> something as "needed by some packages" or let folks know which one(s). >> >> Cmake is tagged as optional as llvm is optional. >> > > Is there a (simple) way for sb-check to take arguments to check > pre-requisites on specific packages? There is no support. I think it would be good to have but I am not sure how we could collect this data and manage it. For example hosts have different names for some commands. Would it be simpler to collect the packages a specific host OS needs? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Fix exception when no output format is specified
Pushed. Thanks.
It may pay to update the RSB to pick this change up.
Chris
On 23/9/19 11:33 pm, Kinsey Moore wrote:
> The JSON log generation patch introduced a bug when the report output
> generation was not configured due to attempting to iterate over 'None'.
> ---
> tester/rt/test.py | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/tester/rt/test.py b/tester/rt/test.py
> index d5c7c66..d258b11 100644
> --- a/tester/rt/test.py
> +++ b/tester/rt/test.py
> @@ -345,6 +345,8 @@ def run(args, command_path = None):
> raise error.general('invalid RTEMS report formats option')
> report_formats = report_formats[1].split(',')
> check_report_formats(report_formats, report_location)
> +else:
> +report_formats = []
> log.notice('RTEMS Testing - Tester, %s' % (version.string()))
> if opts.find_arg('--list-bsps'):
> bsps.list(opts)
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
llvm on ubuntu 18.04 LTS
Hi Chris, I'm trying out the rtems-llvm.bset on Ubuntu 18.04. The first error I encountered was during cmake configuration for llvm, it can't find swig. So, I built the devel/swig.bset inside of bare, and tried again. It got past that error, but it is picking up the installed swig and not the swig that is built by the RSB. I saw this in my rsb log. I'm not sure if it is important, but it doesn't seem to affect anything: -- Found Git: /usr/bin/git (found version "2.17.1") -- git Version: v0.0.0 -- Version: 0.0.0 The second error I encountered comes from missing libedit_INCLUDE_DIRS I had a few options, but I went with: apt-get install libedit-dev This got me past the configuration stages and into building, which finished successfully. I have previously built llvm by hand on this machine, so I don't know if I would encounter other problems in a vanilla environment. I may try that out in a few days. Gedare ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: llvm on CentOS 7
On Mon, Sep 16, 2019 at 4:16 PM Chris Johns wrote:
>
> On 17/9/19 12:36 am, Joel Sherrill wrote:
> > Running log as I work through this.
>
> Thanks, it is appreciated.
>
> > Build failed because I didn't have cmake. Double-checked and sb-check
> > wouldn't
> > have reported this. Not sure we should report it missing unless we can
> > designate
> > something as "needed by some packages" or let folks know which one(s).
>
> Cmake is tagged as optional as llvm is optional.
>
Is there a (simple) way for sb-check to take arguments to check
pre-requisites on specific packages?
> The __cmake define in source-builder/defaults.mc could be changes to remove
> the
> absolute path and the environment's path will be searched. This is already
> done
> in FreeBSD, MacOS and I think Windows so maybe this should be the default.
>
> > Loaded cmake, then got this beauty:
> >
> > /usr/bin/cmake -Wno-dev -G 'Unix Makefiles' -DCMAKE_BUILD_TYPE=Release
> > -DCMAKE_INSTALL_PREFIX=/home/joel/rtems-work/tools/5
> > '-DPACKAGE_VERSION=8.0.1 (RTEMS 5, RSB
> > 4b7af073000d612b21b9dece538d2bcc85c0c240)'
> > -DLLDB_CODESIGN_IDENTITY=llvm ../llvm-8.0.1
> > -- Configuring incomplete, errors occurred!
> > CMake Error at CMakeLists.txt:3 (cmake_minimum_required):
> > CMake 3.4.3 or higher is required. You are running version 2.8.12.2
> >
> > Plenty of people on the net say to download and build it but it turns
> > out that EPEL
> > has a cmake3 RPM. That's a very respectable repo (unlike Ghettoforge which
> > also
> > had it).
> >
> > yum erase cmake
> > yum install cmake3
> >
> > That installed /usr/bin/cmake3 which the build doesn't know about so I
> > symbolically
> > linked /usr/bin/cmake3 to ${HOME}/bin/cmake.
> >
> > This didn't work because it checks for /usr/bin/cmake so I made that
> > symlink to cmake3.
>
> If this is needed for a specific CentOS version I suggest you detect this in
> source-builder/sb/linux.py and set __cmake to cmake3. The llvm references
> %{__cmake}. I would prefer this over documenting symlinks.
>
> > This resulted in a failure further along.
> >
> > -- Detecting CXX compile features - done
> > CMake Error at cmake/modules/CheckCompilerVersion.cmake:40 (message):
> > Host GCC version should be at least 5.1 because LLVM will soon use new C++
> > features which your toolchain version doesn't support. Your version is
> > 4.8.5. You can temporarily opt out using
> > LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN, but very soon your toolchain won't
> > be
> > supported.
> > Call Stack (most recent call first):
> > cmake/modules/CheckCompilerVersion.cmake:45 (check_compiler_version)
> > cmake/config-ix.cmake:13 (include)
> > CMakeLists.txt:590 (include)
> >
>
> Ouch.
>
> > -- Configuring incomplete, errors occurred!
> > See also
> > "/home/joel/rtems-work/rtems-source-builder/rtems/build/rtems-llvm-8.0.1-x86_64-linux-gnu-1/build/CMakeFiles/CMakeOutput.log".
> > shell cmd failed: /bin/sh -ex
> > /home/joel/rtems-work/rtems-source-builder/rtems/build/rtems-llvm-8.0.1-x86_64-linux-gnu-1/do-build
> > error: building rtems-llvm-8.0.1-x86_64-linux-gnu-1
> >
> > Looks like I need to move to a machine with newer gcc. There is a
> > floor on the host environment without doing some work. I think the
> > CentOS machine I use to do test builds of our tools from
> > gcc/binutils/newlib master should work since it has installs of
> > various newer gcc.
> >
> > That may take until I get home.
>
> Again thanks.
>
> FYI Windows with MSYS2 is not bilding even after upgrading it to latest
> packages
> and installing clang-8.0.2 as a package to build clang-8.0.2 with.
>
> On Windows the unpacking of the source has proved problematic because the cfe
> tarball contains links to files that are extracted after the link and on
> Windows
> that fails, the target needs to exist. I have added support to the RSB to
> handle
> this however the testsuite contains a bad link to a non-existent target for
> testing and this means the untar always fails. I have added a work around to
> the
> RSB for this but it is a little painful.
>
> I think this highlights there is a reasonable amount of work to get LLVM and
> clang building on all hosts. On the other hand MSYS2 is like other packaging
> systems, it provides clang-8.0.2 and it is built with all targets. Our users
> can
> then decide to use the packaged LLVM or build from source.
>
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] Fix exception when no output format is specified
The JSON log generation patch introduced a bug when the report output
generation was not configured due to attempting to iterate over 'None'.
---
tester/rt/test.py | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tester/rt/test.py b/tester/rt/test.py
index d5c7c66..d258b11 100644
--- a/tester/rt/test.py
+++ b/tester/rt/test.py
@@ -345,6 +345,8 @@ def run(args, command_path = None):
raise error.general('invalid RTEMS report formats option')
report_formats = report_formats[1].split(',')
check_report_formats(report_formats, report_location)
+else:
+report_formats = []
log.notice('RTEMS Testing - Tester, %s' % (version.string()))
if opts.find_arg('--list-bsps'):
bsps.list(opts)
--
2.11.0
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
RE: rtems-tester initial port getting "'NoneType' object is not iterable"
> -Original Message-
> From: devel On Behalf Of dufa...@hda.com
> Sent: Saturday, September 21, 2019 08:48
> To: Joel Sherrill
> Cc: rtems-de...@rtems.org
> Subject: Re: rtems-tester initial port getting "'NoneType' object is not
> iterable"
>
>
>
> > On Sep 20, 2019, at 21:43 , Joel Sherrill wrote:
> >
> >
> >
> > On Fri, Sep 20, 2019, 8:21 PM Chris Johns wrote:
> > On 21/9/19 5:56 am, dufa...@hda.com wrote:
> > > One thing I should have said is that “rtems" and "rtems-tester" are the
> master branches, "rtems-tester" is updated as of yesterday, and “rtems” is
> recent.
> >
> > Thanks.
> >
> > >
> > >> On Sep 20, 2019, at 15:46 , Peter Dufault wrote:
> > >>
> > >> I’m bringing up the rtems-tester for the PowerPC “beatnik” bsp. I’m
> impressed with how easy it is to implement (well done, Chris).
> >
> > Thanks, it is good to get this type of feedback and things are just working.
> >
> > > But after doing all the easy work, and just as I thought my initial run
> > > of the
> “samples" was about to exit successfully, the script faulted and gave me the
> error "TypeError: 'NoneType' object is not iterable”. I’ve pasted the output
> of
> my run below.
> >
> > OK.
> >
> > >> Average test time: 0:00:40.583694
> >
> > Does this target take a bit of time to boot?
>
> There’s at least 16 seconds overhead - 2 seconds in the power off / on, about
> 7
> seconds before the MOTLOAD monitor visibly starts (probably testing), and a 7
> second delay (that I now see I can change, I’ll lower it to 1) where it is
> letting
> you hit to skip the auto-boot.
>
> >
> > >> Testing time : 0:09:28.171711
> > >> Traceback (most recent call last):
> > >> File "../rtems-tools/tester/rt/cmd-test.py", line 42, in
> > >>test.run(sys.argv[1:], command_path = base) File
> > >> "/home/dufault/development/rtems/rtems-tools/tester/rt/test.py", line
> 455, in run
> > >>for report_format in report_formats:
> > >> TypeError: 'NoneType' object is not iterable
> >
> > This is from Kinsey patch where report formats was added
> >
> > https://git.rtems.org/rtems-tools/commit/?id=5fcaf843bdb491e2da14dc1af
> > 61806ac6d20bae5
> >
> >
> > Joel?
> >
> > Sorry I was traveling home today. I have good news to pass along later.
> >
> > I will get Kinsey to look at this. Peter can you email us the configuration
> > file?
>
> Here’s the global “.ini” file,
> rtems-tools/tester/rtems/testing/bsps/beatnik.ini. I
> notice I should change the reset expressikno to be any error status ("^Error
> Status: " is enough to indicate a problem).
>
> #
> # This is for the MVME5500 PowerPC VME board running the "beatnik" BSP.
> # - The console is connected to a telnet tty device.
> # - The system is running MOTLoad RTOS Version 2.0, PAL Version 2.5 RM01 # -
> The system is connected to ethernet and is booted via TFTP.
> #
> [beatnik]
> bsp= beatnik
> arch = powerpc
> tester = %{_rtscripts}/tftp.cfg
> jobs = 1
> test_restarts = 3
> target_reset_regex = ^Error Status: 0081 target_start_regex =
> ^MVME5500>
> requires = target_on_command, target_off_command,
> target_reset_command, bsp_tty_dev
>
> Here’s my site “.ini” file.
> - beatnik-mkbin is a shell script that does this: "powerpc-rtems5-objcopy -
> Obinary ${from} ${to}” to create a “.bin” from a “.exe”;
> - power-ctl is a shell script that manipulates a network power switch;
> - The console runs at 9600 baud and uses a raspberry PI named “swlab-term”
> running ser2net at port 2000.
>
> [beatnik]
> tftp_port = 3822
> bsp_tty_dev= swlab-term:2000
> target_pretest_command = ./beatnik-mkbin @EXE@
> target_exe_filter = /\.exe/.bin/
> target_on_command = ./power-ctl 1 off-on
> target_off_command = ./power-ctl 1 off
> target_reset_command = ./power-ctl 1 off-on
>
> Peter
> -
> Peter Dufault
> HD Associates, Inc. Software and System Engineering
This bug appears to have snuck in when I refactored the patch for the future
handling of multiple report types. I'll have a patch up shortly.
Kinsey
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: rtems tester: Why does rtems_test_assert() just exit?
> On Sep 22, 2019, at 18:45 , Chris Johns wrote: > > On 23/9/19 12:33 am, dufa...@hda.com wrote: >>> On Sep 22, 2019, at 07:12 , wrote: On Sep 21, 2019, at 17:29 , dufa...@hda.com wrote: > On Sep 21, 2019, at 17:04 , Chris Johns wrote: >>> (…) > The tester is designed to avoid cycling power. A clean working target > should > only need a single power on at the start and a single power off at the > end. > Repeated power cycling can stress power supplies and targets, some switch > modes > do not like it. Some targets have hardware reset issues and may need a > power > cycle and I have seen uboot get wedged. The power cycle logic is for those > cases. I would not expect this being needed on each boot. Also it is a > reset > which can be a power cycle or a wired reset signal however some SOCs > these days > have separate power on reset (POR) logic and a reset signal logic. > > Chris You are bringing up most of my concerns in your response, I’ll go over your response properly tomorrow AM when I’ll have free time. Thanks. >>> I think if I change "rtems_test_assert()" to invoke >>> "exit(RTEMS_FATAL_SOURCE_ASSERT)" instead of "exit(0)" and then use the >>> following for the reset expression it will do what I would like. I'm sure >>> there is a better way to do that regular expression but I'll use this for a >>> test. >>> >>> target_reset_regex = .* RTEMS_FATAL_SOURCE_BDBUF, .*|.* >>> RTEMS_FATAL_SOURCE_APPLICATION, .*|.* RTEMS_FATAL_SOURCE_BSP, .*|.* >>> RTEMS_FATAL_SOURCE_ASSERT, .*|.* RTEMS_FATAL_SOURCE_STACK_CHECKER, .*|.* >>> RTEMS_FATAL_SOURCE_EXCEPTION, .*|.* RTEMS_FATAL_SOURCE_SMP, .*|.* >>> RTEMS_FATAL_SOURCE_PANIC, .*|.* RTEMS_FATAL_SOURCE_INVALID_HEAP_FREE, .* > > The tester knows the test has finished with '*** END OF TEST ' so it will end > the test when this message is seen. If your host is fast or the console is > buffered the test will finish and be looking for the test begin message and > if a > reset trigger is seen in the output from the end of the previous test the > board > will reset as part of the start of the next test. > > In theory a good quality target should not need any reset triggers however it > will need a start trigger to catch a test failing without any output and > restarting. > >> This doesn't work as I'd hoped. There is pending input to the tester from >> the tested device's serial port console. If the tester matches the reset >> condition *after* the first reset but *before* the board restarts it will >> issue the reset again. >> >> In the case of "unlimited.exe" the following is what happened. I watched >> the tester power cycle the board off and on about 15 times before it >> advanced to the next test. >> >> After issuing the reset command should the tester advance through the >> console output without taking action until it sees the start expression? >> >> (...) >> ] TEST3 : signal task 0a01034e to delete, task 844 ending. >> => target reset condition detected >> => target reset: ./power-ctl 1 off-on >> ] TEST3 : signal task 0a01034f to delete, fatal source: >> RTEMS_FATAL_SOURCE_EXCEPTION, error code: 9018872 >> ] exception vector 7 (0x7) >> ] next PC or address of fault = 0x00890038 >> (...) >> ] executing thread ID = 0x0a01034f, name = ai45 >> ] Stack Trace: >> ] IP: 0x00890038, LR: 0x0089003a >> => target reset condition detected >> => target reset: ./power-ctl 1 off-on >> ] fatal source: RTEMS_FATAL_SOURCE_EXCEPTION, error code: 9018088 >> ] exception vector 3 (0x3) > > Is this from the power being turned off? If it is this would cause a loop if > in > the reset trigger. > No, whatever error happened in "unlmited.exe" generated a cascade of errors and so they are all in the console output for the tester to read. The tester reads through them sequentially and keeps cycling power off and on. I did put in the change for the tester to cycle to a start expression after it issues a reset without issuing multiple resets. That almost did what I wanted in that it cycled to the start without any more resets. The tester did not end the test, though, so it issued a second reset when the board requested a TFTP transfer request. I'll think about this a little more, I don't think these are really RESET regular expressions but an "outside of the current tester's framework" failure regular expression. These RTEMS_FATAL_FUBAR errors mean: - The test has failed, and the test is going to reset the board momentarily. There's no need for the tester to do a reset, the tester can fail this test and advance to the next test and download the next test at the next TFTP transfer request. - The test has failed catastrophically, and we're now going to get a possibly infinite cascade of these errors. Rather than wait for a three minute timeout of cascading errors it would be nice to count to a certain number, reset, fail
