Re: RTEMS 6 libbsd, networking issue with xilinx_zynq_zybo_z7 cgem0

[Heinz Junkes]

Hello Kinsey,
thanks for the answer. I am now using the REPHY driver and everything is 
working fine:

diff --git a/rtemsbsd/include/bsp/nexus-devices.h 
b/rtemsbsd/include/bsp/nexus-devices.h
index ac4a52a1..6908ca46 100644
--- a/rtemsbsd/include/bsp/nexus-devices.h
+++ b/rtemsbsd/include/bsp/nexus-devices.h
@@ -100,7 +100,8 @@ RTEMS_BSD_DRIVER_XILINX_ZYNQ_SLCR;
RTEMS_BSD_DRIVER_XILINX_ZYNQ_SDHCI0;
RTEMS_BSD_DRIVER_XILINX_ZYNQ_SDHCI1;
RTEMS_BSD_DRIVER_XILINX_ZYNQ_CGEM0(ZYNQ_IRQ_ETHERNET_0);
-RTEMS_BSD_DRIVER_E1000PHY;
+/* RTEMS_BSD_DRIVER_E1000PHY; */
+RTEMS_BSD_DRIVER_REPHY;
 RTEMS_BSD_DRIVER_MMC;

Heinz


> On 14. Aug 2024, at 19:41, Kinsey Moore  wrote:
>
> Even if that one isn't already used, the generic PHY driver (UKPHY) will work 
> most of the time as long as it's enabled (it isn't by default for the Zynq 
> BSPs). I haven't done much with the Zynq boards, so I won't be of much help. 
> The link you posted mentioned a board frequency change. Have you verified 
> that the default clock hasn't changed for your RevD board?
>
> Kinsey
>
> On Wed, Aug 14, 2024 at 5:14 AM Heinz Junkes  wrote:
> I have a Rev.D board and it has a different Realtek PHY with different 
> connections to MIO Bank.
> RTL8211F instead of RTL8211E
> I have to find out where this is defined/used in the rtems-libbsd.
> Heinz
>
>
> > On 13. Aug 2024, at 17:16, Heinz Junkes  wrote:
> >
> > This is the output of NFS01 Test:
> >
> > *** BEGIN OF TEST LIBBSD NFS 1 ***
> > *** TEST VERSION: 6.0.0.e5b6fa026ac1c07d252233624054785b2b29f54e
> > *** TEST STATE: USER_INPUT
> > *** TEST BUILD: RTEMS_POSIX_API
> > *** TEST TOOLS: 13.3.0 20240521 (RTEMS 6, RSB 
> > 4c6dfb7aef9811258457971aa9213d5aebb9ce8d, Newlib 1ed1516)
> > nexus0: 
> > cgem0:  on nexus0
> > miibus0:  on cgem0
> > info: cgem0: Ethernet address: 92:c2:88:7d:f4:79
> > arasan_sdhci1:  on nexus0
> > arasan_sdhci1-slot0: Hardware doesn't specify base clock frequency, using 
> > 50MHz as default.
> > arasan_sdhci1-slot0: Hardware doesn't specify timeout clock frequency, 
> > setting BROKEN_TIMEOUT quirk.
> > arasan_sdhci1-slot0: Hardware doesn't report any support voltages.
> > arasan_sdhci1: Card Detect failed to stabilize, setting to not present.
> > arasan_sdhci0:  on nexus0
> > arasan_sdhci0-slot0: Hardware doesn't specify base clock frequency, using 
> > 50MHz as default.
> > arasan_sdhci0-slot0: Hardware doesn't specify timeout clock frequency, 
> > setting BROKEN_TIMEOUT quirk.
> > mmc0:  on arasan_sdhci0
> > zy7_slcr0:  on nexus0
> > mmcsd0: 16GB  (read-only) 
> > at mmc0 50.0MHz/4bit/65535-block
> > info: lo0: link state changed to UP
> > add host 141.14.128.128: gateway cgem0
> > add net default: gateway 141.14.128.128
> > error: cgem0: no active link
> > assertion "seconds < 10" failed: file 
> > "../../testsuite/include/rtems/bsd/test/default-network-init.h", line 193, 
> > function: default_wait_for_link_up
> >
> > *** FATAL ***
> > fatal source: 7 (RTEMS_FATAL_SOURCE_ASSERT)
> > fatal code: 3443784 (0x00348c48)
> > RTEMS version: 6.0.0.e5b6fa026ac1c07d252233624054785b2b29f54e
> > RTEMS tools: 13.3.0 20240521 (RTEMS 6, RSB 
> > 4c6dfb7aef9811258457971aa9213d5aebb9ce8d, Newlib 1ed1516)
> > executing thread ID: 0x0a010001
> > executing thread name: UI1
> >
> > Heinz
> >
> >> On 13. Aug 2024, at 16:40, Heinz Junkes  wrote:
> >>
> >> Hi,
> >> unfortunately I cannot activate the cgem0 network interface with RTEMS 6 
> >> (libbsd 6-freebsd-12)
> >> on a xilinx_zynq_zybo_z7 board :
> >>
> >> cgem0: flags�43 metric 0 mtu 1500
> >> d   options�008
> >> e   ether 92:c2:88:7d:f4:79
> >>   inet6 fe80::90c2:88ff:fe7d:f479%cgem0 prefixlen 64 scopeid 0x1
> >> b   inet 141.14.128.72 netmask 0xf000 broadcast 141.14.143.255
> >> u   nd6 options!
> >> ifconfig: cgem0: ngo media types?: cgem0: sending ARP announce (1 of 2), 
> >> next in 2.0 seconds
> >>
> >>
> >> These messages appear during startup :
> >>
> >> * Initializing network (libbsd, dhcpcd) *
> >> nexus0: 
> >> cgem0:  on nexus0
> >> miibus0:  on cgem0
> >> info: cgem0: Ethernet address: 92:c2:88:7d:f4:79
> >> arasan_sdhci1:  on nexus0
> >> arasan_sdhci1-slot0: Hardware doesn't specify base clock frequency, using 
> >> 50MHz as default.
> >> arasan_sdhci1-slot0: Hardware doesn't specify timeout clock frequency, 
> >> setting BROKEN_TIMEOUT quirk.
> >> arasan_sdhci1-slot0: Hardware doesn't report any support voltages.
> >> arasan_sdhci1: Card Detect failed to stabilize, setting to not present.
> >> arasan_sdhci0:  on nexus0
> >> arasan_sdhci0-slot0: Hardware doesn't specify base clock frequency, using 
> >> 50MHz as default.
> >> arasan_sdhci0-slot0: Hardware doesn't specify timeout clock frequency, 
> >> setting BROKEN_TIMEOUT quirk.
> >> mmc0:  on arasan_sdhci0
> >> zy7_slcr0:  on nexus0
> >> mmcsd0: 16GB  (read-only) 
> >> at mmc0 50.0MHz/4bit/65535-block
> >>
> >> I have already found a suitable entry here, but unfortunately I don't know 
> >> how it 'fits' my problem:
> >> https://lists.rtems.

Re: RTEMS 6 libbsd, networking issue with xilinx_zynq_zybo_z7 cgem0

[Kinsey Moore]

Even if that one isn't already used, the generic PHY driver (UKPHY) will
work most of the time as long as it's enabled (it isn't by default for the
Zynq BSPs). I haven't done much with the Zynq boards, so I won't be of much
help. The link you posted mentioned a board frequency change. Have you
verified that the default clock hasn't changed for your RevD board?

Kinsey

On Wed, Aug 14, 2024 at 5:14 AM Heinz Junkes 
wrote:

> I have a Rev.D board and it has a different Realtek PHY with different
> connections to MIO Bank.
> RTL8211F instead of RTL8211E
> I have to find out where this is defined/used in the rtems-libbsd.
> Heinz
>
>
> > On 13. Aug 2024, at 17:16, Heinz Junkes 
> wrote:
> >
> > This is the output of NFS01 Test:
> >
> > *** BEGIN OF TEST LIBBSD NFS 1 ***
> > *** TEST VERSION: 6.0.0.e5b6fa026ac1c07d252233624054785b2b29f54e
> > *** TEST STATE: USER_INPUT
> > *** TEST BUILD: RTEMS_POSIX_API
> > *** TEST TOOLS: 13.3.0 20240521 (RTEMS 6, RSB
> 4c6dfb7aef9811258457971aa9213d5aebb9ce8d, Newlib 1ed1516)
> > nexus0: 
> > cgem0:  on nexus0
> > miibus0:  on cgem0
> > info: cgem0: Ethernet address: 92:c2:88:7d:f4:79
> > arasan_sdhci1:  on nexus0
> > arasan_sdhci1-slot0: Hardware doesn't specify base clock frequency,
> using 50MHz as default.
> > arasan_sdhci1-slot0: Hardware doesn't specify timeout clock frequency,
> setting BROKEN_TIMEOUT quirk.
> > arasan_sdhci1-slot0: Hardware doesn't report any support voltages.
> > arasan_sdhci1: Card Detect failed to stabilize, setting to not present.
> > arasan_sdhci0:  on nexus0
> > arasan_sdhci0-slot0: Hardware doesn't specify base clock frequency,
> using 50MHz as default.
> > arasan_sdhci0-slot0: Hardware doesn't specify timeout clock frequency,
> setting BROKEN_TIMEOUT quirk.
> > mmc0:  on arasan_sdhci0
> > zy7_slcr0:  on nexus0
> > mmcsd0: 16GB 
> (read-only) at mmc0 50.0MHz/4bit/65535-block
> > info: lo0: link state changed to UP
> > add host 141.14.128.128: gateway cgem0
> > add net default: gateway 141.14.128.128
> > error: cgem0: no active link
> > assertion "seconds < 10" failed: file
> "../../testsuite/include/rtems/bsd/test/default-network-init.h", line 193,
> function: default_wait_for_link_up
> >
> > *** FATAL ***
> > fatal source: 7 (RTEMS_FATAL_SOURCE_ASSERT)
> > fatal code: 3443784 (0x00348c48)
> > RTEMS version: 6.0.0.e5b6fa026ac1c07d252233624054785b2b29f54e
> > RTEMS tools: 13.3.0 20240521 (RTEMS 6, RSB
> 4c6dfb7aef9811258457971aa9213d5aebb9ce8d, Newlib 1ed1516)
> > executing thread ID: 0x0a010001
> > executing thread name: UI1
> >
> > Heinz
> >
> >> On 13. Aug 2024, at 16:40, Heinz Junkes 
> wrote:
> >>
> >> Hi,
> >> unfortunately I cannot activate the cgem0 network interface with RTEMS
> 6 (libbsd 6-freebsd-12)
> >> on a xilinx_zynq_zybo_z7 board :
> >>
> >> cgem0: flags=8843 metric 0 mtu
> 1500
> >> d   options=80008
> >> e   ether 92:c2:88:7d:f4:79
> >>   inet6 fe80::90c2:88ff:fe7d:f479%cgem0 prefixlen 64 scopeid 0x1
> >> b   inet 141.14.128.72 netmask 0xf000 broadcast 141.14.143.255
> >> u   nd6 options=21
> >> ifconfig: cgem0: ngo media types?: cgem0: sending ARP announce (1 of
> 2), next in 2.0 seconds
> >>
> >>
> >> These messages appear during startup :
> >>
> >> * Initializing network (libbsd, dhcpcd) *
> >> nexus0: 
> >> cgem0:  on nexus0
> >> miibus0:  on cgem0
> >> info: cgem0: Ethernet address: 92:c2:88:7d:f4:79
> >> arasan_sdhci1:  on nexus0
> >> arasan_sdhci1-slot0: Hardware doesn't specify base clock frequency,
> using 50MHz as default.
> >> arasan_sdhci1-slot0: Hardware doesn't specify timeout clock frequency,
> setting BROKEN_TIMEOUT quirk.
> >> arasan_sdhci1-slot0: Hardware doesn't report any support voltages.
> >> arasan_sdhci1: Card Detect failed to stabilize, setting to not present.
> >> arasan_sdhci0:  on nexus0
> >> arasan_sdhci0-slot0: Hardware doesn't specify base clock frequency,
> using 50MHz as default.
> >> arasan_sdhci0-slot0: Hardware doesn't specify timeout clock frequency,
> setting BROKEN_TIMEOUT quirk.
> >> mmc0:  on arasan_sdhci0
> >> zy7_slcr0:  on nexus0
> >> mmcsd0: 16GB 
> (read-only) at mmc0 50.0MHz/4bit/65535-block
> >>
> >> I have already found a suitable entry here, but unfortunately I don't
> know how it 'fits' my problem:
> >> https://lists.rtems.org/pipermail/users/2023-July/068855.html
> >>
> >>
> >> Danke Heinz___
> >> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS 6 libbsd, networking issue with xilinx_zynq_zybo_z7 cgem0

[Heinz Junkes]

I have a Rev.D board and it has a different Realtek PHY with different 
connections to MIO Bank.
RTL8211F instead of RTL8211E
I have to find out where this is defined/used in the rtems-libbsd.
Heinz


> On 13. Aug 2024, at 17:16, Heinz Junkes  wrote:
>
> This is the output of NFS01 Test:
>
> *** BEGIN OF TEST LIBBSD NFS 1 ***
> *** TEST VERSION: 6.0.0.e5b6fa026ac1c07d252233624054785b2b29f54e
> *** TEST STATE: USER_INPUT
> *** TEST BUILD: RTEMS_POSIX_API
> *** TEST TOOLS: 13.3.0 20240521 (RTEMS 6, RSB 
> 4c6dfb7aef9811258457971aa9213d5aebb9ce8d, Newlib 1ed1516)
> nexus0: 
> cgem0:  on nexus0
> miibus0:  on cgem0
> info: cgem0: Ethernet address: 92:c2:88:7d:f4:79
> arasan_sdhci1:  on nexus0
> arasan_sdhci1-slot0: Hardware doesn't specify base clock frequency, using 
> 50MHz as default.
> arasan_sdhci1-slot0: Hardware doesn't specify timeout clock frequency, 
> setting BROKEN_TIMEOUT quirk.
> arasan_sdhci1-slot0: Hardware doesn't report any support voltages.
> arasan_sdhci1: Card Detect failed to stabilize, setting to not present.
> arasan_sdhci0:  on nexus0
> arasan_sdhci0-slot0: Hardware doesn't specify base clock frequency, using 
> 50MHz as default.
> arasan_sdhci0-slot0: Hardware doesn't specify timeout clock frequency, 
> setting BROKEN_TIMEOUT quirk.
> mmc0:  on arasan_sdhci0
> zy7_slcr0:  on nexus0
> mmcsd0: 16GB  (read-only) at 
> mmc0 50.0MHz/4bit/65535-block
> info: lo0: link state changed to UP
> add host 141.14.128.128: gateway cgem0
> add net default: gateway 141.14.128.128
> error: cgem0: no active link
> assertion "seconds < 10" failed: file 
> "../../testsuite/include/rtems/bsd/test/default-network-init.h", line 193, 
> function: default_wait_for_link_up
>
> *** FATAL ***
> fatal source: 7 (RTEMS_FATAL_SOURCE_ASSERT)
> fatal code: 3443784 (0x00348c48)
> RTEMS version: 6.0.0.e5b6fa026ac1c07d252233624054785b2b29f54e
> RTEMS tools: 13.3.0 20240521 (RTEMS 6, RSB 
> 4c6dfb7aef9811258457971aa9213d5aebb9ce8d, Newlib 1ed1516)
> executing thread ID: 0x0a010001
> executing thread name: UI1
>
> Heinz
>
>> On 13. Aug 2024, at 16:40, Heinz Junkes  wrote:
>>
>> Hi,
>> unfortunately I cannot activate the cgem0 network interface with RTEMS 6 
>> (libbsd 6-freebsd-12)
>> on a xilinx_zynq_zybo_z7 board :
>>
>> cgem0: flagsˆ43 metric 0 mtu 1500
>> d   options€008
>> e   ether 92:c2:88:7d:f4:79
>>   inet6 fe80::90c2:88ff:fe7d:f479%cgem0 prefixlen 64 scopeid 0x1
>> b   inet 141.14.128.72 netmask 0xf000 broadcast 141.14.143.255
>> u   nd6 options!
>> ifconfig: cgem0: ngo media types?: cgem0: sending ARP announce (1 of 2), 
>> next in 2.0 seconds
>>
>>
>> These messages appear during startup :
>>
>> * Initializing network (libbsd, dhcpcd) *
>> nexus0: 
>> cgem0:  on nexus0
>> miibus0:  on cgem0
>> info: cgem0: Ethernet address: 92:c2:88:7d:f4:79
>> arasan_sdhci1:  on nexus0
>> arasan_sdhci1-slot0: Hardware doesn't specify base clock frequency, using 
>> 50MHz as default.
>> arasan_sdhci1-slot0: Hardware doesn't specify timeout clock frequency, 
>> setting BROKEN_TIMEOUT quirk.
>> arasan_sdhci1-slot0: Hardware doesn't report any support voltages.
>> arasan_sdhci1: Card Detect failed to stabilize, setting to not present.
>> arasan_sdhci0:  on nexus0
>> arasan_sdhci0-slot0: Hardware doesn't specify base clock frequency, using 
>> 50MHz as default.
>> arasan_sdhci0-slot0: Hardware doesn't specify timeout clock frequency, 
>> setting BROKEN_TIMEOUT quirk.
>> mmc0:  on arasan_sdhci0
>> zy7_slcr0:  on nexus0
>> mmcsd0: 16GB  (read-only) at 
>> mmc0 50.0MHz/4bit/65535-block
>>
>> I have already found a suitable entry here, but unfortunately I don't know 
>> how it 'fits' my problem:
>> https://lists.rtems.org/pipermail/users/2023-July/068855.html
>>
>>
>> Danke Heinz___
>> 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




smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS 6 libbsd, networking issue with xilinx_zynq_zybo_z7 cgem0

[Heinz Junkes]

This is the output of NFS01 Test:

*** BEGIN OF TEST LIBBSD NFS 1 ***
*** TEST VERSION: 6.0.0.e5b6fa026ac1c07d252233624054785b2b29f54e
*** TEST STATE: USER_INPUT
*** TEST BUILD: RTEMS_POSIX_API
*** TEST TOOLS: 13.3.0 20240521 (RTEMS 6, RSB 
4c6dfb7aef9811258457971aa9213d5aebb9ce8d, Newlib 1ed1516)
nexus0: 
cgem0:  on nexus0
miibus0:  on cgem0
info: cgem0: Ethernet address: 92:c2:88:7d:f4:79
arasan_sdhci1:  on nexus0
arasan_sdhci1-slot0: Hardware doesn't specify base clock frequency, using 50MHz 
as default.
arasan_sdhci1-slot0: Hardware doesn't specify timeout clock frequency, setting 
BROKEN_TIMEOUT quirk.
arasan_sdhci1-slot0: Hardware doesn't report any support voltages.
arasan_sdhci1: Card Detect failed to stabilize, setting to not present.
arasan_sdhci0:  on nexus0
arasan_sdhci0-slot0: Hardware doesn't specify base clock frequency, using 50MHz 
as default.
arasan_sdhci0-slot0: Hardware doesn't specify timeout clock frequency, setting 
BROKEN_TIMEOUT quirk.
mmc0:  on arasan_sdhci0
zy7_slcr0:  on nexus0
mmcsd0: 16GB  (read-only) at 
mmc0 50.0MHz/4bit/65535-block
info: lo0: link state changed to UP
add host 141.14.128.128: gateway cgem0
add net default: gateway 141.14.128.128
error: cgem0: no active link
assertion "seconds < 10" failed: file 
"../../testsuite/include/rtems/bsd/test/default-network-init.h", line 193, 
function: default_wait_for_link_up

*** FATAL ***
fatal source: 7 (RTEMS_FATAL_SOURCE_ASSERT)
fatal code: 3443784 (0x00348c48)
RTEMS version: 6.0.0.e5b6fa026ac1c07d252233624054785b2b29f54e
RTEMS tools: 13.3.0 20240521 (RTEMS 6, RSB 
4c6dfb7aef9811258457971aa9213d5aebb9ce8d, Newlib 1ed1516)
executing thread ID: 0x0a010001
executing thread name: UI1

Heinz

> On 13. Aug 2024, at 16:40, Heinz Junkes  wrote:
>
> Hi,
> unfortunately I cannot activate the cgem0 network interface with RTEMS 6 
> (libbsd 6-freebsd-12)
> on a xilinx_zynq_zybo_z7 board :
>
> cgem0: flagsˆ43 metric 0 mtu 1500
> d   options€008
> e   ether 92:c2:88:7d:f4:79
>inet6 fe80::90c2:88ff:fe7d:f479%cgem0 prefixlen 64 scopeid 0x1
> b   inet 141.14.128.72 netmask 0xf000 broadcast 141.14.143.255
> u   nd6 options!
> ifconfig: cgem0: ngo media types?: cgem0: sending ARP announce (1 of 2), next 
> in 2.0 seconds
>
>
> These messages appear during startup :
>
> * Initializing network (libbsd, dhcpcd) *
> nexus0: 
> cgem0:  on nexus0
> miibus0:  on cgem0
> info: cgem0: Ethernet address: 92:c2:88:7d:f4:79
> arasan_sdhci1:  on nexus0
> arasan_sdhci1-slot0: Hardware doesn't specify base clock frequency, using 
> 50MHz as default.
> arasan_sdhci1-slot0: Hardware doesn't specify timeout clock frequency, 
> setting BROKEN_TIMEOUT quirk.
> arasan_sdhci1-slot0: Hardware doesn't report any support voltages.
> arasan_sdhci1: Card Detect failed to stabilize, setting to not present.
> arasan_sdhci0:  on nexus0
> arasan_sdhci0-slot0: Hardware doesn't specify base clock frequency, using 
> 50MHz as default.
> arasan_sdhci0-slot0: Hardware doesn't specify timeout clock frequency, 
> setting BROKEN_TIMEOUT quirk.
> mmc0:  on arasan_sdhci0
> zy7_slcr0:  on nexus0
> mmcsd0: 16GB  (read-only) at 
> mmc0 50.0MHz/4bit/65535-block
>
> I have already found a suitable entry here, but unfortunately I don't know 
> how it 'fits' my problem:
> https://lists.rtems.org/pipermail/users/2023-July/068855.html
>
>
> Danke Heinz___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel




smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS 6 branching

[Chris Johns]

On 25/4/2024 12:06 am, Peter Dufault wrote:
>> On Apr 24, 2024, at 9:27 AM, Kinsey Moore  wrote:
>>
>> That use case definitely wasn't considered for rtems-lwip and I don't know 
>> that it's ever been discussed. If that were intended, I'd expect a "./waf 
>> uninstall" target to exist that would remove the installed network stack so 
>> that you could install a different one since the different stacks install 
>> vastly different sets of headers. IIRC, Chris advocates for installing the 
>> network libraries into a different location than the installed BSP to allow 
>> you to choose which you want at a later time.
>>
> 
> I've been moving a driver from legacy to bsd so I definitely need to easily 
> switch back and forth for the same BSP for testing.
> 
> I agree with Chris, but it's apparently a desirement, not a requirement, so 
> it shouldn't hold up the branching.

Agreed. It would be nice but is it something user would really want or use? I
get there are use cases like the one you raise but a single installed network
stack in a single install prefix makes it easier to write build system checks to
detect the type of stack. I have applications that can switch between legacy and
libbsd and that is important when migrating stacks and debugging.

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

Re: RTEMS 6 branching

[Peter Dufault]

> On Apr 24, 2024, at 9:27 AM, Kinsey Moore  wrote:
> 
> That use case definitely wasn't considered for rtems-lwip and I don't know 
> that it's ever been discussed. If that were intended, I'd expect a "./waf 
> uninstall" target to exist that would remove the installed network stack so 
> that you could install a different one since the different stacks install 
> vastly different sets of headers. IIRC, Chris advocates for installing the 
> network libraries into a different location than the installed BSP to allow 
> you to choose which you want at a later time.
> 
> Kinsey

I've been moving a driver from legacy to bsd so I definitely need to easily 
switch back and forth for the same BSP for testing.

I agree with Chris, but it's apparently a desirement, not a requirement, so it 
shouldn't hold up the branching.

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



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

Re: RTEMS 6 branching

[Kinsey Moore]

On Wed, Apr 24, 2024 at 6:43 AM Peter Dufault  wrote:

> > On Apr 23, 2024, at 5:45 PM, Vijay Kumar Banerjee 
> wrote:
> > On Tue, Apr 23, 2024 at 1:02 PM Joel Sherrill  wrote:
> >
> >
> > On Tue, Apr 23, 2024, 12:56 PM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> > - Am 21. Apr 2024 um 3:00 schrieb Chris Johns chr...@rtems.org:
> >
> > > Hi,
> > >
> > > There has been some discussion about when we will branch and it is
> timely we
> > > discuss this. This is my input. :)
> > >
> > > While I create the releases I am not solely responsible for milestone
> dates or
> > > thresholds for a release.
> > >
> > > Please test the RC snaphots on our ftp server. Saying you have is as
> important
> > > as reporting issues.
> > >
> > > 1. Are all the things need for the release resolved? Tickets reviewed?
> >
> > It would be nice to have the interrupt get/set priority API in RTEMS 6.
> The Cortex-M floating point issue is not yet fixed in the RTEMS master.
> >
> > There should be time to get it in. The Gitlab transition needs to be
> complete before the branch is cut.
> >
> > >
> > > 2. The tickets are now in GitLab and locked down in Trac so how does
> that work
> > > if we make a release now? I do not think it does.
> > >
> > > 3. GitLab is going to happen soon so do we take this moment in time
> and make 6
> > > with GitLab and learn what we need to do easing dot releases that
> always follow?
> > > If we do not we may end up with 6.1 and then 6.2 that has differences.
> >
> > We should definitely wait with the release after the Gitlab migration is
> done and some basic CI is running.
> >
> > I don't think holding a release for CI is needed. We have the same basic
> quality and testing we have now.
> >
> > Requiring more work and improvements just moves the release bar.
> >
> > That said, we do need to get some CI processes in place. Hopefully
> between 6.1 and 6.2, we will have at least one or two BSPs required to
> build.
> >
> > >
> > > 4. GitLab breaks the release scripts for the release notes
> (ChangeLog). Amar and
> > > I have discussed a few options but we are yet to test and settle on
> anything. As
> > > is the case with these things easy is often is a series of small
> things that
> > > take time to get right.
> > >
> > > 5. Have the docs been reviewed for RTEMS 5 vs RTEMS 6 changes? Are
> they updated
> > > for a separated legacy network stack, net services and waf building?
> >
> > Ryan and Ray worked on the autoconf to waf documentation changes a
> couple of years ago.
> >
> > I have no idea what impact the separated Network stacks have on the
> documentation.
> >
> > The legacy networking docs are separated now with instructions on how to
> build them using waf:
> > https://docs.rtems.org/branches/master/legacy-networking/index.html
> >
> > We might need to mention in the user manual that there is no default
> networking stack anymore and the user needs to build the network stack
> separately.
>
> I do (or did, haven't checked lately) have an issue that if I "./waf
> install" one of the network stacks, probably "libbsd", that I can't then
> switch back and forth.  I think a header file got installed that broke
> things.  Don't know if that was fixed, I've just been careful to not
> install either stack so I can switch.
>
> Is that a bug?  Should I figure out what the problem was and report it?
>

That use case definitely wasn't considered for rtems-lwip and I don't know
that it's ever been discussed. If that were intended, I'd expect a "./waf
uninstall" target to exist that would remove the installed network stack so
that you could install a different one since the different stacks install
vastly different sets of headers. IIRC, Chris advocates for installing the
network libraries into a different location than the installed BSP to allow
you to choose which you want at a later time.

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

Re: RTEMS 6 branching

[Peter Dufault]

> On Apr 23, 2024, at 5:45 PM, Vijay Kumar Banerjee  wrote:
> 
> 
> 
> On Tue, Apr 23, 2024 at 1:02 PM Joel Sherrill  wrote:
> 
> 
> On Tue, Apr 23, 2024, 12:56 PM Sebastian Huber 
>  wrote:
> - Am 21. Apr 2024 um 3:00 schrieb Chris Johns chr...@rtems.org:
> 
> > Hi,
> > 
> > There has been some discussion about when we will branch and it is timely we
> > discuss this. This is my input. :)
> > 
> > While I create the releases I am not solely responsible for milestone dates 
> > or
> > thresholds for a release.
> > 
> > Please test the RC snaphots on our ftp server. Saying you have is as 
> > important
> > as reporting issues.
> > 
> > 1. Are all the things need for the release resolved? Tickets reviewed?
> 
> It would be nice to have the interrupt get/set priority API in RTEMS 6. The 
> Cortex-M floating point issue is not yet fixed in the RTEMS master.
> 
> There should be time to get it in. The Gitlab transition needs to be complete 
> before the branch is cut. 
> 
> > 
> > 2. The tickets are now in GitLab and locked down in Trac so how does that 
> > work
> > if we make a release now? I do not think it does.
> > 
> > 3. GitLab is going to happen soon so do we take this moment in time and 
> > make 6
> > with GitLab and learn what we need to do easing dot releases that always 
> > follow?
> > If we do not we may end up with 6.1 and then 6.2 that has differences.
> 
> We should definitely wait with the release after the Gitlab migration is done 
> and some basic CI is running.
> 
> I don't think holding a release for CI is needed. We have the same basic 
> quality and testing we have now.
> 
> Requiring more work and improvements just moves the release bar. 
> 
> That said, we do need to get some CI processes in place. Hopefully between 
> 6.1 and 6.2, we will have at least one or two BSPs required to build.
> 
> > 
> > 4. GitLab breaks the release scripts for the release notes (ChangeLog). 
> > Amar and
> > I have discussed a few options but we are yet to test and settle on 
> > anything. As
> > is the case with these things easy is often is a series of small things that
> > take time to get right.
> > 
> > 5. Have the docs been reviewed for RTEMS 5 vs RTEMS 6 changes? Are they 
> > updated
> > for a separated legacy network stack, net services and waf building?
> 
> Ryan and Ray worked on the autoconf to waf documentation changes a couple of 
> years ago.
> 
> I have no idea what impact the separated Network stacks have on the 
> documentation.
> 
> The legacy networking docs are separated now with instructions on how to 
> build them using waf:
> https://docs.rtems.org/branches/master/legacy-networking/index.html
> 
> We might need to mention in the user manual that there is no default 
> networking stack anymore and the user needs to build the network stack 
> separately.

I do (or did, haven't checked lately) have an issue that if I "./waf install" 
one of the network stacks, probably "libbsd", that I can't then switch back and 
forth.  I think a header file got installed that broke things.  Don't know if 
that was fixed, I've just been careful to not install either stack so I can 
switch.

Is that a bug?  Should I figure out what the problem was and report it?

> 
> > 6. I have a few small patches to push and then an update to the RSB to pick
> > those changes up before I can create RC4.
> 
> I recently checked in a fix for powerpc and the AArch64 multilib changes for 
> Cortex-A53 in GCC 13. To pick this up, the GCC commit needs to be updated. 
> Maybe we should even wait for the GCC 13.3 release.
> 
> I asked about a gcc 13.3 release and we should not wait. They intend to do a 
> 14 release before returning to 13.3. We should plan to do 6.1 with a GCC 13 
> branch hash and probably plan to swap that out with a 13.3 tarball when it's 
> released. 
> 
> We are good at imposing more requirements. :)
> 
> 


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



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

Re: RTEMS 6 branching

[Vijay Kumar Banerjee]

On Tue, Apr 23, 2024 at 1:02 PM Joel Sherrill  wrote:

>
>
> On Tue, Apr 23, 2024, 12:56 PM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> - Am 21. Apr 2024 um 3:00 schrieb Chris Johns chr...@rtems.org:
>>
>> > Hi,
>> >
>> > There has been some discussion about when we will branch and it is
>> timely we
>> > discuss this. This is my input. :)
>> >
>> > While I create the releases I am not solely responsible for milestone
>> dates or
>> > thresholds for a release.
>> >
>> > Please test the RC snaphots on our ftp server. Saying you have is as
>> important
>> > as reporting issues.
>> >
>> > 1. Are all the things need for the release resolved? Tickets reviewed?
>>
>> It would be nice to have the interrupt get/set priority API in RTEMS 6.
>> The Cortex-M floating point issue is not yet fixed in the RTEMS master.
>>
>
> There should be time to get it in. The Gitlab transition needs to be
> complete before the branch is cut.
>
>>
>> >
>> > 2. The tickets are now in GitLab and locked down in Trac so how does
>> that work
>> > if we make a release now? I do not think it does.
>> >
>> > 3. GitLab is going to happen soon so do we take this moment in time and
>> make 6
>> > with GitLab and learn what we need to do easing dot releases that
>> always follow?
>> > If we do not we may end up with 6.1 and then 6.2 that has differences.
>>
>> We should definitely wait with the release after the Gitlab migration is
>> done and some basic CI is running.
>>
>
> I don't think holding a release for CI is needed. We have the same basic
> quality and testing we have now.
>
> Requiring more work and improvements just moves the release bar.
>
> That said, we do need to get some CI processes in place. Hopefully between
> 6.1 and 6.2, we will have at least one or two BSPs required to build.
>
>>
>> >
>> > 4. GitLab breaks the release scripts for the release notes (ChangeLog).
>> Amar and
>> > I have discussed a few options but we are yet to test and settle on
>> anything. As
>> > is the case with these things easy is often is a series of small things
>> that
>> > take time to get right.
>> >
>> > 5. Have the docs been reviewed for RTEMS 5 vs RTEMS 6 changes? Are they
>> updated
>> > for a separated legacy network stack, net services and waf building?
>>
>
> Ryan and Ray worked on the autoconf to waf documentation changes a couple
> of years ago.
>
> I have no idea what impact the separated Network stacks have on the
> documentation.
>

The legacy networking docs are separated now with instructions on how to
build them using waf:
https://docs.rtems.org/branches/master/legacy-networking/index.html

We might need to mention in the user manual that there is no default
networking stack anymore and the user needs to build the network stack
separately.

>
> > 6. I have a few small patches to push and then an update to the RSB to
>> pick
>> > those changes up before I can create RC4.
>>
>> I recently checked in a fix for powerpc and the AArch64 multilib changes
>> for Cortex-A53 in GCC 13. To pick this up, the GCC commit needs to be
>> updated. Maybe we should even wait for the GCC 13.3 release.
>>
>
> I asked about a gcc 13.3 release and we should not wait. They intend to do
> a 14 release before returning to 13.3. We should plan to do 6.1 with a GCC
> 13 branch hash and probably plan to swap that out with a 13.3 tarball when
> it's released.
>
> We are good at imposing more requirements. :)
>
>
>
>
>> >
>> >
>> > Thanks
>> > Chris
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>>
>> --
>> embedded brains GmbH & Co. KG
>> Herr Sebastian HUBER
>> Dornierstr. 4
>> 82178 Puchheim
>> Germany
>> email: sebastian.hu...@embedded-brains.de
>> phone: +49-89-18 94 741 - 16
>> fax:   +49-89-18 94 741 - 08
>>
>> Registergericht: Amtsgericht München
>> Registernummer: HRB 157899
>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>> Unsere Datenschutzerklärung finden Sie hier:
>> https://embedded-brains.de/datenschutzerklaerung/
>> ___
>> 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: RTEMS 6 branching

[Joel Sherrill]

On Tue, Apr 23, 2024, 12:56 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> - Am 21. Apr 2024 um 3:00 schrieb Chris Johns chr...@rtems.org:
>
> > Hi,
> >
> > There has been some discussion about when we will branch and it is
> timely we
> > discuss this. This is my input. :)
> >
> > While I create the releases I am not solely responsible for milestone
> dates or
> > thresholds for a release.
> >
> > Please test the RC snaphots on our ftp server. Saying you have is as
> important
> > as reporting issues.
> >
> > 1. Are all the things need for the release resolved? Tickets reviewed?
>
> It would be nice to have the interrupt get/set priority API in RTEMS 6.
> The Cortex-M floating point issue is not yet fixed in the RTEMS master.
>

There should be time to get it in. The Gitlab transition needs to be
complete before the branch is cut.

>
> >
> > 2. The tickets are now in GitLab and locked down in Trac so how does
> that work
> > if we make a release now? I do not think it does.
> >
> > 3. GitLab is going to happen soon so do we take this moment in time and
> make 6
> > with GitLab and learn what we need to do easing dot releases that always
> follow?
> > If we do not we may end up with 6.1 and then 6.2 that has differences.
>
> We should definitely wait with the release after the Gitlab migration is
> done and some basic CI is running.
>

I don't think holding a release for CI is needed. We have the same basic
quality and testing we have now.

Requiring more work and improvements just moves the release bar.

That said, we do need to get some CI processes in place. Hopefully between
6.1 and 6.2, we will have at least one or two BSPs required to build.

>
> >
> > 4. GitLab breaks the release scripts for the release notes (ChangeLog).
> Amar and
> > I have discussed a few options but we are yet to test and settle on
> anything. As
> > is the case with these things easy is often is a series of small things
> that
> > take time to get right.
> >
> > 5. Have the docs been reviewed for RTEMS 5 vs RTEMS 6 changes? Are they
> updated
> > for a separated legacy network stack, net services and waf building?
>

Ryan and Ray worked on the autoconf to waf documentation changes a couple
of years ago.

I have no idea what impact the separated Network stacks have on the
documentation.

> 6. I have a few small patches to push and then an update to the RSB to
> pick
> > those changes up before I can create RC4.
>
> I recently checked in a fix for powerpc and the AArch64 multilib changes
> for Cortex-A53 in GCC 13. To pick this up, the GCC commit needs to be
> updated. Maybe we should even wait for the GCC 13.3 release.
>

I asked about a gcc 13.3 release and we should not wait. They intend to do
a 14 release before returning to 13.3. We should plan to do 6.1 with a GCC
13 branch hash and probably plan to swap that out with a 13.3 tarball when
it's released.

We are good at imposing more requirements. :)




> >
> >
> > Thanks
> > Chris
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
> --
> embedded brains GmbH & Co. KG
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> ___
> 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: RTEMS 6 branching

[Sebastian Huber]

- Am 21. Apr 2024 um 3:00 schrieb Chris Johns chr...@rtems.org:

> Hi,
> 
> There has been some discussion about when we will branch and it is timely we
> discuss this. This is my input. :)
> 
> While I create the releases I am not solely responsible for milestone dates or
> thresholds for a release.
> 
> Please test the RC snaphots on our ftp server. Saying you have is as important
> as reporting issues.
> 
> 1. Are all the things need for the release resolved? Tickets reviewed?

It would be nice to have the interrupt get/set priority API in RTEMS 6. The 
Cortex-M floating point issue is not yet fixed in the RTEMS master.

> 
> 2. The tickets are now in GitLab and locked down in Trac so how does that work
> if we make a release now? I do not think it does.
> 
> 3. GitLab is going to happen soon so do we take this moment in time and make 6
> with GitLab and learn what we need to do easing dot releases that always 
> follow?
> If we do not we may end up with 6.1 and then 6.2 that has differences.

We should definitely wait with the release after the Gitlab migration is done 
and some basic CI is running.

> 
> 4. GitLab breaks the release scripts for the release notes (ChangeLog). Amar 
> and
> I have discussed a few options but we are yet to test and settle on anything. 
> As
> is the case with these things easy is often is a series of small things that
> take time to get right.
> 
> 5. Have the docs been reviewed for RTEMS 5 vs RTEMS 6 changes? Are they 
> updated
> for a separated legacy network stack, net services and waf building?
> 
> 6. I have a few small patches to push and then an update to the RSB to pick
> those changes up before I can create RC4.

I recently checked in a fix for powerpc and the AArch64 multilib changes for 
Cortex-A53 in GCC 13. To pick this up, the GCC commit needs to be updated. 
Maybe we should even wait for the GCC 13.3 release.

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

-- 
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS 6 and GCC 10 Status

[Chris Johns]

On 7/7/20 11:03 pm, Sebastian Huber wrote:
> On 05/07/2020 19:13, Joel Sherrill wrote:
>> Should these be the first entries in the RTEMS 6 release description?
> 
> I added:
> 
> https://github.com/RTEMS/rtems-release/blob/master/rtems-notes-6.txt

Thank you.

> Should we rename this file to rtems-notes-6.md?

Yes this makes sense now the source is MD. You will need to update ...

https://git.rtems.org/rtems-release/tree/rtems-release#n101

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

Re: RTEMS 6 and GCC 10 Status

[Joel Sherrill]

On Tue, Jul 7, 2020 at 8:03 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 05/07/2020 19:13, Joel Sherrill wrote:
> > Good job!
> >
> > Should these be the first entries in the RTEMS 6 release description?
>
> I added:
>
> https://github.com/RTEMS/rtems-release/blob/master/rtems-notes-6.txt
>
> Should we rename this file to rtems-notes-6.md?
>

If it is really markdown and that's how it will be used, I suppose it makes
sense.

Besides, it we change our mind, it isn't a big deal to change it again. :)

>
> I added also a migration from v5 to v6 section for the user manual.
>

+1

>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS 6 and GCC 10 Status

[Sebastian Huber]

On 05/07/2020 19:13, Joel Sherrill wrote:

Good job!

Should these be the first entries in the RTEMS 6 release description?


I added:

https://github.com/RTEMS/rtems-release/blob/master/rtems-notes-6.txt

Should we rename this file to rtems-notes-6.md?

I added also a migration from v5 to v6 section for the user manual.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

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

Re: RTEMS 6 and GCC 10 Status

[Joel Sherrill]

Good job!

Should these be the first entries in the RTEMS 6 release description?

On Sun, Jul 5, 2020, 11:12 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> I removed the powerpc SPE BSP variants and the epiphany target support.
> I was able to build all remaining BSPs with GCC 10 with the samples
> enabled.
>
> ___
> 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: RTEMS 6

[Chris Johns]

On 30/6/20 5:44 pm, Sebastian Huber wrote:

Hello,

I updated the version numbers in rtems, rtems-docs, rtems-tools, and 
rtems-source-builder to RTEMS 6 on the master branches. I added also a 
ticket for the version change:


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

The release process documentation should be up to date.



It looks good. Thank you.

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

Re: RTEMS 6

[Sebastian Huber]

Hello,

I updated the version numbers in rtems, rtems-docs, rtems-tools, and 
rtems-source-builder to RTEMS 6 on the master branches. I added also a 
ticket for the version change:


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

The release process documentation should be up to date.

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

Re: RTEMS 6

[Gedare Bloom]

On Sun, Jun 28, 2020 at 11:21 PM Sebastian Huber
 wrote:
>
> On 27/06/2020 23:34, Joel Sherrill wrote:
>
> >
> > Should I prepare a GCC 10 based RTEMS 6 tool chain now? This will
> > require a couple of GCC machine option changes for powerpc and arm.
> >
> >
> > Are you killing spe BSPs?
>
> Yes and powerpc/virtex (not powerpc/virtex5):
>
> https://devel.rtems.org/ticket/3550
>
> https://devel.rtems.org/ticket/3951
>
> >
> > Should we remove the obsolete architectures and BSPs before or
> > after the
> > build system integration?
> >
> >
> > Epiphany is the only architecture I know that had taken to tier 4 and
> > removal discussed. What else do you have in mind and why?
>
> Only epiphany and powerpcspe.
>
> https://devel.rtems.org/ticket/3941
>
> Some cleanup of m32c:
>
> https://devel.rtems.org/ticket/3613
>

I also remember some discussion about superh.

> ___
> 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: RTEMS 6

[Sebastian Huber]

Hello,

I updated the RSB to build an RTEMS 6 tool chain based on the GCC 10 
release branch. I added also an unstable RTEMS 7 tool chain based on the 
GCC master.


For Binutils, GDB and Newlib the master branches are used.

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

Re: RTEMS 6

[Sebastian Huber]

On 27/06/2020 23:34, Joel Sherrill wrote:



Should I prepare a GCC 10 based RTEMS 6 tool chain now? This will
require a couple of GCC machine option changes for powerpc and arm.


Are you killing spe BSPs?


Yes and powerpc/virtex (not powerpc/virtex5):

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

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



Should we remove the obsolete architectures and BSPs before or
after the
build system integration?


Epiphany is the only architecture I know that had taken to tier 4 and 
removal discussed. What else do you have in mind and why?


Only epiphany and powerpcspe.

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

Some cleanup of m32c:

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

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

Re: RTEMS 6

[Chris Johns]

On 28/6/20 7:34 am, Joel Sherrill wrote:
On Fri, Jun 26, 2020, 1:11 PM Sebastian Huber 
> wrote:

in the rtems-release repository we have a rtems-notes-5.txt file.
Should
I already add an rtems-notes-6.txt so that we can build up this file
already during the development cycle?

A human written record will be better than hundreds of tickets. 
Summarised and more useful.


Please add rtems-notes-6.txt.

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

Re: RTEMS 6

[Joel Sherrill]

On Fri, Jun 26, 2020, 1:11 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> in the rtems-release repository we have a rtems-notes-5.txt file. Should
> I already add an rtems-notes-6.txt so that we can build up this file
> already during the development cycle?
>

A human written record will be better than hundreds of tickets. Summarised
and more useful.

We also need to be careful to backport big fixes to 5.x. This release
series will be the foundation of a projects I expect. We didn't do a good
job of dot releases on 4.11 IMO.


> Should I prepare a GCC 10 based RTEMS 6 tool chain now? This will
> require a couple of GCC machine option changes for powerpc and arm.
>

Are you killing spe BSPs?

>
> Should we remove the obsolete architectures and BSPs before or after the
> build system integration?
>

Epiphany is the only architecture I know that had taken to tier 4 and
removal discussed. What else do you have in mind and why?


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