Re: [PATCH] sparc,smp: typo in start.S causing SMP not working
Thanks for the quick review. I will push it in. I will be posting some more patches next week that we have in the pipe, some related to the LLVM development work we are doing. Regards, Daniel On 2018-08-24 15:43, Sebastian Huber wrote: Hello Daniel, the patch set looks good, please check it in. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] sparc,smp: typo in start.S causing SMP not working
Hello Daniel, the patch set looks good, please check it in. -- 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] sparc,smp: typo in start.S causing SMP not working
--- bsps/sparc/shared/start/start.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bsps/sparc/shared/start/start.S b/bsps/sparc/shared/start/start.S index 48072e8..0be93ed 100644 --- a/bsps/sparc/shared/start/start.S +++ b/bsps/sparc/shared/start/start.S @@ -310,7 +310,7 @@ SYM(hard_reset): andn%sp, 0x0f, %sp ! align stack on 16-byte boundary mov %sp, %fp! set frame pointer - mov %o0, %g6 + mov %g6, %o0 callSYM(bsp_start_on_secondary_processor) ! does not return sub%sp, SPARC_MINIMUM_STACK_FRAME_SIZE, %sp .Lbootcpu: -- 2.7.4 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] leon, greth: enable MAC filtering (promiscous mode, multicast)
It enabled promiscous mode or sets the multicast filter according
to the configuration and parameters to ioctl(SIOCSIFFLAGS),
ioctl(SIOCADDMULTI) and ioctl(SIOCDELMULTI).
On SIOCADDMULTI/SIOCDELMULTI requests the greth ioctl calls the
Ethernet helper functions ether_addmulti()/ether_delmulti() which
tells the greth driver when its required to update the MAC multicast
filtering.
The interface notifies support for multicast by setting IFF_MULTICAST.
The GRETH has two registers which contains a bit-mask of allowed MAC
addresses. The incomming MAC address is CRC:ed and the CRC is used as
an index into the bit-mask to determine to allow or drop the frame.
---
bsps/sparc/include/bsp/greth.h | 7 +++
bsps/sparc/shared/net/greth.c | 99 +-
2 files changed, 105 insertions(+), 1 deletion(-)
diff --git a/bsps/sparc/include/bsp/greth.h b/bsps/sparc/include/bsp/greth.h
index 9209d82..1c42c99 100644
--- a/bsps/sparc/include/bsp/greth.h
+++ b/bsps/sparc/include/bsp/greth.h
@@ -24,6 +24,9 @@ typedef struct _greth_regs {
volatile uint32_t mdio_ctrl;/* MDIO control and status */
volatile uint32_t txdesc; /* Transmit descriptor pointer */
volatile uint32_t rxdesc; /* Receive descriptor pointer */
+ volatile uint32_t edcl; /* EDCL IP register */
+ volatile uint32_t ht_msb; /* Multicast MSB hash */
+ volatile uint32_t ht_lsb; /* Multicast LSB hash */
} greth_regs;
#define GRETH_TOTAL_BD 128
@@ -83,8 +86,12 @@ typedef struct _greth_regs {
#define GRETH_CTRL_RST 0x0040 /* Reset MAC */
#define GRETH_CTRL_SP 0x0080 /* 100MBit speed mode */
#define GRETH_CTRL_GB 0x0100 /* 1GBit speed mode */
+#define GRETH_CTRL_MCE 0x0800 /* Multicast Enable */
#define GRETH_CTRL_DD 0x1000 /* Disable EDCL Duplex Detection */
#define GRETH_CTRL_ED 0x4000 /* EDCL Disable */
+#define GRETH_CTRL_MC 0x0200 /* Multicast available */
+#define GRETH_CTRL_ME 0x0400 /* MDIO interrupts enabled */
+#define GRETH_CTRL_GA 0x0800 /* Gigabit MAC available */
/* Status Register */
#define GRETH_STATUS_RXERR 0x0001 /* Receive Error */
diff --git a/bsps/sparc/shared/net/greth.c b/bsps/sparc/shared/net/greth.c
index b2d2569..d282451 100644
--- a/bsps/sparc/shared/net/greth.c
+++ b/bsps/sparc/shared/net/greth.c
@@ -194,6 +194,7 @@ struct greth_softc
int auto_neg;
unsigned int advmodes; /* advertise ethernet speed modes. 0 = all modes. */
struct timespec auto_neg_time;
+ int mc_available;
/*
* Statistics
@@ -341,6 +342,78 @@ static void print_init_info(struct greth_softc *sc)
#endif
}
+/*
+ * Generates the hash words based on CRCs of the enabled MAC addresses that are
+ * allowed to be received. The allowed MAC addresses are maintained in a linked
+ * "multi-cast" list available in the arpcom structure.
+ *
+ * Returns the number of MAC addresses that were processed (in the list)
+ */
+static int
+greth_mac_filter_calc(struct arpcom *ac, uint32_t *msb, uint32_t *lsb)
+{
+struct ether_multistep step;
+struct ether_multi *enm;
+int cnt = 0;
+uint32_t crc, htindex, ht[2] = {0, 0};
+
+/* Go through the Ethernet Multicast addresses one by one and add their
+ * CRC contribution to the MAC filter.
+ */
+ETHER_FIRST_MULTI(step, ac, enm);
+while (enm) {
+crc = ether_crc32_be((uint8_t *)enm->enm_addrlo, 6);
+htindex = crc & 0x3f;
+ht[htindex >> 5] |= (1 << (htindex & 0x1F));
+cnt++;
+ETHER_NEXT_MULTI(step, enm);
+}
+
+if (cnt > 0) {
+*msb = ht[1];
+*lsb = ht[0];
+}
+
+return cnt;
+}
+
+/*
+ * Initialize the ethernet hardware
+ */
+static int greth_mac_filter_set(struct greth_softc *sc)
+{
+struct ifnet *ifp = >arpcom.ac_if;
+uint32_t hash_msb, hash_lsb, ctrl;
+SPIN_IRQFLAGS(flags);
+
+hash_msb = 0;
+hash_lsb = 0;
+ctrl = 0;
+if (ifp->if_flags & IFF_PROMISC) {
+/* No need to enable multi-cast when promiscous mode accepts all */
+ctrl |= GRETH_CTRL_PRO;
+} else if(!sc->mc_available) {
+return EINVAL; /* no hardware support for multicast filtering. */
+} else if (ifp->if_flags & IFF_ALLMULTI) {
+/* We should accept all multicast addresses */
+ctrl |= GRETH_CTRL_MCE;
+hash_msb = 0x;
+hash_lsb = 0x;
+} else if (greth_mac_filter_calc(>arpcom, _msb, _lsb) > 0) {
+/* Generate hash for MAC filtering out multicast addresses */
+ctrl |= GRETH_CTRL_MCE;
+} else {
+/* Multicast list is empty .. disable multicast */
+}
+SPIN_LOCK_IRQ(>devlock, flags);
+sc->regs->ht_msb = hash_msb;
+sc->regs->ht_lsb = hash_lsb;
+sc->regs->ctrl = (sc->regs->ctrl & ~(GRETH_CTRL_PRO | GRETH_CTRL_MCE)) |
+ ctrl;
+SPIN_UNLOCK_IRQ(>devlock, flags);
+
[PATCH] capture: prevent unaligned access when reading time
LLVM warns about this:
cpukit/libmisc/capture/capture.c:405:30: warning:
taking address of packed member 'time' of class or structure
'rtems_capture_record' may result in an unaligned pointer value
[-Waddress-of-packed-member]
rtems_capture_get_time ();
And on sparc it generates an unaligned trap which makes smpcapture01
and smpcapture02 test to fail on sparc.
---
cpukit/libmisc/capture/capture.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/cpukit/libmisc/capture/capture.c b/cpukit/libmisc/capture/capture.c
index 19a90c5..4d40b8f 100644
--- a/cpukit/libmisc/capture/capture.c
+++ b/cpukit/libmisc/capture/capture.c
@@ -387,6 +387,7 @@ rtems_capture_record_open (rtems_tcb*
tcb,
if (ptr != NULL)
{
rtems_capture_record in;
+rtems_capture_time time;
++cpu->count;
@@ -402,7 +403,8 @@ rtems_capture_record_open (rtems_tcb*
tcb,
rtems_capture_task_real_priority (tcb) |
(rtems_capture_task_curr_priority (tcb) << 8));
-rtems_capture_get_time ();
+rtems_capture_get_time ();
+in.time = time; /* need this since in is a packed struct */
ptr = rtems_capture_record_append(ptr, , sizeof(in));
}
--
2.7.4
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] psxfile01: floating point context required when calling fprintf
This avoids an exception (FP disabled) when RTEMS/Newlib have been built with LLVM/Sparc. --- testsuites/psxtests/psxfile01/main.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/testsuites/psxtests/psxfile01/main.c b/testsuites/psxtests/psxfile01/main.c index c634082..5ccdd6b 100644 --- a/testsuites/psxtests/psxfile01/main.c +++ b/testsuites/psxtests/psxfile01/main.c @@ -44,6 +44,8 @@ rtems_task Init( #define CONFIGURE_RTEMS_INIT_TASKS_TABLE +#define CONFIGURE_INIT_TASK_ATTRIBUTES RTEMS_FLOATING_POINT + #define CONFIGURE_INIT #include -- 2.7.4 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] spglobalcon01: LLVM optimization makes variable i always 1
Declare i volatile to avoid compiler optimization putting i
into data section with initialization value 1.
---
testsuites/sptests/spglobalcon01/init.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/testsuites/sptests/spglobalcon01/init.cc
b/testsuites/sptests/spglobalcon01/init.cc
index aee9d0a..f31ceca 100644
--- a/testsuites/sptests/spglobalcon01/init.cc
+++ b/testsuites/sptests/spglobalcon01/init.cc
@@ -27,10 +27,10 @@ class A {
++i;
}
-static int i;
+static volatile int i;
};
-int A::i;
+volatile int A::i;
static A a;
--
2.7.4
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] psx13: floating point context required when calling fprintf
This avoids an exception (FP disabled) when RTEMS/Newlib have been built with LLVM/Sparc. --- testsuites/psxtests/psx13/main.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/testsuites/psxtests/psx13/main.c b/testsuites/psxtests/psx13/main.c index aee8b78..05909a2 100644 --- a/testsuites/psxtests/psx13/main.c +++ b/testsuites/psxtests/psx13/main.c @@ -43,6 +43,8 @@ rtems_task Init( #define CONFIGURE_RTEMS_INIT_TASKS_TABLE +#define CONFIGURE_INIT_TASK_ATTRIBUTES RTEMS_FLOATING_POINT + #define CONFIGURE_INIT #include -- 2.7.4 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] leon, grspw_pkt: remove incorrect comment on SMP not being tested
To clarify, SMP with GRSWP_PKT driver API has been extended to take advantage of multi-core, is now SMP-safe, and has been tested on GR740. --- bsps/sparc/shared/spw/grspw_pkt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bsps/sparc/shared/spw/grspw_pkt.c b/bsps/sparc/shared/spw/grspw_pkt.c index b7b3624..ff481f2 100644 --- a/bsps/sparc/shared/spw/grspw_pkt.c +++ b/bsps/sparc/shared/spw/grspw_pkt.c @@ -2,7 +2,7 @@ * Cobham Gaisler GRSPW/GRSPW2 SpaceWire Kernel Library Interface for RTEMS. * * This driver can be used to implement a standard I/O system "char"-driver - * or used directly. NOTE SMP support has not been tested. + * or used directly. * * COPYRIGHT (c) 2011 * Cobham Gaisler AB -- 2.7.4 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] sparc: Restore npc when returning from the syscall_lazy_fp_switch trap
From: Daniel Cederman If the floating point trap occurred in a delay slot it is not certain that npc will be equal to pc + 4. --- cpukit/score/cpu/sparc/syscall.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cpukit/score/cpu/sparc/syscall.S b/cpukit/score/cpu/sparc/syscall.S index da0ee43..574cf66 100644 --- a/cpukit/score/cpu/sparc/syscall.S +++ b/cpukit/score/cpu/sparc/syscall.S @@ -245,7 +245,7 @@ SYM(syscall_lazy_fp_switch): /* Now, retry the floating point instruction with PSR[EF] == 1 */ jmp %l1 -rett %l1 + 4 +rett %l2 .Lillegal_use_of_floating_point_unit: -- 2.7.4 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] leon, greth: 10/100 MAC enable TX BD interrupt
Missed to enable interrupt per TX descriptor. Could lead to TX buffer
starvation.
Does not affect the GBit code.
---
bsps/sparc/shared/net/greth.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/bsps/sparc/shared/net/greth.c b/bsps/sparc/shared/net/greth.c
index eafcb99..b2d2569 100644
--- a/bsps/sparc/shared/net/greth.c
+++ b/bsps/sparc/shared/net/greth.c
@@ -868,23 +868,23 @@ sendpacket (struct ifnet *ifp, struct mbuf *m)
if ((m = m->m_next) == NULL)
break;
}
-
+
m_freem (n);
-
+
/* don't send long packets */
if (len <= GRETH_MAXBUF_LEN) {
if (dp->tx_ptr < dp->txbufs-1) {
-dp->txdesc[dp->tx_ptr].ctrl = GRETH_TXD_ENABLE | len;
+dp->txdesc[dp->tx_ptr].ctrl = GRETH_TXD_IRQ |
+ GRETH_TXD_ENABLE | len;
} else {
-dp->txdesc[dp->tx_ptr].ctrl =
+dp->txdesc[dp->tx_ptr].ctrl = GRETH_TXD_IRQ |
GRETH_TXD_WRAP | GRETH_TXD_ENABLE | len;
}
dp->tx_ptr = (dp->tx_ptr + 1) % dp->txbufs;
SPIN_LOCK_IRQ(>devlock, flags);
dp->regs->ctrl = dp->regs->ctrl | GRETH_CTRL_TXEN;
SPIN_UNLOCK_IRQ(>devlock, flags);
-
}
return 0;
--
2.7.4
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] leon, apbuart: replace termios c_cflag & CBAUD with c_{i, o}speed
ince some time RTEMS started to use the termios c_ispeed and
c_ospeed variables in the termios struct to hold the UART baudrate.
However the APBUART driver still uses the old c_cflag sometimes
causing other UART parameters to get overwritten, for example the
partiy setting no mapped to the same bits as the old CBAUD mask.
At the same time the RTEMS primitievs for setting/reading
c_{i,o}speed is now used.
---
bsps/sparc/shared/uart/apbuart_cons.c | 64 ++-
1 file changed, 3 insertions(+), 61 deletions(-)
diff --git a/bsps/sparc/shared/uart/apbuart_cons.c
b/bsps/sparc/shared/uart/apbuart_cons.c
index ac8a436..a54c2229 100644
--- a/bsps/sparc/shared/uart/apbuart_cons.c
+++ b/bsps/sparc/shared/uart/apbuart_cons.c
@@ -515,57 +515,6 @@ static int read_task(rtems_termios_device_context *base)
return EOF;
}
-
-struct apbuart_baud {
- unsigned int num;
- unsigned int baud;
-};
-static struct apbuart_baud apbuart_baud_table[] = {
- {B50, 50},
- {B75, 75},
- {B110, 110},
- {B134, 134},
- {B150, 150},
- {B200, 200},
- {B300, 300},
- {B600, 600},
- {B1200, 1200},
- {B1800, 1800},
- {B2400, 2400},
- {B4800, 4800},
- {B9600, 9600},
- {B19200, 19200},
- {B38400, 38400},
- {B57600, 57600},
- {B115200, 115200},
- {B230400, 230400},
- {B460800, 460800},
-};
-#define BAUD_NUM (sizeof(apbuart_baud_table)/sizeof(struct apbuart_baud))
-
-static int apbuart_baud_num2baud(unsigned int num)
-{
- int i;
-
- for(i=0; ic_ospeed);
+ baud = rtems_termios_baud_to_number(t->c_ospeed);
if (baud > 0){
/* Get APBUART core frequency */
drvmgr_freq_get(uart->dev, DEV_APB_SLV, _clk_hz);
@@ -666,9 +610,8 @@ static void get_attributes(
{
struct apbuart_priv *uart = base_get_priv(base);
unsigned int ctrl;
- struct apbuart_baud *baud;
- t->c_cflag = t->c_cflag & ~(CSIZE|PARENB|PARODD|CLOCAL);
+ t->c_cflag = t->c_cflag & ~(CSIZE|PARENB|PARODD|CLOCAL);
/* Hardware support only CS8 */
t->c_cflag |= CS8;
@@ -685,8 +628,7 @@ static void get_attributes(
if ((ctrl & LEON_REG_UART_CTRL_FL) == 0)
t->c_cflag |= CLOCAL;
- baud = apbuart_get_baud_closest(uart);
- t->c_cflag |= baud->num;
+ rtems_termios_set_best_baud(t, apbuart_get_baud(uart));
}
static void write_polled(
--
2.7.4
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Future of or1k RTEMS support?
On Fri, Aug 24, 2018, 7:04 AM Martin Erik Werner < martinerikwerner@gmail.com> wrote: > Hi, > > Regarding or1k, we (ÅAC Microtec/Clyde Space) are currently using it, > together with RTEMS, in some of our products[0], and are thus quite > interested in its continued life as a part of RTEMS, at least in the > foreseeable future (i.e. RTEMS 5). > Thank you for speaking up. Without users filing tickets or saying they are using a target or bsp in RTEMS, we really have no way of knowing if it is used or not. Do you have any local fixes which should be in the main RTEMS repository? It would be most helpful if we could count on you to periodically test and post results. We are happy to guide you through this. > With regards to the upstreaming of GCC, there are still ongoing work on > this for or1k at https://github.com/stffrdhrn/gcc . > As a general rule, when gcc deprecates support for an architecture or the support doesn't get upstreamed and thus begins to bitrot, we treat that as the biggest flag that the architecture needs to be put on an RTEMS deprecation path. Seeing this upstreamed is a good sign. As long as the tools are ok and there are signs of active use, removing a bsp or architecture is very unlikely. Unfortunately, from our perspective, the or1k didn't appear to meet either of those criteria until recently. > > [0] > http://aacmicrotec.com/products/spacecraft-subsystems/avionics/siriusobc/ > http://aacmicrotec.com/products/spacecraft-subsystems/avionics/siriustcm/ > > -- > Martin Erik Werner > ÅAC Microtec AB | Clyde Space Ltd. > > On Thu, 2018-07-26 at 10:01 +0100, Hesham Almatary wrote: > > Hi Sebastian, > > > > Yes, I agree with you. Furthermore, most of the or1k hardware and > software folks are moving to riscv now. > > > > Should we make it obsolete? > > > > Cheers, > > Hesham > > > > On Thu, 26 Jul 2018 at 7:10 am, Sebastian Huber < > sebastian.hu...@embedded-brains.de> wrote: > > > Hello, > > > > > > the or1k ecosystem has a major problem with their non-FSF GCC from my > > > point of view which is maintained here: > > > > > > https://github.com/openrisc/or1k-gcc > > > > > > The last commit was in 2016. It looks like a dead project to me. > > > > > > Given the momentum RISC-V has currently why would someone still want > to > > > use or1k? All RISC-V tools are upstream and well maintained. It is the > > > target with the most helpful and responsive maintainers that I worked > > > with so far. > > > > > > ___ > > > 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: Future of or1k RTEMS support?
Hi, Regarding or1k, we (ÅAC Microtec/Clyde Space) are currently using it, together with RTEMS, in some of our products[0], and are thus quite interested in its continued life as a part of RTEMS, at least in the foreseeable future (i.e. RTEMS 5). With regards to the upstreaming of GCC, there are still ongoing work on this for or1k at https://github.com/stffrdhrn/gcc . [0] http://aacmicrotec.com/products/spacecraft-subsystems/avionics/siriusobc/ http://aacmicrotec.com/products/spacecraft-subsystems/avionics/siriustcm/ -- Martin Erik Werner ÅAC Microtec AB | Clyde Space Ltd. On Thu, 2018-07-26 at 10:01 +0100, Hesham Almatary wrote: > Hi Sebastian, > > Yes, I agree with you. Furthermore, most of the or1k hardware and software > folks are moving to riscv now. > > Should we make it obsolete? > > Cheers, > Hesham > > On Thu, 26 Jul 2018 at 7:10 am, Sebastian Huber > wrote: > > Hello, > > > > the or1k ecosystem has a major problem with their non-FSF GCC from my > > point of view which is maintained here: > > > > https://github.com/openrisc/or1k-gcc > > > > The last commit was in 2016. It looks like a dead project to me. > > > > Given the momentum RISC-V has currently why would someone still want to > > use or1k? All RISC-V tools are upstream and well maintained. It is the > > target with the most helpful and responsive maintainers that I worked > > with so far. > > > > ___ > > 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: git.rtems.org LetsEncrypt TLS certificate expired
Hi! Seems like rtems.org now has this issue. On Thu, Aug 16, 2018 at 6:09 AM Chris Johns wrote: > > On 15/8/18 11:19 pm, Amaan Cheval wrote: > > FYI: https://docs.rtems.org has an expired certificate too. > > > > On Wed, Aug 15, 2018 at 3:30 PM, Amaan Cheval > > wrote: > >> The HTTPS certificate for https://git.rtems.org has expired (~15 > >> minutes ago). Are the auto-renewal scripts failing? > > Thank you for the notice. Amar has resolved this issue. > > Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 4/4] Add FreeBSD kernel space header files
Move the kernel space content of some Newlib provided header files to RTEMS and libbsd. This allows to use the Newlib provided header files with different FreeBSD baselines. Update #3472. --- rtemsbsd/include/machine/_kernel_if.h | 48 ++ rtemsbsd/include/machine/_kernel_socket.h | 83 +++ 2 files changed, 131 insertions(+) create mode 100644 rtemsbsd/include/machine/_kernel_if.h create mode 100644 rtemsbsd/include/machine/_kernel_socket.h diff --git a/rtemsbsd/include/machine/_kernel_if.h b/rtemsbsd/include/machine/_kernel_if.h new file mode 100644 index 0..08086658d --- /dev/null +++ b/rtemsbsd/include/machine/_kernel_if.h @@ -0,0 +1,48 @@ +/*- + * SPDX-License-Identifier: BSD-3-Clause + * + * Copyright (c) 1982, 1986, 1989, 1993 + * The Regents of the University of California. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + *notice, this list of conditions and the following disclaimer in the + *documentation and/or other materials provided with the distribution. + * 3. Neither the name of the University nor the names of its contributors + *may be used to endorse or promote products derived from this software + *without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * @(#)if.h8.1 (Berkeley) 6/10/93 + * $FreeBSD: head/sys/net/if.h 333502 2018-05-11 20:08:28Z mmacy $ + */ + +#if !defined(_NET_IF_H_) || !defined(_KERNEL) +#error "must be included via in kernel space" +#endif + +#ifdef MALLOC_DECLARE +MALLOC_DECLARE(M_IFADDR); +MALLOC_DECLARE(M_IFMADDR); +#endif + +#defineifr_buffer ifr_ifru.ifru_buffer/* user supplied buffer with its length */ +#defineifr_dataifr_ifru.ifru_data /* for use by interface */ + +#define ifgr_group ifgr_ifgru.ifgru_group +#define ifgr_groupsifgr_ifgru.ifgru_groups diff --git a/rtemsbsd/include/machine/_kernel_socket.h b/rtemsbsd/include/machine/_kernel_socket.h new file mode 100644 index 0..e9acc744f --- /dev/null +++ b/rtemsbsd/include/machine/_kernel_socket.h @@ -0,0 +1,83 @@ +/*- + * SPDX-License-Identifier: BSD-3-Clause + * + * Copyright (c) 1982, 1985, 1986, 1988, 1993, 1994 + * The Regents of the University of California. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + *notice, this list of conditions and the following disclaimer in the + *documentation and/or other materials provided with the distribution. + * 3. Neither the name of the University nor the names of its contributors + *may be used to endorse or promote products derived from this software + *without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * @(#)socket.h8.4 (Berkeley) 2/21/94 + * $FreeBSD: head/sys/sys/socket.h
[PATCH 2/4] WPA_SUPPLICANT(8): Remove unused files
Remove unused files which may make trouble during FreeBSD baseline
updates. It also increased the compile-time of the library for nothing.
Update #3472.
---
freebsd/contrib/wpa/src/rsn_supp/tdls.c | 3054 --
freebsd/contrib/wpa/wpa_supplicant/wnm_sta.c | 1168 --
libbsd.py|2 -
3 files changed, 4224 deletions(-)
delete mode 100644 freebsd/contrib/wpa/src/rsn_supp/tdls.c
delete mode 100644 freebsd/contrib/wpa/wpa_supplicant/wnm_sta.c
diff --git a/freebsd/contrib/wpa/src/rsn_supp/tdls.c
b/freebsd/contrib/wpa/src/rsn_supp/tdls.c
deleted file mode 100644
index 337fb80c1..0
--- a/freebsd/contrib/wpa/src/rsn_supp/tdls.c
+++ /dev/null
@@ -1,3054 +0,0 @@
-#include
-
-/*
- * wpa_supplicant - TDLS
- * Copyright (c) 2010-2011, Atheros Communications
- *
- * This software may be distributed under the terms of the BSD license.
- * See README for more details.
- */
-
-#include "utils/includes.h"
-
-#include "utils/common.h"
-#include "utils/eloop.h"
-#include "utils/os.h"
-#include "common/ieee802_11_defs.h"
-#include "common/ieee802_11_common.h"
-#include "crypto/sha256.h"
-#include "crypto/crypto.h"
-#include "crypto/aes_wrap.h"
-#include "rsn_supp/wpa.h"
-#include "rsn_supp/wpa_ie.h"
-#include "rsn_supp/wpa_i.h"
-#include "drivers/driver.h"
-#include "l2_packet/l2_packet.h"
-
-#if defined(__rtems__) && defined(CONFIG_TDLS)
-#ifdef CONFIG_TDLS_TESTING
-#define TDLS_TESTING_LONG_FRAME BIT(0)
-#define TDLS_TESTING_ALT_RSN_IE BIT(1)
-#define TDLS_TESTING_DIFF_BSSID BIT(2)
-#define TDLS_TESTING_SHORT_LIFETIME BIT(3)
-#define TDLS_TESTING_WRONG_LIFETIME_RESP BIT(4)
-#define TDLS_TESTING_WRONG_LIFETIME_CONF BIT(5)
-#define TDLS_TESTING_LONG_LIFETIME BIT(6)
-#define TDLS_TESTING_CONCURRENT_INIT BIT(7)
-#define TDLS_TESTING_NO_TPK_EXPIRATION BIT(8)
-#define TDLS_TESTING_DECLINE_RESP BIT(9)
-#define TDLS_TESTING_IGNORE_AP_PROHIBIT BIT(10)
-#define TDLS_TESTING_WRONG_MIC BIT(11)
-unsigned int tdls_testing = 0;
-#endif /* CONFIG_TDLS_TESTING */
-
-#define TPK_LIFETIME 43200 /* 12 hours */
-#define TPK_M1_RETRY_COUNT 3
-#define TPK_M1_TIMEOUT 5000 /* in milliseconds */
-#define TPK_M2_RETRY_COUNT 10
-#define TPK_M2_TIMEOUT 500 /* in milliseconds */
-
-#define TDLS_MIC_LEN 16
-
-#define TDLS_TIMEOUT_LEN 4
-
-struct wpa_tdls_ftie {
- u8 ie_type; /* FTIE */
- u8 ie_len;
- u8 mic_ctrl[2];
- u8 mic[TDLS_MIC_LEN];
- u8 Anonce[WPA_NONCE_LEN]; /* Responder Nonce in TDLS */
- u8 Snonce[WPA_NONCE_LEN]; /* Initiator Nonce in TDLS */
- /* followed by optional elements */
-} STRUCT_PACKED;
-
-struct wpa_tdls_timeoutie {
- u8 ie_type; /* Timeout IE */
- u8 ie_len;
- u8 interval_type;
- u8 value[TDLS_TIMEOUT_LEN];
-} STRUCT_PACKED;
-
-struct wpa_tdls_lnkid {
- u8 ie_type; /* Link Identifier IE */
- u8 ie_len;
- u8 bssid[ETH_ALEN];
- u8 init_sta[ETH_ALEN];
- u8 resp_sta[ETH_ALEN];
-} STRUCT_PACKED;
-
-/* TDLS frame headers as per IEEE Std 802.11z-2010 */
-struct wpa_tdls_frame {
- u8 payloadtype; /* IEEE80211_TDLS_RFTYPE */
- u8 category; /* Category */
- u8 action; /* Action (enum tdls_frame_type) */
-} STRUCT_PACKED;
-
-static u8 * wpa_add_tdls_timeoutie(u8 *pos, u8 *ie, size_t ie_len, u32 tsecs);
-static void wpa_tdls_tpk_retry_timeout(void *eloop_ctx, void *timeout_ctx);
-static void wpa_tdls_peer_free(struct wpa_sm *sm, struct wpa_tdls_peer *peer);
-static void wpa_tdls_disable_peer_link(struct wpa_sm *sm,
- struct wpa_tdls_peer *peer);
-static int wpa_tdls_send_teardown(struct wpa_sm *sm, const u8 *addr,
- u16 reason_code);
-
-
-#define TDLS_MAX_IE_LEN 80
-#define IEEE80211_MAX_SUPP_RATES 32
-
-struct wpa_tdls_peer {
- struct wpa_tdls_peer *next;
- unsigned int reconfig_key:1;
- int initiator; /* whether this end was initiator for TDLS setup */
- u8 addr[ETH_ALEN]; /* other end MAC address */
- u8 inonce[WPA_NONCE_LEN]; /* Initiator Nonce */
- u8 rnonce[WPA_NONCE_LEN]; /* Responder Nonce */
- u8 rsnie_i[TDLS_MAX_IE_LEN]; /* Initiator RSN IE */
- size_t rsnie_i_len;
- u8 rsnie_p[TDLS_MAX_IE_LEN]; /* Peer RSN IE */
- size_t rsnie_p_len;
- u32 lifetime;
- int cipher; /* Selected cipher (WPA_CIPHER_*) */
- u8 dtoken;
-
- struct tpk {
- u8 kck[16]; /* TPK-KCK */
- u8 tk[16]; /* TPK-TK; assuming only CCMP will be used */
- } tpk;
- int tpk_set;
- int tk_set; /* TPK-TK configured to the driver */
- int tpk_success;
- int tpk_in_progress;
-
- struct tpk_timer {
- u8 dest[ETH_ALEN];
- int count; /* Retry Count */
- int timer; /* Timeout in milliseconds */
- u8 action_code; /* TDLS frame type */
- u8 dialog_token;
- u16
[PATCH 3/4] Allow *.c as kernel space header files
This is a workaround for the FreeBSD kernel space source file
sys/opencrypto/xform.c
which includes a bunch of *.c files.
Update #3472.
---
builder.py | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/builder.py b/builder.py
index 78f592c7b..7f4e71705 100755
--- a/builder.py
+++ b/builder.py
@@ -210,10 +210,16 @@ def assertHeaderFile(path):
def assertSourceFile(path):
if path[-2] != '.' or (path[-1] != 'c' and path[-1] != 'S'):
-print("*** " + path + " does not end in .c")
+print("*** " + path + " does not end in .c or .S")
print("*** Move it to a header file list")
sys.exit(2)
+def assertHeaderOrSourceFile(path):
+if path[-2] != '.' or (path[-1] != 'h' and path[-1] != 'c'):
+print("*** " + path + " does not end in .h or .c")
+print("*** Move it to another list")
+sys.exit(2)
+
def diffSource(dstLines, srcLines, src, dst):
global filesTotal, filesTotalLines, filesTotalInserts, filesTotalDeletes
#
@@ -664,7 +670,7 @@ class Module(object):
def addKernelSpaceHeaderFiles(self, files):
self.files += self.addFiles(files,
FreeBSDPathComposer(),
FromFreeBSDToRTEMSHeaderConverter(),
-FromRTEMSToFreeBSDHeaderConverter(),
assertHeaderFile)
+FromRTEMSToFreeBSDHeaderConverter(),
assertHeaderOrSourceFile)
def addUserSpaceHeaderFiles(self, files):
self.files += self.addFiles(files,
--
2.13.7
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Future of or1k RTEMS support?
On 26/07/18 08:10, Sebastian Huber wrote: Hello, the or1k ecosystem has a major problem with their non-FSF GCC from my point of view which is maintained here: https://github.com/openrisc/or1k-gcc The last commit was in 2016. It looks like a dead project to me. Given the momentum RISC-V has currently why would someone still want to use or1k? All RISC-V tools are upstream and well maintained. It is the target with the most helpful and responsive maintainers that I worked with so far. There was a request to include the ork1 into the FSF GCC recently: https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01507.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: Some problems with the libbsd update
On 24/08/2018 15:31, Sebastian Huber wrote: > > Could you then please make suggestions what should be placed where? Is the > User > Manual the landing point for users? This information could be added here: > > https://docs.rtems.org/branches/master/user/bsps/index.html > Sure, I will put this on the list and have a play. I am currently working on the release notes generator from Dannie's GSoC effort plus the newlib docs. I think the releases need this information more than the development branch. > My current itch is that I want to move forward with the libbsd and not be > burdened with work for obsolete and unmaintained architectures which will very > likely never use libbsd. I suggest libbsd probes a built and installed RTEMS for the features it needs to build and run. If the features are not present the package fails to configure and cannot be built. It might even be possible to use some libbsd modules and not others with some archs and BSPs. If RTEMS needs to be altered to provide or better provide the needed bits and pieces to probe then I suggest that be looked at. This however leaves open the question of what we would like libbsd to support, what we do support and what happens with regressions? I wonder if the kernel's tier approach could be applied to libbsd? It may mean you could concentrate on the archs and BSPs that are in the libbsd tier 1 or 2 or whatever we decide is the policy. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
