Re: Ticket #3515: covoar failure while running for full testsuites

[Bran S]

On Wed, 19 Feb 2020 at 22:51, Vijay Kumar Banerjee
 wrote:
>
>
>
> On Mon, Feb 17, 2020 at 12:08 AM Bran S  wrote:
>>
>> Hi Guys,
>>
> Hi Bran!
>>
>> I am trying to understand and solve Ticket #3515.
>> https://devel.rtems.org/ticket/3515
>>
>> $ /home/user45/quick-start/rtems/5/share/rtems/tester/bin/covoar -
>> -S 
>> /home/user45/quick-start/rtems/5/share/rtems/tester/rtems/testing/coverage/leon3-sis-symbols.ini
>> -O leon3-sis-coverage -E
>> /home/user45/quick-start/rtems/5/share/rtems/tester/rtems/testing/coverage/Explanations.txt
>> -p RTEMS-5 
>> /home/user45/quick-start/build/b-leon3/sparc-rtems5/c/leon3/testsuites/fstests/fsclose01.exe
>>
>> The output of the above command is at:
>> https://gist.github.com/archsbran/7834a931d52311c7b26842c6325d8d9a
>>
>> On the last line it can be seen that absence of `wait` symbol causes the 
>> error.
>>
>> I made some changes in ExecutableInfo.cc to print out the symbols
>> being added into coverageMap.
>> Added symbols can be seen from line 636 to 7236 at the above link.
>> In those lines we can see that `wait` is not added into coverageMap.
>>
> Great work in finding the possible issue.
>>
>> I am new so the only thing I know about covoar is that it does
>> coverage analysis.
>> Any ideas on how to move further into solving this ?
>
> I added Chris in CC, he'll be able to tell us where to look for the source
> of the error you found.
> In general, you can follow covoar.cc file, which has the main `covoar`
> function in it. That will be a good starting point.
>


Yeah, I traversed through the code in covoar.cc

It goes something like:

In covoar.cc: covar()
at line 382: objdumpProcessor->load( exe, objdumpFile, err );
Here, `exe` points to the executableinfo object, the one in which the
coverageMap was created via createCoverageMap()

Now inside objdumpProcessor->load()
at line 301: finalizeSymbol() is called which further calls
findCoverageMap() at line 35. This is the point where error occurs, as
`wait` symbol is not found.

The objdumpProcessor->load() function searches symbols in
CoverageMap(via finalizeSymbol()) according to the symbols present in
objdump generated at
line 291: getFile( executableInformation->getFileName(), objdumpFile, err );

The objdump is created using the executableinfo from which we loaded
the symbols into CoverageMap, right ?
Then is it so that the code missed out on the symbol while adding them
into CoverageMap ?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] drvmgr: Fix determination of prefix in grlib uart driver

[Sebastian Huber]

On 20/02/2020 17:34, Gedare Bloom wrote:

Yes, I'll push in the next few minutes.


Thanks, I forwarded the patch to Gaisler more than a week ago, but 
didn't receive an answer.


--
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

Re: GSOC: Call for Mentors

[Sebastian Huber]

Hello Gedare,

I probably have no time to be a mentor this year. It depends a bit on 
the project and the student. I can help out as an active co-mentor.


--
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

Re: Project query

[suyash singh]

All right. I will get started with coverity right away

On Fri, Feb 21, 2020 at 1:02 AM Gedare Bloom  wrote:

> On Thu, Feb 20, 2020 at 10:56 AM suyash singh 
> wrote:
> >
> > I found this interesting project
> > https://devel.rtems.org/ticket/3710
> >
> > There are no prerequisites given for this one
> >
> This one is a bit on the open-ended side. You should get started by
> looking at our current status with Coverity, and triage a few bugs.
> Convert "real bugs" from coverity scan into RTEMS tickets on Trac, or
> do analysis to identify if a coverity vulnerability is actually a
> false positive / not-a-bug. This will give you some level of
> understanding about the Coverity workflow.
>
> Beyond that, we will need to identify what, if any, patterns exist for
> false positives, and whether we need to provide a more advanced
> modeling file for Coverity. The content of our current modeling file
> is pasted below. Some of these controls are only visible to
> administrator accounts, so if the project moves forward you'd need
> that permission. We'd deal with that if necessary.
>
> There is also the possibility that clang-analyzer can be used. Jose
> recently mentioned they got it to work with some "hacks" -- a good
> project could be to make it working in a productive manner for our
> open-source ecosystem.
>
> I could see the two (coverity and clang-analyzer) being a good basis
> for a GSoC that focuses on integration of static analysis tools in
> RTEMS "devops"
>
> Modeling file for RTEMS
> ---
> //
> // RTEMS-tools currently does not have anything to model for Coverity.
> // Having a file makes them happy we have a fully configured project. :)
> //
>
> typedef unsigned int uint32_t;
>
> void rtems_fatal_error_occurred(uint32_t the_error)
> {
>   __coverity_panic__();
> }
>
> #define rtems_interrupt_disable( _level ) \
>   do { \
> _level = 0; \
>   } while(0)
>
> ---
>
> Gedare
>
> > On Thu, Feb 20, 2020 at 10:31 PM Gedare Bloom  wrote:
> >>
> >> On Thu, Feb 20, 2020 at 9:43 AM suyash singh 
> wrote:
> >> >
> >> > So can I work on x86_64 BSP without hardware with simulator?
> >> > https://devel.rtems.org/ticket/2898
> >> >
> >> > Also out of the prerequisites I only know C programming language but
> I am ready to learn everything else.
> >> >
> >> I think it will be too hard to work on a new BSP/port without the
> >> assembly programming language experience in that architecture.
> >>
> >> I'd suggest you look for projects for which you possess all/most of
> >> the prerequisites (when explicitly stated).
> >>
> >> Gedare
> >>
> >> > On Thu, Feb 20, 2020 at 9:13 AM Gedare Bloom 
> wrote:
> >> >>
> >> >> On Wed, Feb 19, 2020 at 6:29 PM Joel Sherrill 
> wrote:
> >> >> >
> >> >> >
> >> >> >
> >> >> > On Wed, Feb 19, 2020, 6:12 PM John Millard 
> wrote:
> >> >> >>
> >> >> >> Greetings:
> >> >> >>
> >> >> >> I took Joel’s week-long class in June.
> >> >> >
> >> >> >
> >> >> > :) Thanks. Hope you enjoyed it.
> >> >> >
> >> >> >> I’m currently retired and looking for a project, but clearly not
> a GSoC guy. The default list of tickets is mostly old or currently assigned.
> >> >> >
> >> >> >
> >> >> > Currently assigned may not mean as much as you think. It is often
> done by someone to direct the ticket to who wrote the code. I know I often
> file tickets where I have looked into who is most likely to fix it and
> assign it to them.
> >> >> >
> >> >> > For example, I need to file a ticket for breakages building
> rtems-examples using waf. And when you build RTEMS using rtems6 tools,
> there are breakages because rtems5 is not replaced with rtems6 is still in
> some places. I reported both I think this week to devel.
> >> >> >
> >> >> >> The “open projects” page looks more relevant. I can buy hardware
> if somewhat reasonably priced. Having actual hardware would be somewhat
> preferred, even if qemu is amazing. I can do assembly (most familiar with
> Intel, but open to learning), low-level C down to the hardware, and have
> experience with OS level programming and drivers, serial and network
> transport, debuggers.
> >> >> >
> >> >> >
> >> >> > If that's the direction you want to go in, the x86_64 port and bsp
> are incomplete. There should be plenty of room to get things working. This
> would help ween us off of depending on legacy boot PCs.
> >> >> >
> >> >> +1
> >> >>
> >> >> And so far few students to work on it, and it is a big area to work
> on.
> >> >>
> >> >> There is also an open project to improve legacy x86:
> >> >> https://devel.rtems.org/ticket/2900
> >> >>
> >> >> >>
> >> >> >> Is there some priority on the projects? They are all equal, but
> some are more equal than others. I can guess the scope on some of them.
> >> >> >
> >> >> >
> >> >> > For the most part, there isn't much priority. If you ask different
> people, you will likely get different answers.
> >> >> >
> >> >> >>
> >> >> >> Suggestions welcome.
> >> >> >>
> >> >> 

[PATCH v2] Add Amaan to MAINTAINERS

[Amaan Cheval]

---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index f00f2753f2..437b55418b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -51,6 +51,7 @@ Ben Gras   b...@rtems.org
 Pavel Pisa pp...@pikron.com
 Christian Mauderer christian.maude...@embedded-brains.de
 Hesham Almataryheshamelmat...@gmail.com
+Amaan Cheval   am...@rtems.org
 
 Localized Write Permission
 ==
@@ -58,4 +59,5 @@ sparc  Daniel Hellstrom 
(dan...@gaisler.com)
 beagle Ben Gras (b...@rtems.org)
 tms570 Pavel Pisa (p...@cmp.felk.cvut.cz)
 raspberrypiPavel Pisa (p...@cmp.felk.cvut.cz)
+x86_64 Amaan Cheval (am...@rtems.org)
 
-- 
2.23.0

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

Re: [PATCH] Add Amaan to MAINTAINERS

[Amaan Cheval]

Made this patch before fetching/rebasing master, so it won't apply cleanly.
v2 after rebasing is on its way.

On Fri, Feb 21, 2020 at 10:15 AM Amaan Cheval 
wrote:

> ---
>  MAINTAINERS | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2732d773c4..99f473efe0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -51,6 +51,7 @@ Ben Gras   b...@rtems.org
>  Martin Galvan  martin.gal...@tallertechnologies.com
>  Pavel Pisa pp...@pikron.com
>  Christian Mauderer christian.maude...@embedded-brains.de
> +Amaan Cheval   am...@rtems.org
>
>  Localized Write Permission
>  ==
> @@ -58,4 +59,5 @@ sparc  Daniel Hellstrom (
> dan...@gaisler.com)
>  beagle Ben Gras (b...@rtems.org)
>  tms570 Pavel Pisa (p...@cmp.felk.cvut.cz)
>  raspberrypiPavel Pisa (p...@cmp.felk.cvut.cz)
> +x86_64 Amaan Cheval (am...@rtems.org)
>
> --
> 2.23.0
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] Add Amaan to MAINTAINERS

[Amaan Cheval]

---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 2732d773c4..99f473efe0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -51,6 +51,7 @@ Ben Gras   b...@rtems.org
 Martin Galvan  martin.gal...@tallertechnologies.com
 Pavel Pisa pp...@pikron.com
 Christian Mauderer christian.maude...@embedded-brains.de
+Amaan Cheval   am...@rtems.org
 
 Localized Write Permission
 ==
@@ -58,4 +59,5 @@ sparc  Daniel Hellstrom 
(dan...@gaisler.com)
 beagle Ben Gras (b...@rtems.org)
 tms570 Pavel Pisa (p...@cmp.felk.cvut.cz)
 raspberrypiPavel Pisa (p...@cmp.felk.cvut.cz)
+x86_64 Amaan Cheval (am...@rtems.org)
 
-- 
2.23.0

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

Re: SPDX License Identifier Only and Full Copy?

[Gedare Bloom]

On Thu, Feb 20, 2020 at 2:49 PM Chris Johns  wrote:
>
> On 21/2/20 3:20 am, Gedare Bloom wrote:
> > On Thu, Feb 20, 2020 at 12:58 AM Thomas Doerfler
> >  wrote:
> >>
> >> Hello,
> >>
> >> I just want to speak up here. I talked with Sebastian today and I really
> >> tend to keep the license text in each file.
> >>
> >> Rational:
> >>
> >> - With the BSD license, anyone can pick any file from the RTEMS repo and
> >> use/modify it in any project (and this is fine). The original authors
> >> (and their copyright) are listed in the file, but the only pointer to
> >> the legal part is the "SPDX identifier". I am not sure whether this is a
> >> legally binding "tag" and whether this tag is clear to any user.
> >>
> >> - Strictly seen, it is not even forbidden to remove the "SPDX
> >> identifier", because it is not part of the BSD-2-clause-license, it's
> >> just a pointer to it. In the end we might result in code drifting around
> >> without license information, which we all do not want to see.
> >>
> > This is a valid point. I also have no desire to be a lawyer.
> >
> > My intuition here is that, even without any licensing information at
> > all in individual files, one can still apply a single license to an
> > entire repository, e.g., BSD or GPL. For historical reasons, and
> > similar arguments as you've made, BSD-style licenses have tended to be
> > copy-pasted to individual files to make them easier to excerpt. We
> > don't have license uniformity, so we do need to individually specify
> > which license(s) apply to each file.
>
> This makes sense. The simplified BSD license states ...
>
>  1. Redistributions of source code must retain the above copyright
> notice, this list of conditions and the following disclaimer.
>
> I do not see how we can centralise this and have the "above copyright" work?
> Also the SPDX site here ...
>
>  https://spdx.org/ids-how
>
> ... under the heading "Standard license headers" states ...
>
>  When a license defines a recommended notice to attach to files
>  under that license (sometimes called a "standard header"), the SPDX
>  project recommends that the standard header be included in the files,
>  in addition to an SPDX ID.
>
> My reading of this means we should include the license in the source.
>
> We need to consider compliance and machine auditing of the source. The SPDX 
> tag
> is important. Maybe ...
>
> /*
>  * SPDX tag suff
>  */
> /*
>  * Copyright stuff
>  *
>  * 2-Clause BSD license
>  */
>

This is a good point. Probably it is good to follow the SPDX advice on
usage, and keep the "standard header" boilerplate intact.

> > Linux follows a similar philosophy as Sebastian suggests. I think we
> > can also follow Linux in this regards.
> > https://www.kernel.org/doc/html/latest/process/license-rules.html
> >
> > I would suggest we follow their approach to self-document the licenses
> > centrally. I suspect the risk of someone using code without adhering
> > to the license is no greater. Probably they have a higher risk
> > exposure than we do!
>
> I agree with the comments in the Linux license rules text about license text 
> in
> files making it harder to check for compliance.
>
> Chris
>
> >
> >> As you all know I am not a lawyer (and don't want to be), but my gut
> >> say's the extra lines in the top of each file are worth their storage.
> >> And anybody opening a RTEMS source file (even when it has been taken to
> >> a different project) should see what he has.
> >>
> >> -
> >>
> >> If you have different reasons to replace the header and just leave the
> >> identifier I a will go with it and it's fine for me. But my tendency
> >> is... leave it in.
> >>
> >> Kind regards,
> >>
> >> Thomas.
> >>
> >> Am 20.02.20 um 08:30 schrieb Sebastian Huber:
> >>> Hello,
> >>>
> >>> On 18/02/2020 16:58, Gedare Bloom wrote:
> >>> I suggest to use a master COPYING file and use file headers without
> >>> the
> >>> full license text.
> >>>
> >>> https://lists.rtems.org/pipermail/devel/2018-December/024198.html
> >> It would be nice to get some feedback here.
> >
> > I'm generally ok with just the spdx and copyright statements.
> >
>  I'm also fine with the master COPYING, spdx-tag, and individual
>  copyrights in files.
> 
>  I should make a note to take a pass over "my" files to relicense them.
>  Does anyone have any script/tools for making that easy?
> >>>
> >>> I talked with Thomas and he is not in favour of a removal of the licence
> >>> text. Not everyone knows what an SPDX-Licence-Identifier is and that
> >>> this means the file is covered by the reference license. The
> >>> BSD-2-Clause license text is quite clear and not long. For us it is
> >>> important that it is very clear that our contributions are without
> >>> warranties and so on. This information should be also clear if files are
> >>> transferred out of the RTEMS context to other projects.
> >>>
> >>
> >> --
> >> 

Re: SPDX License Identifier Only and Full Copy?

[Amar Takhar]

On 2020-02-21 12:15 +1100, Chris Johns wrote:
> 
> Does the Linux kernel rules apply to the 2 clause BSD license we have?

I don't think so but I've always included BSD licenses in the file as the 
license expressly states that it should be included.  This on top of adding an 
SPDX marker.

Also, the nature of 2BSD means anyone can include any file as they wish and use 
it anywhere they like.  Not having the license is a pain in this aspect.

Having the license and ID satisfies both aspects any typos or errors are not a 
huge issue as it will still be 2BSD.


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

Re: Loading RTEMS applications from u-boot on Raspberry Pi 2

[Niteesh G. S.]

Hii Cláudio,

On Fri, 21 Feb, 2020, 4:55 AM Cláudio Maia (clrrm), 
wrote:

> Hi Niteesh,
>
> Thank you for your input. Following your suggestion allowed me to boot
> successfully RTEMS from u-boot.
> Moreover, I confirm that “-O rtems" does not work for me as well.
>

Your welcome :)

I have a few questions that I would like to ask you. What exactly is going
> on when we execute “bootm 0x20 - 0x1000”?
> The address where we load the dtb is far apart from the one where we load
> the .img, so why do we need to boot the .img 0x1000 bytes below 0x20?
> What is the relation between both, if any?
>

That's just the syntax for bootm.
bootm ${kernel_addr} - ${fdt_addr}

But, bootm  ${kernel_addr}  ${fdt_addr} should also work I guess but I am
not sure. Can you try that and please let me know?

Thank you,
Niteesh.

Regards,
> Cláudio
>
> > On 18 Feb 2020, at 15:56, Niteesh G. S.  wrote:
> >
> > Hii,
> >
> > Regarding loading RTEMS images using U-Boot. It is
> > necessary that you provide a DTB file.
> >
> > So, your commands should be
> >
> > $ mkimage -A arm -O linux -T kernel -a 0x20 -e 0x200080 -d
> kernel.img -C none rtems.img
> >
> > Can you please let me know if -O rtems works for you. I have tried
> > using it but got no output.
> >
> > U-Boot> fatload mmc 0:1 0x20 rtems.img
> > U-Boot> fatload mmc 0:1 0x1000 bcm2709-rpi-2-b.dtb or bcm2710-rpi-2-b.dtb
> > The DTB file should be choosed according to the board version.
> > U-Boot> bootm 0x20 - 0x1000
> >
> > Thanks,
> > Niteesh.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: SPDX License Identifier Only and Full Copy?

[Chris Johns]

On 21/2/20 12:11 pm, Joel Sherrill wrote:
> 
> 
> On Thu, Feb 20, 2020, 3:49 PM Chris Johns  > wrote:
> 
> On 21/2/20 3:20 am, Gedare Bloom wrote:
> > On Thu, Feb 20, 2020 at 12:58 AM Thomas Doerfler
> >  > wrote:
> >>
> >> Hello,
> >>
> >> I just want to speak up here. I talked with Sebastian today and I 
> really
> >> tend to keep the license text in each file.
> >>
> >> Rational:
> >>
> >> - With the BSD license, anyone can pick any file from the RTEMS repo 
> and
> >> use/modify it in any project (and this is fine). The original authors
> >> (and their copyright) are listed in the file, but the only pointer to
> >> the legal part is the "SPDX identifier". I am not sure whether this is 
> a
> >> legally binding "tag" and whether this tag is clear to any user.
> >>
> >> - Strictly seen, it is not even forbidden to remove the "SPDX
> >> identifier", because it is not part of the BSD-2-clause-license, it's
> >> just a pointer to it. In the end we might result in code drifting 
> around
> >> without license information, which we all do not want to see.
> >>
> > This is a valid point. I also have no desire to be a lawyer.
> >
> > My intuition here is that, even without any licensing information at
> > all in individual files, one can still apply a single license to an
> > entire repository, e.g., BSD or GPL. For historical reasons, and
> > similar arguments as you've made, BSD-style licenses have tended to be
> > copy-pasted to individual files to make them easier to excerpt. We
> > don't have license uniformity, so we do need to individually specify
> > which license(s) apply to each file.
> 
> This makes sense. The simplified BSD license states ...
> 
>  1. Redistributions of source code must retain the above copyright
>     notice, this list of conditions and the following disclaimer.
> 
> I do not see how we can centralise this and have the "above copyright" 
> work?
> Also the SPDX site here ...
> 
>  https://spdx.org/ids-how
> 
> ... under the heading "Standard license headers" states ...
> 
>  When a license defines a recommended notice to attach to files
>  under that license (sometimes called a "standard header"), the SPDX
>  project recommends that the standard header be included in the files,
>  in addition to an SPDX ID.
> 
> My reading of this means we should include the license in the source.
> 
> We need to consider compliance and machine auditing of the source. The 
> SPDX tag
> is important. Maybe ...
> 
> /*
>  * SPDX tag suff
>  */
> /*
>  * Copyright stuff
>  *
>  * 2-Clause BSD license
>  */
> 
> > Linux follows a similar philosophy as Sebastian suggests. I think we
> > can also follow Linux in this regards.
> > https://www.kernel.org/doc/html/latest/process/license-rules.html
> >
> > I would suggest we follow their approach to self-document the licenses
> > centrally. I suspect the risk of someone using code without adhering
> > to the license is no greater. Probably they have a higher risk
> > exposure than we do!
> 
> I agree with the comments in the Linux license rules text about license 
> text in
> files making it harder to check for compliance.
> 
> 
> Following Linux is probably a safe approach. I assume there was significant
> legal review of their policy.

Does the Linux kernel rules apply to the 2 clause BSD license we have?

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

Re: Loading RTEMS applications from u-boot on Raspberry Pi 2

[clrrm]

Hi Jan,

I tried your solution and it does not work in my case. The following is an 
example of the output that I get:

—
U-Boot> fatload mmc 0 0x3000 hello.exe
reading hello.exe
3456844 bytes read in 269 ms (12.3 MiB/s)

U-Boot> bootelf 0x3000
CACHE: Misaligned operation at range [0020, 002004d8]
CACHE: Misaligned operation at range [0020ea00, 0020ea0c]
CACHE: Misaligned operation at range [0020ea0c, 0020ea18]
CACHE: Misaligned operation at range [0020ea18, 002506df]
CACHE: Misaligned operation at range [002506e0, 002506e8]
CACHE: Misaligned operation at range [002506e8, 002506ec]
CACHE: Misaligned operation at range [002506ec, 002506f0]
CACHE: Misaligned operation at range [002506f0, 002506f4]
CACHE: Misaligned operation at range [002506f4, 00250734]
CACHE: Misaligned operation at range [00250734, 0030]
CACHE: Misaligned operation at range [0030, 00301a6c]
CACHE: Misaligned operation at range [00301a80, 00303f68]
## Starting application at 0x00200080 ...
data abort
pc : [<002006ce>]  lr : [<00200160>]
reloc pc : []lr : []
sp : 00305b74  ip : 0010 fp : 3b348850
r10: 0002  r9 : 3af41ee8 r8 : 
r7 : 0001  r6 : 0020ecf8 r5 : 3af42694  r4 : 61da
r3 : 0041d710  r2 : 0020ea18 r1 :   r0 : 0006
Flags: Nzcv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...
 
resetting …
—

Regardless of the address where I load the ELF file I get alignment issues, 
even if I try to load “hello.exe” at 0x20. 

I realised that my board version is different than yours by looking to your 
output. Yours is “RTEMS RPi 2B 1.1 (1GB) [00a01041]” and mine is more recent 
“RTEMS RPi 2B 1,2 (with BCM2837) (1GB) [00a22042]” (obtained by following 
Niteesh's solution). So, besides the difference in versions, I don’t see any 
other reason for not getting the same output as you.
 
For your information, the solution provided by Niteesh works for me without 
problems.

Regards,
Cláudio

> On 18 Feb 2020, at 16:31, jan.som...@dlr.de wrote:
> 
> Hi Cláudio,
> 
> I build a current BSP for the raspberry pi 2 recently (atm without SMP 
> though).
> 
>> -Ursprüngliche Nachricht-
>> Von: devel [mailto:devel-boun...@rtems.org] Im Auftrag von Cláudio Maia
>> Gesendet: Montag, 17. Februar 2020 21:19
>> An: devel@rtems.org
>> Betreff: Loading RTEMS applications from u-boot on Raspberry Pi 2
>> 
> 
> [...]
> 
>> 
>> ---
>> For approach #2, I do the following:
>> 
> 
> I skip the whole mkimage step entirely and boot the elf-files directly.
> So my u-boot commands look like this:
> 
> U-Boot> fatload mmc 0 0x3000 ticker.exe
> 4043404 bytes read in 169 ms (22.8 MiB/s)
> U-Boot> bootelf 0x3000
> ## Starting application at 0x00200080 ...
> 
> RTEMS RPi 2B 1.1 (1GB) [00a01041]
> 
> *** BEGIN OF TEST CLOCK TICK ***
> 
> Note, that I load the file quite far at the end of the RAM to avoid conflicts 
> with the sections loaded by the elf-file.
> When I used lower values (below 0x1000), my application got stuck at 
> transfer to RTEMS as well.
> Maybe that is also the problem with your image loading?
> 
>> $ arm-rtems5-objcopy -R -S -O binary hello.exe hello.bin
>> $ mkimage -A arm -O rtems -T kernel -C none -a 0x20 -e 0x200080 -d
>> hello.bin hello-rtems.img
>> 
>> Image Name:
>> Created:  Mon Feb 17 13:59:50 2020
>> Image Type:   ARM RTEMS Kernel Image (uncompressed)
>> Data Size:1055340 Bytes = 1030.61 kB = 1.01 MB
>> Load Address: 0020
>> Entry Point:  00200080
>> 
>> Then, after u-boot loads on the target, I do the following:
>> 
>> U-Boot> fatload mmc 0:1 0x20 hello-rtems.img
>> reading hello-rtems.img
>> 1055404 bytes read in 103 ms (9.8 MiB/s)
>> 
>> U-Boot> iminfo
>> 
>> ## Checking Image at 0020 ...
>>   Legacy image found
>>   Image Name:
>>   Image Type:   ARM RTEMS Kernel Image (uncompressed)
>>   Data Size:1055340 Bytes = 1 MiB
>>   Load Address: 0020
>>   Entry Point:  00200080
>>   Verifying Checksum ... OK
>> 
>> U-Boot> bootm 0x20
>> ## Booting kernel from Legacy Image at 0020 ...
>>   Image Name:
>>   Image Type:   ARM RTEMS Kernel Image (uncompressed)
>>   Data Size:1055340 Bytes = 1 MiB
>>   Load Address: 0020
>>   Entry Point:  00200080
>>   Verifying Checksum ... OK
>>   Loading Kernel Image ... OK
>> ## Transferring control to RTEMS (at address 00200080) ...
>> 
>> After this point, nothing happens on the board.
>> ---
>> 
>> Thank you in advance. Regards
>> Cláudio Maia
>> ___
>> 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

Re: Loading RTEMS applications from u-boot on Raspberry Pi 2

[clrrm]

Hi Niteesh,

Thank you for your input. Following your suggestion allowed me to boot 
successfully RTEMS from u-boot.
Moreover, I confirm that “-O rtems" does not work for me as well. 

I have a few questions that I would like to ask you. What exactly is going on 
when we execute “bootm 0x20 - 0x1000”? 
The address where we load the dtb is far apart from the one where we load the 
.img, so why do we need to boot the .img 0x1000 bytes below 0x20? What is 
the relation between both, if any?

Regards,
Cláudio

> On 18 Feb 2020, at 15:56, Niteesh G. S.  wrote:
> 
> Hii,
> 
> Regarding loading RTEMS images using U-Boot. It is
> necessary that you provide a DTB file.
> 
> So, your commands should be
> 
> $ mkimage -A arm -O linux -T kernel -a 0x20 -e 0x200080 -d kernel.img -C 
> none rtems.img
> 
> Can you please let me know if -O rtems works for you. I have tried
> using it but got no output.
> 
> U-Boot> fatload mmc 0:1 0x20 rtems.img
> U-Boot> fatload mmc 0:1 0x1000 bcm2709-rpi-2-b.dtb or bcm2710-rpi-2-b.dtb
> The DTB file should be choosed according to the board version.
> U-Boot> bootm 0x20 - 0x1000
> 
> Thanks,
> Niteesh.

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

Re: GSOC: Call for Mentors

[Peter Dufault]

> On Feb 17, 2020, at 14:58 , Gedare Bloom  wrote:
> 
> Assuming we get accepted on 2/20, I will be able to start adding mentors 
> shortly after. Please let me know if you're interested to mentor this summer, 
> either in a primary or co-mentor capacity. As usual, I will provide "backup" 
> mentoring and high-level organization of all projects with weekly contact to 
> each student. Primary mentors are responsible for multiple interactions per 
> week (daily is best) with their student and providing strong technical 
> guidance. Co-mentors should stay in the loop, and possibly step in if the 
> primary mentor needs a break or other emergency comes up.
> 
> Gedare
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

I will definitely co-mentor thread stack protection, I'm very interested in 
this. I can't be a mentor due to my current work load.

Peter
-
Peter Dufault
HD Associates, Inc.  Software and System Engineering

This email is delivered through the public internet using protocols subject to 
interception and tampering.

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

Re: SPDX License Identifier Only and Full Copy?

[Chris Johns]

On 21/2/20 3:20 am, Gedare Bloom wrote:
> On Thu, Feb 20, 2020 at 12:58 AM Thomas Doerfler
>  wrote:
>>
>> Hello,
>>
>> I just want to speak up here. I talked with Sebastian today and I really
>> tend to keep the license text in each file.
>>
>> Rational:
>>
>> - With the BSD license, anyone can pick any file from the RTEMS repo and
>> use/modify it in any project (and this is fine). The original authors
>> (and their copyright) are listed in the file, but the only pointer to
>> the legal part is the "SPDX identifier". I am not sure whether this is a
>> legally binding "tag" and whether this tag is clear to any user.
>>
>> - Strictly seen, it is not even forbidden to remove the "SPDX
>> identifier", because it is not part of the BSD-2-clause-license, it's
>> just a pointer to it. In the end we might result in code drifting around
>> without license information, which we all do not want to see.
>>
> This is a valid point. I also have no desire to be a lawyer.
> 
> My intuition here is that, even without any licensing information at
> all in individual files, one can still apply a single license to an
> entire repository, e.g., BSD or GPL. For historical reasons, and
> similar arguments as you've made, BSD-style licenses have tended to be
> copy-pasted to individual files to make them easier to excerpt. We
> don't have license uniformity, so we do need to individually specify
> which license(s) apply to each file.

This makes sense. The simplified BSD license states ...

 1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.

I do not see how we can centralise this and have the "above copyright" work?
Also the SPDX site here ...

 https://spdx.org/ids-how

... under the heading "Standard license headers" states ...

 When a license defines a recommended notice to attach to files
 under that license (sometimes called a "standard header"), the SPDX
 project recommends that the standard header be included in the files,
 in addition to an SPDX ID.

My reading of this means we should include the license in the source.

We need to consider compliance and machine auditing of the source. The SPDX tag
is important. Maybe ...

/*
 * SPDX tag suff
 */
/*
 * Copyright stuff
 *
 * 2-Clause BSD license
 */

> Linux follows a similar philosophy as Sebastian suggests. I think we
> can also follow Linux in this regards.
> https://www.kernel.org/doc/html/latest/process/license-rules.html
> 
> I would suggest we follow their approach to self-document the licenses
> centrally. I suspect the risk of someone using code without adhering
> to the license is no greater. Probably they have a higher risk
> exposure than we do!

I agree with the comments in the Linux license rules text about license text in
files making it harder to check for compliance.

Chris

> 
>> As you all know I am not a lawyer (and don't want to be), but my gut
>> say's the extra lines in the top of each file are worth their storage.
>> And anybody opening a RTEMS source file (even when it has been taken to
>> a different project) should see what he has.
>>
>> -
>>
>> If you have different reasons to replace the header and just leave the
>> identifier I a will go with it and it's fine for me. But my tendency
>> is... leave it in.
>>
>> Kind regards,
>>
>> Thomas.
>>
>> Am 20.02.20 um 08:30 schrieb Sebastian Huber:
>>> Hello,
>>>
>>> On 18/02/2020 16:58, Gedare Bloom wrote:
>>> I suggest to use a master COPYING file and use file headers without
>>> the
>>> full license text.
>>>
>>> https://lists.rtems.org/pipermail/devel/2018-December/024198.html
>> It would be nice to get some feedback here.
>
> I'm generally ok with just the spdx and copyright statements.
>
 I'm also fine with the master COPYING, spdx-tag, and individual
 copyrights in files.

 I should make a note to take a pass over "my" files to relicense them.
 Does anyone have any script/tools for making that easy?
>>>
>>> I talked with Thomas and he is not in favour of a removal of the licence
>>> text. Not everyone knows what an SPDX-Licence-Identifier is and that
>>> this means the file is covered by the reference license. The
>>> BSD-2-Clause license text is quite clear and not long. For us it is
>>> important that it is very clear that our contributions are without
>>> warranties and so on. This information should be also clear if files are
>>> transferred out of the RTEMS context to other projects.
>>>
>>
>> --
>> 
>> embedded brains GmbH
>> Thomas Doerfler
>> Dornierstr. 4
>> D-82178 Puchheim
>> Germany
>> email: thomas.doerf...@embedded-brains.de
>> Phone: +49-89-18 94 741-12
>> Fax:   +49-89-18 94 741-09
>> PGP: Public key available on request.
>> For our privacy statement, see
>> https://embedded-brains.de/en/data-privacy-statement/
>> ___
>> devel mailing list
>> 

Re: Project query

[Gedare Bloom]

On Thu, Feb 20, 2020 at 10:56 AM suyash singh  wrote:
>
> I found this interesting project
> https://devel.rtems.org/ticket/3710
>
> There are no prerequisites given for this one
>
This one is a bit on the open-ended side. You should get started by
looking at our current status with Coverity, and triage a few bugs.
Convert "real bugs" from coverity scan into RTEMS tickets on Trac, or
do analysis to identify if a coverity vulnerability is actually a
false positive / not-a-bug. This will give you some level of
understanding about the Coverity workflow.

Beyond that, we will need to identify what, if any, patterns exist for
false positives, and whether we need to provide a more advanced
modeling file for Coverity. The content of our current modeling file
is pasted below. Some of these controls are only visible to
administrator accounts, so if the project moves forward you'd need
that permission. We'd deal with that if necessary.

There is also the possibility that clang-analyzer can be used. Jose
recently mentioned they got it to work with some "hacks" -- a good
project could be to make it working in a productive manner for our
open-source ecosystem.

I could see the two (coverity and clang-analyzer) being a good basis
for a GSoC that focuses on integration of static analysis tools in
RTEMS "devops"

Modeling file for RTEMS
---
//
// RTEMS-tools currently does not have anything to model for Coverity.
// Having a file makes them happy we have a fully configured project. :)
//

typedef unsigned int uint32_t;

void rtems_fatal_error_occurred(uint32_t the_error)
{
  __coverity_panic__();
}

#define rtems_interrupt_disable( _level ) \
  do { \
_level = 0; \
  } while(0)

---

Gedare

> On Thu, Feb 20, 2020 at 10:31 PM Gedare Bloom  wrote:
>>
>> On Thu, Feb 20, 2020 at 9:43 AM suyash singh  
>> wrote:
>> >
>> > So can I work on x86_64 BSP without hardware with simulator?
>> > https://devel.rtems.org/ticket/2898
>> >
>> > Also out of the prerequisites I only know C programming language but I am 
>> > ready to learn everything else.
>> >
>> I think it will be too hard to work on a new BSP/port without the
>> assembly programming language experience in that architecture.
>>
>> I'd suggest you look for projects for which you possess all/most of
>> the prerequisites (when explicitly stated).
>>
>> Gedare
>>
>> > On Thu, Feb 20, 2020 at 9:13 AM Gedare Bloom  wrote:
>> >>
>> >> On Wed, Feb 19, 2020 at 6:29 PM Joel Sherrill  wrote:
>> >> >
>> >> >
>> >> >
>> >> > On Wed, Feb 19, 2020, 6:12 PM John Millard  wrote:
>> >> >>
>> >> >> Greetings:
>> >> >>
>> >> >> I took Joel’s week-long class in June.
>> >> >
>> >> >
>> >> > :) Thanks. Hope you enjoyed it.
>> >> >
>> >> >> I’m currently retired and looking for a project, but clearly not a 
>> >> >> GSoC guy. The default list of tickets is mostly old or currently 
>> >> >> assigned.
>> >> >
>> >> >
>> >> > Currently assigned may not mean as much as you think. It is often done 
>> >> > by someone to direct the ticket to who wrote the code. I know I often 
>> >> > file tickets where I have looked into who is most likely to fix it and 
>> >> > assign it to them.
>> >> >
>> >> > For example, I need to file a ticket for breakages building 
>> >> > rtems-examples using waf. And when you build RTEMS using rtems6 tools, 
>> >> > there are breakages because rtems5 is not replaced with rtems6 is still 
>> >> > in some places. I reported both I think this week to devel.
>> >> >
>> >> >> The “open projects” page looks more relevant. I can buy hardware if 
>> >> >> somewhat reasonably priced. Having actual hardware would be somewhat 
>> >> >> preferred, even if qemu is amazing. I can do assembly (most familiar 
>> >> >> with Intel, but open to learning), low-level C down to the hardware, 
>> >> >> and have experience with OS level programming and drivers, serial and 
>> >> >> network transport, debuggers.
>> >> >
>> >> >
>> >> > If that's the direction you want to go in, the x86_64 port and bsp are 
>> >> > incomplete. There should be plenty of room to get things working. This 
>> >> > would help ween us off of depending on legacy boot PCs.
>> >> >
>> >> +1
>> >>
>> >> And so far few students to work on it, and it is a big area to work on.
>> >>
>> >> There is also an open project to improve legacy x86:
>> >> https://devel.rtems.org/ticket/2900
>> >>
>> >> >>
>> >> >> Is there some priority on the projects? They are all equal, but some 
>> >> >> are more equal than others. I can guess the scope on some of them.
>> >> >
>> >> >
>> >> > For the most part, there isn't much priority. If you ask different 
>> >> > people, you will likely get different answers.
>> >> >
>> >> >>
>> >> >> Suggestions welcome.
>> >> >>
>> >> >> John
>> >> >> —where there are tools, a will, and a will to build tools there is a 
>> >> >> way
>> >> >>
>> >> >> _
>> >> >>
>> >> >> devel mailing list
>> >> >> 

Re: GSOC 2020 project query

[Christian Mauderer]

On 20/02/2020 20:26, Gedare Bloom wrote:
> I answered in your initial email. In general, it is OK for you to
> "ping" an email that has not been responded to in about 5-7 days.

And for the GSoC tickets: If there is an owner, don't hesitate to add
him on CC. Some of us have filters that highlight mails addressed
directly to them.

> 
> On Thu, Feb 20, 2020 at 11:07 AM Utkarsh Rai  wrote:
>>
>> Based on @Gedare Bloom's feedback,  adding memory protection or enhancing 
>> Wi-fi Support in libbsd are two projects that I would like to work upon.
>>
>> For MMU support I think a lot unmerged PowerPC code is already present, but 
>> since  I would be using BBB I would only be able to use that as a reference. 
>> Is it feasible to start it from scratch?
>>
>> For Wi-Fi support, I would require an RTL8188 USB dongle along with JTAG (I 
>> have a J-link and am in the process of soldering the headers) for debugging 
>> purposes. I am not quite sure about how to handle the 'hot-plugging' case in 
>> this project it would be very helpful if the project owners could point me 
>> in the right direction.
>>
>> Regards,
>> Utkarsh Rai.
>> ___
>> 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
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSOC 2020 project query

[Gedare Bloom]

I answered in your initial email. In general, it is OK for you to
"ping" an email that has not been responded to in about 5-7 days.

On Thu, Feb 20, 2020 at 11:07 AM Utkarsh Rai  wrote:
>
> Based on @Gedare Bloom's feedback,  adding memory protection or enhancing 
> Wi-fi Support in libbsd are two projects that I would like to work upon.
>
> For MMU support I think a lot unmerged PowerPC code is already present, but 
> since  I would be using BBB I would only be able to use that as a reference. 
> Is it feasible to start it from scratch?
>
> For Wi-Fi support, I would require an RTL8188 USB dongle along with JTAG (I 
> have a J-link and am in the process of soldering the headers) for debugging 
> purposes. I am not quite sure about how to handle the 'hot-plugging' case in 
> this project it would be very helpful if the project owners could point me in 
> the right direction.
>
> Regards,
> Utkarsh Rai.
> ___
> 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

Re: GSOC 2020 project query

[Gedare Bloom]

On Thu, Feb 20, 2020 at 12:24 PM Christian Mauderer  wrote:
>
> Hello Utkarsh,
>
> On 20/02/2020 19:07, Utkarsh Rai wrote:
> > Based on @Gedare Bloom's feedback,  adding memory protection
> >  or enhancing Wi-fi Support in
> > libbsd  are two projects that I
> > would like to work upon.
>
> Both sound like great projects.
>
> >
> > For MMU support I think a lot unmerged PowerPC code is already present,
> > but since  I would be using BBB I would only be able to use that as a
> > reference. Is it feasible to start it from scratch?
>
> I don't really know about the current status. But in most cases it would
> be a better idea to continue the work if something exists. Otherwise
> it's quite likely that you'll manage to create a similar unfinished
> version as a result. Of course it depends a bit on what exists.
>
> >
> > For Wi-Fi support, I would require an RTL8188 USB dongle along with
> > JTAG (I have a J-link and am in the process of soldering the
> > headers) for debugging purposes. I am not quite sure about how to handle
> > the 'hot-plugging' case in this project it would be very helpful if the
> > project owners could point me in the right direction.
>
> Regarding the RTL8188: I think that there are quite some similar
> adapters that would work too. And if necessary porting another driver
> from FreeBSD isn't too hard. So if you have trouble finding the RTL8188
> search for another USB dongle that is supported by FreeBSD and ask here
> on the list whether it can be used too.
>
> Regarding the hot plug: Like the ticket tells: It's not entirely clear
> yet. My first step would be to analyze what FreeBSD does and how it
> detects such events. I assume that there is some kind of mechanism to
> notify a userspace application of new devices. Maybe we can hook into
> that mechanism?
>
> In that context: Please note that the ticket #3223 is strongly
> connected. You can also mix some parts of the two tickets if you want.
>
> Best regards
>
> Christian
>
Thanks for responding with the details Christian.

> >
> > Regards,
> > Utkarsh Rai.
> >
> > ___
> > 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Project for GSoC 2020

[Gedare Bloom]

On Tue, Feb 18, 2020 at 12:45 PM Utkarsh Rai  wrote:
>
> Based on your feedback,  adding memory protection or enhancing Wi-fi Support 
> in libbsd are two projects that I would like to work upon.
>
> For MMU support I think a lot unmerged PowerPC code is already present, but 
> since  I would be using BBB I would only be able to use that as a reference. 
> Is it feasible to start it from scratch?
>
The state-of-the-art has advanced in the rtems.git tree since these
projects happened, and it is not all documented. The ARM in particular
generally uses a static initialization or boot-time initialization of
the MMU. You  should study how the ARM approach works in the RTEMS
main repo, and consider whether that approach can be adopted by other
architectures/BSPs, how to improve that approach, and how to build
higher-level services on top of the low-level BSP support that exists.

One of the main interesting applications is to provide thread stack protection.

> For Wi-Fi support, I would require an RTL8188 USB dongle along with JTAG for 
> debugging purposes. I am not quite sure about how to handle the 
> 'hot-plugging' case in this project it would be very helpful if someone could 
> point me in the right direction.
>
I can't speak to the WiFi support, maybe others know. But to get
started you would need to at least demonstrate that you have the
necessary hardware to succeed and that you can at a minimum boot/run
BBB with libbsd, and probably we should like you to show that you can
generate patches for libbsd.

Gedare

>
> On Tue, Feb 18, 2020 at 1:21 AM Gedare Bloom  wrote:
>>
>>
>> On Mon, Feb 17, 2020 at 9:42 AM Utkarsh Rai  wrote:
>>>
>>> Hello everyone,
>>
>> Hello Utkarsh Rai,
>>
>>>
>>> I would like to contribute to the Beagleboard BSP project, in particular 
>>> towards the improvement of the peripheral support. I have a few questions 
>>> pertaining to the same:-
>>>
>>> 1. Is adding support for Ethernet and USB a reasonable goal for the 
>>> duration of the GSOC?
>>>
>>> 2. FreeBSD has support for Ethernet and USB  can we port that to libbsd?
>>>
>>> 3. What are the deliverables for this project, for instance, would I be 
>>> required to add shell support for these peripherals or maybe an example app?
>>>
>>> I have also attached a screenshot of the changed  'hello world' program 
>>> along with this email
>>
>> Thanks. It is nice to see that you already ran it successfully on the BBB.
>>
>> As of now, the BBB has quite mature support including Ethernet and USB. 
>> There is another student actively working on a proposal to expand our BBB 
>> support a bit further. I'm not certain if there is sufficient 
>> work/interest/mentoring available to support multiple BBB projects. You 
>> might consider what specific projects would interest you though. You should 
>> take a look at past years' GSoC projects documented on our wiki, they are 
>> linked from our main 'GSoC' page.
>>
>> There are also lots of interesting projects that can be done in a 
>> BSP-agnostic way, but still could be valuable to test with the BBB. The most 
>> important aspect about doing development with a BBB is that you can use the 
>> JTAG, which requires some soldering and additional effort to work with a 
>> standalone JTAG debugger.  If you don't have that, and want to work with the 
>> BBB, it is highly recommended.
>>
>>
>>>
>>> ___
>>> 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

Re: GSOC 2020 project query

[Christian Mauderer]

Hello Utkarsh,

On 20/02/2020 19:07, Utkarsh Rai wrote:
> Based on @Gedare Bloom's feedback,  adding memory protection
>  or enhancing Wi-fi Support in
> libbsd  are two projects that I
> would like to work upon. 

Both sound like great projects.

> 
> For MMU support I think a lot unmerged PowerPC code is already present,
> but since  I would be using BBB I would only be able to use that as a
> reference. Is it feasible to start it from scratch?

I don't really know about the current status. But in most cases it would
be a better idea to continue the work if something exists. Otherwise
it's quite likely that you'll manage to create a similar unfinished
version as a result. Of course it depends a bit on what exists.

> 
> For Wi-Fi support, I would require an RTL8188 USB dongle along with
> JTAG (I have a J-link and am in the process of soldering the
> headers) for debugging purposes. I am not quite sure about how to handle
> the 'hot-plugging' case in this project it would be very helpful if the
> project owners could point me in the right direction.

Regarding the RTL8188: I think that there are quite some similar
adapters that would work too. And if necessary porting another driver
from FreeBSD isn't too hard. So if you have trouble finding the RTL8188
search for another USB dongle that is supported by FreeBSD and ask here
on the list whether it can be used too.

Regarding the hot plug: Like the ticket tells: It's not entirely clear
yet. My first step would be to analyze what FreeBSD does and how it
detects such events. I assume that there is some kind of mechanism to
notify a userspace application of new devices. Maybe we can hook into
that mechanism?

In that context: Please note that the ticket #3223 is strongly
connected. You can also mix some parts of the two tickets if you want.

Best regards

Christian

> 
> Regards,
> Utkarsh Rai.
> 
> ___
> 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

Re: GSoC organizations list announced

[Mritunjay Sharma]

Heartiest Congratulations and best wishes to everyone!

On Thu, Feb 20, 2020 at 6:40 PM Vaibhav Gupta 
wrote:

> Congratulations. RTEMS
> ___
> 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

GSoC organizations list announced

[Vaibhav Gupta]

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

GSOC 2020 project query

[Utkarsh Rai]

Based on @Gedare Bloom's feedback,  adding memory protection
 or enhancing Wi-fi Support in libbsd
 are two projects that I would like to
work upon.

For MMU support I think a lot unmerged PowerPC code is already present, but
since  I would be using BBB I would only be able to use that as a
reference. Is it feasible to start it from scratch?

For Wi-Fi support, I would require an RTL8188 USB dongle along with JTAG (I
have a J-link and am in the process of soldering the headers) for debugging
purposes. I am not quite sure about how to handle the 'hot-plugging' case
in this project it would be very helpful if the project owners could point
me in the right direction.

Regards,
Utkarsh Rai.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Project query

[suyash singh]

I found this interesting project
https://devel.rtems.org/ticket/3710

There are no prerequisites given for this one

On Thu, Feb 20, 2020 at 10:31 PM Gedare Bloom  wrote:

> On Thu, Feb 20, 2020 at 9:43 AM suyash singh 
> wrote:
> >
> > So can I work on x86_64 BSP without hardware with simulator?
> > https://devel.rtems.org/ticket/2898
> >
> > Also out of the prerequisites I only know C programming language but I
> am ready to learn everything else.
> >
> I think it will be too hard to work on a new BSP/port without the
> assembly programming language experience in that architecture.
>
> I'd suggest you look for projects for which you possess all/most of
> the prerequisites (when explicitly stated).
>
> Gedare
>
> > On Thu, Feb 20, 2020 at 9:13 AM Gedare Bloom  wrote:
> >>
> >> On Wed, Feb 19, 2020 at 6:29 PM Joel Sherrill  wrote:
> >> >
> >> >
> >> >
> >> > On Wed, Feb 19, 2020, 6:12 PM John Millard 
> wrote:
> >> >>
> >> >> Greetings:
> >> >>
> >> >> I took Joel’s week-long class in June.
> >> >
> >> >
> >> > :) Thanks. Hope you enjoyed it.
> >> >
> >> >> I’m currently retired and looking for a project, but clearly not a
> GSoC guy. The default list of tickets is mostly old or currently assigned.
> >> >
> >> >
> >> > Currently assigned may not mean as much as you think. It is often
> done by someone to direct the ticket to who wrote the code. I know I often
> file tickets where I have looked into who is most likely to fix it and
> assign it to them.
> >> >
> >> > For example, I need to file a ticket for breakages building
> rtems-examples using waf. And when you build RTEMS using rtems6 tools,
> there are breakages because rtems5 is not replaced with rtems6 is still in
> some places. I reported both I think this week to devel.
> >> >
> >> >> The “open projects” page looks more relevant. I can buy hardware if
> somewhat reasonably priced. Having actual hardware would be somewhat
> preferred, even if qemu is amazing. I can do assembly (most familiar with
> Intel, but open to learning), low-level C down to the hardware, and have
> experience with OS level programming and drivers, serial and network
> transport, debuggers.
> >> >
> >> >
> >> > If that's the direction you want to go in, the x86_64 port and bsp
> are incomplete. There should be plenty of room to get things working. This
> would help ween us off of depending on legacy boot PCs.
> >> >
> >> +1
> >>
> >> And so far few students to work on it, and it is a big area to work on.
> >>
> >> There is also an open project to improve legacy x86:
> >> https://devel.rtems.org/ticket/2900
> >>
> >> >>
> >> >> Is there some priority on the projects? They are all equal, but some
> are more equal than others. I can guess the scope on some of them.
> >> >
> >> >
> >> > For the most part, there isn't much priority. If you ask different
> people, you will likely get different answers.
> >> >
> >> >>
> >> >> Suggestions welcome.
> >> >>
> >> >> John
> >> >> —where there are tools, a will, and a will to build tools there is a
> way
> >> >>
> >> >> _
> >> >>
> >> >> 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
> >> >
> >> > ___
> >> > 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
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Project query

[Gedare Bloom]

On Thu, Feb 20, 2020 at 9:43 AM suyash singh  wrote:
>
> So can I work on x86_64 BSP without hardware with simulator?
> https://devel.rtems.org/ticket/2898
>
> Also out of the prerequisites I only know C programming language but I am 
> ready to learn everything else.
>
I think it will be too hard to work on a new BSP/port without the
assembly programming language experience in that architecture.

I'd suggest you look for projects for which you possess all/most of
the prerequisites (when explicitly stated).

Gedare

> On Thu, Feb 20, 2020 at 9:13 AM Gedare Bloom  wrote:
>>
>> On Wed, Feb 19, 2020 at 6:29 PM Joel Sherrill  wrote:
>> >
>> >
>> >
>> > On Wed, Feb 19, 2020, 6:12 PM John Millard  wrote:
>> >>
>> >> Greetings:
>> >>
>> >> I took Joel’s week-long class in June.
>> >
>> >
>> > :) Thanks. Hope you enjoyed it.
>> >
>> >> I’m currently retired and looking for a project, but clearly not a GSoC 
>> >> guy. The default list of tickets is mostly old or currently assigned.
>> >
>> >
>> > Currently assigned may not mean as much as you think. It is often done by 
>> > someone to direct the ticket to who wrote the code. I know I often file 
>> > tickets where I have looked into who is most likely to fix it and assign 
>> > it to them.
>> >
>> > For example, I need to file a ticket for breakages building rtems-examples 
>> > using waf. And when you build RTEMS using rtems6 tools, there are 
>> > breakages because rtems5 is not replaced with rtems6 is still in some 
>> > places. I reported both I think this week to devel.
>> >
>> >> The “open projects” page looks more relevant. I can buy hardware if 
>> >> somewhat reasonably priced. Having actual hardware would be somewhat 
>> >> preferred, even if qemu is amazing. I can do assembly (most familiar with 
>> >> Intel, but open to learning), low-level C down to the hardware, and have 
>> >> experience with OS level programming and drivers, serial and network 
>> >> transport, debuggers.
>> >
>> >
>> > If that's the direction you want to go in, the x86_64 port and bsp are 
>> > incomplete. There should be plenty of room to get things working. This 
>> > would help ween us off of depending on legacy boot PCs.
>> >
>> +1
>>
>> And so far few students to work on it, and it is a big area to work on.
>>
>> There is also an open project to improve legacy x86:
>> https://devel.rtems.org/ticket/2900
>>
>> >>
>> >> Is there some priority on the projects? They are all equal, but some are 
>> >> more equal than others. I can guess the scope on some of them.
>> >
>> >
>> > For the most part, there isn't much priority. If you ask different people, 
>> > you will likely get different answers.
>> >
>> >>
>> >> Suggestions welcome.
>> >>
>> >> John
>> >> —where there are tools, a will, and a will to build tools there is a way
>> >>
>> >> _
>> >>
>> >> 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
>> >
>> > ___
>> > 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Project query

[Hesham Almatary]

On Wed, 19 Feb 2020 at 21:38, Joel Sherrill  wrote:
>
>
>
> On Wed, Feb 19, 2020, 12:58 PM Gedare Bloom  wrote:
>>
>> On Wed, Feb 19, 2020 at 9:45 AM suyash singh  
>> wrote:
>> >
>> > sorry clicked reply instead of "reply all"
>> >
>> >
>> > I don't have any boards and experience. What interests me about this 
>> > project is that microblaze is used in FPGA which are used in a variety of 
>> > fields like science, medicine and defence. Porting an os to it would be a 
>> > great contribution
>> >
>> Hi Suyash,
>>
>> For any BSP/port development project we require students to have
>> access ahead of time to the hardware they would need to successfully
>> complete the project.  So I don't think the microblaze would be a good
>> project idea for you. I hope you can look for some more ideas that
>> might interest you.
>>
>> Gedare
>>
>> > On Tue, Feb 18, 2020 at 9:30 PM Gedare Bloom  wrote:
>> >>
>> >> Hello Suyash,
>> >>
>> >> On Tue, Feb 18, 2020 at 8:07 AM suyash singh  
>> >> wrote:
>> >> >
>> >> > Hello,
>> >> >
>> >> > I am interested in "Port RTEMS to MicroBlaze"
>> >> > https://devel.rtems.org/ticket/2902
>> >> >
>> >> > How do I start understanding the previous work done and understanding 
>> >> > what else needs to be done?
>> >> >
>> >> Hopefully Hesham or Joel will chime in on their effort.
>> >>
>> >> Do you have one or more Xilinx FPGA boards that you can use? Do you
>> >> have any experience with Microblaze? If not, what interests you about
>> >> this project?
>
>
> Just to toss some info in. Qemu and gdb both have Microblaze simulation. The 
> Qemu should be close enough to real hardware to be suitable for a complete 
> port.
>
> Graham has a repo somewhere with the port in its current state.
>
https://github.com/heshamelmatary/rtems-microblaze

> I think this is likely a viable project with the Qemu simulator.
>
AFAIR, there were licence issues merging this project which copies some of
Xilinx's drivers/code to RTEMS.


> --joel
>
>> >>
>> >> Gedare
>> >>
>> >> > ___
>> >> > devel mailing list
>> >> > devel@rtems.org
>> >> > http://lists.rtems.org/mailman/listinfo/devel
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
> ___
> 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

Re: Project query

[suyash singh]

So can I work on x86_64 BSP without hardware with simulator?
https://devel.rtems.org/ticket/2898

Also out of the prerequisites I only know C programming language but I am
ready to learn everything else.

On Thu, Feb 20, 2020 at 9:13 AM Gedare Bloom  wrote:

> On Wed, Feb 19, 2020 at 6:29 PM Joel Sherrill  wrote:
> >
> >
> >
> > On Wed, Feb 19, 2020, 6:12 PM John Millard  wrote:
> >>
> >> Greetings:
> >>
> >> I took Joel’s week-long class in June.
> >
> >
> > :) Thanks. Hope you enjoyed it.
> >
> >> I’m currently retired and looking for a project, but clearly not a GSoC
> guy. The default list of tickets is mostly old or currently assigned.
> >
> >
> > Currently assigned may not mean as much as you think. It is often done
> by someone to direct the ticket to who wrote the code. I know I often file
> tickets where I have looked into who is most likely to fix it and assign it
> to them.
> >
> > For example, I need to file a ticket for breakages building
> rtems-examples using waf. And when you build RTEMS using rtems6 tools,
> there are breakages because rtems5 is not replaced with rtems6 is still in
> some places. I reported both I think this week to devel.
> >
> >> The “open projects” page looks more relevant. I can buy hardware if
> somewhat reasonably priced. Having actual hardware would be somewhat
> preferred, even if qemu is amazing. I can do assembly (most familiar with
> Intel, but open to learning), low-level C down to the hardware, and have
> experience with OS level programming and drivers, serial and network
> transport, debuggers.
> >
> >
> > If that's the direction you want to go in, the x86_64 port and bsp are
> incomplete. There should be plenty of room to get things working. This
> would help ween us off of depending on legacy boot PCs.
> >
> +1
>
> And so far few students to work on it, and it is a big area to work on.
>
> There is also an open project to improve legacy x86:
> https://devel.rtems.org/ticket/2900
>
> >>
> >> Is there some priority on the projects? They are all equal, but some
> are more equal than others. I can guess the scope on some of them.
> >
> >
> > For the most part, there isn't much priority. If you ask different
> people, you will likely get different answers.
> >
> >>
> >> Suggestions welcome.
> >>
> >> John
> >> —where there are tools, a will, and a will to build tools there is a way
> >>
> >> _
> >>
> >> 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
> >
> > ___
> > 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] drvmgr: Fix determination of prefix in grlib uart driver

[Gedare Bloom]

Yes, I'll push in the next few minutes.

On Thu, Feb 20, 2020 at 1:41 AM  wrote:
>
> Hello,
>
> Could someone please push this change?
> There has been a lot of activity on this list recently, and I fear I will 
> lose track at some point.
>
> Cheers,
>
>Jan
>
> > -Ursprüngliche Nachricht-
> > Von: devel [mailto:devel-boun...@rtems.org] Im Auftrag von Jan Sommer
> > Gesendet: Mittwoch, 12. Februar 2020 15:10
> > An: devel@rtems.org
> > Betreff: [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
> ___
> 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

Re: Error in building rv32imac BSP

[Gedare Bloom]

On Thu, Feb 20, 2020 at 9:23 AM Jiri Gaisler  wrote:
>
>
> On 2/20/20 5:03 PM, Eshan Dhawan wrote:
> >
> > make[3]: Leaving directory
> > '/home/eshan/development/rtems/kernel/rtems/rv32imac/riscv-rtems5/c/rv32imac'
> > checking for RTEMS_CPU_MODEL...
> > checking for RTEMS_BSP_FAMILY... riscv
> > checking for CPU_CFLAGS... (cached) -march=rv32imac -mabi=ilp32
> > checking for CFLAGS_OPTIMIZE_V... (cached) -O2 -g -ffunction-sections
> > -fdata-sections
> > checking for style of include used by make... GNU
> > checking for riscv-rtems5-gcc... no
>
> --^^^-
>
>
> You need to have the RISC-V tool chain in the PATH. If you don't have a
> tool chain, then you can build it with RSB. See the relevant docs on
> rtems.org ...
>

Hello Eshan,

Adding on, please ensure that you have
1. Successfully built and installed the toolchain for riscv-rtems. You
can follow similar steps as the Quick Start shows for sparc, but using
riscv.
2. Make sure the bin subdirectory of the prefix used to install the
toolchain is in your PATH environment variable, e.g.,
 export PATH=${PATH}:/home/eshan/development/rtems/5/bin

This way the installed tools can be found in your PATH.

Gedare

> Jiri.
>
>
>
> ___
> 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

Re: Error in building rv32imac BSP

[Gedare Bloom]

On Thu, Feb 20, 2020 at 9:24 AM Mritunjay Sharma
 wrote:
>
> Hi Eshan,
>
> I think the error here is "no acceptable cc found in $PATH" which means GCC 
> compiler might be missing
>
> Please try to fix it with :
>
> sudo apt install gcc
>
> Or
>
> sudo apt install build-essential
>
> If GCC compiler is already installed, there are chances that symbolic link is 
> missing. In that case you can do
>
> make CC=gcc
>
This won't work, the problem Eshan has is that the cross-compiler for
riscv-rtems is missing.

> Thanks
> Mritunjay
>
> Get Outlook for iOS
> 
> From: devel  on behalf of Eshan Dhawan 
> 
> Sent: Thursday, February 20, 2020 9:33:08 PM
> To: devel@rtems.org 
> Subject: Error in building rv32imac BSP
>
> /home/eshan/development/rtems/kernel/rtems/configure 
> --prefix=/home/eshan/development/rtems/5 --enable-maintainer-mode 
> --target=riscv-rtems5 --enable-rtemsbsp=rv32imac --enable-tests 
> --enable-posix --disable-networking --enable-cxx
>
> I ran this command and it returns the output
> hecking for gmake... no
> checking for make... make
> checking for RTEMS Version... 5.0.0
> checking build system type... x86_64-pc-linux-gnu
> checking host system type... x86_64-pc-linux-gnu
> checking target system type... riscv-unknown-rtems5
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... /bin/mkdir -p
> checking for gawk... no
> checking for mawk... mawk
> checking whether make sets $(MAKE)... yes
> checking whether make supports nested variables... yes
> checking whether to enable maintainer-specific portions of Makefiles... yes
> checking that generated files are newer than configure... done
> configure: creating ./config.status
> configure: configuring in riscv-rtems5/c
> configure: running /bin/bash 
> '/home/eshan/development/rtems/kernel/rtems/c/configure' 
> '--prefix=/home/eshan/development/rtems/5' '--host=riscv-rtems5' 
> '--build=x86_64-pc-linux-gnu' '--target=riscv-rtems5'  
> '--enable-maintainer-mode' '--enable-rtemsbsp=rv32imac' '--enable-tests' 
> '--enable-posix' '--disable-networking' '--enable-cxx' 
> '--with-target-subdir=riscv-rtems5' 
> '--exec-prefix=/home/eshan/development/rtems/5/riscv-rtems5' 
> '--includedir=/home/eshan/development/rtems/5/riscv-rtems5/include'  
> '--cache-file=/dev/null' 
> '--srcdir=/home/eshan/development/rtems/kernel/rtems/c'
> checking for gmake... no
> checking for make... make
> checking for RTEMS Version... 5.0.0
> checking build system type... x86_64-pc-linux-gnu
> checking host system type... riscv-unknown-rtems5
> checking target system type... riscv-unknown-rtems5
> checking rtems target cpu... riscv
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for riscv-rtems5-strip... no
> checking for strip... strip
> configure: WARNING: using cross tools not prefixed with host triplet
> checking for a thread-safe mkdir -p... /bin/mkdir -p
> checking for gawk... no
> checking for mawk... mawk
> checking whether make sets $(MAKE)... yes
> checking whether make supports nested variables... yes
> checking whether to enable maintainer-specific portions of Makefiles... yes
> checking that generated files are newer than configure... done
> configure: creating ./config.status
> config.status: creating Makefile
>
> target architecture: riscv.
> available BSPs: rv32imac.
> 'make all' will build the following BSPs: rv32imac.
> other BSPs can be built with 'make RTEMS_BSP="bsp1 bsp2 ..."'
>
> config.status: creating Makefile
>
>
> But as I run the make command it shows error :
>
> Making all in riscv-rtems5/c
> make[1]: Entering directory 
> '/home/eshan/development/rtems/kernel/rtems/rv32imac/riscv-rtems5/c'
> Making all in .
> make[2]: Entering directory 
> '/home/eshan/development/rtems/kernel/rtems/rv32imac/riscv-rtems5/c'
> Configuring RTEMS_BSP=rv32imac
> checking for gmake... no
> checking for make... make
> checking build system type... x86_64-pc-linux-gnu
> checking host system type... riscv-unknown-rtems5
> checking rtems target cpu... riscv
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for riscv-rtems5-strip... no
> checking for strip... strip
> configure: WARNING: using cross tools not prefixed with host triplet
> checking for a thread-safe mkdir -p... /bin/mkdir -p
> checking for gawk... no
> checking for mawk... mawk
> checking whether make sets $(MAKE)... yes
> checking whether make supports nested variables... yes
> checking whether to enable maintainer-specific portions of Makefiles... yes
> checking for RTEMS_BSP... rv32imac
> checking whether CPU supports libposix... yes
> configure: setting up make/custom
> configure: creating make/rv32imac.cache
> make[3]: Entering directory 
> '/home/eshan/development/rtems/kernel/rtems/rv32imac/riscv-rtems5/c/rv32imac'
> 

Re: Error in building rv32imac BSP

[Mritunjay Sharma]

Hi Eshan,

I think the error here is "no acceptable cc found in $PATH" which means GCC 
compiler might be missing

Please try to fix it with :

sudo apt install gcc

Or

sudo apt install build-essential

If GCC compiler is already installed, there are chances that symbolic link is 
missing. In that case you can do

make CC=gcc

Thanks
Mritunjay

Get Outlook for iOS

From: devel  on behalf of Eshan Dhawan 

Sent: Thursday, February 20, 2020 9:33:08 PM
To: devel@rtems.org 
Subject: Error in building rv32imac BSP

/home/eshan/development/rtems/kernel/rtems/configure 
--prefix=/home/eshan/development/rtems/5 --enable-maintainer-mode 
--target=riscv-rtems5 --enable-rtemsbsp=rv32imac --enable-tests --enable-posix 
--disable-networking --enable-cxx

I ran this command and it returns the output
hecking for gmake... no
checking for make... make
checking for RTEMS Version... 5.0.0
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... riscv-unknown-rtems5
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
configure: configuring in riscv-rtems5/c
configure: running /bin/bash 
'/home/eshan/development/rtems/kernel/rtems/c/configure' 
'--prefix=/home/eshan/development/rtems/5' '--host=riscv-rtems5' 
'--build=x86_64-pc-linux-gnu' '--target=riscv-rtems5'  
'--enable-maintainer-mode' '--enable-rtemsbsp=rv32imac' '--enable-tests' 
'--enable-posix' '--disable-networking' '--enable-cxx' 
'--with-target-subdir=riscv-rtems5' 
'--exec-prefix=/home/eshan/development/rtems/5/riscv-rtems5' 
'--includedir=/home/eshan/development/rtems/5/riscv-rtems5/include'  
'--cache-file=/dev/null' '--srcdir=/home/eshan/development/rtems/kernel/rtems/c'
checking for gmake... no
checking for make... make
checking for RTEMS Version... 5.0.0
checking build system type... x86_64-pc-linux-gnu
checking host system type... riscv-unknown-rtems5
checking target system type... riscv-unknown-rtems5
checking rtems target cpu... riscv
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for riscv-rtems5-strip... no
checking for strip... strip
configure: WARNING: using cross tools not prefixed with host triplet
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile

target architecture: riscv.
available BSPs: rv32imac.
'make all' will build the following BSPs: rv32imac.
other BSPs can be built with 'make RTEMS_BSP="bsp1 bsp2 ..."'

config.status: creating Makefile


But as I run the make command it shows error :

Making all in riscv-rtems5/c
make[1]: Entering directory 
'/home/eshan/development/rtems/kernel/rtems/rv32imac/riscv-rtems5/c'
Making all in .
make[2]: Entering directory 
'/home/eshan/development/rtems/kernel/rtems/rv32imac/riscv-rtems5/c'
Configuring RTEMS_BSP=rv32imac
checking for gmake... no
checking for make... make
checking build system type... x86_64-pc-linux-gnu
checking host system type... riscv-unknown-rtems5
checking rtems target cpu... riscv
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for riscv-rtems5-strip... no
checking for strip... strip
configure: WARNING: using cross tools not prefixed with host triplet
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... yes
checking for RTEMS_BSP... rv32imac
checking whether CPU supports libposix... yes
configure: setting up make/custom
configure: creating make/rv32imac.cache
make[3]: Entering directory 
'/home/eshan/development/rtems/kernel/rtems/rv32imac/riscv-rtems5/c/rv32imac'
make[3]: Leaving directory 
'/home/eshan/development/rtems/kernel/rtems/rv32imac/riscv-rtems5/c/rv32imac'
checking for RTEMS_CPU_MODEL...
checking for RTEMS_BSP_FAMILY... riscv
checking for CPU_CFLAGS... (cached) -march=rv32imac -mabi=ilp32
checking for CFLAGS_OPTIMIZE_V... (cached) -O2 -g -ffunction-sections 
-fdata-sections
checking for style of include used by 

Re: Error in building rv32imac BSP

[Jiri Gaisler]

On 2/20/20 5:03 PM, Eshan Dhawan wrote:
>
> make[3]: Leaving directory
> '/home/eshan/development/rtems/kernel/rtems/rv32imac/riscv-rtems5/c/rv32imac'
> checking for RTEMS_CPU_MODEL...
> checking for RTEMS_BSP_FAMILY... riscv
> checking for CPU_CFLAGS... (cached) -march=rv32imac -mabi=ilp32
> checking for CFLAGS_OPTIMIZE_V... (cached) -O2 -g -ffunction-sections
> -fdata-sections
> checking for style of include used by make... GNU
> checking for riscv-rtems5-gcc... no

--^^^-


You need to have the RISC-V tool chain in the PATH. If you don't have a
tool chain, then you can build it with RSB. See the relevant docs on
rtems.org ...

Jiri.



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

Re: SPDX License Identifier Only and Full Copy?

[Gedare Bloom]

On Thu, Feb 20, 2020 at 12:58 AM Thomas Doerfler
 wrote:
>
> Hello,
>
> I just want to speak up here. I talked with Sebastian today and I really
> tend to keep the license text in each file.
>
> Rational:
>
> - With the BSD license, anyone can pick any file from the RTEMS repo and
> use/modify it in any project (and this is fine). The original authors
> (and their copyright) are listed in the file, but the only pointer to
> the legal part is the "SPDX identifier". I am not sure whether this is a
> legally binding "tag" and whether this tag is clear to any user.
>
> - Strictly seen, it is not even forbidden to remove the "SPDX
> identifier", because it is not part of the BSD-2-clause-license, it's
> just a pointer to it. In the end we might result in code drifting around
> without license information, which we all do not want to see.
>
This is a valid point. I also have no desire to be a lawyer.

My intuition here is that, even without any licensing information at
all in individual files, one can still apply a single license to an
entire repository, e.g., BSD or GPL. For historical reasons, and
similar arguments as you've made, BSD-style licenses have tended to be
copy-pasted to individual files to make them easier to excerpt. We
don't have license uniformity, so we do need to individually specify
which license(s) apply to each file.

Linux follows a similar philosophy as Sebastian suggests. I think we
can also follow Linux in this regards.
https://www.kernel.org/doc/html/latest/process/license-rules.html

I would suggest we follow their approach to self-document the licenses
centrally. I suspect the risk of someone using code without adhering
to the license is no greater. Probably they have a higher risk
exposure than we do!

> As you all know I am not a lawyer (and don't want to be), but my gut
> say's the extra lines in the top of each file are worth their storage.
> And anybody opening a RTEMS source file (even when it has been taken to
> a different project) should see what he has.
>
> -
>
> If you have different reasons to replace the header and just leave the
> identifier I a will go with it and it's fine for me. But my tendency
> is... leave it in.
>
> Kind regards,
>
> Thomas.
>
> Am 20.02.20 um 08:30 schrieb Sebastian Huber:
> > Hello,
> >
> > On 18/02/2020 16:58, Gedare Bloom wrote:
> > I suggest to use a master COPYING file and use file headers without
> > the
> > full license text.
> >
> > https://lists.rtems.org/pipermail/devel/2018-December/024198.html
>  It would be nice to get some feedback here.
> >>>
> >>> I'm generally ok with just the spdx and copyright statements.
> >>>
> >> I'm also fine with the master COPYING, spdx-tag, and individual
> >> copyrights in files.
> >>
> >> I should make a note to take a pass over "my" files to relicense them.
> >> Does anyone have any script/tools for making that easy?
> >
> > I talked with Thomas and he is not in favour of a removal of the licence
> > text. Not everyone knows what an SPDX-Licence-Identifier is and that
> > this means the file is covered by the reference license. The
> > BSD-2-Clause license text is quite clear and not long. For us it is
> > important that it is very clear that our contributions are without
> > warranties and so on. This information should be also clear if files are
> > transferred out of the RTEMS context to other projects.
> >
>
> --
> 
> embedded brains GmbH
> Thomas Doerfler
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: thomas.doerf...@embedded-brains.de
> Phone: +49-89-18 94 741-12
> Fax:   +49-89-18 94 741-09
> PGP: Public key available on request.
> For our privacy statement, see
> https://embedded-brains.de/en/data-privacy-statement/
> ___
> 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

Error in building rv32imac BSP

[Eshan Dhawan]

/home/eshan/development/rtems/kernel/rtems/configure
--prefix=/home/eshan/development/rtems/5 --enable-maintainer-mode
--target=riscv-rtems5 --enable-rtemsbsp=rv32imac --enable-tests
--enable-posix --disable-networking --enable-cxx

I ran this command and it returns the output
hecking for gmake... no
checking for make... make
checking for RTEMS Version... 5.0.0
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... riscv-unknown-rtems5
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
configure: configuring in riscv-rtems5/c
configure: running /bin/bash
'/home/eshan/development/rtems/kernel/rtems/c/configure'
'--prefix=/home/eshan/development/rtems/5' '--host=riscv-rtems5'
'--build=x86_64-pc-linux-gnu' '--target=riscv-rtems5'
 '--enable-maintainer-mode' '--enable-rtemsbsp=rv32imac' '--enable-tests'
'--enable-posix' '--disable-networking' '--enable-cxx'
'--with-target-subdir=riscv-rtems5'
'--exec-prefix=/home/eshan/development/rtems/5/riscv-rtems5'
'--includedir=/home/eshan/development/rtems/5/riscv-rtems5/include'
 '--cache-file=/dev/null'
'--srcdir=/home/eshan/development/rtems/kernel/rtems/c'
checking for gmake... no
checking for make... make
checking for RTEMS Version... 5.0.0
checking build system type... x86_64-pc-linux-gnu
checking host system type... riscv-unknown-rtems5
checking target system type... riscv-unknown-rtems5
checking rtems target cpu... riscv
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for riscv-rtems5-strip... no
checking for strip... strip
configure: WARNING: using cross tools not prefixed with host triplet
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile

target architecture: riscv.
available BSPs: rv32imac.
'make all' will build the following BSPs: rv32imac.
other BSPs can be built with 'make RTEMS_BSP="bsp1 bsp2 ..."'

config.status: creating Makefile


But as I run the make command it shows error :

Making all in riscv-rtems5/c
make[1]: Entering directory
'/home/eshan/development/rtems/kernel/rtems/rv32imac/riscv-rtems5/c'
Making all in .
make[2]: Entering directory
'/home/eshan/development/rtems/kernel/rtems/rv32imac/riscv-rtems5/c'
Configuring RTEMS_BSP=rv32imac
checking for gmake... no
checking for make... make
checking build system type... x86_64-pc-linux-gnu
checking host system type... riscv-unknown-rtems5
checking rtems target cpu... riscv
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for riscv-rtems5-strip... no
checking for strip... strip
configure: WARNING: using cross tools not prefixed with host triplet
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... yes
checking for RTEMS_BSP... rv32imac
checking whether CPU supports libposix... yes
configure: setting up make/custom
configure: creating make/rv32imac.cache
make[3]: Entering directory
'/home/eshan/development/rtems/kernel/rtems/rv32imac/riscv-rtems5/c/rv32imac'
make[3]: Leaving directory
'/home/eshan/development/rtems/kernel/rtems/rv32imac/riscv-rtems5/c/rv32imac'
checking for RTEMS_CPU_MODEL...
checking for RTEMS_BSP_FAMILY... riscv
checking for CPU_CFLAGS... (cached) -march=rv32imac -mabi=ilp32
checking for CFLAGS_OPTIMIZE_V... (cached) -O2 -g -ffunction-sections
-fdata-sections
checking for style of include used by make... GNU
checking for riscv-rtems5-gcc... no
configure: error: no acceptable cc found in $PATH
Makefile:780: recipe for target 'rv32imac' failed
make[2]: *** [rv32imac] Error 1
make[2]: Leaving directory
'/home/eshan/development/rtems/kernel/rtems/rv32imac/riscv-rtems5/c'
Makefile:362: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
'/home/eshan/development/rtems/kernel/rtems/rv32imac/riscv-rtems5/c'
Makefile:482: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1

help needed


--Eshan Dhawan

Waf Build System Status in RTEMS?

[Hesham Almatary]

Hello,

Are there any progress updates to the Waf build system integration in RTEMS?

I have pulled [1] and it seems like it hasn't got many updates since
December. I wonder what's still remaining/blocking to merge it, or at
least push it as a development branch (without re-writing history)
that others, including me, can use it and submit patches against.

[1] git://git.rtems.org/sebh/rtems.git

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

Re: Status of implementation of fenv.h test suites

[Joel Sherrill]

On Thu, Feb 20, 2020 at 2:33 AM Vaibhav Gupta 
wrote:

>
>
> On Thu, Feb 20, 2020, 12:47 PM Eshan Dhawan 
> wrote:
>
>> Hello
>>  The current fenv.h test suite  supports only basic functions that check
>> that fenv.h environment is present or not
>> I would like to extend the test suite further
>> What more functions can be added to it.
>>
> Test all the functions of fenv.h:
> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/fenv.h.html
>

Here is the FreeBSD test.

http://web.mit.edu/freebsd/head/tools/regression/lib/msun/test-fenv.c

It needs to account for not having the functionality at least.


>
>
> -- Vaibhav Gupta
>
>>
>> -Eshan Dhawan
>> ___
>> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

AW: [PATCH] drvmgr: Fix determination of prefix in grlib uart driver

[Jan.Sommer]

Hello,

Could someone please push this change?
There has been a lot of activity on this list recently, and I fear I will lose 
track at some point.

Cheers,

   Jan

> -Ursprüngliche Nachricht-
> Von: devel [mailto:devel-boun...@rtems.org] Im Auftrag von Jan Sommer
> Gesendet: Mittwoch, 12. Februar 2020 15:10
> An: devel@rtems.org
> Betreff: [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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Status of implementation of fenv.h test suites

[Vaibhav Gupta]

On Thu, Feb 20, 2020, 12:47 PM Eshan Dhawan  wrote:

> Hello
>  The current fenv.h test suite  supports only basic functions that check
> that fenv.h environment is present or not
> I would like to extend the test suite further
> What more functions can be added to it.
>
Test all the functions of fenv.h:
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/fenv.h.html

-- Vaibhav Gupta

>
> -Eshan Dhawan
> ___
> 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 v3] eng: Rework file template section

[Sebastian Huber]

Update #3053.
---
v2:

Clarify COPYING update and placeholders.

v3:

* Prefer verbatim licence texts.
* Add Python file template.

 eng/coding-file-hdr.rst | 251 ++--
 1 file changed, 221 insertions(+), 30 deletions(-)

diff --git a/eng/coding-file-hdr.rst b/eng/coding-file-hdr.rst
index c724c5d..b7f08b0 100644
--- a/eng/coding-file-hdr.rst
+++ b/eng/coding-file-hdr.rst
@@ -1,45 +1,236 @@
 .. SPDX-License-Identifier: CC-BY-SA-4.0
 
-.. Copyright (C) 2018.
-.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
+.. Copyright (C) 2018, 2020 embedded brains GmbH
+..  (https://www.embedded-brains.de)
+.. Copyright (C) 2018, 2020 Sebastian Huber
 
-.. COMMENT:TBD - Convert the following to Rest and insert into this file
-.. COMMENT:TBD - 
https://devel.rtems.org/wiki/Developer/Coding/Boilerplate_File_Header
+File Templates
+==
 
+Every file shall have a copyright and license comment block.  C/C++ files 
should
+have a Doxygen file comment block.
 
-Boilerplate File Header
-===
+The preferred licence for new source code is
+`BSD-2-Clause `_.
 
-Every file should include two comment header blocks, one for the Doxygen
-output and a copyright notice.  This is a typical example:
+.. _FileHeaderCopyright:
+
+Copyright and License Comment Block
+---
+
+You are the copyright holder.  Copy the comment below the top of the file in
+which you want to use this license for your contribution.  Replace the
+ placeholder with the year of your first substantial contribution 
to
+this file.  Update the  with the year of your last substantial
+contribution to this file.  If the first and last years are the same, then
+remove the  placeholder with the comma.  Replace the
+ placeholder with your name.
+
+In case you are a real person, then use the following format for
+:   .  The 
+is your first name (also known as given name), the  are your
+optional middle names, the  is your last name (also known as family
+name).
+
+If more than one copyright holder exists for a file, then sort the copyright
+lines by the first year (earlier years are below later years) followed by the
+copyright holder in alphabetical order (A is above B in the file).
+
+Use the following template for a copyright and license comment block.  Do not
+change the licence text.
+
+.. code-block:: none
+
+ SPDX-License-Identifier: BSD-2-Clause
+
+ Copyright (C) ,  
+
+ Redistribution and use in source and binary forms, with or without
+ modification, are permitted provided that the following conditions
+ are met:
+ 1. Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+ 2. Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in the
+documentation and/or other materials provided with the distribution.
+
+ THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
IS"
+ AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ POSSIBILITY OF SUCH DAMAGE.
+
+Check the top-level :file:`COPYING` file of the repository.  If you are a new
+copyright holder, then add yourself to the top of the list.  If your last year
+of a substantial contribution changed, then please update your copyright line.
+
+C/C++ Header File Template
+--
+
+Use the following guidelines and template for C and C++ header files (here
+:file:``):
+
+* Place the copyright and license comment block to the top of the file.
+
+* For the , , and  placeholders see
+  :ref:`FileHeaderCopyright`.
+
+* Use exactly one blank line between the copyright and licence comment block 
and
+  the Doxygen comment block.
+
+* Separate the Doxygen comment block from the copyright and license, so that
+  the copyright and license information is not included in the Doxygen output.
+
+* For C++ header files discard the extern "C".
 
 .. code-block:: c
 
-  /**
-   * @file
-   *
-   * @ingroup TheGroupForThisFile
-   *
-   * @brief Short "Table of Contents" Description of File Contents
-   *
-   * A short description of the purpose of this file.
-   */
+/*
+