Re: tar/psx/bsdtar on CentOS 8

[Sebastian Huber]

- Am 28. Feb 2020 um 23:07 schrieb Chris Johns chr...@rtems.org:

>>> On 29 Feb 2020, at 6:10 am, Jeff Mayes  wrote:
>> 
>> Aha!  So, spax provides pax now, and spax is in the BaseOS Repo.  That’ll 
>> need
>> to be updated in the documentation.
>>  
> 
> We need the PAX format from any source. I switched to the pax command because
> POSIX defines it and silly me thought a POSIX OS would always provide it.
> 
> If all the tar implementations support an option to generate the PAX format we
> can change back to tar.
> 
> We need to:
> - check tar on each host
> - check a test exe that is built
> 
> Would this be a simpler long term solution?

The problem with tar is that for the tests the file name replacement is quite 
handy. GNU tar supports --transform, BSD tar doesn't support this and instead 
offers a -s option. Is gtar available by default on FreeBSD? I can add support 
for this in the new build system, e.g. check for pax, then gtar, then tar, then 
figure out if its GNU or BSD tar.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] added fesetexeptflag() test to the psxfenv test

[Eshan Dhawan]

I had sent it a few days ago but no one reviewed it.
I would like if someone could check it and give feedback.


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

Re: Project for GSoC 2020

[Utkarsh Rai]

I have gone through the details of the project adding memory protection
 using MMU and have a few questions
and observations regarding the same-

1. Is this a project for which someone from the community would be willing
to mentor for GSoC?
2. As far I could understand by looking into the rtems tree ARM uses static
initialization wherein it first invalidates the cache and TLB blocks and
then performs initialization by setting up a 1 to 1 mapping of the parts of
address space. According to me, static initialization of the mmu is a
generic enough method that can be utilized in most of the architectures.
3. For the thread stack protection, I believe either of the stack guard
protection approach or by verification of stack canaries whereby the OS on
each context switch would check whether the numbers associated with the
canaries are still intact or not are worth considering. Although I still
only have a high-level idea of both of these approaches and will be looking
into their implementation details, I would request your kind feedback on it.

Regards,
Utkarsh Rai.

On Fri, Feb 21, 2020 at 10:28 PM Utkarsh Rai 
wrote:

> Thanks, I will check it out.
>
> On Fri, Feb 21, 2020 at 12:56 AM Gedare Bloom  wrote:
>
>> On Tue, Feb 18, 2020 at 12:45 PM Utkarsh Rai 
>> wrote:
>> >
>> > Based on your feedback,  adding memory protection or enhancing Wi-fi
>> Support in libbsd are two projects that I would like to work upon.
>> >
>> > For MMU support I think a lot unmerged PowerPC code is already present,
>> but since  I would be using BBB I would only be able to use that as a
>> reference. Is it feasible to start it from scratch?
>> >
>> The state-of-the-art has advanced in the rtems.git tree since these
>> projects happened, and it is not all documented. The ARM in particular
>> generally uses a static initialization or boot-time initialization of
>> the MMU. You  should study how the ARM approach works in the RTEMS
>> main repo, and consider whether that approach can be adopted by other
>> architectures/BSPs, how to improve that approach, and how to build
>> higher-level services on top of the low-level BSP support that exists.
>>
>> One of the main interesting applications is to provide thread stack
>> protection.
>>
>> > For Wi-Fi support, I would require an RTL8188 USB dongle along with
>> JTAG for debugging purposes. I am not quite sure about how to handle the
>> 'hot-plugging' case in this project it would be very helpful if someone
>> could point me in the right direction.
>> >
>> I can't speak to the WiFi support, maybe others know. But to get
>> started you would need to at least demonstrate that you have the
>> necessary hardware to succeed and that you can at a minimum boot/run
>> BBB with libbsd, and probably we should like you to show that you can
>> generate patches for libbsd.
>>
>> Gedare
>>
>> >
>> > On Tue, Feb 18, 2020 at 1:21 AM Gedare Bloom  wrote:
>> >>
>> >>
>> >> On Mon, Feb 17, 2020 at 9:42 AM Utkarsh Rai 
>> wrote:
>> >>>
>> >>> Hello everyone,
>> >>
>> >> Hello Utkarsh Rai,
>> >>
>> >>>
>> >>> I would like to contribute to the Beagleboard BSP project, in
>> particular towards the improvement of the peripheral support. I have a few
>> questions pertaining to the same:-
>> >>>
>> >>> 1. Is adding support for Ethernet and USB a reasonable goal for the
>> duration of the GSOC?
>> >>>
>> >>> 2. FreeBSD has support for Ethernet and USB  can we port that to
>> libbsd?
>> >>>
>> >>> 3. What are the deliverables for this project, for instance, would I
>> be required to add shell support for these peripherals or maybe an example
>> app?
>> >>>
>> >>> I have also attached a screenshot of the changed  'hello world'
>> program along with this email
>> >>
>> >> Thanks. It is nice to see that you already ran it successfully on the
>> BBB.
>> >>
>> >> As of now, the BBB has quite mature support including Ethernet and
>> USB. There is another student actively working on a proposal to expand our
>> BBB support a bit further. I'm not certain if there is sufficient
>> work/interest/mentoring available to support multiple BBB projects. You
>> might consider what specific projects would interest you though. You should
>> take a look at past years' GSoC projects documented on our wiki, they are
>> linked from our main 'GSoC' page.
>> >>
>> >> There are also lots of interesting projects that can be done in a
>> BSP-agnostic way, but still could be valuable to test with the BBB. The
>> most important aspect about doing development with a BBB is that you can
>> use the JTAG, which requires some soldering and additional effort to work
>> with a standalone JTAG debugger.  If you don't have that, and want to work
>> with the BBB, it is highly recommended.
>> >>
>> >>
>> >>>
>> >>> ___
>> >>> devel mailing list
>> >>> devel@rtems.org
>> >>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
___
devel m

Re: Odd Microblaze Tool Build Failure

[Joel Sherrill]

I see other reports of this failure. I haven't had a chance to check this
deeply but I was suspicious of the gcc configuration not getting __rtems__
defined.

On Thu, Feb 27, 2020, 11:17 AM Joel Sherrill  wrote:

> Hi
>
> The Microblaze uses the rtems-default.bset and is the only target that
> isn't compiling.
> It ends with this error which seems like something is off in a way that
> should impact
> all targets but doesn't. Any ideas?
>
> FWIW I am proceeding with the update. Since we don't actually have a
> Microblaze
> port yet, this is far from a blocker.
>
> =
> $ make >/dev/null
> ../../../../../../../gcc-7.5.0/newlib/libc/sys/rtems/crt0.c:197:18: error:
> conflicting types for '__assert_func'
>  RTEMS_STUB(void, __assert_func(const char *file, int line, const char
> *failedexpr), { })
>   ^
> ../../../../../../../gcc-7.5.0/newlib/libc/sys/rtems/crt0.c:28:5: note: in
> definition of macro 'RTEMS_STUB'
>  ret func body
>  ^~~~
> In file included from
> /data/home/joel/rtems-work/rtems-source-builder/rtems/build/microblaze-rtems5-gcc-7.5.0-newlib-fbaa096-x86_64-linux-gnu-1/gcc-7.5.0/newlib/libc/include/sys/reent.h:503:0,
>  from
> /data/home/joel/rtems-work/rtems-source-builder/rtems/build/microblaze-rtems5-gcc-7.5.0-newlib-fbaa096-x86_64-linux-gnu-1/gcc-7.5.0/newlib/libc/include/time.h:12,
>  from
> /data/home/joel/rtems-work/rtems-source-builder/rtems/build/microblaze-rtems5-gcc-7.5.0-newlib-fbaa096-x86_64-linux-gnu-1/gcc-7.5.0/newlib/libc/include/sys/stat.h:9,
>  from
> ../../../../../../../gcc-7.5.0/newlib/libc/sys/rtems/crt0.c:14:
> /data/home/joel/rtems-work/rtems-source-builder/rtems/build/microblaze-rtems5-gcc-7.5.0-newlib-fbaa096-x86_64-linux-gnu-1/gcc-7.5.0/newlib/libc/include/assert.h:41:6:
> note: previous declaration of '__assert_func' was here
>  void __assert_func (const char *, int, const char *, const char *)
>   ^
> make[9]: *** [crt0.o] Error 1
> cp: cannot stat ‘rtems/crt0.o’: No such file or directory
> make[9]: *** [crt0.o] Error 1
> ===
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsps/shared/grlib/1553/b1553brm.c : addressed logic issue and unsigned_compare

[suyash singh]

I don't know. There are checks for other things in the function when it
return other than successful.

Since it was never going to return "RTEMS_UNSATISFIED" as the "if" would
always evaluate to true I removed the unnecessary comparison

On Sat, Feb 29, 2020 at 2:52 AM Peter Dufault  wrote:

> And regardless of the value of count it is successful?
>
> > On Feb 28, 2020, at 12:17 , suyash singh 
> wrote:
> >
> > count is unsigned int and will always be >=0.
> >
> > On Fri, Feb 28, 2020 at 10:42 PM suyash singh 
> wrote:
> > ---
> >  bsps/shared/grlib/1553/b1553brm.c | 6 ++
> >  1 file changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/bsps/shared/grlib/1553/b1553brm.c
> b/bsps/shared/grlib/1553/b1553brm.c
> > index 57ef70126b..4041423541 100644
> > --- a/bsps/shared/grlib/1553/b1553brm.c
> > +++ b/bsps/shared/grlib/1553/b1553brm.c
> > @@ -982,10 +982,8 @@ static rtems_device_driver
> brm_write(rtems_device_major_number major, rtems_devi
> >
> > rw_args->bytes_moved = count;
> >
> > -   if (count >= 0) {
> > -   return RTEMS_SUCCESSFUL;
> > -   }
> > -   return RTEMS_UNSATISFIED;
> > +   return RTEMS_SUCCESSFUL;
> > +
> >  }
> >
> >  static rtems_device_driver brm_control(rtems_device_major_number major,
> rtems_device_minor_number minor, void *arg)
> > --
> > 2.17.1
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
> Peter
> -
> Peter Dufault
> HD Associates, Inc.  Software and System Engineering
>
> This email is delivered through the public internet using protocols
> subject to interception and tampering.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel