Re: Requirement Document generator tool

[Christian Mauderer]

On 29/01/2020 23:48, Chris Johns wrote:
> 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.

That's why I originally thought of defining a style for _new_ code with
an optional _slow_ migration if some existing code is touched. Of course
the style should be compatible with the views how the old code should
look in the future too. The patches were just for an estimate how much
influence the suggested styles could have. I would never expect that any
big patch with automated changes would be acceptable without a thorough
review. I wouldn't accept that myself.

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

It would be great if we would have automatic checking for C too. There
are big projects that have something like that and it's really
convenient. For example for Linux before you send a patch you can just
run "./scripts/checkpatch.pl some.patch" and it will give you everything
you should fix before sending it to the list. That removes at least one
round of review.

But I think implementing that would be a lot bigger task than the one we
are just discussing. One of the first problems would be finding a style
checker that can produce _exactly_ the coding style that is defined for
score. And also I'm happy to discuss approaches for something like that
it would start to be of-topic for this thread. So if you want to discuss
details about automatic style checking for score we should create an
extra topic. Maybe we could even create a GSoC project for something
like that?

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

Sorry, I think I don't fully understand you here.

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

I'm really sorry for that. Like I mentioned earlier I'm not really very
good with the overview over this project too. I'll try to discuss this
with Sebastian and Thomas as soon as Sebastian is back from vacation.

> 
> 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 you want to stop the discussion, I have to accept that. Please just
answer with "this needs further discussion but not now" for all parts
where you think we should stop right now.

But please note that our current discussion is in my opinion more of a
basic discussion that is only triggered by the pre-qualification
efforts. It's not really relevant whether new tools are added b

Re: [PATCH 0/2] Add new Xen BSP target using GICv3 driver

[Jeff Kubascik]

On 1/28/2020 12:02 PM, Joel Sherrill wrote:
> 
> I have merged all of Jeff's patches.  Please check that they work as merged
> and do not introduce warnings.
> 
> Thanks.
> 
> --joel
> 
> On Thu, Jan 23, 2020 at 10:04 AM Jeff Kubascik  > wrote:
> 
> This patch set renames the "xen_virtual" target to "xen_gicv2", and adds 
> a new
> "xen_gicv3" target that uses the GICv3 driver. This is the only hardware
> dependency I have identified that a RTEMS virtual machine has with Xen on 
> ARMv8.
> 
> The "xen_gicv3" target has been confirmed to work with Xen and ARMv8 
> QEMU. This
> required 3 patches to QEMU, which have been submitted to QEMU devel. As 
> of now,
> all 3 patches were accepted into master.
> 
> Jeff Kubascik (2):
>   bsp/xen: Rename xen_virtual target to xen_gicv2
>   bsp/xen: Add xen_gicv3 target
> 
>  .../xen/config/{xen_virtual.cfg => xen_gicv2.cfg}  |  2 +-
>  bsps/arm/xen/config/xen_gicv3.cfg                  | 14 ++
>  bsps/arm/xen/include/bsp.h                         | 10 ++
>  bsps/arm/xen/start/bspstartmmu.c                   | 14 ++
>  c/src/lib/libbsp/arm/xen/Makefile.am               |  5 +
>  c/src/lib/libbsp/arm/xen/configure.ac               
> |
> 10 ++
>  6 files changed, 54 insertions(+), 1 deletion(-)
>  rename bsps/arm/xen/config/{xen_virtual.cfg => xen_gicv2.cfg} (82%)
>  create mode 100644 bsps/arm/xen/config/xen_gicv3.cfg
> 
> -- 
> 2.17.1
> 
> ___
> devel mailing list
> devel@rtems.org 
> http://lists.rtems.org/mailman/listinfo/devel
> 

Thanks Joel! I've tested the build using your rtems repo and the xen_gicv3 build
still works. I've also compared the build output before/after the changes could
not identify any new warnings.

Sincerely,
Jeff Kubascik
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 0/2] Add new Xen BSP target using GICv3 driver

[Joel Sherrill]

On Thu, Jan 30, 2020, 9:10 AM Jeff Kubascik 
wrote:

> On 1/28/2020 12:02 PM, Joel Sherrill wrote:
> >
> > I have merged all of Jeff's patches.  Please check that they work as
> merged
> > and do not introduce warnings.
> >
> > Thanks.
> >
> > --joel
> >
> > On Thu, Jan 23, 2020 at 10:04 AM Jeff Kubascik <
> jeff.kubas...@dornerworks.com
> > > wrote:
> >
> > This patch set renames the "xen_virtual" target to "xen_gicv2", and
> adds a new
> > "xen_gicv3" target that uses the GICv3 driver. This is the only
> hardware
> > dependency I have identified that a RTEMS virtual machine has with
> Xen on ARMv8.
> >
> > The "xen_gicv3" target has been confirmed to work with Xen and ARMv8
> QEMU. This
> > required 3 patches to QEMU, which have been submitted to QEMU devel.
> As of now,
> > all 3 patches were accepted into master.
> >
> > Jeff Kubascik (2):
> >   bsp/xen: Rename xen_virtual target to xen_gicv2
> >   bsp/xen: Add xen_gicv3 target
> >
> >  .../xen/config/{xen_virtual.cfg => xen_gicv2.cfg}  |  2 +-
> >  bsps/arm/xen/config/xen_gicv3.cfg  | 14
> ++
> >  bsps/arm/xen/include/bsp.h | 10 ++
> >  bsps/arm/xen/start/bspstartmmu.c   | 14
> ++
> >  c/src/lib/libbsp/arm/xen/Makefile.am   |  5 +
> >  c/src/lib/libbsp/arm/xen/configure.ac 
>   |
> > 10 ++
> >  6 files changed, 54 insertions(+), 1 deletion(-)
> >  rename bsps/arm/xen/config/{xen_virtual.cfg => xen_gicv2.cfg} (82%)
> >  create mode 100644 bsps/arm/xen/config/xen_gicv3.cfg
> >
> > --
> > 2.17.1
> >
> > ___
> > devel mailing list
> > devel@rtems.org 
> > http://lists.rtems.org/mailman/listinfo/devel
> >
>
> Thanks Joel! I've tested the build using your rtems repo and the xen_gicv3
> build
> still works. I've also compared the build output before/after the changes
> could
> not identify any new warnings.
>

Thanks for the feedback!


> Sincerely,
> Jeff Kubascik
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: "atsamv" BSP legacy network driver status

[dufault]

> On Jan 30, 2020, at 01:24 , Christian Mauderer 
>  wrote:
> 
> 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

Is it possible that the latest "SAMV71 "Xplained" Ultra" board doesn't work? 
Details:

Putting those sections into SDRAM worked perfectly, perfectly enough to 
duplicate the problem I had with the legacy stack using the "libbsd" stack.  
The symptoms are the same:

- The network stack is initialized.
- The network stack is receiving incoming packets.
- No transmit packets are sent out.  The software is trying to send out packets 
but they never go out.

I'm looking at two of many possibilities as most likely.
1. Do I have the media setup mis-configured so it can't transmit?
-- Unlikely if that's the case since it's receiving.
-- In the case of using the "libbsd" stack I'm using "ifconfig if-atsam0 
(ip-address) netmask (netmask) media 100TX up", and it starts receiving packets 
but not sending.
2. The second possibility.  I'm looking at this now, and I'm sending the email 
so that you can tell me to stop wasting my time.

Is it possible this is related to not initializing transmit FIFOS?  My google 
searches have turned up really similar situations associated with not 
initializing registers for queues that I don't think exist.

I haven't sorted this out yet but look at:
https://www.avrfreaks.net/comment/2648206#comment-2648206
"I found the problem, at least in the ASF4 code base for Revision B chips
The Revision B chips have 6 priority transmit fifos (there is an errata 
regarding this for the Rev A chips)
Each of these fifos have to be initialized before sending can occur, Atmel 
tried to do this at the end ..."
I went to ... because it doesn't apply after this point.

The newest Microchip / Atmel support package, the one that the "atsamv" BSP is 
*not* based on (and that is totally, totally reorganized and will be difficult 
to rebase on) includes "dummy buffers for unconfigured queues".

for (i = 0; i < GMAC_QUEUE_COUNT; i++) {
gmacd_setup_queue(gmacd, i,
DUMMY_BUFFERS, dummy_buffer, dummy_rx_desc,
DUMMY_BUFFERS, dummy_buffer, dummy_tx_desc,
NULL);
}

So, as I said:

Is it possible that the latest "SAMV71 "Xplained" Ultra" board doesn't work? 

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

Errors in .tcfg Do Not Stop the Build

[Joel Sherrill]

Hi

I made a mistake in a .tcfg file (forgot to write exclude: and just listed
the test name). There was a message in the build log where the error
was reported but the build itself continued and didn't produce any
executables. The ultimate return status was 0 so we thought it passed.

Is this just a wart of the current build system or is there a way to
address this so the build fails?

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

Re: Requirement Document generator tool

[Chris Johns]

On 30/1/20 8:35 pm, Christian Mauderer wrote:
> On 29/01/2020 23:48, Chris Johns wrote:
>> 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.
> 
> That's why I originally thought of defining a style for _new_ code with
> an optional _slow_ migration if some existing code is touched. Of course
> the style should be compatible with the views how the old code should
> look in the future too. 

I do not think this works as I pointed out earlier. We leave a libaility in the
old code that someone needs to clean up or we just ignore the rules for the old
code. Either are not great.

> The patches were just for an estimate how much
> influence the suggested styles could have. I would never expect that any
> big patch with automated changes would be acceptable without a thorough
> review. I wouldn't accept that myself.

I understand this.

>>> 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?
> 
> It would be great if we would have automatic checking for C too. There
> are big projects that have something like that and it's really
> convenient. For example for Linux before you send a patch you can just
> run "./scripts/checkpatch.pl some.patch" and it will give you everything
> you should fix before sending it to the list. That removes at least one
> round of review.

My point is taking say Google C or C++ coding standard and applying it to the
score. I would prefer we wrote up the rules we have in place and check those.

> But I think implementing that would be a lot bigger task than the one we
> are just discussing. One of the first problems would be finding a style
> checker that can produce _exactly_ the coding style that is defined for
> score.

Agreed.

> And also I'm happy to discuss approaches for something like that
> it would start to be of-topic for this thread. So if you want to discuss
> details about automatic style checking for score we should create an
> extra topic. Maybe we could even create a GSoC project for something
> like that?

That is a good idea. Would you like to raise a task ticket?

>>> 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.
> 
> Sorry, I think I don't fully understand you here.

The reviewers often know the rules and can code to them, it is those writing the
code that do not and need the help. A formatter helps them.

 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.
> 
> I'm really sorry for that. Like I mentioned earlier I'm not really very
> good with the overview over this project too. I'll try to discuss this
> with Sebastian

Re: Errors in .tcfg Do Not Stop the Build

[Chris Johns]

On 31/1/20 8:34 am, Joel Sherrill wrote:
> I made a mistake in a .tcfg file (forgot to write exclude: and just listed
> the test name). There was a message in the build log where the error
> was reported but the build itself continued and didn't produce any 
> executables. The ultimate return status was 0 so we thought it passed.

Ouch.

> Is this just a wart of the current build system or is there a way to 
> address this so the build fails?

I am not sure.

Is rtems-test-check.py returning a non-zero exit code with the error?

Is there an exit code check missing in ...

https://git.rtems.org/rtems/tree/testsuites/aclocal/rtems-test-check.m4

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

RTEMS FS locking

[Charles Manning]

Hi All

I'm the Yaffs Guy and have been asked to do some work refreshing the
Yaffs core code that is in Sebastian's rtems-yaffs git as well as
integrate it into the Yaffs tests.

After a few false starts I now have an understanding of how to build a
simulation test environment based on the quickstart guide - thanks to
those that helped me.

When going through Sebastian's wrapper I noticed that some functions
are locked with the yaffs lock and some are not. At first I thought
that might be a locking bug, but then I noticed that some higher level
functions call rtems_filesystem_instance_lock() and some do not.
rtems_filesystem_instance_lock() results in the yaffs lock being
taken, so that is all good.

Can someone please explain the rationale for when
rtems_filesystem_instance_lock is used and when not?

THanks

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

Re: RTEMS FS locking

[Chris Johns]

On 31/1/20 9:51 am, Charles Manning wrote:
> I'm the Yaffs Guy and have been asked to do some work refreshing the
> Yaffs core code that is in Sebastian's rtems-yaffs git as well as
> integrate it into the Yaffs tests.

Excellent and welcome.

> After a few false starts I now have an understanding of how to build a
> simulation test environment based on the quickstart guide - thanks to
> those that helped me.

Nice. Which BSP?

> When going through Sebastian's wrapper I noticed that some functions
> are locked with the yaffs lock and some are not. At first I thought
> that might be a locking bug, but then I noticed that some higher level
> functions call rtems_filesystem_instance_lock() and some do not.
> rtems_filesystem_instance_lock() results in the yaffs lock being
> taken, so that is all good.
> 
> Can someone please explain the rationale for when
> rtems_filesystem_instance_lock is used and when not?

It is a file system level interface to a specific file system's lock so higher
level operations can be grouped together to make a transaction. Calls to other
file systems can happen concurrently.

For example have a look at the call `fchmod` ...

https://git.rtems.org/rtems/tree/cpukit/libcsupport/src/fchmod.c#n65

The implementation does a file system `fstat_h` handler call and then a
`fchmod_h` handler call. With the lock held this sequence cannot be interrupted
on this file system.

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

Re: RTEMS FS locking

[Charles Manning]

On Fri, Jan 31, 2020 at 12:09 PM Chris Johns  wrote:
>
> On 31/1/20 9:51 am, Charles Manning wrote:
> > I'm the Yaffs Guy and have been asked to do some work refreshing the
> > Yaffs core code that is in Sebastian's rtems-yaffs git as well as
> > integrate it into the Yaffs tests.
>
> Excellent and welcome.

Thanks.

Over the last few years we've seen a lot of interest in Yaffs in the
space segment and RTEMS seems to have made good inroads there.
A lot of this interest stems from Yaffs working well on raw NAND
(rather than managed NAND like eMMC) and people prefer raw NAND in
satellite applications.
We're building RTEMS into our test harnesses ("test farm" would be
over-egging the pudding) so that we can keep the RTEMS wrapper fresh.

Hopefully this will also help row the  RTEMS "eco-system" forward.

>
> > After a few false starts I now have an understanding of how to build a
> > simulation test environment based on the quickstart guide - thanks to
> > those that helped me.
>
> Nice. Which BSP?

I used the quickstart HowTo and using erc32 and followed on from there.
I am using a simulator because that allows me to run something
relatively easily on a tests system without extra HW etc.

>
> > When going through Sebastian's wrapper I noticed that some functions
> > are locked with the yaffs lock and some are not. At first I thought
> > that might be a locking bug, but then I noticed that some higher level
> > functions call rtems_filesystem_instance_lock() and some do not.
> > rtems_filesystem_instance_lock() results in the yaffs lock being
> > taken, so that is all good.
> >
> > Can someone please explain the rationale for when
> > rtems_filesystem_instance_lock is used and when not?
>
> It is a file system level interface to a specific file system's lock so higher
> level operations can be grouped together to make a transaction. Calls to other
> file systems can happen concurrently.
>
> For example have a look at the call `fchmod` ...
>
> https://git.rtems.org/rtems/tree/cpukit/libcsupport/src/fchmod.c#n65
>
> The implementation does a file system `fstat_h` handler call and then a
> `fchmod_h` handler call. With the lock held this sequence cannot be 
> interrupted
> on this file system.

Ah, Ok, so basically this is used where locking is absolutely requires
at the whole-fs level and the default is to allow the FS to do its
only locking as required. Is that a reasonable summary?

Thanks

Charles

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

Re: RTEMS FS locking

[Chris Johns]

On 31/1/20 12:48 pm, Charles Manning wrote:
> On Fri, Jan 31, 2020 at 12:09 PM Chris Johns  wrote:
>>
>> On 31/1/20 9:51 am, Charles Manning wrote:
>>> I'm the Yaffs Guy and have been asked to do some work refreshing the
>>> Yaffs core code that is in Sebastian's rtems-yaffs git as well as
>>> integrate it into the Yaffs tests.
>>
>> Excellent and welcome.
> 
> Thanks.
> 
> Over the last few years we've seen a lot of interest in Yaffs in the
> space segment and RTEMS seems to have made good inroads there.
> A lot of this interest stems from Yaffs working well on raw NAND
> (rather than managed NAND like eMMC) and people prefer raw NAND in
> satellite applications.
> We're building RTEMS into our test harnesses ("test farm" would be
> over-egging the pudding) so that we can keep the RTEMS wrapper fresh.

Reach out to me if you need a hand. We have the ability to run tests on hardware
with the rtems-test command.

> Hopefully this will also help row the  RTEMS "eco-system" forward.

Awesome.

>>
>>> After a few false starts I now have an understanding of how to build a
>>> simulation test environment based on the quickstart guide - thanks to
>>> those that helped me.
>>
>> Nice. Which BSP?
> 
> I used the quickstart HowTo and using erc32 and followed on from there.
> I am using a simulator because that allows me to run something
> relatively easily on a tests system without extra HW etc.
> 
>>
>>> When going through Sebastian's wrapper I noticed that some functions
>>> are locked with the yaffs lock and some are not. At first I thought
>>> that might be a locking bug, but then I noticed that some higher level
>>> functions call rtems_filesystem_instance_lock() and some do not.
>>> rtems_filesystem_instance_lock() results in the yaffs lock being
>>> taken, so that is all good.
>>>
>>> Can someone please explain the rationale for when
>>> rtems_filesystem_instance_lock is used and when not?
>>
>> It is a file system level interface to a specific file system's lock so 
>> higher
>> level operations can be grouped together to make a transaction. Calls to 
>> other
>> file systems can happen concurrently.
>>
>> For example have a look at the call `fchmod` ...
>>
>> https://git.rtems.org/rtems/tree/cpukit/libcsupport/src/fchmod.c#n65
>>
>> The implementation does a file system `fstat_h` handler call and then a
>> `fchmod_h` handler call. With the lock held this sequence cannot be 
>> interrupted
>> on this file system.
> 
> Ah, Ok, so basically this is used where locking is absolutely requires
> at the whole-fs level and the default is to allow the FS to do its
> only locking as required. Is that a reasonable summary?

I think so. I suppose looking at the handler that get hooked to do the locking
would help. I am not sure if it a default one or set by each FS. Sebastian did
these changes and he is back next week.

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

Re: "atsamv" BSP legacy network driver status

[Christian Mauderer]

On 30/01/2020 22:12, dufa...@hda.com wrote:
> 
> 
>> On Jan 30, 2020, at 01:24 , Christian Mauderer 
>>  wrote:
>>
>> 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
> 
> Is it possible that the latest "SAMV71 "Xplained" Ultra" board doesn't work? 
> Details:
> 
> Putting those sections into SDRAM worked perfectly, perfectly enough to 
> duplicate the problem I had with the legacy stack using the "libbsd" stack.  
> The symptoms are the same:
> 
> - The network stack is initialized.
> - The network stack is receiving incoming packets.
> - No transmit packets are sent out.  The software is trying to send out 
> packets but they never go out.
> 
> I'm looking at two of many possibilities as most likely.
> 1. Do I have the media setup mis-configured so it can't transmit?
> -- Unlikely if that's the case since it's receiving.
> -- In the case of using the "libbsd" stack I'm using "ifconfig if-atsam0 
> (ip-address) netmask (netmask) media 100TX up", and it starts receiving 
> packets but not sending.

Just an idea: With Ethernet I have already seen hardware bugs that lead
to the effect that a device wouldn't work on one switch but worked
completely fine on another. Such stuff can also have an influence on the
direction. Did you test stuff like connecting to another switch, maybe
using another speed (10MBit), connecting to a PC directly, ...

> 2. The second possibility.  I'm looking at this now, and I'm sending the 
> email so that you can tell me to stop wasting my time.
> 
> Is it possible this is related to not initializing transmit FIFOS?  My google 
> searches have turned up really similar situations associated with not 
> initializing registers for queues that I don't think exist.
> 
> I haven't sorted this out yet but look at:
> https://www.avrfreaks.net/comment/2648206#comment-2648206
> "I found the problem, at least in the ASF4 code base for Revision B chips
> The Revision B chips have 6 priority transmit fifos (there is an errata 
> regarding this for the Rev A chips)
> Each of these fifos have to be initialized before sending can occur, Atmel 
> tried to do this at the end ..."
> I went to ... because it doesn't apply after this point.

If that is a problem with newer chips, that is a quite possible reason.
From a quick look into the driver it seems that we only initialize three
queues. I also had a quick look at one of the customer boards we have
and it seems to be a revision A chip.

Revision A chips seem to have only three queues even if the data sheet
describes 6. So that could match too.

It seems that our driver sets up the queues with the same buffer. Have
you tried just adding the remaining 3 buffers below the lines

GMAC_SetRxQueue(pHw, (uint32_t)buffer_desc, 1);
GMAC_SetRxQueue(pHw, (uint32_t)buffer_desc, 2);

and

GMAC_SetTxQueue(pHw, (uint32_t)buffer_desc, 1);
GMAC_SetTxQueue(pHw, (uint32_t)buffer_desc, 2);

There is a CHIPID_CIDR.VERSION register that gives the chip revision. So
if that works, it maybe would be good to do that only for chips with
this field set to revision B and newer (value >= 0x1).

> 
> The newest Microchip / Atmel support package, the one that the "atsamv" BSP 
> is *not* based on (and that is totally, totally reorganized and will be 
> difficult to rebase on) includes "dummy buffers for unconfigured queues".

Yes, I know. It's really annoying that the new library isn't compatible.
I think that discussion popped up two or three times on the list. It
would be great if someone would have the time for an upgrade.

> 
> for (i = 0; i < GMAC_QUEUE_COUNT; i++) {
> gmacd_setup_queue(gmacd, i,
> DUMMY_BUFFERS, dummy_buffer, dummy_rx_desc,
> DUMMY_BUFFERS, dummy_buffer, dummy_tx_desc,
> NULL);
> }
> 
> So, as I said:
> 
> Is it possible that the latest "SAMV71 "Xplained" Ultra" board doesn't work? 

I would say that it is possible.

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
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Requirement Document generator tool

[Christian Mauderer]

On 30/01/2020 23:13, Chris Johns wrote:
> On 30/1/20 8:35 pm, Christian Mauderer wrote:
>> On 29/01/2020 23:48, Chris Johns wrote:
>>> 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.
>>
>> That's why I originally thought of defining a style for _new_ code with
>> an optional _slow_ migration if some existing code is touched. Of course
>> the style should be compatible with the views how the old code should
>> look in the future too. 
> 
> I do not think this works as I pointed out earlier. We leave a libaility in 
> the
> old code that someone needs to clean up or we just ignore the rules for the 
> old
> code. Either are not great.

I agree that it's not a great solution. But we have existing code. And
like you said yourself: It's not a good idea to just blindly reformat
it. And I assume even if it would be in the scope of some project, we
wouldn't entirely trust a new developer to do it right because we don't
know how careful he works.

> 
>> The patches were just for an estimate how much
>> influence the suggested styles could have. I would never expect that any
>> big patch with automated changes would be acceptable without a thorough
>> review. I wouldn't accept that myself.
> 
> I understand this.
> 
 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?
>>
>> It would be great if we would have automatic checking for C too. There
>> are big projects that have something like that and it's really
>> convenient. For example for Linux before you send a patch you can just
>> run "./scripts/checkpatch.pl some.patch" and it will give you everything
>> you should fix before sending it to the list. That removes at least one
>> round of review.
> 
> My point is taking say Google C or C++ coding standard and applying it to the
> score. I would prefer we wrote up the rules we have in place and check those.

Ah OK. I missed your point. In that case: I'm a bit torn. I wouldn't say
that it is always a bad idea to migrate to some adapted style rules if
there are good reasons to drop the old ones (except from a revision
control system view where such changes are always annoying). But please
also note that the differences would be a lot bigger.

I counted the lines in the files that I touched with the formatting tool:

wc -l `find -name "*.py" | grep -v "patch-gdb-python" | grep -v "tftpy"
| grep -v "asciidoc"`

It's a total of 18193 lines. The patch touched about 3000 of them. So
it's not a small part but it's not everything either. I assume that we
can reduce it as soon as we worked out some rules and solutions for
formats that can't be touched to the extend that these coding standards
would.

For RTEMS score and nearly every C coding style I know it would be more
of 90 to 100 percent of the code due to the indentation style alone.

> 
>> But I think implementing that would be a lot bigger task than the one we
>> are just discussing. One of the first problems would be finding a style
>> checker that can produce _exactly_ the coding style that is defined for
>> score.
> 
> Agreed.
> 
>> And also I'm happy to discuss approaches for something like that
>> it would start to be of-topic for this thread. So if you want to discuss
>> details about automatic style checking for score we should create an
>> extra topic. Maybe we could even create a GSoC project for something
>> like that?
> 
> That is a good idea. Would you like to raise a task ticket?

I can do that. I think it could be a nice