[PATCH] Check the validity of git repository.

[Abhinav Jain]

Sir,

Please check if this works. 

Thanks and Regards
Abhinav Jain

Earlier the function valid was checking the validity of the git repository,
the program was working in. For doing this the function was first checking
whether path exists or not and after that it was checking whether the
directory is a git repository or not and to do so, it
was relying on git status. Since the git status looks for the .git file in
the current directory and if not found it will look up in the tree and if finds
a .git file there it will return valid, which voids the purpose of use.
Now to solve this problem, a function _valid_repo_path is created to check
for the .git file and every function which looks for the validity of
git repository will call this function to check. Closes #2522
---
 source-builder/sb/git.py | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/source-builder/sb/git.py b/source-builder/sb/git.py
index be23396..0d139f9 100644
--- a/source-builder/sb/git.py
+++ b/source-builder/sb/git.py
@@ -38,9 +38,12 @@ class repo:
 if ec:
 raise error.general('git command failed (%s): %d' % (self.git, ec))
 
+def _valid_repo_path(self):
+   return path.exists(path.join(self.path, '.git'))
+
 def _run(self, args, check = False):
 e = execute.capture_execution()
-if path.exists(self.path):
+if _valid_repo_path():
 cwd = self.path
 else:
 cwd = None
@@ -122,7 +125,7 @@ class repo:
 
 def status(self, submodules_always_clean = False):
 _status = {}
-if path.exists(self.path):
+if _valid_repo_path():
 if submodules_always_clean:
 submodules = self.submodules()
 else:
@@ -166,7 +169,7 @@ class repo:
 return not (len(_status) == 1 and 'branch' in _status)
 
 def valid(self):
-if path.exists(self.path):
+if _valid_repo_path():
 ec, output = self._run(['status'])
 return ec == 0
 return False
@@ -233,4 +236,4 @@ if __name__ == '__main__':
 print('g.dirty():', g.dirty())
 print('g.remotes():', g.remotes())
 print('g.email():', g.email())
 print('g.head():', g.head())
\ No newline at end of file
-- 
1.9.1

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

Re: GSOC proposal - Runtime tracing

[Vidushi Vashishth]

Hi!

I have uploaded my final proposal pdf for GSOC'18. I have tried to
incorporate all the comments made. PFA the final draft of the proposal.

Thanks for being such a wonderful community! I enjoyed every bit of the
application process.

Warm regards,
Vidushi Vashishth

​
 GSOC_proposal_Vidushi_runtime_tracing

​

On Sat, Mar 24, 2018 at 1:23 AM, Vidushi Vashishth 
wrote:

> Hello!
>
> >>We should focus on basic functionality and this is interrupt entry/exit
> and thread switching. This should work out of the box without having to
> compile RTEMS with specialized configuration options. It should work via a
> serial line and network (UDP I guess). It should also support SMP machines.
> This requires per-processor trace buffers. The trace buffer should work
> without locks, e.g. only interrupt disable/enable. I would do also a short
> review of existing trace solutions. Maybe we don't have to re-invent the
> wheel. For example:
>
> http://www.cs.unc.edu/~bbb/feathertrace/
>
> I see. I went through the feathertrace solution documentation. I am also
> looking at other solutions, including Linux Trace Toolkit. I will reinvent
> the focus of my proposal to include the basic functionality suggested.
>
> >There is a lot to review to get the
> plan right here. I've made comments on the google doc proposal.
>
> Yes. I went over the comments. Thank you for such a detailed explanation.
> I will amend the proposal to incorporate the comments.
>
> >I don't see how network support can exist out-of-the-box unless the
> solution exists at libbsd level. I think there will be two pieces to
> this kind of project:
> 1. capturing traces to memory buffers from interrupt/"kernel" contexts.
> 2. transporting buffers via worker threads.
>
> Then, one can implement a basic worker thread using available drivers
> in rtems, and also more advanced (network) workers relying on libbsd.
>
> >The use of per-processor buffers makes the "reader" side (transport)
> more complicated. This is a good place to consider a wait-free
> non-blocking data structure, or a rwlock with writer prioritization.
> At any rate, a good design is needed here with some careful thought.
>
> I will investigate if an out of the box solution exists at the libbsd
> level and post it here.
>
>
> Regards,
> Vidushi
>
>
>
> On Fri, Mar 23, 2018 at 8:58 PM, Gedare Bloom  wrote:
>
>> Hello Vidushi, Sebastian:
>>
>> On Fri, Mar 23, 2018 at 2:16 AM, Sebastian Huber
>>  wrote:
>> > Hello Vidushi,
>> >
>> > the RTEMS Trace Linker is definitely an interesting tool to track down
>> > difficult and specific issues. However, this is a nice to have optional
>>
>> out-of-box Trace Linker with integration to debugger or CTF tools will
>> be highly beneficial for the "user-side" experience of RTEMS. This can
>> be quite beneficial for marketing if nothing else. :) Given the
>> current state, and that we've had a few projects already on this
>> topic, any project working here needs to focus on delivering a
>> complete slice of the software stack from trace configuration all the
>> way through trace output analysis. There is a lot to review to get the
>> plan right here. I've made comments on the google doc proposal.
>>
>> > feature from my point of view. We should focus on basic functionality
>> and
>> > this is interrupt entry/exit and thread switching. This should work out
>> of
>> > the box without having to compile RTEMS with specialized configuration
>>
>> I agree that this is also an important aspect for "kernel-level"
>> tracing, and it should be implemented directly into RTEMS with
>> standard configuration (configure or confdefs.h options). The
>> requirements for this functionality is unclear, though, such as what
>> the trace output should be.
>>
>> > options. It should work via a serial line and network (UDP I guess). It
>>
>> I don't see how network support can exist out-of-the-box unless the
>> solution exists at libbsd level. I think there will be two pieces to
>> this kind of project:
>> 1. capturing traces to memory buffers from interrupt/"kernel" contexts.
>> 2. transporting buffers via worker threads.
>>
>> Then, one can implement a basic worker thread using available drivers
>> in rtems, and also more advanced (network) workers relying on libbsd.
>>
>> > should also support SMP machines. This requires per-processor trace
>> buffers.
>> > The trace buffer should work without locks, e.g. only interrupt
>> > disable/enable. I would do also a short review of existing trace
>> solutions.
>>
>> The use of per-processor buffers makes the "reader" side (transport)
>> more complicated. This is a good place to consider a wait-free
>> non-blocking data structure, or a rwlock with writer prioritization.
>> At any rate, a good design is needed here with some careful thought.
>>
>> > Maybe we don't have 

Re: x86_64 port and BSP (GSoC 2018)

[Chris Johns]

On 26/03/2018 14:49, Amaan Cheval wrote:
> Hi!
> 
> Thanks for your comments on the document, by the way. Regarding the
> following comment:
> 
>> We should support multiboot as well for legacy X86 BIOSes. There are
> headers about that can do this.
> 
> This is a great point - this way legacy BIOSes only need something like
> GRUB (or a bootloader implementing the Multiboot spec) to boot RTEMS'
> x86-64 port, right?

Yes as iPXE and others.

> Do you think it's okay to lay this out as a bonus feature? It seems simple
> enough, but I think the scope of the project as-is at the moment seems just
> right, in that it leaves a little room for unexpected time-consuming
> Heisen-bugs.

I was thinking about as a point to remember. If it comes for free why not keep 
it.

> 
> On Mon, Mar 26, 2018 at 4:08 AM Chris Johns  wrote:
> 
>> On 20/03/2018 18:10, Amaan Cheval wrote:
>>> On Tue, Mar 20, 2018 at 11:44 AM Chris Johns  wrote:
 On 20/03/2018 16:21, Amaan Cheval wrote:
> On Tue, Mar 20, 2018 at 8:23 AM Chris Johns  wrote:
>> On 19/03/2018 18:36, Amaan Cheval wrote:
> (Assuming that by tables you meant the Local Vector Table, etc., and
> not
> the ACPI's MADT, which is relevant to SMP in that it contains a list
> of
> LAPICs, thereby letting us find how many cores are available.)
>>>
 I was thinking about the SMP tables. SMP is not part of this work at
> the
>>> moment
 so what ever is needed in this area to make the BSP work. Is the Local
>>> Vector
 Table included in the list of tables?
>>>
>>> Oh, did you mean the MP Table / ACPI MADT as mentioned in the 2nd bullet
>>> here? (From volume 3 of Intel's IA32 and 64 manual.)
>>> https://i.imgur.com/elZIlfy.png
> 
>> It has been a while since I looked at this. Is there a table for
> interrupts and
>> interrupts beyond the master/slave legacy PICs?
> 
> The way I understand it is:
> - There are local APICs per core (making up a CPU)

This seems normal for SMP.

> - Local APICs have local events such as APIC timers, perf counters, I/O
> devices, etc. - the Local Vector Table is used to configure each of these
> local interrupt sources
> - Multiple local APICs can talk to each other through the system/APIC bus
> (model-specific) through Inter-Processor Interrupts
> - The I/O APIC is connected to the system/APIC bus, and allows external
> devices (including PCI) and system hardware to communicate with the local
> APICs (individual CPUs on an SMP system)
> - To use the I/O APIC, you need to parse either MP Tables or tables through
> ACPI (determining how devices map to the I/O APIC's input pins, to tease
> out where lines are being shared, and how interrupts may be redirected)

OK, this is what I saw and I went that is too much to do in a few hours so moved
on. :)

> - The Interrupt Descriptor Table (IDT; protected mode) or Interrupt Vector
> Table (IVT; real mode) are then used to actually call the ISR that was
> registered (depending on specific configuration and the type of
> interrupt/exception, of course)
> 
> I believe the distinction you're looking for is one about configuring more
> than just the legacy master/slave PIC, which should be accomplished merely
> by our use of the APIC (even if complete setup and interfacing with the I/O
> APIC is not in the scope of this proposal, the project sets up future
> improvements nicely).

We found with the newer BIOSs with UEFI some interrupts are mapped above the
last slave PIC IRQ. It is just looking practically at the problem.

> 
>>> One of those tables will need to be parsed to configure boot for SMP
>>> systems correctly, yes. I thought you meant the tables that need to be
>>> setup for the local APIC to be initialized and used correctly (which is
>>> also necessary to be able to send Startup Inter-Proessor Interrupts
> (SIPI)
>>> for SMP boot to work).
> 
>> I think interrupts to access to various PCI devices beyond the slave PIC
> is all
>> we need for now.
> 
> Do you think of this as a key deliverable? To me, it was a bonus feature,
> given that setting this up correctly is apparently a lot of work; see the
> following forum post, for example:
> https://forum.osdev.org/viewtopic.php?f=1=21745=0#p174219

It is not key. A BSP framework we can easily add this is.

> Getting this to work correctly would also mean parsing MP tables, or
> accessing tables through ACPI (which is also a bonus feature for the scope
> of this GSoC proposal).
> 
> Does that sound okay?
> 

It seems fine. My questions and concerns are about understanding expectations.

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

Re: [PATCH] Check the validity of git repository.

[Abhinav Jain]

Sir,

I sent the mail using git-send-email only. I don't know why git reports it
as corrupt. I will resend it.

Thanks and Regards
Abhinav Jain

On Mon, Mar 26, 2018 at 4:39 AM, Chris Johns  wrote:

> On 23/02/2018 15:02, Abhinav Jain wrote:
> > I have made the changes as per your suggestions.
> > Please review the changes and guide me, whether I have done it
> correcctly or not
> > and also if something more is to be added to the code.
> >
>
> I cannot push this patch, git reports it as corrupt. Did you create this
> email
> by hand in gmail?
>
> Please review https://devel.rtems.org/wiki/Developer/Git/Users#
> CreatingaPatch.
> If you cannot send the patch via `git send-email` please create using `git
> format-patch` and attach to the ticket.
>
> Thanks
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Improve coverage analysis toolset

[Vijay Kumar Banerjee]

1. Yes , I plan to work on identifying the discrepancies between what
covoar reports directly and what the gcov reports based on its gcov output.

2. I understand this point that the  scripting that generates symbol set
file, needs to be modified accordingly

3. I have planned to make a note and understand the requirements, changes
needed and the desired type of output during the community bonding period,
so that I have a clear picture of the objective before I start working on
it.

The plan is to work on gcov after the existing work is merged.
 Have I planned too much to work on during the summer? Should I modify my
plan in some way? Please suggest .

Thanks

-- vijay

On 26 March 2018 at 03:49, Joel Sherrill  wrote:

> Just a couple of questions and planning issues. The planning issues
> are because the requirements for some of the work are likely not solid
> on our side.
>
> 1. Do you plan to work on identifying the discrepancies between
> what covoar reports directly and what gcov reports based on its
> gcov file output? I ask because I lined up someone from the GCC
> community who should be able to tell us what is not right once
> we have specific cases.
>
> 2. My recollection is that the symbol set file is generated from
> the RTEMS libraries under test. The scripting that generates this
> file will have to change also. The set of symbols changes as
> RTEMS evolves.
>
> 3. Chris has had ideas on changing the output from directly
> producing ascii and html to something else. It is on he and I
> to give you input on the actual format.
>
> Personally getting all existing work merged and it in a state
> where we can produce coverage reports again is really a
> critical thing. The previous work changed it from being
> a standalone shell script that drove things to part of the RSB
> and make it possible to have the reports based on subdirectories
> rather than one large report.
>
> I don't 'think this changes your plan except that the plan seems to
> put gcov as bonus work. It isn't discussed as work during the
> summer.It would be nice to get gcov correctness done earlier
> because that might be the best way to nice reports. For
> example, running lcov on the .gcov files produced by covoar
> might be an option.
>
> --joel
>
>
> On Sun, Mar 25, 2018 at 3:16 PM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> submitted !
>> If you find time , please give final review as well.
>>
>> Thanks
>>
>> On 26 Mar 2018 1:44 a.m., "Joel Sherrill"  wrote:
>>
>>> I am out and not at a computer. Someone can double check me but I
>>> believe you can replace the PDF you upload.
>>>
>>> Unless someone answers soon, just upload it.
>>>
>>> --joel
>>>
>>> On Mar 25, 2018 2:37 PM, "Vijay Kumar Banerjee" <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 It's the last day before the deadline!
 Please provide a final review of the proposal before submitting.

 Thanks

 -- vijay

 On 24 March 2018 at 21:37, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> hello mentors and other developers of the community , there are only
> three days remaining to the GSoC proposal submission deadline.
>
> I request the mentors and everyone in the community who has experience
> in RTEMS, to please go through my proposal for Coverage Analysis tool
> improvement project , if they have time , and suggest any kind of
> improvements and changes .
> here is the link to the proposal
> https://docs.google.com/document/d/1UjCWE1ojrpDQLQ2fQqxHU0SC
> rLETlerxD6t0SOcQNLQ/edit?usp=sharing
> Thank you
>
> -- vijay
>
> On 22 March 2018 at 04:30, Joel Sherrill  wrote:
>
>> Glad you have tests running. Hopefully as Cillian suggested, you can
>> fix the
>> remaining issues to see coverage.
>>
>> We certainly need to get this merged if Chris is OK with it and it
>> doesn't
>> break anything else.
>>
>> I am reviewing proposals now. Seems to be a queue. :)
>>
>> --joel
>>
>> On Wed, Mar 21, 2018 at 4:42 AM, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> Sir ,
>>> I have done the changes in the proposal , based on the comments in
>>> the google doc , please review it and suggest any further changes if
>>> required
>>>
>>> Thank you ,
>>> -- vijay
>>>
>>> P.S : the previous version is in parentheses , I will remove them
>>> after you review the changes .
>>>
>>> On 18 March 2018 at 16:05, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 Thanks Cillian :)

 It's great to see it running ,  I'll do some background reading
 about RSB, and RTEMS-Tools along with the covoar code . And also work 
 on my
 python skills.

 to try rtems-test on a bsp that runs gdb , I tried it on erc32 and

Re: x86_64 port and BSP (GSoC 2018)

[Amaan Cheval]

Hi!

Thanks for your comments on the document, by the way. Regarding the
following comment:

> We should support multiboot as well for legacy X86 BIOSes. There are
headers about that can do this.

This is a great point - this way legacy BIOSes only need something like
GRUB (or a bootloader implementing the Multiboot spec) to boot RTEMS'
x86-64 port, right?

Do you think it's okay to lay this out as a bonus feature? It seems simple
enough, but I think the scope of the project as-is at the moment seems just
right, in that it leaves a little room for unexpected time-consuming
Heisen-bugs.

On Mon, Mar 26, 2018 at 4:08 AM Chris Johns  wrote:

> On 20/03/2018 18:10, Amaan Cheval wrote:
> > On Tue, Mar 20, 2018 at 11:44 AM Chris Johns  wrote:
> >> On 20/03/2018 16:21, Amaan Cheval wrote:
> >>> On Tue, Mar 20, 2018 at 8:23 AM Chris Johns  wrote:
>  On 19/03/2018 18:36, Amaan Cheval wrote:
> >>> (Assuming that by tables you meant the Local Vector Table, etc., and
not
> >>> the ACPI's MADT, which is relevant to SMP in that it contains a list
of
> >>> LAPICs, thereby letting us find how many cores are available.)
> >
> >> I was thinking about the SMP tables. SMP is not part of this work at
the
> > moment
> >> so what ever is needed in this area to make the BSP work. Is the Local
> > Vector
> >> Table included in the list of tables?
> >
> > Oh, did you mean the MP Table / ACPI MADT as mentioned in the 2nd bullet
> > here? (From volume 3 of Intel's IA32 and 64 manual.)
> > https://i.imgur.com/elZIlfy.png

> It has been a while since I looked at this. Is there a table for
interrupts and
> interrupts beyond the master/slave legacy PICs?

The way I understand it is:
- There are local APICs per core (making up a CPU)
- Local APICs have local events such as APIC timers, perf counters, I/O
devices, etc. - the Local Vector Table is used to configure each of these
local interrupt sources
- Multiple local APICs can talk to each other through the system/APIC bus
(model-specific) through Inter-Processor Interrupts
- The I/O APIC is connected to the system/APIC bus, and allows external
devices (including PCI) and system hardware to communicate with the local
APICs (individual CPUs on an SMP system)
- To use the I/O APIC, you need to parse either MP Tables or tables through
ACPI (determining how devices map to the I/O APIC's input pins, to tease
out where lines are being shared, and how interrupts may be redirected)
- The Interrupt Descriptor Table (IDT; protected mode) or Interrupt Vector
Table (IVT; real mode) are then used to actually call the ISR that was
registered (depending on specific configuration and the type of
interrupt/exception, of course)

I believe the distinction you're looking for is one about configuring more
than just the legacy master/slave PIC, which should be accomplished merely
by our use of the APIC (even if complete setup and interfacing with the I/O
APIC is not in the scope of this proposal, the project sets up future
improvements nicely).


> > One of those tables will need to be parsed to configure boot for SMP
> > systems correctly, yes. I thought you meant the tables that need to be
> > setup for the local APIC to be initialized and used correctly (which is
> > also necessary to be able to send Startup Inter-Proessor Interrupts
(SIPI)
> > for SMP boot to work).

> I think interrupts to access to various PCI devices beyond the slave PIC
is all
> we need for now.

Do you think of this as a key deliverable? To me, it was a bonus feature,
given that setting this up correctly is apparently a lot of work; see the
following forum post, for example:
https://forum.osdev.org/viewtopic.php?f=1=21745=0#p174219

Getting this to work correctly would also mean parsing MP tables, or
accessing tables through ACPI (which is also a bonus feature for the scope
of this GSoC proposal).

Does that sound okay?


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

Re: [PATCH] rsb: Add '--patchdir' option description

[Chris Johns]

On 21/02/2018 01:47, Maksim E. Kozlov wrote:
> According to commit d30be3129e9681a74efc80ce241aaf3c3a5b0efe in
> rtems-source-builder repo.
> 
> Signed-off-by: Maksim E. Kozlov 

Pushed. Thank you.

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

Re: [PATCH] Check the validity of git repository.

[Chris Johns]

On 23/02/2018 15:02, Abhinav Jain wrote:
> I have made the changes as per your suggestions. 
> Please review the changes and guide me, whether I have done it correcctly or 
> not
> and also if something more is to be added to the code.
> 

I cannot push this patch, git reports it as corrupt. Did you create this email
by hand in gmail?

Please review https://devel.rtems.org/wiki/Developer/Git/Users#CreatingaPatch.
If you cannot send the patch via `git send-email` please create using `git
format-patch` and attach to the ticket.

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

Re: [PATCH] cpu-supplement: Add ARM BSPs chapter

[Chris Johns]

On 14/03/2018 17:20, Sebastian Huber wrote:
> On 13/03/18 22:58, Chris Johns wrote:
>> On 09/03/2018 19:55, Sebastian Huber wrote:
>>> On 06/11/17 10:03, Sebastian Huber wrote:
 On 26/10/17 08:22, Sebastian Huber wrote:
> Please review this patch carefully. It adds a new chapter "ARM Board 
> Support
> Packages" following the "ARM Specific Information" chapter. It adds a
> template structure for other BSPs.
>
> Where should we place common BSP configuration options like
> BSP_PRESS_KEY_FOR_RESET? We probably don't want to add a copy and paste
> version to every BSP section.
>
 Any comments with respect to the BSP documentation? It makes little sense 
 to
 start with this work if the general direction is unclear.

>>> The insufficient and user unfriendly BSP documentation is still a big issue 
>>> from
>>> my point of view. I think it is one of be biggest obstacles to get started 
>>> with
>>> RTEMS. The BSP documentation should be part of a sphinx based rtems-docs 
>>> manual.
>>>
>> How do we get the large number of BSP_OPTS parameters out of the BSPs and 
>> into
>> suitable documentation? I am reluctant to support fragmented or partial
>> approaches to solving this problem, I feel the "project" or effect needs to
>> accept _all_ BSPs need to be covered. This is a community effort that needs 
>> some
>> leadership and ownership.
>>
>> It is a difficult area because:
>>
>> 1. The overlap to device TRMs and yet wanting to provide some self contained
>> information for a device knowledgeable user.
>>
>> 2. How is it maintained and checked? Reviews of patches require related doc
>> patches?
>>
>> 3. Changing the build system, the waf build Amar created changes the way
>> BSP_OPTS are handled requiring clear definition with ranges and other factors
>> and that could be annotated with suitable documentation allowing automatic
>> generation. Do we push for funding for this effort and deal with it then?
> 
> For BSP documentation you need to know the hardware and the BSP in detail. I
> think we can only do this step by step and should focus on the BSPs that are
> still in use and maintained. We need a clear concept of the desired BSP
> documentation, so that it is easy for new contributors to fix the 
> documentation
> of their BSP of interest. A build configuration command line help for BSP
> options would be nice, but I think this is optional. I would remove the BSP
> options documentation in configure.ac for BSPs which document the options in a
> manual. If we want to provide build configuration command line help, then we
> should generate it from some documentation master and use it for the command
> line help and the manual. This is some extra effort. It is probably in the 
> range
> of several man weeks to update the documentation of all BSPs.

Agreed and this will need to change any way. A waf build system would bring all
these option out to the top level which is a important. They are hidden at the
moment which is painful.

> The manual should have one level for the architectures, one level for the BSPs
> and one for the BSP details. I would not use more than three levels in a PDF
> document. Do we want to create a dedicated BSP manual or merge it into an
> existing manual (which one and how)?

Can the BSP and Driver Guide be used or do you think we need something new?

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

Re: x86_64 port and BSP (GSoC 2018)

[Chris Johns]

On 20/03/2018 18:10, Amaan Cheval wrote:
> On Tue, Mar 20, 2018 at 11:44 AM Chris Johns  wrote:
>> On 20/03/2018 16:21, Amaan Cheval wrote:
>>> On Tue, Mar 20, 2018 at 8:23 AM Chris Johns  wrote:
 On 19/03/2018 18:36, Amaan Cheval wrote:
>>> (Assuming that by tables you meant the Local Vector Table, etc., and not
>>> the ACPI's MADT, which is relevant to SMP in that it contains a list of
>>> LAPICs, thereby letting us find how many cores are available.)
> 
>> I was thinking about the SMP tables. SMP is not part of this work at the
> moment
>> so what ever is needed in this area to make the BSP work. Is the Local
> Vector
>> Table included in the list of tables?
> 
> Oh, did you mean the MP Table / ACPI MADT as mentioned in the 2nd bullet
> here? (From volume 3 of Intel's IA32 and 64 manual.)
> https://i.imgur.com/elZIlfy.png

It has been a while since I looked at this. Is there a table for interrupts and
interrupts beyond the master/slave legacy PICs?

> One of those tables will need to be parsed to configure boot for SMP
> systems correctly, yes. I thought you meant the tables that need to be
> setup for the local APIC to be initialized and used correctly (which is
> also necessary to be able to send Startup Inter-Proessor Interrupts (SIPI)
> for SMP boot to work).

I think interrupts to access to various PCI devices beyond the slave PIC is all
we need for now.

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

Re: Improve coverage analysis toolset

[Joel Sherrill]

Just a couple of questions and planning issues. The planning issues
are because the requirements for some of the work are likely not solid
on our side.

1. Do you plan to work on identifying the discrepancies between
what covoar reports directly and what gcov reports based on its
gcov file output? I ask because I lined up someone from the GCC
community who should be able to tell us what is not right once
we have specific cases.

2. My recollection is that the symbol set file is generated from
the RTEMS libraries under test. The scripting that generates this
file will have to change also. The set of symbols changes as
RTEMS evolves.

3. Chris has had ideas on changing the output from directly
producing ascii and html to something else. It is on he and I
to give you input on the actual format.

Personally getting all existing work merged and it in a state
where we can produce coverage reports again is really a
critical thing. The previous work changed it from being
a standalone shell script that drove things to part of the RSB
and make it possible to have the reports based on subdirectories
rather than one large report.

I don't 'think this changes your plan except that the plan seems to
put gcov as bonus work. It isn't discussed as work during the
summer.It would be nice to get gcov correctness done earlier
because that might be the best way to nice reports. For
example, running lcov on the .gcov files produced by covoar
might be an option.

--joel


On Sun, Mar 25, 2018 at 3:16 PM, Vijay Kumar Banerjee <
vijaykumar9...@gmail.com> wrote:

> submitted !
> If you find time , please give final review as well.
>
> Thanks
>
> On 26 Mar 2018 1:44 a.m., "Joel Sherrill"  wrote:
>
>> I am out and not at a computer. Someone can double check me but I believe
>> you can replace the PDF you upload.
>>
>> Unless someone answers soon, just upload it.
>>
>> --joel
>>
>> On Mar 25, 2018 2:37 PM, "Vijay Kumar Banerjee" 
>> wrote:
>>
>>> It's the last day before the deadline!
>>> Please provide a final review of the proposal before submitting.
>>>
>>> Thanks
>>>
>>> -- vijay
>>>
>>> On 24 March 2018 at 21:37, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 hello mentors and other developers of the community , there are only
 three days remaining to the GSoC proposal submission deadline.

 I request the mentors and everyone in the community who has experience
 in RTEMS, to please go through my proposal for Coverage Analysis tool
 improvement project , if they have time , and suggest any kind of
 improvements and changes .
 here is the link to the proposal
 https://docs.google.com/document/d/1UjCWE1ojrpDQLQ2fQqxHU0SC
 rLETlerxD6t0SOcQNLQ/edit?usp=sharing
 Thank you

 -- vijay

 On 22 March 2018 at 04:30, Joel Sherrill  wrote:

> Glad you have tests running. Hopefully as Cillian suggested, you can
> fix the
> remaining issues to see coverage.
>
> We certainly need to get this merged if Chris is OK with it and it
> doesn't
> break anything else.
>
> I am reviewing proposals now. Seems to be a queue. :)
>
> --joel
>
> On Wed, Mar 21, 2018 at 4:42 AM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> Sir ,
>> I have done the changes in the proposal , based on the comments in
>> the google doc , please review it and suggest any further changes if
>> required
>>
>> Thank you ,
>> -- vijay
>>
>> P.S : the previous version is in parentheses , I will remove them
>> after you review the changes .
>>
>> On 18 March 2018 at 16:05, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> Thanks Cillian :)
>>>
>>> It's great to see it running ,  I'll do some background reading
>>> about RSB, and RTEMS-Tools along with the covoar code . And also work 
>>> on my
>>> python skills.
>>>
>>> to try rtems-test on a bsp that runs gdb , I tried it on erc32 and
>>> that also worked.
>>>
>>> I'm also waiting for Joel and other mentors' review on my draft
>>> proposal, so that I can also work on it and make any changes if needed.
>>>
>>> Thanks .
>>>
>>> -- vijay
>>>
>>> On 18 March 2018 at 14:17, Cillian O'Donnell 
>>> wrote:
>>>


 On 18 March 2018 at 06:47, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> It worked !
>

 That's great!  That's the good news then. I was using an old leon3
 build and maybe some older Qemu too and I think that's why I didn't 
 see any
 issues initially. I was hoping you could see the coverage running and 
 the
 reports generated from that but it looks like the full update to the
 current master will be necessary to 

Re: Improve coverage analysis toolset

[Vijay Kumar Banerjee]

submitted !
If you find time , please give final review as well.

Thanks

On 26 Mar 2018 1:44 a.m., "Joel Sherrill"  wrote:

> I am out and not at a computer. Someone can double check me but I believe
> you can replace the PDF you upload.
>
> Unless someone answers soon, just upload it.
>
> --joel
>
> On Mar 25, 2018 2:37 PM, "Vijay Kumar Banerjee" 
> wrote:
>
>> It's the last day before the deadline!
>> Please provide a final review of the proposal before submitting.
>>
>> Thanks
>>
>> -- vijay
>>
>> On 24 March 2018 at 21:37, Vijay Kumar Banerjee > > wrote:
>>
>>> hello mentors and other developers of the community , there are only
>>> three days remaining to the GSoC proposal submission deadline.
>>>
>>> I request the mentors and everyone in the community who has experience
>>> in RTEMS, to please go through my proposal for Coverage Analysis tool
>>> improvement project , if they have time , and suggest any kind of
>>> improvements and changes .
>>> here is the link to the proposal
>>> https://docs.google.com/document/d/1UjCWE1ojrpDQLQ2fQqxHU0SC
>>> rLETlerxD6t0SOcQNLQ/edit?usp=sharing
>>> Thank you
>>>
>>> -- vijay
>>>
>>> On 22 March 2018 at 04:30, Joel Sherrill  wrote:
>>>
 Glad you have tests running. Hopefully as Cillian suggested, you can
 fix the
 remaining issues to see coverage.

 We certainly need to get this merged if Chris is OK with it and it
 doesn't
 break anything else.

 I am reviewing proposals now. Seems to be a queue. :)

 --joel

 On Wed, Mar 21, 2018 at 4:42 AM, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> Sir ,
> I have done the changes in the proposal , based on the comments in the
> google doc , please review it and suggest any further changes if required
>
> Thank you ,
> -- vijay
>
> P.S : the previous version is in parentheses , I will remove them
> after you review the changes .
>
> On 18 March 2018 at 16:05, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> Thanks Cillian :)
>>
>> It's great to see it running ,  I'll do some background reading about
>> RSB, and RTEMS-Tools along with the covoar code . And also work on my
>> python skills.
>>
>> to try rtems-test on a bsp that runs gdb , I tried it on erc32 and
>> that also worked.
>>
>> I'm also waiting for Joel and other mentors' review on my draft
>> proposal, so that I can also work on it and make any changes if needed.
>>
>> Thanks .
>>
>> -- vijay
>>
>> On 18 March 2018 at 14:17, Cillian O'Donnell 
>> wrote:
>>
>>>
>>>
>>> On 18 March 2018 at 06:47, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 It worked !

>>>
>>> That's great!  That's the good news then. I was using an old leon3
>>> build and maybe some older Qemu too and I think that's why I didn't see 
>>> any
>>> issues initially. I was hoping you could see the coverage running and 
>>> the
>>> reports generated from that but it looks like the full update to the
>>> current master will be necessary to have a look. So until the parsing 
>>> for
>>> the INI files is added to the coverage.py we won't see the coverage
>>> running. Unfortunately, I'm in the middle of exams until the following
>>> Monday so I won't be able to sink any more time into it until then. You 
>>> can
>>> still figure out the RSB problem you're having and do some background
>>> reading, brush up on your Python skills, have a read of the covoar code
>>>
>>> https://github.com/RTEMS/rtems-tools/blob/master/tester/covo
>>> ar/covoar.cc
>>>
>>> just skim through, read the comments, get a sense of the what it's
>>> doing and in what order.
>>>
>>>
 It's great to see it running ! I have attached the result .

 -- vijay

 On 18 March 2018 at 02:31, Cillian O'Donnell  wrote:

>
>
> On 17 March 2018 at 20:08, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> yes it prints hello world
>>
>
> Alright I've added an .ini for leon3-qemu to the current
> rtems-tools. Pull this branch
>
> https://github.com/cillianodonnell/rtems-tools/tree/ini-update
>
> and try
>
> $HOME/development/rtems/test/rtems-tools/tester/rtems-test
> --rtems-tools=$HOME/development/rtems/5
> --log=coverage-analysis.log --rtems-bsp=leon3_qemu
> $HOME/development/rtems/leon3/sparc-rtems5/c/leon3/testsuite
> s/samples
>
>>
>> -- vijay
>>
>> On 18 March 2018 at 01:31, Cillian O'Donnell <

Re: Improve coverage analysis toolset

[Joel Sherrill]

I am out and not at a computer. Someone can double check me but I believe
you can replace the PDF you upload.

Unless someone answers soon, just upload it.

--joel

On Mar 25, 2018 2:37 PM, "Vijay Kumar Banerjee" 
wrote:

> It's the last day before the deadline!
> Please provide a final review of the proposal before submitting.
>
> Thanks
>
> -- vijay
>
> On 24 March 2018 at 21:37, Vijay Kumar Banerjee 
> wrote:
>
>> hello mentors and other developers of the community , there are only
>> three days remaining to the GSoC proposal submission deadline.
>>
>> I request the mentors and everyone in the community who has experience in
>> RTEMS, to please go through my proposal for Coverage Analysis tool
>> improvement project , if they have time , and suggest any kind of
>> improvements and changes .
>> here is the link to the proposal
>> https://docs.google.com/document/d/1UjCWE1ojrpDQLQ2fQqxHU0SC
>> rLETlerxD6t0SOcQNLQ/edit?usp=sharing
>> Thank you
>>
>> -- vijay
>>
>> On 22 March 2018 at 04:30, Joel Sherrill  wrote:
>>
>>> Glad you have tests running. Hopefully as Cillian suggested, you can fix
>>> the
>>> remaining issues to see coverage.
>>>
>>> We certainly need to get this merged if Chris is OK with it and it
>>> doesn't
>>> break anything else.
>>>
>>> I am reviewing proposals now. Seems to be a queue. :)
>>>
>>> --joel
>>>
>>> On Wed, Mar 21, 2018 at 4:42 AM, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 Sir ,
 I have done the changes in the proposal , based on the comments in the
 google doc , please review it and suggest any further changes if required

 Thank you ,
 -- vijay

 P.S : the previous version is in parentheses , I will remove them after
 you review the changes .

 On 18 March 2018 at 16:05, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> Thanks Cillian :)
>
> It's great to see it running ,  I'll do some background reading about
> RSB, and RTEMS-Tools along with the covoar code . And also work on my
> python skills.
>
> to try rtems-test on a bsp that runs gdb , I tried it on erc32 and
> that also worked.
>
> I'm also waiting for Joel and other mentors' review on my draft
> proposal, so that I can also work on it and make any changes if needed.
>
> Thanks .
>
> -- vijay
>
> On 18 March 2018 at 14:17, Cillian O'Donnell 
> wrote:
>
>>
>>
>> On 18 March 2018 at 06:47, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> It worked !
>>>
>>
>> That's great!  That's the good news then. I was using an old leon3
>> build and maybe some older Qemu too and I think that's why I didn't see 
>> any
>> issues initially. I was hoping you could see the coverage running and the
>> reports generated from that but it looks like the full update to the
>> current master will be necessary to have a look. So until the parsing for
>> the INI files is added to the coverage.py we won't see the coverage
>> running. Unfortunately, I'm in the middle of exams until the following
>> Monday so I won't be able to sink any more time into it until then. You 
>> can
>> still figure out the RSB problem you're having and do some background
>> reading, brush up on your Python skills, have a read of the covoar code
>>
>> https://github.com/RTEMS/rtems-tools/blob/master/tester/covo
>> ar/covoar.cc
>>
>> just skim through, read the comments, get a sense of the what it's
>> doing and in what order.
>>
>>
>>> It's great to see it running ! I have attached the result .
>>>
>>> -- vijay
>>>
>>> On 18 March 2018 at 02:31, Cillian O'Donnell 
>>> wrote:
>>>


 On 17 March 2018 at 20:08, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> yes it prints hello world
>

 Alright I've added an .ini for leon3-qemu to the current
 rtems-tools. Pull this branch

 https://github.com/cillianodonnell/rtems-tools/tree/ini-update

 and try

 $HOME/development/rtems/test/rtems-tools/tester/rtems-test
 --rtems-tools=$HOME/development/rtems/5
 --log=coverage-analysis.log --rtems-bsp=leon3_qemu
 $HOME/development/rtems/leon3/sparc-rtems5/c/leon3/testsuite
 s/samples

>
> -- vijay
>
> On 18 March 2018 at 01:31, Cillian O'Donnell <
> cpodonne...@gmail.com> wrote:
>
>> If you run just one test by itself without rtems-test
>>
>> qemu-system-sparc -no-reboot -monitor null -serial stdio
>> -nographic -M leon3_generic -kernel $HOME/development/rtems/leon3/
>> 

Re: Improve coverage analysis toolset

[Vijay Kumar Banerjee]

It's the last day before the deadline!
Please provide a final review of the proposal before submitting.

Thanks

-- vijay

On 24 March 2018 at 21:37, Vijay Kumar Banerjee 
wrote:

> hello mentors and other developers of the community , there are only three
> days remaining to the GSoC proposal submission deadline.
>
> I request the mentors and everyone in the community who has experience in
> RTEMS, to please go through my proposal for Coverage Analysis tool
> improvement project , if they have time , and suggest any kind of
> improvements and changes .
> here is the link to the proposal
> https://docs.google.com/document/d/1UjCWE1ojrpDQLQ2fQqxHU0SCrLETl
> erxD6t0SOcQNLQ/edit?usp=sharing
> Thank you
>
> -- vijay
>
> On 22 March 2018 at 04:30, Joel Sherrill  wrote:
>
>> Glad you have tests running. Hopefully as Cillian suggested, you can fix
>> the
>> remaining issues to see coverage.
>>
>> We certainly need to get this merged if Chris is OK with it and it doesn't
>> break anything else.
>>
>> I am reviewing proposals now. Seems to be a queue. :)
>>
>> --joel
>>
>> On Wed, Mar 21, 2018 at 4:42 AM, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> Sir ,
>>> I have done the changes in the proposal , based on the comments in the
>>> google doc , please review it and suggest any further changes if required
>>>
>>> Thank you ,
>>> -- vijay
>>>
>>> P.S : the previous version is in parentheses , I will remove them after
>>> you review the changes .
>>>
>>> On 18 March 2018 at 16:05, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 Thanks Cillian :)

 It's great to see it running ,  I'll do some background reading about
 RSB, and RTEMS-Tools along with the covoar code . And also work on my
 python skills.

 to try rtems-test on a bsp that runs gdb , I tried it on erc32 and that
 also worked.

 I'm also waiting for Joel and other mentors' review on my draft
 proposal, so that I can also work on it and make any changes if needed.

 Thanks .

 -- vijay

 On 18 March 2018 at 14:17, Cillian O'Donnell 
 wrote:

>
>
> On 18 March 2018 at 06:47, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> It worked !
>>
>
> That's great!  That's the good news then. I was using an old leon3
> build and maybe some older Qemu too and I think that's why I didn't see 
> any
> issues initially. I was hoping you could see the coverage running and the
> reports generated from that but it looks like the full update to the
> current master will be necessary to have a look. So until the parsing for
> the INI files is added to the coverage.py we won't see the coverage
> running. Unfortunately, I'm in the middle of exams until the following
> Monday so I won't be able to sink any more time into it until then. You 
> can
> still figure out the RSB problem you're having and do some background
> reading, brush up on your Python skills, have a read of the covoar code
>
> https://github.com/RTEMS/rtems-tools/blob/master/tester/covo
> ar/covoar.cc
>
> just skim through, read the comments, get a sense of the what it's
> doing and in what order.
>
>
>> It's great to see it running ! I have attached the result .
>>
>> -- vijay
>>
>> On 18 March 2018 at 02:31, Cillian O'Donnell 
>> wrote:
>>
>>>
>>>
>>> On 17 March 2018 at 20:08, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 yes it prints hello world

>>>
>>> Alright I've added an .ini for leon3-qemu to the current
>>> rtems-tools. Pull this branch
>>>
>>> https://github.com/cillianodonnell/rtems-tools/tree/ini-update
>>>
>>> and try
>>>
>>> $HOME/development/rtems/test/rtems-tools/tester/rtems-test
>>> --rtems-tools=$HOME/development/rtems/5 --log=coverage-analysis.log
>>> --rtems-bsp=leon3_qemu $HOME/development/rtems/leon3/
>>> sparc-rtems5/c/leon3/testsuites/samples
>>>

 -- vijay

 On 18 March 2018 at 01:31, Cillian O'Donnell  wrote:

> If you run just one test by itself without rtems-test
>
> qemu-system-sparc -no-reboot -monitor null -serial stdio
> -nographic -M leon3_generic -kernel $HOME/development/rtems/leon3/
> sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe
>
> Does the hello world print out?
>
> On 17 March 2018 at 14:46, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> I built it manually
>>
>> the environment variable PATH looks like this
>> /home/lunatic/qemu/install/bin:/home/lunatic/development/rte
>> 

24 Hours Until GSoC Application Deadline

[Joel Sherrill]

Hi

Less than 24 hours left to get your applications in as final.
Remember you can replace the PDF even when marked
final.

Please don't let a paperwork issue keep you from being
considered.

Thanks.

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