Re: GSOC: Adding FDT infrastructure to RTEMS

2020-02-01 Thread Niteesh 
I am in the process of preparing my GSoC proposal and I would like to
discuss in more detail on implementation and necessary functions.

Assuming, a basic probe and attach functionality have been added, I guess
the
console-config could be changed to http://collabedit.com/adyh
f.
A similar driver could be written for arm pl011 also. We can then remove
the uart_probe
and just have console_select.
What all functions should be included other than ofw_get_reg and ofw_get_irq

Will these structures be enough for representing devices and drivers?

struct device {

const char *name;

const char *desc;

driver  *drv;

uint32_t  phandle;

}
>From my point of view, a device object should be a reference to a node in
the
device tree file and should have the selected driver referenced to it.

struct driver{

const char  *name;

device_methods*methods;
void*dev_context;

}
What are all the other required members? the dev_context will be used to
store
the device context. For example the structure representing the SPI bus
https://github.com/RTEMS/rtems/blob/9e4f21b927e8a81df8044806e88128388911e123/bsps/arm/imx/spi/imx-ecspi.c#L29
could be part of the dev_context.

This is my incomplete proposal.
https://docs.google.com/document/d/1gvGJSxrMtFtqFjbsmXW4OZsBq5lu7EVxs881G_Rohfs/edit


On Tue, Jan 21, 2020 at 2:13 PM Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> Hello Niteesh,
>
> great that you pick up that project.
>
> On 20/01/2020 18:38, Niteesh wrote:
> > This is what I have understood till now, please correct me if I am wrong
> > All this explanation is in context with FreeBSD.
>
> Note that this stuff in FreeBSD is quite universal and tend to be a bit
> more complex than would be absolutely necessary. I think a first
> implementation for RTEMS can be a lot simpler.
>
> > The drivers register themselves using* EARLY_DRIVER_MODULE*, this done
> with
> > the help of linker sets right?
>
> I'm not entirely sure whether it's linker set in FreeBSD but in libbsd
> we use linker sets for that.
>
> > Where all the data structures for the
> > drivers stored things like
> > compatible strings etc. Is it also in linkerset?
>
> In the simplest form (the one that would be the right target for a first
> draft) the strings are just written as constants in the driver source.
> For example take a look at freebsd/sys/arm/ti/am335x/am335x_usbss.c. The
> usbss_probe just has the following line:
>
> if (!ofw_bus_is_compatible(dev, "ti,am33xx-usb"))
> return (ENXIO);
>
> The relevant convenient function here is ofw_bus_is_compatible.
> Something like that would be great for RTEMS too.
>
> > At some point during initialization, the *ofwbus(fdtbus) *is
> > initialized, it is attached to some kind of
> > bus not sure which one, is it *nexus or newbus*? To which another
> > abstract bus called *simplebus *is
> > attached, all peripherals are then attached to this bus.
>
> Correct. FreeBSD uses a bus system for all hardware. It can have
> different connections and different order depending on the board. All of
> them are connected sooner or later to a Nexus. That's the first bus in
> the system.
>
> Don't go too deep into the different bus systems. I don't think that you
> would need more than one "bus" for the project. Maybe it's not even
> necessary to copy the bus structure but just use a similar interface
> instead.
>
> > I couldn't find anything called *fdtbus*, in the FreeBSD code, All I
> > could find was *ofwbus*, but all reference
> > talk only about *fdtbus*, am I missing something?
>
> The "open firmware bus" is the one that parses the FDT. That's the
> relevant one for you. I'm not sure where the term "fdtbus" comes from.
> Maybe it's an old one?
>
> > After *simplebus* init is done, the *ofwbus_attach(ofwbus.c:137) *goes
> > through all nodes and attaches
> > them to *simplebus*.
> OK.
>
> > But I am really sure of what happens after, it
> > would be really helpful if someone could
> > explain it or at least provide some resources.
>
> Basically the FreeBSD bus systems provide an abstracted view to
> information about the devices. Each bus loops through the connected
> devices (for ofwbus this means looping through all active nodes in the
> fdt).
>
> For each device the probe of all (relevant) drivers is called to check
> whether the driver want's to drive the device. If it wants the device
> and no better driver is found (depends on the return value of probe) the
> attach of the driver will be called. From there it's more or less the
> responsibility of the driver what it want's to do.
>
> The driver can ask the bus systems for resources like interrupts, pins
> or memory. The bus will then look up the resource in it's information
> source - for the ofwbus it will look in the fdt - and return the
> resource. That stuff is done with "bus_alloc_resource_any" functions and
> similar.
>
> >
> > The resources

Re: Ticket #3515

2020-02-01 Thread Vijay Kumar Banerjee 
On Sat, Feb 1, 2020 at 9:31 PM Bran S  wrote:

> On Sat, 1 Feb 2020 at 18:44, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
> >
> > On Sat, Feb 1, 2020 at 12:57 PM Bran S  wrote:
> >>
> >> On Thu, 30 Jan 2020 at 05:52, Chris Johns  wrote:
> >> >
> >> > On 29/1/20 7:03 pm, Bran S wrote:
> >> > > Hi Guys,
> >> > >
> >> > > I am trying to solve #3515
> >> > > https://devel.rtems.org/ticket/3515 <
> https://devel.rtems.org/ticket/3515>
> >> >
> >> > Nice and thanks.
> >> >
> >> > > For this issue covoar is required.
> >> > >
> >> > > So I cloned https://git.rtems.org/rtems-tools/ <
> https://git.rtems.org/rtems-tools/>
> >> > > This is my directory structure:
> >> > > $HOME/quick-start/src/rtems - Main RTEMS repo
> >> > > $HOME/quick-start/src/rsb - Source Builder
> >> > > $HOME/quick-start/src/rtems-tools - The one that I have recently
> cloned
> >> > >
> >> > > But running `rtems-test --list-bsps` inside
> '$HOME/quick-start/src/rtems-tools'
> >> > > gives "error: RTEMS Toolkit python wrapper not found, plrease
> report"
> >> > >
> >> > > Any ideas on how to resolve this error ?
> >> >
> >> > What does `type rtems-test` say?
> >> >
> >> > Have you built a set of sparc tools?
> >> > Have you build the leon3 BSP and all the tests?
> >> >
> >> > I am not sure what happens if the `rtems-test` is run in the source
> tree while
> >> > picking up a version from your path. Maybe `./tester/rtems-test ...`
> works?
> >>
> > Hi Bran,
> >
> > Thanks for taking up this ticket.
> >>
> >> It is now working my $PATH was wrongly set with rtems/4.11 instead of
> rtems/5.
> >> I have corrected it. It now contains '$HOME/quick-start/rtems/5/bin'
> >>
> > Nice.
> >>
> >> Moving on to the next problem:
> >>
> https://devel.rtems.org/wiki/GCI/Documentation/CoverageAnalysis/Coverage#RunningRTEMS-TESTERforCoverageanalysis
> >> I was reading this to know more about covoar.
> >> So as mentioned above I ran
> >>
> >> `rtems-test --rtems-tools=/home/user45/quick-start/rtems/5/
> >> --log=coverage_analysis.log --no-clean --coverage=score
> >> --rtems-bsp=leon3-qemu-cov
> >>
> /home/user45/quick-start/build/b-leon3/sparc-rtems5/c/leon3/testsuites/samples/hello.exe`
> >>
> >> And the output was: https://paste.debian.net/1128608/
> >> `qemu-system-sparc` not being installed seems to be the cause for the
> error.
> >>
> >> So I followed suggestion found here:
> >> https://lists.rtems.org/pipermail/users/2018-January/065583.html
> >> Ran the commands as:
> >>
> >> $ cd /quick-start/src/rsb/rtems/
> >> The rsb directory contains rtems source builder.
> >>
> >> $ ../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/5
> >> devel/qemu.bset
> >>
> > You need devel/qemu-couverture.bset but while trying to build it, I see
> the same error
> > as you see with qemu.bset
> >>
> >> Running this further gives errors and reports it into
> >> 'rsb-report-glib-2.39.3-x86_64-linux-gnu-1.txt'
> >> Full output of above command is at: https://paste.debian.net/1128609/
> >>
> >> The content of 'rsb-report-glib-2.39.3-x86_64-linux-gnu-1.txt' is
> >> here: https://paste.debian.net/1128610/
> >>
> >> In file 'rsb-report-glib-2.39.3-x86_64-linux-gnu-1.txt' (at
> >> https://paste.debian.net/1128610/) the first error occurs at line 385,
> >> which is:
> >>
> >> ../../glib-2.39.3/glib/gdate.c:2497:7: error: format not a string
> >> literal, format string not checked [-Werror=format-nonliteral]
> >>tmplen = strftime (tmpbuf, tmpbufsize, locale_format, );
> >>^~
> >>   CC   libglib_2_0_la-gdir.lo
> >>   CC   libglib_2_0_la-genviron.lo
> >> cc1: some warnings being treated as errors
> >> Makefile:1782: recipe for target 'libglib_2_0_la-gdate.lo' failed
> >> make[4]: *** [libglib_2_0_la-gdate.lo] Error 1
> >>
> >> This happens to be a known error/bug (Ref:
> >> https://bugs.freedesktop.org/show_bug.cgi?id=95326)
> >> and a patch is available for it here:
> >>
> https://gitlab.gnome.org/GNOME/glib/commit/8cdbc7fb2c8c876902e457abe46ee18a0b134486
> >>
> >> Following the patch I manually made changes into
> >>
> '$HOME/quick-start/src/rsb/rtems/build/glib-2.39.3-x86_64-linux-gnu-1/glib-2.39.3/glib/gdate.c'
> >>
> >> But the problem is that as soon as I run
> >> `../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/5
> >> devel/qemu.bset`
> >> My manual changes to the gdate.c disappear and I get the same error as
> >> before. I don't know what is going on.
> >>
> > I applied the patch that you found along with another patch and built
> the souces, glib built
> > successfully, but unfortunately the couverture-qemu itself failed to
> build. Here's the log:
> > https://paste.ofcode.org/KmJCNZrJyQNev6R4FSUafe
> >
> > Here I'm pasting the diff to add patches to RSB:
> > ```
> > diff --git a/bare/config/devel/glib-2.39.3-1.cfg
> b/bare/config/devel/glib-2.39.3-1.cfg
> > index d86fe28..0bada15 100644
> > --- a/bare/config/devel/glib-2.39.3-1.cfg
> > +++ b/bare/config/devel/glib-2.39.3-1.cfg
> > @@ -14,6 +14,10 @@
> >
>

Re: RTEMS FS locking

2020-02-01 Thread Sebastian Huber 
Hello Charles,

- Am 30. Jan 2020 um 23:51 schrieb Charles Manning cdhmann...@gmail.com:

> Hi All
> 
> I'm the Yaffs Guy and have been asked to do some work refreshing the
> Yaffs core code that is in Sebastian's rtems-yaffs git as well as
> integrate it into the Yaffs tests.

do you intend to do a clean room re-implementation of the RTEMS YAFFS2 support 
under the YAFFS2 dual licensing conditions?

> 
> After a few false starts I now have an understanding of how to build a
> simulation test environment based on the quickstart guide - thanks to
> those that helped me.
> 
> When going through Sebastian's wrapper I noticed that some functions
> are locked with the yaffs lock and some are not. At first I thought
> that might be a locking bug, but then I noticed that some higher level
> functions call rtems_filesystem_instance_lock() and some do not.
> rtems_filesystem_instance_lock() results in the yaffs lock being
> taken, so that is all good.
> 
> Can someone please explain the rationale for when
> rtems_filesystem_instance_lock is used and when not?

The RTEMS file system layer is a home grown solution which evolved over time. 
Originally, it had no locking. Some years ago I introduced a new path 
evaluation scheme which uses a global file system instance lock. All current 
RTEMS file systems re-use this lock for other operations. In theory, operations 
which work on file system nodes (rtems_filesystem_file_handlers_r) could use 
finer grained locking. There is no high level documentation available. It would 
be good to document the locking in the Doxygen documentation:

https://docs.rtems.org/doxygen/branches/master/group__LibIOFSHandler.html

The YAFFS2 and JFFS2 code are good examples.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Ticket #3515

2020-02-01 Thread Bran S 
On Sat, 1 Feb 2020 at 18:44, Vijay Kumar Banerjee 
wrote:
>
> On Sat, Feb 1, 2020 at 12:57 PM Bran S  wrote:
>>
>> On Thu, 30 Jan 2020 at 05:52, Chris Johns  wrote:
>> >
>> > On 29/1/20 7:03 pm, Bran S wrote:
>> > > Hi Guys,
>> > >
>> > > I am trying to solve #3515
>> > > https://devel.rtems.org/ticket/3515 <
https://devel.rtems.org/ticket/3515>
>> >
>> > Nice and thanks.
>> >
>> > > For this issue covoar is required.
>> > >
>> > > So I cloned https://git.rtems.org/rtems-tools/ <
https://git.rtems.org/rtems-tools/>
>> > > This is my directory structure:
>> > > $HOME/quick-start/src/rtems - Main RTEMS repo
>> > > $HOME/quick-start/src/rsb - Source Builder
>> > > $HOME/quick-start/src/rtems-tools - The one that I have recently
cloned
>> > >
>> > > But running `rtems-test --list-bsps` inside
'$HOME/quick-start/src/rtems-tools'
>> > > gives "error: RTEMS Toolkit python wrapper not found, plrease report"
>> > >
>> > > Any ideas on how to resolve this error ?
>> >
>> > What does `type rtems-test` say?
>> >
>> > Have you built a set of sparc tools?
>> > Have you build the leon3 BSP and all the tests?
>> >
>> > I am not sure what happens if the `rtems-test` is run in the source
tree while
>> > picking up a version from your path. Maybe `./tester/rtems-test ...`
works?
>>
> Hi Bran,
>
> Thanks for taking up this ticket.
>>
>> It is now working my $PATH was wrongly set with rtems/4.11 instead of
rtems/5.
>> I have corrected it. It now contains '$HOME/quick-start/rtems/5/bin'
>>
> Nice.
>>
>> Moving on to the next problem:
>>
https://devel.rtems.org/wiki/GCI/Documentation/CoverageAnalysis/Coverage#RunningRTEMS-TESTERforCoverageanalysis
>> I was reading this to know more about covoar.
>> So as mentioned above I ran
>>
>> `rtems-test --rtems-tools=/home/user45/quick-start/rtems/5/
>> --log=coverage_analysis.log --no-clean --coverage=score
>> --rtems-bsp=leon3-qemu-cov
>>
/home/user45/quick-start/build/b-leon3/sparc-rtems5/c/leon3/testsuites/samples/hello.exe`
>>
>> And the output was: https://paste.debian.net/1128608/
>> `qemu-system-sparc` not being installed seems to be the cause for the
error.
>>
>> So I followed suggestion found here:
>> https://lists.rtems.org/pipermail/users/2018-January/065583.html
>> Ran the commands as:
>>
>> $ cd /quick-start/src/rsb/rtems/
>> The rsb directory contains rtems source builder.
>>
>> $ ../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/5
>> devel/qemu.bset
>>
> You need devel/qemu-couverture.bset but while trying to build it, I see
the same error
> as you see with qemu.bset
>>
>> Running this further gives errors and reports it into
>> 'rsb-report-glib-2.39.3-x86_64-linux-gnu-1.txt'
>> Full output of above command is at: https://paste.debian.net/1128609/
>>
>> The content of 'rsb-report-glib-2.39.3-x86_64-linux-gnu-1.txt' is
>> here: https://paste.debian.net/1128610/
>>
>> In file 'rsb-report-glib-2.39.3-x86_64-linux-gnu-1.txt' (at
>> https://paste.debian.net/1128610/) the first error occurs at line 385,
>> which is:
>>
>> ../../glib-2.39.3/glib/gdate.c:2497:7: error: format not a string
>> literal, format string not checked [-Werror=format-nonliteral]
>>tmplen = strftime (tmpbuf, tmpbufsize, locale_format, );
>>^~
>>   CC   libglib_2_0_la-gdir.lo
>>   CC   libglib_2_0_la-genviron.lo
>> cc1: some warnings being treated as errors
>> Makefile:1782: recipe for target 'libglib_2_0_la-gdate.lo' failed
>> make[4]: *** [libglib_2_0_la-gdate.lo] Error 1
>>
>> This happens to be a known error/bug (Ref:
>> https://bugs.freedesktop.org/show_bug.cgi?id=95326)
>> and a patch is available for it here:
>>
https://gitlab.gnome.org/GNOME/glib/commit/8cdbc7fb2c8c876902e457abe46ee18a0b134486
>>
>> Following the patch I manually made changes into
>>
'$HOME/quick-start/src/rsb/rtems/build/glib-2.39.3-x86_64-linux-gnu-1/glib-2.39.3/glib/gdate.c'
>>
>> But the problem is that as soon as I run
>> `../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/5
>> devel/qemu.bset`
>> My manual changes to the gdate.c disappear and I get the same error as
>> before. I don't know what is going on.
>>
> I applied the patch that you found along with another patch and built the
souces, glib built
> successfully, but unfortunately the couverture-qemu itself failed to
build. Here's the log:
> https://paste.ofcode.org/KmJCNZrJyQNev6R4FSUafe
>
> Here I'm pasting the diff to add patches to RSB:
> ```
> diff --git a/bare/config/devel/glib-2.39.3-1.cfg
b/bare/config/devel/glib-2.39.3-1.cfg
> index d86fe28..0bada15 100644
> --- a/bare/config/devel/glib-2.39.3-1.cfg
> +++ b/bare/config/devel/glib-2.39.3-1.cfg
> @@ -14,6 +14,10 @@
>
>  %hash sha256 glib-%{glib_version}.tar.xz
d9fa6c9aa645a5e688a3bb29013bb83801b19ee767d99e33ff52e004e1cc5fc8
>
> +#Patch to supress string literal warning
> +
> +%patch add glib
https://gitlab.gnome.org/GNOME/glib/commit/0817af40e8c74c721c30f6ef482b1f53d12044c7.patch
> +%patch add glib

[rtems-docs PATCH] user/testing: Add coverage analysis instructions

2020-02-01 Thread Vijay Kumar Banerjee 
---
 user/testing/coverage.rst | 68 +++
 user/testing/index.rst|  1 +
 2 files changed, 69 insertions(+)
 create mode 100644 user/testing/coverage.rst

diff --git a/user/testing/coverage.rst b/user/testing/coverage.rst
new file mode 100644
index 000..2994c62
--- /dev/null
+++ b/user/testing/coverage.rst
@@ -0,0 +1,68 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 2019 Vijay Kumar Banerjee 
+
+Coverage Analysis
+=
+
+RTEMS is used in many critical systems. It is important that the RTEMS Project
+ensure that the RTEMS product is tested as thoroughly as possible. With this
+goal in mind, the RTEMS test suite was expanded so that 100% of the RTEMS
+executive is tested.
+
+RTEMS-TESTER takes the following arguments to produce coverage reoprt:
+
+`--coverage :`
+When the coverage option is enabled the tester produces coverage reports 
for
+all the symbols in cpukit. To generate coverage report for a specific
+symbol-set ( eg.: score) the symbol-set is passed as an argument to the
+option. eg.: --coverage=score.
+
+`--no-clean :`
+Tells the script not to delete the .cov trace files generated while running
+the coverage. These Trace files are used for debugging purposes and will 
not
+be needed for a normal user.
+
+For example: To generate coverage report of hello.exe for leon3 on SIS, the
+following command will be used:
+
+.. code-block:: none
+
+rtems-test \
+--rtems-tools=$HOME/development/rtems/5 \
+--log=coverage_analysis.log \
+--no-clean \
+--coverage \
+--rtems-bsp=leon3-sis-cov \
+
$HOME/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/hello.exe
+
+The command will create the coverage report in the following tree structure:
+
+.. code-block:: none
+
+├── coverage_analysis.log
+├── leon3-sis-coverage
+│   └── score
+│   ├── annotated.html
+│   ├── annotated.txt
+│   ├── branch.html
+│   ├── branch.txt
+│   ├── covoar.css
+│   ├── ExplanationsNotFound.txt
+│   ├── index.html
+│   ├── no_range_uncovered.html
+│   ├── no_range_uncovered.txt
+│   ├── NotReferenced.html
+│   ├── sizes.html
+│   ├── sizes.txt
+│   ├── summary.txt
+│   ├── symbolSummary.html
+│   ├── symbolSummary.txt
+│   ├── table.js
+│   ├── uncovered.html
+│   └── uncovered.txt
+└── leon3-sis-report.html
+
+The html on top of the directory, i.e., leon3-sis-report.html is the top level
+navigation for the coverage analysis report and will let the user browse 
through
+all the generated reports from different subsystems.
diff --git a/user/testing/index.rst b/user/testing/index.rst
index a938af4..3d36fab 100644
--- a/user/testing/index.rst
+++ b/user/testing/index.rst
@@ -43,6 +43,7 @@ extension.
 
tests
configuration
+   coverage
consoles
simulation
gdb-jtag
-- 
2.21.1

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

Re: [PATCH 6/7] bsps: Remove uses of BSP_GET_WORK_AREA_DEBUG

2020-02-01 Thread Sebastian Huber 
- Am 20. Jan 2020 um 6:01 schrieb Chris Johns chr...@rtems.org:

> On 17/12/19 4:57 pm, Sebastian Huber wrote:
>> My experience tells me that doing a BSP development without a debugger is a
>> waste of time.
> 
> Sometimes getting a working debugger is more effort than getting a BSP to 
> work.
> The Pi is an example. I believe Alan used print statements.

Ok, what do you think about a new configuration option:

CONFIGURE_ENABLE_VERBOSE_INITIALIZATION

This configuration option could enable a bunch of system initialization 
handlers which print (via printk()) some information for each of the 
RTEMS_SYSINIT_* steps.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Linker sets alignment change

2020-02-01 Thread Sebastian Huber 
Hello Jeff,

- Am 14. Jan 2020 um 17:37 schrieb Jeff Kubascik 
jeff.kubas...@dornerworks.com:

> Hello,
> 
> I have noticed a change in the linker section ".rtemsrwset" alignment which 
> has
> affected the zImage header that was added with the arm/xen BSP. The zImage
> header uses the bsp_section_data_end symbol to determine the end of the 
> image. I
> was able to track this change to the commit 234d155e linkersets: Revert to
> zero-length arrays.
> 
> Here is the readelf output of the ticker.exe application just prior before
> commit
> 
> Section Headers:
>  [Nr] Name  TypeAddr OffSize   ES Flg Lk Inf 
> Al
>  [15] .rtemsstack   NOBITS  4010 01358c 001000 00  WA  0   0 
> 64
>  [16] .data PROGBITS40101000 101000 0004e0 00  WA  0   0  
> 8
>  [17] .rtemsrwset   PROGBITS401014e0 1014e0 00 00  0   0  
> 1
> 
> Here is the output with the commit
> 
> Section Headers:
>  [Nr] Name  TypeAddr OffSize   ES Flg Lk Inf 
> Al
>  [15] .rtemsstack   NOBITS  4010 01358c 001000 00  WA  0   0 
> 64
>  [16] .data PROGBITS40101000 101000 0004e0 00  WA  0   0  
> 8
>  [17] .rtemsrwset   PROGBITS40101500 101500 00 00  WA  0   0 
> 64
> 
> This shows that the alignment of the ".rtemsrwset" section changed from 1 byte
> to 64 bytes. This changes the start address of the section to be aligned, even
> though the section is empty.
> 
> The bsp_section_data_end symbol is located at the end of the ".rtemsrwset"
> section. If the section is empty, the bsp_section_data_end symbol will contain
> the start address of the section.
> 
> .data : ALIGN_WITH_INPUT {
>   bsp_section_data_begin = .;
>   *(.data .data.* .gnu.linkonce.d.*)
>   SORT(CONSTRUCTORS)
> } > REGION_DATA AT > REGION_DATA_LOAD
> .data1 : ALIGN_WITH_INPUT {
>   *(.data1)
> } > REGION_DATA AT > REGION_DATA_LOAD
> .rtemsrwset : ALIGN_WITH_INPUT {
>   KEEP (*(SORT(.rtemsrwset.*)))
>   bsp_section_data_end = .;
> } > REGION_DATA AT > REGION_DATA_LOAD
> 
> When I convert the ticker.exe elf to a binary with objcopy, the binary doesn't
> include the ".rtemsrwset" section, since it's empty. As a result, the length 
> of
> the binary doesn't match the bsp_section_data_end symbol. This is a problem 
> for
> some zImage loaders that verify the image length.
> 
> I'm not certain what would be the best way to fix the zImage header. Is there 
> a
> different symbol that I should be using to get the end of the image? Maybe 
> this
> is a bug with the linker script?

there is no bug in the linker script. In wkspace.c there is this linker set 
declared:

RTEMS_LINKER_RWSET(
  _Per_CPU_Data,
  RTEMS_ALIGNED( CPU_CACHE_LINE_BYTES ) char
);

So, the .rtemsrwset contains an empty _Per_CPU_Data set which is properly 
aligned.

In uniprocessor configuration, the cache alignment is superfluous. I will fix 
this.

Why don't you use the file size of your binary created by objcopy to set the 
image size?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] termios: Fix input canonical mode

2020-02-01 Thread Sebastian Huber 


-- 
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.
From 408f11252d29c72a00bb85adeebe4f41f855d398 Mon Sep 17 00:00:00 2001
From: Sebastian Huber 
Date: Wed, 29 Jan 2020 09:32:05 +0100
Subject: [PATCH] termios: Fix input canonical mode

Canonical input processing was broken by
667501a314ba75f80f1c13c6b43dd35d0a00efd1 as shown by test case
termios09.

Update #3800.
---
 cpukit/libcsupport/src/termios.c | 83 
 1 file changed, 33 insertions(+), 50 deletions(-)

diff --git a/cpukit/libcsupport/src/termios.c b/cpukit/libcsupport/src/termios.c
index fedaa80ba0..b10a4ad774 100644
--- a/cpukit/libcsupport/src/termios.c
+++ b/cpukit/libcsupport/src/termios.c
@@ -1337,23 +1337,16 @@ rtems_status_code rtems_termios_register_isig_handler(
 
 /**
  * @brief Type returned by all input processing (iproc) methods
- */ 
+ */
 typedef enum {
   /**
-   * This indicates that the input character was processed
-   * and the results were placed into the buffer.
-   */
-  RTEMS_TERMIOS_IPROC_IN_BUFFER,
-  /**
-   * This indicates that the input character was processed
-   * and the result did not go into the buffer.
+   * This indicates that the input processing can continue.
*/
-  RTEMS_TERMIOS_IPROC_WAS_PROCESSED,
+  RTEMS_TERMIOS_IPROC_CONTINUE,
   /**
-   * This indicates that the input character was not processed and
-   * subsequent processing is required.
+   * This indicates that the input processing is done.
*/
-  RTEMS_TERMIOS_IPROC_WAS_NOT_PROCESSED,
+  RTEMS_TERMIOS_IPROC_DONE,
   /**
* This indicates that the character was processed and determined
* to be one that requires a signal to be raised (e.g. VINTR or
@@ -1361,7 +1354,7 @@ typedef enum {
* occur. There is no further processing of this character required and
* the pending read() operation should be interrupted.
*/
-  RTEMS_TERMIOS_IPROC_INTERRUPT_READ
+  RTEMS_TERMIOS_IPROC_INTERRUPT
 } rtems_termios_iproc_status_code;
 
 /*
@@ -1379,12 +1372,10 @@ iproc (unsigned char c, struct rtems_termios_tty *tty)
   rtems_termios_isig_status_code rc;
   rc = (*termios_isig_handler)(c, tty);
   if (rc == RTEMS_TERMIOS_ISIG_INTERRUPT_READ) {
- return RTEMS_TERMIOS_IPROC_INTERRUPT_READ;
-  }
-  if (rc == RTEMS_TERMIOS_ISIG_WAS_PROCESSED) {
- return RTEMS_TERMIOS_IPROC_IN_BUFFER;
+ return RTEMS_TERMIOS_IPROC_INTERRUPT;
   }
-  _Assert(rc == RTEMS_TERMIOS_ISIG_WAS_NOT_PROCESSED);
+
+  return RTEMS_TERMIOS_IPROC_CONTINUE;
 }
   }
 
@@ -1394,25 +1385,25 @@ iproc (unsigned char c, struct rtems_termios_tty *tty)
   if ((c != '\0') && (tty->termios.c_lflag & ICANON)) {
 if (c == tty->termios.c_cc[VERASE]) {
   erase (tty, 0);
-  return RTEMS_TERMIOS_IPROC_WAS_PROCESSED;
+  return RTEMS_TERMIOS_IPROC_CONTINUE;
 }
 else if (c == tty->termios.c_cc[VKILL]) {
   erase (tty, 1);
-  return RTEMS_TERMIOS_IPROC_WAS_PROCESSED;
+  return RTEMS_TERMIOS_IPROC_CONTINUE;
 }
 else if (c == tty->termios.c_cc[VEOF]) {
-  return RTEMS_TERMIOS_IPROC_IN_BUFFER;
+  return RTEMS_TERMIOS_IPROC_DONE;
 } else if (c == '\n') {
   if (tty->termios.c_lflag & (ECHO | ECHONL))
 echo (c, tty);
   tty->cbuf[tty->ccount++] = c;
-  return RTEMS_TERMIOS_IPROC_IN_BUFFER;
+  return RTEMS_TERMIOS_IPROC_DONE;
 } else if ((c == tty->termios.c_cc[VEOL]) ||
(c == tty->termios.c_cc[VEOL2])) {
   if (tty->termios.c_lflag & ECHO)
 echo (c, tty);
   tty->cbuf[tty->ccount++] = c;
-  return RTEMS_TERMIOS_IPROC_IN_BUFFER;
+  return RTEMS_TERMIOS_IPROC_DONE;
 }
   }
 
@@ -1425,9 +1416,8 @@ iproc (unsigned char c, struct rtems_termios_tty *tty)
 if (tty->termios.c_lflag & ECHO)
   echo (c, tty);
 tty->cbuf[tty->ccount++] = c;
-return RTEMS_TERMIOS_IPROC_IN_BUFFER;
   }
-  return RTEMS_TERMIOS_IPROC_WAS_NOT_PROCESSED;
+  return RTEMS_TERMIOS_IPROC_CONTINUE;
 }
 
 /*
@@ -1456,7 +1446,7 @@ static rtems_termios_iproc_status_code
 siprocPoll (unsigned char c, rtems_termios_tty *tty)
 {
   if (c == '\r' && (tty->termios.c_iflag & IGNCR) != 0) {
-return RTEMS_TERMIOS_IPROC_WAS_NOT_PROCESSED;
+return RTEMS_TERMIOS_IPROC_CONTINUE;
   }
 
   /*
@@ -1476,7 +1466,6 @@ fillBufferPoll (struct rtems_termios_tty *tty)
 {
   int n;
   rtems_termios_iproc_status_code rc;
-  rtems_termios_iproc_status_code retval = RTEMS_TERMIOS_IPROC_WAS_PROCESSED;
 
   if (tty->termios.c_lflag & ICANON) {
 for (;;) {
@@ -1485,12 +1474,8 @@ fillBufferPoll (struct rtems_termios_tty *tty)
 rtems_task_wake_after (1);
   } else {
 rc = siprocPoll (n, tty);
-if (rc ==

[PATCH] score: Optimize STATUS_BUILD()

2020-02-01 Thread Sebastian Huber 


-- 
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.
From 5d113ea4a4464987aa4a6bf2d3166d08810ef74d Mon Sep 17 00:00:00 2001
From: Sebastian Huber 
Date: Thu, 2 Jan 2020 11:31:48 +0100
Subject: [PATCH] score: Optimize STATUS_BUILD()

Do not cast to unsigned int to avoid an unsigned long long enum type.
Use a multiplication/division instead to preserve the signedness of the
POSIX status.
---
 cpukit/include/rtems/score/status.h | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/cpukit/include/rtems/score/status.h b/cpukit/include/rtems/score/status.h
index fe1f0e87e6..b257ccc5db 100644
--- a/cpukit/include/rtems/score/status.h
+++ b/cpukit/include/rtems/score/status.h
@@ -49,9 +49,11 @@ typedef enum {
 
 /**
  * @brief Macro to build a status code from Classic and POSIX API parts.
+ *
+ * Uses a multiplication to preserve the signedness of the POSIX status.
  */
 #define STATUS_BUILD( classic_status, posix_status ) \
-  ( ( ( (unsigned int) ( posix_status ) ) << 8 ) | ( classic_status ) )
+  ( ( ( posix_status ) * 256 ) | ( classic_status ) )
 
 /**
  * @brief Macro to get the Classic API status code.
@@ -62,10 +64,10 @@ typedef enum {
 /**
  * @brief Macro to get the POSIX API status code.
  *
- * Performs an arithmetic shift to reconstruct a negative POSIX status.
+ * Uses a division to preserve the signedness of the POSIX status.
  */
 #define STATUS_GET_POSIX( status ) \
-  ( ( ( (int) ( status ) ) | 0xff ) >> 8 )
+  ( ( status ) / 256 )
 
 /**
  * @brief Status codes.
-- 
2.16.4

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

Re: Ticket #3515

2020-02-01 Thread Vijay Kumar Banerjee 
On Sat, Feb 1, 2020 at 12:57 PM Bran S  wrote:

> On Thu, 30 Jan 2020 at 05:52, Chris Johns  wrote:
> >
> > On 29/1/20 7:03 pm, Bran S wrote:
> > > Hi Guys,
> > >
> > > I am trying to solve #3515
> > > https://devel.rtems.org/ticket/3515 <
> https://devel.rtems.org/ticket/3515>
> >
> > Nice and thanks.
> >
> > > For this issue covoar is required.
> > >
> > > So I cloned https://git.rtems.org/rtems-tools/ <
> https://git.rtems.org/rtems-tools/>
> > > This is my directory structure:
> > > $HOME/quick-start/src/rtems - Main RTEMS repo
> > > $HOME/quick-start/src/rsb - Source Builder
> > > $HOME/quick-start/src/rtems-tools - The one that I have recently cloned
> > >
> > > But running `rtems-test --list-bsps` inside
> '$HOME/quick-start/src/rtems-tools'
> > > gives "error: RTEMS Toolkit python wrapper not found, plrease report"
> > >
> > > Any ideas on how to resolve this error ?
> >
> > What does `type rtems-test` say?
> >
> > Have you built a set of sparc tools?
> > Have you build the leon3 BSP and all the tests?
> >
> > I am not sure what happens if the `rtems-test` is run in the source tree
> while
> > picking up a version from your path. Maybe `./tester/rtems-test ...`
> works?
>
> Hi Bran,

Thanks for taking up this ticket.

> It is now working my $PATH was wrongly set with rtems/4.11 instead of
> rtems/5.
> I have corrected it. It now contains '$HOME/quick-start/rtems/5/bin'
>
> Nice.

> Moving on to the next problem:
>
> https://devel.rtems.org/wiki/GCI/Documentation/CoverageAnalysis/Coverage#RunningRTEMS-TESTERforCoverageanalysis
> I was reading this to know more about covoar.
> So as mentioned above I ran
>
> `rtems-test --rtems-tools=/home/user45/quick-start/rtems/5/
> --log=coverage_analysis.log --no-clean --coverage=score
> --rtems-bsp=leon3-qemu-cov
>
> /home/user45/quick-start/build/b-leon3/sparc-rtems5/c/leon3/testsuites/samples/hello.exe`
>
> And the output was: https://paste.debian.net/1128608/
> `qemu-system-sparc` not being installed seems to be the cause for the
> error.
>
> So I followed suggestion found here:
> https://lists.rtems.org/pipermail/users/2018-January/065583.html
> Ran the commands as:
>
> $ cd /quick-start/src/rsb/rtems/
> The rsb directory contains rtems source builder.
>
> $ ../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/5
> devel/qemu.bset
>
> You need devel/qemu-couverture.bset but while trying to build it, I see
the same error
as you see with qemu.bset

> Running this further gives errors and reports it into
> 'rsb-report-glib-2.39.3-x86_64-linux-gnu-1.txt'
> Full output of above command is at: https://paste.debian.net/1128609/
>
> The content of 'rsb-report-glib-2.39.3-x86_64-linux-gnu-1.txt' is
> here: https://paste.debian.net/1128610/
>
> In file 'rsb-report-glib-2.39.3-x86_64-linux-gnu-1.txt' (at
> https://paste.debian.net/1128610/) the first error occurs at line 385,
> which is:
>
> ../../glib-2.39.3/glib/gdate.c:2497:7: error: format not a string
> literal, format string not checked [-Werror=format-nonliteral]
>tmplen = strftime (tmpbuf, tmpbufsize, locale_format, );
>^~
>   CC   libglib_2_0_la-gdir.lo
>   CC   libglib_2_0_la-genviron.lo
> cc1: some warnings being treated as errors
> Makefile:1782: recipe for target 'libglib_2_0_la-gdate.lo' failed
> make[4]: *** [libglib_2_0_la-gdate.lo] Error 1
>
> This happens to be a known error/bug (Ref:
> https://bugs.freedesktop.org/show_bug.cgi?id=95326)
> and a patch is available for it here:
>
> https://gitlab.gnome.org/GNOME/glib/commit/8cdbc7fb2c8c876902e457abe46ee18a0b134486
>
> Following the patch I manually made changes into
>
> '$HOME/quick-start/src/rsb/rtems/build/glib-2.39.3-x86_64-linux-gnu-1/glib-2.39.3/glib/gdate.c'
>
> But the problem is that as soon as I run
> `../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/5
> devel/qemu.bset`
> My manual changes to the gdate.c disappear and I get the same error as
> before. I don't know what is going on.
>
> I applied the patch that you found along with another patch and built the
souces, glib built
successfully, but unfortunately the couverture-qemu itself failed to build.
Here's the log:
https://paste.ofcode.org/KmJCNZrJyQNev6R4FSUafe

Here I'm pasting the diff to add patches to RSB:
```
diff --git a/bare/config/devel/glib-2.39.3-1.cfg
b/bare/config/devel/glib-2.39.3-1.cfg
index d86fe28..0bada15 100644
--- a/bare/config/devel/glib-2.39.3-1.cfg
+++ b/bare/config/devel/glib-2.39.3-1.cfg
@@ -14,6 +14,10 @@

 %hash sha256 glib-%{glib_version}.tar.xz
d9fa6c9aa645a5e688a3bb29013bb83801b19ee767d99e33ff52e004e1cc5fc8

+#Patch to supress string literal warning
+
+%patch add glib
https://gitlab.gnome.org/GNOME/glib/commit/0817af40e8c74c721c30f6ef482b1f53d12044c7.patch
+%patch add glib
https://gitlab.gnome.org/GNOME/glib/commit/566e1d61a500267c7849ad0b2552feec9c9a29a6.patch
 #
 # The GLib build instructions. We use 2.x.x Release 1.
 #
```

You can apply the above diff into your rtems-source-builder and try to
build