Beagleboard BSP Framebuffer

[Vijay Kumar Banerjee]

Hello,

I was exploring beagle BSP related open projects that can possibly become a
GSoC
project. After an offlist discussion with Christian, he mentioned that
adding
the framebuffer driver for the BSP can be a very good project.

It would be great if any of the mentors want to mentor the project this
year,
would like to discuss this further and maybe work on this project for GSoC
19.

Thank you

--Vijay
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[Error]: error: Invalid rtems path

[Ravindra Kumar Meena]

Hi,

I am trying the tracing example
https://docs.rtems.org/branches/master/user/tracing/examples.html

It is returning an error at the following command

rtems-tld -C fileio-trace.ini -W fileio-wrapper --
-B/home/ravindra/development1/rtems/5/sparc-rtems5/erc32/lib/ -specs
bsp_specs -qrtems -mcpu=cypress -O2 -g -ffunction-sections -fdata-sections
-Wall -Wmissing-prototypes -Wimplicit-function-declaration
-Wstrict-prototypes -Wnested-externs -Wl,--gc-sections -mcpu=cypress -o
sparc-rtems5/c/erc32/testsuites/samples/fileio/fileio.exe
sparc-rtems5/c/erc32/testsuites/samples/fileio/fileio-init.o

*Error:* Invalid rtems path

How to resolve this issue?

Thanks

-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Beagleboard BSP Framebuffer

[Joel Sherrill]

On Sat, Mar 2, 2019, 4:55 AM Vijay Kumar Banerjee 
wrote:

> Hello,
>
> I was exploring beagle BSP related open projects that can possibly become
> a GSoC
> project. After an offlist discussion with Christian, he mentioned that
> adding
> the framebuffer driver for the BSP can be a very good project.
>
> It would be great if any of the mentors want to mentor the project this
> year,
> would like to discuss this further and maybe work on this project for GSoC
> 19.
>

I'm far from a graphics expert but would be willing to mentor this.
Hopefully someone with more graphics experience will also pop up.

For background research, see what documentation and BSD licensed code you
can find as examples. Also plan to use and likely update the graphics
packages in the RSB.

I don't if we have any good basic graphics tests without bringing in a
package. Might also be worth looking at a test that writes some basic
patterns.

And a mouse might be a good bonus if things go well.

A hello world for this would be running code on a beagle and figuring out
how to debug. There was a Qemu from somewhere (Linaro?) that simulated one
and ran RTEMS would help your development if it has the graphics simulated.

As you flesh this out, you will need tickets.

I think I just outlined a project. :)

--joel


> Thank you
>
> --Vijay
>
> ___
> 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

Update and Query regarding "mq_send: thread waiting: no preempt"

[Shashvat Jain]

Hello
Attached with this is a patch which adds some missing test names in the
/psxtmtests_plan.csv .

the test case "mq_send: thread waiting: no preempt" should be made under a
different test name or within psxtmmq01 ?

thank you
Regards
Shashvat
From a09a69690bbfb8956997285ec8da73de7b961681 Mon Sep 17 00:00:00 2001
From: Shashvat Jain 
Date: Sat, 2 Mar 2019 12:09:39 -0500
Subject: [PATCH] Update : psxtmtests_plan.csv

---
 testsuites/psxtmtests/psxtmtests_plan.csv | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/testsuites/psxtmtests/psxtmtests_plan.csv b/testsuites/psxtmtests/psxtmtests_plan.csv
index 5728f3d..4adb25c 100644
--- a/testsuites/psxtmtests/psxtmtests_plan.csv
+++ b/testsuites/psxtmtests/psxtmtests_plan.csv
@@ -130,11 +130,11 @@
 "mq_open: second open","psxtmmq01","psxtmtest_init_destroy","Yes"
 "mq_close: close of second","psxtmmq01","psxtmtest_init_destroy","Yes"
 "mq_unlink: only case","psxtmmq01","psxtmtest_init_destroy","Yes"
-"mq_receive: available",,"psxtmtest_single","Yes"
-"mq_receive: not available: block",,"psxtmtest_blocking","Yes"
+"mq_receive: available","psxtmmq01","psxtmtest_single","Yes"
+"mq_receive: not available: block","psxtmmqrcvblock01","psxtmtest_blocking","Yes"
 "mq_timedreceive: not available: blocks","psxtmmqrcvblock02","psxtmtest_blocking","Yes"
 "mq_timedreceive: not available: blocks",,"psxtmtest_single","No"
-"mq_send: no threads waiting",,"psxtmtest_single","Yes"
+"mq_send: no threads waiting","psxtmmq01","psxtmtest_single","Yes"
 "mq_send: thread waiting: no preempt",,"psxtmtest_unblocking_nopreempt","No"
 "mq_send: thread waiting: preempt",,"psxtmtest_unblocking_preempt","No"
 "mq_timedsend: no threads waiting",,"psxtmtest_single","Yes"
-- 
1.8.3.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Doxygen @return vs. @retval

[Gedare Bloom]

On Fri, Mar 1, 2019 at 4:57 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 28/02/2019 17:06, Joel Sherrill wrote:
> >
> >
> > On Thu, Feb 28, 2019 at 9:03 AM Sebastian Huber
> >  > > wrote:
> >
> > Hello,
> >
> > we agreed to use @retval instead of @return:
> >
> >
> https://docs.rtems.org/branches/master/eng/coding-doxygen.html#doxygen-best-practices
> >
> >
> > Is there going to be a global replacement or have they been purged?
>
> This has to be done step by step. First we need clear guidance.
>
> > How should we indicate that not a particular value is returned, but
> > instead an element of a set. For example:
> >
> > /**
> >   * @brief Performs something and returns the operation status.
> >   *
> >   * @retval 0 Successful operation.
> >   * @retval EIO Input/output error.
> >   * @retval  Any other value will not be returned.
> >   */
> > int f(void);
> >
> >
> > That last @retval doesn't match what I thought your statement above
> > indicated.
> > The English on the last @retval say there are no more. Why even
> > include that?
>
> To make it clear that nothing else is returned. Alternatively, we can
> globally state that functions only return the values documented,
> otherwise there is a documentation or code bug.
>
>
I prefer the global assumption that anything unspecified is not expected.

I would be OK with the convention of using "Otherwise" as a catch-all.


> What about function pointer typedefs where you specify some requirements
> on a particular implementation, e.g.
>
> /**
>   * @brief Write to flash operation.
>   *
>   * @param[in, out] self The flash control.
>   * @param[in] offset The offset to write from the flash begin in bytes.
>   * @param[in] buffer The buffer containing the data to write.
>   * @param[in] size_of_buffer The size of the buffer in bytes.
>   *
>   * @retval 0 Successful operation.
>   * @retval -EIO An error occurred.  Please note that the value is
> negative.
>   * @retval other All other values are reserved and must not be used.
>   */
> typedef int (*rtems_jffs2_flash_write)(
>rtems_jffs2_flash_control *self,
>uint32_t offset,
>const unsigned char *buffer,
>size_t size_of_buffer
> );
>
> >
> > If you mean other errno's may be returned, that's different.
> >
> > What about the -1 and errno cases?
>
> errno is a thread-local variable. You may document this in the @retval
> -1 text.
>
> >
> >
> > /**
> >   * @brief Creates an object.
> >   *
> >   * @retval NULL Not enough resources to create an object.
> >   * @retval  Pointer to created object.
> >   */
> > T *create(void);
> >
> > We may also use "[object]" or "{object}" or "object" or whatever.
> >
> >
> > Can we use "instance of T"?
>
> You cannot use spaces in "@retval value text" for the value.
>
>
@retval !NULL ...

It's a bit hideous, but correct.


>
> > I assume you used object generically. Wouldn't it be the specific noun
> > for the created object?
>
> My intent is to clarify which format we want to use for values which are
> no particular C constant, e.g "", "[value]", "{value}", "value",
> or whatever.
>
> Ahhh... I would avoid <> which may cause confusion if < x  or >y  are used
to indicate range limits on return values.  [] and {} seem fine to me, if
we really need to define something. I might also consider #value#.


> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] RSB: upgrade to sis 2.13 (was: Issue with sis and Leon3)

[Jiri Gaisler]

The attached patch for RSB solves the problem of output not being
flushed in gdb/sis and run/sis.  Note that I would discourage the use of
run as it cannot run the SMP tests. I have also experienced some random
hangs in rtems-test when using run, but never with sis.

Jiri.

On 3/1/19 4:53 PM, Joel Sherrill wrote:
> Thank you for being so responsive. 
>
> I suspected a missing flush but had no idea where to look. I hopedyou
> would spot the missing line of code quickly and was right. :)
>
> --joel
>
> On Thu, Feb 28, 2019 at 1:01 PM Jiri Gaisler  > wrote:
>
> I have found the problem, stdout is not flushed when the simulator
> stops and it has been invoked by gdb. The run command uses the gdb
> interface to call sis, so this is why it happens there too. I will
> make a new sis patch (2.13) with some additional (speed)
> improvements...
>
> Jiri.
>
diff --git a/rtems/config/tools/rtems-gdb-8.2.1-1.cfg b/rtems/config/tools/rtems-gdb-8.2.1-1.cfg
index 2473ee6..3e90826 100644
--- a/rtems/config/tools/rtems-gdb-8.2.1-1.cfg
+++ b/rtems/config/tools/rtems-gdb-8.2.1-1.cfg
@@ -18,4 +18,7 @@
 %patch add gdb https://devel.rtems.org/raw-attachment/ticket/3460/gdb-8.2.1-sis-2.12.patch
 %hash sha512 gdb-8.2.1-sis-2.12.patch ee321be58c4788580eb16f2e9c7329fddd6d9c22922f22f93a33aaa7ff97804cdf3539de835756109b99b4c975ec68880d438debebe22923c303b565fe2188da
 
+%patch add gdb https://gaisler.se/gdb/gdb-8.2.1-sis-2.13.patch
+%hash sha512 gdb-8.2.1-sis-2.13.patch 8239ef23240ef27f64e4deb2a81f91e6d189572fbfd4f5b26e525f2907413f8f09e643fa4ae793616feeeb5db1878a0caa5eea5c9c51ad946ad930adc46e4599
+
 %include %{_configdir}/gdb-8-1.cfg
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] user: correct the path to sb-set-builder

[Vaibhav Gupta]

Index 4.2 User Documentation, rtems query to specify the build set for
architecture, path to sb-set-builder
is: '$HOME/development/rtems/rsb/source-builder/sb-set-builder'

Mentioned command - '../source-builder/sb-set-builder --list-bsets' indicates
the path '$HOME/development/rtems/source-builder/sb-set-builder' , which is
unspecified.
---
 user/installation/developer.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/user/installation/developer.rst b/user/installation/developer.rst
index 541e04b..a903b58 100644
--- a/user/installation/developer.rst
+++ b/user/installation/developer.rst
@@ -92,7 +92,7 @@ build, just ask the tool:
 
 .. code-block:: none
 
-$ ../source-builder/sb-set-builder --list-bsets   <1>
+$ ./source-builder/sb-set-builder --list-bsets   <1>
 RTEMS Source Builder - Set Builder, v4.11.0
 Examining: config
 Examining: ../source-builder/config<2>
-- 
2.20.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] RSB: upgrade to sis 2.13 (was: Issue with sis and Leon3)

[Joel Sherrill]

Jiri.. can't you push this yourself? :)

FWIW The hash on rtems-tools needs a bump if it doesn't reflect the mailer
fix I committed.  Might as well have the next tools to catch both.


On Sat, Mar 2, 2019, 2:50 PM Jiri Gaisler  wrote:

> The attached patch for RSB solves the problem of output not being flushed
> in gdb/sis and run/sis.  Note that I would discourage the use of run as it
> cannot run the SMP tests. I have also experienced some random hangs in
> rtems-test when using run, but never with sis.
>
> Jiri.
> On 3/1/19 4:53 PM, Joel Sherrill wrote:
>
> Thank you for being so responsive.
>
> I suspected a missing flush but had no idea where to look. I hopedyou
> would spot the missing line of code quickly and was right. :)
>
> --joel
>
> On Thu, Feb 28, 2019 at 1:01 PM Jiri Gaisler  wrote:
>
>> I have found the problem, stdout is not flushed when the simulator stops
>> and it has been invoked by gdb. The run command uses the gdb interface to
>> call sis, so this is why it happens there too. I will make a new sis patch
>> (2.13) with some additional (speed) improvements...
>>
>> Jiri.
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel