[PATCH] spec/aarch64: Enable previously disabled tests

2021-03-08 Thread Alex White
This enables several testsuites that were initially disabled during
development.
---
 spec/build/bsps/aarch64/a53/tsta53.yml| 10 +-
 spec/build/bsps/aarch64/xilinx-zynqmp/tstqemu.yml | 10 +-
 2 files changed, 2 insertions(+), 18 deletions(-)

diff --git a/spec/build/bsps/aarch64/a53/tsta53.yml 
b/spec/build/bsps/aarch64/a53/tsta53.yml
index 4e5f28add1..6876d23f56 100644
--- a/spec/build/bsps/aarch64/a53/tsta53.yml
+++ b/spec/build/bsps/aarch64/a53/tsta53.yml
@@ -37,13 +37,5 @@ default: null
 default-by-variant: []
 description: ''
 enabled-by: true
-links:
-- role: build-dependency
-  uid: ../../tstnoiconv
-- role: build-dependency
-  uid: ../../tstnojffs2
-- role: build-dependency
-  uid: ../../tstnolibdl
-- role: build-dependency
-  uid: ../../tstnorfs
+links: []
 type: build
diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/tstqemu.yml 
b/spec/build/bsps/aarch64/xilinx-zynqmp/tstqemu.yml
index 2053dfd217..80d338fda1 100644
--- a/spec/build/bsps/aarch64/xilinx-zynqmp/tstqemu.yml
+++ b/spec/build/bsps/aarch64/xilinx-zynqmp/tstqemu.yml
@@ -37,13 +37,5 @@ default: null
 default-by-variant: []
 description: ''
 enabled-by: true
-links:
-- role: build-dependency
-  uid: ../../tstnoiconv
-- role: build-dependency
-  uid: ../../tstnojffs2
-- role: build-dependency
-  uid: ../../tstnolibdl
-- role: build-dependency
-  uid: ../../tstnorfs
+links: []
 type: build
-- 
2.27.0

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


Re: [PATCH] spec/aarch64: Enable previously disabled tests

2021-03-08 Thread Sebastian Huber

On 08/03/2021 16:30, Alex White wrote:


This enables several testsuites that were initially disabled during
development.

Looks good, thanks.

--
embedded brains GmbH
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: [PATCH 0/2] Import ehci_pci

2021-03-08 Thread Jan.Sommer
Could someone please approve this patchset (and ideally the similar ones for 
6-freebsd-12 and 5-freebsd-12)?
They only import the files for the USB flash drive support from FreeBSD without 
any RTEMS related changes.

Best regards,

Jan


> -Original Message-
> From: devel  On Behalf Of
> gabriel.moy...@dlr.de
> Sent: Monday, February 22, 2021 12:44 PM
> To: devel@rtems.org
> Subject: AW: [PATCH 0/2] Import ehci_pci
> 
> Sorry, I have forgotten to mention that this patch is for the master
> 
> -Ursprüngliche Nachricht-
> Von: Moyano Heredia, Victor Gabriel
> Gesendet: Montag, 22. Februar 2021 11:53
> An: devel@rtems.org
> Cc: Moyano Heredia, Victor Gabriel 
> Betreff: [PATCH 0/2] Import ehci_pci
> 
> Import ehci_pci from freebsd-org using freebsd-to-rtems.py
> 
> Moyano, Gabriel (2):
>   ehci_pci: Import from freebsd-org
>   ehci_pci: Add to build system
> 
>  freebsd/sys/dev/usb/controller/ehci_pci.c | 593
> ++
>  freebsd/sys/dev/usb/usb_pci.h |  43 ++
>  libbsd.py |   2 +
>  3 files changed, 638 insertions(+)
>  create mode 100644 freebsd/sys/dev/usb/controller/ehci_pci.c
>  create mode 100644 freebsd/sys/dev/usb/usb_pci.h
> 
> --
> 2.17.1
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [PATCH 0/2] Import ehci_pci

2021-03-08 Thread Sebastian Huber

On 08/03/2021 16:38, jan.som...@dlr.de wrote:


Could someone please approve this patchset (and ideally the similar ones for 
6-freebsd-12 and 5-freebsd-12)?
They only import the files for the USB flash drive support from FreeBSD without 
any RTEMS related changes.

The changes are fine.

--
embedded brains GmbH
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: [PATCH 00/26] leon: various fixes and TN0018 errata workaround

2021-03-08 Thread Joel Sherrill
On Sun, Mar 7, 2021 at 9:51 AM Daniel Hellstrom  wrote:

> On 2020-09-23 17:05, Gedare Bloom wrote:
>
> On Wed, Sep 23, 2020 at 4:34 AM Daniel Hellstrom  
>  wrote:
>
> Hi Sebastian,
>
> Thanks for asking and sorry for dropping the ball on these.
>
> The status is that two needs updating (BSD license for new CAN files and
> the last tn0018 patch needs some redesign based on feedback) and the
> others are accepted for master. I've sent an response on the tn0018
> errata patch just now. I would like to push them on the 5 and master
> branches. To get them onto 5, should  I create a ticket for the whole
> patch set? I will try getting this done next next couple of days, and
> have a look at you patches too, thanks!
>
>
> It would be good to separate them logically to the TN-0018 errata
> fixes vs the CAN/grlib improvements. The concern for pushing them to 5
> is that they touch core sparc files, but since you guys are releasing
> them this way in RCC I'm also comfortable with it. I didn't see any
> changes outside the sparc (since currently grlib is sparc-specific
> too). We'll need those tickets to help us with the dot-release notes.
>
> Sorry for my very late response. There were some more updates on a few of
> the patches based on the review comments which has been addressed. I have
> now created tickets for all of them which are referenced from the patches,
> so I will go ahead and push them for the 5-branch (the posted patches
> targeted 5).
>

I agree with Gedare on trusting the patches. My only concern is making sure
proper tickets are filed. A couple of guidelines may help decide how many
tickets and for what.

The first thing to remember is that tickets are automatically processed
into release notes. If it is important enough to show up in a release note,
file a ticket. I have been prodding Ryan to file tickets for the Coverity
issues because I think they should be in release notes.

For 5, any changes should have tickets. This is a long standing rule for
release branches.

> However, I will wait with the TN-0018 before I get an acknowledge for that
> one. I updated the its ticket with links to the GCC patch that has now been
> accepted into upstreams GCC (GCC-10 stable and master). The TN0018 patch is
> not enabled if the GCC-patch is not included in the toolchain, so I believe
> it should be ok to push, even before RSB is updated?
>

It sounds like it will be ok.

What happens with TN0018 on the 5 branch where we are using older tools?

> https://devel.rtems.org/ticket/4155
>
> Next step for me is to add some configurations for the new build system
> before I can push them to RTEMS/master.
>

Thanks for submitting all these. Is this going to clean your queue?

--joel

> Thanks,
> /Daniel
>
>
> Kind Regards,
> Daniel
>
> On 2020-09-18 10:03, Sebastian Huber wrote:
>
> Hallo Daniel,
>
> what are your plans with respect to this patch set?
>
> Please also have a look at:
> https://lists.rtems.org/pipermail/devel/2020-September/062176.html
>
> ___
> devel mailing listdevel@rtems.orghttp://lists.rtems.org/mailman/listinfo/devel
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH 0/2] Import ehci_pci

2021-03-08 Thread Jan.Sommer


> -Original Message-
> From: Sebastian Huber 
> Sent: Monday, March 8, 2021 4:42 PM
> To: Sommer, Jan ; Moyano Heredia, Victor Gabriel
> ; devel@rtems.org
> Subject: Re: [PATCH 0/2] Import ehci_pci
> 
> On 08/03/2021 16:38, jan.som...@dlr.de wrote:
> 
> > Could someone please approve this patchset (and ideally the similar ones
> for 6-freebsd-12 and 5-freebsd-12)?
> > They only import the files for the USB flash drive support from FreeBSD
> without any RTEMS related changes.
> The changes are fine.
> 

Thanks, pushed.

> --
> embedded brains GmbH
> 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: RSB build issue with rtems-libbsd

2021-03-08 Thread Chris Johns
On 6/3/21 2:24 pm, Vijay Kumar Banerjee wrote:
> Hello,
> 
> I'm getting the following error when trying to build rtems-libbsd from
> RSB. Is there anything that I'm missing?
> 
> ```
> ../source-builder/sb-set-builder --prefix=$RTEMS6_PREFIX
> 6/rtems-libbsd --host=powerpc-rtems6 --with-rtems-bsp=beatnik
> RTEMS Source Builder - Set Builder, 6 (102cb1e6450f)
> warning: exe: absolute exe found in path: (__chown) /usr/sbin/chown
> Build Set: 6/rtems-libbsd
> config: tools/rtems-libbsd-6.cfg
> error: rtems-bsp.cfg:155: invalid %if operator:  -mcpu=7400
> -I/home/vijay/development/rtems/6/powerpc-rtems6/beatnik/lib/include

This looks like a bug. Please raise a ticket.

> ==
> Build FAILED
> Build Set: Time 0:00:00.046141
> Build FAILED
> 
> ```
> 
> Commenting these checks from rtems-bsp.cfg gets it building.

Unfortunately the checks are needed and this is not the answer.

I wonder how Jennifer has been building libbsd. She is working on this BSP and
libbsd.

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


Re: [PATCH rtems-net-legacy] netlegacy: Build libtelnetd.a and install header file in correct location

2021-03-08 Thread Chris Johns
On 6/3/21 6:18 am, Vijay Kumar Banerjee wrote:
> Pushed. :)

I did not see any vc posts and the archive does not show any. Are the repo's
hooks working?

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


Re: [PATCH rtems-net-legacy] netlegacy: Build libtelnetd.a and install header file in correct location

2021-03-08 Thread Vijay Kumar Banerjee
On Mon, Mar 8, 2021 at 3:06 PM Chris Johns  wrote:
>
> On 6/3/21 6:18 am, Vijay Kumar Banerjee wrote:
> > Pushed. :)
>
> I did not see any vc posts and the archive does not show any. Are the repo's
> hooks working?
>
https://lists.rtems.org/pipermail/vc/2021-March/035534.html
> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [PATCH rtems-net-legacy] netlegacy: Build libtelnetd.a and install header file in correct location

2021-03-08 Thread Joel Sherrill
On Fri, Mar 5, 2021, 1:07 PM Gedare Bloom  wrote:

> On Fri, Mar 5, 2021 at 11:42 AM Vijay Kumar Banerjee 
> wrote:
> >
> > ---
> >  netlegacy.py | 27 +--
> >  testsuites/telnetd01/wscript |  2 +-
> >  2 files changed, 22 insertions(+), 7 deletions(-)
> >
> > diff --git a/netlegacy.py b/netlegacy.py
> > index 037e2ee..0889548 100644
> > --- a/netlegacy.py
> > +++ b/netlegacy.py
> > @@ -31,7 +31,8 @@ import os
> >
> >  source_files = []
> >  include_files = {}
> > -exclude_dirs = ['pppd', 'nfsclient', 'testsuites', 'librpc/include',
> 'bsps']
> > +exclude_dirs = ['pppd', 'nfsclient', 'testsuites', 'librpc/include',
> 'bsps',
> > +'telnetd']
> >  exclude_headers = ['rtems-bsd-user-space.h', 'rtems-bsd-kernel-space.h']
> >
> >  for root, dirs, files in os.walk("."):
> > @@ -51,6 +52,8 @@ def build(bld):
> >  bsp = bld.env.RTEMS_ARCH_BSP.split('-')[-1]
> >  pppd_source = [os.path.join('./pppd', s)
> > for s in os.listdir('./pppd') if s[-2:] == '.c']
> > +telnetd_source = [os.path.join('./telnetd', s)
> > +  for s in os.listdir('telnetd') if s[-2:] == '.c']
> >
> >  bsp_dirs, bsp_sources = bsp_drivers.bsp_files(bld)
> >
> > @@ -98,12 +101,24 @@ def build(bld):
> >use='networking',
> >source=pppd_source)
> >
> > +bld.stlib(target='telnetd',
> > +  features='c',
> > +  includes=ip,
> > +  use='networking',
> > +  source=telnetd_source)
> > +
> >  bld.install_files(os.path.join('${PREFIX}', arch_lib_path),
> > -  ["libnetworking.a"])
> > -bld.install_files(os.path.join('${PREFIX}', arch_lib_path),
> > +  ["libnetworking.a", 'libpppd.a', 'libtelnetd.a'])
> > +bld.install_files(os.path.join('${PREFIX}', arch_lib_path,
> > +   'include', 'libchip'),
> >[os.path.join('./bsps/include/libchip/', f)
> >for f in os.listdir('./bsps/include/libchip/')])
> >  for i in include_files:
> > -bld.install_files(os.path.join('${PREFIX}',
> > -  arch_lib_path, i),
> > -  include_files[i])
> > +if 'include' in i.split('/'):
> > +bld.install_files(os.path.join('${PREFIX}',
> > +   arch_lib_path, i),
> > +  include_files[i])
> > +else:
> > +bld.install_files(os.path.join('${PREFIX}',
> > +   arch_lib_path, 'include', i),
> > +  include_files[i])
> > diff --git a/testsuites/telnetd01/wscript b/testsuites/telnetd01/wscript
> > index 8a48b90..fd573be 100644
> > --- a/testsuites/telnetd01/wscript
> > +++ b/testsuites/telnetd01/wscript
> > @@ -42,5 +42,5 @@ def build(bld):
> >  features='c cprogram',
> >  cfags=['-O2', '-g'],
> unrelated: should this be cflags?
>
> go ahead and push the fix, you can be a little bit aggressive for a
> few days to get this repo "stable"
>


Agreed.


> >  includes='. .. ../include ../../ ../../include',
> > -use=['networking'],
> > +use=['telnetd', 'networking'],
> >  source='init.c')
> > --
> > 2.26.2
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RSB build issue with rtems-libbsd

2021-03-08 Thread Joel Sherrill
On Mon, Mar 8, 2021, 4:02 PM Chris Johns  wrote:

> On 6/3/21 2:24 pm, Vijay Kumar Banerjee wrote:
> > Hello,
> >
> > I'm getting the following error when trying to build rtems-libbsd from
> > RSB. Is there anything that I'm missing?
> >
> > ```
> > ../source-builder/sb-set-builder --prefix=$RTEMS6_PREFIX
> > 6/rtems-libbsd --host=powerpc-rtems6 --with-rtems-bsp=beatnik
> > RTEMS Source Builder - Set Builder, 6 (102cb1e6450f)
> > warning: exe: absolute exe found in path: (__chown) /usr/sbin/chown
> > Build Set: 6/rtems-libbsd
> > config: tools/rtems-libbsd-6.cfg
> > error: rtems-bsp.cfg:155: invalid %if operator:  -mcpu=7400
> > -I/home/vijay/development/rtems/6/powerpc-rtems6/beatnik/lib/include
>
> This looks like a bug. Please raise a ticket.
>
> > ==
> > Build FAILED
> > Build Set: Time 0:00:00.046141
> > Build FAILED
> >
> > ```
> >
> > Commenting these checks from rtems-bsp.cfg gets it building.
>
> Unfortunately the checks are needed and this is not the answer.
>
> I wonder how Jennifer has been building libbsd. She is working on this BSP
> and
> libbsd.
>

Directly with waf.

--joel

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

Re: [PATCH rtems-net-legacy] netlegacy: Build libtelnetd.a and install header file in correct location

2021-03-08 Thread Chris Johns
On 9/3/21 9:10 am, Vijay Kumar Banerjee wrote:
> On Mon, Mar 8, 2021 at 3:06 PM Chris Johns  wrote:
>>
>> On 6/3/21 6:18 am, Vijay Kumar Banerjee wrote:
>>> Pushed. :)
>>
>> I did not see any vc posts and the archive does not show any. Are the repo's
>> hooks working?
>>
> https://lists.rtems.org/pipermail/vc/2021-March/035534.html

Excellent and thanks. I found it, I needed to scroll back a bit to find the 
link.

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


[PATCH v1 5/7] ck: Update for ILP32

2021-03-08 Thread Kinsey Moore
libck assumes all AArch64 pointers are 8 bytes. This adds the required
defines to handle 4 byte pointers on ILP32.
---
 freebsd/sys/contrib/ck/include/gcc/aarch64/ck_pr.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/freebsd/sys/contrib/ck/include/gcc/aarch64/ck_pr.h 
b/freebsd/sys/contrib/ck/include/gcc/aarch64/ck_pr.h
index e739c4d5..ceac0fea 100644
--- a/freebsd/sys/contrib/ck/include/gcc/aarch64/ck_pr.h
+++ b/freebsd/sys/contrib/ck/include/gcc/aarch64/ck_pr.h
@@ -111,7 +111,11 @@ CK_PR_FENCE(unlock, CK_DMB_SY)
}
 
 
+#ifdef __ILP32__
+CK_PR_LOAD(ptr, void, void *, "ldr")
+#else
 CK_PR_LOAD_64(ptr, void, void *, "ldr")
+#endif
 
 #define CK_PR_LOAD_S(S, T, I) CK_PR_LOAD(S, T, T, I)
 #define CK_PR_LOAD_S_64(S, T, I) CK_PR_LOAD_64(S, T, T, I)
@@ -156,7 +160,11 @@ CK_PR_LOAD_S_64(double, double, "ldr")
return; \
}
 
+#ifdef __ILP32__
+CK_PR_STORE(ptr, void, const void *, "str")
+#else
 CK_PR_STORE_64(ptr, void, const void *, "str")
+#endif
 
 #define CK_PR_STORE_S(S, T, I) CK_PR_STORE(S, T, T, I)
 #define CK_PR_STORE_S_64(S, T, I) CK_PR_STORE_64(S, T, T, I)
-- 
2.20.1

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


[PATCH v1 4/7] nexus: Add ZynqMP SLCR driver

2021-03-08 Thread Kinsey Moore
Add a System Level Control Register driver for the Xilinx Zynq
Ultrascale+ MPSoC with basic clock control functionality for use with
the Cadence GEM. This also removes the Zynq-7000 clock control weakref
from compilation depending on the BSP in use.
---
 freebsd/sys/arm/xilinx/zy7_slcr.c |   3 +
 libbsd.py |   1 +
 rtemsbsd/include/bsp/nexus-devices.h  |   1 +
 .../include/machine/rtems-bsd-nexus-bus.h |  21 ++
 rtemsbsd/sys/arm64/xilinx/zynqmp_slcr.c   | 233 ++
 rtemsbsd/sys/arm64/xilinx/zynqmp_slcr.h   |  90 +++
 6 files changed, 349 insertions(+)
 create mode 100644 rtemsbsd/sys/arm64/xilinx/zynqmp_slcr.c
 create mode 100644 rtemsbsd/sys/arm64/xilinx/zynqmp_slcr.h

diff --git a/freebsd/sys/arm/xilinx/zy7_slcr.c 
b/freebsd/sys/arm/xilinx/zy7_slcr.c
index 79fccee5..4bbdb626 100644
--- a/freebsd/sys/arm/xilinx/zy7_slcr.c
+++ b/freebsd/sys/arm/xilinx/zy7_slcr.c
@@ -45,6 +45,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #ifdef __rtems__
 #include 
+#include 
 #endif /* __rtems__ */
 #include 
 #include 
@@ -217,6 +218,7 @@ zy7_slcr_postload_pl(int en_level_shifters)
ZSLCR_UNLOCK(sc);
 }
 
+#if defined(LIBBSP_ARM_XILINX_ZYNQ_BSP_H)
 /* Override cgem_set_refclk() in gigabit ethernet driver
  * (sys/dev/cadence/if_cgem.c).  This function is called to
  * request a change in the gem's reference clock speed.
@@ -264,6 +266,7 @@ cgem_set_ref_clk(int unit, int frequency)
 
return (0);
 }
+#endif /* LIBBSP_ARM_XILINX_ZYNQ_BSP_H */
 
 /* 
  * PL clocks management function
diff --git a/libbsd.py b/libbsd.py
index 28617d21..16e81565 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -1423,6 +1423,7 @@ class dev_net(builder.Module):
 self.addRTEMSKernelSourceFiles(
 [
 'sys/dev/mii/ksz8091rnb_50MHz.c',
+'sys/arm64/xilinx/zynqmp_slcr.c',
 ],
 mm.generator['source']()
 )
diff --git a/rtemsbsd/include/bsp/nexus-devices.h 
b/rtemsbsd/include/bsp/nexus-devices.h
index 7cdd5428..ea8fa7d7 100644
--- a/rtemsbsd/include/bsp/nexus-devices.h
+++ b/rtemsbsd/include/bsp/nexus-devices.h
@@ -107,6 +107,7 @@ RTEMS_BSD_DRIVER_MMC;
 
 #include 
 
+RTEMS_BSD_DRIVER_XILINX_ZYNQMP_SLCR;
 /* Qemu only applies user-mode networking to the first interface by default, so
  * all 4 CGEM instances must be configured in the Qemu arguments using
  * "-nic user,model=cadence_gem" for each nic.
diff --git a/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h 
b/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h
index 5c95d2c3..bb5546a6 100644
--- a/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h
+++ b/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h
@@ -38,6 +38,7 @@
  *
  *  Devices:
  *   RTEMS_BSD_DRIVER_XILINX_ZYNQ_SLCR
+ *   RTEMS_BSD_DRIVER_XILINX_ZYNQMP_SLCR
  *   RTEMS_BSD_DRIVER_LPC32XX_PWR
  *   RTEMS_BSD_DRIVER_LPC32XX_TSC
  *
@@ -117,6 +118,26 @@ extern "C" {
   &zy7_slcr_res[0])
 #endif /* RTEMS_BSD_DRIVER_XILINX_ZYNQ_SLCR */
 
+/*
+ * Xilinx ZynqMP System Level Control Registers (SLCR).
+ */
+#if !defined(RTEMS_BSD_DRIVER_XILINX_ZYNQMP_SLCR)
+  /*
+   * Hard IP part of the ZynqMP so a fixed address.
+   */
+  #define RTEMS_BSD_DRIVER_XILINX_ZYNQMP_SLCR\
+static const rtems_bsd_device_resource zynqmp_slcr_res[] = {  \
+  { \
+.type = RTEMS_BSD_RES_MEMORY,   \
+.start_request = 0, \
+.start_actual = 0xf000  \
+  } \
+};  \
+RTEMS_BSD_DEFINE_NEXUS_DEVICE(zynqmp_slcr, 0,  \
+  RTEMS_ARRAY_SIZE(zynqmp_slcr_res),  \
+  &zynqmp_slcr_res[0])
+#endif /* RTEMS_BSD_DRIVER_XILINX_ZYNQMP_SLCR */
+
 /*
  * Xilinx Zynq Arasan SDIO Driver.
  */
diff --git a/rtemsbsd/sys/arm64/xilinx/zynqmp_slcr.c 
b/rtemsbsd/sys/arm64/xilinx/zynqmp_slcr.c
new file mode 100644
index ..ac52d234
--- /dev/null
+++ b/rtemsbsd/sys/arm64/xilinx/zynqmp_slcr.c
@@ -0,0 +1,233 @@
+#include 
+
+/*-
+ * SPDX-License-Identifier: BSD-2-Clause-FreeBSD
+ *
+ * Copyright (c) 2021 Kinsey Moore
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the dist

[PATCH v1 3/7] nexus: Switch ZynqMP platforms to CGEM3

2021-03-08 Thread Kinsey Moore
Similar to the UARTs, ZynqMP hardware platforms use the highest
memory-mapped CGEM peripheral as the primary instance of that
peripheral. This change allows operation on hardware as well as QEMU.
---
 rtemsbsd/include/bsp/nexus-devices.h | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/rtemsbsd/include/bsp/nexus-devices.h 
b/rtemsbsd/include/bsp/nexus-devices.h
index c3c43dc9..7cdd5428 100644
--- a/rtemsbsd/include/bsp/nexus-devices.h
+++ b/rtemsbsd/include/bsp/nexus-devices.h
@@ -107,7 +107,14 @@ RTEMS_BSD_DRIVER_MMC;
 
 #include 
 
-RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM0(ZYNQMP_IRQ_ETHERNET_0);
+/* Qemu only applies user-mode networking to the first interface by default, so
+ * all 4 CGEM instances must be configured in the Qemu arguments using
+ * "-nic user,model=cadence_gem" for each nic.
+ *
+ * CGEM3 is used for LibBSD because all Zynq Ultrascale+ MPSoC dev boards treat
+ * the highest-mapped CGEM as the primary interface.
+ */
+RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM3(ZYNQMP_IRQ_ETHERNET_3);
 RTEMS_BSD_DRIVER_E1000PHY;
 
 #elif defined(LIBBSP_ARM_ATSAM_BSP_H)
-- 
2.20.1

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


[PATCH v1 1/7] rtembsd: Fix alignment of allocations for 64bit

2021-03-08 Thread Kinsey Moore
Alignment on 64bit hardware is strict in comparison to running in an
emulator. This resolves an alignment exception when allocating memory on
real hardware.
---
 rtemsbsd/rtems/rtems-program.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/rtemsbsd/rtems/rtems-program.c b/rtemsbsd/rtems/rtems-program.c
index 204ed248..370609d4 100644
--- a/rtemsbsd/rtems/rtems-program.c
+++ b/rtemsbsd/rtems/rtems-program.c
@@ -479,12 +479,13 @@ rtems_bsd_program_alloc(size_t size, void *org_ptr)
void *ptr = NULL;
size_t size_with_list;
size_t size_alligned;
+   size_t alignment = sizeof(void*);
 
if (prog_ctrl != NULL) {
/* align the end to the next word address */
size_alligned = size;
-   if ((size_alligned & 0x3) != 0) {
-   size_alligned = (size_alligned | 0x03) + 1;
+   if ((size_alligned & (alignment - 1)) != 0) {
+   size_alligned = (size_alligned | (alignment - 1)) + 1;
}
size_with_list = size_alligned +
sizeof(struct program_allocmem_item);
-- 
2.20.1

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


[PATCH v1 2/7] if_cgem: Add support for ZynqMP CGEM

2021-03-08 Thread Kinsey Moore
This is a port of the latest patch in FreeBSD that adds support for
64bit CGEMs as used in ZynqMP. This does not include the work necessary
for support on RISC-V systems.
---
 freebsd/sys/dev/cadence/if_cgem.c| 241 ++-
 freebsd/sys/dev/cadence/if_cgem_hw.h |  45 +
 2 files changed, 284 insertions(+), 2 deletions(-)

diff --git a/freebsd/sys/dev/cadence/if_cgem.c 
b/freebsd/sys/dev/cadence/if_cgem.c
index 34340f22..34df7ac7 100644
--- a/freebsd/sys/dev/cadence/if_cgem.c
+++ b/freebsd/sys/dev/cadence/if_cgem.c
@@ -81,6 +81,10 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 
+#if defined(__LP64__) || defined(__ILP32__)
+#define CGEM64
+#endif
+
 #include 
 
 #include 
@@ -127,8 +131,14 @@ struct cgem_softc {
void*intrhand;
struct callout  tick_ch;
uint32_tnet_ctl_shadow;
+#ifdef __rtems__
+   uint32_tnet_cfg_shadow;
+   int neednullqs;
+#endif /* __rtems__ */
int ref_clk_num;
+#ifndef __rtems__
u_char  eaddr[6];
+#endif /* __rtems__ */
 
bus_dma_tag_t   desc_dma_tag;
bus_dma_tag_t   mbuf_dma_tag;
@@ -161,12 +171,18 @@ struct cgem_softc {
int txring_hd_ptr;  /* where to put next xmits */
int txring_tl_ptr;  /* next xmit mbuf to free */
int txring_queued;  /* num xmits segs queued */
+#ifndef __rtems__
bus_dmamap_ttxring_dma_map;
+#endif /* __rtems__ */
u_int   txfull; /* tx ring full events */
u_int   txdefrags;  /* tx calls to m_defrag() */
u_int   txdefragfails;  /* tx m_defrag() failures */
u_int   txdmamapfails;  /* tx dmamap failures */
 
+   /* null descriptor rings */
+   void*null_qs;
+   bus_addr_t  null_qs_physaddr;
+
/* hardware provided statistics */
struct cgem_hw_stats {
uint64_ttx_bytes;
@@ -337,7 +353,11 @@ cgem_rx_filter(struct cgem_softc *sc)
hash_hi = 0;
hash_lo = 0;
 
+#ifdef __rtems__
+   net_cfg = sc->net_cfg_shadow;
+#else
net_cfg = RD4(sc, CGEM_NET_CFG);
+#endif
 
net_cfg &= ~(CGEM_NET_CFG_MULTI_HASH_EN |
 CGEM_NET_CFG_NO_BCAST | 
@@ -379,6 +399,9 @@ cgem_rx_filter(struct cgem_softc *sc)
 
WR4(sc, CGEM_HASH_TOP, hash_hi);
WR4(sc, CGEM_HASH_BOT, hash_lo);
+#ifdef __rtems__
+   sc->net_cfg_shadow = net_cfg;
+#endif /* __rtems__ */
WR4(sc, CGEM_NET_CFG, net_cfg);
 }
 
@@ -392,24 +415,87 @@ cgem_getaddr(void *arg, bus_dma_segment_t *segs, int 
nsegs, int error)
*(bus_addr_t *)arg = segs[0].ds_addr;
 }
 
+#ifdef __rtems__
+/* Set up null queues for priority queues we actually can't disable. */
+static void
+cgem_null_qs(struct cgem_softc *sc)
+{
+   struct cgem_rx_desc *rx_desc;
+   struct cgem_tx_desc *tx_desc;
+   uint32_t queue_mask;
+   int n;
+
+   /* Read design config register 6 to determine number of queues. */
+   queue_mask = (RD4(sc, CGEM_DESIGN_CFG6) &
+   CGEM_DESIGN_CFG6_DMA_PRIO_Q_MASK) >> 1;
+   if (queue_mask == 0)
+   return;
+
+   /* Create empty RX queue and empty TX buf queues. */
+   memset(sc->null_qs, 0, sizeof(struct cgem_rx_desc) +
+   sizeof(struct cgem_tx_desc));
+   rx_desc = sc->null_qs;
+   rx_desc->addr = CGEM_RXDESC_OWN | CGEM_RXDESC_WRAP;
+   tx_desc = (struct cgem_tx_desc *)(rx_desc + 1);
+   tx_desc->ctl = CGEM_TXDESC_USED | CGEM_TXDESC_WRAP;
+
+   /* Point all valid ring base pointers to the null queues. */
+   for (n = 1; (queue_mask & 1) != 0; n++, queue_mask >>= 1) {
+   WR4(sc, CGEM_RX_QN_BAR(n), sc->null_qs_physaddr);
+   WR4(sc, CGEM_TX_QN_BAR(n), sc->null_qs_physaddr +
+   sizeof(struct cgem_rx_desc));
+   }
+}
+#endif /* __rtems__ */
+
 /* Create DMA'able descriptor rings. */
 static int
 cgem_setup_descs(struct cgem_softc *sc)
 {
int i, err;
+#ifdef __rtems__
+   int desc_rings_size = CGEM_NUM_RX_DESCS * sizeof(struct cgem_rx_desc) +
+   CGEM_NUM_TX_DESCS * sizeof(struct cgem_tx_desc);
 
+   if (sc->neednullqs)
+   desc_rings_size += sizeof(struct cgem_rx_desc) +
+   sizeof(struct cgem_tx_desc);
+#endif /* __rtems__ */
sc->txring = NULL;
sc->rxring = NULL;
 
/* Allocate non-cached DMA space for RX and TX descriptors.
 */
+#ifndef __rtems__
err = bus_dma_tag_create(bus_get_dma_tag(sc->dev), 1, 0,
 BUS_SPACE_MAXADDR_32BIT,
+#else /* __rtems__ */
+   err = bus_dma_tag_create(bus_get_dma_tag(sc->dev),
+#if defined(__LP64__)
+8,
+  

[PATCH v1 6/7] linker: Enforce set alignment requirements

2021-03-08 Thread Kinsey Moore
According to commentary on GCC bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99143, the alignment
behavior of linker sections on which RTEMS has relied was never
guaranteed to be consistent across platforms and any alignment
requirements for linker sections needs to be enforced explicitly.
This adds those explicit alignment requirements.
---
 freebsd/sys/sys/linker_set.h | 51 ++--
 1 file changed, 37 insertions(+), 14 deletions(-)

diff --git a/freebsd/sys/sys/linker_set.h b/freebsd/sys/sys/linker_set.h
index e10be24c..baa5ae4c 100755
--- a/freebsd/sys/sys/linker_set.h
+++ b/freebsd/sys/sys/linker_set.h
@@ -68,39 +68,62 @@
__used = &(sym)
 #define __MAKE_SET(set, sym)   __MAKE_SET_QV(set, sym, __MAKE_SET_CONST)
 #else /* __rtems__ */
+
+#if __cplusplus >= 201103L
+  #define RTEMS_BSD_ALIGNOF( _type_name ) alignof( _type_name )
+#elif __STDC_VERSION__ >= 201112L
+  #define RTEMS_BSD_ALIGNOF( _type_name ) _Alignof( _type_name )
+#else
+  #define RTEMS_BSD_ALIGNOF( _type_name ) sizeof( _type_name )
+#endif
+
+#define RTEMS_BSD_SET_ALIGN( type )\
+   __attribute__(( __aligned__( RTEMS_BSD_ALIGNOF( type ) ) ))
+
 #define RTEMS_BSD_DEFINE_SET(set, type)
\
-   type const __CONCAT(_bsd__start_set_,set)[0]\
+   RTEMS_BSD_SET_ALIGN( type ) type\
+   const __CONCAT(_bsd__start_set_,set)[0] \
__section(".rtemsroset.bsd." __STRING(set) ".begin") __used;\
-   type const __CONCAT(_bsd__stop_set_,set)[0] \
+   RTEMS_BSD_SET_ALIGN( type ) type\
+   const __CONCAT(_bsd__stop_set_,set)[0]  \
__section(".rtemsroset.bsd." __STRING(set) ".end") __used
 
 #define RTEMS_BSD_DECLARE_SET(set, type)   \
-   extern type const __CONCAT(_bsd__start_set_,set)[0];\
-   extern type const __CONCAT(_bsd__stop_set_,set)[0]
+   extern RTEMS_BSD_SET_ALIGN( type ) type \
+   const __CONCAT(_bsd__start_set_,set)[0];\
+   extern RTEMS_BSD_SET_ALIGN( type ) type \
+   const __CONCAT(_bsd__stop_set_,set)[0]
 
 #define RTEMS_BSD_DEFINE_SET_ITEM(set, sym, type)  \
-   static type const __set_##set##_sym_##sym   \
-   __section(".rtemsroset.bsd." __STRING(set) ".content.1") __used
+   static RTEMS_BSD_SET_ALIGN( type ) type \
+   const __set_##set##_sym_##sym   \
+   __section(".rtemsroset.bsd." __STRING(set) ".content.1") __used
 
-#define RTEMS_BSD_DEFINE_SET_ITEM_ORDERED(set, sym, order, type) \
-   static type const __set_##set##_sym_##sym \
-   __section(".rtemsroset.bsd." __STRING(set) ".content.0."  
RTEMS_XSTRING( order )) __used
+#define RTEMS_BSD_DEFINE_SET_ITEM_ORDERED(set, sym, order, type)   \
+   static RTEMS_BSD_SET_ALIGN( type ) type \
+   const __set_##set##_sym_##sym   \
+   __section(".rtemsroset.bsd." __STRING(set) ".content.0."  
RTEMS_XSTRING( order )) __used
 
 #define __MAKE_SET(set, sym)   \
RTEMS_BSD_DEFINE_SET_ITEM(set, sym, const void *) = &sym
 
 #define RTEMS_BSD_DEFINE_RWSET(set, type)  \
-   type __CONCAT(_bsd__start_set_,set)[0]  \
+   RTEMS_BSD_SET_ALIGN( type ) type\
+   __CONCAT(_bsd__start_set_,set)[0]   \
__section(".rtemsrwset.bsd." __STRING(set) ".begin") __used;\
-   type __CONCAT(_bsd__stop_set_,set)[0]   \
+   RTEMS_BSD_SET_ALIGN( type ) type\
+   __CONCAT(_bsd__stop_set_,set)[0]\
__section(".rtemsrwset.bsd." __STRING(set) ".end") __used
 
 #define RTEMS_BSD_DECLARE_RWSET(set, type) \
-   extern type __CONCAT(_bsd__start_set_,set)[0];  \
-   extern type __CONCAT(_bsd__stop_set_,set)[0]
+   extern RTEMS_BSD_SET_ALIGN( type ) type \
+   __CONCAT(_bsd__start_set_,set)[0];  \
+   extern RTEMS_BSD_SET_ALIGN( type ) type \
+   __CONCAT(_bsd__stop_set_,set)[0]
 
 #define RTEMS_BSD_DEFINE_RWSET_ITEM(set, sym, type)\
-   static type __set_##set##_sym_##sym \
+   static RTEMS_BSD_SET_ALIGN( type ) type \
+   __set_##set##_sym_##sym \
__section(".rtemsrwset.bsd." __STRING(set) ".content") __used
 
 #define __MAKE_RWSET(set, sym)

[PATCH v1 7/7] nexus: Add UKPHY driver to ZynqMP

2021-03-08 Thread Kinsey Moore
ZynqMP hardware comes with many different Ethernet PHYs depending on
which board is used. Add the UKPHY driver to handle basic PHY
interaction for any unrecognized PHYs.
---
 rtemsbsd/include/bsp/nexus-devices.h   | 1 +
 rtemsbsd/include/machine/rtems-bsd-nexus-bus.h | 9 +
 2 files changed, 10 insertions(+)

diff --git a/rtemsbsd/include/bsp/nexus-devices.h 
b/rtemsbsd/include/bsp/nexus-devices.h
index ea8fa7d7..50f23e79 100644
--- a/rtemsbsd/include/bsp/nexus-devices.h
+++ b/rtemsbsd/include/bsp/nexus-devices.h
@@ -117,6 +117,7 @@ RTEMS_BSD_DRIVER_XILINX_ZYNQMP_SLCR;
  */
 RTEMS_BSD_DRIVER_XILINX_ZYNQMP_CGEM3(ZYNQMP_IRQ_ETHERNET_3);
 RTEMS_BSD_DRIVER_E1000PHY;
+RTEMS_BSD_DRIVER_UKPHY;
 
 #elif defined(LIBBSP_ARM_ATSAM_BSP_H)
 
diff --git a/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h 
b/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h
index bb5546a6..632c1466 100644
--- a/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h
+++ b/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h
@@ -78,6 +78,7 @@
  *   RTEMS_BSD_DRIVER_ICSPHY
  *   RTEMS_BSD_DRIVER_REPHY
  *   RTEMS_BSD_DRIVER_PHY_MIC
+ *   RTEMS_BSD_DRIVER_UKPHY
  */
 
 #if !defined(RTEMS_BSD_NEXUS_BUS_h)
@@ -543,6 +544,14 @@ extern "C" {
 SYSINIT_DRIVER_REFERENCE(micphy, miibus);
 #endif /* RTEMS_BSD_DRIVER_PHY_MIC */
 
+/*
+ * UK PHY.
+ */
+#if !defined(RTEMS_BSD_DRIVER_UKPHY)
+  #define RTEMS_BSD_DRIVER_UKPHY  \
+SYSINIT_DRIVER_REFERENCE(ukphy, miibus);
+#endif /* RTEMS_BSD_DRIVER_UKPHY */
+
 #ifdef __cplusplus
 }
 #endif /* __cplusplus */
-- 
2.20.1

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


RE: [PATCH v1 7/7] spec/aarch64: Force strict alignment for ZynqMP

2021-03-08 Thread Kinsey Moore
So after a little more diving into this, I have found why --strict-align is 
required.
If the MMU is disabled, all memory is treated as device memory which requires
strictly aligned accesses.

Kinsey

-Original Message-
From: devel  On Behalf Of Kinsey Moore
Sent: Friday, March 5, 2021 07:12
To: Sebastian Huber ; devel@rtems.org
Subject: RE: [PATCH v1 7/7] spec/aarch64: Force strict alignment for ZynqMP

Hi Sebastian,
For AArch64, that would be SCTLR_EL1.A (bit 1). Even with that alignment
checking disabled, I still see data aborts on misaligned accesses. The MMU is
disabled during operation, so that wouldn't be the issue, either. From reading
the spec on that bit, it would seem that AArch64 is accepting of misaligned
writes by default, but that's not the behavior I've seen with the two ZynqMP
boards I have on hand.

There is also SCTLR_EL1.nAA which toggles allowance of accesses spanning
16-byte boundaries, but the feature controlling whether that bit functions is
only mandatory from ARMv8.4 onward and is optional from ARMv8.2. Even
so, the nAA bit only affects a small subset of load and store instructions.

The section on unaligned accesses in the manual only references these two
bits and the LSE2 feature that controls whether the nAA bit is functional.

Kinsey

-Original Message-
From: Sebastian Huber  
Sent: Thursday, March 4, 2021 23:54
To: Kinsey Moore ; devel@rtems.org
Subject: Re: [PATCH v1 7/7] spec/aarch64: Force strict alignment for ZynqMP

On 04/03/2021 23:15, Kinsey Moore wrote:

> Real hardware running AArch64 does not appreciate accesses misaligned
> relative to the data size. This prevents generation of misaligned writes
> which would throw exceptions.

The patch set is fine independent of the following comment.

To me this problem with misaligned access looks like an MMU/system 
configuration issue. For example in AArch32, you have to enable 
misaligned access in SCTL[A].

-- 
embedded brains GmbH
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: [PATCH v1 1/7] rtembsd: Fix alignment of allocations for 64bit

2021-03-08 Thread Chris Johns
OK for 1 to 7 from me.

In regards to the if_ cgem driver, will any be posted up stream?

Chris

On 9/3/21 10:27 am, Kinsey Moore wrote:
> Alignment on 64bit hardware is strict in comparison to running in an
> emulator. This resolves an alignment exception when allocating memory on
> real hardware.
> ---
>  rtemsbsd/rtems/rtems-program.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/rtemsbsd/rtems/rtems-program.c b/rtemsbsd/rtems/rtems-program.c
> index 204ed248..370609d4 100644
> --- a/rtemsbsd/rtems/rtems-program.c
> +++ b/rtemsbsd/rtems/rtems-program.c
> @@ -479,12 +479,13 @@ rtems_bsd_program_alloc(size_t size, void *org_ptr)
>   void *ptr = NULL;
>   size_t size_with_list;
>   size_t size_alligned;
> + size_t alignment = sizeof(void*);
>  
>   if (prog_ctrl != NULL) {
>   /* align the end to the next word address */
>   size_alligned = size;
> - if ((size_alligned & 0x3) != 0) {
> - size_alligned = (size_alligned | 0x03) + 1;
> + if ((size_alligned & (alignment - 1)) != 0) {
> + size_alligned = (size_alligned | (alignment - 1)) + 1;
>   }
>   size_with_list = size_alligned +
>   sizeof(struct program_allocmem_item);
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [PATCH v1 7/7] spec/aarch64: Force strict alignment for ZynqMP

2021-03-08 Thread Chris Johns
On 9/3/21 10:40 am, Kinsey Moore wrote:
> So after a little more diving into this, I have found why --strict-align is 
> required.
> If the MMU is disabled, all memory is treated as device memory which requires
> strictly aligned accesses.

I think I have missed something or not understanding the background.

Why is the MMU disabled?

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


Re: [5 PATCH 0/2] Backport fixes to zynq uart to RTEMS5

2021-03-08 Thread Chris Johns
OK for 5.

On 6/3/21 5:58 am, Jan Sommer wrote:
> This patchset backports the commits of Kinsey Moore and myself, which
> fix the stdin behavior for the zynq-uart based console driver.
> I checked the behavior on hardware with the termios.exe application.
> Before, the scanf and similar functions do not wait for user input and return
> immediately. With the patches the application behaves as expected.
> 
> A corresponding ticket can be found here: https://devel.rtems.org/ticket/4236
> 
> Small side note:
> I noticed that the ARM BSP docs for RTEMS5 list mostly TODO.
> Should I create a patchset backporting the BSP documentation or do you
> want to do that in one go as part of the 5.2 release preparation?
> 
> Best regards,
> 
> Jan
> 
> Jan Sommer (1):
>   bsps/shared: Allow setting baud rate for zynq uart
> 
> Kinsey Moore (1):
>   zynq-uart: Fix set_attributes implementation
> 
>  bsps/arm/include/bsp/zynq-uart.h  |  7 +++
>  bsps/arm/shared/serial/zynq-uart-polled.c |  2 +-
>  bsps/arm/shared/serial/zynq-uart.c| 77 ---
>  3 files changed, 75 insertions(+), 11 deletions(-)
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


RE: [PATCH v1 1/7] rtembsd: Fix alignment of allocations for 64bit

2021-03-08 Thread Kinsey Moore
The patch to the if_cgem driver is actually a modified (to LibBSD style) 
backport of the
64bit cgem patch that's in 13. FreeBSD doesn't appear to care about ILP32 and 
that is
the majority of functional difference between the upstream and what is being 
applied
here.

Kinsey

-Original Message-
From: Chris Johns  
Sent: Monday, March 8, 2021 20:04
To: Kinsey Moore ; devel@rtems.org
Subject: Re: [PATCH v1 1/7] rtembsd: Fix alignment of allocations for 64bit

OK for 1 to 7 from me.

In regards to the if_ cgem driver, will any be posted up stream?

Chris

On 9/3/21 10:27 am, Kinsey Moore wrote:
> Alignment on 64bit hardware is strict in comparison to running in an
> emulator. This resolves an alignment exception when allocating memory on
> real hardware.
> ---
>  rtemsbsd/rtems/rtems-program.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/rtemsbsd/rtems/rtems-program.c b/rtemsbsd/rtems/rtems-program.c
> index 204ed248..370609d4 100644
> --- a/rtemsbsd/rtems/rtems-program.c
> +++ b/rtemsbsd/rtems/rtems-program.c
> @@ -479,12 +479,13 @@ rtems_bsd_program_alloc(size_t size, void *org_ptr)
>   void *ptr = NULL;
>   size_t size_with_list;
>   size_t size_alligned;
> + size_t alignment = sizeof(void*);
>  
>   if (prog_ctrl != NULL) {
>   /* align the end to the next word address */
>   size_alligned = size;
> - if ((size_alligned & 0x3) != 0) {
> - size_alligned = (size_alligned | 0x03) + 1;
> + if ((size_alligned & (alignment - 1)) != 0) {
> + size_alligned = (size_alligned | (alignment - 1)) + 1;
>   }
>   size_with_list = size_alligned +
>   sizeof(struct program_allocmem_item);
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [PATCH 0/3] Fix Missing break in switch Coverity issues

2021-03-08 Thread Chris Johns
On 6/3/21 6:04 am, Gedare Bloom wrote:
> On Fri, Mar 5, 2021 at 11:48 AM Sebastian Huber
>  wrote:
>>
>> On 05/03/2021 19:40, Joel Sherrill wrote:
>>
>>> On Fri, Mar 5, 2021, 12:25 PM Sebastian Huber
>>> >> > wrote:
>>>
>>> On 05/03/2021 16:27, Gedare Bloom wrote:
>>>
>>> > Should we add a macro for this, e.g., "RTEMS_CASE_NO_BREAK" so
>>> that we
>>> > can update them in future if needed for other tools?
>>> I would just pick a name which is understood by GCC, clang, and
>>> Coverity. I guess other tools will understand this or why did you
>>> buy them?
>>>
>>>
>>> Well we didn't pay for any of those but are you wanting a macro or
>>> just the comment?
>>
>> I would just use a comment which is understood by GCC, clang, and
>> Coverity. What does Linux use?
>>
> That's fine, if there is a de facto standard to use, we can go for it.

Looking at the option documentation gcc supports a lot of different possible
ways and the warning option can change what is selected.

Do we allow all that gcc allows? I hope not.

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


Re: [PATCH v1 1/7] rtembsd: Fix alignment of allocations for 64bit

2021-03-08 Thread Chris Johns
On 9/3/21 1:21 pm, Kinsey Moore wrote:
> The patch to the if_cgem driver is actually a modified (to LibBSD style) 
> backport of the
> 64bit cgem patch that's in 13. FreeBSD doesn't appear to care about ILP32 and 
> that is
> the majority of functional difference between the upstream and what is being 
> applied
> here.

Thanks for the explanation. I hope this is not common and tools like gcc etc are
more supportive of ILP32.

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


[PATCH rtems-docs] networking: Rename to legacy networking

2021-03-08 Thread Vijay Kumar Banerjee
---
 book/index_book.rst   | 2 +-
 {networking => legacy-networking}/command.rst | 0
 {networking => legacy-networking}/conf.py | 4 ++--
 {networking => legacy-networking}/dec_21140.rst   | 0
 {networking => legacy-networking}/index.rst   | 2 +-
 {networking => legacy-networking}/network_servers.rst | 0
 {networking => legacy-networking}/network_task_structure.rst  | 0
 {networking => legacy-networking}/networking_driver.rst   | 0
 {networking => legacy-networking}/preface.rst | 0
 {networking => legacy-networking}/testing_the_driver.rst  | 0
 .../using_networking_rtems_app.rst| 0
 {networking => legacy-networking}/wscript | 0
 wscript   | 2 +-
 13 files changed, 5 insertions(+), 5 deletions(-)
 rename {networking => legacy-networking}/command.rst (100%)
 rename {networking => legacy-networking}/conf.py (68%)
 rename {networking => legacy-networking}/dec_21140.rst (100%)
 rename {networking => legacy-networking}/index.rst (92%)
 rename {networking => legacy-networking}/network_servers.rst (100%)
 rename {networking => legacy-networking}/network_task_structure.rst (100%)
 rename {networking => legacy-networking}/networking_driver.rst (100%)
 rename {networking => legacy-networking}/preface.rst (100%)
 rename {networking => legacy-networking}/testing_the_driver.rst (100%)
 rename {networking => legacy-networking}/using_networking_rtems_app.rst (100%)
 rename {networking => legacy-networking}/wscript (100%)

diff --git a/book/index_book.rst b/book/index_book.rst
index 8282006..96ab0ff 100644
--- a/book/index_book.rst
+++ b/book/index_book.rst
@@ -23,7 +23,7 @@ Table of Contents
cpu_supplement/index.rst
develenv/index.rst
filesystem/index.rst
-   networking/index.rst
+   legacy-networking/index.rst
porting/index.rst
posix1003_1/index.rst
posix_users/index.rst
diff --git a/networking/command.rst b/legacy-networking/command.rst
similarity index 100%
rename from networking/command.rst
rename to legacy-networking/command.rst
diff --git a/networking/conf.py b/legacy-networking/conf.py
similarity index 68%
rename from networking/conf.py
rename to legacy-networking/conf.py
index 1c129bc..6cc01bc 100644
--- a/networking/conf.py
+++ b/legacy-networking/conf.py
@@ -3,12 +3,12 @@ sys.path.insert(0, os.path.abspath('../common/'))
 
 from conf import *
 
-project = "RTEMS Networking User Manual"
+project = "RTEMS Legacy Networking User Manual"
 
 latex_documents = [
 ('index',
  'networking.tex',
- u'RTEMS Networking User Manual',
+ u'RTEMS Legacy Networking User Manual',
  u'RTEMS Documentation Project',
  'manual'),
 ]
diff --git a/networking/dec_21140.rst b/legacy-networking/dec_21140.rst
similarity index 100%
rename from networking/dec_21140.rst
rename to legacy-networking/dec_21140.rst
diff --git a/networking/index.rst b/legacy-networking/index.rst
similarity index 92%
rename from networking/index.rst
rename to legacy-networking/index.rst
index f56a60d..b85119d 100644
--- a/networking/index.rst
+++ b/legacy-networking/index.rst
@@ -5,7 +5,7 @@
 .. highlight:: c
 
 ==
-RTEMS Network User Manual (|version|).
+RTEMS Legacy Network User Manual (|version|).
 ==
 
 .. topic:: Copyrights and License
diff --git a/networking/network_servers.rst 
b/legacy-networking/network_servers.rst
similarity index 100%
rename from networking/network_servers.rst
rename to legacy-networking/network_servers.rst
diff --git a/networking/network_task_structure.rst 
b/legacy-networking/network_task_structure.rst
similarity index 100%
rename from networking/network_task_structure.rst
rename to legacy-networking/network_task_structure.rst
diff --git a/networking/networking_driver.rst 
b/legacy-networking/networking_driver.rst
similarity index 100%
rename from networking/networking_driver.rst
rename to legacy-networking/networking_driver.rst
diff --git a/networking/preface.rst b/legacy-networking/preface.rst
similarity index 100%
rename from networking/preface.rst
rename to legacy-networking/preface.rst
diff --git a/networking/testing_the_driver.rst 
b/legacy-networking/testing_the_driver.rst
similarity index 100%
rename from networking/testing_the_driver.rst
rename to legacy-networking/testing_the_driver.rst
diff --git a/networking/using_networking_rtems_app.rst 
b/legacy-networking/using_networking_rtems_app.rst
similarity index 100%
rename from networking/using_networking_rtems_app.rst
rename to legacy-networking/using_networking_rtems_app.rst
diff --git a/networking/wscript b/legacy-networking/wscript
similarity index 100%
rename from networking/wscript
rename to legacy-networking/wscript
diff --git a/wscript b/wscript
index ce644f8..92775ae 100644
--- a/wscript
++

RE: [PATCH v1 7/7] spec/aarch64: Force strict alignment for ZynqMP

2021-03-08 Thread Kinsey Moore
I was working under the impression that I didn't need it since RTEMS uses a flat
memory model. I'll be spending some time tomorrow seeing what it will take to
enable usage of the "normal" memory model via a configured MMU.

Kinsey

-Original Message-
From: Chris Johns  
Sent: Monday, March 8, 2021 20:08
To: Kinsey Moore 
Cc: devel@rtems.org
Subject: Re: [PATCH v1 7/7] spec/aarch64: Force strict alignment for ZynqMP

On 9/3/21 10:40 am, Kinsey Moore wrote:
> So after a little more diving into this, I have found why --strict-align is 
> required.
> If the MMU is disabled, all memory is treated as device memory which requires
> strictly aligned accesses.

I think I have missed something or not understanding the background.

Why is the MMU disabled?

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


RE: [PATCH v1 1/7] rtembsd: Fix alignment of allocations for 64bit

2021-03-08 Thread Kinsey Moore
Thus far, GCC has been just fine other than violating some behavioral 
expectations that
were never guaranteed (the linker sets patches). Newlib has some ILP32 issues 
that need
to be addressed. I've gotten a patch into the upstream ARM optimized routines 
that will
eventually make it into Newlib and fix those issues. There's possibly another 
issue with
the "dc zva" instruction that may also be solved by enabling the MMU.

Kinsey

-Original Message-
From: Chris Johns  
Sent: Monday, March 8, 2021 20:23
To: Kinsey Moore ; devel@rtems.org
Subject: Re: [PATCH v1 1/7] rtembsd: Fix alignment of allocations for 64bit

On 9/3/21 1:21 pm, Kinsey Moore wrote:
> The patch to the if_cgem driver is actually a modified (to LibBSD style) 
> backport of the
> 64bit cgem patch that's in 13. FreeBSD doesn't appear to care about ILP32 and 
> that is
> the majority of functional difference between the upstream and what is being 
> applied
> here.

Thanks for the explanation. I hope this is not common and tools like gcc etc are
more supportive of ILP32.

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


[PATCH RSB] Add recipe for building rtems-net-legacy

2021-03-08 Thread Vijay Kumar Banerjee
---
 rtems/config/6/rtems-net-legacy.bset  |  4 ++
 rtems/config/tools/rtems-net-legacy-6.cfg | 12 
 .../config/tools/rtems-net-legacy-common.cfg  | 65 +++
 3 files changed, 81 insertions(+)
 create mode 100644 rtems/config/6/rtems-net-legacy.bset
 create mode 100644 rtems/config/tools/rtems-net-legacy-6.cfg
 create mode 100644 rtems/config/tools/rtems-net-legacy-common.cfg

diff --git a/rtems/config/6/rtems-net-legacy.bset 
b/rtems/config/6/rtems-net-legacy.bset
new file mode 100644
index 000..424091c
--- /dev/null
+++ b/rtems/config/6/rtems-net-legacy.bset
@@ -0,0 +1,4 @@
+#
+# Legacy networking stack
+#
+tools/rtems-net-legacy-6
diff --git a/rtems/config/tools/rtems-net-legacy-6.cfg 
b/rtems/config/tools/rtems-net-legacy-6.cfg
new file mode 100644
index 000..9480269
--- /dev/null
+++ b/rtems/config/tools/rtems-net-legacy-6.cfg
@@ -0,0 +1,12 @@
+#
+# RTEMS Legacy networking stack
+#
+
+#  branch: main
+%define rtems_net_version de0585e271701d5683e5ab332db72230
+%hash sha512 rtems-net-legacy-%{rtems_net_version}.tar.gz \
+   
Kmznx8/DsHLf8MX5wL8b65R7AqJVTmGcwB7I4M8ETB27u666Wi1T5M8SQMLHsZMo9aZ44umWyxdCg6l2OpWr2w==
+%define rtems_waf_version 1a118bbcd52138dbdc3236e64bc23fd430a064b1
+%hash sha512 rtems_waf.tar.gz 
9WIROD6rid1M9fsdFWy1Gz/oCsx3l+QGOWoyXnSoGbo/xiyQ+MS+TZU2YoCUNx6/SE18ZeCiq79JYE5H+Yh46Q==
+
+%include tools/rtems-net-legacy-common.cfg
diff --git a/rtems/config/tools/rtems-net-legacy-common.cfg 
b/rtems/config/tools/rtems-net-legacy-common.cfg
new file mode 100644
index 000..6ded30f
--- /dev/null
+++ b/rtems/config/tools/rtems-net-legacy-common.cfg
@@ -0,0 +1,65 @@
+#
+# RTEMS Legacy networking stack
+#
+# This configuration file configure's, build's and install's linetworking.a.
+#
+
+%if %{release} == %{nil}
+%define release 1
+%endif
+
+Name:  rtems-net-letgacy-%{rtems_net_version}-%{_host}-%{release}
+Summary:   RTEMS net legacy provides legacy networking stack from RTEMS 5 and 
earlier
+Version:   %{rtems_net_version}
+Release:   %{release}
+URL:   https://git.rtems.org/rtems-net-legacy.git/
+
+
+#
+# RTEMS BSP support.
+#
+%include rtems-bsp.cfg
+
+#
+# Net legacy Source from github.
+#
+%source set rtems_net_legacy \
+  --rsb-file=rtems-net-legacy-%{rtems_net_version}.tar.gz 
https://github.com/RTEMS/rtems-net-legacy/archive/%{rtems_net_version}.tar.gz 
+%source set rtems_waf \
+  --rsb-file=rtems_waf.tar.gz 
https://github.com/RTEMS/rtems_waf/archive/%{rtems_waf_version}.tar.gz
+
+#
+# Prepare the source code.
+#
+%prep
+  build_top=$(pwd)
+
+  source_dir_net_legacy="rtems-net-legacy-%{rtems_net_version}"
+  %source setup rtems_net_legacy -q -n rtems-net-legacy-%{rtems_net_version}
+  %source setup rtems_waf -q -s 1 -c -a -n 
rtems-net-legacy-%{rtems_net_version}/rtems_waf
+  cd ${build_top}
+
+#
+# Build the source code.
+#
+%build
+  build_top=$(pwd)
+
+  %{host_build_flags}
+
+  cd ${source_dir_net_legacy}
+
+  ./waf distclean configure \
+--prefix=%{_prefix} \
+--rtems-bsp=%{rtems_bsp_arch_bsp}
+
+  ./waf
+
+  cd ${build_top}
+
+%install
+  build_top=$(pwd)
+
+  cd ${source_dir_net_legacy}
+  ./waf install
+  cd ${build_top}
-- 
2.26.2

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


Re: [PATCH v1 7/7] spec/aarch64: Force strict alignment for ZynqMP

2021-03-08 Thread Chris Johns
On 9/3/21 1:24 pm, Kinsey Moore wrote:
> I was working under the impression that I didn't need it since RTEMS uses a 
> flat
> memory model. I'll be spending some time tomorrow seeing what it will take to
> enable usage of the "normal" memory model via a configured MMU.

Most architectures with MMUs run with them enabled and need to for performance
reasons. The MMUs are configured for a 1:1 virtual to physical memory map and
using it helps with segmenting the address space so different areas have
different characteristics. For example DDR memory is cached and alignment is
relaxed while regions mapped to the PL AXI ports and the PL have IO device
attributes. The code does not need to have any special build options.

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


Re: [PATCH RSB] Add recipe for building rtems-net-legacy

2021-03-08 Thread Vijay Kumar Banerjee
Hello,

This patch doesn't build due to an unrelated error in RSB:
https://devel.rtems.org/ticket/4319

With a workaround to bypass the above error, this patch builds and
installs rtems-net-legacy.

Best regards,
Vijay

On Mon, Mar 8, 2021 at 7:31 PM Vijay Kumar Banerjee  wrote:
>
> ---
>  rtems/config/6/rtems-net-legacy.bset  |  4 ++
>  rtems/config/tools/rtems-net-legacy-6.cfg | 12 
>  .../config/tools/rtems-net-legacy-common.cfg  | 65 +++
>  3 files changed, 81 insertions(+)
>  create mode 100644 rtems/config/6/rtems-net-legacy.bset
>  create mode 100644 rtems/config/tools/rtems-net-legacy-6.cfg
>  create mode 100644 rtems/config/tools/rtems-net-legacy-common.cfg
>
> diff --git a/rtems/config/6/rtems-net-legacy.bset 
> b/rtems/config/6/rtems-net-legacy.bset
> new file mode 100644
> index 000..424091c
> --- /dev/null
> +++ b/rtems/config/6/rtems-net-legacy.bset
> @@ -0,0 +1,4 @@
> +#
> +# Legacy networking stack
> +#
> +tools/rtems-net-legacy-6
> diff --git a/rtems/config/tools/rtems-net-legacy-6.cfg 
> b/rtems/config/tools/rtems-net-legacy-6.cfg
> new file mode 100644
> index 000..9480269
> --- /dev/null
> +++ b/rtems/config/tools/rtems-net-legacy-6.cfg
> @@ -0,0 +1,12 @@
> +#
> +# RTEMS Legacy networking stack
> +#
> +
> +#  branch: main
> +%define rtems_net_version de0585e271701d5683e5ab332db72230
> +%hash sha512 rtems-net-legacy-%{rtems_net_version}.tar.gz \
> +   
> Kmznx8/DsHLf8MX5wL8b65R7AqJVTmGcwB7I4M8ETB27u666Wi1T5M8SQMLHsZMo9aZ44umWyxdCg6l2OpWr2w==
> +%define rtems_waf_version 1a118bbcd52138dbdc3236e64bc23fd430a064b1
> +%hash sha512 rtems_waf.tar.gz 
> 9WIROD6rid1M9fsdFWy1Gz/oCsx3l+QGOWoyXnSoGbo/xiyQ+MS+TZU2YoCUNx6/SE18ZeCiq79JYE5H+Yh46Q==
> +
> +%include tools/rtems-net-legacy-common.cfg
> diff --git a/rtems/config/tools/rtems-net-legacy-common.cfg 
> b/rtems/config/tools/rtems-net-legacy-common.cfg
> new file mode 100644
> index 000..6ded30f
> --- /dev/null
> +++ b/rtems/config/tools/rtems-net-legacy-common.cfg
> @@ -0,0 +1,65 @@
> +#
> +# RTEMS Legacy networking stack
> +#
> +# This configuration file configure's, build's and install's linetworking.a.
> +#
> +
> +%if %{release} == %{nil}
> +%define release 1
> +%endif
> +
> +Name:  rtems-net-letgacy-%{rtems_net_version}-%{_host}-%{release}
> +Summary:   RTEMS net legacy provides legacy networking stack from RTEMS 5 
> and earlier
> +Version:   %{rtems_net_version}
> +Release:   %{release}
> +URL:   https://git.rtems.org/rtems-net-legacy.git/
> +
> +
> +#
> +# RTEMS BSP support.
> +#
> +%include rtems-bsp.cfg
> +
> +#
> +# Net legacy Source from github.
> +#
> +%source set rtems_net_legacy \
> +  --rsb-file=rtems-net-legacy-%{rtems_net_version}.tar.gz 
> https://github.com/RTEMS/rtems-net-legacy/archive/%{rtems_net_version}.tar.gz
> +%source set rtems_waf \
> +  --rsb-file=rtems_waf.tar.gz 
> https://github.com/RTEMS/rtems_waf/archive/%{rtems_waf_version}.tar.gz
> +
> +#
> +# Prepare the source code.
> +#
> +%prep
> +  build_top=$(pwd)
> +
> +  source_dir_net_legacy="rtems-net-legacy-%{rtems_net_version}"
> +  %source setup rtems_net_legacy -q -n rtems-net-legacy-%{rtems_net_version}
> +  %source setup rtems_waf -q -s 1 -c -a -n 
> rtems-net-legacy-%{rtems_net_version}/rtems_waf
> +  cd ${build_top}
> +
> +#
> +# Build the source code.
> +#
> +%build
> +  build_top=$(pwd)
> +
> +  %{host_build_flags}
> +
> +  cd ${source_dir_net_legacy}
> +
> +  ./waf distclean configure \
> +--prefix=%{_prefix} \
> +--rtems-bsp=%{rtems_bsp_arch_bsp}
> +
> +  ./waf
> +
> +  cd ${build_top}
> +
> +%install
> +  build_top=$(pwd)
> +
> +  cd ${source_dir_net_legacy}
> +  ./waf install
> +  cd ${build_top}
> --
> 2.26.2
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: RSB build issue with rtems-libbsd

2021-03-08 Thread Vijay Kumar Banerjee
On Mon, Mar 8, 2021 at 3:02 PM Chris Johns  wrote:
>
> On 6/3/21 2:24 pm, Vijay Kumar Banerjee wrote:
> > Hello,
> >
> > I'm getting the following error when trying to build rtems-libbsd from
> > RSB. Is there anything that I'm missing?
> >
> > ```
> > ../source-builder/sb-set-builder --prefix=$RTEMS6_PREFIX
> > 6/rtems-libbsd --host=powerpc-rtems6 --with-rtems-bsp=beatnik
> > RTEMS Source Builder - Set Builder, 6 (102cb1e6450f)
> > warning: exe: absolute exe found in path: (__chown) /usr/sbin/chown
> > Build Set: 6/rtems-libbsd
> > config: tools/rtems-libbsd-6.cfg
> > error: rtems-bsp.cfg:155: invalid %if operator:  -mcpu=7400
> > -I/home/vijay/development/rtems/6/powerpc-rtems6/beatnik/lib/include
>
Hello Chris,

Thanks for taking a look.

> This looks like a bug. Please raise a ticket.
>

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

Best regards,
Vijay
> > ==
> > Build FAILED
> > Build Set: Time 0:00:00.046141
> > Build FAILED
> >
> > ```
> >
> > Commenting these checks from rtems-bsp.cfg gets it building.
>
> Unfortunately the checks are needed and this is not the answer.
>
> I wonder how Jennifer has been building libbsd. She is working on this BSP and
> libbsd.
>
> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: RSB build issue with rtems-libbsd

2021-03-08 Thread Vijay Kumar Banerjee
On Mon, Mar 8, 2021 at 3:14 PM Joel Sherrill  wrote:
>
>
>
>
>
> On Mon, Mar 8, 2021, 4:02 PM Chris Johns  wrote:
>>
>> On 6/3/21 2:24 pm, Vijay Kumar Banerjee wrote:
>> > Hello,
>> >
>> > I'm getting the following error when trying to build rtems-libbsd from
>> > RSB. Is there anything that I'm missing?
>> >
>> > ```
>> > ../source-builder/sb-set-builder --prefix=$RTEMS6_PREFIX
>> > 6/rtems-libbsd --host=powerpc-rtems6 --with-rtems-bsp=beatnik
>> > RTEMS Source Builder - Set Builder, 6 (102cb1e6450f)
>> > warning: exe: absolute exe found in path: (__chown) /usr/sbin/chown
>> > Build Set: 6/rtems-libbsd
>> > config: tools/rtems-libbsd-6.cfg
>> > error: rtems-bsp.cfg:155: invalid %if operator:  -mcpu=7400
>> > -I/home/vijay/development/rtems/6/powerpc-rtems6/beatnik/lib/include
>>
>> This looks like a bug. Please raise a ticket.
>>
>> > ==
>> > Build FAILED
>> > Build Set: Time 0:00:00.046141
>> > Build FAILED
>> >
>> > ```
>> >
>> > Commenting these checks from rtems-bsp.cfg gets it building.
>>
>> Unfortunately the checks are needed and this is not the answer.
>>
>> I wonder how Jennifer has been building libbsd. She is working on this BSP 
>> and
>> libbsd.
>

This issue is happening with other bsps as well.

This error is also being a blocker to building rtems-net-legacy with
the new patch. I can have a look at it, do you have any hints on what
might be going wrong?

Best regards,
Vijay
>
> Directly with waf.
>
> --joel
>>
>>
>> Chris
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [PATCH RSB] Add recipe for building rtems-net-legacy

2021-03-08 Thread Chris Johns
Hi Vijay,

Thank you for sorting this out.

On 9/3/21 1:31 pm, Vijay Kumar Banerjee wrote:
> ---
>  rtems/config/6/rtems-net-legacy.bset  |  4 ++
>  rtems/config/tools/rtems-net-legacy-6.cfg | 12 
>  .../config/tools/rtems-net-legacy-common.cfg  | 65 +++
>  3 files changed, 81 insertions(+)
>  create mode 100644 rtems/config/6/rtems-net-legacy.bset
>  create mode 100644 rtems/config/tools/rtems-net-legacy-6.cfg
>  create mode 100644 rtems/config/tools/rtems-net-legacy-common.cfg
> 
> diff --git a/rtems/config/6/rtems-net-legacy.bset 
> b/rtems/config/6/rtems-net-legacy.bset
> new file mode 100644
> index 000..424091c
> --- /dev/null
> +++ b/rtems/config/6/rtems-net-legacy.bset
> @@ -0,0 +1,4 @@
> +#
> +# Legacy networking stack
> +#
> +tools/rtems-net-legacy-6
> diff --git a/rtems/config/tools/rtems-net-legacy-6.cfg 
> b/rtems/config/tools/rtems-net-legacy-6.cfg
> new file mode 100644
> index 000..9480269
> --- /dev/null
> +++ b/rtems/config/tools/rtems-net-legacy-6.cfg
> @@ -0,0 +1,12 @@
> +#
> +# RTEMS Legacy networking stack
> +#
> +
> +#  branch: main
> +%define rtems_net_version de0585e271701d5683e5ab332db72230
> +%hash sha512 rtems-net-legacy-%{rtems_net_version}.tar.gz \
> +   
> Kmznx8/DsHLf8MX5wL8b65R7AqJVTmGcwB7I4M8ETB27u666Wi1T5M8SQMLHsZMo9aZ44umWyxdCg6l2OpWr2w==
> +%define rtems_waf_version 1a118bbcd52138dbdc3236e64bc23fd430a064b1
> +%hash sha512 rtems_waf.tar.gz 
> 9WIROD6rid1M9fsdFWy1Gz/oCsx3l+QGOWoyXnSoGbo/xiyQ+MS+TZU2YoCUNx6/SE18ZeCiq79JYE5H+Yh46Q==
> +
> +%include tools/rtems-net-legacy-common.cfg
> diff --git a/rtems/config/tools/rtems-net-legacy-common.cfg 
> b/rtems/config/tools/rtems-net-legacy-common.cfg
> new file mode 100644
> index 000..6ded30f
> --- /dev/null
> +++ b/rtems/config/tools/rtems-net-legacy-common.cfg
> @@ -0,0 +1,65 @@
> +#
> +# RTEMS Legacy networking stack
> +#
> +# This configuration file configure's, build's and install's linetworking.a.
> +#
> +
> +%if %{release} == %{nil}
> +%define release 1
> +%endif
> +
> +Name:  rtems-net-letgacy-%{rtems_net_version}-%{_host}-%{release}

rtems-net-letgacy -> rtems-net-legacy

> +Summary:   RTEMS net legacy provides legacy networking stack from RTEMS 5 
> and earlier
> +Version:   %{rtems_net_version}
> +Release:   %{release}
> +URL:   https://git.rtems.org/rtems-net-legacy.git/
> +
> +
> +#
> +# RTEMS BSP support.
> +#
> +%include rtems-bsp.cfg
> +
> +#
> +# Net legacy Source from github.

Why github?

> +#
> +%source set rtems_net_legacy \
> +  --rsb-file=rtems-net-legacy-%{rtems_net_version}.tar.gz 
> https://github.com/RTEMS/rtems-net-legacy/archive/%{rtems_net_version}.tar.gz 
> +%source set rtems_waf \
> +  --rsb-file=rtems_waf.tar.gz 
> https://github.com/RTEMS/rtems_waf/archive/%{rtems_waf_version}.tar.gz

Please so not reference github for rtems_waf for RTEMS project things. We need
to be self contained.

The libbsd recipe has an %{rsb_released} check. This will not work with a
released net-legacy tarball as a released tarball has rtems_waf included, it has
to be included in the tarball for a release be definition. The release scripts
inspect a repo for submodules and includes them as source after filtering (we do
not want to capture things like freebsd-org).

> +
> +#
> +# Prepare the source code.
> +#
> +%prep
> +  build_top=$(pwd)
> +
> +  source_dir_net_legacy="rtems-net-legacy-%{rtems_net_version}"
> +  %source setup rtems_net_legacy -q -n rtems-net-legacy-%{rtems_net_version}
> +  %source setup rtems_waf -q -s 1 -c -a -n 
> rtems-net-legacy-%{rtems_net_version}/rtems_waf
> +  cd ${build_top}
> +
> +#
> +# Build the source code.
> +#
> +%build
> +  build_top=$(pwd)
> +
> +  %{host_build_flags}
> +
> +  cd ${source_dir_net_legacy}
> +
> +  ./waf distclean configure \
> +--prefix=%{_prefix} \
> +--rtems-bsp=%{rtems_bsp_arch_bsp}
> +
> +  ./waf
> +
> +  cd ${build_top}
> +
> +%install
> +  build_top=$(pwd)
> +
> +  cd ${source_dir_net_legacy}
> +  ./waf install

The --destdir needs to be used as it is in the libbsd recipe. What is here
installs into the user's prefix and not into the RSB staging area. An RSB build
is a transaction, it can only install a build once all the pieces in the build
have built. Installing to the user's prefix would leave the user's prefix in an
unknown state if a piece did not build.

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


Re: RSB build issue with rtems-libbsd

2021-03-08 Thread Chris Johns
On 9/3/21 1:44 pm, Vijay Kumar Banerjee wrote:
> On Mon, Mar 8, 2021 at 3:14 PM Joel Sherrill  wrote:
>> On Mon, Mar 8, 2021, 4:02 PM Chris Johns  wrote:
>>>
>>> On 6/3/21 2:24 pm, Vijay Kumar Banerjee wrote:
 Hello,

 I'm getting the following error when trying to build rtems-libbsd from
 RSB. Is there anything that I'm missing?

 ```
 ../source-builder/sb-set-builder --prefix=$RTEMS6_PREFIX
 6/rtems-libbsd --host=powerpc-rtems6 --with-rtems-bsp=beatnik
 RTEMS Source Builder - Set Builder, 6 (102cb1e6450f)
 warning: exe: absolute exe found in path: (__chown) /usr/sbin/chown
 Build Set: 6/rtems-libbsd
 config: tools/rtems-libbsd-6.cfg
 error: rtems-bsp.cfg:155: invalid %if operator:  -mcpu=7400
 -I/home/vijay/development/rtems/6/powerpc-rtems6/beatnik/lib/include
>>>
>>> This looks like a bug. Please raise a ticket.
>>>
 ==
 Build FAILED
 Build Set: Time 0:00:00.046141
 Build FAILED

 ```

 Commenting these checks from rtems-bsp.cfg gets it building.
>>>
>>> Unfortunately the checks are needed and this is not the answer.
>>>
>>> I wonder how Jennifer has been building libbsd. She is working on this BSP 
>>> and
>>> libbsd.
>>
> 
> This issue is happening with other bsps as well.

Great and thanks for checking. I asked this question in the ticket. :)

> This error is also being a blocker to building rtems-net-legacy with
> the new patch. I can have a look at it, do you have any hints on what
> might be going wrong?

Yes in the ticket :) (in short for the thread run with --trace and compare with
libbsd).

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


Re: [PATCH RSB] Add recipe for building rtems-net-legacy

2021-03-08 Thread Vijay Kumar Banerjee
Hi Chris,

Thanks for reviewing.

On Mon, Mar 8, 2021 at 7:54 PM Chris Johns  wrote:
>
> Hi Vijay,
>
> Thank you for sorting this out.
>
> On 9/3/21 1:31 pm, Vijay Kumar Banerjee wrote:
> > ---
> >  rtems/config/6/rtems-net-legacy.bset  |  4 ++
> >  rtems/config/tools/rtems-net-legacy-6.cfg | 12 
> >  .../config/tools/rtems-net-legacy-common.cfg  | 65 +++
> >  3 files changed, 81 insertions(+)
> >  create mode 100644 rtems/config/6/rtems-net-legacy.bset
> >  create mode 100644 rtems/config/tools/rtems-net-legacy-6.cfg
> >  create mode 100644 rtems/config/tools/rtems-net-legacy-common.cfg
> >
> > diff --git a/rtems/config/6/rtems-net-legacy.bset 
> > b/rtems/config/6/rtems-net-legacy.bset
> > new file mode 100644
> > index 000..424091c
> > --- /dev/null
> > +++ b/rtems/config/6/rtems-net-legacy.bset
> > @@ -0,0 +1,4 @@
> > +#
> > +# Legacy networking stack
> > +#
> > +tools/rtems-net-legacy-6
> > diff --git a/rtems/config/tools/rtems-net-legacy-6.cfg 
> > b/rtems/config/tools/rtems-net-legacy-6.cfg
> > new file mode 100644
> > index 000..9480269
> > --- /dev/null
> > +++ b/rtems/config/tools/rtems-net-legacy-6.cfg
> > @@ -0,0 +1,12 @@
> > +#
> > +# RTEMS Legacy networking stack
> > +#
> > +
> > +#  branch: main
> > +%define rtems_net_version de0585e271701d5683e5ab332db72230
> > +%hash sha512 rtems-net-legacy-%{rtems_net_version}.tar.gz \
> > +   
> > Kmznx8/DsHLf8MX5wL8b65R7AqJVTmGcwB7I4M8ETB27u666Wi1T5M8SQMLHsZMo9aZ44umWyxdCg6l2OpWr2w==
> > +%define rtems_waf_version 1a118bbcd52138dbdc3236e64bc23fd430a064b1
> > +%hash sha512 rtems_waf.tar.gz 
> > 9WIROD6rid1M9fsdFWy1Gz/oCsx3l+QGOWoyXnSoGbo/xiyQ+MS+TZU2YoCUNx6/SE18ZeCiq79JYE5H+Yh46Q==
> > +
> > +%include tools/rtems-net-legacy-common.cfg
> > diff --git a/rtems/config/tools/rtems-net-legacy-common.cfg 
> > b/rtems/config/tools/rtems-net-legacy-common.cfg
> > new file mode 100644
> > index 000..6ded30f
> > --- /dev/null
> > +++ b/rtems/config/tools/rtems-net-legacy-common.cfg
> > @@ -0,0 +1,65 @@
> > +#
> > +# RTEMS Legacy networking stack
> > +#
> > +# This configuration file configure's, build's and install's 
> > linetworking.a.
> > +#
> > +
> > +%if %{release} == %{nil}
> > +%define release 1
> > +%endif
> > +
> > +Name:  rtems-net-letgacy-%{rtems_net_version}-%{_host}-%{release}
>
> rtems-net-letgacy -> rtems-net-legacy
>
Thanks.


> > +Summary:   RTEMS net legacy provides legacy networking stack from RTEMS 5 
> > and earlier
> > +Version:   %{rtems_net_version}
> > +Release:   %{release}
> > +URL:   https://git.rtems.org/rtems-net-legacy.git/
> > +
> > +
> > +#
> > +# RTEMS BSP support.
> > +#
> > +%include rtems-bsp.cfg
> > +
> > +#
> > +# Net legacy Source from github.
>
> Why github?
>
We don't have a tar for this in the cgit yet, so this was a workaround.

> > +#
> > +%source set rtems_net_legacy \
> > +  --rsb-file=rtems-net-legacy-%{rtems_net_version}.tar.gz 
> > https://github.com/RTEMS/rtems-net-legacy/archive/%{rtems_net_version}.tar.gz
> > +%source set rtems_waf \
> > +  --rsb-file=rtems_waf.tar.gz 
> > https://github.com/RTEMS/rtems_waf/archive/%{rtems_waf_version}.tar.gz
>
> Please so not reference github for rtems_waf for RTEMS project things. We need
> to be self contained.
>
> The libbsd recipe has an %{rsb_released} check. This will not work with a
> released net-legacy tarball as a released tarball has rtems_waf included, it 
> has
> to be included in the tarball for a release be definition. The release scripts
> inspect a repo for submodules and includes them as source after filtering (we 
> do
> not want to capture things like freebsd-org).
>
Ok, understood. Thanks for the explanation, I'll fix this.

> > +
> > +#
> > +# Prepare the source code.
> > +#
> > +%prep
> > +  build_top=$(pwd)
> > +
> > +  source_dir_net_legacy="rtems-net-legacy-%{rtems_net_version}"
> > +  %source setup rtems_net_legacy -q -n 
> > rtems-net-legacy-%{rtems_net_version}
> > +  %source setup rtems_waf -q -s 1 -c -a -n 
> > rtems-net-legacy-%{rtems_net_version}/rtems_waf
> > +  cd ${build_top}
> > +
> > +#
> > +# Build the source code.
> > +#
> > +%build
> > +  build_top=$(pwd)
> > +
> > +  %{host_build_flags}
> > +
> > +  cd ${source_dir_net_legacy}
> > +
> > +  ./waf distclean configure \
> > +--prefix=%{_prefix} \
> > +--rtems-bsp=%{rtems_bsp_arch_bsp}
> > +
> > +  ./waf
> > +
> > +  cd ${build_top}
> > +
> > +%install
> > +  build_top=$(pwd)
> > +
> > +  cd ${source_dir_net_legacy}
> > +  ./waf install
>
> The --destdir needs to be used as it is in the libbsd recipe. What is here
> installs into the user's prefix and not into the RSB staging area. An RSB 
> build
> is a transaction, it can only install a build once all the pieces in the build
> have built. Installing to the user's prefix would leave the user's prefix in 
> an
> unknown state if a piece did not build.
>
Thanks for the explanation, I took a shortcut to avoid some errors I
was getting with --destdir option,

Re: [PATCH RSB] Add recipe for building rtems-net-legacy

2021-03-08 Thread Chris Johns



On 9/3/21 2:03 pm, Vijay Kumar Banerjee wrote:
> Hi Chris,
> 
> Thanks for reviewing.
> 
> On Mon, Mar 8, 2021 at 7:54 PM Chris Johns  wrote:
>>
>> Hi Vijay,
>>
>> Thank you for sorting this out.
>>
>> On 9/3/21 1:31 pm, Vijay Kumar Banerjee wrote:
>>> ---
>>>  rtems/config/6/rtems-net-legacy.bset  |  4 ++
>>>  rtems/config/tools/rtems-net-legacy-6.cfg | 12 
>>>  .../config/tools/rtems-net-legacy-common.cfg  | 65 +++
>>>  3 files changed, 81 insertions(+)
>>>  create mode 100644 rtems/config/6/rtems-net-legacy.bset
>>>  create mode 100644 rtems/config/tools/rtems-net-legacy-6.cfg
>>>  create mode 100644 rtems/config/tools/rtems-net-legacy-common.cfg
>>>
>>> diff --git a/rtems/config/6/rtems-net-legacy.bset 
>>> b/rtems/config/6/rtems-net-legacy.bset
>>> new file mode 100644
>>> index 000..424091c
>>> --- /dev/null
>>> +++ b/rtems/config/6/rtems-net-legacy.bset
>>> @@ -0,0 +1,4 @@
>>> +#
>>> +# Legacy networking stack
>>> +#
>>> +tools/rtems-net-legacy-6
>>> diff --git a/rtems/config/tools/rtems-net-legacy-6.cfg 
>>> b/rtems/config/tools/rtems-net-legacy-6.cfg
>>> new file mode 100644
>>> index 000..9480269
>>> --- /dev/null
>>> +++ b/rtems/config/tools/rtems-net-legacy-6.cfg
>>> @@ -0,0 +1,12 @@
>>> +#
>>> +# RTEMS Legacy networking stack
>>> +#
>>> +
>>> +#  branch: main
>>> +%define rtems_net_version de0585e271701d5683e5ab332db72230
>>> +%hash sha512 rtems-net-legacy-%{rtems_net_version}.tar.gz \
>>> +   
>>> Kmznx8/DsHLf8MX5wL8b65R7AqJVTmGcwB7I4M8ETB27u666Wi1T5M8SQMLHsZMo9aZ44umWyxdCg6l2OpWr2w==
>>> +%define rtems_waf_version 1a118bbcd52138dbdc3236e64bc23fd430a064b1
>>> +%hash sha512 rtems_waf.tar.gz 
>>> 9WIROD6rid1M9fsdFWy1Gz/oCsx3l+QGOWoyXnSoGbo/xiyQ+MS+TZU2YoCUNx6/SE18ZeCiq79JYE5H+Yh46Q==
>>> +
>>> +%include tools/rtems-net-legacy-common.cfg
>>> diff --git a/rtems/config/tools/rtems-net-legacy-common.cfg 
>>> b/rtems/config/tools/rtems-net-legacy-common.cfg
>>> new file mode 100644
>>> index 000..6ded30f
>>> --- /dev/null
>>> +++ b/rtems/config/tools/rtems-net-legacy-common.cfg
>>> @@ -0,0 +1,65 @@
>>> +#
>>> +# RTEMS Legacy networking stack
>>> +#
>>> +# This configuration file configure's, build's and install's 
>>> linetworking.a.
>>> +#
>>> +
>>> +%if %{release} == %{nil}
>>> +%define release 1
>>> +%endif
>>> +
>>> +Name:  rtems-net-letgacy-%{rtems_net_version}-%{_host}-%{release}
>>
>> rtems-net-letgacy -> rtems-net-legacy
>>
> Thanks.
> 
> 
>>> +Summary:   RTEMS net legacy provides legacy networking stack from RTEMS 5 
>>> and earlier
>>> +Version:   %{rtems_net_version}
>>> +Release:   %{release}
>>> +URL:   https://git.rtems.org/rtems-net-legacy.git/
>>> +
>>> +
>>> +#
>>> +# RTEMS BSP support.
>>> +#
>>> +%include rtems-bsp.cfg
>>> +
>>> +#
>>> +# Net legacy Source from github.
>>
>> Why github?
>>
> We don't have a tar for this in the cgit yet, so this was a workaround.

But we do ...

https://git.rtems.org/rtems-net-legacy/commit/?id=5713f7027984012ea17cdd582e6d0258ee7aa58a

Then the `download` link. Just copy and paste that link into this file...

% shasum -a 512 
rtems-net-legacy-5713f7027984012ea17cdd582e6d0258ee7aa58a.tar.bz2
d1dc27a993fe8fd6f6219eebaa21019dd564a88b1445a9782ffe3ba52238a5ed2bcf8f219966bbf03134f75e467feffe9efb02301d88fec140323f8fe808de78
 rtems-net-legacy-5713f7027984012ea17cdd582e6d0258ee7aa58a.tar.bz2

>>> +#
>>> +%source set rtems_net_legacy \
>>> +  --rsb-file=rtems-net-legacy-%{rtems_net_version}.tar.gz 
>>> https://github.com/RTEMS/rtems-net-legacy/archive/%{rtems_net_version}.tar.gz
>>> +%source set rtems_waf \
>>> +  --rsb-file=rtems_waf.tar.gz 
>>> https://github.com/RTEMS/rtems_waf/archive/%{rtems_waf_version}.tar.gz
>>
>> Please so not reference github for rtems_waf for RTEMS project things. We 
>> need
>> to be self contained.
>>
>> The libbsd recipe has an %{rsb_released} check. This will not work with a
>> released net-legacy tarball as a released tarball has rtems_waf included, it 
>> has
>> to be included in the tarball for a release be definition. The release 
>> scripts
>> inspect a repo for submodules and includes them as source after filtering 
>> (we do
>> not want to capture things like freebsd-org).
>>
> Ok, understood. Thanks for the explanation, I'll fix this.

Thanks

> 
>>> +
>>> +#
>>> +# Prepare the source code.
>>> +#
>>> +%prep
>>> +  build_top=$(pwd)
>>> +
>>> +  source_dir_net_legacy="rtems-net-legacy-%{rtems_net_version}"
>>> +  %source setup rtems_net_legacy -q -n 
>>> rtems-net-legacy-%{rtems_net_version}
>>> +  %source setup rtems_waf -q -s 1 -c -a -n 
>>> rtems-net-legacy-%{rtems_net_version}/rtems_waf
>>> +  cd ${build_top}
>>> +
>>> +#
>>> +# Build the source code.
>>> +#
>>> +%build
>>> +  build_top=$(pwd)
>>> +
>>> +  %{host_build_flags}
>>> +
>>> +  cd ${source_dir_net_legacy}
>>> +
>>> +  ./waf distclean configure \
>>> +--prefix=%{_prefix} \
>>> +--rtems-bsp=%{rtems_bsp_arch_bsp}
>>> +
>>> +  ./waf
>>> +
>>> +  cd ${build_top}
>>> +
>>

Re: [PATCH RSB] Add recipe for building rtems-net-legacy

2021-03-08 Thread Vijay Kumar Banerjee
On Mon, Mar 8, 2021 at 8:23 PM Chris Johns  wrote:
>
>
>
> On 9/3/21 2:03 pm, Vijay Kumar Banerjee wrote:
> > Hi Chris,
> >
> > Thanks for reviewing.
> >
> > On Mon, Mar 8, 2021 at 7:54 PM Chris Johns  wrote:
> >>
> >> Hi Vijay,
> >>
> >> Thank you for sorting this out.
> >>
> >> On 9/3/21 1:31 pm, Vijay Kumar Banerjee wrote:
> >>> ---
> >>>  rtems/config/6/rtems-net-legacy.bset  |  4 ++
> >>>  rtems/config/tools/rtems-net-legacy-6.cfg | 12 
> >>>  .../config/tools/rtems-net-legacy-common.cfg  | 65 +++
> >>>  3 files changed, 81 insertions(+)
> >>>  create mode 100644 rtems/config/6/rtems-net-legacy.bset
> >>>  create mode 100644 rtems/config/tools/rtems-net-legacy-6.cfg
> >>>  create mode 100644 rtems/config/tools/rtems-net-legacy-common.cfg
> >>>
> >>> diff --git a/rtems/config/6/rtems-net-legacy.bset 
> >>> b/rtems/config/6/rtems-net-legacy.bset
> >>> new file mode 100644
> >>> index 000..424091c
> >>> --- /dev/null
> >>> +++ b/rtems/config/6/rtems-net-legacy.bset
> >>> @@ -0,0 +1,4 @@
> >>> +#
> >>> +# Legacy networking stack
> >>> +#
> >>> +tools/rtems-net-legacy-6
> >>> diff --git a/rtems/config/tools/rtems-net-legacy-6.cfg 
> >>> b/rtems/config/tools/rtems-net-legacy-6.cfg
> >>> new file mode 100644
> >>> index 000..9480269
> >>> --- /dev/null
> >>> +++ b/rtems/config/tools/rtems-net-legacy-6.cfg
> >>> @@ -0,0 +1,12 @@
> >>> +#
> >>> +# RTEMS Legacy networking stack
> >>> +#
> >>> +
> >>> +#  branch: main
> >>> +%define rtems_net_version de0585e271701d5683e5ab332db72230
> >>> +%hash sha512 rtems-net-legacy-%{rtems_net_version}.tar.gz \
> >>> +   
> >>> Kmznx8/DsHLf8MX5wL8b65R7AqJVTmGcwB7I4M8ETB27u666Wi1T5M8SQMLHsZMo9aZ44umWyxdCg6l2OpWr2w==
> >>> +%define rtems_waf_version 1a118bbcd52138dbdc3236e64bc23fd430a064b1
> >>> +%hash sha512 rtems_waf.tar.gz 
> >>> 9WIROD6rid1M9fsdFWy1Gz/oCsx3l+QGOWoyXnSoGbo/xiyQ+MS+TZU2YoCUNx6/SE18ZeCiq79JYE5H+Yh46Q==
> >>> +
> >>> +%include tools/rtems-net-legacy-common.cfg
> >>> diff --git a/rtems/config/tools/rtems-net-legacy-common.cfg 
> >>> b/rtems/config/tools/rtems-net-legacy-common.cfg
> >>> new file mode 100644
> >>> index 000..6ded30f
> >>> --- /dev/null
> >>> +++ b/rtems/config/tools/rtems-net-legacy-common.cfg
> >>> @@ -0,0 +1,65 @@
> >>> +#
> >>> +# RTEMS Legacy networking stack
> >>> +#
> >>> +# This configuration file configure's, build's and install's 
> >>> linetworking.a.
> >>> +#
> >>> +
> >>> +%if %{release} == %{nil}
> >>> +%define release 1
> >>> +%endif
> >>> +
> >>> +Name:  rtems-net-letgacy-%{rtems_net_version}-%{_host}-%{release}
> >>
> >> rtems-net-letgacy -> rtems-net-legacy
> >>
> > Thanks.
> >
> >
> >>> +Summary:   RTEMS net legacy provides legacy networking stack from RTEMS 
> >>> 5 and earlier
> >>> +Version:   %{rtems_net_version}
> >>> +Release:   %{release}
> >>> +URL:   https://git.rtems.org/rtems-net-legacy.git/
> >>> +
> >>> +
> >>> +#
> >>> +# RTEMS BSP support.
> >>> +#
> >>> +%include rtems-bsp.cfg
> >>> +
> >>> +#
> >>> +# Net legacy Source from github.
> >>
> >> Why github?
> >>
> > We don't have a tar for this in the cgit yet, so this was a workaround.
>
> But we do ...
>
> https://git.rtems.org/rtems-net-legacy/commit/?id=5713f7027984012ea17cdd582e6d0258ee7aa58a
>
> Then the `download` link. Just copy and paste that link into this file...
>
> % shasum -a 512 
> rtems-net-legacy-5713f7027984012ea17cdd582e6d0258ee7aa58a.tar.bz2
> d1dc27a993fe8fd6f6219eebaa21019dd564a88b1445a9782ffe3ba52238a5ed2bcf8f219966bbf03134f75e467feffe9efb02301d88fec140323f8fe808de78
>  rtems-net-legacy-5713f7027984012ea17cdd582e6d0258ee7aa58a.tar.bz2
>

Thanks!
I didn't notice the link. :p

> >>> +#
> >>> +%source set rtems_net_legacy \
> >>> +  --rsb-file=rtems-net-legacy-%{rtems_net_version}.tar.gz 
> >>> https://github.com/RTEMS/rtems-net-legacy/archive/%{rtems_net_version}.tar.gz
> >>> +%source set rtems_waf \
> >>> +  --rsb-file=rtems_waf.tar.gz 
> >>> https://github.com/RTEMS/rtems_waf/archive/%{rtems_waf_version}.tar.gz
> >>
> >> Please so not reference github for rtems_waf for RTEMS project things. We 
> >> need
> >> to be self contained.
> >>
> >> The libbsd recipe has an %{rsb_released} check. This will not work with a
> >> released net-legacy tarball as a released tarball has rtems_waf included, 
> >> it has
> >> to be included in the tarball for a release be definition. The release 
> >> scripts
> >> inspect a repo for submodules and includes them as source after filtering 
> >> (we do
> >> not want to capture things like freebsd-org).
> >>
> > Ok, understood. Thanks for the explanation, I'll fix this.
>
> Thanks
>
> >
> >>> +
> >>> +#
> >>> +# Prepare the source code.
> >>> +#
> >>> +%prep
> >>> +  build_top=$(pwd)
> >>> +
> >>> +  source_dir_net_legacy="rtems-net-legacy-%{rtems_net_version}"
> >>> +  %source setup rtems_net_legacy -q -n 
> >>> rtems-net-legacy-%{rtems_net_version}
> >>> +  %source setup rtems_waf -q -s 1 -c -a -n 
> >>> rtems-net-legacy-%{rtems_net_

Re: RSB build issue with rtems-libbsd

2021-03-08 Thread Vijay Kumar Banerjee
On Mon, Mar 8, 2021 at 7:57 PM Chris Johns  wrote:
>
> On 9/3/21 1:44 pm, Vijay Kumar Banerjee wrote:
> > On Mon, Mar 8, 2021 at 3:14 PM Joel Sherrill  wrote:
> >> On Mon, Mar 8, 2021, 4:02 PM Chris Johns  wrote:
> >>>
> >>> On 6/3/21 2:24 pm, Vijay Kumar Banerjee wrote:
>  Hello,
> 
>  I'm getting the following error when trying to build rtems-libbsd from
>  RSB. Is there anything that I'm missing?
> 
>  ```
>  ../source-builder/sb-set-builder --prefix=$RTEMS6_PREFIX
>  6/rtems-libbsd --host=powerpc-rtems6 --with-rtems-bsp=beatnik
>  RTEMS Source Builder - Set Builder, 6 (102cb1e6450f)
>  warning: exe: absolute exe found in path: (__chown) /usr/sbin/chown
>  Build Set: 6/rtems-libbsd
>  config: tools/rtems-libbsd-6.cfg
>  error: rtems-bsp.cfg:155: invalid %if operator:  -mcpu=7400
>  -I/home/vijay/development/rtems/6/powerpc-rtems6/beatnik/lib/include
> >>>
> >>> This looks like a bug. Please raise a ticket.
> >>>
>  ==
>  Build FAILED
>  Build Set: Time 0:00:00.046141
>  Build FAILED
> 
>  ```
> 
>  Commenting these checks from rtems-bsp.cfg gets it building.
> >>>
> >>> Unfortunately the checks are needed and this is not the answer.
> >>>
> >>> I wonder how Jennifer has been building libbsd. She is working on this 
> >>> BSP and
> >>> libbsd.
> >>
> >
> > This issue is happening with other bsps as well.
>
> Great and thanks for checking. I asked this question in the ticket. :)
>
> > This error is also being a blocker to building rtems-net-legacy with
> > the new patch. I can have a look at it, do you have any hints on what
> > might be going wrong?
>
> Yes in the ticket :) (in short for the thread run with --trace and compare 
> with
> libbsd).
>
Hi,

I think I found it! :
```
diff --git a/source-builder/sb/config.py b/source-builder/sb/config.py
index cd0bf94..d3ba6cd 100644
--- a/source-builder/sb/config.py
+++ b/source-builder/sb/config.py
@@ -989,7 +989,7 @@ class file:
 else:
 self._error('invalid if bool operator: ' +
reduce(add, ls, ''))
 else:
-if len(ifls) > 3:
+if len(ifls) >= 3:
 for op in ['==', '!=', '>=', '=>', '=<', '<=', '>', '<']:
 ops = s.split(op)
 if len(ops) == 2:

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


Re: [PATCH 0/3] Fix Missing break in switch Coverity issues

2021-03-08 Thread Gedare Bloom
On Mon, Mar 8, 2021 at 7:21 PM Chris Johns  wrote:
>
> On 6/3/21 6:04 am, Gedare Bloom wrote:
> > On Fri, Mar 5, 2021 at 11:48 AM Sebastian Huber
> >  wrote:
> >>
> >> On 05/03/2021 19:40, Joel Sherrill wrote:
> >>
> >>> On Fri, Mar 5, 2021, 12:25 PM Sebastian Huber
> >>>  >>> > wrote:
> >>>
> >>> On 05/03/2021 16:27, Gedare Bloom wrote:
> >>>
> >>> > Should we add a macro for this, e.g., "RTEMS_CASE_NO_BREAK" so
> >>> that we
> >>> > can update them in future if needed for other tools?
> >>> I would just pick a name which is understood by GCC, clang, and
> >>> Coverity. I guess other tools will understand this or why did you
> >>> buy them?
> >>>
> >>>
> >>> Well we didn't pay for any of those but are you wanting a macro or
> >>> just the comment?
> >>
> >> I would just use a comment which is understood by GCC, clang, and
> >> Coverity. What does Linux use?
> >>
> > That's fine, if there is a de facto standard to use, we can go for it.
>
> Looking at the option documentation gcc supports a lot of different possible
> ways and the warning option can change what is selected.
>
> Do we allow all that gcc allows? I hope not.
>

As with other things we should provide a portable way to maintain it.
I would suggest adding to basedefs.h:
#define RTEMS_CASE_FALL_THROUGH
macro as reasonably simple. We can debate a few variations
RTEMS_CASE_FALLTHRU is short and sufficient.

Most likely we'll never have to change it, but this will simplify code
review and avoid typos /* fall-trough */

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


Re: [PATCH rtems-docs] networking: Rename to legacy networking

2021-03-08 Thread Gedare Bloom
On Mon, Mar 8, 2021 at 7:24 PM Vijay Kumar Banerjee  wrote:
>
> ---
>  book/index_book.rst   | 2 +-
>  {networking => legacy-networking}/command.rst | 0
>  {networking => legacy-networking}/conf.py | 4 ++--
>  {networking => legacy-networking}/dec_21140.rst   | 0
>  {networking => legacy-networking}/index.rst   | 2 +-
>  {networking => legacy-networking}/network_servers.rst | 0
>  {networking => legacy-networking}/network_task_structure.rst  | 0
>  {networking => legacy-networking}/networking_driver.rst   | 0
>  {networking => legacy-networking}/preface.rst | 0
>  {networking => legacy-networking}/testing_the_driver.rst  | 0
>  .../using_networking_rtems_app.rst| 0
>  {networking => legacy-networking}/wscript | 0
>  wscript   | 2 +-
>  13 files changed, 5 insertions(+), 5 deletions(-)
>  rename {networking => legacy-networking}/command.rst (100%)
>  rename {networking => legacy-networking}/conf.py (68%)
>  rename {networking => legacy-networking}/dec_21140.rst (100%)
>  rename {networking => legacy-networking}/index.rst (92%)
>  rename {networking => legacy-networking}/network_servers.rst (100%)
>  rename {networking => legacy-networking}/network_task_structure.rst (100%)
>  rename {networking => legacy-networking}/networking_driver.rst (100%)
>  rename {networking => legacy-networking}/preface.rst (100%)
>  rename {networking => legacy-networking}/testing_the_driver.rst (100%)
>  rename {networking => legacy-networking}/using_networking_rtems_app.rst 
> (100%)
>  rename {networking => legacy-networking}/wscript (100%)
>
> diff --git a/book/index_book.rst b/book/index_book.rst
> index 8282006..96ab0ff 100644
> --- a/book/index_book.rst
> +++ b/book/index_book.rst
> @@ -23,7 +23,7 @@ Table of Contents
> cpu_supplement/index.rst
> develenv/index.rst
> filesystem/index.rst
> -   networking/index.rst
> +   legacy-networking/index.rst
other books have an underscore e.g., legacy_networking, should we be consistent?

> porting/index.rst
> posix1003_1/index.rst
> posix_users/index.rst
> diff --git a/networking/command.rst b/legacy-networking/command.rst
> similarity index 100%
> rename from networking/command.rst
> rename to legacy-networking/command.rst
> diff --git a/networking/conf.py b/legacy-networking/conf.py
> similarity index 68%
> rename from networking/conf.py
> rename to legacy-networking/conf.py
> index 1c129bc..6cc01bc 100644
> --- a/networking/conf.py
> +++ b/legacy-networking/conf.py
> @@ -3,12 +3,12 @@ sys.path.insert(0, os.path.abspath('../common/'))
>
>  from conf import *
>
> -project = "RTEMS Networking User Manual"
> +project = "RTEMS Legacy Networking User Manual"
>
>  latex_documents = [
>  ('index',
>   'networking.tex',
> - u'RTEMS Networking User Manual',
> + u'RTEMS Legacy Networking User Manual',
>   u'RTEMS Documentation Project',
>   'manual'),
>  ]
> diff --git a/networking/dec_21140.rst b/legacy-networking/dec_21140.rst
> similarity index 100%
> rename from networking/dec_21140.rst
> rename to legacy-networking/dec_21140.rst
> diff --git a/networking/index.rst b/legacy-networking/index.rst
> similarity index 92%
> rename from networking/index.rst
> rename to legacy-networking/index.rst
> index f56a60d..b85119d 100644
> --- a/networking/index.rst
> +++ b/legacy-networking/index.rst
> @@ -5,7 +5,7 @@
>  .. highlight:: c
>
>  ==
> -RTEMS Network User Manual (|version|).
> +RTEMS Legacy Network User Manual (|version|).
>  ==
>
>  .. topic:: Copyrights and License
> diff --git a/networking/network_servers.rst 
> b/legacy-networking/network_servers.rst
> similarity index 100%
> rename from networking/network_servers.rst
> rename to legacy-networking/network_servers.rst
> diff --git a/networking/network_task_structure.rst 
> b/legacy-networking/network_task_structure.rst
> similarity index 100%
> rename from networking/network_task_structure.rst
> rename to legacy-networking/network_task_structure.rst
> diff --git a/networking/networking_driver.rst 
> b/legacy-networking/networking_driver.rst
> similarity index 100%
> rename from networking/networking_driver.rst
> rename to legacy-networking/networking_driver.rst
> diff --git a/networking/preface.rst b/legacy-networking/preface.rst
> similarity index 100%
> rename from networking/preface.rst
> rename to legacy-networking/preface.rst
> diff --git a/networking/testing_the_driver.rst 
> b/legacy-networking/testing_the_driver.rst
> similarity index 100%
> rename from networking/testing_the_driver.rst
> rename to legacy-networking/testing_the_driver.rst
> diff --git a/networking/using_networking_rtems_app.rst 
> b/legacy-networking/using_networking_rtems_app.rst
>

Re: [5 PATCH 0/2] Backport fixes to zynq uart to RTEMS5

2021-03-08 Thread Gedare Bloom
On Fri, Mar 5, 2021 at 11:59 AM Jan Sommer  wrote:
>
> This patchset backports the commits of Kinsey Moore and myself, which
> fix the stdin behavior for the zynq-uart based console driver.
> I checked the behavior on hardware with the termios.exe application.
> Before, the scanf and similar functions do not wait for user input and return
> immediately. With the patches the application behaves as expected.
>
> A corresponding ticket can be found here: https://devel.rtems.org/ticket/4236
>
> Small side note:
> I noticed that the ARM BSP docs for RTEMS5 list mostly TODO.
> Should I create a patchset backporting the BSP documentation or do you
> want to do that in one go as part of the 5.2 release preparation?

You should do this if you find it valuable. Not many of us take time
to backport to the release docs, and no one will pick those changes up
automatically.

>
> Best regards,
>
> Jan
>
> Jan Sommer (1):
>   bsps/shared: Allow setting baud rate for zynq uart
>
> Kinsey Moore (1):
>   zynq-uart: Fix set_attributes implementation
>
>  bsps/arm/include/bsp/zynq-uart.h  |  7 +++
>  bsps/arm/shared/serial/zynq-uart-polled.c |  2 +-
>  bsps/arm/shared/serial/zynq-uart.c| 77 ---
>  3 files changed, 75 insertions(+), 11 deletions(-)
>
> --
> 2.17.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [PATCH 0/3] Fix Missing break in switch Coverity issues

2021-03-08 Thread Sebastian Huber

On 09/03/2021 06:47, Gedare Bloom wrote:


I would just use a comment which is understood by GCC, clang, and
Coverity. What does Linux use?


That's fine, if there is a de facto standard to use, we can go for it.

Looking at the option documentation gcc supports a lot of different possible
ways and the warning option can change what is selected.

Do we allow all that gcc allows? I hope not.


As with other things we should provide a portable way to maintain it.
I would suggest adding to basedefs.h:
#define RTEMS_CASE_FALL_THROUGH
macro as reasonably simple. We can debate a few variations
RTEMS_CASE_FALLTHRU is short and sufficient.

Most likely we'll never have to change it, but this will simplify code
review and avoid typos /* fall-trough */


Linux uses a macro:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2bf74771ca5610b10c3ac4cd17aacc389e6927ca

My favorite name is RTEMS_FALL_THROUGH.




--
embedded brains GmbH
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: [PATCH 0/3] Fix Missing break in switch Coverity issues

2021-03-08 Thread Gedare Bloom
On Mon, Mar 8, 2021 at 11:04 PM Sebastian Huber
 wrote:
>
> On 09/03/2021 06:47, Gedare Bloom wrote:
>
>  I would just use a comment which is understood by GCC, clang, and
>  Coverity. What does Linux use?
> 
> >>> That's fine, if there is a de facto standard to use, we can go for it.
> >> Looking at the option documentation gcc supports a lot of different 
> >> possible
> >> ways and the warning option can change what is selected.
> >>
> >> Do we allow all that gcc allows? I hope not.
> >>
> > As with other things we should provide a portable way to maintain it.
> > I would suggest adding to basedefs.h:
> > #define RTEMS_CASE_FALL_THROUGH
> > macro as reasonably simple. We can debate a few variations
> > RTEMS_CASE_FALLTHRU is short and sufficient.
> >
> > Most likely we'll never have to change it, but this will simplify code
> > review and avoid typos /* fall-trough */
>
> Linux uses a macro:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2bf74771ca5610b10c3ac4cd17aacc389e6927ca
>
> My favorite name is RTEMS_FALL_THROUGH.
>
Fine with me.

> >
> --
> embedded brains GmbH
> 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