Re: RTEMS Manuals: Single Page HTML version doesn't work
On 12/02/2020 00:11, Chris Johns wrote: > On 12/2/20 12:41 am, Christian Mauderer wrote: >> >> on docs.rtems.org we have a table with the manuals. There are three >> views: Online, PDF and Single Page. It seems that Online and PDF work >> fine. But Single Page doesn't work at all. Only a blank page is displayed. >> >> Should we fix it or remove it? > > If it is fixable I think we should. Amar added single page support when the > original shift from texinfo was done. I have kept it ever since. OK. I wasn't sure whether it is a remnant from an old or intermediate system or if it belongs to the current one. If it belongs to the current one we should definitively fix it. > >> I think I know where I could remove it. > > Are you referring to rtems-docs or rtems-admin (my personal repo)? I would have expected that the stuff on the table is generated with the common/coverpage/static/rtems/js/catalogue.js in rtems-docs. At least the table headers are there. > > Does rtems-docs build with --singlehtml for you? I had some troubles getting node.js inliner but now it builds. The single page HTML is created and installed just like expected. > >> But I have no idea where it should have been generated > > It is generated via a con job under my account on sync.rtems.org and copied > to a > spot on the ftp server where it is picked up by the docs.rtems.org jail and > installed. > > The build or generate line is ... > > https://git.rtems.org/chrisj/rtems-admin.git/tree/docs/builder/rtems-docs-build-branches#n135 Looks OK. There are some logs. Are they kept somewhere accessible? > > Note: > 1. The docs.rtems.org has no resources to perform a build OK. > 2. Using the ftp server avoids special keys etc with ssh to copy the files > from > sync to docs. Would be bad if it would be accessible without a key or simmilar. > >> and therefore I'm a bit lost how to fix it. > > Asking here is a good place to start. :) > > Chris > Best regards Christian -- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
AW: AW: [PATCH v3 2/3] amd64: Add to build
> -Ursprüngliche Nachricht-
> Von: Chris Johns [mailto:chr...@rtems.org]
> Gesendet: Mittwoch, 12. Februar 2020 00:36
> An: Sommer, Jan; sebastian.hu...@embedded-brains.de; devel@rtems.org
> Betreff: Re: AW: [PATCH v3 2/3] amd64: Add to build
>
> On 12/2/20 12:21 am, jan.som...@dlr.de wrote:
> >> Von: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de]
> >> Gesendet: Dienstag, 11. Februar 2020 13:22
> >> An: Sommer, Jan; devel@rtems.org
> >> Betreff: Re: [PATCH v3 2/3] amd64: Add to build
> >>> +includes += ['freebsd/sys/x86/include']
> >>> +if cpu == "x86_64":
> >>> +cpu = 'amd64'
> >>> includes += ['freebsd/sys/x86/include']
> >>> for i in config['cpu-include-paths']:
> >>> includes += [i.replace('@CPU@', cpu)]
> >> I am not sure what this should do. Here cpu x86_64 seems to be renamed
> >> to amd64? Should it be named amd64 in general?
> >
> > The problem is that the RTEMS_ARCH and the compiler prefix is x86_64,
> however in FreeBSD the related files are in amd64 subdirectories.
>
> Yes, this is fixed and cannot change. As Joel points out it is from the tools
> and we a long standing policy of following the tool names.
>
> > libbsd.py uses @CPU@ to create the architecture specific include directories
> which then yields sys/x86_64/include for example, but should create
> sys/amd64/include.
>
> Yes. The i386 has a hidden case as a hack in the generator code. It should
> also
> be removed and cleaned up, see below.
>
> > Before my last patch set, cpu was overridden to x86 for i386, so I thought
> doing something similar saves me the trouble with the include directories
> here.
> > Do you maybe have a more elegant solution?
>
> I think we need some form of path matching. I doubt this will be the only
> place
> we encounter something like this and it is not the first case.
>
> What about adding something that maps one path to another path? eg to
> libbsd.py
> add ...
>
> #
> # Map paths based on RTEMS naming to FreeBSD naming.
> #
> 'path-mappings' : [('freebsd/sys/i386/include', 'freebsd/sys/x64/include'),
> ('freebsd/sys/x86_64/include',
> 'freebsd/sys/amd64/include')]
>
I like the idea, but I also need to add an additional path for amd64 and i386.
It's the include path for header files which are shared among both of them,
e.g., freebsd/sys/x86/include.
Do you have a suggestion where a good place for this addition would be, if the
"if cpu == 'i386'" is to be removed?
> The mapping code can be added here ...
>
> https://git.rtems.org/rtems-libbsd/tree/waf_libbsd.py#n192
>
> ... and the special case of i386 removed. I would add a path_remap call so if
> this is needed in other places it can be added easily.
>
> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] drvmgr: Fix determination of prefix in grlib uart driver
From: Dennis Pfau
drvmgr_get_dev_prefix returns 0 if a prefix was found.
Therefore the if condition needs to check for 0, i.e. DRVMGR_OK.
---
bsps/shared/grlib/uart/apbuart_cons.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bsps/shared/grlib/uart/apbuart_cons.c
b/bsps/shared/grlib/uart/apbuart_cons.c
index ee635e6944..e4d026a4cc 100644
--- a/bsps/shared/grlib/uart/apbuart_cons.c
+++ b/bsps/shared/grlib/uart/apbuart_cons.c
@@ -321,7 +321,7 @@ int apbuart_init1(struct drvmgr_dev *dev)
priv->condev.fsname = NULL;
/* Get Filesystem name prefix */
prefix[0] = '\0';
- if (drvmgr_get_dev_prefix(dev, prefix)) {
+ if (drvmgr_get_dev_prefix(dev, prefix) == DRVMGR_OK) {
/* Got special prefix, this means we have a bus prefix
* And we should use our "bus minor"
*/
--
2.17.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 00/21] Support statically allocated threads
On 04/02/2020 11:35, Sebastian Huber wrote: Hello, any objects to push this patch set with the additional _Objects_Allocate_with_extend()? https://lists.rtems.org/pipermail/devel/2020-January/056724.html I will work on a documentation update afterwards. I checked in the patch set. The next step is to update the documentation. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Tool Roadmap for the RTEMS Pre-Qualification
On Tue, Feb 11, 2020 at 3:29 AM Sebastian Huber wrote: > > Hello, > > this email tries to give an overview of the tool roadmap for the RTEMS > pre-qualification activity and things to decide for the RTEMS Project. > > The tools used for the RTEMS pre-qualification will be command line > tools only. I would like to see an explicit intent for tools to work on specific command lines of our common development platforms. At least, they should work in Ubuntu LTS/Centos/SUSE/MacOS default shells (bash). Whether they need to work in Windows is debatable, I don't know any open-source RTEMS developers that work primarily in Windows. The command line there is a moving target--with the Linux subsystem, it is more or less possible to run any scripts that work in Ubuntu under Windows. It would be nice to define a path that works with Cygwin, simply from an open-source ecosystem perspective. > We will not use GUIs. New tools will be written in Python. The aim is to > reuse > and improve existing tools of the RTEMS Project. The tools will be > configured > via command line options and configuration files. The tool inputs will be > command line options, configuration files, source files, output from other > tools, and bug tracker databases. > > The tools fall roughly in three categories. Firstly, there will be > compiler-like tools which generate output files from input files. For > example, > one tool could generate document-specific glossaries from a project-wide > glossary. Secondly, there will be client/server tools. For example, > there could > be a tool which receives test programs, runs them on a target system and > sends > back the result. Thirdly, there will be builder tools. For example, the > creation of an RTEMS pre-qualification data package for a particular target > which can be handed over to an end user. > > === Important Decisions to Make === > > * Where to place the specification items? > > * What should be in the specification (master data set)? > > * Which content is generated? > > * Which generated content is version controlled? > > * How is the content generation integrated in the build system? > > * How is the Python development organized? > > === Repository Overview === > > We have currently four main repositories in the RTEMS Project: > > * rtems > > * rtems-tools > > * rtems-docs > > * rtems-source-builder (RSB) > > The RSB is a self-contained component and we will use it as is for the > pre-qualification activity. > > There are dependencies between the rtems, rtems-tools, and rtems-docs > repositories. Inconsistencies must be currently resolved manually > without any > tool support. > > For example, we have documentation of API functions in Doxygen and the > Classic API Guide: > > https://docs.rtems.org/doxygen/branches/master/group__ClassicTasks.html#gabffda1c2301962f0ae5af042ac0bba62 > > https://docs.rtems.org/branches/master/c-user/task_manager.html#task-create-create-a-task > > One goal of the pre-qualification activity is to introduce a master data set > (specification) and use tools to generate content in the right format > from it. > > For example, currently a human needs to edit > > https://git.rtems.org/rtems/tree/cpukit/include/rtems/rtems/tasks.h > > and > > https://git.rtems.org/rtems-docs/tree/c-user/task_manager.rst > > to declare and document the Classic Tasks API. This should be replaced by an > API specification which includes documentation elements and a generator tool > which produces the header file with Doxygen markup and the reST files > for the > Classic API Guide. Specifically for the pre-qualification activity, the API > specification can be used to also generate an interface specification > document > (Interface Control Document in ECSS terms). > > For the generated files, we have two options: > > 1. They are version controlled. Specification changes and the generated > changes > are sent for review to the mailing list and then checked in or not. This > means a normal user of the repository has no need to install the > generator > tools. Also in case the generator tools stop to work, we are back > to the > current situation (with a dead specification in the repository). > > 2. They are not version controlled and the build system generates them on > demand. > > === Location of the Specification === > > This seems to be a hot topic. The specification could be located in the > rtems, > the rtems-docs, or a separate repository. The new build system is based on > specification items which are located in the "spec/build" directory in the > RTEMS sources. It is desirable to not split up the specification. > > We could split up the specification and add specification items more > related to > the documentation to the rtems-docs repository. This may end up in > discussions > if a particular item goes into rtems or rtems-docs. I don't think this helps > and makes things easier. > > We could add a new repository which contains the specification and the othe
rtems-libbsd Build Error
Hi
I am trying to build rtems-libbsd for xilinx_zynq_a9_qemu using
tools and RTEMS built from their master branches. Both the
master and 5-freebsd-12 branch fail to build with this error:
In file included from ../../rtemsbsd/rtems/rtems-kernel-thread.c:56:0:
/home/joel/rtems-class/tools/5/bsp-install/arm-rtems5/xilinx_zynq_a9_qemu/lib/include/rtems/score/objectimpl.h:
In function '_Objects_Free':
/home/joel/rtems-class/tools/5/bsp-install/arm-rtems5/xilinx_zynq_a9_qemu/lib/include/rtems/score/objectimpl.h:937:17:
error: 'Objects_Information {aka struct Objects_Information}' has no member
named '_bsd_free'
( *information->free )( information, the_object );
I think the solution is that the structure member free needs to be renamed.
61357479 (Sebastian Huber 2019-12-16 14:50:59 +0100 213) void ( *free )(
Objects_Information *, Objects_Control * );
FWIW I was looking at the MISRA C/C++ rules earlier this week and this is a
violation of one of them. You should not have variables, methods, structure
members, etc that use the same name as standard library entiries.
--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] objectdata.h, objectimpl.h: Change structure member from free to deallocate
Without this change, rtems-libbsd does not compile. A macro turns
free into bsd_free.
Also the use of a standard library element as a program identifier
is a violation of a MISRA rule. Turns out that was a good rule. :)
---
cpukit/include/rtems/score/objectdata.h | 2 +-
cpukit/include/rtems/score/objectimpl.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/cpukit/include/rtems/score/objectdata.h
b/cpukit/include/rtems/score/objectdata.h
index 3d1a79c..56a1b8e 100644
--- a/cpukit/include/rtems/score/objectdata.h
+++ b/cpukit/include/rtems/score/objectdata.h
@@ -210,7 +210,7 @@ struct Objects_Information {
*
* @see _Objects_Free_static(), and _Objects_Free_unlimited().
*/
- void ( *free )( Objects_Information *, Objects_Control * );
+ void ( *deallocate )( Objects_Information *, Objects_Control * );
/**
* @brief This is the number of object control blocks on the inactive chain.
diff --git a/cpukit/include/rtems/score/objectimpl.h
b/cpukit/include/rtems/score/objectimpl.h
index 5ade0ed..c540f90 100644
--- a/cpukit/include/rtems/score/objectimpl.h
+++ b/cpukit/include/rtems/score/objectimpl.h
@@ -933,8 +933,8 @@ RTEMS_INLINE_ROUTINE void _Objects_Free(
)
{
_Assert( _Objects_Allocator_is_owner() );
- _Assert( information->free != NULL );
- ( *information->free )( information, the_object );
+ _Assert( information->deallocate != NULL );
+ ( *information->deallocate )( information, the_object );
}
/**
--
1.8.3.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS Manuals: Single Page HTML version doesn't work
On 12/2/20 7:25 pm, Christian Mauderer wrote: > On 12/02/2020 00:11, Chris Johns wrote: >> On 12/2/20 12:41 am, Christian Mauderer wrote: >>> >>> on docs.rtems.org we have a table with the manuals. There are three >>> views: Online, PDF and Single Page. It seems that Online and PDF work >>> fine. But Single Page doesn't work at all. Only a blank page is displayed. >>> >>> Should we fix it or remove it? >> >> If it is fixable I think we should. Amar added single page support when the >> original shift from texinfo was done. I have kept it ever since. > > OK. I wasn't sure whether it is a remnant from an old or intermediate > system or if it belongs to the current one. If it belongs to the current > one we should definitively fix it. It is useful if a user is deploying our documentation. I am not sure is something people building the docs normally do. >>> I think I know where I could remove it. >> >> Are you referring to rtems-docs or rtems-admin (my personal repo)? > > I would have expected that the stuff on the table is generated with the > common/coverpage/static/rtems/js/catalogue.js in rtems-docs. At least > the table headers are there. The version in the docs repo lets you have a suitable cover page for the HTML generated docs. If you install a build of the docs you get a nice cover page which is similar to the online site. The online site's RTEMS JS is .. https://git.rtems.org/chrisj/rtems-admin.git/tree/docs/docs.rtems.org/static/rtems/js The tables are generated out the XML catalog files. >> Does rtems-docs build with --singlehtml for you? > > I had some troubles getting node.js inliner but now it builds. I have found node.js problematic on Ubuntu 18.something. An openssl ABI change in dot version broke the packaging. I do not remember any issues on FreeBSD. > The > single page HTML is created and installed just like expected. Great. >>> But I have no idea where it should have been generated >> >> It is generated via a con job under my account on sync.rtems.org and copied >> to a >> spot on the ftp server where it is picked up by the docs.rtems.org jail and >> installed. >> >> The build or generate line is ... >> >> https://git.rtems.org/chrisj/rtems-admin.git/tree/docs/builder/rtems-docs-build-branches#n135 > > Looks OK. There are some logs. Are they kept somewhere accessible? No but this is a good idea. I should push the logs to the handover location on ftp.rtems.org so anyone wanting to help can see if a build has broken. It happens from time to time. The handover path is .. https://git.rtems.org/chrisj/rtems-admin.git/tree/docs/builder/rtems-docs-upload#n21 I am not sure when I will have time to add this feature. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS Manuals: Single Page HTML version doesn't work
On 2020-02-13 15:16 +1100, Chris Johns wrote: > It is useful if a user is deploying our documentation. I am not sure is > something people building the docs normally do. Yes it's actually the main method I've seen many use since it inlines all files including images so it's just 1 HTML file per manual we should really keep it. > I have found node.js problematic on Ubuntu 18.something. An openssl ABI change > in dot version broke the packaging. I do not remember any issues on FreeBSD. I've never had an issue on FreeBSD but a few on Linux I think those have been fixed now though this was some time back. OS X and Windows have been fine for me as well. Amar. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS Manuals: Single Page HTML version doesn't work
Hello Amar, On 13/02/2020 05:33, Amar Takhar wrote: > On 2020-02-13 15:16 +1100, Chris Johns wrote: > >> It is useful if a user is deploying our documentation. I am not sure is >> something people building the docs normally do. > > Yes it's actually the main method I've seen many use since it inlines all > files > including images so it's just 1 HTML file per manual we should really keep it. > Understood it. It still works when build locally so it shouldn't be a big problem fixing it. I just wasn't really aware of the single page version before and therefore I wasn't sure whether it should work or not. Just forget my question whether we should remove it. New question is: How do we fix it? > >> I have found node.js problematic on Ubuntu 18.something. An openssl ABI >> change >> in dot version broke the packaging. I do not remember any issues on FreeBSD. > > I've never had an issue on FreeBSD but a few on Linux I think those have been > fixed now though this was some time back. OS X and Windows have been fine > for > me as well. It was no big problem. Only that my distro (OpenSUSE) didn't deliver it packed as rpm. Best regards Christian > > > Amar. > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > -- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS Manuals: Single Page HTML version doesn't work
Hello Chris, On 13/02/2020 05:16, Chris Johns wrote: > On 12/2/20 7:25 pm, Christian Mauderer wrote: >> On 12/02/2020 00:11, Chris Johns wrote: >>> On 12/2/20 12:41 am, Christian Mauderer wrote: on docs.rtems.org we have a table with the manuals. There are three views: Online, PDF and Single Page. It seems that Online and PDF work fine. But Single Page doesn't work at all. Only a blank page is displayed. Should we fix it or remove it? >>> >>> If it is fixable I think we should. Amar added single page support when the >>> original shift from texinfo was done. I have kept it ever since. >> >> OK. I wasn't sure whether it is a remnant from an old or intermediate >> system or if it belongs to the current one. If it belongs to the current >> one we should definitively fix it. > > It is useful if a user is deploying our documentation. I am not sure is > something people building the docs normally do. > I think I know where I could remove it. >>> >>> Are you referring to rtems-docs or rtems-admin (my personal repo)? >> >> I would have expected that the stuff on the table is generated with the >> common/coverpage/static/rtems/js/catalogue.js in rtems-docs. At least >> the table headers are there. > > The version in the docs repo lets you have a suitable cover page for the HTML > generated docs. If you install a build of the docs you get a nice cover page > which is similar to the online site. The online site's RTEMS JS is .. > > https://git.rtems.org/chrisj/rtems-admin.git/tree/docs/docs.rtems.org/static/rtems/js > > The tables are generated out the XML catalog files. Ah OK. I wasn't aware that there are two cover pages. > >>> Does rtems-docs build with --singlehtml for you? >> >> I had some troubles getting node.js inliner but now it builds. > > I have found node.js problematic on Ubuntu 18.something. An openssl ABI change > in dot version broke the packaging. I do not remember any issues on FreeBSD. > Like said toward Amar: It wasn't a big problem. The package just isn't available as a rpm for OpenSUSE. >> The >> single page HTML is created and installed just like expected. > > Great. > But I have no idea where it should have been generated >>> >>> It is generated via a con job under my account on sync.rtems.org and copied >>> to a >>> spot on the ftp server where it is picked up by the docs.rtems.org jail and >>> installed. >>> >>> The build or generate line is ... >>> >>> https://git.rtems.org/chrisj/rtems-admin.git/tree/docs/builder/rtems-docs-build-branches#n135 >> >> Looks OK. There are some logs. Are they kept somewhere accessible? > > No but this is a good idea. I should push the logs to the handover location on > ftp.rtems.org so anyone wanting to help can see if a build has broken. It > happens from time to time. The handover path is .. > > https://git.rtems.org/chrisj/rtems-admin.git/tree/docs/builder/rtems-docs-upload#n21 > > I am not sure when I will have time to add this feature. > No problem. The other forms of the manual work fine so it's no time critical problem. Best regards Christian > Chris > -- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] objectdata.h, objectimpl.h: Change structure member from free to deallocate
On 13/02/2020 01:17, Joel Sherrill wrote: Without this change, rtems-libbsd does not compile. A macro turns free into bsd_free. Also the use of a standard library element as a program identifier is a violation of a MISRA rule. Turns out that was a good rule.:) Thanks, looks good. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v4] doc/raspberrypi: Added instructions for raspberrypi
Can someone take a look at this, It has been unnoticed for quite a while. Thank you, Niteesh On Sat, Jan 25, 2020 at 10:49 PM G S Niteesh wrote: > Added instructions to run examples on raspberrypi. > --- > user/bsps/arm/raspberrypi.rst | 111 +- > 1 file changed, 110 insertions(+), 1 deletion(-) > > diff --git a/user/bsps/arm/raspberrypi.rst b/user/bsps/arm/raspberrypi.rst > index 4ef75bd..72889a5 100644 > --- a/user/bsps/arm/raspberrypi.rst > +++ b/user/bsps/arm/raspberrypi.rst > @@ -5,4 +5,113 @@ > raspberrypi > === > > -TODO. > +This BSP supports `Raspberry Pi 1` and `Raspberry Pi 2` currently. > +The support for `Raspberry Pi 3` is work under progress. > +The default bootloader on the Raspberry Pi which is used to boot Raspbian > +or other OS can be also used to boot RTEMS. U-boot can also be used. > + > +Setup SD card > + > + > +The Raspberry Pis have an unconventional booting mechanism. The GPU > +boots first, initializes itself, runs the bootloader and starts the CPU. > +The bootloader looks for a kernel image, by default the kernel images must > +have a name of the form ``kernel*.img`` but this can be changed by adding > +`kernel=` to ``config.txt``. > + > +You must provide the required files for the GPU to proceed. These files > +can be downloaded from > +`the Raspberry Pi Firmware Repository < > https://github.com/raspberrypi/firmware/tree/master/boot>`_. > +You can remove the ``kernel*.img`` files if you want too, but don't touch > +the other files. > + > +Copy these files in to a SD card with FAT filesystem. > + > +Kernel image > + > + > +The following steps show how to run ``hello.exe`` on a Raspberry Pi 2. > +The same instructions can be applied to Raspberry Pi 1 also. > +Other executables can be processed in a similar way. > + > +To create the kernel image: > + > +.. code-block:: none > + > + $ arm-rtems5-objcopy -Obinary hello.exe kernel.img > + > +Copy the kernel image to the SD card. > + > +Make sure you have these lines below, in your ``config.txt``. > + > +.. code-block:: none > + > + enable-uart=1 > + kernel_address=0x20 > + kernel=kernel.img > + > +Testing using QEMU > +-- > + > +QEMU can be built using RSB. Navigate to ``/rtems`` > +and run this command. > + > +.. code-block:: none > + > + $ ../source-builder/sb-set-builder --prefix= > devel/qemu4.bset > + > +**Note**: Replace and with > the > +correct path of the directories. For example, if you used quick-start > section > +as your reference, these two will be ``$HOME/quick-start/src/rsb`` and > +``$HOME/quick-start/rtems/5`` respectively, > + > +QEMU along with GDB can be used for debugging, but it only supports > +Raspberry Pi 2 and the emulation is also incomplete. So some of the > +features might not work as expected. > + > +Make sure your version of QEMU is newer than v2.6, because older ones > don't > +support Raspberry Pis. > + > +.. code-block:: none > + > + $ qemu-system-arm -M raspi2 -m 1G -kernel hello.exe -serial > mon:stdio -nographic -S -s > + > +This starts QEMU and creates a socket at port ``localhost:1234`` for GDB > to > +connect. > + > +The Device Tree Blob (DTB) is needed to load the device tree while > starting up > +the kernel. The BSP uses information from this file to initialize the > drivers. > + > +Make sure you pass in the correct DTB file. There are currently two > version of > +DTB for the Raspberry Pi 2 ``bcm2709-rpi-2-b.dtb`` and > ``bcm2710-rpi-2-b.dtb``. > +The ``bcm2709-rpi-2-b.dtb`` is for Raspberry Pi 2 Model B and > +``bcm2710-rpi-2-b.dtb`` is for Raspberry Pi 2 Model B v1.2 > + > +We need to pass in the DTB file to GDB before running the example. > + > +In a new terminal, run GDB using > + > +.. code-block:: none > + > + $ arm-rtems5-gdb hello.exe > + > +This will open GDB and will load the symbol table from hello.exe. Issue > the > +following commands in the GDB prompt. > + > +.. code-block:: none > + > + (gdb) tar remote:1234 > + (gdb) load > + (gdb) restore bcm2709-rpi-2-b.dtb binary 0x2ef0 > + (gdb) set $r2 = 0x2ef0 > + > +This will connect GDB to QEMU and will load the DTB file and the > application. > + > +.. code-block:: none > + > + (gdb) continue > + > +The ``continue`` command will run the executable. > + > +**Note**: Add ``set scheduler-locking on`` in GDB if you have any issues > +running the examples. > -- > 2.17.1 > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS Manuals: Single Page HTML version doesn't work
On 2020-02-13 07:20 +0100, Christian Mauderer wrote: > Hello Amar, Hey! > Understood it. It still works when build locally so it shouldn't be a > big problem fixing it. I just wasn't really aware of the single page > version before and therefore I wasn't sure whether it should work or > not. Just forget my question whether we should remove it. New question > is: How do we fix it? I think only Chris can answer that one as the files are 0 bytes. > It was no big problem. Only that my distro (OpenSUSE) didn't deliver it > packed as rpm. Yea.. I know it's a pain but it's the best tool for the job I've used it everywhere and it hasn't broken even once outside of Node issues. Amar. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Tool Roadmap for the RTEMS Pre-Qualification
On 12/02/2020 17:19, Gedare Bloom wrote: On Tue, Feb 11, 2020 at 3:29 AM Sebastian Huber wrote: Hello, this email tries to give an overview of the tool roadmap for the RTEMS pre-qualification activity and things to decide for the RTEMS Project. The tools used for the RTEMS pre-qualification will be command line tools only. I would like to see an explicit intent for tools to work on specific command lines of our common development platforms. At least, they should work in Ubuntu LTS/Centos/SUSE/MacOS default shells (bash). Whether they need to work in Windows is debatable, I don't know any open-source RTEMS developers that work primarily in Windows. The command line there is a moving target--with the Linux subsystem, it is more or less possible to run any scripts that work in Ubuntu under Windows. It would be nice to define a path that works with Cygwin, simply from an open-source ecosystem perspective. Ok, my sentence was a bit unclear. What I meant is that the tools developed for the RTEMS pre-qualification will be command line tools only. For static analysis we may want to use Coverity for example. The formal methods stuff uses its own bunch of tools. I think we have to differentiate here a bit. It is clear that the tools used also for daily RTEMS development should run on all our usual development hosts. The generator tools which read the specification and output header and documentation sources are an example for this. These tools are really simple. Apart from needing a module to read YAML files, they will only use the standard Python library (maybe Python 3.6+). For the pre-qualification we may need also complex third-party tools or web services which are not available on all development hosts. For these tools it is important to evaluate the impact on the RTEMS Project. Tool reports could for example result in a series of patches. The patches should make sense for the RTEMS Project. It is important to document what was used. It is also important to make the complex tools optional and check their availability on the host. If it is not present, you get a warning and reduced functionality, but you should still be able to use the basic tools. [...] 2. We add a new empty rtems-qual repository. 2.1. In this repository we add a "spec" directory for the non-build specification items. 2.2. In this repository we add all the generator tools. 2.3. In this repository we add things closely related to pre-qualification. 2.4. In this repository we add Git submodules for the other RTEMS repositories touched by the generator tools. Changes in generated files in the standard RTEMS repositories go through the normal patch review process. 2.5. This repository may use a simplified review policy during the initial pre-qualification activity. Once the pre-qualification activity produced in a mature and usable infrastructure we can re-evaluate the repository organization and the location of the specification. This seems OK. Basically, you propose a "draft repository" for developing the products that hopefully can get integrated to the "4 main repositories" of RTEMS Project. It can also keep community burden and review off the critical path of the sponsored project's timeline. The risk is that the effort does not merge anything, but I think there is sufficient interest and motivation that the pieces of this that seem useful will migrate into the main repos. An organization like this also makes a lot of sense from a Packaging/Release standpoint. Will it be clear in the subrepos that certain source code should not be modified without first checking the HOWTOs and specifications? Or is this knowledge to be understood by the development community and enforced by the maintainers? In other words, what mechanisms will be in place to help us avoid "breaking" traceability/pre-qualification? Generated files will have a notice in the file header. However, who reads file headers if you want to change something in the middle? It will show up during patch review if something was not done properly provided the parties interested in the pre-qualification remain to be active. If not, then the normal bit rot will occur. If the stuff is difficult to use without a clear benefit, then it will also bit rot. It is our job to make it easy to use with clear benefits for the maintainers. === Python Development === The tool development in Python for the pre-qualification is a team work activity. Therefore we should introduce a coding standard, automatic code formatters (black, yapf), static analysis tools (mypy, pylint, flake8), documentation checkers (pydocstyle), and unit/integration tests (unittest and unittest.mock modules). The mentioned Python development tools are just examples. There use and configuration should be discussed on the RTEMS mailing list. If we place the specification along with corresponding tools into a separate repository we can use it to set up a p
Re: RTEMS Manuals: Single Page HTML version doesn't work
On 13/02/2020 07:51, Amar Takhar wrote: > On 2020-02-13 07:20 +0100, Christian Mauderer wrote: >> Hello Amar, > > Hey! > >> Understood it. It still works when build locally so it shouldn't be a >> big problem fixing it. I just wasn't really aware of the single page >> version before and therefore I wasn't sure whether it should work or >> not. Just forget my question whether we should remove it. New question >> is: How do we fix it? > > I think only Chris can answer that one as the files are 0 bytes. > Yes. He seems a bit busy now and it's no pressing matter. So let's just wait a bit. > >> It was no big problem. Only that my distro (OpenSUSE) didn't deliver it >> packed as rpm. > > Yea.. I know it's a pain but it's the best tool for the job I've used it > everywhere and it hasn't broken even once outside of Node issues. > No problem at all. I don't know of another tool for that and to be honest: I didn't know of that one before. So the tool is completely OK for me. I don't expect all packages pre-packed. It's just a bit simpler if they are. But except for very basic tools there will always be a distribution that doesn't have a package ready for it. Best regards Christian > > Amar. -- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
