RE: [PATCH 0/1] misc: tools: fix mkimage.py script type processing

[Jan.Sommer]

> -Original Message-
> From: Chris Johns 
> Sent: Tuesday, February 16, 2021 6:27 AM
> To: Sommer, Jan ; devel@rtems.org
> Subject: Re: [PATCH 0/1] misc: tools: fix mkimage.py script type processing
> 
> On 12/2/21 3:23 am, Jan Sommer wrote:
> > Here is the patch from Andre also in git send-email format.
> 
> Thanks. Pushed.
> 

Thanks.

> > It would be great if we could integrate it in master and the 5 braches.
> 
> I have created a ticket and pushed the change to the 5 branch. It would be a
> help if a ticket and tested 5 patch is also created. :)
> 

Sorry, this patch was a bit spontaneous and I missed that here.

Best regards,

Jan

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

RE: [PATCH v3 1/3] bsps/xilinx_zynq: Add SPI driver for cadence-spi

[Jan.Sommer]

Ok, I asked if it is ok to use the English name for our organization as well.
The answer might take some time, though.

Best regards,

Jan

From: Joel Sherrill 
Sent: Monday, February 15, 2021 9:41 PM
To: Peter Dufault 
Cc: Sommer, Jan ; rtems-de...@rtems.org 
Subject: Re: [PATCH v3 1/3] bsps/xilinx_zynq: Add SPI driver for cadence-spi

Christian submitted a series of patches to eliminate unicode. I'd prefer if we 
avoided it

On Mon, Feb 15, 2021, 8:20 AM Peter Dufault 
mailto:dufa...@hda.com>> wrote:
An international project should allow UTF in source code.  You might need to 
hunt what setting you need (for gnome-terminal "export LANG=en_US.UTF-8" works 
for me in the US).  I'm surprised if anyone is working on a system that can't 
at least display UTF-8.

> On Feb 15, 2021, at 03:21 , jan.som...@dlr.de wrote:
>
> Hi Chris,
>
>> -Original Message-
>> From: Chris Johns mailto:chr...@rtems.org>>
>> Sent: Sunday, February 14, 2021 10:20 PM
>> To: Sommer, Jan mailto:jan.som...@dlr.de>>; 
>> devel@rtems.org
>> Subject: Re: [PATCH v3 1/3] bsps/xilinx_zynq: Add SPI driver for cadence-spi
>>
>> Hi Jan,
>>
>> Thank you for the changes. I have one question inlined below ...
>>
>> On 14/2/21 10:30 pm, Jan Sommer wrote:
>>> ---
>>> bsps/include/dev/spi/cadence-spi-regs.h |  84 +
>>> bsps/include/dev/spi/cadence-spi.h  |  48 +++
>>> bsps/shared/dev/spi/cadence-spi.c   | 437
>> 
>>> 3 files changed, 569 insertions(+)
>>> create mode 100644 bsps/include/dev/spi/cadence-spi-regs.h
>>> create mode 100644 bsps/include/dev/spi/cadence-spi.h
>>> create mode 100644 bsps/shared/dev/spi/cadence-spi.c
>>>
>>> diff --git a/bsps/include/dev/spi/cadence-spi-regs.h
>>> b/bsps/include/dev/spi/cadence-spi-regs.h
>>> new file mode 100644
>>> index 00..2851c88df1
>>> --- /dev/null
>>> +++ b/bsps/include/dev/spi/cadence-spi-regs.h
>>> @@ -0,0 +1,84 @@
>>> +/* SPDX-License-Identifier: BSD-2-Clause */
>>> +
>>> +/*
>>> + * Copyright (C) 2020 Jan Sommer, Deutsches Zentrum für Luft- und
>> Raumfahrt e. V.
>>
>> Is there a unicode character in this line? I cannot see anything in our 
>> coding
>> standard about unicode characters in source and I am not sure what the
>> actual policy is. I seem to remember some have been removed in the past. I
>> thought I would ask on the list now before we push these changes.
>>
>
> There is an u-Umlaut in it. That is probably it. As it is part of the name, 
> it's hard to get rid of.
> I could probably use the English name (German Aerospace Center) which has no 
> special characters.
> Would that be preferred?
>
> Best regards,
>
>Jan
>
>> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

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

Re: [PATCH v3 1/3] bsps/xilinx_zynq: Add SPI driver for cadence-spi

[dufault]

You could use "fuer" to replace "für" as was done in the olden days.  Or do you 
need permission for that as well?

I find it odd to avoid Unicode and not allow umlauts in 2021.

> On Feb 16, 2021, at 05:21 , jan.som...@dlr.de wrote:
> 
> Ok, I asked if it is ok to use the English name for our organization as well.
> 
> The answer might take some time, though.
> 
> 
> 
> Best regards,
> 
> 
> 
> Jan
> 
> 
> 
> From: Joel Sherrill 
> Sent: Monday, February 15, 2021 9:41 PM
> To: Peter Dufault 
> Cc: Sommer, Jan ; rtems-de...@rtems.org 
> Subject: Re: [PATCH v3 1/3] bsps/xilinx_zynq: Add SPI driver for cadence-spi
> 
> 
> 
> Christian submitted a series of patches to eliminate unicode. I'd prefer if 
> we avoided it
> 
> 
> 
> On Mon, Feb 15, 2021, 8:20 AM Peter Dufault  wrote:
> 
> An international project should allow UTF in source code.  You might need to 
> hunt what setting you need (for gnome-terminal "export LANG=en_US.UTF-8" 
> works for me in the US).  I'm surprised if anyone is working on a system that 
> can't at least display UTF-8.
> 
> > On Feb 15, 2021, at 03:21 , jan.som...@dlr.de wrote:
> >
> > Hi Chris,
> >
> >> -Original Message-
> >> From: Chris Johns 
> >> Sent: Sunday, February 14, 2021 10:20 PM
> >> To: Sommer, Jan ; devel@rtems.org
> >> Subject: Re: [PATCH v3 1/3] bsps/xilinx_zynq: Add SPI driver for 
> >> cadence-spi
> >>
> >> Hi Jan,
> >>
> >> Thank you for the changes. I have one question inlined below ...
> >>
> >> On 14/2/21 10:30 pm, Jan Sommer wrote:
> >>> ---
> >>> bsps/include/dev/spi/cadence-spi-regs.h |  84 +
> >>> bsps/include/dev/spi/cadence-spi.h  |  48 +++
> >>> bsps/shared/dev/spi/cadence-spi.c   | 437
> >> 
> >>> 3 files changed, 569 insertions(+)
> >>> create mode 100644 bsps/include/dev/spi/cadence-spi-regs.h
> >>> create mode 100644 bsps/include/dev/spi/cadence-spi.h
> >>> create mode 100644 bsps/shared/dev/spi/cadence-spi.c
> >>>
> >>> diff --git a/bsps/include/dev/spi/cadence-spi-regs.h
> >>> b/bsps/include/dev/spi/cadence-spi-regs.h
> >>> new file mode 100644
> >>> index 00..2851c88df1
> >>> --- /dev/null
> >>> +++ b/bsps/include/dev/spi/cadence-spi-regs.h
> >>> @@ -0,0 +1,84 @@
> >>> +/* SPDX-License-Identifier: BSD-2-Clause */
> >>> +
> >>> +/*
> >>> + * Copyright (C) 2020 Jan Sommer, Deutsches Zentrum für Luft- und
> >> Raumfahrt e. V.
> >>
> >> Is there a unicode character in this line? I cannot see anything in our 
> >> coding
> >> standard about unicode characters in source and I am not sure what the
> >> actual policy is. I seem to remember some have been removed in the past. I
> >> thought I would ask on the list now before we push these changes.
> >>
> >
> > There is an u-Umlaut in it. That is probably it. As it is part of the name, 
> > it's hard to get rid of.
> > I could probably use the English name (German Aerospace Center) which has 
> > no special characters.
> > Would that be preferred?
> >
> > Best regards,
> >
> >Jan
> >
> >> Chris
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> 
> 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
> 

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

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



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

RE: [PATCH v3 1/3] bsps/xilinx_zynq: Add SPI driver for cadence-spi

[Jan.Sommer]

> -Original Message-
> From: dufa...@hda.com 
> Sent: Tuesday, February 16, 2021 2:05 PM
> To: Sommer, Jan 
> Cc: j...@rtems.org; devel@rtems.org
> Subject: Re: [PATCH v3 1/3] bsps/xilinx_zynq: Add SPI driver for cadence-spi
> 
> You could use "fuer" to replace "für" as was done in the olden days.  Or do
> you need permission for that as well?
> 

The umlaut is part of the official brand.
That can be tricky, depending on the corporate policy.

> I find it odd to avoid Unicode and not allow umlauts in 2021.
> 

Yes. Luckily my parents gave me an ASCII-compatible name.
Saves a lot of trouble  :-)

Best regards,

Jan

> > On Feb 16, 2021, at 05:21 , jan.som...@dlr.de wrote:
> >
> > Ok, I asked if it is ok to use the English name for our organization as 
> > well.
> >
> > The answer might take some time, though.
> >
> >
> >
> > Best regards,
> >
> >
> >
> > Jan
> >
> >
> >
> > From: Joel Sherrill 
> > Sent: Monday, February 15, 2021 9:41 PM
> > To: Peter Dufault 
> > Cc: Sommer, Jan ; rtems-de...@rtems.org
> > 
> > Subject: Re: [PATCH v3 1/3] bsps/xilinx_zynq: Add SPI driver for
> > cadence-spi
> >
> >
> >
> > Christian submitted a series of patches to eliminate unicode. I'd
> > prefer if we avoided it
> >
> >
> >
> > On Mon, Feb 15, 2021, 8:20 AM Peter Dufault  wrote:
> >
> > An international project should allow UTF in source code.  You might need
> to hunt what setting you need (for gnome-terminal "export
> LANG=en_US.UTF-8" works for me in the US).  I'm surprised if anyone is
> working on a system that can't at least display UTF-8.
> >
> > > On Feb 15, 2021, at 03:21 , jan.som...@dlr.de wrote:
> > >
> > > Hi Chris,
> > >
> > >> -Original Message-
> > >> From: Chris Johns 
> > >> Sent: Sunday, February 14, 2021 10:20 PM
> > >> To: Sommer, Jan ; devel@rtems.org
> > >> Subject: Re: [PATCH v3 1/3] bsps/xilinx_zynq: Add SPI driver for
> > >> cadence-spi
> > >>
> > >> Hi Jan,
> > >>
> > >> Thank you for the changes. I have one question inlined below ...
> > >>
> > >> On 14/2/21 10:30 pm, Jan Sommer wrote:
> > >>> ---
> > >>> bsps/include/dev/spi/cadence-spi-regs.h |  84 +
> > >>> bsps/include/dev/spi/cadence-spi.h  |  48 +++
> > >>> bsps/shared/dev/spi/cadence-spi.c   | 437
> > >> 
> > >>> 3 files changed, 569 insertions(+) create mode 100644
> > >>> bsps/include/dev/spi/cadence-spi-regs.h
> > >>> create mode 100644 bsps/include/dev/spi/cadence-spi.h
> > >>> create mode 100644 bsps/shared/dev/spi/cadence-spi.c
> > >>>
> > >>> diff --git a/bsps/include/dev/spi/cadence-spi-regs.h
> > >>> b/bsps/include/dev/spi/cadence-spi-regs.h
> > >>> new file mode 100644
> > >>> index 00..2851c88df1
> > >>> --- /dev/null
> > >>> +++ b/bsps/include/dev/spi/cadence-spi-regs.h
> > >>> @@ -0,0 +1,84 @@
> > >>> +/* SPDX-License-Identifier: BSD-2-Clause */
> > >>> +
> > >>> +/*
> > >>> + * Copyright (C) 2020 Jan Sommer, Deutsches Zentrum für Luft- und
> > >> Raumfahrt e. V.
> > >>
> > >> Is there a unicode character in this line? I cannot see anything in
> > >> our coding standard about unicode characters in source and I am not
> > >> sure what the actual policy is. I seem to remember some have been
> > >> removed in the past. I thought I would ask on the list now before we
> push these changes.
> > >>
> > >
> > > There is an u-Umlaut in it. That is probably it. As it is part of the 
> > > name, it's
> hard to get rid of.
> > > I could probably use the English name (German Aerospace Center) which
> has no special characters.
> > > Would that be preferred?
> > >
> > > Best regards,
> > >
> > >Jan
> > >
> > >> Chris
> > > ___
> > > devel mailing list
> > > devel@rtems.org
> > > http://lists.rtems.org/mailman/listinfo/devel
> >
> > 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
> >
> 
> 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

Re: [PATCH v3 1/3] bsps/xilinx_zynq: Add SPI driver for cadence-spi

[Gedare Bloom]

On Tue, Feb 16, 2021 at 8:47 AM  wrote:
>
> > -Original Message-
> > From: dufa...@hda.com 
> > Sent: Tuesday, February 16, 2021 2:05 PM
> > To: Sommer, Jan 
> > Cc: j...@rtems.org; devel@rtems.org
> > Subject: Re: [PATCH v3 1/3] bsps/xilinx_zynq: Add SPI driver for cadence-spi
> >
> > You could use "fuer" to replace "für" as was done in the olden days.  Or do
> > you need permission for that as well?
> >
>
> The umlaut is part of the official brand.
> That can be tricky, depending on the corporate policy.
>
> > I find it odd to avoid Unicode and not allow umlauts in 2021.
> >
>

We do allow unicode with justification. For names, I have no problem
with unicode characters. We do need to confirm when it commits, that
it comes back out the other side properly and doesn't become mangled
by some ASCII conversion.

> Yes. Luckily my parents gave me an ASCII-compatible name.
> Saves a lot of trouble  :-)
>
> Best regards,
>
> Jan
>
> > > On Feb 16, 2021, at 05:21 , jan.som...@dlr.de wrote:
> > >
> > > Ok, I asked if it is ok to use the English name for our organization as 
> > > well.
> > >
> > > The answer might take some time, though.
> > >
> > >
> > >
> > > Best regards,
> > >
> > >
> > >
> > > Jan
> > >
> > >
> > >
> > > From: Joel Sherrill 
> > > Sent: Monday, February 15, 2021 9:41 PM
> > > To: Peter Dufault 
> > > Cc: Sommer, Jan ; rtems-de...@rtems.org
> > > 
> > > Subject: Re: [PATCH v3 1/3] bsps/xilinx_zynq: Add SPI driver for
> > > cadence-spi
> > >
> > >
> > >
> > > Christian submitted a series of patches to eliminate unicode. I'd
> > > prefer if we avoided it
> > >
> > >
> > >
> > > On Mon, Feb 15, 2021, 8:20 AM Peter Dufault  wrote:
> > >
> > > An international project should allow UTF in source code.  You might need
> > to hunt what setting you need (for gnome-terminal "export
> > LANG=en_US.UTF-8" works for me in the US).  I'm surprised if anyone is
> > working on a system that can't at least display UTF-8.
> > >
> > > > On Feb 15, 2021, at 03:21 , jan.som...@dlr.de wrote:
> > > >
> > > > Hi Chris,
> > > >
> > > >> -Original Message-
> > > >> From: Chris Johns 
> > > >> Sent: Sunday, February 14, 2021 10:20 PM
> > > >> To: Sommer, Jan ; devel@rtems.org
> > > >> Subject: Re: [PATCH v3 1/3] bsps/xilinx_zynq: Add SPI driver for
> > > >> cadence-spi
> > > >>
> > > >> Hi Jan,
> > > >>
> > > >> Thank you for the changes. I have one question inlined below ...
> > > >>
> > > >> On 14/2/21 10:30 pm, Jan Sommer wrote:
> > > >>> ---
> > > >>> bsps/include/dev/spi/cadence-spi-regs.h |  84 +
> > > >>> bsps/include/dev/spi/cadence-spi.h  |  48 +++
> > > >>> bsps/shared/dev/spi/cadence-spi.c   | 437
> > > >> 
> > > >>> 3 files changed, 569 insertions(+) create mode 100644
> > > >>> bsps/include/dev/spi/cadence-spi-regs.h
> > > >>> create mode 100644 bsps/include/dev/spi/cadence-spi.h
> > > >>> create mode 100644 bsps/shared/dev/spi/cadence-spi.c
> > > >>>
> > > >>> diff --git a/bsps/include/dev/spi/cadence-spi-regs.h
> > > >>> b/bsps/include/dev/spi/cadence-spi-regs.h
> > > >>> new file mode 100644
> > > >>> index 00..2851c88df1
> > > >>> --- /dev/null
> > > >>> +++ b/bsps/include/dev/spi/cadence-spi-regs.h
> > > >>> @@ -0,0 +1,84 @@
> > > >>> +/* SPDX-License-Identifier: BSD-2-Clause */
> > > >>> +
> > > >>> +/*
> > > >>> + * Copyright (C) 2020 Jan Sommer, Deutsches Zentrum für Luft- und
> > > >> Raumfahrt e. V.
> > > >>
> > > >> Is there a unicode character in this line? I cannot see anything in
> > > >> our coding standard about unicode characters in source and I am not
> > > >> sure what the actual policy is. I seem to remember some have been
> > > >> removed in the past. I thought I would ask on the list now before we
> > push these changes.
> > > >>
> > > >
> > > > There is an u-Umlaut in it. That is probably it. As it is part of the 
> > > > name, it's
> > hard to get rid of.
> > > > I could probably use the English name (German Aerospace Center) which
> > has no special characters.
> > > > Would that be preferred?
> > > >
> > > > Best regards,
> > > >
> > > >Jan
> > > >
> > > >> Chris
> > > > ___
> > > > devel mailing list
> > > > devel@rtems.org
> > > > http://lists.rtems.org/mailman/listinfo/devel
> > >
> > > 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
> > >
> >
> > 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.
>
> _

Re: [PATCH v3 1/3] bsps/xilinx_zynq: Add SPI driver for cadence-spi

[dufault]

> On Feb 16, 2021, at 11:33 , Gedare Bloom  wrote:
> 
>> The umlaut is part of the official brand.
>> That can be tricky, depending on the corporate policy.
>> 
>>> I find it odd to avoid Unicode and not allow umlauts in 2021.
>>> 
>> 
> 
> We do allow unicode with justification. For names, I have no problem
> with unicode characters. We do need to confirm when it commits, that
> it comes back out the other side properly and doesn't become mangled
> by some ASCII conversion.

Sebastian pointed out this file in an earlier Unicode discussion:

testsuites/fstests/fsdosfsname01/create_files.cs

It's full of Unicode.

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

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



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

Re: [PATCH 1/1] misc: tools: fix mkimage.py script type processing

[Chris Johns]

On 12/2/21 3:23 am, Jan Sommer wrote:
> From: Andre Nahrwold 
> 
> ---
>  misc/tools/mkimage.py | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/misc/tools/mkimage.py b/misc/tools/mkimage.py
> index fd75f0a..111e224 100755
> --- a/misc/tools/mkimage.py
> +++ b/misc/tools/mkimage.py
> @@ -121,6 +121,16 @@ outputfile.seek(struct.size);
>  
>  inputcrc = 0;
>  
> +if options.type in 'script':

I saw this and thought it might be wrong and now I think it is. Should this 
line be:

 > +if options.type in ['script']:

?

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

Re: [PATCH v3 1/3] bsps/xilinx_zynq: Add SPI driver for cadence-spi

[Gedare Bloom]

On Tue, Feb 16, 2021 at 10:44 AM  wrote:
>
>
>
> > On Feb 16, 2021, at 11:33 , Gedare Bloom  wrote:
> >
> >> The umlaut is part of the official brand.
> >> That can be tricky, depending on the corporate policy.
> >>
> >>> I find it odd to avoid Unicode and not allow umlauts in 2021.
> >>>
> >>
> >
> > We do allow unicode with justification. For names, I have no problem
> > with unicode characters. We do need to confirm when it commits, that
> > it comes back out the other side properly and doesn't become mangled
> > by some ASCII conversion.
>
> Sebastian pointed out this file in an earlier Unicode discussion:
>
> testsuites/fstests/fsdosfsname01/create_files.cs
>
> It's full of Unicode.
>
And it is well-justified as testing.

We haven't really made anything official policy, but I think the rule
is to avoid unicode unless there is a good reason for it.

> 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

splinkersets01 test assumptions

[Kinsey Moore]

In verifying AArch64/ILP32 on hardware I ran across quite a few alignment 
issues,
some of which were caused by the use of SUBALIGN() in the linker scripts 
mentioned here:
https://devel.rtems.org/ticket/4178

SUBALIGN() was necessary for two reasons:

  *   libc sysinit linker sets (this can be fixed in the sysinit handler struct)
  *   splinkersets01 could not be made to pass on ILP32 as-is without SUBALIGN

It seems that splinkersets01 makes the assumption that linker sets are aligned 
to no more
than the size of a pointer. For ILP32, this is not the case since AArch64 
hardware is very
sensitive to misaligned accesses and many structs in linker sections need to be 
aligned to
8-byte boundaries to avoid throwing exceptions. Some may even need to be 
aligned to
16-byte boundaries depending on the structure, but this doesn't apply to 
splinkersets01.
The resultant alignment padding causes many assertions in splinkersets01 to 
fail.

I'm trying to find a way to make everything work together, but I'd like some 
input.
The highlights with ILP32/LibBSD/hardware:

  *   current codebase: stuffs a struct into a linker section with bad 
alignment and throws an exception
  *   drop SUBALIGN and fix the sysinit issue: splinkersets01 fails, all other 
tests pass, code runs

Paths forward:

  *   disable splinkersets01 for AArch64/ILP32 BSPs
  *   attempt to detect section alignment and adjust splinkersets01 as necessary
  *   splitting the section up for different alignments would require touching 
every linker script
  *   ?

Hopefully I'm just missing something.

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

Re: [PATCH v3 1/3] bsps/xilinx_zynq: Add SPI driver for cadence-spi

[Chris Johns]

On 17/2/21 7:34 am, Gedare Bloom wrote:
> On Tue, Feb 16, 2021 at 10:44 AM  wrote:
>>> On Feb 16, 2021, at 11:33 , Gedare Bloom  wrote:
 The umlaut is part of the official brand.
 That can be tricky, depending on the corporate policy.

> I find it odd to avoid Unicode and not allow umlauts in 2021.
>
>>> We do allow unicode with justification. For names, I have no problem
>>> with unicode characters. We do need to confirm when it commits, that
>>> it comes back out the other side properly and doesn't become mangled
>>> by some ASCII conversion.
>>
>> Sebastian pointed out this file in an earlier Unicode discussion:
>>
>> testsuites/fstests/fsdosfsname01/create_files.cs
>>
>> It's full of Unicode.
>>
> And it is well-justified as testing.
> 
> We haven't really made anything official policy, but I think the rule
> is to avoid unicode unless there is a good reason for it.

We do not have a policy and I think we should.

I looked back and found the only discussion was about the sources for 
documentation:

https://lists.rtems.org/pipermail/devel/2019-February/052742.html

After that there is not a lot.

The doco thread prompted me to check patch 1/3 in this series and saved the
email. The text in it was a large long box of ascii encoding of some form. I
applied the patch using git as test and git is fine with this which is neat and
the unicode characters appeared in the git log as:

+/*
+ * Copyright (C) 2020 Jan Sommer, Deutsches Zentrum fr Luft- und
Raumfahrt e. V. (DLR)
+ *

Less and vi both has similar things ...

 * Copyright (C) 2020 Jan Sommer, Deutsches Zentrum f\xc3\xbcr Luft- und
Raumfahrt e. V. (DLR)

The issue for terminal level work discussed in the doco source is present but in
terms of formal names I am fine with there being unicode characters. I think
having a formal name written in its proper form is what we should allow. The use
of unicode in comments or code is different and here we need to accept the low
common denominator which looks like me on a text terminal.

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

Re: [6-freebsd-12 PATCH 1/2] rtemsbsd/bus: Add PCI support to the nexus bus

[Chris Johns]

I have looked into this some more with Joel. Comments below ..

On 16/2/21 5:49 pm, Chris Johns wrote:
> Hi Sebastian,
> 
> Thank you for the review.
> 
> On 16/2/21 5:05 pm, Sebastian Huber wrote:
>>
>> On 16/02/2021 03:02, chr...@rtems.org wrote:
>>> +/*
>>> + * Values for the bus space tag, not to be used directly by MI code.
>>> + */
>>> +#define    BSP_BUS_SPACE_IO    0    /* space is i/o space */
>>> +#define    BSP_BUS_SPACE_MEM    1    /* space is mem space */
>>> +
>>> +/*
>>> + * BSP PCI Support
>>> + *
>>> + * The RTEMS Nexus bus support can optionaly support PCI spaces that
>>> + * mapped to BSP speciic address spaces. Add the following define to
>>> + * the BSP header file to enable this support:
>>> + *
>>> + *  #define BSP_HAS_PCI
>>> + *
>>> + * If enabled a BSP must the following IO region calls:
>>> + *
>>> + * inb  : read 8 bits
>>> + * outb : write 8 bits
>>> + * inw  : read 16 bits
>>> + * outw : write 16 bits
>>> + * inl  : read 32 bits
>>> + * outl : write 32 bits
>>> + *
>>> + * The BSP needs to provide the DRAM address space offset
>>> + * PCI_DRAM_OFFSET. This is the base address of the DRAM as seen by a
>>> + * PCI master.
>> Why is it not possible to account for this offset in the bus_space_handle_t 
>> bsh?
> 
> How do I do that?

I have figured this out. We can avoid tags (for now).

> FYI some testing with the zynq in qemu results in the PHY failing to 
> initialise.
> It will need a closer look.

I am yet to see what the issue was here.

>> I thought the purpose of the bus_space_tag_t bst was to select different
>> instructions to access the memory space.
> 
> Instructions or a mix of buses? I am still learning my way around this bus
> design but I would have thought tags can handle specific discontinuous buses
> mixed into the same linear address space. That is the drivers offsets are all
> relative to a specific bus. The PCI reports addresses that are relative to 
> that
> buses base address and this is what PCI drivers use.

Given the defined resources I am not sure you fully mix things without using
tags. As I will discuss below endian issues with a specific bus can be a reason.

> 
>> The generic file is for systems with memory mapped access only.
> 
> The bus.h is per arch so if I specialise it for the PowerPC all BSPs in the
> PowerPC arch come across and in the end it becomes the same thing. I cannot 
> see
> a way specialise this per BSP and I am not sure it is needed.

I am coming the conclusion the current bus.h is not suitable for the PowerPC
architecture in general as is. There maybe younger devices with more advanced
bus structures optimised for a specific niche however we also need to balance
the fact we have decades of proven operation in important systems we need to
maintain. Some how we need to find a path all LibBSD PowerPC users are OK with.

We need to look at using the `eieio` instruction. I am reluctant to stop using
it even if testing shows it is OK. These systems are older PowerPC systems and
playing around at the low level after all this time would concern me.

The factor that has come to light with my testing is the PCI bus and devices are
in LE and the PowerPC is BE. This means a suitability sized volatile pointer to
memory does not work. With the VME PowerPC boards I think we are OK with LibBSD
as the devices it will interact with will all be PCI and we force all IO to be 
LE.

>> It also
>> includes  and thus  in a file which is included all over the 
>> place.
> 
> The buf.h header inlines calls which is fine but if we need an offset from a 
> BSP
> the BSP header is needed. We only export from a BSP as a single header.
> 
> I could not see an easy way to have a BSP indicate it has PCI support in 
> LibBSD.

We need to decide if we let the BSP define a set of calls that can be used. This
would mean including `bsp.h` in `bus.h` as I have done. I would rework the
implementation to default to a volatile memory pointer if the BSP has not
provided a BSP specific replacement.

Another alternative is to have a PowerPC specific `bus.h` and then basically do
the same thing only with the LE and BE present in that file then somehow
figuring out how to select the one needed.

I prefer the first option with the increased build time due to including bsp.h,
rtems.h etc.

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

[libbsd PATCH v2 2/2] bsp/motorola_powerpc: Add dc and ukphy support

[chrisj]

From: Chris Johns 

- Add the dc net dev to the BSP

- Add the ukphy support

Closes # 4246
---
 freebsd/sys/dev/dc/if_dc.c|  7 
 freebsd/sys/dev/dc/if_dcreg.h |  7 
 rtemsbsd/include/bsp/nexus-devices.h  |  4 +++
 .../include/machine/rtems-bsd-nexus-bus.h | 32 +++
 4 files changed, 50 insertions(+)

diff --git a/freebsd/sys/dev/dc/if_dc.c b/freebsd/sys/dev/dc/if_dc.c
index 7fc0ef54..b36967da 100644
--- a/freebsd/sys/dev/dc/if_dc.c
+++ b/freebsd/sys/dev/dc/if_dc.c
@@ -156,6 +156,10 @@ MODULE_DEPEND(dc, miibus, 1, 1, 1);
  * Various supported device vendors/types and their names.
  */
 static const struct dc_type dc_devs[] = {
+#ifdef __rtems__
+   { DC_DEVID(DC_VENDORID_DEC, DC_DEVICEID_21140A), 0,
+   "Intel 21140A 10/100BaseTX" },
+#endif /* __rtems__ */
{ DC_DEVID(DC_VENDORID_DEC, DC_DEVICEID_21143), 0,
"Intel 21143 10/100BaseTX" },
{ DC_DEVID(DC_VENDORID_DAVICOM, DC_DEVICEID_DM9009), 0,
@@ -2076,6 +2080,9 @@ dc_attach(device_t dev)
dc_eeprom_width(sc);
 
switch (sc->dc_info->dc_devid) {
+#ifdef __rtems__
+   case DC_DEVID(DC_VENDORID_DEC, DC_DEVICEID_21140A):
+#endif /* __rtems__ */
case DC_DEVID(DC_VENDORID_DEC, DC_DEVICEID_21143):
sc->dc_type = DC_TYPE_21143;
sc->dc_flags |= DC_TX_POLL | DC_TX_USE_TX_INTR;
diff --git a/freebsd/sys/dev/dc/if_dcreg.h b/freebsd/sys/dev/dc/if_dcreg.h
index 9ae26cc6..1c5d39a0 100644
--- a/freebsd/sys/dev/dc/if_dcreg.h
+++ b/freebsd/sys/dev/dc/if_dcreg.h
@@ -824,6 +824,13 @@ struct dc_softc {
  */
 #defineDC_VENDORID_DEC 0x1011
 
+#ifdef __rtems__
+/*
+ * DEC/Intel 21140 PCI device ID
+ */
+#defineDC_DEVICEID_21140A  0x0009
+
+#endif /* __rtems__ */
 /*
  * DEC/Intel 21143 PCI device ID
  */
diff --git a/rtemsbsd/include/bsp/nexus-devices.h 
b/rtemsbsd/include/bsp/nexus-devices.h
index c3c43dc9..d813addd 100644
--- a/rtemsbsd/include/bsp/nexus-devices.h
+++ b/rtemsbsd/include/bsp/nexus-devices.h
@@ -199,6 +199,8 @@ RTEMS_BSD_DRIVER_PCI_IGB;
 RTEMS_BSD_DRIVER_PCI_EM;
 RTEMS_BSD_DRIVER_PCI_RE;
 RTEMS_BSD_DRIVER_REPHY;
+RTEMS_BSD_DRIVER_PCI_DC;
+RTEMS_BSD_DRIVER_DCPHY;
 
 #elif defined(LIBBSP_POWERPC_QORIQ_BSP_H)
 
@@ -240,6 +242,8 @@ SYSINIT_DRIVER_REFERENCE(ukphy, miibus);
 #elif defined(LIBBSP_POWERPC_MOTOROLA_POWERPC_BSP_H)
 
 RTEMS_BSD_DRIVER_PC_LEGACY;
+RTEMS_BSD_DRIVER_PCI_DC;
+RTEMS_BSD_DRIVER_UKPHY;
 
 #endif /* LIBBSP_POWERPC_MOTOROLA_POWERPC_BSP_H */
 
diff --git a/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h 
b/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h
index 5c95d2c3..752bc559 100644
--- a/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h
+++ b/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h
@@ -486,10 +486,26 @@ extern "C" {
 SYSINIT_DRIVER_REFERENCE(re, pci);
 #endif /* RTEMS_BSD_DRIVER_PCI_RE */
 
+/*
+ * DEC Tulip Driver
+ */
+#if !defined(RTEMS_BSD_DRIVER_PCI_DC)
+  #define RTEMS_BSD_DRIVER_PCI_DC \
+SYSINIT_DRIVER_REFERENCE(dc, pci);
+#endif /* RTEMS_BSD_DRIVER_PCI_DC */
+
 /**
  ** MMI Physical Layer Support.
  **/
 
+/*
+ * UK PHY (for unknown PHY devices)
+ */
+#if !defined(RTEMS_BSD_DRIVER_UKPHY)
+  #define RTEMS_BSD_DRIVER_UKPHY   \
+SYSINIT_DRIVER_REFERENCE(ukphy, miibus);
+#endif /* RTEMS_BSD_DRIVER_UKPHY */
+
 /*
  * E1000 PHY
  */
@@ -522,6 +538,22 @@ extern "C" {
 SYSINIT_DRIVER_REFERENCE(micphy, miibus);
 #endif /* RTEMS_BSD_DRIVER_PHY_MIC */
 
+/*
+ * DC PHY.
+ */
+#if !defined(RTEMS_BSD_DRIVER_DCPHY)
+  #define RTEMS_BSD_DRIVER_DCPHY  \
+SYSINIT_DRIVER_REFERENCE(dcphy, miibus);
+#endif /* RTEMS_BSD_DRIVER_DCPHY */
+
+/*
+ * PN PHY.
+ */
+#if !defined(RTEMS_BSD_DRIVER_PNPHY)
+  #define RTEMS_BSD_DRIVER_PNPHY  \
+SYSINIT_DRIVER_REFERENCE(pnphy, miibus);
+#endif /* RTEMS_BSD_DRIVER_PNPHY */
+
 #ifdef __cplusplus
 }
 #endif /* __cplusplus */
-- 
2.27.0

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

[libbsd PATCH v2 1/2] rtemsbsd/bus: Add PCI support to the nexus bus

[chrisj]

From: Chris Johns 

- Add PCI IO region support

- Add support map buffers to PCI address space

Closes #4245
---
 rtemsbsd/include/machine/bus.h| 282 --
 rtemsbsd/rtems/rtems-kernel-bus-dma.c |   5 +-
 rtemsbsd/rtems/rtems-kernel-nexus.c   |  50 -
 3 files changed, 222 insertions(+), 115 deletions(-)

diff --git a/rtemsbsd/include/machine/bus.h b/rtemsbsd/include/machine/bus.h
index 2f0e7ad6..42148ee3 100644
--- a/rtemsbsd/include/machine/bus.h
+++ b/rtemsbsd/include/machine/bus.h
@@ -6,9 +6,13 @@
  * @brief TODO.
  *
  * File origin from FreeBSD 'sys/amd64/include/bus.h'.
+ *
+ * Conditionally supports PCI IO regions (IO Ports).
  */
 
 /*-
+ * Copyright (c) 2021 Chris Johns.  All rights reserved.
+ *
  * Copyright (c) 2009, 2015 embedded brains GmbH.  All rights reserved.
  *
  *  embedded brains GmbH
@@ -25,7 +29,7 @@
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
  * are met:
- * 
+ *
  * 1. Redistributions of source code must retain the above copyright
  *notice, this list of conditions and the following disclaimer as
  *the first lines of this file unmodified.
@@ -34,7 +38,7 @@
  *documentation and/or other materials provided with the distribution.
  * 3. The name of the author may not be used to endorse or promote products
  *derived from this software without specific prior written permission.
- * 
+ *
  * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
  * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
  * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
@@ -123,7 +127,7 @@
 #endif
 
 #ifdef __i386__
-  #error "your include paths are wrong"
+  #error "x86 has its own bus.h; check your include paths are correct"
 #endif
 
 /*
@@ -144,6 +148,7 @@
 /*
  * Bus access.
  */
+#define BUS_SPACE_INVALID_DATA (~0)
 #define BUS_SPACE_UNRESTRICTED (~0U)
 
 /*
@@ -222,6 +227,93 @@ bus_space_barrier(bus_space_tag_t bst __unused, 
bus_space_handle_t bsh, bus_size
/* Do nothing */
 }
 
+
+/*
+ * BSP or linear inline memory access.
+ */
+#include 
+
+static __inline uint8_t
+bsp_bus_space_read_1(const uint8_t __volatile *bsp)
+{
+#if defined(RTEMS_BSP_READ_1)
+   return RTEMS_BSP_READ_1(bsp);
+#else
+   return (*bsp);
+#endif
+}
+
+static __inline uint16_t
+bsp_bus_space_read_2(const uint16_t __volatile *bsp)
+{
+#if defined(RTEMS_BSP_READ_2)
+   return RTEMS_BSP_READ_2(bsp);
+#else
+   return (*bsp);
+#endif
+}
+
+static __inline uint32_t
+bsp_bus_space_read_4(const uint32_t __volatile *bsp)
+{
+#if defined(RTEMS_BSP_READ_4)
+   return RTEMS_BSP_READ_4(bsp);
+#else
+   return (*bsp);
+#endif
+}
+
+static __inline uint64_t
+bsp_bus_space_read_8(const uint64_t __volatile *bsp)
+{
+#if defined(RTEMS_BSP_READ_8)
+   return RTEMS_BSP_READ_8(bsp);
+#else
+   return (*bsp);
+#endif
+}
+
+static __inline void
+bsp_bus_space_write_1(uint8_t __volatile *bsp, uint8_t val)
+{
+#if defined(RTEMS_BSP_WRITE_1)
+   RTEMS_BSP_WRITE_1(bsp, val);
+#else
+   *bsp = val;
+#endif
+}
+
+static __inline void
+bsp_bus_space_write_2(uint16_t __volatile *bsp, uint16_t val)
+{
+#if defined(RTEMS_BSP_WRITE_2)
+   RTEMS_BSP_WRITE_2(bsp, val);
+#else
+   *bsp = val;
+#endif
+}
+
+static __inline void
+bsp_bus_space_write_4(uint32_t __volatile *bsp, uint32_t val)
+{
+#if defined(RTEMS_BSP_WRITE_4)
+   RTEMS_BSP_WRITE_4(bsp, val);
+#else
+   *bsp = val;
+#endif
+}
+
+static __inline void
+bsp_bus_space_write_8(uint64_t __volatile *bsp, uint64_t val)
+{
+#if defined(RTEMS_BSP_WRITE_8)
+   RTEMS_BSP_WRITE_8(bsp, val);
+#else
+   *bsp = val;
+#endif
+}
+
+
 /*
  * Read 1 unit of data from bus space described by the tag, handle and ofs
  * tuple. A unit of data can be 1 byte, 2 bytes, 4 bytes or 8 bytes. The
@@ -231,28 +323,28 @@ static __inline uint8_t
 bus_space_read_1(bus_space_tag_t bst __unused, bus_space_handle_t bsh, 
bus_size_t ofs)
 {
uint8_t __volatile *bsp = (uint8_t __volatile *)(bsh + ofs);
-   return (*bsp);
+   return bsp_bus_space_read_1(bsp);
 }
 
 static __inline uint16_t
 bus_space_read_2(bus_space_tag_t bst __unused, bus_space_handle_t bsh, 
bus_size_t ofs)
 {
uint16_t __volatile *bsp = (uint16_t __volatile *)(bsh + ofs);
-   return (*bsp);
+   return bsp_bus_space_read_2(bsp);
 }
 
 static __inline uint32_t
 bus_space_read_4(bus_space_tag_t bst __unused, bus_space_handle_t bsh, 
bus_size_t ofs)
 {
uint32_t __volatile *bsp = (uint32_t __volatile *)(bsh + ofs);
-   return (*bsp);
+   return bsp_bus_space_read_4(bsp);
 }
 
 static __inline uint64_t
 bus_space_read_8(bus_space_tag_t bst __unused, bus_space_handle_t bsh, 
bus_size_t ofs)
 {
uint64_t __volatile *bsp = (uint64_t __volatile *)(bsh + ofs);
-   return (*bsp);
+   return bsp_bus_space_read_8(bsp);
 }
 
 
@@ -266,7 +358,7 @@

Re: [6-freebsd-12 PATCH 1/2] rtemsbsd/bus: Add PCI support to the nexus bus

[Sebastian Huber]

On 17/02/2021 03:20, Chris Johns wrote:


I have looked into this some more with Joel. Comments below ..

On 16/2/21 5:49 pm, Chris Johns wrote:

Hi Sebastian,

Thank you for the review.

On 16/2/21 5:05 pm, Sebastian Huber wrote:

On 16/02/2021 03:02, chr...@rtems.org wrote:

+/*
+ * Values for the bus space tag, not to be used directly by MI code.
+ */
+#define    BSP_BUS_SPACE_IO    0    /* space is i/o space */
+#define    BSP_BUS_SPACE_MEM    1    /* space is mem space */
+
+/*
+ * BSP PCI Support
+ *
+ * The RTEMS Nexus bus support can optionaly support PCI spaces that
+ * mapped to BSP speciic address spaces. Add the following define to
+ * the BSP header file to enable this support:
+ *
+ *  #define BSP_HAS_PCI
+ *
+ * If enabled a BSP must the following IO region calls:
+ *
+ * inb  : read 8 bits
+ * outb : write 8 bits
+ * inw  : read 16 bits
+ * outw : write 16 bits
+ * inl  : read 32 bits
+ * outl : write 32 bits
+ *
+ * The BSP needs to provide the DRAM address space offset
+ * PCI_DRAM_OFFSET. This is the base address of the DRAM as seen by a
+ * PCI master.

Why is it not possible to account for this offset in the bus_space_handle_t bsh?

How do I do that?

I have figured this out. We can avoid tags (for now).

Good, the day will come when we need the tags.



FYI some testing with the zynq in qemu results in the PHY failing to initialise.
It will need a closer look.

I am yet to see what the issue was here.


I thought the purpose of the bus_space_tag_t bst was to select different
instructions to access the memory space.

Instructions or a mix of buses? I am still learning my way around this bus
design but I would have thought tags can handle specific discontinuous buses
mixed into the same linear address space. That is the drivers offsets are all
relative to a specific bus. The PCI reports addresses that are relative to that
buses base address and this is what PCI drivers use.

Given the defined resources I am not sure you fully mix things without using
tags. As I will discuss below endian issues with a specific bus can be a reason.


The generic file is for systems with memory mapped access only.

The bus.h is per arch so if I specialise it for the PowerPC all BSPs in the
PowerPC arch come across and in the end it becomes the same thing. I cannot see
a way specialise this per BSP and I am not sure it is needed.

I am coming the conclusion the current bus.h is not suitable for the PowerPC
architecture in general as is. There maybe younger devices with more advanced
bus structures optimised for a specific niche however we also need to balance
the fact we have decades of proven operation in important systems we need to
maintain. Some how we need to find a path all LibBSD PowerPC users are OK with.


The PowerPC architecture is quite old and well designed. I am pretty 
sure that the Cache-Inhibited and Guarded memory is available in all 
PowerPC systems we support.




We need to look at using the `eieio` instruction. I am reluctant to stop using
it even if testing shows it is OK. These systems are older PowerPC systems and
playing around at the low level after all this time would concern me.
I didn't found a use of eieio in the FreeBSD bus support. Where have you 
seen it in FreeBSD?


The factor that has come to light with my testing is the PCI bus and devices are
in LE and the PowerPC is BE. This means a suitability sized volatile pointer to
memory does not work. With the VME PowerPC boards I think we are OK with LibBSD
as the devices it will interact with will all be PCI and we force all IO to be 
LE.


Yes, the endian conversion is an issue. For the NVMe support I hacked it 
like this:


https://git.rtems.org/rtems-libbsd/commit/?id=aaeae61bd097db64e9f3c0c8f67de768887197e5

https://git.rtems.org/rtems-libbsd/commit/?id=cdbae21e4d55c01ce9a3db98443ab315e011e760

This is definitely not a perfect solution, however, it worked without 
changing the bus space implementation.





It also
includes  and thus  in a file which is included all over the 
place.

The buf.h header inlines calls which is fine but if we need an offset from a BSP
the BSP header is needed. We only export from a BSP as a single header.

I could not see an easy way to have a BSP indicate it has PCI support in LibBSD.

We need to decide if we let the BSP define a set of calls that can be used. This
would mean including `bsp.h` in `bus.h` as I have done. I would rework the
implementation to default to a volatile memory pointer if the BSP has not
provided a BSP specific replacement.

Another alternative is to have a PowerPC specific `bus.h` and then basically do
the same thing only with the LE and BE present in that file then somehow
figuring out how to select the one needed.
There are definitely reasons, why the FreeBSD bus space implementation 
is a bit more complicated. For me it would be all right to let BSPs 
optionally enable the full featured bus space implementation ported from 
FreeBSD. This would be a bit of work.

Re: splinkersets01 test assumptions

[Sebastian Huber]

On 16/02/2021 22:26, Kinsey Moore wrote:

In verifying AArch64/ILP32 on hardware I ran across quite a few 
alignment issues,


some of which were caused by the use of SUBALIGN() in the linker 
scripts mentioned here:


https://devel.rtems.org/ticket/4178 

SUBALIGN() was necessary for two reasons:

  * libc sysinit linker sets (this can be fixed in the sysinit handler
struct)
  * splinkersets01 could not be made to pass on ILP32 as-is without
SUBALIGN


In the ld documentation we have:

https://sourceware.org/binutils/docs/ld/Forced-Input-Alignment.html#index-SUBALIGN_0028subsection_005falign_0029

"You can force input section alignment within an output section by using 
SUBALIGN. The value specified overrides any alignment given by input 
sections, whether larger or smaller."


I think the use of SUBALIGN() is a bug and should be removed. Why do you 
want to override the alignment of the input sections?


It seems that splinkersets01 makes the assumption that linker sets are 
aligned to no more


than the size of a pointer. For ILP32, this is not the case since 
AArch64 hardware is very


sensitive to misaligned accesses and many structs in linker sections 
need to be aligned to


8-byte boundaries to avoid throwing exceptions. Some may even need to 
be aligned to


16-byte boundaries depending on the structure, but this doesn’t apply 
to splinkersets01.


The resultant alignment padding causes many assertions in 
splinkersets01 to fail.


The linker sets should use the alignment of the item type. This is done 
by defining zero length arrays:


#define RTEMS_LINKER_ROSET( set, type ) \
  type const RTEMS_LINKER_SET_BEGIN( set )[ 0 ] \
  RTEMS_SECTION( ".rtemsroset." #set ".begin" ) RTEMS_USED; \
  type const RTEMS_LINKER_SET_END( set )[ 0 ] \
  RTEMS_SECTION( ".rtemsroset." #set ".end" ) RTEMS_USED

In standard C such arrays are not defined, but GCC does the right thing:

cat test-linkersets.c
#define RTEMS_USED __attribute__(( __used__ ))

#define RTEMS_SECTION( _section ) __attribute__(( __section__( _section ) ))

#define RTEMS_LINKER_SET_BEGIN( set ) \
  _Linker_set_##set##_begin

#define RTEMS_LINKER_SET_END( set ) \
  _Linker_set_##set##_end

#define RTEMS_LINKER_ROSET( set, type ) \
  type const RTEMS_LINKER_SET_BEGIN( set )[ 0 ] \
  RTEMS_SECTION( ".rtemsroset." #set ".begin" ) RTEMS_USED; \
  type const RTEMS_LINKER_SET_END( set )[ 0 ] \
  RTEMS_SECTION( ".rtemsroset." #set ".end" ) RTEMS_USED

struct s { __attribute__((__aligned__(256))) int i; };

RTEMS_LINKER_ROSET( i, int );
RTEMS_LINKER_ROSET( ll, long long );
RTEMS_LINKER_ROSET( s, struct s );

aarch64-rtems6-gcc -O2 -S -o - test-linkersets.c
    .arch armv8-a
    .file   "test-linkersets.c"
    .text
    .global _Linker_set_s_end
    .global _Linker_set_s_begin
    .global _Linker_set_ll_end
    .global _Linker_set_ll_begin
    .global _Linker_set_i_end
    .global _Linker_set_i_begin
    .section    .rtemsroset.i.begin,"a"
    .align  3
    .type   _Linker_set_i_begin, %object
    .size   _Linker_set_i_begin, 0
_Linker_set_i_begin:
    .section    .rtemsroset.i.end,"a"
    .align  3
    .type   _Linker_set_i_end, %object
    .size   _Linker_set_i_end, 0
_Linker_set_i_end:
    .section    .rtemsroset.ll.begin,"a"
    .align  3
    .type   _Linker_set_ll_begin, %object
    .size   _Linker_set_ll_begin, 0
_Linker_set_ll_begin:
    .section    .rtemsroset.ll.end,"a"
    .align  3
    .type   _Linker_set_ll_end, %object
    .size   _Linker_set_ll_end, 0
_Linker_set_ll_end:
    .section    .rtemsroset.s.begin,"a"
    .align  8
    .type   _Linker_set_s_begin, %object
    .size   _Linker_set_s_begin, 0
_Linker_set_s_begin:
    .section    .rtemsroset.s.end,"a"
    .align  8
    .type   _Linker_set_s_end, %object
    .size   _Linker_set_s_end, 0
_Linker_set_s_end:
    .ident  "GCC: (GNU) 10.2.1 20210205 (RTEMS 6, RSB 
61dcadee0825867ebe51f9f367430ef75b8fe9c0, Newlib d4a756f)"


aarch64-rtems6-gcc -O2 -S -o - test-linkersets.c -mabi=ilp32
    .arch armv8-a
    .file   "test-linkersets.c"
    .text
    .global _Linker_set_s_end
    .global _Linker_set_s_begin
    .global _Linker_set_ll_end
    .global _Linker_set_ll_begin
    .global _Linker_set_i_end
    .global _Linker_set_i_begin
    .section    .rtemsroset.i.begin,"a"
    .align  3
    .type   _Linker_set_i_begin, %object
    .size   _Linker_set_i_begin, 0
_Linker_set_i_begin:
    .section    .rtemsroset.i.end,"a"
    .align  3
    .type   _Linker_set_i_end, %object
    .size   _Linker_set_i_end, 0
_Linker_set_i_end:
    .section    .rtemsroset.ll.begin,"a"
    .align  3
    .type   _Linker_set_ll_begin, %object
    .size   _Linker_set_ll_begin, 0
_Linker_set_ll_begin:
    .section    .rtem

AW: [PATCH 1/1] misc: tools: fix mkimage.py script type processing

[Andre.Nahrwold]

Hi Chris,

as far as my understanding of python goes this does not make any difference.
Strings are essentially arrays in python which would make the parenthesis 
obsolete.

When this condition should catch another type in the future it would be good 
practice to do something like this:

If options.type in ['script', '']:

Even though the following would be functional the same but obviously much less 
readable and logical:

If options.type in 'script':

Best regards
André

-Ursprüngliche Nachricht-
Von: Chris Johns  
Gesendet: Dienstag, 16. Februar 2021 21:29
An: Sommer, Jan ; devel@rtems.org
Cc: Nahrwold, Andre 
Betreff: Re: [PATCH 1/1] misc: tools: fix mkimage.py script type processing

On 12/2/21 3:23 am, Jan Sommer wrote:
> From: Andre Nahrwold 
> 
> ---
>  misc/tools/mkimage.py | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/misc/tools/mkimage.py b/misc/tools/mkimage.py index 
> fd75f0a..111e224 100755
> --- a/misc/tools/mkimage.py
> +++ b/misc/tools/mkimage.py
> @@ -121,6 +121,16 @@ outputfile.seek(struct.size);
>  
>  inputcrc = 0;
>  
> +if options.type in 'script':

I saw this and thought it might be wrong and now I think it is. Should this 
line be:

 > +if options.type in ['script']:

?

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