Re: [PATCH] Add support for ELF notes
On 28/3/2023 5:48 pm, Sebastian Huber wrote: > On 25.03.23 00:39, Chris Johns wrote: >> On 24/3/2023 7:32 pm, Sebastian Huber wrote: >>> On 23.03.23 20:07, Chris Johns wrote: On 24/3/2023 3:57 am, Sebastian Huber wrote: > On 23.03.23 17:52, Will wrote: >> Great idea to store this information in the executable itself. Does this >> need >> a RTEMS_TEST_STATE_LINK_ONLY test state or something similar for >> minimum.exe? > > With the notes you can build the test. The test runner would look at the > notes > and then decide if it makes sense to run the test or not. It could still > run the > minimum.exe and see if it terminates. I welcome notes support. Thanks for adding it. How will we control and manage the notes we support? >>> >>> In the new elfnote.h header file there are defines for the note type >>> (domain-specific integer). >> >> Great. >> Should we document the top level notes domains (?) with some we control and restrict and others users can use? For example `note.rtems.test`, `note.rtems.kernel`, `note.rtems.bsp`, and `note.rtems.user`? >>> >>> The section name doesn't matter. You can divide the number space of the note >>> type for this. >> >> Does this mean we define the numbers or number ranges or is it left open? I >> am >> not sure I am following this bit. > > The patch has this: > > #define ELF_NOTE_RTEMS_TYPE( _index ) ( ( _index ) + 0x1 ) > > We basically have 32-bits available. We could also use something like this: > > #define ELF_NOTE_RTEMS_BASE_TYPE( _index ) ( ( _index ) + 0x1000 ) > > #define ELF_NOTE_RTEMS_TEST_TYPE( _index ) ( ( _index ) + 0x2000 ) > > #define ELF_NOTE_RTEMS_USER_TYPE( _index ) ( ( _index ) + 0x3000 ) > > ... > Nice. Do you have any host side tools in mind to access notes apart from the standards like readefl? Maybe the rtems-exe-info tool could do this? >>> >>> Yes, it should be added to this tool. >> >> Great. Once we have something merged I can take a look. >> >>> I think the most important use case is the >>> RTEMS tester currently. You can read the notes with the elftools for Python. >> >> I could not see an elftools module in the standard cpython support and I have >> carefully avoided any pipy dependences in user facing tools. We have elf >> support >> in the tool kit so if we can sort something out without needing to add >> something >> else I would prefer it. I think the first thing to do is the get this into >> rtems.git and then we can address the tooling we need. > > We could add a JSON output to rtems-exe-info which is used by the RTEMS > Tester. > The drawback is that you need a process for each executable. The exe info tool is fast and yes exporting JSON is a good idea. I have a decent C++ JSON implementation I am using that can be added to the toolkit and used. >> We have a GSoC project to sort out the post link stuff that was stripped out >> when we moved to waf. Could that detail be added as notes? There is something >> nice about each executable having the needed info and not needing to match an >> exe with a specific installed configuration set up. > > I think we just have to try it out. Great. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Add support for ELF notes
On 28.03.23 09:03, Chris Johns wrote: On 28/3/2023 5:48 pm, Sebastian Huber wrote: On 25.03.23 00:39, Chris Johns wrote: On 24/3/2023 7:32 pm, Sebastian Huber wrote: On 23.03.23 20:07, Chris Johns wrote: On 24/3/2023 3:57 am, Sebastian Huber wrote: On 23.03.23 17:52, Will wrote: Great idea to store this information in the executable itself. Does this need a RTEMS_TEST_STATE_LINK_ONLY test state or something similar for minimum.exe? With the notes you can build the test. The test runner would look at the notes and then decide if it makes sense to run the test or not. It could still run the minimum.exe and see if it terminates. I welcome notes support. Thanks for adding it. How will we control and manage the notes we support? In the new elfnote.h header file there are defines for the note type (domain-specific integer). Great. Should we document the top level notes domains (?) with some we control and restrict and others users can use? For example `note.rtems.test`, `note.rtems.kernel`, `note.rtems.bsp`, and `note.rtems.user`? The section name doesn't matter. You can divide the number space of the note type for this. Does this mean we define the numbers or number ranges or is it left open? I am not sure I am following this bit. The patch has this: #define ELF_NOTE_RTEMS_TYPE( _index ) ( ( _index ) + 0x1 ) We basically have 32-bits available. We could also use something like this: #define ELF_NOTE_RTEMS_BASE_TYPE( _index ) ( ( _index ) + 0x1000 ) #define ELF_NOTE_RTEMS_TEST_TYPE( _index ) ( ( _index ) + 0x2000 ) #define ELF_NOTE_RTEMS_USER_TYPE( _index ) ( ( _index ) + 0x3000 ) ... Nice. Maybe we should also encode the data type here, for example: #define ELF_NOTE_DATA_TYPE_BOOL 0 #define ELF_NOTE_DATA_TYPE_INT8 1 #define ELF_NOTE_DATA_TYPE_UINT8 2 #define ELF_NOTE_DATA_TYPE_INT16 3 #define ELF_NOTE_DATA_TYPE_UINT16 4 #define ELF_NOTE_DATA_TYPE_INT32 5 #define ELF_NOTE_DATA_TYPE_UINT32 6 #define ELF_NOTE_DATA_TYPE_INT64 7 #define ELF_NOTE_DATA_TYPE_UINT64 8 #define ELF_NOTE_DATA_TYPE_FLOAT32 9 #define ELF_NOTE_DATA_TYPE_FLOAT32 10 #define ELF_NOTE_DATA_TYPE_FLOAT64 11 #define ELF_NOTE_DATA_TYPE_FLOAT64 12 #define ELF_NOTE_DATA_TYPE_STRING 13 #define ELF_NOTE_DATA_TYPE_BINARY 14 #define ELF_NOTE_RTEMS_BASE_TYPE( _data_type, _index ) \ ( ( ( _data_type ) << 28 ) | ( ( _index ) + 0x100 ) ) This could be used by the host tool to more easily produce the right JSON data. -- 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: [PATCH] Add support for ELF notes
On 28/3/2023 6:20 pm, Sebastian Huber wrote: > On 28.03.23 09:03, Chris Johns wrote: >> On 28/3/2023 5:48 pm, Sebastian Huber wrote: >>> On 25.03.23 00:39, Chris Johns wrote: On 24/3/2023 7:32 pm, Sebastian Huber wrote: > On 23.03.23 20:07, Chris Johns wrote: >> On 24/3/2023 3:57 am, Sebastian Huber wrote: >>> On 23.03.23 17:52, Will wrote: Great idea to store this information in the executable itself. Does this need a RTEMS_TEST_STATE_LINK_ONLY test state or something similar for minimum.exe? >>> With the notes you can build the test. The test runner would look at the >>> notes >>> and then decide if it makes sense to run the test or not. It could still >>> run the >>> minimum.exe and see if it terminates. >> I welcome notes support. Thanks for adding it. >> >> How will we control and manage the notes we support? > In the new elfnote.h header file there are defines for the note type > (domain-specific integer). Great. >> Should we document the top level notes domains (?) with some we control >> and >> restrict and others users can use? For example `note.rtems.test`, >> `note.rtems.kernel`, `note.rtems.bsp`, and `note.rtems.user`? > The section name doesn't matter. You can divide the number space of the > note > type for this. Does this mean we define the numbers or number ranges or is it left open? I am not sure I am following this bit. >>> The patch has this: >>> >>> #define ELF_NOTE_RTEMS_TYPE( _index ) ( ( _index ) + 0x1 ) >>> >>> We basically have 32-bits available. We could also use something like this: >>> >>> #define ELF_NOTE_RTEMS_BASE_TYPE( _index ) ( ( _index ) + 0x1000 ) >>> >>> #define ELF_NOTE_RTEMS_TEST_TYPE( _index ) ( ( _index ) + 0x2000 ) >>> >>> #define ELF_NOTE_RTEMS_USER_TYPE( _index ) ( ( _index ) + 0x3000 ) >>> >>> ... >>> >> Nice. > > Maybe we should also encode the data type here, for example: > > #define ELF_NOTE_DATA_TYPE_BOOL 0 > #define ELF_NOTE_DATA_TYPE_INT8 1 > #define ELF_NOTE_DATA_TYPE_UINT8 2 > #define ELF_NOTE_DATA_TYPE_INT16 3 > #define ELF_NOTE_DATA_TYPE_UINT16 4 > #define ELF_NOTE_DATA_TYPE_INT32 5 > #define ELF_NOTE_DATA_TYPE_UINT32 6 > #define ELF_NOTE_DATA_TYPE_INT64 7 > #define ELF_NOTE_DATA_TYPE_UINT64 8 > #define ELF_NOTE_DATA_TYPE_FLOAT32 9 > #define ELF_NOTE_DATA_TYPE_FLOAT32 10 > #define ELF_NOTE_DATA_TYPE_FLOAT64 11 > #define ELF_NOTE_DATA_TYPE_FLOAT64 12 > #define ELF_NOTE_DATA_TYPE_STRING 13 > #define ELF_NOTE_DATA_TYPE_BINARY 14 > > #define ELF_NOTE_RTEMS_BASE_TYPE( _data_type, _index ) \ > ( ( ( _data_type ) << 28 ) | ( ( _index ) + 0x100 ) ) > > This could be used by the host tool to more easily produce the right JSON > data. > Good idea. I cannot think of anything else as scoping would tend to reduce to a new type. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2] eng: Add register block specification types
On 28.03.23 07:53, Chris Johns wrote: On 23/3/2023 3:59 am, Sebastian Huber wrote: Hello Chris, I would like to come back to this topic, because it blocks the integration of the sparc/gr712rc and sparc/gr740 changes we have done for the pre-qualification activity. On 27.09.21 02:23, Chris Johns wrote: On 24/9/21 11:09 pm, Sebastian Huber wrote: A register block may be used to specify the interface of devices which use a linear address space. Register blocks consist of register block Can we please move away from the "linear address" in the definitions? As stated previously it only serves a specialized version of a bus and register-block. What about something like this: A register block specifies a word addressable set of elements in a device software is required to access and manipulate. The mechanics software uses to access a register element in a register-block is defined by the bus-interface. The software and register may be a direct coupling to the CPU bus as found in a linear cache coherent memory mapped device or the access may be indirect through a bus hierarchy that may require more than one software action to complete. Device and register specifications are independent of the CPU architecture and connecting bus architectures. A linear address space is just an address space in which a single integer is sufficient to address something. So a word addressable set of elements in a device is a linear address space. In contrast to for example the AArch32 system register space, which uses a coprocessor index, Opcode_1, CRn, CRm, and Opcode_2. An address space granule is the smallest block of memory that can be addressed. This could be a subword depending on what a word is and the bus system capabilities. I am sorry I have read and reread this and I do not follow. I do not know if you are saying the aarch64 cp access and addressing is an example for or a counter example? The AArch32 system registers are an example for a not linear or segmented address space. The term "linear address" offers no value. An address bus at any point in a circuit is are collection of signals wired to the address decoder of a device so by the nature of how that works it is going to resolve itself to a number and to be accurate it is a whole number because the concept of negative addressing would be interesting. The wiring of the interfacing address to a device's address bus does not have to be 1:1 and it does not need to be continuous in the external interface's addressing scheme. If linear is saying there is a series of numbers then again I wonder what the value is. You can view this in datasheets and code that maps struct to memory mapping devices because reserved (or what ever they get called) are added. Adding these reserved etc fields is doing nothing more than making a memory mapped struct work as you hope and I mean hope. That logic needs a continuous address space. The register block specification is used to specify a device which consists of registers with an address. Each register consists of bit fields. We need a name for the address space of the register block specification and linear address space is from my point of view the best name for an address space in which an address is simply an unsigned integer. How would you name it? The register block specification does not specify a bus system. It just transfers what you have documented in a datasheet of a device. I did read quite a lot of datasheets and the register block specification resulted from this experience. Do you have a datasheet which would be difficult to translate into the proposed scheme? Actually the register block specification for the Gailser IP Library was done by translating the PDF https://www.gaisler.com/products/grlib/grip.pdf into a text file, parsing the text file with a Python script and then generating the specification files: https://git.rtems.org/rtems-central/tree/spec/dev/grlib/if This work was reviewed by the ISVV activity: https://devel.rtems.org/ticket/4842 The offsets in the register block specification are just the offset you find in the corresponding datasheet. I know this is just the commit message but I think this should be in the manual. bus-interface: A bus interface is the mechanics software uses to access a register word element in a device. A bus interface specifies the requirements needed by software to access a register word. It must consider timing, CPU word size to device word size, byte ordering for word sizes greater than 8bits, cache considerations and sequencing of multiple software accesses if required. I would like to see a bus-interface section and the device reference it. It only needs to cover the type of bus interface you need to specify at this point in time. At the moment I just have a header file generator for memory-mapped devices. I don't think there will be major issues to adopt the generator to output interfaces for some bus space API. I think the langua
FreeBSD libefi import -- how to proceed?
Folks, I'm using FreeBSD's libefi on my hacked multiboot2 based amd64 BSP which I'd like to push for review (at least). Now, I'd like to prepare libefi for import but I'm still in doubts if to do that in: - as intact form as possible, import even files which will not be used in foreseeable future or even ever - as minimalistic as possible. Include only files really needed by RTEMS. Where making compilation issues #ifdef __rtems__ as usual. What exactly I need to import is: https://github.com/freebsd/freebsd-src/tree/main/stand/efi/include https://github.com/freebsd/freebsd-src/tree/main/stand/efi/libefi In 'include' I'd like to omit risc/arm/arm64 platform specific subdirectories for now. Anyway, plan is to put both those directories into bsps/shared/freebsd/stand/efi to mimic perfectly location in FBSD tree and to have them ready to be reusable later for arm64 and risc-v BSPs consumption. Thanks! Karel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
GSoC Proposal for Code Formatting and Style Check for RTEMS score
Hey there, the draft for my GSoC 2023 proposal is ready. It would be very helpful if anyone could review my proposal. All your suggestions are welcome. I have attached the link to my proposal below and opened it for suggestions. If there is any issue with the link, please do let me know. https://docs.google.com/document/d/11nEfcVgS7XvwPSW3VEreohFeaT9vP8dLNb41sz420UA/edit?usp=sharing -- *Thanks & Regards* *Hardik Sethi* ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Add support for ELF notes
On 28.03.23 09:26, Chris Johns wrote: On 28/3/2023 6:20 pm, Sebastian Huber wrote: On 28.03.23 09:03, Chris Johns wrote: On 28/3/2023 5:48 pm, Sebastian Huber wrote: On 25.03.23 00:39, Chris Johns wrote: On 24/3/2023 7:32 pm, Sebastian Huber wrote: On 23.03.23 20:07, Chris Johns wrote: On 24/3/2023 3:57 am, Sebastian Huber wrote: On 23.03.23 17:52, Will wrote: Great idea to store this information in the executable itself. Does this need a RTEMS_TEST_STATE_LINK_ONLY test state or something similar for minimum.exe? With the notes you can build the test. The test runner would look at the notes and then decide if it makes sense to run the test or not. It could still run the minimum.exe and see if it terminates. I welcome notes support. Thanks for adding it. How will we control and manage the notes we support? In the new elfnote.h header file there are defines for the note type (domain-specific integer). Great. Should we document the top level notes domains (?) with some we control and restrict and others users can use? For example `note.rtems.test`, `note.rtems.kernel`, `note.rtems.bsp`, and `note.rtems.user`? The section name doesn't matter. You can divide the number space of the note type for this. Does this mean we define the numbers or number ranges or is it left open? I am not sure I am following this bit. The patch has this: #define ELF_NOTE_RTEMS_TYPE( _index ) ( ( _index ) + 0x1 ) We basically have 32-bits available. We could also use something like this: #define ELF_NOTE_RTEMS_BASE_TYPE( _index ) ( ( _index ) + 0x1000 ) #define ELF_NOTE_RTEMS_TEST_TYPE( _index ) ( ( _index ) + 0x2000 ) #define ELF_NOTE_RTEMS_USER_TYPE( _index ) ( ( _index ) + 0x3000 ) ... Nice. Maybe we should also encode the data type here, for example: #define ELF_NOTE_DATA_TYPE_BOOL 0 #define ELF_NOTE_DATA_TYPE_INT8 1 #define ELF_NOTE_DATA_TYPE_UINT8 2 #define ELF_NOTE_DATA_TYPE_INT16 3 #define ELF_NOTE_DATA_TYPE_UINT16 4 #define ELF_NOTE_DATA_TYPE_INT32 5 #define ELF_NOTE_DATA_TYPE_UINT32 6 #define ELF_NOTE_DATA_TYPE_INT64 7 #define ELF_NOTE_DATA_TYPE_UINT64 8 #define ELF_NOTE_DATA_TYPE_FLOAT32 9 #define ELF_NOTE_DATA_TYPE_FLOAT32 10 #define ELF_NOTE_DATA_TYPE_FLOAT64 11 #define ELF_NOTE_DATA_TYPE_FLOAT64 12 #define ELF_NOTE_DATA_TYPE_STRING 13 #define ELF_NOTE_DATA_TYPE_BINARY 14 #define ELF_NOTE_RTEMS_BASE_TYPE( _data_type, _index ) \ ( ( ( _data_type ) << 28 ) | ( ( _index ) + 0x100 ) ) This could be used by the host tool to more easily produce the right JSON data. Good idea. I cannot think of anything else as scoping would tend to reduce to a new type. Another option would be to add a GNU note type for JSON data. The note description would be an arbitrary JSON string. For example: diff --git a/binutils/readelf.c b/binutils/readelf.c index cafba9a4f56..1d977376b77 100644 --- a/binutils/readelf.c +++ b/binutils/readelf.c @@ -20261,6 +20261,10 @@ print_gnu_note (Filedata * filedata, Elf_Internal_Note *pnote) print_gnu_property_note (filedata, pnote); break; +case NT_GNU_JSON: + print_json_note (filedata, pnote); + break; + default: /* Handle unrecognised types. An error message should have already been created by get_gnu_elf_note_type(), so all that we need to do is to diff --git a/include/elf/common.h b/include/elf/common.h index ebcd8f9e82c..c5671447074 100644 --- a/include/elf/common.h +++ b/include/elf/common.h @@ -805,6 +805,7 @@ #define NT_GNU_BUILD_ID3 /* Generated by ld --build-id. */ #define NT_GNU_GOLD_VERSION4 /* Generated by gold. */ #define NT_GNU_PROPERTY_TYPE_0 5 /* Generated by gcc. */ +#define NT_GNU_JSON6 /* Contains arbitrary JSON data. */ #define NT_GNU_BUILD_ATTRIBUTE_OPEN0x100 #define NT_GNU_BUILD_ATTRIBUTE_FUNC0x101 -- 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: [PATCH] Add support for ELF notes
On 29/3/2023 5:36 am, Sebastian Huber wrote: > On 28.03.23 09:26, Chris Johns wrote: >> On 28/3/2023 6:20 pm, Sebastian Huber wrote: >>> On 28.03.23 09:03, Chris Johns wrote: On 28/3/2023 5:48 pm, Sebastian Huber wrote: > On 25.03.23 00:39, Chris Johns wrote: >> On 24/3/2023 7:32 pm, Sebastian Huber wrote: >>> On 23.03.23 20:07, Chris Johns wrote: On 24/3/2023 3:57 am, Sebastian Huber wrote: > On 23.03.23 17:52, Will wrote: >> Great idea to store this information in the executable itself. Does >> this >> need >> a RTEMS_TEST_STATE_LINK_ONLY test state or something similar for >> minimum.exe? > With the notes you can build the test. The test runner would look at > the > notes > and then decide if it makes sense to run the test or not. It could > still > run the > minimum.exe and see if it terminates. I welcome notes support. Thanks for adding it. How will we control and manage the notes we support? >>> In the new elfnote.h header file there are defines for the note type >>> (domain-specific integer). >> Great. >> Should we document the top level notes domains (?) with some we control and restrict and others users can use? For example `note.rtems.test`, `note.rtems.kernel`, `note.rtems.bsp`, and `note.rtems.user`? >>> The section name doesn't matter. You can divide the number space of the >>> note >>> type for this. >> Does this mean we define the numbers or number ranges or is it left open? >> I am >> not sure I am following this bit. > The patch has this: > > #define ELF_NOTE_RTEMS_TYPE( _index ) ( ( _index ) + 0x1 ) > > We basically have 32-bits available. We could also use something like > this: > > #define ELF_NOTE_RTEMS_BASE_TYPE( _index ) ( ( _index ) + 0x1000 ) > > #define ELF_NOTE_RTEMS_TEST_TYPE( _index ) ( ( _index ) + 0x2000 ) > > #define ELF_NOTE_RTEMS_USER_TYPE( _index ) ( ( _index ) + 0x3000 ) > > ... > Nice. >>> Maybe we should also encode the data type here, for example: >>> >>> #define ELF_NOTE_DATA_TYPE_BOOL 0 >>> #define ELF_NOTE_DATA_TYPE_INT8 1 >>> #define ELF_NOTE_DATA_TYPE_UINT8 2 >>> #define ELF_NOTE_DATA_TYPE_INT16 3 >>> #define ELF_NOTE_DATA_TYPE_UINT16 4 >>> #define ELF_NOTE_DATA_TYPE_INT32 5 >>> #define ELF_NOTE_DATA_TYPE_UINT32 6 >>> #define ELF_NOTE_DATA_TYPE_INT64 7 >>> #define ELF_NOTE_DATA_TYPE_UINT64 8 >>> #define ELF_NOTE_DATA_TYPE_FLOAT32 9 >>> #define ELF_NOTE_DATA_TYPE_FLOAT32 10 >>> #define ELF_NOTE_DATA_TYPE_FLOAT64 11 >>> #define ELF_NOTE_DATA_TYPE_FLOAT64 12 >>> #define ELF_NOTE_DATA_TYPE_STRING 13 >>> #define ELF_NOTE_DATA_TYPE_BINARY 14 >>> >>> #define ELF_NOTE_RTEMS_BASE_TYPE( _data_type, _index ) \ >>> ( ( ( _data_type ) << 28 ) | ( ( _index ) + 0x100 ) ) >>> >>> This could be used by the host tool to more easily produce the right JSON >>> data. >>> >> Good idea. I cannot think of anything else as scoping would tend to reduce >> to a >> new type. > > Another option would be to add a GNU note type for JSON data. The note > description would be an arbitrary JSON string. Wooo that is interesting. JSON can be useful in these situations. I like it. Chris > For example: > > diff --git a/binutils/readelf.c b/binutils/readelf.c > index cafba9a4f56..1d977376b77 100644 > --- a/binutils/readelf.c > +++ b/binutils/readelf.c > @@ -20261,6 +20261,10 @@ print_gnu_note (Filedata * filedata, > Elf_Internal_Note > *pnote) > print_gnu_property_note (filedata, pnote); > break; > > + case NT_GNU_JSON: > + print_json_note (filedata, pnote); > + break; > + > default: > /* Handle unrecognised types. An error message should have already > been > created by get_gnu_elf_note_type(), so all that we need to do is to > diff --git a/include/elf/common.h b/include/elf/common.h > index ebcd8f9e82c..c5671447074 100644 > --- a/include/elf/common.h > +++ b/include/elf/common.h > @@ -805,6 +805,7 @@ > #define NT_GNU_BUILD_ID 3 /* Generated by ld > --build-id. */ > #define NT_GNU_GOLD_VERSION 4 /* Generated by gold. */ > #define NT_GNU_PROPERTY_TYPE_0 5 /* Generated by gcc. */ > +#define NT_GNU_JSON 6 /* Contains arbitrary JSON data. */ > > #define NT_GNU_BUILD_ATTRIBUTE_OPEN 0x100 > #define NT_GNU_BUILD_ATTRIBUTE_FUNC 0x101 > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 0/1] Improve coherence of user/start docs
This patch improves consistency of the documentation in the user/start section. In app.rst, absolute path has been removed because the PATH had already been set appropriately in the previous page, i.e. bsp-buil. In bsp-build.rst, instructions have been removed for manually creating a build directory as it is unnecessary. Apart from that, minor grammatical fixes have been made. Utkarsh Verma (1): bsp-howto: Fix grammar and improve coherence. user/start/app.rst | 2 +- user/start/bsp-build.rst | 17 + 2 files changed, 6 insertions(+), 13 deletions(-) -- 2.40.0 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 1/1] bsp-howto: Fix grammar and improve coherence.
--- user/start/app.rst | 2 +- user/start/bsp-build.rst | 17 + 2 files changed, 6 insertions(+), 13 deletions(-) diff --git a/user/start/app.rst b/user/start/app.rst index ce9a44d..0599305 100644 --- a/user/start/app.rst +++ b/user/start/app.rst @@ -209,7 +209,7 @@ Run the executable: .. code-block:: none -$HOME/quick-start/rtems/@rtems-ver-major@/bin/rtems-run --rtems-bsps=erc32-sis build/sparc-rtems@rtems-ver-major@-erc32/hello.exe +rtems-run --rtems-bsps=erc32-sis build/sparc-rtems@rtems-ver-major@-erc32/hello.exe The output will be something close to: diff --git a/user/start/bsp-build.rst b/user/start/bsp-build.rst index 8401d71..585d009 100644 --- a/user/start/bsp-build.rst +++ b/user/start/bsp-build.rst @@ -99,16 +99,9 @@ If you have built a BSP with the RSB, you can move on to Manual BSP Build -We manually build the BSP in four steps. The first step is to create a build -directory. It must be separate from the RTEMS source directory. We use -:file:`$HOME/quick-start/build/b-erc32`. - -.. code-block:: none - -mkdir -p $HOME/quick-start/build/b-erc32 - -The second step is to set your path. Prepend the RTEMS tool suite binary -directory to your ``$PATH`` throughout the remaining steps. Run the command: +We manually build the BSP in four steps. The first step is to set your path. +Prepend the RTEMS tool suite binary directory to your ``$PATH`` throughout the +remaining steps. Run the command: .. code-block:: none @@ -133,7 +126,7 @@ has not been correctly set. Check the contents of the path file cannot be found return to :ref:`QuickStartTools` and install the tools again. -The first step is to configure the BSP. There are various BSP build +The second step is to configure the BSP. There are various BSP build configuration options available. Some options are BSP-specific. Each section in the INI-style configuration file ``config.ini`` instructs the build system to build a particular BSP variant (`sparc/erc32` in our case). We enable the build @@ -179,7 +172,7 @@ by ``$BASE``. Checking for program 'xz': $BASE/anaconda3/bin/xz 'configure' finished successfully (0.414s) -Building the BSP is the second step. +Building the BSP is the third step. .. code-block:: none -- 2.40.0 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
