Re: x86_64 port and BSP (GSoC 2018)

[Amaan Cheval]

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:
> >>> Thanks for checking the tool status!
> >>>
> >>> TLS support for the tool seems okay to me as well - I see the TLS
> > program header
> >>> and the "T" flag for the ".tbss" section header, as you'd expect in
the
> > ELF. I
> >>> haven't looked into the run-time support for TLS in RTEMS yet - is
there
> >>> something I need to dig into there?
> >>>
> >>> How do we determine if we need multilib support?
> >>>
> >
> >> GCC should be able to dump it configuration, try adding
> > `--print-multi-lib`.
> >
> > No multilibs were found for me, in that case. Output was ".;".
> > What determines whether we need it or not? Is it based on whether we
think
> > of x86_64 as a BSP for the i386 arch vs. it being its own, new arch +
BSP?
> > (Since multilib, the way I understand it, would allow us to compile for
> > 32-bit as well.)
> I would prefer less rather than more and we settle on just 64bit and
support
> that. We have 32bit with the PC BSP in the 4.11 release branch.

Amen.


> >
> > In that case, I believe we've settled on new arch + new BSP, right?
> >

> I think this is the best way to go. It will make it easier to remove the
32bit
> support when the time comes.

> >
>   I'd encourage you to flesh out
>  the plan for one of the "bonus" areas for this phase. That way, if
you
>  reach it, you will be prepared to undertake it without having to
think
>  too hard about the design aspects.
> >>>
> >>> I've added a few bullets about SMP support and it's SMP-specific APIC
> > related tasks.
> >
> >> This requires bringing code in from FreeBSD which includes Intel code
to
> > manage
> >> these tables.
> >
> > Good point. I've added what seem to be the relevant FreeBSD sources to
the
> > resources listed in the proposal:
> >
> > -
> >
https://github.com/freebsd/freebsd/blob/master/sys/x86/x86/local_apic.c#L498-L503
> > -
> >
https://github.com/freebsd/freebsd/blob/master/sys/amd64/amd64/apic_vector.S
> >

> Thanks.

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

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


> One area the current PC BSP is poor is extended interrupt support past the
> master and slave legacy PICs.

> >
> >
> >>>
>  FYI one step I do for new ports is to get to the point where I can
> > link all tests with stubs or first quick cuts at the port and bsp.
> >>>
> >>> That's a good tip! I've added that to the phase 1 deliverable, since
it
> > seems
> >>> like an important step - I'll aim to get here much sooner, though.
> >>>
>  I have always thought the first part of this project would be to get
>  an UEFI "hello world" running on Qemu. That is the entry point to the
>  BSP and as Chris pointed out, there is a fair amount of work just
>  to ensure you can do prints to the optional video and later serial
> > port.
> >>>
> >>> The UEFI "hello world" would be achievable through a minimal BSP
> > (primarily
> >>> boot/init code) and stubs for the rest (console, idle thread clock,
fake
> >>> context-switching & ISR handling), right?
> >
> >> In theory. We need to resolve the way we build the UEFI header as
listed
> > in the
> >> ticket for this task.
> >
>  All that should be doable and testable on qemu.
> >>>
> >>> Sweet! A question about hardware requirements; how do you guys usually
> > test and
> >>> debug hardware problems?
> >
> >> What is involved in booting on qemu with UEFI + 64bit?
> >
> > Besides needing OVMF for UEFI, I don't think there should be any issues
in
> > that regard. I'm also familiar enough with QEMU (since we use it a fair
bit
> > as an "oracle" to be compared to our x86 emulator at work), so I think
we
> > should be able to resolve this setup before the GSoC coding period
starts.

> Great.

> >
> >>> Is there any equipment I'll likely need or should look
> >>> into (JTAG)?
> >
> >> Not that I know of. Intel has a different JTAG like protocol on it's
Atom
> >> devices available under NDA some commercial debuggers support.
> >
> >> Qemu is nice because you get a

Re: [PATCH] Eliminate config.inc.

[Christian Mauderer]

Am 20.03.2018 um 02:14 schrieb Chris Johns:
> On 20/03/2018 02:16, Christian Mauderer wrote:
>> Most of the values in config.inc haven't been used any more. The only
>> part left has been the ip addresses for some of the test.
> 
> Why not just removed the parts not being used?
> 
>> All other values are not used and might irritate new users.
> 
> Why would it? It would irritate existing "users" if the hard coded set up
> conflicts with any networks they use.
> 
> I do not agree with a hard coded set of addresses and I cannot see a 
> compelling
> reason given in this patch to do this.
> 
> The way the setting of these is currently handled may end up being part of the
> #3351 resolution once that ticket's path is resolved.
> 
>>
>> Generating the header for the network configuration adds quite some
>> lines to the build system.
> 
> It is not that much, it exists and it works. The code being removed is about 
> 30
> lines while the generated waf script is over 3000 lines long.
> 
> How is this complicating the build system?

I think it is currently the only generated header file. Therefore it is
a special case and special cases are always hard to handle. But I'll
re-do the patch so that it only removes the parts that are not used or
never worked.

> 
>> On the other side it seems not really that
>> necessary to make the network configuration for the tests configurable.
> 
> Why?
> 
>> Therefore this patch elimintates that too and uses fixed IP addresses in
>> the (previously generated) network-config.h header instead. If someone
>> really needs to run the tests with some other IP addresses, he still can
>> locally change the header (instead of the config.inc).
> 
> Sorry, lets not go there. As a policy I would like to see RTEMS avoid touching
> code this way so tests can run. Saying this requires developers walk patches
> through repeated changes to the repo and that is an overhead for them, it
> complicates continuous integration set ups and it added complexity to an audit
> process wanting to run any certification effort.
> 
>> ---
>>  config.inc | 15 
>>  libbsd.txt | 30 +++
>>  libbsd_waf.py  | 36 -
>>  .../test/{network-config.h.in => network-config.h} |  8 ++--
>>  waf_generator.py   | 45 
>> --
>>  wscript|  5 ---
>>  6 files changed, 10 insertions(+), 129 deletions(-)
>>  delete mode 100644 config.inc
>>  rename testsuite/include/rtems/bsd/test/{network-config.h.in => 
>> network-config.h} (92%)
>>
>> diff --git a/config.inc b/config.inc
>> deleted file mode 100644
>> index 3432a5fc..
>> --- a/config.inc
>> +++ /dev/null
>> @@ -1,15 +0,0 @@
>> -# Mandatory: Select your BSP and installation prefix
>> -TARGET = arm-rtems4.11
>> -BSP = realview_pbx_a9_qemu
>> -PREFIX = /opt/rtems-4.11
>> -
>> -# Optional: Separate installation base directory
>> -INSTALL_BASE = $(PREFIX)/$(TARGET)/$(BSP)
>> -
>> -# Optional: Network test configuration
>> -TEST_RUNNER = $(BSP)
>> -NET_CFG_SELF_IP = 10.0.2.1
>> -NET_CFG_NETMASK = 255.255.0.0
>> -NET_CFG_PEER_IP = 192.168.100.11
>> -NET_CFG_GATEWAY_IP = 192.168.100.11
>> -NET_TAP_INTERFACE = tap0
>> diff --git a/libbsd.txt b/libbsd.txt
>> index 71d5cc8d..d57d1884 100644
>> --- a/libbsd.txt
>> +++ b/libbsd.txt
>> @@ -42,7 +42,6 @@ installed.
>>  
>>  . Clone the Git repository +git clone git://git.rtems.org/rtems-libbsd.git+.
>>  . Change into the RTEMS BSD library root directory.
>> -. Edit the `config.inc` configuration file and adjust it to your 
>> environment.
>>  . Run +waf configure ...+.
>>  . Run +waf+.
>>  . Run +waf install+.
>> @@ -119,29 +118,6 @@ devices (you can run multiple test instances on one 
>> virtual network).
>>  The build system based on the Waf build system. To build with Waf please 
>> refer
>>  to the README.waf file.
>>  
>> -= Example Configuration =
>> -
>> -In the BSD library source directory edit the file `config.inc`.  Continuing 
>> on
>> -the above, the `config.inc` used to match the above is:
>> -
>> 
>> -# Mandatory: Select your BSP and installation prefix
>> -TARGET = arm-rtems4.12
>> -BSP = xilinx_zynq_a9_qemu
>> -PREFIX = $(HOME)/sandbox/install
>> -
>> -# Optional: Separate installation base directory
>> -INSTALL_BASE = $(PREFIX)/$(TARGET)/$(BSP)
>> -
>> -# Optional: Network test configuration
>> -TEST_RUNNER = $(BSP)
>> -NET_CFG_SELF_IP = 10.0.0.2
>> -NET_CFG_NETMASK = 255.255.0.0
>> -NET_CFG_PEER_IP = 10.0.0.1
>> -NET_CFG_GATEWAY_IP = 10.0.0.1
>> -NET_TAP_INTERFACE = tap0
>> 
>> -
>>  === BSD Library Initialization ===
>>  
>>  To initialise the BSD Library create a suitable rc.conf file. The FreeBSD 
>> man
>> @@

Re: [PATCH v2] bsp/atsam: Fix GMAC Rx Descriptor fields.

[Christian Mauderer]

Hello Gedare,

is that patch better / acceptable from your point of view?

Best regards

Christian

Am 19.03.2018 um 08:58 schrieb Christian Mauderer:
> ---
>  bsps/arm/atsam/include/libchip/include/gmac.h | 17 +++--
>  1 file changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/bsps/arm/atsam/include/libchip/include/gmac.h 
> b/bsps/arm/atsam/include/libchip/include/gmac.h
> index 64e0079c25..418165eacf 100644
> --- a/bsps/arm/atsam/include/libchip/include/gmac.h
> +++ b/bsps/arm/atsam/include/libchip/include/gmac.h
> @@ -148,6 +148,13 @@ extern "C" {
>   (GMAC_ISR_RCOMP | GMAC_ISR_RXUBR | GMAC_ISR_ROVR)
>  #define GMAC_INT_TX_STATUS_ERR_BITS  \
>   (GMAC_ISR_TUR | GMAC_ISR_RLEX | GMAC_ISR_TFC | GMAC_ISR_HRESP)
> +
> +// Rx descriptor status flags
> +#define   GMAC_RXDESC_ST_CKSUM_RESULT_NOT_CHECKED(0)
> +#define   GMAC_RXDESC_ST_CKSUM_RESULT_IP_CHECKED (1)
> +#define   GMAC_RXDESC_ST_CKSUM_RESULT_IP_AND_TCP_CHECKED (2)
> +#define   GMAC_RXDESC_ST_CKSUM_RESULT_IP_AND_UDP_CHECKED (3)
> +
>  
> /*
>   *Types
>   
> **/
> @@ -186,13 +193,11 @@ typedef struct _GmacRxDescriptor {
>vlanPriority: 3,   /** VLAN 
> priority (if VLAN detected) */
>bPriorityDetected: 1,  /** Priority 
> tag detected */
>bVlanDetected: 1,  /**< VLAN tag 
> detected */
> -  bTypeIDMatch: 1,   /**< Type ID 
> match */
> -  bAddr4Match: 1,/**< Address 
> register 4 match */
> -  bAddr3Match: 1,/**< Address 
> register 3 match */
> -  bAddr2Match: 1,/**< Address 
> register 2 match */
> -  bAddr1Match: 1,/**< Address 
> register 1 match */
> +  typeIDMatchOrCksumResult: 2,
> +  bTypeIDMatchFoundOrCksumSNAPState: 1,
> +  specAddrMatchRegister: 2,
> +  bSpecAddrMatchFound: 1,
>reserved: 1,
> -  bExtAddrMatch: 1,  /**< External 
> address match */
>bUniHashMatch: 1,  /**< Unicast 
> hash match */
>bMultiHashMatch: 1,/**< Multicast 
> hash match */
>bBroadcastDetected: 1;  /**< Global 
> all ones broadcast
> 

-- 

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

Re: [PATCH] openssl: Provide deprecated functions.

[Christian Mauderer]

Am 19.03.2018 um 09:26 schrieb Christian Mauderer:
> Am 16.03.2018 um 15:11 schrieb Gedare Bloom:
>> On Tue, Mar 13, 2018 at 10:02 AM, Christian Mauderer
>>  wrote:
>>> Some applications (like the civetweb web server) still use functions
>>> that are deprecated by openssl. If OPENSSL_NO_DEPRECATED is defined,
>>> openssl will not provide these functions. This patch removes the define
>>> so that the functions are available.
>>> ---
>>
>> What are the negative consequences to this? I'm quite leery about
>> enabling deprecated features in a security library.
>>
>> What is the cost to fix civetweb instead?
>>
>> -Gedare
> 
> Hello Gedare,
> 
> there are still a lot of application that use the deprecated API. A
> quick search on github for one of the deprecated functions
> (ERR_remove_state) provided nearly 5 results:
> https://github.com/search?l=C&q=+ERR_remove_state&type=Code&utf8=%E2%9C%93
> 
> Beneath that I just checked on my OpenSUSE machine and on a FreeBSD VM:
> They still provide this function. So I wouldn't see a problem with that.
> 
> Best regards
> 
> Christian

Would you agree with the patch with the additional information from my
last mail that the deprecated API is still widely used?

> 
>>
>>>  libbsd.py | 3 +--
>>>  libbsd_waf.py | 2 +-
>>>  2 files changed, 2 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/libbsd.py b/libbsd.py
>>> index f70b4ead..233c06cd 100644
>>> --- a/libbsd.py
>>> +++ b/libbsd.py
>>> @@ -3614,8 +3614,7 @@ def crypto_openssl(mm):
>>>  'crypto/openssl/crypto/cversion.c',
>>>  'crypto/openssl/crypto/o_str.c',
>>>  ],
>>> -mm.generator['source'](['-DOPENSSL_NO_DEPRECATED=1',
>>> -'-DOPENSSL_NO_EC_NISTP_64_GCC_128=1',
>>> +mm.generator['source'](['-DOPENSSL_NO_EC_NISTP_64_GCC_128=1',
>>>  '-DOPENSSL_NO_GMP=1',
>>>  '-DOPENSSL_NO_JPAKE=1',
>>>  '-DOPENSSL_NO_LIBUNBOUND=1',
>>> diff --git a/libbsd_waf.py b/libbsd_waf.py
>>> index 7782bccb..745512bf 100644
>>> --- a/libbsd_waf.py
>>> +++ b/libbsd_waf.py
>>> @@ -1317,7 +1317,7 @@ def build(bld):
>>>  features = "c",
>>>  cflags = cflags,
>>>  includes = ['freebsd/crypto', 'freebsd/crypto/openssl', 
>>> 'freebsd/crypto/openssl/crypto', 'freebsd/crypto/openssl/crypto/asn1', 
>>> 'freebsd/crypto/openssl/crypto/evp', 'freebsd/crypto/openssl/crypto/modes'] 
>>> + includes,
>>> -defines = defines + ['NO_WINDOWS_BRAINDEATH=1', 
>>> 'OPENSSL_DISABLE_OLD_DES_SUPPORT=1', 'OPENSSL_NO_DEPRECATED=1', 
>>> 'OPENSSL_NO_EC_NISTP_64_GCC_128=1', 'OPENSSL_NO_GMP=1', 
>>> 'OPENSSL_NO_JPAKE=1', 'OPENSSL_NO_LIBUNBOUND=1', 'OPENSSL_NO_MD2=1', 
>>> 'OPENSSL_NO_RC5=1', 'OPENSSL_NO_RFC3779=1', 'OPENSSL_NO_SCTP=1', 
>>> 'OPENSSL_NO_SSL2=1', 'OPENSSL_NO_SSL_TRACE=1', 'OPENSSL_NO_STORE=1', 
>>> 'OPENSSL_NO_UNIT_TEST=1', 'OPENSSL_NO_WEAK_SSL_CIPHERS=1'],
>>> +defines = defines + ['NO_WINDOWS_BRAINDEATH=1', 
>>> 'OPENSSL_DISABLE_OLD_DES_SUPPORT=1', 'OPENSSL_NO_EC_NISTP_64_GCC_128=1', 
>>> 'OPENSSL_NO_GMP=1', 'OPENSSL_NO_JPAKE=1', 'OPENSSL_NO_LIBUNBOUND=1', 
>>> 'OPENSSL_NO_MD2=1', 'OPENSSL_NO_RC5=1', 'OPENSSL_NO_RFC3779=1', 
>>> 'OPENSSL_NO_SCTP=1', 'OPENSSL_NO_SSL2=1', 'OPENSSL_NO_SSL_TRACE=1', 
>>> 'OPENSSL_NO_STORE=1', 'OPENSSL_NO_UNIT_TEST=1', 
>>> 'OPENSSL_NO_WEAK_SSL_CIPHERS=1'],
>>>  source = objs04_source)
>>>  libbsd_use += ["objs04"]
>>>
>>> --
>>> 2.13.6
>>>
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
> 

-- 

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

Re: [PATCH] Eliminate config.inc.

[Sebastian Huber]

On 20/03/18 10:57, Christian Mauderer wrote:

+=== Tests ===
+
+There are tests for some features in the `testsuite` directory. Note that some
+of the tests use a fixed IP configuration that is defined in
+`testsuite/include/rtems/bsd/test/network-config.h`.

It is not clear to me in this documentation how a developer who has clashing
networks is suppose to handle these static settings and nothing here explains
what what to do.


What about changing all tests which require an external network to use DHCP?

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

[PATCH v2] config.inc: Remove unused values.

[Christian Mauderer]

---
 config.inc   | 11 ---
 libbsd.txt   | 20 +---
 libbsd_waf.py|  3 ---
 waf_generator.py |  3 ---
 4 files changed, 5 insertions(+), 32 deletions(-)

diff --git a/config.inc b/config.inc
index 3432a5fc..6727a3d3 100644
--- a/config.inc
+++ b/config.inc
@@ -1,15 +1,4 @@
-# Mandatory: Select your BSP and installation prefix
-TARGET = arm-rtems4.11
-BSP = realview_pbx_a9_qemu
-PREFIX = /opt/rtems-4.11
-
-# Optional: Separate installation base directory
-INSTALL_BASE = $(PREFIX)/$(TARGET)/$(BSP)
-
-# Optional: Network test configuration
-TEST_RUNNER = $(BSP)
 NET_CFG_SELF_IP = 10.0.2.1
 NET_CFG_NETMASK = 255.255.0.0
 NET_CFG_PEER_IP = 192.168.100.11
 NET_CFG_GATEWAY_IP = 192.168.100.11
-NET_TAP_INTERFACE = tap0
diff --git a/libbsd.txt b/libbsd.txt
index 71d5cc8d..b0b59504 100644
--- a/libbsd.txt
+++ b/libbsd.txt
@@ -42,7 +42,8 @@ installed.
 
 . Clone the Git repository +git clone git://git.rtems.org/rtems-libbsd.git+.
 . Change into the RTEMS BSD library root directory.
-. Edit the `config.inc` configuration file and adjust it to your environment.
+. If you want to run tests with a custom IP configuration instead of the 
default
+  one you can adjust the `config.inc` configuration file.
 . Run +waf configure ...+.
 . Run +waf+.
 . Run +waf install+.
@@ -119,27 +120,16 @@ devices (you can run multiple test instances on one 
virtual network).
 The build system based on the Waf build system. To build with Waf please refer
 to the README.waf file.
 
-= Example Configuration =
+= Example Configuration for Network Tests =
 
-In the BSD library source directory edit the file `config.inc`.  Continuing on
-the above, the `config.inc` used to match the above is:
+If you need some other IP configuration for some of the network tests you can
+edit the file `config.inc`:
 
 ---
-# Mandatory: Select your BSP and installation prefix
-TARGET = arm-rtems4.12
-BSP = xilinx_zynq_a9_qemu
-PREFIX = $(HOME)/sandbox/install
-
-# Optional: Separate installation base directory
-INSTALL_BASE = $(PREFIX)/$(TARGET)/$(BSP)
-
-# Optional: Network test configuration
-TEST_RUNNER = $(BSP)
 NET_CFG_SELF_IP = 10.0.0.2
 NET_CFG_NETMASK = 255.255.0.0
 NET_CFG_PEER_IP = 10.0.0.1
 NET_CFG_GATEWAY_IP = 10.0.0.1
-NET_TAP_INTERFACE = tap0
 ---
 
 === BSD Library Initialization ===
diff --git a/libbsd_waf.py b/libbsd_waf.py
index 745512bf..65f5ae0f 100644
--- a/libbsd_waf.py
+++ b/libbsd_waf.py
@@ -98,7 +98,6 @@ def build(bld):
 net_cfg_netmask = None
 net_cfg_peer_ip = None
 net_cfg_gateway_ip = None
-net_tap_interface = None
 try:
 net_cfg_lines = open(bld.env.NET_CONFIG).readlines()
 except:
@@ -120,8 +119,6 @@ def build(bld):
 net_cfg_peer_ip = rhs
 if lhs == "NET_CFG_GATEWAY_IP":
 net_cfg_gateway_ip = rhs
-if lhs == "NET_TAP_INTERFACE":
-net_tap_interface = rhs
 bld(target = "testsuite/include/rtems/bsd/test/network-config.h",
 source = "testsuite/include/rtems/bsd/test/network-config.h.in",
 rule = "sed -e 's/@NET_CFG_SELF_IP@/%s/' -e 's/@NET_CFG_NETMASK@/%s/' 
-e 's/@NET_CFG_PEER_IP@/%s/' -e 's/@NET_CFG_GATEWAY_IP@/%s/' < ${SRC} > ${TGT}" 
% (net_cfg_self_ip, net_cfg_netmask, net_cfg_peer_ip, net_cfg_gateway_ip),
diff --git a/waf_generator.py b/waf_generator.py
index 73b02a83..70b0c307 100755
--- a/waf_generator.py
+++ b/waf_generator.py
@@ -416,7 +416,6 @@ class ModuleManager(builder.ModuleManager):
 self.add('net_cfg_netmask = None')
 self.add('net_cfg_peer_ip = None')
 self.add('net_cfg_gateway_ip = None')
-self.add('net_tap_interface = None')
 self.add('try:')
 self.add('net_cfg_lines = 
open(bld.env.NET_CONFIG).readlines()')
 self.add('except:')
@@ -439,8 +438,6 @@ class ModuleManager(builder.ModuleManager):
 self.add('net_cfg_peer_ip = rhs')
 self.add('if lhs == "NET_CFG_GATEWAY_IP":')
 self.add('net_cfg_gateway_ip = rhs')
-self.add('if lhs == "NET_TAP_INTERFACE":')
-self.add('net_tap_interface = rhs')
 self.add('bld(target = 
"testsuite/include/rtems/bsd/test/network-config.h",')
 self.add('source = 
"testsuite/include/rtems/bsd/test/network-config.h.in",')
 self.add('rule = "sed -e \'s/@NET_CFG_SELF_IP@/%s/\' ' + \
-- 
2.13.6

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

[PATCH] MAINAINERS: Add rule for BSP-specific patches

[Sebastian Huber]

---
 MAINTAINERS | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 2d91ecb149..ee991c6e95 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -20,12 +20,13 @@ who can be trusted to distinguish between changes which 
require
 others to review, require a problem report, or can be safely committed
 with limited review.
 
-Write After Approval is granted to experienced but also trusted 
+Write After Approval is granted to experienced but also trusted
 RTEMS developers.  These developers may be less familiar with
 the breadth of RTEMS.  Developers with write after approval need
-to submit their patches for review. Once the patches have been
-approved by a developer with Blanket Write Privileges, the patches
-may be checked in.  
+to submit their patches for review.  Once the patches have been approved by a
+developer with Blanket Write Privileges, the patches may be checked in.
+A BSP-specific patch may be checked in three work days after sending it to
+devel@rtems.org in case nobody explictly rejected the patch.
 
 Localized Write Permission is for developers who have primary
 responsibility for a port and all associated BSPs, a BSP, or other
-- 
2.12.3

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

[PATCH v2] MAINAINERS: Add rule for BSP-specific patches

[Sebastian Huber]

---
 MAINTAINERS | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 2d91ecb149..2732d773c4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -20,12 +20,13 @@ who can be trusted to distinguish between changes which 
require
 others to review, require a problem report, or can be safely committed
 with limited review.
 
-Write After Approval is granted to experienced but also trusted 
+Write After Approval is granted to experienced but also trusted
 RTEMS developers.  These developers may be less familiar with
 the breadth of RTEMS.  Developers with write after approval need
-to submit their patches for review. Once the patches have been
-approved by a developer with Blanket Write Privileges, the patches
-may be checked in.  
+to submit their patches for review.  Once the patches have been approved by a
+developer with Blanket Write Privileges, the patches may be checked in.
+A BSP-specific patch may be checked in three work days after sending it to
+devel@rtems.org in case nobody explicitly rejected the patch.
 
 Localized Write Permission is for developers who have primary
 responsibility for a port and all associated BSPs, a BSP, or other
-- 
2.12.3

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

Re: [PATCH] MAINAINERS: Add rule for BSP-specific patches

[Sebastian Huber]

On 20/03/18 13:43, Sebastian Huber wrote:

+devel@rtems.org in case nobody explictly rejected the patch.


Sorry for the typo.

--
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: [PATCH] MAINAINERS: Add rule for BSP-specific patches

[Gedare Bloom]

Thanks, looks good.

On Tue, Mar 20, 2018 at 8:54 AM, Sebastian Huber
 wrote:
> On 20/03/18 13:43, Sebastian Huber wrote:
>>
>> +devel@rtems.org in case nobody explictly rejected the patch.
>
>
> Sorry for the typo.
>
> --
> 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

Re: [PATCH] openssl: Provide deprecated functions.

[Gedare Bloom]

On Tue, Mar 20, 2018 at 6:03 AM, Christian Mauderer
 wrote:
>
> Am 19.03.2018 um 09:26 schrieb Christian Mauderer:
>> Am 16.03.2018 um 15:11 schrieb Gedare Bloom:
>>> On Tue, Mar 13, 2018 at 10:02 AM, Christian Mauderer
>>>  wrote:
 Some applications (like the civetweb web server) still use functions
 that are deprecated by openssl. If OPENSSL_NO_DEPRECATED is defined,
 openssl will not provide these functions. This patch removes the define
 so that the functions are available.
 ---
>>>
>>> What are the negative consequences to this? I'm quite leery about
>>> enabling deprecated features in a security library.
>>>
>>> What is the cost to fix civetweb instead?
>>>
>>> -Gedare
>>
>> Hello Gedare,
>>
>> there are still a lot of application that use the deprecated API. A
>> quick search on github for one of the deprecated functions
>> (ERR_remove_state) provided nearly 5 results:
>> https://github.com/search?l=C&q=+ERR_remove_state&type=Code&utf8=%E2%9C%93
>>
>> Beneath that I just checked on my OpenSUSE machine and on a FreeBSD VM:
>> They still provide this function. So I wouldn't see a problem with that.
>>
>> Best regards
>>
>> Christian
>
> Would you agree with the patch with the additional information from my
> last mail that the deprecated API is still widely used?
>

OK.

>>
>>>
  libbsd.py | 3 +--
  libbsd_waf.py | 2 +-
  2 files changed, 2 insertions(+), 3 deletions(-)

 diff --git a/libbsd.py b/libbsd.py
 index f70b4ead..233c06cd 100644
 --- a/libbsd.py
 +++ b/libbsd.py
 @@ -3614,8 +3614,7 @@ def crypto_openssl(mm):
  'crypto/openssl/crypto/cversion.c',
  'crypto/openssl/crypto/o_str.c',
  ],
 -mm.generator['source'](['-DOPENSSL_NO_DEPRECATED=1',
 -'-DOPENSSL_NO_EC_NISTP_64_GCC_128=1',
 +mm.generator['source'](['-DOPENSSL_NO_EC_NISTP_64_GCC_128=1',
  '-DOPENSSL_NO_GMP=1',
  '-DOPENSSL_NO_JPAKE=1',
  '-DOPENSSL_NO_LIBUNBOUND=1',
 diff --git a/libbsd_waf.py b/libbsd_waf.py
 index 7782bccb..745512bf 100644
 --- a/libbsd_waf.py
 +++ b/libbsd_waf.py
 @@ -1317,7 +1317,7 @@ def build(bld):
  features = "c",
  cflags = cflags,
  includes = ['freebsd/crypto', 'freebsd/crypto/openssl', 
 'freebsd/crypto/openssl/crypto', 'freebsd/crypto/openssl/crypto/asn1', 
 'freebsd/crypto/openssl/crypto/evp', 
 'freebsd/crypto/openssl/crypto/modes'] + includes,
 -defines = defines + ['NO_WINDOWS_BRAINDEATH=1', 
 'OPENSSL_DISABLE_OLD_DES_SUPPORT=1', 'OPENSSL_NO_DEPRECATED=1', 
 'OPENSSL_NO_EC_NISTP_64_GCC_128=1', 'OPENSSL_NO_GMP=1', 
 'OPENSSL_NO_JPAKE=1', 'OPENSSL_NO_LIBUNBOUND=1', 'OPENSSL_NO_MD2=1', 
 'OPENSSL_NO_RC5=1', 'OPENSSL_NO_RFC3779=1', 'OPENSSL_NO_SCTP=1', 
 'OPENSSL_NO_SSL2=1', 'OPENSSL_NO_SSL_TRACE=1', 'OPENSSL_NO_STORE=1', 
 'OPENSSL_NO_UNIT_TEST=1', 'OPENSSL_NO_WEAK_SSL_CIPHERS=1'],
 +defines = defines + ['NO_WINDOWS_BRAINDEATH=1', 
 'OPENSSL_DISABLE_OLD_DES_SUPPORT=1', 'OPENSSL_NO_EC_NISTP_64_GCC_128=1', 
 'OPENSSL_NO_GMP=1', 'OPENSSL_NO_JPAKE=1', 'OPENSSL_NO_LIBUNBOUND=1', 
 'OPENSSL_NO_MD2=1', 'OPENSSL_NO_RC5=1', 'OPENSSL_NO_RFC3779=1', 
 'OPENSSL_NO_SCTP=1', 'OPENSSL_NO_SSL2=1', 'OPENSSL_NO_SSL_TRACE=1', 
 'OPENSSL_NO_STORE=1', 'OPENSSL_NO_UNIT_TEST=1', 
 'OPENSSL_NO_WEAK_SSL_CIPHERS=1'],
  source = objs04_source)
  libbsd_use += ["objs04"]

 --
 2.13.6

 ___
 devel mailing list
 devel@rtems.org
 http://lists.rtems.org/mailman/listinfo/devel
>>
>
> --
> 
> 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

GSoC Proposals to Review

[Joel Sherrill]

Hi

If any students have proposals to review, please share the links with
myself and other mentors.

Thanks.

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

Re: [PATCH v2] bsp/atsam: Fix GMAC Rx Descriptor fields.

[Gedare Bloom]

On Tue, Mar 20, 2018 at 6:01 AM, Christian Mauderer
 wrote:
> Hello Gedare,
>
> is that patch better / acceptable from your point of view?
>
Yes, thank you.

> Best regards
>
> Christian
>
> Am 19.03.2018 um 08:58 schrieb Christian Mauderer:
>> ---
>>  bsps/arm/atsam/include/libchip/include/gmac.h | 17 +++--
>>  1 file changed, 11 insertions(+), 6 deletions(-)
>>
>> diff --git a/bsps/arm/atsam/include/libchip/include/gmac.h 
>> b/bsps/arm/atsam/include/libchip/include/gmac.h
>> index 64e0079c25..418165eacf 100644
>> --- a/bsps/arm/atsam/include/libchip/include/gmac.h
>> +++ b/bsps/arm/atsam/include/libchip/include/gmac.h
>> @@ -148,6 +148,13 @@ extern "C" {
>>   (GMAC_ISR_RCOMP | GMAC_ISR_RXUBR | GMAC_ISR_ROVR)
>>  #define GMAC_INT_TX_STATUS_ERR_BITS  \
>>   (GMAC_ISR_TUR | GMAC_ISR_RLEX | GMAC_ISR_TFC | GMAC_ISR_HRESP)
>> +
>> +// Rx descriptor status flags
>> +#define   GMAC_RXDESC_ST_CKSUM_RESULT_NOT_CHECKED(0)
>> +#define   GMAC_RXDESC_ST_CKSUM_RESULT_IP_CHECKED (1)
>> +#define   GMAC_RXDESC_ST_CKSUM_RESULT_IP_AND_TCP_CHECKED (2)
>> +#define   GMAC_RXDESC_ST_CKSUM_RESULT_IP_AND_UDP_CHECKED (3)
>> +
>>  
>> /*
>>   *Types
>>   
>> **/
>> @@ -186,13 +193,11 @@ typedef struct _GmacRxDescriptor {
>>vlanPriority: 3,   /** VLAN 
>> priority (if VLAN detected) */
>>bPriorityDetected: 1,  /** Priority 
>> tag detected */
>>bVlanDetected: 1,  /**< VLAN tag 
>> detected */
>> -  bTypeIDMatch: 1,   /**< Type ID 
>> match */
>> -  bAddr4Match: 1,/**< Address 
>> register 4 match */
>> -  bAddr3Match: 1,/**< Address 
>> register 3 match */
>> -  bAddr2Match: 1,/**< Address 
>> register 2 match */
>> -  bAddr1Match: 1,/**< Address 
>> register 1 match */
>> +  typeIDMatchOrCksumResult: 2,
>> +  bTypeIDMatchFoundOrCksumSNAPState: 1,
>> +  specAddrMatchRegister: 2,
>> +  bSpecAddrMatchFound: 1,
>>reserved: 1,
>> -  bExtAddrMatch: 1,  /**< External 
>> address match */
>>bUniHashMatch: 1,  /**< Unicast 
>> hash match */
>>bMultiHashMatch: 1,/**< Multicast 
>> hash match */
>>bBroadcastDetected: 1;  /**< Global 
>> all ones broadcast
>>
>
> --
> 
> 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

Re: GSoC'18 proposal - Porting SDIO driver and benchmarking

[Udit agarwal]

Hi,

On Sun, Mar 18, 2018 at 8:48 PM, Christian Mauderer 
wrote:

> Am 18.03.2018 um 14:22 schrieb Udit agarwal:
> > Hi all,
> > Here's the link to my proposal:
> > https://docs.google.com/document/d/15Ut9FLAV3Y0Up1Qn02ys6KAb2QhtR
> eF_P-wNR861NMo/edit?usp=sharing
> >
> > Please have a look, and comment where ever needed.
> > I tried my best to make time-line as realistic as possible. Please feel
> > free to comment in case of any unbalance or overlooked task.
> >
> > Regards,
> > Udit agarwal
> >
> >
>
> Hello Udit,
>
> some (not too well sorted) notes:
>
> 1. One point I'm missing is the target that you produce a set of patches
> that can be easily merged as soon as the libbsd receives it's next
> update. Otherwise the only result from that project would be the
> comparison document.
>
> That's a really good idea! I have now included that in my proposal, please
have a look.

>
> 2. I'm not sure whether the point
>
>   "Backport the SDIO driver residing within the mmccam stack to FreeBSD
> version being used by libbsd"
>
> is a good idea. It sounds like you want to do the backport on FreeBSD.
> You most likely would have a lot of work with that without any really
> useful results. It would be better to analyse whether some other
> subsystems might have an influence on the performance measurement (which
> I would expect to be quite few) and then do the backport directly on
> RTEMS libbsd.
>
> Noted. I have corrected this. Moreover, i am studying several files

changed/modified during
the mmccam commit and as of now, i didn't  came across any such Non-RTEMS
dependency
that might affect systems performance. I have a query here, in RTEMS-libbsd
 cam
directory, there are some files
like cam.h and cam_ccb.h belonging to different FreeBSD head versions. Is
it because, since there has been no change in the file, so its not updated?

>
> 3. It seems that you have split up the test bench over all three phases.
> It might would be more efficient to search a test bench and get it
> running on FreeBSD as well as on RTEMS quite early. There should be no
> difference whether it runs on the old SD-card driver, the SDIO one or
> some USB stick. It should basically work with with any block device.
>
> If you start to port it to RTEMS in phase 3 and then find out that it
> doesn't work like expected, you will have to restart with searching some
> other test bench. This would mean that you can throw away all results of
> the workbench that you collected in between.
>
> I have corrected this. So, now the first phase, I'll be porting SDIO
driver, and in the second and third phase, I'll focus on the benchmarking
task. Hopefully, now we have ample time to fallback and search for another
benchmarks in case the first one didn't work expectedly.

>
> 4. I'm not quite sure whether the amount of work would really fill all
> three phases. Maybe you should plan an extended goal. With that topic
> that could for example be a benchmark for some other drivers (like USB
> storage).
>
> Done.

>
> 5. Currently your results are a document and a set of patches that
> (hopefully) can be integrated into libbsd in the future. I think that if
> you find some good standard performance test for block devices, porting
> that could be another core result that can be integrated directly and
> not only after a libbsd upgrade.
>
> I came across several popular, multipurpose I/O benchmarks like IOZone and
IOrate with compatible license(1
,2
). Since, these are FreeBSD
compatible probably they will work. Still, I have added 'Searching and
testing benchmarks on FreeBSD' as one of my goal.

> With kind regards
>
> Christian Mauderer
>

Regards,
Udit agarwal
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC'18 proposal - Porting SDIO driver and benchmarking

[Gedare Bloom]

I have a question about the high-level goal of this project. Is it to
produce a back-ported version of the stack to our current libbsd, or
is to prepare the changes necessary to apply to libbsd when it gets
updated to a newer FreeBSD containing the sdio stack, or both?

On Tue, Mar 20, 2018 at 11:41 AM, Udit agarwal  wrote:
> Hi,
>
> On Sun, Mar 18, 2018 at 8:48 PM, Christian Mauderer 
> wrote:
>>
>> Am 18.03.2018 um 14:22 schrieb Udit agarwal:
>> > Hi all,
>> > Here's the link to my proposal:
>> >
>> > https://docs.google.com/document/d/15Ut9FLAV3Y0Up1Qn02ys6KAb2QhtReF_P-wNR861NMo/edit?usp=sharing
>> >
>> > Please have a look, and comment where ever needed.
>> > I tried my best to make time-line as realistic as possible. Please feel
>> > free to comment in case of any unbalance or overlooked task.
>> >
>> > Regards,
>> > Udit agarwal
>> >
>> >
>>
>> Hello Udit,
>>
>> some (not too well sorted) notes:
>>
>> 1. One point I'm missing is the target that you produce a set of patches
>> that can be easily merged as soon as the libbsd receives it's next
>> update. Otherwise the only result from that project would be the
>> comparison document.
>>
> That's a really good idea! I have now included that in my proposal, please
> have a look.
>>
>>
>> 2. I'm not sure whether the point
>>
>>   "Backport the SDIO driver residing within the mmccam stack to FreeBSD
>> version being used by libbsd"
>>
>> is a good idea. It sounds like you want to do the backport on FreeBSD.
>> You most likely would have a lot of work with that without any really
>> useful results. It would be better to analyse whether some other
>> subsystems might have an influence on the performance measurement (which
>> I would expect to be quite few) and then do the backport directly on
>> RTEMS libbsd.
>>
> Noted. I have corrected this. Moreover, i am studying several files
> changed/modified during
> the mmccam commit and as of now, i didn't  came across any such Non-RTEMS
> dependency
> that might affect systems performance. I have a query here, in RTEMS-libbsd
> cam directory, there are some files
> like cam.h and cam_ccb.h belonging to different FreeBSD head versions. Is it
> because, since there has been no change in the file, so its not updated?
>>
>>
>> 3. It seems that you have split up the test bench over all three phases.
>> It might would be more efficient to search a test bench and get it
>> running on FreeBSD as well as on RTEMS quite early. There should be no
>> difference whether it runs on the old SD-card driver, the SDIO one or
>> some USB stick. It should basically work with with any block device.
>>
>> If you start to port it to RTEMS in phase 3 and then find out that it
>> doesn't work like expected, you will have to restart with searching some
>> other test bench. This would mean that you can throw away all results of
>> the workbench that you collected in between.
>>
> I have corrected this. So, now the first phase, I'll be porting SDIO driver,
> and in the second and third phase, I'll focus on the benchmarking task.
> Hopefully, now we have ample time to fallback and search for another
> benchmarks in case the first one didn't work expectedly.
>>
>>
>> 4. I'm not quite sure whether the amount of work would really fill all
>> three phases. Maybe you should plan an extended goal. With that topic
>> that could for example be a benchmark for some other drivers (like USB
>> storage).
>>
> Done.
>>
>>
>> 5. Currently your results are a document and a set of patches that
>> (hopefully) can be integrated into libbsd in the future. I think that if
>> you find some good standard performance test for block devices, porting
>> that could be another core result that can be integrated directly and
>> not only after a libbsd upgrade.
>>
> I came across several popular, multipurpose I/O benchmarks like IOZone and
> IOrate with compatible license(1,2). Since, these are FreeBSD compatible
> probably they will work. Still, I have added 'Searching and testing
> benchmarks on FreeBSD' as one of my goal.
>>
>> With kind regards
>>
>> Christian Mauderer
>
>
> Regards,
> Udit agarwal
>
> ___
> 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: GSoC'18 proposal - Porting SDIO driver and benchmarking

[Udit agarwal]

Hi,
We can't really merge the back-ported code with the current libbsd version
to avoid version inconsistency.
Thus, i am proposing to prepare all the necessary changes(patches), which
can be applied once the libbsd receives it's next update.


On Tue, Mar 20, 2018 at 9:14 PM, Gedare Bloom  wrote:

> I have a question about the high-level goal of this project. Is it to
> produce a back-ported version of the stack to our current libbsd, or
> is to prepare the changes necessary to apply to libbsd when it gets
> updated to a newer FreeBSD containing the sdio stack, or both?
>
> On Tue, Mar 20, 2018 at 11:41 AM, Udit agarwal 
> wrote:
> > Hi,
> >
> > On Sun, Mar 18, 2018 at 8:48 PM, Christian Mauderer 
> > wrote:
> >>
> >> Am 18.03.2018 um 14:22 schrieb Udit agarwal:
> >> > Hi all,
> >> > Here's the link to my proposal:
> >> >
> >> > https://docs.google.com/document/d/15Ut9FLAV3Y0Up1Qn02ys6KAb2QhtR
> eF_P-wNR861NMo/edit?usp=sharing
> >> >
> >> > Please have a look, and comment where ever needed.
> >> > I tried my best to make time-line as realistic as possible. Please
> feel
> >> > free to comment in case of any unbalance or overlooked task.
> >> >
> >> > Regards,
> >> > Udit agarwal
> >> >
> >> >
> >>
> >> Hello Udit,
> >>
> >> some (not too well sorted) notes:
> >>
> >> 1. One point I'm missing is the target that you produce a set of patches
> >> that can be easily merged as soon as the libbsd receives it's next
> >> update. Otherwise the only result from that project would be the
> >> comparison document.
> >>
> > That's a really good idea! I have now included that in my proposal,
> please
> > have a look.
> >>
> >>
> >> 2. I'm not sure whether the point
> >>
> >>   "Backport the SDIO driver residing within the mmccam stack to FreeBSD
> >> version being used by libbsd"
> >>
> >> is a good idea. It sounds like you want to do the backport on FreeBSD.
> >> You most likely would have a lot of work with that without any really
> >> useful results. It would be better to analyse whether some other
> >> subsystems might have an influence on the performance measurement (which
> >> I would expect to be quite few) and then do the backport directly on
> >> RTEMS libbsd.
> >>
> > Noted. I have corrected this. Moreover, i am studying several files
> > changed/modified during
> > the mmccam commit and as of now, i didn't  came across any such Non-RTEMS
> > dependency
> > that might affect systems performance. I have a query here, in
> RTEMS-libbsd
> > cam directory, there are some files
> > like cam.h and cam_ccb.h belonging to different FreeBSD head versions.
> Is it
> > because, since there has been no change in the file, so its not updated?
> >>
> >>
> >> 3. It seems that you have split up the test bench over all three phases.
> >> It might would be more efficient to search a test bench and get it
> >> running on FreeBSD as well as on RTEMS quite early. There should be no
> >> difference whether it runs on the old SD-card driver, the SDIO one or
> >> some USB stick. It should basically work with with any block device.
> >>
> >> If you start to port it to RTEMS in phase 3 and then find out that it
> >> doesn't work like expected, you will have to restart with searching some
> >> other test bench. This would mean that you can throw away all results of
> >> the workbench that you collected in between.
> >>
> > I have corrected this. So, now the first phase, I'll be porting SDIO
> driver,
> > and in the second and third phase, I'll focus on the benchmarking task.
> > Hopefully, now we have ample time to fallback and search for another
> > benchmarks in case the first one didn't work expectedly.
> >>
> >>
> >> 4. I'm not quite sure whether the amount of work would really fill all
> >> three phases. Maybe you should plan an extended goal. With that topic
> >> that could for example be a benchmark for some other drivers (like USB
> >> storage).
> >>
> > Done.
> >>
> >>
> >> 5. Currently your results are a document and a set of patches that
> >> (hopefully) can be integrated into libbsd in the future. I think that if
> >> you find some good standard performance test for block devices, porting
> >> that could be another core result that can be integrated directly and
> >> not only after a libbsd upgrade.
> >>
> > I came across several popular, multipurpose I/O benchmarks like IOZone
> and
> > IOrate with compatible license(1,2). Since, these are FreeBSD compatible
> > probably they will work. Still, I have added 'Searching and testing
> > benchmarks on FreeBSD' as one of my goal.
> >>
> >> With kind regards
> >>
> >> Christian Mauderer
> >
> >
> > Regards,
> > Udit agarwal
> >
> > ___
> > 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: GSoC'18 proposal - Porting SDIO driver and benchmarking

[Gedare Bloom]

On Tue, Mar 20, 2018 at 11:56 AM, Udit agarwal  wrote:
> Hi,
> We can't really merge the back-ported code with the current libbsd version
> to avoid version inconsistency.
> Thus, i am proposing to prepare all the necessary changes(patches), which
> can be applied once the libbsd receives it's next update.
>

Ah, OK. Thank you for clarifying this. Please make this be quite clear
in your proposal.

>
> On Tue, Mar 20, 2018 at 9:14 PM, Gedare Bloom  wrote:
>>
>> I have a question about the high-level goal of this project. Is it to
>> produce a back-ported version of the stack to our current libbsd, or
>> is to prepare the changes necessary to apply to libbsd when it gets
>> updated to a newer FreeBSD containing the sdio stack, or both?
>>
>> On Tue, Mar 20, 2018 at 11:41 AM, Udit agarwal 
>> wrote:
>> > Hi,
>> >
>> > On Sun, Mar 18, 2018 at 8:48 PM, Christian Mauderer 
>> > wrote:
>> >>
>> >> Am 18.03.2018 um 14:22 schrieb Udit agarwal:
>> >> > Hi all,
>> >> > Here's the link to my proposal:
>> >> >
>> >> >
>> >> > https://docs.google.com/document/d/15Ut9FLAV3Y0Up1Qn02ys6KAb2QhtReF_P-wNR861NMo/edit?usp=sharing
>> >> >
>> >> > Please have a look, and comment where ever needed.
>> >> > I tried my best to make time-line as realistic as possible. Please
>> >> > feel
>> >> > free to comment in case of any unbalance or overlooked task.
>> >> >
>> >> > Regards,
>> >> > Udit agarwal
>> >> >
>> >> >
>> >>
>> >> Hello Udit,
>> >>
>> >> some (not too well sorted) notes:
>> >>
>> >> 1. One point I'm missing is the target that you produce a set of
>> >> patches
>> >> that can be easily merged as soon as the libbsd receives it's next
>> >> update. Otherwise the only result from that project would be the
>> >> comparison document.
>> >>
>> > That's a really good idea! I have now included that in my proposal,
>> > please
>> > have a look.
>> >>
>> >>
>> >> 2. I'm not sure whether the point
>> >>
>> >>   "Backport the SDIO driver residing within the mmccam stack to FreeBSD
>> >> version being used by libbsd"
>> >>
>> >> is a good idea. It sounds like you want to do the backport on FreeBSD.
>> >> You most likely would have a lot of work with that without any really
>> >> useful results. It would be better to analyse whether some other
>> >> subsystems might have an influence on the performance measurement
>> >> (which
>> >> I would expect to be quite few) and then do the backport directly on
>> >> RTEMS libbsd.
>> >>
>> > Noted. I have corrected this. Moreover, i am studying several files
>> > changed/modified during
>> > the mmccam commit and as of now, i didn't  came across any such
>> > Non-RTEMS
>> > dependency
>> > that might affect systems performance. I have a query here, in
>> > RTEMS-libbsd
>> > cam directory, there are some files
>> > like cam.h and cam_ccb.h belonging to different FreeBSD head versions.
>> > Is it
>> > because, since there has been no change in the file, so its not updated?
>> >>
>> >>
>> >> 3. It seems that you have split up the test bench over all three
>> >> phases.
>> >> It might would be more efficient to search a test bench and get it
>> >> running on FreeBSD as well as on RTEMS quite early. There should be no
>> >> difference whether it runs on the old SD-card driver, the SDIO one or
>> >> some USB stick. It should basically work with with any block device.
>> >>
>> >> If you start to port it to RTEMS in phase 3 and then find out that it
>> >> doesn't work like expected, you will have to restart with searching
>> >> some
>> >> other test bench. This would mean that you can throw away all results
>> >> of
>> >> the workbench that you collected in between.
>> >>
>> > I have corrected this. So, now the first phase, I'll be porting SDIO
>> > driver,
>> > and in the second and third phase, I'll focus on the benchmarking task.
>> > Hopefully, now we have ample time to fallback and search for another
>> > benchmarks in case the first one didn't work expectedly.
>> >>
>> >>
>> >> 4. I'm not quite sure whether the amount of work would really fill all
>> >> three phases. Maybe you should plan an extended goal. With that topic
>> >> that could for example be a benchmark for some other drivers (like USB
>> >> storage).
>> >>
>> > Done.
>> >>
>> >>
>> >> 5. Currently your results are a document and a set of patches that
>> >> (hopefully) can be integrated into libbsd in the future. I think that
>> >> if
>> >> you find some good standard performance test for block devices, porting
>> >> that could be another core result that can be integrated directly and
>> >> not only after a libbsd upgrade.
>> >>
>> > I came across several popular, multipurpose I/O benchmarks like IOZone
>> > and
>> > IOrate with compatible license(1,2). Since, these are FreeBSD compatible
>> > probably they will work. Still, I have added 'Searching and testing
>> > benchmarks on FreeBSD' as one of my goal.
>> >>
>> >> With kind regards
>> >>
>> >> Christian Mauderer
>> >
>> >
>> > Regards,
>> > Udit agarwal
>> >
>> > _

[PATCH] 4.11: fix hosts defaults loading for linux systems.

[Gedare Bloom]

---
 rtemstoolkit/linux.py   | 2 +-
 rtemstoolkit/options.py | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/rtemstoolkit/linux.py b/rtemstoolkit/linux.py
index d011f67..15c6132 100644
--- a/rtemstoolkit/linux.py
+++ b/rtemstoolkit/linux.py
@@ -138,7 +138,7 @@ def load():
  '__chown':('exe', 'required', 
'/usr/sbin/chown') },
 }
 
-if variations in distro:
+if distro in variations:
 for v in variations[distro]:
 if path.exists(variations[distro][v][2]):
 defines[v] = variations[distro][v]
diff --git a/rtemstoolkit/options.py b/rtemstoolkit/options.py
index d0e4c81..f156641 100644
--- a/rtemstoolkit/options.py
+++ b/rtemstoolkit/options.py
@@ -581,6 +581,7 @@ def load(opts):
 from . import linux
 except:
 import linux
+overrides = linux.load()
 elif uname[0] == 'SunOS':
 try:
 from . import solaris
-- 
2.7.4

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

Re: [PATCH v2] config.inc: Remove unused values.

[Chris Johns]

On 20/3/18 9:21 pm, Christian Mauderer wrote:
> ---
>  config.inc   | 11 ---
>  libbsd.txt   | 20 +---
>  libbsd_waf.py|  3 ---
>  waf_generator.py |  3 ---
>  4 files changed, 5 insertions(+), 32 deletions(-)
> 
> diff --git a/config.inc b/config.inc
> index 3432a5fc..6727a3d3 100644
> --- a/config.inc
> +++ b/config.inc
> @@ -1,15 +1,4 @@
> -# Mandatory: Select your BSP and installation prefix
> -TARGET = arm-rtems4.11
> -BSP = realview_pbx_a9_qemu
> -PREFIX = /opt/rtems-4.11
> -
> -# Optional: Separate installation base directory
> -INSTALL_BASE = $(PREFIX)/$(TARGET)/$(BSP)
> -
> -# Optional: Network test configuration
> -TEST_RUNNER = $(BSP)
>  NET_CFG_SELF_IP = 10.0.2.1
>  NET_CFG_NETMASK = 255.255.0.0
>  NET_CFG_PEER_IP = 192.168.100.11
>  NET_CFG_GATEWAY_IP = 192.168.100.11
> -NET_TAP_INTERFACE = tap0
> diff --git a/libbsd.txt b/libbsd.txt
> index 71d5cc8d..b0b59504 100644
> --- a/libbsd.txt
> +++ b/libbsd.txt
> @@ -42,7 +42,8 @@ installed.
>  
>  . Clone the Git repository +git clone git://git.rtems.org/rtems-libbsd.git+.
>  . Change into the RTEMS BSD library root directory.
> -. Edit the `config.inc` configuration file and adjust it to your environment.
> +. If you want to run tests with a custom IP configuration instead of the 
> default
> +  one you can adjust the `config.inc` configuration file.
>  . Run +waf configure ...+.
>  . Run +waf+.
>  . Run +waf install+.
> @@ -119,27 +120,16 @@ devices (you can run multiple test instances on one 
> virtual network).
>  The build system based on the Waf build system. To build with Waf please 
> refer
>  to the README.waf file.
>  
> -= Example Configuration =
> += Example Configuration for Network Tests =
>  
> -In the BSD library source directory edit the file `config.inc`.  Continuing 
> on
> -the above, the `config.inc` used to match the above is:
> +If you need some other IP configuration for some of the network tests you can
> +edit the file `config.inc`:
>  

Ah ok, this may explain the disconnect between us with this change, there is an
option to provide an external version of the file, see `waf --help`. This means
you do not need to touch the source tree.

What about changing the last line to:

 +If you need some other IP configuration for some of the network tests copy
 +`config.inc` to a location outside to the source tree and change then
 +use the option `--net-test-config=NET_CONFIG` to pass the file to waf's
 +configure command.

Chris

>  
> ---
> -# Mandatory: Select your BSP and installation prefix
> -TARGET = arm-rtems4.12
> -BSP = xilinx_zynq_a9_qemu
> -PREFIX = $(HOME)/sandbox/install
> -
> -# Optional: Separate installation base directory
> -INSTALL_BASE = $(PREFIX)/$(TARGET)/$(BSP)
> -
> -# Optional: Network test configuration
> -TEST_RUNNER = $(BSP)
>  NET_CFG_SELF_IP = 10.0.0.2
>  NET_CFG_NETMASK = 255.255.0.0
>  NET_CFG_PEER_IP = 10.0.0.1
>  NET_CFG_GATEWAY_IP = 10.0.0.1
> -NET_TAP_INTERFACE = tap0
>  
> ---
>  
>  === BSD Library Initialization ===
> diff --git a/libbsd_waf.py b/libbsd_waf.py
> index 745512bf..65f5ae0f 100644
> --- a/libbsd_waf.py
> +++ b/libbsd_waf.py
> @@ -98,7 +98,6 @@ def build(bld):
>  net_cfg_netmask = None
>  net_cfg_peer_ip = None
>  net_cfg_gateway_ip = None
> -net_tap_interface = None
>  try:
>  net_cfg_lines = open(bld.env.NET_CONFIG).readlines()
>  except:
> @@ -120,8 +119,6 @@ def build(bld):
>  net_cfg_peer_ip = rhs
>  if lhs == "NET_CFG_GATEWAY_IP":
>  net_cfg_gateway_ip = rhs
> -if lhs == "NET_TAP_INTERFACE":
> -net_tap_interface = rhs
>  bld(target = "testsuite/include/rtems/bsd/test/network-config.h",
>  source = "testsuite/include/rtems/bsd/test/network-config.h.in",
>  rule = "sed -e 's/@NET_CFG_SELF_IP@/%s/' -e 
> 's/@NET_CFG_NETMASK@/%s/' -e 's/@NET_CFG_PEER_IP@/%s/' -e 
> 's/@NET_CFG_GATEWAY_IP@/%s/' < ${SRC} > ${TGT}" % (net_cfg_self_ip, 
> net_cfg_netmask, net_cfg_peer_ip, net_cfg_gateway_ip),
> diff --git a/waf_generator.py b/waf_generator.py
> index 73b02a83..70b0c307 100755
> --- a/waf_generator.py
> +++ b/waf_generator.py
> @@ -416,7 +416,6 @@ class ModuleManager(builder.ModuleManager):
>  self.add('net_cfg_netmask = None')
>  self.add('net_cfg_peer_ip = None')
>  self.add('net_cfg_gateway_ip = None')
> -self.add('net_tap_interface = None')
>  self.add('try:')
>  self.add('net_cfg_lines = 
> open(bld.env.NET_CONFIG).readlines()')
>  self.add('except:')
> @@ -439,8 +438,6 @@ class ModuleManager(builder.ModuleManager):
>  self.add('net_cfg_peer_ip = rhs')
>  self.add('if lhs == "NET_CFG_GATEWAY_IP":')
>  self.add('  

Re: [PATCH] MAINAINERS: Add rule for BSP-specific patches

[Chris Johns]

+1

On 21/3/18 2:35 am, Gedare Bloom wrote:
> Thanks, looks good.
> 
> On Tue, Mar 20, 2018 at 8:54 AM, Sebastian Huber
>  wrote:
>> On 20/03/18 13:43, Sebastian Huber wrote:
>>>
>>> +devel@rtems.org in case nobody explictly rejected the patch.
>>
>>
>> Sorry for the typo.
>>
>> --
>> 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

Re: [ANNOUNCE] RTEMS 4.11.3 Release

[Sebastian Huber]

The web site https://www.rtems.org/ needs an update. Latest release is 
still 4.11.2 on this page.


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