Re: x86_64 port and BSP (GSoC 2018)
On Mon, May 14, 2018 at 9:37 PM, Joel Sherrill wrote: > > > On Mon, May 14, 2018 at 10:20 AM, Gedare Bloom wrote: >> >> On Mon, May 14, 2018 at 9:30 AM, Sebastian Huber >> wrote: >> > On 14/05/18 15:20, Amaan Cheval wrote: >> >> >> >> For now, do we all agree to x86_64 as the arch, and x86_64_generic as >> >> the >> >> BSP? >> > >> > >> > I would drop the _generic. I don't think there will be a non-generic BSP >> > on >> > this architecture. >> > >> >> I agree. Use x86_64 for the arch. The BSP name can also be x86_64, or >> a variant of the generic such as (please don't hit me): amd64, x86 :) > > > amd64's not awful. :) > > Another direction which is dated now but I think FreeBSD has directories > with these names is the "PCxxx" standards. These are the PC System > Design Guide editions from Intel and Microsoft. > > https://en.wikipedia.org/wiki/PC_System_Design_Guide > > Unfortunately, the last was PC2001. > > http://tech-insider.org/windows/research/2000/1102.html > > But that predates UEFI so wouldn't be the best option. > > The PCxxx specifications show that the PC evolved slowly but has had > changes over the years. Don't assume that just because some peripherals > are part of the "CPU" component now that they aren't shared or won't > change in the future. For example, the PC/AT included the cascaded > part of i8259s which are still emulated today in "legacy" mode. However, > the APIC is the preferred interrupt controller now and it has been through > a couple of revisions as I recall. This is leading up to putting this > support > code in bsps/x86_64/shared and have BSP variants use various combinations. > You could start with a "legacy" BSP (bad name) which uses old style > interrupts, etc. As more code for "non-legacy" comes into being, use > it in another BSP variant. This is an interesting idea, but I think I'd rather lean away from it unless we plan on keeping both the legacy and non-legacy versions for the BSP variants. Is that the idea? In my vision, that might happen while I'm working on the port, in my fork, but what'll be upstreamed won't be multiple BSP variants (unless we come upon them naturally in the course of the work), in which case what'll be upstreamed won't need the segregation or the BSP variants, since it'll only be one variant. Does that seem misguided? (I'm also leaning away from it because I'm relatively uneducated about the history of computer architecture, so I'd need to spend more time figuring out how these things evolved, which seems unnecessary for the port.) FYI: For now, I'm going with "bsps/x86_64/amd64" in my fork, and we can fine-tune the BSP name and its alias as more discussion takes place (so as to not be blocked by a naming issue). > > --joel > >> >> >> >> > >> > -- >> > Sebastian Huber, embedded brains GmbH >> > >> > Address : Dornierstr. 4, D-82178 Puchheim, Germany >> > Phone : +49 89 189 47 41-16 >> > Fax : +49 89 189 47 41-09 >> > E-Mail : sebastian.hu...@embedded-brains.de >> > PGP : Public key available on request. >> > >> > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. >> > >> > ___ >> > devel mailing list >> > devel@rtems.org >> > http://lists.rtems.org/mailman/listinfo/devel >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > > > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 1/1] Fix and extend error message in posix timer test
_Timespec_Equal_to() does not set errno, hence avoid using perror(),
instead use fprintf() to stderr, and extend the error message to provide
information about what the error is (measured timer value after
re-arming is not equal to the configured interval), and how large of a
difference was measured.
Signed-off-by: Martin Erik Werner
---
testsuites/psxtests/psxtimer01/psxtimer.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/testsuites/psxtests/psxtimer01/psxtimer.c
b/testsuites/psxtests/psxtimer01/psxtimer.c
index 032e9f8e6c..6ec049ac54 100644
--- a/testsuites/psxtests/psxtimer01/psxtimer.c
+++ b/testsuites/psxtests/psxtimer01/psxtimer.c
@@ -143,7 +143,12 @@ void * task_a (void *arg)
rtems_test_exit(0);
}
if (! _Timespec_Equal_to( &timerdata.it_value, &my_period )){
- perror ("Error in Task A timer_gettime\n");
+ fprintf(
+ stderr, "Error in Task A timer_gettime:\n"
+ " re-armed timer: %" PRIdtime_t ":%ld does not match interval: %"
PRIdtime_t ":%ld\n",
+ timerdata.it_value.tv_sec, timerdata.it_value.tv_nsec,
+ my_period.tv_sec, my_period.tv_nsec
+ );
}
clock = time(NULL);
printf("Executing task A with count = %2i %s", params->count,
ctime(&clock));
@@ -291,7 +296,12 @@ void * task_c (void *arg)
rtems_test_exit(0);
}
if (! _Timespec_Equal_to( &timerdata.it_value, &my_period) ){
- perror ("Error in Task C timer_gettime\n");
+ fprintf(
+ stderr, "Error in Task A timer_gettime:\n"
+ " re-armed timer: %" PRIdtime_t ":%ld does not match interval: %"
PRIdtime_t ":%ld\n",
+ timerdata.it_value.tv_sec, timerdata.it_value.tv_nsec,
+ my_period.tv_sec, my_period.tv_nsec
+ );
}
pthread_mutex_lock (&data.mutex);
while (data.updated == FALSE) {
--
2.11.0
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 0/1] posixtimer01 test questions and patch
When running the testsuites/psxtests/psxtimer01/ tests on our or1k
board, I've noticed a common 10ms (one clock tick) time difference when
measuring the re-armed time value in task A and C, which causes the
posixtimer01 test to report failure:
(...)
if (sigwait(&set,&received_sig) == -1) {
perror ("Error in sigwait\n");
}
if (timer_gettime(timer_id, &timerdata) == -1) {
perror ("Error in timer_gettime\n");
rtems_test_exit(0);
}
if (! _Timespec_Equal_to( &timerdata.it_value, &my_period )){
perror ("Error in Task A timer_gettime\n");
}
(...)
Given that this time value check is disabled in task B:
#if 0
/*
* It is not an error if they are not equal. A clock tick could occur
* and thus they are close but not equal. Can we test for this?
*/
if ( !_Timespec_Equal_to( &timerdata.it_value, &my_period) ){
printf( "NOT EQUAL %d:%d != %d:%d\n",
timerdata.it_value.tv_sec,
timerdata.it_value.tv_nsec,
my_period.tv_sec,
my_period.tv_nsec
);
rtems_test_exit(0);
}
#endif
does this check still belong as a certain failure in task A and C?
I've made a modification to the failure printout in order to avoid using unset
errno, and to provide information about the time difference, which might be
interesting, if these checks are still valid as certain failures:
Martin Erik Werner (1):
Fix and extend error message in posix timer test
testsuites/psxtests/psxtimer01/psxtimer.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
--
2.11.0
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Move to bsps finished?
Hello, I just wanted to ask if the reorganization of the BSP source code is more or less finished? Then this might be a good point for us to pull the changes into our local copies to be close to the development branch again otherwise it might be easier to wait a bit longer. Best regards, Jan Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR) German Aerospace Center Simulation and Software Technology | Software for Space Systems and Interactive Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany Jan Sommer Telephone +49 531 295-2494 | Telefax 0531 295-2767 | jan.som...@dlr.de DLR.de/SC ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Move to bsps finished?
Hey Jan! The ticket tracking the BSP reorganization seems to have been closed once the docs were updated, so I'm leaning towards a yes for them being more or less finished (except for perhaps minor changes in case something was missed, I imagine). Ticket: https://devel.rtems.org/ticket/3285 If you'd like to be safe, it might be better if one of the maintainers also confirmed. Cheers On Tue, May 15, 2018 at 5:56 PM, wrote: > Hello, > > I just wanted to ask if the reorganization of the BSP source code is more or > less finished? > Then this might be a good point for us to pull the changes into our local > copies to be close to the development branch again otherwise it might be > easier to wait a bit longer. > > Best regards, > >Jan > > > > Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR) > German Aerospace Center > Simulation and Software Technology | Software for Space Systems and > Interactive Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany > > Jan Sommer > Telephone +49 531 295-2494 | Telefax 0531 295-2767 | jan.som...@dlr.de > DLR.de/SC > > ___ > 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: Move to bsps finished?
Hello Jan, the source and header file moves in the BSP area are done. We may still move some selected files around. The build files still have to move, but this is a matter of months. - Am 15. Mai 2018 um 14:45 schrieb Amaan Cheval amaan.che...@gmail.com: > Hey Jan! > > The ticket tracking the BSP reorganization seems to have been closed > once the docs were updated, so I'm leaning towards a yes for them > being more or less finished (except for perhaps minor changes in case > something was missed, I imagine). > > Ticket: > https://devel.rtems.org/ticket/3285 > > If you'd like to be safe, it might be better if one of the maintainers > also confirmed. > > Cheers > > On Tue, May 15, 2018 at 5:56 PM, wrote: >> Hello, >> >> I just wanted to ask if the reorganization of the BSP source code is more or >> less finished? >> Then this might be a good point for us to pull the changes into our local >> copies >> to be close to the development branch again otherwise it might be easier to >> wait a bit longer. >> >> Best regards, >> >>Jan >> >> >> >> Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR) >> German Aerospace Center >> Simulation and Software Technology | Software for Space Systems and >> Interactive >> Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany >> >> Jan Sommer >> Telephone +49 531 295-2494 | Telefax 0531 295-2767 | jan.som...@dlr.de >> DLR.de/SC >> >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 2/2] sparc64 niagara, usiii: Remove -D options from cfg file and move to bspopts.h
I have no problem with it, but it must be tested :) Just a compile-only check is fine. On Mon, May 14, 2018 at 4:33 PM, Joel Sherrill wrote: > I haven't tested this but what do you think of this? > > > -RTEMS_BSPOPTS_SET([US3],[usiii],[1]) > -RTEMS_BSPOPTS_SET([US3],[*],[]) > -RTEMS_BSPOPTS_HELP([US3], > -[If defined, enable UltraSPARC optons for the USIII BSP.]) > - > -RTEMS_BSPOPTS_SET([SUN4U],[usiii],[1]) > -RTEMS_BSPOPTS_SET([SUN4U],[*],[]) > -RTEMS_BSPOPTS_HELP([SUN4U], > -[If defined, enable SUN model optons for the USIII BSP.]) > +AC_DEFINE(US3, 1, [UltraSPARC model option]) > +AC_DEFINE(SUN4U, 1, [SUN model option]) > > > On Sun, May 13, 2018 at 11:16 AM, Joel Sherrill wrote: >> >> >> >> On Sun, May 13, 2018, 10:20 AM Gedare Bloom wrote: >>> >>> On Wed, May 9, 2018 at 4:23 PM, Joel Sherrill wrote: >>> > Updates #3425. >>> > --- >>> > bsps/sparc64/include/arch/arch.h | 4 >>> > bsps/sparc64/include/arch/mm/frame.h | 4 >>> > bsps/sparc64/include/arch/mm/mmu.h| 4 >>> > bsps/sparc64/include/arch/mm/tlb.h| 3 +++ >>> > bsps/sparc64/include/arch/mm/tte.h| 4 >>> > bsps/sparc64/niagara/config/niagara.cfg | 2 +- >>> > bsps/sparc64/usiii/config/usiii.cfg | 2 +- >>> > c/src/lib/libbsp/sparc64/niagara/configure.ac | 4 >>> > c/src/lib/libbsp/sparc64/usiii/configure.ac | 10 +- >>> > 9 files changed, 34 insertions(+), 3 deletions(-) >>> > >>> > diff --git a/bsps/sparc64/include/arch/arch.h >>> > b/bsps/sparc64/include/arch/arch.h >>> > index 5fdd4a2..36aa922 100644 >>> > --- a/bsps/sparc64/include/arch/arch.h >>> > +++ b/bsps/sparc64/include/arch/arch.h >>> > @@ -37,10 +37,14 @@ >>> > #ifndef KERN_sparc64_ARCH_H_ >>> > #define KERN_sparc64_ARCH_H_ >>> > >>> > +#include >>> > + >>> > #if defined (SUN4U) >>> > #include >>> > #elif defined (SUN4V) >>> > #include >>> > +#else >>> > +#error "No SUN model defined" >>> > #endif >>> > >>> > #define ASI_AIUP 0x10/** Access to primary context >>> > with user privileges. */ >>> > diff --git a/bsps/sparc64/include/arch/mm/frame.h >>> > b/bsps/sparc64/include/arch/mm/frame.h >>> > index fb66e54..2fc17cc 100644 >>> > --- a/bsps/sparc64/include/arch/mm/frame.h >>> > +++ b/bsps/sparc64/include/arch/mm/frame.h >>> > @@ -35,10 +35,14 @@ >>> > #ifndef KERN_sparc64_FRAME_H_ >>> > #define KERN_sparc64_FRAME_H_ >>> > >>> > +#include >>> > + >>> > #if defined (SUN4U) >>> > #include >>> > #elif defined (SUN4V) >>> > #include >>> > +#else >>> > +#error "No SUN model defined" >>> > #endif >>> > >>> > #endif >>> > diff --git a/bsps/sparc64/include/arch/mm/mmu.h >>> > b/bsps/sparc64/include/arch/mm/mmu.h >>> > index 1d445f2..aab143f 100644 >>> > --- a/bsps/sparc64/include/arch/mm/mmu.h >>> > +++ b/bsps/sparc64/include/arch/mm/mmu.h >>> > @@ -35,10 +35,14 @@ >>> > #ifndef KERN_sparc64_MMU_H_ >>> > #define KERN_sparc64_MMU_H_ >>> > >>> > +#include >>> > + >>> > #if defined (SUN4U) >>> > #include >>> > #elif defined (SUN4V) >>> > #include >>> > +#else >>> > +#error "No SUN model defined" >>> > #endif >>> > >>> > >>> > diff --git a/bsps/sparc64/include/arch/mm/tlb.h >>> > b/bsps/sparc64/include/arch/mm/tlb.h >>> > index 4adf26c..7a6b85d 100644 >>> > --- a/bsps/sparc64/include/arch/mm/tlb.h >>> > +++ b/bsps/sparc64/include/arch/mm/tlb.h >>> > @@ -35,11 +35,14 @@ >>> > #ifndef KERN_sparc64_TLB_H_ >>> > #define KERN_sparc64_TLB_H_ >>> > >>> > +#include >>> > >>> > #if defined (SUN4U) >>> > #include >>> > #elif defined (SUN4V) >>> > #include >>> > +#else >>> > +#error "No SUN model defined" >>> > #endif >>> > >>> > #endif >>> > diff --git a/bsps/sparc64/include/arch/mm/tte.h >>> > b/bsps/sparc64/include/arch/mm/tte.h >>> > index f0b746e..10a672b 100644 >>> > --- a/bsps/sparc64/include/arch/mm/tte.h >>> > +++ b/bsps/sparc64/include/arch/mm/tte.h >>> > @@ -35,10 +35,14 @@ >>> > #ifndef KERN_sparc64_TTE_H_ >>> > #define KERN_sparc64_TTE_H_ >>> > >>> > +#include >>> > + >>> > #if defined (SUN4U) >>> > #include >>> > #elif defined (SUN4V) >>> > #include >>> > +#else >>> > +#error "No SUN model defined" >>> > #endif >>> > >>> > #endif >>> > diff --git a/bsps/sparc64/niagara/config/niagara.cfg >>> > b/bsps/sparc64/niagara/config/niagara.cfg >>> > index 2fd8973..bfa73aa 100644 >>> > --- a/bsps/sparc64/niagara/config/niagara.cfg >>> > +++ b/bsps/sparc64/niagara/config/niagara.cfg >>> > @@ -7,7 +7,7 @@ RTEMS_CPU=sparc64 >>> > >>> > # This contains the compiler options necessary to select the CPU >>> > model >>> > # and (hopefully) optimize for it. >>> > -CPU_CFLAGS = -mcpu=niagara -DSUN4V >>> > +CPU_CFLAGS = -mcpu=niagara >>> > >>> > # optimize flag: typically -g -O2 >>> > CFLAGS_OPTIMIZE_V = -g -O2 >>> > diff --git a/bsps/sparc64/usiii/config/usiii.cfg >>> > b/bsps/sparc64/usiii/config/usiii.cfg >>> > index b9fad21..ee1c508 100644 >>> > --- a/bsps/sparc64/usiii/config/usiii.cfg >>> > +++ b/bsps/sparc64/
Re: [GSOC] Weekly report
Minor nit: please put a short description of your project in the title (e.g., "tracing") just to avoid overly plain and possibly confusing titles if multiple students start to do this. Thanks for the update! On Mon, May 14, 2018 at 9:12 PM, Vidushi Vashishth wrote: > Hi! > > As asked by my mentor, I am going to post my weekly project target on the > mailing list every Monday. For this week I have the following planned: > > 1) Develop use cases (common development problems catered to, etc) for the > rtems tracing support and identify what all needs to be implemented around > with it. This would be documented first in my blog then the users manual. > > 2) Create a babeltrace conversion formula for CTF conversion. Document it > with sufficient example test cases. > > 3) Fixing the buffering sample test cases which is currently failing a > rtems-path check on execution. > > 4) Gain familiarity with barectf, identify methods of integrating it with > rtems-tld output and working on array support for barectf. > > > Best, > Vidushi ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RE: Move to bsps finished?
> -Original Message- > From: Amaan Cheval [mailto:amaan.che...@gmail.com] > Sent: Tuesday, May 15, 2018 2:46 PM > To: Sommer, Jan > Cc: RTEMS > Subject: Re: Move to bsps finished? > > Hey Jan! > > The ticket tracking the BSP reorganization seems to have been closed > once the docs were updated, so I'm leaning towards a yes for them > being more or less finished (except for perhaps minor changes in case > something was missed, I imagine). > > Ticket: > https://devel.rtems.org/ticket/3285 > Ah, I forgot about this. Thank you for reminding me. I guess if the ticket is closed it is safe to start. If there will be smaller changes it probably won't be a problem. > If you'd like to be safe, it might be better if one of the maintainers > also confirmed. > > Cheers > > On Tue, May 15, 2018 at 5:56 PM, wrote: > > Hello, > > > > I just wanted to ask if the reorganization of the BSP source code is more or > less finished? > > Then this might be a good point for us to pull the changes into our local > > copies > to be close to the development branch again otherwise it might be easier to > wait a bit longer. > > > > Best regards, > > > >Jan > > > > > > > > Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR) > > German Aerospace Center > > Simulation and Software Technology | Software for Space Systems and > Interactive Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany > > > > Jan Sommer > > Telephone +49 531 295-2494 | Telefax 0531 295-2767 | jan.som...@dlr.de > > DLR.de/SC > > > > ___ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 2/2] sparc64 niagara, usiii: Remove -D options from cfg file and move to bspopts.h
On Tue, May 15, 2018 at 7:59 AM, Gedare Bloom wrote: > I have no problem with it, but it must be tested :) Just a > compile-only check is fine. > Awesome! I will test the patch. I did this on a machine without sparc64 tools just to see if I could find an answer. --joel > > On Mon, May 14, 2018 at 4:33 PM, Joel Sherrill wrote: > > I haven't tested this but what do you think of this? > > > > > > -RTEMS_BSPOPTS_SET([US3],[usiii],[1]) > > -RTEMS_BSPOPTS_SET([US3],[*],[]) > > -RTEMS_BSPOPTS_HELP([US3], > > -[If defined, enable UltraSPARC optons for the USIII BSP.]) > > - > > -RTEMS_BSPOPTS_SET([SUN4U],[usiii],[1]) > > -RTEMS_BSPOPTS_SET([SUN4U],[*],[]) > > -RTEMS_BSPOPTS_HELP([SUN4U], > > -[If defined, enable SUN model optons for the USIII BSP.]) > > +AC_DEFINE(US3, 1, [UltraSPARC model option]) > > +AC_DEFINE(SUN4U, 1, [SUN model option]) > > > > > > On Sun, May 13, 2018 at 11:16 AM, Joel Sherrill wrote: > >> > >> > >> > >> On Sun, May 13, 2018, 10:20 AM Gedare Bloom wrote: > >>> > >>> On Wed, May 9, 2018 at 4:23 PM, Joel Sherrill wrote: > >>> > Updates #3425. > >>> > --- > >>> > bsps/sparc64/include/arch/arch.h | 4 > >>> > bsps/sparc64/include/arch/mm/frame.h | 4 > >>> > bsps/sparc64/include/arch/mm/mmu.h| 4 > >>> > bsps/sparc64/include/arch/mm/tlb.h| 3 +++ > >>> > bsps/sparc64/include/arch/mm/tte.h| 4 > >>> > bsps/sparc64/niagara/config/niagara.cfg | 2 +- > >>> > bsps/sparc64/usiii/config/usiii.cfg | 2 +- > >>> > c/src/lib/libbsp/sparc64/niagara/configure.ac | 4 > >>> > c/src/lib/libbsp/sparc64/usiii/configure.ac | 10 +- > >>> > 9 files changed, 34 insertions(+), 3 deletions(-) > >>> > > >>> > diff --git a/bsps/sparc64/include/arch/arch.h > >>> > b/bsps/sparc64/include/arch/arch.h > >>> > index 5fdd4a2..36aa922 100644 > >>> > --- a/bsps/sparc64/include/arch/arch.h > >>> > +++ b/bsps/sparc64/include/arch/arch.h > >>> > @@ -37,10 +37,14 @@ > >>> > #ifndef KERN_sparc64_ARCH_H_ > >>> > #define KERN_sparc64_ARCH_H_ > >>> > > >>> > +#include > >>> > + > >>> > #if defined (SUN4U) > >>> > #include > >>> > #elif defined (SUN4V) > >>> > #include > >>> > +#else > >>> > +#error "No SUN model defined" > >>> > #endif > >>> > > >>> > #define ASI_AIUP 0x10/** Access to primary context > >>> > with user privileges. */ > >>> > diff --git a/bsps/sparc64/include/arch/mm/frame.h > >>> > b/bsps/sparc64/include/arch/mm/frame.h > >>> > index fb66e54..2fc17cc 100644 > >>> > --- a/bsps/sparc64/include/arch/mm/frame.h > >>> > +++ b/bsps/sparc64/include/arch/mm/frame.h > >>> > @@ -35,10 +35,14 @@ > >>> > #ifndef KERN_sparc64_FRAME_H_ > >>> > #define KERN_sparc64_FRAME_H_ > >>> > > >>> > +#include > >>> > + > >>> > #if defined (SUN4U) > >>> > #include > >>> > #elif defined (SUN4V) > >>> > #include > >>> > +#else > >>> > +#error "No SUN model defined" > >>> > #endif > >>> > > >>> > #endif > >>> > diff --git a/bsps/sparc64/include/arch/mm/mmu.h > >>> > b/bsps/sparc64/include/arch/mm/mmu.h > >>> > index 1d445f2..aab143f 100644 > >>> > --- a/bsps/sparc64/include/arch/mm/mmu.h > >>> > +++ b/bsps/sparc64/include/arch/mm/mmu.h > >>> > @@ -35,10 +35,14 @@ > >>> > #ifndef KERN_sparc64_MMU_H_ > >>> > #define KERN_sparc64_MMU_H_ > >>> > > >>> > +#include > >>> > + > >>> > #if defined (SUN4U) > >>> > #include > >>> > #elif defined (SUN4V) > >>> > #include > >>> > +#else > >>> > +#error "No SUN model defined" > >>> > #endif > >>> > > >>> > > >>> > diff --git a/bsps/sparc64/include/arch/mm/tlb.h > >>> > b/bsps/sparc64/include/arch/mm/tlb.h > >>> > index 4adf26c..7a6b85d 100644 > >>> > --- a/bsps/sparc64/include/arch/mm/tlb.h > >>> > +++ b/bsps/sparc64/include/arch/mm/tlb.h > >>> > @@ -35,11 +35,14 @@ > >>> > #ifndef KERN_sparc64_TLB_H_ > >>> > #define KERN_sparc64_TLB_H_ > >>> > > >>> > +#include > >>> > > >>> > #if defined (SUN4U) > >>> > #include > >>> > #elif defined (SUN4V) > >>> > #include > >>> > +#else > >>> > +#error "No SUN model defined" > >>> > #endif > >>> > > >>> > #endif > >>> > diff --git a/bsps/sparc64/include/arch/mm/tte.h > >>> > b/bsps/sparc64/include/arch/mm/tte.h > >>> > index f0b746e..10a672b 100644 > >>> > --- a/bsps/sparc64/include/arch/mm/tte.h > >>> > +++ b/bsps/sparc64/include/arch/mm/tte.h > >>> > @@ -35,10 +35,14 @@ > >>> > #ifndef KERN_sparc64_TTE_H_ > >>> > #define KERN_sparc64_TTE_H_ > >>> > > >>> > +#include > >>> > + > >>> > #if defined (SUN4U) > >>> > #include > >>> > #elif defined (SUN4V) > >>> > #include > >>> > +#else > >>> > +#error "No SUN model defined" > >>> > #endif > >>> > > >>> > #endif > >>> > diff --git a/bsps/sparc64/niagara/config/niagara.cfg > >>> > b/bsps/sparc64/niagara/config/niagara.cfg > >>> > index 2fd8973..bfa73aa 100644 > >>> > --- a/bsps/sparc64/niagara/config/niagara.cfg > >>> > +++ b/bsps/sparc64/niagara/config/niagara.cfg > >>> > @@ -7,7 +7,7 @@ RTEMS_CPU=sparc64 > >>> > > >>> > # T
Re: [GSOC] Weekly report
Oh okay, will keep that in mind from the next time! On Tue, May 15, 2018 at 6:31 PM, Gedare Bloom wrote: > Minor nit: please put a short description of your project in the title > (e.g., "tracing") just to avoid overly plain and possibly confusing > titles if multiple students start to do this. Thanks for the update! > > On Mon, May 14, 2018 at 9:12 PM, Vidushi Vashishth > wrote: > > Hi! > > > > As asked by my mentor, I am going to post my weekly project target on the > > mailing list every Monday. For this week I have the following planned: > > > > 1) Develop use cases (common development problems catered to, etc) for > the > > rtems tracing support and identify what all needs to be implemented > around > > with it. This would be documented first in my blog then the users manual. > > > > 2) Create a babeltrace conversion formula for CTF conversion. Document it > > with sufficient example test cases. > > > > 3) Fixing the buffering sample test cases which is currently failing a > > rtems-path check on execution. > > > > 4) Gain familiarity with barectf, identify methods of integrating it with > > rtems-tld output and working on array support for barectf. > > > > > > Best, > > Vidushi > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
