Re: GSOC project: #4272 BSP Executable Conversion

[Ayushman Mishra]

Boot-loader is used to initialize the hardware device , but is there
any way to simulate the boot-loader without hardware?.
And I suppose the command "rtems-boot-image" performs somewhat similar
function to one of the objective of this project "This project is
about capturing the commands and logic needed to convert the RTEMS
executable format to the BSP boot loader format"  ( 3rd point of "The
boot image tool can:"
https://docs.rtems.org/branches/master/user/tools/boot-image.html)

Also I think potential mentors of this project are Chris Johns and
Joel Sherrill , please correct me if I'm wrong.

On Sun, Apr 4, 2021 at 10:27 PM Ayushman Mishra
 wrote:
>
> Respected Sir,
> I went through project description https://devel.rtems.org/ticket/4272
> (BSP Executable Conversion) and wanted to take it as GSOC project.
> I know python programming ,shell scripting and after working a little
> bit on project #4334 "Replace Mongoose with Civetweb" (in which I am
> not able to proceed further) I have gained some knowledge about bsp
> build system in rtems6.
> I have already build tools and bsp xilinx_zynq_a9_qemu  on rtems5 and
> rtems6 and package libbsd for bsp erc32 and xilinx_zynq_a9_qemu.
>
> Also, I have a few doubts regarding project "BSP Executable Conversion" :
> 1. In description its written to make a command "rtems-exe-convert" ,
> I wanted to ask what will be the actual function of this command like
> after capturing the commands and logic for converting 'RTEMS
> executable format' will it create a boot-loader for specific bsp and
> provide it with 'RTEMS executable format' ?,
> and also I wanted to ask what is need for this command (or this
> project in general) and how will it affect the present building
> procedure of rtems?
> (like first building the specific tools then installing the particular bsp)
>
> 2. I have build 2 BSP in simulation but wanted to ask are all BSPs
> available in rtems able to perfectly build in simulation or do I need
> some specific hardware for any BSP.
> I would be very thankful if you can please clarify my above doubts and
> provide a little guidance about this project.
> Thanks, Ayushman
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-docs v2 1/2] Added FAQ page

[Chris Johns]

On 4/4/21 1:30 pm, Ayushman Mishra wrote:
> Using "-" makes H4 size headings
> (https://documentation-style-guide-sphinx.readthedocs.io/en/latest/style-guide.html#headings).
> 
> Could there be a single FAQ section and then internal references, ie
> links? : Does it mean making separate .rst pages for each question
> (whose answers were previously written in faq page) and the reader
> will only see hyper-link questions , and regarding cross-link
> questions written single line example: " Please refer section
> "Creating a Patch" of RTEMS Software Engineering manual in
> https://docs.rtems.org/ ".

A single faq.rst is fine. Can there be a single single section and in that you
create anchors and links to them without having section headers?

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

Uncrustify Configuration vs RTEMS Coding Style

[Joel Sherrill]

Hi Sebastian,

Do you have a list or remember where uncrustify could not match the RTEMS
Coding Style?

Thanks.

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

Re: #3860 - GSoC enquiries

[Joel Sherrill]

On Sun, Apr 4, 2021 at 2:25 PM Ida Delphine  wrote:

> Hello,
>
> Please who are the possible mentors for this project?
>

IMO this is a project which has a larger potential potential set of mentors
than
one focused on say a single board.

>
> On Sun, 4 Apr 2021, 3:32 am Ida Delphine,  wrote:
>
>> Regarding adding a script similar to linux/checkpatch.pl the criteria
>> whether patches should need changes before being applied will be based on
>> the output from running uncrustify right?
>>
>
Yes. Assuming we find a combination of uncrustify settings combined with
changes to the RTEMS style and changes to uncrustify that put us in a place
where we trust that the output wth the right settings matches our style.

That is your goal. Find changes to the settlngs, uncrustify, and RTEMS code
style where automated checking is possible. When you find a place where the
coding style requires something uncrustify cannot currently do, the
question is uncrustify changed or our coding style?

Sebastian may have a list of some of those from his effort to create that
configuration. But addressing the list of where the tooling and style guide
do not align is a key part of your project.

--joel


>> On Sat, Apr 3, 2021 at 2:32 AM Gedare Bloom  wrote:
>>
>>> On Fri, Apr 2, 2021 at 6:09 PM Joel Sherrill  wrote:
>>> >
>>> >
>>> >
>>> > On Fri, Apr 2, 2021, 6:59 PM Gedare Bloom  wrote:
>>> >>
>>> >> On Fri, Apr 2, 2021 at 4:48 PM Ida Delphine 
>>> wrote:
>>> >> >
>>> >> > Hello,
>>> >> > Please can you help explain what you mean by Adding a "check-style"
>>> target to the RTEMS build system?
>>> >> > And how I could possibly go about this?
>>> >> >
>>> >> I don't know if this makes sense exactly to me.  When compiling RTEMS
>>> >> it could be nice to have an option to check the style rules for
>>> >> compliance. This would be something to integrate in the
>>> >> rtems.git/wscript file most likely, as part of the waf build system.
>>> >> However, since checking style does not generate a target file, I don't
>>> >> know that this really is suitable as a way to verify style rules. It
>>> >> may be suitable to add a standalone script in rtems-tools.git that can
>>> >> be run over the rtems.git that creates a report about style problems.
>>> >> Maybe, a way to configure it to ignore some files or to add exceptions
>>> >> to the style rules for certain cases then could be possible.
>>> >
>>> >
>>> > If you have a configuration that produces the code formatted as
>>> expected in certain directories, then if a change is made as part of normal
>>> development, running uncrustify will result in changes to the file needed.
>>> In a way the goal is to have a directory full of files that an RTEMS
>>> uncrustify configuration does not change.
>>> >
>>> > If you have a script that can do that manually then we can easily add
>>> an automated check somewhere in the process to ensure that directories that
>>> adhere to the style rules continue to adhere to them.
>>> >
>>> > One thing to keep in mind is that there there are places where
>>> uncrustify does not have the ability to format code the way RTEMS has
>>> historically done it. we want the rules to be as close as possible to the
>>> existing practice but we are willing to adjust practice if it allows the
>>> tool to produce formatted output we can trust.
>>> >
>>> Also on the table could be modifications to uncrustify.
>>>
>>> > On each point where this type of issue occurs, we'll have to have a
>>> discussion about our Style versus what tool supports. It's likely indicates
>>> we're doing something that's not common in the open source world.
>>> >
>>> > Once the delta between the output of uncrustify and the committed
>>> source is zero, running uncrustify should produce no changes. Anything
>>> uncrustify wants to change at that point would be a style violation and
>>> flagged. In a perfect world it would prevent you from committing.
>>> >
>>> >>
>>> >>
>>> >> I think focus on 1 and 3 is better as a way to start, and perhaps
>>> >> something like the above can be the phase 2 effort.
>>> >>
>>> >> Gedare
>>> >>
>>> >> > Cheers,
>>> >> > Ida
>>> >> >
>>> >> > On Mon, Mar 29, 2021 at 9:45 PM Gedare Bloom 
>>> wrote:
>>> >> >>
>>> >> >> On Mon, Mar 29, 2021 at 1:28 PM Ida Delphine 
>>> wrote:
>>> >> >> >
>>> >> >> > Yes I have. But wondering how to run it with the given
>>> configuration I saw in this thread(
>>> https://lists.rtems.org/pipermail/devel/2020-October/062770.html).
>>> >> >> >
>>> >> >>
>>> >> >> If you download/copy the configuration into a cfg file, then you
>>> can
>>> >> >> use the examples from
>>> >> >> https://github.com/uncrustify/uncrustify#running-the-program and
>>> >> >> attempt to run it on some files within rtems.git/cpukit/score/src
>>> >> >> would be my suggestion.
>>> >> >>
>>> >> >> > On Mon, Mar 29, 2021 at 3:37 PM Gedare Bloom 
>>> wrote:
>>> >> >> >>
>>> >> >> >> Hi Ida,
>>> >> >> >>
>>> >> >> >> On Mon, Mar 29, 2021 at 7:36 AM Ida Delphine 
>>> wrote:
>>> 

Re: #3860 - GSoC enquiries

[Ida Delphine]

Hello,

Please who are the possible mentors for this project?

On Sun, 4 Apr 2021, 3:32 am Ida Delphine,  wrote:

> Regarding adding a script similar to linux/checkpatch.pl the criteria
> whether patches should need changes before being applied will be based on
> the output from running uncrustify right?
>
> On Sat, Apr 3, 2021 at 2:32 AM Gedare Bloom  wrote:
>
>> On Fri, Apr 2, 2021 at 6:09 PM Joel Sherrill  wrote:
>> >
>> >
>> >
>> > On Fri, Apr 2, 2021, 6:59 PM Gedare Bloom  wrote:
>> >>
>> >> On Fri, Apr 2, 2021 at 4:48 PM Ida Delphine  wrote:
>> >> >
>> >> > Hello,
>> >> > Please can you help explain what you mean by Adding a "check-style"
>> target to the RTEMS build system?
>> >> > And how I could possibly go about this?
>> >> >
>> >> I don't know if this makes sense exactly to me.  When compiling RTEMS
>> >> it could be nice to have an option to check the style rules for
>> >> compliance. This would be something to integrate in the
>> >> rtems.git/wscript file most likely, as part of the waf build system.
>> >> However, since checking style does not generate a target file, I don't
>> >> know that this really is suitable as a way to verify style rules. It
>> >> may be suitable to add a standalone script in rtems-tools.git that can
>> >> be run over the rtems.git that creates a report about style problems.
>> >> Maybe, a way to configure it to ignore some files or to add exceptions
>> >> to the style rules for certain cases then could be possible.
>> >
>> >
>> > If you have a configuration that produces the code formatted as
>> expected in certain directories, then if a change is made as part of normal
>> development, running uncrustify will result in changes to the file needed.
>> In a way the goal is to have a directory full of files that an RTEMS
>> uncrustify configuration does not change.
>> >
>> > If you have a script that can do that manually then we can easily add
>> an automated check somewhere in the process to ensure that directories that
>> adhere to the style rules continue to adhere to them.
>> >
>> > One thing to keep in mind is that there there are places where
>> uncrustify does not have the ability to format code the way RTEMS has
>> historically done it. we want the rules to be as close as possible to the
>> existing practice but we are willing to adjust practice if it allows the
>> tool to produce formatted output we can trust.
>> >
>> Also on the table could be modifications to uncrustify.
>>
>> > On each point where this type of issue occurs, we'll have to have a
>> discussion about our Style versus what tool supports. It's likely indicates
>> we're doing something that's not common in the open source world.
>> >
>> > Once the delta between the output of uncrustify and the committed
>> source is zero, running uncrustify should produce no changes. Anything
>> uncrustify wants to change at that point would be a style violation and
>> flagged. In a perfect world it would prevent you from committing.
>> >
>> >>
>> >>
>> >> I think focus on 1 and 3 is better as a way to start, and perhaps
>> >> something like the above can be the phase 2 effort.
>> >>
>> >> Gedare
>> >>
>> >> > Cheers,
>> >> > Ida
>> >> >
>> >> > On Mon, Mar 29, 2021 at 9:45 PM Gedare Bloom 
>> wrote:
>> >> >>
>> >> >> On Mon, Mar 29, 2021 at 1:28 PM Ida Delphine 
>> wrote:
>> >> >> >
>> >> >> > Yes I have. But wondering how to run it with the given
>> configuration I saw in this thread(
>> https://lists.rtems.org/pipermail/devel/2020-October/062770.html).
>> >> >> >
>> >> >>
>> >> >> If you download/copy the configuration into a cfg file, then you can
>> >> >> use the examples from
>> >> >> https://github.com/uncrustify/uncrustify#running-the-program and
>> >> >> attempt to run it on some files within rtems.git/cpukit/score/src
>> >> >> would be my suggestion.
>> >> >>
>> >> >> > On Mon, Mar 29, 2021 at 3:37 PM Gedare Bloom 
>> wrote:
>> >> >> >>
>> >> >> >> Hi Ida,
>> >> >> >>
>> >> >> >> On Mon, Mar 29, 2021 at 7:36 AM Ida Delphine 
>> wrote:
>> >> >> >> >
>> >> >> >> > Hello,
>> >> >> >> > Please do you mind telling me how to run uncrustify with the
>> given configuration with any sample file?
>> >> >> >>
>> >> >> >> What have you tried? Any directions followed/attempted or notes
>> that
>> >> >> >> you have taken would be helpful.
>> >> >> >>
>> >> >> >> I guess all the info that you should need is in Uncrustify's
>> readme
>> >> >> >> file. https://github.com/uncrustify/uncrustify
>> >> >> >>
>> >> >> >> Did you successfully compile uncrustify tool?
>> >> >> >>
>> >> >> >> > I'm a bit stuck.
>> >> >> >> >
>> >> >> >> > Thanks,
>> >> >> >> > Ida.
>> >> >> >> >
>> >> >> >> > On Wed, Mar 17, 2021 at 10:34 PM Gedare Bloom <
>> ged...@rtems.org> wrote:
>> >> >> >> >>
>> >> >> >> >> On Wed, Mar 17, 2021 at 2:28 PM Ida Delphine <
>> idad...@gmail.com> wrote:
>> >> >> >> >> >
>> >> >> >> >> > Hello,
>> >> >> >> >> > So I have gone through this configuration file and I think
>> I'm getting it. However I'm a bit lost in 

Re: GSoC 2021 - Raspberry Pi projects

[Pranav Dangi]

In addition to the previous mail, i've completed the basic Hello task. If a
mentor who has previously worked on the raspberry pi bsp could let me know
if the ticket is obsolete or not, I can immediately get started with the
required work on it.

On Fri, 2 Apr 2021, 14:35 Pranav Dangi,  wrote:

> Hi everyone,
> I am keen on working on the Raspberry Pi project #2899
> . However, the ticket and also the
> TODOs in the github README
>  for the
> same haven't been updated since 4 years, so I am not sure what work needs
> to be done specifically. For example, the README lists support for SPI and
> GPIO in TODO but apparently support for them has already been added.
> Moreover given the smaller GSoC, I'd like a mentor to elaborate on the
> potential scope of the project.
> From what I could understand so far, I think I can continue/complete the
> previous GSoC projects(the situation seems fine on drivers for the initial
> Pis), or work on the support for Pi 3 or 4.
> PS: I only have spare Pi Zeroes at home, so I'll be getting the hardware
> for the specific project this week depending on what aspect I have to work
> on.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

GSOC project: #4272 BSP Executable Conversion

[Ayushman Mishra]

Respected Sir,
I went through project description https://devel.rtems.org/ticket/4272
(BSP Executable Conversion) and wanted to take it as GSOC project.
I know python programming ,shell scripting and after working a little
bit on project #4334 "Replace Mongoose with Civetweb" (in which I am
not able to proceed further) I have gained some knowledge about bsp
build system in rtems6.
I have already build tools and bsp xilinx_zynq_a9_qemu  on rtems5 and
rtems6 and package libbsd for bsp erc32 and xilinx_zynq_a9_qemu.

Also, I have a few doubts regarding project "BSP Executable Conversion" :
1. In description its written to make a command "rtems-exe-convert" ,
I wanted to ask what will be the actual function of this command like
after capturing the commands and logic for converting 'RTEMS
executable format' will it create a boot-loader for specific bsp and
provide it with 'RTEMS executable format' ?,
and also I wanted to ask what is need for this command (or this
project in general) and how will it affect the present building
procedure of rtems?
(like first building the specific tools then installing the particular bsp)

2. I have build 2 BSP in simulation but wanted to ask are all BSPs
available in rtems able to perfectly build in simulation or do I need
some specific hardware for any BSP.
I would be very thankful if you can please clarify my above doubts and
provide a little guidance about this project.
Thanks, Ayushman
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: How to build and run RTEMS Shell

[Joel Sherrill]

On Sun, Apr 4, 2021, 4:38 AM Eshan Dhawan  wrote:

> Hello Everyone,
> How Do I build RTEMS Shell over sparc/leon3 ??
>

It is always built and the sample fileio is a good program to use it with.

There are also examples in libbsd.

--joel


> --
> Thanks
> - Eshan
> ___
> 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

How to build and run RTEMS Shell

[Eshan Dhawan]

Hello Everyone,
How Do I build RTEMS Shell over sparc/leon3 ??

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