Re: "atsamv" BSP legacy network driver status

2020-01-29 Thread Christian Mauderer 
On 29/01/2020 22:30, dufa...@hda.com wrote:
> 
> 
>> On Jan 29, 2020, at 08:12 , Christian Mauderer 
>>  wrote:
>>
>> On 29/01/2020 13:15, dufa...@hda.com wrote:
>>>
 On Jan 29, 2020, at 03:13 , Christian Mauderer 
  wrote:

 Hello Peter,

 On 28/01/2020 22:37, dufa...@hda.com wrote:
>
>> On Jan 28, 2020, at 04:46 , Christian Mauderer 
>>  wrote:
>>
>> Before our customers migrated to libbsd (to get some of the features
>> there) the driver in legacy worked. But that is a few years back.
>> Currently I only know of applications using the libbsd driver.
>>
>
> How are you linking the libbsd code?  Where do you run the code from?

 May I start with a counter-question? Are you using an evaluation board
 or some custom one? Which chip variant are you using? All projects that
 I have been involved used one of the bigger chips (SAME70 or SAMV71).
>>>
>>> I put the BSP configuration in the original posting but I clipped it out, I 
>>> tend to like to clip.  It's the SAMV71 "Xplained" Ultra.
>>>
>>
>> No problem. Just missed that in the first message. So it's one of the
>> bigger chips too.
>>

>
> The application I'm testing doesn't fit in the internal SRAM provided by 
> the default "linkcmds" in the libbsd case, partly because libbsd is 
> bigger and partly because when I build for "libbsd" it needs "libblock".
>
 That depends on the project. One project where I can give you quite open
 information is GRiSP. That project is an evaluation platform for using
 Erlang on RTEMS. We did most of the initial the RTEMS stuff for it. You
 can find the basic RTEMS software here:

 https://github.com/grisp/grisp-software

 In this project we have a bootloader in the internal flash with some
 stuff in an SDRAM. See the linker command file for that:

 https://github.com/grisp/grisp-software/blob/master/grisp-bootloader/linkcmds.bootloader

 The bootloader doesn't have network support (I removed quite some bits
 with the "slim-down.h" file) but it uses libbsd for the SD card. It then
 starts a bigger RTEMS application from the SD card. That application
 uses libbsd for USB and WLAN. The application uses linkcmds.sdram from
 RTEMS.

> It fits if I use "linkcmds.sdram", but then I can't run it because the 
> SDRAM must not be set up properly at reset, I guess I'd need to come up 
> with something using "openocd" that will set up the SDRAM before starting 
> the program.
>
> I then tried putting just REGION_START in internal flash but it fails 
> when it jump through a trampoline to "system_init_flash" which was still 
> in the SDRAM.
>
> Then I tried using "linkcmds.qspiflash" but the program didn't fit again 
> since more space was required in the internal SRAM.
>

 We have another project where QSPI is used. I can't give you all details
 but some basic information are possible:


> 
> (...)
> 

>
>>> This will help a lot.
>>>
>>> Is the bootloader for the second project the same as the one in "grisp" but 
>>> not slimmed down?
>>
>> No. It's a different one because there is a completely different boot
>> concept. On GRiSP the boot is done from a SD card. For this customer the
>> bootloader can update the program in the XIP area and start it from there.
>>
>> Let me know if I can help you with more information.
>>
>> Best regards
>>
>> Christian
>>
> 
> 
> I thought I'd found an easy way to continue by just putting REGION_WORK in 
> SDRAM.  That region isn't used until after the SDRAM is initialized.  It 
> freed up lots of internal SRAM memory when not using "libbsd".
> 
> Unfortunately it still overflows internal SRAM (INTSRAM) when using "libbsd".
> I'm assuming that there isn't anything else assigned to INTSRAM that can 
> easily be moved to SDRAM where the SDRAM won't be used until after 
> initialization.  Is that correct?
> 

The SDRAM initialization is done in bsp_start_hook_0. Most
initialization is done in bsp_start_hook_1. You should be able to put
the following into SDRAM without problems:

- REGION_WORK
- REGION_BSS
- REGION_DATA
- REGION_STACK

If that's not enough, I would have to take a more detailed look.

Best regards

Christian


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

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list

Re: Ticket #3515

2020-01-29 Thread Chris Johns 
On 29/1/20 7:03 pm, Bran S wrote:
> Hi Guys,
> 
> I am trying to solve #3515
> https://devel.rtems.org/ticket/3515 

Nice and thanks.

> For this issue covoar is required.
> 
> So I cloned https://git.rtems.org/rtems-tools/ 
> 
> This is my directory structure:
> $HOME/quick-start/src/rtems - Main RTEMS repo
> $HOME/quick-start/src/rsb - Source Builder
> $HOME/quick-start/src/rtems-tools - The one that I have recently cloned
> 
> But running `rtems-test --list-bsps` inside 
> '$HOME/quick-start/src/rtems-tools'
> gives "error: RTEMS Toolkit python wrapper not found, plrease report"
> 
> Any ideas on how to resolve this error ?

What does `type rtems-test` say?

Have you built a set of sparc tools?
Have you build the leon3 BSP and all the tests?

I am not sure what happens if the `rtems-test` is run in the source tree while
picking up a version from your path. Maybe `./tester/rtems-test ...` works?

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

Re: Requirement Document generator tool

2020-01-29 Thread Chris Johns 
On 29/1/20 7:40 pm, Christian Mauderer wrote:
> On 28/01/2020 23:15, Chris Johns wrote:
>> On 28/1/20 10:22 pm, Christian Mauderer wrote:
>>> I'm quite indifferent which style we use
>>
>> But you are arguing a position, such as ...
>>
>>> but do you really think that it
>>> is a good idea to roll our own RTEMS-Python-style instead of using one
>>> of the big ones (like PEP8, Google or some other that might is a better
>>> fit for existing code). Rolling our own would lead to:
>>>
>>> 1. Long discussions about what is THE RIGHT STYLE (already started in
>>> this mail).
>>>
>>> 2. A lot of problems that there is no tool that formats or checks
>>> whether code is in THE RIGHT STYLE.
>>>
>>> 3. More discussions later because some other developer thinks that THE
>>> RIGHT STYLE is wrong.
> 
> You are right that I argue against home-grown styles. I learned that
> style discussions are quite similar to religious discussions. Everyone
> beliefs that his style is the only right one. Using a big one makes it
> simpler to avoid discussions because a lot of people know it.

And yet you inherit issues a large organisation cannot correct because
historically a style is difficult to change and they are wedged. They need to be
reviewed and evaluated.

> Please don't get me wrong: I'm OK with another style too. The relevant
> result is that we have _one_ style in RTEMS that can be automatically
> checked. 

I find it interesting this view is OK for Python and the tools and yet we do not
have automatic checking for the score's C. Or do we?

> That also will make patch review simpler because we as
> maintainers don't have to do the style review by hand.

This is often more about those coding than those reviewing.

>> I wrote the code, I know it and I need to maintain it. All I am asking is if
>> pre-qual wants rules then I suggest they find some common ground.
> 
> I agree that it is a good idea to find something that is acceptable for all.
> 
>>
>> I wonder how libbsd.py goes with these rules. Also all the wscript files 
>> which
>> are also python and also the RSB would be covered.
> 
> Most likely not well. But that's the problem: We already have a bunch of
> different styles. Let's try to agree on one before we get lots of extra
> code. A lot of pre-qualification code will be python. Therefore now is
> the best time.

You may know more than me about this. We have been given no information about
the project's plans or these tools and is becoming frustrating. Joel and I have
asked on a number occasions. The silence is testing our patience.

How about we put a python rules discussion on hold until the intentions of the
pre-qual project are presented publicly and in a manner we can all digest. I
have spent enough time and energy discussing this stuff and it is not clear to
me we are in a position to accept what is to be written.

> If I understood you correctly your main problem with both suggested ones
> (PEP8 and Google) is that multi line lists have been put together into
> one liners and dictionaries with aligned fields are not aligned anymore?

They cannot be touched ...

https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/darwin.py#n41
https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/freebsd.py#n50
https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/linux.py#n54
https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/linux.py#n104
https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/linux.py#n104
https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/options.py#n56
https://git.rtems.org/rtems-libbsd/tree/libbsd.py#n59
https://git.rtems.org/rtems-libbsd/tree/libbsd.py#n108
https://git.rtems.org/rtems-libbsd/tree/libbsd.py#n148

I could go on but I think this list should highlight the issue.

> About correct?

The lack of space around the arguments is also a change that is silly and I do
not want changed.

The biggest challenge who ever finally proposes these rules faces is the RSB. It
is very difficult to know if you have broken it. It has taken years to converge
to the level of stability we have. All changes in here would need a close review
and that something I am not excited about.

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

Re: rtems-tester lock failure

2020-01-29 Thread Chris Johns 
On 30/1/20 4:14 am, Joel Sherrill wrote:
> I have seen similar failures before but Chris and I discussed it was likely 
> related to Python 2. Using Python 3, I am getting the following error:
> 
> + /home/joel/rtems-work/rtems-tools//tester/rtems-test
> --rtems-tools=/home/joel/rtems-work/tools/5 --rtems-bsp=leon3-sis 
> --log=run.log .
> RTEMS Testing - Tester, 5 (4cb2ddc568b1)
> [  2/594] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   | sparc/leon3:
> linpack.exe
> [  1/594] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   | sparc/leon3:
> dhrystone.exe
> [  6/594] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   | sparc/leon3:
> fsdosfsformat01.exe
> [  7/594] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   | sparc/leon3:
> fsdosfsname01.exe
> [  3/594] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   | sparc/leon3:
> whetstone.exe
> [  5/594] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   | sparc/leon3:
> fsclose01.exe
> [  8/594] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   | sparc/leon3:
> fsdosfsname02.exe
> [  4/594] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   | sparc/leon3:
> fsbdpart01.exe
> error: invalid test state:
> ./sparc-rtems5/c/leon3/testsuites/fstests/fsbdpart01.exe: EXPECTED_PASS

This is the error that is causing the problem. I suspect it is related to the
patches that went in recently to change `-` to `_` in all the labels which
caused a parsing or something like that issue. I suspect we would see these
issues pop up and we are.

> Exception ignored in:  '/opt/rh/rh-python36/root/usr/lib64/python3.6/threading.py'>
> Traceback (most recent call last):
>   File "/opt/rh/rh-python36/root/usr/lib64/python3.6/threading.py", line 1294,
> in _shutdown
>     t.join()
>   File "/opt/rh/rh-python36/root/usr/lib64/python3.6/threading.py", line 1056,
> in join
>     self._wait_for_tstate_lock()
>   File "/opt/rh/rh-python36/root/usr/lib64/python3.6/threading.py", line 1072,
> in _wait_for_tstate_lock
>     elif lock.acquire(block, timeout):

This is in the thread shutdown. I am not sure what is wrong here.

> Hopefully someone can reproduce this.

It should be with a hack. Start a bunch of simulation jobs then raise a general
error exception.

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

Re: "atsamv" BSP legacy network driver status

2020-01-29 Thread dufault 



> On Jan 29, 2020, at 08:12 , Christian Mauderer 
>  wrote:
> 
> On 29/01/2020 13:15, dufa...@hda.com wrote:
>> 
>>> On Jan 29, 2020, at 03:13 , Christian Mauderer 
>>>  wrote:
>>> 
>>> Hello Peter,
>>> 
>>> On 28/01/2020 22:37, dufa...@hda.com wrote:
 
> On Jan 28, 2020, at 04:46 , Christian Mauderer 
>  wrote:
> 
> Before our customers migrated to libbsd (to get some of the features
> there) the driver in legacy worked. But that is a few years back.
> Currently I only know of applications using the libbsd driver.
> 
 
 How are you linking the libbsd code?  Where do you run the code from?
>>> 
>>> May I start with a counter-question? Are you using an evaluation board
>>> or some custom one? Which chip variant are you using? All projects that
>>> I have been involved used one of the bigger chips (SAME70 or SAMV71).
>> 
>> I put the BSP configuration in the original posting but I clipped it out, I 
>> tend to like to clip.  It's the SAMV71 "Xplained" Ultra.
>> 
> 
> No problem. Just missed that in the first message. So it's one of the
> bigger chips too.
> 
>>> 
 
 The application I'm testing doesn't fit in the internal SRAM provided by 
 the default "linkcmds" in the libbsd case, partly because libbsd is bigger 
 and partly because when I build for "libbsd" it needs "libblock".
 
>>> That depends on the project. One project where I can give you quite open
>>> information is GRiSP. That project is an evaluation platform for using
>>> Erlang on RTEMS. We did most of the initial the RTEMS stuff for it. You
>>> can find the basic RTEMS software here:
>>> 
>>> https://github.com/grisp/grisp-software
>>> 
>>> In this project we have a bootloader in the internal flash with some
>>> stuff in an SDRAM. See the linker command file for that:
>>> 
>>> https://github.com/grisp/grisp-software/blob/master/grisp-bootloader/linkcmds.bootloader
>>> 
>>> The bootloader doesn't have network support (I removed quite some bits
>>> with the "slim-down.h" file) but it uses libbsd for the SD card. It then
>>> starts a bigger RTEMS application from the SD card. That application
>>> uses libbsd for USB and WLAN. The application uses linkcmds.sdram from
>>> RTEMS.
>>> 
 It fits if I use "linkcmds.sdram", but then I can't run it because the 
 SDRAM must not be set up properly at reset, I guess I'd need to come up 
 with something using "openocd" that will set up the SDRAM before starting 
 the program.
 
 I then tried putting just REGION_START in internal flash but it fails when 
 it jump through a trampoline to "system_init_flash" which was still in the 
 SDRAM.
 
 Then I tried using "linkcmds.qspiflash" but the program didn't fit again 
 since more space was required in the internal SRAM.
 
>>> 
>>> We have another project where QSPI is used. I can't give you all details
>>> but some basic information are possible:
>>> 
>>> 

(...)

>>> 
 
>> This will help a lot.
>> 
>> Is the bootloader for the second project the same as the one in "grisp" but 
>> not slimmed down?
> 
> No. It's a different one because there is a completely different boot
> concept. On GRiSP the boot is done from a SD card. For this customer the
> bootloader can update the program in the XIP area and start it from there.
> 
> Let me know if I can help you with more information.
> 
> Best regards
> 
> Christian
> 


I thought I'd found an easy way to continue by just putting REGION_WORK in 
SDRAM.  That region isn't used until after the SDRAM is initialized.  It freed 
up lots of internal SRAM memory when not using "libbsd".

Unfortunately it still overflows internal SRAM (INTSRAM) when using "libbsd".
I'm assuming that there isn't anything else assigned to INTSRAM that can easily 
be moved to SDRAM where the SDRAM won't be used until after initialization.  Is 
that correct?

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.

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

PC386 BSP Serial Console Problems

2020-01-29 Thread Lou Woods 
Hello all,

I've been working on getting an old PC based SBC (Winsystems EBC-855) up and 
running in our RTEMS lab and I'm having a problem getting the serial console to 
work.  The VGA console is works, however when the executable is started with 
the -console=/dev/com1 command line argument the output to COM1 is 
unprintable/incorrect characters AKA garbage.  The serial output looks like a 
baud rate mismatch.  It is almost like baud rate is just a little off.  
Unfortunately, I don't have the means to measure the actual baud rate.

Has anyone done this recently?

I'm using the latest RTEMS head, pc386 BSP, and ticker test.  I've been testing 
this configuration by chain loading TFTP via IPXE which seems to work well.  In 
order to verify my end to end configuration works, I also tested this on a Dell 
Optiplex 755 Intel Core 2 Duo computer.  With this configuration I was able 
verify the same serial corruption exists on this computer under RTEMS and I was 
able to demonstrate that while running Windows I could use the same serial 
port, cabling, baud rates and serial host computer for serial communications.

The BSP is configured to use 9600bps 8-N-1 with no flow control by default.
Here is how RTEMS is configured:
../rtems/configure --target=i386-rtems5 --enable-rtemsbsp=pc386 
IDE_USE_PRIMARY_INTERFACE=0 --prefix=/home/woods/pc386/bsp-install/ 
--disable-networking --enable-posix --disable-smp --disable-multiprocessing 
--enable-tests --enable-cxx --enable-maintainer-mode

The serial host is a Raspberry Pi 3 running Debian (Raspian) Stretch.

These are the things I've tried, not in combination:
- sweeping the baud rate on the serial host while holding the board at 9600 8N1
- trying different baud rates in lock-step board and serial host.
- various combination of hardware flow control, parity, word size, stop bits.
- Winsystems board talking to a Windows PC running Foxterm.
- Running RTEMS 4.11 branch with current i386 toolschain - exe hangs, haven't 
tracked down error yet.
- COM2 port on the Winsystems board.
- Changing the clock rate for the baud-rate divisor in RTEMS
- 3 wire serial communications with RX, TX, and GND

Does anyone have any ideas?  I will open a ticket on this as well.

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

rtems-tester lock failure

2020-01-29 Thread Joel Sherrill 
Hi

I have seen similar failures before but Chris and I discussed it was likely
related to Python 2. Using Python 3, I am getting the following error:

+ /home/joel/rtems-work/rtems-tools//tester/rtems-test
--rtems-tools=/home/joel/rtems-work/tools/5 --rtems-bsp=leon3-sis
--log=run.log .
RTEMS Testing - Tester, 5 (4cb2ddc568b1)
[  2/594] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   |
sparc/leon3: linpack.exe
[  1/594] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   |
sparc/leon3: dhrystone.exe
[  6/594] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   |
sparc/leon3: fsdosfsformat01.exe
[  7/594] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   |
sparc/leon3: fsdosfsname01.exe
[  3/594] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   |
sparc/leon3: whetstone.exe
[  5/594] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   |
sparc/leon3: fsclose01.exe
[  8/594] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   |
sparc/leon3: fsdosfsname02.exe
[  4/594] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   |
sparc/leon3: fsbdpart01.exe
error: invalid test state:
./sparc-rtems5/c/leon3/testsuites/fstests/fsbdpart01.exe: EXPECTED_PASS
Exception ignored in: 
Traceback (most recent call last):
  File "/opt/rh/rh-python36/root/usr/lib64/python3.6/threading.py", line
1294, in _shutdown
t.join()
  File "/opt/rh/rh-python36/root/usr/lib64/python3.6/threading.py", line
1056, in join
self._wait_for_tstate_lock()
  File "/opt/rh/rh-python36/root/usr/lib64/python3.6/threading.py", line
1072, in _wait_for_tstate_lock
elif lock.acquire(block, timeout):

Hopefully someone can reproduce this.

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

Re: "atsamv" BSP legacy network driver status

2020-01-29 Thread Christian Mauderer 
On 29/01/2020 13:15, dufa...@hda.com wrote:
> 
>> On Jan 29, 2020, at 03:13 , Christian Mauderer 
>>  wrote:
>>
>> Hello Peter,
>>
>> On 28/01/2020 22:37, dufa...@hda.com wrote:
>>>
 On Jan 28, 2020, at 04:46 , Christian Mauderer 
  wrote:

 Before our customers migrated to libbsd (to get some of the features
 there) the driver in legacy worked. But that is a few years back.
 Currently I only know of applications using the libbsd driver.

>>>
>>> How are you linking the libbsd code?  Where do you run the code from?
>>
>> May I start with a counter-question? Are you using an evaluation board
>> or some custom one? Which chip variant are you using? All projects that
>> I have been involved used one of the bigger chips (SAME70 or SAMV71).
> 
> I put the BSP configuration in the original posting but I clipped it out, I 
> tend to like to clip.  It's the SAMV71 "Xplained" Ultra.
> 

No problem. Just missed that in the first message. So it's one of the
bigger chips too.

>>
>>>
>>> The application I'm testing doesn't fit in the internal SRAM provided by 
>>> the default "linkcmds" in the libbsd case, partly because libbsd is bigger 
>>> and partly because when I build for "libbsd" it needs "libblock".
>>>
>> That depends on the project. One project where I can give you quite open
>> information is GRiSP. That project is an evaluation platform for using
>> Erlang on RTEMS. We did most of the initial the RTEMS stuff for it. You
>> can find the basic RTEMS software here:
>>
>> https://github.com/grisp/grisp-software
>>
>> In this project we have a bootloader in the internal flash with some
>> stuff in an SDRAM. See the linker command file for that:
>>
>> https://github.com/grisp/grisp-software/blob/master/grisp-bootloader/linkcmds.bootloader
>>
>> The bootloader doesn't have network support (I removed quite some bits
>> with the "slim-down.h" file) but it uses libbsd for the SD card. It then
>> starts a bigger RTEMS application from the SD card. That application
>> uses libbsd for USB and WLAN. The application uses linkcmds.sdram from
>> RTEMS.
>>
>>> It fits if I use "linkcmds.sdram", but then I can't run it because the 
>>> SDRAM must not be set up properly at reset, I guess I'd need to come up 
>>> with something using "openocd" that will set up the SDRAM before starting 
>>> the program.
>>>
>>> I then tried putting just REGION_START in internal flash but it fails when 
>>> it jump through a trampoline to "system_init_flash" which was still in the 
>>> SDRAM.
>>>
>>> Then I tried using "linkcmds.qspiflash" but the program didn't fit again 
>>> since more space was required in the internal SRAM.
>>>
>>
>> We have another project where QSPI is used. I can't give you all details
>> but some basic information are possible:
>>
>> This project starts a Bootloader from the internal flash. The bootloader
>> would then start an application from QSPI XIP area. But it can also use
>> libbsd for networking. The linkcmds for the bootloader look like follows:
>>
>> 
>> INCLUDE linkcmds.memory
>>
>> REGION_ALIAS ("REGION_START", INTFLASH);
>> REGION_ALIAS ("REGION_VECTOR", INTSRAM);
>> REGION_ALIAS ("REGION_TEXT", INTFLASH);
>> REGION_ALIAS ("REGION_TEXT_LOAD", INTFLASH);
>> REGION_ALIAS ("REGION_RODATA", INTFLASH);
>> REGION_ALIAS ("REGION_RODATA_LOAD", INTFLASH);
>> REGION_ALIAS ("REGION_DATA", SDRAM);
>> REGION_ALIAS ("REGION_DATA_LOAD", INTFLASH);
>> REGION_ALIAS ("REGION_FAST_TEXT", ITCM);
>> REGION_ALIAS ("REGION_FAST_TEXT_LOAD", INTFLASH);
>> REGION_ALIAS ("REGION_FAST_DATA", DTCM);
>> REGION_ALIAS ("REGION_FAST_DATA_LOAD", INTFLASH);
>> REGION_ALIAS ("REGION_BSS", SDRAM);
>> REGION_ALIAS ("REGION_WORK", SDRAM);
>> REGION_ALIAS ("REGION_STACK", SDRAM);
>> REGION_ALIAS ("REGION_NOCACHE", NOCACHE);
>> REGION_ALIAS ("REGION_NOCACHE_LOAD", INTFLASH);
>>
>> INCLUDE linkcmds.armv7m
>> 
>>
>> For the application that is put into QSPIFLASH it's the following:
>>
>> 
>> INCLUDE linkcmds.memory
>>
>> REGION_ALIAS ("REGION_START", QSPIFLASH);
>> REGION_ALIAS ("REGION_VECTOR", INTSRAM);
>> REGION_ALIAS ("REGION_TEXT", QSPIFLASH);
>> REGION_ALIAS ("REGION_TEXT_LOAD", QSPIFLASH);
>> REGION_ALIAS ("REGION_RODATA", QSPIFLASH);
>> REGION_ALIAS ("REGION_RODATA_LOAD", QSPIFLASH);
>> REGION_ALIAS ("REGION_DATA", SDRAM);
>> REGION_ALIAS ("REGION_DATA_LOAD", QSPIFLASH);
>> REGION_ALIAS ("REGION_FAST_TEXT", ITCM);
>> REGION_ALIAS ("REGION_FAST_TEXT_LOAD", QSPIFLASH);
>> REGION_ALIAS ("REGION_FAST_DATA", DTCM);
>> REGION_ALIAS ("REGION_FAST_DATA_LOAD", QSPIFLASH);
>> REGION_ALIAS ("REGION_BSS", SDRAM);
>> REGION_ALIAS ("REGION_WORK", SDRAM);
>> REGION_ALIAS ("REGION_STACK", SDRAM);
>> REGION_ALIAS ("REGION_NOCACHE", NOCACHE);
>> REGION_ALIAS ("REGION_NOCACHE_LOAD", SDRAM);
>>
>> INCLUDE linkcmds.armv7m
>> 
>>
>> I hope that helps.
>>
>> Best regards
>>
>> Christian
>>
>>>
> This will help a lot.
> 
> Is the bootloader for the second project the same as the one in "grisp" but 
> not

Re: "atsamv" BSP legacy network driver status

2020-01-29 Thread dufault 


> On Jan 29, 2020, at 03:13 , Christian Mauderer 
>  wrote:
> 
> Hello Peter,
> 
> On 28/01/2020 22:37, dufa...@hda.com wrote:
>> 
>>> On Jan 28, 2020, at 04:46 , Christian Mauderer 
>>>  wrote:
>>> 
>>> Before our customers migrated to libbsd (to get some of the features
>>> there) the driver in legacy worked. But that is a few years back.
>>> Currently I only know of applications using the libbsd driver.
>>> 
>> 
>> How are you linking the libbsd code?  Where do you run the code from?
> 
> May I start with a counter-question? Are you using an evaluation board
> or some custom one? Which chip variant are you using? All projects that
> I have been involved used one of the bigger chips (SAME70 or SAMV71).

I put the BSP configuration in the original posting but I clipped it out, I 
tend to like to clip.  It's the SAMV71 "Xplained" Ultra.

> 
>> 
>> The application I'm testing doesn't fit in the internal SRAM provided by the 
>> default "linkcmds" in the libbsd case, partly because libbsd is bigger and 
>> partly because when I build for "libbsd" it needs "libblock".
>> 
> That depends on the project. One project where I can give you quite open
> information is GRiSP. That project is an evaluation platform for using
> Erlang on RTEMS. We did most of the initial the RTEMS stuff for it. You
> can find the basic RTEMS software here:
> 
> https://github.com/grisp/grisp-software
> 
> In this project we have a bootloader in the internal flash with some
> stuff in an SDRAM. See the linker command file for that:
> 
> https://github.com/grisp/grisp-software/blob/master/grisp-bootloader/linkcmds.bootloader
> 
> The bootloader doesn't have network support (I removed quite some bits
> with the "slim-down.h" file) but it uses libbsd for the SD card. It then
> starts a bigger RTEMS application from the SD card. That application
> uses libbsd for USB and WLAN. The application uses linkcmds.sdram from
> RTEMS.
> 
>> It fits if I use "linkcmds.sdram", but then I can't run it because the SDRAM 
>> must not be set up properly at reset, I guess I'd need to come up with 
>> something using "openocd" that will set up the SDRAM before starting the 
>> program.
>> 
>> I then tried putting just REGION_START in internal flash but it fails when 
>> it jump through a trampoline to "system_init_flash" which was still in the 
>> SDRAM.
>> 
>> Then I tried using "linkcmds.qspiflash" but the program didn't fit again 
>> since more space was required in the internal SRAM.
>> 
> 
> We have another project where QSPI is used. I can't give you all details
> but some basic information are possible:
> 
> This project starts a Bootloader from the internal flash. The bootloader
> would then start an application from QSPI XIP area. But it can also use
> libbsd for networking. The linkcmds for the bootloader look like follows:
> 
> 
> INCLUDE linkcmds.memory
> 
> REGION_ALIAS ("REGION_START", INTFLASH);
> REGION_ALIAS ("REGION_VECTOR", INTSRAM);
> REGION_ALIAS ("REGION_TEXT", INTFLASH);
> REGION_ALIAS ("REGION_TEXT_LOAD", INTFLASH);
> REGION_ALIAS ("REGION_RODATA", INTFLASH);
> REGION_ALIAS ("REGION_RODATA_LOAD", INTFLASH);
> REGION_ALIAS ("REGION_DATA", SDRAM);
> REGION_ALIAS ("REGION_DATA_LOAD", INTFLASH);
> REGION_ALIAS ("REGION_FAST_TEXT", ITCM);
> REGION_ALIAS ("REGION_FAST_TEXT_LOAD", INTFLASH);
> REGION_ALIAS ("REGION_FAST_DATA", DTCM);
> REGION_ALIAS ("REGION_FAST_DATA_LOAD", INTFLASH);
> REGION_ALIAS ("REGION_BSS", SDRAM);
> REGION_ALIAS ("REGION_WORK", SDRAM);
> REGION_ALIAS ("REGION_STACK", SDRAM);
> REGION_ALIAS ("REGION_NOCACHE", NOCACHE);
> REGION_ALIAS ("REGION_NOCACHE_LOAD", INTFLASH);
> 
> INCLUDE linkcmds.armv7m
> 
> 
> For the application that is put into QSPIFLASH it's the following:
> 
> 
> INCLUDE linkcmds.memory
> 
> REGION_ALIAS ("REGION_START", QSPIFLASH);
> REGION_ALIAS ("REGION_VECTOR", INTSRAM);
> REGION_ALIAS ("REGION_TEXT", QSPIFLASH);
> REGION_ALIAS ("REGION_TEXT_LOAD", QSPIFLASH);
> REGION_ALIAS ("REGION_RODATA", QSPIFLASH);
> REGION_ALIAS ("REGION_RODATA_LOAD", QSPIFLASH);
> REGION_ALIAS ("REGION_DATA", SDRAM);
> REGION_ALIAS ("REGION_DATA_LOAD", QSPIFLASH);
> REGION_ALIAS ("REGION_FAST_TEXT", ITCM);
> REGION_ALIAS ("REGION_FAST_TEXT_LOAD", QSPIFLASH);
> REGION_ALIAS ("REGION_FAST_DATA", DTCM);
> REGION_ALIAS ("REGION_FAST_DATA_LOAD", QSPIFLASH);
> REGION_ALIAS ("REGION_BSS", SDRAM);
> REGION_ALIAS ("REGION_WORK", SDRAM);
> REGION_ALIAS ("REGION_STACK", SDRAM);
> REGION_ALIAS ("REGION_NOCACHE", NOCACHE);
> REGION_ALIAS ("REGION_NOCACHE_LOAD", SDRAM);
> 
> INCLUDE linkcmds.armv7m
> 
> 
> I hope that helps.
> 
> Best regards
> 
> Christian
> 
>> 
This will help a lot.

Is the bootloader for the second project the same as the one in "grisp" but not 
slimmed down?

Thanks.  I should have sent this to "-users", maybe I'll post a summary there 
when done.

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

This email is delivered through the

Re: Requirement Document generator tool

2020-01-29 Thread Christian Mauderer 
On 28/01/2020 23:15, Chris Johns wrote:
> On 28/1/20 10:22 pm, Christian Mauderer wrote:
>> I'm quite indifferent which style we use
> 
> But you are arguing a position, such as ...
> 
>> but do you really think that it
>> is a good idea to roll our own RTEMS-Python-style instead of using one
>> of the big ones (like PEP8, Google or some other that might is a better
>> fit for existing code). Rolling our own would lead to:
>>
>> 1. Long discussions about what is THE RIGHT STYLE (already started in
>> this mail).
>>
>> 2. A lot of problems that there is no tool that formats or checks
>> whether code is in THE RIGHT STYLE.
>>
>> 3. More discussions later because some other developer thinks that THE
>> RIGHT STYLE is wrong.

You are right that I argue against home-grown styles. I learned that
style discussions are quite similar to religious discussions. Everyone
beliefs that his style is the only right one. Using a big one makes it
simpler to avoid discussions because a lot of people know it.

Please don't get me wrong: I'm OK with another style too. The relevant
result is that we have _one_ style in RTEMS that can be automatically
checked. That also will make patch review simpler because we as
maintainers don't have to do the style review by hand.

> 
> I wrote the code, I know it and I need to maintain it. All I am asking is if
> pre-qual wants rules then I suggest they find some common ground.

I agree that it is a good idea to find something that is acceptable for all.

> 
> I wonder how libbsd.py goes with these rules. Also all the wscript files which
> are also python and also the RSB would be covered.

Most likely not well. But that's the problem: We already have a bunch of
different styles. Let's try to agree on one before we get lots of extra
code. A lot of pre-qualification code will be python. Therefore now is
the best time.

If I understood you correctly your main problem with both suggested ones
(PEP8 and Google) is that multi line lists have been put together into
one liners and dictionaries with aligned fields are not aligned anymore?
About correct?

Best regards

Christian

> 
> Chris
> 

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Requirement Document generator tool

2020-01-29 Thread Christian Mauderer 
On 28/01/2020 23:15, Joel Sherrill wrote:
> 
> 
> On Tue, Jan 28, 2020, 5:22 AM Christian Mauderer
>  > wrote:
> 
> On 28/01/2020 11:41, Chris Johns wrote:
> >
> >
> > On 28/1/20 8:14 pm, Christian Mauderer wrote:
> >> On 28/01/2020 01:42, Chris Johns wrote:
> >>> On 28/1/20 10:48 am, Joel Sherrill wrote:
>  On Mon, Jan 27, 2020 at 4:18 PM Chris Johns  
>  >> wrote:
> 
>      On 24/1/20 9:57 pm, Jose Valdez wrote:
>      > In fact these tools target the pre-qualified project.
> 
>      Do you see this as different to the RTEMS project?
> 
>      > Since it was Sebastian who suggested to create this set
> of python tools,
> 
>      I think Sebastian is wanting a smooth path for these tools
> into the project.
> 
>      > I think the idea was to standardize the use of python not
> only for this
>      project, but also for other python written code in RTEMS
> community. This has
>      the advantages that every written python code is standard,
> but has the
>      drawbacks:
>      >
>      > -> old written code would need to be adapted to the
> standards.
> 
>      How different to the proposed coding standard is the
> existing code? Why not base
>      the coding standard on what exists in the code base?
> 
>  This is a very important question.
> 
>      Have you evaluated the size of the task to update the
> existing code? How would
>      get such changes for the rtems-tools and the RSB be tested
> and integrated back
>      into the project? This apporach seems like a huge review
> task for me.
> 
>  It could be or it may turn out that there isn't much changed.
> Without someone
>  running the reformatter and reporting, we won't know.
> >>>
> >>> Running a reformatter may give you an idea of the scale however
> I have some
> >>> concerns as Python's logic is based on indent levels and a
> missed level changes
> >>> the logic. I am not sure how you know such a tool is safe to use
> unless you
> >>> review all the changes.
> >>
> >> To get some statistics for that I tried using yapf on the rtems-tools
> >> repo. I excluded everything with  "patch-gdb-python", "tftpy" and
> >> "asciidoc" in the name. You can see the yapf call in the commit
> message.
> >
> > The doxygen is from waf. Thomas knows how to write python.
> 
> OK. I missed that one. The patches were just a test to get some
> orientation about what it would mean.
> 
> Please also note: I don't want to doubt the python knowledge of anyone.
> 
> >
> >> Google style:
> >>
> 
> https://gist.githubusercontent.com/c-mauderer/18746eaa8f3a077adddfe35c1f7b5194/raw/f8202a53ca043d23732d79ab217071e975dc35ad/0001-FIXME-Format-in-Google-style.patch
> >>
> >> PEP8 Style:
> >>
> 
> https://gist.githubusercontent.com/c-mauderer/18746eaa8f3a077adddfe35c1f7b5194/raw/c97c77762f65041d9244bc8bc64b90ec698735bf/0001-FIXME-Reformat-using-PEP8.patch
> >>
> >> In both cases it's about 3000 lines removed and 3700 lines added.
> 
> 
> Is it possible to make changes we think are ok and in both styles? That
> would start to whittle down the style issues 
> 
> 
> >>
> >> Without having a look at each line: Most seems to be just the normal
> >> formatting stuff. Some lines are too long. Some spaces missing around
> >> operators or spaces where they shouldn't be.
> >
> > And then there is removal of spaces on default args ...
> >
> > -    def section_macro_map(self, section, nesting_level = 0):
> > +    def section_macro_map(self, section, nesting_level=0):
> >
> > I prefer spaces as it is consistent with other uses of spaces
> around operators.
> 
> In my view these are detail style discussions. Same is true for most of
> your notes further below (although I agree with some of your opinions).
> But I didn't wanted to trigger any of these. My intention was to give
> some impression about how big such changes would be.
> 
> I know that there is quite some python code already in RTEMS. And I'm
> also sure that there are already quite some different python styles in
> RTEMS. At least as many as programmers touching python code. But
> currently the python code is still few enough that it would be possible
> to get a uniform style. And pre-qualification or not: I'm really
> convinced that a fixed style would be a good thing for the code base in
> general.
> 
> I'm quite indifferent which style we use but do you really think that it
> is a good idea to

Re: "atsamv" BSP legacy network driver status

2020-01-29 Thread Christian Mauderer 
Hello Peter,

On 28/01/2020 22:37, dufa...@hda.com wrote:
> 
>> On Jan 28, 2020, at 04:46 , Christian Mauderer 
>>  wrote:
>>
>> Before our customers migrated to libbsd (to get some of the features
>> there) the driver in legacy worked. But that is a few years back.
>> Currently I only know of applications using the libbsd driver.
>>
> 
> How are you linking the libbsd code?  Where do you run the code from?

May I start with a counter-question? Are you using an evaluation board
or some custom one? Which chip variant are you using? All projects that
I have been involved used one of the bigger chips (SAME70 or SAMV71).

> 
> The application I'm testing doesn't fit in the internal SRAM provided by the 
> default "linkcmds" in the libbsd case, partly because libbsd is bigger and 
> partly because when I build for "libbsd" it needs "libblock".
>
That depends on the project. One project where I can give you quite open
information is GRiSP. That project is an evaluation platform for using
Erlang on RTEMS. We did most of the initial the RTEMS stuff for it. You
can find the basic RTEMS software here:

https://github.com/grisp/grisp-software

In this project we have a bootloader in the internal flash with some
stuff in an SDRAM. See the linker command file for that:

https://github.com/grisp/grisp-software/blob/master/grisp-bootloader/linkcmds.bootloader

The bootloader doesn't have network support (I removed quite some bits
with the "slim-down.h" file) but it uses libbsd for the SD card. It then
starts a bigger RTEMS application from the SD card. That application
uses libbsd for USB and WLAN. The application uses linkcmds.sdram from
RTEMS.

> It fits if I use "linkcmds.sdram", but then I can't run it because the SDRAM 
> must not be set up properly at reset, I guess I'd need to come up with 
> something using "openocd" that will set up the SDRAM before starting the 
> program.
> 
> I then tried putting just REGION_START in internal flash but it fails when it 
> jump through a trampoline to "system_init_flash" which was still in the SDRAM.
> 
> Then I tried using "linkcmds.qspiflash" but the program didn't fit again 
> since more space was required in the internal SRAM.
> 

We have another project where QSPI is used. I can't give you all details
but some basic information are possible:

This project starts a Bootloader from the internal flash. The bootloader
would then start an application from QSPI XIP area. But it can also use
libbsd for networking. The linkcmds for the bootloader look like follows:


INCLUDE linkcmds.memory

REGION_ALIAS ("REGION_START", INTFLASH);
REGION_ALIAS ("REGION_VECTOR", INTSRAM);
REGION_ALIAS ("REGION_TEXT", INTFLASH);
REGION_ALIAS ("REGION_TEXT_LOAD", INTFLASH);
REGION_ALIAS ("REGION_RODATA", INTFLASH);
REGION_ALIAS ("REGION_RODATA_LOAD", INTFLASH);
REGION_ALIAS ("REGION_DATA", SDRAM);
REGION_ALIAS ("REGION_DATA_LOAD", INTFLASH);
REGION_ALIAS ("REGION_FAST_TEXT", ITCM);
REGION_ALIAS ("REGION_FAST_TEXT_LOAD", INTFLASH);
REGION_ALIAS ("REGION_FAST_DATA", DTCM);
REGION_ALIAS ("REGION_FAST_DATA_LOAD", INTFLASH);
REGION_ALIAS ("REGION_BSS", SDRAM);
REGION_ALIAS ("REGION_WORK", SDRAM);
REGION_ALIAS ("REGION_STACK", SDRAM);
REGION_ALIAS ("REGION_NOCACHE", NOCACHE);
REGION_ALIAS ("REGION_NOCACHE_LOAD", INTFLASH);

INCLUDE linkcmds.armv7m


For the application that is put into QSPIFLASH it's the following:


INCLUDE linkcmds.memory

REGION_ALIAS ("REGION_START", QSPIFLASH);
REGION_ALIAS ("REGION_VECTOR", INTSRAM);
REGION_ALIAS ("REGION_TEXT", QSPIFLASH);
REGION_ALIAS ("REGION_TEXT_LOAD", QSPIFLASH);
REGION_ALIAS ("REGION_RODATA", QSPIFLASH);
REGION_ALIAS ("REGION_RODATA_LOAD", QSPIFLASH);
REGION_ALIAS ("REGION_DATA", SDRAM);
REGION_ALIAS ("REGION_DATA_LOAD", QSPIFLASH);
REGION_ALIAS ("REGION_FAST_TEXT", ITCM);
REGION_ALIAS ("REGION_FAST_TEXT_LOAD", QSPIFLASH);
REGION_ALIAS ("REGION_FAST_DATA", DTCM);
REGION_ALIAS ("REGION_FAST_DATA_LOAD", QSPIFLASH);
REGION_ALIAS ("REGION_BSS", SDRAM);
REGION_ALIAS ("REGION_WORK", SDRAM);
REGION_ALIAS ("REGION_STACK", SDRAM);
REGION_ALIAS ("REGION_NOCACHE", NOCACHE);
REGION_ALIAS ("REGION_NOCACHE_LOAD", SDRAM);

INCLUDE linkcmds.armv7m


I hope that helps.

Best regards

Christian

> I need to:
> - reduce the size by figuring out how to get rid of "libblock" (it isn't 
> needed in the non libbsd case);
> - figure out how to set things up so that "openocd" works using the SDRAM;
> - or relocate everything needed prior to initializing SDRAM to be in the 
> internal flash.
>  
> This is still an evaluation so I only want to see it run.
> 
> 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.
> 

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de

Ticket #3515

2020-01-29 Thread Bran S 
Hi Guys,

I am trying to solve #3515
https://devel.rtems.org/ticket/3515
For this issue covoar is required.

So I cloned https://git.rtems.org/rtems-tools/
This is my directory structure:
$HOME/quick-start/src/rtems - Main RTEMS repo
$HOME/quick-start/src/rsb - Source Builder
$HOME/quick-start/src/rtems-tools - The one that I have recently cloned

But running `rtems-test --list-bsps` inside '$HOME/quick-start/src/rtems-
tools'
gives "error: RTEMS Toolkit python wrapper not found, plrease report"

Any ideas on how to resolve this error ?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel