Gsoc Proposal : Packaging Programming Language Draft 2

[Eshan Dhawan]

Hello Everyone,
I have tried to implement the received feedback on draft 1 into this draft.
I would like everyone to look into this and tell how the proposal can be
improved further.

Link:
https://docs.google.com/document/d/1J4J114C3CrCKEV2L5vgobT-mE0f2xQx2waJTrQ0tNLQ/edit?usp=sharing


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

Re: GSOC project: #4272 BSP Executable Conversion

[Ayushman Mishra]

Hello everyone ,
I am working on project "BSP Executable Conversion"
(https://devel.rtems.org/ticket/4272) where I have to make BSP
specific script for conversion of executables from RTEMS executable
format to the BSP boot loader format so that it can be run on target.
I know that the previous version of RTEMS had bsp-post-link in some
BSPs which helped in conversion of BSP executables but it's disabled
in the present version to simplify the build process. It would be
really helpful to know what is the current situation regarding the
conversion of BSP executable, that is how BSP specific executable runs
on target ,and also would be grateful if you can please point out some
example regarding it.
Thanks , Ayushman

On Thu, Apr 8, 2021 at 1:28 PM Ayushman Mishra  wrote:
>
> Sir I have made a draft for the project
> https://devel.rtems.org/ticket/4272 after some discussion about it on
> discord and mail-list . I would be highly grateful to get some
> comments and reviews about it in improving the draft (for example the
> part related to adding support of newly created scripts in rtems-tools
> to rtems-test.)
> https://docs.google.com/document/d/19HeKc6W2ng2X8PoCMVi68A1Z1BbO5D7C0xVHhkgMgBY/edit?usp=sharing
> . Also since I am little new to this project it will be really helpful
> if anyone can please point out any basic errors which I may have made
> in the project description.
>
> On Tue, Apr 6, 2021 at 10:30 PM Joel Sherrill  wrote:
> >
> >
> >
> > On Tue, Apr 6, 2021 at 6:22 AM Ayushman Mishra  
> > wrote:
> >>
> >> I checked all the BSPs having bsp-post-link in their config file (find
> >> . -name *.cfg | xargs -e grep define | grep bsp-post-link) but
> >> couldn't find similarity between them (other than "$(OBJCOPY) -O
> >> binary --strip-all \ $(basename $@)$(EXEEXT) $(basename $@)$(BINEXT) "
> >> in most of them . Sir I wanted to know is there any specific way to
> >> categorize them from other BSPs, And I am not able to find similar set
> >> of commands in rtems 4.11 (since in project description
> >> "https://devel.rtems.org/ticket/4272"; its written that post-link was
> >> active in earlier versions of rtems).
> >
> >
> > In 4.11, these were under c/src/lib/libbsp. There was a source 
> > reorganization
> > between 4.11 and 5 to ease the transition to waf. This command finds the
> > same set of bsp-post-link definitions once you are on the 4.11 branch.
> >
> > find c/src/lib/libbsp -name "*.cfg" | xargs -e grep post-
> >
> > I mentioned there was a few patterns of what these do. mrm332.cfg
> > is creating an S-Record image to download. mvme2100.cfg is creating
> > a compressed binary with a program prepended that decompresses it
> > and jumps to it.
> >
> > I'd suggest using Google Sheets to capture a list of every BSP with
> > a bsp-post-link stanza and a second column to categorize them based
> > on the output format. You and I have talked about the compressed
> > binary with header, S-Records, and mkimage for U-Boot. I would
> > expect that without those types, you will find similarities and a set
> > of repeating things that get tailored from BSP to BSP.
> >
> > Compare two that have the same output format. The S-Record
> > output ones should be easy to compare.
> >
> >>
> >> Also I have started making a draft on this project and wanted to know
> >> where I should post it to get some initial reviews on it.
> >
> >
> > This is pressing as is getting an application and draft filed with Google.
> >
> > --joel
> >
> >>
> >> Thanks, Ayushman
> >>
> >> On Mon, Apr 5, 2021 at 9:35 AM Ayushman Mishra  
> >> wrote:
> >> >
> >> > 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 re

[PATCH] smpfatal08: halt secondary RISC-V processors

[Jiri Gaisler]

smpfatal08 fails on SMP RISC-V systems because all cpus are started by the 
boot-loader and clobber the test output. This patch stops the secondary cpus 
with a WFI (wait-for-interrupt). Harmless if only one cpu is started by the 
loader, as in the griscv bsp.

From 722f8363fe131801ebb9f733f836d0bf6cd82c7a Mon Sep 17 00:00:00 2001
From: Jiri Gaisler 
Date: Sun, 11 Apr 2021 21:15:13 +0200
Subject: [PATCH] smpfatal08: halt secondary RISC-V processors

	* On most RISC-V platforms, all cpus are started by the
	  boot-loader. We need to stop the secondary cpus or they
	  will clobber the test output.
---
 testsuites/smptests/smpfatal08/init.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/testsuites/smptests/smpfatal08/init.c b/testsuites/smptests/smpfatal08/init.c
index 47ea91b29d..d0c9fe276a 100644
--- a/testsuites/smptests/smpfatal08/init.c
+++ b/testsuites/smptests/smpfatal08/init.c
@@ -37,6 +37,9 @@ const char rtems_test_name[] = "SMPFATAL 8";
 void bsp_start_on_secondary_processor(struct Per_CPU_Control *cpu_self)
 {
   /* Provided to avoid multiple definitions of the CPU SMP support functions */
+#if defined(__riscv)
+   asm("wfi");
+#endif
   (void) cpu_self;
 }
 
-- 
2.25.1

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

Re: [PATCH rtems-libbsd] Import telnetd from RTEMS repository

[Chris Johns]

On 9/4/21 10:49 pm, Joel Sherrill wrote> libdebugger is probably the only
service that is tied enough to RTEMS
> that moving it would be a pain for maintenance. The others are just 
> simple applications.

libdebugger's transport layer is independent of the debugger implementation so
in theory it could be moved if needed. It also support specific network
interfaces, ie lwip, or even termios. The structure of libdebugger should let us
depended on the interfaces it has but new transport layers will show if it is.

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

Tool update procedure (was Re: Fwd: GCC 10.3 Released)

[Chris Johns]

On 10/4/21 1:19 am, Joel Sherrill wrote:
> On Fri, Apr 9, 2021, 9:07 AM Sebastian Huber 
>  > wrote:
> 
> On 08/04/2021 14:50, Joel Sherrill wrote:
> 
> > Is it time to bump the RSB GCC version for rtems6?
> I am not sure, we are always quite up to date since we track the GCC 10
> release branch. I have a test build running with updates.
> 
> I forgot we were tracking the branch not release points. 
> 
> My test build sweeps on centos, FreeBSD, and Ubuntu will kick in later today.
> They run at 445pm Central time every Friday.
> 
> I did manage to build PowerPC and SPARC on Cygwin this week but something
> happens in the rsb on mingw64. I think that is known.
> 
> I want to eventually automate doing a build sweeps on Cygwin and Mingw but 
> have
> to.solve it sending reports to build@ and something like Cron.
>
I would to discuss the how we maintain the tools. The currently broken gdb on
MSYS2 MinGW is a current source of frustration for me and a potential GSoC
student. I have wasted hours on it and there is now a backlog of things
appearing we cannot test on Windows because the tools cannot be built.

I would like to formalise the tool updates procedure for the master branch, ie
currently rtems 6.

1. The master branch of the RSB needs to be able to build the tools for all the
platforms we support. We support Linux (which distros?), FreeBSD, MacOS and
Windows MSYS2.

2. The master branch of the RSB tools need to be able to build tier 1 BSPs.

3. Upstream tool releases are to be used over git hashes unless there is a
specific fix that makes this difficult. A git hash is to revert to a release
once the reason for the git hash being used has been resolved and released
upstream. Newlib is exempt from this because of the close integration with
rtems.git.

4. Tools need to build on the selected host for an update to proceed. Cross
building is a viable solution but that should be considered a deployment
technique individuals can decide to use and not a successful host build.

Rational

1. We need to be able to make releases with as little overhead as possible. I
have invested a considerable amount of time improving the release process
however a reoccurring problem is finding tools do not build on host platforms
core developers like myself do no use on a regular basis. Having the tools build
on all supported platforms spreads this work load out and lets us know and
understand issues well before we need to make a release. Placing the burden on
the person releasing only results in no one wanting to manage a release and
RTEMS again not providing timely releases.

We need to find a balance between updating and working builds on hosts. If a
host does not build and the problem is known about and being worked on then this
should not block an update however we need a means to know when the problem has
been resolved and we can make a further update. The key point is removing the
surprise a release manager gets when things are being built by anyone. If we
know our releases can be managed as a team and not a panic of platform specific
fixes.

2. This item is just being sensible. We need a certain level of confidence an
update is not regressing some targets while improving others.

3. Tracking the state of what we release and provide on master is hard when git
hashes are being used. The upstream tools provide detailed release notes for
releases and not using releases means we do not have access to them, nor do our
users. It is hard to engage with a project when reporting an issues against a
random commit git in their repo. Releases are the established mechanism and I
feel directly using a git commit adds a burden to our project we do not need.

The Next Release and Bleeding Edge

The think future releases such as 7 can be more relaxed but our next release
means the 7 tools become master and subject to these requirements. It is a
difficult line to run between keeping current with tools like gcc and being able
to move that state to master. I feel we will need to consider how this happens
when we next release so we find a process that is sensible and workable. I do
not have any suggestions here at the moment.

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

Re: #3860 - GSoC enquiries

[Ida Delphine]

Hello all,
I made some changes to my initial proposal draft based on some feedback I
got. Here's is the modified version. Please help me review and suggest
improvements.
https://docs.google.com/document/d/1VADJh3_kIhs578IEmBJ98rjR6p5E1XcksUkq1Ms4jRA/edit?usp=sharing

Cheers,
Ida.

On Fri, Apr 9, 2021 at 1:51 AM Ida Delphine  wrote:

> Hello All,
>
> Just a gentle reminder to please help me review this my proposal draft and
> help me with ways to make it better :)
>
> https://docs.google.com/document/d/1VADJh3_kIhs578IEmBJ98rjR6p5E1XcksUkq1Ms4jRA/edit?usp=sharing
>
> Cheers,
> Ida
>
> On Thu, 8 Apr 2021, 6:51 am Ida Delphine,  wrote:
>
>> Hello everyone,
>> Here is the link to my GSoC proposal. Will love if you leave comments on
>> ways I could make it better or any corrections (Especially the *Proposesd
>> Schedule* section so that I will be sure about my project deliverables
>> when inputting them).
>>
>> https://docs.google.com/document/d/1VADJh3_kIhs578IEmBJ98rjR6p5E1XcksUkq1Ms4jRA/edit?usp=sharing
>> I will also love to know about any future improvements to this project.
>>
>> Cheers,
>> Ida.
>>
>> On Wed, Apr 7, 2021 at 5:27 PM Gedare Bloom  wrote:
>>
>>> On Wed, Apr 7, 2021 at 10:11 AM Ida Delphine  wrote:
>>> >
>>> > Hello,
>>> >
>>> > In case I succeed with this project will I be required to do some
>>> documentation on how it works?
>>> >
>>> Yes, in general we expect students to produce documentation while they
>>> work on also creating code.
>>>
>>> I think the direction we're heading right now is toward using
>>> clang-format, perhaps with an update to a common coding style. In this
>>> case, we solve our problem by policy rather than technical solution,
>>> and your work should focus on tool integration and automation without
>>> concern about the coding style itself.
>>>
>>> >
>>> > On Wed, Apr 7, 2021 at 9:51 AM Sebastian Huber <
>>> sebastian.hu...@embedded-brains.de> wrote:
>>> >>
>>> >> On 07/04/2021 09:03, Chris Johns wrote:
>>> >>
>>> >> > Would it be pragmatic to review these cases and change the standard?
>>> >>
>>> >> I sent a patch to review the format changes done by clang-format
>>> recently:
>>> >>
>>> >> https://lists.rtems.org/pipermail/devel/2021-April/066311.html
>>> >>
>>> >> It doesn't look that bad from my point of view. Fixing the alignment
>>> >> issue would make it even better:
>>> >>
>>> >> https://reviews.llvm.org/D27651
>>> >>
>>> >> >
>>> >> > I understand the long history but as you point out we either invest
>>> in the tools
>>> >> > to support the format, we change what we have or we manage it
>>> manually.
>>> >> I would prefer to change the style and use a widely used formatting
>>> >> tool. I think we spend to much time on the coding style in reviews.
>>> This
>>> >> is quite bad since we are all busy with all sorts of things and our
>>> time
>>> >> is better spent on more important tasks. A consistently formatted
>>> source
>>> >> code is very important, but enforcing this style manually is a waste
>>> of
>>> >> time.
>>> >>
>>> >> --
>>> >> embedded brains GmbH
>>> >> Herr Sebastian HUBER
>>> >> Dornierstr. 4
>>> >> 82178 Puchheim
>>> >> Germany
>>> >> email: sebastian.hu...@embedded-brains.de
>>> >> phone: +49-89-18 94 741 - 16
>>> >> fax:   +49-89-18 94 741 - 08
>>> >>
>>> >> Registergericht: Amtsgericht München
>>> >> Registernummer: HRB 157899
>>> >> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas
>>> Dörfler
>>> >> Unsere Datenschutzerklärung finden Sie hier:
>>> >> https://embedded-brains.de/datenschutzerklaerung/
>>> >>
>>> >> ___
>>> >> 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: How to run the full RTEMS testsuite

[Ida Delphine]

Thanks, I'll check it out.

On Sun, Apr 11, 2021 at 6:57 AM Eshan Dhawan 
wrote:

>
> On 11-Apr-2021, at 1:15 AM, Ida Delphine  wrote:
>
> 
> For some reason I get this:
> rtems-test: command not found
> I've used this command a few times and it worked. I don't know what I
> am doing wrong now...
> Any idea what I am doing wrong?
>
> Did you add the path to the toolchain to your $PATH variable in the
> terminal ? (This might be a reason )
> Or rtems-test isn’t built for the bsp you are using try looking into
> rtems-testing repo
>
>
> On Sat, Apr 10, 2021 at 12:43 PM Eshan Dhawan 
> wrote:
>
>> Hi
>> You can use rtems-test to run tests in a directory
>> Eg :
>>
>> rtems-test --rtems-bsp=erc32-run --rtems-tools=$HOME/development/rtems/5 
>> ~/development/rtems/kernel/erc32/sparc-rtems5/c/erc32/testsuites/samples
>>
>> Thanks
>> Eshan
>>
>> On 10-Apr-2021, at 5:01 PM, Ida Delphine  wrote:
>>
>> 
>> Hello everyone,
>> I'm looking forward to work on automatic style checking and code
>> formatting for RTEMS as my GSoC project and will need to test that style
>> changes do not cause any implementation bugs. I will carryout this test by
>> running the full RTEMS testsuite. I've tried looking in the RTEMS
>> documentation for a detailed step by step guide on how to do this but I
>> can't find anything helpful. Can someone please guide me on how to achieve
>> this?
>>
>> Cheers,
>> Ida.
>> ___
>> 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