Re: [stm32f4] status of the bsp
Hi Chris Yes, I am very interested. I guess you have interrupts working there? Do you mind your code or work based on it to end up under RTEMS licence on the git repository? Thanks 2014-09-19 6:00 GMT+02:00 Chris Nott : > Hi, I was fiddling with this platform and got as far as a project > implementing a USB device. If you are interested I could send you the code. > It hasn't been touched for a while, it may or may not have bit rot. > > Sent with AquaMail for Android > http://www.aqua-mail.com > > On 18 September 2014 12:12:21 Tomasz Gregorek > wrote: > >> Hello >> >> I am interested in development of the stm32f4 bsp. >> We have small project based on the STM32F429 MCPU which we would like to >> run RTEMS on. >> >> From the current code one could say there is not much. Only UART in >> polling, started I2C, some defines and few registers descriptions, >> interrupts just touched. >> >> Is anyone working on this so I would not double the work? >> What is current status of the work? >> >> Who can I contact for some initial information about bsps? >> >> Still a lot of reading to do... >> >> Best regards >> Tomasz >> ___ >> 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: Moving to GCC 4.9
On September 19, 2014 12:00:26 AM CDT, Sebastian Huber wrote: >On 18/09/14 23:47, Joel Sherrill wrote: >> Hi >> >> Is it possible to move all platforms to GCC 4.9.x? >> >> If not, which ones have issues and do these issues >> have GCC PRs filed? >> >> Thanks. >> > >The PowerPC build issues have been fixed. Also the C++ problem with >GCC 4.9 >for SMP configurations is fixed. So we should move to the latest GCC 4.9 release? We can discuss whether it makes sense to wait until my newlib inttypes.h work is done. Then we only make one tool bump. Newlib should be making monthly tarball snapshots starting in October per our request so that may be a good point to bump both. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 6/6] Thread Queue: Merge discipline subroutines into main methods
On 08/07/14 22:52, Joel Sherrill wrote:
There was a lot of duplication between the discipline subroutines.
With the transition to RBTrees for priority discipline, there were
only a few lines of source code manipulating the data structure
for FIFO and priority. Thus is made sense to fold these back
into the main methods.
As part of doing this all of the tests for discipline were changed
to be in the same order.
[...]
diff --git a/cpukit/score/src/threadqdequeue.c
b/cpukit/score/src/threadqdequeue.c
index 93d5c07..3b55e52 100644
--- a/cpukit/score/src/threadqdequeue.c
+++ b/cpukit/score/src/threadqdequeue.c
[...]
+ /*
+ * We did not find a thread to unblock.
+ */
+ if ( !the_thread ) {
+sync_state = the_thread_queue->sync_state;
+if ( (sync_state == THREAD_BLOCKING_OPERATION_TIMEOUT) ||
+ (sync_state == THREAD_BLOCKING_OPERATION_NOTHING_HAPPENED) ) {
+ the_thread_queue->sync_state = THREAD_BLOCKING_OPERATION_SATISFIED;
+ the_thread = _Thread_Executing;
}
- _ISR_Enable( level );
+_ISR_Enable( level );
+return NULL;
+ }
This introduced a serious bug and its pretty sad that the test suite didn't
find it. This is one of the core routines and we had no proper test case for it.
In case we set the_thread_queue->sync_state =
THREAD_BLOCKING_OPERATION_SATISFIED we must not return NULL.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 6/6] Thread Queue: Merge discipline subroutines into main methods
On September 19, 2014 7:28:36 AM CDT, Sebastian Huber
wrote:
>On 08/07/14 22:52, Joel Sherrill wrote:
>> There was a lot of duplication between the discipline subroutines.
>> With the transition to RBTrees for priority discipline, there were
>> only a few lines of source code manipulating the data structure
>> for FIFO and priority. Thus is made sense to fold these back
>> into the main methods.
>>
>> As part of doing this all of the tests for discipline were changed
>> to be in the same order.
>[...]
>> diff --git a/cpukit/score/src/threadqdequeue.c
>b/cpukit/score/src/threadqdequeue.c
>> index 93d5c07..3b55e52 100644
>> --- a/cpukit/score/src/threadqdequeue.c
>> +++ b/cpukit/score/src/threadqdequeue.c
>[...]
>> + /*
>> + * We did not find a thread to unblock.
>> + */
>> + if ( !the_thread ) {
>> +sync_state = the_thread_queue->sync_state;
>> +if ( (sync_state == THREAD_BLOCKING_OPERATION_TIMEOUT) ||
>> + (sync_state == THREAD_BLOCKING_OPERATION_NOTHING_HAPPENED)
>) {
>> + the_thread_queue->sync_state =
>THREAD_BLOCKING_OPERATION_SATISFIED;
>> + the_thread = _Thread_Executing;
>> }
>> - _ISR_Enable( level );
>> +_ISR_Enable( level );
>> +return NULL;
>> + }
>
>This introduced a serious bug and its pretty sad that the test suite
>didn't
>find it. This is one of the core routines and we had no proper test
>case for it.
>
>In case we set the_thread_queue->sync_state =
>THREAD_BLOCKING_OPERATION_SATISFIED we must not return NULL.
:( other than adding debug asserts, any ideas on how to test this? It is an
internal state that the tests are not supposed to have visibility on.
It should be possible to add a wrapper to thread queue operations when debug is
enabled which checked the various conditions.
At least that would have caught it.
--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] or1k fix bug: Initialize thread context with higher stack address.
Since or1k architecture stack grows down, threads should be initialized with high stack addresses instead of lower ones. This is done in _CPU_Context_Initialize function. --- cpukit/score/cpu/or1k/or1k-context-initialize.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/cpukit/score/cpu/or1k/or1k-context-initialize.c b/cpukit/score/cpu/or1k/or1k-context-initialize.c index 1c9cdd7..a7205e3 100644 --- a/cpukit/score/cpu/or1k/or1k-context-initialize.c +++ b/cpukit/score/cpu/or1k/or1k-context-initialize.c @@ -32,13 +32,14 @@ void _CPU_Context_Initialize( /* Decrement 200 byte to account for red-zone */ uint32_t stack = ((uint32_t) stack_area_begin) - 200; uint32_t sr; + uint32_t stack_high = stack + stack_area_size; sr = _OR1K_mfspr(CPU_OR1K_SPR_SR); memset(context, 0, sizeof(*context)); - context->r1 = stack; - context->r2 = stack; + context->r1 = stack_high; + context->r2 = stack_high; context->r9 = (uint32_t) entry_point; context->sr = sr; } -- 1.9.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
or1ksim: Updated results from RTEMS Tester
Hi, I run another test for or1ksim BSP yesterday via RTEMS Tester and got the following results: Passed: 432 Failed: 4 Timeouts: 67 Invalid:0 Total:503 Average test time: 0:00:23.380789 Testing time : 3:16:00.537058 However, when I tested failures and timeouts separately, most of them work on QEMU, the others miss the trailing end-of-test line, which exists when I run them on or1ksim simulator. By running the other failed, timed-outs tests separately (on both qemu and or1ksim) and re-calculating the previous test results, I got the following: Passed: 496 Failed: 0 Timeouts: 7 Invalid:0 Total:503 List of failures/timeouts (on both qemu and or1ksim) with their output: __ sptls01.exe *** BEGIN OF TEST SPTLS 1 *** Fatal Error 5.1 Halted Note: TLS is not supported yet. __ spintrcritical20.exe *** BEGIN OF TEST SPINTRCRITICAL 20 *** ../../../../../../../rtems/c/src/../../testsuites/sptests/spintrcritical20/init.c: 146 ctx->thread_queue_was_null Fatal Error 5.0 Halted __ sp37.exe *** BEGIN OF TEST SP 37 *** ../../../../../../../rtems/c/src/../../testsuites/sptests/sp37/init.c: 113 ctx.actual_level == current Fatal Error 5.0 Halted __ psxconfig01.exe *** BEGIN OF TEST PSXCONFIG 1 *** used blocks = 50, largest used block = 16464, used space = 90760 free blocks = 1, largest free block = 91216, free space = 91216 rtems_partition_create FAILED -- expected (RTEMS_SUCCESSFUL) got (RTEMS_INVALID_ADDRESS) Fatal Error 5.9 Halted __ fsfseeko01.exe *** BEGIN OF TEST FSFSEEKO 1 *** ../../../../../../../rtems/c/src/../../testsuites/fstests/fsfseeko01/init.c: 67 actual_long_off == -1L Fatal Error 5.0 Halted __ sp20.exe *** BEGIN OF TEST SP 20 *** TA1 - rtems_rate_monotonic_create id = 0x42010001 TA1 - rtems_rate_monotonic_ident id = 0x42010001 TA1 - (0x42010001) period 2 TA2 - rtems_rate_monotonic_create id = 0x42010002 TA2 - rtems_rate_monotonic_ident id = 0x42010002 TA2 - (0x42010002) period 2 TA3 - rtems_rate_monotonic_create id = 0x42010003 TA3 - rtems_rate_monotonic_ident id = 0x42010003 TA3 - (0x42010003) period 2 TA4 - rtems_rate_monotonic_create id = 0x42010004 TA4 - rtems_rate_monotonic_ident id = 0x42010004 TA4 - (0x42010004) period 2 TA5 - rtems_rate_monotonic_create id = 0x42010005 TA5 - rtems_rate_monotonic_ident id = 0x42010005 TA5 - (0x42010005) period 100 TA6 - rtems_rate_monotonic_create id = 0x42010006 TA6 - rtems_rate_monotonic_ident id = 0x42010006 TA6 - (0x42010006) period 0 TA5 - PERIODS CHECK OK (1) TA5 - PERIODS CHECK OK (2) TA5 - PERIODS CHECK OK (3) TA5 - PERIODS CHECK OK (4) TA5 - PERIODS CHECK OK (5) TA6 - Actual: 10 Expected: 10 - OK TA6 - Actual: 20 Expected: 20 - OK TA6 - Actual: 30 Expected: 30 - OK TA6 - Actual: 40 Expected: 40 - OK TA6 - Actual: 50 Expected: 50 - OK TA6 - Actual: 60 Expected: 60 - OK TA6 - Actual: 70 Expected: 70 - OK TA6 - Actual: 80 Expected: 80 - OK TA6 - Actual: 90 Expected: 90 - OK TA6 - Actual: 100 Expected: 100 - OK rtems_rate_monotonic_period FAILED -- expected (RTEMS_SUCCESSFUL) got (RTEMS_TIMEOUT) Fatal Error 5.6 Halted __ spintrcritical21.exe *** BEGIN OF TEST SPINTRCRITICAL 21 *** Event sent from ISR hitting synchronization point has NOT occurred ../../../../../../../rtems/c/src/../../testsuites/sptests/spintrcritical21/init.c: 147 case_hit Fatal Error 5.0 Halted __ Notes: spcontext01.exe should not return if the context validate works properly, so it should be always timed-out. minimum.exe should not give any output, but it's considered from time-out Hope this is a good state of the port. Regards, Hesham ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [stm32f4] status of the bsp
Interrupts working yes. No I don't mind. It's a bit of a mess though, I was in the process of doing another cleaner USB device implementation for BeagleBone Black, which I was then going to backport to STM32F4 and eventually maybe work towards some sort of general RTEMS USB device framework. Actually I got the BB black code enumerating as well, I just ran out of time to work on it. I'll send the STM32 project to you soon, I will be travelling for the next week so if I don't get a chance tonight it will probably be in a week or so. Regards, Chris. Sent with AquaMail for Android http://www.aqua-mail.com On 19 September 2014 00:43:59 Tomasz Gregorek wrote: Hi Chris Yes, I am very interested. I guess you have interrupts working there? Do you mind your code or work based on it to end up under RTEMS licence on the git repository? Thanks 2014-09-19 6:00 GMT+02:00 Chris Nott : > Hi, I was fiddling with this platform and got as far as a project > implementing a USB device. If you are interested I could send you the code. > It hasn't been touched for a while, it may or may not have bit rot. > > Sent with AquaMail for Android > http://www.aqua-mail.com > > On 18 September 2014 12:12:21 Tomasz Gregorek > wrote: > >> Hello >> >> I am interested in development of the stm32f4 bsp. >> We have small project based on the STM32F429 MCPU which we would like to >> run RTEMS on. >> >> From the current code one could say there is not much. Only UART in >> polling, started I2C, some defines and few registers descriptions, >> interrupts just touched. >> >> Is anyone working on this so I would not double the work? >> What is current status of the work? >> >> Who can I contact for some initial information about bsps? >> >> Still a lot of reading to do... >> >> Best regards >> Tomasz >> ___ >> 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: [stm32f4] status of the bsp
On Fri, Sep 19, 2014 at 12:26 PM, Chris Nott wrote: > Interrupts working yes. > > No I don't mind. It's a bit of a mess though, I was in the process of doing > another cleaner USB device implementation for BeagleBone Black, which I was > then going to backport to STM32F4 and eventually maybe work towards some > sort of general RTEMS USB device framework. > There is some support for USB in the BSD stack which is probably the best place to put efforts toward improving. I don't personally know the state of USB there. > Actually I got the BB black code enumerating as well, I just ran out of time > to work on it. > > I'll send the STM32 project to you soon, I will be travelling for the next > week so if I don't get a chance tonight it will probably be in a week or so. > > Regards, > Chris. > > Sent with AquaMail for Android > http://www.aqua-mail.com > > On 19 September 2014 00:43:59 Tomasz Gregorek > wrote: >> >> Hi Chris >> >> Yes, I am very interested. >> I guess you have interrupts working there? >> >> Do you mind your code or work based on it to end up under RTEMS licence on >> the git repository? >> Thanks >> >> 2014-09-19 6:00 GMT+02:00 Chris Nott : >>> >>> Hi, I was fiddling with this platform and got as far as a project >>> implementing a USB device. If you are interested I could send you the code. >>> It hasn't been touched for a while, it may or may not have bit rot. >>> >>> Sent with AquaMail for Android >>> http://www.aqua-mail.com >>> >>> On 18 September 2014 12:12:21 Tomasz Gregorek >>> wrote: Hello I am interested in development of the stm32f4 bsp. We have small project based on the STM32F429 MCPU which we would like to run RTEMS on. From the current code one could say there is not much. Only UART in polling, started I2C, some defines and few registers descriptions, interrupts just touched. Is anyone working on this so I would not double the work? What is current status of the work? Who can I contact for some initial information about bsps? Still a lot of reading to do... Best regards Tomasz ___ 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: [stm32f4] status of the bsp
2014-09-19 18:26 GMT+02:00 Chris Nott : > Interrupts working yes. > > No I don't mind. It's a bit of a mess though, I was in the process of > doing another cleaner USB device implementation for BeagleBone Black, which > I was then going to backport to STM32F4 and eventually maybe work towards > some sort of general RTEMS USB device framework. > > Actually I got the BB black code enumerating as well, I just ran out of > time to work on it. > > I'll send the STM32 project to you soon, I will be travelling for the next > week so if I don't get a chance tonight it will probably be in a week or so. > > Regards, > Chris. > > Sent with AquaMail for Android > http://www.aqua-mail.com > > On 19 September 2014 00:43:59 Tomasz Gregorek > wrote: > >> Hi Chris >> >> Yes, I am very interested. >> I guess you have interrupts working there? >> >> Do you mind your code or work based on it to end up under RTEMS licence >> on the git repository? >> Thanks >> >> 2014-09-19 6:00 GMT+02:00 Chris Nott : >> >>> Hi, I was fiddling with this platform and got as far as a project >>> implementing a USB device. If you are interested I could send you the code. >>> It hasn't been touched for a while, it may or may not have bit rot. >>> >>> Sent with AquaMail for Android >>> http://www.aqua-mail.com >>> >>> On 18 September 2014 12:12:21 Tomasz Gregorek >>> wrote: >>> Hello I am interested in development of the stm32f4 bsp. We have small project based on the STM32F429 MCPU which we would like to run RTEMS on. From the current code one could say there is not much. Only UART in polling, started I2C, some defines and few registers descriptions, interrupts just touched. Is anyone working on this so I would not double the work? What is current status of the work? Who can I contact for some initial information about bsps? Still a lot of reading to do... Best regards Tomasz ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel >>> >> No worries, we have some work to do. We have clocks settings and UART interrupt driven implementations almost ready and will be sending those for the review in a day or two. I2C and SPI drivers are the next targets. Thanks ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [stm32f4] status of the bsp
2014-09-19 18:37 GMT+02:00 Gedare Bloom : > On Fri, Sep 19, 2014 at 12:26 PM, Chris Nott wrote: > > Interrupts working yes. > > > > No I don't mind. It's a bit of a mess though, I was in the process of > doing > > another cleaner USB device implementation for BeagleBone Black, which I > was > > then going to backport to STM32F4 and eventually maybe work towards some > > sort of general RTEMS USB device framework. > > > There is some support for USB in the BSD stack which is probably the > best place to put efforts toward improving. I don't personally know > the state of USB there. > > That's a good idea. Thanks Gedare (PS. sending with rtems-devel) > > Actually I got the BB black code enumerating as well, I just ran out of > time > > to work on it. > > > > I'll send the STM32 project to you soon, I will be travelling for the > next > > week so if I don't get a chance tonight it will probably be in a week or > so. > > > > Regards, > > Chris. > > > > Sent with AquaMail for Android > > http://www.aqua-mail.com > > > > On 19 September 2014 00:43:59 Tomasz Gregorek > > > wrote: > >> > >> Hi Chris > >> > >> Yes, I am very interested. > >> I guess you have interrupts working there? > >> > >> Do you mind your code or work based on it to end up under RTEMS licence > on > >> the git repository? > >> Thanks > >> > >> 2014-09-19 6:00 GMT+02:00 Chris Nott : > >>> > >>> Hi, I was fiddling with this platform and got as far as a project > >>> implementing a USB device. If you are interested I could send you the > code. > >>> It hasn't been touched for a while, it may or may not have bit rot. > >>> > >>> Sent with AquaMail for Android > >>> http://www.aqua-mail.com > >>> > >>> On 18 September 2014 12:12:21 Tomasz Gregorek < > tomasz.grego...@gmail.com> > >>> wrote: > > Hello > > I am interested in development of the stm32f4 bsp. > We have small project based on the STM32F429 MCPU which we would like > to > run RTEMS on. > > From the current code one could say there is not much. Only UART in > polling, started I2C, some defines and few registers descriptions, > interrupts just touched. > > Is anyone working on this so I would not double the work? > What is current status of the work? > > Who can I contact for some initial information about bsps? > > Still a lot of reading to do... > > Best regards > Tomasz > ___ > 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
[PATCH] or1ksim: Console: implement uart_read_polled
Implement uart_read_polled which is needed for any application that
reads input from users. It works fine with pppd, capture, and all
termios tests.
---
c/src/lib/libbsp/or1k/or1ksim/console/uart.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/c/src/lib/libbsp/or1k/or1ksim/console/uart.c
b/c/src/lib/libbsp/or1k/or1ksim/console/uart.c
index f1cfa09..c0ee618 100644
--- a/c/src/lib/libbsp/or1k/or1ksim/console/uart.c
+++ b/c/src/lib/libbsp/or1k/or1ksim/console/uart.c
@@ -86,9 +86,18 @@ static int uart_last_close(int major, int minor, void *arg)
return 0;
}
-static int uart_read_polled(int minor)
+static char uart_read_polled(int minor)
{
- return -1;
+ unsigned char lsr;
+ char c;
+
+ /* Get a character when avaiable */
+ do {
+ lsr = OR1KSIM_REG(OR1KSIM_BSP_UART_REG_LINE_STATUS);
+ } while ((lsr & OR1KSIM_BSP_UART_REG_LINE_STATUS_DR)
+ != OR1KSIM_BSP_UART_REG_LINE_STATUS_DR);
+
+ return OR1KSIM_REG(OR1KSIM_BSP_UART_REG_RX);
}
static void uart_write_polled(int minor, char c)
--
1.9.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [stm32f4] status of the bsp
I have used the BSD stack with RTEMS on a project with Chris J. It is fine for some uses but it is very heavyweight for implementing just a device on small embedded target. Sent with AquaMail for Android http://www.aqua-mail.com On 19 September 2014 09:37:35 Gedare Bloom wrote: On Fri, Sep 19, 2014 at 12:26 PM, Chris Nott wrote: > Interrupts working yes. > > No I don't mind. It's a bit of a mess though, I was in the process of doing > another cleaner USB device implementation for BeagleBone Black, which I was > then going to backport to STM32F4 and eventually maybe work towards some > sort of general RTEMS USB device framework. > There is some support for USB in the BSD stack which is probably the best place to put efforts toward improving. I don't personally know the state of USB there. > Actually I got the BB black code enumerating as well, I just ran out of time > to work on it. > > I'll send the STM32 project to you soon, I will be travelling for the next > week so if I don't get a chance tonight it will probably be in a week or so. > > Regards, > Chris. > > Sent with AquaMail for Android > http://www.aqua-mail.com > > On 19 September 2014 00:43:59 Tomasz Gregorek > wrote: >> >> Hi Chris >> >> Yes, I am very interested. >> I guess you have interrupts working there? >> >> Do you mind your code or work based on it to end up under RTEMS licence on >> the git repository? >> Thanks >> >> 2014-09-19 6:00 GMT+02:00 Chris Nott : >>> >>> Hi, I was fiddling with this platform and got as far as a project >>> implementing a USB device. If you are interested I could send you the code. >>> It hasn't been touched for a while, it may or may not have bit rot. >>> >>> Sent with AquaMail for Android >>> http://www.aqua-mail.com >>> >>> On 18 September 2014 12:12:21 Tomasz Gregorek >>> wrote: Hello I am interested in development of the stm32f4 bsp. We have small project based on the STM32F429 MCPU which we would like to run RTEMS on. From the current code one could say there is not much. Only UART in polling, started I2C, some defines and few registers descriptions, interrupts just touched. Is anyone working on this so I would not double the work? What is current status of the work? Who can I contact for some initial information about bsps? Still a lot of reading to do... Best regards Tomasz ___ 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: [stm32f4] status of the bsp
There is a port of LWIP discussed recently on the list which would be very appropriate on lower memory targets. On September 19, 2014 9:21:02 PM CDT, Chris Nott wrote: >I have used the BSD stack with RTEMS on a project with Chris J. It is >fine >for some uses but it is very heavyweight for implementing just a device >on >small embedded target. > >Sent with AquaMail for Android >http://www.aqua-mail.com > > >On 19 September 2014 09:37:35 Gedare Bloom wrote: > >> On Fri, Sep 19, 2014 at 12:26 PM, Chris Nott >wrote: >> > Interrupts working yes. >> > >> > No I don't mind. It's a bit of a mess though, I was in the process >of doing >> > another cleaner USB device implementation for BeagleBone Black, >which I was >> > then going to backport to STM32F4 and eventually maybe work towards >some >> > sort of general RTEMS USB device framework. >> > >> There is some support for USB in the BSD stack which is probably the >> best place to put efforts toward improving. I don't personally know >> the state of USB there. >> >> > Actually I got the BB black code enumerating as well, I just ran >out of time >> > to work on it. >> > >> > I'll send the STM32 project to you soon, I will be travelling for >the next >> > week so if I don't get a chance tonight it will probably be in a >week or so. >> > >> > Regards, >> > Chris. >> > >> > Sent with AquaMail for Android >> > http://www.aqua-mail.com >> > >> > On 19 September 2014 00:43:59 Tomasz Gregorek > >> > wrote: >> >> >> >> Hi Chris >> >> >> >> Yes, I am very interested. >> >> I guess you have interrupts working there? >> >> >> >> Do you mind your code or work based on it to end up under RTEMS >licence on >> >> the git repository? >> >> Thanks >> >> >> >> 2014-09-19 6:00 GMT+02:00 Chris Nott : >> >>> >> >>> Hi, I was fiddling with this platform and got as far as a project >> >>> implementing a USB device. If you are interested I could send you >the code. >> >>> It hasn't been touched for a while, it may or may not have bit >rot. >> >>> >> >>> Sent with AquaMail for Android >> >>> http://www.aqua-mail.com >> >>> >> >>> On 18 September 2014 12:12:21 Tomasz Gregorek > >> >>> wrote: >> >> Hello >> >> I am interested in development of the stm32f4 bsp. >> We have small project based on the STM32F429 MCPU which we would >like to >> run RTEMS on. >> >> From the current code one could say there is not much. Only UART >in >> polling, started I2C, some defines and few registers >descriptions, >> interrupts just touched. >> >> Is anyone working on this so I would not double the work? >> What is current status of the work? >> >> Who can I contact for some initial information about bsps? >> >> Still a lot of reading to do... >> >> Best regards >> Tomasz >> ___ >> 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [stm32f4] status of the bsp
On good, thanks. I was hoping to work up to putting a tcpip stack on one of our STM32F4 boards with ethernet. I thought the BSD stack was the only option but LWIP would be ideal. Sent with AquaMail for Android http://www.aqua-mail.com On 19 September 2014 19:23:33 Joel Sherrill wrote: There is a port of LWIP discussed recently on the list which would be very appropriate on lower memory targets. On September 19, 2014 9:21:02 PM CDT, Chris Nott wrote: >I have used the BSD stack with RTEMS on a project with Chris J. It is >fine >for some uses but it is very heavyweight for implementing just a device >on >small embedded target. > >Sent with AquaMail for Android >http://www.aqua-mail.com > > >On 19 September 2014 09:37:35 Gedare Bloom wrote: > >> On Fri, Sep 19, 2014 at 12:26 PM, Chris Nott >wrote: >> > Interrupts working yes. >> > >> > No I don't mind. It's a bit of a mess though, I was in the process >of doing >> > another cleaner USB device implementation for BeagleBone Black, >which I was >> > then going to backport to STM32F4 and eventually maybe work towards >some >> > sort of general RTEMS USB device framework. >> > >> There is some support for USB in the BSD stack which is probably the >> best place to put efforts toward improving. I don't personally know >> the state of USB there. >> >> > Actually I got the BB black code enumerating as well, I just ran >out of time >> > to work on it. >> > >> > I'll send the STM32 project to you soon, I will be travelling for >the next >> > week so if I don't get a chance tonight it will probably be in a >week or so. >> > >> > Regards, >> > Chris. >> > >> > Sent with AquaMail for Android >> > http://www.aqua-mail.com >> > >> > On 19 September 2014 00:43:59 Tomasz Gregorek > >> > wrote: >> >> >> >> Hi Chris >> >> >> >> Yes, I am very interested. >> >> I guess you have interrupts working there? >> >> >> >> Do you mind your code or work based on it to end up under RTEMS >licence on >> >> the git repository? >> >> Thanks >> >> >> >> 2014-09-19 6:00 GMT+02:00 Chris Nott : >> >>> >> >>> Hi, I was fiddling with this platform and got as far as a project >> >>> implementing a USB device. If you are interested I could send you >the code. >> >>> It hasn't been touched for a while, it may or may not have bit >rot. >> >>> >> >>> Sent with AquaMail for Android >> >>> http://www.aqua-mail.com >> >>> >> >>> On 18 September 2014 12:12:21 Tomasz Gregorek > >> >>> wrote: >> >> Hello >> >> I am interested in development of the stm32f4 bsp. >> We have small project based on the STM32F429 MCPU which we would >like to >> run RTEMS on. >> >> From the current code one could say there is not much. Only UART >in >> polling, started I2C, some defines and few registers >descriptions, >> interrupts just touched. >> >> Is anyone working on this so I would not double the work? >> What is current status of the work? >> >> Who can I contact for some initial information about bsps? >> >> Still a lot of reading to do... >> >> Best regards >> Tomasz >> ___ >> 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Moving to GCC 4.9
On 19/09/2014 9:17 pm, Joel Sherrill wrote: On September 19, 2014 12:00:26 AM CDT, Sebastian Huber wrote: On 18/09/14 23:47, Joel Sherrill wrote: Hi Is it possible to move all platforms to GCC 4.9.x? If not, which ones have issues and do these issues have GCC PRs filed? Thanks. The PowerPC build issues have been fixed. Also the C++ problem with GCC 4.9 for SMP configurations is fixed. So we should move to the latest GCC 4.9 release? We can discuss whether it makes sense to wait until my newlib inttypes.h work is done. Then we only make one tool bump. Newlib should be making monthly tarball snapshots starting in October per our request so that may be a good point to bump both. I will start the process of moving to 4.9. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: or1ksim: Updated results from RTEMS Tester
On 20/09/2014 12:56 am, Hesham Moustafa wrote: However, when I tested failures and timeouts separately, most of them work on QEMU, the others miss the trailing end-of-test line, which exists when I run them on or1ksim simulator. How many cores do you have and what host OS ? I assume this is not on a VM. The tester attempts to have a single test running on each core but the effect this can have may vary from host to host. The --jobs option is there to help. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: or1ksim: Updated results from RTEMS Tester
On Sep 20, 2014 6:44 AM, "Chris Johns" wrote: > > On 20/09/2014 12:56 am, Hesham Moustafa wrote: >> >> However, when I tested failures and timeouts separately, most of them >> work on QEMU, the others miss the trailing end-of-test line, which >> exists when I run them on or1ksim simulator. > > > How many cores do you have and what host OS ? I assume this is not on a VM. I have 4 physical cores, and I usually run make with J8. My host OS is fedora 20. > The tester attempts to have a single test running on each core but the effect this can have may vary from host to host. The --jobs option is there to help. > > 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: or1ksim: Updated results from RTEMS Tester
On 20/09/2014 3:13 pm, Hesham Moustafa wrote: I have 4 physical cores, and I usually run make with J8. My host OS is fedora 20. Try with --jobs=4 and see if you get any time outs. Anything else running at the same time may effect the result. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
