Re: [PATCH] Add GMP as a prerequisite for GDB
On 15/12/2020 08:53, Chris Johns wrote: On FreeBSD is see no dynamic libexpat: /home/user/rtems/6/bin/sparc-rtems6-gdb: libutil.so.9 => /lib/libutil.so.9 (0x8009fc000) libncursesw.so.8 => /lib/libncursesw.so.8 (0x800a13000) libm.so.5 => /lib/libm.so.5 (0x800a74000) libpython2.7.so.1 => /usr/local/lib/libpython2.7.so.1 (0x800aa6000) libdl.so.1 => /usr/lib/libdl.so.1 (0x800c9a000) libintl.so.8 => /usr/local/lib/libintl.so.8 (0x800c9e000) liblzma.so.5 => /usr/lib/liblzma.so.5 (0x800cab000) libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x800cd7000) libc++.so.1 => /usr/lib/libc++.so.1 (0x800dd5000) libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x800ea5000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x800ec7000) libthr.so.3 => /lib/libthr.so.3 (0x800ee1000) libc.so.7 => /lib/libc.so.7 (0x800f0e000) Good. Silly me, I just assumed this would be the same on all Unix systems. What does an installed gcc show? On Linux: ldd /opt/rtems/6/bin/arm-rtems6-gcc linux-vdso.so.1 (0x7ffcf4726000) libm.so.6 => /lib64/libm.so.6 (0x7f0cb05a1000) libc.so.6 => /lib64/libc.so.6 (0x7f0cb01e6000) /lib64/ld-linux-x86-64.so.2 (0x7f0cb08d9000) On FreeBSD: rtems/6/bin/sparc-rtems6-gcc: libc++.so.1 => /usr/lib/libc++.so.1 (0x80034f000) libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x80041f000) libm.so.5 => /lib/libm.so.5 (0x800441000) libc.so.7 => /lib/libc.so.7 (0x800473000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x80086c000) -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-docs commit] c-user: Generate Timer Manager documentation
[...] > > may change and may break. A release with the frozen code will point to > those > same pages for ever and that is broken no matter where the links are, > source, > comments or built and released documentation packages. The links should > either > refer to pages for that release, a link that we declare is stable or no > link but > a reference to chapter etc in a manual. > > +1 We should version cross-doc links, just like internal doc links implicitly are versioned. How that gets done is the key question here. I don't mind adding more of the cross-doc links IF there is a plan in place to sweep all of them at once to fix the versioning. Without a plan to fix the links so they will work right when a release is cut, then I agree with Chris, because it is putting technical debt on him and the release process. Gedare ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-docs commit] c-user: Generate Timer Manager documentation
On 15/12/2020 17:26, Gedare Bloom wrote: [...] may change and may break. A release with the frozen code will point to those same pages for ever and that is broken no matter where the links are, source, comments or built and released documentation packages. The links should either refer to pages for that release, a link that we declare is stable or no link but a reference to chapter etc in a manual. +1 We should version cross-doc links, just like internal doc links implicitly are versioned. I just would like to emphasize that we are currently talking about links in comments which do not show up in the generated documentation for the user. How that gets done is the key question here. I don't mind adding more of the cross-doc links IF there is a plan in place to sweep all of them at once to fix the versioning. Without a plan to fix the links so they will work right when a release is cut, then I agree with Chris, because it is putting technical debt on him and the release process. To which text should I change: _AUTOMATICALLY_GENERATED_WARNING = [ "This file is part of the RTEMS quality process and was automatically", "generated. If you find something that needs to be fixed or", "worded better please post a report or patch to an RTEMS mailing list", "or raise a bug report:", "", "https://docs.rtems.org/branches/master/user/support/bugs.html";, "", "For information on updating and regenerating please refer to:", "", "https://docs.rtems.org/branches/master/eng/req/howto.html";, ] ? -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
microzed board boot from a sd card
Hi, there, I followed this article: https://devel.rtems.org/wiki/Boards/Zynq%20-%20Zedboard for development. It basically gets the boot img file from a tftp server. It worked very well for me. Now I am done with the development. I'd like to boot with my image file on the SD card itself, not getting the img file through tftp anymore. How should I modify the uenv.txt file to do that? Thanks. Xiaomin ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] eng: Requirements counting shall start at zero
On 12/12/20 12:34 am, Gedare Bloom wrote: > I don't mind starting 0 or 1, consistency is important. > > If we know the max count (N) ahead of time, it can be helpful to generate > with a > 0-padded number. +1 > This makes every name a consistent size and can be sorted > lexicographically. If this is not possible should we estimate then allocate a number of 0's? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-docs commit] c-user: Generate Timer Manager documentation
On 16/12/20 3:38 am, Sebastian Huber wrote: > On 15/12/2020 17:26, Gedare Bloom wrote: >> [...] >> >> may change and may break. A release with the frozen code will >> point to those >> same pages for ever and that is broken no matter where the links >> are, source, >> comments or built and released documentation packages. The links >> should either >> refer to pages for that release, a link that we declare is stable >> or no link but >> a reference to chapter etc in a manual. >> >> +1 >> >> We should version cross-doc links, just like internal doc links implicitly >> are >> versioned. > I just would like to emphasize that we are currently talking about links in > comments which do not show up in the generated documentation for the user. This understood however why treat comments as something we do not take care of? We use comments in a number of ways including doxygen so lets not undermine our user's confidence in them. >> How that gets done is the key question here. >> >> I don't mind adding more of the cross-doc links IF there is a plan in place >> to >> sweep all of them at once to fix the versioning. Without a plan to fix the >> links so they will work right when a release is cut, then I agree with Chris, >> because it is putting technical debt on him and the release process. > > To which text should I change: > > _AUTOMATICALLY_GENERATED_WARNING = [ > "This file is part of the RTEMS quality process and was automatically", > "generated. If you find something that needs to be fixed or", > "worded better please post a report or patch to an RTEMS mailing list", > "or raise a bug report:", > "", > "https://docs.rtems.org/branches/master/user/support/bugs.html";, > "", > "For information on updating and regenerating please refer to:", > "", > "https://docs.rtems.org/branches/master/eng/req/howto.html";, > ] > > ? I am with Gedare and prefer we all engage in a solution to cross-links in the documentation. Maybe that can be a separate topic from the links here and we separate the issue into cross-links and these links. I am sure these links may appear in places outside of the documentation. I suggest we provide a bug page link. The regeneration link is much harder. Could it be explained in words and we avoid a link For information on updating and regenerating please refer to the How To section of the Software Engineering Manual. The Software Engineering Manual is provided as a part of a release. For development sources please refer to the online development documentation at https://docs.rtems.org. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v3 1/1] tester: Add yaml format to the supported report formats
Hello Chris,
Did you have a chance to look at the updated version of this patch?
Regards,
Cláudio
On 08/12/20 15:40, cl...@isep.ipp.pt wrote:
> From: Cláudio Maia
>
> ---
> tester/rt/test.py | 116 +-
> 1 file changed, 114 insertions(+), 2 deletions(-)
>
> diff --git a/tester/rt/test.py b/tester/rt/test.py
> index 9b157e9..66f1756 100644
> --- a/tester/rt/test.py
> +++ b/tester/rt/test.py
> @@ -339,9 +339,115 @@ def generate_junit_report(args, reports, start_time,
> end_time,
> with open(junit_file, 'w') as f:
> TestSuite.to_file(f, [ts], prettyprint = True)
>
> +
> +def generate_yaml_report(args, reports, start_time, end_time,
> + total, yaml_file):
> +""" Generates a YAML file containing information about the test run,
> +including all test outputs """
> +
> +import yaml
> +
> +def format_output(output_list):
> +return "\n".join(output_list).replace("] ", '').replace('=> ', '')
> +
> +yaml_log = {}
> +yaml_log['command-line'] = args
> +yaml_log['host'] = host.label(mode='all')
> +yaml_log['python'] = sys.version.replace('\n', '')
> +yaml_log['summary'] = {}
> +yaml_log['summary']['passed-count'] = reports.passed
> +yaml_log['summary']['failed-count'] = reports.failed
> +yaml_log['summary']['user-input-count'] = reports.user_input
> +yaml_log['summary']['expected-fail-count'] = reports.expected_fail
> +yaml_log['summary']['indeterminate-count'] = reports.indeterminate
> +yaml_log['summary']['benchmark-count'] = reports.benchmark
> +yaml_log['summary']['timeout-count'] = reports.timeouts
> +yaml_log['summary']['test-too-long_count'] = reports.test_too_long
> +yaml_log['summary']['invalid-count'] = reports.invalids
> +yaml_log['summary']['wrong-version-count'] = reports.wrong_version
> +yaml_log['summary']['wrong-build-count'] = reports.wrong_build
> +yaml_log['summary']['wrong-tools-count'] = reports.wrong_tools
> +yaml_log['summary']['total-count'] = reports.total
> +time_delta = end_time - start_time
> +yaml_log['summary']['average-test-time'] = str(time_delta / total)
> +yaml_log['summary']['testing-time'] = str(time_delta)
> +
> +result_types = [
> +'failed', 'user-input', 'expected-fail', 'indeterminate',
> +'benchmark', 'timeout', 'test-too-long', 'invalid',
> 'wrong-version',
> +'wrong-build', 'wrong-tools'
> +]
> +for result_type in result_types:
> +yaml_log['summary'][result_type] = []
> +
> +result_element = {}
> +yaml_log['outputs'] = []
> +
> +# process output of each test
> +for exe_name in reports.results:
> +test_parts = exe_name.split("/")
> +test_name = test_parts[-1]
> +result_element['executable-name'] = test_name
> +result_element['executable-sha512'] = get_hash512(exe_name)
> +result_element['execution-start'] =
> reports.results[exe_name]['start'].isoformat()
> +result_element['execution-end'] =
> reports.results[exe_name]['end'].isoformat()
> +date_diff = reports.results[exe_name]['end'] -
> reports.results[exe_name]['start']
> +result_element['execution-duration'] = str(date_diff)
> +result_element['execution-result'] =
> reports.results[exe_name]['result']
> +result_element['bsp'] = reports.results[exe_name]['bsp']
> +result_element['bsp-arch'] = reports.results[exe_name]['bsp_arch']
> +result_output = reports.results[exe_name]['output']
> +
> +dbg_output = []
> +test_output = []
> +idxs_output = [] # store indices of given substrings
> +for elem in result_output:
> +if '=> ' in elem:
> +idxs_output.append(result_output.index(elem))
> +if '*** END' in elem:
> +idxs_output.append(result_output.index(elem))
> +
> +if len(idxs_output) == 3: # test executed and has result
> +dbg_output = result_output[idxs_output[0]:idxs_output[1]]
> +dbg_output.append("=== Executed Test ===")
> +dbg_output = dbg_output +
> result_output[idxs_output[2]+1:len(result_output)]
> +test_output = result_output[idxs_output[1]:idxs_output[2]+1]
> +else:
> +dbg_output = result_output
> +
> +result_element['debugger-output'] = format_output(dbg_output)
> +result_element['console-output'] = format_output(test_output)
> +yaml_log['outputs'].append(result_element)
> +
> +result_type = reports.results[exe_name]['result']
> +# map "fatal-error" on to "failed"
> +if result_type == "fatal-error":
> +result_type = "failed"
> +
> +if result_type != 'passed':
> +yaml_log['summary'][result_type].append(test_name)
> +
> +result_element = {}
> +
> +with open(yaml_file, 'w') as outfile:
> +yaml.dump
Re: [PATCH v3 1/1] tester: Add yaml format to the supported report formats
On 16/12/20 10:36 am, Cláudio Maia wrote: > Did you have a chance to look at the updated version of this patch? Thanks for the ping and I am sorry I had let is slip. The patch looks good so it is OK to be pushed. I hope someone can do that for me. Thank you for the change and working with me on it. Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v3 1/1] tester: Add yaml format to the supported report formats
On 16/12/2020 01:28, Chris Johns wrote: The patch looks good so it is OK to be pushed. I hope someone can do that for me. Thanks for the review. I checked it in and updated the RSB. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
