Re: Report on failing tests with thread stack protection and their resolution.

[Utkarsh Rai]

On Mon, Dec 7, 2020 at 8:00 AM Utkarsh Rai  wrote:

>
>
> On Thu, Dec 3, 2020 at 10:22 PM Gedare Bloom  wrote:
>
>>
>>
>> On Wed, Dec 2, 2020 at 5:53 PM Utkarsh Rai 
>> wrote:
>>
>>> Hello,
>>> As discussed in this
>>>  thread,
>>> I have compiled a list of the tests that deal with inter stack
>>> communication and fail with the thread stack protection option. Most of
>>> these tests pass when, as Sebastian suggested and had provided a
>>> wonderful example, I disable memory protection at places where contents of
>>> different thread stacks are accessed by the current thread. There are a few
>>> tests that still fail due to inter-stack access in the application code
>>> itself.
>>>
>>> The changes I have made are -
>>>
>>> diff --git a/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
>>> b/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
>>> index c176d4b8c5..a45b175395 100644
>>> --- a/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
>>> +++ b/bsps/arm/realview-pbx-a9/mmu/bsp-set-mmu-attr.c
>>> @@ -1,15 +1,49 @@
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>
>>> +bool set_memory_flags(Thread_Control* thread, void* arg)
>>> +{
>>> +  uintptr_t begin;
>>> +  uintptr_t end;
>>> +  uint32_t flags;
>>> +  rtems_interrupt_level irq_level;
>>> +  Thread_Control *executing;
>>> +
>>> +  executing = _Thread_Executing;
>>> +
>>> +  if(thread !=  executing) {
>>>
>> This is not concurrency-safe. By time the check happens, or following
>> code happens, the thread could become executing.
>>
>>
>>> +
>>> +flags = *( uint32_t *)( arg );
>>> +begin = thread->Start.Initial_stack.area;
>>> +end = begin + thread->Start.Initial_stack.size;
>>> +
>>> +rtems_interrupt_disable(irq_level);
>>> +arm_cp15_set_translation_table_entries(begin, end, flags);
>>> +rtems_interrupt_enable(irq_level);
>>> +  }
>>> +
>>> +  return false;
>>>
>> why -- what does the return value mean?
>>
>
> While iterating over threads, if the visitor returns true the iteration
> stops.
>
>
>>
>>
>>> +}
>>> +
>>> +rtems_status_code _Memory_protection_Enable( void )
>>> +{
>>> +  uint32_t access_flags;
>>> +
>>> +  access_flags = translate_flags(  RTEMS_NO_ACCESS );
>>> +
>>> +  _Thread_Iterate( set_memory_flags, _flags );
>>> +
>>> +  return RTEMS_SUCCESSFUL; // check the return values for iterating
>>> function and current method.
>>> +}
>>> +
>>> +rtems_status_code _Memory_protection_Disable( void )
>>> +{
>>> +  uint32_t access_flags;
>>> +
>>> +  access_flags = translate_flags(  RTEMS_READ_WRITE );
>>> +
>>> +  _Thread_Iterate( set_memory_flags, _flags );
>>> +
>>> +  return RTEMS_SUCCESSFUL;
>>>  }
>>> \ No newline at end of file
>>> diff --git a/cpukit/include/rtems/score/coremsgimpl.h
>>> b/cpukit/include/rtems/score/coremsgimpl.h
>>> index e598dce96a..3719a3d3c8 100644
>>> --- a/cpukit/include/rtems/score/coremsgimpl.h
>>> +++ b/cpukit/include/rtems/score/coremsgimpl.h
>>> @@ -27,6 +27,10 @@
>>>  #include 
>>>  #include 
>>>
>>> +#if defined RTEMS_THREAD_STACK_PROTECTION
>>> + #include 
>>> +#endif
>>> +
>>>  #include 
>>>  #include 
>>>
>>> @@ -586,7 +590,9 @@ RTEMS_INLINE_ROUTINE Thread_Control
>>> *_CORE_message_queue_Dequeue_receiver(
>>>if ( the_thread == NULL ) {
>>>  return NULL;
>>>}
>>> -
>>> +#if defined RTEMS_THREAD_STACK_PROTECTION
>>> +  _Memory_protection_Disable();
>>>
>> I wonder if it is necessary to disable all protection, or can you just
>> disable the protection applied to 'the_thread' (or maybe to 'executing')?
>>
>
> No, it is not necessary. I will make the changes.
>
>
>>
>>
>>> +#endif
>>> *(size_t *) the_thread->Wait.return_argument = size;
>>> the_thread->Wait.count = (uint32_t) submit_type;
>>>
>>> @@ -595,6 +601,9 @@ RTEMS_INLINE_ROUTINE Thread_Control
>>> *_CORE_message_queue_Dequeue_receiver(
>>>  the_thread->Wait.return_argument_second.mutable_object,
>>>  size
>>>);
>>> +#if defined RTEMS_THREAD_STACK_PROTECTION
>>> +  _Memory_protection_Enable();
>>> +#endif
>>>
>>>_Thread_queue_Extract_critical(
>>>  _message_queue->Wait_queue.Queue,
>>>
>>> diff --git a/cpukit/posix/src/psignalunblockthread.c
>>> b/cpukit/posix/src/psignalunblockthread.c
>>> index 80a0f33a09..e0f8468de6 100644
>>> --- a/cpukit/posix/src/psignalunblockthread.c
>>> +++ b/cpukit/posix/src/psignalunblockthread.c
>>> @@ -24,6 +24,9 @@
>>>  #include 
>>>
>>>  #include 
>>> +#if defined RTEMS_THREAD_STACK_PROTECTION
>>> +#include 
>>> +#endif
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -205,6 +208,10 @@ bool _POSIX_signals_Unblock_thread(
>>>
>>>the_info = (siginfo_t *) the_thread->Wait.return_argument;
>>>
>>> +#if defined RTEMS_THREAD_STACK_PROTECTION
>>> +_Memory_protection_Disable();
>>> +#endif
>>> +
>>>if ( !info ) {
>>>  the_info->si_signo = signo;
>>>  the_info->si_code = SI_USER;
>>> @@ -212,6 +219,9 @@ bool _POSIX_signals_Unblock_thread(
>>>} else {
>>>  

Re: Quick question: How do I get rtems-test

[Richi Dubey]

Thanks!

On Fri, Jan 22, 2021 at 6:46 PM Gedare Bloom  wrote:

>
>
> On Fri, Jan 22, 2021 at 1:15 AM Richi Dubey  wrote:
>
>> Hi,
>>
>> I want to clone the rtems-tools/tester repository, but when I run:
>>
>> ~/quick-start/rtems/6$ git clone https://git.rtems.org/rtems-tools/
>>
>
> git://git.rtems.org/rtems-tools.git
> should work
>
>
>>
>> Cloning into 'rtems-tools'...
>>
>> It does not progress any further from this. What may be wrong?
>>
>> Thanks,
>> Richi.
>> ___
>> 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: Instructions for RTEMS waf build

[Gedare Bloom]

https://docs.rtems.org/branches/master/user/start/bsp-build.html

that should help. more detail is also at
https://docs.rtems.org/branches/master/user/bld/index.html

On Fri, Jan 22, 2021 at 10:44 AM Eshan Dhawan 
wrote:

> Hello everyone,
> Where can I find instructions for waf build of rtems kernel
>
>
> --
> Thanks
> - Eshan
> ___
> 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: Status of clang-llvm builds? Related to powerpc-spe.

[dufault]

Actually, replying to myself:

I bet the context-switching code is broken for platforms that use the SPE via a 
Freescale library.  That's something I'll need to look at.

> On Jan 22, 2021, at 14:26 , Peter Dufault  wrote:
> 
> Signed PGP part
> The PowerPC Signal Processing Engine (powerpc-spe) is now gone from gcc and 
> therefore from RTEMS (on the master branch).  It *appears* to be supported 
> with Clang/LLVM on FreeBSD, apparently primarily to support some Amiga 
> platforms (I think), I think it's supported beginning in FreeBSD 12.
> 
> RTEMS has appropriately pulled out support for the SPE.  Since in the 
> applications I use the SPE is used via libraries from Motorola/Freescale/... 
> that may be OK, but having support for the architecture would "look good" to 
> my clients.
> 
> I'm not going to push for a project to switch to LLVM for the SPE targets, I 
> don't have either the time or the money and I'm not going to ask my clients 
> to fund it.  But I do want to know:
> 
> - What's the status of Clang/LLVM and RTEMS?  Is it production-ready and 
> production-used on certain (RISCV?) platforms?
> - Does anybody know anything the quality of the "powerpc-spe" support in 
> Clang/LLVM?
> 
> This is must an exploratory question.  I don't have a plan to work on this 
> soon.
> 
> Peter
> -
> Peter Dufault
> HD Associates, Inc.  Software and System Engineering
> 
> This email is delivered through the public internet using protocols subject 
> to interception and tampering.
> 
> 
> 

Peter
-
Peter Dufault
HD Associates, Inc.  Software and System Engineering

This email is delivered through the public internet using protocols subject to 
interception and tampering.



signature.asc
Description: Message signed with OpenPGP
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Status of clang-llvm builds? Related to powerpc-spe.

[Peter Dufault]

The PowerPC Signal Processing Engine (powerpc-spe) is now gone from gcc and 
therefore from RTEMS (on the master branch).  It *appears* to be supported with 
Clang/LLVM on FreeBSD, apparently primarily to support some Amiga platforms (I 
think), I think it's supported beginning in FreeBSD 12.

RTEMS has appropriately pulled out support for the SPE.  Since in the 
applications I use the SPE is used via libraries from Motorola/Freescale/... 
that may be OK, but having support for the architecture would "look good" to my 
clients.

I'm not going to push for a project to switch to LLVM for the SPE targets, I 
don't have either the time or the money and I'm not going to ask my clients to 
fund it.  But I do want to know:

- What's the status of Clang/LLVM and RTEMS?  Is it production-ready and 
production-used on certain (RISCV?) platforms?
- Does anybody know anything the quality of the "powerpc-spe" support in 
Clang/LLVM?

This is must an exploratory question.  I don't have a plan to work on this soon.

Peter
-
Peter Dufault
HD Associates, Inc.  Software and System Engineering

This email is delivered through the public internet using protocols subject to 
interception and tampering.



signature.asc
Description: Message signed with OpenPGP
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Instructions for RTEMS waf build

[Eshan Dhawan]

Hello everyone,
Where can I find instructions for waf build of rtems kernel


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

Largest Partition and File Size for RTEMS FAT Filesystem?

[Joel Sherrill]

Hi

Based on this wikipedia article, I think the maximum file size for FAT32 is
4GB and the partition size is 16TB with 4KB sectors.

https://en.wikipedia.org/wiki/File_Allocation_Table#FAT32

Assuming we had a driver to handle the media, does this match the limits of
the RTEMS FAT32 implementation?

Ignore the issue of why someone would put FAT on a media that large. The
better solution would involve getting BSD file systems working on RTEMS.

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

Re: Raspberry Pi Pico

[Christian MAUDERER]

Hello,

Raspberry Pi creating their own chips? Sounds like a stupid idea...

Am 21.01.21 um 16:44 schrieb Joel Sherrill:

Hi

Is a BSP for this feasible? If it is feasible, is is a GSoC size project?

It is an M0+ with 264k SRAM. Although I'm not sure what six independent 
banks does to the amount of RAM for programs?


The SRAM isn't really big. But the STM32F4 is in a similar range. So 
that could work.




https://www.raspberrypi.org/products/raspberry-pi-pico/ 



I can see the M0+ support in RTEMS being a broad issue and the memory 
layout being another but the datasheet seems to show the memory as one 
block:


https://datasheets.raspberrypi.org/rp2040/rp2040_datasheet.pdf 



Agreed: It seems that the memory can be used in a continuous address 
space so the organization shouldn't matter as long as no performance 
optimization is necessary.



The M0+ could be a real problem. Do we currently have any BSPs for an M0 
or M0+ core? I think adding a new core would be _very_ difficult for a 
GSoC student. Especially I think it's less time this year, isn't it?


By the way: It's a dual core. So if the support is added, it would be 
most likely our smallest SMP system ;-)




Feature list:

Dual ARM Cortex-M0+ @ 133MHz
264kB on-chip SRAM in six independent banks
Support for up to 16MB of off-chip Flash memory via dedicated QSPI bus
DMA controller
Fully-connected AHB crossbar
Interpolator and integer divider peripherals
On-chip programmable LDO to generate core voltage
2 on-chip PLLs to generate USB and core clocks
30 GPIO pins, 4 of which can be used as analog inputs
Peripherals
2 UARTs
2 SPI controllers
2 I2C controllers
16 PWM channels
USB 1.1 controller and PHY, with host and device support
8 PIO state machines


The chip seems to be thrown together using various IPs (which is not 
necessarily a bad idea if they did it right). UART is an ARM PL011 which 
should be simple - we have already a driver for that. The other 
peripherals seem to be sometimes ARM, sometimes Synopsis, sometimes 
something else. The documentation looks OK on a first glance. So it 
should be doable.




Not our problem but I don't see obvious details on hooking up a JTAG but 
if someone does a BSP, that will be an issue.


The chip has a SWCLK and SWDIO. So its not a full JTAG but at least a 
debug interface. The Board has three pins marked "DEBUG" on the small 
side opposite to the USB connector. So in theory a debugger could be 
connected. It even seems that there is an openOCD port done by the 
Raspberry Pi developers:


   https://github.com/raspberrypi/openocd/tree/rp2040

Best regards

Christian


--joel


___
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: [PATCH v2] bsps/shared: Build fsl-edma only for certain BSP

[Jan.Sommer]

Thank you. The pipeline works again.

Have a nice week-end,

Jan

> -Original Message-
> From: devel  On Behalf Of Christian MAUDERER
> Sent: Friday, January 22, 2021 3:52 PM
> To: Sebastian Huber ; RTEMS
> 
> Subject: Re: [PATCH v2] bsps/shared: Build fsl-edma only for certain BSP
> 
> Am 22.01.21 um 15:48 schrieb Sebastian Huber:
> > On 22/01/2021 15:44, Christian Mauderer wrote:
> >
> >> Move the Freescale EDMA driver to it's own object and build it only
> >> for the BSP that is currently using it.
> > Looks good.
> >
> 
> Thanks. I pushed it.
> 
> --
> 
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] Improve file header comment in generated files

[Sebastian Huber]

---
 cpukit/doxygen/appl-config.h| 10 +++---
 cpukit/include/rtems.h  | 10 +++---
 cpukit/include/rtems/config.h   | 10 +++---
 cpukit/include/rtems/io.h   | 10 +++---
 cpukit/include/rtems/rtems/attr.h   | 10 +++---
 cpukit/include/rtems/rtems/config.h | 10 +++---
 cpukit/include/rtems/rtems/event.h  | 10 +++---
 cpukit/include/rtems/rtems/modes.h  | 10 +++---
 cpukit/include/rtems/rtems/object.h | 10 +++---
 cpukit/include/rtems/rtems/options.h| 10 +++---
 cpukit/include/rtems/rtems/part.h   | 10 +++---
 cpukit/include/rtems/rtems/status.h | 10 +++---
 cpukit/include/rtems/rtems/timer.h  | 10 +++---
 cpukit/include/rtems/rtems/types.h  | 10 +++---
 cpukit/include/rtems/score/basedefs.h   | 10 +++---
 testsuites/validation/tc-message-construct-errors.c | 10 +++---
 testsuites/validation/tc-part-performance.c | 10 +++---
 testsuites/validation/tc-task-construct-errors.c| 10 +++---
 testsuites/validation/ts-performance-0.c| 10 +++---
 testsuites/validation/ts-validation-0.c | 10 +++---
 20 files changed, 140 insertions(+), 60 deletions(-)

diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h
index 4774972600..092e02ccca 100644
--- a/cpukit/doxygen/appl-config.h
+++ b/cpukit/doxygen/appl-config.h
@@ -33,11 +33,15 @@
  * worded better please post a report or patch to an RTEMS mailing list
  * or raise a bug report:
  *
- * https://docs.rtems.org/branches/master/user/support/bugs.html
+ * https://www.rtems.org/bugs.html
  *
- * For information on updating and regenerating please refer to:
+ * For information on updating and regenerating please refer to the How-To
+ * section in the Software Requirements Engineering chapter of the
+ * RTEMS Software Engineering manual.  The manual is provided as a part of
+ * a release.  For development sources please refer to the online
+ * documentation at:
  *
- * https://docs.rtems.org/branches/master/eng/req/howto.html
+ * https://docs.rtems.org
  */
 
 /**
diff --git a/cpukit/include/rtems.h b/cpukit/include/rtems.h
index d1b1452000..29716e9eaf 100644
--- a/cpukit/include/rtems.h
+++ b/cpukit/include/rtems.h
@@ -40,11 +40,15 @@
  * worded better please post a report or patch to an RTEMS mailing list
  * or raise a bug report:
  *
- * https://docs.rtems.org/branches/master/user/support/bugs.html
+ * https://www.rtems.org/bugs.html
  *
- * For information on updating and regenerating please refer to:
+ * For information on updating and regenerating please refer to the How-To
+ * section in the Software Requirements Engineering chapter of the
+ * RTEMS Software Engineering manual.  The manual is provided as a part of
+ * a release.  For development sources please refer to the online
+ * documentation at:
  *
- * https://docs.rtems.org/branches/master/eng/req/howto.html
+ * https://docs.rtems.org
  */
 
 /* Generated from spec:/rtems/if/header */
diff --git a/cpukit/include/rtems/config.h b/cpukit/include/rtems/config.h
index 3fda60289f..cc54a25d9e 100644
--- a/cpukit/include/rtems/config.h
+++ b/cpukit/include/rtems/config.h
@@ -40,11 +40,15 @@
  * worded better please post a report or patch to an RTEMS mailing list
  * or raise a bug report:
  *
- * https://docs.rtems.org/branches/master/user/support/bugs.html
+ * https://www.rtems.org/bugs.html
  *
- * For information on updating and regenerating please refer to:
+ * For information on updating and regenerating please refer to the How-To
+ * section in the Software Requirements Engineering chapter of the
+ * RTEMS Software Engineering manual.  The manual is provided as a part of
+ * a release.  For development sources please refer to the online
+ * documentation at:
  *
- * https://docs.rtems.org/branches/master/eng/req/howto.html
+ * https://docs.rtems.org
  */
 
 /* Generated from spec:/rtems/config/if/header */
diff --git a/cpukit/include/rtems/io.h b/cpukit/include/rtems/io.h
index 92ffb6d51b..445f24cb78 100644
--- a/cpukit/include/rtems/io.h
+++ b/cpukit/include/rtems/io.h
@@ -40,11 +40,15 @@
  * worded better please post a report or patch to an RTEMS mailing list
  * or raise a bug report:
  *
- * https://docs.rtems.org/branches/master/user/support/bugs.html
+ * https://www.rtems.org/bugs.html
  *
- * For information on updating and regenerating please refer to:
+ * For information on updating and regenerating please refer to the How-To
+ * section in the Software Requirements Engineering chapter of the
+ * RTEMS Software Engineering manual.  The manual is provided as a part of
+ * a release.  For development sources please refer to the online
+ * documentation at:
  *
- * 

Re: [PATCH v2] bsps/shared: Build fsl-edma only for certain BSP

[Christian MAUDERER]

Am 22.01.21 um 15:48 schrieb Sebastian Huber:

On 22/01/2021 15:44, Christian Mauderer wrote:


Move the Freescale EDMA driver to it's own object and build it only for
the BSP that is currently using it.

Looks good.



Thanks. I pushed it.

--

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 v2] bsps/shared: Build fsl-edma only for certain BSP

[Sebastian Huber]

On 22/01/2021 15:44, Christian Mauderer wrote:


Move the Freescale EDMA driver to it's own object and build it only for
the BSP that is currently using it.

Looks good.

--
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 v2] bsps/shared: Build fsl-edma only for certain BSP

[Christian Mauderer]

Move the Freescale EDMA driver to it's own object and build it only for
the BSP that is currently using it.
---
 spec/build/bsps/arm/imxrt/bspimxrt.yml |  2 ++
 spec/build/bsps/obj.yml|  5 -
 spec/build/bsps/objdevfsledma.yml  | 18 ++
 3 files changed, 20 insertions(+), 5 deletions(-)
 create mode 100644 spec/build/bsps/objdevfsledma.yml

diff --git a/spec/build/bsps/arm/imxrt/bspimxrt.yml 
b/spec/build/bsps/arm/imxrt/bspimxrt.yml
index 3044fda998..916c959eb3 100644
--- a/spec/build/bsps/arm/imxrt/bspimxrt.yml
+++ b/spec/build/bsps/arm/imxrt/bspimxrt.yml
@@ -143,6 +143,8 @@ links:
   uid: ../../obj
 - role: build-dependency
   uid: ../../objirq
+- role: build-dependency
+  uid: ../../objdevfsledma
 - role: build-dependency
   uid: ../../opto2
 - role: build-dependency
diff --git a/spec/build/bsps/obj.yml b/spec/build/bsps/obj.yml
index abed6bc76f..b598d54d16 100644
--- a/spec/build/bsps/obj.yml
+++ b/spec/build/bsps/obj.yml
@@ -28,10 +28,6 @@ install:
   source:
   - bsps/include/ofw/ofw.h
   - bsps/include/ofw/ofw_compat.h
-- destination: ${BSP_INCLUDEDIR}/fsl
-  source:
-  - bsps/include/fsl/edma.h
-  - bsps/include/fsl/regs-edma.h
 - destination: ${BSP_INCLUDEDIR}/libchip
   source:
   - bsps/include/libchip/ata.h
@@ -76,7 +72,6 @@ links:
 source:
 - bsps/shared/dev/display/disp_hcms29xx.c
 - bsps/shared/dev/display/font_hcms29xx.c
-- bsps/shared/dev/dma/fsl-edma.c
 - bsps/shared/dev/i2c/i2c-2b-eeprom.c
 - bsps/shared/dev/i2c/i2c-ds1621.c
 - bsps/shared/dev/i2c/i2c-sc620.c
diff --git a/spec/build/bsps/objdevfsledma.yml 
b/spec/build/bsps/objdevfsledma.yml
new file mode 100644
index 00..a3295a4060
--- /dev/null
+++ b/spec/build/bsps/objdevfsledma.yml
@@ -0,0 +1,18 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+build-type: objects
+cflags: []
+copyrights:
+- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+cppflags: []
+cxxflags: []
+enabled-by: true
+includes: []
+install:
+- destination: ${BSP_INCLUDEDIR}/fsl
+  source:
+  - bsps/include/fsl/edma.h
+  - bsps/include/fsl/regs-edma.h
+links: []
+source:
+- bsps/shared/dev/dma/fsl-edma.c
+type: build
-- 
2.26.2

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

Re: [PATCH] bsps/shared: Build fsl-edma only for certain BSP

[Christian MAUDERER]

Am 22.01.21 um 15:30 schrieb Sebastian Huber:

On 22/01/2021 15:15, Christian Mauderer wrote:


Move the Freescale EDMA driver to it's own object and build it only for
the BSP that is currently using it.

I think the removal part is missing.



I shouldn't send patches on a Friday afternoon. I'll send a V2.

--

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] bsps/shared: Build fsl-edma only for certain BSP

[Sebastian Huber]

On 22/01/2021 15:15, Christian Mauderer wrote:


Move the Freescale EDMA driver to it's own object and build it only for
the BSP that is currently using it.

I think the removal part is missing.

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

Re: [PATCH rtems 1/2] libblock: Add rtems_bdbuf_peek()

[Gedare Bloom]

On Fri, Jan 22, 2021 at 7:08 AM Christian MAUDERER <
christian.maude...@embedded-brains.de> wrote:

> Am 22.01.21 um 14:59 schrieb Gedare Bloom:
> >
> >
> > On Fri, Jan 22, 2021 at 6:24 AM Christian Mauderer
> >  > > wrote:
> >
> > Adds a peek function that allows (for example) a file system to
> suggest
> > the next blocks that should be used for read ahead. This can increase
> > the read speed of fragmented files.
> > ---
> >   cpukit/include/rtems/bdbuf.h |  21 
> >   cpukit/include/rtems/diskdevs.h  |  27 -
> >   cpukit/libblock/src/bdbuf.c  |  80 +++
> >   cpukit/libblock/src/blkdev-print-stats.c |  28 ++---
> >   testsuites/fstests/fsdosfswrite01/init.c |  51 +-
> >   testsuites/libtests/block14/block14.scn  |  37 ---
> >   testsuites/libtests/block14/init.c   | 124
> +--
> >   7 files changed, 264 insertions(+), 104 deletions(-)
> >
> > diff --git a/cpukit/include/rtems/bdbuf.h
> b/cpukit/include/rtems/bdbuf.h
> > index fbb4fc05e9..0cde571816 100644
> > --- a/cpukit/include/rtems/bdbuf.h
> > +++ b/cpukit/include/rtems/bdbuf.h
> > @@ -539,6 +539,27 @@ rtems_bdbuf_read (
> > rtems_bdbuf_buffer** bd
> >   );
> >
> > +/**
> > + * Provide a hint to the read ahead mechanism which blocks should
> > be cached
> > + * next. This overwrites the default linear pattern. You should use
> > it in (for
> > + * example) a file system to tell bdbuf where the next part of a
> > fragmented file
> > + * is. If you know the length of the file, you can provide that too.
> > + *
> > + * Before you can use this function, the rtems_bdbuf_init() routine
> > must be
> > + * called at least once to initialize everything. Otherwise you
> > might get
> > + * unexpected results.
> > + *
> > + * @param dd [in] The disk device.
> > + * @param block [in] Linear media block number.
> > + * @param nr_blocks [in] Number of consecutive blocks that can be
> > pre-fetched.
> > + */
> > +void
> > +rtems_bdbuf_peek (
> > +  rtems_disk_device *dd,
> > +  rtems_blkdev_bnum block,
> > +  uint32_t nr_blocks
> > +);
> > +
> >   /**
> >* Release the buffer obtained by a read call back to the cache.
> > If the buffer
> >* was obtained by a get call and was not already in the cache the
> > release
> > diff --git a/cpukit/include/rtems/diskdevs.h
> > b/cpukit/include/rtems/diskdevs.h
> > index 85d157dcd5..d7529cbe89 100644
> > --- a/cpukit/include/rtems/diskdevs.h
> > +++ b/cpukit/include/rtems/diskdevs.h
> > @@ -58,6 +58,11 @@ typedef int (*rtems_block_device_ioctl)(
> >*/
> >   #define RTEMS_DISK_READ_AHEAD_NO_TRIGGER ((rtems_blkdev_bnum) -1)
> >
> > +/**
> > + * @brief Size value to set number of blocks based on config and
> > disk size.
> > + */
> > +#define RTEMS_DISK_READ_AHEAD_SIZE_AUTO (0)
> > +
> >   /**
> >* @brief Block device read-ahead control.
> >*/
> > @@ -71,7 +76,8 @@ typedef struct {
> >  * @brief Block value to trigger the read-ahead request.
> >  *
> >  * A value of @ref RTEMS_DISK_READ_AHEAD_NO_TRIGGER will disable
> > further
> > -   * read-ahead requests since no valid block can have this value.
> > +   * read-ahead requests (except the ones triggered by @a
> > rtems_bdbuf_peek)
> > +   * since no valid block can have this value.
> >  */
> > rtems_blkdev_bnum trigger;
> >
> > @@ -82,6 +88,14 @@ typedef struct {
> >  * be arbitrary.
> >  */
> > rtems_blkdev_bnum next;
> > +
> > +  /**
> > +   * @brief Size of the next read-ahead request in blocks.
> > +   *
> > +   * A value of @ref RTEMS_DISK_READ_AHEAD_SIZE_AUTO will try to
> > read the rest
> > +   * of the disk but at most the configured max_read_ahead_blocks.
> > +   */
> > +  uint32_t nr_blocks;
> >   } rtems_blkdev_read_ahead;
> >
> >   /**
> > @@ -110,10 +124,19 @@ typedef struct {
> > /**
> >  * @brief Read-ahead transfer count.
> >  *
> > -   * Each read-ahead transfer may read multiple blocks.
> > +   * Each read-ahead transfer may read multiple blocks. This counts
> all
> > +   * transfers (with and without size).
> >  */
> > uint32_t read_ahead_transfers;
> >
> > +  /**
> > +   * @brief Read-ahead transfers with given size.
> > +   *
> > +   * Number of times a read ahead transfer has been given a size.
> > This is the
> > +   * case for read ahead transfers that are caused by a peek.
> > +   */
> > +  uint32_t read_ahead_transfers_with_size;
> >
> >
> > A little bit wordy. Maybe you just want to count the number of peeks?

Re: [rtems commit] bsps/shared: Adapt fsl-edma driver for imxrt

[Christian MAUDERER]

I have sent a patch for review:

   https://lists.rtems.org/pipermail/devel/2021-January/064009.html

Am 22.01.21 um 14:07 schrieb Christian MAUDERER:

Am 22.01.21 um 14:04 schrieb Sebastian Huber:


On 21/01/2021 10:26, Christian Mauderer wrote:

  spec/build/bsps/obj.yml  |   5 +
This is the wrong place for these files. Please add a separate object 
for the driver and link to this object in all BSPs which use the driver.




Sorry. I'll create a commit to fix it soon.

I thought that the commit would be OK after it had been on the list for 
about one month without objections.


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

[PATCH] bsps/shared: Build fsl-edma only for certain BSP

[Christian Mauderer]

Move the Freescale EDMA driver to it's own object and build it only for
the BSP that is currently using it.
---
 spec/build/bsps/arm/imxrt/bspimxrt.yml |  2 ++
 spec/build/bsps/objdevfsledma.yml  | 18 ++
 2 files changed, 20 insertions(+)
 create mode 100644 spec/build/bsps/objdevfsledma.yml

diff --git a/spec/build/bsps/arm/imxrt/bspimxrt.yml 
b/spec/build/bsps/arm/imxrt/bspimxrt.yml
index 3044fda998..916c959eb3 100644
--- a/spec/build/bsps/arm/imxrt/bspimxrt.yml
+++ b/spec/build/bsps/arm/imxrt/bspimxrt.yml
@@ -143,6 +143,8 @@ links:
   uid: ../../obj
 - role: build-dependency
   uid: ../../objirq
+- role: build-dependency
+  uid: ../../objdevfsledma
 - role: build-dependency
   uid: ../../opto2
 - role: build-dependency
diff --git a/spec/build/bsps/objdevfsledma.yml 
b/spec/build/bsps/objdevfsledma.yml
new file mode 100644
index 00..a3295a4060
--- /dev/null
+++ b/spec/build/bsps/objdevfsledma.yml
@@ -0,0 +1,18 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+build-type: objects
+cflags: []
+copyrights:
+- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+cppflags: []
+cxxflags: []
+enabled-by: true
+includes: []
+install:
+- destination: ${BSP_INCLUDEDIR}/fsl
+  source:
+  - bsps/include/fsl/edma.h
+  - bsps/include/fsl/regs-edma.h
+links: []
+source:
+- bsps/shared/dev/dma/fsl-edma.c
+type: build
-- 
2.26.2

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

Re: [PATCH rtems 1/2] libblock: Add rtems_bdbuf_peek()

[Christian MAUDERER]

Am 22.01.21 um 14:59 schrieb Gedare Bloom:



On Fri, Jan 22, 2021 at 6:24 AM Christian Mauderer 
> wrote:


Adds a peek function that allows (for example) a file system to suggest
the next blocks that should be used for read ahead. This can increase
the read speed of fragmented files.
---
  cpukit/include/rtems/bdbuf.h             |  21 
  cpukit/include/rtems/diskdevs.h          |  27 -
  cpukit/libblock/src/bdbuf.c              |  80 +++
  cpukit/libblock/src/blkdev-print-stats.c |  28 ++---
  testsuites/fstests/fsdosfswrite01/init.c |  51 +-
  testsuites/libtests/block14/block14.scn  |  37 ---
  testsuites/libtests/block14/init.c       | 124 +--
  7 files changed, 264 insertions(+), 104 deletions(-)

diff --git a/cpukit/include/rtems/bdbuf.h b/cpukit/include/rtems/bdbuf.h
index fbb4fc05e9..0cde571816 100644
--- a/cpukit/include/rtems/bdbuf.h
+++ b/cpukit/include/rtems/bdbuf.h
@@ -539,6 +539,27 @@ rtems_bdbuf_read (
    rtems_bdbuf_buffer** bd
  );

+/**
+ * Provide a hint to the read ahead mechanism which blocks should
be cached
+ * next. This overwrites the default linear pattern. You should use
it in (for
+ * example) a file system to tell bdbuf where the next part of a
fragmented file
+ * is. If you know the length of the file, you can provide that too.
+ *
+ * Before you can use this function, the rtems_bdbuf_init() routine
must be
+ * called at least once to initialize everything. Otherwise you
might get
+ * unexpected results.
+ *
+ * @param dd [in] The disk device.
+ * @param block [in] Linear media block number.
+ * @param nr_blocks [in] Number of consecutive blocks that can be
pre-fetched.
+ */
+void
+rtems_bdbuf_peek (
+  rtems_disk_device *dd,
+  rtems_blkdev_bnum block,
+  uint32_t nr_blocks
+);
+
  /**
   * Release the buffer obtained by a read call back to the cache.
If the buffer
   * was obtained by a get call and was not already in the cache the
release
diff --git a/cpukit/include/rtems/diskdevs.h
b/cpukit/include/rtems/diskdevs.h
index 85d157dcd5..d7529cbe89 100644
--- a/cpukit/include/rtems/diskdevs.h
+++ b/cpukit/include/rtems/diskdevs.h
@@ -58,6 +58,11 @@ typedef int (*rtems_block_device_ioctl)(
   */
  #define RTEMS_DISK_READ_AHEAD_NO_TRIGGER ((rtems_blkdev_bnum) -1)

+/**
+ * @brief Size value to set number of blocks based on config and
disk size.
+ */
+#define RTEMS_DISK_READ_AHEAD_SIZE_AUTO (0)
+
  /**
   * @brief Block device read-ahead control.
   */
@@ -71,7 +76,8 @@ typedef struct {
     * @brief Block value to trigger the read-ahead request.
     *
     * A value of @ref RTEMS_DISK_READ_AHEAD_NO_TRIGGER will disable
further
-   * read-ahead requests since no valid block can have this value.
+   * read-ahead requests (except the ones triggered by @a
rtems_bdbuf_peek)
+   * since no valid block can have this value.
     */
    rtems_blkdev_bnum trigger;

@@ -82,6 +88,14 @@ typedef struct {
     * be arbitrary.
     */
    rtems_blkdev_bnum next;
+
+  /**
+   * @brief Size of the next read-ahead request in blocks.
+   *
+   * A value of @ref RTEMS_DISK_READ_AHEAD_SIZE_AUTO will try to
read the rest
+   * of the disk but at most the configured max_read_ahead_blocks.
+   */
+  uint32_t nr_blocks;
  } rtems_blkdev_read_ahead;

  /**
@@ -110,10 +124,19 @@ typedef struct {
    /**
     * @brief Read-ahead transfer count.
     *
-   * Each read-ahead transfer may read multiple blocks.
+   * Each read-ahead transfer may read multiple blocks. This counts all
+   * transfers (with and without size).
     */
    uint32_t read_ahead_transfers;

+  /**
+   * @brief Read-ahead transfers with given size.
+   *
+   * Number of times a read ahead transfer has been given a size.
This is the
+   * case for read ahead transfers that are caused by a peek.
+   */
+  uint32_t read_ahead_transfers_with_size;


A little bit wordy. Maybe you just want to count the number of peeks?


I thought about that too. But in theory, someone could add another 
mechanism that uses the size. For example it would be possible to do the 
normal read ahead with that too.


But if you prefer, I can rename it to "read_ahead_peeks". I would avoid 
removing the read_ahead altogether because it belongs to this mechanism.




+
    /**
     * @brief Count of blocks transfered from the device.
     */
diff --git a/cpukit/libblock/src/bdbuf.c b/cpukit/libblock/src/bdbuf.c
index a7d471507c..02acf11f54 100644
--- a/cpukit/libblock/src/bdbuf.c
+++ 

Re: [PATCH rtems 1/2] libblock: Add rtems_bdbuf_peek()

[Gedare Bloom]

On Fri, Jan 22, 2021 at 6:24 AM Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> Adds a peek function that allows (for example) a file system to suggest
> the next blocks that should be used for read ahead. This can increase
> the read speed of fragmented files.
> ---
>  cpukit/include/rtems/bdbuf.h |  21 
>  cpukit/include/rtems/diskdevs.h  |  27 -
>  cpukit/libblock/src/bdbuf.c  |  80 +++
>  cpukit/libblock/src/blkdev-print-stats.c |  28 ++---
>  testsuites/fstests/fsdosfswrite01/init.c |  51 +-
>  testsuites/libtests/block14/block14.scn  |  37 ---
>  testsuites/libtests/block14/init.c   | 124 +--
>  7 files changed, 264 insertions(+), 104 deletions(-)
>
> diff --git a/cpukit/include/rtems/bdbuf.h b/cpukit/include/rtems/bdbuf.h
> index fbb4fc05e9..0cde571816 100644
> --- a/cpukit/include/rtems/bdbuf.h
> +++ b/cpukit/include/rtems/bdbuf.h
> @@ -539,6 +539,27 @@ rtems_bdbuf_read (
>rtems_bdbuf_buffer** bd
>  );
>
> +/**
> + * Provide a hint to the read ahead mechanism which blocks should be
> cached
> + * next. This overwrites the default linear pattern. You should use it in
> (for
> + * example) a file system to tell bdbuf where the next part of a
> fragmented file
> + * is. If you know the length of the file, you can provide that too.
> + *
> + * Before you can use this function, the rtems_bdbuf_init() routine must
> be
> + * called at least once to initialize everything. Otherwise you might get
> + * unexpected results.
> + *
> + * @param dd [in] The disk device.
> + * @param block [in] Linear media block number.
> + * @param nr_blocks [in] Number of consecutive blocks that can be
> pre-fetched.
> + */
> +void
> +rtems_bdbuf_peek (
> +  rtems_disk_device *dd,
> +  rtems_blkdev_bnum block,
> +  uint32_t nr_blocks
> +);
> +
>  /**
>   * Release the buffer obtained by a read call back to the cache. If the
> buffer
>   * was obtained by a get call and was not already in the cache the release
> diff --git a/cpukit/include/rtems/diskdevs.h
> b/cpukit/include/rtems/diskdevs.h
> index 85d157dcd5..d7529cbe89 100644
> --- a/cpukit/include/rtems/diskdevs.h
> +++ b/cpukit/include/rtems/diskdevs.h
> @@ -58,6 +58,11 @@ typedef int (*rtems_block_device_ioctl)(
>   */
>  #define RTEMS_DISK_READ_AHEAD_NO_TRIGGER ((rtems_blkdev_bnum) -1)
>
> +/**
> + * @brief Size value to set number of blocks based on config and disk
> size.
> + */
> +#define RTEMS_DISK_READ_AHEAD_SIZE_AUTO (0)
> +
>  /**
>   * @brief Block device read-ahead control.
>   */
> @@ -71,7 +76,8 @@ typedef struct {
> * @brief Block value to trigger the read-ahead request.
> *
> * A value of @ref RTEMS_DISK_READ_AHEAD_NO_TRIGGER will disable further
> -   * read-ahead requests since no valid block can have this value.
> +   * read-ahead requests (except the ones triggered by @a
> rtems_bdbuf_peek)
> +   * since no valid block can have this value.
> */
>rtems_blkdev_bnum trigger;
>
> @@ -82,6 +88,14 @@ typedef struct {
> * be arbitrary.
> */
>rtems_blkdev_bnum next;
> +
> +  /**
> +   * @brief Size of the next read-ahead request in blocks.
> +   *
> +   * A value of @ref RTEMS_DISK_READ_AHEAD_SIZE_AUTO will try to read the
> rest
> +   * of the disk but at most the configured max_read_ahead_blocks.
> +   */
> +  uint32_t nr_blocks;
>  } rtems_blkdev_read_ahead;
>
>  /**
> @@ -110,10 +124,19 @@ typedef struct {
>/**
> * @brief Read-ahead transfer count.
> *
> -   * Each read-ahead transfer may read multiple blocks.
> +   * Each read-ahead transfer may read multiple blocks. This counts all
> +   * transfers (with and without size).
> */
>uint32_t read_ahead_transfers;
>
> +  /**
> +   * @brief Read-ahead transfers with given size.
> +   *
> +   * Number of times a read ahead transfer has been given a size. This is
> the
> +   * case for read ahead transfers that are caused by a peek.
> +   */
> +  uint32_t read_ahead_transfers_with_size;


A little bit wordy. Maybe you just want to count the number of peeks?


>

+
>/**
> * @brief Count of blocks transfered from the device.
> */
> diff --git a/cpukit/libblock/src/bdbuf.c b/cpukit/libblock/src/bdbuf.c
> index a7d471507c..02acf11f54 100644
> --- a/cpukit/libblock/src/bdbuf.c
> +++ b/cpukit/libblock/src/bdbuf.c
> @@ -2018,6 +2018,23 @@ rtems_bdbuf_read_ahead_reset (rtems_disk_device *dd)
>dd->read_ahead.trigger = RTEMS_DISK_READ_AHEAD_NO_TRIGGER;
>  }
>
> +static void
> +rtems_bdbuf_read_ahead_add_to_chain (rtems_disk_device *dd)
> +{
> +  rtems_status_code sc;
> +  rtems_chain_control *chain = _cache.read_ahead_chain;
> +
> +  if (rtems_chain_is_empty (chain))
> +  {
> +sc = rtems_event_send (bdbuf_cache.read_ahead_task,
> +   RTEMS_BDBUF_READ_AHEAD_WAKE_UP);
> +if (sc != RTEMS_SUCCESSFUL)
> +  rtems_bdbuf_fatal (RTEMS_BDBUF_FATAL_RA_WAKE_UP);
> +  }
> +
> +  rtems_chain_append_unprotected (chain, 

[PATCH rtems 1/2] libblock: Add rtems_bdbuf_peek()

[Christian Mauderer]

Adds a peek function that allows (for example) a file system to suggest
the next blocks that should be used for read ahead. This can increase
the read speed of fragmented files.
---
 cpukit/include/rtems/bdbuf.h |  21 
 cpukit/include/rtems/diskdevs.h  |  27 -
 cpukit/libblock/src/bdbuf.c  |  80 +++
 cpukit/libblock/src/blkdev-print-stats.c |  28 ++---
 testsuites/fstests/fsdosfswrite01/init.c |  51 +-
 testsuites/libtests/block14/block14.scn  |  37 ---
 testsuites/libtests/block14/init.c   | 124 +--
 7 files changed, 264 insertions(+), 104 deletions(-)

diff --git a/cpukit/include/rtems/bdbuf.h b/cpukit/include/rtems/bdbuf.h
index fbb4fc05e9..0cde571816 100644
--- a/cpukit/include/rtems/bdbuf.h
+++ b/cpukit/include/rtems/bdbuf.h
@@ -539,6 +539,27 @@ rtems_bdbuf_read (
   rtems_bdbuf_buffer** bd
 );
 
+/**
+ * Provide a hint to the read ahead mechanism which blocks should be cached
+ * next. This overwrites the default linear pattern. You should use it in (for
+ * example) a file system to tell bdbuf where the next part of a fragmented 
file
+ * is. If you know the length of the file, you can provide that too.
+ *
+ * Before you can use this function, the rtems_bdbuf_init() routine must be
+ * called at least once to initialize everything. Otherwise you might get
+ * unexpected results.
+ *
+ * @param dd [in] The disk device.
+ * @param block [in] Linear media block number.
+ * @param nr_blocks [in] Number of consecutive blocks that can be pre-fetched.
+ */
+void
+rtems_bdbuf_peek (
+  rtems_disk_device *dd,
+  rtems_blkdev_bnum block,
+  uint32_t nr_blocks
+);
+
 /**
  * Release the buffer obtained by a read call back to the cache. If the buffer
  * was obtained by a get call and was not already in the cache the release
diff --git a/cpukit/include/rtems/diskdevs.h b/cpukit/include/rtems/diskdevs.h
index 85d157dcd5..d7529cbe89 100644
--- a/cpukit/include/rtems/diskdevs.h
+++ b/cpukit/include/rtems/diskdevs.h
@@ -58,6 +58,11 @@ typedef int (*rtems_block_device_ioctl)(
  */
 #define RTEMS_DISK_READ_AHEAD_NO_TRIGGER ((rtems_blkdev_bnum) -1)
 
+/**
+ * @brief Size value to set number of blocks based on config and disk size.
+ */
+#define RTEMS_DISK_READ_AHEAD_SIZE_AUTO (0)
+
 /**
  * @brief Block device read-ahead control.
  */
@@ -71,7 +76,8 @@ typedef struct {
* @brief Block value to trigger the read-ahead request.
*
* A value of @ref RTEMS_DISK_READ_AHEAD_NO_TRIGGER will disable further
-   * read-ahead requests since no valid block can have this value.
+   * read-ahead requests (except the ones triggered by @a rtems_bdbuf_peek)
+   * since no valid block can have this value.
*/
   rtems_blkdev_bnum trigger;
 
@@ -82,6 +88,14 @@ typedef struct {
* be arbitrary.
*/
   rtems_blkdev_bnum next;
+
+  /**
+   * @brief Size of the next read-ahead request in blocks.
+   *
+   * A value of @ref RTEMS_DISK_READ_AHEAD_SIZE_AUTO will try to read the rest
+   * of the disk but at most the configured max_read_ahead_blocks.
+   */
+  uint32_t nr_blocks;
 } rtems_blkdev_read_ahead;
 
 /**
@@ -110,10 +124,19 @@ typedef struct {
   /**
* @brief Read-ahead transfer count.
*
-   * Each read-ahead transfer may read multiple blocks.
+   * Each read-ahead transfer may read multiple blocks. This counts all
+   * transfers (with and without size).
*/
   uint32_t read_ahead_transfers;
 
+  /**
+   * @brief Read-ahead transfers with given size.
+   *
+   * Number of times a read ahead transfer has been given a size. This is the
+   * case for read ahead transfers that are caused by a peek.
+   */
+  uint32_t read_ahead_transfers_with_size;
+
   /**
* @brief Count of blocks transfered from the device.
*/
diff --git a/cpukit/libblock/src/bdbuf.c b/cpukit/libblock/src/bdbuf.c
index a7d471507c..02acf11f54 100644
--- a/cpukit/libblock/src/bdbuf.c
+++ b/cpukit/libblock/src/bdbuf.c
@@ -2018,6 +2018,23 @@ rtems_bdbuf_read_ahead_reset (rtems_disk_device *dd)
   dd->read_ahead.trigger = RTEMS_DISK_READ_AHEAD_NO_TRIGGER;
 }
 
+static void
+rtems_bdbuf_read_ahead_add_to_chain (rtems_disk_device *dd)
+{
+  rtems_status_code sc;
+  rtems_chain_control *chain = _cache.read_ahead_chain;
+
+  if (rtems_chain_is_empty (chain))
+  {
+sc = rtems_event_send (bdbuf_cache.read_ahead_task,
+   RTEMS_BDBUF_READ_AHEAD_WAKE_UP);
+if (sc != RTEMS_SUCCESSFUL)
+  rtems_bdbuf_fatal (RTEMS_BDBUF_FATAL_RA_WAKE_UP);
+  }
+
+  rtems_chain_append_unprotected (chain, >read_ahead.node);
+}
+
 static void
 rtems_bdbuf_check_read_ahead_trigger (rtems_disk_device *dd,
   rtems_blkdev_bnum  block)
@@ -2026,18 +2043,8 @@ rtems_bdbuf_check_read_ahead_trigger (rtems_disk_device 
*dd,
   && dd->read_ahead.trigger == block
   && !rtems_bdbuf_is_read_ahead_active (dd))
   {
-rtems_status_code sc;
-rtems_chain_control *chain = _cache.read_ahead_chain;
-
-if 

[PATCH rtems 0/2] Add Peek Support to libblock and use in dosfs

[Christian Mauderer]

Hello,

the first patch allows filesystems to have an influence on the read
ahead of libblock. The second one uses it in our FAT implementation
during reads.

I tested the patches on a SD card attached to an i.MX6ULL based system.
To test it I used an empty 16 MB FAT partition. The bdbuf cache in the
test application has been 1MB. First I wrote one big file (which should
have nearly no fragments, because the partition has been empty before
the write) and tested how long it takes to read the entire file. My read
speed increased from 2040 kiByte/s to 2070 kiByte/s for the first read
of the file (about 1.5 percent faster). For all consecutive reads it
increased from about 3230 kiByte/s to 3340 kiByte/s which is 3 to 4
percent faster for all follow up reads.

As a second test I first filled the partition with lots of small
(about 8000 with only a few bytes per file). Then I removed one random
file at a time and filled the space up by attaching data to a big file.
I did that for about a third of the files. With that I created a heavily
fragmented file. Linux "filefrag" tool tells me that my 5.3 MiB file has
2680 fragments which is about 2kiB per fragment.

The read speed for this big fragmented file increased from 2530 kiByte/s
to 2920 kiByte/s for the first read (about 15 percent faster). For
consecutive reads it increased from 2910 kiByte/s to 3170 kiByte/s which
is nearly 9 percent faster.

I didn't analyze why the first read is allways a bit slower. Either for
the consecutive reads some blocks are still in the cache or some
resources are allocated during that time. It's also possible that the SD
card has some internal cache that causes this.

These results have been reached when optimizing BSP, libbsd and
application with -O2. For an unoptimized build (-O0) it was more in the
range of 25 percent faster for a fragmented file.

If the patch set is OK, I'll create a ticket for it (with the
information from this mail) and push it to RTEMS master.

Best regards

Christian


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

[PATCH rtems 2/2] dosfs: Use peek support

[Christian Mauderer]

This speeds up reading fragmented files.
---
 cpukit/libfs/src/dosfs/fat.c  | 10 ++
 cpukit/libfs/src/dosfs/fat.h  |  5 +
 cpukit/libfs/src/dosfs/fat_file.c | 21 -
 3 files changed, 31 insertions(+), 5 deletions(-)

diff --git a/cpukit/libfs/src/dosfs/fat.c b/cpukit/libfs/src/dosfs/fat.c
index c687477d04..e5cbe6c375 100644
--- a/cpukit/libfs/src/dosfs/fat.c
+++ b/cpukit/libfs/src/dosfs/fat.c
@@ -200,6 +200,16 @@ _fat_block_read(
 return cmpltd;
 }
 
+void
+fat_block_peek(
+fat_fs_info_t*fs_info,
+const uint32_tblk,
+const uint32_tblk_cnt
+)
+{
+rtems_bdbuf_peek(fs_info->vol.dd, blk, blk_cnt);
+}
+
 static ssize_t
 fat_block_write(
 fat_fs_info_t*fs_info,
diff --git a/cpukit/libfs/src/dosfs/fat.h b/cpukit/libfs/src/dosfs/fat.h
index 064b4747a9..dae69d6e4e 100644
--- a/cpukit/libfs/src/dosfs/fat.h
+++ b/cpukit/libfs/src/dosfs/fat.h
@@ -499,6 +499,11 @@ _fat_block_read(fat_fs_info_t
*fs_info,
 uint32_t  count,
 void *buff);
 
+void
+fat_block_peek(fat_fs_info_t*fs_info,
+   const uint32_tblk,
+   const uint32_tblk_cnt);
+
 ssize_t
 fat_cluster_write(fat_fs_info_t*fs_info,
 uint32_t  start_cln,
diff --git a/cpukit/libfs/src/dosfs/fat_file.c 
b/cpukit/libfs/src/dosfs/fat_file.c
index b4af8a11ca..ef9df0a67c 100644
--- a/cpukit/libfs/src/dosfs/fat_file.c
+++ b/cpukit/libfs/src/dosfs/fat_file.c
@@ -301,8 +301,11 @@ fat_file_read(
 uint32_t   ofs = 0;
 uint32_t   save_ofs;
 uint32_t   sec = 0;
+uint32_t   sec_peek = 0;
 uint32_t   byte = 0;
 uint32_t   c = 0;
+uint32_t   blk = 0;
+uint32_t   blk_cnt = 0;
 
 /* it couldn't be removed - otherwise cache update will be broken */
 if (count == 0)
@@ -345,19 +348,27 @@ fat_file_read(
 c = MIN(count, (fs_info->vol.bpc - ofs));
 
 sec = fat_cluster_num_to_sector_num(fs_info, cur_cln);
+
+save_cln = cur_cln;
+rc = fat_get_fat_cluster(fs_info, cur_cln, _cln);
+if ( rc != RC_OK )
+return rc;
+
+sec_peek = fat_cluster_num_to_sector_num(fs_info, cur_cln);
+blk = fat_sector_num_to_block_num (fs_info, sec_peek);
+blk_cnt = fs_info->vol.bpc >> fs_info->vol.bytes_per_block_log2;
+if (blk_cnt == 0)
+blk_cnt = 1;
+fat_block_peek(fs_info, blk, blk_cnt);
+
 sec += (ofs >> fs_info->vol.sec_log2);
 byte = ofs & (fs_info->vol.bps - 1);
-
 ret = _fat_block_read(fs_info, sec, byte, c, buf + cmpltd);
 if ( ret < 0 )
 return -1;
 
 count -= c;
 cmpltd += c;
-save_cln = cur_cln;
-rc = fat_get_fat_cluster(fs_info, cur_cln, _cln);
-if ( rc != RC_OK )
-return rc;
 
 ofs = 0;
 }
-- 
2.26.2

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

Re: Phrases for CONSTRAINTS section in the directive documentation

[Gedare Bloom]

On Fri, Jan 22, 2021 at 5:55 AM Andrew Butterfield <
andrew.butterfi...@scss.tcd.ie> wrote:

> Hi Sebastian,
>
> I'd prefer 2.
>
> The directive may be called from an interrupt context
>
> (substituting  "must",  "must not", as appropriate)
>
>
Yes, I agree. (Use of "in" is ambiguous here, because "called in" has a
meaning in colloquial speech that differs from the intent here.)


> Regards, Andrew
>
> On 22 Jan 2021, at 12:09, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
> Hello,
>
> since there is an agreement to add a CONSTRAINTS section to the directive
> documentation, I need some standard phrases.
>
> 1.
>
> The directive may be called in interrupt context.
>
> 2.
>
> The directive may be called from interrupt context.
>
> 3.
>
> The directive can be called ... interrupt context.
>
> What do you prefer?
>
> I would use it for other contexts as well.
>
> --
> 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
>
>
> 
> Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204
> Lero@TCD, Head of Software Foundations & Verification Research Group
> School of Computer Science and Statistics,
> Room G.39, O'Reilly Institute, Trinity College, University of Dublin
>  http://www.scss.tcd.ie/Andrew.Butterfield/
> 
>
> ___
> 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: Quick question: How do I get rtems-test

[Gedare Bloom]

On Fri, Jan 22, 2021 at 1:15 AM Richi Dubey  wrote:

> Hi,
>
> I want to clone the rtems-tools/tester repository, but when I run:
>
> ~/quick-start/rtems/6$ git clone https://git.rtems.org/rtems-tools/
>

git://git.rtems.org/rtems-tools.git
should work


>
> Cloning into 'rtems-tools'...
>
> It does not progress any further from this. What may be wrong?
>
> Thanks,
> Richi.
> ___
> 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: [rtems commit] bsps/shared: Adapt fsl-edma driver for imxrt

[Christian MAUDERER]

Am 22.01.21 um 14:04 schrieb Sebastian Huber:


On 21/01/2021 10:26, Christian Mauderer wrote:

  spec/build/bsps/obj.yml  |   5 +
This is the wrong place for these files. Please add a separate object 
for the driver and link to this object in all BSPs which use the driver.




Sorry. I'll create a commit to fix it soon.

I thought that the commit would be OK after it had been on the list for 
about one month without objections.


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

Re: [rtems commit] bsps/shared: Adapt fsl-edma driver for imxrt

[Sebastian Huber]

On 21/01/2021 10:26, Christian Mauderer wrote:

  spec/build/bsps/obj.yml  |   5 +
This is the wrong place for these files. Please add a separate object 
for the driver and link to this object in all BSPs which use the driver.


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

Re: Phrases for CONSTRAINTS section in the directive documentation

[Andrew Butterfield]

Hi Sebastian,

I'd prefer 2.

The directive may be called from an interrupt context

(substituting  "must",  "must not", as appropriate)

Regards, Andrew

> On 22 Jan 2021, at 12:09, Sebastian Huber 
>  wrote:
> 
> Hello,
> 
> since there is an agreement to add a CONSTRAINTS section to the directive 
> documentation, I need some standard phrases.
> 
> 1.
> 
> The directive may be called in interrupt context.
> 
> 2.
> 
> The directive may be called from interrupt context.
> 
> 3.
> 
> The directive can be called ... interrupt context.
> 
> What do you prefer?
> 
> I would use it for other contexts as well.
> 
> -- 
> 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


Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204
Lero@TCD, Head of Software Foundations & Verification Research Group
School of Computer Science and Statistics,
Room G.39, O'Reilly Institute, Trinity College, University of Dublin
 http://www.scss.tcd.ie/Andrew.Butterfield/


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

Build failure with current master

[Jan.Sommer]

Hello,

Our nightly build of the current master of some ARM BSPs failed today (e.g. 
raspberrypi, zedboard).
It seems to be related to commit a434cc80cb00e: bsps/shared: Adapt fsl-edma 
driver for imxrt

The error I get is:
[  60/4060] Compiling bsps/shared/dev/dma/fsl-edma.c
[  62/4060] Compiling bsps/shared/dev/display/disp_hcms29xx.c
../../../bsps/shared/dev/dma/fsl-edma.c:65:35: error: 'EDMA' undeclared here 
(not in a function)
   65 | (volatile struct fsl_edma *) ,
  |   ^~~~
../../../bsps/shared/dev/dma/fsl-edma.c: In function 'fsl_edma_init':
../../../bsps/shared/dev/dma/fsl-edma.c:265:4: error: #error "Unknown chip"
  265 |   #error "Unknown chip"
  |^
../../../bsps/shared/dev/dma/fsl-edma.c: In function 
'fsl_edma_install_obtained_channel':
../../../bsps/shared/dev/dma/fsl-edma.c:362:4: error: #error "Unknown chip"
  362 |   #error "Unknown chip"
  |^
../../../bsps/shared/dev/dma/fsl-edma.c:341:12: warning: unused variable 
'channel_index' [-Wunused-variable]
  341 |   unsigned channel_index = fsl_edma_channel_index_of_tcd(ctx->edma_tcd);
  |^
../../../bsps/shared/dev/dma/fsl-edma.c: In function 'fsl_edma_release_channel':
../../../bsps/shared/dev/dma/fsl-edma.c:422:4: error: #error "Unknown chip"
  422 |   #error "Unknown chip"
  |^
../../../bsps/shared/dev/dma/fsl-edma.c:424:5: warning: passing argument 1 of 
'rtems_interrupt_handler_remove' makes integer from pointer without a cast 
[-Wint-conversion]
  424 | fsl_edma_interrupt_handler,
  | ^~
  | |
  | void (*)(void *)
In file included from ../../../bsps/arm/xilinx-zynq/include/bsp/irq.h:40,
 from ../../../bsps/shared/dev/dma/fsl-edma.c:41:
../../../cpukit/include/rtems/irq-extension.h:159:23: note: expected 
'rtems_vector_number' {aka 'unsigned int'} but argument is of type 'void 
(*)(void *)'
  159 |   rtems_vector_number vector,
  |   ^~
../../../bsps/shared/dev/dma/fsl-edma.c:425:5: warning: passing argument 2 of 
'rtems_interrupt_handler_remove' from incompatible pointer type 
[-Wincompatible-pointer-types]
  425 | ctx
  | ^~~
  | |
  | fsl_edma_channel_context *
In file included from ../../../bsps/arm/xilinx-zynq/include/bsp/irq.h:40,
 from ../../../bsps/shared/dev/dma/fsl-edma.c:41:
../../../cpukit/include/rtems/irq-extension.h:160:27: note: expected 
'rtems_interrupt_handler' {aka 'void (*)(void *)'} but argument is of type 
'fsl_edma_channel_context *'
  160 |   rtems_interrupt_handler handler,
  |   ^~~
../../../bsps/shared/dev/dma/fsl-edma.c:416:8: error: too few arguments to 
function 'rtems_interrupt_handler_remove'
  416 |   sc = rtems_interrupt_handler_remove(
  |^~
In file included from ../../../bsps/arm/xilinx-zynq/include/bsp/irq.h:40,
 from ../../../bsps/shared/dev/dma/fsl-edma.c:41:
../../../cpukit/include/rtems/irq-extension.h:158:19: note: declared here
  158 | rtems_status_code rtems_interrupt_handler_remove(
  |   ^~
../../../bsps/shared/dev/dma/fsl-edma.c:411:12: warning: unused variable 
'channel_index' [-Wunused-variable]
  411 |   unsigned channel_index = fsl_edma_channel_index_of_tcd(ctx->edma_tcd);
  |^
At top level:
../../../bsps/shared/dev/dma/fsl-edma.c:151:13: warning: 
'edma_interrupt_error_handler' defined but not used [-Wunused-function]
  151 | static void edma_interrupt_error_handler(void *arg)
  | ^~~~

We should have the most recent build tools installed.

Best regards,

Jan


Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR)
German Aerospace Center
Institute for Software Technology | Software for Space Systems and Interactive 
Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Phrases for CONSTRAINTS section in the directive documentation

[Sebastian Huber]

Hello,

since there is an agreement to add a CONSTRAINTS section to the 
directive documentation, I need some standard phrases.


1.

The directive may be called in interrupt context.

2.

The directive may be called from interrupt context.

3.

The directive can be called ... interrupt context.

What do you prefer?

I would use it for other contexts as well.

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

Re: Quick question: How do I get rtems-test

[Richi Dubey]

Nevermind, This works: git clone https://github.com/RTEMS/rtems-tools.git

On Fri, Jan 22, 2021 at 1:44 PM Richi Dubey  wrote:

> Hi,
>
> I want to clone the rtems-tools/tester repository, but when I run:
>
> ~/quick-start/rtems/6$ git clone https://git.rtems.org/rtems-tools/
> Cloning into 'rtems-tools'...
>
> It does not progress any further from this. What may be wrong?
>
> Thanks,
> Richi.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Quick question: How do I get rtems-test

[Richi Dubey]

Hi,

I want to clone the rtems-tools/tester repository, but when I run:

~/quick-start/rtems/6$ git clone https://git.rtems.org/rtems-tools/
Cloning into 'rtems-tools'...

It does not progress any further from this. What may be wrong?

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

Re: stm32f4 bsp flash address

[Juan Solano]

Thanks Andrei,

I thought 0x0800 was common across all F4s.

Rgds,
Juan.

On Thu, 21 Jan 2021, at 10:41 PM, Mr. Andrei Chichak wrote:
> Hi Juan,
> 
> On the original stm32f4 board for this BSP (STM32F407 on a STMF4 
> Discovery board), the FLASH memory resides at 0x0.
> 
> I have a BSP for STM32F767 and its FLASH is located at 0x0800  as 
> you have in the 429. It works.
> 
> Andrei
> 
> > On 2021-January-21, at 14:02, Juan Solano  wrote:
> > 
> > Hi all,
> > 
> > I had to update the flash address of the linker script to be able to use 
> > the stm32f4 bsp with my Nucleo board (stm32f429zi). Flash resides at 
> > 0x0800, and it is aliased also at 0x0. I made it work with my gdb 
> > environment just by changing the ROM address to the actual flash address in 
> > the chip.
> > 
> > We can always use tools that flash it at the correct location, 
> > independently of what the linker script says, but Is there a reason why in 
> > RTEMS the 0x0 address is used?
> > 
> > --- a/c/src/lib/libbsp/arm/stm32f4/startup/linkcmds.stm32f4
> > +++ b/c/src/lib/libbsp/arm/stm32f4/startup/linkcmds.stm32f4
> > @@ -1,6 +1,6 @@
> > MEMORY {
> >   RAM_INT : ORIGIN = 0x2000, LENGTH = 128k
> > -   ROM_INT : ORIGIN = 0x, LENGTH = 1M
> > +   ROM_INT : ORIGIN = 0x0800, LENGTH = 1M
> > 
> > Thanks,
> > Juan.
> > ___
> > 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