Re: libbsd master and 5-freebsd-12 build failure

[Sebastian Huber]

Yes, sorry. I managed to enable an obscure FreeBSD kernel option which 
breaks the IPv6 support:


https://lists.freebsd.org/pipermail/freebsd-hackers/2019-March/054379.html

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

Re: Stm32l4 contribution

[Chris Johns]

On 29/3/19 8:10 am, Ярослав Лещинский wrote:
> Today I added some patches related to stm32l4 board support. 

Fantastic.

> As it was the first
> time when I’m dealing with a contribution here in RTEMS, could you please 
> check:
> does this patches existed at all? I sent them via git email, so I’m not sure
> that I made all correct. 

Which address did you send them too?

I have checked this list and there are no pending posts.

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

libbsd master and 5-freebsd-12 build failure

[Chris Johns]

Hi,

I am seeing the following build failure on master and the R12 branch with this
configure command line:

 ./waf distclean configure --prefix=/opt/work/rtems/5
--rtems-tools=/opt/work/si/rtems/5 --rtems=/opt/work/rtems/5
--rtems-bsps=arm/xilinx_zynq_zc706

/opt/work/si/rtems/5/lib/gcc/arm-rtems5/7.4.0/../../../../arm-rtems5/bin/ld:
./libbsd.a(ip6_output.c.18.o): in function `_bsd_ip6_output':
/opt/work/si/rtems/rtems-libbsd.git/build/arm-rtems5-xilinx_zynq_zc706-default/../../freebsd/sys/netinet6/ip6_output.c:548:
undefined reference to `_bsd_in6_selectroute_fib'


/opt/work/si/rtems/5/lib/gcc/arm-rtems5/7.4.0/../../../../arm-rtems5/bin/ld:
./libbsd.a(nd6.c.18.o): in function `nd6_llinfo_timer':
/opt/work/si/rtems/rtems-libbsd.git/build/arm-rtems5-xilinx_zynq_zc706-default/../../freebsd/sys/netinet6/nd6.c:881:
undefined reference to `_bsd_nd6_ns_output'


/opt/work/si/rtems/5/lib/gcc/arm-rtems5/7.4.0/../../../../arm-rtems5/bin/ld:
./libbsd.a(nd6.c.18.o): in function `nd6_resolve_slow':
/opt/work/si/rtems/rtems-libbsd.git/build/arm-rtems5-xilinx_zynq_zc706-default/../../freebsd/sys/netinet6/nd6.c:2461:
undefined reference to `_bsd_nd6_ns_output'


/opt/work/si/rtems/5/lib/gcc/arm-rtems5/7.4.0/../../../../arm-rtems5/bin/ld:
./libbsd.a(nd6_nbr.c.18.o): in function `nd6_dad_ns_output':
/opt/work/si/rtems/rtems-libbsd.git/build/arm-rtems5-xilinx_zynq_zc706-default/../../freebsd/sys/netinet6/nd6_nbr.c:1513:
undefined reference to `_bsd_nd6_ns_output'


collect2: error: ld returned 1 exit status

I was building before I updated today.

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

Stm32l4 contribution

[Ярослав Лещинский]

Hello,

Today I added some patches related to stm32l4 board support. As it was the
first time when I’m dealing with a contribution here in RTEMS, could you
please check: does this patches existed at all? I sent them via git email,
so I’m not sure that I made all correct.

Thanks.
-- 
--
Kind regards,
*Yaroslav Leshchinsky*
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Fully disabled seemingly unsupported zynq_uart_set_attributes handler

[Chris Johns]

On 28/3/19 5:40 pm, Sebastian Huber wrote:
> On 27/03/2019 20:26, Chris Johns wrote:
>> On 28/3/19 5:28 am, Joel Sherrill wrote:
>>> On Wed, Mar 27, 2019 at 1:10 AM Sebastian Huber
>>> >> >
>>> wrote:
>>>  On 26/03/2019 15:17, Lou Woods wrote:
>>>  > From: Lou Woods 
>>>  >
>>>  > ---
>>>  >   bsps/arm/xilinx-zynq/console/zynq-uart.c | 16 +++-
>>>  >   1 file changed, 11 insertions(+), 5 deletions(-)
>>>  >
>>>  > diff --git a/bsps/arm/xilinx-zynq/console/zynq-uart.c
>>>  b/bsps/arm/xilinx-zynq/console/zynq-uart.c
>>>  > index fa91f3f..9c21f6f 100644
>>>  > --- a/bsps/arm/xilinx-zynq/console/zynq-uart.c
>>>  > +++ b/bsps/arm/xilinx-zynq/console/zynq-uart.c
>>>  > @@ -262,12 +262,16 @@ static void zynq_uart_write_support(
>>>  >   #endif
>>>  >   }
>>>  >
>>>  > +/*
>>>  > + * Disable this because the initialization is done by code generated
>>>  > + * by the Xilinx code generator.
>>>  > + */
>>>
>>>  The main purpose of the set attributes function is to apply the 
>>> settings
>>>  specified by the user via the Termios interface. Returning false just
>>>  indicates that this function is not implemented. If you want to hide
>>>  this fact from the user, then you can simply return true ...
>> This assumes all UART hardware supports all possible options. There are many
>> UARTs that do not. I am not sure if there are errno's that could determine 
>> the
>> nature of the failure.
>>
>>> We discussed this alternative with Chris and this was the end result.
>>>
>>> git blame shows that Chris added the if 0 and then you added the return 
>>> false
>>> which broke the callers. From that point forward, no interactive test ran
>>> successfully.
>> The driver provides no attribute functionality so removing the function means
>> the default behavior in termios is used to manage the error. It was decided
>> having the default behavior was best until the driver provided the 
>> functionality.
>>
>> The Zynq is sort of strange in relation to default settings for UARTs. The
>> SystemZ component in the Xilinx design tool provides settings for the UART 
>> and
>> this ends up in the ps7_init.c file generated by the SDK and built into the 
>> FSBL
>> bootloader. This code paints all registers including the UART at boot time.
>> Adding UART attribute setting code to the RTEMS driver would result in the
>> SystemZ settings being overridden by RTEMS which is confusing. I am not sure 
>> how
>> this can be handled without there being some conflict. RTEMS would need to 
>> set
>> the baudrate to 115200 to match the SystemZ default.
> 
> So even if we implement the set attributes we have the problem to figure out 
> in
> which state the UART is during initialization? 

I cannot figure out what the default for RTEMS should be and then how that
matches the bootloader and SystemZ settings.

> My hope was eventually someone will implement it.

Yes it would be good however we need a user who uses the UART for something
other than a console.

> Since nobody requested the set attributes function in a
> couple of years, I think it is all right to just remove it and return no 
> error.

Yeap.

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

Re: Project Track Page: Drafted proposal for Basic Support for Trace Compass

[Ravindra Kumar Meena]

Hi Gedare

I am aware of that. I am waiting for Sebastian to review my proposal.
Besides that, I am trying to find out the mechanism for Phase 1 and 2 as
mentioned in my GSoC proposal.

Thanks

On Thu, Mar 28, 2019 at 7:25 PM Gedare Bloom  wrote:

> Hi Ravindra,
>
> Please note that you can (and should) continue to improve your
> proposal throughout the application period. This is an important time
> to fine-tune your ideas and lay out your plans for the summer.
>
> Gedare
>
> On Wed, Mar 27, 2019 at 8:28 AM Ravindra Kumar Meena
>  wrote:
> >
> > Hi Sebastian,
> >
> > I have already submitted the proposal. Phase 1 of my proposal is to
> generate trace data(LTTng). So I tried this example to figure out the way
> for generating trace data(LTTng)
> https://lttng.org/docs/v2.10/#doc-tracing-your-own-user-application
> >
> > Maybe we could try out the same. I would like to hear your opinion on
> this.
> >
> > Thanks
> > --Ravindra Kumar Meena
> >
> > On Tue, Mar 26, 2019 at 10:27 PM Ravindra Kumar Meena <
> rmeena...@gmail.com> wrote:
> >>
> >> Great, thanks for the update.
> >>
> >> On Tue, Mar 26, 2019, 10:26 PM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> >>>
> >>> Hello Ravindra Kumar Meena,
> >>>
> >>> thanks for your proposal and the good work to prepare it. I will have
> a look at it this week.
> >
> >
> >
> > --
> > Ravindra Kumar Meena,
> > B. Tech. Computer Science and Engineering,
> > Indian Institute of Technology (Indian School of Mines), Dhanbad
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>


-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS on ARMv8

[Sebastian Huber]

Hello Jeff,

On 27/03/2019 19:11, Jeff Kubascik wrote:

Hello,

I am interested in porting RTEMS to run as a Xen guest on our distro for the
Xilinx Zynq UltraScale+ MPSoC. The MPSoC has an ARM Cortex-A53 processor, which
is based on the ARMv8 architecture.

I have noticed that RTEMS already runs on a few Zynq 7000 boards. However, those
are using the Cortex-A9 processor, which is based on the ARMv7 architecture.
Looking at the source code, I didn't see any ARMv8 cpu code.

I was curious if there has been any work done to port RTEMS to an ARMv8 based
platform?


AArch64 is a completely new architecture port. I think nobody is working 
on that. We may work on AArch32 support for the Zynq UltraScale+ this year:


http://devel.rtems.org/ticket/3682

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

Re: libbsd: Add openssl tool

[Sebastian Huber]

On 27/03/2019 20:40, Chris Johns wrote:

I'll commit the patches and backport them to the
5-freebsd-12 branch.

What is this branch? I could not find anything in the top level CONTRIBUTING.md
doc. Is it documented?


I added a "Branches" section to the README.md:

https://github.com/RTEMS/rtems-libbsd#branches

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

Re: libbsd: Add openssl tool

[Christian Mauderer]

Am 27.03.19 um 20:40 schrieb Chris Johns:
> On 27/3/19 9:11 pm, Christian Mauderer wrote:
>> Hello,
>>
>> I've added a port of the openssl tool together with a test for `openssl
>> speed` (benchmark) and `openssl req` (generating server certificates).
>>
>> Unfortunately the openssl tool is quite big so that I can't send the
>> patches to the mailing list. You can find them on a bin-openssl branch here:
>>
>>   https://git.rtems.org/christianm/rtems-libbsd.git/log/?h=bin-openssl
>>
>> The two patches are
>>
>>   Import:
>> https://git.rtems.org/christianm/rtems-libbsd.git/commit/?h=bin-openssl=0fecf49362778d77da97e19cf9cbb639c64e1735
>>
>>   Port:
>> https://git.rtems.org/christianm/rtems-libbsd.git/commit/?h=bin-openssl=d1dac7891cd3234c935ce7e4d742b6f87663a5e1
>>
>> If everything is OK,
> 
> Very nice and thank you. The change looks great.

Thanks. I committed them.

> 
> I see OpenSSL 3.0.0 and later has an Apache V2 license so I assume the code is
> covered by this license. I could not see a LICENSES file in the top of our
> source tree that lists the licenses. Should we have one with the licenses
> contained in the libbsd package?

FreeBSD has a number of LICENSE files scattered about the source tree.
How about a plain text importer where we can just pick up LICENSE files
and import them together with the code?

> 
>> I'll commit the patches and backport them to the
>> 5-freebsd-12 branch.
> 
> What is this branch? I could not find anything in the top level 
> CONTRIBUTING.md
> doc. Is it documented?

Sebastian will write something about that.

> 
> Chris
> 

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
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