Re: [PATCH] wscript: Deduplicate installed files

[Chris Johns]

On 4/2/2023 6:11 am, Sebastian Huber wrote:
> On 03.02.23 19:45, Kinsey Moore wrote:
>> This is my first stab at solving this duplicate install problem. I could
>> manually solve the problem by deduplicating the object includes and moving it
>> up to the BSP, but that is less intuitive since these drivers both depend on
>> the same code and the BSP doesn't depend on it directly.
> 
> Why don't you add the shared stuff to a objxilcommon.yml?
> 
> The approach in the wscript is a bit complex from my point of view.

I am OK with adding this code or something similar. It is no more complex than
other places I have reviewed, eg `Item._init_link()`.

The issue is currently not easy to see and may be present in other places
without us knowing. I am also fine with a spec file check that highlights a
clash to draw attention to a problem when the spec files are parsed. I feeling
we need something.

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

Re: [RBW] Re: Bombadil and Hunqapillar origins: The definitive thread

[JohnS]

Wow! I'm super impressed. And I bet they are all in the same great 
condition as your Bombadil. Thanks for sharing.

JohnS


On Sunday, February 5, 2023 at 8:04:43 AM UTC-5 lconley wrote:

> 8 - behind the Bombadil - Betty Foy, Hubbuhubbuh, Frank Jones Sr, Mystery 
> Bike, Gus Boots Willsen, hanging on the wall Rosco Bubbe V1, Rivendell 
> Custom. There are others not in the picture (Clementine, Rosco Bubbe Medium 
> Mountain Mixte, Roscoe Baby, Keven's Custom Mixte). The Hubbuhubbuh has 
> been sold since the picture was taken.
>
> Also in the picture - 2 1973 Schwinn Paramount P-15s, 2 Flying Pigeons, 2 
> Gitane Tour de Frances, Pashley Guv'nor, Crust Scapegoat,  Kent Cavalier 
> (recumbent 3 wheeler).
>
> Laing
>
>
> On Saturday, February 4, 2023 at 1:19:46 PM UTC-5 JohnS wrote:
> Wait a minute there Laing! How many Riv's are in that picture???
>
> Drill press, one of my favorite tools :)
>
> JohnS
>
>

-- 
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/eb53ccc0-0b49-4964-a8c2-6ce82efc6286n%40googlegroups.com.

Re: [RBW] Re: Bombadil and Hunqapillar origins: The definitive thread

[JohnS]

Wait a minute there Laing! How many Riv's are in that picture???

Drill press, one of my favorite tools :)

JohnS


On Saturday, February 4, 2023 at 6:21:15 AM UTC-5 Garth wrote:

> On Friday, February 3, 2023 at 4:28:29 PM UTC-5 Mackenzy Albright wrote:
> One thing i've been curious about is the geometry changes over time. 
>
> It seems the Hunqapillars were generally a bit shorter TT's and relatively 
> traditional geometry while the Bombadils ran long (I'm assuming meant more 
> for non drops?). Eventually all Rivendells started getting lnger and 
> more swept back bar designed. The Hunqapillars took over the Bombadils in 
> terms of production. Which is funny because I was always under the 
> impression hunqs were cheaper bombas, but the top tubes have always from 
> what i've seen been longer on the bombas. 
>
> It seems to me the 58 hunqs and bombas were around 61-62 and the 60 (?) 
> were 62-64? is this correct? It seems the charts vary as well as peoples 
> physical measurements (especially with the sloping tubes) 
>
> Has anyone ridden or tried out different length variations or a 
> hunqapillar and a bombadil in terms of drop bar oriented or swept back 
> oriented designs? 
>
>
> Mackenzey, You have it correct in that the Bombas were a bit longer in 
> reach and front-center overall. There's no direct comparing them as the 
> frame sizes were never the same, save the 48cm. If the H frames were an 
> equal to or greater than the B in terms of stack, reach and f-c I would 
> have purchased one, but they were not.  Even the 62 H didn't have the 
> reach/f-c of 60 B.The 60 B from the original batch is dimensionally "just 
> right" for me. 
>
> The frames in mass didn't go looong-er in the font end until the 2019 Clem 
> update. Well, not all of them did, not the road bikes. But all the others 
> went much longer than previous. As if everyone wants or needs to ride with 
> a vertical posture ? (Rhetorically) Hah hah  certainly 
> not...(Me,We,Thee) !  To me the whole lengthening of the bikes is from the 
> belief in the vertical posture(ride like a horseman) thing and long 
> chainstays. Having the rear end long, without the front long, and sitting 
> vertically, well I could sense that as being a bit unbalanced feeling. 
> (opinion here) Well gee, the vertical benefit thing is assumptive to begin 
> with so there is no cure/compensation for it. If the stays weren't so 
> long the front end wouldn't need to be so long either, like how the Bomba 
> is. Of course one can still ride posture-vertical on any bike if that's 
> your thing, you certainly don't need surfboard length to do it. 
>
> In regards to decals mine has none, as it had the original font style that 
> to me, just didn't fit the bike. I prefer no brandings/names of frames 
> anyways. Create a cool looking(subjective, I know) small "LaBomba" or "Mad 
> Bomba" sticker and maybe I'd consider it   ((( laughing ))). The 
> frame/form speaks for itself though and doesn't need anything more. 
>
>
>
>
>
>
>
>

-- 
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/2120fbf6-5d56-4239-b686-7d47d34641bcn%40googlegroups.com.

[RBW] Re: Blue Lug / Nitto strut light mount hack

[JohnS]

Thank you BB for sharing. Nice, clean mounts for rear lights can be hard to 
find/improvise. How do you like the light? I'm not familiar with that one.

JohnS

On Saturday, February 4, 2023 at 8:46:33 AM UTC-5 brok...@gmail.com wrote:

> I was looking for a better way to mount my Koma rear light onto my Gus, 
> but still keeping the light high enough to see, AND using the original 
> light hardware for ease of unscrewing it and charging it each time.
>
> Then I found this neat little hack on Blue Lug's site and decided to try 
> it. Allows you to mount a light anywhere along the length of a Nitto rack 
> strut, and it's pretty unobtrusive-looking. I know the Nitto (left and 
> right side) light mount does the same thing, but it was too big and 
> unwieldy (and pricey) for this purpose. Plus, I like how this mount allows 
> me to tuck the light cleanly up under the rack platform, so it's not 
> sticking out very far.
>
> All you need is the Minoura Gamoh rack adapter (sold as a 2-pack), found 
> here through The Inconvenience Store: 
> https://the-inconvenience-store.com/collections/blue-lug/products/gamoh-rack-adapter
> ...and an extra Nitto daruma bolt (strut bolt).
>
> Optional: lop off and file the unused tab and voila! A clean, simple, 
> light mount for your Koma light!
> [image: IMG_4420.jpg][image: IMG_4419.jpg][image: IMG_4422.jpg]
>

-- 
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/8356b5f4-481b-4069-9651-bb5c5af75b76n%40googlegroups.com.

[RBW] Re: Roaduno catnip

[JohnS]

Thank you Doug. I think that was the only blug post that I didn't look at 
the other day.

JohnS

On Friday, February 3, 2023 at 11:13:06 AM UTC-5 lconley wrote:

> I want one with Bullmoose bars and cantilevers, in purple of course. Need 
> is a different matter...
>
> Laing
>
> On Friday, February 3, 2023 at 11:03:07 AM UTC-5 Doug H. wrote:
>
>> John,
>> There is one on the linked blog below. You'll need to scroll a bit to 
>> find the photo. Note that the fork is mismatched. 
>> Blog 
>> <https://www.rivbike.com/blogs/grant-petersens-blog/done-done-wrong-proably-still-doing-wrong>
>> Doug
>> On Friday, February 3, 2023 at 10:50:53 AM UTC-5 JohnS wrote:
>>
>>> Does any one have a link to a picture of a fully built Roaduno? I was 
>>> looking for one the other day and the closest I could find was the pics of 
>>> the three frames without paint. 
>>>
>>> Thanks!
>>> JohnS
>>>
>>> On Friday, February 3, 2023 at 9:34:41 AM UTC-5 mark e wrote:
>>>
>>>> I am excited to see the Uno in purple. 
>>>>
>>>> On Thursday, February 2, 2023 at 6:13:09 PM UTC-5 Edwin W wrote:
>>>>
>>>>> From Will's email update today:
>>>>> September: Roaduno complete and frames (lime-olive, purple and dark 
>>>>> gold).
>>>>>
>>>>> That's good news!
>>>>>
>>>>> Roaduno dreaming,
>>>>>
>>>>> Edwin
>>>>>
>>>>

-- 
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/1263ef3e-c5a9-4b8a-b99f-9face685e04an%40googlegroups.com.

[RBW] Re: Roaduno catnip

[JohnS]

Does any one have a link to a picture of a fully built Roaduno? I was 
looking for one the other day and the closest I could find was the pics of 
the three frames without paint. 

Thanks!
JohnS

On Friday, February 3, 2023 at 9:34:41 AM UTC-5 mark e wrote:

> I am excited to see the Uno in purple. 
>
> On Thursday, February 2, 2023 at 6:13:09 PM UTC-5 Edwin W wrote:
>
>> From Will's email update today:
>> September: Roaduno complete and frames (lime-olive, purple and dark gold).
>>
>> That's good news!
>>
>> Roaduno dreaming,
>>
>> Edwin
>>
>

-- 
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/f9fdbbcb-14be-4d4b-a713-9339cab2230cn%40googlegroups.com.

Re: [RBW] Bikes For Sale: Craigslist, ebay, etc. Fall 2022 edition

[JohnS]

A double Joe on e-bay, too bad about the fork, says the frame is ok, my 
size, but I'm not interested in the couplers, hope the link works...

https://www.ebay.com/itm/195580791334?hash=item2d89860a26:g:8xQAAOSwFcVj2rdv=enc%3AAQAHoJv5UDIf9dDzr79gBBXMhsE8B9HpZo%2Fqge9EDALLRrwXxaXDKk2Bx8qCfNa63hWX%2FNheZOQ6pKAiAOeEbRkMvVYBgpQgArMvYyJsXr382Y9%2BFgsiT%2FVZ7onThJP1Pm8JDrnCDiSCxq6%2F9XGMPv8JKadJzDe2jwKQX5HJiqyVfqBIDaIvo5CKIjNLW0RTcUaiZyv61SKTspQaaBv9FWZdBuQ%3D%7Ctkp%3ABk9SR9jBhK3CYQ

On Wednesday, February 1, 2023 at 9:38:48 PM UTC-5 Ryan wrote:

> That was snapped up fast!. Reynold decal on fork leads me to believe it's 
> an early Waterford Road or LL
>
> On Wednesday, February 1, 2023 at 12:34:34 AM UTC-6 Luke Hendrickson wrote:
>
>> Epic custom!
>>
>> On Tuesday, January 31, 2023 at 2:12:32 PM UTC-8 mmille...@gmail.com 
>> wrote:
>>
>>> Not sure the condition under the dirt, but looks like good value for a 
>>> custom Riv if you are in the San Jose area. Heck, could sell those tower 
>>> bars and nitto, clean and relist if you don't like it.
>>>
>>> https://sfbay.craigslist.org/sby/bik/d/san-jose-waterford-built-rivendell/7583922987.html[image:
>>>  
>>> 00d0d_a7kqoWQLvI0_0CI0lM_1200x900.jpeg]
>>>
>>> On Monday, January 30, 2023 at 8:20:25 AM UTC-6 eric...@gmail.com wrote:
>>>
 Looks like a price drop on the 60cm Hillborne in Vienna. 

 [image: 325914195_6538259239522205_455293595224308313_n.jpg]

 Sam Hillborne
 60cm
 $1,850
 Vienna, Virginia 

 https://www.facebook.com/marketplace/item/562587362592331/
 On Monday, January 2, 2023 at 9:57:19 PM UTC-5 aelga...@castilleja.org 
 wrote:

> And I’m selling my beautiful Sam in San Mateo.  $2100 
> Pedals and saddle not included. 
>
>
>
> On Mon, Jan 2, 2023 at 5:57 PM Eliot Balogh  
> wrote:
>
>> There’s a beautiful Ram in Ft Lauderdale
>>
>>
>> https://miami.craigslist.org/brw/bik/d/fort-lauderdale-2007-rivendell/7572481687.html
>>
>>
>> And this Sam in Atlanta
>>
>>
>> https://atlanta.craigslist.org/atl/bik/d/decatur-rivendell-hillborne-blue-and/7565756188.html
>>
>>
>> I would have jumped on one if I wasn’t Atlantis hunting. 
>>
>> -- 
>>
> 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-bun...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/rbw-owners-bunch/CAALGE1XXETvS6SNCe6kd_D_-0fPTRzcmBCeNRvbMaUE2DWN-DQ%40mail.gmail.com
>>  
>> 
>> .
>>
> -- 
>
> *Ahmed Elgasseir*
>
> Department Chair, Visual and Performing Arts
>
>
> *Castilleja School* 
>
> 1310 Bryant Street 
> 
>
> Palo Alto, CA 94301 
> 
>
>
> P (415) 654-7977
>
> E aelga...@castilleja.org
>
> www.castilleja.org   
>
>
> Follow us on Instagram  
> | Facebook  | Twitter 
>  | LinkedIn 
> 
>
>
> *Women Learning. Women Leading. *
>


-- 
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/02e8d438-1d5d-45d5-a31c-373c6cae1868n%40googlegroups.com.

[RBW] Re: Fun film encounter

[JohnS]

Julian,

Your friend has a very good eye for composition. I could see having that 
one framed.

JohnS

On Wednesday, February 1, 2023 at 8:07:53 PM UTC-5 jamin orrall wrote:

> this is great!
> On Wednesday, February 1, 2023 at 4:52:38 PM UTC-8 weste...@gmail.com 
> wrote:
>
>> About 2 weeks ago I was riding home from work on a cold, grey day and 
>> overtook a two friend walking on the multi-use trail on which i commute. I 
>> stopped to chat, and one of them got out a camera and asked if she could 
>> take some photos -- I said sure... 
>>
>> She just emailed me this digital image of the print image she took and 
>> developed -- she'll being over the actual print this weekend. Neato -- 
>> although had I been thinking about the photo instead of chatting I would 
>> have flipped the bike around drive-side out!  
>>
>> Bike is my Clem H 65 cm. 
>>
>> Julian Westerhout
>> Bloomington, IL  
>>
>

-- 
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/c849c311-b0b6-4b2c-bd00-8ee6deba6827n%40googlegroups.com.

Re: [xubuntu-users] unable to install grub

[Alex Johns]

On 2/02/23 08:29, Clarence Fender wrote:
Yes, this is an install from a USB. If it's supposed to install GRUB 
by itself, it's doing a very poor job :)   I have a 500M EFI 
partition. It fails.


sda   - all primary partitions
1M (appears by itself, no format)
500M  EFI
50G  ext4  /
16M swap
remainder of space ext4 but not mounted

Thanks.




Have you checksumed the ISO?  SHA256  I have had these type of issues 
when the ISO was corrupt


Also I have found that Rufus or Ventoy  are best for writing ISO to USB 
keys if you have a windows partition available  or gnome disks.  Some 
programmes  don't write the ISO correctly



da cyborg


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

Re: Dynamic loader usage in RTEMS 5.1

[Chris Johns]

On 14/1/2023 7:58 am, John Clemens wrote:
> I'm trying to understand how to build/link code to use the dynamic loader in
> RTEMS v5.1. I'm using
> https://docs.rtems.org/releases/rtems-5.1/user/exe/loader.html as a reference.
> 
> My codebase has a core object and several components that will be loaded at 
> boot
> time.  I do the 2-pass linking step with the embedded global symbol table on 
> my
> core object, and then run rtems-syms to generate "*-sym.o" objects for my
> runtime files (but do -not- send them through a second linking pass).
> 
> Now I have a core object and several "fooX.o" and "fooX-sym.o" files.. what 
> do I
> do from here?  Are the fooX-sym.o files supposed to be linked into the core
> object somehow?
> 
> I'm sure I'm missing an obvious step.  Any pointers?

Have you read the documentation in the User Manual:

https://docs.rtems.org/branches/master/user/exe/loader.html

If you still have some questions, please ask.

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

Re: [PATCH rtems-source-builder] dtc: Add patch to build for ticket 4783

[Chris Johns]

On 31/1/2023 10:23 am, Kinsey Moore wrote:
> On 1/30/2023 5:13 PM, Chris Johns wrote:
>> Can the subject please be:
>>
>> dtc: Add patch to build for cygwin builds
>>
>> ?
> 
> Unfortunately, Joel pushed this and a tools hash bump along with the other two
> patches, so that would require rewriting history.

That is a shame. We should limit references to tickets to the body of a commit
message and not the subject line. I needed to inspect the ticket to determine
what the change was about.

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

Re: [PATCH rtems-source-builder] dtc: Add patch to build for ticket 4783

[Chris Johns]

Can the subject please be:

dtc: Add patch to build for cygwin builds

?

Chris

On 31/1/2023 4:30 am, Kinsey Moore wrote:
> This patch resolves a build error with dtc on cygwin until upstream
> adopts a fix.
> ---
>  bare/config/devel/dtc-1.6.1-1.cfg | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/bare/config/devel/dtc-1.6.1-1.cfg 
> b/bare/config/devel/dtc-1.6.1-1.cfg
> index 54aed09..acf2cd8 100644
> --- a/bare/config/devel/dtc-1.6.1-1.cfg
> +++ b/bare/config/devel/dtc-1.6.1-1.cfg
> @@ -12,6 +12,9 @@
>  
>  %hash sha256 dtc-%{dtc_version}.tar.gz 
> 38a6257f2c23cb9dfa1781ac4ad122d8358e1a22d33b2da0eb492c190644a376
>  
> +%patch add dtc 
> https://devel.rtems.org/raw-attachment/ticket/4783/0001-checks.c-Ensure-argument-is-an-integer-v2.patch
> +%hash sha256 0001-checks.c-Ensure-argument-is-an-integer-v2.patch 
> dd83c10326188732ac26c1fd8dce70b796a7dde204b31c67cf4d04f29ed4dfef
> +
>  #
>  # The DTC build instructions. We use 1.x.x Release 1.
>  #
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-source-builder] devel/gnu-default-tools: Use correct include path

[Chris Johns]

OK

Thanks
Chris

On 31/1/2023 9:55 am, Kinsey Moore wrote:
> Include paths must use the full file name with extension. This was
> causing errors because it couldn't resolve the include.
> ---
>  bare/config/devel/gnu-default-tools.bset | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/bare/config/devel/gnu-default-tools.bset 
> b/bare/config/devel/gnu-default-tools.bset
> index cb253f4..2290788 100644
> --- a/bare/config/devel/gnu-default-tools.bset
> +++ b/bare/config/devel/gnu-default-tools.bset
> @@ -11,7 +11,7 @@
>  # available
>  #
>  %define _internal_gsed_path %{_tmppath}/sb-%{_uid}/${SB_PREFIX_CLEAN}
> -%include textproc/gsed-internal
> +%include textproc/gsed-internal.bset
>  
>  #
>  # Build gdb first to raise the Python install error as early as
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-source-builder] Update hashes for github-sourced tarballs

[Chris Johns]

OK

Thanks
Chris

On 31/1/2023 9:40 am, Kinsey Moore wrote:
> Github has changed the way it generates on-the-fly tarball requests
> which has changed the hashes of the resulting tarballs. This adjusts the
> affected tarball hashes as a stop-gap until a more permanent solution
> can be devised.
> ---
>  bare/config/devel/capstone-4.0.1-1.cfg| 2 +-
>  bare/config/devel/gcc-12-newlib-head.cfg  | 4 ++--
>  bare/config/devel/qemu-couverture-git-1.cfg   | 2 +-
>  bare/config/devel/spike-1.1.0.cfg | 2 +-
>  bare/config/devel/swig-4.0.1.cfg  | 2 +-
>  rtems/config/graphics/microwindows-0.93-dev-1.cfg | 2 +-
>  rtems/config/net-mgmt/net-snmp-5.7.2.1-1.cfg  | 2 +-
>  rtems/config/tools/rtems-binutils-2.36.cfg| 2 +-
>  rtems/config/tools/rtems-binutils-head.cfg| 2 +-
>  rtems/config/tools/rtems-gcc-10-newlib-head.cfg   | 4 ++--
>  rtems/config/tools/rtems-gcc-10.4-newlib-head.cfg | 2 +-
>  rtems/config/tools/rtems-gcc-12-newlib-head.cfg   | 4 ++--
>  rtems/config/tools/rtems-gcc-head-newlib-head.cfg | 4 ++--
>  rtems/config/tools/rtems-gdb-head.cfg | 2 +-
>  source-builder/config/capstone-1-1.cfg| 2 +-
>  15 files changed, 19 insertions(+), 19 deletions(-)
> 
> diff --git a/bare/config/devel/capstone-4.0.1-1.cfg 
> b/bare/config/devel/capstone-4.0.1-1.cfg
> index 9f3627c..3a7c6bc 100644
> --- a/bare/config/devel/capstone-4.0.1-1.cfg
> +++ b/bare/config/devel/capstone-4.0.1-1.cfg
> @@ -19,7 +19,7 @@
>  # Set source from github.
>  #
>  %source set capstone --rsb-file=capstone-%{capstone_version}.tar.gz 
> https://github.com/aquynh/capstone/archive/%{capstone_version}.tar.gz
> -%hash sha512 capstone-%{capstone_version}.tar.gz 
> 43c52024065b41b45eff9423341db3f3d5163fa7aa01b360faa30437786740c8f2c34c36faa04dced5308e09d8bd78df3bad0ab9c06f98612169edb176f83c36
> +%hash sha512 capstone-%{capstone_version}.tar.gz 
> 296c90fcca96117b710472fb55881cb932f4f1d45e847647c2357bfa15bf36fd7f4584db5ffdabf85703d9840e65085ba76f387e6a8e0af941a344dcf95c
>  
>  #
>  # The build instructions.
> diff --git a/bare/config/devel/gcc-12-newlib-head.cfg 
> b/bare/config/devel/gcc-12-newlib-head.cfg
> index ce168ea..d50553d 100644
> --- a/bare/config/devel/gcc-12-newlib-head.cfg
> +++ b/bare/config/devel/gcc-12-newlib-head.cfg
> @@ -5,7 +5,7 @@
>  %define gcc_external 1
>  %define gcc_expand_name gnu-mirror-gcc-%{gcc_version}
>  %source set gcc --rsb-file=%{gcc_expand_name}.tar.gz 
> https://codeload.github.com/RTEMS/gnu-mirror-gcc/tar.gz/%{gcc_version}
> -%hash sha512 %{gcc_expand_name}.tar.gz 
> f9eb91029c31ed2ca3c4ce2066d99352f63f55120aaad295b58621786fe76228d182a4421292fa95007ac6b6529a589795fe3e794ac77b0b86f9cf9286125e36
> +%hash sha512 %{gcc_expand_name}.tar.gz 
> 2f78955344634e3d13a34ae8e724a61761dbc71a88e41916192e6c9d01508014ded06e32a9b640d203b6a8e989ec5410bda32d0469f4b3fe5bf20ae63ad9de21
>  
>  %patch add gcc -p1 
> https://devel.rtems.org/raw-attachment/ticket/4196/0001-Back-port-v1-of-gcov-tool-merge-stream-to-GCC-12.patch
>  %hash sha512 0001-Back-port-v1-of-gcov-tool-merge-stream-to-GCC-12.patch 
> 413f14374856f8bfd2bb94a56f1860fff8fe9a936f33c96fdf6a5a0c5a30e2cf7d05026d0338e8b30015a93d80169a602397076b947c8292ac5b5cdc2237ec4e
> @@ -31,7 +31,7 @@
>  %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 
> 0e142b06b855b78729c3319e31cf5c15b48cea1f90e001ae1e2d61793c496374065c5658e835e6277ae0739af22ea397feb2c1bc2509a6a80ee6c03818efbf55
> +%hash sha512 newlib-%{newlib_version}.tar.gz 
> 051496b686c0acaf1e5fb4f63155aa35357bbe71017f827d6e4113138fec964b083f29c880c3ced9db6e09dc6b3b5bc11ea7d9e9e2987ce015ac2784c2905082
>  
>  %define with_threads 1
>  %define with_plugin 0
> diff --git a/bare/config/devel/qemu-couverture-git-1.cfg 
> b/bare/config/devel/qemu-couverture-git-1.cfg
> index bb9b7a6..c6fbe1f 100644
> --- a/bare/config/devel/qemu-couverture-git-1.cfg
> +++ b/bare/config/devel/qemu-couverture-git-1.cfg
> @@ -29,7 +29,7 @@
>  # Set Couverture-Qemu source from github.
>  #
>  %source set qemu --rsb-file=qemu-couverture-%{qemu_version}.tar.gz 
> https://github.com/AdaCore/qemu/archive/%{qemu_version}.tar.gz
> -%hash sha512 qemu-couverture-%{qemu_version}.tar.gz 
> 4b1877f1e8a10508b161a2b65f8e862e2ffa5bfc36cb458cdcad4e8a71a384bbb28e7fb50555008b023691b8187d252870586b1435e31989d059692f53ad6e1c
> +%hash sha512 qemu-couverture-%{qemu_version}.tar.gz 
> e26959cb55ae0c565c299ec38fe86b7bf85bdb246bfc99f0fcd22e1baaebaa05e96a46b3781443678fb63de8e4b3b7b0abc30d717eda6eef216a53fcabab47c0
>  
>  #
>  # The Qemu build instructions. We use 4.x.x Release 1.
> diff --git a/bare/config/devel/spike-1.1.0.cfg 
> b/bare/config/devel/spike-1.1.0.cfg
> index 73cf3c2..5a8cae0 100644
> --- 

Re: [RSB 5] Remove aarch64 and microblaze from RSB on 5 branch

[Chris Johns]

OK to push

Thanks
Chris

On 31/1/2023 1:44 am, Joel Sherrill wrote:
> Closes #4555.
> ---
>  rtems/config/5/rtems-aarch64.bset| 4 
>  rtems/config/5/rtems-all.bset| 2 --
>  rtems/config/5/rtems-microblaze.bset | 3 ---
>  rtems/config/5/rtems-tier-4.bset | 1 -
>  4 files changed, 10 deletions(-)
>  delete mode 100644 rtems/config/5/rtems-aarch64.bset
>  delete mode 100644 rtems/config/5/rtems-microblaze.bset
> 
> diff --git a/rtems/config/5/rtems-aarch64.bset 
> b/rtems/config/5/rtems-aarch64.bset
> deleted file mode 100644
> index f38aff3..000
> --- a/rtems/config/5/rtems-aarch64.bset
> +++ /dev/null
> @@ -1,4 +0,0 @@
> -%define release 1
> -%define rtems_arch aarch64
> -%define with_libgomp
> -%include 5/rtems-default.bset
> diff --git a/rtems/config/5/rtems-all.bset b/rtems/config/5/rtems-all.bset
> index 00ccfae..81076e4 100644
> --- a/rtems/config/5/rtems-all.bset
> +++ b/rtems/config/5/rtems-all.bset
> @@ -1,11 +1,9 @@
> -5/rtems-aarch64
>  5/rtems-arm
>  5/rtems-bfin
>  5/rtems-epiphany
>  5/rtems-i386
>  5/rtems-lm32
>  5/rtems-m68k
> -5/rtems-microblaze
>  5/rtems-mips
>  5/rtems-moxie
>  5/rtems-nios2
> diff --git a/rtems/config/5/rtems-microblaze.bset 
> b/rtems/config/5/rtems-microblaze.bset
> deleted file mode 100644
> index e5c23af..000
> --- a/rtems/config/5/rtems-microblaze.bset
> +++ /dev/null
> @@ -1,3 +0,0 @@
> -%define release 1
> -%define rtems_arch microblaze
> -%include 5/rtems-default.bset
> diff --git a/rtems/config/5/rtems-tier-4.bset 
> b/rtems/config/5/rtems-tier-4.bset
> index 24d392d..042f2a0 100644
> --- a/rtems/config/5/rtems-tier-4.bset
> +++ b/rtems/config/5/rtems-tier-4.bset
> @@ -5,6 +5,5 @@
>  # anyone working on adding a BSP.
>  #
>  5/rtems-epiphany
> -5/rtems-microblaze
>  5/rtems-riscv
>  5/rtems-x86_64
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[RBW] Re: What's up with welded Nitto parts?

[JohnS]

Thank you Jeff for sharing. Eric had mentioned Circles bike shop in his 
MB-2 build, so I appreciate the link.

Is it just me or is it kind of crazy that we have to search the world over 
to find a particular bike part It shouldn't have to be this hard to 
find current production parts. I could understand if it were some odd, 
vintage part that was out of production for decades, but really, production 
parts not available in the US. Ugh, rant off.

JohnS

On Monday, January 30, 2023 at 12:29:42 PM UTC-5 jeff dobie wrote:

> I have been looking for a particular Nitto stem for several months with no 
> luck and some how stumbled on this place in Japan Circles bicycle shop 
> https://shop.circles-jp.com/en  shipping was only $22 and they shipped 
> right away via fedex
> On Saturday, January 21, 2023 at 3:37:21 PM UTC-7 Joe Bernard wrote:
>
>> The way I read it - a completely wild guess - is the supply has been 
>> terrible for years and most of it has gotten too pricey to try to sell. Riv 
>> has been slowly replacing everything welded with cheaper/more plentiful 
>> options, I imagine they're going to keep the forged stems and that's about 
>> it. Guessing! 
>>
>> On Saturday, January 21, 2023 at 2:28:29 PM UTC-8 JohnS wrote:
>>
>>> Anyone know what's going on here???
>>>
>>> From Will's January update email...
>>>
>>>  *Anything Nitto makes that's welded might get scarce soon. We still 
>>> have big back racks, fillet stems, bullmoose bars, 32F mini front racks, 
>>> brake hangers, and lugged stems and posts; If you've been eyeing something 
>>> on that list, I'd get it now.*
>>>
>>> That's kind of scary! Nitto parts are my favs.
>>>
>>> JohnS
>>>
>>

-- 
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/74a8d709-2227-4db3-b7c1-5b7b25864ce9n%40googlegroups.com.

Re: [RBW] Single-Bolt Stem Spreading Options

[JohnS]

+1 on the coin trick, but I've used a large flat washer, no federal offense 
committed :P

JohnS


On Friday, January 27, 2023 at 9:26:33 AM UTC-5 Patrick Moore wrote:

> This works if the threaded hole is open at the outer end but not if it's 
> capped. I've managed to spread Nitto stems with a large flathead 
> screwdriver but yes, the Nitto spreader tool is far easier to use. If the 
> absence of the Nitto tool, a thin but stiff and sturdy and properly thick 
> piece of steel works better than the flathead which will have a tapered 
> profile that makes this use awkward.
>
> FWIW, way back in the day when I several times installed drop bars onto my 
> 55 cm XO-1 and my first, similarly-sized (54 cm) 1995 Riv road custom 
> (Grant said "Don't you dare" when I told him I'd tell others how much I 
> liked the compact, XO-1-style frame design, but I think the statute of 
> limitations has expired) using the penny trick. In fact, several times I 
> installed a 26.4 mm Cinelli Giro d'Italia bar into 25.4mm Tioga and Salsa 
> steel stems using this method; steel is very forgiving.
>
> On Fri, Jan 27, 2023 at 1:13 AM 'Hetchins52' via RBW Owners Bunch <
> rbw-owne...@googlegroups.com> wrote:
>
>> I usually have a nickel (with a few, round dents already in it) somewhere 
>> on one of my work stands for when I need to do this. Dime is too thin, a 
>> penny too soft and a quarter is too valuable!
>> David in Berkeley
>>
>> On Thursday, January 26, 2023 at 4:27:32 PM UTC-8 Andrew Letton wrote:
>>
>>> Hi Brian, 
>>>
>>> If your stem has a tapped hole for the clamp bolt (as many steel stems 
>>> have, rather than a loose nut like many aluminum Nittos) you can use this 
>>> method:
>>>
>>> Helpful tip: Take the pinch bolt out. Insert a coin in the slot between 
>>> the clamp area. Thread the bolt in from the back side. Tighten it against 
>>> the coin. It will force the clamp open and it will stay that way during 
>>> your install.
>>>
>>> (I copied this from the net, rather than type up my own description.)
>>>
>>

-- 
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/af21d51a-ff67-4c54-afe7-c73031ae8958n%40googlegroups.com.

[RBW] Re: New build: 1985 Bridgestone MB-2

[JohnS]

Thank you Eric on the cable length tip. I'll measure/eyeball a few times 
before cutting. Now I can't decide if I want the Nissen clear or steel blue 
to work with the blue in the head badge, too many choices.

John

On Friday, January 27, 2023 at 11:13:59 AM UTC-5 eric...@gmail.com wrote:

> Mike — Wow, definitely sounds like the same bike I started out with. I 
> thought I had some footage of the disassembled bike but I couldn't find any 
> when it came time for the edit. Bridgestone called the color "shadow blue" 
> in their catalog (here's a link 
> 
>  
> for reference). The catalog also specs the weight at 32lbs so you're right 
> on. Very cool you got Grant to sign it and maybe the new owner has come 
> around to checking out the old Bridgestone and Rivendell lore. The gold 
> Araya rims are now on an MB-3 from the same year I built up for a friend. 
>
> Paul — Thanks for checking it out! 
>
> On Thursday, January 26, 2023 at 11:35:06 PM UTC-5 Bikie#4646 wrote:
>
>> Fantastic Eric. Congrats, nicely done.
>>
>> Paul Germain
>> Midlothian, Va.
>>
>> On Monday, January 23, 2023 at 6:06:27 PM UTC-5 eric...@gmail.com wrote:
>>
>>> [image: MB-2 230115 S 00 Complete.jpg]
>>>
>>> Hi all — I just finished up a build, it's a 1985 Bridgestone MB-2. I 
>>> have a full build video up over here: https://youtu.be/gJPnbpzjbKg
>>>
>>> [image: MB-2 230115 S 01 Complete.jpg]
>>>
>>> I purchased the bike as a complete from Marketplace, it was stock but 
>>> for the saddle and tires. Everything was removed and I passed the frame 
>>> over to Rob Gassie at Bing Bicycles. He added some rack mounts to the fork 
>>> and seat stays, changes some the cable guides, added a third bottle boss to 
>>> the downtube and two additional bottle bosses to the underside. He also 
>>> stripped the frame to raw steel. 
>>>
>>> [image: MB-2 230115 S 02 Headbadge.jpg]
>>>
>>> Instead of paint I went for a raw finish. There are two applications of 
>>> patination acids, with and without heat, followed by clear lacquer and wax. 
>>>
>>> [image: MB-2 230115 S Rear mech.jpg]
>>>
>>> It's built up with a mix of parts from across time, all silver. 
>>> De-anodized some black Paul cantilevers and also de-anodized an XTR 
>>> RD-M952. Dead stock WTB grease guard headset purchased from Jacque Phelan. 
>>> Lots of Suntour, some TA cranks and modern parts from Japan. Crust x Nitto 
>>> Shaka bars, MKS bear trap pedals, Nitto cable hanger. 
>>>
>>> [image: MB-2 230115 S Downtube.jpg]
>>>
>>> I had some custom brass headbadges made with the old Bridgestone logo 
>>> which I shaped and finished. 
>>>
>>> [image: MB2 09 SM Head tube.jpg]
>>>
>>> Velocity Atlas 26" wheelset with a Kasai dynamo hub up front and an XTR 
>>> M900 in the rear. Front wheel by Rich at Rivendell, rear built by Andre at 
>>> my local bike shop. I'm running Rene Herse extra-light tires with a Rat 
>>> Trap Pass in the back and a Humptulips Ridge in front. 
>>>
>>> Many thanks to members here for helping out with parts when I needed 
>>> them: Trevor B., Dave H., Liz S. and Patrick M. 
>>>
>>> • Velocity Atlas 26" 32/32 wheelset
>>> • Rene Herse Antelope Hill, extra light
>>> • Rene Herse Rat Trap Pass, extra light
>>> • Shimano XTR M900 rear hub
>>> • Kasai 32H front hub
>>> • Schmidt Edelux II polished headlight
>>> • Busch + Müller light mount
>>> • Crust x Nitto Shaka handlebars, 54cm
>>> • Newbaum's cotton bar tape, white
>>> • Suntour Bar-Con shifters
>>> • Suntour Superbe levers
>>> • Paul Neo Retro cantilever brakes, front
>>> • Paul Touring cantilever brakes, rear
>>> • Hunter Nugz barrel adjusters
>>> • Dia Compe yoke hangers
>>> • Fairweather x Nitto stem-mounted cable hanger
>>> • Nitto Technomic 6cm stem, 26.0 clamp 
>>> • WTB New Paradigm Grease Guard headset 
>>> • TA Specialities Cyclotourist crankset, 48/42/28, 170mm 
>>> • Shimano 115mm square taper bottom bracket 
>>> • Shimano 9 speed 12-36 cassette
>>> • MKS XC-III pedals
>>> • Suntour AR front derailer
>>> • Shimano XTR MD-952 rear derailer 
>>> • Suntour XC Pro seat post 
>>> • Brooks Conquest saddle
>>> • Wheels Mfg. brass housing ferrules
>>> • Sim Works x Nissen brass cable ferrules
>>> • Sim Works x Nissen brake and shift housing 
>>> • Sim Works x Hoshi
>>> • M5 brass socket head screws
>>> • Shovel Research M5 brass slotted screws
>>>
>>> Larger pictures here: 
>>> https://drive.google.com/file/d/1_gXuRvwsKYVjG7GLMqFf2KGhPrYRNlp3/view?usp=sharing
>>>
>>> Thanks for lookin'! 
>>>
>>

-- 
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/b3e7ca20-2fb1-4752-9527-f669e1704cdbn%40googlegroups.com.

[RBW] Re: New build: 1985 Bridgestone MB-2

[JohnS]

Hello Eric,

How do you like the  Sim Works x Nissen brake housing? I'm thinking of 
using the clear on my Quickbeam (also trying to minimize black on the 
build), would be the same Superbe brake levers (from my '83 expedition) and 
Paul brakes, except the front will be the mini-mottos. Usually I use 
Jagwire pro-slick cables and housings, kind of spoiled by them.

Thank you!
JohnS

On Wednesday, January 25, 2023 at 4:17:47 PM UTC-5 David Pulsipher wrote:

> beautiful work Eric - thank you for sharing with us!
>
> On Monday, January 23, 2023 at 4:06:27 PM UTC-7 eric...@gmail.com wrote:
>
>> [image: MB-2 230115 S 00 Complete.jpg]
>>
>> Hi all — I just finished up a build, it's a 1985 Bridgestone MB-2. I have 
>> a full build video up over here: https://youtu.be/gJPnbpzjbKg
>>
>> [image: MB-2 230115 S 01 Complete.jpg]
>>
>> I purchased the bike as a complete from Marketplace, it was stock but for 
>> the saddle and tires. Everything was removed and I passed the frame over to 
>> Rob Gassie at Bing Bicycles. He added some rack mounts to the fork and seat 
>> stays, changes some the cable guides, added a third bottle boss to the 
>> downtube and two additional bottle bosses to the underside. He also 
>> stripped the frame to raw steel. 
>>
>> [image: MB-2 230115 S 02 Headbadge.jpg]
>>
>> Instead of paint I went for a raw finish. There are two applications of 
>> patination acids, with and without heat, followed by clear lacquer and wax. 
>>
>> [image: MB-2 230115 S Rear mech.jpg]
>>
>> It's built up with a mix of parts from across time, all silver. 
>> De-anodized some black Paul cantilevers and also de-anodized an XTR 
>> RD-M952. Dead stock WTB grease guard headset purchased from Jacque Phelan. 
>> Lots of Suntour, some TA cranks and modern parts from Japan. Crust x Nitto 
>> Shaka bars, MKS bear trap pedals, Nitto cable hanger. 
>>
>> [image: MB-2 230115 S Downtube.jpg]
>>
>> I had some custom brass headbadges made with the old Bridgestone logo 
>> which I shaped and finished. 
>>
>> [image: MB2 09 SM Head tube.jpg]
>>
>> Velocity Atlas 26" wheelset with a Kasai dynamo hub up front and an XTR 
>> M900 in the rear. Front wheel by Rich at Rivendell, rear built by Andre at 
>> my local bike shop. I'm running Rene Herse extra-light tires with a Rat 
>> Trap Pass in the back and a Humptulips Ridge in front. 
>>
>> Many thanks to members here for helping out with parts when I needed 
>> them: Trevor B., Dave H., Liz S. and Patrick M. 
>>
>> • Velocity Atlas 26" 32/32 wheelset
>> • Rene Herse Antelope Hill, extra light
>> • Rene Herse Rat Trap Pass, extra light
>> • Shimano XTR M900 rear hub
>> • Kasai 32H front hub
>> • Schmidt Edelux II polished headlight
>> • Busch + Müller light mount
>> • Crust x Nitto Shaka handlebars, 54cm
>> • Newbaum's cotton bar tape, white
>> • Suntour Bar-Con shifters
>> • Suntour Superbe levers
>> • Paul Neo Retro cantilever brakes, front
>> • Paul Touring cantilever brakes, rear
>> • Hunter Nugz barrel adjusters
>> • Dia Compe yoke hangers
>> • Fairweather x Nitto stem-mounted cable hanger
>> • Nitto Technomic 6cm stem, 26.0 clamp 
>> • WTB New Paradigm Grease Guard headset 
>> • TA Specialities Cyclotourist crankset, 48/42/28, 170mm 
>> • Shimano 115mm square taper bottom bracket 
>> • Shimano 9 speed 12-36 cassette
>> • MKS XC-III pedals
>> • Suntour AR front derailer
>> • Shimano XTR MD-952 rear derailer 
>> • Suntour XC Pro seat post 
>> • Brooks Conquest saddle
>> • Wheels Mfg. brass housing ferrules
>> • Sim Works x Nissen brass cable ferrules
>> • Sim Works x Nissen brake and shift housing 
>> • Sim Works x Hoshi
>> • M5 brass socket head screws
>> • Shovel Research M5 brass slotted screws
>>
>> Larger pictures here: 
>> https://drive.google.com/file/d/1_gXuRvwsKYVjG7GLMqFf2KGhPrYRNlp3/view?usp=sharing
>>
>> Thanks for lookin'! 
>>
>

-- 
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/c8a9b462-37ea-4034-aa80-f76d3c06c767n%40googlegroups.com.

[RBW] Re: New build: 1985 Bridgestone MB-2

[JohnS]

Eric and Greg,

Both are excellent builds! Well done. Any chance we'll see either of them 
featured on The Radavist, Reader's Rides???

I would like to see a frame overlay of Eric's MB-2 and my '82 Stumpjumper. 
Looks like they have very similar geometries and long wheelbases. 

JohnS

On Wednesday, January 25, 2023 at 11:44:15 AM UTC-5 MoVelo wrote:

> Eric, beautiful build. looks like you had fun with that one!
>
> Greg, very nice restoration.
>
> James P
> mid-nebraska
>
> On Wednesday, January 25, 2023 at 8:45:38 AM UTC-6 Ted Durant wrote:
>
>> On Monday, January 23, 2023 at 5:06:27 PM UTC-6 eric...@gmail.com wrote:
>> Hi all — I just finished up a build, it's a 1985 Bridgestone MB-2. I have 
>> a full build video up over here: https://youtu.be/gJPnbpzjbKg
>>
>> Wow - labor of love! So much attention to detail. I love seeing people 
>> pour time and money into something with no expectation for "getting their 
>> money out of it" at the end. 
>>
>> Ted Durant
>> Milwaukee WI USA  
>>
>

-- 
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/d0394b79-cb1b-4bfc-ac2d-5206d4f64472n%40googlegroups.com.

[RBW] What's up with welded Nitto parts?

[JohnS]

Anyone know what's going on here???

>From Will's January update email...

 *Anything Nitto makes that's welded might get scarce soon. We still have 
big back racks, fillet stems, bullmoose bars, 32F mini front racks, brake 
hangers, and lugged stems and posts; If you've been eyeing something on 
that list, I'd get it now.*

That's kind of scary! Nitto parts are my favs.

JohnS

-- 
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/0ba690f1-5d1b-4ba5-8cbc-e4a451aa9221n%40googlegroups.com.

[RBW] Re: Selle Anatomica carbon rails with Nitto S65 seatpost?

[JohnS]

That's interesting. I wonder what they think of the  Selle Anatomica carbon 
rails being used with an S83? I have that set up on my Crust Lightning 
Bold/canti for well over a year and seems to be fine to me. Then again the 
S83 has two bolts to clamp the rails, maybe that's the difference.

JohnS

On Friday, January 20, 2023 at 6:24:34 PM UTC-5 andyree...@gmail.com wrote:

> The silence from the group and Nitto's web page has given me my answer. 
> If you gotta ask, don't do it! 
>
> Cheers,
> Andrew- will-soon-be-selling-carbon-rails- Turner
>
> On Friday, January 20, 2023 at 2:08:17 PM UTC-6 Andrew Turner wrote:
>
>> Simple question, 
>> I have a set of carbon rails from Selle Anatomica I'd like to install but 
>> wanted to double-check that the Nitto S65 seatpost I'll be using won't 
>> present a problem. Would I need to opt for a double-bolt design instead? 
>>
>> Cheers, 
>> Andrew-  shaving-50-dumb-grams  -Turner
>>
>

-- 
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/e2f18084-7eed-460f-969f-5dec510cb302n%40googlegroups.com.

Re: [PATCH v2 1/1] RSB: Mitigate too short error reports

[Chris Johns]

OK to push.

Thanks
Chris

On 21/1/2023 2:06 am, Frank Kuehndel wrote:
> From: Frank Kühndel 
> 
> Close #4642
> ---
>  source-builder/sb/ereport.py | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/source-builder/sb/ereport.py b/source-builder/sb/ereport.py
> index d8fb5f6..52ee2eb 100755
> --- a/source-builder/sb/ereport.py
> +++ b/source-builder/sb/ereport.py
> @@ -54,7 +54,9 @@ def generate(name, opts, header = None, footer = None):
>  name = name.replace('/', '-')
>  with open(name, 'w') as l:
>  l.write(os.linesep.join(r))
> -log.notice('  See error report: %s' % (name))
> +log.notice(os.linesep.join(['  See error report: %s' % (name),
> +'  Note: In some cases the error appears only in',
> +'  the complete build log (see --log option)']))
>  except:
>  log.stderr('error: failure to create error report')
>  raise
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[RBW] Re: Sam Build - Wish Me Luck!

[JohnS]

Looks great Jake! Congrats on your first build, seems like you have a knack 
for it.

Enjoy,
JohnS

On Friday, January 20, 2023 at 9:31:06 AM UTC-5 jak...@me.com wrote:

> Done!
>
> No one was hurt in the process, thankfully!  It goes, stops, and actually 
> shifts.  What fun.   My reflections are that I know I took about 10 times 
> longer to build this than was necessary, but I enjoyed every minute.  Very 
> little profanity was used, hardly any at all.  The derailer hanger was out 
> about, say, 5-10 degrees out of the box, so that was an easy adjustment 
> with the expensive Park tool that I may never use again.  :-)   I was able 
> to find Shimano instructions for the Nexave online, so that was super 
> helpful.  I still need to dial the shifting in, but it works beautifully in 
> friction mode.  It's a mess in index mode.  I think I have my answer 
> there.  Keep it in friction.  Right.  Getting the FD dialed in was much 
> more finicky than I anticipated.
>
> Where's Kim?  Hey Kim, the Selle Anatomica rocks!  Right out of the box 
> super comfort.   I'm definitely joining the club.  I am going to kick my 
> old B-17 to the curb.  And the big H stamped on the saddle matches with 
> Hillborne!  Bonus.  I am going to hold off on the shellac as the Newbaum 
> feels great naked.  If it gets gnarly over time it's easy enough to 
> rewrap.  I might hit up the twine with some shellac though.  I might also 
> swap out those black DXR brake handles for some expensive Paul's as I am 
> not sure I like the black.  They sure do work well, though.  The Albatross 
> looks huge in this picture, but not so much in reality.  It's a keeper - 
> super comfortable.  Body positioning is very neutral on this upright 
> configuration. Love the platform of the pedals.  I tried to keep the 
> obnoxious blue to a minimum while accenting it.  That's an Air Force blue 
> if anyone was wondering.
>
> Needs a rack or two, undecided on fenders (toe clearance), and a cool 
> matching stowaway bag from Tunitas is on it's way.  Time to re-torque 
> everything and go for a nice long ride.
>
> [image: Silver Sam.JPG]
>
> Last night when I finished it.  Cockpit view.
>
> [image: SH Cockpit.JPG]
>
> Fun stuff!
>
> On Friday, January 20, 2023 at 8:59:39 AM UTC-5 Slacky Mac wrote:
>
>> Have you looked at the SimWorks "Obento" rack?
>>
>> Hi David, yes I did.  Jess (of Tunitas) directed me to the Obento after I 
>> inquired what that beautiful rack was on her bike pictured on the Riv 
>> site.  Sadly, not the same aesthetic as the Potluck.  Similar function 
>> though.
>>
>> On Wednesday, January 18, 2023 at 3:34:11 AM UTC-5 Hetchins52 wrote:
>>
>>> Have you looked at the SimWorks "Obento" rack?
>>>https://www.sim.works/products/obento-rack
>>> Pricey, but the "shiny" version seems to be in stock!
>>>
>>> David Lipsky
>>> Berkeley, CA
>>> On Tuesday, January 17, 2023 at 12:40:19 PM UTC-8 jak...@me.com wrote:
>>>
>>>> “Any changes in parts and such while thinking over the build?”
>>>>
>>>> Reginald - yes, a few!   I switched to bar ends as thumbie mounts were 
>>>> temporarily out of stock and I was impatient.  Lots of downstream effects 
>>>> from that one.  I originally wanted to go with Ergon cork grips with 
>>>> something like a Billie or a Crumworks bar.  I’ll see if the bar-ends on 
>>>> my 
>>>> old Albatross and prodigious use of Newbaums works.  It’ll be creative 
>>>> (nice word for obviously DIY).  If it’s not comfy, easy enough to make a 
>>>> change.
>>>>
>>>> With the gigantic pedals, I am concerned with toe-to-tire spacing, so 
>>>> am holding off on fenders.  Also no decision on racks. Crushed that the 
>>>> Nitto Potluck rack is NLA.
>>>>
>>>> Getting there.  Riv box delivered today, more work this weekend. 
>>>>  Assuming the Nexave derailer doesn’t derail me, should be finished up and 
>>>> ready to ride.  (Whoa that’s a big photo - sorry). 
>>>>
>>>> Jake
>>>>
>>>> [image: A00698B8-FA9B-4BE4-8582-253D37FDB4B9.jpeg]
>>>>
>>>>
>>>> On Monday, January 16, 2023 at 1:46:21 AM UTC-5 R. Alexis wrote:
>>>>
>>>>> Congratulations How exciting when the planning and futzing over 
>>>>> the bike and parts finally come together. Any changes in parts and such 
>>>>> while thinking over the build? I know when I built the Rivendell Mountain 
>>>>> I 
>>>>> went back and

Re: [PATCHES rtems, source-builder] Add GitHub Actions scripts

[Chris Johns]

On 20/1/2023 1:50 am, Christian MAUDERER wrote:
> Am 19.01.23 um 15:42 schrieb Gedare Bloom:
>> Nice. I would like some time to look at this and think about it a
>> little more. What would be the plan for removing this capability? Will
>> it leave any artifacts behind in the RTEMS github mirror?
> 
> As soon as we want to get rid of the scripts again (because we have found and
> implemented a proper CI/CD that we officially want to use and not only have 
> in a
> test phase), we can just remove the scripts with a new commit.
> 
> If we use both commits, we will have a bot that adds a comment to pull 
> requests,
> that patches should be sent to the mailing list as soon as they are tested. It
> will close pull requests after 30 days. That can be disabled again with 
> removing
> that action.
> 
> All artefacts can be removed by everyone with enough rights in the RTEMS 
> GitHub
> organization. That should be most maintainers.

What github account does all this happen on?

Chris

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

Re: [PATCH] build: Update PyYAML to 5.4.1

[Chris Johns]

On 20/1/2023 1:59 pm, Chris Johns wrote:
> On 20/1/2023 1:51 pm, Gedare Bloom wrote:
>> On Thu, Jan 19, 2023 at 5:23 PM Chris Johns  wrote:
>>>
>>> On 20/1/2023 2:19 am, Sebastian Huber wrote:
>>>> The latest version is 6.0 which dropped support for Python 2.7.
>>>
>>> Was 6 our last version to support python 2 and 3?
>>>
>>> Is making this change this close to a release wise?
>>>
>> I sense confusion here. Are we referring to Pyyaml 6.0, or RTEMS 6.0?
> 
> I assumed it referenced RTEMS 6.
> 
>> I understand the comment above to mean we can't update to pyyaml 6.0
>> yet, because it doesn't support Python 2.7 which we still require for
>> the user-facing tools.
> 
> Thanks, that confirms my understanding. So this means it is not OK to apply.
> 

Oh I see and yes I have misunderstood the patch twice. Sorry about that.

We can drop user facing python 2 support after RTEMS 6 branches. :)

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

Re: [PATCH 1/3] build: Format build items

[Chris Johns]

On 20/1/2023 11:53 am, Amar Takhar wrote:
> On 2023-01-20 11:03 +1100, Chris Johns wrote:
> 
>> I have been OK with the headers and tests being generated this way because 
>> the
>> agreement is files in rtems.git can be manually edited and rtems-central has 
>> to
>> track those changes. The sources and code to generate the files need to be
>> located together.
> 
> Yes.  To be clear in this case if we have  in rtems.git and 
>  in rtems-central.git where you need to edit  to 
> generate  then both the tool *and* somefile.yml need to be in 
> rtems.git.

Placing the API header spec files into rtems.git complicates being able to
update or add a new API by editing the header files. With the spec files to
generate the headers in the same repo they would need to be updated and that
means learning about the whole qual workflow, spec formats etc. This is why the
separation is done this way. As things are the rtems-central could be left as is
and rtems.git is not effected. We just continue to maintain the headers
manually. Those interested in qualifications can fund support for rtems-central
independently of the other parts of RTEMS.

> If what you are saying is the requirement is reversed.  rtems-central.git 
> needs 
> rtems.git to work that's fine and the order it should be.

The rtems-central specs files are cleverly put together so the headers,
documentation and other pieces are all handled from one place. This means all
pieces would need to be brought together. The rtems-central repo is the central
clearing house for the specifications.

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

Re: [PATCH 1/3] build: Format build items

[Chris Johns]

On 20/1/2023 11:22 am, Karel Gardas wrote:
> 
> Sorry to hijack that thread, but correction is needed here.
> 
> On 1/20/23 01:03, Chris Johns wrote:
>> The FreeBSD single repo is about the kernel and base runtime. The ports are 
>> not
>> part of this so the analogy breaks down.
> 
> Certainly all BSDs have separated ports repos, but AFAIK all of them maintain 
> so
> called base and in base there is kernel, libs, bin/sbin commands and most
> importantly *all* tool-chain required to build *all* this code to form whole 
> OS.

Yes the ports place executables in /usr/local. The kernel and base is considered
a working set so the user commands under /bin /usr/bin /sbin etc match the
kernel and it is tested as a whole.

We will never have a single repo of all sources such as gcc etc like FreeBSD 
has.

> IMHO this rebuild whole OS distro is discussed here, isn't it? If not, I'm 
> sorry
> for noise here...

Ah ok, the discussion is about the how we manage over a long period of time
scripts, tools etc that read and write the spec files in rtems.git. This patch
adds a format option to aid automation via scripting however there is no script
support included so is that left as an exercise for those in the know on how to
do it or should we require support being brought into rtems.git and maintained
along with the file format? If there is no provided scripting support who does
this patch serve or benefit and what value does it bring other than overheads in
maintaining these spec files? [1]

The spec files are close or the same as the YAML spec files rtems-central has
and that repo has scripting support so those working with rtems-central are ok
because that single repo has consistent support. The history and agreement for
the qual effort is these repos remain separated and nothing has changed here.
The rtems.git repo will always take precedence over rtems-central.git.

In relation to a single RTEMS repo it helps make deployment easier for some use
cases and for others it makes no difference. It all depends on how you want to
tool up for deployment but it is not essential. Many repos or a single repo does
not change what is in a release and that is where the project's efforts are 
focused.

Chris

[1] the patch in this thread was pushed while I am still questioning it (hmm)
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] build: Update PyYAML to 5.4.1

[Chris Johns]

On 20/1/2023 1:51 pm, Gedare Bloom wrote:
> On Thu, Jan 19, 2023 at 5:23 PM Chris Johns  wrote:
>>
>> On 20/1/2023 2:19 am, Sebastian Huber wrote:
>>> The latest version is 6.0 which dropped support for Python 2.7.
>>
>> Was 6 our last version to support python 2 and 3?
>>
>> Is making this change this close to a release wise?
>>
> I sense confusion here. Are we referring to Pyyaml 6.0, or RTEMS 6.0?

I assumed it referenced RTEMS 6.

> I understand the comment above to mean we can't update to pyyaml 6.0
> yet, because it doesn't support Python 2.7 which we still require for
> the user-facing tools.

Thanks, that confirms my understanding. So this means it is not OK to apply.

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

Re: [PATCH] build: Update PyYAML to 5.4.1

[Chris Johns]

On 20/1/2023 2:19 am, Sebastian Huber wrote:
> The latest version is 6.0 which dropped support for Python 2.7.

Was 6 our last version to support python 2 and 3?

Is making this change this close to a release wise?

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

Re: [PATCH 1/1] RSB: Mitigate too short error reports

[Chris Johns]

On 20/1/2023 3:13 am, Frank Kühndel wrote:
> Hi Joel,
> 
> On 1/19/23 15:08, Joel Sherrill wrote:
>> Subject:
>> Re: [PATCH 1/1] RSB: Mitigate too short error reports
>> From:
>> Joel Sherrill 
>> Date:
>> 1/19/23, 15:08
>>
>> To:
>> Frank Kühndel 
>> CC:
>> Chris Johns , devel@rtems.org
>>
>>
>> On Thu, Jan 19, 2023 at 6:47 AM Frank Kühndel <
>> frank.kuehn...@embedded-brains.de> wrote:
>>
>>> Hello Chris,
>>> Hello Joel,
>>>
>>> On 1/16/23 18:27, Joel Sherrill wrote:
>>>> Subject:
>>>> Re: [PATCH 1/1] RSB: Mitigate too short error reports
>>>> From:
>>>> Joel Sherrill
>>>> Date:
>>>> 1/16/23, 18:27
>>>>
>>>> To:
>>>> Frank Kühndel
>>>> CC:
>>>> Chris Johns,devel@rtems.org
>>>>
>>>>
>>>> On Mon, Jan 16, 2023 at 8:46 AM Frank Kühndel <
>>>> frank.kuehn...@embedded-brains.de> wrote:
>>>>
>>>>> Hi Chris,
>>>>>
>>>>> On 1/16/23 01:02, Chris Johns wrote:
>>>>>> Subject:
>>>>>> Re: [PATCH 1/1] RSB: Mitigate too short error reports
>>>>>> From:
>>>>>> Chris Johns
>>>>>> Date:
>>>>>> 1/16/23, 01:02
>>>>>>
>>>>>> To:
>>>>>> Frank Kühndel,devel@rtems.org
>>>>>>
>>>>>>
>>>>>> On 22/12/2022 9:09 pm, Frank Kühndel wrote:
>>>>>>> On 12/21/22 00:06, Chris Johns wrote:
>>>>>>>> On 21/12/2022 3:44 am, Frank Kuehndel wrote:
>>>>>>>>> From: Frank Kühndel
>>>>>>>>>
>>>>>>>>> Close #4642
>>>>>>>>> ---
>>>>>>>>>  source-builder/sb/ereport.py | 4 
>>>>>>>>>  1 file changed, 4 insertions(+)
>>>>>>>>>
>>>>>>>>> diff --git a/source-builder/sb/ereport.py
>>>>> b/source-builder/sb/ereport.py
>>>>>>>>> index d8fb5f6..d391917 100755
>>>>>>>>> --- a/source-builder/sb/ereport.py
>>>>>>>>> +++ b/source-builder/sb/ereport.py
>>>>>>>>> @@ -55,6 +55,10 @@ def generate(name, opts, header = None, footer =
>>>>> None):
>>>>>>>>>  with open(name, 'w') as l:
>>>>>>>>>  l.write(os.linesep.join(r))
>>>>>>>>>  log.notice('  See error report: %s' % (name))
>>>>>>>>> +    log.notice('  (Hint: The first error may be in front of
>>>>> a '
>>>>>>>>> +    'line containing\n'
>>>>>>>>> +    '  "Error 1" [GNU make] and may be only in the
>>> whole
>>>>> log '
>>>>>>>> Is this too specific to GNU make? What ifs a package uses cmake or
>>>>> something
>>>>>>>> else?
>>>>>>> As the text indicates, this is specific to GNU make. For those using
>>>>> something
>>>>>>> else reading this text will still hint that the first error may not be
>>>>> in the
>>>>>>> end of the report "and may be only in the whole log".
>>>>>>>
>>>>>>> Another weak point in this text is that by far not all errors
>>>>> originating from
>>>>>>> "make". Yet, the true trouble is the original "See error report: %s"
>>>>> where it
>>>>>>> can sometimes happen that the error is not in this "error report" at
>>>>> all.
>>>>>>> I found it difficult to find a wording which is short, clear and
>>>>> helpful to the
>>>>>>> reader and at the same time not confusing. I am not perfectly happy
>>>>> with the
>>>>>>> notice above. I just found it a reasonable compromise.
>>>>>>>
>>>>>>> If you prefer more generic texts - such as the examples below - I will
>>>>> send a
>>>>>>> new patch with the suggested test.
>>>>>>>
>>>>>>>    "Hint: The first error may be far way from

Re: [PATCH v1 4/4] testsuites/libtest/dl11: Add DL test for TLS

[Chris Johns]

On 20/1/2023 8:40 am, Kinsey Moore wrote:
> On 1/15/2023 6:07 PM, Chris Johns wrote:
>> On 13/1/2023 12:51 pm, Kinsey Moore wrote:
>>> On Thu, Jan 12, 2023 at 5:11 PM Joel Sherrill >> <mailto:j...@rtems.org>> wrote:
>>>
>>>  Will this need to be added as an expected fail on other architectures?
>>>
>>>  Just wondering how many bsp test configuration files need touching
>>>
>>>
>>> I suppose I could set it to enabled for only AArch64 for now. It would
>>> definitely fail on other architectures.
>> Should we enable it for archs we would like supported for 6 and then make 
>> sure
>> we have support for the release?
>>
>> The support is a side effect of the switch to TLS in newlib and not related 
>> to
>> libdl.
>>
> That sounds reasonable. I'll leave it as-is.
> 
> Assuming that's commit approval, I'll open a ticket for the missing support.

Yes and sorry for not making this clear.

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

Re: [PATCH 1/3] build: Format build items

[Chris Johns]

On 20/1/2023 6:01 am, Amar Takhar wrote:
> On 2023-01-19 08:21 +0100, Sebastian Huber wrote:
>>
>> In rtems-central.git there are Python modules and scripts which generate 
>> source, header, and documentation files from specification items. This 
>> repository contains the pre-qualification support for RTEMS. By 
>> accident, a part of the build system uses also specification items. So, 
>> if you want to change the format of the items, you can use the tooling 
>> available in rtems-central.git to do this. An example is the recent 
>> merge of the "default" and "default-by-variant" attributes.
> 
> Why are these in 'rtems-central' and not the RTEMS repository?  Why are we 
> using 
> tools with unpinned versioning generating files in RTEMS?

My view is below.

>> The changes were made by a 10 liner throw away script. I could have done 
>> the changes also manually it would be just more work.
> 
> This does not alter my above point.  I understand that in this case it was a 
> script but the rest wasn't generated by a throw-away script.

It is good to know the amount of python is small. It should be easy to add :)

>> There is nothing to regenerate. The patch set contains simple format 
>> changes and a transformation of attributes.
>>
>> However, your concern is still valid for the generated files, for example
>>
>> https://github.com/RTEMS/rtems/blob/master/cpukit/include/rtems.h
>>
>> which is generated from
>>
>> https://github.com/RTEMS/rtems-central/blob/master/spec/rtems/if/header.yml
> 
> Yes I do not like this at all both the software and header.yml should be 
> sitting 
> in our main repository.

I have been OK with the headers and tests being generated this way because the
agreement is files in rtems.git can be manually edited and rtems-central has to
track those changes. The sources and code to generate the files need to be
located together.

>> Most of the Classic API header files are generated from specification 
>> items. If nobody takes care that rtems-central.git is used and stays up 
>> to date the specification will get out of synchronization with rtems.git.
> 
> Okay but why is this sitting in rtems-central.git and not in rtems.git.  
> You've 
> just made the argument that it's very important we don't want anything to be 
> out 
> of sync.

The specification maintenance is a separate responsibility to the function and
role of rtems.git and related repos. The bar to make changes in rtems.git is at
the source level because it is the norm for open source projects and those
working with the code. The separation also helps make it clear how funding of
the qual related work happens. If we bring those specifications items down into
rtems.git the responsibility moves to that repo and that raises the bar on being
able to make a change. Our view on this may change as we learn now the pre-qual
effort effects what we do.

We have YAML files to run our build system and it is awesome. It also allows
automation so I think it makes sense to provide an interface to read and write
these files to aid automation rather than a disjointed set of personal scripts,
tools etc that may break or clash.

>>> I'm not against the purpose of the tool or the work has been done but this 
>>> is
>>> not the correct way to handle generated files within a repository if we 
>>> want to
>>> maintain the ability to make changes or debug years down the line.
>>
>> I would use a single repository for RTEMS just like the FreeBSD base 
>> system, but this is another discussion.
> 
> FreeBSD also uses a vendor system which brings all this code under a central 
> repository.  They aren't maintaining code outside and then requiring FreeBSD 
> to 
> be built with it.  They even bring the compiler in this has an astounding 
> impact 
> on the usability of FreeBSD.
> 
> Recently I took a FreeBSD 3.1 image and rebuilt it for a customer who needed 
> a 
> change it was used in an appliance.  It just worked.
> 
> If I want to make a chance to rtems.h it's now generated from a header.yml 
> with 
> no version pinning how am I going to find the first header.yml to make a 
> single 
> change in 20 years?
> 
> rtems.h is a small file where we can get rid of it and move to another tool.  
> It's integral and anything that works with it is integral this is arguably 
> different.

The FreeBSD single repo is about the kernel and base runtime. The ports are not
part of this so the analogy breaks down. Bringing the RSB, RTEMS tools and
documentation into a single repo creates new complexities I am not sure we are
prepared enough to handle those. Maybe patch review and CI would help here and
how they effect a single repo is something I have not given much consideration 
too.

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

Re: [PATCH 2/3] build: Replace variant patterns with a list

[Chris Johns]

On 19/1/2023 6:06 pm, Sebastian Huber wrote:
> On 19.01.23 01:17, Chris Johns wrote:
>>>> Why has this been done?
>>> The enabled-by expressions used in patch 3 do not support regular 
>>> expressions.
>> I did not pick that up. Why was that regx functionality removed? Is it 
>> related
>> to scripting and rtems-central?
> 
> The enabled-by expressions supported by the wscript don't support regular
> expressions:
> 
> https://github.com/RTEMS/rtems/blob/master/wscript#L144
> 
> The interesting part of the patch set is patch 3:
> 
> Merge the "default" and "default-by-variant" attributes.  Use an
> "enabled-by" expression to select the default value based on the enabled
> set.  This makes it possible to select default values depending on other
> options.  For example you could choose memory settings based on whether
> RTEMS_SMP is enabled or disabled.

Thanks, this make sense. I had not made the connections.

>>>> Why the noise in the patch of only lines being moved? Where has this come 
>>>> from?
>>>> Is there a new requirement spec fields be in some osrt of order?
>>> I did the change with a script which sorted the lists. In general, the lists
>>> should be sorted.
>> This is a good example of problems a lack of scripting support along side the
>> build spec files creates. It makes manual changes difficult when rules get
>> layered like this plus it means you are the only one who can make generated
>> changes without there being a clash of scripting specifics, ie my script vs 
>> your
>> script or something like that.
> 
> I don't understand what is the problem with the sorted lists. If you have a 
> list
> of unordered phrases, it is not unusual to still sort them in lexicographic 
> order.

I welcome sorted entries. Manual edits may or may not be sorted so we end up
with a mix and when a "magic" script runs again it generates more of these white
space changes. If I can run:

./waf formatspec

the "magic" happens it is easy to document and for any user to update these
files, run a command and know the results are OK to post. It is no different to
the work Gedare is doing to get the code formatting sorted so none us have to
audit formatting of the code.

So let me turn this around ... I am do not understand your resistance to there
being importable modules of python in rtems.git to read and write these files in
rtems.git?

>> And I have no intention in cloning rtems-central and learning how to use it.
>> There was a primary agreement for the separation of all qual work and the
>> ability for it to be removed from the project without any side effects.
> 
> You don't have to use the stuff in rtems-central, it could be just more
> convenient and efficient. It would be possible to write a Github action which
> checks that the build items match the expected format for pull requests.

Lets not bring more github stuff into our workflows. There is no agreement that
github is what this project wants to use. I am OK with automation if it is
something we can manage.

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

Re: Proposal for an "Age" PostgreSQL ORM function

[Jason Johns]

the AGE function takes in two timestamps and returns an interval.  You can 
do this in python by subtracting two date/datetime objects and getting a 
timedelta.  what would the difference be to kick this out to the db?
On Tuesday, January 17, 2023 at 11:11:37 AM UTC-5 niccol...@gmail.com wrote:

> How would you see adding the "AGE" function to the current set of 
> PostgreSQL ORM functions?
>

-- 
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/17148207-2d4e-4163-86ce-0691e14ab7fan%40googlegroups.com.

Re: [PATCH 2/3] build: Replace variant patterns with a list

[Chris Johns]

On 18/1/2023 6:00 pm, Sebastian Huber wrote:
> On 18.01.23 04:59, Chris Johns wrote:
>> Hi Sebastian,
>>
>> I had not got to this part of the patch set because the other was being
>> discussed. I thought a patch set was considerd as a whole rather than having 
>> to
>> deal with the extra complexity of possible splits and if they exist? If this 
>> was
>> pull request or merge request in a tool none of this patch set would have 
>> been
>> applied unless split into separate merge reguests. :)
> 
> Sorry, I thought you were already finished with the patch set. Maybe we should
> move the patch review to pull requests.

I am still buried after being away and no I was not finsihed. I am sorry for the
confusion.

>> Why has this been done?
> 
> The enabled-by expressions used in patch 3 do not support regular expressions.

I did not pick that up. Why was that regx functionality removed? Is it related
to scripting and rtems-central?

>> Why the noise in the patch of only lines being moved? Where has this come 
>> from?
>> Is there a new requirement spec fields be in some osrt of order?
> 
> I did the change with a script which sorted the lists. In general, the lists
> should be sorted.

This is a good example of problems a lack of scripting support along side the
build spec files creates. It makes manual changes difficult when rules get
layered like this plus it means you are the only one who can make generated
changes without there being a clash of scripting specifics, ie my script vs your
script or something like that.

And I have no intention in cloning rtems-central and learning how to use it.
There was a primary agreement for the separation of all qual work and the
ability for it to be removed from the project without any side effects.

Chris

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

Re: [PATCH 1/3] build: Format build items

[Chris Johns]

On 19/1/2023 8:58 am, Amar Takhar wrote:
> On 2023-01-17 08:39 +0100, Sebastian Huber wrote:
> 
>>
>> The Python modules to work with specification items are in 
>> rtems-central.git. This repository contains also a format specification 
>> of the build items. We could add an action to a Github work flow to 
>> check the build item format for pull requests and commits.
> 
> I don't chime in here very often but after seeing the recent changes I'm 
> extremely confused.
> 
> There are now tools that sit outside of the RTEMS repository that now change 
> source files in RTEMS?
> 
> I have never seen it done this way before.  What version of this tool have 
> you 
> used?  How can anyone in the future possibly debug this?
> 
> What should happen here is this tools should sit in the main repository.  Any 
> required changes made and then a command run to generate new output:
> 
>   ./waf 
> 
> This lets us know that the output in this commit was generated by code 
> existing 
> in the previous commit.  There is no need to version anything it's already 
> done.
> 
> Having it sitting outside of the source repository makes debugging 
> impossible.  
> Case in point is the commit message here.  No explanation as to where these 
> changes have come from.  No commit version.  I spent a very long time 
> figuring 
> out what was going on and I could not figure it out without digging through 
> the 
> lists.
> 
> How is anyone in 5, 10, 15 years down the road going to sort through this?  
> What 
> if I want to make a change in 10 years and regenerate.  It is impossible as I 
> have no idea what's been done let alone where to look.
> 
> I'm not against the purpose of the tool or the work has been done but this is 
> not the correct way to handle generated files within a repository if we want 
> to 
> maintain the ability to make changes or debug years down the line.

Yes these are good points. The rtems-central repo is not a requirement for
rtems.git and never will be. The separation was agreed to before any qual work
started. The rtems.git repo can exist and operate without rtems-central however
the rtems-central repo is meaningless without rtems.git so Amar I agree the
dependency is the wrong way around.

I have agreed to generated content for headers, some tests, and documentation
because the generator input is in rtems-central so the effort to maintain that
rtems-central data with any manual changes in rtems.git etc is part of the
overhead of maintaining rtems-central. The build spec files are in rtems.git and
this relationship is very different.

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

Re: [PATCH 2/3] build: Replace variant patterns with a list

[Chris Johns]

Hi Sebastian,

I had not got to this part of the patch set because the other was being
discussed. I thought a patch set was considerd as a whole rather than having to
deal with the extra complexity of possible splits and if they exist? If this was
pull request or merge request in a tool none of this patch set would have been
applied unless split into separate merge reguests. :)

Why has this been done?

Why the noise in the patch of only lines being moved? Where has this come from?
Is there a new requirement spec fields be in some osrt of order?

Thanks
Chris

On 12/1/2023 11:03 pm, Sebastian Huber wrote:
> Replace the variant patterns in the default-by-variant list with an
> explicit list of matching BSPs.
> 
> The change was tested by comparing the output of
> 
>   ./waf bspdefaults
> 
> before and after the change.


The change message does not explain the line movements.

Chris

> ---
>  .../bsps/aarch64/xilinx-zynqmp/optclki2c0.yml |  8 +++
>  .../bsps/aarch64/xilinx-zynqmp/optclki2c1.yml |  8 +++
>  .../bsps/aarch64/xilinx-zynqmp/optclkuart.yml |  7 +--
>  .../bsps/aarch64/xilinx-zynqmp/optloadoff.yml |  2 +-
>  .../bsps/aarch64/xilinx-zynqmp/optramori.yml  |  2 +-
>  .../arm/altera-cyclone-v/optclkfastidle.yml   |  4 +++-
>  spec/build/bsps/arm/beagle/optam335x.yml  |  3 ++-
>  spec/build/bsps/arm/beagle/optdebug.yml   |  3 ++-
>  spec/build/bsps/arm/beagle/optdm3730.yml  |  3 ++-
>  spec/build/bsps/arm/imx/optcachedata.yml  |  4 +++-
>  spec/build/bsps/arm/imx/optcacheinst.yml  |  4 +++-
>  spec/build/bsps/arm/lm3s69xx/optgpioahb.yml   |  4 ++--
>  spec/build/bsps/arm/lm3s69xx/optgpionum.yml   |  7 ---
>  spec/build/bsps/arm/lm3s69xx/optlm3s3749.yml  |  2 +-
>  spec/build/bsps/arm/lm3s69xx/optlm3s6965.yml  |  3 ++-
>  spec/build/bsps/arm/lm3s69xx/optlm4f120.yml   |  2 +-
>  spec/build/bsps/arm/lm3s69xx/optssiblks.yml   |  7 ---
>  spec/build/bsps/arm/lm3s69xx/optsysclk.yml|  6 --
>  spec/build/bsps/arm/lm3s69xx/optudma.yml  |  4 ++--
>  spec/build/bsps/arm/lm3s69xx/optxtalcfg.yml   |  7 ---
>  spec/build/bsps/arm/lpc24xx/optcclk.yml   | 12 +++
>  spec/build/bsps/arm/lpc24xx/optdmachn.yml | 11 --
>  spec/build/bsps/arm/lpc24xx/optemcclkdiv.yml  |  6 --
>  .../bsps/arm/lpc24xx/optemcis42s32800b.yml|  4 ++--
>  .../bsps/arm/lpc24xx/optemcis42s32800d7.yml   |  3 ++-
>  .../build/bsps/arm/lpc24xx/optemcm29w160e.yml |  3 ++-
>  .../bsps/arm/lpc24xx/optemcm29w320e70.yml |  3 ++-
>  .../bsps/arm/lpc24xx/optemcmt48lc4m16a2.yml   |  3 ++-
>  spec/build/bsps/arm/lpc24xx/optethrmii.yml|  5 -
>  spec/build/bsps/arm/lpc24xx/optheapext.yml|  3 ++-
>  spec/build/bsps/arm/lpc24xx/optoscmain.yml|  3 ++-
>  spec/build/bsps/arm/lpc24xx/optotgi2c.yml |  6 --
>  spec/build/bsps/arm/lpc24xx/optpclkdiv.yml|  6 --
>  spec/build/bsps/arm/lpc24xx/optstopeth.yml|  3 ++-
>  spec/build/bsps/arm/lpc24xx/optstopusb.yml|  3 ++-
>  spec/build/bsps/arm/lpc24xx/optuart1cfg.yml   |  5 -
>  spec/build/bsps/arm/lpc24xx/optuart2cfg.yml   | 12 ---
>  spec/build/bsps/arm/lpc24xx/optuart3cfg.yml   |  7 +--
>  spec/build/bsps/arm/lpc32xx/optotgi2c.yml |  4 +++-
>  spec/build/bsps/arm/lpc32xx/optotgvbus.yml|  4 +++-
>  spec/build/bsps/arm/lpc32xx/optscratchsz.yml  |  4 +++-
>  .../bsps/arm/realview-pbx-a9/optcachedata.yml |  4 +++-
>  .../bsps/arm/realview-pbx-a9/optcacheinst.yml |  4 +++-
>  .../arm/realview-pbx-a9/optclkbootcpu.yml |  4 +++-
>  .../arm/realview-pbx-a9/optclkfastidle.yml|  4 +++-
>  spec/build/bsps/arm/stm32f4/opteni2c1.yml |  2 +-
>  spec/build/bsps/arm/stm32f4/optf10xxx.yml |  2 +-
>  spec/build/bsps/arm/stm32f4/optf4.yml |  2 +-
>  spec/build/bsps/arm/stm32f4/opthclk.yml   |  2 +-
>  spec/build/bsps/arm/stm32f4/optpclk1.yml  |  2 +-
>  spec/build/bsps/arm/stm32f4/optpclk2.yml  |  2 +-
>  spec/build/bsps/arm/stm32f4/optsysclk.yml |  2 +-
>  spec/build/bsps/arm/stm32h7/abi.yml   |  2 +-
>  spec/build/bsps/arm/stm32h7/optbootcore.yml   |  4 ++--
>  spec/build/bsps/arm/stm32h7/optenuart4.yml|  4 ++--
>  spec/build/bsps/arm/stm32h7/optenuart5.yml|  6 +++---
>  spec/build/bsps/arm/stm32h7/optenuart7.yml|  6 +++---
>  spec/build/bsps/arm/stm32h7/optenuart8.yml|  2 +-
>  spec/build/bsps/arm/stm32h7/optenuart9.yml|  6 +++---
>  spec/build/bsps/arm/stm32h7/optenusart10.yml  |  6 +++---
>  spec/build/bsps/arm/stm32h7/optenusart3.yml   |  6 +++---
>  spec/build/bsps/arm/stm32h7/optenusart6.yml   |  6 +++---
>  spec/build/bsps/arm/stm32h7/optlinkcmds.yml   |  8 +++
>  .../bsps/arm/stm32h7/optmemflashorigin.yml|  2 +-
>  spec/build/bsps/arm/stm32h7/optmemflashsz.yml |  2 +-
>  .../build/bsps/arm/stm32h7/optmemsdram1sz.yml |  8 +++
>  .../build/bsps/arm/stm32h7/optmemsdram2sz.yml |  4 ++--
>  spec/build/bsps/arm/stm32h7/optpwrsupply.yml  |  6 +++---
>  .../arm/stm32h7/optusart1alternatefunc.yml|  2 

Re: [PATCH 1/3] build: Format build items

[Chris Johns]

On 17/1/2023 6:39 pm, Sebastian Huber wrote:
> On 17.01.23 03:48, Chris Johns wrote:
>> On 16/1/2023 6:56 pm, Sebastian Huber wrote:
>>> On 16.01.23 01:35, Chris Johns wrote:
>>>> On 13/1/2023 1:54 am, Sebastian Huber wrote:
>>>>> On 12.01.23 15:44, Kinsey Moore wrote:
>>>>>> The other two patches look fine to me. The use of dump() that results in 
>>>>>> this
>>>>>> patch does several things:
>>>>>> * Removal of whitespace
>>>>>> This is fine for whitespace at the base level of indentation. Whitespace
>>>>>> within an indented block may be more important for readability.
>>>>>>
>>>>>> * Removal of comments
>>>>>> This is not good as they are exclusively used to annotate manually 
>>>>>> ordered
>>>>>> blocks of test result expectations
>>>>>>
>>>>>> * Rearrangement of items in alphabetical order
>>>>>> In general, rearrangement of top-level sections is good. For indented
>>>>>> sections
>>>>>> specifically in tst*.yml, this is bad for the above reaso
>>>>> One goal of the new build system was to be able to alter the data through
>>>>> scripts. This requires that the build items are human and machine 
>>>>> readable and
>>>>> writable. The Python YAML import/export does not preserve white space and
>>>>> comments.
>>>> Can someone edit the file and add a hex number?
>>>
>>> Yes, you can manually use whatever format is understood by the YAML loader. 
>>> When
>>> you write the file with the YAML dumper, then the standard representation is
>>> used.
>>
>> Are there python modules in rtems.git someone could import that reads and 
>> writes
>> the YAML spec files? If not should we provide a module to do this? It could 
>> be
>> `spec` so a user can use `import spec` after setting the import path.
>>
>> That is, if external scripts (and I encourage this) all used a common read 
>> and
>> write type functionality the format consistency is relative to specific 
>> version
>> of rtems.git being used. Updates become read then write.
> 
> The Python modules to work with specification items are in rtems-central.git.
> This repository contains also a format specification of the build items.

And how does that help here with this repo? I suggest you reconsider the
accessibility of those modules before pushing scripted generation changes like
this into rtems.git.

> We
> could add an action to a Github work flow to check the build item format for
> pull requests and commits.

Thanks for including github in this thread. It has now confirmed my position of
no github automations in our repos (including rtems-central).

>>> I changed the representer to use the format attribute, see v2 of the patch:
>>>
>>> https://lists.rtems.org/pipermail/devel/2023-January/074094.html
>>>
>>
>> I see and thanks. How many format strings would cover the majority of 
>> formats we
>> have?
>>
>> I am wondering if `format:` is checked against a standard list and those are
>> part of the "writer" support? For example `address`, `address32`, `hex64` 
>> etc? I
>> am concerned about repeated common format strings being placed through all 
>> the
>> spec files.
> 
> The format string is a standard Python format string. This is easy to 
> implement
> and flexible. We could replace this with a fixed set of formats.

Maybe if you have scripting support which this repo does not. I think the
formats should be controlled however I see the whole discussion and patch as
academic until rtems.git has scripting support in python modules.

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

Re: Typo in rtems-libbsd/rtems_waf/rtems.py?

[Chris Johns]

On 18/1/2023 7:17 am, Heinz Junkes wrote:
> ok with
>  ./waf bspdefaults --rtems-bsps=powerpc/beatnik … it works 
> 
> I had ./waf bsp_defaults :-(

Ah

> rtems@rtems-dev:~/MVME6100_6_RUN/rtems/6/share$ ls -l
> total 36
> drwxr-xr-x 3 rtems rtems 4096 Jan 17 17:09 doc
> drwxr-xr-x 3 rtems rtems 4096 Jan 17 17:42 gcc-12.2.1
> drwxr-xr-x 5 rtems rtems 4096 Jan 17 17:44 gdb
> drwxr-xr-x 2 rtems rtems 4096 Jan 17 17:44 iconv_data
> drwxr-xr-x 2 rtems rtems 4096 Jan 17 17:44 info
> drwxr-xr-x 2 rtems rtems 4096 Jan 17 17:13 locale
> drwxr-xr-x 5 rtems rtems 4096 Jan 17 17:42 man
> drwxr-xr-x 9 rtems rtems 4096 Jan 17 17:44 rtems
> drwxr-xr-x 3 rtems rtems 4096 Jan 17 21:15 rtems6
> 

Nice and thanks for letting us know.

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

Re: Typo in rtems-libbsd/rtems_waf/rtems.py?

[Chris Johns]

On 18/1/2023 6:16 am, Frank Kühndel wrote:
> have you installed RTEMS (not only the tools) in `${RTEMS_ROOT}` before
> configuring libbsd? If I am not mistaken, installing RTEMS creates the
> `share/rtems6` directory.

This is correct and it is a simple and fast key to see if a kernel of a specific
version has been installed.

> On 1/17/23 18:11, Heinz Junkes wrote:
>> Hi,
>>
>> It looks like there is a typo in rtems-libbsd/rtems_waf/rtems.py.
>>
>> rtems_share_rtems_version = os.path.join(rtems_path, 'share', 'rtems' +
>> rtems_version)
>> if not os.path.exists(os.path.join(rtems_share_rtems_version)):
>>  ctx.fatal('RTEMS path is not valid, "%s" not found.' %
>> (rtems_share_rtems_version))
>>
>> I think that "+ rtems_version" does not belong there?
>>
>> git clonehttps://github.com/RTEMS/rtems-libbsd.git
>> cd rtems-libbsd/
>> git checkout 6-freebsd-12
>> git submodule init
>> git submodule update rtems_waf
>>
>> ./waf configure --prefix=${RTEMS_ROOT} --rtems-bsps=powerpc/beatnik
>> --buildset=buildset/default.ini

As Frank points put the kernel needs to be installed before this command is run.

Chris

>>
>> leads to :
>>
>> # project  configured on Tue Jan 17 17:46:09 2023 by
>> # waf 2.0.19 (abi 20, python 20710f0 on linux2)
>> # using ./waf configure --prefix=/home/rtems/MVME6100_6_RUN/rtems/6
>> --rtems-bsps=powerpc/beatnik --buildset=buildset/default.ini
>> #
>> 
>> Setting top to
>> /home/rtems/MVME6100_6_INST/rtems-libbsd
>> 
>> Setting out to
>> /home/rtems/MVME6100_6_INST/rtems-libbsd/build
>> from /home/rtems/MVME6100_6_INST/rtems-libbsd: RTEMS path is not valid,
>> "/home/rtems/MVME6100_6_RUN/rtems/6/share/rtems6" not found.
>>
>>
>> Heinz
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/3] build: Format build items

[Chris Johns]

On 16/1/2023 6:56 pm, Sebastian Huber wrote:
> On 16.01.23 01:35, Chris Johns wrote:
>> On 13/1/2023 1:54 am, Sebastian Huber wrote:
>>> On 12.01.23 15:44, Kinsey Moore wrote:
>>>> The other two patches look fine to me. The use of dump() that results in 
>>>> this
>>>> patch does several things:
>>>> * Removal of whitespace
>>>> This is fine for whitespace at the base level of indentation. Whitespace
>>>> within an indented block may be more important for readability.
>>>>
>>>> * Removal of comments
>>>> This is not good as they are exclusively used to annotate manually ordered
>>>> blocks of test result expectations
>>>>
>>>> * Rearrangement of items in alphabetical order
>>>> In general, rearrangement of top-level sections is good. For indented 
>>>> sections
>>>> specifically in tst*.yml, this is bad for the above reaso
>>> One goal of the new build system was to be able to alter the data through
>>> scripts. This requires that the build items are human and machine readable 
>>> and
>>> writable. The Python YAML import/export does not preserve white space and
>>> comments.
>> Can someone edit the file and add a hex number?
> 
> Yes, you can manually use whatever format is understood by the YAML loader. 
> When
> you write the file with the YAML dumper, then the standard representation is
> used.

Are there python modules in rtems.git someone could import that reads and writes
the YAML spec files? If not should we provide a module to do this? It could be
`spec` so a user can use `import spec` after setting the import path.

That is, if external scripts (and I encourage this) all used a common read and
write type functionality the format consistency is relative to specific version
of rtems.git being used. Updates become read then write.

> I changed the representer to use the format attribute, see v2 of the patch:
> 
> https://lists.rtems.org/pipermail/devel/2023-January/074094.html
> 

I see and thanks. How many format strings would cover the majority of formats we
have?

I am wondering if `format:` is checked against a standard list and those are
part of the "writer" support? For example `address`, `address32`, `hex64` etc? I
am concerned about repeated common format strings being placed through all the
spec files.

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

Re: [PATCH 1/3] build: Format build items

[Chris Johns]

On 13/1/2023 1:54 am, Sebastian Huber wrote:
> On 12.01.23 15:44, Kinsey Moore wrote:
>> The other two patches look fine to me. The use of dump() that results in this
>> patch does several things:
>> * Removal of whitespace
>> This is fine for whitespace at the base level of indentation. Whitespace
>> within an indented block may be more important for readability.
>>
>> * Removal of comments
>> This is not good as they are exclusively used to annotate manually ordered
>> blocks of test result expectations
>>
>> * Rearrangement of items in alphabetical order
>> In general, rearrangement of top-level sections is good. For indented 
>> sections
>> specifically in tst*.yml, this is bad for the above reaso
> One goal of the new build system was to be able to alter the data through
> scripts. This requires that the build items are human and machine readable and
> writable. The Python YAML import/export does not preserve white space and 
> comments.

Can someone edit the file and add a hex number?

> This there is a need for comments, then the data format should be improved. 
> For
> example, the test state list could be changed to also include a reason for a
> categorization.
> 
>>
>> * Alteration of integer representation to base-10 in all cases
>> I'd say this is a net-negative as most items represented in hex are
>> memory-related and should stay that way.
> 
> Yes, this is a bit annoying. To mitigate this issue the options have a format
> attribute so that the numbers are correctly formatted in user visible content,
> for example the configuration files or generated header and linker command
> files. The build item maintainer has to use a calculator or whatever to look 
> at
> the numbers in the right format.

I cannot see an example of a format attribute? Do the patches contain an 
example?

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

Re: [PATCH rtems-tools] linkers/rtems-syms: Generate TLS symbols

[Chris Johns]

OK

Thanks
Chris

On 13/1/2023 8:12 am, Kinsey Moore wrote:
> When generating the symbol table for loadable modules, include TLS
> symbols so that the modules can reference them.
> ---
>  linkers/rtems-syms.cpp   | 5 +
>  rtemstoolkit/rld-elf.cpp | 1 +
>  rtemstoolkit/rld-symbols.cpp | 3 +++
>  3 files changed, 9 insertions(+)
> 
> diff --git a/linkers/rtems-syms.cpp b/linkers/rtems-syms.cpp
> index 5aa4d27..e5170e1 100644
> --- a/linkers/rtems-syms.cpp
> +++ b/linkers/rtems-syms.cpp
> @@ -242,6 +242,11 @@ output_sym::operator ()(const 
> rld::symbols::symtab::value_type& value)
>  
>c.write_line ("asm(\"  .asciz \\\"" + sym.name () + "\\\"\");");
>  
> +  if (sym.type() == STT_TLS)
> +  {
> +c.write_line ("asm(\"  .type \\\"" + sym.name () + "\\\", 
> %tls_object\");");
> +  }
> +
>if (embed)
>{
>  c.write_line ("#if __SIZEOF_POINTER__ == 8");
> diff --git a/rtemstoolkit/rld-elf.cpp b/rtemstoolkit/rld-elf.cpp
> index ffa3376..68efdbe 100644
> --- a/rtemstoolkit/rld-elf.cpp
> +++ b/rtemstoolkit/rld-elf.cpp
> @@ -891,6 +891,7 @@ namespace rld
>  {
>if (((stype == STT_NOTYPE) ||
> (stype == STT_OBJECT) ||
> +   (stype == STT_TLS) ||
> (stype == STT_FUNC)) &&
>((weak && (sbind == STB_WEAK)) ||
> (!unresolved && ((local && (sbind == STB_LOCAL)) ||
> diff --git a/rtemstoolkit/rld-symbols.cpp b/rtemstoolkit/rld-symbols.cpp
> index 661b598..01291c0 100644
> --- a/rtemstoolkit/rld-symbols.cpp
> +++ b/rtemstoolkit/rld-symbols.cpp
> @@ -277,6 +277,9 @@ namespace rld
>  case STT_FILE:
>type = "STT_FILE   ";
>break;
> +case STT_TLS:
> +  type = "STT_TLS";
> +  break;
>  default:
>if ((type_val >= STT_LOPROC) && (type_val <= STT_HIPROC))
>  type = "STT_LOPROC(" + rld::to_string (type_val) + ")";
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v1 4/4] testsuites/libtest/dl11: Add DL test for TLS

[Chris Johns]

On 13/1/2023 12:51 pm, Kinsey Moore wrote:
> On Thu, Jan 12, 2023 at 5:11 PM Joel Sherrill  > wrote:
> 
> Will this need to be added as an expected fail on other architectures? 
> 
> Just wondering how many bsp test configuration files need touching 
> 
> 
> I suppose I could set it to enabled for only AArch64 for now. It would
> definitely fail on other architectures.

Should we enable it for archs we would like supported for 6 and then make sure
we have support for the release?

The support is a side effect of the switch to TLS in newlib and not related to
libdl.

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

Re: [PATCH 1/1] RSB: Mitigate too short error reports

[Chris Johns]

On 22/12/2022 9:09 pm, Frank Kühndel wrote:
> On 12/21/22 00:06, Chris Johns wrote:
>> On 21/12/2022 3:44 am, Frank Kuehndel wrote:
>>> From: Frank Kühndel
>>>
>>> Close #4642
>>> ---
>>>   source-builder/sb/ereport.py | 4 
>>>   1 file changed, 4 insertions(+)
>>>
>>> diff --git a/source-builder/sb/ereport.py b/source-builder/sb/ereport.py
>>> index d8fb5f6..d391917 100755
>>> --- a/source-builder/sb/ereport.py
>>> +++ b/source-builder/sb/ereport.py
>>> @@ -55,6 +55,10 @@ def generate(name, opts, header = None, footer = None):
>>>   with open(name, 'w') as l:
>>>   l.write(os.linesep.join(r))
>>>   log.notice('  See error report: %s' % (name))
>>> +    log.notice('  (Hint: The first error may be in front of a '
>>> +    'line containing\n'
>>> +    '  "Error 1" [GNU make] and may be only in the whole log '
>> Is this too specific to GNU make? What ifs a package uses cmake or something
>> else?
> 
> As the text indicates, this is specific to GNU make. For those using something
> else reading this text will still hint that the first error may not be in the
> end of the report "and may be only in the whole log".
> 
> Another weak point in this text is that by far not all errors originating from
> "make". Yet, the true trouble is the original "See error report: %s" where it
> can sometimes happen that the error is not in this "error report" at all.
> 
> I found it difficult to find a wording which is short, clear and helpful to 
> the
> reader and at the same time not confusing. I am not perfectly happy with the
> notice above. I just found it a reasonable compromise.
> 
> If you prefer more generic texts - such as the examples below - I will send a
> new patch with the suggested test.
> 
>     "Hint: The first error may be far way from the end of the
>     report and in cases can only be found in the whole build log."
> 
>     "Hint: The error is most likely in the error report otherwise
>     see the whole build log [--log option]."
> 
> If you find any such change might cause more confusion than it might be 
> helpful,
> I think it better to close this bug than to try to fix it.
> 

I think all you have written is valid and I have found the wording difficult.
There will never be a robust error message scanner or a simple full proof way to
find errors. The parallel builds makes tracking the errors difficult and the
point of error and end of the build a long distance apart.

As a result I question the value of the report and wonder if it should be
removed. The report adds overhead to the build as the logging process needs to
maintain a buffer of lines that is always updating. Your attention and interest
around this feature highlights how problematic it is so maybe it is simpler and
better to remove it and we leave users to find the error in the log file.

I am happy to accept the report has not worked as a feature, remove it and in
the process we recover some overheads in the logging area of the RSB?

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

Re: [RBW] bottom bracket toubleshooting trivia

[JohnS]

Hello Scott,

Is there a screw for the under bottom bracket cable guide? It could be a 
tad long and interfering with the bottom bracket. I would recommend backing 
it out and if that helps adding a washer to the screw or replacing with a 
slightly shorter one. I've had some difficulties with bottom bracket 
installs in the past due to the cable guide screw being too long.

Hope it helps,
JohnS

On Sunday, January 15, 2023 at 1:52:56 PM UTC-5 Scott wrote:

> Edit correction to my post, please.
>
> Second sentence of third paragraph of original post should read:
>
> When I turn the spindle by hand it is not smooth (definitely some 
> resistance and a tad sticky)*, unlike* the one I installed in Atlantis or 
> an uninstalled on.
>
>
>
> On Sunday, January 15, 2023 at 11:44:35 AM MST, 'Scott' via RBW Owners 
> Bunch  wrote: 
>
>
> Hey, Bunch:
>
> Pinging the group's knowledge for input/feedback on an issue I'm having 
> with an install of a new cartridge style BB in a new frame.
>
> I'm building a new Atlantis and Gus. I installed a new BB (Shimano XTR 
> UN91) in Atlantis and torqued to spec. It's butterlicious smooth. Installed 
> cranks and gave them a spin. It's what every man, woman, and child wants. 
>
> I installed same BB (also new) in Gus and tightened to spec. When I turn 
> the spindle by hand it is not smooth (definitely some resistance and a tad 
> sticky) like the one I installed in Atlantis or an uninstalled one. Why is 
> that? I checked it before install, and it was butter smooth. I uninstalled 
> it from Gus, and it spins butter smooth. I reinstalled main body section to 
> spec, and it is butter smooth, no change. When I install the opposing cup 
> (Shimano calls it an adapter), at this point is when I begin to notice a 
> notable change in spindle rotation smoothness.
>
> I've ensured proper shell widths. And I've ensured shell/cartridge faces 
> are clean and blemish-free.
>
> Of note, opposing cup spins freely during install for about one third the 
> way to full seat. From there it spins freely part of rotation and not 
> freely otherwise. I can turn it by hand still using splined-tool, but there 
> is definitely resistance during part of the rotation. After I can't go any 
> further by hand, I fully seat with torque wrench.
>
> Could it be that the threads on either side of the shell are not exactly 
> coplanar, since threads are not continuous from one side of shell to the 
> other?
> It shouldn't be a shell facing issue, because the opposing cup doesn't 
> interface with shell face.
>
> Confounding to me. There isn't much to installing a new cartridge style BB 
> into a new frame...screw it in. That's the problem, in part. There's 
> nothing to correct with install technique. I'd love to be wrong and get it 
> butter smooth like one in my Atlantis, for example.
>
> Please, share your thoughts as to what the source of issue may be and 
> recommended remedy!
>
> Scott in (I want it to be spring, summer, and fall) Montana
>
>
>
>
> -- 
> You received this message because you are subscribed to a topic in the 
> Google Groups "RBW Owners Bunch" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/rbw-owners-bunch/7Uu5LBGsfxQ/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to 
> rbw-owners-bun...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/rbw-owners-bunch/db5d0a09-b8cd-4433-9ffc-cce5be97fd4fn%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/rbw-owners-bunch/db5d0a09-b8cd-4433-9ffc-cce5be97fd4fn%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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/fc9a7577-53ca-4b2f-80a1-75d7b7d1aa41n%40googlegroups.com.

Re: [RBW] Which Paul brakes for a Quickbeam or Simple One?

[JohnS]

Thank you Marty for sharing. I'm about to go out and get some orange touch 
up paint for my Quickbeam now. The touring brakes came yesterday and the 
mini-motos should be here later in the week.

JohnS


On Sunday, January 15, 2023 at 11:34:06 AM UTC-5 Marty Gierke, Stewartstown 
PA wrote:

> Ten years ago I had a QB set up  "ALL PAUL" style; brakes 
> (neo-retro/touring), levers, Moon Units, hubs, crankset, seatpost, and even 
> the rack they made for a short time. Wonderful build and fun to ride. Might 
> be fun to do something similar when the RoadUno shows up. 
>
> [image: 7190356252_e623d4ae9f_c.jpg]
>
> Grabbed this shot at a bookstore in the Chicago burbs when Grant was doing 
> his Just Ride book tour and I stopped by. 
>
> [image: 8016747421_ba760b696c_c.jpg]
>
> Marty
>
> On Saturday, January 14, 2023 at 6:58:41 PM UTC-5 Patrick Moore wrote:
>
>> Thanks; come to think of it, I had a pair of these as well but found them 
>> too cramped. The CC or Tektros were more comfortable but are made from a 
>> lot of plastic.
>>
>> I think I'll stick to my old Dura Ace levers and Paul cantis.
>>
>> On Fri, Jan 13, 2023 at 5:23 PM iamkeith  wrote:
>>
>>>
>>> DIa Compe 287V still seems to be readily available.
>>> On Friday, January 13, 2023 at 5:15:26 PM UTC-7 Patrick Moore wrote:
>>>
>>>> To fully clean and purge all residual nuances for this discussion of 
>>>> the bestPaul brakes for one's bike: Question: What are the several options 
>>>> for long-pull road levers? Long ago it was Tektro and Cane Creek long-pull 
>>>> road levers, and I used both, but that was circa 2012 when I first built 
>>>> my 
>>>> first edition Fargo. Have any other long pull drop bar levers appeared in 
>>>> the last decade? Context: I'd really love to use V brakes on my 2020 
>>>> Matthews, but I would hate to give up my 7410-era DA levers. So I wonder 
>>>> if 
>>>> anyone makes long-pull drop bar levers more like the DAs and less like the 
>>>> CC and Tektros -- which I think were the same brake under different logos? 
>>>> Don't want Travel Agents or similar.
>>>>
>>>> I expect that in 2023 we have the same options, CC and Tektro, only.
>>>>
>>> -- 
>>>
>> 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-bun...@googlegroups.com.
>>>
>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/rbw-owners-bunch/cc2ead86-4bac-4e8d-b5a3-91c9d781182bn%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/rbw-owners-bunch/cc2ead86-4bac-4e8d-b5a3-91c9d781182bn%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>
>>
>> -- 
>>
>> ---
>> Patrick Moore
>> Alburquerque, Nuevo Mexico, Etats Unis d'Amerique, Orbis Terrarum
>>
>>

-- 
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/421609d7-236e-43d7-918a-45c6e6fbec19n%40googlegroups.com.

Re: [RBW] Which Paul brakes for a Quickbeam or Simple One?

[JohnS]

Thank you Joe, I'll have to consider the Motolites for my next bike rebuild.

JohnS

On Thursday, January 12, 2023 at 10:31:51 PM UTC-5 Joe Bernard wrote:

> I think there's one call for Motolites in this thread so I'm throwing down 
> a second one. They're great, I love them, they should be the only brakes on 
> all bikes. Is what I'm saying.
>
> On Thursday, January 12, 2023 at 6:18:18 PM UTC-8 Philip Williamson wrote:
>
>> On my Quickbeam, the only Paul braking bits I've got are green Moon 
>> Units. I have used the Neo-Retro / Touring setup on another bike, and 
>> switched to Minimotos due to brake judder. I've never had judder on my 
>> Quickbeam. As Mark said, regular road levers work with both minimotos and 
>> cantis. 
>>
>> I love minimotos. They stop great. They look a little funny, since they 
>> aren't symmetrical. Setup was easy. I think you could flip some washers 
>> around to get the noodle side of the brake not to knock the fender. 
>>
>> A Minimoto in front seems like the opposite strategy from a Neo-retro in 
>> front. Paul Tourings are stronger brakes than Neo-retros, and Minimotos are 
>> stronger yet. I doubt in practice you'd notice. 
>>
>> Philip 
>> Sonoma County, Calif
>>
>> On Thursday, January 12, 2023 at 3:43:07 PM UTC-8 JohnS wrote:
>>
>>> Thanks everyone for sharing your experiences with Paul brakes. I do like 
>>> the way the brake cable connects to the minimotos, same as a v-brake, no 
>>> cable hanger required. I'm planning to have a small front rack. I'll have 
>>> to make sure the rack tang doesn't interfere with the brake cable as it 
>>> connects across to brake arm. Looks like it wasn't an issue for Patch on 
>>> his QB, just above the fender and below the rack tang.
>>>
>>> JohnS
>>>
>>> On Thursday, January 12, 2023 at 12:10:26 PM UTC-5 Minh wrote:
>>>
>>>> another vote for the touring Canti rear/ Neo retro front set up,  
>>>> though one caveat, i recently swapped out front racks, and the new one has 
>>>> a fork tang thats a little higher, requiring a very long straddle cable, 
>>>> braking has been fine but in my mind feels a little less stopping power.  
>>>>
>>>> On Thursday, January 12, 2023 at 11:20:36 AM UTC-5 Patch T wrote:
>>>>
>>>>> John - I like the combination very much, but I don't think it is 
>>>>> significantly *better* than other brake set-ups, and do not 
>>>>> necessarily champion this set-up over others. I went this route because 
>>>>> (a) 
>>>>> I, too, felt bad leaving the QB brake stop bridge hanging out all alone, 
>>>>> and (b) had another bike that was in need of only one Minimoto (a 92 XO1 
>>>>> calipered frame with a 93 XO1 canti'd fork) and after a parts shuffle 
>>>>> across 3 (mostly) canti'd bikes, I ended up with one spare Minimoto.
>>>>>
>>>>> I'll say that the Minimotos and Motolites have a sharper, crisper, 
>>>>> more abrupt stopping action than the Touring and/or Neo Retros. That is 
>>>>> not 
>>>>> to say that the latter pair are 'bad' at stopping - they're marvelous and 
>>>>> strong - but the transition feel is slower/smoother. When running a combo 
>>>>> of Minimoto front + Touring rear, the difference in brake feel is not 
>>>>> funny 
>>>>> or weird or all that noticeable. I suppose there's slightly less wheel 
>>>>> lock 
>>>>> with the Touring out back, but this isn't a dominant factor for me.
>>>>>
>>>>> I personally would recommend the Touring/Neo Retro for road riding; 
>>>>> and Minimotos for more off-road/trail action, and/or/especially in cases 
>>>>> where quick-hard-steep stopping is desired. I save my Motolites for my 
>>>>> 26" 
>>>>> dedicated trail bike. 
>>>>>
>>>>> Last item - aesthetically speaking (YMMV, don't @ me!)
>>>>> Minimotos look sick with knobbies
>>>>> Touring/Neo Retro look sick with knobbies
>>>>> Touring/Neo Retro look sick with slicks
>>>>> Minimotos look just ok with slicks, but sick with 45mm fenders + slicks
>>>>>
>>>>> Everyone's got different brake feelings and experiences, these are 
>>>>> mine, hope they help.
>>>>>
>>>>> Patch in NYC
>>>>>
>>>>>
>>>>> On Wednesday, January 11, 2023

Re: [RBW] Which Paul brakes for a Quickbeam or Simple One?

[JohnS]

Thanks everyone for sharing your experiences with Paul brakes. I do like 
the way the brake cable connects to the minimotos, same as a v-brake, no 
cable hanger required. I'm planning to have a small front rack. I'll have 
to make sure the rack tang doesn't interfere with the brake cable as it 
connects across to brake arm. Looks like it wasn't an issue for Patch on 
his QB, just above the fender and below the rack tang.

JohnS

On Thursday, January 12, 2023 at 12:10:26 PM UTC-5 Minh wrote:

> another vote for the touring Canti rear/ Neo retro front set up,  though 
> one caveat, i recently swapped out front racks, and the new one has a fork 
> tang thats a little higher, requiring a very long straddle cable, braking 
> has been fine but in my mind feels a little less stopping power.  
>
> On Thursday, January 12, 2023 at 11:20:36 AM UTC-5 Patch T wrote:
>
>> John - I like the combination very much, but I don't think it is 
>> significantly *better* than other brake set-ups, and do not necessarily 
>> champion this set-up over others. I went this route because (a) I, too, 
>> felt bad leaving the QB brake stop bridge hanging out all alone, and (b) 
>> had another bike that was in need of only one Minimoto (a 92 XO1 calipered 
>> frame with a 93 XO1 canti'd fork) and after a parts shuffle across 3 
>> (mostly) canti'd bikes, I ended up with one spare Minimoto.
>>
>> I'll say that the Minimotos and Motolites have a sharper, crisper, more 
>> abrupt stopping action than the Touring and/or Neo Retros. That is not to 
>> say that the latter pair are 'bad' at stopping - they're marvelous and 
>> strong - but the transition feel is slower/smoother. When running a combo 
>> of Minimoto front + Touring rear, the difference in brake feel is not funny 
>> or weird or all that noticeable. I suppose there's slightly less wheel lock 
>> with the Touring out back, but this isn't a dominant factor for me.
>>
>> I personally would recommend the Touring/Neo Retro for road riding; and 
>> Minimotos for more off-road/trail action, and/or/especially in cases where 
>> quick-hard-steep stopping is desired. I save my Motolites for my 26" 
>> dedicated trail bike. 
>>
>> Last item - aesthetically speaking (YMMV, don't @ me!)
>> Minimotos look sick with knobbies
>> Touring/Neo Retro look sick with knobbies
>> Touring/Neo Retro look sick with slicks
>> Minimotos look just ok with slicks, but sick with 45mm fenders + slicks
>>
>> Everyone's got different brake feelings and experiences, these are mine, 
>> hope they help.
>>
>> Patch in NYC
>>
>>
>> On Wednesday, January 11, 2023 at 5:50:15 PM UTC-8 JohnS wrote:
>>
>>> Thank you everyone for the tips/advice. I'm not planning to have a rear 
>>> rack on this bike, so the brake arm extension isn't an issue. Also I may or 
>>> may not mount the fenders that I have, my Crust LB-canti has them so not a 
>>> priority to have them on the QB.
>>>
>>> Patch, so how do you like the touring/minimoto combination? Would say it 
>>> was better or as good as other brake set ups?
>>>
>>> Thanks,
>>> JohnS
>>>
>>> On Wednesday, January 11, 2023 at 2:56:39 PM UTC-5 Patch T wrote:
>>>
>>>> I use Paul's Touring on the rear and Minimotos on the front on my QB. 
>>>> The Minimotos clear a VO Smooth 45mm fender just fine.
>>>> I agree that not using the canti stop bridge on the rear is a little 
>>>> sad, but one could get creative and mount a light there if you preferred 
>>>> to 
>>>> run a Minimoto on the rear as well.
>>>>
>>>> Patch in NYC
>>>>
>>>

-- 
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/01d8f620-95cd-43e1-9428-0475627617ddn%40googlegroups.com.

Re: [RBW] Which Paul brakes for a Quickbeam or Simple One?

[JohnS]

Thank you everyone for the tips/advice. I'm not planning to have a rear 
rack on this bike, so the brake arm extension isn't an issue. Also I may or 
may not mount the fenders that I have, my Crust LB-canti has them so not a 
priority to have them on the QB.

Patch, so how do you like the touring/minimoto combination? Would say it 
was better or as good as other brake set ups?

Thanks,
JohnS

On Wednesday, January 11, 2023 at 2:56:39 PM UTC-5 Patch T wrote:

> I use Paul's Touring on the rear and Minimotos on the front on my QB. 
> The Minimotos clear a VO Smooth 45mm fender just fine.
> I agree that not using the canti stop bridge on the rear is a little sad, 
> but one could get creative and mount a light there if you preferred to run 
> a Minimoto on the rear as well.
>
> Patch in NYC
>
> On Wednesday, January 11, 2023 at 11:44:55 AM UTC-8 Benjamin Kelley wrote:
>
>> When I was starting my design process for Paul braking my Quickbeam 
>> everyone said to put touring on the rear.
>> I measured my heel clearance and decided for my bike and fit, that 
>> touring would be unnecessary and neo-retro's would clear fine.
>> However, a set of used touring in my preferred color came up either here 
>> or i-bob first, so I ended up going with them anyways.
>> Definitely measure before you buy tho if you are only considering the 
>> touring for clearance problems, it might not be an issue for you.
>>
>> --ben
>>
>>
>> On Wed, Jan 11, 2023 at 1:19 PM iamkeith  wrote:
>>
>>> Since the Quickbeam has a nice, built-in cable hanger at the rear 
>>> (whereas the Simple One relies on an ad-on hanger installed at the seatpost 
>>> clamp bolt), I think it's nice to use canti brakes.  Just my opinion.  I 
>>> had wide profile brakes, like the neo-retro, both front and rear on my 
>>> Quickbeam (and will again when I finish rebuilding it) and never had heel 
>>> clearance problems.   I do have another bike where I needed to use the 
>>> touring on the rear with the neo retro on the front.
>>>
>>> On Wednesday, January 11, 2023 at 12:01:17 PM UTC-7 eliot...@gmail.com 
>>> wrote:
>>>
>>>> Why not do the motolite V brakes ? I bet they rock
>>>>
>>>> On Wed, Jan 11, 2023 at 10:19 AM Drew Henson  
>>>> wrote:
>>>>
>>>>> Also depends on if you want to run fenders. I don't think the 
>>>>> minimotos have all that much clearance depending on tire size.
>>>>>
>>>>> On Wednesday, January 11, 2023 at 10:06:49 AM UTC-8 JohnS wrote:
>>>>>
>>>>>> Thank you Mark, good to know.
>>>>>>
>>>>>> On Wednesday, January 11, 2023 at 1:04:13 PM UTC-5 
>>>>>> esoter...@gmail.com wrote:
>>>>>>
>>>>>>> John,
>>>>>>>
>>>>>>> The Paul Minomotos are actually short-pull calipers, so you can use 
>>>>>>> the same short-pull levers that you would use with the 
>>>>>>> touring/neo-retro 
>>>>>>> cantilevers. The Paul Motolites are the ones that use long-pull levers. 
>>>>>>>
>>>>>>> ~Mark
>>>>>>> Raleigh, NC
>>>>>>>
>>>>>>>
>>>>>>> On Jan 11, 2023, at 12:57, JohnS  wrote:
>>>>>>>
>>>>>>> The "are Paul's brakes worth it thread" got me thinking that I 
>>>>>>> should give them a try on my Quickbeam. What do people have experience 
>>>>>>> with? I like the idea of using touring canti's on the rear and 
>>>>>>> minimotos on 
>>>>>>> the front as seen on this Rock Lobster build over on The Radivist.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> https://theradavist.com/cyclofunk-single-speed-rock-lobster-cyclocross-kyle-kelley/
>>>>>>>
>>>>>>> The only problem with that is, I'll have to get two pairs of brake 
>>>>>>> levels, one short pull and one long pull. I'm planning on using 
>>>>>>> Mark/noodle 
>>>>>>> drop bars, so the Tektro R340 and RL520 brake levers are at reasonably 
>>>>>>> priced at $30/pair.
>>>>>>>
>>>>>>> Any suggestions are appreciated,
>>>>>>> JohnS
>>>>>>>
>>>>>>> -- 
>>>>>>> You received this message because y

Re: [RBW] Which Paul brakes for a Quickbeam or Simple One?

[JohnS]

Thank you Mark, good to know.

On Wednesday, January 11, 2023 at 1:04:13 PM UTC-5 esoter...@gmail.com 
wrote:

> John,
>
> The Paul Minomotos are actually short-pull calipers, so you can use the 
> same short-pull levers that you would use with the touring/neo-retro 
> cantilevers. The Paul Motolites are the ones that use long-pull levers. 
>
> ~Mark
> Raleigh, NC
>
>
> On Jan 11, 2023, at 12:57, JohnS  wrote:
>
> The "are Paul's brakes worth it thread" got me thinking that I should 
> give them a try on my Quickbeam. What do people have experience with? I 
> like the idea of using touring canti's on the rear and minimotos on the 
> front as seen on this Rock Lobster build over on The Radivist.
>
>
>
> https://theradavist.com/cyclofunk-single-speed-rock-lobster-cyclocross-kyle-kelley/
>
> The only problem with that is, I'll have to get two pairs of brake levels, 
> one short pull and one long pull. I'm planning on using Mark/noodle drop 
> bars, so the Tektro R340 and RL520 brake levers are at reasonably priced at 
> $30/pair.
>
> Any suggestions are appreciated,
> JohnS
>
> -- 
> 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-bun...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/rbw-owners-bunch/8fdc7e95-aa10-446d-97ec-695316b217d2n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/rbw-owners-bunch/8fdc7e95-aa10-446d-97ec-695316b217d2n%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>

-- 
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/e334f39c-c530-4a61-a2ea-d2d14395646cn%40googlegroups.com.

[RBW] Which Paul brakes for a Quickbeam or Simple One?

[JohnS]

The "are Paul's brakes worth it thread" got me thinking that I should give 
them a try on my Quickbeam. What do people have experience with? I like the 
idea of using touring canti's on the rear and minimotos on the front as 
seen on this Rock Lobster build over on The Radivist.

https://theradavist.com/cyclofunk-single-speed-rock-lobster-cyclocross-kyle-kelley/

The only problem with that is, I'll have to get two pairs of brake levels, 
one short pull and one long pull. I'm planning on using Mark/noodle drop 
bars, so the Tektro R340 and RL520 brake levers are at reasonably priced at 
$30/pair.

Any suggestions are appreciated,
JohnS

-- 
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/8fdc7e95-aa10-446d-97ec-695316b217d2n%40googlegroups.com.

[dspace-community] Using containers for ds 7?

[Erica Johns]

Hi All,

I am writing to ask which institutions are using containers for their ds 7
application. I’m not seeking tech support but looking for a sub-community
for future discussion, conference/publishing collaborations,  and/or
questions :)

Thanks in advance for your response!

Erica Johns
Cornell University

-- 
All messages to this mailing list should adhere to the Code of Conduct: 
https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-community+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-community/CAHEWQQVKyC4sLpN%3DjLOVmci7tCB%2Bs_JMOAxVk4kCrZr%2BVHM_Eg%40mail.gmail.com.

[dspace-tech] Using containers for ds 7?

[Erica Johns]

Hi All,

I am writing to ask which institutions are using containers for their ds 7
application. I’m not seeking tech support but looking for a sub-community
for future discussion, conference/publishing collaborations,  and/or
questions :)

Thanks in advance for your response!

Erica Johns
Cornell University

-- 
All messages to this mailing list should adhere to the Code of Conduct: 
https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/CAHEWQQVKyC4sLpN%3DjLOVmci7tCB%2Bs_JMOAxVk4kCrZr%2BVHM_Eg%40mail.gmail.com.

Re: [RBW] Last ride of 2022

[JohnS]

My son (who's 20 and rides my old Salsa Casseroll) and I were out for about 
20 mile ride on the D on Friday, from Slatington north to the Dunkin's in 
Lehighton . Great weather conditions, around 50, no wind. Trail conditions 
weren't so good, with many sections of the hard packed gravel were 
saturated by recent rains and spring like thaw. We had to walk about 1/4 
mile where there the trail was covered in ice, a shady section near the 
Lehighton water treatment plant (always a few degrees cooler along here). I 
felt like we were members of the Rough Stuff Fellowship. Nonetheless, we 
had a great time and enjoyed being outside for a few hours. The trail is 
different this time of year, all the leaves are down and you see more than 
you do otherwise.

Happy New Years Everyone, 
John


On Sunday, January 1, 2023 at 3:19:08 PM UTC-5 Patrick Moore wrote:

> Mine was on 12/30 and described in another thread: ~12 m rt extension of a 
> 1.8 m rt trip to the nearest Sprout's. Skipped 12/31, but rode 13 miles rt 
> to church and back this morning, and found that the brisk if short (~6.5m) 
> outbound ride at ~39*F was an excellent specific for mild overindulgence 
> the night before.
>

-- 
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/b953614e-8ed5-4070-8d33-bf4edd73943dn%40googlegroups.com.

[RBW] Re: cassette advice?

[JohnS]

Hello Adam,

My experience with the Megarange freewheels has been that they are 
difficult to setup with index shifters, friction is OK. 

JohnS

On Wednesday, December 28, 2022 at 1:23:42 PM UTC-5 Adam wrote:

> Also, does the "megarange" setup shift well? I can imagine that being 
> perfect for my situation. I could swap the 27 for a 32.
>
> On Wednesday, December 28, 2022 at 12:16:47 PM UTC-6 Adam wrote:
>
>> Thanks all,
>>
>> I appreciate the thoughts. I agree with the 48x11 being minimally useful. 
>> I have found it only useful for standing and "sprinting" sometimes on long 
>> flat rides.
>>
>> Going to try building a 12-27 and see where that gets me.
>> On Wednesday, December 28, 2022 at 10:58:01 AM UTC-6 Drew Saunders wrote:
>>
>>> How much do you use the 48x11? It’s a pretty high gear, but you may 
>>> prefer a lower cadence than many others. If so, I’ll be the contrarian and 
>>> suggest an 11-23 9 speed. I currently use a 24-36-46 with an 11-23 9 speed 
>>> on my Riv in hilly Silicon Valley, and spend a lot of time in the middle 
>>> ring. I’m gathering parts to convert to 2x11 soon as a rainy winter project.
>>>
>>> On Tuesday, December 27, 2022 at 9:45:56 AM UTC-8 Adam wrote:
>>>
>>>> Hi all,
>>>>
>>>> I'm thinking about changing up the cassette on my Hillborne this 
>>>> winter. I'm currently running an 11-32 (9sp) with 48/36/26 in front.
>>>>
>>>> I've moved to the midwest, and now the closest thing I see to a hill is 
>>>> a freeway overpass. I'd like to try a more compact cassette, thinking 
>>>> something like a 13-28. I somehow have only ridden wide range cassettes, 
>>>> so 
>>>> this is new territory to me. Any advice on this swap?
>>>>
>>>> I also realize the triple front is superfluous, but don't want to swap 
>>>> it unnecessarily, the cassette is getting old, cranks seem fine.
>>>>
>>>> Thanks!
>>>>
>>>> Adam - just back from a ride through Chicago snow.
>>>>
>>>

-- 
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/04efe0a9-5f64-4f50-825e-421ca2db250bn%40googlegroups.com.

Re: [PATCH RSB] Remove aarch64 and microblaze from RSB 5 branch.

[Chris Johns]

OK to push

Thanks
Chris

On 21/12/2022 3:37 am, Joel Sherrill wrote:
> The ports did not get contributed until during 6 development and are
> not on this release branch.
> 
> Closes #4555.
> ---
>  rtems/config/5/rtems-aarch64.bset| 4 
>  rtems/config/5/rtems-all.bset| 2 --
>  rtems/config/5/rtems-microblaze.bset | 3 ---
>  3 files changed, 9 deletions(-)
>  delete mode 100644 rtems/config/5/rtems-aarch64.bset
>  delete mode 100644 rtems/config/5/rtems-microblaze.bset
> 
> diff --git a/rtems/config/5/rtems-aarch64.bset 
> b/rtems/config/5/rtems-aarch64.bset
> deleted file mode 100644
> index f38aff3..000
> --- a/rtems/config/5/rtems-aarch64.bset
> +++ /dev/null
> @@ -1,4 +0,0 @@
> -%define release 1
> -%define rtems_arch aarch64
> -%define with_libgomp
> -%include 5/rtems-default.bset
> diff --git a/rtems/config/5/rtems-all.bset b/rtems/config/5/rtems-all.bset
> index 00ccfae..81076e4 100644
> --- a/rtems/config/5/rtems-all.bset
> +++ b/rtems/config/5/rtems-all.bset
> @@ -1,11 +1,9 @@
> -5/rtems-aarch64
>  5/rtems-arm
>  5/rtems-bfin
>  5/rtems-epiphany
>  5/rtems-i386
>  5/rtems-lm32
>  5/rtems-m68k
> -5/rtems-microblaze
>  5/rtems-mips
>  5/rtems-moxie
>  5/rtems-nios2
> diff --git a/rtems/config/5/rtems-microblaze.bset 
> b/rtems/config/5/rtems-microblaze.bset
> deleted file mode 100644
> index e5c23af..000
> --- a/rtems/config/5/rtems-microblaze.bset
> +++ /dev/null
> @@ -1,3 +0,0 @@
> -%define release 1
> -%define rtems_arch microblaze
> -%include 5/rtems-default.bset
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/1] RSB: Mitigate too short error reports

[Chris Johns]

On 21/12/2022 3:44 am, Frank Kuehndel wrote:
> From: Frank Kühndel 
> 
> Close #4642
> ---
>  source-builder/sb/ereport.py | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/source-builder/sb/ereport.py b/source-builder/sb/ereport.py
> index d8fb5f6..d391917 100755
> --- a/source-builder/sb/ereport.py
> +++ b/source-builder/sb/ereport.py
> @@ -55,6 +55,10 @@ def generate(name, opts, header = None, footer = None):
>  with open(name, 'w') as l:
>  l.write(os.linesep.join(r))
>  log.notice('  See error report: %s' % (name))
> +log.notice('  (Hint: The first error may be in front of a '
> +'line containing\n'
> +'  "Error 1" [GNU make] and may be only in the whole log '

Is this too specific to GNU make? What ifs a package uses cmake or something 
else?

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

Re: [RBW] Re: Will's Roadini SS

[JohnS]

On my Quickbeam there is a fixed 18 cog that I use all the time and on the 
other side is a fixed 16 that I never use. So as long as I can get it off 
the hub, I'll try one of the SS freewheels that I have. Should be able to 
work on it over the Christmas break. 

I agree Philip, changing tires, swapping bars, adding/removing 
fenders/racks all make a bike seem like new.

On the upside of fixed gear riding, I can do a very good track stand, being 
able to push forward or backward just makes it so much easier. I don't even 
try on my multi-geared bikes any more.

Thanks,
JohnS
On Saturday, December 17, 2022 at 2:14:52 PM UTC-5 Philip Williamson wrote:

> I’m a big fan of riding fixed. It just feels good to me, but I’m not an 
> evangelist: “more for me, I guess!” I like having a second gear option (two 
> rings, dingle cog), but almost never use the low gear. 
>
> Will’s Roadini is like a Golden Age tribute bike. I love it. Now I kinda 
> want one, but I’ll go swap tires around on the bikes I’ve got, instead. 
>
> Philip
> Sonoma County, Calif
>
> On Sat, Dec 17, 2022 at 11:02 AM Berkeleyan  wrote:
>
>> It's a different ride, and a fun ride, to have a single speed. I have a 
>> Dos Eno on my QuickBeam, but still stay primarily on the 15 tooth sprocket. 
>> The 17 comes into play for East Bay hills, but I rode (with camping gear) 
>> in the 15 from Berkeley to the Entmoot in Marin via San Francisco and 
>> Sausalito/Tiburon, and it was delightful. With no levers to move, you focus 
>> on building momentum, and save strength for hills.
>>
>> - Andrew, Berkeley
>>
>> On Friday, December 16, 2022 at 7:57:35 AM UTC-8 Ryan wrote:
>>
>>> Have to say...I like that bike a lot. Very clean and elegant
>>>
>>> And Will's post : 
>>> https://www.rivbike.com/blogs/news/singlespeed-roadini?mc_cid=1ea8aef045_eid=0074b52ae1
>>>  
>>> nails what I like about single-speeds; for some years now my SS PX-10 has 
>>> been a fave. Apologies to Rivendell but riding that old Peugeot IS 
>>> addictive.  I am curious to see the landing of the Roaduno in 2023
>>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "RBW Owners Bunch" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/rbw-owners-bunch/0X6eDD7_XCI/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to 
>> rbw-owners-bun...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/rbw-owners-bunch/97b5f06e-1902-4542-b7fa-9aac57ffe14fn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/rbw-owners-bunch/97b5f06e-1902-4542-b7fa-9aac57ffe14fn%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/3b430f54-f193-4651-bc24-19a96a2c4833n%40googlegroups.com.

Announce: RTEMS 5.2 Release

[Chris Johns]

RTEMS 5.2 Release is available.

 https://ftp.rtems.org/pub/rtems/releases/5/5.2

Please follow the release instructions provided by the link.

We love to hear about your projects and what you use RTEMS on so please let us
know. You can drop by on Discord, post on u...@rtems.org or you can send Joel or
me a private email.

If you find a problem please raise a ticket and select the 5.3 milestone. The
simplest way to create a ticket is to head to the developer Wiki at:

 https://devel.rtems.org/

Then click on the "Next (milestone)" link for the RTEMS 5 Release. You will need
an account.

Thanks to everyone who has contributed to the release over the past few years.
This is a community project and without the support of the community we would
not be able to make these quality releases.

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

Announce: RTEMS 5.2 Release

[Chris Johns]

RTEMS 5.2 Release is available.

 https://ftp.rtems.org/pub/rtems/releases/5/5.2

Please follow the release instructions provided by the link.

We love to hear about your projects and what you use RTEMS on so please let us
know. You can drop by on Discord, post on u...@rtems.org or you can send Joel or
me a private email.

If you find a problem please raise a ticket and select the 5.3 milestone. The
simplest way to create a ticket is to head to the developer Wiki at:

 https://devel.rtems.org/

Then click on the "Next (milestone)" link for the RTEMS 5 Release. You will need
an account.

Thanks to everyone who has contributed to the release over the past few years.
This is a community project and without the support of the community we would
not be able to make these quality releases.

Thanks
Chris

ps: Happy birthday Dad!
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

[RBW] Re: Will's Roadini SS

[JohnS]

Hello Ryan,

I'm very inspired my Will's Roadini build as well. I haven't done much SS 
riding, I'm more of a fixed or multi-gear rider. How do people feel about 
SS vs. fixed? Am I missing something by not riding SS some of the time?

Thanks,
JohnS


On Friday, December 16, 2022 at 10:57:35 AM UTC-5 Ryan wrote:

> Have to say...I like that bike a lot. Very clean and elegant
>
> And Will's post : 
> https://www.rivbike.com/blogs/news/singlespeed-roadini?mc_cid=1ea8aef045_eid=0074b52ae1
>  
> nails what I like about single-speeds; for some years now my SS PX-10 has 
> been a fave. Apologies to Rivendell but riding that old Peugeot IS 
> addictive.  I am curious to see the landing of the Roaduno in 2023
>

-- 
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/573bd15d-f446-400f-b3bd-5c87fad42d27n%40googlegroups.com.

Re: [PATCH] bsps/zynqmp: Fix and update device trees

[Chris Johns]

On 6/12/2022 5:04 pm, Kinsey Moore wrote:
> On 12/5/2022 9:48 PM, Chris Johns wrote:
>> I am still seeing issues with this change. The interface is `cgem0` and not
>> `cgem3`. I have confirmed I have the same RTEMS hash in the build. Is there
>> anything I need to set up to have the FDT be seem by libbsd?
> 
> Seeing the first interface to come up as cgem0 is what I observe with this 
> patch
> on the ZCU102, but I do get DHCP. I haven't yet worked out a way around the
> change in behavior for interface numbering. It may need to complete the probe
> and reject the attach. I'll have the person with the TE0802 double check this
> tomorrow.

Ah yes it is working for me. I hd altered the config to reference cgem3 and
needed to change it back.

I am fine with cgem0 being selected and used.

> The output you've shared with me thus far indicates that the device tree is
> being read and used and there should be no additional actions to take for it 
> to
> be utilized.

Great.

The patch looks good. Please push.

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

Re: [PATCH] bsps/zynqmp: Fix and update device trees

[Chris Johns]

I am still seeing issues with this change. The interface is `cgem0` and not
`cgem3`. I have confirmed I have the same RTEMS hash in the build. Is there
anything I need to set up to have the FDT be seem by libbsd?

Chris

On 6/12/2022 10:27 am, Kinsey Moore wrote:
> Add ref-clock-num identifiers to the device tree to ensure that
> interfaces use the correct clocks even when some are not used due to
> unconnected MII busses. This also adjusts the default ZynqMP PHY
> attachment to RGMII-ID which was the default before device trees were
> introduced.
> ---
>  bsps/aarch64/xilinx-zynqmp/fdt/cfc400x.dts   |   4 +
>  bsps/aarch64/xilinx-zynqmp/fdt/cfc400x_dtb.c | 132 ++-
>  bsps/aarch64/xilinx-zynqmp/fdt/zynqmp.dts|  12 +-
>  bsps/aarch64/xilinx-zynqmp/fdt/zynqmp_dtb.c  | 104 ---
>  4 files changed, 137 insertions(+), 115 deletions(-)
> 
> diff --git a/bsps/aarch64/xilinx-zynqmp/fdt/cfc400x.dts 
> b/bsps/aarch64/xilinx-zynqmp/fdt/cfc400x.dts
> index 763a668a5c..05647e0848 100644
> --- a/bsps/aarch64/xilinx-zynqmp/fdt/cfc400x.dts
> +++ b/bsps/aarch64/xilinx-zynqmp/fdt/cfc400x.dts
> @@ -62,6 +62,7 @@
>   interrupts = <0x00 0x39 0x04>;
>   reg = <0x00 0xff0b 0x00 0x1000>;
>   phy-mode = "sgmii";
> + ref-clock-num = <0>;
>   };
>  
>   ethernet@ff0c {
> @@ -71,6 +72,7 @@
>   interrupts = <0x00 0x3b 0x04>;
>   reg = <0x00 0xff0c 0x00 0x1000>;
>   phy-mode = "sgmii";
> + ref-clock-num = <1>;
>   };
>  
>   ethernet@ff0d {
> @@ -80,6 +82,7 @@
>   interrupts = <0x00 0x3d 0x04>;
>   reg = <0x00 0xff0d 0x00 0x1000>;
>   phy-mode = "sgmii";
> + ref-clock-num = <2>;
>   };
>  
>   ethernet@ff0e {
> @@ -89,6 +92,7 @@
>   interrupts = <0x00 0x3f 0x04>;
>   reg = <0x00 0xff0e 0x00 0x1000>;
>   phy-mode = "sgmii";
> + ref-clock-num = <3>;
>   };
>  
>   serial@800a {
> diff --git a/bsps/aarch64/xilinx-zynqmp/fdt/cfc400x_dtb.c 
> b/bsps/aarch64/xilinx-zynqmp/fdt/cfc400x_dtb.c
> index 2d0078678e..7a45b4f7dd 100644
> --- a/bsps/aarch64/xilinx-zynqmp/fdt/cfc400x_dtb.c
> +++ b/bsps/aarch64/xilinx-zynqmp/fdt/cfc400x_dtb.c
> @@ -1,8 +1,8 @@
>  unsigned char zynqmp_dtb[] = {
> -  0xd0, 0x0d, 0xfe, 0xed, 0x00, 0x00, 0x05, 0xa3, 0x00, 0x00, 0x00, 0x38,
> -  0x00, 0x00, 0x04, 0xd0, 0x00, 0x00, 0x00, 0x28, 0x00, 0x00, 0x00, 0x11,
> -  0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xd3,
> -  0x00, 0x00, 0x04, 0x98, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +  0xd0, 0x0d, 0xfe, 0xed, 0x00, 0x00, 0x05, 0xf1, 0x00, 0x00, 0x00, 0x38,
> +  0x00, 0x00, 0x05, 0x10, 0x00, 0x00, 0x00, 0x28, 0x00, 0x00, 0x00, 0x11,
> +  0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xe1,
> +  0x00, 0x00, 0x04, 0xd8, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
>0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01,
>0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x04,
>0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x03,
> @@ -39,33 +39,37 @@ unsigned char zynqmp_dtb[] = {
>0x00, 0x00, 0x00, 0x3e, 0x00, 0x00, 0x00, 0x00, 0xff, 0x0b, 0x00, 0x00,
>0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x03,
>0x00, 0x00, 0x00, 0x06, 0x00, 0x00, 0x00, 0x82, 0x73, 0x67, 0x6d, 0x69,
> -  0x69, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x01,
> -  0x65, 0x74, 0x68, 0x65, 0x72, 0x6e, 0x65, 0x74, 0x40, 0x66, 0x66, 0x30,
> -  0x63, 0x30, 0x30, 0x30, 0x30, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03,
> -  0x00, 0x00, 0x00, 0x09, 0x00, 0x00, 0x00, 0x1b, 0x63, 0x64, 0x6e, 0x73,
> -  0x2c, 0x67, 0x65, 0x6d, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03,
> -  0x00, 0x00, 0x00, 0x05, 0x00, 0x00, 0x00, 0x5f, 0x6f, 0x6b, 0x61, 0x79,
> -  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x04,
> -  0x00, 0x00, 0x00, 0x66, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x03,
> -  0x00, 0x00, 0x00, 0x0c, 0x00, 0x00, 0x00, 0x77, 0x00, 0x00, 0x00, 0x00,
> -  0x00, 0x00, 0x00, 0x3b, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, 0x03,
> -  0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, 0x3e, 0x00, 0x00, 0x00, 0x00,
> -  0xff, 0x0c, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x10, 0x00,
> -  0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x06, 0x00, 0x00, 0x00, 0x82,
> -  0x73, 0x67, 0x6d, 0x69, 0x69, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02,
> +  0x69, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x04,
> +  0x00, 0x00, 0x00, 0x8b, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02,
>0x00, 0x00, 0x00, 0x01, 0x65, 0x74, 0x68, 0x65, 0x72, 0x6e, 0x65, 

Moving ticket milestones to a different RTEMS version

[Chris Johns]

Hi,

Joel and I have been cleaning up the 6 tickets and some have been moved to 7
(thanks) which may be appropriate however I am wondering about open ended
tickets for a specific set of work and release notes. These tickets are really
great for collecting commits for a specific change.

The release notes are based on the tickets for a release and milestone. An open
ended ticket for a specific task when part of release collects the related
commits however moving that ticket to the next release moves the commits to that
release's release notes and the current release does not see the commits in its
release notes?

Should the ticket be cloned (without comments?) to the next release and the one
on the current release closed. It seems to make sense to me. The work is
continuing however it is closed for the branch being release?

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

Re: [PATCH] cpukit/include/dev/can: Disabled debug prints in CAN Framework

[Chris Johns]

On 2/12/2022 2:38 pm, Chris Johns wrote:
> The CAN bus changes have warnings ...
> 
> In file included from ../../../cpukit/include/dev/can/canqueueimpl.h:48,
>  from ../../../cpukit/dev/can/can.c:45:
> ../../../cpukit/dev/can/can.c: In function 'can_bus_read':
> ../../../cpukit/dev/can/can.c:213:15: warning: format '%u' expects argument of
> type 'unsigned int', but argument 2 has type 'long unsigned int' [-Wformat=]
>   213 | CAN_DEBUG("can_bus_read: buffer size is small min sizeof(struct
> can_msg) = %u\n",
>   |
> ^~
>   214 | sizeof(struct can_msg));
>   | ~~
>   | |
>   | long unsigned int
> ../../../cpukit/include/dev/can/can.h:53:14: note: in definition of macro
> 
> etc etc etc
> 
> Can these please be fixed? Use #4662.

I should add I used the aarch64/xilinx_zynqmp_lp64_zu3eg BSP so it looks like
these are 64bit related. I hope that helps. I do not see them with 32bit builds.

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

Re: [PATCH] cpukit/include/dev/can: Disabled debug prints in CAN Framework

[Chris Johns]

The CAN bus changes have warnings ...

In file included from ../../../cpukit/include/dev/can/canqueueimpl.h:48,
 from ../../../cpukit/dev/can/can.c:45:
../../../cpukit/dev/can/can.c: In function 'can_bus_read':
../../../cpukit/dev/can/can.c:213:15: warning: format '%u' expects argument of
type 'unsigned int', but argument 2 has type 'long unsigned int' [-Wformat=]
  213 | CAN_DEBUG("can_bus_read: buffer size is small min sizeof(struct
can_msg) = %u\n",
  |
^~
  214 | sizeof(struct can_msg));
  | ~~
  | |
  | long unsigned int
../../../cpukit/include/dev/can/can.h:53:14: note: in definition of macro

etc etc etc

Can these please be fixed? Use #4662.

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

Re: [PATCH 0/3] Add CONFIGURE_RECORD_INTERRUPTS_ENABLED

[Chris Johns]

Looks good.

Thanks
Chris

On 1/12/2022 11:10 pm, Sebastian Huber wrote:
> This enables the tracing of interrupt entry/exit events through an
> application configuration option.  The interrupt processing can be
> viewed with Trace Compass.
> 
> Sebastian Huber (3):
>   bsps/irq: Rename handler in dispatch table
>   bsps/irq: Add bsp_interrupt_get_dispatch_table_slot()
>   config: Add CONFIGURE_RECORD_INTERRUPTS_ENABLED
> 
>  bsps/include/bsp/irq-generic.h| 79 ---
>  bsps/powerpc/mpc55xxevb/include/bsp/irq.h |  2 +-
>  bsps/riscv/riscv/include/tm27.h   |  4 +-
>  bsps/shared/irq/irq-entry-remove.c|  6 +-
>  bsps/shared/irq/irq-generic.c | 41 
>  bsps/shared/irq/irq-handler-iterate.c |  4 +-
>  bsps/shared/irq/irq-record.c  | 97 +++
>  cpukit/doxygen/appl-config.h  | 23 +
>  cpukit/include/rtems/confdefs/extensions.h|  8 ++
>  cpukit/include/rtems/record.h |  2 +
>  spec/build/bsps/objirq.yml|  1 +
>  spec/build/bsps/powerpc/ss555/bspss555.yml|  1 +
>  .../validation/tc-bsp-interrupt-spurious.c|  4 +-
>  testsuites/validation/tc-intr-entry-install.c |  4 +-
>  testsuites/validation/tc-intr-entry-remove.c  |  8 +-
>  .../validation/tc-intr-handler-iterate.c  |  4 +-
>  16 files changed, 218 insertions(+), 70 deletions(-)
>  create mode 100644 bsps/shared/irq/irq-record.c
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Document CONFIGURE_RECORD_INTERRUPTS_ENABLED

[Chris Johns]

Looks good.

Thanks
Chris

On 1/12/2022 11:11 pm, Sebastian Huber wrote:
> Close #4769.
> ---
>  c-user/config/event-record.rst  | 43 +-
>  user/tracing/eventrecording.rst | 65 +++--
>  2 files changed, 47 insertions(+), 61 deletions(-)
> 
> diff --git a/c-user/config/event-record.rst b/c-user/config/event-record.rst
> index 31a4fa9..f1e7969 100644
> --- a/c-user/config/event-record.rst
> +++ b/c-user/config/event-record.rst
> @@ -1,6 +1,6 @@
>  .. SPDX-License-Identifier: CC-BY-SA-4.0
>  
> -.. Copyright (C) 2019, 2021 embedded brains GmbH 
> (http://www.embedded-brains.de)
> +.. Copyright (C) 2019, 2022 embedded brains GmbH 
> (http://www.embedded-brains.de)
>  
>  .. This file is part of the RTEMS quality process and was automatically
>  .. generated.  If you find something that needs to be fixed or
> @@ -150,6 +150,47 @@ in a fatal error extension (see :ref:`Terminate`).
>  The zlib compression needs about 512KiB of RAM.  This extension can be used
>  to produce crash dumps.
>  
> +.. Generated from spec:/acfg/if/record-interrupts-enabled
> +
> +.. raw:: latex
> +
> +\clearpage
> +
> +.. index:: CONFIGURE_RECORD_INTERRUPTS_ENABLED
> +
> +.. _CONFIGURE_RECORD_INTERRUPTS_ENABLED:
> +
> +CONFIGURE_RECORD_INTERRUPTS_ENABLED
> +---
> +
> +.. rubric:: CONSTANT:
> +
> +``CONFIGURE_RECORD_INTERRUPTS_ENABLED``
> +
> +.. rubric:: OPTION TYPE:
> +
> +This configuration option is a boolean feature define.
> +
> +.. rubric:: DEFAULT CONFIGURATION:
> +
> +If this configuration option is undefined, then the described feature is not
> +enabled.
> +
> +.. rubric:: DESCRIPTION:
> +
> +In case
> +
> +* this configuration option is defined
> +
> +* and :ref:`CONFIGURE_RECORD_PER_PROCESSOR_ITEMS` is properly defined,
> +
> +then the interrupt event recording is enabled.
> +
> +.. rubric:: NOTES:
> +
> +The interrupt event recording generates interrupt entry and exit events when
> +interrupt entries are dispatched.
> +
>  .. Generated from spec:/acfg/if/record-per-processor-items
>  
>  .. raw:: latex
> diff --git a/user/tracing/eventrecording.rst b/user/tracing/eventrecording.rst
> index 7130658..b5561cc 100644
> --- a/user/tracing/eventrecording.rst
> +++ b/user/tracing/eventrecording.rst
> @@ -48,8 +48,11 @@ The application enables the event recording support via 
> the configuration
>  option :c:macro:`CONFIGURE_RECORD_PER_PROCESSOR_ITEMS`.  The configuration
>  option :c:macro:`CONFIGURE_RECORD_EXTENSIONS_ENABLED` enables the generation 
> of
>  thread create, start, restart, delete, switch, begin, exitted and terminate
> -events.  Dumps of the event records in a fatal error handler can be enabled 
> by
> -the mutually exclusive :c:macro:`CONFIGURE_RECORD_FATAL_DUMP_BASE64` and
> +events.  The configuration option
> +:c:macro:`CONFIGURE_RECORD_INTERRUPTS_ENABLED` enables the generation of
> +interrupt entry and exit events.  Dumps of the event records in a fatal error
> +handler can be enabled by the mutually exclusive
> +:c:macro:`CONFIGURE_RECORD_FATAL_DUMP_BASE64` and
>  :c:macro:`CONFIGURE_RECORD_FATAL_DUMP_BASE64_ZLIB` configuration options.
>  
>  Custom events can be recorded for example with the
> @@ -98,64 +101,6 @@ instrumented functions:
>   );
> }
>  
> -To generate interrupt handler entry/exit events, the following patch can be
> -used:
> -
> -.. code-block:: diff
> -
> -diff --git a/bsps/arm/shared/clock/clock-armv7m.c 
> b/bsps/arm/shared/clock/clock-armv7m.c
> -index 255de1ca42..0d37c63ac6 100644
> ---- a/bsps/arm/shared/clock/clock-armv7m.c
> -+++ b/bsps/arm/shared/clock/clock-armv7m.c
> -@@ -29,6 +29,7 @@
> - #include 
> -
> - #include 
> -+#include 
> - #include 
> -
> - #ifdef ARM_MULTILIB_ARCH_V7M
> -@@ -45,9 +46,11 @@ static uint32_t _ARMV7M_TC_get_timecount(struct 
> timecounter *base)
> -
> - void _ARMV7M_Clock_handler(void)
> - {
> -+  rtems_record_produce(RTEMS_RECORD_INTERRUPT_ENTRY, 
> ARMV7M_VECTOR_SYSTICK);
> -   _ARMV7M_Interrupt_service_enter();
> -   Clock_isr(NULL);
> -   _ARMV7M_Interrupt_service_leave();
> -+  rtems_record_produce(RTEMS_RECORD_INTERRUPT_EXIT, 
> ARMV7M_VECTOR_SYSTICK);
> - }
> -
> - static void _ARMV7M_Clock_handler_install(void)
> -diff --git a/bsps/include/bsp/irq-generic.h 
> b/bsps/include/bsp/irq-generic.h
> -index 31835d07ba..2ab2f78b65 100644
> ---- a/bsps/include/bsp/irq-generic.h
> -+++ b/bsps/include/bsp/irq-generic.h
> -@@ -30,6 +30,7 @@
> - #include 
> -
> - #include 
> -+#include 
> - #include 
> -
> - #ifdef RTEMS_SMP
> -@@ -258,6 +259,7 @@ void 
> bsp_interrupt_vector_disable(rtems_vector_number vector);
> -  */
> - static inline void bsp_interrupt_handler_dispatch(rtems_vector_number 
> vector)
> - {
> -+  rtems_record_produce(RTEMS_RECORD_INTERRUPT_ENTRY, vector);
> -   if (bsp_interrupt_is_valid_vector(vector)) {
> - 

Re: [PATCH rtems-docs] c-user/*: Add trailing parentheses on methods in index which were missing it

[Chris Johns]

Looks good and thanks

Chris

On 1/12/2022 3:00 am, Joel Sherrill wrote:
> Closes #4766.
> ---
>  c-user/chains.rst | 46 
> +--
>  c-user/clock/removed-directives.rst   |  2 +-
>  c-user/constant_bandwidth_server.rst  | 24 +-
>  c-user/cpu_usage_statistics.rst   |  4 +--
>  c-user/directive_status_codes.rst |  2 +-
>  c-user/key_concepts.rst   | 12 -
>  c-user/task/deprecated-directives.rst |  2 +-
>  c-user/task/operations.rst| 10 
>  c-user/task/removed-directives.rst| 10 
>  c-user/timespec_helpers.rst   | 28 ++---
>  c-user/user-extensions/background.rst |  2 +-
>  11 files changed, 71 insertions(+), 71 deletions(-)
> 
> diff --git a/c-user/chains.rst b/c-user/chains.rst
> index 0dce1d9..f518ef4 100644
> --- a/c-user/chains.rst
> +++ b/c-user/chains.rst
> @@ -220,7 +220,7 @@ The section details the Chains directives.
>  .. _rtems_chain_initialize:
>  
>  .. index:: chain initialize
> -.. index:: rtems_chain_initialize
> +.. index:: rtems_chain_initialize()
>  
>  Initialize Chain With Nodes
>  ---
> @@ -258,7 +258,7 @@ NOTES:
>  .. _rtems_chain_initialize_empty:
>  
>  .. index:: chain initialize empty
> -.. index:: rtems_chain_initialize_empty
> +.. index:: rtems_chain_initialize_empty()
>  
>  Initialize Empty
>  
> @@ -287,7 +287,7 @@ NOTES:
>  .. _rtems_chain_is_null_node:
>  
>  .. index:: chain is node null
> -.. index:: rtems_chain_is_null_node
> +.. index:: rtems_chain_is_null_node()
>  
>  Is Null Node ?
>  --
> @@ -313,7 +313,7 @@ DESCRIPTION:
>  .. _rtems_chain_head:
>  
>  .. index:: chain get head
> -.. index:: rtems_chain_head
> +.. index:: rtems_chain_head()
>  
>  Head
>  
> @@ -338,7 +338,7 @@ DESCRIPTION:
>  .. _rtems_chain_tail:
>  
>  .. index:: chain get tail
> -.. index:: rtems_chain_tail
> +.. index:: rtems_chain_tail()
>  
>  Tail
>  
> @@ -363,7 +363,7 @@ DESCRIPTION:
>  .. _rtems_chain_are_nodes_equal:
>  
>  .. index:: chare are nodes equal
> -.. index:: rtems_chain_are_nodes_equal
> +.. index:: rtems_chain_are_nodes_equal()
>  
>  Are Two Nodes Equal ?
>  -
> @@ -391,7 +391,7 @@ DESCRIPTION:
>  .. _rtems_chain_is_empty:
>  
>  .. index:: chain is chain empty
> -.. index:: rtems_chain_is_empty
> +.. index:: rtems_chain_is_empty()
>  
>  Is the Chain Empty
>  --
> @@ -418,7 +418,7 @@ DESCRIPTION:
>  .. _rtems_chain_is_first:
>  
>  .. index:: chain is node the first
> -.. index:: rtems_chain_is_first
> +.. index:: rtems_chain_is_first()
>  
>  Is this the First Node on the Chain ?
>  -
> @@ -445,7 +445,7 @@ DESCRIPTION:
>  .. _rtems_chain_is_last:
>  
>  .. index:: chain is node the last
> -.. index:: rtems_chain_is_last
> +.. index:: rtems_chain_is_last()
>  
>  Is this the Last Node on the Chain ?
>  
> @@ -472,7 +472,7 @@ DESCRIPTION:
>  .. _rtems_chain_has_only_one_node:
>  
>  .. index:: chain only one node
> -.. index:: rtems_chain_has_only_one_node
> +.. index:: rtems_chain_has_only_one_node()
>  
>  Does this Chain have only One Node ?
>  
> @@ -499,7 +499,7 @@ DESCRIPTION:
>  .. _rtems_chain_node_count_unprotected:
>  
>  .. index:: chain only one node
> -.. index:: rtems_chain_node_count_unprotected
> +.. index:: rtems_chain_node_count_unprotected()
>  
>  Returns the node count of the chain (unprotected)
>  -
> @@ -524,7 +524,7 @@ DESCRIPTION:
>  .. _rtems_chain_is_head:
>  
>  .. index:: chain is node the head
> -.. index:: rtems_chain_is_head
> +.. index:: rtems_chain_is_head()
>  
>  Is this Node the Chain Head ?
>  -
> @@ -552,7 +552,7 @@ DESCRIPTION:
>  .. _rtems_chain_is_tail:
>  
>  .. index:: chain is node the tail
> -.. index:: rtems_chain_is_tail
> +.. index:: rtems_chain_is_tail()
>  
>  Is this Node the Chain Tail ?
>  -
> @@ -580,7 +580,7 @@ DESCRIPTION:
>  .. _rtems_chain_extract:
>  
>  .. index:: chain extract a node
> -.. index:: rtems_chain_extract
> +.. index:: rtems_chain_extract()
>  
>  Extract a Node
>  --
> @@ -611,7 +611,7 @@ NOTES:
>  .. _rtems_chain_extract_unprotected:
>  
>  .. index:: chain extract a node unprotected
> -.. index:: rtems_chain_extract_unprotected
> +.. index:: rtems_chain_extract_unprotected()
>  
>  Extract a Node (unprotected)
>  
> @@ -639,7 +639,7 @@ NOTES:
>  .. _rtems_chain_get:
>  
>  .. index:: chain get first node
> -.. index:: rtems_chain_get
> +.. index:: rtems_chain_get()
>  
>  Get the First Node
>  --
> @@ -672,7 +672,7 @@ NOTES:
>  .. _rtems_chain_get_unprotected:
>  
>  .. index:: chain get first node
> -.. index:: rtems_chain_get_unprotected
> +.. index:: rtems_chain_get_unprotected()
>  
>  Get 

Re: [PATCH rtems-docs] user/hosts/windows.rst: flex needs to be installed for msys2

[Chris Johns]

OK and thanks

Chris

On 1/12/2022 2:32 am, Joel Sherrill wrote:
> Closes #4382.
> ---
>  user/hosts/windows.rst | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/user/hosts/windows.rst b/user/hosts/windows.rst
> index fac1366..fd7ff55 100644
> --- a/user/hosts/windows.rst
> +++ b/user/hosts/windows.rst
> @@ -156,6 +156,7 @@ The packages we require are:
>  * python
>  * mingw-w64-x86_64-python2
>  * mingw-w64-x86_64-gcc
> +* flex
>  * git
>  * bison
>  * cvs
> @@ -176,7 +177,7 @@ Install the packages using ``pacman``:
>  .. code-block:: none
>  
>$ pacman -S python mingw-w64-x86_64-python2 mingw-w64-x86_64-gcc \
> -  bison cvs diffutils git make patch tar texinfo unzip
> +  bison flex cvs diffutils git make patch tar texinfo unzip
>resolving dependencies...
>looking for conflicting packages...
> output shortened for brevity 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Fwd: Coverity Scan: Analysis completed for RTEMS

[Chris Johns]

On 25/11/2022 5:40 pm, Joel Sherrill wrote:
> Looks like edit.c may still have an issue since only one was eliminated. Late
> here and I didn't check the Coverity report for sure.

With Coverity is there anyway to check changes or do we consider the issues
raised, attempt a solution then just keep trying?

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

Re: [PATCH rtems-tools] fix _mkdir parameter error.

[Chris Johns]

Pushed. Thanks

Chris

On 27/11/2022 8:20 pm, zhengxiaojun wrote:
> fix _mkdir parameter error.
> 
> Signed-off-by: zhengxiaojun 
> ---
>  tester/covoar/ReportsBase.cc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tester/covoar/ReportsBase.cc b/tester/covoar/ReportsBase.cc
> index 0fb9ce0..eb56c4f 100644
> --- a/tester/covoar/ReportsBase.cc
> +++ b/tester/covoar/ReportsBase.cc
> @@ -65,7 +65,7 @@ void ReportsBase::OpenFile(
> 
>    // Create the output directory if it does not already exist
>  #ifdef _WIN32
> -  sc = _mkdir( symbolSetOutputDirectory );
> +  sc = _mkdir( symbolSetOutputDirectory.c_str() );
>  #else
>    sc = mkdir( symbolSetOutputDirectory.c_str(), 0755 );
>  #endif
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] spec/beagle: Add missing spi.h install

[Chris Johns]

Pushed. Thanks

Chris

On 26/11/2022 2:19 pm, Kinsey Moore wrote:
> The beagle SPI functions are unusable by applications unless this file
> is installed with the BSP. This ensures that the file is installed
> properly.
> ---
>  spec/build/bsps/arm/beagle/obj.yml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/spec/build/bsps/arm/beagle/obj.yml 
> b/spec/build/bsps/arm/beagle/obj.yml
> index 56072075c2..90b0499031 100644
> --- a/spec/build/bsps/arm/beagle/obj.yml
> +++ b/spec/build/bsps/arm/beagle/obj.yml
> @@ -20,6 +20,7 @@ install:
>- bsps/arm/beagle/include/bsp/irq.h
>- bsps/arm/beagle/include/bsp/pwmss.h
>- bsps/arm/beagle/include/bsp/qep.h
> +  - bsps/arm/beagle/include/bsp/spi.h
>  - destination: ${BSP_LIBDIR}
>source:
>- bsps/arm/beagle/start/linkcmds
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] libmisc/shell: Support terminal size as env variables

[Chris Johns]

On 23/11/22 12:44 am, Joel Sherrill wrote:
> On Tue, Nov 22, 2022, 6:02 AM mailto:chr...@rtems.org>> 
> wrote:
>     From: Chris Johns mailto:chr...@rtems.org>>
> 
> Closes #4763
> ---
>  cpukit/libmisc/shell/main_edit.c | 17 +-
>  cpukit/libmisc/shell/main_help.c | 94 
>  cpukit/libmisc/shell/shell.c     | 83 +++-
>  3 files changed, 154 insertions(+), 40 deletions(-)
> 
> diff --git a/cpukit/libmisc/shell/main_edit.c 
> b/cpukit/libmisc/shell/main_edit.c
> index 4cc742719a..16c44f2a11 100644
> --- a/cpukit/libmisc/shell/main_edit.c
> +++ b/cpukit/libmisc/shell/main_edit.c
> @@ -755,8 +755,21 @@ static void get_console_size(struct env *env) {
>    env->cols = ws.ws_col;
>    env->lines = ws.ws_row - 1;
>  #elif defined(__rtems__)
> -  env->cols = 80;
> -  env->lines = 25;
> +  char* e;
> +  e = getenv("LINES");
> +  if (e != NULL) {
> +    int lines = strtol(e, 0, 10);
> +    if (lines > 0) {
> +      env->lines = lines - 1;
> +    }
> +  }
> +  e = getenv("COLUMNS");
> +  if (e != NULL) {
> +    int cols = strtol(e, 0, 10);
> +    if (cols > 0) {
> +      env->cols = cols - 1;
> +    }
> +  }
> 
> Does this lose the default values if the environment variables are not set?
> 

Yes. I will add the defaults back and then push.

Thanks for the review.

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

Re: [PATCH] aarch64/versal: Add UART interrupt support

[Chris Johns]

On 22/11/22 6:01 pm, Sebastian Huber wrote:
> Hello Chris,
> 
> On 22/11/2022 03:03, chr...@rtems.org wrote:
>> +static void versal_uart_write_support(
>> +  rtems_termios_device_context *base,
>> +  const char *buf,
>> +  size_t len
>> +)
>> +{
>> +#ifdef VERSAL_CONSOLE_USE_INTERRUPTS
>> +  versal_uart_context *ctx = (versal_uart_context *) base;
>> +  volatile versal_uart *regs = ctx->regs;
>> +
>> +  if (len > 0) {
>> +    rtems_interrupt_lock_context lock_context;
>> +    size_t len_remaining = len;
>> +    const char *p = [0];
>> +    rtems_interrupt_lock_acquire(>interrupt_lock, _context);
> 
> you don't need an extra interrupt lock. The rtems_termios_device_context 
> already
> contains an interrupt lock, see rtems_termios_device_lock_acquire(). This lock
> is held while the write support handler is called.
> 

Thanks for the review and I will remove. The driver took a while to isolate a
possible issue in the hardware. I have raised this with Xilinx. The TX will not
start with the single character write. I needed to write past the trigger point.

I think this driver could be moved to shared as the hardware is based on the ARM
IP for the PL011 UART. I wanted to get the chcanges in and used before
considering moving it. Xilinx has changed the IP a little which is a shame.

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

Re: Use of rtems_fdt_* and sp01

[Chris Johns]

On 20/11/2022 10:25 am, Joel Sherrill wrote:
> On Sat, Nov 19, 2022, 4:19 PM Chris Johns  <mailto:chr...@rtems.org>> wrote:
> 
> On 19/11/22 2:13 am, Joel Sherrill wrote:
> > On Fri, Nov 18, 2022, 8:49 AM Kinsey Moore  <mailto:kinsey.mo...@oarcorp.com>
> > <mailto:kinsey.mo...@oarcorp.com <mailto:kinsey.mo...@oarcorp.com>>> 
> wrote:
> >     On Fri, Nov 18, 2022 at 12:44 AM Sebastian Huber
> >      <mailto:sebastian.hu...@embedded-brains.de>
> >     <mailto:sebastian.hu...@embedded-brains.de
> <mailto:sebastian.hu...@embedded-brains.de>>> wrote:
> >         On 18/11/2022 06:32, Kinsey Moore wrote:
> >         > On Thu, Nov 17, 2022 at 4:49 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 18/11/2022 2:39 am, Kinsey Moore wrote:
> >         >      > I recently added FDT support to the AArch64 ZynqMP 
> BSPs to
> >         >     support an optional
> >         >      > management console and managing ethernet parameters for
> LibBSD.
> >         >     Use of the
> >         >      > rtems_fdt_* functions implies use of malloc which adds 
> 4
> bytes in
> >         >     the TLS space.
> >         >      > The sp01 test uses rtems_task_construct and specifies a
> maximum
> >         >     TLS size of 0
> >         >      > bytes which causes a failure which the non-zero TLS 
> size is
> >         >     checked against the
> >         >      > maximum TLS size of 0.
> >         >
> >         >     Does this mean there exists a requirement a BSPs cannot
> internally
> >         >     use the heap?
> >         >
> >         >
> >         > That appears to be the case, at least practically. It works
> fine, but it
> >         > causes a test failure...
> >
> >         You can use the heap during system initialization. However, you 
> should
> >         avoid dependencies on errno, so instead of using 
> malloc()/calloc() use
> >         rtems_malloc()/rtems_calloc(). Independent of this, if the BSP
> >         initialization can easily avoid the heap, then it should not use
> the heap.
> >
> >         >
> >         >
> >         >     Maybe the test needs to be adjusted?
> >         >
> >         >
> >         > That's part of why I sent this to the list. I was unsure 
> whether
> it was
> >         > allowed or whether the test had bad assumptions baked into it.
> >
> >         The tests check specific aspects of the thread-local storage
> support and
> >         this works only if the BSP does not depend on TLS objects such 
> as
> errno.
> >
> >     This affects several other tests as well, so I guess my solution 
> here is
> >     either to alter the rtems_fdt_ wrappers to avoid dependencies on 
> TLS or
> >     proceed with the existing patch that uses the non-wrapped FDT 
> functions.
> >
> > I agree with Sebastian that fixing the bsp is right.
> >
> > But also rtems_ fdt methods should be changed to use rtems_malloc. That 
> would
> > leave those methods useful. They are broken now for many intended use 
> cases.
> 
> We are currently reviewing the support for ftbo files in Linux 
> (petalinux) with
> a view to seeing how we can support them on RTEMS. I see FDT being use 
> more and
> more in RTEMS and with a number of different use cases and flows there is 
> a need
> to try and unify how we handle them. I see benefits if we can support a 
> similar
> dtbo model as Linux and if that happens the specific area in question in
> rtems-fst can be move over to using it.
> 
> 
> FWIW Kinsey's patch to the rtems_fdt methods eliminated two coverity issues.

Yes and that is a worth while change. Thanks.

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

Re: Use of rtems_fdt_* and sp01

[Chris Johns]

On 19/11/22 2:13 am, Joel Sherrill wrote:
> On Fri, Nov 18, 2022, 8:49 AM Kinsey Moore  <mailto:kinsey.mo...@oarcorp.com>> wrote:
> On Fri, Nov 18, 2022 at 12:44 AM Sebastian Huber
>  <mailto:sebastian.hu...@embedded-brains.de>> wrote:
> On 18/11/2022 06:32, Kinsey Moore wrote:
> > On Thu, Nov 17, 2022 at 4:49 PM Chris Johns  <mailto:chr...@rtems.org>
> > <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>> wrote:
> >
> >     On 18/11/2022 2:39 am, Kinsey Moore wrote:
> >      > I recently added FDT support to the AArch64 ZynqMP BSPs to
> >     support an optional
> >      > management console and managing ethernet parameters for 
> LibBSD.
> >     Use of the
> >      > rtems_fdt_* functions implies use of malloc which adds 4 
> bytes in
> >     the TLS space.
> >      > The sp01 test uses rtems_task_construct and specifies a 
> maximum
> >     TLS size of 0
> >      > bytes which causes a failure which the non-zero TLS size is
> >     checked against the
> >      > maximum TLS size of 0.
> >
> >     Does this mean there exists a requirement a BSPs cannot 
> internally
> >     use the heap?
> >
> >
> > That appears to be the case, at least practically. It works fine, 
> but it
> > causes a test failure...
> 
> You can use the heap during system initialization. However, you should
> avoid dependencies on errno, so instead of using malloc()/calloc() use
> rtems_malloc()/rtems_calloc(). Independent of this, if the BSP
> initialization can easily avoid the heap, then it should not use the 
> heap.
> 
> >
> >
> >     Maybe the test needs to be adjusted?
> >
> >
> > That's part of why I sent this to the list. I was unsure whether it 
> was
> > allowed or whether the test had bad assumptions baked into it.
> 
> The tests check specific aspects of the thread-local storage support 
> and
> this works only if the BSP does not depend on TLS objects such as 
> errno.
> 
> This affects several other tests as well, so I guess my solution here is
> either to alter the rtems_fdt_ wrappers to avoid dependencies on TLS or
> proceed with the existing patch that uses the non-wrapped FDT functions.
> 
> I agree with Sebastian that fixing the bsp is right.
> 
> But also rtems_ fdt methods should be changed to use rtems_malloc. That would
> leave those methods useful. They are broken now for many intended use cases.

We are currently reviewing the support for ftbo files in Linux (petalinux) with
a view to seeing how we can support them on RTEMS. I see FDT being use more and
more in RTEMS and with a number of different use cases and flows there is a need
to try and unify how we handle them. I see benefits if we can support a similar
dtbo model as Linux and if that happens the specific area in question in
rtems-fst can be move over to using it.

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

Re: [PATCH] cpukit/rtems-fdt: Avoid use of malloc/errno

[Chris Johns]

Looks good and thanks

Chris

On 19/11/2022 2:47 am, Kinsey Moore wrote:
> Use of malloc implies errno which adds TLS dependencies and prevents use
> of this FDT wrapper library in BSP initialization code. This change
> makes use of rtems_malloc and rtems_calloc which avoid TLS dependencies.
> ---
>  cpukit/libmisc/rtems-fdt/rtems-fdt.c | 13 ++---
>  1 file changed, 6 insertions(+), 7 deletions(-)
> 
> diff --git a/cpukit/libmisc/rtems-fdt/rtems-fdt.c 
> b/cpukit/libmisc/rtems-fdt/rtems-fdt.c
> index 1e382ca108..e5bab21664 100644
> --- a/cpukit/libmisc/rtems-fdt/rtems-fdt.c
> +++ b/cpukit/libmisc/rtems-fdt/rtems-fdt.c
> @@ -25,9 +25,7 @@
>   * POSSIBILITY OF SUCH DAMAGE.
>   */
>  
> -#include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -35,6 +33,7 @@
>  #include 
>  #include 
>  
> +#include 
>  #include 
>  #include 
>  
> @@ -175,13 +174,13 @@ rtems_fdt_init_index (rtems_fdt_handle* fdt, 
> rtems_fdt_blob* blob)
>/*
> * Create the index.
> */
> -  entries = calloc(num_entries, sizeof(rtems_fdt_index_entry));
> +  entries = rtems_calloc(num_entries, sizeof(rtems_fdt_index_entry));
>if (!entries)
>{
>  return -RTEMS_FDT_ERR_NO_MEMORY;
>}
>  
> -  names = calloc(1, total_name_memory);
> +  names = rtems_calloc(1, total_name_memory);
>if (!names)
>{
>  free(entries);
> @@ -505,7 +504,7 @@ rtems_fdt_load (const char* filename, rtems_fdt_handle* 
> handle)
>{
>  size_t offset;
>  
> -cdata = malloc(sb.st_size);
> +cdata = rtems_malloc(sb.st_size);
>  if (!cdata)
>  {
>close (bf);
> @@ -546,7 +545,7 @@ rtems_fdt_load (const char* filename, rtems_fdt_handle* 
> handle)
>  
>name_len = strlen (filename) + 1;
>  
> -  blob = malloc(sizeof (rtems_fdt_blob) + name_len + bsize);
> +  blob = rtems_malloc(sizeof (rtems_fdt_blob) + name_len + bsize);
>if (!blob)
>{
>  free(cdata);
> @@ -649,7 +648,7 @@ rtems_fdt_register (const void* dtb, rtems_fdt_handle* 
> handle)
>  return fe;
>}
>  
> -  blob = malloc(sizeof (rtems_fdt_blob));
> +  blob = rtems_malloc(sizeof (rtems_fdt_blob));
>if (!blob)
>{
>  return -RTEMS_FDT_ERR_NO_MEMORY;
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Use of rtems_fdt_* and sp01

[Chris Johns]

On 18/11/2022 2:39 am, Kinsey Moore wrote:
> I recently added FDT support to the AArch64 ZynqMP BSPs to support an optional
> management console and managing ethernet parameters for LibBSD. Use of the
> rtems_fdt_* functions implies use of malloc which adds 4 bytes in the TLS 
> space.
> The sp01 test uses rtems_task_construct and specifies a maximum TLS size of 0
> bytes which causes a failure which the non-zero TLS size is checked against 
> the
> maximum TLS size of 0.

Does this mean there exists a requirement a BSPs cannot internally use the heap?

Maybe the test needs to be adjusted?
> It appears that other BSPs that use FDT data avoid the rtems_fdt_* calls,
> possibly because they weren’t available until recently, and this is the path
> that I’ll be following to resolve this issue for the moment.
> 
> I thought it would be good to bring this up if the rtems_fdt_* wrappers are to
> be more widely useful.

FDT support seems to be based around isolated BSPs and how they use the FDT. I
guess this approach has been done to minimise the impact on RTEMS and I would
have most likely followed a similar path.

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

Announce: RTEMS 5.2-rc1 Release Candidate

[Chris Johns]

The RTEMS 5.2-rc1 Release Candidate is available. The release can be found at:

 https://ftp.rtems.org/pub/rtems/releases/5/rc/5.2-rc1/

Please follow the release instructions provided by the link. The release notes
can be found here:

 
https://ftp.rtems.org/pub/rtems/releases/5/rc/5.2-rc1/rtems-5.2-rc1-release-notes.html

They detail the changes that have been made on the 5 branch.

If you find a problem please raise a ticket and select the 5.2 milestone. The
simplest way to create a ticket is to head to the developer Wiki at:

 https://devel.rtems.org/

Then click on the "Next (milestone)" link for the RTEMS 5 Release. You will need
an account.

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

Announce: RTEMS 5.2-rc1 Release Candidate

[Chris Johns]

The RTEMS 5.2-rc1 Release Candidate is available. The release can be found at:

 https://ftp.rtems.org/pub/rtems/releases/5/rc/5.2-rc1/

Please follow the release instructions provided by the link. The release notes
can be found here:

 
https://ftp.rtems.org/pub/rtems/releases/5/rc/5.2-rc1/rtems-5.2-rc1-release-notes.html

They detail the change that have been made on the 5 branch.

If you find a problem please raise a ticket and select the 5.2 milestone. The
simplest way to create a ticket is to head to the developer Wiki at:

 https://devel.rtems.org/

Then click on the "Next (milestone)" link for the RTEMS 5 Release. You will need
an account.

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

Re: [PATCH] aarch64/mmu: Prevent block descriptors at level -1

[Chris Johns]

Tested on Versal (A72) and large mappings are now working. I have pushed the 
patch.

Thanks for this. :)

Chris

On 17/11/2022 2:22 am, Kinsey Moore wrote:
> In the original implementation, level -1 was unused and all levels could
> have block-like descriptors (level 2 block descriptors are called page
> descriptors). When support for level -1 page tables was added the
> constraint on level -1 block descriptors was not honored. This prevents
> block descriptors from being mapped at level -1 since the hardware will
> not map them properly.
> ---
>  bsps/aarch64/include/bsp/aarch64-mmu.h | 23 +--
>  1 file changed, 13 insertions(+), 10 deletions(-)
> 
> diff --git a/bsps/aarch64/include/bsp/aarch64-mmu.h 
> b/bsps/aarch64/include/bsp/aarch64-mmu.h
> index 1287c67016..ebc224b9e1 100644
> --- a/bsps/aarch64/include/bsp/aarch64-mmu.h
> +++ b/bsps/aarch64/include/bsp/aarch64-mmu.h
> @@ -243,26 +243,29 @@ BSP_START_TEXT_SECTION static inline rtems_status_code 
> aarch64_mmu_map_block(
>  /* check for perfect block match */
>  if ( block_bottom == addr ) {
>if ( size >= chunk_size ) {
> -/* when page_flag is set the last level must be a page descriptor */
> -if ( page_flag || ( page_table[index] & MMU_DESC_TYPE_TABLE ) != 
> MMU_DESC_TYPE_TABLE ) {
> -  /* no sub-table, apply block properties */
> -  page_table[index] = addr | flags | page_flag;
> -  size -= chunk_size;
> -  addr += chunk_size;
> -  continue;
> +/* level -1 can't contain block descriptors, fall through to 
> subtable */
> +if ( level != -1 ) {
> +  /* when page_flag is set the last level must be a page descriptor 
> */
> +  if ( page_flag || ( page_table[index] & MMU_DESC_TYPE_TABLE ) != 
> MMU_DESC_TYPE_TABLE ) {
> +/* no sub-table, apply block properties */
> +page_table[index] = addr | flags | page_flag;
> +size -= chunk_size;
> +addr += chunk_size;
> +continue;
> +  }
>  }
>} else {
>  /* block starts on a boundary, but is short */
>  chunk_size = size;
>  
> - /* it isn't possible to go beyond page table level 2 */
> - if ( page_flag ) {
> +/* it isn't possible to go beyond page table level 2 */
> +if ( page_flag ) {
>/* no sub-table, apply block properties */
>page_table[index] = addr | flags | page_flag;
>size -= chunk_size;
>addr += chunk_size;
>continue;
> - }
> +}
>}
>  } else {
>uintptr_t block_top = RTEMS_ALIGN_UP( addr, granularity );
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [5 RSB PATCH 3/3] rtems/net-snmp: Update to 5.9.3 with the RTEMS patch

[Chris Johns]

On 15/11/22 3:22 am, Gedare Bloom wrote:
> ok thanks for sorting this out, and for linking the patch through
> trac. You've given me one more thing to check for in RSB patches that
> reference %patch command :)

Thanks for the review and yeah sorry about the extra bit to check. It cannot be
helped.

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

[RBW] Re: WTB: 54cm Losco Handlebar

[JohnS]

Losco's found. Thank you Mack!

JohnS

On Saturday, November 12, 2022 at 2:42:32 PM UTC-5 JohnS wrote:

> Hello All,
>
> I'm in the market for a used 54cm Losco handlebar. My plan is to move my 
> Soma Oxfords to my wife's Shogun mixte and the Losco would be for my '82 
> Stumpjumper. 
>
> Thanks so much,
> JohnS
>

-- 
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/aabefc4b-d383-49eb-8fa1-375d79dfd981n%40googlegroups.com.

[RBW] WTB: 54cm Losco Handlebar

[JohnS]

Hello All,

I'm in the market for a used 54cm Losco handlebar. My plan is to move my 
Soma Oxfords to my wife's Shogun mixte and the Losco would be for my '82 
Stumpjumper. 

Thanks so much,
JohnS

-- 
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/d470e6a4-576b-4222-861b-5d8d971aa8dfn%40googlegroups.com.

Re: [rtems-docs commit] Update build system related sections for RTEMS 6

[Chris Johns]

On 11/11/22 6:39 pm, Sebastian Huber wrote:
> On 10/11/2022 01:30, Chris Johns wrote:
>> The first is the maintenance of embedded the version numbers in the
>> documentation. If we can avoid doing that the work per release or dot release
>> is less.
> 
> We could use a simple search and replace for this. Searching for 'rtems[0-9]'
> shows a couple of spots which need a more through rework. We even have stuff
> with rtems4.10.

That may work for some places but I found it useful to review the documentation
at the same time given things may have changed. In the end I am not fussed how
we make the change. :)

>> The second is the changing of `kernel` to `src`. The use of `kernel` was
>> specific because it removes any ambiguity when a new user attempts to build a
>> package like libbsd in the same tree. Source can mean it is the place where
>> all source is placed. I think `kernel` should be used and returned.
> 
> I usually place all Git repositories in a "src" directory.

Is there a per repo directory under src? I am fine with that. The important
point is having a consistent arrangement that can be used when building other
things like libbsd or the examples without needing to delete or change anything.

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

Re: [PATCH rtems-lwip] rtemslwip: Add note to intentionally blank files

[Chris Johns]

On 11/11/22 8:36 am, Kinsey Moore wrote:
> This should be covered by COPYING.rtemslwip. I would say it isn't worth 
> putting
> it in the intentionally empty files.

Agreed. Copyright of "empty" does not make sense.

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

Re: [PATCH] cpukit/fdt: Fix typos and clarify params

[Chris Johns]

OK.

Thanks
Chris

On 10/11/22 4:01 am, Kinsey Moore wrote:
> ---
>  cpukit/include/rtems/rtems-fdt.h | 24 +++-
>  1 file changed, 15 insertions(+), 9 deletions(-)
> 
> diff --git a/cpukit/include/rtems/rtems-fdt.h 
> b/cpukit/include/rtems/rtems-fdt.h
> index 3919593582..18e04352aa 100644
> --- a/cpukit/include/rtems/rtems-fdt.h
> +++ b/cpukit/include/rtems/rtems-fdt.h
> @@ -256,7 +256,7 @@ int rtems_fdt_register (const void* blob, 
> rtems_fdt_handle* handle);
>  
>  /**
>   * Unload a device tree blob or DTB file and release any memory allocated 
> when
> - * loading. The blob is removed from the list of registered.
> + * loading. The blob is removed from the list if registered.
>   *
>   * @param blob_desc A valid blob descriptor.
>   * @return int If less than 0 it is an error code else 0 is return on 
> success.
> @@ -296,7 +296,7 @@ int rtems_fdt_get_mem_rsv (rtems_fdt_handle* handle,
>   * larger string, such as a full path.
>   *
>   * @param blob_desc A valid blob descriptor.
> - * @param arentoffset Structure block offset of a node
> + * @param parentoffset Structure block offset of a node
>   * @param name Name of the subnode to locate.
>   * @param namelen Number of characters of name to consider.
>   * @return int If less than 0 it is an error code else the node offset is
> @@ -345,7 +345,9 @@ int rtems_fdt_path_offset (rtems_fdt_handle* handle, 
> const char* path);
>   *
>   * @param handle The FDT handle to the current blob.
>   * @param nodeoffset Structure block offset of the starting node.
> - * @param length Pointer to an integer variable (will be overwritten) or 
> NULL.
> + * @param length Pointer to an integer variable or NULL. If non-NULL, this 
> will
> + *   be overwritten with either the length in bytes or the error
> + *   code.
>   * @return const char* The node's name on success or NULL on error. The 
> length
>   * if non-NULL will hold the error code.
>   */
> @@ -378,7 +380,9 @@ int rtems_fdt_next_prop_offset(rtems_fdt_handle* handle, 
> int propoffset);
>   * @param handle The FDT handle to the current blob.
>   * @param propoffset Property offset
>   * @param name If not NULL set the pointer to the name string.
> - * @param length Pointer to an integer variable (will be overwritten) or 
> NULL.
> + * @param length Pointer to an integer variable or NULL. If non-NULL, this 
> will
> + *   be overwritten with either the length in bytes or the error
> + *   code.
>   * @return const void* The node's value data.
>   */
>  const void* rtems_fdt_getprop_by_offset(rtems_fdt_handle* handle,
> @@ -395,8 +399,9 @@ const void* rtems_fdt_getprop_by_offset(rtems_fdt_handle* 
> handle,
>   * @param nodeoffset Offset of the node whose property to find
>   * @param name The name of the property to find
>   * @param namelen The number of characters of name to consider
> - * @param length A pointer to an integer variable (will be overwritten) or
> - *   NULL.
> + * @param length Pointer to an integer variable or NULL. If non-NULL, this 
> will
> + *   be overwritten with either the length in bytes or the error
> + *   code.
>   * @return const void* The node's property on success or NULL on error. The
>   * length if non-NULL will hold the error code.
>   */
> @@ -416,8 +421,9 @@ const void *rtems_fdt_getprop_namelen (rtems_fdt_handle* 
> handle,
>   * @param handle The FDT handle to the current blob.
>   * @param nodeoffset The offset of the node whose property to find.
>   * @param name The name of the property to find.
> - * @param length A pointer to an integer variable (will be overwritten) or
> - *   NULL.
> + * @param length Pointer to an integer variable or NULL. If non-NULL, this 
> will
> + *   be overwritten with either the length in bytes or the error
> + *   code.
>   * @return const void* The node's property on success or NULL on error. The
>   * length if non-NULL will hold the error code.
>   */
> @@ -427,7 +433,7 @@ const void *rtems_fdt_getprop (rtems_fdt_handle* handle,
> int*  length);
>  
>  /**
> - * Retrieve the phandle of a given of the device tree node at structure block
> + * Retrieve the phandle of the device tree node at structure block
>   * offset nodeoffset.
>   *
>   * @param handle The FDT handle to the current blob.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [5 DOCS PATCH] waf: Backport from main build fixes

[Chris Johns]

On 10/11/22 3:40 pm, Gedare Bloom wrote:
> looks fine. i'm not sure where
> +   "review":   ("Gerrit Code Review",
> "https://review.rtems.org/;),
> came from, but I see it in before too.

It came from the initial work Amar did in moving us to the RST format.

There is no service provided and I have not removed the label.

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

Re: [PATCH rtems-libbsd v2 0/3] CFC400X support

[Chris Johns]

Looks good.

Thanks
Chris

On 9/11/2022 4:10 pm, Kinsey Moore wrote:

In this revised patch set, SGMII support has been reworked to use device
trees while preserving existing static instantiation used by Zynq and
Versal BSPs.

___
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: Add Formal Verification chapter v2

[Chris Johns]

On 9/11/2022 9:48 pm, andrew.butterfi...@scss.tcd.ie wrote:

ping

(my fault really, i've let this sit!)



Thank you for raising this and I am sorry we have not been as proactive 
as we should be.



But I have been busy, interacting with a group doing a follow-up IV project 
with the qualification data package we produced.
A conseuience of this is that I am helping them to add two extra manager models 
developed by students, for Barriers and Message Queues.

This would add two more entries to the model guide, and raises the question of 
the best place to document the models.
Is the RTEMS Software Engineering manual the best location for those? If not, 
where should they live?

Another side effect fo all this is that there is now a definitive version of 
the formal models and test generation in a public repo:

https://github.com/andrewbutterfield/RTEMS-SMP-Formal



Excellent.

I have no expertise in this area and I am more than happy to defer to 
you and your team in this area.


I have no objections to this working being merge as is. I see it as 
green field work and yours is the first here. I am sure updates or 
changes can be made over time by you or others as the work is absorbed 
and reviewed.


Thank you for all the efforts you and those with you have made. I 
personally think it is fantastic to have this work happen and being made 
public in this way so thank you from me.


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

Re: [rtems-docs commit] Update build system related sections for RTEMS 6

[Chris Johns]

On 9/11/2022 4:28 pm, Sebastian Huber wrote:

On 09/11/2022 01:35, Chris Johns wrote:


Was this posted for review? I do not remember seeing it?


Yes, on September 12.


Thanks. Sorry, I must have missed it.


There are a number of things that could be improved with this change.


I am sure things can be improved, but removing completely out of date 
stuff can't be that bad.


The change is needed, thanks.

I had a couple of points. Both minor in the context of the needed change.

The first is the maintenance of embedded the version numbers in the 
documentation. If we can avoid doing that the work per release or dot 
release is less.


The second is the changing of `kernel` to `src`. The use of `kernel` was 
specific because it removes any ambiguity when a new user attempts to 
build a package like libbsd in the same tree. Source can mean it is the 
place where all source is placed. I think `kernel` should be used and 
returned.


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

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

[Chris Johns]

Looks good and thank you for sorting out this approach.

Thanks
Chris

On 9/11/2022 8:56 am, Kinsey Moore wrote:

This adds a BSP variant for the ZynqMP BSP family to support the
Innoflight CFC-400X platform. To properly support the CFC-400X, device
trees were added to the ZynqMP platform due to both the optional
management interface as well as alternate physical configuration of the
ethernet interfaces.
---
  bsps/aarch64/xilinx-zynqmp/console/console.c  | 163 +-
  bsps/aarch64/xilinx-zynqmp/fdt/bsp_fdt.c  |  51 ++
  bsps/aarch64/xilinx-zynqmp/fdt/cfc400x.dts| 110 
  bsps/aarch64/xilinx-zynqmp/fdt/cfc400x_dtb.c  | 124 +
  bsps/aarch64/xilinx-zynqmp/fdt/zynqmp.dts |  94 ++
  bsps/aarch64/xilinx-zynqmp/fdt/zynqmp_dtb.c   |  97 +++
  bsps/aarch64/xilinx-zynqmp/include/bsp.h  |  15 ++
  .../aarch64/xilinx-zynqmp/start/bspstartmmu.c |   4 +
  .../aarch64/xilinx-zynqmp/bspcfc400xlp64.yml  |  21 +++
  .../aarch64/xilinx-zynqmp/bspqemuilp32.yml|   2 +
  .../aarch64/xilinx-zynqmp/bspqemulp64.yml |   2 +
  .../aarch64/xilinx-zynqmp/bspzu3egilp32.yml   |   2 +
  .../aarch64/xilinx-zynqmp/bspzu3eglp64.yml|   2 +
  spec/build/bsps/aarch64/xilinx-zynqmp/obj.yml |   1 +
  .../aarch64/xilinx-zynqmp/objfdtcfc400x.yml   |  14 ++
  .../aarch64/xilinx-zynqmp/objfdtzynqmp.yml|  14 ++
  .../bsps/aarch64/xilinx-zynqmp/optloadoff.yml |   1 +
  .../bsps/aarch64/xilinx-zynqmp/optramori.yml  |   1 +
  spec/build/cpukit/optsmp.yml  |   1 +
  19 files changed, 718 insertions(+), 1 deletion(-)
  create mode 100644 bsps/aarch64/xilinx-zynqmp/fdt/bsp_fdt.c
  create mode 100644 bsps/aarch64/xilinx-zynqmp/fdt/cfc400x.dts
  create mode 100644 bsps/aarch64/xilinx-zynqmp/fdt/cfc400x_dtb.c
  create mode 100644 bsps/aarch64/xilinx-zynqmp/fdt/zynqmp.dts
  create mode 100644 bsps/aarch64/xilinx-zynqmp/fdt/zynqmp_dtb.c
  create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/bspcfc400xlp64.yml
  create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/objfdtcfc400x.yml
  create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/objfdtzynqmp.yml

diff --git a/bsps/aarch64/xilinx-zynqmp/console/console.c 
b/bsps/aarch64/xilinx-zynqmp/console/console.c
index d1948f1a0c..d546db8535 100644
--- a/bsps/aarch64/xilinx-zynqmp/console/console.c
+++ b/bsps/aarch64/xilinx-zynqmp/console/console.c
@@ -9,7 +9,7 @@
   */
  
  /*

- * Copyright (C) 2020 On-Line Applications Research Corporation (OAR)
+ * Copyright (C) 2022 On-Line Applications Research Corporation (OAR)
   * Written by Kinsey Moore 
   *
   * Redistribution and use in source and binary forms, with or without
@@ -36,13 +36,165 @@
  
  #include 

  #include 
+#include 
+#include 
  #include 
  
+#include 

+#include 
  #include 
+
  #include 
  
  #include 
  
+#include 

+
+uint32_t mgmt_uart_reg_shift = 0;
+static uint8_t get_register(uintptr_t addr, uint8_t i)
+{
+  volatile uint8_t *reg = (uint8_t *) addr;
+
+  i <<= mgmt_uart_reg_shift;
+  return reg [i];
+}
+
+static void set_register(uintptr_t addr, uint8_t i, uint8_t val)
+{
+  volatile uint8_t *reg = (uint8_t *) addr;
+
+  i <<= mgmt_uart_reg_shift;
+  reg [i] = val;
+}
+
+static ns16550_context zynqmp_mgmt_uart_context = {
+  .base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER("Management UART 0"),
+  .get_reg = get_register,
+  .set_reg = set_register,
+  .port = 0,
+  .irq = 0,
+  .clock = 0,
+  .initial_baud = 0,
+};
+
+__attribute__ ((weak)) void 
zynqmp_configure_management_console(rtems_termios_device_context *base)
+{
+  /* This SLIP-encoded watchdog command sets timeouts to 0x seconds. */
+  const char mgmt_watchdog_cmd[] =
+"\xc0\xda\x00\x00\xff\xff\xff\xff\xff\x00\xff\xff\xff\xffM#\xc0";
+
+  /* Send the system watchdog configuration command */
+  for (int i = 0; i < sizeof(mgmt_watchdog_cmd); i++) {
+ns16550_polled_putchar(base, mgmt_watchdog_cmd[i]);
+  }
+}
+
+static void zynqmp_management_console_init(void)
+{
+  /* Find the management console in the device tree */
+  rtems_fdt_handle fdt_handle;
+  const uint32_t *prop;
+  uint32_t outprop[4];
+  int proplen;
+  int node;
+
+  rtems_fdt_init_handle(_handle);
+  rtems_fdt_register(bsp_fdt_get(), _handle);
+  const char *alias = rtems_fdt_get_alias(_handle, "mgmtport");
+  if (alias == NULL) {
+rtems_fdt_release_handle(_handle);
+return;
+  }
+  node = rtems_fdt_path_offset(_handle, alias);
+
+  prop = rtems_fdt_getprop(_handle, node, "clock-frequency", );
+  if ( prop == NULL || proplen != 4 ) {
+rtems_fdt_release_handle(_handle);
+zynqmp_mgmt_uart_context.port = 0;
+return;
+  }
+  outprop[0] = rtems_uint32_from_big_endian((const uint8_t *) [0]);
+  zynqmp_mgmt_uart_context.clock = outprop[0];
+
+  prop = rtems_fdt_getprop(_handle, node, "current-speed", );
+  if ( prop == NULL || proplen != 4 ) {
+rtems_fdt_release_handle(_handle);
+zynqmp_mgmt_uart_context.port = 0;
+return;
+  }
+  outprop[0] = 

Documentation changes required for release

[Chris Johns]

Hello,

The following was add to the documentation build support for the RTEMS 6 
release to avoid the need for us to perform mindless updates of the 
documentation on each release cycle:


https://git.rtems.org/rtems-docs/tree/README.txt#n604

The text is:

10. Use the following to embed the version number in any part of the
documentation source:

 1. @rtems-version@

The complete version string of the documentation.

 2. @rtems-ver-major@

The version major number.

 2. @rtems-ver-minor@

The version minor number.

 2. @rtems-ver-revision@

The version revision number.

The replacement happens during the source read phase of the build
and is not context specific. The substitution will happen in code
blocks and other normally quoted area.

It is a requirement these be used then embedded commands or
related text in the documentation to let the documentation track
the release. For example `microblaze-rtems6-gdb` should be written
as `microblaze-rtems@rtems-ver-major@-gdb`.

Note, the support for these version number may require some adjustments 
of what is provided in the documentation to aid the text being moved 
across releases without change. There is no hard and fast set of rule so 
please use commonsense. Sometimes less is better but is it a piece by 
piece call.


I would appreciate this being followed rather than it being the 
responsibility of the people perform the release to sort out. It only 
delays the releases.


Thanks
Chris

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

Re: [rtems-docs commit] Update build system related sections for RTEMS 6

[Chris Johns]

Hi,

Was this posted for review? I do not remember seeing it?

There are a number of things that could be improved with this change.

Chris

On 8/11/2022 4:47 pm, Sebastian Huber wrote:

Module:rtems-docs
Branch:master
Commit:31199e3a69d2dbd0a8f360e424fd19f3e9ef66ce
Changeset: 
http://git.rtems.org/rtems-docs/commit/?id=31199e3a69d2dbd0a8f360e424fd19f3e9ef66ce

Author:Sebastian Huber 
Date:  Mon Sep 12 09:10:38 2022 +0200

Update build system related sections for RTEMS 6

Update sections which contained the word "bsp_specs".

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

Re: [PATCH 2/2] c-user/clock: Fix typo

[Chris Johns]

+1

On 8/11/2022 3:26 am, Gedare Bloom wrote:
> ok to both
> 
> On Mon, Nov 7, 2022 at 3:20 AM Matthew Joyce
>  wrote:
>>
>> From: Matt Joyce 
>>
>> ---
>>  c-user/clock/directives.rst | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/c-user/clock/directives.rst b/c-user/clock/directives.rst
>> index 6e1542c..877204a 100644
>> --- a/c-user/clock/directives.rst
>> +++ b/c-user/clock/directives.rst
>> @@ -1222,7 +1222,7 @@ system initialization using :term:`CLOCK_MONOTONIC`.
>>  .. rubric:: PARAMETERS:
>>
>>  ``uptime``
>> -This parameter is the pointer to a `struct timeval
>> +This parameter is the pointer to a `struct timespec
>>  
>> `_
>>  object.  When the directive call is successful, the seconds and 
>> nanoseconds
>>  elapsed since some time point during the system initialization and some
>> --
>> 2.35.3
>>
>> ___
>> 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: 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