Re: Status of RISCV port on sis

[Sebastian Huber]

- Am 13. Jan 2019 um 0:09 schrieb Jiri Gaisler j...@gaisler.se:

> On 1/11/19 1:36 PM, Jiri Gaisler wrote:
>> On 1/9/19 10:46 AM, Sebastian Huber wrote:
>>> Hello Jiri,
>>>
>>> could you please rebase your work to this RTEMS commit:
>>>
>>> https://git.rtems.org/rtems/commit/?id=b9ffc41c9678fb3c5386c1a6ab394656ec85dbc6
>>>
>> This works fine for me - I can now pass all uni-processor tests. On SMP, I 
>> still
>> have a few fails but I think they are related to the simulator and the
>> compressed RISC-V instruction set. I will investigate further ...
> 
> The atomic LR/SC instructions did not work as expected in the simulator, which
> caused the failures. After cleaning that up, all tests now pass. I have tested
> up to 4 cpus and various frequencies and time slots in the sim with no fails,
> so it seems fairly robust. I will clean up my bsp sources and post the patches
> on the list for review. I will also provide a patch for the RISC-V version of
> gdb-8.2 to add the new sim. Thanks for the help to get this going..!
> 
> 
> $ rtems-test --rtems-bsp=riscv-sis riscv-rtems5/c/grlib/testsuites 
> --log=all.txt
> 
> 
> Passed:    630
> Failed:  0
> User Input:  5
> Expected Fail:   0
> Indeterminate:   0
> Benchmark:   3
> Timeout: 0
> Invalid: 0
> Wrong Version:   0
> Wrong Build: 0
> Wrong Tools: 0
> --
> Total: 638
> User Input:
> monitor.exe
> termios.exe
> top.exe
> capture.exe
> fileio.exe
> Benchmark:
> linpack.exe
> dhrystone.exe
> whetstone.exe
> Average test time: 0:00:00.732410
> Testing time : 0:07:47.277261

This is really great. This is the second free simulator (the other is SIS) 
which is capable enough to run all tests successfully. We should think about 
making a RISC-V BSP the default in the documentation instead of erc32.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Status of RISCV port on sis

[Jiri Gaisler]

On 1/13/19 2:48 PM, Sebastian Huber wrote:
> - Am 13. Jan 2019 um 0:09 schrieb Jiri Gaisler j...@gaisler.se:
>
>> On 1/11/19 1:36 PM, Jiri Gaisler wrote:
>>> On 1/9/19 10:46 AM, Sebastian Huber wrote:
 Hello Jiri,

 could you please rebase your work to this RTEMS commit:

 https://git.rtems.org/rtems/commit/?id=b9ffc41c9678fb3c5386c1a6ab394656ec85dbc6

>>> This works fine for me - I can now pass all uni-processor tests. On SMP, I 
>>> still
>>> have a few fails but I think they are related to the simulator and the
>>> compressed RISC-V instruction set. I will investigate further ...
>> The atomic LR/SC instructions did not work as expected in the simulator, 
>> which
>> caused the failures. After cleaning that up, all tests now pass. I have 
>> tested
>> up to 4 cpus and various frequencies and time slots in the sim with no fails,
>> so it seems fairly robust. I will clean up my bsp sources and post the 
>> patches
>> on the list for review. I will also provide a patch for the RISC-V version of
>> gdb-8.2 to add the new sim. Thanks for the help to get this going..!
>>
>>
>> $ rtems-test --rtems-bsp=riscv-sis riscv-rtems5/c/grlib/testsuites 
>> --log=all.txt
>>
>>
>> Passed:    630
>> Failed:  0
>> User Input:  5
>> Expected Fail:   0
>> Indeterminate:   0
>> Benchmark:   3
>> Timeout: 0
>> Invalid: 0
>> Wrong Version:   0
>> Wrong Build: 0
>> Wrong Tools: 0
>> --
>> Total: 638
>> User Input:
>>  monitor.exe
>>  termios.exe
>>  top.exe
>>  capture.exe
>>  fileio.exe
>> Benchmark:
>>  linpack.exe
>>  dhrystone.exe
>>  whetstone.exe
>> Average test time: 0:00:00.732410
>> Testing time : 0:07:47.277261
> This is really great. This is the second free simulator (the other is SIS) 
> which is capable enough to run all tests successfully. We should think about 
> making a RISC-V BSP the default in the documentation instead of erc32.

Good idea. ERC32 is getting old and is not really known outside the space 
community. I still need to add the M, F and D extensions to the RISC-V sim 
though, so we can test all of the (32-bit) combinations. I should be able to do 
this next week and then I can post all patches for review and testing. Code 
coverage support is still on the list, it will follow once the sim has settled 
a bit ...




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

[PATCH] FIXED: wrong configure switch for stm32f4 BSP

[kaidoho]

---
 c/src/lib/libbsp/arm/stm32f4/configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/c/src/lib/libbsp/arm/stm32f4/configure.ac 
b/c/src/lib/libbsp/arm/stm32f4/configure.ac
index 7b621aa6d4..00ca0b73ae 100644
--- a/c/src/lib/libbsp/arm/stm32f4/configure.ac
+++ b/c/src/lib/libbsp/arm/stm32f4/configure.ac
@@ -32,7 +32,7 @@ RTEMS_BSPOPTS_SET([STM32F4_PCLK1],[stm32f1*],[800])
 RTEMS_BSPOPTS_SET([STM32F4_PCLK1],[*],[1600])
 RTEMS_BSPOPTS_HELP([STM32F4_PCLK1],[PCLK1 frequency in Hz])
 
-RTEMS_BSPOPTS_SET([STM32F4_PCLK1],[stm32f1*],[800])
+RTEMS_BSPOPTS_SET([STM32F4_PCLK2],[stm32f1*],[800])
 RTEMS_BSPOPTS_SET([STM32F4_PCLK2],[*],[1600])
 RTEMS_BSPOPTS_HELP([STM32F4_PCLK2],[PCLK2 frequency in Hz])
 
-- 
2.20.1.windows.1

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

Re: [PATCH] Fix 'build_max_size_human' ref. before assignment

[Chris Johns]

On 11/1/19 4:31 pm, Sebastian Huber wrote:
> - Am 11. Jan 2019 um 0:11 schrieb Chris Johns chr...@rtems.org:
> 
>> On 10/1/19 11:17 pm, Sebastian Huber wrote:
>>> This patch resulted in this mail report issue:
>>>
>>> Your mail to 'build' with the subject
>>>
>>>     Build Linux: FAILED 6/rtems-epiphany on x86_64-linux-gnu
>>> (epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1)
>>>
>>>
>>>
>>> Is being held until the list moderator can review it for approval.
>>>
>>> The reason it is being held:
>>>
>>>     Message body is too big: 1093190 bytes with a limit of 256 KB
>>>
>>
>> Are you asking for the size limit on the list to be raised?
> 
> No, but is this the normal size for a failed report?
> 

It should not be. I will accept the post and then we can see the reason.

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

Re: clang-format Style for RTEMS

[Mikail Yayla]

Hello,

to evaluate the effort needed to adapt clang-format for RTEMS, we are
currently trying to implement the option to put the ")" at the
end of a function declaration in a separate line, e.g.:

bool _Thread_Initialize(
   Thread_Information   *information,
[...]
   Objects_Name  name
) // <- in a new line
{

I asked for help in the clang mailing list, but it does not seem like there
is a person who is willing to mentor me in getting used to the clang-format
code and the tools it depends on. It looks like they don't have much
interest to invest time in a private patch.

Currently I am using QtCreator to load the LLVM cmake and build the
project. It is possible to use the Debugger to trace the execution of
clang-format.

In my view, with the help of QtCreator and the debugger it should be
possible to adapt clang-format for RTEMS in a reasonable amount of time.
But since it is an extensive project, it will take some time to understand
the code and to feel comfortable enough to implement new functionality.

Best,
Mikail

On Mon, Dec 17, 2018 at 1:44 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Mikail,
>
> thanks for your summary. I tried a couple for C code formatters for
> RTEMS in the last couple of years and none delivered sufficiently good
> results. My hope was that we could use clang-format with some additions
> for RTEMS. However, it seems the hurdle to add new style options to
> clang-format is quite high:
>
>
> https://clang.llvm.org/docs/ClangFormatStyleOptions.html#adding-additional-style-options
>
>
> "The goal of the clang-format project is more on the side of supporting
> a limited set of styles really well as opposed to supporting every
> single style used by a codebase somewhere in the wild. Of course, we do
> want to support all major projects and thus have established the
> following bar for adding style options. Each new style option must ..
>
>   * be used in a project of significant size (have dozens of
> contributors)
>   * have a publicly accessible style guide
>   * have a person willing to contribute and maintain patches"
>
> I am not sure if RTEMS would count as a project of "significant size".
>
> See also:
>
> http://lists.llvm.org/pipermail/cfe-dev/2018-December/060560.html
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: Zynq RTEMS 5 SMP Crashing on call to connect in socket.h [Solved]

[Misra, Avinash]

Hi,

My issue turned out to be a configuration issue where I was using the incorrect 
scheduler. I was originally using #define 
CONFIGURE_SCHEDULER_PRIORITY_AFFINITY_SMP when in fact I should have been using 
#define CONFIGURE_SCHEDULER_EDF_SMP. This thread 
(https://lists.rtems.org/pipermail/devel/2018-October/023349.html) made that 
very clear to me. However, I do wonder if this is documented as part of the BSD 
documentation and I missed it? Is this already well documented or is this 
something that should be included with the BSD/RTEMS Networking documentation?

Thanks,
Avi

From: devel  On Behalf Of Misra, Avinash
Sent: Sunday, January 13, 2019 1:04 PM
To: rtems-de...@rtems.org 
Subject: Zynq RTEMS 5 SMP Crashing on call to connect in socket.h

Hi,

I'm having a peculiar issue when running RTEMS in a SMP configuration and 
trying to call connect on a TCP Client Socket which is that RTEMS crashes when 
calling the system connect routine with the following error:

Fatal source: 10 
Fatal Code: 7 <0x0007>
RTEMS version: 5.0.0.b3c624d8886db6e791babe5e0d4f8b28992e000a
RTEMS tools: 7.3.0 20180125 (RTEMS 5, RSB 
9955b1a430677b12c04c77eb6502fae4bb6947b2, Newlib 
08eab6396f678cf5e5968acaed0bae9fd129983b)
Executing Thread ID: 0x08a010003
Executing Thread Name: IRQS

This only seems to occur when I configure RTEMS to execute on both cores of the 
A9 processor (by setting #define CONFIGURE_MAXIMUM_PROCESSORS to 2). When I 
have #define CONFIGURE_MAXIMUM_PROCESSORS set to 1 the program runs as 
expected, connects to my TCP server and sends nominal data.  Also, for what 
it's worth, the name of my task is not IRQS so I'm not sure why I keep getting 
this exception in the IRQS thread.

My system.hdf file and MMU setup code look as follow:

System.hdf:

[cid:image001.jpg@01D4AB60.40D3CEE0]

MMU Configuration file:
#include 
#include 
#include 
#include 
#include 

BSP_START_DATA_SECTION static const arm_cp15_start_section_config
zynq_mmu_config_table[] = {
  ARMV7_CP15_START_DEFAULT_SECTIONS,
  {
.begin = 0xE000U,
   .end   = 0xE030U,
.flags = ARMV7_MMU_DEVICE | ARM_MMU_SECT_S
  },{
.begin = 0xF800U,
.end   = 0xF900U,
.flags = ARMV7_MMU_DEVICE | ARM_MMU_SECT_S
  },{
.begin = 0xU, /*RAM 0 START ADDR*/
.end   = 0x0002U, /*RAM 0 END ADDR*/
.flags = ARMV7_MMU_DEVICE | ARM_MMU_SECT_S
  },{
   .begin = 0xU, /*RAM 1 START ADDR*/
   .end   = 0xFDFFU, /*RAM 1 END ADDR*/
   .flags = ARMV7_MMU_DEVICE | ARM_MMU_SECT_S
  },{
   .begin = 0x4120U, /*AXI GPIO*/
   .end   = 0x4120U, /*AXI GPIO*/
   .flags = ARMV7_MMU_DEVICE | ARM_MMU_SECT_S
  }
};

BSP_START_TEXT_SECTION void zynq_setup_mmu_and_cache(void)
{
  uint32_t ctrl = arm_cp15_start_setup_mmu_and_cache(
  ARM_CP15_CTRL_A,
  ARM_CP15_CTRL_AFE | ARM_CP15_CTRL_Z
  );

  arm_cp15_start_setup_translation_table_and_enable_mmu_and_cache(
 ctrl,
 (uint32_t *) bsp_translation_table_base,
 ARM_MMU_DEFAULT_CLIENT_DOMAIN,
 &zynq_mmu_config_table[0],
 RTEMS_ARRAY_SIZE(zynq_mmu_config_table)
  );
}


Does anyone have an idea of as to what may be going on here?

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

RE: Strange RTEMS DMA Access on Zynq [Solved]

[Misra, Avinash]

Hi Chris,

Thank you for your insightful email below, it went a long way towards solving 
my issue. I wanted to describe what I ran into here in case someone else runs 
into this in the future.  My issue was comprised of 2 parts:

1.) Turns out I had an alignment issue with the DMA to begin with, which is why 
I kept getting random offsets in where my data would appear and also as to why 
my data would appear clipped. I'm using the AXI DMA IP and it was configured to 
be an "auto size" on the READ which ended up doing 64-bit transactions on a 
32-bit bus. Sizing this back to 32-bit gave me what I would expect to see on 
the ILA in the firmware. The next thing I did was ensured my static buffer was 
aligned on a  32-bit address boundary this was done using the  GCC align 
attribute to do this. Then, finally, to make sure that I wouldn't run into 
future alignment issues I enabled the "Allow Unaligned Transactions" option in 
the AXI DMA IP which, per the Xilinx Documentation, allows for and resolves 
unaligned address issues.

2.) The next thing that I had to do after getting the alignment issues sorted 
out was to ensure I was invalidating the cache. What I learned was that I had 
to do a rtems_cache_flush_multiple_data_lines() before starting the DMA and 
after the DMA had finished.

By taking the steps outlined above I am able to obtain my data from the DMA.

Thanks,
Avi
-Original Message-
From: Chris Johns  
Sent: Wednesday, January 9, 2019 10:36 PM
To: Misra, Avinash ; rtems-de...@rtems.org 

Subject: Re: Strange RTEMS DMA Access on Zynq

On 10/1/19 2:28 pm, Misra, Avinash wrote:
> 
> I am currently using RTEMS to access a DMA core on the Zynq and am 
> noticing some interesting/peculiar behavior:
> 
> When I provide my DMA engine a statically allocated buffer what I 
> notice is that the first few bytes (5) of the buffer, after getting it 
> back from the DMA, remain unchanged however the rest of the buffer 
> after that contains the data (minus the first 5 bytes that are missing).
> 
> When I provide my DMA engine a dynamically allocated buffer from 
> either C++ new or Posix malloc() or posix_memalign() then I receive 
> all of the data correctly from byte 0 to the last byte.
> 
> If I provide my DMA engine my statically allocated buffer offset by 
> the amount of bytes it fails to write into then I will see all of my 
> data from the DMA beginning at the offset.
> 
> Has anyone experienced something similar or have any suggestions as to 
> what may be going on and/or thoughts on how to fix this behavior? I 
> would ideally like to be able to do this with some statically allocated 
> buffers.
> 

The compiler's default alignment for the buffer will not be the same as the DMA 
engine. You will need to use the alignment.

What is the alignment requirement for the DMA engine? You will need to add this 
to the size of the static buffer and use an offset into the buffer that meets 
the DMA engine's alignment.

Do not forget to invalidate the cache once the DMA engine has finished.

Are you using the CDMA IP?

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

Re: RSB documentation

[Chris Johns]

On 11/1/19 8:13 pm, Sebastian Huber wrote:
> At which position in the manual should it be placed? I think we should 
> organize the chapters according to the relevance for new users and how the 
> are used later during application development. I would use the RSB chapter as 
> a reference chapter containing all the details and cover the common case in 
> the Quick Start chapter. So, I would move the RSB chapter to the end after 
> the Host Tools.

The place the RSB moves to could depend on where some others get moved too. A
review of the sections follows.

Do we need a "How to use this manual?" section in the Introduction? It could
also have a "What to read before starting" part.

The manual is organised as:

 Introduction
  Overview, features, what a real-time and what a real-time kernel is.

 Ecosystem
  Rational, open source and deployment. This is to explain what we
  call the host side tools, commands, and configuration. Maybe we
  need to explain RTEMS is only run on targets and is not self
  hosting so the ecosystem provides a consistent host side
  environment.

  This section needs to be enhanced to cover the RSB, RTEMS Tools
  and what ever else we want to include. The deployment section's
  building binary tools can be moved to some where else, that is
  an advanced topic.

 Quick Start
  I think we need to keep a top level section called "Quick Start"
  because it is easy for a new user to see and click on. The sidebar
  on the html output is collapsed and searching for a quick start or
  something like it is awkward. Links to other sections should aim to
  provide launch sites to more detail.

 Host Computer
  Should this be placed under Ecosystem?

  This needs to be before the RSB section so the correct packages are
  present on the host for the RSB.

 Installation
  This explains the environment. Is this also part of the Ecosystem?

 Hardware
  A discussion about the way RTEMS views hardware, architectures and
  BSPs. This is about the RTEMS side of things rather than the
  host and the ecosystem.

 Board Support Packages
  The BSPs. I have been wondering if the BSP names are suitable
  heading or do we want something more formal if that is even
  possible?

 Executables
  This is the first section I have added that starts with something
  about the section and what to expect. I think this is a good
  practice to do.

  I am planning to add a section on libdl and applications for it
  once the rtl-archive and rtl-ctor-dtor branches in
  https://git.rtems.org/chrisj/rtems.git/ are merged.

 Testing
  Using the rtems-test and rtems-run interface to run code.

 Tracing
  The tracing support for RTEMS. This is the last in a progression
  from a host, tools, kernel, testing the kernel, to runtime performance.

 Host Tools
  The published interface to the tools we support. In effect the interface
  users can depend on across releases.

I hope this helps.

Note: I see the index is broken with the online builds. I suspect the
genindex.rst removal I did is the cause and I also suspect there is an issue
between versions of sphinx-build being used. My development version is newer
than the online builder but we cannot update that version until the xindy issue
on FreeBSD is resolved and even with upstream FreeBSD fixing the port getting it
into the version 10 we run is problematic.

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

Re: Rework parts of the user manual

[Chris Johns]

On 12/1/19 1:59 am, Sebastian Huber wrote:
> this is the first patch set targeting the user manual. My goal is to write an 
> easy to follow quick start chapter which references other chapters for the 
> details.

Is there a build of this I could please review?

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

Re: rtems-test : getting result invalid

[Chris Johns]

On 13/1/19 5:55 pm, Vijay Kumar Banerjee wrote:
> On Sun, 13 Jan 2019 at 08:41, Chris Johns  > wrote:
> 
> On 13/1/19 7:19 am, Vijay Kumar Banerjee wrote:
> >
> > With the recent change to the qemu options I'm getting results invalid 
> when
> > running rtems-test without the coverage option. However, it works fine
> when the
> > coverage option is enabled.
> >
> 
> What are the command lines for each run?
> 
> $HOME/development/rtems/rtems-tools/tester/rtems-test \
> --rtems-tools=$HOME/development/rtems/5 \
> --log=coverage_analysis.log \
> --rtems-bsp=leon3-qemu-cov \
> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples
>  
> 
> I'm also attaching the log file.
> 

Sorry I should have been exact in my question.

Could you please paste one of each og the qemu commands lines the rtems-test
runs for coverage and no coverage so we can view the differences?

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

Re: [PATCH] Fix 'build_max_size_human' ref. before assignment

[Chris Johns]

On 14/1/19 8:05 am, Chris Johns wrote:
> On 11/1/19 4:31 pm, Sebastian Huber wrote:
>> - Am 11. Jan 2019 um 0:11 schrieb Chris Johns chr...@rtems.org:
>>
>>> On 10/1/19 11:17 pm, Sebastian Huber wrote:
 This patch resulted in this mail report issue:

 Your mail to 'build' with the subject

     Build Linux: FAILED 6/rtems-epiphany on x86_64-linux-gnu
 (epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1)



 Is being held until the list moderator can review it for approval.

 The reason it is being held:

     Message body is too big: 1093190 bytes with a limit of 256 KB

>>>
>>> Are you asking for the size limit on the list to be raised?
>>
>> No, but is this the normal size for a failed report?
>>
> 
> It should not be. I will accept the post and then we can see the reason.
> 

The report captures the last part of the build and it looks like the lines in
the section of the libstdc++ library being built are long. The use of full
length hashes in gcc and newlib has increased the path lengths.

I increased the number of lines captured a while ago because the number of cores
being used when building meant distance in the output between the error and the
end of the log can be a long way.

Maybe a smarter parser should be added and just the error logged?

Chris


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

Re: Strange RTEMS DMA Access on Zynq [Solved]

[Chris Johns]

On 14/1/19 9:02 am, Misra, Avinash wrote:
> Thank you for your insightful email below, it went a long way towards solving 
> my issue. I wanted to describe what I ran into here in case someone else runs 
> into this in the future.  

Thank you for the follow up and nice work getting it running.

> My issue was comprised of 2 parts:
> 
> 1.) Turns out I had an alignment issue with the DMA to begin with, which is 
> why I kept getting random offsets in where my data would appear and also as 
> to why my data would appear clipped. I'm using the AXI DMA IP and it was 
> configured to be an "auto size" on the READ which ended up doing 64-bit 
> transactions on a 32-bit bus. Sizing this back to 32-bit gave me what I would 
> expect to see on the ILA in the firmware. The next thing I did was ensured my 
> static buffer was aligned on a  32-bit address boundary this was done using 
> the  GCC align attribute to do this. Then, finally, to make sure that I 
> wouldn't run into future alignment issues I enabled the "Allow Unaligned 
> Transactions" option in the AXI DMA IP which, per the Xilinx Documentation, 
> allows for and resolves unaligned address issues.
> 
> 2.) The next thing that I had to do after getting the alignment issues sorted 
> out was to ensure I was invalidating the cache. What I learned was that I had 
> to do a rtems_cache_flush_multiple_data_lines() before starting the DMA and 
> after the DMA had finished.

If you are reading from the memory in to the IP then you would need to flush the
memory otherwise I do not think you need too.

> 
> By taking the steps outlined above I am able to obtain my data from the DMA.
> 

I have not used the AXI DMA IP. I know with the CMDA IP you need to be careful
when handling the done interrupt because the DMA can still be active by the time
the software enters the interrupt. The DMA engine is finished however the data
is still working it's way to the memory.

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

RE: Strange RTEMS DMA Access on Zynq [Solved]

[Misra, Avinash]

Thanks for this additional tidbit. I'm new to using DMA but haven't seen this 
behavior on any of the testing I've done so far with the AXI DMA, however, I do 
check the status register of the DMA and wait for the DMA to transition to the 
IDLE state prior to marking the DMAed data ready for use.  I will, however, 
keep this comment in the back of my mind if I run into any further issues with 
the DMA and will also reply to this thread to keep the mailing list up to date 
with relevant information as well.

-Original Message-
From: Chris Johns  
Sent: Sunday, January 13, 2019 5:24 PM
To: Misra, Avinash ; rtems-de...@rtems.org 

Subject: Re: Strange RTEMS DMA Access on Zynq [Solved]

On 14/1/19 9:02 am, Misra, Avinash wrote:
> Thank you for your insightful email below, it went a long way towards solving 
> my issue. I wanted to describe what I ran into here in case someone else runs 
> into this in the future.  

Thank you for the follow up and nice work getting it running.

> My issue was comprised of 2 parts:
> 
> 1.) Turns out I had an alignment issue with the DMA to begin with, which is 
> why I kept getting random offsets in where my data would appear and also as 
> to why my data would appear clipped. I'm using the AXI DMA IP and it was 
> configured to be an "auto size" on the READ which ended up doing 64-bit 
> transactions on a 32-bit bus. Sizing this back to 32-bit gave me what I would 
> expect to see on the ILA in the firmware. The next thing I did was ensured my 
> static buffer was aligned on a  32-bit address boundary this was done using 
> the  GCC align attribute to do this. Then, finally, to make sure that I 
> wouldn't run into future alignment issues I enabled the "Allow Unaligned 
> Transactions" option in the AXI DMA IP which, per the Xilinx Documentation, 
> allows for and resolves unaligned address issues.
> 
> 2.) The next thing that I had to do after getting the alignment issues sorted 
> out was to ensure I was invalidating the cache. What I learned was that I had 
> to do a rtems_cache_flush_multiple_data_lines() before starting the DMA and 
> after the DMA had finished.

If you are reading from the memory in to the IP then you would need to flush 
the memory otherwise I do not think you need too.

> 
> By taking the steps outlined above I am able to obtain my data from the DMA.
> 

I have not used the AXI DMA IP. I know with the CMDA IP you need to be careful 
when handling the done interrupt because the DMA can still be active by the 
time the software enters the interrupt. The DMA engine is finished however the 
data is still working it's way to the memory.

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

Re: rtems-test : getting result invalid

[Vijay Kumar Banerjee]

On Mon, 14 Jan 2019 at 03:39, Chris Johns  wrote:

> On 13/1/19 5:55 pm, Vijay Kumar Banerjee wrote:
> > On Sun, 13 Jan 2019 at 08:41, Chris Johns  > > wrote:
> >
> > On 13/1/19 7:19 am, Vijay Kumar Banerjee wrote:
> > >
> > > With the recent change to the qemu options I'm getting results
> invalid when
> > > running rtems-test without the coverage option. However, it works
> fine
> > when the
> > > coverage option is enabled.
> > >
> >
> > What are the command lines for each run?
> >
> > $HOME/development/rtems/rtems-tools/tester/rtems-test \
> > --rtems-tools=$HOME/development/rtems/5 \
> > --log=coverage_analysis.log \
> > --rtems-bsp=leon3-qemu-cov \
> >
> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples
> >
> > I'm also attaching the log file.
> >
>
> Sorry I should have been exact in my question.
>
> Could you please paste one of each og the qemu commands lines the
> rtems-test
> runs for coverage and no coverage so we can view the differences?
>
> ---
without coverage
---
] QEMU 2.4.1 monitor - type 'help' for more information
] (qemu) QEMU 2.4.1 monitor - type 'help' for more information
] (qemu)
] (qemu)
[ 2/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | sparc/leon3-qemu:
capture.exe
Result: invalidTime: 0:00:21.067479 capture.exe
=>  run: qemu-system-sparc -no-reboot -serial null -serial mon:stdio
-nographic -M leon3_generic -exec-trace
/home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/capture.exe.cov
-kernel
/home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/capture.exe
--

with coverage
-
[ 2/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | sparc/leon3-qemu:
capture.exe
Result: user-input Time: 0:00:01.053977 capture.exe
=>  run: qemu-system-sparc -no-reboot -monitor none -serial stdio
-nographic -M leon3_generic -exec-trace
/home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/capture.exe.cov
-kernel
/home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/capture.exe

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

Re: RSB documentation

[Sebastian Huber]

I added a build of the partially restructured user manual here:

https://ftp.rtems.org/pub/rtems/people/sebh/user.pdf

On 13/01/2019 23:03, Chris Johns wrote:

On 11/1/19 8:13 pm, Sebastian Huber wrote:

At which position in the manual should it be placed? I think we should organize 
the chapters according to the relevance for new users and how the are used 
later during application development. I would use the RSB chapter as a 
reference chapter containing all the details and cover the common case in the 
Quick Start chapter. So, I would move the RSB chapter to the end after the Host 
Tools.

The place the RSB moves to could depend on where some others get moved too. A
review of the sections follows.

Do we need a "How to use this manual?" section in the Introduction? It could
also have a "What to read before starting" part.


I think this should go into Introduction -> Overview.



The manual is organised as:

  Introduction
   Overview, features, what a real-time and what a real-time kernel is.

  Ecosystem
   Rational, open source and deployment. This is to explain what we
   call the host side tools, commands, and configuration. Maybe we
   need to explain RTEMS is only run on targets and is not self
   hosting so the ecosystem provides a consistent host side
   environment.

   This section needs to be enhanced to cover the RSB, RTEMS Tools
   and what ever else we want to include. The deployment section's
   building binary tools can be moved to some where else, that is
   an advanced topic.


I moved the Ecosystem into Introduction, since it introduces the RTEMS 
world. I think it fits quite well here.




  Quick Start
   I think we need to keep a top level section called "Quick Start"
   because it is easy for a new user to see and click on. The sidebar
   on the html output is collapsed and searching for a quick start or
   something like it is awkward. Links to other sections should aim to
   provide launch sites to more detail.


Yes, this is now the second chapter. I would like to use the following 
sections:


"Host Computer Setup"
"Prefixes"
"RTEMS Repository Clone"
"RTEMS Tool Set Installation"
"RTEMS Source Bootstrap"
"BSP Configuration and Installation"
"Example Application"

Do we want to use "tool chain" or "tool set" or "tools" for the RTEMS 
things running on the host computer?




  Host Computer
   Should this be placed under Ecosystem?

   This needs to be before the RSB section so the correct packages are
   present on the host for the RSB.


I think this should remain a separate chapter. It is one of the first 
things you have to deal with as a new user.




  Installation
   This explains the environment. Is this also part of the Ecosystem?


The installation of things running on the host and the installation of 
an RTEMS BSP should be in separate chapters.




  Hardware
   A discussion about the way RTEMS views hardware, architectures and
   BSPs. This is about the RTEMS side of things rather than the
   host and the ecosystem.

  Board Support Packages
   The BSPs. I have been wondering if the BSP names are suitable
   heading or do we want something more formal if that is even
   possible?


The heading is now " (name>)". This should make it easy to find.




  Executables
   This is the first section I have added that starts with something
   about the section and what to expect. I think this is a good
   practice to do.

   I am planning to add a section on libdl and applications for it
   once the rtl-archive and rtl-ctor-dtor branches in
   https://git.rtems.org/chrisj/rtems.git/ are merged.

  Testing
   Using the rtems-test and rtems-run interface to run code.

  Tracing
   The tracing support for RTEMS. This is the last in a progression
   from a host, tools, kernel, testing the kernel, to runtime performance.

  Host Tools
   The published interface to the tools we support. In effect the interface
   users can depend on across releases.

I hope this helps.

Note: I see the index is broken with the online builds. I suspect the
genindex.rst removal I did is the cause and I also suspect there is an issue
between versions of sphinx-build being used. My development version is newer
than the online builder but we cannot update that version until the xindy issue
on FreeBSD is resolved and even with upstream FreeBSD fixing the port getting it
into the version 10 we run is problematic.


It is also broken on my host. I use sphinx-build 1.8.1.

--
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: Rework parts of the user manual

[Sebastian Huber]

On 13/01/2019 23:04, Chris Johns wrote:

On 12/1/19 1:59 am, Sebastian Huber wrote:

this is the first patch set targeting the user manual. My goal is to write an 
easy to follow quick start chapter which references other chapters for the 
details.

Is there a build of this I could please review?


https://ftp.rtems.org/pub/rtems/people/sebh/user.pdf

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

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

[PATCH] score: Simplify _Addresses_Is_aligned()

[Sebastian Huber]

The CPU_ALIGNMENT must not be zero, this is also checked via a static
assertion.  Fix formatting.
---
 cpukit/include/rtems/score/address.h | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/cpukit/include/rtems/score/address.h 
b/cpukit/include/rtems/score/address.h
index fb88230d18..00fc105e48 100644
--- a/cpukit/include/rtems/score/address.h
+++ b/cpukit/include/rtems/score/address.h
@@ -107,15 +107,11 @@ RTEMS_INLINE_ROUTINE intptr_t _Addresses_Subtract(
  * @retval true The @a address is aligned.
  * @retval false The @a address is not aligned.
  */
-RTEMS_INLINE_ROUTINE bool _Addresses_Is_aligned (
+RTEMS_INLINE_ROUTINE bool _Addresses_Is_aligned(
   const void *address
 )
 {
-#if (CPU_ALIGNMENT == 0)
-return true;
-#else
-return (((uintptr_t)address % CPU_ALIGNMENT) == 0);
-#endif
+  return ( (uintptr_t) address % CPU_ALIGNMENT ) == 0;
 }
 
 /**
-- 
2.16.4

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