AW: [PATCH v4 3/3] i386: Port to RTEMS

2020-04-15 Thread Jan.Sommer


> -Ursprüngliche Nachricht-
> Von: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de]
> Gesendet: Mittwoch, 15. April 2020 09:23
> An: Sommer, Jan; devel@rtems.org
> Betreff: Re: [PATCH v4 3/3] i386: Port to RTEMS
> 
> On 09/04/2020 15:56, Jan Sommer wrote:
> 
> > - Update imported files to compile rtems-libbsd for i386 based BSPs
> > ---
> >   freebsd-org  |2 +-
> >   freebsd/sbin/sysctl/sysctl.c |8 +
> >   freebsd/sys/dev/pci/pci_pci.c|2 +
> >   freebsd/sys/i386/i386/legacy.c   |  381 -
> >   freebsd/sys/i386/include/machine/cpufunc.h   |2 +
> >   freebsd/sys/i386/include/machine/legacyvar.h |   63 --
> >   freebsd/sys/kern/subr_gtaskqueue.c   |4 +
> Looks good.

Does that ok include the deactivation of the BSD_ASSERT for i386 as well?
I am not that deep in the FreeBSD internals, yet, so I have no reliable gut 
feeling for those kind of changes.

> >   freebsd/sys/net/iflib.c  |   24 +
> Please move this to a separate commit with a reason for the change.
Ok.

> >   freebsd/sys/sys/callout.h|6 +
> 
> Please move this to a separate commit with a reason for the change.
>
Ok.
 
> >   rtemsbsd/i386/include/machine/clock.h|2 +
> >   rtemsbsd/include/rtems/bsd/local/opt_acpi.h  |0
> 
> >   rtemsbsd/include/x86/legacyvar.h |1 +
> >   rtemsbsd/include/x86/specialreg.h| 1074
> ++
> >   rtemsbsd/include/x86/x86_var.h   |  156 
> Where do these files come from?

Originally from freebsd-org/sys/x86/include . 
However, I just noticed that with the path-mappings feature it is now pretty 
easy to solve that with header indirection.
In the next version I will add the files to libbsd.py and add here only a 
oneliner.
That should be more future proof.

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

Re: [PATCH v4 3/3] i386: Port to RTEMS

2020-04-15 Thread Sebastian Huber

On 09/04/2020 15:56, Jan Sommer wrote:


- Update imported files to compile rtems-libbsd for i386 based BSPs
---
  freebsd-org  |2 +-
  freebsd/sbin/sysctl/sysctl.c |8 +
  freebsd/sys/dev/pci/pci_pci.c|2 +
  freebsd/sys/i386/i386/legacy.c   |  381 -
  freebsd/sys/i386/include/machine/cpufunc.h   |2 +
  freebsd/sys/i386/include/machine/legacyvar.h |   63 --
  freebsd/sys/kern/subr_gtaskqueue.c   |4 +

Looks good.

  freebsd/sys/net/iflib.c  |   24 +

Please move this to a separate commit with a reason for the change.

  freebsd/sys/sys/callout.h|6 +


Please move this to a separate commit with a reason for the change.


  rtemsbsd/i386/include/machine/clock.h|2 +
  rtemsbsd/include/rtems/bsd/local/opt_acpi.h  |0



  rtemsbsd/include/x86/legacyvar.h |1 +
  rtemsbsd/include/x86/specialreg.h| 1074 ++
  rtemsbsd/include/x86/x86_var.h   |  156 

Where do these files come from?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [PATCH v4 3/3] i386: Port to RTEMS

2020-04-15 Thread Sebastian Huber

On 09/04/2020 16:10, jan.som...@dlr.de wrote:


-Ursprüngliche Nachricht-
Von: Sommer, Jan
Gesendet: Donnerstag, 9. April 2020 15:57
An:devel@rtems.org
Cc: Sommer, Jan
Betreff: [PATCH v4 3/3] i386: Port to RTEMS

- Update imported files to compile rtems-libbsd for i386 based BSPs
---

[...]

diff --git a/freebsd/sys/kern/subr_gtaskqueue.c
b/freebsd/sys/kern/subr_gtaskqueue.c
index c061c6b0..4ef05e0a 100644
--- a/freebsd/sys/kern/subr_gtaskqueue.c
+++ b/freebsd/sys/kern/subr_gtaskqueue.c
@@ -744,7 +744,9 @@ taskqgroup_attach(struct taskqgroup *qgroup, struct
grouptask *gtask,
__func__, gtask->gt_name, error);
} else
  #else /* __rtems__ */
+#ifndef __i386__
BSD_ASSERT(irq == -1);
+#endif /* __i386 */
  #endif /* __rtems__ */
mtx_unlock(>tqg_lock);
  }
@@ -776,7 +778,9 @@ taskqgroup_attach_deferred(struct taskqgroup
*qgroup, struct grouptask *gtask)

}
  #else /* __rtems__ */
+#ifndef __i386__
BSD_ASSERT(gtask->gt_irq == -1);
+#endif /* __i386 */
  #endif /* __rtems__ */
qgroup->tqg_queue[qid].tgc_cnt++;
LIST_INSERT_HEAD(>tqg_queue[qid].tgc_tasks, gtask,
gt_list);

For example in "iflib_legacy_setup" the function " taskqgroup_attach" is called 
with an irq value other than -1, which triggers the assert.
Now, with the assert disabled the driver seems to work and we can, e.g. get an 
IP with the dhcpcd0x tests.
We haven't managed to find out what the assert is for exactly, so I don't know 
if that opens a can of worms.
Is this safe to do?


It looks like your upper layers request an unsupported feature. I 
disabled several things related to CPU affinity in libbsd since this was 
not properly supported by RTEMS before the EDF SMP scheduler was 
introduced. It may be possible to enable these features now. If you want 
to enable something in this area, please add test cases.


FreeBSD sometimes uses per-CPU data structures. They must be used with care.

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

AW: [PATCH v4 3/3] i386: Port to RTEMS

2020-04-09 Thread Jan.Sommer


> -Ursprüngliche Nachricht-
> Von: Sommer, Jan
> Gesendet: Donnerstag, 9. April 2020 15:57
> An: devel@rtems.org
> Cc: Sommer, Jan
> Betreff: [PATCH v4 3/3] i386: Port to RTEMS
> 
> - Update imported files to compile rtems-libbsd for i386 based BSPs
> ---
>  freebsd-org  |2 +-
>  freebsd/sbin/sysctl/sysctl.c |8 +
>  freebsd/sys/dev/pci/pci_pci.c|2 +
>  freebsd/sys/i386/i386/legacy.c   |  381 -
>  freebsd/sys/i386/include/machine/cpufunc.h   |2 +
>  freebsd/sys/i386/include/machine/legacyvar.h |   63 --
>  freebsd/sys/kern/subr_gtaskqueue.c   |4 +
>  freebsd/sys/net/iflib.c  |   24 +
>  freebsd/sys/sys/callout.h|6 +
>  rtemsbsd/i386/include/machine/clock.h|2 +
>  rtemsbsd/include/rtems/bsd/local/opt_acpi.h  |0
>  rtemsbsd/include/x86/legacyvar.h |1 +
>  rtemsbsd/include/x86/specialreg.h| 1074
> ++
>  rtemsbsd/include/x86/x86_var.h   |  156 
>  14 files changed, 1280 insertions(+), 445 deletions(-)
>  delete mode 100644 freebsd/sys/i386/i386/legacy.c
>  delete mode 100644 freebsd/sys/i386/include/machine/legacyvar.h
>  create mode 100644 rtemsbsd/i386/include/machine/clock.h
>  create mode 100644 rtemsbsd/include/rtems/bsd/local/opt_acpi.h
>  create mode 100644 rtemsbsd/include/x86/legacyvar.h
>  create mode 100644 rtemsbsd/include/x86/specialreg.h
>  create mode 100644 rtemsbsd/include/x86/x86_var.h
> 
> diff --git a/freebsd-org b/freebsd-org
> index 0d1c3913..7e8d1444 16
> --- a/freebsd-org
> +++ b/freebsd-org
> @@ -1 +1 @@
> -Subproject commit 0d1c391321b34b3025cf0e72f2231d836ff76da8
> +Subproject commit 7e8d1444023128d34fb9aa4e4515928a4f794d1b

Somehow messed up here. I will revert the change in the next version.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [PATCH v4 3/3] i386: Port to RTEMS

2020-04-09 Thread Jan.Sommer



> -Ursprüngliche Nachricht-
> Von: Sommer, Jan
> Gesendet: Donnerstag, 9. April 2020 15:57
> An: devel@rtems.org
> Cc: Sommer, Jan
> Betreff: [PATCH v4 3/3] i386: Port to RTEMS
> 
> - Update imported files to compile rtems-libbsd for i386 based BSPs
> ---

[...]
> diff --git a/freebsd/sys/kern/subr_gtaskqueue.c
> b/freebsd/sys/kern/subr_gtaskqueue.c
> index c061c6b0..4ef05e0a 100644
> --- a/freebsd/sys/kern/subr_gtaskqueue.c
> +++ b/freebsd/sys/kern/subr_gtaskqueue.c
> @@ -744,7 +744,9 @@ taskqgroup_attach(struct taskqgroup *qgroup, struct
> grouptask *gtask,
>   __func__, gtask->gt_name, error);
>   } else
>  #else /* __rtems__ */
> +#ifndef __i386__
>   BSD_ASSERT(irq == -1);
> +#endif /* __i386 */
>  #endif /* __rtems__ */
>   mtx_unlock(>tqg_lock);
>  }
> @@ -776,7 +778,9 @@ taskqgroup_attach_deferred(struct taskqgroup
> *qgroup, struct grouptask *gtask)
> 
>   }
>  #else /* __rtems__ */
> +#ifndef __i386__
>   BSD_ASSERT(gtask->gt_irq == -1);
> +#endif /* __i386 */
>  #endif /* __rtems__ */
>   qgroup->tqg_queue[qid].tgc_cnt++;
>   LIST_INSERT_HEAD(>tqg_queue[qid].tgc_tasks, gtask,
> gt_list);

For example in "iflib_legacy_setup" the function " taskqgroup_attach" is called 
with an irq value other than -1, which triggers the assert.
Now, with the assert disabled the driver seems to work and we can, e.g. get an 
IP with the dhcpcd0x tests. 
We haven't managed to find out what the assert is for exactly, so I don't know 
if that opens a can of worms.
Is this safe to do?

[...]
> --
> 2.12.3

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


[PATCH v4 3/3] i386: Port to RTEMS

2020-04-09 Thread Jan Sommer
- Update imported files to compile rtems-libbsd for i386 based BSPs
---
 freebsd-org  |2 +-
 freebsd/sbin/sysctl/sysctl.c |8 +
 freebsd/sys/dev/pci/pci_pci.c|2 +
 freebsd/sys/i386/i386/legacy.c   |  381 -
 freebsd/sys/i386/include/machine/cpufunc.h   |2 +
 freebsd/sys/i386/include/machine/legacyvar.h |   63 --
 freebsd/sys/kern/subr_gtaskqueue.c   |4 +
 freebsd/sys/net/iflib.c  |   24 +
 freebsd/sys/sys/callout.h|6 +
 rtemsbsd/i386/include/machine/clock.h|2 +
 rtemsbsd/include/rtems/bsd/local/opt_acpi.h  |0
 rtemsbsd/include/x86/legacyvar.h |1 +
 rtemsbsd/include/x86/specialreg.h| 1074 ++
 rtemsbsd/include/x86/x86_var.h   |  156 
 14 files changed, 1280 insertions(+), 445 deletions(-)
 delete mode 100644 freebsd/sys/i386/i386/legacy.c
 delete mode 100644 freebsd/sys/i386/include/machine/legacyvar.h
 create mode 100644 rtemsbsd/i386/include/machine/clock.h
 create mode 100644 rtemsbsd/include/rtems/bsd/local/opt_acpi.h
 create mode 100644 rtemsbsd/include/x86/legacyvar.h
 create mode 100644 rtemsbsd/include/x86/specialreg.h
 create mode 100644 rtemsbsd/include/x86/x86_var.h

diff --git a/freebsd-org b/freebsd-org
index 0d1c3913..7e8d1444 16
--- a/freebsd-org
+++ b/freebsd-org
@@ -1 +1 @@
-Subproject commit 0d1c391321b34b3025cf0e72f2231d836ff76da8
+Subproject commit 7e8d1444023128d34fb9aa4e4515928a4f794d1b
diff --git a/freebsd/sbin/sysctl/sysctl.c b/freebsd/sbin/sysctl/sysctl.c
index 30ebe5fd..035c1db2 100644
--- a/freebsd/sbin/sysctl/sysctl.c
+++ b/freebsd/sbin/sysctl/sysctl.c
@@ -69,7 +69,9 @@ static const char rcsid[] =
 #endif
 
 #if defined(__amd64__) || defined(__i386__)
+#ifndef __rtems__
 #include 
+#endif /* __rtems__ */
 #endif
 
 #include 
@@ -832,6 +834,7 @@ S_efi_map(size_t l2, void *p)
 #endif
 
 #if defined(__amd64__) || defined(__i386__)
+#ifndef __rtems__
 static int
 S_bios_smap_xattr(size_t l2, void *p)
 {
@@ -850,6 +853,7 @@ S_bios_smap_xattr(size_t l2, void *p)
(uintmax_t)smap->length);
return (0);
 }
+#endif /* __rtems__ */
 #endif
 
 static int
@@ -1061,7 +1065,11 @@ show_var(int *oid, int nlen)
 #endif
 #if defined(__amd64__) || defined(__i386__)
else if (strcmp(fmt, "S,bios_smap_xattr") == 0)
+#ifndef __rtems__
func = S_bios_smap_xattr;
+#else /* __rtems__ */
+   func = NULL;
+#endif /* __rtems__ */
 #endif
else {
func = NULL;
diff --git a/freebsd/sys/dev/pci/pci_pci.c b/freebsd/sys/dev/pci/pci_pci.c
index 43c71461..5ba3e9a0 100644
--- a/freebsd/sys/dev/pci/pci_pci.c
+++ b/freebsd/sys/dev/pci/pci_pci.c
@@ -1593,6 +1593,7 @@ pcib_attach_common(device_t dev)
sc->flags |= PCIB_SUBTRACTIVE;
break;
 
+#ifndef __rtems__
 #if !(defined(NEW_PCIB) && defined(PCI_RES_BUS))
 /* Compaq R3000 BIOS sets wrong subordinate bus number. */
 case 0x00dd10de:
@@ -1620,6 +1621,7 @@ pcib_attach_common(device_t dev)
break;
}
 #endif
+#endif /* __rtems__ */
 }
 
 if (pci_msi_device_blacklisted(dev))
diff --git a/freebsd/sys/i386/i386/legacy.c b/freebsd/sys/i386/i386/legacy.c
deleted file mode 100644
index 50fa9aa2..
--- a/freebsd/sys/i386/i386/legacy.c
+++ /dev/null
@@ -1,381 +0,0 @@
-#include 
-
-/*-
- * Copyright 1998 Massachusetts Institute of Technology
- *
- * Permission to use, copy, modify, and distribute this software and
- * its documentation for any purpose and without fee is hereby
- * granted, provided that both the above copyright notice and this
- * permission notice appear in all copies, that both the above
- * copyright notice and this permission notice appear in all
- * supporting documentation, and that the name of M.I.T. not be used
- * in advertising or publicity pertaining to distribution of the
- * software without specific, written prior permission.  M.I.T. makes
- * no representations about the suitability of this software for any
- * purpose.  It is provided "as is" without express or implied
- * warranty.
- * 
- * THIS SOFTWARE IS PROVIDED BY M.I.T. ``AS IS''.  M.I.T. DISCLAIMS
- * ALL EXPRESS OR IMPLIED WARRANTIES WITH REGARD TO THIS SOFTWARE,
- * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
- * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT
- * SHALL M.I.T. BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
- * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
- * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
- * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
- * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
- * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
- * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- *