Re: [PATCH 1/2] bsps/riscv: Remove inaccurate statement about reliance on a boot loader
On 31/10/2022 10:44 pm, Hesham Almatary wrote: > Hello, > > I tried to push that but got an error message: > "remote: git_buildbot: ERROR: Could not connect to > buildbot.int.rtems.org:9899: Connection was refused by other side: 61: > Connection refused." Please try again. We have had some server issues. Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 1/2] bsps/riscv: Remove inaccurate statement about reliance on a boot loader
Hello, I tried to push that but got an error message: "remote: git_buildbot: ERROR: Could not connect to buildbot.int.rtems.org:9899: Connection was refused by other side: 61: Connection refused." Please push if you're happy with the patch. Cheers, Hesham On Tue, 25 Oct 2022 at 19:04, Hesham Almatary wrote: > > On Tue, 25 Oct 2022 at 18:59, Alan Cudmore wrote: > > > > I agree – I am working on a riscv BSP variant (Sipeed MAIX Bit with K210 > > CPU) where the RTEMS image can be flashed directly to the board and boots > > without a bootloader. > > > > I was also wondering if the statement “Each variant corresponds to a GCC > > multilib” is still accurate as BSP variants such as the FE310Arty and > > Microchip Polarfire are added? > > > I agree. It only applies to rv* BSPs. We should fix that. > > > Thanks, > > > > Alan > > > > From: heshamelmat...@gmail.com > > Sent: Tuesday, October 25, 2022 1:48 PM > > To: devel@rtems.org > > Subject: [PATCH 1/2] bsps/riscv: Remove inaccurate statement about reliance > > on a boot loader > > > > > > > > From: Hesham Almatary > > > > > > > > The BSP is capable of initialising the hardware being the first software > > > > that takes control on hardware reset (after the bootrom). For instance, > > > > using on QEMU's virt platforms, RTEMS runs as a bios without BBL. > > > > Similarily, RTEMS can also be run on harware/FPGA and loaded using > > > > GDB; the bootrom (or a GDB script) should just set the a0/a1 registers > > > > with the boot HART ID and DTB address respectively. > > > > --- > > > > user/bsps/bsps-riscv.rst | 4 +--- > > > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > > > > > diff --git a/user/bsps/bsps-riscv.rst b/user/bsps/bsps-riscv.rst > > > > index 48e7ee7..224506d 100644 > > > > --- a/user/bsps/bsps-riscv.rst > > > > +++ b/user/bsps/bsps-riscv.rst > > > > @@ -43,9 +43,7 @@ This BSP offers 15 variants: > > > > Each variant corresponds to a GCC multilib. A particular variant reflects > > an > > > > ISA with ABI and code model choice. > > > > -The basic hardware initialization is not performed by the BSP. A boot > > loader > > > > -with device tree support must be used to start the BSP, e.g. BBL. The BSP > > must > > > > -be started im machine mode. > > > > +The BSP must be started im machine mode. > > > > The reference platform for this BSP is the Qemu `virt` machine. > > > > -- > > > > 2.25.1 > > > > > > > > ___ > > > > devel mailing list > > > > devel@rtems.org > > > > http://lists.rtems.org/mailman/listinfo/devel > > > > > > > > -- > Hesham -- Hesham ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Text Formatting Patches coming
On 1/11/2022 2:59 am, Gedare Bloom wrote: > I am planning to roll out several text formatting changes over the > next 6 weeks or so, to include: > 1. Removal of URLs from Copyright lines as per #4636. Note: Most of > the included URLs currently are from EB or Chris Johns (Contemporary > Software). > 2. Consistent capitalization of Copyright (C) in file header blocks as > per #4637. > * Style Updates as per #3860. > > This effort will include documentation, inclusion of automation tools, > and 3rd party software management. I will send patches and give notice > before any changes hit, but I wanted to give a heads up here that this > process will be taking place. If you have any specific requests or > patches pending in an area that I should avoid for now, please let me > know. Sounds good and looking forward to seeing this happen. Where is the clang-format style? I would like to play and have look at the results? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Text Formatting Patches coming
On Mon, Oct 31, 2022, 4:38 PM Gedare Bloom wrote: > I am planning to roll out several text formatting changes over the > next 6 weeks or so, to include: > 1. Removal of URLs from Copyright lines as per #4636. Note: Most of > the included URLs currently are from EB or Chris Johns (Contemporary > Software). > 2. Consistent capitalization of Copyright (C) in file header blocks as > per #4637. > * Style Updates as per #3860. > Are all of these properly described in the Coding Standard? > This effort will include documentation, inclusion of automation tools, > and 3rd party software management. I will send patches and give notice > before any changes hit, but I wanted to give a heads up here that this > process will be taking place. If you have any specific requests or > patches pending in an area that I should avoid for now, please let me > know. > > Gedare > ___ > 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
Text Formatting Patches coming
I am planning to roll out several text formatting changes over the next 6 weeks or so, to include: 1. Removal of URLs from Copyright lines as per #4636. Note: Most of the included URLs currently are from EB or Chris Johns (Contemporary Software). 2. Consistent capitalization of Copyright (C) in file header blocks as per #4637. * Style Updates as per #3860. This effort will include documentation, inclusion of automation tools, and 3rd party software management. I will send patches and give notice before any changes hit, but I wanted to give a heads up here that this process will be taking place. If you have any specific requests or patches pending in an area that I should avoid for now, please let me know. Gedare ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Fwd: Identify 3rd party source in spec?
Resending without the first patch since it may trigger size filters. -- Forwarded message - From: Gedare Bloom Date: Mon, Oct 31, 2022 at 12:55 PM Subject: Identify 3rd party source in spec? To: devel@rtems.org Hello all, I would like to float the idea of managing 3rd party source tracking through the build system spec files. I believe this would be the most efficient way to maintain this information, and we can leverage the existing build system code for tasks such as automatic format checks, generating lists of third-party code, etc. This will require refactoring some spec files to pull 3rd party code out to a separate .yml file that gets linked. Once that is done, then we could add another attribute for this tracking purpose. I would like to keep it simple as a boolean, maybe just "third-party: true/false" Attached is an example patch showing how this might work for the dtc/libfdt code as a build objects item type 'obj', and for zlib library as a build library item type 'lib' with some proof-of-concept code for generating a listing of third party source files. As an initial step before making this refactoring, I have added an explicit default "third-party: false" attribute to every yml file preceding the enabled-by: attribute, using the following bit of shell: rtems.git/spec/build$ find . -name "*.yml" | xargs sed -i -e 's/\(enabled-by.*\)/third-party: false\n\1/' This touches 2333 files adding that one line, which is the contents of the first 1 MiB patch attached in the series. The remaining patches then layer on the top and are functional, outputting: rtems.git$ ./waf third_party_list cpukit/dtc/libfdt/fdt.c cpukit/dtc/libfdt/fdt_addresses.c cpukit/dtc/libfdt/fdt_empty_tree.c cpukit/dtc/libfdt/fdt_ro.c cpukit/dtc/libfdt/fdt_rw.c cpukit/dtc/libfdt/fdt_strerror.c cpukit/dtc/libfdt/fdt_sw.c cpukit/dtc/libfdt/fdt_wip.c cpukit/zlib/adler32.c cpukit/zlib/compress.c cpukit/zlib/crc32.c cpukit/zlib/deflate.c cpukit/zlib/gzclose.c cpukit/zlib/gzlib.c cpukit/zlib/gzread.c cpukit/zlib/gzwrite.c cpukit/zlib/infback.c cpukit/zlib/inffast.c cpukit/zlib/inflate.c cpukit/zlib/inftrees.c cpukit/zlib/trees.c cpukit/zlib/uncompr.c cpukit/zlib/zutil.c I'll continue to work on this, feedback is requested though if this is a good direction or how to improve. Gedare From 44ae3a1ae62875047c57fbd25163fa78e21c4ed5 Mon Sep 17 00:00:00 2001 From: Gedare Bloom Date: Mon, 31 Oct 2022 12:52:35 -0600 Subject: [PATCH 4/4] wscript: add command to print third-party sources --- wscript | 28 1 file changed, 28 insertions(+) diff --git a/wscript b/wscript index 4071cc9ef8..051f35ca52 100755 --- a/wscript +++ b/wscript @@ -226,6 +226,17 @@ class Item(object): p.build(bld, bic) self.do_build(bld, bic) +def third_parties(self, ctx): +tpl = [] +for p in self.links(): +x = p.third_parties(ctx) +if x is not None: +tpl.extend(x) +x = self.do_third_parties(ctx) +if x is not None: +tpl.extend(x) +return tpl + def do_defaults(self, variant, family): return @@ -241,6 +252,11 @@ class Item(object): def do_build(self, bld, bic): return +def do_third_parties(self, ctx): +if self.data["third-party"]: +source = self.data["source"] +return source + def substitute(self, ctx, value): if isinstance(value, str): try: @@ -1711,3 +1727,15 @@ def bsp_list(ctx): print(variant) if first: no_matches_error(ctx, white_list) + +def third_party_list(ctx): +"""lists third-party sources""" +check_forbidden_options( +ctx, ["compiler", "config", "options", "tools", "top_group", "version"] +) +add_log_filter(ctx.cmd) +load_items_from_options(ctx) +top_group = get_top_group(ctx) +tp = items[top_group].third_parties(ctx) +for s in tp: +print(s) -- 2.34.1 From a0cf7dc9dc56c83c3949a67f9c5aa439aef94994 Mon Sep 17 00:00:00 2001 From: Gedare Bloom Date: Mon, 31 Oct 2022 12:52:09 -0600 Subject: [PATCH 3/4] spec/build: mark objdtc and libz as third-party --- spec/build/cpukit/libz.yml | 2 +- spec/build/cpukit/objdtc.yml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/spec/build/cpukit/libz.yml b/spec/build/cpukit/libz.yml index d1ade6c18c..90f804f44b 100644 --- a/spec/build/cpukit/libz.yml +++ b/spec/build/cpukit/libz.yml @@ -5,7 +5,7 @@ copyrights: - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de) cppflags: [] cxxflags: [] -third-party: false +third-party: true enabled-by: true includes: [] install: diff --git a/spec/build/cpukit/objdtc.yml b/spec/build/cpukit/objdtc.yml index 2492cbca74..43f16f2b02 100644 --- a/spec/build/cpukit/objdtc.yml +++ b/spec/build/cpukit/objdtc.yml @@ -5,7 +5,7 @@ copyrights: - Copyright (C) 2022 Gedare Bloom cppflags: [] cxxflags: []
