[PATCH 5/5] dev/sc16is752: Check return values.
Escalate a failed installation of the interrupts to the next higher
level.
---
cpukit/dev/serial/sc16is752.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/cpukit/dev/serial/sc16is752.c b/cpukit/dev/serial/sc16is752.c
index 153b589ac1..39e5df2ae7 100644
--- a/cpukit/dev/serial/sc16is752.c
+++ b/cpukit/dev/serial/sc16is752.c
@@ -234,11 +234,13 @@ static bool sc16is752_first_open(
set_efr(ctx, EFR_ENHANCED_FUNC_ENABLE);
rtems_termios_set_initial_baud(tty, 115200);
- sc16is752_set_attributes(base, term);
-
- (*ctx->install_irq)(ctx);
+ ok = sc16is752_set_attributes(base, term);
+ if (!ok) {
+return ok;
+ }
- return true;
+ ok = (*ctx->install_irq)(ctx);
+ return ok;
}
static void sc16is752_last_close(
--
2.13.6
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 4/5] dev/sc16is752: Add GPIO access via ioctl.
---
cpukit/dev/serial/sc16is752-regs.h| 2 ++
cpukit/dev/serial/sc16is752.c | 20
cpukit/include/dev/serial/sc16is752.h | 45 +++
3 files changed, 67 insertions(+)
diff --git a/cpukit/dev/serial/sc16is752-regs.h
b/cpukit/dev/serial/sc16is752-regs.h
index 8080074d2c..847874baab 100644
--- a/cpukit/dev/serial/sc16is752-regs.h
+++ b/cpukit/dev/serial/sc16is752-regs.h
@@ -107,6 +107,8 @@ extern "C" {
#define EFR_RTS_FLOW_CTRL_EN (1u << 6)
#define EFR_CTS_FLOW_CTRL_EN (1u << 7)
+/* IOCONTROL: User accessible. Therefore see sc16is752.h for the defines. */
+
#define SC16IS752_FIFO_DEPTH 64
#ifdef __cplusplus
diff --git a/cpukit/dev/serial/sc16is752.c b/cpukit/dev/serial/sc16is752.c
index 74c3ad3d7a..153b589ac1 100644
--- a/cpukit/dev/serial/sc16is752.c
+++ b/cpukit/dev/serial/sc16is752.c
@@ -282,6 +282,7 @@ static int sc16is752_ioctl(
)
{
sc16is752_context *ctx = (sc16is752_context *)base;
+ uint8_t regval;
switch (request) {
case SC16IS752_SET_SLEEP_MODE:
@@ -290,6 +291,25 @@ static int sc16is752_ioctl(
case SC16IS752_GET_SLEEP_MODE:
*(int *)buffer = is_sleep_mode_enabled(ctx);
break;
+case SC16IS752_SET_IOCONTROL:
+ regval = (*(uint8_t *)buffer) & ~SC16IS752_IOCONTROL_SRESET;
+ write_reg(ctx, SC16IS752_IOCONTROL, ®val, 1);
+ break;
+case SC16IS752_GET_IOCONTROL:
+ read_reg(ctx, SC16IS752_IOCONTROL, (uint8_t *)buffer, 1);
+ break;
+case SC16IS752_SET_IODIR:
+ write_reg(ctx, SC16IS752_IODIR, (uint8_t *)buffer, 1);
+ break;
+case SC16IS752_GET_IODIR:
+ read_reg(ctx, SC16IS752_IODIR, (uint8_t *)buffer, 1);
+ break;
+case SC16IS752_SET_IOSTATE:
+ write_reg(ctx, SC16IS752_IOSTATE, (uint8_t *)buffer, 1);
+ break;
+case SC16IS752_GET_IOSTATE:
+ read_reg(ctx, SC16IS752_IOSTATE, (uint8_t *)buffer, 1);
+ break;
default:
rtems_set_errno_and_return_minus_one(EINVAL);
}
diff --git a/cpukit/include/dev/serial/sc16is752.h
b/cpukit/include/dev/serial/sc16is752.h
index 7e5b47aaa2..67c2e009bc 100644
--- a/cpukit/include/dev/serial/sc16is752.h
+++ b/cpukit/include/dev/serial/sc16is752.h
@@ -251,10 +251,55 @@ rtems_status_code sc16is752_spi_create(
#define SC16IS752_SET_SLEEP_MODE _IOW('d', 0, int)
/**
+ * @brief Set the I/O Control bits except for the SRESET.
+ *
+ * Note that it will not be possible to set the SRESET. Otherwise the driver
+ * might would have an undefined state.
+ */
+#define SC16IS752_SET_IOCONTROL _IOW('d', 1, uint8_t)
+
+/**
+ * @brief Set the I/O pins direction register.
+ */
+#define SC16IS752_SET_IODIR _IOW('d', 2, uint8_t)
+
+/**
+ * @brief Set the I/O pins state register.
+ */
+#define SC16IS752_SET_IOSTATE _IOW('d', 3, uint8_t)
+
+/**
* @brief Returns non-zero in case the sleep mode is enabled, otherwise zero.
*/
#define SC16IS752_GET_SLEEP_MODE _IOR('d', 0, int)
+/**
+ * @brief Read the I/O Control register.
+ */
+#define SC16IS752_GET_IOCONTROL _IOR('d', 1, uint8_t)
+
+/**
+ * @brief Read the I/O pins direction register.
+ */
+#define SC16IS752_GET_IODIR _IOR('d', 2, uint8_t)
+
+/**
+ * @brief Read the I/O pins state register.
+ */
+#define SC16IS752_GET_IOSTATE _IOR('d', 3, uint8_t)
+
+/**
+ * @brief Bits for the IOCONTROL register.
+ * @{
+ */
+#define SC16IS752_IOCONTROL_SRESET (1u << 3)
+#define SC16IS752_IOCONTROL_GPIO_3_0_OR_MODEM (1u << 2)
+#define SC16IS752_IOCONTROL_GPIO_7_4_OR_MODEM (1u << 1)
+#define SC16IS752_IOCONTROL_IOLATCH (1u << 0)
+/**
+ * @}
+ */
+
#ifdef __cplusplus
}
#endif /* __cplusplus */
--
2.13.6
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 1/5] bsp/atsam: Add option to disable 32kHz XTAL.
From: Christian Mauderer
---
c/src/lib/libbsp/arm/atsam/README | 4
c/src/lib/libbsp/arm/atsam/configure.ac | 8
.../arm/atsam/libraries/libboard/resources_v71/system_samv71.c| 2 ++
3 files changed, 14 insertions(+)
diff --git a/c/src/lib/libbsp/arm/atsam/README
b/c/src/lib/libbsp/arm/atsam/README
index c374e861c3..2ebaa726c8 100644
--- a/c/src/lib/libbsp/arm/atsam/README
+++ b/c/src/lib/libbsp/arm/atsam/README
@@ -43,6 +43,10 @@ const struct BOARD_Sdram_Config BOARD_Sdram_Config = {
};
+Use ATSAM_SLOWCLOCK_USE_XTAL=0 to disable the usage of the external 32kHz
+oscillator for the slow clock. This is useful for example for the SAM E70
+Xplained kit.
+
Use ATSAM_CONSOLE_BAUD=XYZ to set the initial baud for console devices (default
115200).
diff --git a/c/src/lib/libbsp/arm/atsam/configure.ac
b/c/src/lib/libbsp/arm/atsam/configure.ac
index 519d5237f6..3ebeb93255 100644
--- a/c/src/lib/libbsp/arm/atsam/configure.ac
+++ b/c/src/lib/libbsp/arm/atsam/configure.ac
@@ -72,6 +72,14 @@ RTEMS_BSPOPTS_HELP([ATSAM_MCK],
[Frequency of the MCK in Hz. Set to 0 to force application defined speed.
See startup/pmc-config.c for available clock configurations.])
+RTEMS_BSPOPTS_SET([ATSAM_SLOWCLOCK_USE_XTAL],[*],[1])
+RTEMS_BSPOPTS_HELP([ATSAM_SLOWCLOCK_USE_XTAL],
+[Use the external crystal as source for the slow clock instead of the internal
+RC oscillator. Note that on the ATSAM the NRST pin seems to depend on the slow
+clock as well as all watchdogs. If ATSAM_SLOWCLOCK_USE_XTAL is set to 1 without
+a external crystal connected, the controller might hang in the switching
process
+without a working NRST pin. ])
+
RTEMS_BSPOPTS_SET([ATSAM_CHANGE_CLOCK_FROM_SRAM],[*],[0])
RTEMS_BSPOPTS_HELP([ATSAM_CHANGE_CLOCK_FROM_SRAM],
[Move the functions that set up the clock into the SRAM.
diff --git
a/c/src/lib/libbsp/arm/atsam/libraries/libboard/resources_v71/system_samv71.c
b/c/src/lib/libbsp/arm/atsam/libraries/libboard/resources_v71/system_samv71.c
index 8d7eb8e6a7..19c5a947b5 100644
---
a/c/src/lib/libbsp/arm/atsam/libraries/libboard/resources_v71/system_samv71.c
+++
b/c/src/lib/libbsp/arm/atsam/libraries/libboard/resources_v71/system_samv71.c
@@ -93,6 +93,7 @@ extern "C" {
* OSC
*/
+#if ATSAM_SLOWCLOCK_USE_XTAL == 1
read_MOR = PMC->CKGR_MOR;
/* enable external crystal - enable RC OSC */
read_MOR |= (CKGR_MOR_KEY_PASSWD | CKGR_MOR_XT32KFME);
@@ -104,6 +105,7 @@ extern "C" {
while (!(SUPC->SUPC_SR & SUPC_SR_OSCSEL));
}
+#endif
/* Initialize main oscillator */
if (!(PMC->CKGR_MOR & CKGR_MOR_MOSCSEL)) {
--
2.13.6
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 3/5] bsp/atsam: Fix cache / DMA handling in SPI.
This patch fixes the cache handling for the atsam SPI driver. Note that
this solution might doesn't have the best performance for small packets.
---
bsps/arm/atsam/headers.am | 1 +
bsps/arm/atsam/include/bsp/iocopy.h| 37
c/src/lib/libbsp/arm/atsam/Makefile.am | 3 +
.../arm/atsam/libraries/libchip/source/qspi.c | 36 +---
c/src/lib/libbsp/arm/atsam/spi/atsam_spi_bus.c | 205 +++--
c/src/lib/libbsp/arm/atsam/utils/iocopy.c | 49 +
6 files changed, 287 insertions(+), 44 deletions(-)
create mode 100644 bsps/arm/atsam/include/bsp/iocopy.h
create mode 100644 c/src/lib/libbsp/arm/atsam/utils/iocopy.c
diff --git a/bsps/arm/atsam/headers.am b/bsps/arm/atsam/headers.am
index 1ec34a2e69..70473c7ea1 100644
--- a/bsps/arm/atsam/headers.am
+++ b/bsps/arm/atsam/headers.am
@@ -11,6 +11,7 @@ include_bsp_HEADERS +=
../../../../../../bsps/arm/atsam/include/bsp/atsam-clock-
include_bsp_HEADERS += ../../../../../../bsps/arm/atsam/include/bsp/atsam-i2c.h
include_bsp_HEADERS += ../../../../../../bsps/arm/atsam/include/bsp/atsam-spi.h
include_bsp_HEADERS += ../../../../../../bsps/arm/atsam/include/bsp/i2c.h
+include_bsp_HEADERS += ../../../../../../bsps/arm/atsam/include/bsp/iocopy.h
include_bsp_HEADERS += ../../../../../../bsps/arm/atsam/include/bsp/irq.h
include_bsp_HEADERS +=
../../../../../../bsps/arm/atsam/include/bsp/pin-config.h
include_bsp_HEADERS += ../../../../../../bsps/arm/atsam/include/bsp/power.h
diff --git a/bsps/arm/atsam/include/bsp/iocopy.h
b/bsps/arm/atsam/include/bsp/iocopy.h
new file mode 100644
index 00..27e374747e
--- /dev/null
+++ b/bsps/arm/atsam/include/bsp/iocopy.h
@@ -0,0 +1,37 @@
+/*
+ * Copyright (c) 2018 embedded brains GmbH. All rights reserved.
+ *
+ * embedded brains GmbH
+ * Dornierstr. 4
+ * 82178 Puchheim
+ * Germany
+ *
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this distribution or at
+ * http://www.rtems.org/license/LICENSE.
+ */
+
+#ifndef ATSAM_IOCOPY_H
+#define ATSAM_IOCOPY_H
+
+#include
+#include
+
+#ifdef __cplusplus
+extern "C" {
+#endif /* __cplusplus */
+
+/*
+ * Note: This functions are for copying from or to memory that is marked as
+ * Peripheral memory. In this regions a misaligned access is not allowed.
+ * Therefore memcopy would not work in all cases.
+ */
+void atsam_copy_to_io(void *dst, const void *src, size_t n);
+void atsam_copy_from_io(void *dst, const void *src, size_t n);
+
+#ifdef __cplusplus
+}
+#endif /* __cplusplus */
+
+#endif /* ATSAM_IOCOPY_H */
diff --git a/c/src/lib/libbsp/arm/atsam/Makefile.am
b/c/src/lib/libbsp/arm/atsam/Makefile.am
index 10f34dab55..aa97025568 100644
--- a/c/src/lib/libbsp/arm/atsam/Makefile.am
+++ b/c/src/lib/libbsp/arm/atsam/Makefile.am
@@ -156,6 +156,9 @@ libbsp_a_SOURCES += spi/sc16is752.c
libbsp_a_SOURCES += ../../shared/tod.c
libbsp_a_SOURCES += rtc/rtc-config.c
+# Helper functions
+libbsp_a_SOURCES += utils/iocopy.c
+
# Includes
libbsp_a_CPPFLAGS += -I$(srcdir)/../shared/CMSIS/Include
libbsp_a_CPPFLAGS += -I$(srcdir)/libraries/libboard
diff --git a/c/src/lib/libbsp/arm/atsam/libraries/libchip/source/qspi.c
b/c/src/lib/libbsp/arm/atsam/libraries/libchip/source/qspi.c
index c80d0dd53a..314cfdf16c 100644
--- a/c/src/lib/libbsp/arm/atsam/libraries/libchip/source/qspi.c
+++ b/c/src/lib/libbsp/arm/atsam/libraries/libchip/source/qspi.c
@@ -75,6 +75,7 @@
#include "string.h"
#include
+#include
#define SCRAMBLE_KEY0x0BADDEAD
@@ -211,35 +212,6 @@ __STATIC_INLINE void QSPI_ScrambleData(Qspi *pQspi,
uint32_t wKey,
pQspi->QSPI_SMR = (EnableFlag | (Random << 1));
}
-static void do_copy(uint8_t *dst, const uint8_t *src, size_t n, bool aligned)
-{
- if (aligned) {
- while (n > 3) {
- *(uint32_t *)dst = *(uint32_t *)src;
- dst += 4;
- src += 4;
- n -= 4;
- }
- }
-
- while (n > 0) {
- *dst = *src;
- ++dst;
- ++src;
- --n;
- }
-}
-
-static void copy_to_io(void *dst, const void *src, size_t n)
-{
- do_copy(dst, src, n, ((uintptr_t)dst) % 4 == 0);
-}
-
-static void copy_from_io(void *dst, const void *src, size_t n)
-{
- do_copy(dst, src, n, ((uintptr_t)src) % 4 == 0);
-}
-
/*
*Exported functions
**/
@@ -766,9 +738,11 @@ QspidStatus_t QSPI_ReadWriteMem(Qspid_t *pQspid, Access_t
const ReadWrite)
&& (ReadWrite <= WriteAccess)) ? true : false);
if (ReadWrite == WriteAccess) {
- copy_to_io(pQspiMem, pBuffer.pDataTx , pBuffer.TxDataSize);
+ atsam_copy_to_io(pQspiMem, pBuffer.pDataTx ,
+ pBu
[PATCH 0/5] Improvements for atsam BSP and sc16is752 UART.
These patches add various improvements for the atsam BSP and for the sc16is752 SPI UART controller. Regarding patch 1: Note that I have thought about an auto detection instead of the option. But I had a board where something responded to the oscillator so that I could initialize it despite the fact that no crystall has been connected. So I think an auto detection would be dangerous. With kind regards Christian Mauderer ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 2/5] bsp/atsam: Allow to use a decoder for SPI CS.
The SPI controller supports a decoder connected to the chip select
lines. This patch allows to use this mode.
---
bsps/arm/atsam/include/bsp/atsam-spi.h | 13 +---
c/src/lib/libbsp/arm/atsam/spi/atsam_spi_bus.c | 41 -
c/src/lib/libbsp/arm/atsam/spi/atsam_spi_init.c | 26 +++-
3 files changed, 54 insertions(+), 26 deletions(-)
diff --git a/bsps/arm/atsam/include/bsp/atsam-spi.h
b/bsps/arm/atsam/include/bsp/atsam-spi.h
index 548dd544f4..4bfa6c3a1e 100644
--- a/bsps/arm/atsam/include/bsp/atsam-spi.h
+++ b/bsps/arm/atsam/include/bsp/atsam-spi.h
@@ -21,12 +21,17 @@
extern "C" {
#endif /* __cplusplus */
+typedef struct {
+ uint8_t spi_peripheral_id;
+ const Pin *pins;
+ Spi*spi_regs;
+ size_t pin_count;
+ boolchip_select_decode;
+} atsam_spi_config;
+
int spi_bus_register_atsam(
const char *bus_path,
- uint8_t spi_peripheral_id,
- Spi*spi_regs,
- const Pin *pins,
- size_t pin_count
+ const atsam_spi_config *config
);
#ifdef __cplusplus
diff --git a/c/src/lib/libbsp/arm/atsam/spi/atsam_spi_bus.c
b/c/src/lib/libbsp/arm/atsam/spi/atsam_spi_bus.c
index 5c6cdc2af7..24850c8327 100644
--- a/c/src/lib/libbsp/arm/atsam/spi/atsam_spi_bus.c
+++ b/c/src/lib/libbsp/arm/atsam/spi/atsam_spi_bus.c
@@ -49,6 +49,7 @@ typedef struct {
uint32_t dma_rx_channel;
int transfer_in_progress;
bool chip_select_active;
+ bool chip_select_decode;
} atsam_spi_bus;
static void atsam_spi_wakeup_task(atsam_spi_bus *bus)
@@ -91,17 +92,27 @@ static void atsam_configure_spi(atsam_spi_bus *bus)
{
uint8_t delay_cs;
uint32_t csr = 0;
+ uint32_t mode = 0;
+ uint32_t cs = bus->base.cs;
delay_cs = atsam_calculate_dlybcs(bus->base.delay_usecs);
+ mode |= SPI_MR_DLYBCS(delay_cs);
+ mode |= SPI_MR_MSTR;
+ mode |= SPI_MR_MODFDIS;
+ if (bus->chip_select_decode) {
+mode |= SPI_MR_PCS(bus->base.cs);
+mode |= SPI_MR_PCSDEC;
+cs /= 4;
+ } else {
+mode |= SPI_PCS(bus->base.cs);
+ }
+
SPID_Configure(
&bus->spi,
bus->spi.pSpiHw,
bus->spi.spiId,
-(SPI_MR_DLYBCS(delay_cs) |
- SPI_MR_MSTR |
- SPI_MR_MODFDIS |
- SPI_PCS(bus->base.cs)),
+mode,
&XDMAD_Instance
);
@@ -113,7 +124,7 @@ static void atsam_configure_spi(atsam_spi_bus *bus)
atsam_set_phase_and_polarity(bus->base.mode, &csr);
- SPI_ConfigureNPCS(bus->spi.pSpiHw, bus->base.cs, csr);
+ SPI_ConfigureNPCS(bus->spi.pSpiHw, cs, csr);
}
static void atsam_spi_start_dma_transfer(
@@ -141,7 +152,11 @@ static void atsam_spi_do_transfer(
bus->chip_select_active = true;
-SPI_ChipSelect(pSpiHw, 1 << msg->cs);
+if (bus->chip_select_decode) {
+ pSpiHw->SPI_MR = (pSpiHw->SPI_MR & ~SPI_MR_PCS_Msk) |
SPI_MR_PCS(msg->cs);
+} else {
+ SPI_ChipSelect(pSpiHw, 1 << msg->cs);
+}
SPI_Enable(pSpiHw);
}
@@ -389,10 +404,7 @@ static void atsam_spi_init_xdma(atsam_spi_bus *bus)
int spi_bus_register_atsam(
const char *bus_path,
- uint8_t spi_peripheral_id,
- Spi*spi_regs,
- const Pin *pins,
- size_t pin_count
+ const atsam_spi_config *config
)
{
atsam_spi_bus *bus;
@@ -410,11 +422,12 @@ int spi_bus_register_atsam(
bus->base.speed_hz = bus->base.max_speed_hz;
bus->base.delay_usecs = 1;
bus->base.cs = 1;
- bus->spi.spiId = spi_peripheral_id;
- bus->spi.pSpiHw = spi_regs;
+ bus->spi.spiId = config->spi_peripheral_id;
+ bus->spi.pSpiHw = config->spi_regs;
+ bus->chip_select_decode = config->chip_select_decode;
- PIO_Configure(pins, pin_count);
- PMC_EnablePeripheral(spi_peripheral_id);
+ PIO_Configure(config->pins, config->pin_count);
+ PMC_EnablePeripheral(config->spi_peripheral_id);
atsam_configure_spi(bus);
atsam_spi_init_xdma(bus);
diff --git a/c/src/lib/libbsp/arm/atsam/spi/atsam_spi_init.c
b/c/src/lib/libbsp/arm/atsam/spi/atsam_spi_init.c
index 09440f263f..ca18f8ec35 100644
--- a/c/src/lib/libbsp/arm/atsam/spi/atsam_spi_init.c
+++ b/c/src/lib/libbsp/arm/atsam/spi/atsam_spi_init.c
@@ -66,12 +66,17 @@ int atsam_register_spi_0(void)
PIN_SPI0_CLOCK
};
+ static const atsam_spi_config config = {
+.spi_peripheral_id = ID_SPI0,
+.spi_regs = SPI0,
+.pins = pins,
+.pin_count = RTEMS_ARRAY_SIZE(pins),
+.chip_select_decode = false
+ };
+
return spi_bus_register_atsam(
ATSAM_SPI_0_BUS_PATH,
-ID_SPI0,
-SPI0,
-pins,
-RTEMS_ARRAY_SIZE(pins)
+&config
);
}
@@ -90,11 +95,16 @@ int atsam_register_spi_1(void)
PIN_SPI1_CLOCK
};
+ static const atsam_spi_config config = {
+.spi_peripheral_id = ID_SPI1,
+.spi_regs = SPI1,
+.pins = pins,
+.pin_count = RTEMS_ARRAY_SIZE(pins),
+.chip_select_decode = false
+ };
+
return spi_bus_register_atsam(
ATSAM_SPI_1_BUS_PATH,
-ID_SPI1,
-SPI1,
-pins,
-RTEMS_ARRAY_SIZE(pins)
+&config
);
}
--
2.13.6
___
devel mailing list
RE: New BSP Advice
Hi RTEMS Developers, Sorry, what finally happened to STM32F BSP, after a few emails with this subject? Looking at the latest master on git.rtems.org, I see the folder "stm32f7x" exists in c\src\lib\libbsp\arm directory, but it has just a "hal" folder and its files have never been used. Best Regards, Afshin Jamaali -Original Message- From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Isaac Gutekunst Sent: Thursday, September 17, 2015 18:40 To: devel@rtems.org Subject: New BSP Advice Hey RTEMS Developers, Vecna has recently reached the final stretch of our BSP development effort for the STM32F4 and STM32F7 families of processors. We would love to contribute it back and where wondering what we should do to get that process moving. I understand many of you are busy with the 4.11 effort, and if you can't offer much help at the moment, we understand. On our end, we are performing internal peer review through the GitHub interface, and are hoping to wrap things up in about two weeks. Outstanding areas are the LWIP port which is not visible in the pull request. The in progress code is viewable here: https://github.com/vecnatechnologies/rtems/pull/4 Kind Regards, Isaac Gutekunst Embedded Systems Software Engineer isaac.guteku...@vecna.com www.vecna.com Cambridge Research Laboratory Vecna Technologies, Inc. 36 Cambridge Park Drive Cambridge, MA 02140 Office: (617) 864-0636 x3069 Fax: (617) 864-0638 http://vecna.com Better Technology, Better World (TM) ___ 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: Contribute to project
Sir, I have gone through the projects available in the link provided by you and I am interested in an issue (*RSB can sometimes change the wrong local git repository (includes a fix).*) listed there. Link: https://devel.rtems.org/ticket/2522#no1 I request you to please provide some more information regarding this so that I can proceed with the coding part. Thanks and Regards Abhinav Jain On Wed, Feb 7, 2018 at 9:12 AM, Abhinav Jain wrote: > Sir, > > Thanks a lot for the guidance. I will start with contributing to an > existing project. > > Thanks and Regards > Abhinav jain > > On Feb 6, 2018 10:55 PM, "Gedare Bloom" wrote: > >> Hello Abhinav Jain, >> >> It is good that you are studying. Now, you should pursue two paths: >> 1. Produce some code for RTEMS, perhaps by fixing a bug. A good place >> to start is the tickets on the open releases: >> https://devel.rtems.org/query?status=assigned&status=accepte >> d&status=reopened&group=status&milestone=4.11.3 >> https://devel.rtems.org/query?status=accepted&status=assigne >> d&status=new&status=reopened&milestone=4.10.3&group=status&order=priority >> >> 2. Prepare your project idea. You will want to convert your learning >> into a concrete, achievable plan for code that can be implemented in >> RTEMS and will be beneficial to someone. >> >> Gedare >> >> On Tue, Feb 6, 2018 at 10:23 AM, Abhinav Jain >> wrote: >> > Sir, >> > >> > I have studied about SASOS. It's really a great approach to make the >> process >> > faster by avoiding multiple copies of the data. I read about two SASOS >> > namely Angel system(developed at City University, London) and Mungi >> > system(developed by University of New South Wales, Australia). I also >> > studied about Memory Protection in SASOS, where the concept of address >> > protection is replaced by protection domain. I studied about >> Multithreading, >> > POSIX, Race condition and Synchronization to avoid the Race condition. >> > Please guide me, am I on the right path and what all do I need to learn >> > further? >> > >> > Thanks and Regards >> > Abhinav Jain >> > >> > On Wed, Jan 31, 2018 at 11:17 PM, Abhinav Jain >> > wrote: >> >> >> >> Sir, >> >> >> >> Thanks for the guidance. The mail is very informative and I will follow >> >> the way suggested by you. >> >> >> >> Thanks and regards >> >> Abhinav Jain >> >> >> >> On Jan 31, 2018 5:41 PM, "Sebastian Huber" >> >> wrote: >> >>> >> >>> The MMU support is a very challenging project. The scope of the >> project >> >>> and potential use cases must be determined. You need a lot of >> experience to >> >>> design good APIs and it helps if you know the APIs for this kind of >> stuff on >> >>> other systems like QNX, Linux, FreeBSD, etc. For the architecture >> support a >> >>> lot of background knowledge is required at least on PowerPC, ARMv5..8, >> >>> SPARC, Nios2, MIPS, etc. For example, changing the TLB1 based MMU >> during >> >>> application run-time on PowerPC (including SMP support, cache >> consistency) >> >>> is not easy. There are some optimization problems involved if you >> want to >> >>> determine a good cover with memory areas (alignment restrictions, >> limited >> >>> number of areas in the MMU/MPU if not page based, e.g. 16). >> >>> >> >>> -- >> >>> 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: Contribute to project
Abhinav, Attempt to reproduce the reported problem, try out the patch and see if it works. I see this was reported for 4.10. See if the problem also affects 4.11, master, and if the fix works for them too. Gedare On Mon, Feb 12, 2018 at 11:55 AM, Abhinav Jain wrote: > Sir, > > I have gone through the projects available in the link provided by you and I > am interested in an issue (RSB can sometimes change the wrong local git > repository (includes a fix).) listed there. > Link: https://devel.rtems.org/ticket/2522#no1 > I request you to please provide some more information regarding this so that > I can proceed with the coding part. > > Thanks and Regards > Abhinav Jain > > On Wed, Feb 7, 2018 at 9:12 AM, Abhinav Jain wrote: >> >> Sir, >> >> Thanks a lot for the guidance. I will start with contributing to an >> existing project. >> >> Thanks and Regards >> Abhinav jain >> >> On Feb 6, 2018 10:55 PM, "Gedare Bloom" wrote: >>> >>> Hello Abhinav Jain, >>> >>> It is good that you are studying. Now, you should pursue two paths: >>> 1. Produce some code for RTEMS, perhaps by fixing a bug. A good place >>> to start is the tickets on the open releases: >>> >>> https://devel.rtems.org/query?status=assigned&status=accepted&status=reopened&group=status&milestone=4.11.3 >>> >>> https://devel.rtems.org/query?status=accepted&status=assigned&status=new&status=reopened&milestone=4.10.3&group=status&order=priority >>> >>> 2. Prepare your project idea. You will want to convert your learning >>> into a concrete, achievable plan for code that can be implemented in >>> RTEMS and will be beneficial to someone. >>> >>> Gedare >>> >>> On Tue, Feb 6, 2018 at 10:23 AM, Abhinav Jain >>> wrote: >>> > Sir, >>> > >>> > I have studied about SASOS. It's really a great approach to make the >>> > process >>> > faster by avoiding multiple copies of the data. I read about two SASOS >>> > namely Angel system(developed at City University, London) and Mungi >>> > system(developed by University of New South Wales, Australia). I also >>> > studied about Memory Protection in SASOS, where the concept of address >>> > protection is replaced by protection domain. I studied about >>> > Multithreading, >>> > POSIX, Race condition and Synchronization to avoid the Race condition. >>> > Please guide me, am I on the right path and what all do I need to >>> > learn >>> > further? >>> > >>> > Thanks and Regards >>> > Abhinav Jain >>> > >>> > On Wed, Jan 31, 2018 at 11:17 PM, Abhinav Jain >>> > wrote: >>> >> >>> >> Sir, >>> >> >>> >> Thanks for the guidance. The mail is very informative and I will >>> >> follow >>> >> the way suggested by you. >>> >> >>> >> Thanks and regards >>> >> Abhinav Jain >>> >> >>> >> On Jan 31, 2018 5:41 PM, "Sebastian Huber" >>> >> wrote: >>> >>> >>> >>> The MMU support is a very challenging project. The scope of the >>> >>> project >>> >>> and potential use cases must be determined. You need a lot of >>> >>> experience to >>> >>> design good APIs and it helps if you know the APIs for this kind of >>> >>> stuff on >>> >>> other systems like QNX, Linux, FreeBSD, etc. For the architecture >>> >>> support a >>> >>> lot of background knowledge is required at least on PowerPC, >>> >>> ARMv5..8, >>> >>> SPARC, Nios2, MIPS, etc. For example, changing the TLB1 based MMU >>> >>> during >>> >>> application run-time on PowerPC (including SMP support, cache >>> >>> consistency) >>> >>> is not easy. There are some optimization problems involved if you >>> >>> want to >>> >>> determine a good cover with memory areas (alignment restrictions, >>> >>> limited >>> >>> number of areas in the MMU/MPU if not page based, e.g. 16). >>> >>> >>> >>> -- >>> >>> 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: Contribute to project
On 13/02/2018 06:05, Gedare Bloom wrote: > Abhinav, > > Attempt to reproduce the reported problem, try out the patch and see > if it works. I see this was reported for 4.10. See if the problem also > affects 4.11, master, and if the fix works for them too. I suspect it is common to all branches. > > On Mon, Feb 12, 2018 at 11:55 AM, Abhinav Jain wrote: >> Sir, >> >> I have gone through the projects available in the link provided by you and I >> am interested in an issue (RSB can sometimes change the wrong local git >> repository (includes a fix).) listed there. >> Link: https://devel.rtems.org/ticket/2522#no1 >> I request you to please provide some more information regarding this so that >> I can proceed with the coding part. >> As Gedare suggests take a look at the master and 4.11 branches and if present work I suggest you work on the master branch and then we can take git.py and back port to 4.11 and 4.10 by simply coping git.py to those branches. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 0/5] Improvements for atsam BSP and sc16is752 UART.
On 13/02/2018 00:39, Christian Mauderer wrote: > These patches add various improvements for the atsam BSP and for the > sc16is752 SPI UART controller. > > Regarding patch 1: Note that I have thought about an auto detection > instead of the option. But I had a board where something responded to > the oscillator so that I could initialize it despite the fact that no > crystall has been connected. So I think an auto detection would be > dangerous. I agree with this approach. Auto-detection is OK in systems with users however in embedded systems it is dangerous. I have a rule, any auto-detection requires a system level module that audits the part of a system that has auto-detection and raises any unexpected differences as errors. Auto-detection can be hard to avoid in some systems, ie PC motherboards, PCI etc. I remember back in the mid-90s working on an important system with RAM size detection where one of two static RAM chips had started to fail and the system adjusted assuming this was all the available memory so no one noticed until many many months into operation the application was reconfigured and it ran out of memory when it should not have. At the start of the project I had been asked to add the memory detection to handle different build variants of the hardware. The feature was disabled and I have not been a fan of it ever since. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Mentors and Open Projects
Any interested mentors (primary or co-mentor roles) please let me know so I can send you an invite. On Thu, Jan 4, 2018 at 10:23 AM, Christian Mauderer wrote: > > Am 04.01.2018 um 16:18 schrieb Gedare Bloom: >> Hi Christian, >> >> On Wed, Jan 3, 2018 at 3:52 PM, Christian Mauderer >> wrote: >>> - Ursprüngliche Mail - Von: "Gedare Bloom" An: "RTEMS Devel" Gesendet: Mittwoch, 3. Januar 2018 18:24:21 Betreff: GSoC Mentors and Open Projects >>> RTEMS development community: The GSoC organization application opens tomorrow. If you anticipate being able to mentor/co-mentor this summer please let me know, or if you were a mentor in the past but are not able to this year please also give me a heads up. An ounce of prevention is worth a pound of cure. If everyone could, please take a look at the Open Projects page to see if anything should be added or removed. Also, if you would like to take the time to convert one of the older open projects into a ticket, that would be greatly appreciated! Potential Mentors should especially be sure that any projects you might like to mentor exist as a ticket. https://devel.rtems.org/wiki/Developer/OpenProjects Thanks, and Happy New Year, Gedare ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel >>> >>> Hello Gedare, >>> >>> GSoC has been really been a lot of fun last time so I would be happy to be >>> a mentor again if there is an interesting proposal. >>> >>> Regarding the tickets: >>> - I added some notes and updates to the Beagle BSP ticket. >>> - Some time back I had a discussion on the mailing list (I think mainly >>> with Chris Johns) regarding two WiFi topics. Both might could be a project. >>> I've added the tickets to a new "libbsd" section in the project list in the >>> wiki. >>> >> Great! >> >>> By the way: Back when I created the tickets for WiFi I have been in a >>> hurry. So the tickets are a little simple and short. I would have liked to >>> reformat and improve the tickets at least a little. But I haven't seen a >>> possibility to change the initial text. It seems that at least the Beagle >>> Bone ticket has been changed a few times. Did I just miss the correct link >>> for changing the ticket or is there some special permission necessary to do >>> that? >>> >> There is a "Modify" permission that needs to be added. I will ask to >> get it put on your account. It is disabled by default to avoid too >> much modifications of tickets directly. >> >> -Gedare > > Hello Gedare, > > thanks for the info. If it's simpler or better for you I can also just > add all additional info as a comment. > > Regards > > Christian ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Contribute to project
Sir, Thanks for the guidance. I will study the code available and will try to resolve the issue as soon as possible. Thanks and Regards Abhinav Jain On Tue, Feb 13, 2018 at 4:47 AM, Chris Johns wrote: > On 13/02/2018 06:05, Gedare Bloom wrote: > > Abhinav, > > > > Attempt to reproduce the reported problem, try out the patch and see > > if it works. I see this was reported for 4.10. See if the problem also > > affects 4.11, master, and if the fix works for them too. > > I suspect it is common to all branches. > > > > > On Mon, Feb 12, 2018 at 11:55 AM, Abhinav Jain > wrote: > >> Sir, > >> > >> I have gone through the projects available in the link provided by you > and I > >> am interested in an issue (RSB can sometimes change the wrong local git > >> repository (includes a fix).) listed there. > >> Link: https://devel.rtems.org/ticket/2522#no1 > >> I request you to please provide some more information regarding this so > that > >> I can proceed with the coding part. > >> > > As Gedare suggests take a look at the master and 4.11 branches and if > present > work I suggest you work on the master branch and then we can take git.py > and > back port to 4.11 and 4.10 by simply coping git.py to those branches. > > Chris > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 0/5] Improvements for atsam BSP and sc16is752 UART.
Am 13.02.2018 um 00:34 schrieb Chris Johns: > On 13/02/2018 00:39, Christian Mauderer wrote: >> These patches add various improvements for the atsam BSP and for the >> sc16is752 SPI UART controller. >> >> Regarding patch 1: Note that I have thought about an auto detection >> instead of the option. But I had a board where something responded to >> the oscillator so that I could initialize it despite the fact that no >> crystall has been connected. So I think an auto detection would be >> dangerous. > > I agree with this approach. > > Auto-detection is OK in systems with users however in embedded systems it is > dangerous. I have a rule, any auto-detection requires a system level module > that > audits the part of a system that has auto-detection and raises any unexpected > differences as errors. Auto-detection can be hard to avoid in some systems, ie > PC motherboards, PCI etc. > > I remember back in the mid-90s working on an important system with RAM size > detection where one of two static RAM chips had started to fail and the system > adjusted assuming this was all the available memory so no one noticed until > many > many months into operation the application was reconfigured and it ran out of > memory when it should not have. At the start of the project I had been asked > to > add the memory detection to handle different build variants of the hardware. > The > feature was disabled and I have not been a fan of it ever since. > > Chris > Hello Chris, thanks for the support for this approach. I mostly wanted to give a reason why I thought it would be necessary to add another option to the BSP. Any other remarks regarding the patches? Can I apply them? Kind regards Christian -- 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
