Re: About scheduler entry point add_processor
Thanks for the help. On Sat, Mar 27, 2021 at 8:07 PM Gedare Bloom wrote: > On Thu, Mar 25, 2021 at 11:11 PM Richi Dubey wrote: > > > > Hi, > > > > I remember reading somewhere that the add_processor function is only > used when a processor is explicitly added during runtime of an application > :p, Is that correct?Please let me know which test tests/uses this function. > > > > cd ~/rtems/rtems/testsuites$ grep -r add_processor > smptests/smpirqs01/init.c: sc = > rtems_scheduler_add_processor(scheduler_id, 1); > smptests/smpscheduler04/init.c:sc = rtems_scheduler_add_processor( > smptests/smpscheduler04/smpscheduler04.doc: - > rtems_scheduler_add_processor() > smptests/smpthreadpin01/init.c: sc = > rtems_scheduler_add_processor(ctx->sched_b, 1); > smptests/smpscheduler02/init.c: sc = > rtems_scheduler_add_processor(scheduler_c_id, 62); > smptests/smpscheduler02/init.c: sc = > rtems_scheduler_add_processor(scheduler_c_id, 63); > smptests/smpscheduler02/init.c:sc = > rtems_scheduler_add_processor(scheduler_a_id, 1); > smptests/smpscheduler02/init.c:sc = > rtems_scheduler_add_processor(scheduler_a_id, 0); > smptests/smpscheduler02/init.c:sc = > rtems_scheduler_add_processor(scheduler_b_id, 1); > sptests/spscheduler01/init.c: sc = > rtems_scheduler_add_processor(invalid_id, 0); > sptests/spscheduler01/init.c: sc = > rtems_scheduler_add_processor(scheduler_id, 1); > sptests/spscheduler01/init.c: sc = > rtems_scheduler_add_processor(scheduler_id, 0); > > I guess you should start with one of those. > > > Thanks. > > ___ > > 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 rtems-libbsd 1/2] racoon/session: Honor file descriptor maximum
Hello Chris,
Am 28.03.21 um 04:43 schrieb Chris Johns:
On 22/3/21 7:45 pm, Christian MAUDERER wrote:
Hello Chris,
Am 19.03.21 um 02:11 schrieb Chris Johns:
On 3/3/21 7:41 pm, Christian MAUDERER wrote:
Hello Chris,
Am 03.03.21 um 02:17 schrieb Chris Johns:
On 2/3/21 7:26 pm, Christian MAUDERER wrote:
Hello Chris,
Am 02.03.21 um 01:03 schrieb Chris Johns:
On 1/3/21 7:24 pm, Christian MAUDERER wrote:
Hello Chris,
thanks for the review.
Am 26.02.21 um 19:04 schrieb Chris Johns:
On 26/2/21 2:01 am, Christian Mauderer wrote:
Dynamically allocate a big enough file descriptor set for select(). A
better solution would be to use kqueue() instead of select().
---
.../racoon/rtems-bsd-racoon-session-data.h | 6 +--
ipsec-tools/src/racoon/session.c | 40
+++
2 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/ipsec-tools/src/racoon/rtems-bsd-racoon-session-data.h
b/ipsec-tools/src/racoon/rtems-bsd-racoon-session-data.h
index b869a1518..196107a35 100644
--- a/ipsec-tools/src/racoon/rtems-bsd-racoon-session-data.h
+++ b/ipsec-tools/src/racoon/rtems-bsd-racoon-session-data.h
@@ -2,11 +2,11 @@
#include
#include "rtems-bsd-racoon-data.h"
/* session.c */
-RTEMS_LINKER_RWSET_CONTENT(bsd_prog_racoon, static fd_set active_mask);
-RTEMS_LINKER_RWSET_CONTENT(bsd_prog_racoon, static fd_set preset_mask);
+RTEMS_LINKER_RWSET_CONTENT(bsd_prog_racoon, static _types_fd_set
*allocated_active_mask);
+RTEMS_LINKER_RWSET_CONTENT(bsd_prog_racoon, static _types_fd_set
*allocated_preset_mask);
RTEMS_LINKER_RWSET_CONTENT(bsd_prog_racoon, static int nfds);
RTEMS_LINKER_RWSET_CONTENT(bsd_prog_racoon, static int signals[]);
RTEMS_LINKER_RWSET_CONTENT(bsd_prog_racoon, static sig_atomic_t
volatile
volatile sigreq[]);
-RTEMS_LINKER_RWSET_CONTENT(bsd_prog_racoon, static struct fd_monitor
fd_monitors[]);
+RTEMS_LINKER_RWSET_CONTENT(bsd_prog_racoon, static struct fd_monitor
*allocated_fd_monitors);
RTEMS_LINKER_RWSET_CONTENT(bsd_prog_racoon, static struct
fd_monitor_list
fd_monitor_tree[]);
RTEMS_LINKER_RWSET_CONTENT(bsd_prog_racoon, static struct sched
scflushsa);
diff --git a/ipsec-tools/src/racoon/session.c
b/ipsec-tools/src/racoon/session.c
index 65124c15e..90120c761 100644
--- a/ipsec-tools/src/racoon/session.c
+++ b/ipsec-tools/src/racoon/session.c
@@ -65,6 +65,10 @@
#include
#include
#include
+#ifdef __rtems__
+#include
+#include
+#endif /* __rtems__ */
#include
#include
@@ -123,8 +127,16 @@ static void check_sigreq __P((void));
static void check_flushsa __P((void));
static int close_sockets __P((void));
+#ifndef __rtems__
static fd_set preset_mask, active_mask;
static struct fd_monitor fd_monitors[FD_SETSIZE];
+#else /* __rtems__ */
+static fd_set *allocated_preset_mask, *allocated_active_mask;
+static struct fd_monitor *allocated_fd_monitors;
+#define preset_mask (*allocated_preset_mask)
+#define active_mask (*allocated_active_mask)
+#define fd_monitors (allocated_fd_monitors)
+#endif /* __rtems__ */
static TAILQ_HEAD(fd_monitor_list, fd_monitor)
fd_monitor_tree[NUM_PRIORITIES];
static int nfds = 0;
@@ -134,7 +146,11 @@ static struct sched scflushsa =
SCHED_INITIALIZER();
void
monitor_fd(int fd, int (*callback)(void *, int), void *ctx, int
priority)
{
+#ifndef __rtems__
if (fd < 0 || fd >= FD_SETSIZE) {
+#else /* __rtems__ */
+ if (fd < 0 || fd >= rtems_libio_number_iops) {
+#endif /* __rtems__ */
plog(LLV_ERROR, LOCATION, NULL, "fd_set overrun");
exit(1);
}
@@ -158,7 +174,11 @@ monitor_fd(int fd, int (*callback)(void *, int), void
*ctx, int priority)
void
unmonitor_fd(int fd)
{
+#ifndef __rtems__
if (fd < 0 || fd >= FD_SETSIZE) {
+#else /* __rtems__ */
+ if (fd < 0 || fd >= rtems_libio_number_iops) {
+#endif /* __rtems__ */
plog(LLV_ERROR, LOCATION, NULL, "fd_set overrun");
exit(1);
}
@@ -186,7 +206,22 @@ session(void)
struct fd_monitor *fdm;
nfds = 0;
+#ifndef __rtems__
FD_ZERO(&preset_mask);
+#else /* __rtems__ */
+ allocated_preset_mask = calloc(sizeof(fd_set),
+ howmany(rtems_libio_number_iops, sizeof(fd_set) * 8));
Does `maxfiles` work here?
To be honest: I'm not sure.
According to the comment in file.h:
extern int maxfiles; /* kernel limit on number of open files */
Yes.
Sounds like it _can_ be the same as the maximum file number but doesn't
have to.
I think we need to have them be the same value.
I didn't find where we implement it. It's declared as an extern int
maxfiles but
I didn't find any definition. I found it only in libbsd in
freebsd/sys/kern/uipc_socket.c where it is defined like follows:
#define maxfiles rtems_libio_number_iops
Ah OK. I knew it had been assigned somewhere and yes it looks like it is
local
to that file.
x86_64 BSP : Status Update [ticket #2898]
Hello everyone ! I wanted to know the status of the x86_64 BSP's development. Also it would be great help if someone guides me to get it running on QEMU or my x64 based laptop running legacy BIOS.(not UEFI) Regards Shashvat ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: libbsd: Backport fd_set size fixes for racoon and ping6 to 5
Hello Gedare, Am 26.03.21 um 16:03 schrieb Gedare Bloom: seems fine to me. Thanks. I just wanted to push the patches and noted that there haven't been any changes to the 5 branch of libbsd since the release. But there have been some fixes on the 5-freebsd-12 branch. Did I miss something and the 5 branch shouldn't be updated with fixes? Or have the fixes just not been applied to 5? Best regards Christian On Fri, Mar 26, 2021 at 7:14 AM Christian MAUDERER wrote: Hello, I would like to backport the following patches to 5 and 5-freebsd-12: https://git.rtems.org/rtems-libbsd/commit/?h=6-freebsd-12&id=e7fb073f3a1040847daab3ef917aeade755eb30b https://git.rtems.org/rtems-libbsd/commit/?h=6-freebsd-12&id=33e3cf8eaff0081e74593f8a91edc8e37f732430 Ticket is here: https://devel.rtems.org/ticket/4361 Is that OK? Best regards Christian -- embedded brains GmbH Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- embedded brains GmbH Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: x86_64 BSP : Status Update [ticket #2898]
Hey Shashvat! I've CC'd Chris who may have something to add given that the original ticket seems to have an update from John Millard - not sure if John's made progress since my work on the x86-64 BSP was upstreamed, so I'll let Chris speak to that. I wouldn't recommend running it on real hardware yet - I don't think anyone has tested it on hardware. Not all tests in the testsuite pass in QEMU either, from what I remember (some basic ones do), so that will likely be what you'll need to work on. To run the BSP in QEMU, you'll need to follow these instructions: https://docs.rtems.org/branches/master/user/bsps/bsps-x86_64.html Let me know if you run into any issues, since the setup can be a bit complicated. In summary, for the setup, you'll want to: - Build RTEMS/RSB with x86-64 as the BSP (this should be the same as what you did for your GSoC proof in terms of building the BSP and samples/tests) - Get QEMU - Build OVMF's open-source UEFI firmware - Get FreeBSD booting in QEMU with UEFI, and then replace it's `kernel` with a built RTEMS application (such as the ticker tests or hello.exe, etc.) - Run FreeBSD image with RTEMS app as its kernel We need to do this because for the x86-64 BSP, we use FreeBSD's bootloader. This is slightly problematic, because FreeBSD's bootloader only supports UFS/ZFS for filesystems. I think ideally, we'll want a UEFI-compatible bootloader which can support more filesystems - FreeBSD's bootloader is functional, but perhaps not the best for a dev/prod environment long-term - maybe Joel/Chris can comment on this. (For eg. most Linux systems can't mount UFS/ZFS unless specifically compiled for that support, which means the dev-environment is quite hacky and slow - I had to use the network to get my RTEMS apps into the FreeBSD filesystem for the bootloader to use it.) After the bootloader issues are made easier (so we don't need to replace FreeBSD's kernel every time we want to recompile our RTEMS app and re-run it), the next aim will probably be to make as many tests pass as possible, and to improve automated tests, such as a configuration for rtems-test[1]. I recall there being some edge-cases in the clock driver, so you'll likely have the failing tests to guide which drivers you need to work on in the BSP. If there's still time after that, I think we can figure out which specific portions need to be worked on (i.e. running on hardware, improving existing drivers, adding libbsd support, SMP support, etc.). In case you haven't seen this already, this is my blog post from my GSoC on the x86-64 BSP, summarizing the status as of then, as well as potential areas for improvement next: https://blog.whatthedude.com/post/gsoc-phase-2-status/#upcoming [1] https://docs.rtems.org/branches/master/user/tools/tester.html On Mon, Mar 29, 2021, 12:58 PM Shashvat wrote: > > Hello everyone ! > > I wanted to know the status of the x86_64 BSP's development. > Also it would be great help if someone guides me to get it running on QEMU or > my x64 based laptop running legacy BIOS.(not UEFI) > > > Regards > Shashvat > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: x86_64 BSP : Status Update [ticket #2898]
I linked the wrong GSoC status update of mine there - here's the final report that you may find useful: https://blog.whatthedude.com/post/gsoc-final/#future-to-do On Mon, Mar 29, 2021 at 3:38 PM Amaan Cheval wrote: > > Hey Shashvat! > > I've CC'd Chris who may have something to add given that the original > ticket seems to have an update from John Millard - not sure if John's > made progress since my work on the x86-64 BSP was upstreamed, so I'll > let Chris speak to that. > > I wouldn't recommend running it on real hardware yet - I don't think > anyone has tested it on hardware. > Not all tests in the testsuite pass in QEMU either, from what I > remember (some basic ones do), so that will likely be what you'll need > to work on. > > To run the BSP in QEMU, you'll need to follow these instructions: > https://docs.rtems.org/branches/master/user/bsps/bsps-x86_64.html > > Let me know if you run into any issues, since the setup can be a bit > complicated. In summary, for the setup, you'll want to: > > - Build RTEMS/RSB with x86-64 as the BSP (this should be the same as > what you did for your GSoC proof in terms of building the BSP and > samples/tests) > - Get QEMU > - Build OVMF's open-source UEFI firmware > - Get FreeBSD booting in QEMU with UEFI, and then replace it's > `kernel` with a built RTEMS application (such as the ticker tests or > hello.exe, etc.) > - Run FreeBSD image with RTEMS app as its kernel > > We need to do this because for the x86-64 BSP, we use FreeBSD's > bootloader. This is slightly problematic, because FreeBSD's bootloader > only supports UFS/ZFS for filesystems. > I think ideally, we'll want a UEFI-compatible bootloader which can > support more filesystems - FreeBSD's bootloader is functional, but > perhaps not the best for a dev/prod environment long-term - maybe > Joel/Chris can comment on this. > (For eg. most Linux systems can't mount UFS/ZFS unless specifically > compiled for that support, which means the dev-environment is quite > hacky and slow - I had to use the network to get my RTEMS apps into > the FreeBSD filesystem for the bootloader to use it.) > > After the bootloader issues are made easier (so we don't need to > replace FreeBSD's kernel every time we want to recompile our RTEMS app > and re-run it), the next aim will probably be to make as many tests > pass as possible, and to improve automated tests, such as a > configuration for rtems-test[1]. > I recall there being some edge-cases in the clock driver, so you'll > likely have the failing tests to guide which drivers you need to work > on in the BSP. > > If there's still time after that, I think we can figure out which > specific portions need to be worked on (i.e. running on hardware, > improving existing drivers, adding libbsd support, SMP support, etc.). > > In case you haven't seen this already, this is my blog post from my > GSoC on the x86-64 BSP, summarizing the status as of then, as well as > potential areas for improvement next: > https://blog.whatthedude.com/post/gsoc-phase-2-status/#upcoming > > [1] https://docs.rtems.org/branches/master/user/tools/tester.html > > On Mon, Mar 29, 2021, 12:58 PM Shashvat wrote: > > > > Hello everyone ! > > > > I wanted to know the status of the x86_64 BSP's development. > > Also it would be great help if someone guides me to get it running on QEMU > > or my x64 based laptop running legacy BIOS.(not UEFI) > > > > > > Regards > > Shashvat > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Basic lwIP for STM32H7 BSP
I solved it like you mentioned now by putting the descriptors in the
.bsp_no_cache section and with the correct alignment.
/* Put into special RTEMS section and align correctly */
ETH_DMADescTypeDef DMARxDscrTab[ETH_RX_DESC_CNT]
__attribute__((section(".bsp_nocache"),
__aligned__(DMA_DESCRIPTOR_ALIGNMENT)));
/* Put into special RTEMS section and align correctly */
ETH_DMADescTypeDef DMATxDscrTab[ETH_TX_DESC_CNT]
__attribute__((section(".bsp_nocache"),
__aligned__(DMA_DESCRIPTOR_ALIGNMENT)));
uint8_t Rx_Buff[ETH_RX_DESC_CNT][ETH_RX_BUFFER_SIZE];
I will update the patch I sent with the sections removed from linccmd.base
. Maybe it still would be a better idea to have a separate BSP for the
STm32H743ZIT6-Nucleo but I would have to look into how to do this again.
Kind Regards
Robin
On Fri, 26 Mar 2021 at 15:24, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
>
> On 26/03/2021 11:34, Robin Müller wrote:
> > How would you define a generic linker section? I tried to put the
> > following section into the
> > linkcmdsmemory file like you suggested (at
> > spec/build/bsps/arm/stm32h7/linkcmdsmemory.yml):
> >
> > SECTIONS {
> > .stm32h7_sram_3 (NOLOAD) : ALIGN_WITH_INPUT {
> > bsp_stm32h7_sram_3_start = stm32h7_memory_sram_3_begin;
> > bsp_stm32h7_sram_3_end = stm32h7_memory_sram_3_end;
> > } > SRAM_3 AT > FLASH
> > }
>
> This should work. You need also input sections for this output section.
> I still don't know why you can't use the already existing:
>
> .nocache : ALIGN_WITH_INPUT {
> bsp_section_nocache_begin = .;
> *(SORT_BY_ALIGNMENT (SORT_BY_NAME (.bsp_nocache*)))
> bsp_section_nocache_end = .;
> } > REGION_NOCACHE AT > REGION_NOCACHE_LOAD
> bsp_section_nocache_size = bsp_section_nocache_end -
> bsp_section_nocache_begin;
> bsp_section_nocache_load_begin = LOADADDR (.nocache);
> bsp_section_nocache_load_end = bsp_section_nocache_load_begin +
> bsp_section_nocache_size;
>
> .nocachenoload (NOLOAD) : ALIGN_WITH_INPUT {
> bsp_section_nocachenoload_begin = .;
> *(SORT_BY_ALIGNMENT (SORT_BY_NAME (.bsp_noload_nocache*)))
> bsp_section_nocacheheap_begin = .;
> . += ORIGIN (REGION_NOCACHE) + LENGTH (REGION_NOCACHE) -
> ABSOLUTE (.);
> bsp_section_nocacheheap_end = .;
> bsp_section_nocachenoload_end = .;
> } > REGION_NOCACHE AT > REGION_NOCACHE
> bsp_section_nocacheheap_size = bsp_section_nocacheheap_end -
> bsp_section_nocacheheap_begin;
> bsp_section_nocachenoload_size = bsp_section_nocachenoload_end -
> bsp_section_nocachenoload_begin;
>
> For the stm32h7 these regions are used:
>
>REGION_ALIAS ("REGION_NOCACHE", SRAM_1);
>REGION_ALIAS ("REGION_NOCACHE_LOAD", SDRAM_1);
>
> >
> > But the waf build fails with a syntax error:
> >
> > [1610/1611] Linking build/arm/stm32h7/testsuites/samples/ticker.exe
> > [1611/1611] Linking build/arm/stm32h7/testsuites/samples/unlimited.exe
> >
> c:/users/robin/rtems/rtems-tools/rtems/6/bin/../lib/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/ld.exe:linkcmds.memory:84:
>
> > syntax error
> > collect2.exe: error: ld returned 1 exit status
> >
> >
> c:/users/robin/rtems/rtems-tools/rtems/6/bin/../lib/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/ld.exe:linkcmds.memory:84:
>
> > syntax error
> > collect2.exe: error: ld returned 1 exit status
> What is around line 84?
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax: +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] STM32H743ZI Nucleo and basic lwIP support
This patch adds support for the STM32H743ZI-Nucleo board
variation. This currently works by setting the STM32H743ZI_NUCLEO
flag in the config.ini flag
It also adds basic lwIP support which can be enabled
with the flag STM32H7_ADD_LWIP. This enables certain functionalities
required for lwIP to work properly
This patch also changes the default implementation
of HAL_GetTick to return the system tick by forwarding the call
to the respective RTEMS function.
---
bsps/arm/stm32h7/console/console-usart3-cfg.c | 21
bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c | 16 -
.../stm32h7/include/Legacy/stm32_hal_legacy.h | 4 +++-
bsps/arm/stm32h7/include/stm32h7xx_hal_conf.h | 11 -
bsps/arm/stm32h7/include/stm32h7xx_hal_uart.h | 1 +
bsps/arm/stm32h7/start/bspstart.c | 2 +-
bsps/arm/stm32h7/start/stm32h7-hal-eth.c | 3 +--
spec/build/bsps/arm/stm32h7/bspstm32h7.yml| 4
spec/build/bsps/arm/stm32h7/opth743nucleo.yml | 13 ++
spec/build/bsps/arm/stm32h7/optlwip.yml | 24 +++
10 files changed, 88 insertions(+), 11 deletions(-)
create mode 100644 spec/build/bsps/arm/stm32h7/opth743nucleo.yml
create mode 100644 spec/build/bsps/arm/stm32h7/optlwip.yml
diff --git a/bsps/arm/stm32h7/console/console-usart3-cfg.c
b/bsps/arm/stm32h7/console/console-usart3-cfg.c
index b40f6da5aa..dc552610e1 100644
--- a/bsps/arm/stm32h7/console/console-usart3-cfg.c
+++ b/bsps/arm/stm32h7/console/console-usart3-cfg.c
@@ -25,12 +25,32 @@
* POSSIBILITY OF SUCH DAMAGE.
*/
+#ifdef __rtems__
+#include
+#endif
+
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#include
+#if STM32H743ZI_NUCLEO == 1
+const stm32h7_uart_config stm32h7_usart3_config = {
+ .gpio = {
+.regs = GPIOD,
+.config = {
+ .Pin = GPIO_PIN_8 | GPIO_PIN_9,
+ .Mode = GPIO_MODE_AF_PP,
+ .Pull = GPIO_NOPULL,
+ .Speed = GPIO_SPEED_FREQ_LOW,
+ .Alternate = GPIO_AF7_USART3
+}
+ },
+ .irq = USART3_IRQn,
+ .device_index = 2
+};
+#else
const stm32h7_uart_config stm32h7_usart3_config = {
.gpio = {
.regs = GPIOB,
@@ -45,3 +65,4 @@ const stm32h7_uart_config stm32h7_usart3_config = {
.irq = USART3_IRQn,
.device_index = 2
};
+#endif /* STM32H743ZI_NUCLEO == 1 */
diff --git a/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
b/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
index 4f2634df5b..6c3590bce8 100644
--- a/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
+++ b/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
@@ -146,6 +146,10 @@
/* Includes
--*/
#include "stm32h7xx_hal.h"
+#ifdef __rtems__
+#include
+#endif
+
/** @addtogroup STM32H7xx_HAL_Driver
* @{
*/
@@ -361,10 +365,10 @@ HAL_StatusTypeDef HAL_ETH_Init(ETH_HandleTypeDef *heth)
/*-- MAC, MTL and DMA default Configuration
*/
ETH_MACDMAConfig(heth);
-#ifndef __rtems__
+#if STM32H7_ADD_LWIP == 1
/* SET DSL to 64 bit */
MODIFY_REG(heth->Instance->DMACCR, ETH_DMACCR_DSL, ETH_DMACCR_DSL_64BIT);
-#endif /* __rtems__ */
+#endif
/* Set Receive Buffers Length (must be a multiple of 4) */
if ((heth->Init.RxBuffLen % 0x4U) != 0x0U)
@@ -2647,7 +2651,7 @@ static void ETH_MAC_MDIO_ClkConfig(ETH_HandleTypeDef
*heth)
*/
static void ETH_DMATxDescListInit(ETH_HandleTypeDef *heth)
{
-#ifndef __rtems__
+#if STM32H7_ADD_LWIP == 1
ETH_DMADescTypeDef *dmatxdesc;
uint32_t i;
@@ -2674,7 +2678,7 @@ static void ETH_DMATxDescListInit(ETH_HandleTypeDef *heth)
/* Set Transmit Descriptor Tail pointer */
WRITE_REG(heth->Instance->DMACTDTPR, (uint32_t) heth->Init.TxDesc);
-#endif /* __rtems__ */
+#endif /* STM32H7_ADD_LWIP == 1 */
}
/**
@@ -2686,7 +2690,7 @@ static void ETH_DMATxDescListInit(ETH_HandleTypeDef *heth)
*/
static void ETH_DMARxDescListInit(ETH_HandleTypeDef *heth)
{
-#ifndef __rtems__
+#if STM32H7_ADD_LWIP == 1
ETH_DMADescTypeDef *dmarxdesc;
uint32_t i;
@@ -2719,7 +2723,7 @@ static void ETH_DMARxDescListInit(ETH_HandleTypeDef *heth)
/* Set Receive Descriptor Tail pointer Address */
WRITE_REG(heth->Instance->DMACRDTPR, ((uint32_t)(heth->Init.RxDesc +
(((uint32_t)(ETH_RX_DESC_CNT - 1))*sizeof(ETH_DMADescTypeDef);
-#endif /* __rtems__ */
+#endif /* STM32H7_ADD_LWIP == 1 */
}
/**
diff --git a/bsps/arm/stm32h7/include/Legacy/stm32_hal_legacy.h
b/bsps/arm/stm32h7/include/Legacy/stm32_hal_legacy.h
index c311c1618e..c4fa5d7151 100644
--- a/bsps/arm/stm32h7/include/Legacy/stm32_hal_legacy.h
+++ b/bsps/arm/stm32h7/include/Legacy/stm32_hal_legacy.h
@@ -420,7 +420,9 @@
#define TYPEPROGRAMDATA_FASTBYTE FLASH_TYPEPROGRAMDATA_FASTBYTE
#define TYPEPROGRAMDATA_FASTHALFWORD FLASH_TYPEPROGRAMDATA_FASTHALFWORD
#define TYPEPROGRAMDATA_FASTWORD FLASH_TYPEPROGRAMDATA_FASTWORD
-#define PAGESIZE FLASH_PAGE_SIZE
+/* Commented out for the RTEMS BSP because there can be nameclashes with
another
+similar defininition in limi
Re: x86_64 BSP : Status Update [ticket #2898]
On 3/29/21 12:08 PM, Amaan Cheval wrote: > I wouldn't recommend running it on real hardware yet - I don't think > anyone has tested it on hardware. I did and reported to the mailing list. Generally speaking works on some systems (both demos: hello/ticker) and another it causes general protection fault on an attempt to disable legacy interrupt controller. Advice on osdev was that using 1GB pages may be problematic so I should switch to 2M pages at least for test. Still slacking on this one as I'm overloaded in real life. > Not all tests in the testsuite pass in QEMU either, from what I > remember (some basic ones do), so that will likely be what you'll need > to work on. > > To run the BSP in QEMU, you'll need to follow these instructions: > https://docs.rtems.org/branches/master/user/bsps/bsps-x86_64.html > > Let me know if you run into any issues, since the setup can be a bit > complicated. In summary, for the setup, you'll want to: > > - Build RTEMS/RSB with x86-64 as the BSP (this should be the same as > what you did for your GSoC proof in terms of building the BSP and > samples/tests) > - Get QEMU > - Build OVMF's open-source UEFI firmware > - Get FreeBSD booting in QEMU with UEFI, and then replace it's > `kernel` with a built RTEMS application (such as the ticker tests or > hello.exe, etc.) > - Run FreeBSD image with RTEMS app as its kernel Or! Install VirtualBox, install FreeBSD into it but before it make sure you tick/switch on UEFI box and then install. Once done you do have FBSD working in UEFI environment. The advice on replacing kernel is not needed as you can select rtems binary dynamically from the bootloader command line. Simply: boot to boot loader and hit '3' to get into boot loader prompt then type: boot and hit ENTER key and it'll boot, e.g.: boot /boot/rtems/hello.exe works here. > We need to do this because for the x86-64 BSP, we use FreeBSD's > bootloader. This is slightly problematic, because FreeBSD's bootloader > only supports UFS/ZFS for filesystems. > I think ideally, we'll want a UEFI-compatible bootloader which can > support more filesystems - FreeBSD's bootloader is functional, but > perhaps not the best for a dev/prod environment long-term - maybe > Joel/Chris can comment on this. This is quite personal note, it basically depends where you develop. If in FreeBSD, then its boot loader is best option since you only need to copy rtems binary into /boot somewhere and reboot for test. Anyway, I've tested also bootboot but this has not worked well e.g. not at all. GRUB probably requires multiboot support which is a step back from UEFI. I have multiboot bits done here but not tested as I've moved to real UEFI work later. I've also investigated compiling RTEMS binary directly into PE+ but this requires PIC for all code (which Chris does not like and which may be a bit problematic -- e.g. asm needs to be fixed in some places). You have written somewhere that you have been able to do that, but I was not able to duplicate your success with it. So I think the best option is to use current freebsd bootloader for now and then perhaps test other real UEFI/64bit loaders (slimboot comes to mind). If not satisfied then write own wrapper/boot loader support which will be compiled together with rtems app and it'll then relocate its ELF code properly and boot. Zephyr provides some python code for generating such wrapper. https://github.com/zephyrproject-rtos/zephyr/tree/master/arch/x86/zefi Note: if would be fantastic if RTEMS have the capability to call UEFI so it would be best if bootloader does not call ExitBootServices() before booting RTEMS. Well if it does, then still calling UEFI is nice to have to for example: - grab resolution and address of framebuffer -- which is way much better than VESA fb in pc386 BSP IMHO. - grab IP address from possible network boot - set/check for nvram values. > If there's still time after that, I think we can figure out which > specific portions need to be worked on (i.e. running on hardware, > improving existing drivers, adding libbsd support, SMP support, etc.). I think the issue summary summs that very well. What we need for working amd64 support is we need to grab required ACPI regs/tables to get memory ranges and APICs configuration details, better paging (e.g. hopefully 2M below 4G and then 1GB pages on top of that? -- depends on experiment above), LoAPIC/APIC support in minimum but rather MSI(-X) where supported. Use available bsd code as much as possible... Note: I spent some time in FBSD code, I'm most interested in passing r/xsdt + UEFI addr from fbsd loader to RTEMS app due to a need to grab right memory map and UEFI fb addr/resolution. I've seen a lot there, but so far not materialized any code for it -- especially since fbsd boot loader is a bit complex due to a need of supporting loadable modules (besides kernel). Thanks, Karel ___ devel mailing list devel@rtems.org http://lists.rtems.
Re: Two Resource Leaks
https://docs.google.com/spreadsheets/d/12FkAE6Wvo0dDw9D75p-w8UISc8_aOKQqntvruGGdeN4/edit#gid=0 This sheet has rtems-test result comparisons between different SMP schedulers set as default schedulers and has results from last the 2 months. This might be of help to you. On Sat, Mar 27, 2021 at 9:50 PM Joel Sherrill wrote: > > > On Sat, Mar 27, 2021, 11:07 AM Sebastian Huber < > sebastian.hu...@embedded-brains.de> wrote: > >> On 27/03/2021 16:08, Joel Sherrill wrote: >> >> > The issue I found is different and won't happen on every target or >> > bsp. >> > >> > Psim has 6-9 failures even after freeing the right stack address. >> > >> > >> > The stack address and now (I think) size saved for later use are wrong >> > and this leads to multiple failures. >> I work on a fix. psim seems to be a good platform for these tests. >> > > I put a patch for the address issue but I think the fundamental issue is > you changed the semantics of what was stored in the stack structure. You > probably want a different approach but this is at least a good > temporary fix. > > And something different on Libbsd. But not sure. > > I think Richi has raised the issue that there are some recently introduced > failures. Not sure how many are this. > >> >> -- >> embedded brains GmbH >> Herr Sebastian HUBER >> Dornierstr. 4 >> 82178 Puchheim >> Germany >> email: sebastian.hu...@embedded-brains.de >> phone: +49-89-18 94 741 - 16 >> fax: +49-89-18 94 741 - 08 >> >> Registergericht: Amtsgericht München >> Registernummer: HRB 157899 >> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler >> Unsere Datenschutzerklärung finden Sie hier: >> https://embedded-brains.de/datenschutzerklaerung/ >> >> ___ > 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: Two Resource Leaks
On Mon, Mar 29, 2021 at 7:56 AM Richi Dubey wrote: > > https://docs.google.com/spreadsheets/d/12FkAE6Wvo0dDw9D75p-w8UISc8_aOKQqntvruGGdeN4/edit#gid=0 > > This sheet has rtems-test result comparisons between different SMP > schedulers set as default schedulers and has results from last the 2 > months. This might be of help to you. > Thanks! Which BSP? I ran mips/jmr3904 yesterday and need to look at all those results. It is one of my favorite BSPs to test on because it has no valid addresses between 0x0 and 0x7fff. That tends to catch any random writes. It has ~14 failiures now. > > On Sat, Mar 27, 2021 at 9:50 PM Joel Sherrill wrote: > >> >> >> On Sat, Mar 27, 2021, 11:07 AM Sebastian Huber < >> sebastian.hu...@embedded-brains.de> wrote: >> >>> On 27/03/2021 16:08, Joel Sherrill wrote: >>> >>> > The issue I found is different and won't happen on every target or >>> > bsp. >>> > >>> > Psim has 6-9 failures even after freeing the right stack address. >>> > >>> > >>> > The stack address and now (I think) size saved for later use are wrong >>> > and this leads to multiple failures. >>> I work on a fix. psim seems to be a good platform for these tests. >>> >> >> I put a patch for the address issue but I think the fundamental issue is >> you changed the semantics of what was stored in the stack structure. You >> probably want a different approach but this is at least a good >> temporary fix. >> >> And something different on Libbsd. But not sure. >> >> I think Richi has raised the issue that there are some recently >> introduced failures. Not sure how many are this. >> >>> >>> -- >>> embedded brains GmbH >>> Herr Sebastian HUBER >>> Dornierstr. 4 >>> 82178 Puchheim >>> Germany >>> email: sebastian.hu...@embedded-brains.de >>> phone: +49-89-18 94 741 - 16 >>> fax: +49-89-18 94 741 - 08 >>> >>> Registergericht: Amtsgericht München >>> Registernummer: HRB 157899 >>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler >>> Unsere Datenschutzerklärung finden Sie hier: >>> https://embedded-brains.de/datenschutzerklaerung/ >>> >>> ___ >> 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: x86_64 BSP : Status Update [ticket #2898]
On 3/29/21 2:41 PM, Karel Gardas wrote: > Or! Install VirtualBox, install FreeBSD into it but before it make sure > you tick/switch on UEFI box and then install. Once done you do have FBSD > working in UEFI environment. One very important bit! You also need to tick/switch-on PAE support box. Without it, VBox would assert/crash on RTEMS execution. Please note: VBox allows you to configure serial port and you can forward its output to the file -- so you are able to see output of the RTEMS app running there... Karel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: #3860 - GSoC enquiries
Hello, Please do you mind telling me how to run uncrustify with the given configuration with any sample file? I'm a bit stuck. Thanks, Ida. On Wed, Mar 17, 2021 at 10:34 PM Gedare Bloom wrote: > On Wed, Mar 17, 2021 at 2:28 PM Ida Delphine wrote: > > > > Hello, > > So I have gone through this configuration file and I think I'm getting > it. However I'm a bit lost in the reading the messages in the thread. Do > you mind explaining? Or we can start talking about a way forward. > > Also can you help me with some steps on how to test this by myself if > possible? > > > > It may be easier if you go "up" a level to see the full thread > context: > https://lists.rtems.org/pipermail/devel/2020-October/thread.html#62769 > Then you can go through the messages non-linearly. Right now, the > basic idea is to follow the steps outlined in the open project ticket. > I think Christian has summarized it nicely in his recent email [1]: "I > think the contributions from this project that would add value would > be: > 1. Finding a tool and a configuration that can do an RTEMS style or an > acceptable close one. > 2. Adding a "check-style" target to our build system. > 3. Maybe add some kind of script similar to Linux "checkpatch.pl" that > could check whether patches would need changes _before_ they are > applied. > " > > The proposal preparation phase should work through identifying the > options and pros/cons for different tools while preparing a plan for > how to integrate style checks in 2, 3 and thinking through the coding > tasks for the summer. > > Getting the style checking tool's configuration to match with the > RTEMS style will be some effort, and testing it out and submitting > some patches based on it could be a good proposal activity also to > build some confidence about the tools that will be used. > > We also have some Python style guidelines that might be worth > addressing. Those are harder maybe, since the style refactoring might > be challenging to review for correctness. > > For getting started, I would recommend that you try running uncrustify > with the given configuration on some files in RTEMS, see what it > results in. Play around. > > [1] https://lists.rtems.org/pipermail/devel/2021-March/065547.html > > -Gedare > > > Thanks, > > Ida > > > > On Mon, Mar 15, 2021 at 9:39 PM Gedare Bloom wrote: > >> > >> See the related thread, and we'll have to discuss how to move forward. > >> The existing approach provides an uncrustify script: > >> https://lists.rtems.org/pipermail/devel/2020-October/062769.html > >> > >> > >> On Sun, Mar 14, 2021 at 9:47 PM Ida Delphine wrote: > >> > > >> > Hello everyone, > >> > This ticket(https://devel.rtems.org/ticket/3860) was proposed to me > and I'm interested in it for GSoC. > >> > The first task there is to find a code checker or formater that can > produce results that match the RTEMS coding conventions. It also made > mention some tools have been discussed in the past. Please I will love > suggestions on possible tools I could use to achieve this. > >> > > >> > > >> > Cheers, > >> > Ida. > >> > ___ > >> > 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: x86_64 BSP : Status Update [ticket #2898]
On 3/29/21 2:41 PM, Karel Gardas wrote: > On 3/29/21 12:08 PM, Amaan Cheval wrote: >> I wouldn't recommend running it on real hardware yet - I don't think >> anyone has tested it on hardware. > > I did and reported to the mailing list. Generally speaking works on some > systems (both demos: hello/ticker) and another it causes general > protection fault on an attempt to disable legacy interrupt controller. My original report is here: https://lists.rtems.org/pipermail/devel/2020-December/063878.html ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: #3860 - GSoC enquiries
Hi Ida, On Mon, Mar 29, 2021 at 7:36 AM Ida Delphine wrote: > > Hello, > Please do you mind telling me how to run uncrustify with the given > configuration with any sample file? What have you tried? Any directions followed/attempted or notes that you have taken would be helpful. I guess all the info that you should need is in Uncrustify's readme file. https://github.com/uncrustify/uncrustify Did you successfully compile uncrustify tool? > I'm a bit stuck. > > Thanks, > Ida. > > On Wed, Mar 17, 2021 at 10:34 PM Gedare Bloom wrote: >> >> On Wed, Mar 17, 2021 at 2:28 PM Ida Delphine wrote: >> > >> > Hello, >> > So I have gone through this configuration file and I think I'm getting it. >> > However I'm a bit lost in the reading the messages in the thread. Do you >> > mind explaining? Or we can start talking about a way forward. >> > Also can you help me with some steps on how to test this by myself if >> > possible? >> > >> >> It may be easier if you go "up" a level to see the full thread >> context: >> https://lists.rtems.org/pipermail/devel/2020-October/thread.html#62769 >> Then you can go through the messages non-linearly. Right now, the >> basic idea is to follow the steps outlined in the open project ticket. >> I think Christian has summarized it nicely in his recent email [1]: "I >> think the contributions from this project that would add value would >> be: >> 1. Finding a tool and a configuration that can do an RTEMS style or an >> acceptable close one. >> 2. Adding a "check-style" target to our build system. >> 3. Maybe add some kind of script similar to Linux "checkpatch.pl" that >> could check whether patches would need changes _before_ they are >> applied. >> " >> >> The proposal preparation phase should work through identifying the >> options and pros/cons for different tools while preparing a plan for >> how to integrate style checks in 2, 3 and thinking through the coding >> tasks for the summer. >> >> Getting the style checking tool's configuration to match with the >> RTEMS style will be some effort, and testing it out and submitting >> some patches based on it could be a good proposal activity also to >> build some confidence about the tools that will be used. >> >> We also have some Python style guidelines that might be worth >> addressing. Those are harder maybe, since the style refactoring might >> be challenging to review for correctness. >> >> For getting started, I would recommend that you try running uncrustify >> with the given configuration on some files in RTEMS, see what it >> results in. Play around. >> >> [1] https://lists.rtems.org/pipermail/devel/2021-March/065547.html >> >> -Gedare >> >> > Thanks, >> > Ida >> > >> > On Mon, Mar 15, 2021 at 9:39 PM Gedare Bloom wrote: >> >> >> >> See the related thread, and we'll have to discuss how to move forward. >> >> The existing approach provides an uncrustify script: >> >> https://lists.rtems.org/pipermail/devel/2020-October/062769.html >> >> >> >> >> >> On Sun, Mar 14, 2021 at 9:47 PM Ida Delphine wrote: >> >> > >> >> > Hello everyone, >> >> > This ticket(https://devel.rtems.org/ticket/3860) was proposed to me and >> >> > I'm interested in it for GSoC. >> >> > The first task there is to find a code checker or formater that can >> >> > produce results that match the RTEMS coding conventions. It also made >> >> > mention some tools have been discussed in the past. Please I will love >> >> > suggestions on possible tools I could use to achieve this. >> >> > >> >> > >> >> > Cheers, >> >> > Ida. >> >> > ___ >> >> > 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: libbsd: Backport fd_set size fixes for racoon and ping6 to 5
On Mon, Mar 29, 2021 at 1:31 AM Christian MAUDERER wrote: > > Hello Gedare, > > Am 26.03.21 um 16:03 schrieb Gedare Bloom: > > seems fine to me. > > Thanks. > > I just wanted to push the patches and noted that there haven't been any > changes to the 5 branch of libbsd since the release. But there have been > some fixes on the 5-freebsd-12 branch. Did I miss something and the 5 > branch shouldn't be updated with fixes? Or have the fixes just not been > applied to 5? > I don't use libbsd enough to remember what is the agreed-upon protocol for its branches. I recall there is some confusing parts about how some branches track freebsd's head, while others track some freebsd branches. I guess, when we release a version of rtems, we need to freeze on a commit/point of freebsd? > Best regards > > Christian > > > > > On Fri, Mar 26, 2021 at 7:14 AM Christian MAUDERER > > wrote: > >> > >> Hello, > >> > >> I would like to backport the following patches to 5 and 5-freebsd-12: > >> > >> https://git.rtems.org/rtems-libbsd/commit/?h=6-freebsd-12&id=e7fb073f3a1040847daab3ef917aeade755eb30b > >> https://git.rtems.org/rtems-libbsd/commit/?h=6-freebsd-12&id=33e3cf8eaff0081e74593f8a91edc8e37f732430 > >> > >> Ticket is here: > >> > >> https://devel.rtems.org/ticket/4361 > >> > >> Is that OK? > >> > >> Best regards > >> > >> Christian > >> -- > >> > >> embedded brains GmbH > >> Herr Christian MAUDERER > >> Dornierstr. 4 > >> 82178 Puchheim > >> Germany > >> email: christian.maude...@embedded-brains.de > >> phone: +49-89-18 94 741 - 18 > >> fax: +49-89-18 94 741 - 08 > >> > >> Registergericht: Amtsgericht München > >> Registernummer: HRB 157899 > >> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler > >> Unsere Datenschutzerklärung finden Sie hier: > >> https://embedded-brains.de/datenschutzerklaerung/ > >> ___ > >> devel mailing list > >> devel@rtems.org > >> http://lists.rtems.org/mailman/listinfo/devel > > -- > > embedded brains GmbH > Herr Christian MAUDERER > Dornierstr. 4 > 82178 Puchheim > Germany > email: christian.maude...@embedded-brains.de > phone: +49-89-18 94 741 - 18 > fax: +49-89-18 94 741 - 08 > > Registergericht: Amtsgericht München > Registernummer: HRB 157899 > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler > Unsere Datenschutzerklärung finden Sie hier: > https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Ticket#3889 updated
On Sun, Mar 28, 2021 at 1:26 PM zack_on_the_speed_chanel wrote: > > Hello all, > > I'm updating on what' i've found out with the issue (forgot to reply all) . > Joel recommended me check the coverage for the leon BSP( to check if it's > supported) and i found that the branch with CLOCK_MONOTONIC was not reached > I think now that it's supported (because the annotated assembly is in the > sparc instruction set). I also found out that the test would be similar to > Psxclock02 and it runs the same tests on a different clock. Then I tried to > build the psxclock02 test , change the create_clock to have the > clock_monotonic argument and i didn't see the executable or any change in the > ./waf build. Then I was suggested that you have to enable all tests some how? > How do i enable all tests? > Do you use something like: ./waf bsp_defaults ---rtems-bsp=leon3 > config.ini Then, take a look, BUILD_TESTS and BUILD_PSXTESTS are two options that if either is True it should build psxclock02. When you write code, you should first make sure you can build the code as it exists if it is supposed to work, and run it to see that it works. Then you should make changes from a working baseline. Otherwise when you get a problem, how do you know if the problem is your problem, or it already existed? > Thanks > Zack > > ___ > 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: libbsd: Backport fd_set size fixes for racoon and ping6 to 5
Hello Gedare, Am 29.03.21 um 16:40 schrieb Gedare Bloom: On Mon, Mar 29, 2021 at 1:31 AM Christian MAUDERER wrote: Hello Gedare, Am 26.03.21 um 16:03 schrieb Gedare Bloom: seems fine to me. Thanks. I just wanted to push the patches and noted that there haven't been any changes to the 5 branch of libbsd since the release. But there have been some fixes on the 5-freebsd-12 branch. Did I miss something and the 5 branch shouldn't be updated with fixes? Or have the fixes just not been applied to 5? I don't use libbsd enough to remember what is the agreed-upon protocol for its branches. I recall there is some confusing parts about how some branches track freebsd's head, while others track some freebsd branches. I guess, when we release a version of rtems, we need to freeze on a commit/point of freebsd? Basically there is the master (or 5) branch which tracks FreeBSD master and the *-freebsd-12 branch which tracks the FreeBSD stable release. I would suggest everyone who want's to use libbsd in a productive environment to use the *-freebsd-12. But I'm not sure what our post-release-policy for the branches is. From the current commits on the branches it seems to be: Don't touch 5 and only fix stuff on 5-freebsd-12. But I'm still not sure. Best regards Christian Best regards Christian On Fri, Mar 26, 2021 at 7:14 AM Christian MAUDERER wrote: Hello, I would like to backport the following patches to 5 and 5-freebsd-12: https://git.rtems.org/rtems-libbsd/commit/?h=6-freebsd-12&id=e7fb073f3a1040847daab3ef917aeade755eb30b https://git.rtems.org/rtems-libbsd/commit/?h=6-freebsd-12&id=33e3cf8eaff0081e74593f8a91edc8e37f732430 Ticket is here: https://devel.rtems.org/ticket/4361 Is that OK? Best regards Christian -- embedded brains GmbH Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- embedded brains GmbH Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ -- embedded brains GmbH Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC : Ticket#3892
Hello Umang Gupta, On Sun, Mar 28, 2021 at 2:57 PM UMANG GUPTA wrote: > > hello everyone , > > My name is Umang Gupta , i wanted to participate in GSOC'21 with RTEMS i > would like to work on the ticket #3892 : RTEMS python standardization > project. Plz guide me about this > project . As indicated [1], please complete the GSoC Getting Started tutorial we have created: [1] https://devel.rtems.org/wiki/GSoC [2] https://devel.rtems.org/wiki/GSoC/GettingStarted We'll be glad to discuss potential projects. I think this one is actually not available during this year. If you are drawn to Python projects though, there are other Testing and Development Ecosystem projects that involve Python that you could look into. > Thank you > ___ > 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 : Ticket#3892
Hello Umang Gupta, welcome to RTEMS. Also #3892 is a pure python project, I think you'll need a running RTEMS environment for that to test the tools. So please start with the "GSoC Getting Started" guide that is linked in the wiki page: https://devel.rtems.org/wiki/GSoC and https://devel.rtems.org/wiki/GSoC/GettingStarted Best regards Christian Am 28.03.21 um 22:57 schrieb UMANG GUPTA: hello everyone , My name is Umang Gupta , i wanted to participate in GSOC'21 with RTEMS i would like to work on the ticket #3892 : RTEMS python standardization project. Plz guide me about this project . Thank you ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- embedded brains GmbH Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: libbsd: Backport fd_set size fixes for racoon and ping6 to 5
On Mon, Mar 29, 2021 at 8:47 AM Christian MAUDERER wrote: > > Hello Gedare, > > Am 29.03.21 um 16:40 schrieb Gedare Bloom: > > On Mon, Mar 29, 2021 at 1:31 AM Christian MAUDERER > > wrote: > >> > >> Hello Gedare, > >> > >> Am 26.03.21 um 16:03 schrieb Gedare Bloom: > >>> seems fine to me. > >> > >> Thanks. > >> > >> I just wanted to push the patches and noted that there haven't been any > >> changes to the 5 branch of libbsd since the release. But there have been > >> some fixes on the 5-freebsd-12 branch. Did I miss something and the 5 > >> branch shouldn't be updated with fixes? Or have the fixes just not been > >> applied to 5? > >> > > I don't use libbsd enough to remember what is the agreed-upon protocol > > for its branches. I recall there is some confusing parts about how > > some branches track freebsd's head, while others track some freebsd > > branches. I guess, when we release a version of rtems, we need to > > freeze on a commit/point of freebsd? > > Basically there is the master (or 5) branch which tracks FreeBSD master > and the *-freebsd-12 branch which tracks the FreeBSD stable release. I > would suggest everyone who want's to use libbsd in a productive > environment to use the *-freebsd-12. > > But I'm not sure what our post-release-policy for the branches is. From > the current commits on the branches it seems to be: Don't touch 5 and > only fix stuff on 5-freebsd-12. But I'm still not sure. > If we don't have a policy, then we should define one. My inclination here is that we should either abandon the 5/ tracking the upstream master after a release. Possibly, we should name the recommended version to use with rtems5 as 5/ though, to make life a bit more consistent across our repos. > Best regards > > Christian > > > > >> Best regards > >> > >> Christian > >> > >>> > >>> On Fri, Mar 26, 2021 at 7:14 AM Christian MAUDERER > >>> wrote: > > Hello, > > I would like to backport the following patches to 5 and 5-freebsd-12: > > https://git.rtems.org/rtems-libbsd/commit/?h=6-freebsd-12&id=e7fb073f3a1040847daab3ef917aeade755eb30b > https://git.rtems.org/rtems-libbsd/commit/?h=6-freebsd-12&id=33e3cf8eaff0081e74593f8a91edc8e37f732430 > > Ticket is here: > > https://devel.rtems.org/ticket/4361 > > Is that OK? > > Best regards > > Christian > -- > > embedded brains GmbH > Herr Christian MAUDERER > Dornierstr. 4 > 82178 Puchheim > Germany > email: christian.maude...@embedded-brains.de > phone: +49-89-18 94 741 - 18 > fax: +49-89-18 94 741 - 08 > > Registergericht: Amtsgericht München > Registernummer: HRB 157899 > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler > Unsere Datenschutzerklärung finden Sie hier: > https://embedded-brains.de/datenschutzerklaerung/ > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > >> > >> -- > >> > >> embedded brains GmbH > >> Herr Christian MAUDERER > >> Dornierstr. 4 > >> 82178 Puchheim > >> Germany > >> email: christian.maude...@embedded-brains.de > >> phone: +49-89-18 94 741 - 18 > >> fax: +49-89-18 94 741 - 08 > >> > >> Registergericht: Amtsgericht München > >> Registernummer: HRB 157899 > >> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler > >> Unsere Datenschutzerklärung finden Sie hier: > >> https://embedded-brains.de/datenschutzerklaerung/ > > -- > > embedded brains GmbH > Herr Christian MAUDERER > Dornierstr. 4 > 82178 Puchheim > Germany > email: christian.maude...@embedded-brains.de > phone: +49-89-18 94 741 - 18 > fax: +49-89-18 94 741 - 08 > > Registergericht: Amtsgericht München > Registernummer: HRB 157899 > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler > Unsere Datenschutzerklärung finden Sie hier: > https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-littlevgl] wscript: Upgrade rtems_version number
Hello Christian,
On Mon, Mar 29, 2021 at 12:38 AM Christian MAUDERER
wrote:
>
> Hello Vijay,
>
> please push the littlevgl patches. These are our responsibility anyway.
>
Pushed!
Thanks,
Vijay
> Best regards
>
> Christian
>
> Am 26.03.21 um 21:43 schrieb Vijay Kumar Banerjee:
> > ---
> > lvgl.py | 2 +-
> > wscript | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/lvgl.py b/lvgl.py
> > index 0eadd90..2574acd 100644
> > --- a/lvgl.py
> > +++ b/lvgl.py
> > @@ -110,5 +110,5 @@ def build(bld):
> > bld.install_files(os.path.join("${PREFIX}", arch_inc_path,
> > include_path),
> > include_headers)
> > bld.install_files(os.path.join('${PREFIX}', arch_lib_path),
> > ["liblvgl.a"])
> > -bld.install_files(os.path.join('${PREFIX}', arch_inc_path,
> > include_path),
> > +bld.install_files(os.path.join('${PREFIX}', arch_inc_path),
> > [lv_conf_h, lv_drv_conf_h])
> > diff --git a/wscript b/wscript
> > index b3aa96f..6e2c722 100644
> > --- a/wscript
> > +++ b/wscript
> > @@ -30,7 +30,7 @@ from __future__ import print_function
> > import lvgl
> > import sys
> >
> > -rtems_version = "5"
> > +rtems_version = "6"
> >
> > try:
> > import rtems_waf.rtems as rtems
> >
>
> --
>
> embedded brains GmbH
> Herr Christian MAUDERER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: christian.maude...@embedded-brains.de
> phone: +49-89-18 94 741 - 18
> fax: +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-examples] lvgl/wscript: Add libpath to search for required libraries
Hi,
Is this OK to push? This only affects lvgl.
Best regards,
Vijay
On Fri, Mar 26, 2021 at 2:47 PM Vijay Kumar Banerjee wrote:
>
> ---
> lvgl/wscript | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/lvgl/wscript b/lvgl/wscript
> index 064ebed..281af25 100644
> --- a/lvgl/wscript
> +++ b/lvgl/wscript
> @@ -5,11 +5,19 @@
>
> import rtems_waf.rtems as rtems
> import rtems_waf.rtems_bsd as rtems_bsd
> +import os
>
> def configure(conf):
> +arch_lib_path = rtems.arch_bsp_lib_path(str(conf.env.RTEMS_VERSION),
> +str(conf.env.RTEMS_ARCH_BSP))
> +arch_lib_path = os.path.join(conf.env.PREFIX, arch_lib_path)
> rtems.check_lib_path(conf, lib = 'm')
> -rtems.check_lib_path(conf, lib = 'lvgl', mandatory = False)
> -rtems.check_lib_path(conf, lib = 'bsd', mandatory = False)
> +rtems.check_lib_path(conf, lib = 'lvgl',
> + libpath = [arch_lib_path],
> + mandatory = False)
> +rtems.check_lib_path(conf, lib = 'bsd',
> + libpath = [arch_lib_path],
> + mandatory = False)
>
> def build(bld):
> bld.recurse('hello')
> --
> 2.26.2
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: GSOC project: #4334 Replace Mongoose with Civetweb
I have installed libbsd package (made RTEMS_POSIX_API=True,RTEMS_NETWORKING=True in config.ini file to enable POSIX and networking) but I am still confused about the work already done in this project in past. Also after interacting on discord I think completely replacing mongoose with another web-server is not a good option since it may rise some user complaints who are already using old system and may find it difficult to instantly switch over to new system , instead civetweb can be added as an extra new web-server where user has a choice to either use old mongoose or the new web server both having all dependencies and functionalities available. Also I still don't know whether the project #4334 is long enough for summer of code project and after going through docs I think https://devel.rtems.org/ticket/4272 is also a very interesting project since now I think I know a little bit about BSPs and I am good in python and know shell-scripting. I would be very grateful to know more about this project. Thanks. On Sat, Mar 27, 2021 at 5:36 PM Ayushman Mishra wrote: > > Greetings to all the respected mentors, > 1. I saw there has been a lot of discussion regarding replacing > mongoose with civetweb ( > https://lists.rtems.org/pipermail/devel/2016-April/014661.html ). > I think the basic outline of the project is like this > a. Completely removing mongoose and replace it with civetweb and make > it configurable in rsb > b. check the parameters and options available in civetweb and make it > usable for users in rtems. > c. making test-cases for civetweb (should be similar to mongoose) > d. documentation of using civetweb and web-server in general. > I would be very grateful to know what is the actual current status of > this project and the coding involved in it enough for a summer of code > project or some extra things should be added in it. > > Also, > 2. I have build bsp on rtems6 and a simple application is working > correct, but while trying to build libbsd package in rtems6 > (../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/6 \ > --host=sparc-rtems6 --with-rtems-bsp=erc32 6/rtems-libbsd ) I am > constantly getting build failed > RTEMS Source Builder - Set Builder, 6 (ade089253e70) > Build Set: 6/rtems-libbsd > config: tools/rtems-libbsd-6.cfg > error: rtems-bsp.cfg:155: invalid %if operator: -mcpu=cypress > -I/home/ayush/quick-start/rtems/6/sparc-rtems6/erc32/lib/include == > Build FAILED > Build Set: Time 0:00:00.045392 > Build FAILED > > I also tried building all packages for bsp erc32 > (../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/6 \ > --with-rtems-tests=yes bsps/erc32) but after building for more > than an hour it also gave build failed error. > building: sparc-rtems6-kernel-erc32-1 > error: building sparc-rtems6-kernel-erc32-1 > Build FAILED > See error report: rsb-report-sparc-rtems6-kernel-erc32-1.txt > error: building sparc-rtems6-kernel-erc32-1 > Build Set: Time 0:23:14.195494 > error: building sparc-rtems6-kernel-erc32-1 > Build Set: Time 3:55:05.826612 > Build FAILED > > Thanks, Ayushman > > On Mon, Mar 22, 2021 at 6:37 AM Ayushman Mishra > wrote: > > > > Thanks a lot for help and information , actually i am trying to setup > > mongoose on simple rtems application > > (https://devel.rtems.org/wiki/Developer/Mongoose_Web_Server) and for > > that right now I am trying to configure networking and file-system in > > the application. > > > > On Sun, Mar 21, 2021 at 8:54 PM Joel Sherrill wrote: > > > > > > > > > > > > On Sun, Mar 21, 2021, 4:45 AM Christian Mauderer > > > wrote: > > >> > > >> Hello Ayushman, > > >> > > >> On 21/03/2021 04:15, Ayushman Mishra wrote: > > >> > Ayushman > > >> > Hello everyone , I am very much interested in taking > > >> > https://devel.rtems.org/ticket/4334 > > >> > as a GSOC 2021 project. I know some basic networking concepts and > > >> > would like to > > >> > learn more about it and how its applied to OS like RTEMS , regarding > > >> > this I have some questions. > > >> > > >> Note that the ticket will be more about integrating civetweb into a > > >> RTEMS Source Builder (RSB) recipe and finding a way to make it > > >> configurable there. Alternative could be some kind of stand alone repo > > >> like for littlevgl. > > > > > > > > > Making the civitweb configure options available to RTEMS user is a key > > > point. > > > > > > It may make sense to do a repo with waf build system and config.ini that > > > maps to their settings. > > > > > >> > > >> civetweb builds on RTEMS nearly out of the box. So don't expect too much > > >> C-Code. > > > > > > > > > I set it up recently on Linux for embedding in their application. As you > > > turned on options, it had more dependencies. This would have to be > > > managed with RTEMS. > > > > > >> > > >> I'm not yet sure how much work will be on that ticket. If it is too few > > >> for a whole GSoC, you might want to think about reviving the discussion > > >> about some usef
Re: [PATCH] STM32H743ZI Nucleo and basic lwIP support
On Mon, Mar 29, 2021 at 6:17 AM Robin Mueller wrote:
>
> This patch adds support for the STM32H743ZI-Nucleo board
> variation. This currently works by setting the STM32H743ZI_NUCLEO
> flag in the config.ini flag
>
> It also adds basic lwIP support which can be enabled
> with the flag STM32H7_ADD_LWIP. This enables certain functionalities
> required for lwIP to work properly
>
> This patch also changes the default implementation
> of HAL_GetTick to return the system tick by forwarding the call
> to the respective RTEMS function.
>
> ---
> bsps/arm/stm32h7/console/console-usart3-cfg.c | 21
> bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c | 16 -
> .../stm32h7/include/Legacy/stm32_hal_legacy.h | 4 +++-
> bsps/arm/stm32h7/include/stm32h7xx_hal_conf.h | 11 -
> bsps/arm/stm32h7/include/stm32h7xx_hal_uart.h | 1 +
> bsps/arm/stm32h7/start/bspstart.c | 2 +-
> bsps/arm/stm32h7/start/stm32h7-hal-eth.c | 3 +--
> spec/build/bsps/arm/stm32h7/bspstm32h7.yml| 4
> spec/build/bsps/arm/stm32h7/opth743nucleo.yml | 13 ++
> spec/build/bsps/arm/stm32h7/optlwip.yml | 24 +++
> 10 files changed, 88 insertions(+), 11 deletions(-)
> create mode 100644 spec/build/bsps/arm/stm32h7/opth743nucleo.yml
> create mode 100644 spec/build/bsps/arm/stm32h7/optlwip.yml
>
> diff --git a/bsps/arm/stm32h7/console/console-usart3-cfg.c
> b/bsps/arm/stm32h7/console/console-usart3-cfg.c
> index b40f6da5aa..dc552610e1 100644
> --- a/bsps/arm/stm32h7/console/console-usart3-cfg.c
> +++ b/bsps/arm/stm32h7/console/console-usart3-cfg.c
> @@ -25,12 +25,32 @@
> * POSSIBILITY OF SUCH DAMAGE.
> */
>
> +#ifdef __rtems__
> +#include
> +#endif
> +
> #ifdef HAVE_CONFIG_H
> #include "config.h"
> #endif
>
> #include
>
> +#if STM32H743ZI_NUCLEO == 1
> +const stm32h7_uart_config stm32h7_usart3_config = {
> + .gpio = {
> +.regs = GPIOD,
> +.config = {
> + .Pin = GPIO_PIN_8 | GPIO_PIN_9,
> + .Mode = GPIO_MODE_AF_PP,
> + .Pull = GPIO_NOPULL,
> + .Speed = GPIO_SPEED_FREQ_LOW,
> + .Alternate = GPIO_AF7_USART3
> +}
> + },
> + .irq = USART3_IRQn,
> + .device_index = 2
> +};
> +#else
> const stm32h7_uart_config stm32h7_usart3_config = {
>.gpio = {
> .regs = GPIOB,
> @@ -45,3 +65,4 @@ const stm32h7_uart_config stm32h7_usart3_config = {
>.irq = USART3_IRQn,
>.device_index = 2
> };
> +#endif /* STM32H743ZI_NUCLEO == 1 */
> diff --git a/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> b/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> index 4f2634df5b..6c3590bce8 100644
> --- a/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> +++ b/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> @@ -146,6 +146,10 @@
> /* Includes
> --*/
> #include "stm32h7xx_hal.h"
>
> +#ifdef __rtems__
> +#include
> +#endif
> +
> /** @addtogroup STM32H7xx_HAL_Driver
>* @{
>*/
> @@ -361,10 +365,10 @@ HAL_StatusTypeDef HAL_ETH_Init(ETH_HandleTypeDef *heth)
>/*-- MAC, MTL and DMA default Configuration
> */
>ETH_MACDMAConfig(heth);
>
> -#ifndef __rtems__
> +#if STM32H7_ADD_LWIP == 1
Someone else may be able to address whether we need to disable this
stuff for 'non-lwip' builds of stm32. There is an ongoing effort to
collect lwip drivers and lwip build as a library after building rtems,
so maybe this will move eventually to the lwip driver repo when that
gets into production.
>/* SET DSL to 64 bit */
>MODIFY_REG(heth->Instance->DMACCR, ETH_DMACCR_DSL, ETH_DMACCR_DSL_64BIT);
> -#endif /* __rtems__ */
> +#endif
>
>/* Set Receive Buffers Length (must be a multiple of 4) */
>if ((heth->Init.RxBuffLen % 0x4U) != 0x0U)
> @@ -2647,7 +2651,7 @@ static void ETH_MAC_MDIO_ClkConfig(ETH_HandleTypeDef
> *heth)
>*/
> static void ETH_DMATxDescListInit(ETH_HandleTypeDef *heth)
> {
> -#ifndef __rtems__
> +#if STM32H7_ADD_LWIP == 1
>ETH_DMADescTypeDef *dmatxdesc;
>uint32_t i;
>
> @@ -2674,7 +2678,7 @@ static void ETH_DMATxDescListInit(ETH_HandleTypeDef
> *heth)
>
>/* Set Transmit Descriptor Tail pointer */
>WRITE_REG(heth->Instance->DMACTDTPR, (uint32_t) heth->Init.TxDesc);
> -#endif /* __rtems__ */
> +#endif /* STM32H7_ADD_LWIP == 1 */
> }
>
> /**
> @@ -2686,7 +2690,7 @@ static void ETH_DMATxDescListInit(ETH_HandleTypeDef
> *heth)
>*/
> static void ETH_DMARxDescListInit(ETH_HandleTypeDef *heth)
> {
> -#ifndef __rtems__
> +#if STM32H7_ADD_LWIP == 1
>ETH_DMADescTypeDef *dmarxdesc;
>uint32_t i;
>
> @@ -2719,7 +2723,7 @@ static void ETH_DMARxDescListInit(ETH_HandleTypeDef
> *heth)
>
>/* Set Receive Descriptor Tail pointer Address */
>WRITE_REG(heth->Instance->DMACRDTPR, ((uint32_t)(heth->Init.RxDesc +
> (((uint32_t)(ETH_RX_DESC_CNT - 1))*sizeof(ETH_DMADescTypeDef);
> -#endif /* __rtems__ */
> +#endif /* STM32H7_ADD_LWIP == 1 */
> }
>
> /**
> diff --git a/bsps/arm/stm32h7/include/Legacy/stm32_ha
Re: x86_64 BSP : Status Update [ticket #2898]
On Mon, Mar 29, 2021 at 1:28 AM Shashvat wrote: > > Hello everyone ! > > I wanted to know the status of the x86_64 BSP's development. > Also it would be great help if someone guides me to get it running on QEMU or > my x64 based laptop running legacy BIOS.(not UEFI) > Is this intended for a GSoC application, or just fun/profit? > > Regards > Shashvat > > ___ > 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 project: #4334 Replace Mongoose with Civetweb
On Mon, Mar 29, 2021 at 9:49 AM Ayushman Mishra wrote: > > I have installed libbsd package (made > RTEMS_POSIX_API=True,RTEMS_NETWORKING=True in config.ini file to > enable POSIX and networking) but I am still confused about the work That doesn't look right. RTEMS_NETWORKING=True enables the legacy network stack. If you want to build libbsd, you need to check out https://git.rtems.org/rtems-libbsd/ > already done in this project in past. Also after interacting on > discord I think completely replacing mongoose with another web-server > is not a good option since it may rise some user complaints who are > already using old system and may find it difficult to instantly switch > over to new system , instead civetweb can be added as an extra new > web-server where user has a choice to either use old mongoose or the > new web server both having all dependencies and functionalities > available. > No, we will replace mghttpd with civetweb. Anyone who still wants the frozen version of mghttpd can revive it, but we want to replace it moving forward. > Also I still don't know whether the project #4334 is long enough for > summer of code project and after going through docs I think There are other activities involved in getting civetweb to work well with RTEMS. It should be sufficient, but you would need to flesh out the proposal details with mentor assistance. To be clear, it will be C/network programming. > https://devel.rtems.org/ticket/4272 is also a very interesting project > since now I think I know a little bit about BSPs and I am good in > python and know shell-scripting. I would be very grateful to know more > about this project. You should start a new thread to discuss this project. I thought someone else may have inquired about this, maybe it was you? I didn't see any response yet, but probably because it was buried in other content (like this comment) so likely the potential mentor didn't even notice it, especially since all you mention here is the ticket number. Gedare > Thanks. > > On Sat, Mar 27, 2021 at 5:36 PM Ayushman Mishra > wrote: > > > > Greetings to all the respected mentors, > > 1. I saw there has been a lot of discussion regarding replacing > > mongoose with civetweb ( > > https://lists.rtems.org/pipermail/devel/2016-April/014661.html ). > > I think the basic outline of the project is like this > > a. Completely removing mongoose and replace it with civetweb and make > > it configurable in rsb > > b. check the parameters and options available in civetweb and make it > > usable for users in rtems. > > c. making test-cases for civetweb (should be similar to mongoose) > > d. documentation of using civetweb and web-server in general. > > I would be very grateful to know what is the actual current status of > > this project and the coding involved in it enough for a summer of code > > project or some extra things should be added in it. > > > > Also, > > 2. I have build bsp on rtems6 and a simple application is working > > correct, but while trying to build libbsd package in rtems6 > > (../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/6 \ > > --host=sparc-rtems6 --with-rtems-bsp=erc32 6/rtems-libbsd ) I am > > constantly getting build failed > > RTEMS Source Builder - Set Builder, 6 (ade089253e70) > > Build Set: 6/rtems-libbsd > > config: tools/rtems-libbsd-6.cfg > > error: rtems-bsp.cfg:155: invalid %if operator: -mcpu=cypress > > -I/home/ayush/quick-start/rtems/6/sparc-rtems6/erc32/lib/include == > > Build FAILED > > Build Set: Time 0:00:00.045392 > > Build FAILED > > > > I also tried building all packages for bsp erc32 > > (../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/6 \ > > --with-rtems-tests=yes bsps/erc32) but after building for more > > than an hour it also gave build failed error. > > building: sparc-rtems6-kernel-erc32-1 > > error: building sparc-rtems6-kernel-erc32-1 > > Build FAILED > > See error report: rsb-report-sparc-rtems6-kernel-erc32-1.txt > > error: building sparc-rtems6-kernel-erc32-1 > > Build Set: Time 0:23:14.195494 > > error: building sparc-rtems6-kernel-erc32-1 > > Build Set: Time 3:55:05.826612 > > Build FAILED > > > > Thanks, Ayushman > > > > On Mon, Mar 22, 2021 at 6:37 AM Ayushman Mishra > > wrote: > > > > > > Thanks a lot for help and information , actually i am trying to setup > > > mongoose on simple rtems application > > > (https://devel.rtems.org/wiki/Developer/Mongoose_Web_Server) and for > > > that right now I am trying to configure networking and file-system in > > > the application. > > > > > > On Sun, Mar 21, 2021 at 8:54 PM Joel Sherrill wrote: > > > > > > > > > > > > > > > > On Sun, Mar 21, 2021, 4:45 AM Christian Mauderer > > > > wrote: > > > >> > > > >> Hello Ayushman, > > > >> > > > >> On 21/03/2021 04:15, Ayushman Mishra wrote: > > > >> > Ayushman > > > >> > Hello everyone , I am very much interested in taking > > > >> > https://devel.rtems.org/ticket/4334 > > > >> > as a GSOC 2021 project. I kn
Re: [PATCH rtems-examples] lvgl/wscript: Add libpath to search for required libraries
On Mon, Mar 29, 2021 at 9:20 AM Vijay Kumar Banerjee wrote:
>
> Hi,
>
> Is this OK to push? This only affects lvgl.
>
You're a maintainer of lvgl repo, so you can make that decision yourself ;)
> Best regards,
> Vijay
>
> On Fri, Mar 26, 2021 at 2:47 PM Vijay Kumar Banerjee wrote:
> >
> > ---
> > lvgl/wscript | 12 ++--
> > 1 file changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/lvgl/wscript b/lvgl/wscript
> > index 064ebed..281af25 100644
> > --- a/lvgl/wscript
> > +++ b/lvgl/wscript
> > @@ -5,11 +5,19 @@
> >
> > import rtems_waf.rtems as rtems
> > import rtems_waf.rtems_bsd as rtems_bsd
> > +import os
> >
> > def configure(conf):
> > +arch_lib_path = rtems.arch_bsp_lib_path(str(conf.env.RTEMS_VERSION),
> > +
> > str(conf.env.RTEMS_ARCH_BSP))
> > +arch_lib_path = os.path.join(conf.env.PREFIX, arch_lib_path)
> > rtems.check_lib_path(conf, lib = 'm')
> > -rtems.check_lib_path(conf, lib = 'lvgl', mandatory = False)
> > -rtems.check_lib_path(conf, lib = 'bsd', mandatory = False)
> > +rtems.check_lib_path(conf, lib = 'lvgl',
> > + libpath = [arch_lib_path],
> > + mandatory = False)
> > +rtems.check_lib_path(conf, lib = 'bsd',
> > + libpath = [arch_lib_path],
> > + mandatory = False)
> >
> > def build(bld):
> > bld.recurse('hello')
> > --
> > 2.26.2
> >
> ___
> 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 project: #4334 Replace Mongoose with Civetweb
Sir , It would be very helpful to know about potential mentors of (Replace mongoose with civetweb) https://devel.rtems.org/ticket/4334 this project. On Mon, Mar 29, 2021, 9:39 PM Gedare Bloom wrote: > On Mon, Mar 29, 2021 at 9:49 AM Ayushman Mishra > wrote: > > > > I have installed libbsd package (made > > RTEMS_POSIX_API=True,RTEMS_NETWORKING=True in config.ini file to > > enable POSIX and networking) but I am still confused about the work > That doesn't look right. RTEMS_NETWORKING=True enables the legacy > network stack. If you want to build libbsd, you need to check out > https://git.rtems.org/rtems-libbsd/ > > > already done in this project in past. Also after interacting on > > discord I think completely replacing mongoose with another web-server > > is not a good option since it may rise some user complaints who are > > already using old system and may find it difficult to instantly switch > > over to new system , instead civetweb can be added as an extra new > > web-server where user has a choice to either use old mongoose or the > > new web server both having all dependencies and functionalities > > available. > > > No, we will replace mghttpd with civetweb. Anyone who still wants the > frozen version of mghttpd can revive it, but we want to replace it > moving forward. > > > Also I still don't know whether the project #4334 is long enough for > > summer of code project and after going through docs I think > There are other activities involved in getting civetweb to work well > with RTEMS. It should be sufficient, but you would need to flesh out > the proposal details with mentor assistance. To be clear, it will be > C/network programming. > > > https://devel.rtems.org/ticket/4272 is also a very interesting project > > since now I think I know a little bit about BSPs and I am good in > > python and know shell-scripting. I would be very grateful to know more > > about this project. > You should start a new thread to discuss this project. I thought > someone else may have inquired about this, maybe it was you? I didn't > see any response yet, but probably because it was buried in other > content (like this comment) so likely the potential mentor didn't even > notice it, especially since all you mention here is the ticket number. > > Gedare > > > Thanks. > > > > On Sat, Mar 27, 2021 at 5:36 PM Ayushman Mishra > > wrote: > > > > > > Greetings to all the respected mentors, > > > 1. I saw there has been a lot of discussion regarding replacing > > > mongoose with civetweb ( > > > https://lists.rtems.org/pipermail/devel/2016-April/014661.html ). > > > I think the basic outline of the project is like this > > > a. Completely removing mongoose and replace it with civetweb and make > > > it configurable in rsb > > > b. check the parameters and options available in civetweb and make it > > > usable for users in rtems. > > > c. making test-cases for civetweb (should be similar to mongoose) > > > d. documentation of using civetweb and web-server in general. > > > I would be very grateful to know what is the actual current status of > > > this project and the coding involved in it enough for a summer of code > > > project or some extra things should be added in it. > > > > > > Also, > > > 2. I have build bsp on rtems6 and a simple application is working > > > correct, but while trying to build libbsd package in rtems6 > > > (../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/6 \ > > > --host=sparc-rtems6 --with-rtems-bsp=erc32 6/rtems-libbsd ) I am > > > constantly getting build failed > > > RTEMS Source Builder - Set Builder, 6 (ade089253e70) > > > Build Set: 6/rtems-libbsd > > > config: tools/rtems-libbsd-6.cfg > > > error: rtems-bsp.cfg:155: invalid %if operator: -mcpu=cypress > > > -I/home/ayush/quick-start/rtems/6/sparc-rtems6/erc32/lib/include == > > > Build FAILED > > > Build Set: Time 0:00:00.045392 > > > Build FAILED > > > > > > I also tried building all packages for bsp erc32 > > > (../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/6 \ > > > --with-rtems-tests=yes bsps/erc32) but after building for more > > > than an hour it also gave build failed error. > > > building: sparc-rtems6-kernel-erc32-1 > > > error: building sparc-rtems6-kernel-erc32-1 > > > Build FAILED > > > See error report: rsb-report-sparc-rtems6-kernel-erc32-1.txt > > > error: building sparc-rtems6-kernel-erc32-1 > > > Build Set: Time 0:23:14.195494 > > > error: building sparc-rtems6-kernel-erc32-1 > > > Build Set: Time 3:55:05.826612 > > > Build FAILED > > > > > > Thanks, Ayushman > > > > > > On Mon, Mar 22, 2021 at 6:37 AM Ayushman Mishra > > > wrote: > > > > > > > > Thanks a lot for help and information , actually i am trying to setup > > > > mongoose on simple rtems application > > > > (https://devel.rtems.org/wiki/Developer/Mongoose_Web_Server) and for > > > > that right now I am trying to configure networking and file-system in > > > > the application. > > > > > > > > On Sun, Mar 21,
Re: GSOC project: #4334 Replace Mongoose with Civetweb
CC: Christian On Mon, Mar 29, 2021 at 10:34 AM Ayushman Mishra wrote: > > Sir , > It would be very helpful to know about potential mentors of (Replace mongoose > with civetweb) https://devel.rtems.org/ticket/4334 this project. > I think Christian is the most likely potential mentor. > On Mon, Mar 29, 2021, 9:39 PM Gedare Bloom wrote: >> >> On Mon, Mar 29, 2021 at 9:49 AM Ayushman Mishra >> wrote: >> > >> > I have installed libbsd package (made >> > RTEMS_POSIX_API=True,RTEMS_NETWORKING=True in config.ini file to >> > enable POSIX and networking) but I am still confused about the work >> That doesn't look right. RTEMS_NETWORKING=True enables the legacy >> network stack. If you want to build libbsd, you need to check out >> https://git.rtems.org/rtems-libbsd/ >> >> > already done in this project in past. Also after interacting on >> > discord I think completely replacing mongoose with another web-server >> > is not a good option since it may rise some user complaints who are >> > already using old system and may find it difficult to instantly switch >> > over to new system , instead civetweb can be added as an extra new >> > web-server where user has a choice to either use old mongoose or the >> > new web server both having all dependencies and functionalities >> > available. >> > >> No, we will replace mghttpd with civetweb. Anyone who still wants the >> frozen version of mghttpd can revive it, but we want to replace it >> moving forward. >> >> > Also I still don't know whether the project #4334 is long enough for >> > summer of code project and after going through docs I think >> There are other activities involved in getting civetweb to work well >> with RTEMS. It should be sufficient, but you would need to flesh out >> the proposal details with mentor assistance. To be clear, it will be >> C/network programming. >> >> > https://devel.rtems.org/ticket/4272 is also a very interesting project >> > since now I think I know a little bit about BSPs and I am good in >> > python and know shell-scripting. I would be very grateful to know more >> > about this project. >> You should start a new thread to discuss this project. I thought >> someone else may have inquired about this, maybe it was you? I didn't >> see any response yet, but probably because it was buried in other >> content (like this comment) so likely the potential mentor didn't even >> notice it, especially since all you mention here is the ticket number. >> >> Gedare >> >> > Thanks. >> > >> > On Sat, Mar 27, 2021 at 5:36 PM Ayushman Mishra >> > wrote: >> > > >> > > Greetings to all the respected mentors, >> > > 1. I saw there has been a lot of discussion regarding replacing >> > > mongoose with civetweb ( >> > > https://lists.rtems.org/pipermail/devel/2016-April/014661.html ). >> > > I think the basic outline of the project is like this >> > > a. Completely removing mongoose and replace it with civetweb and make >> > > it configurable in rsb >> > > b. check the parameters and options available in civetweb and make it >> > > usable for users in rtems. >> > > c. making test-cases for civetweb (should be similar to mongoose) >> > > d. documentation of using civetweb and web-server in general. >> > > I would be very grateful to know what is the actual current status of >> > > this project and the coding involved in it enough for a summer of code >> > > project or some extra things should be added in it. >> > > >> > > Also, >> > > 2. I have build bsp on rtems6 and a simple application is working >> > > correct, but while trying to build libbsd package in rtems6 >> > > (../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/6 \ >> > > --host=sparc-rtems6 --with-rtems-bsp=erc32 6/rtems-libbsd ) I am >> > > constantly getting build failed >> > > RTEMS Source Builder - Set Builder, 6 (ade089253e70) >> > > Build Set: 6/rtems-libbsd >> > > config: tools/rtems-libbsd-6.cfg >> > > error: rtems-bsp.cfg:155: invalid %if operator: -mcpu=cypress >> > > -I/home/ayush/quick-start/rtems/6/sparc-rtems6/erc32/lib/include == >> > > Build FAILED >> > > Build Set: Time 0:00:00.045392 >> > > Build FAILED >> > > >> > > I also tried building all packages for bsp erc32 >> > > (../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/6 \ >> > > --with-rtems-tests=yes bsps/erc32) but after building for more >> > > than an hour it also gave build failed error. >> > > building: sparc-rtems6-kernel-erc32-1 >> > > error: building sparc-rtems6-kernel-erc32-1 >> > > Build FAILED >> > > See error report: rsb-report-sparc-rtems6-kernel-erc32-1.txt >> > > error: building sparc-rtems6-kernel-erc32-1 >> > > Build Set: Time 0:23:14.195494 >> > > error: building sparc-rtems6-kernel-erc32-1 >> > > Build Set: Time 3:55:05.826612 >> > > Build FAILED >> > > >> > > Thanks, Ayushman >> > > >> > > On Mon, Mar 22, 2021 at 6:37 AM Ayushman Mishra >> > > wrote: >> > > > >> > > > Thanks a lot for help and information , actually i am trying to setup >> > > > mongoose
Re: x86_64 BSP : Status Update [ticket #2898]
I don't know if it changes the answer to the question but it was not intended as a GSOC application. I just needed a project to spend some time learning about the architecture and how BSPs are built in general. Regards Shashvat On Mon, Mar 29, 2021 at 9:27 PM Gedare Bloom wrote: > On Mon, Mar 29, 2021 at 1:28 AM Shashvat > wrote: > > > > Hello everyone ! > > > > I wanted to know the status of the x86_64 BSP's development. > > Also it would be great help if someone guides me to get it running on > QEMU or my x64 based laptop running legacy BIOS.(not UEFI) > > > Is this intended for a GSoC application, or just fun/profit? > > > > > Regards > > Shashvat > > > > ___ > > 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: x86_64 BSP : Status Update [ticket #2898]
On Mon, Mar 29, 2021 at 11:23 AM Shashvat wrote: > > I don't know if it changes the answer to the question but it was not intended > as a GSOC application. > It does not. I just want to be aware of what's coming in for GSoC. Thanks. > I just needed a project to spend some time learning about the architecture > and how BSPs are built in general. > > Regards > Shashvat > > On Mon, Mar 29, 2021 at 9:27 PM Gedare Bloom wrote: >> >> On Mon, Mar 29, 2021 at 1:28 AM Shashvat wrote: >> > >> > Hello everyone ! >> > >> > I wanted to know the status of the x86_64 BSP's development. >> > Also it would be great help if someone guides me to get it running on QEMU >> > or my x64 based laptop running legacy BIOS.(not UEFI) >> > >> Is this intended for a GSoC application, or just fun/profit? >> >> > >> > Regards >> > Shashvat >> > >> > ___ >> > 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
[PATCH rtems-docs] User/BSPs/Beagle: Add JTAG debugger section
--- user/bsps/arm/beagle.rst | 67 ++-- 1 file changed, 65 insertions(+), 2 deletions(-) diff --git a/user/bsps/arm/beagle.rst b/user/bsps/arm/beagle.rst index ac49b1c..dedd01b 100644 --- a/user/bsps/arm/beagle.rst +++ b/user/bsps/arm/beagle.rst @@ -102,8 +102,8 @@ The function prototype is given below: rtems_vector_number irq ); -Debugging -- +Debugging using libdebugger +--- RTEMS's ``libdebugger`` requires the ARM debug resources be enabled for it to work. The TI SOC used on the ``beagleboneblack`` board provides no access for @@ -162,3 +162,66 @@ If ``libdebugger`` fails to detect the registers open the ``bspdebug.c`` source and change ``has_tdo`` to ``1``, save then rebuild and install the BSP. This will turn on an internal feeback to check the JTAG logic. Discard the edit once the hardware is working. + +Debugging Beagle Bone Black using a JTAG debugger and gdb +- + +Debugging a Beagle Bone Black (or variants) is also possible using a hardware +JTAG debugger. The JTAG is available via P2. The connector is thought for a +ARM 20 pin cTI connector. That connector should be used, if it is relevant to +have access to commercially available adapters. + +For hand-made cables and adapters a standard 1.27mm pitch header and a 0.635mm +ribbon cable can be much cheaper. But note that even if it looks compatible, +it's not the same pin out as a ARM Cortex 20 pin connector! + +A lot of JTAG adapters that are working together with OpenOCD will work. There +are also commercially available systems (like Segger J-Link) that work well with +the Beagle. Note that the JTAG debugger has to be compatible with ARM Cortex A8. +Cortex M only debuggers (like the Segger J-Link Edu Mini) won't work. + +If the debugger offers a gdb server (like OpenOCD or Segger J-Link) the +following gdb start script can be used: + +.. code-block:: + +define reset +echo -- Reset target and wait for U-Boot to start kernel.\n +monitor reset +# RTEMS U-Boot starts at this address. +tbreak *0x8000 +# Linux starts here. +tbreak *0x8200 +continue + +echo -- Disable watchdog.\n +set *(uint32_t*)0x44e35048=0x +while (*(uint32_t*)0x44e35034 != 0) +end +set *(uint32_t*)0x44e35048=0x +while (*(uint32_t*)0x44e35034 != 0) +end + +echo -- Overwrite kernel with application to debug.\n +load +end + +target remote :2331 + +Note that you might have to replace the ``monitor reset`` by some other command +that resets the target using your specific debugger. You also have to replace +the ``target remote :2331`` to match the port of your gdb server. + +The script expects that the Beagle Bone Black starts some application from an SD +card or from eMMC. It defines a ``reset`` command that does the following: + + * reset the target + * let U-Boot run, initialize the base system, load an FDT and an application + * break at the application entry point + * disable the watchdog + * overwrite the application that has been loaded by U-Boot with the application + provided as an command line argument to gdb + +This method has the advantage that the application is executed in nearly exact +the same environment like it would be executed if loaded by U-Boot directly +(except for the watchdog). -- 2.30.2 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [Beagle BSP] How to run all tests on a Beaglebone Black in an automated way
On 29/03/2021 00:29, Chris Johns wrote: On 28/3/21 8:04 pm, Christian Mauderer wrote: On 28/03/2021 03:16, Chris Johns wrote: On 28/3/21 6:16 am, Ahamed Husni wrote: Hi, I ran the hello program on the BBB using a bootable SD card. The SD card has two partitions. 1. BOOT - primary, bootable, FAT32 2. ROOT - primary, ext4 The BOOT partition has the following files. 1. uEnv.txt 2. rtems-app.img 3. Device Tree Blob (am335x-boneblack.dtb) I want to run all the tests on the BBB. Is there any other way to do this? You have to get the BBB to fetch exes from a ftftp server (provided inside rtems-test) and provide some automated power control to the board. - Dr. Joel (in Discord) Please have a look at .. https://docs.rtems.org/branches/master/user/testing/configuration.html https://docs.rtems.org/branches/master/user/testing/tftp.html Chris Like Chris pointed out, the testing documentation is a good start point if you want to automate running tests. Thanks. We are talking about an online tut session to work through running the tests on real hardware as a practical demonstration. I am not sure how we run this and what we need to handle doing this. Beneath using TFTP for the Beagle you could also use a JTAG debugger to load the application if you have one. As far as I know, the tester is quite flexible regarding how to load an application. If your JTAG debugger has an GDB interface, you could use about the following commands for beagle (you have to adapt "monitor reset" to whatever causes a reset with your JTAG hardware): define reset echo -- Reset target and wait for U-Boot to start kernel.\n monitor reset # RTEMS starts at this address. tbreak *0x8000 # Linux starts here. tbreak *0x8200 continue echo -- Disable watchdog.\n set *(uint32_t*)0x44e35048=0x while (*(uint32_t*)0x44e35034 != 0) end set *(uint32_t*)0x44e35048=0x while (*(uint32_t*)0x44e35034 != 0) end echo -- Overwrite kernel with application to debug.\n load end Nice. This would be a great example for the user manual :) I've sent a patch. Best regards Christian Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: x86_64 BSP : Status Update [ticket #2898]
On 3/29/21 6:20 PM, Shashvat wrote: > I don't know if it changes the answer to the question but it was not > intended as a GSOC application. > > I just needed a project to spend some time learning about the > architecture and how BSPs are built in general. Well, if you have spare cycles, then amd64 bsp screams for attention. If you like reading about architectures then amd64 will provide you with a plenty of documentation to deal with. If you like elegant architecture, then it would not be your cup of tea probably. If you like architecture history, then it'll be probably as it's rooted in early '80s. Also it's not easy architecture like some armv7 board. It's architecture tuned for server usage too and hence quite complex. On the other hand it's not architecture which would not innovate at all. Two examples: (1) interrupt controller: first PIC then two PICs together, then APIC, later xAPIC and even later x2APIC and even later some peripherals just give up and use MSI(-X). From RTEMS point of view MSI-X is most interesting due to lowest latency[1], but amd64 BSP will need to deal with x(2)APIC too just to be able to fire all the cores/threads anyway and due to some peripherals not supporting MSI(-X).[2] (2) firmware: first it was BIOS, then BIOS cloned into various forms. Later with 80386 IBM come with idea to have OS booted right into 32bit (protected mode of the new 386 CPU). It happened on a few IBM PS/2 models and IBM even promised to fully document this which I'm not sure if happened at all since market was flowing in different way. Much later Intel came and did what IBM promised long time ago by porting their EFI (from Itanium) to x86 and this allows modern PCs to look like real 64bit machines from the startup -- except few exceptions you will be able to forget about all those 8086isms and 80386isms since you are right into long mode of blessed AMD64. :-) But or so, even if x86 is quite complex, there are still people tinkering with it and writing toy/example OSes, so this is certainly manageable. Hobby site known for x86 support is osdev.org[3], so definitely a lot of resources available and happy to be consumed if you have just some free time... Good luck! Karel [1]: https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/msg-signaled-interrupts-paper.pdf [2]: https://habr.com/en/post/446312/ [3]: https://wiki.osdev.org/Expanded_Main_Page ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-docs] User/BSPs/Beagle: Add JTAG debugger section
thanks, just a couple tweaks On Mon, Mar 29, 2021 at 12:13 PM Christian Mauderer wrote: > > --- > user/bsps/arm/beagle.rst | 67 ++-- > 1 file changed, 65 insertions(+), 2 deletions(-) > > diff --git a/user/bsps/arm/beagle.rst b/user/bsps/arm/beagle.rst > index ac49b1c..dedd01b 100644 > --- a/user/bsps/arm/beagle.rst > +++ b/user/bsps/arm/beagle.rst > @@ -102,8 +102,8 @@ The function prototype is given below: > rtems_vector_number irq > ); > > -Debugging > -- > +Debugging using libdebugger > +--- > > RTEMS's ``libdebugger`` requires the ARM debug resources be enabled for it to > work. The TI SOC used on the ``beagleboneblack`` board provides no access for > @@ -162,3 +162,66 @@ If ``libdebugger`` fails to detect the registers open > the ``bspdebug.c`` > source and change ``has_tdo`` to ``1``, save then rebuild and install the > BSP. This will turn on an internal feeback to check the JTAG logic. Discard > the edit once the hardware is working. > + > +Debugging Beagle Bone Black using a JTAG debugger and gdb > +- > + > +Debugging a Beagle Bone Black (or variants) is also possible using a hardware > +JTAG debugger. The JTAG is available via P2. The connector is thought for a 'thought for'? through? > +ARM 20 pin cTI connector. That connector should be used, if it is relevant to relevant -> necessary > +have access to commercially available adapters. > + > +For hand-made cables and adapters a standard 1.27mm pitch header and a > 0.635mm > +ribbon cable can be much cheaper. But note that even if it looks compatible, > +it's not the same pin out as a ARM Cortex 20 pin connector! > + > +A lot of JTAG adapters that are working together with OpenOCD will work. > There > +are also commercially available systems (like Segger J-Link) that work well > with > +the Beagle. Note that the JTAG debugger has to be compatible with ARM Cortex > A8. > +Cortex M only debuggers (like the Segger J-Link Edu Mini) won't work. > + > +If the debugger offers a gdb server (like OpenOCD or Segger J-Link) the > +following gdb start script can be used: > + > +.. code-block:: > + > +define reset > +echo -- Reset target and wait for U-Boot to start kernel.\n > +monitor reset > +# RTEMS U-Boot starts at this address. > +tbreak *0x8000 > +# Linux starts here. > +tbreak *0x8200 > +continue > + > +echo -- Disable watchdog.\n > +set *(uint32_t*)0x44e35048=0x > +while (*(uint32_t*)0x44e35034 != 0) > +end > +set *(uint32_t*)0x44e35048=0x > +while (*(uint32_t*)0x44e35034 != 0) > +end > + > +echo -- Overwrite kernel with application to debug.\n > +load > +end > + > +target remote :2331 > + > +Note that you might have to replace the ``monitor reset`` by some other > command > +that resets the target using your specific debugger. You also have to replace > +the ``target remote :2331`` to match the port of your gdb server. > + > +The script expects that the Beagle Bone Black starts some application from > an SD > +card or from eMMC. It defines a ``reset`` command that does the following: > + > + * reset the target > + * let U-Boot run, initialize the base system, load an FDT and an application > + * break at the application entry point > + * disable the watchdog > + * overwrite the application that has been loaded by U-Boot with the > application > + provided as an command line argument to gdb > + > +This method has the advantage that the application is executed in nearly > exact delete exact > +the same environment like it would be executed if loaded by U-Boot directly > +(except for the watchdog). > -- > 2.30.2 > > ___ > 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
[PATCH rtems-docs v2] User/BSPs/Beagle: Add JTAG debugger section
--- user/bsps/arm/beagle.rst | 67 ++-- 1 file changed, 65 insertions(+), 2 deletions(-) diff --git a/user/bsps/arm/beagle.rst b/user/bsps/arm/beagle.rst index ac49b1c..5789bb8 100644 --- a/user/bsps/arm/beagle.rst +++ b/user/bsps/arm/beagle.rst @@ -102,8 +102,8 @@ The function prototype is given below: rtems_vector_number irq ); -Debugging -- +Debugging using libdebugger +--- RTEMS's ``libdebugger`` requires the ARM debug resources be enabled for it to work. The TI SOC used on the ``beagleboneblack`` board provides no access for @@ -162,3 +162,66 @@ If ``libdebugger`` fails to detect the registers open the ``bspdebug.c`` source and change ``has_tdo`` to ``1``, save then rebuild and install the BSP. This will turn on an internal feeback to check the JTAG logic. Discard the edit once the hardware is working. + +Debugging Beagle Bone Black using a JTAG debugger and gdb +- + +Debugging a Beagle Bone Black (or variants) is also possible using a hardware +JTAG debugger. The JTAG is available via P2. The footprint is for an ARM 20 pin +cTI connector. That connector should be used, if it is necessary to have access +to commercially available adapters. + +For hand-made cables and adapters a standard 1.27mm pitch header and a 0.635mm +ribbon cable can be much cheaper. But note that even if it looks compatible, +it's not the same pin out as a ARM Cortex 20 pin connector! + +A lot of JTAG adapters that are working together with OpenOCD will work. There +are also commercially available systems (like Segger J-Link) that work well with +the Beagle. Note that the JTAG debugger has to be compatible with ARM Cortex A8. +Cortex M only debuggers (like the Segger J-Link Edu Mini) won't work. + +If the debugger offers a gdb server (like OpenOCD or Segger J-Link) the +following gdb start script can be used: + +.. code-block:: + +define reset +echo -- Reset target and wait for U-Boot to start kernel.\n +monitor reset +# RTEMS U-Boot starts at this address. +tbreak *0x8000 +# Linux starts here. +tbreak *0x8200 +continue + +echo -- Disable watchdog.\n +set *(uint32_t*)0x44e35048=0x +while (*(uint32_t*)0x44e35034 != 0) +end +set *(uint32_t*)0x44e35048=0x +while (*(uint32_t*)0x44e35034 != 0) +end + +echo -- Overwrite kernel with application to debug.\n +load +end + +target remote :2331 + +Note that you might have to replace the ``monitor reset`` by some other command +that resets the target using your specific debugger. You also have to replace +the ``target remote :2331`` to match the port of your gdb server. + +The script expects that the Beagle Bone Black starts some application from an SD +card or from eMMC. It defines a ``reset`` command that does the following: + + * reset the target + * let U-Boot run, initialize the base system, load an FDT and an application + * break at the application entry point + * disable the watchdog + * overwrite the application that has been loaded by U-Boot with the application + provided as an command line argument to gdb + +This method has the advantage that the application is executed in nearly the +same environment like it would be executed if loaded by U-Boot directly (except +for the watchdog). -- 2.30.2 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-docs] User/BSPs/Beagle: Add JTAG debugger section
Hello Gedare, thanks for the review. I've sent a v2. I changed the first sentence (with "thought") a bit. Otherwise I followed your suggestions. Best regards Christian On 29/03/2021 21:08, Gedare Bloom wrote: thanks, just a couple tweaks On Mon, Mar 29, 2021 at 12:13 PM Christian Mauderer wrote: --- user/bsps/arm/beagle.rst | 67 ++-- 1 file changed, 65 insertions(+), 2 deletions(-) diff --git a/user/bsps/arm/beagle.rst b/user/bsps/arm/beagle.rst index ac49b1c..dedd01b 100644 --- a/user/bsps/arm/beagle.rst +++ b/user/bsps/arm/beagle.rst @@ -102,8 +102,8 @@ The function prototype is given below: rtems_vector_number irq ); -Debugging -- +Debugging using libdebugger +--- RTEMS's ``libdebugger`` requires the ARM debug resources be enabled for it to work. The TI SOC used on the ``beagleboneblack`` board provides no access for @@ -162,3 +162,66 @@ If ``libdebugger`` fails to detect the registers open the ``bspdebug.c`` source and change ``has_tdo`` to ``1``, save then rebuild and install the BSP. This will turn on an internal feeback to check the JTAG logic. Discard the edit once the hardware is working. + +Debugging Beagle Bone Black using a JTAG debugger and gdb +- + +Debugging a Beagle Bone Black (or variants) is also possible using a hardware +JTAG debugger. The JTAG is available via P2. The connector is thought for a 'thought for'? through? +ARM 20 pin cTI connector. That connector should be used, if it is relevant to relevant -> necessary +have access to commercially available adapters. + +For hand-made cables and adapters a standard 1.27mm pitch header and a 0.635mm +ribbon cable can be much cheaper. But note that even if it looks compatible, +it's not the same pin out as a ARM Cortex 20 pin connector! + +A lot of JTAG adapters that are working together with OpenOCD will work. There +are also commercially available systems (like Segger J-Link) that work well with +the Beagle. Note that the JTAG debugger has to be compatible with ARM Cortex A8. +Cortex M only debuggers (like the Segger J-Link Edu Mini) won't work. + +If the debugger offers a gdb server (like OpenOCD or Segger J-Link) the +following gdb start script can be used: + +.. code-block:: + +define reset +echo -- Reset target and wait for U-Boot to start kernel.\n +monitor reset +# RTEMS U-Boot starts at this address. +tbreak *0x8000 +# Linux starts here. +tbreak *0x8200 +continue + +echo -- Disable watchdog.\n +set *(uint32_t*)0x44e35048=0x +while (*(uint32_t*)0x44e35034 != 0) +end +set *(uint32_t*)0x44e35048=0x +while (*(uint32_t*)0x44e35034 != 0) +end + +echo -- Overwrite kernel with application to debug.\n +load +end + +target remote :2331 + +Note that you might have to replace the ``monitor reset`` by some other command +that resets the target using your specific debugger. You also have to replace +the ``target remote :2331`` to match the port of your gdb server. + +The script expects that the Beagle Bone Black starts some application from an SD +card or from eMMC. It defines a ``reset`` command that does the following: + + * reset the target + * let U-Boot run, initialize the base system, load an FDT and an application + * break at the application entry point + * disable the watchdog + * overwrite the application that has been loaded by U-Boot with the application + provided as an command line argument to gdb + +This method has the advantage that the application is executed in nearly exact delete exact +the same environment like it would be executed if loaded by U-Boot directly +(except for the watchdog). -- 2.30.2 ___ 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: #3860 - GSoC enquiries
Yes I have. But wondering how to run it with the given configuration I saw in this thread( https://lists.rtems.org/pipermail/devel/2020-October/062770.html). On Mon, Mar 29, 2021 at 3:37 PM Gedare Bloom wrote: > Hi Ida, > > On Mon, Mar 29, 2021 at 7:36 AM Ida Delphine wrote: > > > > Hello, > > Please do you mind telling me how to run uncrustify with the given > configuration with any sample file? > > What have you tried? Any directions followed/attempted or notes that > you have taken would be helpful. > > I guess all the info that you should need is in Uncrustify's readme > file. https://github.com/uncrustify/uncrustify > > Did you successfully compile uncrustify tool? > > > I'm a bit stuck. > > > > Thanks, > > Ida. > > > > On Wed, Mar 17, 2021 at 10:34 PM Gedare Bloom wrote: > >> > >> On Wed, Mar 17, 2021 at 2:28 PM Ida Delphine wrote: > >> > > >> > Hello, > >> > So I have gone through this configuration file and I think I'm > getting it. However I'm a bit lost in the reading the messages in the > thread. Do you mind explaining? Or we can start talking about a way forward. > >> > Also can you help me with some steps on how to test this by myself if > possible? > >> > > >> > >> It may be easier if you go "up" a level to see the full thread > >> context: > https://lists.rtems.org/pipermail/devel/2020-October/thread.html#62769 > >> Then you can go through the messages non-linearly. Right now, the > >> basic idea is to follow the steps outlined in the open project ticket. > >> I think Christian has summarized it nicely in his recent email [1]: "I > >> think the contributions from this project that would add value would > >> be: > >> 1. Finding a tool and a configuration that can do an RTEMS style or an > >> acceptable close one. > >> 2. Adding a "check-style" target to our build system. > >> 3. Maybe add some kind of script similar to Linux "checkpatch.pl" that > >> could check whether patches would need changes _before_ they are > >> applied. > >> " > >> > >> The proposal preparation phase should work through identifying the > >> options and pros/cons for different tools while preparing a plan for > >> how to integrate style checks in 2, 3 and thinking through the coding > >> tasks for the summer. > >> > >> Getting the style checking tool's configuration to match with the > >> RTEMS style will be some effort, and testing it out and submitting > >> some patches based on it could be a good proposal activity also to > >> build some confidence about the tools that will be used. > >> > >> We also have some Python style guidelines that might be worth > >> addressing. Those are harder maybe, since the style refactoring might > >> be challenging to review for correctness. > >> > >> For getting started, I would recommend that you try running uncrustify > >> with the given configuration on some files in RTEMS, see what it > >> results in. Play around. > >> > >> [1] https://lists.rtems.org/pipermail/devel/2021-March/065547.html > >> > >> -Gedare > >> > >> > Thanks, > >> > Ida > >> > > >> > On Mon, Mar 15, 2021 at 9:39 PM Gedare Bloom > wrote: > >> >> > >> >> See the related thread, and we'll have to discuss how to move > forward. > >> >> The existing approach provides an uncrustify script: > >> >> https://lists.rtems.org/pipermail/devel/2020-October/062769.html > >> >> > >> >> > >> >> On Sun, Mar 14, 2021 at 9:47 PM Ida Delphine > wrote: > >> >> > > >> >> > Hello everyone, > >> >> > This ticket(https://devel.rtems.org/ticket/3860) was proposed to > me and I'm interested in it for GSoC. > >> >> > The first task there is to find a code checker or formater that > can produce results that match the RTEMS coding conventions. It also made > mention some tools have been discussed in the past. Please I will love > suggestions on possible tools I could use to achieve this. > >> >> > > >> >> > > >> >> > Cheers, > >> >> > Ida. > >> >> > ___ > >> >> > 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
Would like to participate in GSoC
Hi, I am a Computer Science student studying in university, Would like to participate in GSoC'21 while contributing to RTEMS this summer. This is the ticket which I have selected https://devel.rtems.org/ticket/3314 Let me know further details. Sincerely, Austin ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RE: [PATCH] coverage/symbol-sets.ini : Add libtrace
On Sat, Mar 27, 2021 at 9:46 AM Gedare Bloom wrote: > > On Fri, Mar 12, 2021 at 10:17 AM Alex White wrote: > > > > --- > > tester/rtems/testing/coverage/symbol-sets.ini | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/tester/rtems/testing/coverage/symbol-sets.ini > > b/tester/rtems/testing/coverage/symbol-sets.ini > > index 9617dd8..52e25ff 100644 > > --- a/tester/rtems/testing/coverage/symbol-sets.ini > > +++ b/tester/rtems/testing/coverage/symbol-sets.ini > > @@ -29,7 +29,7 @@ > > # > > > > [symbol-sets] > > -sets = > > score,rtems,sapi,posix,librfs,libpipe,libdosfs,libimfs,libjffs2,libcsupport,libbspcmdline,libcpuuse,libstackchk,libfsmount,libstringto,libdevnull,libdumpbuf,libuntar,libblock,libcrypt,libmd,libstdthreads > > +sets = > > score,rtems,sapi,posix,librfs,libpipe,libdosfs,libimfs,libjffs2,libcsupport,libbspcmdline,libcpuuse,libstackchk,libfsmount,libstringto,libdevnull,libdumpbuf,libuntar,libblock,libcrypt,libmd,libstdthreads,libtrace > > > ok, but this is really ugly. is the comma-separated list with no > whitespace mandatory, or can it be reformatted in a follow-up patch? Currently, it is mandatory because the coverage.py script does not remove whitespace when processing the values, it simply splits them on ',' characters. It can be reformatted in a follow-up patch to look something like this: sets = score,rtems,sapi,posix,librfs,libpipe,libdosfs,libimfs,libjffs2,libcsupport, libbspcmdline,libcpuuse,libstackchk,libfsmount,libstringto,libdevnull, libdumpbuf,libuntar,libblock,libcrypt,libmd,libstdthreads,libtrace As long as subsequent lines are indented (to comply with Python's ConfigParser format), it should work fine assuming logic is added to call strip() on the values in the parse() method of the symbol_parser class in coverage.py. > > > [libraries] > > score = @BUILD-TARGET@/@BSP@/cpukit/score/src > > @@ -76,4 +76,5 @@ libblock = @BUILD-TARGET@/@BSP@/cpukit/libblock/src > > libcrypt = @BUILD-TARGET@/@BSP@/cpukit/libcrypt > > libmd = @BUILD-TARGET@/@BSP@/cpukit/libmd > > libstdthreads = @BUILD-TARGET@/@BSP@/cpukit/libstdthreads > > +libtrace = @BUILD-TARGET@/@BSP@/cpukit/libtrace/record > > #zlib = @BUILD-TARGET@/@BSP@/cpukit/zlib > > -- > > 2.27.0 > > > > ___ > > 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: [PATCH] STM32H743ZI Nucleo and basic lwIP support
On Mon, Mar 29, 2021 at 9:52 AM Gedare Bloom wrote:
>
> On Mon, Mar 29, 2021 at 6:17 AM Robin Mueller
> wrote:
> >
> > This patch adds support for the STM32H743ZI-Nucleo board
> > variation. This currently works by setting the STM32H743ZI_NUCLEO
> > flag in the config.ini flag
> >
> > It also adds basic lwIP support which can be enabled
> > with the flag STM32H7_ADD_LWIP. This enables certain functionalities
> > required for lwIP to work properly
> >
> > This patch also changes the default implementation
> > of HAL_GetTick to return the system tick by forwarding the call
> > to the respective RTEMS function.
> >
> > ---
> > bsps/arm/stm32h7/console/console-usart3-cfg.c | 21
> > bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c | 16 -
> > .../stm32h7/include/Legacy/stm32_hal_legacy.h | 4 +++-
> > bsps/arm/stm32h7/include/stm32h7xx_hal_conf.h | 11 -
> > bsps/arm/stm32h7/include/stm32h7xx_hal_uart.h | 1 +
> > bsps/arm/stm32h7/start/bspstart.c | 2 +-
> > bsps/arm/stm32h7/start/stm32h7-hal-eth.c | 3 +--
> > spec/build/bsps/arm/stm32h7/bspstm32h7.yml| 4
> > spec/build/bsps/arm/stm32h7/opth743nucleo.yml | 13 ++
> > spec/build/bsps/arm/stm32h7/optlwip.yml | 24 +++
> > 10 files changed, 88 insertions(+), 11 deletions(-)
> > create mode 100644 spec/build/bsps/arm/stm32h7/opth743nucleo.yml
> > create mode 100644 spec/build/bsps/arm/stm32h7/optlwip.yml
> >
> > diff --git a/bsps/arm/stm32h7/console/console-usart3-cfg.c
> > b/bsps/arm/stm32h7/console/console-usart3-cfg.c
> > index b40f6da5aa..dc552610e1 100644
> > --- a/bsps/arm/stm32h7/console/console-usart3-cfg.c
> > +++ b/bsps/arm/stm32h7/console/console-usart3-cfg.c
> > @@ -25,12 +25,32 @@
> > * POSSIBILITY OF SUCH DAMAGE.
> > */
> >
> > +#ifdef __rtems__
> > +#include
> > +#endif
> > +
> > #ifdef HAVE_CONFIG_H
> > #include "config.h"
> > #endif
> >
> > #include
> >
> > +#if STM32H743ZI_NUCLEO == 1
> > +const stm32h7_uart_config stm32h7_usart3_config = {
> > + .gpio = {
> > +.regs = GPIOD,
> > +.config = {
> > + .Pin = GPIO_PIN_8 | GPIO_PIN_9,
> > + .Mode = GPIO_MODE_AF_PP,
> > + .Pull = GPIO_NOPULL,
> > + .Speed = GPIO_SPEED_FREQ_LOW,
> > + .Alternate = GPIO_AF7_USART3
> > +}
> > + },
> > + .irq = USART3_IRQn,
> > + .device_index = 2
> > +};
> > +#else
> > const stm32h7_uart_config stm32h7_usart3_config = {
> >.gpio = {
> > .regs = GPIOB,
> > @@ -45,3 +65,4 @@ const stm32h7_uart_config stm32h7_usart3_config = {
> >.irq = USART3_IRQn,
> >.device_index = 2
> > };
> > +#endif /* STM32H743ZI_NUCLEO == 1 */
> > diff --git a/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> > b/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> > index 4f2634df5b..6c3590bce8 100644
> > --- a/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> > +++ b/bsps/arm/stm32h7/hal/stm32h7xx_hal_eth.c
> > @@ -146,6 +146,10 @@
> > /* Includes
> > --*/
> > #include "stm32h7xx_hal.h"
> >
> > +#ifdef __rtems__
> > +#include
> > +#endif
> > +
> > /** @addtogroup STM32H7xx_HAL_Driver
> >* @{
> >*/
> > @@ -361,10 +365,10 @@ HAL_StatusTypeDef HAL_ETH_Init(ETH_HandleTypeDef
> > *heth)
> >/*-- MAC, MTL and DMA default Configuration
> > */
> >ETH_MACDMAConfig(heth);
> >
> > -#ifndef __rtems__
> > +#if STM32H7_ADD_LWIP == 1
>
> Someone else may be able to address whether we need to disable this
> stuff for 'non-lwip' builds of stm32. There is an ongoing effort to
> collect lwip drivers and lwip build as a library after building rtems,
> so maybe this will move eventually to the lwip driver repo when that
> gets into production.
>
Hi,
Yes, we're moving all the network stacks out of RTEMS so that a user
can choose their preferred network stack to work with RTEMS. The LWIP
repository is in initial state and it is gradually starting to include
the drivers. This lwip patch would be a great start of adding the
drivers and I'm happy to work with you to get it integrated into that
repository. Would you be interested in taking a look at it and adding
it to the rtems-lwip repository?
https://git.rtems.org/vijay/rtems-lwip.git/
Once this is in a working state, this repository will be added to
rtems top directory as official rtems-lwip.
Best regards,
Vijay
> >/* SET DSL to 64 bit */
> >MODIFY_REG(heth->Instance->DMACCR, ETH_DMACCR_DSL, ETH_DMACCR_DSL_64BIT);
> > -#endif /* __rtems__ */
> > +#endif
> >
> >/* Set Receive Buffers Length (must be a multiple of 4) */
> >if ((heth->Init.RxBuffLen % 0x4U) != 0x0U)
> > @@ -2647,7 +2651,7 @@ static void ETH_MAC_MDIO_ClkConfig(ETH_HandleTypeDef
> > *heth)
> >*/
> > static void ETH_DMATxDescListInit(ETH_HandleTypeDef *heth)
> > {
> > -#ifndef __rtems__
> > +#if STM32H7_ADD_LWIP == 1
> >ETH_DMADescTypeDef *dmatxdesc;
> >uint32_t i;
> >
> > @@ -2674,7 +2678,7 @@ static void ETH
RE: [PATCH] covoar: Add option to create named objdumps
ping
> -Original Message-
> From: Alex White
> Sent: Friday, March 12, 2021 11:07 AM
> To: devel@rtems.org
> Cc: Alex White
> Subject: [PATCH] covoar: Add option to create named objdumps
>
> This adds a new behavior to the -d option which allows the creation of
> named objdump outputs in the /tmp directory. This allows the outputs to be
> reused on subsequent runs of covoar rather than running objdump again.
> ---
> tester/covoar/ObjdumpProcessor.cc | 22 +-
> tester/covoar/ObjdumpProcessor.h | 6 --
> tester/covoar/app_common.cc | 10 ++
> tester/covoar/app_common.h| 1 +
> tester/covoar/covoar.cc | 23 +++
> 5 files changed, 47 insertions(+), 15 deletions(-)
>
> diff --git a/tester/covoar/ObjdumpProcessor.cc
> b/tester/covoar/ObjdumpProcessor.cc
> index 9ef2390..fb23ca6 100644
> --- a/tester/covoar/ObjdumpProcessor.cc
> +++ b/tester/covoar/ObjdumpProcessor.cc
> @@ -236,7 +236,8 @@ namespace Coverage {
>void ObjdumpProcessor::getFile(
> std::string fileName,
> rld::process::tempfile& objdumpFile,
> -rld::process::tempfile& err
> +rld::process::tempfile& err,
> +bool debug
> )
>{
> rld::process::statusstatus;
> @@ -245,11 +246,13 @@ namespace Coverage {
> fileName };
> try
> {
> - status = rld::process::execute( TargetInfo->getObjdump(),
> - args, objdumpFile.name(), err.name() );
> - if ( (status.type != rld::process::status::normal)
> - || (status.code != 0) ) {
> -throw rld::error( "Objdump error", "generating objdump" );
> + if (!debug || FileIsNewer( fileName.c_str(), objdumpFile.name().c_str()
> )) {
> +status = rld::process::execute( TargetInfo->getObjdump(),
> +args, objdumpFile.name(), err.name()
> );
> +if ( (status.type != rld::process::status::normal)
> + || (status.code != 0) ) {
> + throw rld::error( "Objdump error", "generating objdump" );
> +}
>}
> } catch( rld::error& err )
>{
> @@ -325,7 +328,8 @@ namespace Coverage {
>void ObjdumpProcessor::load(
> ExecutableInfo* constexecutableInformation,
> rld::process::tempfile& objdumpFile,
> -rld::process::tempfile& err
> +rld::process::tempfile& err,
> +bool debug
>)
>{
> std::string currentSymbol = "";
> @@ -348,9 +352,9 @@ namespace Coverage {
>
> // Obtain the objdump file.
> if ( !executableInformation->hasDynamicLibrary() )
> - getFile( executableInformation->getFileName(), objdumpFile, err );
> + getFile( executableInformation->getFileName(), objdumpFile, err,
> + debug );
> else
> - getFile( executableInformation->getLibraryName(), objdumpFile, err );
> + getFile( executableInformation->getLibraryName(), objdumpFile,
> + err, debug );
>
> while ( true ) {
>// Get the line.
> diff --git a/tester/covoar/ObjdumpProcessor.h
> b/tester/covoar/ObjdumpProcessor.h
> index c75755d..4dab001 100644
> --- a/tester/covoar/ObjdumpProcessor.h
> +++ b/tester/covoar/ObjdumpProcessor.h
> @@ -103,7 +103,8 @@ namespace Coverage {
> */
> void getFile( std::string fileName,
>rld::process::tempfile& dmp,
> - rld::process::tempfile& err );
> + rld::process::tempfile& err,
> + bool debug = false );
>
> /*!
> * This method fills the objdumpList list with all the @@ -122,7 +123,8
> @@
> namespace Coverage {
> void load(
>ExecutableInfo* const executableInformation,
>rld::process::tempfile& dmp,
> - rld::process::tempfile& err
> + rld::process::tempfile& err,
> + bool debug
> );
>
> /*!
> diff --git a/tester/covoar/app_common.cc b/tester/covoar/app_common.cc
> index 8b490ed..0f3c8e2 100644
> --- a/tester/covoar/app_common.cc
> +++ b/tester/covoar/app_common.cc
> @@ -116,3 +116,13 @@ bool ReadUntilFound( FILE *file, const char *line )
>} while (1);
> }
>
> +std::string GetFileNameFromPath( const std::string& path ) {
> + size_t idx = path.rfind('/', path.length());
> + if (idx == std::string::npos) {
> +return "";
> + }
> +
> + return path.substr(idx + 1, path.length() - idx); }
> +
> diff --git a/tester/covoar/app_common.h b/tester/covoar/app_common.h
> index ac32bbd..21e8cfa 100644
> --- a/tester/covoar/app_common.h
> +++ b/tester/covoar/app_common.h
> @@ -30,5 +30,6 @@ extern char
> inputBuffer2[MAX_LINE_LENGTH];
> bool FileIsNewer( const char *f1, const char *f2 ); bool FileIsReadable(
> const
> char *f1 ); bool ReadUntilFound( FILE *file, const char *line );
> +std::string GetFileNameFromPath( const std::string& path );
>
> #endif
> diff --git a/tester/covoar/covoar.cc b/tester/covoar/covoar.cc index
> bf95cb4..6b2082d 1006
Re: Would like to participate in GSoC
Hi Austin, On Mon, Mar 29, 2021 at 2:09 PM Austin J. Anderson wrote: > That is an interesting gmail account. > Hi, I am a Computer Science student studying in university, Would like > to participate in GSoC'21 while contributing to RTEMS this summer. > > This is the ticket which I have selected https://devel.rtems.org/ticket/3314 > As indicated [1], please complete the GSoC Getting Started tutorial we have created: [1] https://devel.rtems.org/wiki/GSoC [2] https://devel.rtems.org/wiki/GSoC/GettingStarted We'll be glad to discuss potential projects, but would like you to work toward completing this activity ASAP. You should start an email thread with the project title in the subject line to increase your chance of getting the right people to notice. Not everyone here reads every message. Gedare > Let me know further details. > > Sincerely, > Austin > ___ > 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: #3860 - GSoC enquiries
On Mon, Mar 29, 2021 at 1:28 PM Ida Delphine wrote: > > Yes I have. But wondering how to run it with the given configuration I saw in > this thread(https://lists.rtems.org/pipermail/devel/2020-October/062770.html). > If you download/copy the configuration into a cfg file, then you can use the examples from https://github.com/uncrustify/uncrustify#running-the-program and attempt to run it on some files within rtems.git/cpukit/score/src would be my suggestion. > On Mon, Mar 29, 2021 at 3:37 PM Gedare Bloom wrote: >> >> Hi Ida, >> >> On Mon, Mar 29, 2021 at 7:36 AM Ida Delphine wrote: >> > >> > Hello, >> > Please do you mind telling me how to run uncrustify with the given >> > configuration with any sample file? >> >> What have you tried? Any directions followed/attempted or notes that >> you have taken would be helpful. >> >> I guess all the info that you should need is in Uncrustify's readme >> file. https://github.com/uncrustify/uncrustify >> >> Did you successfully compile uncrustify tool? >> >> > I'm a bit stuck. >> > >> > Thanks, >> > Ida. >> > >> > On Wed, Mar 17, 2021 at 10:34 PM Gedare Bloom wrote: >> >> >> >> On Wed, Mar 17, 2021 at 2:28 PM Ida Delphine wrote: >> >> > >> >> > Hello, >> >> > So I have gone through this configuration file and I think I'm getting >> >> > it. However I'm a bit lost in the reading the messages in the thread. >> >> > Do you mind explaining? Or we can start talking about a way forward. >> >> > Also can you help me with some steps on how to test this by myself if >> >> > possible? >> >> > >> >> >> >> It may be easier if you go "up" a level to see the full thread >> >> context: >> >> https://lists.rtems.org/pipermail/devel/2020-October/thread.html#62769 >> >> Then you can go through the messages non-linearly. Right now, the >> >> basic idea is to follow the steps outlined in the open project ticket. >> >> I think Christian has summarized it nicely in his recent email [1]: "I >> >> think the contributions from this project that would add value would >> >> be: >> >> 1. Finding a tool and a configuration that can do an RTEMS style or an >> >> acceptable close one. >> >> 2. Adding a "check-style" target to our build system. >> >> 3. Maybe add some kind of script similar to Linux "checkpatch.pl" that >> >> could check whether patches would need changes _before_ they are >> >> applied. >> >> " >> >> >> >> The proposal preparation phase should work through identifying the >> >> options and pros/cons for different tools while preparing a plan for >> >> how to integrate style checks in 2, 3 and thinking through the coding >> >> tasks for the summer. >> >> >> >> Getting the style checking tool's configuration to match with the >> >> RTEMS style will be some effort, and testing it out and submitting >> >> some patches based on it could be a good proposal activity also to >> >> build some confidence about the tools that will be used. >> >> >> >> We also have some Python style guidelines that might be worth >> >> addressing. Those are harder maybe, since the style refactoring might >> >> be challenging to review for correctness. >> >> >> >> For getting started, I would recommend that you try running uncrustify >> >> with the given configuration on some files in RTEMS, see what it >> >> results in. Play around. >> >> >> >> [1] https://lists.rtems.org/pipermail/devel/2021-March/065547.html >> >> >> >> -Gedare >> >> >> >> > Thanks, >> >> > Ida >> >> > >> >> > On Mon, Mar 15, 2021 at 9:39 PM Gedare Bloom wrote: >> >> >> >> >> >> See the related thread, and we'll have to discuss how to move forward. >> >> >> The existing approach provides an uncrustify script: >> >> >> https://lists.rtems.org/pipermail/devel/2020-October/062769.html >> >> >> >> >> >> >> >> >> On Sun, Mar 14, 2021 at 9:47 PM Ida Delphine wrote: >> >> >> > >> >> >> > Hello everyone, >> >> >> > This ticket(https://devel.rtems.org/ticket/3860) was proposed to me >> >> >> > and I'm interested in it for GSoC. >> >> >> > The first task there is to find a code checker or formater that can >> >> >> > produce results that match the RTEMS coding conventions. It also >> >> >> > made mention some tools have been discussed in the past. Please I >> >> >> > will love suggestions on possible tools I could use to achieve this. >> >> >> > >> >> >> > >> >> >> > Cheers, >> >> >> > Ida. >> >> >> > ___ >> >> >> > 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 rtems-docs v2] User/BSPs/Beagle: Add JTAG debugger section
looks fine to me On Mon, Mar 29, 2021 at 1:12 PM Christian Mauderer wrote: > > --- > user/bsps/arm/beagle.rst | 67 ++-- > 1 file changed, 65 insertions(+), 2 deletions(-) > > diff --git a/user/bsps/arm/beagle.rst b/user/bsps/arm/beagle.rst > index ac49b1c..5789bb8 100644 > --- a/user/bsps/arm/beagle.rst > +++ b/user/bsps/arm/beagle.rst > @@ -102,8 +102,8 @@ The function prototype is given below: > rtems_vector_number irq > ); > > -Debugging > -- > +Debugging using libdebugger > +--- > > RTEMS's ``libdebugger`` requires the ARM debug resources be enabled for it to > work. The TI SOC used on the ``beagleboneblack`` board provides no access for > @@ -162,3 +162,66 @@ If ``libdebugger`` fails to detect the registers open > the ``bspdebug.c`` > source and change ``has_tdo`` to ``1``, save then rebuild and install the > BSP. This will turn on an internal feeback to check the JTAG logic. Discard > the edit once the hardware is working. > + > +Debugging Beagle Bone Black using a JTAG debugger and gdb > +- > + > +Debugging a Beagle Bone Black (or variants) is also possible using a hardware > +JTAG debugger. The JTAG is available via P2. The footprint is for an ARM 20 > pin > +cTI connector. That connector should be used, if it is necessary to have > access > +to commercially available adapters. > + > +For hand-made cables and adapters a standard 1.27mm pitch header and a > 0.635mm > +ribbon cable can be much cheaper. But note that even if it looks compatible, > +it's not the same pin out as a ARM Cortex 20 pin connector! > + > +A lot of JTAG adapters that are working together with OpenOCD will work. > There > +are also commercially available systems (like Segger J-Link) that work well > with > +the Beagle. Note that the JTAG debugger has to be compatible with ARM Cortex > A8. > +Cortex M only debuggers (like the Segger J-Link Edu Mini) won't work. > + > +If the debugger offers a gdb server (like OpenOCD or Segger J-Link) the > +following gdb start script can be used: > + > +.. code-block:: > + > +define reset > +echo -- Reset target and wait for U-Boot to start kernel.\n > +monitor reset > +# RTEMS U-Boot starts at this address. > +tbreak *0x8000 > +# Linux starts here. > +tbreak *0x8200 > +continue > + > +echo -- Disable watchdog.\n > +set *(uint32_t*)0x44e35048=0x > +while (*(uint32_t*)0x44e35034 != 0) > +end > +set *(uint32_t*)0x44e35048=0x > +while (*(uint32_t*)0x44e35034 != 0) > +end > + > +echo -- Overwrite kernel with application to debug.\n > +load > +end > + > +target remote :2331 > + > +Note that you might have to replace the ``monitor reset`` by some other > command > +that resets the target using your specific debugger. You also have to replace > +the ``target remote :2331`` to match the port of your gdb server. > + > +The script expects that the Beagle Bone Black starts some application from > an SD > +card or from eMMC. It defines a ``reset`` command that does the following: > + > + * reset the target > + * let U-Boot run, initialize the base system, load an FDT and an application > + * break at the application entry point > + * disable the watchdog > + * overwrite the application that has been loaded by U-Boot with the > application > + provided as an command line argument to gdb > + > +This method has the advantage that the application is executed in nearly the > +same environment like it would be executed if loaded by U-Boot directly > (except > +for the watchdog). > -- > 2.30.2 > > ___ > 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] coverage/symbol-sets.ini : Add libtrace
Ok, thanks. On Mon, Mar 29, 2021 at 2:19 PM Alex White wrote: > > On Sat, Mar 27, 2021 at 9:46 AM Gedare Bloom wrote: > > > > On Fri, Mar 12, 2021 at 10:17 AM Alex White wrote: > > > > > > --- > > > tester/rtems/testing/coverage/symbol-sets.ini | 3 ++- > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > diff --git a/tester/rtems/testing/coverage/symbol-sets.ini > > > b/tester/rtems/testing/coverage/symbol-sets.ini > > > index 9617dd8..52e25ff 100644 > > > --- a/tester/rtems/testing/coverage/symbol-sets.ini > > > +++ b/tester/rtems/testing/coverage/symbol-sets.ini > > > @@ -29,7 +29,7 @@ > > > # > > > > > > [symbol-sets] > > > -sets = > > > score,rtems,sapi,posix,librfs,libpipe,libdosfs,libimfs,libjffs2,libcsupport,libbspcmdline,libcpuuse,libstackchk,libfsmount,libstringto,libdevnull,libdumpbuf,libuntar,libblock,libcrypt,libmd,libstdthreads > > > +sets = > > > score,rtems,sapi,posix,librfs,libpipe,libdosfs,libimfs,libjffs2,libcsupport,libbspcmdline,libcpuuse,libstackchk,libfsmount,libstringto,libdevnull,libdumpbuf,libuntar,libblock,libcrypt,libmd,libstdthreads,libtrace > > > > > ok, but this is really ugly. is the comma-separated list with no > > whitespace mandatory, or can it be reformatted in a follow-up patch? > > Currently, it is mandatory because the coverage.py script does not remove > whitespace when processing the values, it simply splits them on ',' > characters. > > It can be reformatted in a follow-up patch to look something like this: > > sets = > score,rtems,sapi,posix,librfs,libpipe,libdosfs,libimfs,libjffs2,libcsupport, > libbspcmdline,libcpuuse,libstackchk,libfsmount,libstringto,libdevnull, > libdumpbuf,libuntar,libblock,libcrypt,libmd,libstdthreads,libtrace > > As long as subsequent lines are indented (to comply with Python's > ConfigParser format), it should work fine assuming logic is added to call > strip() on the values in the parse() method of the symbol_parser class in > coverage.py. > > > > > > [libraries] > > > score = @BUILD-TARGET@/@BSP@/cpukit/score/src > > > @@ -76,4 +76,5 @@ libblock = @BUILD-TARGET@/@BSP@/cpukit/libblock/src > > > libcrypt = @BUILD-TARGET@/@BSP@/cpukit/libcrypt > > > libmd = @BUILD-TARGET@/@BSP@/cpukit/libmd > > > libstdthreads = @BUILD-TARGET@/@BSP@/cpukit/libstdthreads > > > +libtrace = @BUILD-TARGET@/@BSP@/cpukit/libtrace/record > > > #zlib = @BUILD-TARGET@/@BSP@/cpukit/zlib > > > -- > > > 2.27.0 > > > > > > ___ > > > 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: [PATCH] covoar: Add option to create named objdumps
On Fri, Mar 12, 2021 at 10:07 AM Alex White wrote:
>
> This adds a new behavior to the -d option which allows the creation of
> named objdump outputs in the /tmp directory. This allows the outputs to
> be reused on subsequent runs of covoar rather than running objdump
> again.
This seems to be a hackish way to optimize a behavior. Do you guys
have a plan to improve this caching mechanism?
> ---
> tester/covoar/ObjdumpProcessor.cc | 22 +-
> tester/covoar/ObjdumpProcessor.h | 6 --
> tester/covoar/app_common.cc | 10 ++
> tester/covoar/app_common.h| 1 +
> tester/covoar/covoar.cc | 23 +++
> 5 files changed, 47 insertions(+), 15 deletions(-)
>
> diff --git a/tester/covoar/ObjdumpProcessor.cc
> b/tester/covoar/ObjdumpProcessor.cc
> index 9ef2390..fb23ca6 100644
> --- a/tester/covoar/ObjdumpProcessor.cc
> +++ b/tester/covoar/ObjdumpProcessor.cc
> @@ -236,7 +236,8 @@ namespace Coverage {
>void ObjdumpProcessor::getFile(
> std::string fileName,
> rld::process::tempfile& objdumpFile,
> -rld::process::tempfile& err
> +rld::process::tempfile& err,
> +bool debug
> )
>{
> rld::process::statusstatus;
> @@ -245,11 +246,13 @@ namespace Coverage {
> fileName };
> try
> {
> - status = rld::process::execute( TargetInfo->getObjdump(),
> - args, objdumpFile.name(), err.name() );
> - if ( (status.type != rld::process::status::normal)
> - || (status.code != 0) ) {
> -throw rld::error( "Objdump error", "generating objdump" );
> + if (!debug || FileIsNewer( fileName.c_str(),
> objdumpFile.name().c_str() )) {
what's this !debug
Relying on timestamps can be tricky. You all should consider how to
create a proper cache of files, probably in the local directory from
which this tool is run, that updates based on hashed contents of the
source files rather than timestamps. This is for your TODO list.
> +status = rld::process::execute( TargetInfo->getObjdump(),
> +args, objdumpFile.name(), err.name()
> );
> +if ( (status.type != rld::process::status::normal)
> + || (status.code != 0) ) {
> + throw rld::error( "Objdump error", "generating objdump" );
> +}
>}
> } catch( rld::error& err )
>{
> @@ -325,7 +328,8 @@ namespace Coverage {
>void ObjdumpProcessor::load(
> ExecutableInfo* constexecutableInformation,
> rld::process::tempfile& objdumpFile,
> -rld::process::tempfile& err
> +rld::process::tempfile& err,
> +bool debug
>)
>{
> std::string currentSymbol = "";
> @@ -348,9 +352,9 @@ namespace Coverage {
>
> // Obtain the objdump file.
> if ( !executableInformation->hasDynamicLibrary() )
> - getFile( executableInformation->getFileName(), objdumpFile, err );
> + getFile( executableInformation->getFileName(), objdumpFile, err, debug
> );
> else
> - getFile( executableInformation->getLibraryName(), objdumpFile, err );
> + getFile( executableInformation->getLibraryName(), objdumpFile, err,
> debug );
>
> while ( true ) {
>// Get the line.
> diff --git a/tester/covoar/ObjdumpProcessor.h
> b/tester/covoar/ObjdumpProcessor.h
> index c75755d..4dab001 100644
> --- a/tester/covoar/ObjdumpProcessor.h
> +++ b/tester/covoar/ObjdumpProcessor.h
> @@ -103,7 +103,8 @@ namespace Coverage {
> */
> void getFile( std::string fileName,
>rld::process::tempfile& dmp,
> - rld::process::tempfile& err );
> + rld::process::tempfile& err,
> + bool debug = false );
>
> /*!
> * This method fills the objdumpList list with all the
> @@ -122,7 +123,8 @@ namespace Coverage {
> void load(
>ExecutableInfo* const executableInformation,
>rld::process::tempfile& dmp,
> - rld::process::tempfile& err
> + rld::process::tempfile& err,
> + bool debug
> );
>
> /*!
> diff --git a/tester/covoar/app_common.cc b/tester/covoar/app_common.cc
> index 8b490ed..0f3c8e2 100644
> --- a/tester/covoar/app_common.cc
> +++ b/tester/covoar/app_common.cc
> @@ -116,3 +116,13 @@ bool ReadUntilFound( FILE *file, const char *line )
>} while (1);
> }
>
> +std::string GetFileNameFromPath( const std::string& path )
> +{
> + size_t idx = path.rfind('/', path.length());
Are there any library helpers that can do this?
What happens if you run this on windows? (I know the answer, this
stuff doesn't work on windows. But it doesn't mean we shouldn't
consider cross-platform issues?)
> + if (idx == std::string::npos) {
> +return "";
> + }
> +
> + return path.substr(idx + 1, path.length() - idx);
> +}
> +
> diff --git a/tester/covoar/app_common.h b/tester/covoar/app_common.h
> index ac32bbd.
Re: [PATCH] covoar: Add option to create named objdumps
On 30/3/21 7:56 am, Gedare Bloom wrote:
> On Fri, Mar 12, 2021 at 10:07 AM Alex White wrote:
>>
>> This adds a new behavior to the -d option which allows the creation of
>> named objdump outputs in the /tmp directory. This allows the outputs to
>> be reused on subsequent runs of covoar rather than running objdump
>> again.
> This seems to be a hackish way to optimize a behavior. Do you guys
> have a plan to improve this caching mechanism?
Agreed. If objdump and generated files is being used then caching and management
across instances of covoar will be complex but that is one of the trade-offs
when wrapping objdump.
>> -throw rld::error( "Objdump error", "generating objdump" );
>> + if (!debug || FileIsNewer( fileName.c_str(),
>> objdumpFile.name().c_str() )) {
> what's this !debug
>
> Relying on timestamps can be tricky. You all should consider how to
> create a proper cache of files, probably in the local directory from
> which this tool is run, that updates based on hashed contents of the
> source files rather than timestamps. This is for your TODO list.
The commit comment says the files are in /tmp. Using /tmp to hold files that are
not temporary seems the contradict the idea of a temporary directory.
Who cleans up the files in /tmp that are left there?
>> +{
>> + size_t idx = path.rfind('/', path.length());
> Are there any library helpers that can do this?
>
> What happens if you run this on windows? (I know the answer, this
> stuff doesn't work on windows. But it doesn't mean we shouldn't
> consider cross-platform issues?)
Windows is a supported host for this project so I hope it is tested on Windows.
Not building or not working just means someone else needs to fix the problem.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] coverage/symbol-sets.ini : Add libtrace
On 30/3/21 7:19 am, Alex White wrote: > On Sat, Mar 27, 2021 at 9:46 AM Gedare Bloom wrote: >> >> On Fri, Mar 12, 2021 at 10:17 AM Alex White wrote: >>> >>> --- >>> tester/rtems/testing/coverage/symbol-sets.ini | 3 ++- >>> 1 file changed, 2 insertions(+), 1 deletion(-) >>> >>> diff --git a/tester/rtems/testing/coverage/symbol-sets.ini >>> b/tester/rtems/testing/coverage/symbol-sets.ini >>> index 9617dd8..52e25ff 100644 >>> --- a/tester/rtems/testing/coverage/symbol-sets.ini >>> +++ b/tester/rtems/testing/coverage/symbol-sets.ini >>> @@ -29,7 +29,7 @@ >>> # >>> >>> [symbol-sets] >>> -sets = >>> score,rtems,sapi,posix,librfs,libpipe,libdosfs,libimfs,libjffs2,libcsupport,libbspcmdline,libcpuuse,libstackchk,libfsmount,libstringto,libdevnull,libdumpbuf,libuntar,libblock,libcrypt,libmd,libstdthreads >>> +sets = >>> score,rtems,sapi,posix,librfs,libpipe,libdosfs,libimfs,libjffs2,libcsupport,libbspcmdline,libcpuuse,libstackchk,libfsmount,libstringto,libdevnull,libdumpbuf,libuntar,libblock,libcrypt,libmd,libstdthreads,libtrace >>> >> ok, but this is really ugly. is the comma-separated list with no >> whitespace mandatory, or can it be reformatted in a follow-up patch? > > Currently, it is mandatory because the coverage.py script does not remove > whitespace when processing the values, it simply splits them on ',' > characters. > > It can be reformatted in a follow-up patch to look something like this: > > sets = > score,rtems,sapi,posix,librfs,libpipe,libdosfs,libimfs,libjffs2,libcsupport, > libbspcmdline,libcpuuse,libstackchk,libfsmount,libstringto,libdevnull, > libdumpbuf,libuntar,libblock,libcrypt,libmd,libstdthreads,libtrace > > As long as subsequent lines are indented (to comply with Python's > ConfigParser format), it should work fine assuming logic is added to call > strip() on the values in the parse() method of the symbol_parser class in > coverage.py. Maybe the better solution is to use the toolkit's `configuraiton` module which manages a number of things including this (see comma_list [1]). I suggest you investigate this path. Chris [1] https://git.rtems.org/rtems-tools/tree/rtemstoolkit/configuration.py#n141 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RE: [PATCH] covoar: Add option to create named objdumps
On Mon, Mar 29, 2021 at 4:39 PM Chris Johns wrote:
>
> On 30/3/21 7:56 am, Gedare Bloom wrote:
> > On Fri, Mar 12, 2021 at 10:07 AM Alex White wrote:
> >>
> >> This adds a new behavior to the -d option which allows the creation of
> >> named objdump outputs in the /tmp directory. This allows the outputs to
> >> be reused on subsequent runs of covoar rather than running objdump
> >> again.
> > This seems to be a hackish way to optimize a behavior. Do you guys
> > have a plan to improve this caching mechanism?
>
> Agreed. If objdump and generated files is being used then caching and
> management
> across instances of covoar will be complex but that is one of the trade-offs
> when wrapping objdump.
At the moment, there is no plan to improve it, no.
The original behavior of -d was just to keep the temp files around after a run.
This change augments that behavior to also give the temp files useful names. It
allows for a nice speedup when trying to do multiple runs for debugging
purposes since the temp files can now be checked to see if they need to be
regenerated.
Ideally, yes, this would be more sophisticated and less hackish. I hid it behind
the debug flag since it was added as a means to test my changes more quickly
rather than as a fully-fledged file caching feature.
If the caching mechanism were improved, I would likely move it to its own flag.
That would allow the speedup to be realized on more than just debug runs.
>
> >> - throw rld::error( "Objdump error", "generating objdump" );
> >> + if (!debug || FileIsNewer( fileName.c_str(),
> >> objdumpFile.name().c_str() )) {
> > what's this !debug
`debug` is set at the top level to `true` if the "-d" option is provided, false
otherwise.
> >
> > Relying on timestamps can be tricky. You all should consider how to
> > create a proper cache of files, probably in the local directory from
> > which this tool is run, that updates based on hashed contents of the
> > source files rather than timestamps. This is for your TODO list.
>
> The commit comment says the files are in /tmp. Using /tmp to hold files that
> are
> not temporary seems the contradict the idea of a temporary directory.
>
> Who cleans up the files in /tmp that are left there?
The original behavior of the "-d" option was to preserve the generated files in
the /tmp directory, I believe.
This behavior is unchanged.
>
> >> +{
> >> + size_t idx = path.rfind('/', path.length());
> > Are there any library helpers that can do this?
None that I have found.
> >
> > What happens if you run this on windows? (I know the answer, this
> > stuff doesn't work on windows. But it doesn't mean we shouldn't
> > consider cross-platform issues?)
>
> Windows is a supported host for this project so I hope it is tested on
> Windows.
> Not building or not working just means someone else needs to fix the problem.
I was only running with `-d` on Linux and FreeBSD so I wasn't thinking about it.
Should I change it to handle separators on Windows using an ifdef?
>
> Chris
> ___
> 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: Ticket#3889 updated
Sorry that assumption was very native of me that i didn't have a working baseline. Joel said that the erc32 was similar to the leon bsp " The ERC32 what's the first space hardened sparc processor. The leon3 is a later processor in the same family. Both use the same build of GCC and are just different bsps. In fact both run on the same sis simulator. " I also though that the bsps were the same and I can work on the issue with only the erc32 BSP. I have one more question: when i run the hello world test. All the test files are within one specific directory and I don't see the executables for specific bsps that's why i thought all tests would be built (there would not be any specific considerations for bsps) . Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Monday, March 29, 2021 2:45 PM, Gedare Bloom wrote: > On Sun, Mar 28, 2021 at 1:26 PM zack_on_the_speed_chanel > zack_on_the_speed_cha...@protonmail.ch wrote: > > > Hello all, > > I'm updating on what' i've found out with the issue (forgot to reply all) . > > Joel recommended me check the coverage for the leon BSP( to check if it's > > supported) and i found that the branch with CLOCK_MONOTONIC was not reached > > I think now that it's supported (because the annotated assembly is in the > > sparc instruction set). I also found out that the test would be similar to > > Psxclock02 and it runs the same tests on a different clock. Then I tried to > > build the psxclock02 test , change the create_clock to have the > > clock_monotonic argument and i didn't see the executable or any change in > > the ./waf build. Then I was suggested that you have to enable all tests > > some how? How do i enable all tests? > > Do you use something like: ./waf bsp_defaults ---rtems-bsp=leon3 > config.ini > > Then, take a look, BUILD_TESTS and BUILD_PSXTESTS are two options that > if either is True it should build psxclock02. > > When you write code, you should first make sure you can build the code > as it exists if it is supposed to work, and run it to see that it > works. Then you should make changes from a working baseline. Otherwise > when you get a problem, how do you know if the problem is your > problem, or it already existed? > > > Thanks > > Zack > > > > 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] covoar: Add option to create named objdumps
On 30/3/21 9:10 am, Alex White wrote:
> On Mon, Mar 29, 2021 at 4:39 PM Chris Johns wrote:
>>
>> On 30/3/21 7:56 am, Gedare Bloom wrote:
>>> On Fri, Mar 12, 2021 at 10:07 AM Alex White wrote:
This adds a new behavior to the -d option which allows the creation of
named objdump outputs in the /tmp directory. This allows the outputs to
be reused on subsequent runs of covoar rather than running objdump
again.
>>> This seems to be a hackish way to optimize a behavior. Do you guys
>>> have a plan to improve this caching mechanism?
>>
>> Agreed. If objdump and generated files is being used then caching and
>> management
>> across instances of covoar will be complex but that is one of the trade-offs
>> when wrapping objdump.
>
> At the moment, there is no plan to improve it, no.
>
> The original behavior of -d was just to keep the temp files around after a
> run.
> This change augments that behavior to also give the temp files useful names.
> It
> allows for a nice speedup when trying to do multiple runs for debugging
> purposes since the temp files can now be checked to see if they need to be
> regenerated.
This is different to improving performance and that is what the commit comments
say. And changing the commit comments now to discuss a debug option that is
there for performance testing only makes life harder for us as reviewers.
> Ideally, yes, this would be more sophisticated and less hackish. I hid it
> behind
> the debug flag since it was added as a means to test my changes more quickly
> rather than as a fully-fledged file caching feature.
Great and so it seems the test has worked. There is no need to merge the test
code. A full solution would be welcome.
> If the caching mechanism were improved, I would likely move it to its own
> flag.
> That would allow the speedup to be realized on more than just debug runs.
Great, sounds like a plan.
- throw rld::error( "Objdump error", "generating objdump" );
+ if (!debug || FileIsNewer( fileName.c_str(),
objdumpFile.name().c_str() )) {
>>> what's this !debug
>
> `debug` is set at the top level to `true` if the "-d" option is provided,
> false
> otherwise.
Yes I know. I changed that top level to be more C++ 3 years ago unfunded to try
and provide a pathway for more changes to happen.
>>> Relying on timestamps can be tricky. You all should consider how to
>>> create a proper cache of files, probably in the local directory from
>>> which this tool is run, that updates based on hashed contents of the
>>> source files rather than timestamps. This is for your TODO list.
>>
>> The commit comment says the files are in /tmp. Using /tmp to hold files that
>> are
>> not temporary seems the contradict the idea of a temporary directory.
>>
>> Who cleans up the files in /tmp that are left there?
>
> The original behavior of the "-d" option was to preserve the generated files
> in the /tmp directory, I believe.
This is the part that is disconnected and does not match. I am concerned it
becomes a back door performance hack. Some systems use RAM disks for /tmp for
performance so having it fill would be a problem.
> This behavior is unchanged.
I think it is changed with this patch.
+{
+ size_t idx = path.rfind('/', path.length());
>>> Are there any library helpers that can do this?
>
> None that I have found.
H
https://git.rtems.org/rtems-tools/tree/rtemstoolkit/rld-path.h#n44
This is not the first tool in our tool suite that has had to deal with this.
>>>
>>> What happens if you run this on windows? (I know the answer, this
>>> stuff doesn't work on windows. But it doesn't mean we shouldn't
>>> consider cross-platform issues?)
>>
>> Windows is a supported host for this project so I hope it is tested on
>> Windows.
>> Not building or not working just means someone else needs to fix the problem.
>
> I was only running with `-d` on Linux and FreeBSD so I wasn't thinking about
> it.
>
> Should I change it to handle separators on Windows using an ifdef?
No. I suggest to stop guessing and testing our patience.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems 01/18] Broke low-level parts of mv643xx_eth driver into separate files
From: till straumann Update #4344 --- bsps/powerpc/beatnik/headers.am |1 + .../powerpc/beatnik/include/bsp/mv643xx_eth.h | 111 + bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c | 1162 +- .../beatnik/net/if_mve/mv643xx_eth_bsdnet.c | 3519 + c/src/lib/libbsp/powerpc/beatnik/Makefile.am |4 +- 5 files changed, 3659 insertions(+), 1138 deletions(-) create mode 100644 bsps/powerpc/beatnik/include/bsp/mv643xx_eth.h create mode 100644 bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c diff --git a/bsps/powerpc/beatnik/headers.am b/bsps/powerpc/beatnik/headers.am index 36df3cd759..8416bbd626 100644 --- a/bsps/powerpc/beatnik/headers.am +++ b/bsps/powerpc/beatnik/headers.am @@ -20,3 +20,4 @@ include_bsp_HEADERS += ../../../../../../bsps/powerpc/beatnik/include/bsp/if_em_ include_bsp_HEADERS += ../../../../../../bsps/powerpc/beatnik/include/bsp/if_gfe_pub.h include_bsp_HEADERS += ../../../../../../bsps/powerpc/beatnik/include/bsp/if_mve_pub.h include_bsp_HEADERS += ../../../../../../bsps/powerpc/beatnik/include/bsp/irq.h +include_bsp_HEADERS += ../../../../../../bsps/powerpc/beatnik/include/bsp/mv643xx_eth.h diff --git a/bsps/powerpc/beatnik/include/bsp/mv643xx_eth.h b/bsps/powerpc/beatnik/include/bsp/mv643xx_eth.h new file mode 100644 index 00..eefca62603 --- /dev/null +++ b/bsps/powerpc/beatnik/include/bsp/mv643xx_eth.h @@ -0,0 +1,111 @@ +#ifndef MV643XX_LOWLEVEL_DRIVER_H +#define MV643XX_LOWLEVEL_DRIVER_H + +struct mveth_private; + +/* Clear multicast filters*/ +void +BSP_mve_mcast_filter_clear(struct mveth_private *mp); +void +BSP_mve_mcast_filter_accept_all(struct mveth_private *mp); +void +BSP_mve_mcast_filter_accept_add(struct mveth_private *mp, unsigned char *enaddr); +void +BSP_mve_mcast_filter_accept_del(struct mveth_private *mp, unsigned char *enaddr); +/* Stop hardware and clean out the rings */ +void +BSP_mve_stop_hw(struct mveth_private *mp); + +struct mveth_private * +BSP_mve_setup_1( + struct mveth_private*, + int unit, + void (*isr)(void *isr_arg), + void *isr_arg, + void (*cleanup_txbuf)(void *user_buf, void *closure, int error_on_tx_occurred), + void *cleanup_txbuf_arg, + void *(*alloc_rxbuf)(int *p_size, uintptr_t *p_data_addr), + void (*consume_rxbuf)(void *user_buf, void *closure, int len), + void *consume_rxbuf_arg, + int rx_ring_size, + int tx_ring_size, + int irq_mask +); + +/* MAIN RX-TX ROUTINES + * + * BSP_mve_swipe_tx(): descriptor scavenger; releases mbufs + * BSP_mve_send_buf(): xfer mbufs from IF to chip + * BSP_mve_swipe_rx(): enqueue received mbufs to interface + *allocate new ones and yield them to the + *chip. + */ + +/* clean up the TX ring freeing up buffers */ +int +BSP_mve_swipe_tx(struct mveth_private *mp); +int +BSP_mve_send_buf_raw( + struct mveth_private *mp, + void *head_p, + int h_len, + void *data_p, +int d_len); +/* send received buffers upwards and replace them + * with freshly allocated ones; + * ASSUMPTION: buffer length NEVER changes and is set + * when the ring is initialized. + * TS 20060727: not sure if this assumption is still necessary - I believe it isn't. + */ +int +BSP_mve_swipe_rx(struct mveth_private *mp); + +rtems_id +BSP_mve_get_tid(struct mveth_private *mp); +int +BSP_mve_detach(struct mveth_private *mp); + +/* Fire up the low-level driver + * + * - make sure hardware is halted + * - enable cache snooping + * - clear address filters + * - clear mib counters + * - reset phy + * - initialize (or reinitialize) descriptor rings + * - check that the firmware has set up a reasonable mac address. + * - generate unicast filter entry for our mac address + * - write register config values to the chip + * - start hardware (serial port and SDMA) + */ + +void +BSP_mve_init_hw(struct mveth_private *mp, int promisc, unsigned char *enaddr); + +/* read ethernet address from hw to buffer */ +void +BSP_mve_read_eaddr(struct mveth_private *mp, unsigned char *oeaddr); + +void +BSP_mve_enable_irqs(struct mveth_private *mp); +void +BSP_mve_disable_irqs(struct mveth_private *mp); +uint32_t +BSP_mve_ack_irqs(struct mveth_private *mp); +void +BSP_mve_enable_irq_mask(struct mveth_private *mp, uint32_t mask); +uint32_t +BSP_mve_disable_irq_mask(struct mveth_private *mp, uint32_t mask); +uint32_t +BSP_mve_ack_irq_mask(struct mveth_private *mp, uint32_t mask); + +void +BSP_mve_dump_stats(struct mveth_private *mp, FILE *f); + +unsigned +BSP_mve_mii_read(struct mveth_private *mp, unsigned addr); + +unsigned +BSP_mve_mii_write(struct mveth_private *mp, unsigned addr, unsigned v); + +#endif diff --git a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
[PATCH rtems 03/18] verified that we can compile with MVETH_TESTING and MVETH_DEBUG
From: till straumann
Update #4344
---
bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c | 59 +++
.../beatnik/net/if_mve/mv643xx_eth_bsdnet.c | 1 -
2 files changed, 47 insertions(+), 13 deletions(-)
diff --git a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
index 26fe7db9e6..9d23d22898 100644
--- a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
+++ b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
@@ -108,16 +108,10 @@
/* Compile-time debugging features */
/* Enable paranoia assertions and checks; reduce # of descriptors to minimum
for stressing */
-#undef MVETH_TESTING
+#define MVETH_TESTING
/* Enable debugging messages and some support routines (dump rings etc.)
*/
-#undef MVETH_DEBUG
-
-/* Hack for driver development; rtems bsdnet doesn't implement detaching an
interface :-(
- * but this hack allows us to unload/reload the driver module which makes
development
- * a lot less painful.
- */
-#undef MVETH_DETACH_HACK
+#define MVETH_DEBUG
/* Ring sizes */
@@ -790,6 +784,15 @@ static const char *mibfmt[] = {
/* forward decls + implementation for IRQ API funcs */
+STATIC int
+mveth_init_rx_desc_ring(struct mveth_private *mp);
+
+STATIC int
+mveth_init_tx_desc_ring(struct mveth_private *mp);
+
+int
+BSP_mve_dring_nonsync(struct mveth_private *mp);
+
static void mveth_isr(rtems_irq_hdl_param unit);
static void noop(const rtems_irq_connect_data *unused) {}
static int noop1(const rtems_irq_connect_data *unused) { return 0; }
@@ -1747,7 +1750,7 @@ MveEthBufIter head = *it;
#ifdef MVETH_TESTING
assert( !h->buf_ptr );
- assert( !h->mb );
+ assert( !h->u_buf );
#endif
/* Don't use the first descriptor yet because BSP_mve_swipe_tx()
@@ -1778,7 +1781,7 @@ MveEthBufIter head = *it;
*/
for ( l = NEXT_TXD(h); l!=d; l=NEXT_TXD(l) ) {
#ifdef MVETH_TESTING
- assert( l->mb == 0 );
+ assert( l->u_buf == 0 );
#endif
l->buf_ptr = 0;
l->cmd_sts = 0;
@@ -1870,7 +1873,7 @@ int frst_len;
rval = 0;
#ifdef MVETH_TESTING
- assert(header || data);
+ assert(head_p || data_p);
#endif
needed = head_p && data_p ? 2 : 1;
@@ -1887,7 +1890,7 @@ int frst_len;
#ifdef MVETH_TESTING
assert( !h->buf_ptr );
- assert( !h->mb );
+ assert( !h->u_buf );
#endif
/* find the 'first' user buffer */
@@ -2359,3 +2362,35 @@ uint32_t v;
}
fprintf(f, "\n");
}
+
+#ifdef MVETH_DEBUG
+/* Display/dump descriptor rings */
+
+/* These low-level routines need to be synchronized with
+ * any Tx/Rx threads!
+ */
+int
+BSP_mve_dring_nonsync(struct mveth_private *mp)
+{
+int i;
+if (1) {
+MvEthRxDesc pr;
+printf("RX:\n");
+
+ for (i=0, pr=mp->rx_ring; irbuf_count; i++, pr++) {
+ printf("cnt: 0x%04x, size: 0x%04x, stat: 0x%08x, next: 0x%08x,
buf: 0x%08x\n",
+ pr->byte_cnt, pr->buf_size, pr->cmd_sts,
(uint32_t)pr->next_desc_ptr, pr->buf_ptr);
+ }
+}
+if (1) {
+MvEthTxDesc pt;
+printf("TX:\n");
+ for (i=0, pt=mp->tx_ring; ixbuf_count; i++, pt++) {
+ printf("cnt: 0x%04x, stat: 0x%08x, next: 0x%08x, buf: 0x%08x,
mb: 0x%08x\n",
+ pt->byte_cnt, pt->cmd_sts, (uint32_t)pt->next_desc_ptr,
pt->buf_ptr,
+ (uint32_t)pt->u_buf);
+ }
+}
+ return 0;
+}
+#endif
diff --git a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
index 2e841c5e8b..3f85e2c78a 100644
--- a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
+++ b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
@@ -135,7 +135,6 @@
/* Enable Hardware Snooping; if this is disabled (undefined),
* cache coherency is maintained by software.
*/
-#undef ENABLE_HW_SNOOPING
/* Compile-time debugging features */
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems 04/18] removed direct access to ring-size / ring-available from BSD driver
From: till straumann
Update #4344
---
bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c | 6 +++---
.../beatnik/net/if_mve/mv643xx_eth_bsdnet.c| 14 +-
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
index 9d23d22898..1d920df342 100644
--- a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
+++ b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
@@ -108,10 +108,10 @@
/* Compile-time debugging features */
/* Enable paranoia assertions and checks; reduce # of descriptors to minimum
for stressing */
-#define MVETH_TESTING
+#undef MVETH_TESTING
/* Enable debugging messages and some support routines (dump rings etc.)
*/
-#define MVETH_DEBUG
+#undef MVETH_DEBUG
/* Ring sizes */
@@ -1726,7 +1726,7 @@ register MvEthTxDesc d;
mp->d_tx_t = d;
mp->avail += rval;
- return rval;
+ return mp->avail;
}
int
diff --git a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
index 3f85e2c78a..e8819be6bf 100644
--- a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
+++ b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
@@ -135,6 +135,7 @@
/* Enable Hardware Snooping; if this is disabled (undefined),
* cache coherency is maintained by software.
*/
+#undef ENABLE_HW_SNOOPING
/* Compile-time debugging features */
@@ -543,6 +544,8 @@ typedef uint32_t Dma_addr_t;
/* stuff needed for bsdnet support */
struct mveth_bsdsupp {
int oif_flags;
/* old / cached if_flags */
+ int tx_ring_size;
+ int rx_ring_size;
};
struct mveth_softc {
@@ -665,6 +668,9 @@ struct mveth_private *mp;
}
}
+ theMvEths[unit-1].bsd.tx_ring_size = tx_ring_size;
+ theMvEths[unit-1].bsd.rx_ring_size = rx_ring_size;
+
/* mark as used */
ifp->if_init = (void*)(-1);
@@ -1172,6 +1178,7 @@ static void mveth_daemon(void *arg)
struct mveth_softc *sc;
struct ifnet *ifp;
rtems_event_setevs;
+int avail;
for (;;) {
rtems_bsdnet_event_receive( 7, RTEMS_WAIT | RTEMS_EVENT_ANY,
RTEMS_NO_TIMEOUT, &evs );
evs &= 7;
@@ -1211,13 +1218,10 @@ rtems_event_set evs;
}
}
/* free tx chain */
- if ( (MV643XX_ETH_EXT_IRQ_TX_DONE & x) &&
BSP_mve_swipe_tx(sc->pvt) ) {
+ if ( (MV643XX_ETH_EXT_IRQ_TX_DONE & x) &&
(avail = BSP_mve_swipe_tx(sc->pvt)) > 0 ) {
ifp->if_flags &= ~IFF_OACTIVE;
-#warning FIXME
-#ifdef BSDBSD
- if ( TX_AVAILABLE_RING_SIZE(sc->pvt) ==
sc->pvt->avail )
+ if ( sc->bsd.tx_ring_size == avail )
ifp->if_timer = 0;
-#endif
mveth_start(ifp);
}
if ( (MV643XX_ETH_IRQ_RX_DONE & x) )
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems 02/18] first version with mv643xx eth driver broken into pieces which compiles
From: till straumann
Update #4344
---
.../powerpc/beatnik/include/bsp/mv643xx_eth.h | 85 +-
bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c | 343 ++-
.../beatnik/net/if_mve/mv643xx_eth_bsdnet.c | 2601 ++---
3 files changed, 575 insertions(+), 2454 deletions(-)
diff --git a/bsps/powerpc/beatnik/include/bsp/mv643xx_eth.h
b/bsps/powerpc/beatnik/include/bsp/mv643xx_eth.h
index eefca62603..f963b91d3d 100644
--- a/bsps/powerpc/beatnik/include/bsp/mv643xx_eth.h
+++ b/bsps/powerpc/beatnik/include/bsp/mv643xx_eth.h
@@ -3,24 +3,11 @@
struct mveth_private;
-/* Clear multicast filters*/
-void
-BSP_mve_mcast_filter_clear(struct mveth_private *mp);
-void
-BSP_mve_mcast_filter_accept_all(struct mveth_private *mp);
-void
-BSP_mve_mcast_filter_accept_add(struct mveth_private *mp, unsigned char
*enaddr);
-void
-BSP_mve_mcast_filter_accept_del(struct mveth_private *mp, unsigned char
*enaddr);
-/* Stop hardware and clean out the rings */
-void
-BSP_mve_stop_hw(struct mveth_private *mp);
-
struct mveth_private *
-BSP_mve_setup_1(
- struct mveth_private*,
+BSP_mve_create(
int unit,
- void (*isr)(void *isr_arg),
+ rtems_id tid,
+ void (*isr)(void*isr_arg),
void *isr_arg,
void (*cleanup_txbuf)(void *user_buf, void *closure, int
error_on_tx_occurred),
void *cleanup_txbuf_arg,
@@ -32,6 +19,23 @@ BSP_mve_setup_1(
int irq_mask
);
+/* Enable/disable promiscuous mode */
+void
+BSP_mve_promisc_set(struct mveth_private *mp, int promisc);
+
+/* Clear multicast filters*/
+void
+BSP_mve_mcast_filter_clear(struct mveth_private *mp);
+void
+BSP_mve_mcast_filter_accept_all(struct mveth_private *mp);
+void
+BSP_mve_mcast_filter_accept_add(struct mveth_private *mp, unsigned char
*enaddr);
+void
+BSP_mve_mcast_filter_accept_del(struct mveth_private *mp, unsigned char
*enaddr);
+/* Stop hardware and clean out the rings */
+void
+BSP_mve_stop_hw(struct mveth_private *mp);
+
/* MAIN RX-TX ROUTINES
*
* BSP_mve_swipe_tx(): descriptor scavenger; releases mbufs
@@ -44,6 +48,33 @@ BSP_mve_setup_1(
/* clean up the TX ring freeing up buffers */
int
BSP_mve_swipe_tx(struct mveth_private *mp);
+
+/* Enqueue a mbuf chain or a raw data buffer for transmission;
+ * RETURN: #bytes sent or -1 if there are not enough descriptors
+ * -2 is returned if the caller should attempt to
+ * repackage the chain into a smaller one.
+ *
+ * Comments: software cache-flushing incurs a penalty if the
+ * packet cannot be queued since it is flushed anyways.
+ * The algorithm is slightly more efficient in the normal
+ * case, though.
+ */
+
+typedef struct MveEthBufIter {
+ void *hdl;/* opaque handle for the iterator implementor */
+ void *data; /* data to be sent*/
+ size_t len;/* data size (in octets) */
+ void *uptr; /* user-pointer to go into the descriptor;
+ note: cleanup_txbuf is only called for desriptors
+ where this field is non-NULL (for historical
+ reasons) */
+} MveEthBufIter;
+
+typedef MveEthBufIter *(*MveEthBufIterNext)(const MveEthBufIter*);
+
+int
+BSP_mve_send_buf_chain(struct mveth_private *mp, MveEthBufIterNext next,
MveEthBufIter *it);
+
int
BSP_mve_send_buf_raw(
struct mveth_private *mp,
@@ -51,6 +82,7 @@ BSP_mve_send_buf_raw(
int h_len,
void *data_p,
int d_len);
+
/* send received buffers upwards and replace them
* with freshly allocated ones;
* ASSUMPTION: buffer length NEVER changes and is set
@@ -82,6 +114,14 @@ BSP_mve_detach(struct mveth_private *mp);
void
BSP_mve_init_hw(struct mveth_private *mp, int promisc, unsigned char *enaddr);
+#define MV643XX_MEDIA_FD (1<<0)
+#define MV643XX_MEDIA_10 (1<<8)
+#define MV643XX_MEDIA_100 (2<<8)
+#define MV643XX_MEDIA_1000 (3<<8)
+#define MV643XX_MEDIA_SPEED_MSK (0xff00)
+void
+BSP_mve_update_serial_port(struct mveth_private *mp, int media);
+
/* read ethernet address from hw to buffer */
void
BSP_mve_read_eaddr(struct mveth_private *mp, unsigned char *oeaddr);
@@ -90,12 +130,19 @@ void
BSP_mve_enable_irqs(struct mveth_private *mp);
void
BSP_mve_disable_irqs(struct mveth_private *mp);
+
+#define MV643XX_ETH_IRQ_RX_DONE
(1<<2)
+#define MV643XX_ETH_EXT_IRQ_TX_DONE(1<<0)
+#define MV643XX_ETH_EXT_IRQ_LINK_CHG (1<<16)
uint32_t
BSP_mve_ack_irqs(struct mveth_private *mp);
+
void
BSP_mve_enable_irq_mask(struct mveth_private *mp, uint32_t mask);
+
uint32_t
BSP_mve_disable_irq_mask(struct mveth_private *mp, uint32_t mask);
+
uint32_t
BSP_mve_ack_irq_mask(struct mve
[PATCH rtems 05/18] mv643xx_eth_bsdnet.c: use default descriptor ring size if ifconfig says 0
From: till straumann
Update #4344
---
bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c | 39 ---
.../beatnik/net/if_mve/mv643xx_eth_bsdnet.c | 8
2 files changed, 8 insertions(+), 39 deletions(-)
diff --git a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
index 1d920df342..25631d76c3 100644
--- a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
+++ b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
@@ -113,45 +113,6 @@
/* Enable debugging messages and some support routines (dump rings etc.)
*/
#undef MVETH_DEBUG
-/* Ring sizes */
-
-#ifdef MVETH_TESTING
-
-/* hard and small defaults */
-#undef MV643XX_RX_RING_SIZE
-#define MV643XX_RX_RING_SIZE 2
-#undef MV643XX_TX_RING_SIZE
-#define MV643XX_TX_RING_SIZE 4
-
-#else /* MVETH_TESTING */
-
-/* Define default ring sizes, allow override from bsp.h, Makefile,... and from
ifcfg->rbuf_count/xbuf_count */
-
-#ifndef MV643XX_RX_RING_SIZE
-#define MV643XX_RX_RING_SIZE 40 /* attached buffers are always 2k
clusters, i.e., this
-*
driver - with a configured ring size of 40 - constantly
-*
locks 80k of cluster memory - your app config better
-*
provides enough space!
-*/
-#endif
-
-#ifndef MV643XX_TX_RING_SIZE
-/* NOTE: tx ring size MUST be > max. # of fragments / mbufs in a chain;
- * in 'TESTING' mode, special code is compiled in to repackage
- * chains that are longer than the ring size. Normally, this is
- * disabled for sake of speed.
- * I observed chains of >17 entries regularly!
- *
- * Also, TX_NUM_TAG_SLOTS (1) must be left empty as a marker, hence
- * the ring size must be > max. #frags + 1.
- */
-#define MV643XX_TX_RING_SIZE 200 /* these are smaller fragments and not
occupied when
-* the
driver is idle.
-*/
-#endif
-
-#endif /* MVETH_TESTING */
-
/* How many instances to we support (bsp.h could override) */
#ifndef MV643XXETH_NUM_DRIVER_SLOTS
#define MV643XXETH_NUM_DRIVER_SLOTS2
diff --git a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
index e8819be6bf..b3ec1542ff 100644
--- a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
+++ b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
@@ -1271,6 +1271,14 @@ struct ifnet *ifp;
mveth_tid = rtems_bsdnet_newproc("MVEd", 4096,
mveth_daemon, 0);
}
+ if ( 0 == ifcfg->rbuf_count ) {
+ ifcfg->rbuf_count = MV643XX_RX_RING_SIZE;
+ }
+
+ if ( 0 == ifcfg->xbuf_count ) {
+ ifcfg->xbuf_count = MV643XX_TX_RING_SIZE;
+ }
+
if ( !BSP_mve_setup( unit,
mveth_tid,
release_tx_mbuf, ifp,
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems 06/18] mv643xx_eth.h: iterator callback takes no const arg
From: till straumann
Update #4344
---
bsps/powerpc/beatnik/include/bsp/mv643xx_eth.h | 2 +-
bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c | 9 +++--
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/bsps/powerpc/beatnik/include/bsp/mv643xx_eth.h
b/bsps/powerpc/beatnik/include/bsp/mv643xx_eth.h
index f963b91d3d..6a7dbacf69 100644
--- a/bsps/powerpc/beatnik/include/bsp/mv643xx_eth.h
+++ b/bsps/powerpc/beatnik/include/bsp/mv643xx_eth.h
@@ -70,7 +70,7 @@ typedef struct MveEthBufIter {
reasons) */
} MveEthBufIter;
-typedef MveEthBufIter *(*MveEthBufIterNext)(const MveEthBufIter*);
+typedef MveEthBufIter *(*MveEthBufIterNext)(MveEthBufIter*);
int
BSP_mve_send_buf_chain(struct mveth_private *mp, MveEthBufIterNext next,
MveEthBufIter *it);
diff --git a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
index 25631d76c3..b475711fef 100644
--- a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
+++ b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
@@ -1830,6 +1830,7 @@ register MvEthTxDesc l,d,h;
intneeded;
void*frst_buf;
int frst_len;
+void*uarg;
rval = 0;
@@ -1855,13 +1856,17 @@ int frst_len;
#endif
/* find the 'first' user buffer */
- if ( (frst_buf = head_p) ) {
+ if ( (frst_buf = head_p) && (h_len > 0) ) {
frst_len = h_len;
} else {
frst_buf = data_p;
frst_len = d_len;
}
+ uarg = (head_p && ! h_len) ? head_p : frst_buf;
+
+ /* Legacy: if h_len == 0 but head_p is not then use that for the user
arg */
+
/* Don't use the first descriptor yet because BSP_mve_swipe_tx()
* needs mp->d_tx_h->buf_ptr == NULL as a marker. Hence, we
* start with the second (optional) slot and fill the first
@@ -1898,7 +1903,7 @@ int frst_len;
l->cmd_sts |= TDESC_LAST | TDESC_INT_ENA;
/* first buffer of 'chain' goes into last desc */
- l->u_buf= frst_buf;
+ l->u_buf= uarg;
FLUSH_DESC(l);
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems 07/18] mv643xx_eth_bsdnet.c: removed leftover macros
From: till straumann
Update #4344
---
.../beatnik/net/if_mve/mv643xx_eth_bsdnet.c | 352 +-
1 file changed, 8 insertions(+), 344 deletions(-)
diff --git a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
index b3ec1542ff..e233f96dde 100644
--- a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
+++ b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
@@ -132,11 +132,6 @@
/* CONFIGURABLE PARAMETERS */
-/* Enable Hardware Snooping; if this is disabled (undefined),
- * cache coherency is maintained by software.
- */
-#undef ENABLE_HW_SNOOPING
-
/* Compile-time debugging features */
/* Enable paranoia assertions and checks; reduce # of descriptors to minimum
for stressing */
@@ -189,8 +184,6 @@
#define MV643XXETH_NUM_DRIVER_SLOTS2
#endif
-#define TX_NUM_TAG_SLOTS 1 /* leave room for tag; must
not be 0 */
-
#define DRVNAME"mve"
#define MAX_NUM_SLOTS 3
@@ -204,32 +197,8 @@
#define STATIC static
#endif
-struct mveth_private *
-BSP_mve_setup(
- int unit,
- rtems_id tid,
- void (*cleanup_txbuf)(void *user_buf, void *closure, int
error_on_tx_occurred),
- void *cleanup_txbuf_arg,
- void *(*alloc_rxbuf)(int *p_size, uintptr_t *p_data_addr),
- void (*consume_rxbuf)(void *user_buf, void *closure, int len),
- void *consume_rxbuf_arg,
- int rx_ring_size,
- int tx_ring_size,
- int irq_mask
-);
-
-#define TX_AVAILABLE_RING_SIZE(mp) ((mp)->xbuf_count -
(TX_NUM_TAG_SLOTS))
-
/* macros for ring alignment; proper alignment is a hardware req; . */
-#ifdef ENABLE_HW_SNOOPING
-
-#define RING_ALIGNMENT 16
-/* rx buffers must be 64-bit aligned (chip requirement) */
-#define RX_BUF_ALIGNMENT 8
-
-#else /* ENABLE_HW_SNOOPING */
-
/* Software cache management */
#ifndef __PPC__
@@ -247,292 +216,17 @@ BSP_mve_setup(
#define RX_BUF_ALIGNMENT PPC_CACHE_ALIGNMENT
#endif
-#endif /* ENABLE_HW_SNOOPING */
-
-
/* HELPER MACROS */
/* Align base to alignment 'a' */
#define MV643XX_ALIGN(b, a)uint32_t)(b)) + (a)-1) & (~((a)-1)))
-#define NOOP() do {} while(0)
-
-/* Function like macros */
-#define MV_READ(off) \
- ld_le32((volatile uint32_t *)(BSP_MV64x60_BASE + (off)))
-#define MV_WRITE(off, data)\
- st_le32((volatile uint32_t *)(BSP_MV64x60_BASE + (off)),
((unsigned)data))
-
-
-/* ENET window mapped 1:1 to CPU addresses by our BSP/MotLoad
- * -- if this is changed, we should think about caching the 'next' and 'buf'
pointers.
- */
-#define CPUADDR2ENET(a) ((Dma_addr_t)(a))
-#define ENET2CPUADDR(a) (a)
-
-#if 1 /* Whether to automatically try to reclaim descriptors when enqueueing
new packets */
-#define MVETH_CLEAN_ON_SEND(mp) (BSP_mve_swipe_tx(mp))
-#else
-#define MVETH_CLEAN_ON_SEND(mp) (-1)
-#endif
-
-#define NEXT_TXD(d)(d)->next
-#define NEXT_RXD(d)(d)->next
-
-/* REGISTER AND DESCRIPTOR OFFSET AND BIT DEFINITIONS */
-
-/* Descriptor Definitions */
-/* Rx descriptor */
-#define RDESC_ERROR
(1<< 0) /* Error summary*/
-
-/* Error code (bit 1&2) is only valid if summary bit is set */
-#define RDESC_CRC_ERROR
(1)
-#define RDESC_OVERRUN_ERROR
(3)
-#define RDESC_MAX_FRAMELENGTH_ERROR(5)
-#define RDESC_RESOURCE_ERROR (7)
-
-#define RDESC_LAST
(1<<26) /* Last Descriptor */
-#define RDESC_FRST
(1<<27) /* First Descriptor */
-#define RDESC_INT_ENA
(1<<29) /* Enable Interrupts */
-#define RDESC_DMA_OWNED
(1<<31)
-
-/* Tx descriptor */
-#define TDESC_ERROR
(1<< 0) /* Error summary */
-#define TDESC_ZERO_PAD
(1<<19)
-#define TDESC_LAST
(1<<20) /* Last Descriptor */
-#define TDESC_FRST
(1<<21) /* First Descriptor */
-#define TDESC_GEN_CRC
(1<<22)
-#define TDESC_INT_ENA
(1<<23) /* Enable Interrupts */
-#define TDESC_DMA_OWNED
(1<<31)
-
-
[PATCH rtems 08/18] mv643xx_eth.c, mv643xx_eth_bsdnet.c: moved some definitions to public header
From: till straumann Update #4344 --- bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c| 5 - bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c | 5 - 2 files changed, 10 deletions(-) diff --git a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c index b475711fef..f786b66c5c 100644 --- a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c +++ b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c @@ -113,11 +113,6 @@ /* Enable debugging messages and some support routines (dump rings etc.) */ #undef MVETH_DEBUG -/* How many instances to we support (bsp.h could override) */ -#ifndef MV643XXETH_NUM_DRIVER_SLOTS -#define MV643XXETH_NUM_DRIVER_SLOTS2 -#endif - #define TX_NUM_TAG_SLOTS 1 /* leave room for tag; must not be 0 */ /* This is REAL; chip reads from 64-bit down-aligned buffer diff --git a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c index e233f96dde..0a42dc4190 100644 --- a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c +++ b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c @@ -179,11 +179,6 @@ #endif /* MVETH_TESTING */ -/* How many instances to we support (bsp.h could override) */ -#ifndef MV643XXETH_NUM_DRIVER_SLOTS -#define MV643XXETH_NUM_DRIVER_SLOTS2 -#endif - #define DRVNAME"mve" #define MAX_NUM_SLOTS 3 -- 2.26.2 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems 10/18] mv643xx_eth_bsdnet.c, mv643xx_eth.c, mv643xx_eth.h: init_hw has new 'speed' argument
From: till straumann
Remove any calls to mii_ioctl from the low-level driver. Instead, the caller
must determine the current speed and communicate to init_hw().
Update #4344
---
.../powerpc/beatnik/include/bsp/mv643xx_eth.h | 2 +-
bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c | 12 ++---
.../beatnik/net/if_mve/mv643xx_eth_bsdnet.c | 54 ---
3 files changed, 39 insertions(+), 29 deletions(-)
diff --git a/bsps/powerpc/beatnik/include/bsp/mv643xx_eth.h
b/bsps/powerpc/beatnik/include/bsp/mv643xx_eth.h
index 160cadbc82..5bfcd9b26a 100644
--- a/bsps/powerpc/beatnik/include/bsp/mv643xx_eth.h
+++ b/bsps/powerpc/beatnik/include/bsp/mv643xx_eth.h
@@ -301,7 +301,7 @@ BSP_mve_dump_stats(struct mveth_private *mp, FILE *f);
* are programmed to accept all multicast frames.
*/
void
-BSP_mve_init_hw(struct mveth_private *mp, int promisc, unsigned char *enaddr);
+BSP_mve_init_hw(struct mveth_private *mp, int promisc, unsigned char *enaddr,
int speed);
/*
* Update the serial port to a new speed (e.g., result of a PHY IRQ)
diff --git a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
index f786b66c5c..35ef6622d9 100644
--- a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
+++ b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
@@ -2063,7 +2063,7 @@ uint32_t mveth_serial_ctrl_config_val =
MVETH_SERIAL_CTRL_CONFIG_VAL;
*/
void
-BSP_mve_init_hw(struct mveth_private *mp, int promisc, unsigned char *enaddr)
+BSP_mve_init_hw(struct mveth_private *mp, int promisc, unsigned char *enaddr,
int media)
{
inti;
uint32_t v;
@@ -2173,15 +2173,9 @@ static int inited = 0;
v |= mveth_serial_ctrl_config_val;
MV_WRITE(MV643XX_ETH_SERIAL_CONTROL_R(mp->port_num), v);
-#ifdef BSDMII
-#warning FIXME
- i = IFM_MAKEWORD(0, 0, 0, 0);
- if ( 0 == BSP_mve_media_ioctl(mp, SIOCGIFMEDIA, &i) ) {
- if ( (IFM_LINK_OK & i) ) {
- mveth_update_serial_port(mp, i);
- }
+ if ( (MV643XX_MEDIA_LINK & media) ) {
+ BSP_mve_update_serial_port(mp, media);
}
-#endif
/* enable serial port */
v = MV_READ(MV643XX_ETH_SERIAL_CONTROL_R(mp->port_num));
diff --git a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
index 0a42dc4190..cdec5c6e14 100644
--- a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
+++ b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
@@ -563,6 +563,34 @@ int rval;
return rval;
}
+/* Translate IFFLAGS to low-level driver representation */
+static int
+xlateMediaFlags(int media)
+{
+int lowLevelFlags = 0;
+
+ if ( IFM_LINK_OK & media ) {
+ lowLevelFlags |= MV643XX_MEDIA_LINK;
+
+ if ( IFM_FDX & media ) {
+ lowLevelFlags |= MV643XX_MEDIA_FD;
+ }
+
+ switch ( IFM_SUBTYPE(media) ) {
+ default: /* treat as 10 */
+ lowLevelFlags |= MV643XX_MEDIA_10;
+ break;
+ case IFM_100_TX:
+ lowLevelFlags |= MV643XX_MEDIA_100;
+ break;
+ case IFM_1000_T:
+ lowLevelFlags |= MV643XX_MEDIA_1000;
+ break;
+ }
+ }
+ return lowLevelFlags;
+}
+
int
BSP_mve_ack_link_chg(struct mveth_private *mp, int *pmedia)
{
@@ -570,23 +598,7 @@ int media = IFM_MAKEWORD(0,0,0,0);
if ( 0 == BSP_mve_media_ioctl(mp, SIOCGIFMEDIA, &media)) {
if ( IFM_LINK_OK & media ) {
- int serport_cfg = 0;
-
- if ( IFM_FDX & media ) {
- serport_cfg |= MV643XX_MEDIA_FD;
- }
-
- switch ( IFM_SUBTYPE(media) ) {
- default: /* treat as 10 */
- serport_cfg |= MV643XX_MEDIA_10;
- break;
- case IFM_100_TX:
- serport_cfg |= MV643XX_MEDIA_100;
- break;
- case IFM_1000_T:
- serport_cfg |= MV643XX_MEDIA_1000;
- break;
- }
+ int serport_cfg = xlateMediaFlags( media );
BSP_mve_update_serial_port(mp, serport_cfg);
}
@@ -713,8 +725,7 @@ mveth_init(void *arg)
struct mveth_softc *sc = arg;
struct ifnet *ifp = &sc->arpcom.ac_if;
int media;
-
- BSP_mve_init_hw(sc->pvt, ifp->if_flags & IFF_PROMISC,
sc->arpcom.ac_enaddr);
+int
[PATCH rtems 09/18] if_mve_pub.h, mv643xx_eth.h: header reorg and cleanup.
From: till straumann
All low-level interfaces were moved to mv643xx_eth.h
and the latter is included by if_mve_pub.h.
Update #4344
---
bsps/powerpc/beatnik/include/bsp/if_mve_pub.h | 199 +---
.../powerpc/beatnik/include/bsp/mv643xx_eth.h | 298 ++
2 files changed, 250 insertions(+), 247 deletions(-)
diff --git a/bsps/powerpc/beatnik/include/bsp/if_mve_pub.h
b/bsps/powerpc/beatnik/include/bsp/if_mve_pub.h
index 46cc4ccd23..b9f0c7101b 100644
--- a/bsps/powerpc/beatnik/include/bsp/if_mve_pub.h
+++ b/bsps/powerpc/beatnik/include/bsp/if_mve_pub.h
@@ -1,19 +1,19 @@
#ifndef RTEMS_BSDNET_IF_MVE_PUBLIC_SYMBOLS_H
#define RTEMS_BSDNET_IF_MVE_PUBLIC_SYMBOLS_H
-/*
+/*
* Authorship
* --
* This software ('beatnik' RTEMS BSP for MVME6100 and MVME5500) was
* created by Till Straumann , 2005-2007,
*Stanford Linear Accelerator Center, Stanford University.
- *
+ *
* Acknowledgement of sponsorship
* --
* The 'beatnik' BSP was produced by
* the Stanford Linear Accelerator Center, Stanford University,
*under Contract DE-AC03-76SFO0515 with the Department of Energy.
- *
+ *
* Government disclaimer of liability
* --
* Neither the United States nor the United States Department of Energy,
@@ -22,18 +22,18 @@
* completeness, or usefulness of any data, apparatus, product, or process
* disclosed, or represents that its use would not infringe privately owned
* rights.
- *
+ *
* Stanford disclaimer of liability
*
* Stanford University makes no representations or warranties, express or
* implied, nor assumes any liability for the use of this software.
- *
+ *
* Stanford disclaimer of copyright
*
* Stanford University, owner of the copyright, hereby disclaims its
* copyright and all other rights in this software. Hence, anyone may
- * freely use it for any purpose without restriction.
- *
+ * freely use it for any purpose without restriction.
+ *
* Maintenance of notices
* --
* In the interest of clarity regarding the origin and status of this
@@ -42,13 +42,14 @@
* or distributed by the recipient and are to be affixed to any copy of
* software made or distributed by the recipient that contains a copy or
* derivative of this software.
- *
+ *
* -- SLAC Software Notices, Set 4 OTT.002a, 2004 FEB 03
- */
+ */
#include
#include
#include
#include
+#include
#ifdef __cplusplus
extern "C" {
@@ -86,8 +87,8 @@ struct mveth_private;
* by BSP_mve_send_buf() earlier. The callback is passed
'cleanup_txbuf_arg'
* and a flag indicating whether the send had been successful.
* The driver no longer accesses 'user_buf' after invoking this
callback.
- * CONTEXT: This callback is executed either by BSP_mve_swipe_tx()
or
- * BSP_mve_send_buf(), BSP_mve_init_hw(), BSP_mve_stop_hw() (the
latter
+ * CONTEXT: This callback is executed either by BSP_mve_swipe_tx()
or
+ * BSP_mve_send_buf(), BSP_mve_init_hw(), BSP_mve_stop_hw() (the
latter
* ones calling BSP_mve_swipe_tx()).
* void *cleanup_txbuf_arg:
* Closure argument that is passed on to 'cleanup_txbuf()'
callback;
@@ -105,7 +106,7 @@ struct mveth_private;
* instead of handing it out to 'consume_rxbuf()'.
* CONTEXT: Called when initializing the RX ring
(BSP_mve_init_hw()) or when
* swiping it (BSP_mve_swipe_rx()).
- *
+ *
*
* void (*consume_rxbuf)(void *user_buf, void *consume_rxbuf_arg, int len);
* Pointer to user-supplied callback to pass a received buffer
back to
@@ -140,7 +141,7 @@ struct mveth_private *
BSP_mve_setup(
int unit,
rtems_id driver_tid,
- void (*cleanup_txbuf)(void *user_buf, void *cleanup_txbuf_arg, int
error_on_tx_occurred),
+ void (*cleanup_txbuf)(void *user_buf, void *cleanup_txbuf_arg, int
error_on_tx_occurred),
void *cleanup_txbuf_arg,
void *(*alloc_rxbuf)(int *p_size, uintptr_t *p_data_addr),
void (*consume_rxbuf)(void *user_buf, void *consume_rxbuf_arg, int len),
@@ -161,7 +162,7 @@ BSP_mve_setup_1(
int unit,
void (*isr)(void *isr_arg),
void *isr_arg,
- void (*cleanup_txbuf)(void *user_buf, void *cleanup_txbuf_arg, int
error_on_tx_occurred),
+ void (*cleanup_txbuf)(void *user_buf, void *cleanup_txbuf_arg, int
error_on_tx_occurred),
void *cleanup_txbuf_arg,
void *(*alloc_rxbuf)(int *p_size, uintptr_t *p_data_addr),
void (*consume_rxbuf)(void *user_buf, void *consume_rxbuf_arg, int len),
@@ -172,81 +173,6 @@ BSP_mve_setup_1(
);
-/*
- * Initialize interface hardware
- *
- * 'mp'
[PATCH rtems 11/18] mv643xx_eth.c, mv643xx_eth_bsdnet.c: added some more debugging messages (#ifdef)
From: till straumann
Update #4344
---
bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c | 15 ++-
.../beatnik/net/if_mve/mv643xx_eth_bsdnet.c | 13 +
2 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
index 35ef6622d9..82ecf5ffa4 100644
--- a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
+++ b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
@@ -908,6 +908,7 @@ static inline uint32_t
mveth_ack_irqs(struct mveth_private *mp, uint32_t mask)
{
register uint32_t x,xe,p;
+register uint32_t rval;
p = mp->port_num;
/* Get cause */
@@ -943,13 +944,21 @@ register uint32_t x,xe,p;
/* luckily, the extended and 'normal' interrupts we use don't
overlap so
* we can just OR them into a single word
*/
- return (xe & mp->xirq_mask) | (x & mp->irq_mask);
+ rval = (xe & mp->xirq_mask) | (x & mp->irq_mask);
+
+#ifdef MVETH_DEBUG
+ printk(DRVNAME"%i: mveth_ack_irqs 0x%08x\n", rval);
+#endif
+ return rval;
}
static void mveth_isr(rtems_irq_hdl_param arg)
{
struct mveth_private *mp = (struct mveth_private*) arg;
+#ifdef MVETH_DEBUG
+ printk(DRVNAME": mveth_isr\n");
+#endif
mp->stats.irqs++;
mp->isr(mp->isr_arg);
}
@@ -1577,6 +1586,10 @@ BSP_mve_update_serial_port(struct mveth_private *mp, int
media)
int port = mp->port_num;
uint32_t old, new;
+#ifdef MVETH_DEBUG
+ printk(DRVNAME"%i: Entering BSP_mve_update_serial_port()\n");
+#endif
+
new = old = MV_READ(MV643XX_ETH_SERIAL_CONTROL_R(port));
/* mask speed and duplex settings */
diff --git a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
index cdec5c6e14..308b992479 100644
--- a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
+++ b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
@@ -884,8 +884,17 @@ struct mveth_softc *sc;
struct ifnet *ifp;
rtems_event_setevs;
int avail;
+
+#ifdef MVETH_DEBUG
+ sleep(1);
+ printk(DRVNAME": bsdnet mveth_daemon started\n");
+#endif
+
for (;;) {
rtems_bsdnet_event_receive( 7, RTEMS_WAIT | RTEMS_EVENT_ANY,
RTEMS_NO_TIMEOUT, &evs );
+#ifdef MVETH_DEBUG
+ printk(DRVNAME": bsdnet mveth_daemon event received 0x%x\n",
evs);
+#endif
evs &= 7;
for ( sc = theMvEths; evs; evs>>=1, sc++ ) {
if ( (evs & 1) ) {
@@ -976,6 +985,10 @@ struct ifnet *ifp;
mveth_tid = rtems_bsdnet_newproc("MVEd", 4096,
mveth_daemon, 0);
}
+#ifdef MVETH_DEBUG
+ printk(DRVNAME": daemon created; id 0x%08x\n", mveth_tid);
+#endif
+
if ( 0 == ifcfg->rbuf_count ) {
ifcfg->rbuf_count = MV643XX_RX_RING_SIZE;
}
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems 13/18] mv643xx_eth_bsdnet.c: reworked buffer-iterator code.
From: till straumann
Must be careful to skip empty buffers and to correctly
identify the last non-empty buffer (since that is the one
whose associated descriptor stores the head of the chain
for deferred cleanup).
Update #4344
---
.../beatnik/net/if_mve/mv643xx_eth_bsdnet.c | 42 +++
1 file changed, 25 insertions(+), 17 deletions(-)
diff --git a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
index 2bafe09ac7..f8400c9f13 100644
--- a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
+++ b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
@@ -245,8 +245,8 @@ struct mveth_softc {
typedef struct BsdMveIter {
MveEthBufIter it;
- struct mbuf *m;
- struct mbuf *h;
+ struct mbuf *next;
+ struct mbuf *head;
} BsdMveIter;
/* GLOBAL VARIABLES */
@@ -462,21 +462,34 @@ bail:
return m;
}
-static MveEthBufIter *fillIter(struct mbuf *m, BsdMveIter *it)
+static inline struct mbuf *skipEmpty(struct mbuf *m)
{
- if ( (it->m = (void*)m) ) {
+ while ( m && ( 0 == m->m_len ) ) {
+ m = m->m_next;
+ }
+ return m;
+}
+
+static MveEthBufIter *nextBuf(MveEthBufIter *arg)
+{
+BsdMveIter *it = (BsdMveIter*)arg;
+struct mbuf *m;
+ if ( (m = it->next) ) {
+ it->next= skipEmpty( m->m_next );
it->it.data = mtod(m, void*);
it->it.len = m->m_len;
- it->it.uptr = m->m_next ? it->h : 0;
+ it->it.uptr = it->next ? 0 : it->head;
return (MveEthBufIter*)it;
}
return 0;
}
-static MveEthBufIter *nextBuf(MveEthBufIter *arg)
+static MveEthBufIter *initIter(BsdMveIter *it, struct mbuf *m)
{
-BsdMveIter *it = (BsdMveIter*)arg;
- return fillIter( it->m->m_next, it );
+ it->head = m;
+ it->next = skipEmpty( m );
+ /* Fill with first buf info */
+ return nextBuf( &it->it );
}
int
@@ -501,12 +514,10 @@ startover:
return 0;
/* find first mbuf with actual data */
- while ( 0 == m1->m_len ) {
- if ( ! (m1 = m1->m_next) ) {
- /* end reached and still no data to send ?? */
- m_freem(m_head);
- return 0;
- }
+ if ( ! initIter( &iter, m_head ) ) {
+ /* end reached and still no data to send ?? */
+ m_freem(m_head);
+ return 0;
}
#ifdef MVETH_DEBUG_TX_DUMP
@@ -524,9 +535,6 @@ startover:
}
#endif
- fillIter( m_head, &iter );
- iter.h = m_head;
-
rval = BSP_mve_send_buf_chain( mp, nextBuf, &iter.it );
if ( -2 == rval ) {
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems 12/18] mv643xx_eth_bsdnet.c: define ISR (which was removed from low-level driver)
From: till straumann
NOTE: apparently we now must use rtems_bsdnet_event_send(). The
combination of rtems_event_send()/rtems_bsdnet_event_receive()
apparently no longer works (rtems-5).
Update #4344
---
.../beatnik/net/if_mve/mv643xx_eth_bsdnet.c| 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
index 308b992479..2bafe09ac7 100644
--- a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
+++ b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
@@ -877,6 +877,17 @@ intf;
/* DRIVER TASK */
+static void mveth_isr(void *arg)
+{
+struct mveth_softc *sc = (struct mveth_softc*) arg;
+int idx = (sc - &theMvEths[0]);
+ BSP_mve_disable_irqs( sc->pvt );
+#ifdef MVETH_DEBUG
+ printk(DRVNAME": bsdnet isr; posting event %i to 0x%08x\n", idx,
BSP_mve_get_tid( sc->pvt ));
+#endif
+ rtems_bsdnet_event_send( BSP_mve_get_tid( sc->pvt ), (1
[PATCH rtems 14/18] mv643xx_eth.c: fixed format in debugging message
From: till straumann
Update #4344
---
bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
index 82ecf5ffa4..fb72ee132e 100644
--- a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
+++ b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
@@ -1063,7 +1063,11 @@ unsigned wc = 0;
unsigned
BSP_mve_mii_read(struct mveth_private *mp, unsigned addr)
{
- return do_mii_read(mp->phy, addr);
+unsigned rval = do_mii_read(mp->phy, addr);
+#ifdef MVETH_DEBUG
+ printk(DRVNAME": BSP_mve_mii_read(%d): 0x%08x\n", addr, rval);
+#endif
+ return rval;
}
unsigned
@@ -1096,6 +1100,9 @@ unsigned wc = 0;
unsigned
BSP_mve_mii_write(struct mveth_private *mp, unsigned addr, unsigned v)
{
+#ifdef MVETH_DEBUG
+ printk(DRVNAME": BSP_mve_mii_write(%d): 0x%08x\n", addr, v);
+#endif
return do_mii_write( mp->phy, addr, v );
}
@@ -1587,7 +1594,7 @@ int port = mp->port_num;
uint32_t old, new;
#ifdef MVETH_DEBUG
- printk(DRVNAME"%i: Entering BSP_mve_update_serial_port()\n");
+ printk(DRVNAME": Entering BSP_mve_update_serial_port()\n");
#endif
new = old = MV_READ(MV643XX_ETH_SERIAL_CONTROL_R(port));
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems 15/18] mv643xx_eth_bsdnet.c: minor cleanup
From: till straumann
Update #4344
---
bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
index f8400c9f13..0f2a97d49a 100644
--- a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
+++ b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
@@ -168,9 +168,6 @@
* chains that are longer than the ring size. Normally, this is
* disabled for sake of speed.
* I observed chains of >17 entries regularly!
- *
- * Also, TX_NUM_TAG_SLOTS (1) must be left empty as a marker, hence
- * the ring size must be > max. #frags + 1.
*/
#define MV643XX_TX_RING_SIZE 200 /* these are smaller fragments and not
occupied when
* the
driver is idle.
@@ -207,7 +204,6 @@
#ifPPC_CACHE_ALIGMENT != 16 && PPC_CACHE_ALIGNMENT != 32
#error "Cache line size must be 16 or 32"
#else
-#define RING_ALIGNMENT PPC_CACHE_ALIGNMENT
#define RX_BUF_ALIGNMENT PPC_CACHE_ALIGNMENT
#endif
@@ -951,7 +947,7 @@ int avail;
}
}
/* free tx chain */
- if ( (MV643XX_ETH_EXT_IRQ_TX_DONE & x) &&
(avail = BSP_mve_swipe_tx(sc->pvt)) > 0 ) {
+ if ( (MV643XX_ETH_EXT_IRQ_TX_DONE & x) &&
((avail = BSP_mve_swipe_tx(sc->pvt)) > 0) ) {
ifp->if_flags &= ~IFF_OACTIVE;
if ( sc->bsd.tx_ring_size == avail )
ifp->if_timer = 0;
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems 16/18] BUGFIX: if buffer allocation fails we *must not* call consume_rxbuf()
From: till straumann
If we have no new buffer then we must recycle/reuse the old one
and *not* return it to the user for consumption.
Update #4344
---
bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
index fb72ee132e..9e21614367 100644
--- a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
+++ b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
@@ -659,7 +659,7 @@ struct mveth_private {
unsignedmaxchain;
unsignedrepack;
unsignedpacket;
- unsignedodrops;
/* no counter in core code */
+ unsignedidrops;
/* no counter in core code */
struct {
uint64_tgood_octs_rcvd; /* 64-bit */
uint32_tbad_octs_rcvd;
@@ -1976,7 +1976,7 @@ uintptr_t baddr;
if ( err || !(newbuf = mp->alloc_rxbuf(&sz, &baddr)) ) {
/* drop packet and recycle buffer */
newbuf = d->u_buf;
- mp->consume_rxbuf(0, mp->consume_rxbuf_arg, err ? -1 :
0);
+ mp->stats.idrops++;
} else {
#ifdef MVETH_TESTING
assert( d->byte_cnt > 0 );
@@ -2312,6 +2312,7 @@ uint32_t v;
fprintf(f, " Max. mbuf chain length: %i\n", mp->stats.maxchain);
fprintf(f, " # repacketed: %i\n", mp->stats.repack);
fprintf(f, " # packets: %i\n", mp->stats.packet);
+ fprintf(f, " # buffer alloc failed: %i\n", mp->stats.idrops);
fprintf(f, "MIB Counters:\n");
for ( idx = MV643XX_ETH_MIB_GOOD_OCTS_RCVD_LO>>2;
idx < MV643XX_ETH_NUM_MIB_COUNTERS;
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems 18/18] mv643xx_eth.c, mv643xx_eth_bsdnet.c: removed trailing whitespace
From: till straumann Update #4344 --- bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c | 66 +++ .../beatnik/net/if_mve/mv643xx_eth_bsdnet.c | 44 ++--- 2 files changed, 61 insertions(+), 49 deletions(-) diff --git a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c index e952cbbb8a..7fc0bed86a 100644 --- a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c +++ b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c @@ -18,19 +18,19 @@ * new implementation and is the original work by the author. */ -/* +/* * Authorship * -- * This software (mv643xx ethernet driver for RTEMS) was * created by Till Straumann , 2005-2007, *Stanford Linear Accelerator Center, Stanford University. - * + * * Acknowledgement of sponsorship * -- * The 'mv643xx ethernet driver for RTEMS' was produced by * the Stanford Linear Accelerator Center, Stanford University, *under Contract DE-AC03-76SFO0515 with the Department of Energy. - * + * * Government disclaimer of liability * -- * Neither the United States nor the United States Department of Energy, @@ -39,18 +39,18 @@ * completeness, or usefulness of any data, apparatus, product, or process * disclosed, or represents that its use would not infringe privately owned * rights. - * + * * Stanford disclaimer of liability * * Stanford University makes no representations or warranties, express or * implied, nor assumes any liability for the use of this software. - * + * * Stanford disclaimer of copyright * * Stanford University, owner of the copyright, hereby disclaims its * copyright and all other rights in this software. Hence, anyone may - * freely use it for any purpose without restriction. - * + * freely use it for any purpose without restriction. + * * Maintenance of notices * -- * In the interest of clarity regarding the origin and status of this @@ -59,9 +59,9 @@ * or distributed by the recipient and are to be affixed to any copy of * software made or distributed by the recipient that contains a copy or * derivative of this software. - * + * * -- SLAC Software Notices, Set 4 OTT.002a, 2004 FEB 03 - */ + */ /* * NOTE: Some register (e.g., the SMI register) are SHARED among the @@ -110,7 +110,7 @@ /* Enable paranoia assertions and checks; reduce # of descriptors to minimum for stressing */ #define MVETH_TESTING -/* Enable debugging messages and some support routines (dump rings etc.) */ +/* Enable debugging messages and some support routines (dump rings etc.) */ #undef MVETH_DEBUG #define TX_NUM_TAG_SLOTS 1 /* leave room for tag; must not be 0 */ @@ -199,7 +199,7 @@ * * broadcast packet RX: 0x0005 * last buf: 0x0c05 - * overrun: 0x0c00 + * overrun: 0x0c00 * unicast packet RX: 0x0005 * bad CRC received:0x0005 * @@ -232,11 +232,11 @@ *} *--> sometimes, cmd_sts is STILL != 0 here * - * b) Sometimes, the OWNership flag is *not cleared*. - * + * b) Sometimes, the OWNership flag is *not cleared*. + * * c) Weird things happen if the chip finds a descriptor with 'OWN' *still set (i.e., not properly loaded), i.e., corrupted packets - *are sent [with OK checksum since the chip calculates it]. + *are sent [with OK checksum since the chip calculates it]. * * Combine a+b+c and we end up with a real mess. * @@ -398,11 +398,16 @@ /* not fully understood; RX seems to raise 0x0005 or 0x0c05 if last buffer is filled and 0x0c00 * if there are no buffers */ -#define MV643XX_ETH_ALL_IRQS (0x0007) -#define MV643XX_ETH_KNOWN_IRQS (0x0c05) +#define MV643XX_ETH_ALL_IRQS (0x07ff) +#define MV643XX_ETH_KNOWN_IRQS (0x00080c07) #define MV643XX_ETH_IRQ_EXT_ENA (1<<1) +/* defined in public header #define MV643XX_ETH_IRQ_RX_DONE (1<<2) + */ #define MV643XX_ETH_IRQ_RX_NO_DESC (1<<10) +#define MV643XX_ETH_TX_Q_N_END(n) (1<<((n)+19)) +/* We just use queue 0 */ +#define MV643XX_ETH_TX_Q_END MV643XX_ETH_TX_Q_N_END(0) #define MV643XX_ETH_INTERRUPT_EXTEND_CAUSE_R(port) (0x2464 + ((port)<<10)) /* not fully understood; TX seems to raise 0x0001 and link change is 0x0001 @@ -411,8 +416,13 @@ #define MV643XX_ETH_ALL_EXT_IRQS (0x0011) /* Recent (2013) linu
[PATCH rtems 17/18] mv643xx_eth.c: added 0x00100000 bit to 'known' ext. interrupt causes
From: till straumann In 'testing' mode the paranoia checks found this bit asserted. The recent linux driver (2013) mentions lists this bit as a 'phy link status change' bit (together with (1<<16)). Thus, we accept this as a 'known' bit now. Update #4344 --- bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c index 9e21614367..e952cbbb8a 100644 --- a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c +++ b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c @@ -108,7 +108,7 @@ /* Compile-time debugging features */ /* Enable paranoia assertions and checks; reduce # of descriptors to minimum for stressing */ -#undef MVETH_TESTING +#define MVETH_TESTING /* Enable debugging messages and some support routines (dump rings etc.) */ #undef MVETH_DEBUG @@ -409,7 +409,8 @@ * if there are no buffers */ #define MV643XX_ETH_ALL_EXT_IRQS (0x0011) -#define MV643XX_ETH_KNOWN_EXT_IRQS (0x00010101) +/* Recent (2013) linux driver mentions both bits 0x0011 as 'link change' causes */ +#define MV643XX_ETH_KNOWN_EXT_IRQS (0x00110101) #define MV643XX_ETH_EXT_IRQ_TX_DONE(1<<0) #define MV643XX_ETH_EXT_IRQ_LINK_CHG (1<<16) #define MV643XX_ETH_INTERRUPT_ENBL_R(port) (0x2468 + ((port)<<10)) -- 2.26.2 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-libbsd 1/5] rtemsbsd: Add mv643xx nexus ethernet driver
From: till straumann Update #4345 --- libbsd.py| 19 + rtemsbsd/include/bsp/nexus-devices.h | 7 +- rtemsbsd/sys/dev/mve/mv643xx_nexus.c | 965 +++ 3 files changed, 990 insertions(+), 1 deletion(-) create mode 100644 rtemsbsd/sys/dev/mve/mv643xx_nexus.c diff --git a/libbsd.py b/libbsd.py index a2056f36..b25d7e03 100644 --- a/libbsd.py +++ b/libbsd.py @@ -292,6 +292,25 @@ class rtems(builder.Module): 'pppd/sys-rtems.c', 'pppd/upap.c', 'pppd/utils.c', +'sys/arm/lpc/if_lpe.c', +'sys/arm/lpc/lpc_pwr.c', +'sys/dev/atsam/if_atsam.c', +'sys/dev/atsam/if_atsam_media.c', +'sys/dev/dw_mmc/dw_mmc.c', +'sys/dev/ffec/if_ffec_mcf548x.c', +'sys/dev/ffec/if_ffec_mpc8xx.c', +'sys/dev/mve/mv643xx_nexus.c', +'sys/dev/input/touchscreen/tsc_lpc32xx.c', +'sys/dev/smc/if_smc_nexus.c', +'sys/dev/tsec/if_tsec_nexus.c', +'sys/dev/usb/controller/ehci_mpc83xx.c', +'sys/dev/usb/controller/ohci_lpc32xx.c', +'sys/dev/usb/controller/ohci_lpc.c', +'sys/dev/usb/controller/usb_otg_transceiver.c', +'sys/dev/usb/controller/usb_otg_transceiver_dump.c', +'sys/fs/devfs/devfs_devs.c', +'sys/net/if_ppp.c', +'sys/net/ppp_tty.c', 'telnetd/telnetd-service.c', ], mm.generator['source']() diff --git a/rtemsbsd/include/bsp/nexus-devices.h b/rtemsbsd/include/bsp/nexus-devices.h index 53a22798..82a6f332 100644 --- a/rtemsbsd/include/bsp/nexus-devices.h +++ b/rtemsbsd/include/bsp/nexus-devices.h @@ -246,6 +246,11 @@ SYSINIT_DRIVER_REFERENCE(ukphy, miibus); RTEMS_BSD_DRIVER_PC_LEGACY; -#endif /* LIBBSP_POWERPC_MOTOROLA_POWERPC_BSP_H */ +#elif defined(LIBBSP_BEATNIK_BSP_H) + +RTEMS_BSD_DEFINE_NEXUS_DEVICE(mve, 0, 0, NULL); +SYSINIT_DRIVER_REFERENCE(ukphy, miibus); + +#endif #endif diff --git a/rtemsbsd/sys/dev/mve/mv643xx_nexus.c b/rtemsbsd/sys/dev/mve/mv643xx_nexus.c new file mode 100644 index ..804c3e7f --- /dev/null +++ b/rtemsbsd/sys/dev/mve/mv643xx_nexus.c @@ -0,0 +1,965 @@ +/* RTEMS driver for the mv643xx gigabit ethernet chip */ + +/* Acknowledgement: + * + * Valuable information for developing this driver was obtained + * from the linux open-source driver mv643xx_eth.c which was written + * by the following people and organizations: + * + * Matthew Dharm + * rab...@galileo.co.il + * PMC-Sierra, Inc., Manish Lachwani + * Ralf Baechle + * MontaVista Software, Inc., Dale Farnsworth + * Steven J. Hill / + * + * Note however, that in spite of the identical name of this file + * (and some of the symbols used herein) this file provides a + * new implementation and is the original work by the author. + */ + +/* + * Authorship + * -- + * This software (mv643xx ethernet driver for RTEMS) was + * created by Till Straumann , 2005-2007, + *Stanford Linear Accelerator Center, Stanford University. + * + * Acknowledgement of sponsorship + * -- + * The 'mv643xx ethernet driver for RTEMS' was produced by + * the Stanford Linear Accelerator Center, Stanford University, + *under Contract DE-AC03-76SFO0515 with the Department of Energy. + * + * Government disclaimer of liability + * -- + * Neither the United States nor the United States Department of Energy, + * nor any of their employees, makes any warranty, express or implied, or + * assumes any legal liability or responsibility for the accuracy, + * completeness, or usefulness of any data, apparatus, product, or process + * disclosed, or represents that its use would not infringe privately owned + * rights. + * + * Stanford disclaimer of liability + * + * Stanford University makes no representations or warranties, express or + * implied, nor assumes any liability for the use of this software. + * + * Stanford disclaimer of copyright + * + * Stanford University, owner of the copyright, hereby disclaims its + * copyright and all other rights in this software. Hence, anyone may + * freely use it for any purpose without restriction. + * + * Maintenance of notices + * -- + * In the interest of clarity regarding the origin and status of this + * SLAC software, this and all the preceding Stanford University notices + * are to remain affixed to any copy or derivative of this software made + * or distributed by the recipient and are to be affixed to any copy of + * software made or distributed by the recipient that contains a copy or + * derivative of this software. + * + * -- SLAC Software Notices, Set 4 OTT.002a, 2004 FEB 03 + */ + +/* Nexus port by Till Straumann
[PATCH rtems-libbsd 2/5] mv643xx_nexus.c: removed unlocked mve_init(), mve_start()
From: till straumann
The recursive lock takes care of this...
Update #4345
---
rtemsbsd/sys/dev/mve/mv643xx_nexus.c | 37 +++-
1 file changed, 9 insertions(+), 28 deletions(-)
diff --git a/rtemsbsd/sys/dev/mve/mv643xx_nexus.c
b/rtemsbsd/sys/dev/mve/mv643xx_nexus.c
index 804c3e7f..3b443583 100644
--- a/rtemsbsd/sys/dev/mve/mv643xx_nexus.c
+++ b/rtemsbsd/sys/dev/mve/mv643xx_nexus.c
@@ -23,13 +23,13 @@
* --
* This software (mv643xx ethernet driver for RTEMS) was
* created by Till Straumann , 2005-2007,
- *Stanford Linear Accelerator Center, Stanford University.
+ * Stanford Linear Accelerator Center, Stanford University.
*
* Acknowledgement of sponsorship
* --
* The 'mv643xx ethernet driver for RTEMS' was produced by
* the Stanford Linear Accelerator Center, Stanford University,
- *under Contract DE-AC03-76SFO0515 with the Department of Energy.
+ * under Contract DE-AC03-76SFO0515 with the Department of Energy.
*
* Government disclaimer of liability
* --
@@ -615,9 +615,10 @@ int msk = IFM_AVALID | IFM_ACTIVE;
}
static void
-mve_init_unlocked(struct mve_enet_softc *sc)
+mve_init(void *arg)
{
-struct ifnet *ifp = sc->ifp;
+struct mve_enet_softc *sc = (struct mve_enet_softc*)arg;
+struct ifnet *ifp= sc->ifp;
intlowLevelMediaStatus = 0;
intpromisc;
@@ -625,7 +626,6 @@ intpromisc;
printk(DRVNAME": mve_init (entering)\n");
#endif
-
if ( sc->mii_softc ) {
mii_pollstat( sc->mii_softc );
lowLevelMediaStatus = xlateMediaFlags( sc->mii_softc );
@@ -649,33 +649,16 @@ intpromisc;
if_setdrvflagbits(ifp, IFF_DRV_RUNNING, 0);
}
-static void
-mve_init(void *arg)
-{
-struct mve_enet_softc *sc = (struct mve_enet_softc*)arg;
- mve_lock( sc, "mve_init" );
- mve_init_unlocked( sc );
- mve_unlock( sc, "mve_init" );
-}
-
-static void
-mve_start_unlocked(struct ifnet *ifp)
-{
-struct mve_enet_softc *sc = (struct mve_enet_softc*)ifp->if_softc;
- if_setdrvflagbits(ifp, IFF_DRV_OACTIVE, 0);
- mve_send_event( sc, TX_EVENT );
-}
-
static void
mve_start(struct ifnet *ifp)
{
struct mve_enet_softc *sc = (struct mve_enet_softc*)ifp->if_softc;
mve_lock( sc, "mve_start" );
- mve_start_unlocked( ifp );
+ if_setdrvflagbits(ifp, IFF_DRV_OACTIVE, 0);
mve_unlock( sc, "mve_start" );
+ mve_send_event( sc, TX_EVENT );
}
-
static int
mve_ioctl(struct ifnet *ifp, ioctl_command_t cmd, caddr_t data)
{
@@ -696,7 +679,7 @@ int f, df;
df = if_getdrvflags( ifp );
if ( (f & IFF_UP) ) {
if ( ! ( df & IFF_DRV_RUNNING ) ) {
- mve_init_unlocked(sc);
+ mve_init( (void*)sc );
} else {
if ( (f & IFF_PROMISC) !=
(sc->oif_flags & IFF_PROMISC) ) {
mve_set_filters(ifp);
@@ -761,7 +744,7 @@ int lowLevelMediaStatus;
if ( (lowLevelMediaStatus & MV643XX_MEDIA_LINK) ) {
BSP_mve_update_serial_port( sc->mp, lowLevelMediaStatus );
if_setdrvflagbits( sc->ifp, 0, IFF_DRV_OACTIVE );
-mve_start_unlocked( sc->ifp );
+mve_start( sc->ifp );
} else {
if_setdrvflagbits( sc->ifp, IFF_DRV_OACTIVE, 0 );
}
@@ -808,7 +791,6 @@ struct mii_data*mii = sc->mii_softc;
ifmr->ifm_active = mii->mii_media_active;
ifmr->ifm_status = mii->mii_media_status;
}
-
}
static int
@@ -865,7 +847,6 @@ int tx_q_size=
MV643XX_TX_QUEUE_SIZE;
sc->mp = mp;
-
BSP_mve_read_eaddr( mp, hwaddr );
if ( 0 == mii_attach( sc->dev,
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-libbsd 3/5] mv643xx_nexus.c: removed 'repackage_chain()'.
From: till straumann
Testing (TCP with larger amounts of data while MVETH_TESTING
was defined which reduces the ring sizes to very small numbers)
revealed that the BSD stack honours the 'sendqlen' and
never hands us chains exceeding the ring size.
Update #4345
---
rtemsbsd/sys/dev/mve/mv643xx_nexus.c | 33 ++--
1 file changed, 2 insertions(+), 31 deletions(-)
diff --git a/rtemsbsd/sys/dev/mve/mv643xx_nexus.c
b/rtemsbsd/sys/dev/mve/mv643xx_nexus.c
index 3b443583..5edcdea4 100644
--- a/rtemsbsd/sys/dev/mve/mv643xx_nexus.c
+++ b/rtemsbsd/sys/dev/mve/mv643xx_nexus.c
@@ -95,8 +95,9 @@
/* Define default ring sizes */
-#ifdef MVETH_TESTING
+#undef MVETH_TESTING
+#ifdef MVETH_TESTING
/* hard and small defaults */
#define MV643XX_RX_RING_SIZE 2
#define MV643XX_TX_QUEUE_SIZE 4
@@ -116,9 +117,6 @@
#endif /* MVETH_TESTING */
/* NOTE: tx ring size MUST be > max. # of fragments / mbufs in a chain;
- * in 'TESTING' mode, special code is compiled in to repackage
- * chains that are longer than the ring size. Normally, this is
- * disabled for sake of speed.
* I observed chains of >17 entries regularly!
*/
#define MV643XX_TX_RING_SIZE ((MV643XX_TX_QUEUE_SIZE) *
(MV643XX_BD_PER_PACKET))
@@ -240,25 +238,6 @@ mve_probe(device_t dev)
return err;
}
-/* allocate a new cluster and copy an existing chain there;
- * old chain is released...
- */
-static struct mbuf *
-repackage_chain(struct mbuf *m_head)
-{
-struct mbuf *m;
-
- m = m_getcl(M_NOWAIT, MT_DATA, M_PKTHDR);
-
- if ( m ) {
- m_copydata(m_head, 0, MCLBYTES, mtod(m, caddr_t));
- m->m_pkthdr.len = m->m_len = m_head->m_pkthdr.len;
- }
-
- m_freem(m_head);
- return m;
-}
-
/*
* starting at 'm' scan the buffer chain until we
* find a non-empty buffer (which we return)
@@ -328,8 +307,6 @@ mve_send_mbuf( struct mve_enet_softc *sc, struct mbuf
*m_head )
MveMbufIter iter;
int rval;
-startover:
-
if ( ! m_head ) {
return 0;
}
@@ -342,12 +319,6 @@ startover:
rval = BSP_mve_send_buf_chain( sc->mp, nextBuf, &iter.it );
- if ( -2 == rval ) {
- /* would never fit (too many fragments) */
- m_head = repackage_chain( m_head );
- goto startover;
- }
-
return rval;
}
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-libbsd 4/5] mv643xx_nexus.c: added a helper routine that allows printing of driver statistics
From: till straumann
The 'legal' access by means of a special ioctl() is way too cumbersome
when you need to do quick diagnosis.
Update #4345
---
rtemsbsd/sys/dev/mve/mv643xx_nexus.c | 16
1 file changed, 16 insertions(+)
diff --git a/rtemsbsd/sys/dev/mve/mv643xx_nexus.c
b/rtemsbsd/sys/dev/mve/mv643xx_nexus.c
index 5edcdea4..ef84200d 100644
--- a/rtemsbsd/sys/dev/mve/mv643xx_nexus.c
+++ b/rtemsbsd/sys/dev/mve/mv643xx_nexus.c
@@ -171,6 +171,8 @@ struct mve_enet_softc {
int oif_flags;
};
+static struct mve_enet_softc * ifaces[MV643XXETH_NUM_DRIVER_SLOTS] = { 0 };
+
typedef struct MveMbufIter {
MveEthBufIter it;
struct mbuf *next;
@@ -695,6 +697,18 @@ int f, df;
return err;
}
+/* SIO RTEMS_SHOW_STATS is too cumbersome to use -- for debugging, provide
direct hack */
+int
+mv643xx_nexus_dump_stats(int unit, FILE *f)
+{
+ if ( unit < 0 || unit >= MV643XXETH_NUM_DRIVER_SLOTS || ! ifaces[unit] )
+ return -EINVAL;
+ if ( ! f )
+ f = stdout;
+ BSP_mve_dump_stats(ifaces[unit]->mp, f);
+ return 0;
+}
+
/*
* Used to update speed settings in the hardware
* when the phy setup changes.
@@ -840,6 +854,8 @@ int tx_q_size=
MV643XX_TX_QUEUE_SIZE;
printk(DRVNAME": mve_attach (leaving)\n");
#endif
+ ifaces[unit] = sc;
+
return 0;
}
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-libbsd 5/5] mv643xx_nexus.c: more use of if_xxx() access functions
From: till straumann
avoid using struct members directly.
Update #4345
---
rtemsbsd/sys/dev/mve/mv643xx_nexus.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/rtemsbsd/sys/dev/mve/mv643xx_nexus.c
b/rtemsbsd/sys/dev/mve/mv643xx_nexus.c
index ef84200d..44a22197 100644
--- a/rtemsbsd/sys/dev/mve/mv643xx_nexus.c
+++ b/rtemsbsd/sys/dev/mve/mv643xx_nexus.c
@@ -346,7 +346,7 @@ mve_stop(struct mve_enet_softc *sc)
static void
mve_set_filters(struct ifnet *ifp)
{
-struct mve_enet_softc *sc = (struct mve_enet_softc*)ifp->if_softc;
+struct mve_enet_softc *sc = (struct mve_enet_softc*) if_getsoftc( ifp );
int iff = if_getflags(ifp);
struct ifmultiaddr *ifma;
unsigned char*lladdr;
@@ -625,7 +625,7 @@ intpromisc;
static void
mve_start(struct ifnet *ifp)
{
-struct mve_enet_softc *sc = (struct mve_enet_softc*)ifp->if_softc;
+struct mve_enet_softc *sc = (struct mve_enet_softc*) if_getsoftc( ifp );
mve_lock( sc, "mve_start" );
if_setdrvflagbits(ifp, IFF_DRV_OACTIVE, 0);
mve_unlock( sc, "mve_start" );
@@ -635,7 +635,7 @@ struct mve_enet_softc *sc = (struct
mve_enet_softc*)ifp->if_softc;
static int
mve_ioctl(struct ifnet *ifp, ioctl_command_t cmd, caddr_t data)
{
-struct mve_enet_softc *sc = (struct mve_enet_softc*)ifp->if_softc;
+struct mve_enet_softc *sc = (struct mve_enet_softc*) if_getsoftc( ifp );
struct ifreq *ifr = (struct ifreq *)data;
interr = 0;
int f, df;
@@ -744,7 +744,7 @@ int lowLevelMediaStatus;
static int
mve_media_change(struct ifnet *ifp)
{
-struct mve_enet_softc *sc = (struct mve_enet_softc *)ifp->if_softc;
+struct mve_enet_softc *sc = (struct mve_enet_softc*) if_getsoftc( ifp );
struct mii_data*mii = sc->mii_softc;
int err;
@@ -764,7 +764,7 @@ int err;
static void
mve_media_status(struct ifnet *ifp, struct ifmediareq *ifmr)
{
-struct mve_enet_softc *sc = (struct mve_enet_softc *)ifp->if_softc;
+struct mve_enet_softc *sc = (struct mve_enet_softc*) if_getsoftc( ifp );
struct mii_data*mii = sc->mii_softc;
#ifdef MVETH_DEBUG
@@ -803,14 +803,15 @@ int tx_q_size=
MV643XX_TX_QUEUE_SIZE;
mtx_init( &sc->mtx, device_get_nameunit( sc->dev ), MTX_NETWORK_LOCK,
MTX_RECURSE );
callout_init_mtx( &sc->wdCallout, &sc->mtx, 0 );
- ifp->if_softc = sc;
- if_initname(ifp, device_get_name(dev), unit);
- ifp->if_init = mve_init;
- ifp->if_ioctl = mve_ioctl;
- ifp->if_start = mve_start;
- if_setflags(ifp, (IFF_BROADCAST | IFF_MULTICAST | IFF_SIMPLEX) );
- sc->oif_flags = if_getflags(ifp);
- if_setsendqlen( ifp, tx_q_size );
+ if_setsoftc ( ifp, sc);
+ if_initname ( ifp, device_get_name(dev), unit);
+ if_setinitfn( ifp, mve_init );
+ if_setioctlfn ( ifp, mve_ioctl );
+ if_setstartfn ( ifp, mve_start );
+ if_setflags ( ifp, (IFF_BROADCAST | IFF_MULTICAST | IFF_SIMPLEX) );
+ sc->oif_flags = if_getflags( ifp );
+
+ if_setsendqlen ( ifp, tx_q_size );
if_setsendqready( ifp );
mp = BSP_mve_create(
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-examples] lvgl/wscript: Add libpath to search for required libraries
On Mon, Mar 29, 2021 at 10:09 AM Gedare Bloom wrote:
>
> On Mon, Mar 29, 2021 at 9:20 AM Vijay Kumar Banerjee wrote:
> >
> > Hi,
> >
> > Is this OK to push? This only affects lvgl.
> >
> You're a maintainer of lvgl repo, so you can make that decision yourself ;)
>
Thanks. Pushed this. :)
> > Best regards,
> > Vijay
> >
> > On Fri, Mar 26, 2021 at 2:47 PM Vijay Kumar Banerjee
> > wrote:
> > >
> > > ---
> > > lvgl/wscript | 12 ++--
> > > 1 file changed, 10 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/lvgl/wscript b/lvgl/wscript
> > > index 064ebed..281af25 100644
> > > --- a/lvgl/wscript
> > > +++ b/lvgl/wscript
> > > @@ -5,11 +5,19 @@
> > >
> > > import rtems_waf.rtems as rtems
> > > import rtems_waf.rtems_bsd as rtems_bsd
> > > +import os
> > >
> > > def configure(conf):
> > > +arch_lib_path = rtems.arch_bsp_lib_path(str(conf.env.RTEMS_VERSION),
> > > +
> > > str(conf.env.RTEMS_ARCH_BSP))
> > > +arch_lib_path = os.path.join(conf.env.PREFIX, arch_lib_path)
> > > rtems.check_lib_path(conf, lib = 'm')
> > > -rtems.check_lib_path(conf, lib = 'lvgl', mandatory = False)
> > > -rtems.check_lib_path(conf, lib = 'bsd', mandatory = False)
> > > +rtems.check_lib_path(conf, lib = 'lvgl',
> > > + libpath = [arch_lib_path],
> > > + mandatory = False)
> > > +rtems.check_lib_path(conf, lib = 'bsd',
> > > + libpath = [arch_lib_path],
> > > + mandatory = False)
> > >
> > > def build(bld):
> > > bld.recurse('hello')
> > > --
> > > 2.26.2
> > >
> > ___
> > 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 rtems-libbsd] libbsd.py: Build i2c shell command
Ping :) On Fri, Mar 26, 2021 at 2:40 PM Vijay Kumar Banerjee wrote: > > --- > libbsd.py | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/libbsd.py b/libbsd.py > index f7efda43..fe0566e7 100644 > --- a/libbsd.py > +++ b/libbsd.py > @@ -258,6 +258,7 @@ class rtems(builder.Module): > 'rtems/rtems-bsd-rc-conf.c', > 'rtems/rtems-bsd-set-if-input.c', > 'rtems/rtems-bsd-shell-arp.c', > +'rtems/rtems-bsd-shell-i2c.c', > 'rtems/rtems-bsd-shell-ifconfig.c', > 'rtems/rtems-bsd-shell-ifmcstat.c', > 'rtems/rtems-bsd-shell-netstat.c', > -- > 2.26.2 > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-libbsd] Import telnetd from RTEMS repository
ping :)
On Tue, Mar 23, 2021 at 2:10 PM Vijay Kumar Banerjee wrote:
>
> The files have been taken from RTEMS repository with head commit at
> bd9e45d91f77657445400bc2c814f251c9e37cef
> ---
> libbsd.py| 22 +-
> rtemsbsd/include/rtems/telnetd.h | 137 +
> rtemsbsd/telnetd/README | 23 +
> rtemsbsd/telnetd/check_passwd.c | 106
> rtemsbsd/telnetd/des.c | 873 +++
> rtemsbsd/telnetd/des.h | 1 +
> rtemsbsd/telnetd/genpw.c | 79 +++
> rtemsbsd/telnetd/pty.c | 401 ++
> rtemsbsd/telnetd/telnetd-init.c | 18 +
> rtemsbsd/telnetd/telnetd.c | 449
> 10 files changed, 2100 insertions(+), 9 deletions(-)
> create mode 100644 rtemsbsd/include/rtems/telnetd.h
> create mode 100644 rtemsbsd/telnetd/README
> create mode 100644 rtemsbsd/telnetd/check_passwd.c
> create mode 100644 rtemsbsd/telnetd/des.c
> create mode 100644 rtemsbsd/telnetd/des.h
> create mode 100644 rtemsbsd/telnetd/genpw.c
> create mode 100644 rtemsbsd/telnetd/pty.c
> create mode 100644 rtemsbsd/telnetd/telnetd-init.c
> create mode 100644 rtemsbsd/telnetd/telnetd.c
>
> diff --git a/libbsd.py b/libbsd.py
> index a2056f36..f7efda43 100644
> --- a/libbsd.py
> +++ b/libbsd.py
> @@ -293,6 +293,12 @@ class rtems(builder.Module):
> 'pppd/upap.c',
> 'pppd/utils.c',
> 'telnetd/telnetd-service.c',
> +'telnetd/check_passwd.c',
> +'telnetd/des.c',
> +'telnetd/pty.c',
> +'telnetd/genpw.c',
> +'telnetd/telnetd-init.c',
> +'telnetd/telnetd.c',
> ],
> mm.generator['source']()
> )
> @@ -5368,8 +5374,7 @@ class tests(builder.Module):
> self.addTest(mm.generator['test']('arphole', ['test_main'],
>runTest = False, netTest = True))
> self.addTest(mm.generator['test']('telnetd01', ['test_main'],
> - runTest = False, netTest = True,
> - extraLibs = ['telnetd']))
> + runTest = False, netTest = True))
> self.addTest(mm.generator['test']('unix01', ['test_main']))
> self.addTest(mm.generator['test']('ftpd01', ['test_main'],
>netTest = True,
> @@ -5397,27 +5402,26 @@ class tests(builder.Module):
> self.addTest(mm.generator['test']('mutex01', ['test_main']))
> self.addTest(mm.generator['test']('condvar01', ['test_main']))
> self.addTest(mm.generator['test']('ppp01', ['test_main'], runTest =
> False,
> - extraLibs = ['ftpd', 'telnetd']))
> + extraLibs = ['ftpd']))
> self.addTest(mm.generator['test']('zerocopy01', ['test_main'],
> - runTest = False, netTest = True,
> - extraLibs = ['telnetd']))
> + runTest = False, netTest = True))
> self.addTest(mm.generator['test']('smp01', ['test_main'], extraLibs
> = ['rtemstest']))
> self.addTest(mm.generator['test']('media01', ['test_main'],
>runTest = False,
> - extraLibs = ['ftpd', 'telnetd']))
> + extraLibs = ['ftpd']))
> self.addTest(mm.generator['test']('mcast01', ['test_main']))
> self.addTest(mm.generator['test']('vlan01', ['test_main'], netTest =
> True))
> self.addTest(mm.generator['test']('lagg01', ['test_main'], netTest =
> True))
> self.addTest(mm.generator['test']('log01', ['test_main']))
> self.addTest(mm.generator['test']('rcconf01', ['test_main']))
> self.addTest(mm.generator['test']('rcconf02', ['test_main'],
> - extraLibs = ['ftpd', 'telnetd']))
> + extraLibs = ['ftpd']))
> self.addTest(mm.generator['test']('cdev01', ['test_main',
> 'test_cdev']))
> self.addTest(mm.generator['test']('pf01', ['test_main'],
> - extraLibs = ['ftpd', 'telnetd']))
> + extraLibs = ['ftpd']))
> self.addTest(mm.generator['test']('pf02', ['test_main'],
>runTest = False,
> - extraLibs = ['ftpd', 'telnetd']))
> + extraLibs = ['ftpd']))
> self.addTest(mm.generator['test']('termios', ['test_main',
>'test_termios_driver',
>
Re: [PATCH rtems-docs v3] networking: Rename to legacy networking
On Fri, Mar 26, 2021 at 5:26 PM Joel Sherrill wrote:
>
>
>
> On Fri, Mar 26, 2021, 5:53 PM Vijay Kumar Banerjee wrote:
>>
>> Hi Joel,
>>
>> On Fri, Mar 26, 2021, 16:46 Joel Sherrill wrote:
>>>
>>> I thought I said this looked good on the first round.
>>
>> In this version of the patch I send networking to bottom of the index in
>> coverpage.
>
>
> Sorry. That was a subtle change. Thanks for making it.
Ok to push?
>>
>>
>>>
>>> My only question was whether you want to update it the minimum to point to
>>> the legacy stack as a separate package. But that should be a follow up
>>> patch.
>>
>>
>> Yes, I'll add a note in the docs about the separate package and how to build
>> it manually and with RSB. I'll send that as a separate patch as you
>> mentioned.
>
>
> Good enough. Thanks to you the legacy network stack is not as dead as it
> could be. Since you did this fantastic piece of work to put it in a separate
> repository, we just want the documentation to reflect that.
>>
>>
>>
>> Best regards,
>> Vijay
>>>
>>>
>>> --joel
>>>
>>> On Fri, Mar 26, 2021 at 3:48 PM Vijay Kumar Banerjee
>>> wrote:
Ping :)
On Tue, Mar 23, 2021 at 2:04 PM Vijay Kumar Banerjee
wrote:
>
> ---
> book/index_book.rst | 2 +-
> {networking => legacy-networking}/command.rst | 0
> {networking => legacy-networking}/conf.py | 6 +++---
> {networking => legacy-networking}/dec_21140.rst | 0
> {networking => legacy-networking}/index.rst | 2 +-
> {networking => legacy-networking}/network_servers.rst | 0
> .../network_task_structure.rst | 0
> {networking => legacy-networking}/networking_driver.rst | 0
> {networking => legacy-networking}/preface.rst | 0
> {networking => legacy-networking}/testing_the_driver.rst| 0
> .../using_networking_rtems_app.rst | 0
> {networking => legacy-networking}/wscript | 0
> wscript | 4 ++--
> 13 files changed, 7 insertions(+), 7 deletions(-)
> rename {networking => legacy-networking}/command.rst (100%)
> rename {networking => legacy-networking}/conf.py (58%)
> rename {networking => legacy-networking}/dec_21140.rst (100%)
> rename {networking => legacy-networking}/index.rst (92%)
> rename {networking => legacy-networking}/network_servers.rst (100%)
> rename {networking => legacy-networking}/network_task_structure.rst
> (100%)
> rename {networking => legacy-networking}/networking_driver.rst (100%)
> rename {networking => legacy-networking}/preface.rst (100%)
> rename {networking => legacy-networking}/testing_the_driver.rst (100%)
> rename {networking => legacy-networking}/using_networking_rtems_app.rst
> (100%)
> rename {networking => legacy-networking}/wscript (100%)
>
> diff --git a/book/index_book.rst b/book/index_book.rst
> index 8282006..afe15a1 100644
> --- a/book/index_book.rst
> +++ b/book/index_book.rst
> @@ -23,7 +23,7 @@ Table of Contents
> cpu_supplement/index.rst
> develenv/index.rst
> filesystem/index.rst
> - networking/index.rst
> porting/index.rst
> posix1003_1/index.rst
> posix_users/index.rst
> + legacy_networking/index.rst
> diff --git a/networking/command.rst b/legacy-networking/command.rst
> similarity index 100%
> rename from networking/command.rst
> rename to legacy-networking/command.rst
> diff --git a/networking/conf.py b/legacy-networking/conf.py
> similarity index 58%
> rename from networking/conf.py
> rename to legacy-networking/conf.py
> index 1c129bc..98a06b6 100644
> --- a/networking/conf.py
> +++ b/legacy-networking/conf.py
> @@ -3,12 +3,12 @@ sys.path.insert(0, os.path.abspath('../common/'))
>
> from conf import *
>
> -project = "RTEMS Networking User Manual"
> +project = "RTEMS Legacy Networking User Manual"
>
> latex_documents = [
> ('index',
> - 'networking.tex',
> - u'RTEMS Networking User Manual',
> + 'legacy-networking.tex',
> + u'RTEMS Legacy Networking User Manual',
> u'RTEMS Documentation Project',
> 'manual'),
> ]
> diff --git a/networking/dec_21140.rst b/legacy-networking/dec_21140.rst
> similarity index 100%
> rename from networking/dec_21140.rst
> rename to legacy-networking/dec_21140.rst
> diff --git a/networking/index.rst b/legacy-networking/index.rst
> similarity index 92%
> rename from networking/index.rst
> rename to legacy-networking/index.rst
> index f56a60d..b85119d 10
Re: [PATCH rtems-net-legacy 1/2] Remove RTEMS_NETWORKING checks
ping :)
On Tue, Mar 23, 2021 at 2:10 PM Vijay Kumar Banerjee wrote:
>
> * Remove nfsclient wscript and build from netlegacy.py
> ---
> bsps/powerpc/mpc55xxevb/net/smsc9218i.c | 4 +--
> libmisc/dummy-networking.c | 44 -
> netlegacy.py| 17 +-
> nfsclient/wscript | 1 +
> telnetd/telnetd.c | 4 ---
> wscript | 2 +-
> 6 files changed, 41 insertions(+), 31 deletions(-)
>
> diff --git a/bsps/powerpc/mpc55xxevb/net/smsc9218i.c
> b/bsps/powerpc/mpc55xxevb/net/smsc9218i.c
> index d88aa8a..384f9cd 100644
> --- a/bsps/powerpc/mpc55xxevb/net/smsc9218i.c
> +++ b/bsps/powerpc/mpc55xxevb/net/smsc9218i.c
> @@ -24,7 +24,7 @@
>
> #include
>
> -#if defined(RTEMS_NETWORKING) && defined(MPC55XX_HAS_SIU)
> +#if defined(MPC55XX_HAS_SIU)
>
> #include
>
> @@ -2121,4 +2121,4 @@ int smsc9218i_attach_detach(
>return 0;
> }
>
> -#endif /* defined(RTEMS_NETWORKING) && defined(MPC55XX_HAS_SIU) */
> +#endif /* defined(MPC55XX_HAS_SIU) */
> diff --git a/libmisc/dummy-networking.c b/libmisc/dummy-networking.c
> index 379e23e..b7f15c8 100644
> --- a/libmisc/dummy-networking.c
> +++ b/libmisc/dummy-networking.c
> @@ -16,27 +16,25 @@
> #include
>
> /* Loopback Network Configuration */
> -#if defined(RTEMS_NETWORKING)
> - #include
> - #include
> - #include
> +#include
> +#include
> +#include
>
> - struct rtems_bsdnet_config rtems_bsdnet_config = {
> - NULL, /* Network interface */
> - NULL, /* Use fixed network configuration */
> - 0, /* Default network task priority */
> - 0, /* Default mbuf capacity */
> - 0, /* Default mbuf cluster capacity */
> - "testSystem", /* Host name */
> - "nowhere.com", /* Domain name */
> - "127.0.0.1",/* Gateway */
> - "127.0.0.1",/* Log host */
> - {"127.0.0.1" }, /* Name server(s) */
> - {"127.0.0.1" }, /* NTP server(s) */
> - 1, /* sb_efficiency */
> - 0, /* udp_tx_buf_size */
> - 0, /* udp_rx_buf_size */
> - 0, /* tcp_tx_buf_size */
> - 0 /* tcp_rx_buf_size */
> - };
> -#endif
> +struct rtems_bsdnet_config rtems_bsdnet_config = {
> +NULL, /* Network interface */
> +NULL, /* Use fixed network configuration */
> +0, /* Default network task priority */
> +0, /* Default mbuf capacity */
> +0, /* Default mbuf cluster capacity */
> +"testSystem", /* Host name */
> +"nowhere.com", /* Domain name */
> +"127.0.0.1",/* Gateway */
> +"127.0.0.1",/* Log host */
> +{"127.0.0.1" }, /* Name server(s) */
> +{"127.0.0.1" }, /* NTP server(s) */
> +1, /* sb_efficiency */
> +0, /* udp_tx_buf_size */
> +0, /* udp_rx_buf_size */
> +0, /* tcp_tx_buf_size */
> +0 /* tcp_rx_buf_size */
> +};
> diff --git a/netlegacy.py b/netlegacy.py
> index 0889548..0e69076 100644
> --- a/netlegacy.py
> +++ b/netlegacy.py
> @@ -54,6 +54,12 @@ def build(bld):
> for s in os.listdir('./pppd') if s[-2:] == '.c']
> telnetd_source = [os.path.join('./telnetd', s)
>for s in os.listdir('telnetd') if s[-2:] == '.c']
> +nfs_source = []
> +for root, dirs, files in os.walk('./nfsclient'):
> +for name in files:
> +if name[-2:] == '.c':
> +src_root = root.split('/')[2]
> +nfs_source.append(os.path.join('./nfsclient', src_root,
> name))
>
> bsp_dirs, bsp_sources = bsp_drivers.bsp_files(bld)
>
> @@ -66,6 +72,7 @@ def build(bld):
> './bsps/include'])
> arch_lib_path = rtems.arch_bsp_lib_path(bld.env.RTEMS_VERSION,
> bld.env.RTEMS_ARCH_BSP)
> +lib_path = os.path.join(bld.env.PREFIX, arch_lib_path)
> include_path.append(os.path.relpath(os.path.join(bld.env.PREFIX,
> arch_lib_path)))
> include_path.append(os.path.relpath(os.path.join(bld.env.PREFIX,
> @@ -73,6 +80,8 @@ def build(bld):
> 'include')))
> include_path.append('./bsps/include/libchip')
>
> +bld.read_stlib('rtemsbsp', paths=[lib_path])
> +
> if bsp in bsp_dirs:
> include_path.extend(bsp_dirs[bsp])
>
> @@ -107,8 +116,14 @@ def build(bld):
>use='networking',
>source=telnetd_source)
>
> +bld.stlib(target='nfs
Re: [PATCH rtems-net-legacy 2/2] greth.c: Pull RTEMS commit for variable size descriptor
ping :) On Tue, Mar 23, 2021 at 2:10 PM Vijay Kumar Banerjee wrote: > > RTEMS commit hash: 053b17ce8e3f710167e9ec3f44b37756cbdcbec0 > --- > bsps/shared/grlib/net/greth.c | 22 +++--- > 1 file changed, 15 insertions(+), 7 deletions(-) > > diff --git a/bsps/shared/grlib/net/greth.c b/bsps/shared/grlib/net/greth.c > index 8b19b48..84efcd7 100644 > --- a/bsps/shared/grlib/net/greth.c > +++ b/bsps/shared/grlib/net/greth.c > @@ -187,6 +187,7 @@ struct greth_softc > unsigned int advmodes; /* advertise ethernet speed modes. 0 = all modes. > */ > struct timespec auto_neg_time; > int mc_available; > + int num_descs; > > /* > * Statistics > @@ -423,7 +424,7 @@ greth_initialize_hardware (struct greth_softc *sc) > int tmp2; > struct timespec tstart, tnow; > greth_regs *regs; > -unsigned int advmodes, speed; > +unsigned int advmodes, speed, tabsize; > > regs = sc->regs; > > @@ -617,8 +618,9 @@ auto_neg_done: > /* Initialize rx/tx descriptor table pointers. Due to alignment we > * always allocate maximum table size. > */ > -sc->txdesc = (greth_rxtxdesc *) almalloc(0x800, 0x400); > -sc->rxdesc = (greth_rxtxdesc *) &sc->txdesc[128]; > +tabsize = sc->num_descs * 8; > +sc->txdesc = (greth_rxtxdesc *) almalloc(tabsize * 2, tabsize); > +sc->rxdesc = (greth_rxtxdesc *) (tabsize + (void *)sc->txdesc); > sc->tx_ptr = 0; > sc->tx_dptr = 0; > sc->tx_cnt = 0; > @@ -632,8 +634,8 @@ auto_neg_done: > CPUMEM_TO_DMA, > (void *)sc->txdesc, > (void **)&sc->txdesc_remote, > -0x800); > -sc->rxdesc_remote = sc->txdesc_remote + 0x400; > +tabsize * 2); > +sc->rxdesc_remote = sc->txdesc_remote + tabsize; > regs->txdesc = (int) sc->txdesc_remote; > regs->rxdesc = (int) sc->rxdesc_remote; > > @@ -1555,6 +1557,7 @@ int greth_device_init(struct greth_softc *sc) > struct ambapp_core *pnpinfo; > union drvmgr_key_value *value; > unsigned int speed; > +int i, nrd; > > /* Get device information from AMBA PnP information */ > ambadev = (struct amba_dev_info *)sc->dev->businfo; > @@ -1608,12 +1611,17 @@ int greth_device_init(struct greth_softc *sc) > sc->rxbufs = 32; > sc->phyaddr = -1; > > +/* Probe the number of descriptors available the */ > +nrd = (sc->regs->status & GRETH_STATUS_NRD) >> 24; > +for (sc->num_descs = 128, i = 0; i < nrd; i++) > +sc->num_descs = sc->num_descs * 2; > + > value = drvmgr_dev_key_get(sc->dev, "txDescs", DRVMGR_KT_INT); > -if ( value && (value->i <= 128) ) > +if ( value && (value->i <= sc->num_descs) ) > sc->txbufs = value->i; > > value = drvmgr_dev_key_get(sc->dev, "rxDescs", DRVMGR_KT_INT); > -if ( value && (value->i <= 128) ) > +if ( value && (value->i <= sc->num_descs) ) > sc->rxbufs = value->i; > > value = drvmgr_dev_key_get(sc->dev, "phyAdr", DRVMGR_KT_INT); > -- > 2.26.2 > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems 03/18] verified that we can compile with MVETH_TESTING and MVETH_DEBUG
On 30/3/21 12:27 pm, Vijay Kumar Banerjee wrote:
> From: till straumann
>
> Update #4344
> ---
> bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c | 59 +++
> .../beatnik/net/if_mve/mv643xx_eth_bsdnet.c | 1 -
> 2 files changed, 47 insertions(+), 13 deletions(-)
>
> diff --git a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
> b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
> index 26fe7db9e6..9d23d22898 100644
> --- a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
> +++ b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
> @@ -108,16 +108,10 @@
> /* Compile-time debugging features */
>
> /* Enable paranoia assertions and checks; reduce # of descriptors to minimum
> for stressing */
> -#undef MVETH_TESTING
> +#define MVETH_TESTING
>
> /* Enable debugging messages and some support routines (dump rings etc.)
> */
> -#undef MVETH_DEBUG
> -
> -/* Hack for driver development; rtems bsdnet doesn't implement detaching an
> interface :-(
> - * but this hack allows us to unload/reload the driver module which makes
> development
> - * a lot less painful.
> - */
> -#undef MVETH_DETACH_HACK
> +#define MVETH_DEBUG
Is this suppose to be enabled?
Chris
>
> /* Ring sizes */
>
> @@ -790,6 +784,15 @@ static const char *mibfmt[] = {
>
> /* forward decls + implementation for IRQ API funcs */
>
> +STATIC int
> +mveth_init_rx_desc_ring(struct mveth_private *mp);
> +
> +STATIC int
> +mveth_init_tx_desc_ring(struct mveth_private *mp);
> +
> +int
> +BSP_mve_dring_nonsync(struct mveth_private *mp);
> +
> static void mveth_isr(rtems_irq_hdl_param unit);
> static void noop(const rtems_irq_connect_data *unused) {}
> static int noop1(const rtems_irq_connect_data *unused) { return 0; }
> @@ -1747,7 +1750,7 @@ MveEthBufIter head = *it;
>
> #ifdef MVETH_TESTING
> assert( !h->buf_ptr );
> - assert( !h->mb );
> + assert( !h->u_buf );
> #endif
>
> /* Don't use the first descriptor yet because BSP_mve_swipe_tx()
> @@ -1778,7 +1781,7 @@ MveEthBufIter head = *it;
>*/
> for ( l = NEXT_TXD(h); l!=d; l=NEXT_TXD(l) ) {
> #ifdef MVETH_TESTING
> - assert( l->mb == 0 );
> + assert( l->u_buf == 0 );
> #endif
> l->buf_ptr = 0;
> l->cmd_sts = 0;
> @@ -1870,7 +1873,7 @@ int frst_len;
> rval = 0;
>
> #ifdef MVETH_TESTING
> - assert(header || data);
> + assert(head_p || data_p);
> #endif
>
> needed = head_p && data_p ? 2 : 1;
> @@ -1887,7 +1890,7 @@ int frst_len;
>
> #ifdef MVETH_TESTING
> assert( !h->buf_ptr );
> - assert( !h->mb );
> + assert( !h->u_buf );
> #endif
>
> /* find the 'first' user buffer */
> @@ -2359,3 +2362,35 @@ uint32_t v;
> }
> fprintf(f, "\n");
> }
> +
> +#ifdef MVETH_DEBUG
> +/* Display/dump descriptor rings */
> +
> +/* These low-level routines need to be synchronized with
> + * any Tx/Rx threads!
> + */
> +int
> +BSP_mve_dring_nonsync(struct mveth_private *mp)
> +{
> +int i;
> +if (1) {
> +MvEthRxDesc pr;
> +printf("RX:\n");
> +
> + for (i=0, pr=mp->rx_ring; irbuf_count; i++, pr++) {
> + printf("cnt: 0x%04x, size: 0x%04x, stat: 0x%08x, next: 0x%08x,
> buf: 0x%08x\n",
> + pr->byte_cnt, pr->buf_size, pr->cmd_sts,
> (uint32_t)pr->next_desc_ptr, pr->buf_ptr);
> + }
> +}
> +if (1) {
> +MvEthTxDesc pt;
> +printf("TX:\n");
> + for (i=0, pt=mp->tx_ring; ixbuf_count; i++, pt++) {
> + printf("cnt: 0x%04x, stat: 0x%08x, next: 0x%08x, buf: 0x%08x,
> mb: 0x%08x\n",
> + pt->byte_cnt, pt->cmd_sts, (uint32_t)pt->next_desc_ptr,
> pt->buf_ptr,
> + (uint32_t)pt->u_buf);
> + }
> +}
> + return 0;
> +}
> +#endif
> diff --git a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
> b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
> index 2e841c5e8b..3f85e2c78a 100644
> --- a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
> +++ b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth_bsdnet.c
> @@ -135,7 +135,6 @@
> /* Enable Hardware Snooping; if this is disabled (undefined),
> * cache coherency is maintained by software.
> */
> -#undef ENABLE_HW_SNOOPING
>
> /* Compile-time debugging features */
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-docs] common/latex.py: use distro module for python3.5 and up
Hi,
Sorry for too many pings at once :)
Thanks.
On Tue, Mar 23, 2021 at 2:05 PM Vijay Kumar Banerjee wrote:
>
> ---
> common/latex.py | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/common/latex.py b/common/latex.py
> index a042510..a1b3917 100644
> --- a/common/latex.py
> +++ b/common/latex.py
> @@ -3,8 +3,11 @@
> #
>
> import os
> -import platform
> import re
> +try:
> +from distro import linux_distribution
> +except:
> +from platform import linux_distribution
>
> package_test_preamble = ['\\newif\\ifsphinxKeepOldNames
> \\sphinxKeepOldNamestrue',
> '\documentclass[a4paper,11pt,english]{report}']
> @@ -82,7 +85,7 @@ def tex_test(test):
> def host_name():
> uname = os.uname()
> if uname[0] == 'Linux':
> -distro = platform.dist()
> +distro = linux_distribution()
> name = '%s/%s' % (uname[0], distro[0])
> version = distro[1]
> else:
> --
> 2.26.2
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-libbsd 1/5] rtemsbsd: Add mv643xx nexus ethernet driver
On 30/3/21 12:30 pm, Vijay Kumar Banerjee wrote: > From: till straumann > > Update #4345 > --- > libbsd.py| 19 + > rtemsbsd/include/bsp/nexus-devices.h | 7 +- > rtemsbsd/sys/dev/mve/mv643xx_nexus.c | 965 +++ > 3 files changed, 990 insertions(+), 1 deletion(-) > create mode 100644 rtemsbsd/sys/dev/mve/mv643xx_nexus.c > > diff --git a/libbsd.py b/libbsd.py > index a2056f36..b25d7e03 100644 > --- a/libbsd.py > +++ b/libbsd.py > @@ -292,6 +292,25 @@ class rtems(builder.Module): > 'pppd/sys-rtems.c', > 'pppd/upap.c', > 'pppd/utils.c', > +'sys/arm/lpc/if_lpe.c', > +'sys/arm/lpc/lpc_pwr.c', > +'sys/dev/atsam/if_atsam.c', > +'sys/dev/atsam/if_atsam_media.c', > +'sys/dev/dw_mmc/dw_mmc.c', > +'sys/dev/ffec/if_ffec_mcf548x.c', > +'sys/dev/ffec/if_ffec_mpc8xx.c', > +'sys/dev/mve/mv643xx_nexus.c', > +'sys/dev/input/touchscreen/tsc_lpc32xx.c', > +'sys/dev/smc/if_smc_nexus.c', > +'sys/dev/tsec/if_tsec_nexus.c', > +'sys/dev/usb/controller/ehci_mpc83xx.c', > +'sys/dev/usb/controller/ohci_lpc32xx.c', > +'sys/dev/usb/controller/ohci_lpc.c', > +'sys/dev/usb/controller/usb_otg_transceiver.c', > +'sys/dev/usb/controller/usb_otg_transceiver_dump.c', > +'sys/fs/devfs/devfs_devs.c', > +'sys/net/if_ppp.c', > +'sys/net/ppp_tty.c', > 'telnetd/telnetd-service.c', This looks like it is more than just this driver? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Two Resource Leaks
realview_pbx_a9_qemu Cool, that's interesting. On Mon, Mar 29, 2021 at 6:38 PM Joel Sherrill wrote: > > > On Mon, Mar 29, 2021 at 7:56 AM Richi Dubey wrote: > >> >> https://docs.google.com/spreadsheets/d/12FkAE6Wvo0dDw9D75p-w8UISc8_aOKQqntvruGGdeN4/edit#gid=0 >> >> This sheet has rtems-test result comparisons between different SMP >> schedulers set as default schedulers and has results from last the 2 >> months. This might be of help to you. >> > > Thanks! Which BSP? > > I ran mips/jmr3904 yesterday and need to look at all those results. It is > one of my favorite BSPs to test on because it has no valid addresses > between 0x0 and 0x7fff. That tends to catch any random writes. It has > ~14 failiures now. > >> >> On Sat, Mar 27, 2021 at 9:50 PM Joel Sherrill wrote: >> >>> >>> >>> On Sat, Mar 27, 2021, 11:07 AM Sebastian Huber < >>> sebastian.hu...@embedded-brains.de> wrote: >>> On 27/03/2021 16:08, Joel Sherrill wrote: > The issue I found is different and won't happen on every target or > bsp. > > Psim has 6-9 failures even after freeing the right stack address. > > > The stack address and now (I think) size saved for later use are wrong > and this leads to multiple failures. I work on a fix. psim seems to be a good platform for these tests. >>> >>> I put a patch for the address issue but I think the fundamental issue is >>> you changed the semantics of what was stored in the stack structure. You >>> probably want a different approach but this is at least a good >>> temporary fix. >>> >>> And something different on Libbsd. But not sure. >>> >>> I think Richi has raised the issue that there are some recently >>> introduced failures. Not sure how many are this. >>> -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ >>> 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 project: #4334 Replace Mongoose with Civetweb
Hello Ayushman, hello Gedare, Am 29.03.21 um 18:50 schrieb Gedare Bloom: CC: Christian On Mon, Mar 29, 2021 at 10:34 AM Ayushman Mishra wrote: Sir , It would be very helpful to know about potential mentors of (Replace mongoose with civetweb) https://devel.rtems.org/ticket/4334 this project. I think Christian is the most likely potential mentor. Possible for the civetweb part. I have done quite a bit with mongoose or later civetweb. So most likely I should at least help on this project. But I don't think that building civetweb will be the critical part here. That is quite straightforward. The more tricky part of the project will be to find a way to make the configuration options available to the users. That means either creating a repo (similar to for example rtems-littlevgl) or some integration into RSB (no idea how to add options there). We should try to get someone with more experience in that area into this project too. On Mon, Mar 29, 2021, 9:39 PM Gedare Bloom wrote: On Mon, Mar 29, 2021 at 9:49 AM Ayushman Mishra wrote: I have installed libbsd package (made RTEMS_POSIX_API=True,RTEMS_NETWORKING=True in config.ini file to enable POSIX and networking) but I am still confused about the work That doesn't look right. RTEMS_NETWORKING=True enables the legacy network stack. If you want to build libbsd, you need to check out https://git.rtems.org/rtems-libbsd/ already done in this project in past. Also after interacting on discord I think completely replacing mongoose with another web-server is not a good option since it may rise some user complaints who are already using old system and may find it difficult to instantly switch over to new system , instead civetweb can be added as an extra new web-server where user has a choice to either use old mongoose or the new web server both having all dependencies and functionalities available. No, we will replace mghttpd with civetweb. Anyone who still wants the frozen version of mghttpd can revive it, but we want to replace it moving forward. Agreed. We maybe can leave some hints where to get the current version of mghttpd (basically a commit number, a path and current build options). If someone really want's to continue using mghttpd, he can then copy the files into his application build. But the old version we have is now a lot behind the master and most likely has a lot of bugs and quite some security holes. Also I still don't know whether the project #4334 is long enough for summer of code project and after going through docs I think There are other activities involved in getting civetweb to work well with RTEMS. It should be sufficient, but you would need to flesh out the proposal details with mentor assistance. To be clear, it will be C/network programming. Civetweb also has a lot of different features. If building with basic features is not enough for the project, we can pile different configurations on top of it ;-) I think that we should target at least two configurations: 1. Minimal functionality as http server. 2. Integration with OpenSSL (most likely the version from libbsd) so that we can use https. Having two configurations makes it necessary to create a build environment that allows having configurations. That is a good start for further extensions. Best regards Christian https://devel.rtems.org/ticket/4272 is also a very interesting project since now I think I know a little bit about BSPs and I am good in python and know shell-scripting. I would be very grateful to know more about this project. You should start a new thread to discuss this project. I thought someone else may have inquired about this, maybe it was you? I didn't see any response yet, but probably because it was buried in other content (like this comment) so likely the potential mentor didn't even notice it, especially since all you mention here is the ticket number. Gedare Thanks. On Sat, Mar 27, 2021 at 5:36 PM Ayushman Mishra wrote: Greetings to all the respected mentors, 1. I saw there has been a lot of discussion regarding replacing mongoose with civetweb ( https://lists.rtems.org/pipermail/devel/2016-April/014661.html ). I think the basic outline of the project is like this a. Completely removing mongoose and replace it with civetweb and make it configurable in rsb b. check the parameters and options available in civetweb and make it usable for users in rtems. c. making test-cases for civetweb (should be similar to mongoose) d. documentation of using civetweb and web-server in general. I would be very grateful to know what is the actual current status of this project and the coding involved in it enough for a summer of code project or some extra things should be added in it. Also, 2. I have build bsp on rtems6 and a simple application is working correct, but while trying to build libbsd package in rtems6 (../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/6 \ --host=sparc-rtems6 --with-
