[PATCH 1/1] Updated Hello World

[prakhar]

From: Prakhar 

---
 hello.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hello.c b/hello.c
index f0b662c..72d1dd4 100644
--- a/hello.c
+++ b/hello.c
@@ -9,6 +9,6 @@ rtems_task Init(
   rtems_task_argument ignored
 )
 {
-  printf( "\nHello RTEMS from India!\n" );
+  printf( "\nHello World\n" );
   exit( 0 );
 }
-- 
2.25.1

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

Re: GitLab and BuildBot

[Christian MAUDERER]

Hello Chris,

On 2023-02-08 23:35, Chris Johns wrote:

On 8/2/2023 8:04 pm, Christian MAUDERER wrote:

On 2023-02-07 23:37, Chris Johns wrote:

On 7/2/2023 9:31 pm, Christian MAUDERER wrote:

On 2023-02-07 07:03, Chris Johns wrote:

On 30/1/2023 10:12 pm, Christian MAUDERER wrote:

That shouldn't be a pure decision by the one who pays for the work but one that
is (in the optimal case) discussed and specified in the tickets.


I did not know that was happening. I am sorry if you think it is and if I gave
you that impression.


There have been relatively new tickets that changed the status from
"needs-funding" to "funded" nearly without delay. That was a bit surprising for 
me.

It seems that the tickets are still updated based on feedback so that is fine
and it's great that someone funded them. It just would have been nice if there
would have been some announcement for two or three days like "Someone wants to
fund the tickets 1, 2 and that part of 4 exactly like they are written now. If
there are big objections with the direction, please speak up now."


I have never seen EB, your employer, make such an announcement about private
commercial in confidence contracts in this way and I would never expect EB to do
that so I think it is outrageous you think you can ask this here like this. The
funding is a private commercial agreement Amar has and it is no different to the
ones your employer makes. Any questions need to be directed to Amar directly but
I suggest the questions should be along of the lines of what you can fund.


Seems that I exaggerated too much. It's a tendency that I have sometimes 
as an attempt to be descriptive. I'm sorry if that I haven't been more 
careful in my choice of words.


Of course, it's not relevant for the list whether it's paid or not and 
who is paying. It doesn't have to have any special form either.


But announcements for changes to the devel list are not unusual in 
general. For bigger changes it's often done before the change. Sometimes 
vague but it's at least announced (Example: New build system [1], [2], 
...). If someone wants to know more or objects the planned changes he 
can speak up in these mail threads and concerns can be discussed and in 
the worst case a change can be rejected entirely.


For smaller changes everyone just sends patches to the list that are 
usually accepted and sometimes rejected if someone objects.


For infrastructure changes, a patch review after it is done isn't 
possible. So these are more the big kind of changes that should be 
announced with at least a few days time for someone to object or 
discuss. Tickets are nice but they are not very visible.




This list is open and public for the project and its community and I will not
tolerant any commercial activity of any type.



Sorry, shouldn't have mentioned "Someone wants to fund ...". The tickets 
already had something similar in the comments, so I didn't think that 
someone would object as long as it is an anonymous "Someone wants to 
fund ..." and not "Company X wants to fund ...".



Regarding the tickets, there are many cases over the years of those providing
services performing services internally, raising tickets and committing changes.
I see no issue here and I am fine with that continuing to happen.

Finally, my understanding of the funded tickets is most of the work is to
rebuild the servers to be current and capable of running modern CI systems, what
ever that ends up being.



Maintenance tasks that keep the systems running are fine without an 
announcement. These are a lot of great work that happens behind the 
scenes. But these tasks don't change how a user can access the system. 
It's great if someone decides to make that work visible too so that 
everyone can at least say a "thank you", but it's not necessary.


For tasks that change something fundamental, some public review time 
would be nice at least a few days before the work starts. Like said 
above: I would see that similar to review time for every patch that is 
more or less a suggestion to change something.


I haven't seen that announcement and review time for the tickets that 
are already funded. Maybe I missed it and if that is the case it's fully 
my fault and I'm sorry that I even started the discussion. On the other 
hand all currently funded tickets fall into the category "necessary 
maintenance task" so I clearly overreacted to even mention it.


Regarding the commercial aspect: Of course an announcement doesn't have 
to happen before a contract is closed - that is something between the 
two companies or individuals that close the contract. But like you said 
multiple times yourself: It's not a contract that the RTEMS project 
closes but one between two unrelated legal entities. So it's still 
possible that a community members might object and in the worst case 
block the change.


Just to make that clear again: Except for some details (that we are 
currently discussing in various mail threads) I'm 

bsps/riscv: interrupt not occurred

[Padmarao.Begari]

Hi,

While testing the Candence GEM driver of RTEMS-FreeBSD with the RTEMS
on the PolarFire SoC Icicle Kit found one issue.

Issue:The Interrupt is disabled before clearing the interrupt complete
in the PLIC because of this the same interrupt is not occurred next
time.

Resolved: Clear the Interrupt complete in the PLIC before disable the
interrupt. 

Updated the bsp_interrupt_vector_disable() function like below then the
cgem driver is working fine with the RTEMS. 

@Sebastian Huber - Can I send the patch for this?

---
rtems_status_code bsp_interrupt_vector_disable(rtems_vector_number
vector)
{
  bsp_interrupt_assert(bsp_interrupt_is_valid_vector(vector));

  if (RISCV_INTERRUPT_VECTOR_IS_EXTERNAL(vector)) {
uint32_t interrupt_index;
volatile uint32_t *enable;
uint32_t group;
uint32_t bit;
rtems_interrupt_lock_context lock_context;
volatile RISCV_PLIC_hart_regs *plic_hart_regs;

interrupt_index = RISCV_INTERRUPT_VECTOR_EXTERNAL_TO_INDEX(vector);
enable = riscv_plic_irq_to_cpu[interrupt_index - 1];
group = interrupt_index / 32;
bit = UINT32_C(1) << (interrupt_index % 32);

rtems_interrupt_lock_acquire(_plic_lock, _context);

#ifdef RTEMS_SMP
  uint32_t cpu_max;
  uint32_t cpu_index;

  cpu_max = _SMP_Get_processor_maximum();

  for (cpu_index = 0; cpu_index < cpu_max; ++cpu_index) {
Per_CPU_Control *cpu;

cpu = _Per_CPU_Get_by_index(cpu_index);
enable = cpu->cpu_per_cpu.plic_m_ie;
plic_hart_regs = cpu->cpu_per_cpu.plic_hart_regs;
   
plic_hart_regs->claim_complete = interrupt_index;

if (enable != NULL) {
  enable[group] &= ~bit;
}
  }
#else
  Per_CPU_Control *cpu;

  cpu = _Per_CPU_Get_by_index(0);
  enable = cpu->cpu_per_cpu.plic_m_ie;
  plic_hart_regs = cpu->cpu_per_cpu.plic_hart_regs;
  plic_hart_regs->claim_complete = interrupt_index;
  if (enable != NULL) {
enable[group] &= ~bit;
  }
#endif

rtems_interrupt_lock_release(_plic_lock, _context);
return RTEMS_SUCCESSFUL;
  }

  if (vector == RISCV_INTERRUPT_VECTOR_TIMER) {
clear_csr(mie, MIP_MTIP);
return RTEMS_SUCCESSFUL;
  }

  _Assert(vector == RISCV_INTERRUPT_VECTOR_SOFTWARE);
  clear_csr(mie, MIP_MSIP);
  return RTEMS_SUCCESSFUL;
} 


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

Re: [PATCH rtems-release 1/3] rtems-notes-6.md: Obsolete SPARC64 port

[Chris Johns]

On 9/2/2023 12:53 pm, Joel Sherrill wrote:
> Then ok to push and get almost ten percent of the 6.1 tickets closed? :)

Sorry, yes it is. I will sort the move at after.

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

Re: [PATCH rtems-release 1/3] rtems-notes-6.md: Obsolete SPARC64 port

[Joel Sherrill]

Then ok to push and get almost ten percent of the 6.1 tickets closed? :)

On Wed, Feb 8, 2023, 6:39 PM Chris Johns  wrote:

> Looks good.
>
> I will move this file into the `notes` directory once merged.
>
> Thanks
> Chris
>
> On 9/2/2023 8:40 am, Joel Sherrill wrote:
> > Closes #4613.
> > ---
> >  rtems-notes-6.md | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/rtems-notes-6.md b/rtems-notes-6.md
> > index 0eb7c2f..755663e 100644
> > --- a/rtems-notes-6.md
> > +++ b/rtems-notes-6.md
> > @@ -274,7 +274,7 @@ Removed obsoleted architectures:
> >
> >  Obsoleted architectures:
> >
> > -* TBD
> > +* SPARC64
> >
> >  ## BSPs and Device Drivers
> >
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] spec/bsps: Deduplicate objxilinxsupport

[Chris Johns]

On 7/2/2023 5:55 pm, Sebastian Huber wrote:
> On 06.02.23 23:09, Gedare Bloom wrote:
>> ok. I'm not sure, maybe we need a note about this in
>> https://docs.rtems.org/branches/master/eng/build-system.html
> 
> A hint in the documentation would be helpful. Even more helpful would be a
> consistency check before patch sets are pulled in. For example, it is a bug if
> you have a diamond in the build dependency graph and the nodes with an 
> indegree
> greater than one install files. If the nodes with an indegree greater than one
> build source files with identical build options, then this is also a bug.
> However, a valid special case could be a node which is built with different
> build flags, for example:
> 
> lib -> grp_a (-DFLAG_A) -> objxyz
>  \---> grp_b (-DFLAG_B) -> objxyz

I would expect that case would map to separate build objects?

How do you suggest someone proceed to add a check?

Would that check happen when the spec files are parsed? That is, we assume the
pickled output loaded on each build is OK?

Do we have any unittests for the build system? Adding a check would mean we need
a test case to generate the problem?

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

Re: [PATCH rtems-release 1/3] rtems-notes-6.md: Obsolete SPARC64 port

[Chris Johns]

Looks good.

I will move this file into the `notes` directory once merged.

Thanks
Chris

On 9/2/2023 8:40 am, Joel Sherrill wrote:
> Closes #4613.
> ---
>  rtems-notes-6.md | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/rtems-notes-6.md b/rtems-notes-6.md
> index 0eb7c2f..755663e 100644
> --- a/rtems-notes-6.md
> +++ b/rtems-notes-6.md
> @@ -274,7 +274,7 @@ Removed obsoleted architectures:
>  
>  Obsoleted architectures:
>  
> -* TBD
> +* SPARC64
>  
>  ## BSPs and Device Drivers
>  
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GitLab and BuildBot

[Chris Johns]

On 8/2/2023 8:04 pm, Christian MAUDERER wrote:
> On 2023-02-07 23:37, Chris Johns wrote:
>> On 7/2/2023 9:31 pm, Christian MAUDERER wrote:
>>> On 2023-02-07 07:03, Chris Johns wrote:
 On 30/1/2023 10:12 pm, Christian MAUDERER wrote:
>>> That shouldn't be a pure decision by the one who pays for the work but one 
>>> that
>>> is (in the optimal case) discussed and specified in the tickets.
>>
>> I did not know that was happening. I am sorry if you think it is and if I 
>> gave
>> you that impression.
> 
> There have been relatively new tickets that changed the status from
> "needs-funding" to "funded" nearly without delay. That was a bit surprising 
> for me.
> 
> It seems that the tickets are still updated based on feedback so that is fine
> and it's great that someone funded them. It just would have been nice if there
> would have been some announcement for two or three days like "Someone wants to
> fund the tickets 1, 2 and that part of 4 exactly like they are written now. If
> there are big objections with the direction, please speak up now."

I have never seen EB, your employer, make such an announcement about private
commercial in confidence contracts in this way and I would never expect EB to do
that so I think it is outrageous you think you can ask this here like this. The
funding is a private commercial agreement Amar has and it is no different to the
ones your employer makes. Any questions need to be directed to Amar directly but
I suggest the questions should be along of the lines of what you can fund.

This list is open and public for the project and its community and I will not
tolerant any commercial activity of any type.

Regarding the tickets, there are many cases over the years of those providing
services performing services internally, raising tickets and committing changes.
I see no issue here and I am fine with that continuing to happen.

Finally, my understanding of the funded tickets is most of the work is to
rebuild the servers to be current and capable of running modern CI systems, what
ever that ends up being.

> At the moment I don't need all tickets from my point of view. But there are no
> tickets that I would see as a problem. So again: I'm happy that our system 
> will
> get better.

Thank you the positive feed back, it is appreciated. The process is not perfect
and what can be achieved is limited but things are moving and changing and that
is encouraging.

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

Re: [PATCH 1] Changed Hello World

[Gedare Bloom]

On Tue, Feb 7, 2023 at 8:06 AM Christian MAUDERER
 wrote:
>
> Hello Prakhar,
>
> that looks suspiciously like a HTML mail (or rather a mixed mode mail).
> How did you send that patch? Usually it's best to use git send-email to
> send patches to the list so that no mail client messes up formatting
> which helps with applying patches again.
>
+1

Meanwhile, Prakhar, you can send me and j...@rtems.org a screenshot of
you running your modified hello world in a simulator to complete the
GSoC Getting Started (assuming that's what this is)

> Best regards
>
> Christian
>
> On 2023-02-07 09:17, Prakhar Agrawal wrote:
> > From: Prakhar  > >
> > Date: Tue, 7 Feb 2023 13:43:09 +0530
> > Subject: [PATCH 4/4] updated hello.c
> >
> > ---
> >   hello.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/hello.c b/hello.c
> > index 72d1dd4..a3c40ae 100644
> > --- a/hello.c
> > +++ b/hello.c
> > @@ -9,6 +9,6 @@ rtems_task Init(
> > rtems_task_argument ignored
> >   )
> >   {
> > -  printf( "\nHello World\n" );
> > +  printf( "\nHello RTEMS from Prakhar!\n" );
> > exit( 0 );
> >   }
> > --
> > 2.25.1
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
> --
> 
> embedded brains GmbH
> Herr Christian MAUDERER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email:  christian.maude...@embedded-brains.de
> phone:  +49-89-18 94 741 - 18
> mobile: +49-176-152 206 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

[PATCH rtems-release 3/3] rtems-notes-6.md: Obsolete v850 port

[Joel Sherrill]

Closes #4615.
---
 rtems-notes-6.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/rtems-notes-6.md b/rtems-notes-6.md
index e5dc0d0..70b66a3 100644
--- a/rtems-notes-6.md
+++ b/rtems-notes-6.md
@@ -274,6 +274,7 @@ Removed obsoleted architectures:
 
 Obsoleted architectures:
 
+* V850
 * SPARC64
 * SuperH (sh)
 
-- 
1.8.3.1

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

[PATCH rtems-release 2/3] rtems-notes-6.md: Obsolete sh port

[Joel Sherrill]

Closes #4614.
---
 rtems-notes-6.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/rtems-notes-6.md b/rtems-notes-6.md
index 755663e..e5dc0d0 100644
--- a/rtems-notes-6.md
+++ b/rtems-notes-6.md
@@ -275,6 +275,7 @@ Removed obsoleted architectures:
 Obsoleted architectures:
 
 * SPARC64
+* SuperH (sh)
 
 ## BSPs and Device Drivers
 
-- 
1.8.3.1

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

[PATCH rtems-release 1/3] rtems-notes-6.md: Obsolete SPARC64 port

[Joel Sherrill]

Closes #4613.
---
 rtems-notes-6.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rtems-notes-6.md b/rtems-notes-6.md
index 0eb7c2f..755663e 100644
--- a/rtems-notes-6.md
+++ b/rtems-notes-6.md
@@ -274,7 +274,7 @@ Removed obsoleted architectures:
 
 Obsoleted architectures:
 
-* TBD
+* SPARC64
 
 ## BSPs and Device Drivers
 
-- 
1.8.3.1

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

Re: [PATCH rtems-central] spec/build-objects: Add details about duplicates

[Sebastian Huber]

On 07.02.23 23:00, Kinsey Moore wrote:

Add a comment warning against duplicate ObjectsItem inclusions and why
that can cause problems.


Thanks, looks good. I can regenerate the file and check it in tomorrow.

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

Re: GitLab and BuildBot

[Christian MAUDERER]

On 2023-02-07 23:37, Chris Johns wrote:

On 7/2/2023 9:31 pm, Christian MAUDERER wrote:

On 2023-02-07 07:03, Chris Johns wrote:

On 30/1/2023 10:12 pm, Christian MAUDERER wrote:

Hello,

recently the following tickets were added (beneath a few more related ones):

https://devel.rtems.org/ticket/4790 - Setup Gitlab instance
https://devel.rtems.org/ticket/4791 - Update BuildBot

It's great that a patch review system and a CI/CD that builds every patch for
RTEMS starts to get within reach. Thanks a lot to all involved in that for the
efforts.


It is exciting to see this happening. It will benefit the project and all who
give their time.


I reviewed earlier discussions related to CI/CD. From my point of view there are
mainly two points that are missing in the tickets:

First: From my point of view, we should make it simple for new users to
register. Adding authentication using well-known services can help with that.
GitLab supports (for example):
    - GitHub: https://docs.gitlab.com/ee/integration/github.html
    - GitLab.com: https://docs.gitlab.com/ee/integration/gitlab.html
    - Google: https://docs.gitlab.com/ee/integration/google.html
    - ...
I think it would be good to select the most common ones (at least the three
mentioned above) and add them as a goal to the ticket or a new one. What do you
think?


I suggest a ticket to handle authentication. If you create a ticket please
indicate it is unfunded. If this is handled else where and in another ticket
this one can be closed with a suitable reason.



https://devel.rtems.org/ticket/4840


Thanks.


The addition of these authentication methods can be done when someone funds the
work. If a person or organisation thinks it is important please reach out to
Amar directly.


Second: It's still a bit unclear for me how the CI/CD with BuildBot will work.
Will it be possible for anyone to help improve the CI/CD? An example to make it
clear what I want to know: Let's assume an unprivileged developer has a patch
set that allows building device tree files using the RTEMS build system, but the
patches require a new tool like dtc. Let's further assume that the idea has been
discussed and everyone agrees that it is a good idea (currently not yet the case
for dtc). Problem is: The patches trigger a CI error because the new tool is
missing and therefore can't be merged yet. How can the developer suggest a fix
so that the patches can be accepted faster without having to wait for one
specific maintainer to have enough time for adapting the CI config?


There are details that will need to be worked out. Deployment of tools for
building in a CI flow is important. How complex and automated this will be will
depends on the funding provided. At this point in time the push is to get a
basic framework up that allows us to handle simple merge requests. The approach
is more organic in nature so funding can be targeted at the most important
foundation pieces. Further funding can build on that base. Before we get to
Gitlab and CI we need to rebase the servers and software on them. This part of
the effort is funded and under way. Amar is updating the tickets with the
progress.


Maybe my question hasn't been clear enough. Of course part of it depends on what
is implemented. But every selected system also adds limitations. At the moment
BuildBot is the suggested system in the tickets. It is a well known service and
has a lot of usefull features for us that certainly make it a good choice.

But I never really worked with it, so I basically wanted to know what I have to
expect. Some systems like (I think it was) jenkins.io can be configured to
behave quite different depending on how you use it. You can either configure it
via a static configuration that is put somewhere where only admins can access
it. But you can also configure it in a way that build jobs are defined by yaml
files in the repository similar to popular services like GitHub, GitLab or 
Travis.

Basically what I wanted to know is: What is possible / usual with BuildBot and
which of the possible solutions do we want to use?


A developer with a gitlab account will be encouraged to move their personal repo
to their gitlab account and doing that allows them to use the gitlab CI tools.
Gitlab will be running on FreeBSD and in a jail so any dependent services a
developer needs will need to be requested via a ticket. I hope you appreciate
there are limit here related to resources and the hardened nature of the
environment.



Of course there are limits. That's OK.


Do we configure BuildBot
statically and every change will be done only if someone pays for it?


The main CI build flows will be controlled and changed via a ticket. We need to
QA control that process to ensure the patches merged are suitable. I have no
idea yet how this will look and work but it will need to allow the project to
make updates. Wether this is widely available on the first pass or pass ten of
the work that needs to be done I cannot say.



Of