Re: xz_crc64.c not compiled

[Chris Johns]

On 8/11/2022 3:23 am, Gedare Bloom wrote:
> On Fri, Nov 4, 2022 at 5:05 PM Chris Johns  wrote:
>>
>> On 5/11/2022 6:46 am, Gedare Bloom wrote:
>>> On Fri, Nov 4, 2022 at 1:39 PM Joel Sherrill  wrote:
>>>>
>>>>
>>>>
>>>> On Fri, Nov 4, 2022, 2:37 PM Gedare Bloom  wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I don't see an entry in spec/build anywhere for xz_crc64.c
>>>>>
>>>>>  From what I can tell it is not compiled/tested. I guess the
>>>>> This leads me to believe it is not compiled. And therefore is not
>>>>> being called or tested anywhere.
>>>>>
>>>>> Should it be compiled, or should it be removed?
>>>>
>>>>
>>>> What about in 5 and the autotools build system?
>>>>
>>> It appears to be omitted from 5's cpukit/Makefile.am
>>>
>>> I don't see the code in 4.11. It was added by Chris to support untar
>>> of tgz files.
>>
>> Sorry I do not recall why it was not added into the build. There are no
>> calls in the code to it.
>>
> I guess the question then is whether to add it to the build and write
> a testsuite call to it, or to remove it from the tree.

Maybe add it? If you need to add a 64bit CRC the code is there?

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

Re: Apple's Ventura OS issue with RSB.

[Chris Johns]

On 7/11/2022 5:38 am, Karel Gardas wrote:
> 
> Side note before answering : the email was motivated by the fact that I 
> provided
> few patches to RSB to make that working well on Monterey running on M1. This 
> was
> just few weeks ago so I know, this was running well. Last week I've updated to
> Ventura and things felt apart. Hence the report here.
> 
> On 11/6/22 16:09, Joel Sherrill wrote:
>> Is the cross gcc compiled with the native compiler provided by Apple? 
> 
> Yes, it is.
> 
>> The alternative would likely be you installing something special.
> 
> No, I keep OS as clean as possible and as stock as possible to be as close as
> possible to customer configuration.
> 
>> I wonder if using gcc to compile it would work. But there's not a real 
>> solution.
> 
> Indeed, I'll see if I can do anything about that as that would also be usable
> for...
> 
>>
>> Seems like an issue which needs reporting to gcc.
>>
> 
> indeed, the report here is probably minimal thing I should do.

Sebastian has pushed updates to the tools to the RSB. Did you happen to pick up
those?

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

Re: [xubuntu-users] file system window read-only

[Alex Johns]

On 6/11/22 07:43, Alessandro Lin wrote:


Hallo,

I have a problem with read-only filesystem.
I describe neatly:

I installed XUBUNTU 22 on a new desktop.
Windows 10 already pre-installed.

Before:

I created a partition for xubuntu.

I turned off Windows 10 quick start

I disabled Bitlocker and decrypted the disk.

Well, now xubuntu works and also windows 10

Xubuntu 22 does not have a good support for Italian language, while 
Xubuntu 20 had it but it is a thing of little importance.


Now The Windows disk partition is read-only. This is my problem.

List all of the mounted file systems:

/$ mount/

... etc. etc.
/dev/sda3 on /media/alex/B87A648A7A64476A type fuseblk 
(ro,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)
... etc. etc.



The Windows partition /dev/sda3 is read-only.

To have read / write I can try :

sudo mount -o remount /dev/sda3 /media/alex/B87A648A7A64476A


Is correct?

The Windows partition is read-only for some reason.

If I mount it in read-write mode, do any collateral problems arise?

Thank you





my win 10 partition is mounted rw, and has given me no issues.

cheers da kiwi
-- 
xubuntu-users mailing list
xubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/xubuntu-users

Re: xz_crc64.c not compiled

[Chris Johns]

On 5/11/2022 6:46 am, Gedare Bloom wrote:

On Fri, Nov 4, 2022 at 1:39 PM Joel Sherrill  wrote:




On Fri, Nov 4, 2022, 2:37 PM Gedare Bloom  wrote:


Hi all,

I don't see an entry in spec/build anywhere for xz_crc64.c

 From what I can tell it is not compiled/tested. I guess the
This leads me to believe it is not compiled. And therefore is not
being called or tested anywhere.

Should it be compiled, or should it be removed?



What about in 5 and the autotools build system?


It appears to be omitted from 5's cpukit/Makefile.am

I don't see the code in 4.11. It was added by Chris to support untar
of tgz files.


Sorry I do not recall why it was not added into the build. There are no 
calls in the code to it.


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

Re: Fwd: Identify 3rd party source in spec?

[Chris Johns]

On 5/11/2022 4:00 am, Gedare Bloom wrote:

Given the complexity of this tagging, I'm going to start with just the
true/false approach to categorize third-party sources. We can do
something like the above in the future.


Sounds good. We can consider a dict when someone maps out how to manage 
3rd party source. I think it would premature to do it without further 
consideration.


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

Re: [PATCH 2/2] wscript: rename bsp_list to bsplist

[Chris Johns]

+1

On 4/11/2022 2:59 am, Gedare Bloom wrote:
> ---
>  wscript | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/wscript b/wscript
> index a8510edbee..b42c8f1119 100755
> --- a/wscript
> +++ b/wscript
> @@ -1694,7 +1694,7 @@ COMPILER = {}""".format(
>  no_matches_error(ctx, white_list)
>  
>  
> -def bsp_list(ctx):
> +def bsplist(ctx):
>  """lists base BSP variants"""
>  check_forbidden_options(
>  ctx, ["compiler", "config", "options", "tools", "top_group", 
> "version"]
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Fwd: Identify 3rd party source in spec?

[Chris Johns]

On 3/11/2022 2:50 pm, Chris Johns wrote:
> On 3/11/2022 10:30 am, Gedare Bloom wrote:
>> It was pointed out in Discord that the "third_party_list" command is
>> unusual with respect to other waf commands, which are given as oneword
>> formats (other than bsp_list and bsp_defaults). I think it makes sense
>> to go with such a oneword format for consistent commands. So I will
>> instead start prototyping this as
>> ./waf thirdparties
>>
>> instead of
>> ./waf third_party_list
>>
> 
> Great and thanks.
> 
>> Relatedly: I might look into changing
>> ./waf bsp_list
>> to
>> ./waf bsps
>>
>> and
>> ./waf bsp_defaults
>> to
>> ./waf bspdefaults
>>
>> the hard part will be chasing down the documentation.
> 
> I like the change and doing it now would mean it would change across releases.

Would not be changing across releases ... that is

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

Re: Fwd: Identify 3rd party source in spec?

[Chris Johns]

On 3/11/2022 10:30 am, Gedare Bloom wrote:
> It was pointed out in Discord that the "third_party_list" command is
> unusual with respect to other waf commands, which are given as oneword
> formats (other than bsp_list and bsp_defaults). I think it makes sense
> to go with such a oneword format for consistent commands. So I will
> instead start prototyping this as
> ./waf thirdparties
> 
> instead of
> ./waf third_party_list
> 

Great and thanks.

> Relatedly: I might look into changing
> ./waf bsp_list
> to
> ./waf bsps
> 
> and
> ./waf bsp_defaults
> to
> ./waf bspdefaults
> 
> the hard part will be chasing down the documentation.

I like the change and doing it now would mean it would change across releases.

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

Re: [RBW] Who is getting a Platypus?

[JohnS]

Thank you  Laing for the derailleur hanger alignment tool tip. I think I'll 
order this one from Nashbar, only $54.95.

https://www.nashbar.com/super-b-derailleur-hanger-alignment-gauge-silver-tb-1946/p1398199?gclid=Cj0KCQjwqoibBhDUARIsAH2OpWgTQxYdht-0vbnpE-So3anrX8FnoYvXu0tfPrjzHaAV72CFexJOtlkaAtXGEALw_wcB

JohnS

On Wednesday, November 2, 2022 at 9:49:28 AM UTC-4 DavidP wrote:

> An Instagram update from yesterday shows Platypus frames are being packed 
> and shipped!
> https://www.instagram.com/p/Ckbmiz_S5GB/
>
> Anyone get a shipping notification for theirs yet?
>
> -Dave
>
> On Friday, October 28, 2022 at 8:50:29 PM UTC-4 John Hawrylak wrote:
>
>> Scott
>>
>> AFAIK RBW had stated in the newsletter that they do not want to open the 
>> box just to check it sicne they need to ship it in another box.  One can 
>> see their logic, especially since they are handling many more frames than 5 
>> years ago, and can't/don't have the time to check them or feel the level of 
>> service they provided in the past is just unattainable now,
>>
>> John Hawrylak
>> Woodstown NJ
>>
>> On Friday, October 28, 2022 at 11:14:06 AM UTC-4 Scott wrote:
>>
>>> Joe:
>>>
>>> I talked to Riv earlier this week about purchasing an Atlantis and posed 
>>> a few questions about F/F prep. I'm not here to make a blanket statement 
>>> about how all F/F are handled before they depart Riv, but I was told they 
>>> receive the Atlantis F/F with headset already installed and that a F/F I 
>>> purchase would not have the hanger checked/aligned before sent to me. My 
>>> "guess" is they may not even unpack the F/F when they receive it. There 
>>> wouldn't be any reason for them to open it up, if nothing is to be done on 
>>> F/F. Maybe they are so busy it's easier to just place a new shipping label 
>>> on the box and out it goes. I live in rural Montana and am a little bummed 
>>> I have to travel a good distance just to ensure hanger is properly aligned 
>>> after spending $1750 on a new baby. And I would doubt the threads are 
>>> chased.
>>>
>>> Nothing whatsoever against Riv, just an observation. Seems it should be 
>>> part of the frame making process to quickly verify proper hanger position 
>>> somewhere between frame build completion and paint. I'm going to travel and 
>>> pay to have it done, anyways.
>>>
>>> On Thursday, October 20, 2022 at 08:21:39 PM MDT, Joe Bernard <
>>> joer...@gmail.com> wrote: 
>>>
>>>
>>> Are these frames being sold as unprepped? I'm not clear on where they 
>>> are with that now but it would certainly slow down my "buy" finger if I 
>>> knew I still had to install the fork, adjust the headset, chase the threads 
>>> and check the derailer hanger adjustment. 
>>>
>>> Joe "I don't know how to do the last two parts" Bernard 
>>>
>>> On Thursday, October 20, 2022 at 6:52:23 PM UTC-7 Doug H. wrote:
>>>
>>> I imagine quite a few have sold but Riv not being able to offer many 
>>> complete builds may be reducing sales. Hopefully they can get caught up on 
>>> the backlog of builds in the queue. And, the Rosco version of the Platypus 
>>> was just released recently so that fulfilled some people's wish for a mixte 
>>> type road bike.
>>> Doug
>>>
>>> On Thursday, October 20, 2022 at 7:13:17 PM UTC-4 cycli...@gmail.com 
>>> wrote:
>>>
>>> It would seem that demand is mirroring that of the housing market.  
>>> Decidedly cooler than 12 months ago when Platys and house listing were sold 
>>> out in mere hours. 
>>>
>>> On Monday, October 10, 2022 at 2:34:14 PM UTC-7 Johnny Alien wrote:
>>>
>>> I think they will sell pretty quick but not as lightning fast as they 
>>> did during the pandemic.
>>> On Monday, October 10, 2022 at 4:13:58 PM UTC-4 Eric Daume wrote:
>>>
>>> There is still one Rosco Plat in 60cm of each color available, so maybe 
>>> supply and demand are balancing out. At least for the taller folks. 
>>>
>>> Eric
>>>
>>> On Monday, October 10, 2022, Bicycle Belle Ding Ding! <
>>> jonasa...@gmail.com> wrote:
>>>
>>> I can never tamp down my excitement over the Riv mixtes and have given 
>>> up trying. I’m SO excited that there is a paddle of Platypuses on the 
>>> water, heading to Rivendell as I type this. I remember the excitement of 
>>> the 2020 Platypuses (which were de

Re: [PATCH rtems-libbsd] freebsd/cgem: Use SGMII when necessary

[Chris Johns]

On 2/11/2022 1:48 pm, Kinsey Moore wrote:
> On Tue, Nov 1, 2022 at 9:22 PM Chris Johns  <mailto:chr...@rtems.org>> wrote:
> On 2/11/2022 1:18 pm, Kinsey Moore wrote:
> > On Tue, Nov 1, 2022 at 5:49 PM Chris Johns  <mailto:chr...@rtems.org>
> > <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>> wrote:
> >
> >     On 2/11/2022 8:56 am, Kinsey Moore wrote:
> >     > On Tue, Nov 1, 2022 at 4:14 PM Chris Johns  <mailto:chr...@rtems.org>
> >     <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>
> >     > <mailto:chr...@rtems.org <mailto:chr...@rtems.org>
> <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>>> wrote:
> >     >     On 2/11/2022 5:51 am, Kinsey Moore wrote:
> >     >     > Certain hardware configurations will always use SGMII 
> instead
> of RGMII.
> >     >     > Apply the appropriate flags for the relevant BSPs.
> >     >     > ---
> >     >     >  freebsd/sys/dev/cadence/if_cgem.c | 10 ++
> >     >     >  1 file changed, 10 insertions(+)
> >     >     >
> >     >     > diff --git a/freebsd/sys/dev/cadence/if_cgem.c
> >     >     b/freebsd/sys/dev/cadence/if_cgem.c
> >     >     > index 3eaaf6b2..9b4cf693 100644
> >     >     > --- a/freebsd/sys/dev/cadence/if_cgem.c
> >     >     > +++ b/freebsd/sys/dev/cadence/if_cgem.c
> >     >     > @@ -1296,6 +1296,16 @@ cgem_config(struct cgem_softc *sc)
> >     >     >               CGEM_NET_CFG_FULL_DUPLEX |
> >     >     >               CGEM_NET_CFG_SPEED100;
> >     >     > 
> >     >     > +#ifdef __rtems__
> >     >     > +#define STRINGIFY(to_str) #to_str
> >     >     > +#define BSP_STR(to_str) STRINGIFY(to_str)
> >     >     > +     /* Configure the PHYs to use SGMII for particular 
> BSPs */
> >     >     > +     if ( 0 == strcmp( BSP_STR(RTEMS_BSP),
> >     "xilinx_zynqmp_lp64_cfc400x" ) ) {
> >     >     > +             net_cfg |= CGEM_NET_CFG_SGMII_EN;
> >     >     > +             net_cfg |= CGEM_NET_CFG_PCS_SEL;
> >     >     > +     }
> >     >
> >     >     This makes it a precedent a cgem device has to be an RTEMS 
> BSP to
> >     support SGMII.
> >     >     I do not think that is a good idea.
> >     >
> >     > I don't particularly like this solution either, but I evaluated a
> few other
> >     > options (see below).
> >
> >     I also do not like it.
> >
> >     >     Is the simplest solution adding a weak function call asks 
> which mode
> >     and the
> >     >     default call returns RGMII?
> >     >
> >     > The downside to that is that none of the tests can operate as
> expected on a
> >     > SGMII-attached-PHY system since the application would be 
> overriding
> the weak
> >     > symbol and the tests wouldn't do that. Another option would be to 
> have a
> >     generic
> >     > option in RTEMS that specifies the PHY attachment and can be set 
> in
> >     config.ini,
> >     > but that would appear to be dead code since it's not used within 
> RTEMS.
> >
> >     Would FDT solve this problem? Forcing FDT support onto the cgem 
> driver
> would
> >     break compatibility so it would have to handle a default state. If 
> FDT
> probes
> >     were tolerant of calls without a valid FDT being loaded it would be
> better but
> >     our FDT support seems to have no middle ground from what I can see.
> >
> >
> > FDT could technically solve the problem, current driver support and PHY
> > transport option support notwithstanding. As you pointed out, there 
> isn't
> > currently a way to have both static configuration and FDT support at 
> the same
> > time and multiple BSPs across multiple architectures use the CGEM 
> support - at
> > least Zynq, ZynqMP, and Versal - all of which would need the appropriate
> support
> > added. I thought we had a RISC-V BSP that used it as well, but I don't 
> see
> it at
> > the moment.
> >
> >
> >     > As far as I'm aware, the closest analog in LibBSD would be the 
> buildset
> >     > configuration, but that seems more like a place to define which
> modules get
> >     > built than a location for configuring hardware.
> >
> >     I think FDT is handling this stuff for other archs and the MRMAC 
> will also
> >     require FDT support.
> >
> >
> > It is and the FDT support in this driver in FreeBSD 13 is a bit better.
> 
> Does this mean existing Zynq etc BSPs would need to add FDT support?
> 
> 
> Yes, unless there's a solution that allows both to exist at the same time. I
> haven't investigated that option thoroughly.

Maybe we meet up and discuss the options.

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

Re: [PATCH rtems-libbsd] freebsd/cgem: Use SGMII when necessary

[Chris Johns]

On 2/11/2022 1:18 pm, Kinsey Moore wrote:
> On Tue, Nov 1, 2022 at 5:49 PM Chris Johns  <mailto:chr...@rtems.org>> wrote:
> 
> On 2/11/2022 8:56 am, Kinsey Moore wrote:
> > On Tue, Nov 1, 2022 at 4:14 PM Chris Johns  <mailto:chr...@rtems.org>
> > <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>> wrote:
> >     On 2/11/2022 5:51 am, Kinsey Moore wrote:
> >     > Certain hardware configurations will always use SGMII instead of 
> RGMII.
> >     > Apply the appropriate flags for the relevant BSPs.
> >     > ---
> >     >  freebsd/sys/dev/cadence/if_cgem.c | 10 ++
> >     >  1 file changed, 10 insertions(+)
> >     >
> >     > diff --git a/freebsd/sys/dev/cadence/if_cgem.c
> >     b/freebsd/sys/dev/cadence/if_cgem.c
> >     > index 3eaaf6b2..9b4cf693 100644
> >     > --- a/freebsd/sys/dev/cadence/if_cgem.c
> >     > +++ b/freebsd/sys/dev/cadence/if_cgem.c
> >     > @@ -1296,6 +1296,16 @@ cgem_config(struct cgem_softc *sc)
> >     >               CGEM_NET_CFG_FULL_DUPLEX |
> >     >               CGEM_NET_CFG_SPEED100;
> >     > 
> >     > +#ifdef __rtems__
> >     > +#define STRINGIFY(to_str) #to_str
> >     > +#define BSP_STR(to_str) STRINGIFY(to_str)
> >     > +     /* Configure the PHYs to use SGMII for particular BSPs */
> >     > +     if ( 0 == strcmp( BSP_STR(RTEMS_BSP),
> "xilinx_zynqmp_lp64_cfc400x" ) ) {
> >     > +             net_cfg |= CGEM_NET_CFG_SGMII_EN;
> >     > +             net_cfg |= CGEM_NET_CFG_PCS_SEL;
> >     > +     }
> >
> >     This makes it a precedent a cgem device has to be an RTEMS BSP to
> support SGMII.
> >     I do not think that is a good idea.
> >
> > I don't particularly like this solution either, but I evaluated a few 
> other
> > options (see below).
> 
> I also do not like it.
> 
> >     Is the simplest solution adding a weak function call asks which mode
> and the
> >     default call returns RGMII?
> >
> > The downside to that is that none of the tests can operate as expected 
> on a
> > SGMII-attached-PHY system since the application would be overriding the 
> weak
> > symbol and the tests wouldn't do that. Another option would be to have a
> generic
> > option in RTEMS that specifies the PHY attachment and can be set in
> config.ini,
> > but that would appear to be dead code since it's not used within RTEMS.
> 
> Would FDT solve this problem? Forcing FDT support onto the cgem driver 
> would
> break compatibility so it would have to handle a default state. If FDT 
> probes
> were tolerant of calls without a valid FDT being loaded it would be 
> better but
> our FDT support seems to have no middle ground from what I can see.
> 
> 
> FDT could technically solve the problem, current driver support and PHY
> transport option support notwithstanding. As you pointed out, there isn't
> currently a way to have both static configuration and FDT support at the same
> time and multiple BSPs across multiple architectures use the CGEM support - at
> least Zynq, ZynqMP, and Versal - all of which would need the appropriate 
> support
> added. I thought we had a RISC-V BSP that used it as well, but I don't see it 
> at
> the moment.
> 
> 
> > As far as I'm aware, the closest analog in LibBSD would be the buildset
> > configuration, but that seems more like a place to define which modules 
> get
> > built than a location for configuring hardware.
> 
> I think FDT is handling this stuff for other archs and the MRMAC will also
> require FDT support.
> 
> 
> It is and the FDT support in this driver in FreeBSD 13 is a bit better.

Does this mean existing Zynq etc BSPs would need to add FDT support?

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

Re: [PATCH rtems-libbsd] freebsd/cgem: Use SGMII when necessary

[Chris Johns]

On 2/11/2022 8:56 am, Kinsey Moore wrote:
> On Tue, Nov 1, 2022 at 4:14 PM Chris Johns  <mailto:chr...@rtems.org>> wrote:
> On 2/11/2022 5:51 am, Kinsey Moore wrote:
> > Certain hardware configurations will always use SGMII instead of RGMII.
> > Apply the appropriate flags for the relevant BSPs.
> > ---
> >  freebsd/sys/dev/cadence/if_cgem.c | 10 ++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/freebsd/sys/dev/cadence/if_cgem.c
> b/freebsd/sys/dev/cadence/if_cgem.c
> > index 3eaaf6b2..9b4cf693 100644
> > --- a/freebsd/sys/dev/cadence/if_cgem.c
> > +++ b/freebsd/sys/dev/cadence/if_cgem.c
> > @@ -1296,6 +1296,16 @@ cgem_config(struct cgem_softc *sc)
> >               CGEM_NET_CFG_FULL_DUPLEX |
> >               CGEM_NET_CFG_SPEED100;
> > 
> > +#ifdef __rtems__
> > +#define STRINGIFY(to_str) #to_str
> > +#define BSP_STR(to_str) STRINGIFY(to_str)
> > +     /* Configure the PHYs to use SGMII for particular BSPs */
> > +     if ( 0 == strcmp( BSP_STR(RTEMS_BSP), 
> "xilinx_zynqmp_lp64_cfc400x" ) ) {
> > +             net_cfg |= CGEM_NET_CFG_SGMII_EN;
> > +             net_cfg |= CGEM_NET_CFG_PCS_SEL;
> > +     }
> 
> This makes it a precedent a cgem device has to be an RTEMS BSP to support 
> SGMII.
> I do not think that is a good idea.
> 
> I don't particularly like this solution either, but I evaluated a few other
> options (see below).

I also do not like it.

> Is the simplest solution adding a weak function call asks which mode and 
> the
> default call returns RGMII?
> 
> The downside to that is that none of the tests can operate as expected on a
> SGMII-attached-PHY system since the application would be overriding the weak
> symbol and the tests wouldn't do that. Another option would be to have a 
> generic
> option in RTEMS that specifies the PHY attachment and can be set in 
> config.ini,
> but that would appear to be dead code since it's not used within RTEMS.

Would FDT solve this problem? Forcing FDT support onto the cgem driver would
break compatibility so it would have to handle a default state. If FDT probes
were tolerant of calls without a valid FDT being loaded it would be better but
our FDT support seems to have no middle ground from what I can see.

> As far as I'm aware, the closest analog in LibBSD would be the buildset
> configuration, but that seems more like a place to define which modules get
> built than a location for configuring hardware.

I think FDT is handling this stuff for other archs and the MRMAC will also
require FDT support.

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

Re: [PATCH rtems-lwip 1/2] lwip.py: Remove redundant assignment

[Chris Johns]

+1

On 2/11/2022 7:28 am, Vijay Kumar Banerjee wrote:
> Hi Kinsey,
> 
> The patches look great. Thanks for the cleanup.
> 
> 
> Best regards,
> Vijay
> 
> On Tue, Nov 1, 2022 at 1:51 PM Kinsey Moore  wrote:
>>
>> ---
>>  lwip.py | 2 --
>>  1 file changed, 2 deletions(-)
>>
>> diff --git a/lwip.py b/lwip.py
>> index c11ed1f..e6580eb 100644
>> --- a/lwip.py
>> +++ b/lwip.py
>> @@ -214,8 +214,6 @@ def build(bld):
>>  lib=['rtemscpu', 'rtemsbsp', 'rtemstest', 'lwip'],
>>  includes=' '.join(test_app_incl))
>>
>> -arch_lib_path = rtems.arch_bsp_lib_path(bld.env.RTEMS_VERSION,
>> -bld.env.RTEMS_ARCH_BSP)
>>  lib_path = os.path.join(bld.env.PREFIX, arch_lib_path)
>>  bld.read_stlib('telnetd', paths=[lib_path])
>>  bld.read_stlib('rtemstest', paths=[lib_path])
>> --
>> 2.30.2
>>
>> ___
>> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] zynqmp: Add support for the CFC-400X

[Chris Johns]

On 2/11/2022 8:15 am, Kinsey Moore wrote:
> On Tue, Nov 1, 2022 at 3:59 PM Chris Johns  <mailto:chr...@rtems.org>> wrote:
> 
> On 2/11/2022 5:38 am, Kinsey Moore wrote:> +#ifdef
> BSP_XILINX_ZYNQMP_MGMT_UART_BASE
> > +/**
> > + * @brief Zynq UltraScale+ MPSoC specific set up of a management 
> console.
> > + *
> > + * The ZynqMP SoC's programmable logic can provide a serial interface 
> for
> system
> > + * management which may need special initialization. Provide in the
> application
> > + * to override the defaults in the BSP.
> > + */
> 
> I am not comfortable with PL implementation dependences for specific 
> hardware
> being added to the generic BSP code. The Zynq, ZymqMP and Versal have so 
> far
> only referenced the hard IP.
> 
> Is the PL project and implementation for the PL logic openly available?
> 
> Unfortunately, not as far as I'm aware. The management interface is guaranteed
> to exist as a 16550 UART on all variants of the system and, from the RTEMS
> perspective, the PL is a locked/hard part of the system.

The PL is anything but hard, it is a feature of the device.

> The hardware requires I request a data sheet from the manufacturer and 
> that
> makes keeping this code in our open repo difficult.
> 
> I understand. The unfortunate part of this is that RTEMS isn't usable on this
> platform beyond a couple of seconds without pushing off the system watchdog 
> via
> the 16550 UART. I have automated the watchdog parameter manipulation 
> externally
> for testing purposes, but a system running outside that harness would 
> encounter
> problems with many tests in the testsuite.

I am not sure I am following. Have they wired a watchdog to accessing the UART?

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

Re: [PATCH rtems-libbsd] freebsd/cgem: Use SGMII when necessary

[Chris Johns]

On 2/11/2022 5:51 am, Kinsey Moore wrote:
> Certain hardware configurations will always use SGMII instead of RGMII.
> Apply the appropriate flags for the relevant BSPs.
> ---
>  freebsd/sys/dev/cadence/if_cgem.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/freebsd/sys/dev/cadence/if_cgem.c 
> b/freebsd/sys/dev/cadence/if_cgem.c
> index 3eaaf6b2..9b4cf693 100644
> --- a/freebsd/sys/dev/cadence/if_cgem.c
> +++ b/freebsd/sys/dev/cadence/if_cgem.c
> @@ -1296,6 +1296,16 @@ cgem_config(struct cgem_softc *sc)
>   CGEM_NET_CFG_FULL_DUPLEX |
>   CGEM_NET_CFG_SPEED100;
>  
> +#ifdef __rtems__
> +#define STRINGIFY(to_str) #to_str
> +#define BSP_STR(to_str) STRINGIFY(to_str)
> + /* Configure the PHYs to use SGMII for particular BSPs */
> + if ( 0 == strcmp( BSP_STR(RTEMS_BSP), "xilinx_zynqmp_lp64_cfc400x" ) ) {
> + net_cfg |= CGEM_NET_CFG_SGMII_EN;
> + net_cfg |= CGEM_NET_CFG_PCS_SEL;
> + }

This makes it a precedent a cgem device has to be an RTEMS BSP to support SGMII.
I do not think that is a good idea.

Is the simplest solution adding a weak function call asks which mode and the
default call returns RGMII?

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

Re: Fwd: Identify 3rd party source in spec?

[Chris Johns]

On 2/11/2022 3:25 am, o...@c-mauderer.de wrote:> Is it a good idea to make it a
mandatory attribute? It makes the yaml files
> bigger. It will only mean that we have to look for copy and paste bugs instead
> of missing attributes if someone adds a new third party library.

Can you avoid having to add the item to all? I am no spec build system expert
(having invested time) and seem to remember needing to hit a lot of files when
adding something ...

https://git.rtems.org/rtems/commit/?id=6f2aa8ad36e3aaffc9fa2cb8c744b04da7339ee2

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

Re: [PATCH] zynqmp: Add support for the CFC-400X

[Chris Johns]

On 2/11/2022 5:38 am, Kinsey Moore wrote:> +#ifdef 
BSP_XILINX_ZYNQMP_MGMT_UART_BASE
> +/**
> + * @brief Zynq UltraScale+ MPSoC specific set up of a management console.
> + *
> + * The ZynqMP SoC's programmable logic can provide a serial interface for 
> system
> + * management which may need special initialization. Provide in the 
> application
> + * to override the defaults in the BSP.
> + */

I am not comfortable with PL implementation dependences for specific hardware
being added to the generic BSP code. The Zynq, ZymqMP and Versal have so far
only referenced the hard IP.

Is the PL project and implementation for the PL logic openly available?

The hardware requires I request a data sheet from the manufacturer and that
makes keeping this code in our open repo difficult.

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

[RBW] Re: Video: Vintage lugged steel mixte restoration

[JohnS]

Nice looking mixte Paul. I see you have an Uno seat post as well. As I 
recall the Shogun had an odd size, not too many options to chose from.

JohnS

On Monday, October 31, 2022 at 7:46:16 PM UTC-4 Paul in Dallas wrote:

>
>
>
>
> I've got the 1973 Nishiki low step 22" frame going and it's a nice riding 
> bike.
>
> I have a tan saddle on the way and a few other changes planned.
>
> Remarkable to think it will be 50 years old next year and going strong.
>
> When I get too decrepit to straddle a diamond frame perhaps I can straddle 
> this. 
> Ha! 
> Or acquire a low step Riv.
>
> Paul in Dallas.
> .
>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/0c30a272-7067-4854-9df8-62799d6ba8f1n%40googlegroups.com.

Re: [PATCH 1/2] bsps/riscv: Remove inaccurate statement about reliance on a boot loader

[Chris Johns]

On 31/10/2022 10:44 pm, Hesham Almatary wrote:
> Hello,
> 
> I tried to push that but got an error message:
> "remote: git_buildbot: ERROR: Could not connect to
> buildbot.int.rtems.org:9899: Connection was refused by other side: 61:
> Connection refused."

Please try again. We have had some server issues.

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

Re: Text Formatting Patches coming

[Chris Johns]

On 1/11/2022 2:59 am, Gedare Bloom wrote:
> I am planning to roll out several text formatting changes over the
> next 6 weeks or so, to include:
> 1. Removal of URLs from Copyright lines as per #4636. Note: Most of
> the included URLs currently are from EB or Chris Johns (Contemporary
> Software).
> 2. Consistent capitalization of Copyright (C) in file header blocks as
> per #4637.
> * Style Updates as per #3860.
> 
> This effort will include documentation, inclusion of automation tools,
> and 3rd party software management. I will send patches and give notice
> before any changes hit, but I wanted to give a heads up here that this
> process will be taking place. If you have any specific requests or
> patches pending in an area that I should avoid for now, please let me
> know.

Sounds good and looking forward to seeing this happen.

Where is the clang-format style? I would like to play and have look at the 
results?

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

[RBW] Re: Philadelphia Bike Expo 2022

[JohnS]

Looking forward to seeing everyone on Saturday! I'll be at the food court 
for 12:30 to say hello. Otherwise I'll be taking it all in and picking up 
my free gift from Will, when I say, "and I for one welcome our new insect 
overlords". LOL!

JohnS

On Wednesday, October 26, 2022 at 9:25:50 PM UTC-4 Pam Bikes wrote:

> I'll be riding to the Expo Sat 
> <https://phillybikeexpo.com/ride-to-pbe22/>morning, 
> doing a demo at 1:30 
> <https://phillybikeexpo.com/meet-my-rivendell-betty-foy-my-daily-drive-how-to-set-up-your-bike-for-everyday-use-like-your-car/>
>  
> and riding to the Keystone Party 
> <https://phillybikeexpo.com/ride-with-cyclingsavvy-to-keystone-bikes/>.  
> Details on PBE website.  Please come see me and ride w/me.  
>
> On Wednesday, October 26, 2022 at 6:36:39 PM UTC-4 Roberta wrote:
>
>> I got this update to the bike expo in my email today.  Lots of 
>> information, including a press release:  
>> https://madmimi.com/p/dc7ae41?pact=367096-170142516-11332754941-2829bc1df8e3bd915158a7aa4c23f05462633058
>>   
>>
>>
>> From the press release, which you can read in full, embedded in the above 
>> link.:
>>
>> "The exhibitor count is approaching all-time pre-pandemic highs... an 
>> exhibitor list of 160 brands, up 40 percent over last year’s tentative 
>> post-pandemic expo. Pre-event ticket sales have been very healthy too.
>>
>> "The popular PBE Food Court is back in the exhibition hall with the same 
>> range of offerings as pre-pandemic."
>>
>> Want to meet at the Food Court around 12:30 for a meet and great?  You 
>> know what Leah looks like.  You know what Pam looks like.  I am tall-ish 
>> and have short white hair and will probably be near them.  
>>
>> Weather Saturday and Sunday:  low 41, high 63.  Sunny.  No rain.
>>
>> Contact me off list if you need anything local.
>>
>> Roberta
>>
>>
>>
>>
>> On Friday, October 14, 2022 at 11:24:16 AM UTC-4 Pam Bikes wrote:
>>
>>> I can't wait to meet ya'll  I'l be flying and boxing my bike (Betty 
>>> Foy).  I'll be doing a demo of what to carry on your bike and how to carry 
>>> stuff and hope to give a presentation on ideas to build bike community and 
>>> culture.  I'll be helping w/a ride Sat mornining to the Expo and another 
>>> from the Expo to the Keystone Bike Party Sat night.  I think there's a Riv 
>>> sisters Fri night ride brewing too - I guess guys will be invited but will 
>>> need to follow us.  I'm always up for a ride and have a dyno so I ride all 
>>> the time.  I'm not on the group all the time but I check email all the 
>>> time.  Working on details, routes, etc.  But email me for any questions.  
>>> For example, Joe, just box the bike.  Watch the video on Riv.  I think it's 
>>> Emilio packing a bike to ship.  It's easy to pack and only $30 like a 
>>> checked bag.  I put the duffle bag backpack straps on so my hands are free 
>>> to carry the bike box to check it at the airport.  If I can do it, you can 
>>> too.  I'm smaller than you.  
>>>
>>> Picture from last weeks 367 mile ride across NC on my Betty Foy.  p.s. 
>>> that's a My Little Pony I found.[image: IMG_5928.JPG]
>>>
>>> On Tuesday, October 4, 2022 at 7:09:59 PM UTC-4 eric...@gmail.com wrote:
>>>
>>>> Joe — I went to PBE for the first time last year. Not sure I'll make it 
>>>> this year. There are lots of vendors displaying all kinds of cycling 
>>>> related stuff: bike makers of all kinds, bag and luggage makers, tool 
>>>> makers and anything else you can think of. There are food, beer and coffee 
>>>> vendors as well. 
>>>>
>>>> Russ's video from PBE a few years ago 
>>>> <https://www.youtube.com/watch?v=nEDra8YR8-s> gives a pretty good idea 
>>>> of the flow of things. 
>>>>
>>>> I found it helpful to do a quick surface walk around all the booths and 
>>>> displays without stopping, then returning to check out booths that caught 
>>>> my attention. There is no end of stuff to dive into and people to chat 
>>>> with. 
>>>>
>>>> Things I'd check out this year: Rivendell, Paul Component, King Cage, 
>>>> Silca, Chapman Cycles, Fat Chance, Sal's Bikes, Jubilee Mfg, Breadwinner, 
>>>> Merry Sales, White Ind, Velocity, Sinewave. Whoever has good decaf 
>>>> espresso. Always cool to check in with yr fave brands because they often 
>>>> have custom swag. 
>>>>
>

Re: [PATCH 1/2] bsps/aarch64: Ensure FPU trap state is consistent

[Chris Johns]

On 28/10/2022 9:57 am, Kinsey Moore wrote:
> 
> On Thu, Oct 27, 2022 at 5:46 PM Chris Johns  <mailto:chr...@rtems.org>> wrote:
> 
> On 28/10/2022 9:25 am, Kinsey Moore wrote:
> > On Thu, Oct 27, 2022 at 5:10 PM Chris Johns  <mailto:chr...@rtems.org>
> > <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>> wrote:
> >
> >     On 28/10/2022 9:05 am, Kinsey Moore wrote:
> >     > RTEMS may be booted from a dirty environment. Ensure that FPU trap
> >     > settings are consistent.
> >     > ---
> >     >  bsps/aarch64/shared/start/start.S | 10 ++
> >     >  1 file changed, 10 insertions(+)
> >     >
> >     > diff --git a/bsps/aarch64/shared/start/start.S
> >     b/bsps/aarch64/shared/start/start.S
> >     > index 8bd4f86f4e..de0fdf4c80 100644
> >     > --- a/bsps/aarch64/shared/start/start.S
> >     > +++ b/bsps/aarch64/shared/start/start.S
> >     > @@ -307,6 +307,16 @@ _el1_start:
> >     > 
> >     >    /* FPU does not need to be enabled on AArch64 */
> >     > 
> >     > +  /* Ensure FPU traps are disabled by default */
> >     > +  mrs x0, FPCR
> >     > +  bic x0, x0, #(1 << 8)
> >     > +  bic x0, x0, #(1 << 9)
> >     > +  bic x0, x0, #(1 << 10)
> >     > +  bic x0, x0, #(1 << 11)
> >     > +  bic x0, x0, #(1 << 12)
> >     > +  bic x0, x0, #(1 << 15)
> >
> >     Does `bic x0, x0, #((1 << 8) | (1 << 9) | (1 << 10) | ...)` work?
> >
> > The assembler complains about the operand being out of range. I can 
> split it
> > into 8-12 in one and 15 by itself and everything seems to work.
> 
> Huh? If you use a hex value does it work?
> 
> I think the equivalent value would be 0x9f00. That generates the same error as
> putting all the components on the same line. I think there's a 6-bit immediate
> involved that's the limitation.

Ah, must be an aarch64 thing. I have been using ARM and thumb mode asm this 
week :)

I will leave this with you to sort out which is best.

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

Re: [PATCH 1/2] bsps/aarch64: Ensure FPU trap state is consistent

[Chris Johns]

On 28/10/2022 9:25 am, Kinsey Moore wrote:
> On Thu, Oct 27, 2022 at 5:10 PM Chris Johns  <mailto:chr...@rtems.org>> wrote:
> 
> On 28/10/2022 9:05 am, Kinsey Moore wrote:
> > RTEMS may be booted from a dirty environment. Ensure that FPU trap
> > settings are consistent.
> > ---
> >  bsps/aarch64/shared/start/start.S | 10 ++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/bsps/aarch64/shared/start/start.S
> b/bsps/aarch64/shared/start/start.S
> > index 8bd4f86f4e..de0fdf4c80 100644
> > --- a/bsps/aarch64/shared/start/start.S
> > +++ b/bsps/aarch64/shared/start/start.S
> > @@ -307,6 +307,16 @@ _el1_start:
> > 
> >    /* FPU does not need to be enabled on AArch64 */
> > 
> > +  /* Ensure FPU traps are disabled by default */
> > +  mrs x0, FPCR
> > +  bic x0, x0, #(1 << 8)
> > +  bic x0, x0, #(1 << 9)
> > +  bic x0, x0, #(1 << 10)
> > +  bic x0, x0, #(1 << 11)
> > +  bic x0, x0, #(1 << 12)
> > +  bic x0, x0, #(1 << 15)
> 
> Does `bic x0, x0, #((1 << 8) | (1 << 9) | (1 << 10) | ...)` work?
> 
> The assembler complains about the operand being out of range. I can split it
> into 8-12 in one and 15 by itself and everything seems to work.

Huh? If you use a hex value does it work?

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

Re: [PATCH 1/2] bsps/aarch64: Ensure FPU trap state is consistent

[Chris Johns]

On 28/10/2022 9:05 am, Kinsey Moore wrote:
> RTEMS may be booted from a dirty environment. Ensure that FPU trap
> settings are consistent.
> ---
>  bsps/aarch64/shared/start/start.S | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/bsps/aarch64/shared/start/start.S 
> b/bsps/aarch64/shared/start/start.S
> index 8bd4f86f4e..de0fdf4c80 100644
> --- a/bsps/aarch64/shared/start/start.S
> +++ b/bsps/aarch64/shared/start/start.S
> @@ -307,6 +307,16 @@ _el1_start:
>  
>/* FPU does not need to be enabled on AArch64 */
>  
> +  /* Ensure FPU traps are disabled by default */
> +  mrs x0, FPCR
> +  bic x0, x0, #(1 << 8)
> +  bic x0, x0, #(1 << 9)
> +  bic x0, x0, #(1 << 10)
> +  bic x0, x0, #(1 << 11)
> +  bic x0, x0, #(1 << 12)
> +  bic x0, x0, #(1 << 15)

Does `bic x0, x0, #((1 << 8) | (1 << 9) | (1 << 10) | ...)` work?

The operand2 is a mask of bits to clear.

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

Re: Increase Frequency of Updates of RTEMS GitHub Tools Mirroring

[Chris Johns]

Hi Christian,

Thank you for your considered comments.

On 27/10/2022 12:06 am, Christian MAUDERER wrote:
> Am 26.10.22 um 01:06 schrieb Chris Johns:
>> On 26/10/2022 4:46 am, Joel Sherrill wrote:
>>>  In general, our current approach is quite a hack. We should do things
>>>  more event driven. For example, if you want to update the RSB, then you
>>>  create a pull request. This pull request starts a CI script which
>>>  updates the mirrors and builds the RSB on a selected set of platforms.
>>>  If everything is all right, the pull request can be merged.
>>>
>>> Just getting to the point where a pull request triggered an update would
>>> be useful. Assuming a pull request with no content would be ok.
>>
>> I feel starting to have pull requests will only result in changes being 
>> posted
>> there by users who see pull requests as active. It is reasonable for a user 
>> to
>> think this. Who will then field those and merge them?
>>
>> Chris
> 
> Hello Chris,
> 
> I agree that as long as the RTEMS project doesn't officially use pull 
> requests,
> it's not a good idea to have something that looks official but isn't used. On
> the other hand, I think that it would be a really good idea for the RTEMS
> project to migrate to a patch management system where a pull-request with
> automated CI run is the official method for contributing.

I would love a patch management system to be in place. Getting consensus on what
to use, how we host it, who does the work and who maintains it is hard.

> That would take a lot
> of work from the shoulders of the maintainers because for a lot of patches, no
> more manual tests whether the patch builds would be necessary. Of course the
> patch would still need review.

No question that would be the case. A good tool will also manage CI to make sure
we have buildable commits entering the repo.

> Beneath that, a system with pull requests usually has a nice overview over
> pending patches. At the moment we have patches on the mailing list mixed with
> discussions.

Yes this is true and I would like to add pull requests are widely used and
people know how to use them and trust them and this is important for us long
term. We need to stay current in the tools and methods we employ.

> A user has to get the attention of a maintainer to get a patch
> merged. Users that don't want to be pushy maybe don't ping such patches or 
> some
> might just forget that they send a patch to the list.

Agreed. I am guilty of forgetting.

> I'm sure that we lost
> quite a few patches due to that because no one felt responsible, no one noted
> the patch or no one had the time to test the patches before merging them.

I also think this is true.

> I know that I have even lost some of my own patches on the list because no one
> acknoledged them and I started to work on something else and forget them. I
> found some a few months later and was surprised that I didn't push them. I
> wouldn't guarantee that I found all of them. A patch management system should
> help to see whether there are still open ones.

Good to know I am not the only one.

> PS: I already mentioned it in another mail: I started to build some github CI
> scripts that we at embedded brains want to use for testing our own public
> patches. Github doesn't seem to limit the CI time on public projects so 
> everyone
> who wants to play a bit with it: Feel free to create pull requests to see how
> something like that works. Just select the "ci" branch on
> 
>   https://github.com/embedded-brains/rtems
> 
> That repo is clearly a fork (marked with "forked from RTEMS/rtems" so I don't
> see the risk that someone mixes it up with the official repos. But if unknown
> users will use it to create pull requests, I'll add a comment to the pull
> requests, that patches should be sent to the mailing list instead. If there 
> are
> a lot of unknown users, I'll automate the comments.

Yes I remember, maybe on discord. I took a look and it is nice. It is great to
see support companies running CI flows. OAR has tools builds and simulator test
runs posting to build results to the builds list and this is great and 
important.

I would like to see more hardware test runs and posted results. Does EB have any
plans to run the testsuite on hardware and post the results to builds?

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

Re: Increase Frequency of Updates of RTEMS GitHub Tools Mirroring

[Chris Johns]

On 26/10/2022 4:46 am, Joel Sherrill wrote:
> In general, our current approach is quite a hack. We should do things
> more event driven. For example, if you want to update the RSB, then you
> create a pull request. This pull request starts a CI script which
> updates the mirrors and builds the RSB on a selected set of platforms.
> If everything is all right, the pull request can be merged.
> 
> Just getting to the point where a pull request triggered an update would
> be useful. Assuming a pull request with no content would be ok.

I feel starting to have pull requests will only result in changes being posted
there by users who see pull requests as active. It is reasonable for a user to
think this. Who will then field those and merge them?

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

Re: [PATCH] bsps/microblaze: Fix console interrupt build errors

[Chris Johns]

OK to push

Chris

On 25/10/2022 12:36 pm, Alex White wrote:
> This fixes build errors seen when building with console interrupts
> enabled. A few places were missing bspopts.h includes, and one of the
> UART functions was not defined.
> ---
>  bsps/microblaze/include/dev/serial/uartlite.h  |  1 +
>  .../microblaze/include/dev/serial/uartlite_l.h | 18 ++
>  bsps/microblaze/shared/dev/serial/uartlite.c   |  3 ++-
>  3 files changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/bsps/microblaze/include/dev/serial/uartlite.h 
> b/bsps/microblaze/include/dev/serial/uartlite.h
> index 6e288d4dc7..2fda3796b3 100644
> --- a/bsps/microblaze/include/dev/serial/uartlite.h
> +++ b/bsps/microblaze/include/dev/serial/uartlite.h
> @@ -36,6 +36,7 @@
>  #ifndef LIBBSP_MICROBLAZE_SHARED_UARTLITE_H
>  #define LIBBSP_MICROBLAZE_SHARED_UARTLITE_H
>  
> +#include 
>  #include 
>  
>  #include 
> diff --git a/bsps/microblaze/include/dev/serial/uartlite_l.h 
> b/bsps/microblaze/include/dev/serial/uartlite_l.h
> index 8c0598e191..834fbb5f75 100644
> --- a/bsps/microblaze/include/dev/serial/uartlite_l.h
> +++ b/bsps/microblaze/include/dev/serial/uartlite_l.h
> @@ -234,6 +234,24 @@ static inline void Xil_Out32(UINTPTR Addr, u32 Value)
>((XUartLite_GetStatusReg((BaseAddress)) & XUL_SR_RX_FIFO_VALID_DATA) != \
>   XUL_SR_RX_FIFO_VALID_DATA)
>  
> +#ifdef __rtems__
> +//
> +/**
> +*
> +* Check to see if the transmitter is empty.
> +*
> +* @param BaseAddress is the  base address of the device
> +*
> +* @returnTRUE if the transmitter is empty, FALSE otherwise.
> +*
> +* @note  C-style Signature:
> +*int XUartLite_IsTransmitEmpty(u32 BaseAddress);
> +*
> +*/
> +#define XUartLite_IsTransmitEmpty(BaseAddress) \
> +  ((XUartLite_GetStatusReg((BaseAddress)) & XUL_SR_TX_FIFO_EMPTY) == \
> + XUL_SR_TX_FIFO_EMPTY)
> +#endif /* __rtems__ */
>  
>  
> //
>  /**
> diff --git a/bsps/microblaze/shared/dev/serial/uartlite.c 
> b/bsps/microblaze/shared/dev/serial/uartlite.c
> index 7387e22635..a5fc4fe82b 100644
> --- a/bsps/microblaze/shared/dev/serial/uartlite.c
> +++ b/bsps/microblaze/shared/dev/serial/uartlite.c
> @@ -35,6 +35,7 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  #ifdef BSP_MICROBLAZE_FPGA_CONSOLE_INTERRUPTS
>  static void microblaze_uart_interrupt( void *arg )
> @@ -47,7 +48,7 @@ static void microblaze_uart_interrupt( void *arg )
>  rtems_termios_enqueue_raw_characters( tty, , 1 );
>}
>  
> -  while ( ctx->transmitting && !XUartLite_IsTransmitEmpty( ctx ) ) {
> +  while ( ctx->transmitting && !XUartLite_IsTransmitEmpty( ctx->address ) ) {
>  rtems_termios_dequeue_characters( tty, 1 );
>}
>  }
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] testproc/gsed: fix compilation of GNU sed on Mac OS X

[Chris Johns]

Looks good. Ok to push.

Thanks
Chris

On 24/10/2022 8:36 am, Karel Gardas wrote:
> GNU sed compiles on Mac OS X fine, but without providing --host/--build
> configure options. Hence removing them solved the issue of configure
> not being able to recognize arm64-darwin platform.
> ---
>  source-builder/config/gsed-1.cfg | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/source-builder/config/gsed-1.cfg 
> b/source-builder/config/gsed-1.cfg
> index 828da50..87eb0fb 100644
> --- a/source-builder/config/gsed-1.cfg
> +++ b/source-builder/config/gsed-1.cfg
> @@ -86,7 +86,6 @@ URL:   https://www.gnu.org/software/sed/
>  --mandir=%{gsed_mandir} \
>  --infodir=%{gsed_infodir} \
>  --datadir=%{gsed_datadir} \
> ---build=%{_build} --host=%{_host}
>  
>%{__make} %{?_smp_mflags} all
>  
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Intention behind `adelete` being a queryset method, and not available on a model instance?

[Jason Johns]

The explanation makes sense, which is one thing that’s making me feel this 
is something to be called out in the documentation, because it is a 
difference in expectations in the api interface. Since a model has a delete 
method, as does a queryset, the absence of that equivalence for async is 
not what I would expect and it’s not obvious why. 
On Friday, October 21, 2022 at 12:29:31 PM UTC-4 Adam Johnson wrote:

> I opened a ticket to add async methods to Model: 
> https://code.djangoproject.com/ticket/34112
>
> This would be released in Django 4.2, at minimum.
>
> Using async to perform model updates is not likely to be performant, since 
> the queries end up being processed synchronously on a thread anyway. This 
> is because the database libraries Django supports don't have async 
> interfaces.
>
> On Fri, Oct 21, 2022 at 4:49 PM Adam Johnson  wrote:
>
>> If you have a suggestion, sure. But from my perspective the docs are 
>> clear. There's an adelete() method doc'd for QuerySet, and not for Model, 
>> and the release note 
>> <https://docs.djangoproject.com/en/4.1/releases/4.1/#asynchronous-orm-interface>
>>  
>> says “QuerySet now provides an asynchronous interface...”.
>>
>> On Fri, Oct 21, 2022 at 3:51 PM Jason Johns  wrote:
>>
>>> gotcha, then perhaps a documentation tweak would be in order, on both 
>>> queryset and model pages?  because as is, its unclear this is expected.
>>>
>>> On Friday, October 21, 2022 at 9:57:33 AM UTC-4 Adam Johnson wrote:
>>>
>>>> This is intentional, as it stands. Django 4.1 only added async QuerySet 
>>>> methods, not async Model methods. Async model methods like adelete(), and 
>>>> perhaps asave(), would be the next logical step.
>>>>
>>>> On Fri, Oct 21, 2022 at 1:47 PM Jason Johns  wrote:
>>>>
>>>>> I came across a reddit post yesterday 
>>>>> <https://www.reddit.com/r/django/comments/y7w5dm/django_async_delete_from_db/>about
>>>>>  
>>>>> `adelete` raising an attribute error
>>>>>
>>>>> r = await mymodel.objects.aget(some_name=myname) 
>>>>> await r.adelete()
>>>>>
>>>>> would throw an `AttributeError`,
>>>>>
>>>>> whereas r = await mymodel.objects.filter(some_name=myname).adelete() 
>>>>> works as expected.
>>>>>
>>>>> I was a little curious about this, and adelete 
>>>>> <https://docs.djangoproject.com/en/4.1/ref/models/querysets/#django.db.models.query.QuerySet.adelete>
>>>>>  is 
>>>>> explicitly called out in the queryset docs within the `delete` section.  
>>>>> but the models doc page  
>>>>> <https://docs.djangoproject.com/en/4.1/ref/models/instances/#deleting-objects>only
>>>>>  
>>>>> contains items about `delete`.  Is this intentional or not, and if it is 
>>>>> intentional, perhaps a specific call-out in both queryset and model 
>>>>> delete 
>>>>> sections would help with clarification.
>>>>>
>>>>> -- 
>>>>> You received this message because you are subscribed to the Google 
>>>>> Groups "Django developers (Contributions to Django itself)" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>>> an email to django-develop...@googlegroups.com.
>>>>> To view this discussion on the web visit 
>>>>> https://groups.google.com/d/msgid/django-developers/82ba40ef-ea73-4492-a2c3-448dbd1b9245n%40googlegroups.com
>>>>>  
>>>>> <https://groups.google.com/d/msgid/django-developers/82ba40ef-ea73-4492-a2c3-448dbd1b9245n%40googlegroups.com?utm_medium=email_source=footer>
>>>>> .
>>>>>
>>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to django-develop...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/cbb9dbba-be64-4c97-abfe-0b42ed42ddb3n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/django-developers/cbb9dbba-be64-4c97-abfe-0b42ed42ddb3n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f49f87ed-166e-4da8-baba-218b2da485a2n%40googlegroups.com.

Re: Intention behind `adelete` being a queryset method, and not available on a model instance?

[Jason Johns]

gotcha, then perhaps a documentation tweak would be in order, on both 
queryset and model pages?  because as is, its unclear this is expected.

On Friday, October 21, 2022 at 9:57:33 AM UTC-4 Adam Johnson wrote:

> This is intentional, as it stands. Django 4.1 only added async QuerySet 
> methods, not async Model methods. Async model methods like adelete(), and 
> perhaps asave(), would be the next logical step.
>
> On Fri, Oct 21, 2022 at 1:47 PM Jason Johns  wrote:
>
>> I came across a reddit post yesterday 
>> <https://www.reddit.com/r/django/comments/y7w5dm/django_async_delete_from_db/>about
>>  
>> `adelete` raising an attribute error
>>
>> r = await mymodel.objects.aget(some_name=myname) 
>> await r.adelete()
>>
>> would throw an `AttributeError`,
>>
>> whereas r = await mymodel.objects.filter(some_name=myname).adelete() 
>> works as expected.
>>
>> I was a little curious about this, and adelete 
>> <https://docs.djangoproject.com/en/4.1/ref/models/querysets/#django.db.models.query.QuerySet.adelete>
>>  is 
>> explicitly called out in the queryset docs within the `delete` section.  
>> but the models doc page  
>> <https://docs.djangoproject.com/en/4.1/ref/models/instances/#deleting-objects>only
>>  
>> contains items about `delete`.  Is this intentional or not, and if it is 
>> intentional, perhaps a specific call-out in both queryset and model delete 
>> sections would help with clarification.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/82ba40ef-ea73-4492-a2c3-448dbd1b9245n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/82ba40ef-ea73-4492-a2c3-448dbd1b9245n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cbb9dbba-be64-4c97-abfe-0b42ed42ddb3n%40googlegroups.com.

Intention behind `adelete` being a queryset method, and not available on a model instance?

[Jason Johns]

I came across a reddit post yesterday 
about
 
`adelete` raising an attribute error

r = await mymodel.objects.aget(some_name=myname) 
await r.adelete()

would throw an `AttributeError`,

whereas r = await mymodel.objects.filter(some_name=myname).adelete() works 
as expected.

I was a little curious about this, and adelete 

 is 
explicitly called out in the queryset docs within the `delete` section.  
but the models doc page  
only
 
contains items about `delete`.  Is this intentional or not, and if it is 
intentional, perhaps a specific call-out in both queryset and model delete 
sections would help with clarification.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/82ba40ef-ea73-4492-a2c3-448dbd1b9245n%40googlegroups.com.

Re: [PATCH rtems-docs v2] user/bsps: Update riscv for PolarFire SoC

[Chris Johns]

On 21/10/2022 4:04 pm, padmarao.beg...@microchip.com wrote:
> The Patch v1 was reviewed by Alan, update few comments, and submitted Patch 
> v2.
>  https://lists.rtems.org/pipermail/devel/2022-October/073469.html - Patch v1
> 
> https://lists.rtems.org/pipermail/devel/2022-October/073528.html - Patch v2
> 
> Can you please review or merge it to rtems-docs git?

Sorry about the delay. I have merged the patch based on Alan's review.

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

Re: [libbsd 00/22] Remove FreeBSD file descriptors and avoid VFS

[Chris Johns]

On 20/10/2022 7:01 pm, Sebastian Huber wrote:
> On 29/08/2022 10:27, Sebastian Huber wrote:
>> Hello Chris,
>>
>> On 25/07/2022 08:12, Sebastian Huber wrote:
>>> On 11/07/2022 15:04, Sebastian Huber wrote:
 On 24/06/2022 08:33, Sebastian Huber wrote:
> This patch set removes the FreeBSD file descriptors.  The VFS is no longer
> used
> if only the USB, SD/MMC, network, PCI, and NVMe support is used by the
> application.  This change significantly reduce the memory usage of LibBSD 
> for
> these applications.  Using the media01 test case for the arm/lpc32xx BSP 
> as a
> benchmark, the heap usage dropped from 14.3MiB to 10.2MiB.  The "_BSD
> bufdaemon", "_BSD vnlru", "_BSD syncer", and "_BSD bufspacedaemon-" tasks 
> are
> no longer present in media01.  The code size is reduced by about 8KiB.  
> The
> data size is reduced by about 30KiB.  The throughput with a simple FTP 
> test
> increased by about 1%.
>
> The "Remove FreeBSD file descriptors" change removes more lines than 
> there are
> added.
>
> This change makes it easier to port the NFS support to the master branch 
> since
> now the changes are more localized.

 I have a target with only 8MiB of RAM (for code and data). So, this patch
 set is not just a micro optimization.
>>>
>>> This pending patch set is currently a blocker for me. I would like to work 
>>> on
>>> the NTP daemon integration and an update of the libbsd master branch to a
>>> more recent FreeBSD version. This patch set just restores what worked well
>>> for several years.
>>
>> did you have time to review this patch set in the meantime? The NTP client no
>> longer crashes with this patch set.
> 
> This patch set is now pending for about four months. From my point of view it 
> is
> a straight forward fix of some severe issues which prevent the use of libbsd 
> on
> lower end targets.

Is there a repo somewhere with the patches applied? I am being lazy asking as I
would like to avoid downloading the 22 patches and applying them by hand.

It seems the media test cannot grow by more than 9K of code and the heap by 5M!
Is my understanding correct? Anything else we need to understand about the low
end limits?

I have not seen any requirements on the lower end for libbsd before now. How do
we manage the competing requirement of low end support and adding functionality
to libbsd in the future if they clash?

Adding VFS support as FreeBSD implements it has pushed you over the edge but
that edge is not defined so it makes it difficult for anyone other than you to
work on this code base in a major way. I was not aware this was an issue and for
me the extra 9K of code is not a problem and a 5M change in heap is acceptable.

> It is not really good if our internal libbsd branches diverge
> too much from the RTEMS mainline.

Yes I agree. It is not in anyone's interest and that only benefits you.

I would like to reiterate we have an obligation to maintain the code base as
close to FreeBSD as possible. Some of these changes push that boundary. We need
to find a suitable path forward.

Reviewing the changes:

1. The break up of the syscalls file. The related comments are:

 "Collecting all system calls in a single translation unit is not good
  due to the library initialization through linker sets."

Could you please explain what the linker set issue is?

Why the need to change FreeBSD calls to static? Is it solely a performance
optimisation?

We are required to use function and data sections so I assume the syscall file
will be broken up by the linker where possible?

I cannot tell from the patches if the conditional syscall trace support is still
present?

I do not agree with your statement in the patches separation helps porting. My
experience was not that. When adding VFS and the NFS client I found the syscall
code all over the place and not easy to find, hard to review and it added
complexity. It adds unnecessary changes to the FreeBSD code against a base
requirement of the porting effort.

2. FreeBSD file descriptor removal

Does this mean we can never have them in libbsd? Does that limit what can be
brought across from FreeBSD in the future?

3. select, poll, and kqueue

Do these calls work with an NFS client fd?

4. Types of RTEMS fd's in libbsd

The change I made brought the types into a single location so it is easier to
review and understand. There is:

 - rtems_bsd_sysgen_dirops
 - rtems_bsd_sysgen_fileops
 - rtems_bsd_sysgen_nodeops
 - rtems_bsd_sysgen_imfsnodeops

VFS is now left to handle the specific vnode ops as FreeBSD is designed to do.

[
https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/rtems/rtems-bsd-syscall-api.c?h=6-freebsd-12
]

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

Re: RTEMS5 and file descriptors

[Chris Johns]

On 20/10/2022 4:03 am, Michael Davidsaver wrote:
> On 10/17/22 22:50, Chris Johns wrote:
>> On 18/10/2022 4:42 pm, Sebastian Huber wrote:
>>> On 18/10/2022 06:15, Chris Johns wrote:
>>>> On 18/10/2022 2:22 pm, Michael Davidsaver wrote:
>>>>> On 10/17/22 16:20, Chris Johns wrote:
>>>>>> 2. Look at kqueue, it is a better interface for this type of blocking
>>>>> Maybe not relevant in Miroslaw's application, but I've found
>>>>> that the RTEMS kqueue implementation doesn't notify when a
>>>>> TCP connection is closed by reset.  I think this is a lack
>>>>> of NOTE_EOF *.
>>>> Thanks. I cannot find a ticket for this? Do you know if one has been 
>>>> created?
> 
> Not by me.  I ran into this incidentally while testing some
> new networking code using libevent, which helped me towards
> finding:
> 
> https://www.mail-archive.com/freebsd-hackers@freebsd.org/msg43808.html
> 
> Which leads with a reasonably clear statement that kqueue
> is/was not 100% functionally equivalent to select()/poll().
> At that point I configured libevent to use poll() and
> continued with my own troubleshooting.  Then unfortunately,
> I forgot about it until I read this thread.
> 
> https://github.com/mdavidsaver/pvxs/blob/6ee82fac6533d6551b18aa489cb263adc1333018/src/evhelper.cpp#L171-L178
> 
> That freebsd thread is 19 years old, and I haven't spent the
> time to investigate what happened since then.
> 
> libevent has:
> 
>> #ifdef NOTE_EOF
>>     /* Make it behave like select() and poll() */
>>     if (filter == EVFILT_READ)
>>     out->fflags = NOTE_EOF;
>> #endif
> https://github.com/libevent/libevent/blob/8f47d8de281b877450474734594fdc0a60ee35d1/kqueue.c#L193-L197
> 
> 
>>> This looks like a general FreeBSD limitation.
> 
> This was my general assessment at the time.
> 
>  
>> Is NOTE_EOF the same as EV_EOF? I noticed EV_EOF in the FreeBSD man page for
>> kqueue.
> 
> I'm no expert on the kqueue mechanism, but I think not.
> 
> https://man.openbsd.org/kqueue.2
> 
> This openbsd manpage mentions both, although 'NOTE_EOF' is
> only mentioned in passing, with no definition given.
> 
> Some searching leads me to think that EV_EOF is a "flag"
> while NOTE_EOF is an "fflag" (filter flag).  I have not
> investigated the precise distinction between the two.

Thanks for the response. It is unusual compatibility between implementations of
kqueue is not a major concern.

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

[RBW] Re: Painting a new fork

[JohnS]

About a year ago I had a frame and fork stripped and powder coated for just 
under $200, which I thought was a bargain. The powder coat paint options 
have come a long way since the last time I had a frame and fork coated 
about 12 years ago. This time I choose "intense orange" which looks like 
metal flake and looks great.

Good luck,
JohnS


On Wednesday, October 19, 2022 at 12:36:21 PM UTC-4 fra...@gmail.com wrote:

> Thank you Rich, I bet it does! Nice and clean. 
>
> I sent a message to a local powder coating place to see if they do bikes. 
> There are a few options around at least. I don’t want to spend a ton or I 
> think Cerakote would be a great option as well. So thin that the lug 
> details would be even better than paint I bet!
> On Wednesday, October 19, 2022 at 9:21:12 AM UTC-7 RichS wrote:
>
>> One of my bikes (single color) has two decals: headtube and a tiny "C" on 
>> the seat tube. Otherwise clean as a whistle; looks great.
>>
>> Best
>> Rich in ATL
>> On Wednesday, October 19, 2022 at 9:34:38 AM UTC-4 fra...@gmail.com 
>> wrote:
>>
>>> Thank you for the reply Garth! I live in Spokane Washington. It isn’t 
>>> like when I lived on the other side of the state and my bikes saw rain 
>>> riding for most months of the year, but there is plenty of weather in the 
>>> winter. 
>>>
>>> It seems like it wouldn’t be terribly difficult to find a painter but 
>>> price is a bit of a concern at the moment. I really don’t know what a full 
>>> paint job would cost. I plan to get a quote (powder) for the fork and 
>>> possibly the frame as well when the fork gets here. Spraying it myself 
>>> would be an option for this winter and then have it fully done next year. 
>>> Has anyone tried spraybike.us paints?
>>>
>>> I also like the clean look on a bike. Pictures are always welcome Garth!
>>>
>>> On Wednesday, October 19, 2022 at 3:43:11 AM UTC-7 Garth wrote:
>>>
>>>> I'd say it depends on where you live, does price matter, what painters 
>>>> are available, and as for doing it yourself, why not ? 
>>>>
>>>> I had my Bomba painted without any decals/logos mostly because I like 
>>>> unfettered clean paint. 
>>>> On Tuesday, October 18, 2022 at 4:46:45 PM UTC-4 fra...@gmail.com 
>>>> wrote:
>>>>
>>>>> Thank you Joe, that is what I was looking for. Also don’t want to 
>>>>> break any Rivendell rules to go for powder coating. It seems like the way 
>>>>> to go since it sees year round use in place with wet and snowy winters. 
>>>>>
>>>>> The frame is reasonably scratched up as well though. Maybe I should 
>>>>> just have it all powder coated. Does a bike free from any logos seem less 
>>>>> desirable to thieves? Ha! 
>>>>>
>>>>> On Tuesday, October 18, 2022 at 11:24:59 AM UTC-7 Joe Bernard wrote:
>>>>>
>>>>>> I think you're looking for "if it were me" thoughts from us so here's 
>>>>>> mine: 
>>>>>>
>>>>>> The first Clems didn't come with the fork accents and I think it 
>>>>>> looks fine. I have a powder coater place in town so for a 
>>>>>> commuter/shopper 
>>>>>> lock-up bike - which is what Clems are for! - I would keep the price low 
>>>>>> and the fork-covering tough and powder coat it. I don't know if he could 
>>>>>> do 
>>>>>> the accents. 
>>>>>>
>>>>>> On Tuesday, October 18, 2022 at 7:27:13 AM UTC-7 fra...@gmail.com 
>>>>>> wrote:
>>>>>>
>>>>>>> After talking with Will about my tweaked Clem fork, he thought it 
>>>>>>> would like a new fork would be better then trying to fix it. Easy to 
>>>>>>> talk 
>>>>>>> me into because mine has rust issues on top of being crooked (in two 
>>>>>>> directions). The cost wasn’t as bad as I thought either. It will 
>>>>>>> actually 
>>>>>>> be a Hunq fork because that’s what they had. Very slight rake 
>>>>>>> difference is 
>>>>>>> all I guess. 
>>>>>>>
>>>>>>> Anyway, it is a bare fork so now I get to decide how to paint it. My 
>>>>>>> Clem is Grilver and I love the color. I’m thinking of just having it 
>>>>>>> powder 
>>>>>>> coated for maximum durability since it is my daily commuter and gets 
>>>>>>> locked 
>>>>>>> up all over. I’m not sure the accent colors can be done with that 
>>>>>>> though? 
>>>>>>>  Or should I find a painter to do it. Or should I just spray it myself 
>>>>>>> and 
>>>>>>> not worry too much about it? Thoughts? Thanks in advance!
>>>>>>>
>>>>>>>
>>>>>>>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/54b26a7b-8af5-43e6-be2b-230ccb2b8842n%40googlegroups.com.

[RBW] Re: Thinking about getting a 62 Quickbeam

[JohnS]

Hello Tom,

Not mine, but a nice looking 62 QB frame/fork on the bay now...

https://www.ebay.com/itm/364015264475?hash=item54c10022db:g:SzwAAOSwD79jEA9r=enc%3AAQAHoHwOqNWKMXHgc3oWyVn7pYPofBnuW5KG%2BoPQYyGHw3W5Fsfi278BWZin%2FGqnOZzDrWipsEVRl3DPDOIhASKUW968jEuKj49QYo3jTAqPBpMecpPHLrK2mmAyrgkZAI1sTF0XB2epZ4zk52Mkr4rj3WPFqdkj9wfeClKfmTrIuEUKfAJ%2F2QGA18n2Idq1vJd9pnww4UQOZqCh0ds1J9j5jn0%3D%7Ctkp%3ABk9SR7CYj8T9YA

On Tuesday, October 18, 2022 at 10:17:13 AM UTC-4 tc wrote:

> Hey group,
> If anyone is thinking about selling or trading a 62 Quickbeam in good 
> condition, I'd like to discus with you - thanks.
>
> Tom
>
>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/5e744c13-542a-487d-a2e3-71c88e4637e1n%40googlegroups.com.

Re: RTEMS5 and file descriptors

[Chris Johns]

On 18/10/2022 4:42 pm, Sebastian Huber wrote:
> On 18/10/2022 06:15, Chris Johns wrote:
>> On 18/10/2022 2:22 pm, Michael Davidsaver wrote:
>>> On 10/17/22 16:20, Chris Johns wrote:
>>>> 2. Look at kqueue, it is a better interface for this type of blocking
>>> Maybe not relevant in Miroslaw's application, but I've found
>>> that the RTEMS kqueue implementation doesn't notify when a
>>> TCP connection is closed by reset.  I think this is a lack
>>> of NOTE_EOF *.
>> Thanks. I cannot find a ticket for this? Do you know if one has been created?
> 
> This looks like a general FreeBSD limitation.
> 

Is NOTE_EOF the same as EV_EOF? I noticed EV_EOF in the FreeBSD man page for 
kqueue.

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

Re: RTEMS5 and file descriptors

[Chris Johns]

On 18/10/2022 2:22 pm, Michael Davidsaver wrote:
> On 10/17/22 16:20, Chris Johns wrote:
>> 2. Look at kqueue, it is a better interface for this type of blocking
> 
> Maybe not relevant in Miroslaw's application, but I've found
> that the RTEMS kqueue implementation doesn't notify when a
> TCP connection is closed by reset.  I think this is a lack
> of NOTE_EOF *.

Thanks. I cannot find a ticket for this? Do you know if one has been created?

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

Re: Ping on ticket 4728 + patch

[Chris Johns]

On 18/10/2022 1:13 pm, Joel Sherrill wrote:
> On Sun, Oct 16, 2022 at 9:32 AM Alan Cudmore  > wrote:
> 
> On Fri, Oct 14, 2022 at 9:19 AM Joel Sherrill  > wrote:
> >
> > Pushed. Thanks for pinging. It does help.
> >
> > Since you are looking at the riscv BSPs, could you look at the four
> > BSP build failures reported here:
> >
> > https://lists.rtems.org/pipermail/build/2022-September/036496.html
> 
> >
> > I think they are all variants so one fix (maybe repeated) should do it.
> > The reported message isn't much help:
> >
> >    1 smp riscv/rv32iac build:
> >       configure: /home/tester/rtems-cron-6/rtems/waf configure\
> >       --prefix=/home/tester/rtems-cron-6/tools/6/bsps 
> --top=/home/tester\
> >       /rtems-cron-6/rtems --rtems-config=config-riscv-rv32iac-smp.ini
> >      error: ld/collect2:0 error: no error message found!
> >
> 
> I ran the bsp builder on the riscv BSPs with an updated toolchain and
> latest rtems master. I was able to reproduce only one of the failures
> with the rv32imafdc SMP configuration:
> Failures:
>    1 smp riscv/rv32imafdc build:
>       configure: /home/alan/rtems/test-build/rtems/waf configure\
>       --prefix=/home/alan/rtems/test-build/bsps\
>       --top=/home/alan/rtems/test-build/rtems 
> --rtems-config=config-riscv-\
>       rv32imafdc-smp.ini
>      error: ld/collect2:0 error: no error message found!
> 
> Average BSP Build Time: 0:00:26.253927
> Total Time 1:04:45.581263
> Passes: 147   Failures: 1
> 
> This is the detail from the log:
> [1424/1437] Compiling ../../../rtems/testsuites/samples/nsecs/init.c
> start.o: in function `.L0 ':
> 
> /home/alan/rtems/test-build/rtems/build/riscv/rv32imafdc/../../../bsps/riscv/shared/start/start.S:86:(.bsp_start_text+0x5
> c): relocation truncated to fit: R_RISCV_GPREL_I against symbol
> `bsp_section_bss_size' defined in *ABS* section in /home/
> 
> alan/rtems/test-build/rtems/build/riscv/rv32imafdc/testsuites/samples/minimum.exe
> collect2: error: ld returned 1 exit status
> 
> This seems to be similar to the error I get when I try to build the
> frdme310arty BSP with the testsuite and posix enabled:
> [4152/4326] Compiling testsuites/validation/tr-sem-surrender.c
> start.o: in function `.L0 ':
> 
> /home/alan/rtems/test-build/rtems-tmp/build/riscv/frdme310arty/../../../bsps/riscv/shared/start/start.S:86:(.bsp_start_te
> xt+0x28): relocation truncated to fit: R_RISCV_GPREL_I against symbol
> `bsp_section_bss_size' defined in *ABS* section in
> 
> /home/alan/rtems/test-build/rtems-tmp/build/riscv/frdme310arty/testsuites/validation/ts-validation-io-kernel.exe
> collect2: error: ld returned 1 exit status
> 
> I need to investigate this more.
> 
> 
> There are two issues. 
> 
> (1) The test in question does not fit on this target and needs to be disabled.
> 
> (2) Somewhere there is parsing of this output which may be able to be more 
> helpful.
> 
> Chris... any pointers on (2)? Can the output of bsp builder be improved?

1) There should be a log of all the build details. Check in that for the error.

2) Can you build it by hand and see the error?

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

Re: RTEMS5 and file descriptors

[Chris Johns]

On 18/10/2022 9:19 am, Miroslaw Dach wrote:
>>AFAIK you'd have to patch the header in the C Library when building the tools
> using the RSB to have a possible clean solution. Editing the installed header
> would be uncool.
> I see , I thought that it is somehow simpler thing.
>>How many descriptors do you need? And will you be using select()?
> I need maximum 128 file descriptors to be used.

The issue is a little more complicated because of the way the fd number are
allocated. RTEMS implements not reusing fd number once free (closed) preferring
to move to an unused fd number until all numbers have been used. The idea is to
try and catch the accidental continued use of an fd after close when an open
follows.

If you allocate 200 descriptors the following select code will work:

/* RTEMS entry point */
void Init(void) {
  /* start networking */
  int fd = socket(...);
  FD_ZERO();
  FD_SET(fd, );
  nfds = sd + 1;
  r = select(nfds, , NULL, NULL, NULL);
  /* blah blah */
}

while this will not:

/* RTEMS entry point */
void Init(void) {
  /* use up all the fd spots select has by default */
  for (i = 0; i < 65; i++) {
fd = open("afile", ...);
close(fd);
  }
  /* start networking */
  fd = socket(...);
  FD_ZERO();
  /* out of range access */
  FD_SET(fd, );
  nfds = sd + 1;
  rv = select(nfds, , NULL, NULL, NULL);
  /* blah blah */
}

If you control the code in quesiton and can make changes the following are some
suggestions:

1. Consider a thread per descriptor. Select is slow

2. Look at kqueue, it is a better interface for this type of blocking

3. Look at the following select work around ..
https://git.rtems.org/rtems/tree/cpukit/mghttpd/mongoose.c#n1522

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

Re: [PATCH] libdebugger: Add a target break call to suspend all running threads

[Chris Johns]

I have fixed the subject line as above in the commit to push :)

Chris

On 18/10/22 7:35 am, chr...@rtems.org wrote:
> From: Chris Johns 
> 
> - Optionally wait if there is no remote debugger connected and break
>   when the remote connects
> 
> Closes #4740
> ---
>  .../rtems/debugger/rtems-debugger-server.h|  1 +
>  cpukit/include/rtems/rtems-debugger.h |  8 +++
>  cpukit/libdebugger/rtems-debugger-server.c| 72 ++-
>  3 files changed, 65 insertions(+), 16 deletions(-)
> 
> diff --git a/cpukit/include/rtems/debugger/rtems-debugger-server.h 
> b/cpukit/include/rtems/debugger/rtems-debugger-server.h
> index 2189aac873..4d0407a951 100644
> --- a/cpukit/include/rtems/debugger/rtems-debugger-server.h
> +++ b/cpukit/include/rtems/debugger/rtems-debugger-server.h
> @@ -103,6 +103,7 @@ extern "C" {
>  #define RTEMS_DEBUGGER_FLAG_MULTIPROCESS (1 << 4)
>  #define RTEMS_DEBUGGER_FLAG_VERBOSE_LOCK (1 << 5)
>  #define RTEMS_DEBUGGER_FLAG_VERBOSE_CMDS (1 << 6)
> +#define RTEMS_DEBUGGER_FLAG_BREAK_WAITER (1 << 7)
>  
>  /**
>   * Forward decl for the threads and targets.
> diff --git a/cpukit/include/rtems/rtems-debugger.h 
> b/cpukit/include/rtems/rtems-debugger.h
> index 1fc8b3d522..7627e83382 100644
> --- a/cpukit/include/rtems/rtems-debugger.h
> +++ b/cpukit/include/rtems/rtems-debugger.h
> @@ -53,6 +53,14 @@ extern int rtems_debugger_start(const char*  
> remote,
>  rtems_task_priority  priority,
>  const rtems_printer* printer);
>  
> +/**
> + * Suspend all running threads including the caller if not
> + * excluded. Returns when the debugger has connected and continued.
> + *
> + * If wait is true and there is no remote connected wait then break.
> + */
> +extern int rtems_debugger_break(bool wait);
> +
>  /**
>   * Stop the Debugger.
>   */
> diff --git a/cpukit/libdebugger/rtems-debugger-server.c 
> b/cpukit/libdebugger/rtems-debugger-server.c
> index 9de9421b6b..b7b9727d84 100644
> --- a/cpukit/libdebugger/rtems-debugger-server.c
> +++ b/cpukit/libdebugger/rtems-debugger-server.c
> @@ -1678,18 +1678,30 @@ rtems_debugger_events(rtems_task_argument arg)
>  
>rtems_debugger_target_enable();
>  
> -  while (rtems_debugger_server_events_running()) {
> -rtems_debugger_server_events_wait();
> -if (rtems_debugger_verbose())
> -  rtems_debugger_printf("rtems-db: event woken\n");
> -if (!rtems_debugger_server_events_running())
> -  break;
> +  if (rtems_debugger_server_flag(RTEMS_DEBUGGER_FLAG_BREAK_WAITER)) {
> +rtems_debugger->flags &= ~RTEMS_DEBUGGER_FLAG_BREAK_WAITER;
>  r = rtems_debugger_thread_system_suspend();
> -if (r < 0)
> -  break;
> -r = remote_stop_reason(NULL, 0);
> -if (r < 0)
> -  break;
> +if (rtems_debugger_verbose())
> +  rtems_debugger_printf("rtems-db: break waiter\n");
> +rtems_debugger_server_events_signal();
> +if (rtems_debugger_verbose())
> +  rtems_debugger_printf("rtems-db: break waiter: signalled\n");
> +  }
> +
> +  if (r == 0) {
> +while (rtems_debugger_server_events_running()) {
> +  rtems_debugger_server_events_wait();
> +  if (rtems_debugger_verbose())
> +rtems_debugger_printf("rtems-db: event woken\n");
> +  if (!rtems_debugger_server_events_running())
> +break;
> +  r = rtems_debugger_thread_system_suspend();
> +  if (r < 0)
> +break;
> +  r = remote_stop_reason(NULL, 0);
> +  if (r < 0)
> +break;
> +}
>}
>  
>if (r < 0)
> @@ -1972,6 +1984,30 @@ rtems_debugger_server_crash(void)
>rtems_debugger->remote->end(rtems_debugger->remote);
>  }
>  
> +int
> +rtems_debugger_break(bool wait)
> +{
> +  int r = 0;
> +  if (!rtems_debugger_running()) {
> +errno = EIO;
> +r = -1;
> +  } else {
> +rtems_debugger_lock();
> +if (rtems_debugger_server_events_running()) {
> +  rtems_debugger_server_events_signal();
> +} else if (
> +  wait && !rtems_debugger_server_flag(RTEMS_DEBUGGER_FLAG_BREAK_WAITER)) 
> {
> +  rtems_debugger->flags |= RTEMS_DEBUGGER_FLAG_BREAK_WAITER;
> +  rtems_debugger_server_events_wait();
> +} else {
> +  errno = EIO;
> +  r = -1;
> +}
> +rtems_debugger_unlock();
> +  }
> +  return r;
> +}
> +
>  int
>  rtems_debugger_stop(void)
>  {
> @@ -1998,10 +2034,14 @@ rtems_debugger_set_verbose(bool on)
>  int
>  rtems_debugger_remote_debug(bool state)
>  {
> -  rtems_debugger_lo

Re: Documentation index entries for functions

[Chris Johns]

On 15/10/2022 12:58 am, Joel Sherrill wrote:
> On Fri, Oct 14, 2022 at 8:53 AM Sebastian Huber
>  >
> wrote:
> On 14.10.22 15:45, Joel Sherrill wrote:
> >
> > While teaching an RTEMS class this week, I noticed that rtems_build_name
> > is in the Classic API Guide index twice. Once with () and once without.
> > I started to fix that one case when I noticed that it appears we are
> > just very inconsistent.
> >
> > (rtemsdocs) [joel@localhost c-user]$ grep -r index::  | grep rtems_ |
> > grep "()$" | wc -l
> > 280
> > (rtemsdocs) [joel@localhost c-user]$ grep -r index::  | grep rtems_ |
> > grep -v "()$" | wc -l
> > 158
> >
> > There are 280 index entries with () on a method name and 158 without.
> 
> FWIW Some of the 158 without could be rtems_ data types.  
> 
> >
> > Which way should it be? :)
> 
> I strongly prefer the () style for functions and macros.
> 
> I should have mentioned that I also agree with this approach.  
> 
> If we get a third pro-parentheses vote, I'll make a sweep. 

+1

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

Re: [PATCH] TFTPFS: Adding missing diagram

[Chris Johns]

I have built HTML and PDF and it looks is fine. Pushed.

Thank you for updating the image and sorting this out. It is appreciated.

Chris

On 14/10/2022 2:41 am, Frank Kuehndel wrote:
> From: Frank Kühndel 
> 
> ---
>  filesystem/trivial_ftp.rst  |   8 --
>  images/filesystem/tftpfs_usage.png  | Bin 0 -> 47217 bytes
>  images/filesystem/tftpfs_usage.puml |  37 
>  3 files changed, 43 insertions(+), 2 deletions(-)
>  create mode 100644 images/filesystem/tftpfs_usage.png
>  create mode 100644 images/filesystem/tftpfs_usage.puml
> 
> diff --git a/filesystem/trivial_ftp.rst b/filesystem/trivial_ftp.rst
> index 3ef8bba..b8e1ae4 100644
> --- a/filesystem/trivial_ftp.rst
> +++ b/filesystem/trivial_ftp.rst
> @@ -275,16 +275,20 @@ repository):
>  Usage
>  =
>  
> -The following diagram shows how the TFTP filesystem is used by an
> +The following diagram usage_ shows how the TFTP filesystem is used by an
>  application.  The mount point can be any directory.  The name ``/tftp``
>  used in the figure serves only as an example.  The final unmounting and
>  remove directory steps are optional.
>  
> +.. _usage:
> +
>  .. figure:: ../images/filesystem/tftpfs_usage.png
> -  :width: 90%
> +  :width: 75%
>:align: center
>:alt: TFTP Usage Diagram
>  
> +  TFTP file system usage
> +
>  Mounting the TFTP Filesystem
>  
>  
> diff --git a/images/filesystem/tftpfs_usage.png 
> b/images/filesystem/tftpfs_usage.png
> new file mode 100644
> index 
> ..5faa72f768a0742c50f32fa30380a3be33e7
> GIT binary patch
> literal 47217
> zcmb5Wby$>L+ci#zAl)E{bV!4eN_PuL!_b}5jg%6C(jX-zQVt=V64EW*NaxTE-$uOe
> z=Xu}n_w73c!9DElX9HKD_0=San
> z*c$|XJ#m)MbT+nk@USs8bB2>LwKH`zbT&1iF!G?VaCUa!XJd1)F|>1bv9)0}wztJ$
> z=X(SPhrnm~O4IqD>u~VkHts1!s>=40?AX2^TK#zU@GCyj#!|)SsZ`=JGT_JFBUXwM
> zdsHlKWAgmvm#b60Y+-HN7`k4i)!N zOJ1-y&^qhgQ-6>8pa5eLMrq6!w-AZLxPZBlZbIdD^yz0w$8d9ut#Px<*CupWi+|;*
> zU|>3Q^mp4Q;VcFRQ=(_}U;O!xYLrPvbaUF#rc20=k*UY@&$}=Kmw#ad`m%3d_yxG{
> zj6tek_x&%zzDhmOu?@C5>8sGT{Vi zkVo{Pao!azuilYGlOob(j3vML5Kn*pP+h?(LsBX<*vRR<5n1&38)6xJNsnj)yE-JI
> zea%b_oPkq?2fQ}YVR3z7t=+L2c~(VVohcVz%{TIt!LEyv5b1ICYdI9VZUSGD#4KGt
> zBG`$G8FmcKw?44zc0cx=rA-7@TJN`%zsQDJP!AKW_X-JC`JHR-CvS=8f%
> z<1DMAu7#K{s(j&)K4+|d7{)<~KOlIUh|(zJlMfid{lKbJ8Y{W-gG3)yj6AEv{4
> znuFw1`5f+)570M?wPz91Fb)lE13}h<9yvYC@e0c%*Hz=nCyxHf$3;1j9>%Wr^0j9}
> z+s>1px>}=N=|8;8`pD~KAZ~G;dE^if=27L`W<=m>KzNv}XB)J}FJ(=OtGb<$h$EDr
> z2)#nU*yktFSNXvW2loa}MqK2TJ7g>Mf#xf ze>E2|OB}>?ZI4W! za3MJNZndv^HO*;fA*KJaFEz<4{7Qi;N}7i0YvMD1aquc0dm#?|E~IK^3Kgf)k_ghk
> z4HYj9LxIxZhMExIKxAleI~l3!qNQn~)x_Ot!AA>1U>lB}-m5z^J>5JpLwY}WhwD;m
> zhgd11Y^a(G3f3lPW4}Mpml)Y7Vi=tqsjHQQ{u*>*4c_kW_hQ~A!tJ!8s_W9{S^V&`
> z{1JTD*B7;4-<_ptmFwb_o=Ijl6TE*aQ0D2ev1VCYa3YK)KDLuwtr%4SI(C9RIV
> zpw>6EvYLLVgH^a?IiQ61{mBi~x#&2k`~2LWEL2Y_g9o#YZ)5hXV5pBOikYRkzy_(}
> zn%9BQB6{cIET+!*g`MuOMiv59UCj>j*b@O>MkXdE9-foIEUBRe>L_MP@BtUc3Rb(e
> zp+u?o;TPA-L03>LI73yjtY;(@g^8JkmWqmJt>#ho3UCibUR>yh1rQj7jHFo
> z(mpw`KYbd5B3Jqr1?m{9?ls@5>_u{zWsM-25`$B82#Z|XEl@8AEvB&!fia5dO(h2m
> zsNvOxnxkrM9j^PLo^aRl*wQyg7lLM>#~m+ZhREvelasIdixOTe90fL6kAJo-DJikE
> zv?Ph3 z^}W>E8aDL8Og8kyCDm|3rs>IhK9zboDzx z!2+h;@hig$Jo*7oo&=M;dsV0zsYIlM_x-^PL9w%og@uKU4Ku>{)|QQBdbD>@Dt
> z^XAL@?ys-ju|KBm`NqLrTf`Z9my
> z>CI5XWU&)HKR@5mAziMW8W%^qt%|#zB<>!UY)6+9NW_Cn@Ip3GVJS9rqNmHU!~4OP
> zY#dCg8t4Q|qSJ
> z8BH5Tz@(o4s?%xJsMSJF=7GgvCJv;+=FG~|^J}&+WpaXs#3M8>cYHTDH}lX+JKE!&
> znQz`_r9Ky~!k_aiWtt_|hjQo?A8F>P1n z_I{<+2r zZ?}K=;NP)1c43H!TwyufIzZW@l=f(MAfq~cj`!FRHvf1y7t8OI-R0-|g{S6`xTSlv
> z#T7{RyszeeM4ilThGw0{UYv}WcD-=h8pnKQHd@G0q_atac(Sz~(M$^8iZo
> z9E1)}Qm}^q+r}%x2#5Xw2nWRPiVMMSf)a%WgRHsEVlZ~4SKm;>SY!m3_J!T7eA97f
> z%t8by4>ovUNI1VcY)V7lCrat;p#POp|9(b>T$9$Ts5lq6+Tw+kmAC9k1fuS=6Uw)-
> zHvwb(*f9Vxd@kr)R_Qj3O3)S0tkv8>2@AzD?4T>0VAG#%|HjR(QJ}8X(V0NO%J}pt
> zD&^Dk=6qoqo%))wH}HD>X)_VA1scC!R=s3ih%=D_tB|f>k(S-GIZ@DjT<
> zKSW96+ok+hq90%0Nxc^TBpPPWaPPHph?>4vkzjfN_agz4LY9y`jl#sUpQI7rkp>HD
> zYcF;iH^24ZLS&8!7S!xY@gXH)$QV$)aKHVfs*j1uUc_kL%-bR*!Dv3+32fG1o0J3}
> z4i@PYTwdnd&2Rr6_E_mrrm%P1cS9q*JSbwTr`5|>_g)IA9Rd|F^?ZwIN+#78K
> zM51SwLm%TtYu#$Ao!Su_^nH$S{^^F?0>R^FU%fzJ7OxS~+s(ef+C0}T&+kp<$#C7?
> z;N$D`M00j>LQD;ogKxYnMGGB+wx4W{;q0*?Oc}Sk5?kVOTm6E4dS;1zkp`EkEQmA_
> z9bLg?JBj`7nf-N`Hd%-4bHD3!d(56hjue<|Y1Zu`$mw2xqx0d;>02feSI)e)yZe
> zM(=I<;*(Z6V}O>u1_S)1E+s{6QYA9KM|`LWQrKJFS*(kj6tRw}?s=DTQTa
> z(UsKGQQqYPd!&2!upu z**V>=ZPN}#n0s-!J0T-0R`z$nr`=zvU#c%=p7M4oDGONKD
> z7o-u*1@?qo%>)>;yRCgb3q!pAEG3_BnQWHMgb%r}MXdfS89ML{fS#8Jj
> zrgVpp(InKR|IL$8Z4Pfb(XoMnm-BIUxeB*$EFGzL(r}I6#GhK4c{hf+@BP~Jrqm&7
> zs6L`}ShJWQgQ*F%Zm7jT`nF$vvRIKS@$1BDl}d_|*e#9cIm8<<{*MgzNkmCCf0d
> zmX;1V?Sd2N`e-5ohL5?>2_%l#xSA(nUgT$MP8yiT2Rqp**JgP;Wrd5gTc6;Jt%d#9
> zM5h1b19M93VT)(Pm6WS0{ZBj_{fw>y<{IW4sFe-n^dm5N%N)-}5`}#e)O;u%
> zhL!YLcn56Xmx}AmxD{*HK{czDd(;<7g|)Rw!r z`i$kfB-_l;_=s+O!v0KN7p?U}%^#|+^#ty1uFlTS%3+9;1 zXOE>>A$el+s8AE~cuvMa{F4 z!!;+4)U*dZLSc-44}#jxd01H$b5u%TEbQzb{ojV_1%Hoz;~2bCksqG@+=gn;
> zaw{s12=_OprzbHg%z7Rwu{_ii(mQgbyD+eEgWT)fr_Op(t;jPwvgw
> 

Re: docs not building to PDF

[Chris Johns]

On 13/10/2022 4:06 pm, Sam Price wrote:
> example
> 
> https://mermaid.live/edit#pako:eNqFVG1vmzAQ_iuWP6UVaZM0DQGlkSYlnSJ1bUUyddmYkAlmYQEbGVP6sv732cdrtSrj0z0v9p19h1_xjgcU2ziTRNJFRH4JkvQfRy5zWcQi6WeBjVYqiEgcvVAUR76iSu2WyoKLwzu94lyWHBaRsNGOs0yi3Z4IdJrwnEkv5RGT6Aq5-FyGMnXxzBfnc0GzPNZ0cggi0UMdr4HW3sp5-PYV_amiz010dwKrdbWwAnK2e2mqh8CC9OdiFxsN7OZoSGez_LL2rlc3y_V2rWJvs71fepvrzf36iMlZflp4D85qs2xNLvZjvjtk6lquhoPR2CgiFvAC8Nh4pMLnGXVxWd6JPgJPKRPcRmGgitegh1Ii9wa685zF3e3NFimboES1xH-WNFMujXpqgYECIonn52FIhaHT6zw87HV5dFJvsItV7s5NAdb7aIPOXHxYxYNTV1GISNK2DIBtHQZkb3xHs-XQho6as6pv3XnRdSfBu-4C_sflMji8nmYUqkn0ynA202A-L2WEfpz-RP3-HFUzXtMVbKRmnFu5osACQ16LAEq6GsVGqTCIbVG1fIyBJeVc1GKJQNCtrGkdHyfh2rsKECCXTTiSvuhmL4CG1tY0gP_S7ypomQ9KKLOXnGreb9XetnkVDefSQ4ANnFCRkChQD9mrdrlY7mmi_i5bhQENiRoZ9fOzN2UlueTrZ7bDthQ5NXCeBu3Th-2QxJliU8K-c57UJgWx_YqfsD0cDs6soXk5mlyMR2PTmkwN_Kzo0dn4cmxZg4FlTqeTifVm4BfYQNkvLNMyzUvLvJhMp6b59hcqM78E
>  
> 
> 
> SVG link
> https://mermaid.ink/svg/pako:eNqFVG1v2jAQ_iuWP0GVtrxDIoo0CTohdaUCJsaWKXKIMzKIjRynKWX899mXV7SK5dM9L_adfRef8IZ7FFs4kkTScUB-CRLevrZsZrOABdKNPAtNVRCQffBO0T5wFZVqz1QmXOwu9IyzWbgbB8JCG84iiTZbItBNyGMmnQMPmEQPyMb30pcHGw9dcT8SNIr3mg53XiBqqOI10MKZzlffvqI_WfS5iGZ1WK2rhRWQs9xLUzUEFqQ_G9vYKGA1R0HOl5MvC-dx-jRZrBcqdpbrl4mzfFy-LK6Y5pNPY2c1ny4npcnG7p5vdpG6lodmo9UxkoB5PAHcMV6pcHlEbZyWV9dH4AfKBLeQ76niNaihA5FbA82c-Xj2_LRGyiYoUS1xj5JGyqVRTS0wkEckcdzY96kwdHqdh_u1Ko_q-QabvcpduSnAeh9t0JmTD6tYzfMqEhFIWpYBsKzDgOyF72q2GNpQUWOW9a06L7ru0LvoLuB_XDaDw-tpRr6aRCcNh0MNRqNURujHzU90eztC2YzndAYLqRjnUs4osMCQ5yKAlM5GsVAyDGJZVC5fY2BJOhe5mCIQdCtzWsfXSbj2qgIEyGkTrqRPqtkToKG1OQ3gv_RFBSXzQQlp9pRTzfut2ls2L6PhXHoIsIFDKkISeOohO2mXjeWWhurvslToUZ-okVE_PzsrK4klXxzZBltSxNTA8cErn76cPBD2nfMqxNYJv2Gr2Wzcmc1-t9Vrd1qdvtkbGPio6NZdp9sxzUbD7A8GvZ55NvA7bKDsbbNv9vtds9HtNcxm-_wXZ4G-ow
>  
> 
> 
> 
> I couldn't figure out how to get semi colons to work
> new lines are kind  of a pain also.

You are a legend (pun intended) :D

It is looking goo but Frank has the final say.

Chris

> 
> stateDiagram-v2
> 
> initbsd:Initialize libbsd
> initNetwork:Initialize Network
> mkDir:const char *mount_point = "/tftp"result = mkdir( mount_point, 
> S_IRWXU
> | S_IRWXG | S_IRWXO)
> 
> mountDir:result = mount(  "", mount_point,
> RTEMS_FILESYSTEM_TYPE_TFTPS, RTEMS_FILESYSTEM_READ_WRITE,
> "blocksize=1024,windowsize=4,verbose" )
> 
> openro:fd = open( path, O_RDONLY )
> read:bytes = read( fd, data_buffer, sizeof( data_buffer ) )
> readclose:result = close( fd )
> openw:fd = open( path, O_WRONLY )
> write:bytes = write( fd, data, size )
> writeclose:result = close( fd )
> umount:result = unmount( mount_point )
> rmdir:result = rmdir( mount_point )
> 
> state fork_state <>
> [*] --> initbsd
> initbsd --> initNetwork
> initNetwork --> mkDir
> mkDir --> mountDir
> mountDir --> fork_state
> fork_state
> fork_state --> openro
> openro --> read
> read --> read
> read --> readclose
> readclose --> umount
> fork_state --> openw
> openw --> write
> write --> write
> write --> writeclose
> writeclose --> umount
> state umount <>
> umount --> rmdir
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: docs not building to PDF

[Chris Johns]

On 13/10/2022 3:15 pm, Sam Price wrote:
> Yes
> https://github.com/mermaid-js/mermaid-cli
> 
> 
> There are command line tools so it can be integrated into pipelines.
> 
> 
>   Convert Mermaid mmd Diagram File To SVG
> 
> mmdc -i input.mmd -o output.svg
> 
> 
>   
> Create
>  A PNG With A Dark Theme And Transparent Background
> 
> mmdc -i input.mmd -o output.png -t dark -b transparent
> 
> You dont get much control though over how it places boxes. 
> But it does sequence diagrams.
> Im using it for gantt charts.
> 
> Its one of the mainstream alternatives to plantuml
> 

This tool looks really good and it fits the pattern of tools we can use.

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

Re: docs not building to PDF

[Chris Johns]

On 13/10/2022 2:01 pm, Sam Price wrote:
> Have you guys looked at mermaidjs for simplistic diagrams?
> https://mermaid-js.github.io/mermaid/#/flowchart
> 

No I have not.

> You can embed it in markdown. pandoc will convert it to images for html.
> it works on gitlab wiki, and prob others.

Can it generate a format we can embed in PDFs?

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

Re: Cygwin tools failure

[Chris Johns]

On 12/10/2022 3:24 pm, Chris Johns wrote:
> Consider a patch to add the piece removed at the end of this patch as 
> approved.

I see the patch was pushed, thanks. The RSB hash will need to be updated so
users pick it up.

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

Re: docs not building to PDF

[Chris Johns]

On 12/10/2022 8:56 pm, Frank Kühndel wrote:
> Hello Chris,
> On 10/11/22 23:47, Chris Johns wrote:
>> On 11/10/2022 7:12 pm, Frank Kühndel wrote:
>>> Hello Chris,
>>>
>>> On 10/11/22 03:09, Chris Johns wrote:
>>>> On 10/10/2022 9:22 pm, Frank Kühndel wrote:
>>>>> images/filesystem/tftpfs_usage.png:
>>>>> https://share.embedded-brains.de/index.php/s/fQ4WrLrqmBjcbwC
>>>> I have a greyed out image I cannot clearly see?
>>> The image has a transparent background. Some image viewers put a gray 
>>> pattern in
>>> the background in those case. The PDF has naturally a white background on 
>>> top of
>>> which the image is displayed.
>>>
>>>>> images/filesystem/ftpfs_usage.svg:
>>>>> https://share.embedded-brains.de/index.php/s/xk7kArkm6mbjcn2
>>>>>
>>>>> The SVG file is the source for the PNG. Both files must be placed in the
>>>>> images/filesystem folder.
>>>> How is the SVG file created and how can it be edited?
>>> I used Inkscape. It should be possible to edit it with (almost) any tool 
>>> that
>>> supports SVG.
>> I tried withhttps://pixelied.com/features/svg-editor  and it was a mess.
> 
> Yes. I tried another Web-based tool and it was the same mess. Yet, all 
> converter
> handle this correctly. For example:
> 
> $ firefox file:///home/frank/tftpfs_usage.svg
> $ convert -geometry 1422x1574 tftpfs_usage.svg tftpfs_usage.png
> $ display tftpfs_usage.svg
> $ libreoffice tftpfs_usage.svg
> $ rsvg-convert --width 1422 --height 1574 -o tftpfs_usage_Z.png 
> tftpfs_usage.svg
> 
> So, I guess it is a bug in the web-based tools.

The format is always going to be fragile and locked into the specific tool used
to create it. Being an open format does not help. Word is a form of XML and it
is also not suitable.

>> My concern is the widgets (or whatever they are called) a tool has may not be
>> available in another.
> 
> Inkscape is open source and available freely on (almost?) all operating 
> system.
> It is *the* standard open source tool for producing high-quality vector 
> graphics
> today.

I do not agree and I question "the" in your last sentence. Making a fact of your
view does not impress me.

We need a solution that can be maintained past your current employment.

>>> Your Web-Browser should be able to display SVG directly when you
>>> point it to the file like for 
>>> example:file:///home//tftpfs_usage.svg
>>>
>>> You can recreate the PNG with Inkscape on the command line with:
>>>
>>> $ inkscape --export-dpi=300 --export-filename=tftpfs_usage.png 
>>> tftpfs_usage.svg
>> We have a number of images in the doco created using PlantUML. Did you 
>> consider
>> using that tool? It has the advantage the images can be regenerated from the
>> source as part of the build if PlantUML and Ditaa are installed and we get a
>> consistent looking set of images.
> 
> I took a look into PlantUML:
> 
> * My image is not an UML diagram (or similar to another diagram input format 
> it
> supports)

Ditaa is an option and easy to use.

> * It may be realized as an Activity Diagram, yet. But it will not look very
> similar to the current image.
>
> * Most of all, I will need to spend significant time to learn PlantUML and to
> get the result in shape I will certainly need to do some trying and fumbling
> around.

Maybe an example would help:

https://git.rtems.org/rtems-docs/tree/images/user/exe-debug-libdebugger.ditaa

> Openly, my company will never pay me for converting the image to PlantUML. 
> Sorry
> about this.

Seems you have made this a commercial issue on a public mailing list I have
included Thomas on the email and he can reach out me directly. I always enjoy
catching up with him.

> Do you see any solution to this problem?

1. Revert the patch.

2. Use something like ditaa

3. Reword the section to not include the image

In the mean time the docs are not building.

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

Re: Cygwin tools failure

[Chris Johns]

On 12/10/2022 2:30 pm, Joel Sherrill wrote:
> 
> 
> On Tue, Oct 11, 2022 at 8:36 PM Ryan Long  > wrote:
> 
> Cygwin has been unable to build the tools for awhile. This has been due
> to an array subscript being a char while building DTC. The maintainers
> didn't see an issue with the code itself, so it's going to go on being
> broken for awhile I guess.
> 
> Joel recommended commented out the building of DTC through the RSB.
> After doing so, I'm running into the following error. I was building
> AArch64's tools. Disabling DTC and building with my Debian WSL instance
> built it just fine.
> 
> 
> [ 48/258] Compiling rtemstoolkit/elftoolchain/libelf/libelf_align.c
> ../rtemstoolkit/elftoolchain/libelf/elf.c:34:35: error: ‘LIBELF_ARCH’
> undeclared here (not in a function); did you mean ‘LIBELF_ERROR’?
>     34 | .libelf_arch    = LIBELF_ARCH,
>    |   ^~~
>    |   LIBELF_ERROR
> ../rtemstoolkit/elftoolchain/libelf/elf.c:35:35: error:
> ‘LIBELF_BYTEORDER’ undeclared here (not in a function); did you mean
> ‘LIBELF_ERROR’?
>     35 | .libelf_byteorder   = LIBELF_BYTEORDER,
>    |   ^~~~
>    |   LIBELF_ERROR
> ../rtemstoolkit/elftoolchain/libelf/elf.c:36:35: error: ‘LIBELF_CLASS’
> undeclared here (not in a function)
>     36 | .libelf_class   = LIBELF_CLASS,
>    |   ^~~~
> 
> Waf: Leaving directory
> 
> `/home/rtems-tester/rtems-cron-6/rtems-source-builder/rtems/build/rtems-tools-d0a65c72d1a170637258eb19f7d3e433be7c3c86-1/rtems-tools-d0a65c72d1a170637258eb19f7d3e433be7c3c86/build'
> 
> 
> Does anyone know a fix for this?
> 
> 
> rtemstoolkit/elftoolchain/libelf/_libelf_config.h has ifdef's for various host
> operating
> systems and does not have one for Cygwin or MSYS. But it can't know the 
> native ELF
> details because the native format is not ELF:
> 
> $ file /bin/cat.exe
> /bin/cat.exe: PE32+ executable (console) x86-64, for MS Windows
> 
> I'm not sure what to do about this. My first thought would be to add 
> Cygwin to the list like FreeBSD and see if that defines what you need.
> or find the x86_64 Linux settings and use those for Cygwin to let it
> compile.
> 
> I'm not sure why we need to know the native ELF details.

The tools use to build on Ming64...

https://git.rtems.org/rtems-tools/tree/rtemstoolkit/elftoolchain/libelf/_libelf_config.h?h=5#n191

This patch broke the support...

https://git.rtems.org/rtems-tools/commit/rtemstoolkit/elftoolchain/libelf/_libelf_config.h?id=ff68bccc25386c84d893187af36e4bac88db4b10

Consider a patch to add the piece removed at the end of this patch as approved.

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

Re: docs not building to PDF

[Chris Johns]

On 11/10/2022 7:12 pm, Frank Kühndel wrote:
> Hello Chris,
> 
> On 10/11/22 03:09, Chris Johns wrote:
>> On 10/10/2022 9:22 pm, Frank Kühndel wrote:
>>> images/filesystem/tftpfs_usage.png:
>>> https://share.embedded-brains.de/index.php/s/fQ4WrLrqmBjcbwC
>> I have a greyed out image I cannot clearly see?
> 
> The image has a transparent background. Some image viewers put a gray pattern 
> in
> the background in those case. The PDF has naturally a white background on top 
> of
> which the image is displayed.
> 
>>
>>> images/filesystem/ftpfs_usage.svg:
>>> https://share.embedded-brains.de/index.php/s/xk7kArkm6mbjcn2
>>>
>>> The SVG file is the source for the PNG. Both files must be placed in the
>>> images/filesystem folder.
>> How is the SVG file created and how can it be edited?
> 
> I used Inkscape. It should be possible to edit it with (almost) any tool that
> supports SVG. 

I tried with https://pixelied.com/features/svg-editor and it was a mess.

My concern is the widgets (or whatever they are called) a tool has may not be
available in another.

> Your Web-Browser should be able to display SVG directly when you
> point it to the file like for example: 
> file:///home//tftpfs_usage.svg
> 
> You can recreate the PNG with Inkscape on the command line with:
> 
> $ inkscape --export-dpi=300 --export-filename=tftpfs_usage.png 
> tftpfs_usage.svg

We have a number of images in the doco created using PlantUML. Did you consider
using that tool? It has the advantage the images can be regenerated from the
source as part of the build if PlantUML and Ditaa are installed and we get a
consistent looking set of images.

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

Re: Fwd: New Defects reported by Coverity Scan for RTEMS

[Chris Johns]

Hi,

Thanks Coverity for picking up I forgot to add the new error string. :)

I will push the 1 line change.

Chris

On 10/10/2022 10:46 pm, Joel Sherrill wrote:
> 
> -- Forwarded message -
> From: mailto:scan-ad...@coverity.com>>
> Date: Mon, Oct 10, 2022, 12:22 AM
> Subject: New Defects reported by Coverity Scan for RTEMS
> To: mailto:bu...@rtems.org>>
> 
> 
> Hi,
> 
> Please find the latest report on new defect(s) introduced to RTEMS found with
> Coverity Scan.
> 
> 1 new defect(s) introduced to RTEMS found with Coverity Scan.
> 
> 
> New defect(s) Reported-by: Coverity Scan
> Showing 1 of 1 defect(s)
> 
> 
> ** CID 1515930:  Memory - illegal accesses  (OVERRUN)
> /cpukit/libmisc/rtems-fdt/rtems-fdt.c: 971 in rtems_fdt_strerror()
> 
> 
> 
> *** CID 1515930:  Memory - illegal accesses  (OVERRUN)
> /cpukit/libmisc/rtems-fdt/rtems-fdt.c: 971 in rtems_fdt_strerror()
> 965         "blob has references"
> 966       };
> 967       if (errval > -RTEMS_FDT_ERR_RTEMS_MIN)
> 968         return fdt_strerror (errval);
> 969       if (errval < -RTEMS_FDT_ERR_MAX)
> 970         return "invalid error code";
     CID 1515930:  Memory - illegal accesses  (OVERRUN)
     Overrunning array "errors" of 5 4-byte elements at element index 5 
(byte
> offset 23) using index "-errval - 100" (which evaluates to 5).
> 971       return errors[(-errval) - RTEMS_FDT_ERR_RTEMS_MIN];
> 972     }
> 973     
> 974     int
> 975     rtems_fdt_prop_value(const char* const path,
> 976                          const char* const propname,
> 
> 
> 
> To view the defects in Coverity Scan visit,
> https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50ypUUzi-2FdSNmuyRB7BEFT8xQ4-2B8hpujh0hTgQljRGId4Dg-3D-3D3tGt_EU3W9teASMK00lBXX9WT4lsogDrkCcNZLvg-2FVxwAXMrx8nV9Pzi0hugn9s2FK6ZfLix8JmyqOKq3RkOqFldjBEAraGrjvpmsds-2B4Iivd5W95gEqWlcvVuG1EDWj6hubB5Z5pEtpqtddGnBcH49eyBbkHPbRwsax2k1rSx8EynyzF-2Fw-2BumI1vwItGf-2FpJNy6Us6XZ0o-2BY2bhnazRwWhumfA-3D-3D
>  
> 
> 
> ___
> build mailing list
> bu...@rtems.org 
> http://lists.rtems.org/mailman/listinfo/build
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: docs not building to PDF

[Chris Johns]

On 10/10/2022 9:22 pm, Frank Kühndel wrote:
> images/filesystem/tftpfs_usage.png:
> https://share.embedded-brains.de/index.php/s/fQ4WrLrqmBjcbwC
I have a greyed out image I cannot clearly see?

> images/filesystem/ftpfs_usage.svg:
> https://share.embedded-brains.de/index.php/s/xk7kArkm6mbjcn2
> 
> The SVG file is the source for the PNG. Both files must be placed in the
> images/filesystem folder.

How is the SVG file created and how can it be edited?

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

Re: docs not building to PDF

[Chris Johns]

On 8/10/2022 9:47 am, Chris Johns wrote:
> On 8/10/2022 10:12 am, Noor Aman wrote:
>> I can confirm that the same is happening on my PC too.
> 
> Could you please bisect the repo to find the patch that broke things?

A simpler way to find the commit is to see the last build on docs.rtems.org
which is 6.278550b and the next commit after 278550b is:

commit 23fc93bf648507ac417237c20069c4ab7c793251
Author: Frank Kühndel 
Date:   Thu Jun 9 15:21:05 2022 +0200

TFTPFS: New documentation

Frank ?

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

Re: docs not building to PDF

[Chris Johns]

On 8/10/2022 10:12 am, Noor Aman wrote:
> I can confirm that the same is happening on my PC too.

Could you please bisect the repo to find the patch that broke things?

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

Re: [PATCH rtems-docs v4] raspberrypi4.rst: Documentation for the new AArch64 Raspberry pi 4B BSP

[Chris Johns]

On 8/10/2022 10:29 am, Noor Aman wrote:
> I'm on an older commit of master branch (20 commits behind) and on that, the 
> pdf
> builds fine, If that helps you in any way.

Please make sure the patches you post are based on the latest when you post
them. We assume this is the case.

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

Re: [PATCH rtems-docs v4] raspberrypi4.rst: Documentation for the new AArch64 Raspberry pi 4B BSP

[Chris Johns]

Looks good. Thank you for your patience in getting the changes made.

Chris

On 7/10/2022 4:16 pm, Noor Aman wrote:
> New patch sent with new changes.
> 
> On Fri, 7 Oct 2022 at 10:30, Mohd Noor Aman  > wrote:
> 
> This patch adds the relevant documentations required for booting the new 
> BSP.
> JTAG support is added for debugging. I have built the HTML docs and 
> verified
> them.
> ---
>  user/bsps/aarch64/raspberrypi4.rst | 111 +
>  user/bsps/bsps-aarch64.rst         |   1 +
>  2 files changed, 112 insertions(+)
>  create mode 100644 user/bsps/aarch64/raspberrypi4.rst
> 
> diff --git a/user/bsps/aarch64/raspberrypi4.rst
> b/user/bsps/aarch64/raspberrypi4.rst
> new file mode 100644
> index 000..b36d47b
> --- /dev/null
> +++ b/user/bsps/aarch64/raspberrypi4.rst
> @@ -0,0 +1,111 @@
> +.. SPDX-License-Identifier: CC-BY-SA-4.0
> +
> +.. Copyright (C) 2022 Mohd Noor Aman
> +
> +.. _BSP_aarch64_Raspberrypi_4:
> +
> +Raspberry Pi 4B
> +===
> +
> +The 'raspberrypi4b' BSP currently supports only the LP64 ABI. ILP32 is 
> not
> +supported. Raspberry pi 4B all variants and Raspberry Pi 400  are
> supported. The
> +default bootloader which is used by the Raspbian OS or other OS can be 
> used to
> +boot RTEMS. SMP is currently not supported.
> +
> +Raspberry Pi 4B has 2 types of interrupt controller, GIC-400 (GICv2) and 
> ARM
> +legacy generic controller. Both are supported. By default, raspberrypi 
> 4B uses
> +ARM legacy generic controller. Set ``enable_gic=1`` in the 
> ``config.txt`` file
> +to enable GIC.
> +
> +Clock Driver
> +
> +
> +The clock driver uses the `ARM Generic Timer`.
> +
> +Console Driver
> +--
> +
> +Raspberry pi 4B has 2 types of UARTs, ARM PL011 and Mini-uart. The PL011 
> is a
> +capable, broadly 16550-compatible UART, while the mini UART has a reduced
> +feature set. The console driver supports the default Qemu emulated ARM 
> PL011
> +PrimeCell UART as well as the physical ARM PL011 PrimeCell UART in the
> +raspberrypi hardware. Mini-uart is not supported.
> +
> +Preparing to boot
> +--
> +
> +Raspberry Pi uses a different mechanism to boot when compared with any 
> ARM SoC.
> +First the GPU initializes, loads the bootloader (Raspberry pi firmware) 
> and
> then
> +looks for the kernel img. This whole process is done by the GPU 
> (VideoCore IV)
> +till the kernel is loaded. More information can be found on the 
> `Raspberry pi
> +documentation page
> 
> +  
> >`_.
> +By default the arm64 mode looks for the ``kernel8.img``. Any other kernel
> can be
> +loaded by adding ``kernel=`` to the ``config.txt`` file.
> +
> +The Firmware files are required in order to boot RTEMS. The latest 
> firmware can
> +be downloaded from the `Raspberry Pi Firmware Repository
> + >`_. USB boot is supported. All 
> the
> +files (Firmwares and kernel) must be place in the FAT32 partition only. 
> Add
> +``arm_64bit=1`` in the ``config.txt`` file in order to boot the BSP in 
> 64bit
> +kernel mode.
> +
> +
> +UART Setup
> +^^
> +
> +Connect your serial device to the GPIO15 and GPIO14. Add the following 
> to the
> +``config.txt`` file in order to use the PL011 UART0 and thus disabling 
> the
> +default Mini-uart.
> +
> +.. code-block:: none
> +
> +  # if user wants to enable GIC, uncomment the next line
> +  # enable_gic=1
> +  arm_64bit=1
> +  dtoverlay = disable-bt
> +  enable_uart=1
> +
> +.. note::
> +  The Raspberry Pi 4B and 400 have an additional four PL011 UARTs. They 
> are
> not
> +  supported.
> +
> +Generating kernel image
> +^^^
> +
> +The following steps show how to run ``hello.exe`` on the BSP. Other 
> executables
> +can be processed in a similar way.
> +
> +To create the kernel image:
> +
> +.. code-block:: shell
> +
> +  $ aarch64-rtems@rtems-ver-major@-objcopy -Obinary hello.exe kernel8.img
> +
> +Copy the kernel image to the SD card.
> +
> +JTAG Setup
> +--
> +
> +The Raspberry Pi 4 doesn't have dedicated JTAG pins. Instead, you must
> configure
> +the GPIO pins (GPIO22-GPIO27) to activate the JTAG functionality. The 
> RPi 4
> +documentation refers to this as Alt4 functions of those pins. Alt5 does 
> exist
> +too, which goes from GPIO4, 5, 6, 

Re: [PATCH v2 06/13] score: Add CPU_THREAD_LOCAL_STORAGE_VARIANT

[Chris Johns]

On 7/10/2022 3:33 pm, Sebastian Huber wrote:
> On 07.10.22 06:31, Chris Johns wrote:
>> On 7/10/2022 3:23 pm, Sebastian Huber wrote:
>>> On 07.10.22 05:44, Chris Johns wrote:
>>>> On 6/10/2022 7:23 pm, Sebastian Huber wrote:
>>>>> +#if CPU_THREAD_LOCAL_STORAGE_VARIANT == 10
>>>>> +  tls_data = (void *)
>>>>> +    RTEMS_ALIGN_UP( (uintptr_t) tls_area + sizeof( *tcb ), alignment );
>>>>> +  tcb = (TLS_Thread_control_block *) ((char *) tls_data - sizeof( *tcb 
>>>>> ));
>>>>> +  return_value = tls_data;
>>>>> +#elif CPU_THREAD_LOCAL_STORAGE_VARIANT == 11
>>>>> +  tcb_size = RTEMS_ALIGN_UP( sizeof( *tcb ), alignment );
>>>>> +  tls_data = (void *)
>>>>> +    RTEMS_ALIGN_UP( (uintptr_t) tls_area + tcb_size, alignment );
>>>>> +  tcb = (TLS_Thread_control_block *) ((char *) tls_data - tcb_size);
>>>>> +  return_value = tcb;
>>>>> +#elif CPU_THREAD_LOCAL_STORAGE_VARIANT == 20
>>>>> +  alignment_2 = RTEMS_ALIGN_UP( alignment, CPU_SIZEOF_POINTER );
>>>>> +  tls_area = (void *) RTEMS_ALIGN_UP( (uintptr_t) tls_area, alignment_2 
>>>>> );
>>>>> +  size = _TLS_Get_size();
>>>>> +  tcb = (TLS_Thread_control_block *)
>>>>> +    ((char *) tls_area + RTEMS_ALIGN_UP( size, alignment_2 ));
>>>>> +  tls_data = (char *) tcb - RTEMS_ALIGN_UP( size, alignment );
>>>>> +  return_value = tcb;
>>>>> +#else
>>>>> +#error "unexpected CPU_THREAD_LOCAL_STORAGE_VARIANT value"
>>>> What are the expected values? I can see 10, 11, 20.
>>>>
>>>> Can this please be changed to something readable? For example:
>>>>
>>>> #if CPU_THREAD_LOCAL_STORAGE_VARIANT == CPU_THREAD_LOCAL_STORAGE_BLAH
>>>>
>>>> #elif CPU_THREAD_LOCAL_STORAGE_VARIANT == 
>>>> CPU_THREAD_LOCAL_STORAGE_BLAH_BLAH
>>>
>>> This is documented in the no_cpu/cpuimpl.h. I think the numbers are all 
>>> right if
>>> you know the TLS variants. Otherwise we would have to add an extra header 
>>> file
>>> just for the CPU_THREAD_LOCAL_STORAGE_* defines.
>>
>> Is the doco in this patch? I could not find it.
> 
> Yes, all the CPU port options are documented in the no_cpu port:
> 
> diff --git a/cpukit/score/cpu/no_cpu/include/rtems/score/cpuimpl.h
> b/cpukit/score/cpu/no_cpu/include/rtems/score/cpuimpl.h
> index d5082383e8..72d223de24 100644
> --- a/cpukit/score/cpu/no_cpu/include/rtems/score/cpuimpl.h
> +++ b/cpukit/score/cpu/no_cpu/include/rtems/score/cpuimpl.h
> @@ -54,6 +54,24 @@
>   */
>  #define CPU_PER_CPU_CONTROL_SIZE 0
> 
> +/**
> + * @brief Defines the thread-local storage (TLS) variant.
> + *
> + * Use one of the following values:
> + *
> + * 10: The architecture uses Variant I and the TLS offsets emitted by the
> + * linker neglect the TCB (examples: nios2, m68k, microblaze, powerpc,
> + * riscv).  The thread pointer directly references the thread-local data
> + * area.
> + *
> + * 11: The architecture uses Variant I and the TLS offsets emitted by the
> + * linker take the TCB into account (examples: arm, aarch64).
> + * The thread pointer references the TCB.
> + *
> + * 20: The architecture uses Variant II (examples: i386, sparc).
> + */
> +#define CPU_THREAD_LOCAL_STORAGE_VARIANT 10
> +
>  #ifndef ASM
> 
>  #ifdef __cplusplus

Thanks. The number now make sense to me.

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

Re: [PATCH v2 06/13] score: Add CPU_THREAD_LOCAL_STORAGE_VARIANT

[Chris Johns]

On 7/10/2022 3:23 pm, Sebastian Huber wrote:
> On 07.10.22 05:44, Chris Johns wrote:
>> On 6/10/2022 7:23 pm, Sebastian Huber wrote:
>>> +#if CPU_THREAD_LOCAL_STORAGE_VARIANT == 10
>>> +  tls_data = (void *)
>>> +    RTEMS_ALIGN_UP( (uintptr_t) tls_area + sizeof( *tcb ), alignment );
>>> +  tcb = (TLS_Thread_control_block *) ((char *) tls_data - sizeof( *tcb ));
>>> +  return_value = tls_data;
>>> +#elif CPU_THREAD_LOCAL_STORAGE_VARIANT == 11
>>> +  tcb_size = RTEMS_ALIGN_UP( sizeof( *tcb ), alignment );
>>> +  tls_data = (void *)
>>> +    RTEMS_ALIGN_UP( (uintptr_t) tls_area + tcb_size, alignment );
>>> +  tcb = (TLS_Thread_control_block *) ((char *) tls_data - tcb_size);
>>> +  return_value = tcb;
>>> +#elif CPU_THREAD_LOCAL_STORAGE_VARIANT == 20
>>> +  alignment_2 = RTEMS_ALIGN_UP( alignment, CPU_SIZEOF_POINTER );
>>> +  tls_area = (void *) RTEMS_ALIGN_UP( (uintptr_t) tls_area, alignment_2 );
>>> +  size = _TLS_Get_size();
>>> +  tcb = (TLS_Thread_control_block *)
>>> +    ((char *) tls_area + RTEMS_ALIGN_UP( size, alignment_2 ));
>>> +  tls_data = (char *) tcb - RTEMS_ALIGN_UP( size, alignment );
>>> +  return_value = tcb;
>>> +#else
>>> +#error "unexpected CPU_THREAD_LOCAL_STORAGE_VARIANT value"
>> What are the expected values? I can see 10, 11, 20.
>>
>> Can this please be changed to something readable? For example:
>>
>> #if CPU_THREAD_LOCAL_STORAGE_VARIANT == CPU_THREAD_LOCAL_STORAGE_BLAH
>>
>> #elif CPU_THREAD_LOCAL_STORAGE_VARIANT == CPU_THREAD_LOCAL_STORAGE_BLAH_BLAH
> 
> This is documented in the no_cpu/cpuimpl.h. I think the numbers are all right 
> if
> you know the TLS variants. Otherwise we would have to add an extra header file
> just for the CPU_THREAD_LOCAL_STORAGE_* defines.

Is the doco in this patch? I could not find it.

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

Re: [PATCH 06/13] config: Add rtems_malloc_task_stack_for_idle()

[Chris Johns]

On 7/10/2022 3:25 pm, Sebastian Huber wrote:
> On 07.10.22 04:57, Chris Johns wrote:
>> On 6/10/2022 6:35 pm, Sebastian Huber wrote:
>>> On 06/10/2022 00:13, Chris Johns wrote:
>>>> Will the IDLE TLS size be based on the
>>>> CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE if it is not zero? This effects
>>>> libdl once it supports loading TLS based code.
>>>
>>> Currently, only the actual TLS size is used. We would have to change
>>> _TLS_Get_allocation_size() to use the maximum if it is non-zero.
>>
>> It would be good to get this sorted and in before a push is made on libdl to
>> support TLS. I think the newlib change will make TLS a visible issue in 
>> libdl in
>> 6 so it needs to be fixed.
> 
> I checked _TLS_Get_allocation_size(). It already returns the maximum size if 
> it
> is configured:
> 
>     if ( _Thread_Maximum_TLS_size != 0 ) {
>   if ( allocation_size <= _Thread_Maximum_TLS_size ) {
>     _Assert( _Thread_Maximum_TLS_size % CPU_STACK_ALIGNMENT == 0 );
>     allocation_size = _Thread_Maximum_TLS_size;
>   } else {
>     _Internal_error( INTERNAL_ERROR_TOO_LARGE_TLS_SIZE );
>   }
>     }
> 

Thanks. I also checked and found this. It looks good to me.

Is the end of the TLS BSS area the start of the TSL space available for libdl to
use?

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

Re: [PATCH v2 06/13] score: Add CPU_THREAD_LOCAL_STORAGE_VARIANT

[Chris Johns]

On 6/10/2022 7:23 pm, Sebastian Huber wrote:
> +#if CPU_THREAD_LOCAL_STORAGE_VARIANT == 10
> +  tls_data = (void *)
> +RTEMS_ALIGN_UP( (uintptr_t) tls_area + sizeof( *tcb ), alignment );
> +  tcb = (TLS_Thread_control_block *) ((char *) tls_data - sizeof( *tcb ));
> +  return_value = tls_data;
> +#elif CPU_THREAD_LOCAL_STORAGE_VARIANT == 11
> +  tcb_size = RTEMS_ALIGN_UP( sizeof( *tcb ), alignment );
> +  tls_data = (void *)
> +RTEMS_ALIGN_UP( (uintptr_t) tls_area + tcb_size, alignment );
> +  tcb = (TLS_Thread_control_block *) ((char *) tls_data - tcb_size);
> +  return_value = tcb;
> +#elif CPU_THREAD_LOCAL_STORAGE_VARIANT == 20
> +  alignment_2 = RTEMS_ALIGN_UP( alignment, CPU_SIZEOF_POINTER );
> +  tls_area = (void *) RTEMS_ALIGN_UP( (uintptr_t) tls_area, alignment_2 );
> +  size = _TLS_Get_size();
> +  tcb = (TLS_Thread_control_block *)
> +((char *) tls_area + RTEMS_ALIGN_UP( size, alignment_2 ));
> +  tls_data = (char *) tcb - RTEMS_ALIGN_UP( size, alignment );
> +  return_value = tcb;
> +#else
> +#error "unexpected CPU_THREAD_LOCAL_STORAGE_VARIANT value"

What are the expected values? I can see 10, 11, 20.

Can this please be changed to something readable? For example:

#if CPU_THREAD_LOCAL_STORAGE_VARIANT == CPU_THREAD_LOCAL_STORAGE_BLAH

#elif CPU_THREAD_LOCAL_STORAGE_VARIANT == CPU_THREAD_LOCAL_STORAGE_BLAH_BLAH

> +#endif
> +
> +  _TLS_Initialize_TCB_and_DTV( tls_data, tcb, dtv );
> +  _TLS_Copy_and_clear( tls_data );
> +
> +  return return_value;
>  }

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

Re: [tools] tester: Check for begin/end of test

[Chris Johns]

OK

Thanks
Chris

On 6/10/2022 6:29 pm, Sebastian Huber wrote:
> Check for "BEGIN OF TEST" and "END OF TEST" to not use other information 
> blocks
> such as "END OF GCOV" to determine the test status.
> ---
>  tester/rt/report.py | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/tester/rt/report.py b/tester/rt/report.py
> index d3bf1cb..21580e2 100644
> --- a/tester/rt/report.py
> +++ b/tester/rt/report.py
> @@ -144,11 +144,11 @@ class report(object):
>  if line[0] == output_prefix:
>  if line[1].startswith('*** '):
>  banner = line[1][4:]
> -if banner.startswith('BEGIN OF '):
> +if banner.startswith('BEGIN OF TEST '):
>  start = True
> -elif line[1][4:].startswith('END OF '):
> +elif banner.startswith('END OF TEST '):
>  end = True
> -elif line[1][4:].startswith('FATAL'):
> +elif banner.startswith('FATAL'):
>  fatal = True
>  elif banner.startswith('TIMEOUT TIMEOUT'):
>  timeout = True
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 06/13] config: Add rtems_malloc_task_stack_for_idle()

[Chris Johns]

On 6/10/2022 6:35 pm, Sebastian Huber wrote:
> On 06/10/2022 00:13, Chris Johns wrote:
>> Will the IDLE TLS size be based on the
>> CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE if it is not zero? This effects
>> libdl once it supports loading TLS based code.
> 
> Currently, only the actual TLS size is used. We would have to change
> _TLS_Get_allocation_size() to use the maximum if it is non-zero.

It would be good to get this sorted and in before a push is made on libdl to
support TLS. I think the newlib change will make TLS a visible issue in libdl in
6 so it needs to be fixed.

Chris

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

[RBW] Re: Long Chainstay Living

[JohnS]

Emmet,

The pic of you smiling ear to ear says it all! Glad you're enjoying it so 
much.

JohnS


On Wednesday, October 5, 2022 at 8:20:06 PM UTC-4 Rick Harries wrote:

> Great looking Atlantis!  I’m also enjoying a long chain stay bike - a 64 
> cm Homer Hilsen. Wonderful for touring with rear panniers on pavement and 
> the occasional tow path and gravel road. Handles 35 lbs of gear in the 
> hills and rough roads with an ease that I haven’t found in any of the other 
> touring bikes I’ve had. I still prefer the look of a classic level top tube 
> bike, but the ride of the LWB Hilsen is a revelation for me. 
>
> Rick Harries
> Easton, Maryland
>
> On Wednesday, October 5, 2022 at 3:36:46 AM UTC-4 Luke Hendrickson wrote:
>
>> Beautiful build, Emmet! I’ve also fallen under the spell of the 62cm 
>> Atlantis. Knobby tires front (2.4”) and rear (2.3”) really complement the 
>> overall build (friction with 12-32 in the rear and 44-32-22 in the front). 
>> I was actually shredding on some trails daydreaming about what this would 
>> look like spec’d as a touring bike. Stoked to hear more from you about your 
>> lovely Atlantis and also hear more from others about touring with one!
>>
>> On Tuesday, October 4, 2022 at 7:23:52 PM UTC-7 e.q.s...@gmail.com wrote:
>>
>>> Accompanying Album: https://photos.app.goo.gl/4bGXtPryjGpsePdx7
>>>
>>> Howdy all, 
>>>
>>> Just wanted to share my new 62cm Atlantis I received by way of Hope 
>>> Cyclery. While waiting for this bike to be built due to parts shortage, I 
>>> came across a Rambouillet that I have been riding religiously (maybe a post 
>>> for another day). Anyway, this bike is something else. When the bike came, 
>>> I had issues with reach being completely upright with Tosco bars and a 
>>> 100mm stem. We quickly switched to the crust towel racks 67cm with a 60mm 
>>> stem. It completely made the bike for me (95 PBH with a shorter torso). 
>>> Sitting in the hoods is comfortable for most riding, the drops for the 
>>> cutty, and the swept back flats for those ghastly western PA climbs when I 
>>> have to bailout.
>>>
>>> It's currently set up with 2.2 UD Mars tires for the dirt. These photos 
>>> were taken in Stackhouse Park just outside of Johnstown, PA. I have also 
>>> ridden it in the bits of singletrack around Pittsburgh in the last couple 
>>> of days. It is unbelievably smooth and completely stable which I'm 
>>> attributing to those crazy long chainstays. However, it also just tears 
>>> through everything. It's remarkably fast on the road with this knobby of a 
>>> tire. 
>>>
>>> Riding it like this makes me wonder if anyone has toured on the MIT 
>>> Atlantis? Maybe with antelope pass tires, it makes me excited to think that 
>>> it has the ability to be just as capable on paved. 
>>>
>>> Best, 
>>> Emmet
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/681db483-eef2-48eb-9f04-7dc0883e2cc8n%40googlegroups.com.

Re: [EX]Re: xilinx_zynqmp_ilp32_zu3eg namespace issue (cmath round not in std)

[Chris Johns]

On 6/10/2022 5:54 am, Trip Richert wrote:
> I've been using primarily :
> 
> aarch64-rtems6-gcc (GCC) 10.3.1 20210409 (RTEMS 6, RSB no-repo, Newlib 
> 0c0f3df)
> aarch64-rtems6-g++ (GCC) 10.3.1 20210409 (RTEMS 6, RSB no-repo, Newlib 
> 0c0f3df)
> 
> but also tested it with 
> 
> aarch64-rtems6-gcc (GCC) 12.2.1 20220924 (RTEMS 6, RSB
> cfed1659a297cb0f95a03e053345962097aa02bf, Newlib 01f6251c0)
> aarch64-rtems6-g++ (GCC) 12.2.1 20220924 (RTEMS 6, RSB
> cfed1659a297cb0f95a03e053345962097aa02bf, Newlib 01f6251c0)
> 

I can confirm the example code in
https://en.cppreference.com/w/cpp/numeric/math/round fails to build with
aarch64-rtems6-gcc and it does builds with arm-rtems6-gcc.

Something is broken. Joel?

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

Re: [PATCH rtems-docs v2] raspberrypi4.rst: Added Documentation for the new AArch64 Raspberry pi 4B BSP

[Chris Johns]

Thanks for the documentation. It is great to have this.

My comments are below.

On 5/10/2022 4:41 pm, Mohd Noor Aman wrote:
> This patch adds the relevant documentations required for booting the new BSP.
> JTAG support is added for debugging. I have built the HTML docs and verified
> them.
> ---
>  user/bsps/aarch64/raspberrypi4.rst | 99 ++
>  user/bsps/bsps-aarch64.rst |  1 +
>  2 files changed, 100 insertions(+)
>  create mode 100644 user/bsps/aarch64/raspberrypi4.rst
> 
> diff --git a/user/bsps/aarch64/raspberrypi4.rst 
> b/user/bsps/aarch64/raspberrypi4.rst
> new file mode 100644
> index 000..5a45c65
> --- /dev/null
> +++ b/user/bsps/aarch64/raspberrypi4.rst
> @@ -0,0 +1,99 @@
> +.. SPDX-License-Identifier: CC-BY-SA-4.0
> +
> +.. Copyright (C) 2022 Mohd Noor Aman
> +
> +.. _BSP_aarch64_Raspberrypi_4:
> +
> +Raspberry Pi 4B
> +===
> +
> +The 'raspberrypi4b' BSP currently supports only the LP64 ABI. ILP32 is not

Should this be ``raspberrypi4b``?

> +supported. Raspberry pi 4B all variants and Raspberry Pi 400  are supported. 

Maybe:

All variants of the Raspberry pi 4B  and Raspberry Pi 400 are supported.

> The
> +default bootloader which is used by the Raspbian OS or other OS can be used 
> to
> +boot the RTEMS. 

I think it would help to explain what the default bootloader is? I am not sure
what this means.

> Currently, QEMU emulation is not supported. 
> +
> +Clock Driver
> +
> +
> +The clock driver uses the `ARM Generic Timer`.
> +
> +Console Driver
> +--
> +
> +Raspberry pi 4B has 2 types of UARTs, ARM PL011 and Mini-uart. The PL011 is a
> +capable, broadly 16550-compatible UART, while the mini UART has a reduced
> +feature set. The console driver supports the default Qemu emulated ARM PL011
> +PrimeCell UART as well as the physical ARM PL011 PrimeCell UART in the
> +raspberrypi hardware. Mini-uart is not supported.

What are the configuration options?

> +
> +Preparing to boot

Please change to:

Preparing to Boot

> +--
> +
> +Raspberry Pi uses a different mechanism to boot. First the GPU initializes,
> +loads the bootloader and then looks for the kernel img. By default the arm64

img should be image

> +mode looks for the ``kernel8.img``. Any other kernel can be loaded by adding
> +`kernel=` to the ``config.txt``.

Is config.txt explained, ie a text file in the root directory of the SD card?

> +
> +The Firmware files are required in order to boot RTEMS. The latest firmware 
> can
> +be downloaded from the `Raspberry Pi Firmware Repository
> +`_. USB boot is supported. All the
> +files (Firmwares and kernel) must be place in the FAT32 partition only. Add
> +``arm_64bit=1`` in the config.txt file in order to boot the BSP in 64bit 
> kernel
> +mode. 
> +
> +
> +UART Setup
> +^^
> +
> +Connect your serial device to the GPIO15 and GPIO14. Add the following to the
> +config.txt file in order to use the PL011 UART0 and thus disabling the 
> default
> +Mini-uart.
> +
> +.. code-block:: none
> +
> +  dtoverlay = disable-bt
> +  enable_uart=1
> +
> +.. note:: 
> +  The Raspberry Pi 4B and 400 have an additional four PL011 UARTs. They are 
> not 
> +  supported.
> +
> +Generating kernel image 

Change to:

Generating Kernel Image

> +^^^
> +
> +The following steps show how to run ``hello.exe`` on the BSP. Other 
> executables
> +can be processed in a similar way.
> +
> +To create the kernel image:
> +
> +.. code-block:: shell
> +
> +  $ aarch64-rtems@rtems-ver-major@-objcopy -Obinary hello.exe kernel8.img
> +
> +Copy the kernel image to the SD card.

To the root directory of the SD card?

> +
> +JTAG Setup

Change to:

JTAG Set-up

> +--
> +
> +The Raspberry Pi 4 doesn't have dedicated JTAG pins. Instead, you must 
> configure
> +the GPIO pins (GPIO22-GPIO27) to activate the JTAG functionality. The RPi 4
> +documentation refers to this as Alt4 functions of those pins. Alt5 does exist
> +too, which goes from GPIO4, 5, 6, 12 and 13. you can check this out from
> +`pinout.xyz `_ or `eLinux
> +`_
> +

What about:

The Raspberry Pi 4 doesn't have dedicated JTAG pins. To use JTAG configure
the GPIO pins (GPIO22-GPIO27) to activate the JTAG functionality. The RPi 4
documentation refers to this as Alt4 functions of those pins. Alt5 does exist
and goes from GPIO4, 5, 6, 12 and 13. You can check this out from
`pinout.xyz `_ or `eLinux
> +`_

Also what does Alt5 offer? I see it mentioned but I do not know why?

> +One more thing to note on JTAG with Raspberry pi 4B is that, by default, All 
> the
> +GPIO pins are pulled down, according to the `BCM2711 documentation
> +`_. This
> +wasn't the case in the earlier models. So in order to let 

Re: [PATCH 06/13] config: Add rtems_malloc_task_stack_for_idle()

[Chris Johns]

On 5/10/2022 4:00 pm, Sebastian Huber wrote:
> On 04/10/2022 23:21, Chris Johns wrote:
>> On 5/10/2022 12:41 am, Sebastian Huber wrote:
>>> On 04/10/2022 15:21, Joel Sherrill wrote:
>>>> On Tue, Oct 4, 2022 at 12:40 AM Sebastian Huber
>>>> >>> <mailto:sebastian.hu...@embedded-brains.de>> wrote:
>>>>
>>>>  On 30/09/2022 23:39, Chris Johns wrote:
>>>>   > On 30/9/2022 7:21 pm, Sebastian Huber wrote:
>>>>   >> Update #4524.
>>>>   >> ---
>>>>   >>   cpukit/doxygen/appl-config.h                | 13 +
>>>>   >>   cpukit/include/rtems/rtems/config.h         | 29 +-
>>>>   >>   cpukit/include/rtems/score/interr.h         |  1 +
>>>>   >>   cpukit/sapi/src/interrtext.c                |  3 +-
>>>>   >>   cpukit/sapi/src/malloctaskstackforidle.c    | 59
>>>>  +
>>>>   >>   spec/build/cpukit/librtemscpu.yml           |  1 +
>>>>   >>   spec/build/testsuites/sptests/grp.yml       |  2 +
>>>>   >>   spec/build/testsuites/sptests/spfatal36.yml | 19 +++
>>>>   >>   testsuites/sptests/spfatal36/init.c         | 52
>>>>  ++
>>>>   >>   testsuites/sptests/spfatal36/spfatal36.doc  | 11 
>>>>   >>   testsuites/sptests/spinternalerror02/init.c |  2 +-
>>>>   >>   testsuites/sptests/sptls04/init.c           |  2 +
>>>>   >>   12 files changed, 191 insertions(+), 3 deletions(-)
>>>>   >>   create mode 100644 cpukit/sapi/src/malloctaskstackforidle.c
>>>>   >>   create mode 100644 spec/build/testsuites/sptests/spfatal36.yml
>>>>   >>   create mode 100644 testsuites/sptests/spfatal36/init.c
>>>>   >>   create mode 100644 testsuites/sptests/spfatal36/spfatal36.doc
>>>>   >>
>>>>   >> diff --git a/cpukit/doxygen/appl-config.h
>>>>  b/cpukit/doxygen/appl-config.h
>>>>   >> index aa6dbae648..ee647dc961 100644
>>>>   >> --- a/cpukit/doxygen/appl-config.h
>>>>   >> +++ b/cpukit/doxygen/appl-config.h
>>>>   >> @@ -4842,6 +4842,19 @@
>>>>   >>    * configuration options.  It is assumed that any memory
>>>>  allocated for the
>>>>   >>    * stack of an IDLE task will not be from the RTEMS Workspace
>>>>  or the memory
>>>>   >>    * statically allocated by default.
>>>>   >> + *
>>>>   >> + * For applications with a thread-local storage size which is
>>>>  completely
>>>>   >> + * unknown at the time the application configuration is
>>>>  defined, RTEMS provides
>>>>   >> + * an IDLE task stack allocator which uses rtems_malloc().
>>>>   >
>>>>   > I thought the TLS size was static and set by the linker? Has this
>>>>  changed?
>>>>
>>>>  No, this didn't change.
>>>>
>>>>   >
>>>>   > I am confused about the relationship between an unknown TLS size
>>>>  and IDLE task?
>>>>   > And the relationship of the TLS size and stack size?
>>>>
>>>>  Currently, the IDLE task storage area is statically allocated. The 
>>>> size
>>>>  of this area is defined by CONFIGURE_IDLE_TASK_STACK_SIZE. So, this
>>>>  configuration option doesn't directly specify the IDLE task stack 
>>>> size.
>>>>  This size covers also the TLS area.
>>>>
>>>>
>>>> Thanks for speaking up Chris. I also don't like the idea that something 
>>>> that
>>>> has said and meant IDLE stack size was getting other items lumped into it.
>>>>
>>>>
>>>>   >
>>>>   >> * * The size of the
>>>>   >> + * allocated thread storage area is the sum of stack size
>>>>  defined by the
>>>>   >> + * #CONFIGURE_IDLE_TASK_STACK_SIZE configuration option and the
>>>>  actual
>>>>   >> + * thread-local storage size of the application.
>>>>   >
>>>>   > The label CONFIGURE_IDLE_TASK_STACK_SIZE provides no insight in

Re: Git master/main/trunk/current/best...

[Chris Johns]

On 6/10/2022 6:14 am, Sebastian Huber wrote:
> On 05/10/2022 20:37, Joel Sherrill wrote:
>> On Thu, Sep 29, 2022 at 4:24 PM Chris Johns > <mailto:chr...@rtems.org>> wrote:
>>
>>     On 30/9/22 4:00 am, Joel Sherrill wrote:
>>  > I'd like to propose that short term we change lwip main to master for
>>  > consistency with existing repos. This helps avoid stupid mistakes
>>     because lwip
>>  > is the odd case.
>>
>>     I propose we use devel. I prefer it over main.
>>
>>
>> I'm ok with that. But no one else has spoken up.
> 
> I don't care that much about the name, however, github.com, gitlab.com, and
> bitbucket.org use "main" for the primary branch.

That is good to know. Happy to follow their lead and use main.

Timing for a switch?

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

Re: [PATCH] gsed.cfg: Add check for gsed

[Chris Johns]

On 6/10/2022 5:29 am, Ryan Long wrote:
> On 10/4/2022 4:31 PM, Chris Johns wrote:
>> On 5/10/2022 12:52 am, Ryan Long wrote:
>>> It looks like gcc checks for gsed if sed is not the GNU version.
>> Thanks for checking this.
>>
>>> I've installed it on FreeBSD and MacOS. I had to install it via Homebrew on
>>> MacOS, but that's because it fails to build gsed.
>> Homebrew complicates your work. I make sure my test Macs have never had 
>> Homebrew
>> or Macports installed. When I played with this a long time ago the install
>> prefix was /usr/local and after a while I found I had no idea what was 
>> installed
>> and what was provided by the OS and if the base OS versions were 
>> overwritten. I
>> believe Macports is not doing this these days (if it ever did) but I have not
>> looked.
> 
> On the m1 macs, Homebrew installs under /opt/homebrew/bin. The prefix for 
> Intel
> macs is /usr/local, so I assume anything installed would be under
> /usr/local/homebrew/bin.

That helps but I am not sure my point has been made that RTEMS as a project
depending on homebrew or macports complicates our builds and how we maintain
them long term. If either are rolling releases it is hard. There has been no
need for homebrew or macports up to now and I still do not see a need.

And I think they are great and useful projects so this is about how we maintain
our tools and not a reflection on them.

> I don't know when the packages in Homebrew may overwrite the programs used by
> the systems, but at least in the case of gsed, it didn't overwrite the 
> system's
> sed.>
>>
>>> The error is "machine `arm64-apple' not recognized".
>> Does the GNU sed upstream project have a fix?
> 
> I looked into how Homebrew builds it. All that they do is
> 
>   def install
>     args = %W[
>   --prefix=#{prefix}
>   --disable-dependency-tracking
>     ]
> 
>     args << if OS.mac?
>   "--program-prefix=g"
>     else
>   "--without-selinux"
>     end
>     system "./configure", *args
>     system "make", "install"
> 
> I experimented with the building of gsed with the RSB. I just removed the 
> --host
> flag, and I was able to get around the error. However, it then reports

What was `--host` set to?

Without the option what does sed'w configure detect the host to be?

> sizes: gsed-4.8-arm64-apple-darwin21.6.0-1: 16.874MB (installed: 0.000B)

Is this the latest RSB?

If it is I suggest you put the RSB aside and manually untar the source,
configure it and run make. Once you know how to build the package run the RSB
with --dry-run to get the options you need then remove the --dry-run option.
Always use --trace when adding a new build and look at the log file for the 
details.

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

Re: [docs 1/5] c-user: Add CONFIGURE_IDLE_TASK_MINIMUM_STACK_SIZE

[Chris Johns]

Hi,

Can we please wait until the patches are sorted before this is merged?

Thanks
Chris

On 30/9/2022 7:15 pm, Sebastian Huber wrote:
> ---
>  c-user/config/idle-task.rst| 95 --
>  c-user/config/task-stack-alloc.rst | 39 ++--
>  2 files changed, 124 insertions(+), 10 deletions(-)
> 
> diff --git a/c-user/config/idle-task.rst b/c-user/config/idle-task.rst
> index 359f862..d7b43ae 100644
> --- a/c-user/config/idle-task.rst
> +++ b/c-user/config/idle-task.rst
> @@ -1,6 +1,6 @@
>  .. SPDX-License-Identifier: CC-BY-SA-4.0
>  
> -.. Copyright (C) 2020, 2021 embedded brains GmbH 
> (http://www.embedded-brains.de)
> +.. Copyright (C) 2020, 2022 embedded brains GmbH 
> (http://www.embedded-brains.de)
>  .. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
>  
>  .. This file is part of the RTEMS quality process and was automatically
> @@ -134,6 +134,74 @@ options
>  
>  otherwise a compile time error in the configuration file will occur.
>  
> +.. Generated from spec:/acfg/if/idle-task-min-stack-size
> +
> +.. raw:: latex
> +
> +\clearpage
> +
> +.. index:: CONFIGURE_IDLE_TASK_MINIMUM_STACK_SIZE
> +.. index:: minimum task stack size
> +
> +.. _CONFIGURE_IDLE_TASK_MINIMUM_STACK_SIZE:
> +
> +CONFIGURE_IDLE_TASK_MINIMUM_STACK_SIZE
> +--
> +
> +.. rubric:: CONSTANT:
> +
> +``CONFIGURE_IDLE_TASK_MINIMUM_STACK_SIZE``
> +
> +.. rubric:: OPTION TYPE:
> +
> +This configuration option is an integer define.
> +
> +.. rubric:: DEFAULT VALUE:
> +
> +:c:macro:`CPU_STACK_MINIMUM_SIZE` / 4
> +
> +.. rubric:: DESCRIPTION:
> +
> +The value of this configuration option defines the minimum stack size in
> +bytes for every :term:`IDLE task` in the system.
> +
> +.. rubric:: NOTES:
> +
> +Adjusting this parameter should be done with caution.  Examining the actual
> +stack usage using the stack checker usage reporting facility is recommended
> +(see also :ref:`CONFIGURE_STACK_CHECKER_ENABLED`).
> +
> +This parameter can be used to increase the minimum from that
> +recommended. This can be used in higher memory systems to reduce the risk
> +of stack overflow without performing analysis on actual consumption.
> +
> +By default, the IDLE task storage areas are statically allocated.  The size
> +of the task storage area is defined by the 
> :ref:`CONFIGURE_IDLE_TASK_STACK_SIZE`
> +configuration option.  The task storage area contains the task stack, the
> +thread-local storage, and the floating-point context on architectures with a
> +separate floating-point context.  The size of the thread-local storage area
> +is defined at link time or by the 
> :ref:`CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE`
> +configuration option.  This configuration option is used to ensure that the
> +IDLE task stack size has at least the configured minimum size.  If the IDLE
> +task stack size is too small, for example because the thread-local storage
> +size is too large, then the system terminates with the
> +:ref:`INTERNAL_ERROR_CORE ` fatal source and the
> +:ref:`INTERNAL_ERROR_IDLE_THREAD_STACK_TOO_SMALL ` fatal 
> code during
> +system initialization.
> +
> +.. rubric:: CONSTRAINTS:
> +
> +The value of the configuration option shall be large enough so that
> +
> +* the thread handler can call the thread switch extensions for the IDLE task,
> +
> +* the thread handler can call the thread begin extensions for the IDLE task,
> +
> +* the thread handler can call the IDLE task body (see
> +  :ref:`CONFIGURE_IDLE_TASK_BODY`), and
> +
> +* the IDLE task can be interrupted by interrupt services.
> +
>  .. Generated from spec:/acfg/if/idle-task-stack-size
>  
>  .. raw:: latex
> @@ -165,13 +233,30 @@ defined by the :ref:`CONFIGURE_MINIMUM_TASK_STACK_SIZE` 
> configuration option.
>  
>  .. rubric:: DESCRIPTION:
>  
> -The value of this configuration option defines the task stack size for an
> -IDLE task.
> +The value of this configuration option defines the task storage area size for
> +an IDLE task.
>  
>  .. rubric:: NOTES:
>  
> -In SMP configurations, there is one IDLE task per configured processor, see
> -:ref:`CONFIGURE_MAXIMUM_PROCESSORS`.
> +Where the system was built with SMP support enabled, there is one IDLE task
> +for each configured processor, see :ref:`CONFIGURE_MAXIMUM_PROCESSORS`.
> +
> +By default, the IDLE task storage areas are statically allocated.  The size
> +of the task storage area for each IDLE task is defined by this configuration
> +option.  The task storage area contains the task stack, the thread-local
> +storage, and the floating-point context on architectures with a separate
> +floating-point context.  The size of the thread-local storage area is defined
> +at link time or by the :ref:`CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE` 
> configuration
> +option.  The :ref:`CONFIGURE_IDLE_TASK_MINIMUM_STACK_SIZE` configuration 
> option is used
> +to ensure that the IDLE task stack size has at least the configured minimum
> +size.  

Re: [PATCH v3] bsp/aarch64: Add new Raspberry Pi 4B BSP

[Chris Johns]

On 5/10/2022 5:39 am, Joel Sherrill wrote:
> Once Alan says it's OK, I will merge this.
> 
> Great work! Please make sure code, docs, tester configuration, etc gets 
> merged.

Looks great, well done for all the hard work.

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

Re: [PATCH] gsed.cfg: Add check for gsed

[Chris Johns]

On 5/10/2022 12:52 am, Ryan Long wrote:
> It looks like gcc checks for gsed if sed is not the GNU version.

Thanks for checking this.

> I've installed it on FreeBSD and MacOS. I had to install it via Homebrew on
> MacOS, but that's because it fails to build gsed.

Homebrew complicates your work. I make sure my test Macs have never had Homebrew
or Macports installed. When I played with this a long time ago the install
prefix was /usr/local and after a while I found I had no idea what was installed
and what was provided by the OS and if the base OS versions were overwritten. I
believe Macports is not doing this these days (if it ever did) but I have not
looked.

> The error is "machine `arm64-apple' not recognized".

Does the GNU sed upstream project have a fix?

> So I added this check to get around that, and it built successfully.

Sorry, I see Homebrew and Macports as user options and not a project option. We
need repeatable builds and not builds based on a local checkout of some 
packages.

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

Re: [PATCH 06/13] config: Add rtems_malloc_task_stack_for_idle()

[Chris Johns]

On 5/10/2022 12:41 am, Sebastian Huber wrote:
> On 04/10/2022 15:21, Joel Sherrill wrote:
>> On Tue, Oct 4, 2022 at 12:40 AM Sebastian Huber
>> > <mailto:sebastian.hu...@embedded-brains.de>> wrote:
>>
>>     On 30/09/2022 23:39, Chris Johns wrote:
>>  > On 30/9/2022 7:21 pm, Sebastian Huber wrote:
>>  >> Update #4524.
>>  >> ---
>>  >>   cpukit/doxygen/appl-config.h                | 13 +
>>  >>   cpukit/include/rtems/rtems/config.h         | 29 +-
>>  >>   cpukit/include/rtems/score/interr.h         |  1 +
>>  >>   cpukit/sapi/src/interrtext.c                |  3 +-
>>  >>   cpukit/sapi/src/malloctaskstackforidle.c    | 59
>>     +
>>  >>   spec/build/cpukit/librtemscpu.yml           |  1 +
>>  >>   spec/build/testsuites/sptests/grp.yml       |  2 +
>>  >>   spec/build/testsuites/sptests/spfatal36.yml | 19 +++
>>  >>   testsuites/sptests/spfatal36/init.c         | 52
>>     ++
>>  >>   testsuites/sptests/spfatal36/spfatal36.doc  | 11 
>>  >>   testsuites/sptests/spinternalerror02/init.c |  2 +-
>>  >>   testsuites/sptests/sptls04/init.c           |  2 +
>>  >>   12 files changed, 191 insertions(+), 3 deletions(-)
>>  >>   create mode 100644 cpukit/sapi/src/malloctaskstackforidle.c
>>  >>   create mode 100644 spec/build/testsuites/sptests/spfatal36.yml
>>  >>   create mode 100644 testsuites/sptests/spfatal36/init.c
>>  >>   create mode 100644 testsuites/sptests/spfatal36/spfatal36.doc
>>  >>
>>  >> diff --git a/cpukit/doxygen/appl-config.h
>>     b/cpukit/doxygen/appl-config.h
>>  >> index aa6dbae648..ee647dc961 100644
>>  >> --- a/cpukit/doxygen/appl-config.h
>>  >> +++ b/cpukit/doxygen/appl-config.h
>>  >> @@ -4842,6 +4842,19 @@
>>  >>    * configuration options.  It is assumed that any memory
>>     allocated for the
>>  >>    * stack of an IDLE task will not be from the RTEMS Workspace
>>     or the memory
>>  >>    * statically allocated by default.
>>  >> + *
>>  >> + * For applications with a thread-local storage size which is
>>     completely
>>  >> + * unknown at the time the application configuration is
>>     defined, RTEMS provides
>>  >> + * an IDLE task stack allocator which uses rtems_malloc().
>>  >
>>  > I thought the TLS size was static and set by the linker? Has this
>>     changed?
>>
>>     No, this didn't change.
>>
>>  >
>>  > I am confused about the relationship between an unknown TLS size
>>     and IDLE task?
>>  > And the relationship of the TLS size and stack size?
>>
>>     Currently, the IDLE task storage area is statically allocated. The size
>>     of this area is defined by CONFIGURE_IDLE_TASK_STACK_SIZE. So, this
>>     configuration option doesn't directly specify the IDLE task stack size.
>>     This size covers also the TLS area.
>>
>>
>> Thanks for speaking up Chris. I also don't like the idea that something that
>> has said and meant IDLE stack size was getting other items lumped into it.
>>
>>
>>  >
>>  >> * * The size of the
>>  >> + * allocated thread storage area is the sum of stack size
>>     defined by the
>>  >> + * #CONFIGURE_IDLE_TASK_STACK_SIZE configuration option and the
>>     actual
>>  >> + * thread-local storage size of the application.
>>  >
>>  > The label CONFIGURE_IDLE_TASK_STACK_SIZE provides no insight into
>>     it being
>>  > effected by the TLS size.
>>  >
>>  >> * * Define this configuration
>>  >> + * option to ``rtems_malloc_task_stack_for_idle`` to use this
>>     allocator.  If
>>  >> + * the memory allocation fails, then the system terminates with the
>>  >> + * INTERNAL_ERROR_CORE fatal source and the
>>  >> + * INTERNAL_ERROR_NO_MEMORY_FOR_IDLE_TASK_STACK fatal code
>>     during system
>>  >> + * initialization.
>>  >> + * @endparblock
>>  >
>>  > I am confused about the how and why I would use this change?
>>
>>     With the statically allocated storage area for the IDLE task you
>>     need at
>>     least

[RBW] Re: Philadelphia Bike Expo 2022

[JohnS]

Hello Roberta,

I'm planning to be there on Saturday. Same as last year, I'll park at the 
northern end of the Wissahickon trail and ride to the convention center. 
Anyone want to join me, just let me know.

Look forward to see everyone there.
JohnS

On Tuesday, October 4, 2022 at 9:35:13 AM UTC-4 Roberta wrote:

> Andy, I love this!  Also, hope to see you again.
>
> On Tuesday, October 4, 2022 at 4:51:34 AM UTC-4 ascpgh wrote:
>
>> I trying to get there, bothersome work schedule has me working on both 
>> Friday and Monday around the weekend. I'm aiming for a turnpike motel then 
>> close in for a Saturday night location near the SEPTA for both parking and 
>> an orderly exit for home Sunday. 
>>
>> I now think of this gathering as a "meet your maker" opportunity. Amazing 
>> how after a few conversations you find yourself in the industry, because 
>> you are the focus at this bike expo. 
>>
>> Andy Cheatham
>> Pittsburgh
>>
>> On Sunday, October 2, 2022 at 8:55:34 PM UTC-4 Bicycle Belle Ding Ding! 
>> wrote:
>>
>>> I’m tentatively planning to be there. I will arrive Friday evening and 
>>> have to leave late morning Sunday. I’d love to meet Riv people! Roberta and 
>>> I have met a few times in real life on my turf but this will be my first 
>>> time on hers! I’ve been dying to meet Pam Murray and she will be at the 
>>> expo. Who else can come? 
>>> Leah
>>>
>>> On Saturday, October 1, 2022 at 8:03:22 PM UTC-4 Roberta wrote:
>>>
>>>> Oct 29 and 30, downtown Philadelphia, easily accessible by car, Septa, 
>>>> NJ Transit, Amtrak, Greyhound, etc.,  and bike!  They also have free valet 
>>>> bike parking inside. 
>>>>
>>>> https://phillybikeexpo.com/  
>>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/e835315b-4e0d-4954-8565-e5385a1c56e7n%40googlegroups.com.

Re: [PATCH] c-user: Add application config info directives

[Chris Johns]

On 1/10/2022 12:25 am, Sebastian Huber wrote:
> On 17/09/2022 09:31, Chris Johns wrote:
>>> diff --git a/c-user/config/introduction.rst b/c-user/config/introduction.rst
>>> new file mode 100644
>>> index 000..d06662a
>>> --- /dev/null
>>> +++ b/c-user/config/introduction.rst
>>> @@ -0,0 +1,221 @@
>>> +.. SPDX-License-Identifier: CC-BY-SA-4.0
>>> +
>>> +.. Copyright (C) 2009, 2021 embedded brains GmbH
>>> (http://www.embedded-brains.de)
>>> +.. Copyright (C) 1988, 2021 On-Line Applications Research Corporation (OAR)
>> Is this right? I see in the diff fragments Gedare?
> 
> Yes, I think so. Gedare has a copyright in the unlimited objects section.
> 

Great and thanks

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

Re: [PATCH] c-user: Add application config info directives

[Chris Johns]

On 30/9/2022 11:43 pm, Sebastian Huber wrote:
> On 17/09/2022 09:31, Chris Johns wrote:
>>> +rtems_configuration_get_milliseconds_per_tick()
>>> +---
>>> +
>>> +Gets the number of milliseconds per clock tick configured for this 
>>> application.
>> There are other API calls that return this value. What should a user do?
> 
> I don't know another API function to get this value.

Yes there is not. It may have been 5 or 4.11 I was thinking about. I have been
working with those version.

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

Re: [PATCH] c-user: Add application config info directives

[Chris Johns]

On 30/9/2022 11:34 pm, Sebastian Huber wrote:
> On 17/09/2022 09:31, Chris Johns wrote:
>>> +rtems_get_version_string()
>>> +--
>>> +
>>> +Gets the RTEMS version string.
>>> +
>>> +.. rubric:: CALLING SEQUENCE:
>>> +
>>> +.. code-block:: c
>>> +
>>> +    const char *rtems_get_version_string( void );
>>> +
>>> +.. rubric:: RETURN VALUES:
>>> +
>>> +Returns the pointer to the RTEMS version string.
>> Is the version string subject to change across releases or do as set this 
>> string
>> format?
>>
>> Is it worth discussing the revision values and what they mean?
> 
> The version string contains a lot of stuff:
> 
> const char _RTEMS_version[] =
>   "rtems-" RTEMS_VERSION " (" CPU_NAME "/" CPU_MODEL_NAME "/"
>   RTEMS_XSTRING( RTEMS_BSP ) ")";
> 
> I don't know if we should specify a particular format.
> 

I agree. We should say it may change and parsing it may break.

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

Re: [PATCH] gsed.cfg: Add check for gsed

[Chris Johns]

On 4/10/2022 2:52 am, Ryan Long wrote:
> ---
>  bare/config/textproc/gsed.cfg | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/bare/config/textproc/gsed.cfg b/bare/config/textproc/gsed.cfg
> index 8287c74..b4aaf4f 100644
> --- a/bare/config/textproc/gsed.cfg
> +++ b/bare/config/textproc/gsed.cfg
> @@ -2,7 +2,7 @@
>  # GNU sed has a version option, check for it.
>  # If not found build it.
>  #
> -%define has_gnu_sed %(sed --version > /dev/null 2>&1; echo $?)
> +%define has_gnu_sed %(sed --version > /dev/null 2>&1 || gsed --version > 
> /dev/null 2>&1; echo $?)
>  %if %{has_gnu_sed} != 0
>   %include %{_configdir}/textproc/gsed-4.8.cfg
>  %endif

What does gcc require sed be as a command? Is it sed or gsed?

Which host has gsed installed?

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

Re: Libexpat missing when using Python from python.org

[Chris Johns]

On 4/10/2022 2:32 am, Ryan Long wrote:
> Hello,
> 
> Following Chris's advice, I installed Python 3.10.6 from Python's website. It
> gets me past the header check for gdb,

Great.

> but then it reports
> 
> 
> checking whether to use expat... yes
> 
> checking for libexpat... no
> 
> configure: error: expat is missing or unusable
> 
> make[1]: *** [configure-gdb] Error 1
> 
> make: *** [all] Error 2
> 
> 
> What's the best way to get Libexpat on macOS?
> 
> I was able to successfully build it with the python installed from Homebrew
> after disabling the building of gsed.

It should build for the Xcode (MacOS) python so I something is wrong in the GDB
common build script.

gsed has to be built if sed is not the GNU version

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

Re: [PATCH 06/13] config: Add rtems_malloc_task_stack_for_idle()

[Chris Johns]

On 30/9/2022 7:21 pm, Sebastian Huber wrote:
> Update #4524.
> ---
>  cpukit/doxygen/appl-config.h| 13 +
>  cpukit/include/rtems/rtems/config.h | 29 +-
>  cpukit/include/rtems/score/interr.h |  1 +
>  cpukit/sapi/src/interrtext.c|  3 +-
>  cpukit/sapi/src/malloctaskstackforidle.c| 59 +
>  spec/build/cpukit/librtemscpu.yml   |  1 +
>  spec/build/testsuites/sptests/grp.yml   |  2 +
>  spec/build/testsuites/sptests/spfatal36.yml | 19 +++
>  testsuites/sptests/spfatal36/init.c | 52 ++
>  testsuites/sptests/spfatal36/spfatal36.doc  | 11 
>  testsuites/sptests/spinternalerror02/init.c |  2 +-
>  testsuites/sptests/sptls04/init.c   |  2 +
>  12 files changed, 191 insertions(+), 3 deletions(-)
>  create mode 100644 cpukit/sapi/src/malloctaskstackforidle.c
>  create mode 100644 spec/build/testsuites/sptests/spfatal36.yml
>  create mode 100644 testsuites/sptests/spfatal36/init.c
>  create mode 100644 testsuites/sptests/spfatal36/spfatal36.doc
> 
> diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h
> index aa6dbae648..ee647dc961 100644
> --- a/cpukit/doxygen/appl-config.h
> +++ b/cpukit/doxygen/appl-config.h
> @@ -4842,6 +4842,19 @@
>   * configuration options.  It is assumed that any memory allocated for the
>   * stack of an IDLE task will not be from the RTEMS Workspace or the memory
>   * statically allocated by default.
> + *
> + * For applications with a thread-local storage size which is completely
> + * unknown at the time the application configuration is defined, RTEMS 
> provides
> + * an IDLE task stack allocator which uses rtems_malloc(). 

I thought the TLS size was static and set by the linker? Has this changed?

I am confused about the relationship between an unknown TLS size and IDLE task?
And the relationship of the TLS size and stack size?

> * * The size of the
> + * allocated thread storage area is the sum of stack size defined by the
> + * #CONFIGURE_IDLE_TASK_STACK_SIZE configuration option and the actual
> + * thread-local storage size of the application.

The label CONFIGURE_IDLE_TASK_STACK_SIZE provides no insight into it being
effected by the TLS size.

> * * Define this configuration
> + * option to ``rtems_malloc_task_stack_for_idle`` to use this allocator.  If
> + * the memory allocation fails, then the system terminates with the
> + * INTERNAL_ERROR_CORE fatal source and the
> + * INTERNAL_ERROR_NO_MEMORY_FOR_IDLE_TASK_STACK fatal code during system
> + * initialization.
> + * @endparblock

I am confused about the how and why I would use this change?

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

Re: [PATCH] spec/pkgconfig: Allow builds to override headers

[Chris Johns]

On 1/10/2022 6:30 am, Kinsey Moore wrote:
> On 9/29/2022 16:19, Chris Johns wrote:
>> On 29/9/22 11:24 pm, Kinsey Moore wrote:
>>> On 9/28/2022 19:03, Chris Johns wrote:
>>>> On 29/9/2022 7:13 am, Kinsey Moore wrote:
>>>>> This allows any builds targeting an installed RTEMS BSP to override
>>>>> headers in the installed BSP reliably, including headers previously
>>>>> installed by that or other builds. This includes applications, network
>>>>> stacks, libraries, and any other builds.
>>>> I am a little confused by these comments. This change effects the 
>>>> generated .pc
>>>> file for a BSP so it is only used once it is installed.
>>> Correct, this is a fix for things like rtems-libbsd and rtems-lwip that 
>>> allows
>>> them to build correctly even if there are existing conflicting 
>>> installations of
>>> that library already installed in the BSP install.
>> So this is a change to aid developers of these packages who use a single 
>> prefix
>> for the tools, BSP and packages? I split the install paths up and that avoids
>> the problem.
> I guess I'm conflating a couple of different problems here. I'll take a closer
> look at how things behave when there is a separate installation path.

I just delete the effect piece. This is not the only reason to separate the
paths. Cleaning the builds away is an important test. We have been caught a few
times over the years.

>>>> An install should update
>>>> the headers at the same time the .pc is installed and made available so 
>>>> what is
>>>> old or previous? What are the "builds targeting" you refer too?
>>> "builds targeting an installed RTEMS BSP" refers to any external build that 
>>> uses
>>> installed RTEMS headers and libraries. These external builds can install 
>>> their
>>> own files in the BSP install.
>> Is this install or reinstall?
> The issues happen on reinstall since there is an existing header that has a
> higher priority in the include search paths than the local search paths.

OK

>>>> I think defining the include search of RTEMS BSP and any vertical stack
>>>> packages
>>>> headers installed under the same prefix as system headers seems like the 
>>>> right
>>>> thing to do. However this change will silence warnings from RTEMS (and
>>>> installed
>>>> packages). Is that want we want?
>>> What warnings will this silence?
>> https://gcc.gnu.org/onlinedocs/cpp/System-Headers.html
>>
>> This changes the level of warnings we currently have for a specific but
>> important group of packages that are based on rtems_waf or use .pc files. I
>> think this is important to consider.
> 
> It changes the warning level when used from the installed BSP, but we should
> still see these warnings when compiling RTEMS itself and packages compiled
> against an installed BSP using the .pc files (via rtems_waf or otherwise) will
> still display these warnings in their own headers since they will be used
> locally pre-installation.
> 
> There is still the issue of using existing headers in novel ways that could
> generate warnings which would be missed due to this change, but even then the
> documentation linked claims that macros instanced in non-system-header 
> locations
> are only immune to a small subset of warnings. I think it's worth the change
> given that installing additional packages into the installed BSP is common
> practice from what I've seen.

Yes there is a chance a warning is missed and I cannot answer if that is OK.
Maybe Joel would like to comment about this?

>>> It shouldn't affect RTEMS builds because RTEMS
>>> doesn't use the pkgconfg while building. It still places installed headers
>>> before actual system/tools headers in the include hierarchy, so any build 
>>> errors
>>> generated that way should be preserved.
>> Is Makefile.inc also updated? It effects some users of RTEMS but not all. Is
>> that important?
> I hunted for this earlier and missed it. It's apparently in make/custom and
> would need to be tweaked as well for consistency.

It should be consistent.

>> Is this something we should document as mandated for all users of BSP 
>> installed
>> headers?
> 
> It's worth putting it somewhere. Users of the .pc and Makefile.inc won't 
> notice
> or need to care for the most part, but anyone using non-standard external 
> build
> systems will need to know.

Agreed

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

Re: [PATCH] sb/set-builder: Fix staging and tar file generation with a single config build

[Chris Johns]

On 30/9/2022 5:01 pm, Christian MAUDERER wrote:
>  The rtems-deployment repo doesn't have a .gitlab-ci.yml. Did you keep that 
> separate?

Sorry missed this. The plumbing is outside of that repo.

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

Re: [PATCH] sb/set-builder: Fix staging and tar file generation with a single config build

[Chris Johns]

On 30/9/2022 5:01 pm, Christian MAUDERER wrote:
> Am 30.09.22 um 08:48 schrieb Chris Johns:
>> On 30/9/2022 4:08 pm, Christian MAUDERER wrote:
>>> Am 30.09.22 um 07:37 schrieb Chris Johns:
>>>> On 30/9/2022 3:33 pm, Christian MAUDERER wrote:
>>>>> Am 30.09.22 um 05:49 schrieb Chris Johns:
>>>>>> On 29/9/2022 9:50 pm, Chris Johns wrote:
>>>>>>> On 29/9/22 9:45 pm, Christian MAUDERER wrote:
>>>>>>>> Hello Chris,
>>>>>>>>
>>>>>>>> thanks for the quick patch. With this qemu and microblaze work again 
>>>>>>>> like
>>>>>>>> expected.
>>>>>>>>
>>>>>>>> I tested all tools starting with devel/* and from the ones that work 
>>>>>>>> only
>>>>>>>> devel/autotools-internal didn't generate a tar archive. But that one 
>>>>>>>> has a
>>>>>>>> comment "Do not use via the command line" in the bset file so that is 
>>>>>>>> most
>>>>>>>> likely fine.
>>>>>>>>
>>>>>>>> Some of other devel/* packages didn't build in my test setup, but I 
>>>>>>>> have
>>>>>>>> never
>>>>>>>> tested or used them before so that is probably a problem of my build
>>>>>>>> environment
>>>>>>>> or maybe a known bug.
>>>>>>>
>>>>>>> Thanks for the testing. I will push to the devel branch and 5.
>>>>>>>
>>>>>>
>>>>>> Tarfile creation is working however installing is not. I am working on 
>>>>>> fixing
>>>>>> this.
>>>>>>
>>>>>> Chris
>>>>>
>>>>> Sorry that I missed that. I only tried to generate the tar archives.
>>>>
>>>> Same. Testing a fix but it takes time to check properly.
>>>>
>>>> I am wondering if I can create a test mode in the deployment repo. The hard
>>>> part
>>>> is how to automatically check the build has worked.
>>>>
>>>> Chris
>>>
>>> I'm currently trying to create a basic CI/CD setup for testing our embedded
>>> brains patches using GitHub. At the moment it's still quite experimental and
>>> still a bit thrown together but it basically runs:
>>>
>>> https://github.com/embedded-brains/rtems-source-builder/actions/runs/3151126889
>>
>> Nice.
>>
>>> It didn't catch that bug because it doesn't use installed tools for the
>>> simulator runs, but maybe I can change that.
>>>
>>> If it works well enough, we maybe could re-use some scripts or work flows 
>>> to set
>>> up an official RTEMS CI/CD with whatever community preferred CI system. It
>>> shouldn't be too big of a problem to port the logic to Gitlab CI, Cirrus CI 
>>> or
>>> any other modern CI system.
>>
>> I have started https://git.rtems.org/chrisj/rtems-deployment.git/. I would 
>> like
>> it to be the landing place for this type of stuff if it fits. The repo is 
>> being
>> actively worked on by me.
> 
> I have seen that repo after you mentioned it recently, but I have to admit I
> haven't looked at it yet. From the name I have guessed that it is more for
> building release versions and not for continuous checks. I'll take a more
> detailed look.

CI is something that would come under deployment, it is the same process. In
your case the output is not used, it is for testing.

The repo can build buildsets that will fail and show them as a pass.

>> I can build RPMs on Rocky 8 and 9. These RPMs are the base for EPICS RPMs 
>> built
>> into docker containers used to build Gemini's EPICS based systems. All 
>> handled
>> via CI in gitlab.
> 
> That's quite interesting. Do you have a public GitLab instance where you build
> these or is that a private instance?

https://gitlab.com/nsf-noirlab/gemini/rtsw/epics-base/epics-base

> The rtems-deployment repo doesn't have a .gitlab-ci.yml. Did you keep that 
> separate?
$ ./waf configure --prefix=/opt/rtems --rsb=../rtems-source-builder
$ ./waf rpmspec
$ rpmbuild -bb out/test/dtc.spec

$ rpm -qi \
 out/buildroot/RPMS/x86_64/rtems-dtc-5-ddfcc320ab74_modified.el9.x86_64.rpm
Name: rtems-dtc
Version : 5
Release : ddfcc320ab74_modified.el9
Architecture: x86_64
Install Date: (not installed)
Group   : Unspecified
Size: 1191613
License : GPLv2, GPLv3, BSD-2
Signature   : (none)
Source RPM  : rtems-dtc-5-ddfcc320ab74_modified.el9.src.rpm
Build Date  : Friday 30 September 2022 05:24:31 PM
Build Host  : rocky.contemporary.net.au
Summary : RTEMS tools and board support package
Description :
This RPM is development tools and BSP for RTEMS

If you switch the RSB branch from 6 to 5 the same process works. That is really
important because users do not need to update their plumbing.

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

Re: [PATCH] sb/set-builder: Fix staging and tar file generation with a single config build

[Chris Johns]

On 30/9/2022 4:08 pm, Christian MAUDERER wrote:
> Am 30.09.22 um 07:37 schrieb Chris Johns:
>> On 30/9/2022 3:33 pm, Christian MAUDERER wrote:
>>> Am 30.09.22 um 05:49 schrieb Chris Johns:
>>>> On 29/9/2022 9:50 pm, Chris Johns wrote:
>>>>> On 29/9/22 9:45 pm, Christian MAUDERER wrote:
>>>>>> Hello Chris,
>>>>>>
>>>>>> thanks for the quick patch. With this qemu and microblaze work again like
>>>>>> expected.
>>>>>>
>>>>>> I tested all tools starting with devel/* and from the ones that work only
>>>>>> devel/autotools-internal didn't generate a tar archive. But that one has 
>>>>>> a
>>>>>> comment "Do not use via the command line" in the bset file so that is 
>>>>>> most
>>>>>> likely fine.
>>>>>>
>>>>>> Some of other devel/* packages didn't build in my test setup, but I have
>>>>>> never
>>>>>> tested or used them before so that is probably a problem of my build
>>>>>> environment
>>>>>> or maybe a known bug.
>>>>>
>>>>> Thanks for the testing. I will push to the devel branch and 5.
>>>>>
>>>>
>>>> Tarfile creation is working however installing is not. I am working on 
>>>> fixing
>>>> this.
>>>>
>>>> Chris
>>>
>>> Sorry that I missed that. I only tried to generate the tar archives.
>>
>> Same. Testing a fix but it takes time to check properly.
>>
>> I am wondering if I can create a test mode in the deployment repo. The hard 
>> part
>> is how to automatically check the build has worked.
>>
>> Chris
> 
> I'm currently trying to create a basic CI/CD setup for testing our embedded
> brains patches using GitHub. At the moment it's still quite experimental and
> still a bit thrown together but it basically runs:
> 
> https://github.com/embedded-brains/rtems-source-builder/actions/runs/3151126889

Nice.

> It didn't catch that bug because it doesn't use installed tools for the
> simulator runs, but maybe I can change that.
> 
> If it works well enough, we maybe could re-use some scripts or work flows to 
> set
> up an official RTEMS CI/CD with whatever community preferred CI system. It
> shouldn't be too big of a problem to port the logic to Gitlab CI, Cirrus CI or
> any other modern CI system.

I have started https://git.rtems.org/chrisj/rtems-deployment.git/. I would like
it to be the landing place for this type of stuff if it fits. The repo is being
actively worked on by me.

I can build RPMs on Rocky 8 and 9. These RPMs are the base for EPICS RPMs built
into docker containers used to build Gemini's EPICS based systems. All handled
via CI in gitlab.

To build an RPM you configure with the path to the RSB and then run `./waf
rpmspec`. A spec file is created you can use with `rpmbuild` to make an RPM. I
am keeping the generation and building of the RPM separate. By default the repo
builds a tarfile.

Once this repo stabilises I would like to see if it can move to the top level. I
am working on better documentation for it and with that some constraints about
what is offered.

Deployment is something varies and I hope this repo can grow to make common
solutions widely available. I am fine for organisation to send in specific
configurations if they are open to having them in the repo.

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

Re: [PATCH] sb/set-builder: Fix staging and tar file generation with a single config build

[Chris Johns]

On 30/9/2022 3:33 pm, Christian MAUDERER wrote:
> Am 30.09.22 um 05:49 schrieb Chris Johns:
>> On 29/9/2022 9:50 pm, Chris Johns wrote:
>>> On 29/9/22 9:45 pm, Christian MAUDERER wrote:
>>>> Hello Chris,
>>>>
>>>> thanks for the quick patch. With this qemu and microblaze work again like
>>>> expected.
>>>>
>>>> I tested all tools starting with devel/* and from the ones that work only
>>>> devel/autotools-internal didn't generate a tar archive. But that one has a
>>>> comment "Do not use via the command line" in the bset file so that is most
>>>> likely fine.
>>>>
>>>> Some of other devel/* packages didn't build in my test setup, but I have 
>>>> never
>>>> tested or used them before so that is probably a problem of my build
>>>> environment
>>>> or maybe a known bug.
>>>
>>> Thanks for the testing. I will push to the devel branch and 5.
>>>
>>
>> Tarfile creation is working however installing is not. I am working on fixing
>> this.
>>
>> Chris
> 
> Sorry that I missed that. I only tried to generate the tar archives.

Same. Testing a fix but it takes time to check properly.

I am wondering if I can create a test mode in the deployment repo. The hard part
is how to automatically check the build has worked.

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

Re: [PATCH] sb/set-builder: Fix staging and tar file generation with a single config build

[Chris Johns]

On 29/9/2022 9:50 pm, Chris Johns wrote:
> On 29/9/22 9:45 pm, Christian MAUDERER wrote:
>> Hello Chris,
>>
>> thanks for the quick patch. With this qemu and microblaze work again like 
>> expected.
>>
>> I tested all tools starting with devel/* and from the ones that work only
>> devel/autotools-internal didn't generate a tar archive. But that one has a
>> comment "Do not use via the command line" in the bset file so that is most
>> likely fine.
>>
>> Some of other devel/* packages didn't build in my test setup, but I have 
>> never
>> tested or used them before so that is probably a problem of my build 
>> environment
>> or maybe a known bug.
> 
> Thanks for the testing. I will push to the devel branch and 5.
> 

Tarfile creation is working however installing is not. I am working on fixing 
this.

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

Re: Git master/main/trunk/current/best...

[Chris Johns]

On 30/9/22 4:00 am, Joel Sherrill wrote:
> I'd like to propose that short term we change lwip main to master for
> consistency with existing repos. This helps avoid stupid mistakes because lwip
> is the odd case.

I propose we use devel. I prefer it over main.

When should we change away from master?

> Longer term, we may want to change the name master in all repos. But we need 
> to
> agree on a new name, socialize it, update documentation, and announce it. It's
> more than a simple set of git commands impacting only a few people.
> 
> Can we come to some agreement on what to do? 

New git versions warns you about the use of master when creating a new repo and
at a guess this is why the repo has main. I am using devel in rtems-deployment
so there will be a mix.

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

Re: [PATCH] spec/pkgconfig: Allow builds to override headers

[Chris Johns]

On 29/9/22 11:24 pm, Kinsey Moore wrote:
> On 9/28/2022 19:03, Chris Johns wrote:
>> On 29/9/2022 7:13 am, Kinsey Moore wrote:
>>> This allows any builds targeting an installed RTEMS BSP to override
>>> headers in the installed BSP reliably, including headers previously
>>> installed by that or other builds. This includes applications, network
>>> stacks, libraries, and any other builds.
>> I am a little confused by these comments. This change effects the generated 
>> .pc
>> file for a BSP so it is only used once it is installed.
> Correct, this is a fix for things like rtems-libbsd and rtems-lwip that allows
> them to build correctly even if there are existing conflicting installations 
> of
> that library already installed in the BSP install.

So this is a change to aid developers of these packages who use a single prefix
for the tools, BSP and packages? I split the install paths up and that avoids
the problem.

>> An install should update
>> the headers at the same time the .pc is installed and made available so what 
>> is
>> old or previous? What are the "builds targeting" you refer too?
> "builds targeting an installed RTEMS BSP" refers to any external build that 
> uses
> installed RTEMS headers and libraries. These external builds can install their
> own files in the BSP install.

Is this install or reinstall?

>> I think defining the include search of RTEMS BSP and any vertical stack 
>> packages
>> headers installed under the same prefix as system headers seems like the 
>> right
>> thing to do. However this change will silence warnings from RTEMS (and 
>> installed
>> packages). Is that want we want?
> 
> What warnings will this silence? 

https://gcc.gnu.org/onlinedocs/cpp/System-Headers.html

This changes the level of warnings we currently have for a specific but
important group of packages that are based on rtems_waf or use .pc files. I
think this is important to consider.

> It shouldn't affect RTEMS builds because RTEMS
> doesn't use the pkgconfg while building. It still places installed headers
> before actual system/tools headers in the include hierarchy, so any build 
> errors
> generated that way should be preserved.

Is Makefile.inc also updated? It effects some users of RTEMS but not all. Is
that important?

Is this something we should document as mandated for all users of BSP installed
headers?

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

Re: [PATCH] sb/set-builder: Fix staging and tar file generation with a single config build

[Chris Johns]

On 29/9/22 9:45 pm, Christian MAUDERER wrote:
> Hello Chris,
> 
> thanks for the quick patch. With this qemu and microblaze work again like 
> expected.
> 
> I tested all tools starting with devel/* and from the ones that work only
> devel/autotools-internal didn't generate a tar archive. But that one has a
> comment "Do not use via the command line" in the bset file so that is most
> likely fine.
> 
> Some of other devel/* packages didn't build in my test setup, but I have never
> tested or used them before so that is probably a problem of my build 
> environment
> or maybe a known bug.

Thanks for the testing. I will push to the devel branch and 5.

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

Re: [rtems-source-builder commit] sb/setbuilder: Correctly create build set tar files

[Chris Johns]

On 29/9/22 6:01 pm, Christian MAUDERER wrote:
> Am 29.09.22 um 09:52 schrieb Chris Johns:
>>
>>
>> On 29/9/22 5:13 pm, Christian MAUDERER wrote:
>>> Am 29.09.22 um 08:56 schrieb Chris Johns:
>>>> On 29/9/2022 4:55 pm, Christian MAUDERER wrote:
>>>>> Am 29.09.22 um 08:54 schrieb Chris Johns:
>>>>>> On 29/9/2022 4:42 pm, Christian MAUDERER wrote:
>>>>>>>> It could be a bug if the tools builds work, ie 6/rtems-*. Please raise 
>>>>>>>> a
>>>>>>>> ticket?
>>>>>>>
>>>>>>> The tool builds work except for the 6/rtems-microblaze.
>>>>>>
>>>>>> Thanks, I will take a look.
>>>>>>
>>>>>
>>>>> I just checked it: There is the same behavior for devel/dtc (which is much
>>>>> faster to build). Without the patch an archive is created. With the patch 
>>>>> it
>>>>> doesn't create one.
>>>>
>>>> Awesome, that will help.
>>>>
>>>
>>> In case of dtc, it seems to not work because dtc is in
>>>
>>>    devel/dtc-1.6.1-1.cfg
>>>
>>> which ends in a ".cfg" and not in a ".bset".
>>>
>>> The bset_tar(...) function is only called if the have_staging is set here:
>>>
>>> https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/setbuilder.py?id=161b7f108c3daa0f71ac289ba048a68b730d422c#n623
>>>
>>>
>>>
>>> That variable seems to be only set to True here:
>>>
>>> https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/setbuilder.py?id=161b7f108c3daa0f71ac289ba048a68b730d422c#n489
>>>
>>>
>>>
>>> And that statement is in a
>>>
>>>    if configs[s].endswith('.bset')
>>>
>>> Does that mean that only bsets can be packed?
>>
>> It means the build is not being staged and so no bset tar generation. At a 
>> guess
>> a single package in a build does not need to be staged so that step is 
>> missed.
>>
>> Just a bug. If you could please raise a ticket and assign to me I will take 
>> care
>> of this.
>>
> 
> https://devel.rtems.org/ticket/4730#ticket

Thanks.

> Is there anything I can help with solving that?

I have a fix so some testing a bit would be a big help.

The staging logic was a progression of changes at the time and took some effort.
Once it was sorted some extra and unneeded complexity was left and that can be
remove. All bsets and cfgs should be staged so removing the logic that made only
nested builds stage fixes it for dtc. I just need to test the more complex 
builds.

The microblaze is a separate gcc version so I am not sure about it. I will to
look into it next.

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

Re: [rtems-source-builder commit] sb/setbuilder: Correctly create build set tar files

[Chris Johns]

On 29/9/22 5:13 pm, Christian MAUDERER wrote:
> Am 29.09.22 um 08:56 schrieb Chris Johns:
>> On 29/9/2022 4:55 pm, Christian MAUDERER wrote:
>>> Am 29.09.22 um 08:54 schrieb Chris Johns:
>>>> On 29/9/2022 4:42 pm, Christian MAUDERER wrote:
>>>>>> It could be a bug if the tools builds work, ie 6/rtems-*. Please raise a
>>>>>> ticket?
>>>>>
>>>>> The tool builds work except for the 6/rtems-microblaze.
>>>>
>>>> Thanks, I will take a look.
>>>>
>>>
>>> I just checked it: There is the same behavior for devel/dtc (which is much
>>> faster to build). Without the patch an archive is created. With the patch it
>>> doesn't create one.
>>
>> Awesome, that will help.
>>
> 
> In case of dtc, it seems to not work because dtc is in
> 
>   devel/dtc-1.6.1-1.cfg
> 
> which ends in a ".cfg" and not in a ".bset".
> 
> The bset_tar(...) function is only called if the have_staging is set here:
> 
> https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/setbuilder.py?id=161b7f108c3daa0f71ac289ba048a68b730d422c#n623
> 
> 
> That variable seems to be only set to True here:
> 
> https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/setbuilder.py?id=161b7f108c3daa0f71ac289ba048a68b730d422c#n489
> 
> 
> And that statement is in a
> 
>   if configs[s].endswith('.bset')
> 
> Does that mean that only bsets can be packed? 

It means the build is not being staged and so no bset tar generation. At a guess
a single package in a build does not need to be staged so that step is missed.

Just a bug. If you could please raise a ticket and assign to me I will take care
of this.

Nice work getting it down to here. I appreciate it.

> I think having a tarball for tools like qemu or dtc could be quite useful too.

Agreed.

> PS: Not sure yet why microblaze is affected too. That maybe is another case.

Thanks. Getting to it with rtems-deployment repo but I hit 5 verses devel branch
issues.

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

Re: [rtems-source-builder commit] sb/setbuilder: Correctly create build set tar files

[Chris Johns]

On 29/9/2022 4:55 pm, Christian MAUDERER wrote:
> Am 29.09.22 um 08:54 schrieb Chris Johns:
>> On 29/9/2022 4:42 pm, Christian MAUDERER wrote:
>>>> It could be a bug if the tools builds work, ie 6/rtems-*. Please raise a
>>>> ticket?
>>>
>>> The tool builds work except for the 6/rtems-microblaze.
>>
>> Thanks, I will take a look.
>>
> 
> I just checked it: There is the same behavior for devel/dtc (which is much
> faster to build). Without the patch an archive is created. With the patch it
> doesn't create one.

Awesome, that will help.

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

Re: [rtems-source-builder commit] sb/setbuilder: Correctly create build set tar files

[Chris Johns]

On 29/9/2022 4:42 pm, Christian MAUDERER wrote:
>> It could be a bug if the tools builds work, ie 6/rtems-*. Please raise a 
>> ticket?
> 
> The tool builds work except for the 6/rtems-microblaze.

Thanks, I will take a look.

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

Re: [PATCH] cpukit/fdt: Free index before container

[Chris Johns]

OK to push.

Should 5 be updated? Consider OK for 5 as well.

Thanks
Chris

On 29/9/2022 7:12 am, Kinsey Moore wrote:
> Ensure that the index is released before the structure containing it is
> freed and NULLed.
> 
> Updates #4460
> ---
>  cpukit/libmisc/rtems-fdt/rtems-fdt.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/cpukit/libmisc/rtems-fdt/rtems-fdt.c 
> b/cpukit/libmisc/rtems-fdt/rtems-fdt.c
> index 1d3b82ae29..bea01dbf78 100644
> --- a/cpukit/libmisc/rtems-fdt/rtems-fdt.c
> +++ b/cpukit/libmisc/rtems-fdt/rtems-fdt.c
> @@ -700,14 +700,14 @@ rtems_fdt_unload (rtems_fdt_handle* handle)
>  
>rtems_chain_extract_unprotected (>blob->node);
>  
> +  rtems_fdt_release_index(>blob->index);
> +
>free (handle->blob);
>  
>handle->blob = NULL;
>  
>rtems_fdt_unlock (fdt);
>  
> -  rtems_fdt_release_index(>blob->index);
> -
>return 0;
>  }
>  
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] spec/pkgconfig: Allow builds to override headers

[Chris Johns]

On 29/9/2022 7:13 am, Kinsey Moore wrote:
> This allows any builds targeting an installed RTEMS BSP to override
> headers in the installed BSP reliably, including headers previously
> installed by that or other builds. This includes applications, network
> stacks, libraries, and any other builds.

I am a little confused by these comments. This change effects the generated .pc
file for a BSP so it is only used once it is installed. An install should update
the headers at the same time the .pc is installed and made available so what is
old or previous? What are the "builds targeting" you refer too?

I think defining the include search of RTEMS BSP and any vertical stack packages
headers installed under the same prefix as system headers seems like the right
thing to do. However this change will silence warnings from RTEMS (and installed
packages). Is that want we want?

Chris

> ---
>  spec/build/bsps/pkgconfig.yml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/spec/build/bsps/pkgconfig.yml b/spec/build/bsps/pkgconfig.yml
> index a9462fcc95..8a3c3677a4 100644
> --- a/spec/build/bsps/pkgconfig.yml
> +++ b/spec/build/bsps/pkgconfig.yml
> @@ -22,7 +22,7 @@ content: |
>Name: ${ARCH}-rtems${__RTEMS_MAJOR__}-${BSP_NAME}
>Version: ${RTEMS_VERSION}
>Description: RTEMS BSP ${ARCH}/${BSP_NAME}
> -  Cflags: $${ABI_FLAGS} -I$${includedir}
> +  Cflags: $${ABI_FLAGS} -isystem$${includedir}
>Ldflags: -B$${libdir} ${PKGCONFIG_LDFLAGS}
>Libs: -B$${libdir} ${PKGCONFIG_LDFLAGS}
>  copyrights:
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] cpukit/fdt: Check correct allocation

[Chris Johns]

OK and thanks.

Should this be fixed on 5 as well? If you think so consider it OK as well.

Thanks
Chris

On 29/9/2022 7:12 am, Kinsey Moore wrote:
> The second allocation check was mistakenly rechecking the first
> allocation. It now checks the correct allocation and ensures that names
> is not NULL.
> 
> Updates #4462
> ---
>  cpukit/libmisc/rtems-fdt/rtems-fdt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/cpukit/libmisc/rtems-fdt/rtems-fdt.c 
> b/cpukit/libmisc/rtems-fdt/rtems-fdt.c
> index 7dd2bc1047..1d3b82ae29 100644
> --- a/cpukit/libmisc/rtems-fdt/rtems-fdt.c
> +++ b/cpukit/libmisc/rtems-fdt/rtems-fdt.c
> @@ -182,7 +182,7 @@ rtems_fdt_init_index (rtems_fdt_handle* fdt, 
> rtems_fdt_blob* blob)
>}
>  
>names = calloc(1, total_name_memory);
> -  if (!entries)
> +  if (!names)
>{
>  free(entries);
>  return -RTEMS_FDT_ERR_NO_MEMORY;
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems-source-builder commit] sb/setbuilder: Correctly create build set tar files

[Chris Johns]

On 28/9/2022 11:42 pm, Christian MAUDERER wrote:
> Hello,
> 
> with this patch, I don't get a tar for devel/qemu and for the 
> 6/rtems-microblaze
> anymore. All other 6/rtems-* toolchains work without problems. I haven't 
> tested
> a lot of the other packages.
> 
> The bset for microblaze is a bit different from the other ones. But I'm not 
> yet
> sure what the relevant difference is.
> 
> @Chris: With your change: What is necessary that a bset can generate a tar 
> archive?

It could be a bug if the tools builds work, ie 6/rtems-*. Please raise a ticket?

I changed the --bset-tar-file option to create a single tarfile of the final
staged output of a build. There were a few commits to get this right so I assume
you are testing on the latest?

Incremental tarfiles based on separate buildsets in a buildset may have worked
in some cases however there were some basic issues in how it was implemented.
When you add deployment requirements on top it did not match up well and it was
confusing. The best solution was to rebase the tarfile against the final staged
output as that is known to be correct in all cases.

I have created a https://git.rtems.org/chrisj/rtems-deployment.git repo and in
it a config test directory
(https://git.rtems.org/chrisj/rtems-deployment.git/tree/config/test). I will
look at adding a test to make sure we catch any issues.

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

Re: [PATCH RSB v2] rtems-gcc-12-newlib-head.cfg: Bump newlib hash to get extern C on resource.h

[Chris Johns]

Looks good. Please push.

Thanks
Chris

On 27/9/2022 10:52 am, Joel Sherrill wrote:
> ---
>  rtems/config/tools/rtems-gcc-12-newlib-head.cfg | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/rtems/config/tools/rtems-gcc-12-newlib-head.cfg 
> b/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
> index fe4f827..c8eb0a6 100644
> --- a/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
> +++ b/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
> @@ -40,12 +40,13 @@
>  
> KEmxHjYOqY4LTXCMZ3I60tbHusbR5GlnP0CLARHPAnhCnovDj9K3U43C1bsMxDDGRqD6fwtrEFoEgqVFX63IuQ==
>  # Comment above related to #4657 and patches ends here
>  
> -%define newlib_version d9dc880
> +%define newlib_version 01f6251c0
>  %define newlib_external 1
>  %define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
>  %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz \
> 
> https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
> -%hash sha512 newlib-%{newlib_version}.tar.gz 
> 3062c1f62dece119b6f0c74489ce57b29cb2dcf291b884f38361504e83a049fda17bf89b781605643f29bd0af2d61fd180852944576033efc55bc0e21505b84c
> +%hash sha512 newlib-%{newlib_version}.tar.gz \
> + 
> 5HRkzpOsZ43Q0IOQGof4slTN5k741fRXsFkkfa5Heu+RI28hDeYD7YErt2A/PlMtgSQ6TKefDfH3MEuSlRszRQ==
>  
>  %define with_threads 1
>  %define with_plugin 0
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH RSB v1] rtems-gcc-12-newlib-head.cfg: Bump newlib hash to get extern C on resource.h

[Chris Johns]

On 27/9/2022 10:30 am, Joel Sherrill wrote:
> ---
>  rtems/config/tools/rtems-gcc-12-newlib-head.cfg | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/rtems/config/tools/rtems-gcc-12-newlib-head.cfg 
> b/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
> index fe4f827..76dc221 100644
> --- a/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
> +++ b/rtems/config/tools/rtems-gcc-12-newlib-head.cfg
> @@ -40,12 +40,13 @@
>  
> KEmxHjYOqY4LTXCMZ3I60tbHusbR5GlnP0CLARHPAnhCnovDj9K3U43C1bsMxDDGRqD6fwtrEFoEgqVFX63IuQ==
>  # Comment above related to #4657 and patches ends here
>  
> -%define newlib_version d9dc880
> +%define newlib_version 01f6251c0969f92bf802e1c9f2acd199353a3956

Can we keep with short hashes for the version? I am concerned how this flows
into the naming of files and the length of paths.

Thanks
Chris

>  %define newlib_external 1
>  %define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
>  %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz \
> 
> https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
> -%hash sha512 newlib-%{newlib_version}.tar.gz 
> 3062c1f62dece119b6f0c74489ce57b29cb2dcf291b884f38361504e83a049fda17bf89b781605643f29bd0af2d61fd180852944576033efc55bc0e21505b84c
> +%hash sha512 newlib-%{newlib_version}.tar.gz \
> + 
> pFL0kYx8sOi3lS+7AioLDGrmBPgvHlPF6XVgTahhqMed3qYn5FJI2hE69FhHch99MBDF8a6KmA6kTlX/SFQhPw==
>  
>  %define with_threads 1
>  %define with_plugin 0
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-docs] raspberrypi4.rst: Added Documentation for the new AArch64 Raspberry pi 4B BSP

[Chris Johns]

On 26/9/2022 5:10 pm, Chris Johns wrote:
> Hi,
> 
> Thanks for this. Looks good. I few minor issues.
> 
> Should memory sizes be discussed given there are a few models with different
> sized memory?
> 
> Can the subject please be:
> 
>  user/raspberrypi4.rst: Added the AArch64 Raspberry pi 4B BSP

Sorry this should be ...

  user/raspberrypi4: Added the AArch64 Raspberry pi 4B BSP

Chris

> 
> Minor nit has the end of the email ...
> 
> On 26/9/2022 4:52 pm, Mohd Noor Aman wrote:
>> This patch adds the relevant documentations required for booting the new 
>> BSP. JTAG support is added for debugging. I have built the HTML docs and 
>> verified them.
> 
> Please update the commit message to be max 80 characters in width.
> 
>> ---
>>  user/bsps/aarch64/raspberrypi4.rst | 92 ++
>>  user/bsps/bsps-aarch64.rst |  1 +
>>  2 files changed, 93 insertions(+)
>>  create mode 100644 user/bsps/aarch64/raspberrypi4.rst
>>
>> diff --git a/user/bsps/aarch64/raspberrypi4.rst 
>> b/user/bsps/aarch64/raspberrypi4.rst
>> new file mode 100644
>> index 000..94daacf
>> --- /dev/null
>> +++ b/user/bsps/aarch64/raspberrypi4.rst
>> @@ -0,0 +1,92 @@
>> +.. SPDX-License-Identifier: CC-BY-SA-4.0
>> +
>> +.. Copyright (C) 2022 Mohd Noor Aman
>> +
>> +.. _BSP_aarch64_Raspberrypi_4:
>> +
>> +Raspberry Pi 4B
>> +===
>> +
>> +The 'raspberrypi4b' BSP currently supports only the LP64 ABI. Raspberry pi 
>> 4B
>> +and Raspberry Pi 400  are supported. The default bootloader which is used 
>> by the
>> +Raspbian OS or other OS can be used to boot the RTEMS. Currently, QEMU is 
>> not
>> +supported. This BSP supports the GICv2 interrupt controller.
>> +
>> +Clock Driver
>> +
>> +
>> +The clock driver uses the `ARM Generic Timer`.
>> +
>> +Console Driver
>> +--
>> +
>> +The console driver supports the default Qemu emulated ARM PL011 PrimeCell 
>> UART
>> +as well as the physical ARM PL011 PrimeCell UART in the raspberrypi 
>> hardware.
>> +Only UART0 is supported as of now.
>> +
>> +Preparing to boot
>> +--
>> +
>> +Raspberry Pi uses a different mechanism to boot. First the GPU initializes,
>> +loads the bootloader and then looks for the kernel img. By default the arm64
>> +mode looks for the ``kernel8.img``. Any other kernel can be loaded by adding
>> +`kernel=` to the ``config.txt``.
>> +
>> +The Firmware files are required in order to boot RTEMS. The latest firmware 
>> can
>> +be downloaded from the `Raspberry Pi Firmware Repository
>> +<https://github.com/raspberrypi/firmware/>`_. USB boot is supported. All the
>> +files (Firmwares and kernel) must be place in the FAT32 partition only. Add
>> +``arm_64bit=1`` in the config.txt file in order to boot the BSP in 64bit 
>> kernel
>> +mode. 
>> +
>> +
>> +UART Setup
>> +^^
>> +
>> +Connect your serial device to the GPIO15 and GPIO14. Add the following to 
>> the
>> +config.txt file in order to use the PL011 UART0.
>> +
>> +.. code-block:: none
>> +
>> +  dtoverlay = disable-bt
>> +  enable_uart=1
>> +
>> +Generating kernel image 
>> +^^^
>> +
>> +The following steps show how to run ``hello.exe`` on the BSP. Other 
>> executables
>> +can be processed in a similar way.
>> +
>> +To create the kernel image:
>> +
>> +.. code-block:: shell
>> +
>> +  $ aarch64-rtems@rtems-ver-major@-objcopy -Obinary hello.exe kernel8.img
>> +
>> +Copy the kernel image to the SD card.
>> +
>> +JTAG Setup
>> +--
>> +
>> +The Raspberry Pi 4 doesn't have dedicated JTAG pins. Instead, you must 
>> configure
>> +the GPIO pins (GPIO22-GPIO27) to activate the JTAG functionality. The RPi 4
>> +documentation refers to this as Alt4 functions of those pins. Alt5 does 
>> exist
>> +too, which goes from GPIO4, 5, 6, 12 and 13. you can check this out from
>> +`pinout.xyz <https://pinout.xyz/pinout/jtag#>`_ or `eLinux
>> +<https://elinux.org/RPi_BCM2835_GPIOs>`_
>> +
>> +One more thing to note on JTAG with Raspberry pi 4B is that, by default, 
>> All the
>> +GPIO pins are pulled down, according to the `BCM2711 documentation
>> +<https://datasheets.raspberrypi.com/bcm2711/bcm2711-peripherals.pdf>`_. This
>> +wasn't the case in the earlier models. So in order to let the data flow 
>> 

Re: [PATCH rtems-docs] raspberrypi4.rst: Added Documentation for the new AArch64 Raspberry pi 4B BSP

[Chris Johns]

Hi,

Thanks for this. Looks good. I few minor issues.

Should memory sizes be discussed given there are a few models with different
sized memory?

Can the subject please be:

 user/raspberrypi4.rst: Added the AArch64 Raspberry pi 4B BSP

Minor nit has the end of the email ...

On 26/9/2022 4:52 pm, Mohd Noor Aman wrote:
> This patch adds the relevant documentations required for booting the new BSP. 
> JTAG support is added for debugging. I have built the HTML docs and verified 
> them.

Please update the commit message to be max 80 characters in width.

> ---
>  user/bsps/aarch64/raspberrypi4.rst | 92 ++
>  user/bsps/bsps-aarch64.rst |  1 +
>  2 files changed, 93 insertions(+)
>  create mode 100644 user/bsps/aarch64/raspberrypi4.rst
> 
> diff --git a/user/bsps/aarch64/raspberrypi4.rst 
> b/user/bsps/aarch64/raspberrypi4.rst
> new file mode 100644
> index 000..94daacf
> --- /dev/null
> +++ b/user/bsps/aarch64/raspberrypi4.rst
> @@ -0,0 +1,92 @@
> +.. SPDX-License-Identifier: CC-BY-SA-4.0
> +
> +.. Copyright (C) 2022 Mohd Noor Aman
> +
> +.. _BSP_aarch64_Raspberrypi_4:
> +
> +Raspberry Pi 4B
> +===
> +
> +The 'raspberrypi4b' BSP currently supports only the LP64 ABI. Raspberry pi 4B
> +and Raspberry Pi 400  are supported. The default bootloader which is used by 
> the
> +Raspbian OS or other OS can be used to boot the RTEMS. Currently, QEMU is not
> +supported. This BSP supports the GICv2 interrupt controller.
> +
> +Clock Driver
> +
> +
> +The clock driver uses the `ARM Generic Timer`.
> +
> +Console Driver
> +--
> +
> +The console driver supports the default Qemu emulated ARM PL011 PrimeCell 
> UART
> +as well as the physical ARM PL011 PrimeCell UART in the raspberrypi hardware.
> +Only UART0 is supported as of now.
> +
> +Preparing to boot
> +--
> +
> +Raspberry Pi uses a different mechanism to boot. First the GPU initializes,
> +loads the bootloader and then looks for the kernel img. By default the arm64
> +mode looks for the ``kernel8.img``. Any other kernel can be loaded by adding
> +`kernel=` to the ``config.txt``.
> +
> +The Firmware files are required in order to boot RTEMS. The latest firmware 
> can
> +be downloaded from the `Raspberry Pi Firmware Repository
> +`_. USB boot is supported. All the
> +files (Firmwares and kernel) must be place in the FAT32 partition only. Add
> +``arm_64bit=1`` in the config.txt file in order to boot the BSP in 64bit 
> kernel
> +mode. 
> +
> +
> +UART Setup
> +^^
> +
> +Connect your serial device to the GPIO15 and GPIO14. Add the following to the
> +config.txt file in order to use the PL011 UART0.
> +
> +.. code-block:: none
> +
> +  dtoverlay = disable-bt
> +  enable_uart=1
> +
> +Generating kernel image 
> +^^^
> +
> +The following steps show how to run ``hello.exe`` on the BSP. Other 
> executables
> +can be processed in a similar way.
> +
> +To create the kernel image:
> +
> +.. code-block:: shell
> +
> +  $ aarch64-rtems@rtems-ver-major@-objcopy -Obinary hello.exe kernel8.img
> +
> +Copy the kernel image to the SD card.
> +
> +JTAG Setup
> +--
> +
> +The Raspberry Pi 4 doesn't have dedicated JTAG pins. Instead, you must 
> configure
> +the GPIO pins (GPIO22-GPIO27) to activate the JTAG functionality. The RPi 4
> +documentation refers to this as Alt4 functions of those pins. Alt5 does exist
> +too, which goes from GPIO4, 5, 6, 12 and 13. you can check this out from
> +`pinout.xyz `_ or `eLinux
> +`_
> +
> +One more thing to note on JTAG with Raspberry pi 4B is that, by default, All 
> the
> +GPIO pins are pulled down, according to the `BCM2711 documentation
> +`_. This
> +wasn't the case in the earlier models. So in order to let the data flow 
> freely,
> +we will have to disable them.
> +
> +.. code-block:: none
> +
> +  # Disable pull downs
> +  gpio=22-27=np
> +
> +  # Enable jtag pins (i.e. GPIO22-GPIO27)
> +  enable_jtag_gpio=1
> +
> +
> diff --git a/user/bsps/bsps-aarch64.rst b/user/bsps/bsps-aarch64.rst
> index 933370f..f3aa15c 100644
> --- a/user/bsps/bsps-aarch64.rst
> +++ b/user/bsps/bsps-aarch64.rst
> @@ -9,3 +9,4 @@ aarch64 (AArch64)
>  .. include:: aarch64/a72.rst>  .. include:: aarch64/xilinx-versal.rst
>  .. include:: aarch64/xilinx-zynqmp.rst
> +.. include:: aarch64/raspberrypi4.rst

Can the order please be sorted?

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