Re: libc++ port, including libc++abi and libunwind

[Patrick Wildt]

On Fri, May 13, 2016 at 09:04:26PM +0100, Stuart Henderson wrote:
> On 2016/05/13 21:49, Patrick Wildt wrote:
> > +BUILD_DEPENDS +=   devel/llvm
> 
> Only thing I noticed in first review was this, please use
> 
> MODULES = lang/clang
> MODCLANG_LANGS =  c++
> MODCLANG_ARCHS =  amd64
> 
> instead of the BUILD_DEPENDS. Then, in theory, you shouldn't need
> these lines in the various Makefiles:
> 
> > +CC=clang
> > +CXX=   clang++
> 
> I'll try to do some testing but I'm a bit swamped at the moment.

Thanks!

FWIW, updated diff based on LLVM 3.8:

diff --git devel/libc++/Makefile devel/libc++/Makefile
new file mode 100644
index 000..1c16190
--- /dev/null
+++ devel/libc++/Makefile
@@ -0,0 +1,57 @@
+# $OpenBSD$
+
+ONLY_FOR_ARCHS = amd64
+DPB_PROPERTIES = parallel
+
+COMMENT =  new implementation of the C++ standard library
+
+LLVM_V =   3.8.0
+DISTNAME = libcxx-${LLVM_V}.src
+PKGNAME =  libc++-${LLVM_V}
+CATEGORIES =   devel
+DISTFILES =libcxx-${LLVM_V}.src${EXTRACT_SUFX} \
+   libcxxabi-${LLVM_V}.src${EXTRACT_SUFX} \
+   libunwind-${LLVM_V}.src${EXTRACT_SUFX}
+MASTER_SITES = http://www.llvm.org/releases/${LLVM_V}/
+EXTRACT_SUFX = .tar.xz
+
+SHARED_LIBS =  c++ 1.0 \
+   c++abi  1.0
+
+# packager notes in http://llvm.org/docs/Packaging.html
+HOMEPAGE = http://www.llvm.org/
+
+MAINTAINER=Patrick Wildt <patr...@blueri.se>
+
+# BSD
+PERMIT_PACKAGE_CDROM = Yes
+
+WANTLIB =  c
+
+MODULES =  lang/clang
+MODCLANG_LANGS =   c++
+MODCLANG_ARCHS =   amd64
+
+SEPARATE_BUILD =   Yes
+
+WRKDIST = ${WRKDIR}/${DISTNAME}
+MAKE_ENV += LIBCXX=${WRKSRC}
+MAKE_ENV += LIBCXXABI=${WRKSRC}/libcxxabi
+MAKE_ENV += LIBUNWIND=${WRKSRC}/libunwind
+
+post-extract:
+   mv ${WRKDIR}/libcxxabi-${LLVM_V}.src ${WRKSRC}/libcxxabi
+   mv ${WRKDIR}/libunwind-${LLVM_V}.src ${WRKSRC}/libunwind
+   mkdir -p ${WRKBUILD}/libcxx
+   mkdir -p ${WRKBUILD}/libcxxabi
+
+pre-build:
+   @printf "major=${LIBc++_VERSION:R}\nminor=${LIBc++_VERSION:E}\n" \
+   >${WRKBUILD}/libcxx/shlib_version
+   @printf "major=${LIBc++abi_VERSION:R}\nminor=${LIBc++abi_VERSION:E}\n" \
+   >${WRKBUILD}/libcxxabi/shlib_version
+   @cp ${FILESDIR}/Makefile ${WRKBUILD}/Makefile
+   @cp ${FILESDIR}/libcxx-Makefile ${WRKBUILD}/libcxx/Makefile
+   @cp ${FILESDIR}/libcxxabi-Makefile ${WRKBUILD}/libcxxabi/Makefile
+
+.include 
diff --git devel/libc++/distinfo devel/libc++/distinfo
new file mode 100644
index 000..e7d0a73
--- /dev/null
+++ devel/libc++/distinfo
@@ -0,0 +1,6 @@
+SHA256 (libcxx-3.8.0.src.tar.xz) = NoBFEblAvIp878fLORprKPXj9T9jcpZWQgINuRF0I3s=
+SHA256 (libcxxabi-3.8.0.src.tar.xz) = 
xe4Ica/27HQTgMSJkAen2X8LeRyB32nSW3RO68XO5QQ=
+SHA256 (libunwind-3.8.0.src.tar.xz) = 
rz6vOezcO56Jhj+2LhqjwTXP3n6UFUJOTjltdIapQis=
+SIZE (libcxx-3.8.0.src.tar.xz) = 1062884
+SIZE (libcxxabi-3.8.0.src.tar.xz) = 508900
+SIZE (libunwind-3.8.0.src.tar.xz) = 60600
diff --git devel/libc++/files/Makefile devel/libc++/files/Makefile
new file mode 100644
index 000..32aef54
--- /dev/null
+++ devel/libc++/files/Makefile
@@ -0,0 +1,7 @@
+# $OpenBSD$
+
+.include 
+
+SUBDIR= libcxx libcxxabi
+
+.include 
diff --git devel/libc++/files/libcxx-Makefile devel/libc++/files/libcxx-Makefile
new file mode 100644
index 000..2e08e38
--- /dev/null
+++ devel/libc++/files/libcxx-Makefile
@@ -0,0 +1,222 @@
+HDRDIR=${LIBCXX}/include
+SRCDIR=${LIBCXX}/src
+AHDRDIR=   ${LIBCXXABI}/include
+UHDRDIR=   ${LIBUNWIND}/include
+CXXINCLUDEDIR= /usr/local/include/c++/v1
+
+.PATH: ${SRCDIR}
+
+LIB=   c++
+LIBDIR=/usr/local/lib
+
+SRCS+= algorithm.cpp\
+   any.cpp\
+   bind.cpp\
+   chrono.cpp\
+   condition_variable.cpp\
+   debug.cpp\
+   exception.cpp\
+   future.cpp\
+   hash.cpp\
+   ios.cpp\
+   iostream.cpp\
+   locale.cpp\
+   memory.cpp\
+   mutex.cpp\
+   new.cpp\
+   random.cpp\
+   regex.cpp\
+   shared_mutex.cpp\
+   stdexcept.cpp\
+   string.cpp\
+   strstream.cpp\
+   system_error.cpp\
+   thread.cpp\
+   typeinfo.cpp\
+   utility.cpp\
+   valarray.cpp
+
+WARNS= 0
+CFLAGS+=   -nostdlib -DLIBCXXABI -I${HDRDIR} -I${SRCDIR}/include \
+   -DLIBCXX_BUILDING_LIBCXXABI -I${AHDRDIR} -I${UHDRDIR}
+CPPFLAGS+= ${CFLAGS}
+.if empty(CXXFLAGS:M-std=*)
+CXXFLAGS+= -std=c++11
+.endif
+
+LDFLAGS+=  --verbose
+INCSGROUPS=STD EXT EXP
+
+STD_HEADERS=   __bit_reference\
+   __config\
+ 

libc++ port, including libc++abi and libunwind

[Patrick Wildt]

Hi,

I created a port for libc++, LLVM's C++ standard library.  I'm not
a port's guy, so bear with me if this is not up to the standard.

The port contains libc++, libc++abi for the low level support and
libunwind as unwinder.  As libc++ and libc++abi kind of depend on each
other's headers I have put them together into a single port.

The cmake Makefiles expect to be compiled as part of a bigger LLVM
project checkout, which is overkill in my opinion.  Thus I have
created my own Makefiles for it.  In theory they could, with a few
modifications, also work in base.

The unwinder is configured to use the Itanium-ABI for exception
handling.  With LLVM/Clang it would also be possible to make ARM use
that ABI for exception handling.

libc++ actually expects the xlocale API to exist.  As we cannot provide
it, we just use Newlib's wrappers that basically ignore any thread-
local locales.  As far as I can see this also breaks a few of the tests,
but it's probably ok as a first step.

Additionally LLVM has to be modified to include the correct C++ header
directory if it is told to use libc++ as stdlib.  I have also appended
that diff, though without any REVISION change to LLVM.

Patrick


libc++ testsuite results:


Results for /home/patrick/openbsd-ports/pobj/libc++-3.7.1/libcxx-3.7.1.src/test:
using clang version 3.7.1 (tags/RELEASE_371/final)
Target: amd64-unknown-openbsd5.9
Thread model: posix
with -std=c++11 -stdlib=libc++ 
-I/home/patrick/openbsd-ports/pobj/libc++-3.7.1/libcxx-3.7.1.src/test/support 
-I/home/patrick/openbsd-ports/pobj/libc++-3.7.1/libcxx-3.7.1.src/include 
-L/home/patrick/openbsd-ports/pobj/libc++-3.7.1/libcxx-3.7.1.src/lib

sections without tests   : 13
sections with failures   : 55
sections without failures: 1106
   +   
total number of sections : 1174

number of tests failed   : 185
number of tests passed   : 4740
   +   
total number of tests: 4925



libc++abi testsuite results:


Results for 
/home/patrick/openbsd-ports/pobj/libc++-3.7.1/libcxx-3.7.1.src/libcxxabi/test:
using clang version 3.7.1 (tags/RELEASE_371/final)
Target: amd64-unknown-openbsd5.9
Thread model: posix
with -std=c++0x -stdlib=libc++

sections without tests   : 3
sections with failures   : 1
sections without failures: 0
   +   
total number of sections : 4

number of tests failed   : 2
number of tests passed   : 39
   +   
total number of tests: 41



diff --git devel/libc++/Makefile devel/libc++/Makefile
new file mode 100644
index 000..9654917
--- /dev/null
+++ devel/libc++/Makefile
@@ -0,0 +1,56 @@
+# $OpenBSD$
+
+ONLY_FOR_ARCHS = amd64
+DPB_PROPERTIES = parallel
+
+COMMENT =  new implementation of the C++ standard library
+
+LLVM_V =   3.7.1
+DISTNAME = libcxx-${LLVM_V}.src
+PKGNAME =  libc++-${LLVM_V}
+REVISION = 0
+CATEGORIES =   devel
+DISTFILES =libcxx-${LLVM_V}.src${EXTRACT_SUFX} \
+   libcxxabi-${LLVM_V}.src${EXTRACT_SUFX} \
+   libunwind-${LLVM_V}.src${EXTRACT_SUFX}
+MASTER_SITES = http://www.llvm.org/releases/${LLVM_V}/
+EXTRACT_SUFX = .tar.xz
+
+SHARED_LIBS =  c++ 1.0 \
+   c++abi  1.0
+
+# packager notes in http://llvm.org/docs/Packaging.html
+HOMEPAGE = http://www.llvm.org/
+
+MAINTAINER=Patrick Wildt <patr...@blueri.se>
+
+# BSD
+PERMIT_PACKAGE_CDROM = Yes
+
+WANTLIB =  c
+
+BUILD_DEPENDS +=   devel/llvm
+
+SEPARATE_BUILD =   Yes
+
+WRKDIST = ${WRKDIR}/${DISTNAME}
+MAKE_ENV += LIBCXX=${WRKSRC}
+MAKE_ENV += LIBCXXABI=${WRKSRC}/libcxxabi
+MAKE_ENV += LIBUNWIND=${WRKSRC}/libunwind
+
+post-extract:
+   mv ${WRKDIR}/libcxxabi-${LLVM_V}.src ${WRKSRC}/libcxxabi
+   mv ${WRKDIR}/libunwind-${LLVM_V}.src ${WRKSRC}/libunwind
+   mkdir -p ${WRKBUILD}/libcxx
+   mkdir -p ${WRKBUILD}/libcxxabi
+
+pre-build:
+   @printf "major=${LIBc++_VERSION:R}\nminor=${LIBc++_VERSION:E}\n" \
+   >${WRKBUILD}/libcxx/shlib_version
+   @printf "major=${LIBc++abi_VERSION:R}\nminor=${LIBc++abi_VERSION:E}\n" \
+   >${WRKBUILD}/libcxxabi/shlib_version
+   @cp ${FILESDIR}/Makefile ${WRKBUILD}/Makefile
+   @cp ${FILESDIR}/libcxx-Makefile ${WRKBUILD}/libcxx/Makefile
+   @cp ${FILESDIR}/libcxxabi-Makefile ${WRKBUILD}/libcxxabi/Makefile
+
+.include 
diff --git devel/libc++/distinfo devel/libc++/distinfo
new file mode 100644
index 000..ac0d557
--- /dev/null
+++ devel/libc++/distinfo
@@ -0,0 +1,6 @@
+SHA256 (libcxx-3.7.1.src.tar.xz) = NX+9QojOmXM

Re: [NEW] devel/aarch64-none-elf with binutils and gcc

[Patrick Wildt]

On Fri, Nov 25, 2016 at 10:54:57AM +0100, Patrick Wildt wrote:
> Hi,
> 
> I would like to import two ports that will allow the cross-build of
> u-boot for 64-bit ARM machines.  This is basically a copy of the
> devel/arm-none-eabi toolchain with a different --target and without
> gdb/newlib (+ one source code patch in gcc-linaro for aarch64,
> patch-gcc_config_aarch64_geniterators_sh).
> 
> Snippet from the DESCRs:
> 
> binutils
>   GNU Binutils collection, configured for the aarch64-none-elf target.
> * ld - the GNU linker.
> * as - the GNU assembler.
> 
> gcc-linaro
>   GNU cross compiler suite, configured for the aarch64-none-elf target.
> 
> ok?
> 
> Patrick

After feedback from Landry I have tried to integrate it into
devel/arm-none-eabi.  This port now has a flavor that generates an
aarch64-none-elf package.  Does this look better?

Patrick

diff --git a/devel/arm-none-eabi/Makefile.inc b/devel/arm-none-eabi/Makefile.inc
index 6abb8bd..c20ac6d 100644
--- a/devel/arm-none-eabi/Makefile.inc
+++ b/devel/arm-none-eabi/Makefile.inc
@@ -1,7 +1,13 @@
 # $OpenBSD: Makefile.inc,v 1.1.1.1 2015/05/28 23:28:25 bmercer Exp $
 
-CONFIG=arm-none-eabi
+FLAVOR?=
+.if "${FLAVOR}" == "aarch64"
+CONFIG=aarch64-none-elf
+.endif
+
+CONFIG?=   arm-none-eabi
 PKGNAME?=  ${CONFIG}-${DISTNAME}
+FULLPKGNAME?=  ${PKGNAME}
 CATEGORIES+=   devel
 
 # GPLv3
@@ -10,7 +16,7 @@ CATEGORIES+=  devel
 PERMIT_PACKAGE_CDROM=   Yes
 
 CONFIGURE_STYLE=gnu
-CONFIGURE_ARGS+=--target=arm-none-eabi\
+CONFIGURE_ARGS+=--target=${CONFIG}  \
--disable-shared\
--disable-nls   \
--disable-werror
diff --git a/devel/arm-none-eabi/binutils/Makefile 
b/devel/arm-none-eabi/binutils/Makefile
index 4c1255f..328d46d 100644
--- a/devel/arm-none-eabi/binutils/Makefile
+++ b/devel/arm-none-eabi/binutils/Makefile
@@ -3,9 +3,19 @@
 COMMENT=   binutils for arm-none-eabi cross-development
 
 V= 2.25
-#REVISION= 0
+REVISION=  0
 DISTNAME=  binutils-${V}
 
+FLAVORS=   aarch64
+
+.if "${FLAVOR}" == "aarch64"
+PKG_ARGS+= -Daarch64=1
+PKG_ARGS+= -Darm=0
+.else
+PKG_ARGS+= -Daarch64=0
+PKG_ARGS+= -Darm=1
+.endif
+
 HOMEPAGE=  https://www.gnu.org/software/binutils/
 
 WANTLIB=   c z
@@ -19,4 +29,6 @@ CONFIGURE_ARGS+=--enable-commonbfdlib=no \
--enable-interwork   \
--enable-multilib
 
+SUBST_VARS +=  CONFIG
+
 .include 
diff --git a/devel/arm-none-eabi/binutils/pkg/PFRAG.aarch64 
b/devel/arm-none-eabi/binutils/pkg/PFRAG.aarch64
new file mode 100644
index 000..78e03e5
--- /dev/null
+++ b/devel/arm-none-eabi/binutils/pkg/PFRAG.aarch64
@@ -0,0 +1,63 @@
+@comment $OpenBSD$
+${CONFIG}/lib/
+${CONFIG}/lib/ldscripts/
+${CONFIG}/lib/ldscripts/aarch64elf.x
+${CONFIG}/lib/ldscripts/aarch64elf.xbn
+${CONFIG}/lib/ldscripts/aarch64elf.xc
+${CONFIG}/lib/ldscripts/aarch64elf.xn
+${CONFIG}/lib/ldscripts/aarch64elf.xr
+${CONFIG}/lib/ldscripts/aarch64elf.xs
+${CONFIG}/lib/ldscripts/aarch64elf.xsc
+${CONFIG}/lib/ldscripts/aarch64elf.xsw
+${CONFIG}/lib/ldscripts/aarch64elf.xu
+${CONFIG}/lib/ldscripts/aarch64elf.xw
+${CONFIG}/lib/ldscripts/aarch64elf32.x
+${CONFIG}/lib/ldscripts/aarch64elf32.xbn
+${CONFIG}/lib/ldscripts/aarch64elf32.xc
+${CONFIG}/lib/ldscripts/aarch64elf32.xn
+${CONFIG}/lib/ldscripts/aarch64elf32.xr
+${CONFIG}/lib/ldscripts/aarch64elf32.xs
+${CONFIG}/lib/ldscripts/aarch64elf32.xsc
+${CONFIG}/lib/ldscripts/aarch64elf32.xsw
+${CONFIG}/lib/ldscripts/aarch64elf32.xu
+${CONFIG}/lib/ldscripts/aarch64elf32.xw
+${CONFIG}/lib/ldscripts/aarch64elf32b.x
+${CONFIG}/lib/ldscripts/aarch64elf32b.xbn
+${CONFIG}/lib/ldscripts/aarch64elf32b.xc
+${CONFIG}/lib/ldscripts/aarch64elf32b.xn
+${CONFIG}/lib/ldscripts/aarch64elf32b.xr
+${CONFIG}/lib/ldscripts/aarch64elf32b.xs
+${CONFIG}/lib/ldscripts/aarch64elf32b.xsc
+${CONFIG}/lib/ldscripts/aarch64elf32b.xsw
+${CONFIG}/lib/ldscripts/aarch64elf32b.xu
+${CONFIG}/lib/ldscripts/aarch64elf32b.xw
+${CONFIG}/lib/ldscripts/aarch64elfb.x
+${CONFIG}/lib/ldscripts/aarch64elfb.xbn
+${CONFIG}/lib/ldscripts/aarch64elfb.xc
+${CONFIG}/lib/ldscripts/aarch64elfb.xn
+${CONFIG}/lib/ldscripts/aarch64elfb.xr
+${CONFIG}/lib/ldscripts/aarch64elfb.xs
+${CONFIG}/lib/ldscripts/aarch64elfb.xsc
+${CONFIG}/lib/ldscripts/aarch64elfb.xsw
+${CONFIG}/lib/ldscripts/aarch64elfb.xu
+${CONFIG}/lib/ldscripts/aarch64elfb.xw
+${CONFIG}/lib/ldscripts/armelf.x
+${CONFIG}/lib/ldscripts/armelf.xbn
+${CONFIG}/lib/ldscripts/armelf.xc
+${CONFIG}/lib/ldscripts/armelf.xn
+${CONFIG}/lib/ldscripts/armelf.xr
+${CONFIG}/lib/ldscripts/armelf.xs
+${CONFIG}/lib/ldscripts/armelf.xsc
+${CONFIG}/lib/ldscripts/armelf.xsw
+${CONFIG}/lib/ldscripts/armelf.xu
+${CONFIG}/lib/ldscripts/armelf.xw
+${CONFIG}/lib/ldscripts/armelfb.x
+${CONFIG}/lib/ldscripts/armelfb.xbn
+${CONFIG}/lib/ldscripts/armelfb.xc
+${C

[NEW] devel/aarch64-none-elf with binutils and gcc

[Patrick Wildt]

Hi,

I would like to import two ports that will allow the cross-build of
u-boot for 64-bit ARM machines.  This is basically a copy of the
devel/arm-none-eabi toolchain with a different --target and without
gdb/newlib (+ one source code patch in gcc-linaro for aarch64,
patch-gcc_config_aarch64_geniterators_sh).

Snippet from the DESCRs:

binutils
  GNU Binutils collection, configured for the aarch64-none-elf target.
* ld - the GNU linker.
* as - the GNU assembler.

gcc-linaro
  GNU cross compiler suite, configured for the aarch64-none-elf target.

ok?

Patrick


aarch64-none-elf.tar.gz
Description: application/tar-gz

Re: [NEW] devel/aarch64-none-elf with binutils and gcc

[Patrick Wildt]

On Tue, Dec 06, 2016 at 09:48:08AM +, Stuart Henderson wrote:
> On 2016/12/04 22:12, Patrick Wildt wrote:
> > If we also add a FLAVOR arm it looks like pkg_add cannot cope with a
> > port gaining a flavor without really changing its name.
> 
> It can, but you need to tell it via @pkgpath. It's a little more work
> but I think it's a more standard way to handle it.
> 
> You can do this by adding "@pkgpath devel/arm-none-eabi/binutils" and
> "@pkgpath devel/arm-none-eabi/gcc-linaro" to the various PFRAG.arm files,
> remove the -Darm / -Daarch64 workaround, and I think also guard against
> someone trying FLAVOR="aarch64 arm", e.g.
> 
> FLAVOR?=  arm
> .if "${FLAVOR}" == "aarch64"
> CONFIG=   aarch64-none-elf
> .elif "${FLAVOR}" == "arm"
> CONFIG=   arm-none-eabi
> .else
> ERRORS=   Fatal: invalid combination of FLAVORs
> .endif
> 
> Since this changes the pkgpath, dependencies need a bump to chase it -
> you're already bumping the various devel/arm-none-eabi so...
> 
> sqlite> select * from depends where dependspath like 'devel/arm-none-eabi%' 
>...> and fullpkgpath not like 'devel/arm-none-eabi%';
> sysutils/u-boot|devel/arm-none-eabi/gcc-linaro|||devel/arm-none-eabi/gcc-linaro|B
> 
> ...sysutils/u-boot is the only thing you'd need to touch.
> 
> Minor point but to make it easier to review update diffs in the future,
> I would also define a variable for the gcc version, like
> 
> GCC_V=4.9.4
> SUBST_VARS+=  GCC_V
> 
> and use it in PLISTs
> 
> -lib/gcc/${CONFIG}/4.9.4/...
> +lib/gcc/${CONFIG}/${GCC_V}/...
> 
> > FULLPKGNAME seems to be PKGNAME-FLAVOR, which would looks like
> > aarch64-none-elf-gcc-linaro-VERSION-aarch64.  I overwrite FULLPKGNAME
> > so that it stays aarch64-none-elf-gcc-linaro-VERSION.
> 
> Yes I think that's the right thing to do.
> 

zhuk@ gave me some of those pointers as well last night.  I also added
the @pkgpath, though he said I should explicitly add the trailing comma.

I also added the 4.9.4 -> VAR suggestion.  For u-boot I have another
diff that also adds aarch64 support to u-boot.

diff --git a/devel/arm-none-eabi/Makefile b/devel/arm-none-eabi/Makefile
index 773d78e..71e8b7a 100644
--- a/devel/arm-none-eabi/Makefile
+++ b/devel/arm-none-eabi/Makefile
@@ -2,7 +2,9 @@
 
 SUBDIR =
 SUBDIR += binutils
+SUBDIR += binutils,aarch64
 SUBDIR += gcc-linaro
+SUBDIR += gcc-linaro,aarch64
 SUBDIR += gdb
 SUBDIR += newlib
 
diff --git a/devel/arm-none-eabi/Makefile.inc b/devel/arm-none-eabi/Makefile.inc
index 6abb8bd..9944e62 100644
--- a/devel/arm-none-eabi/Makefile.inc
+++ b/devel/arm-none-eabi/Makefile.inc
@@ -1,7 +1,8 @@
 # $OpenBSD: Makefile.inc,v 1.1.1.1 2015/05/28 23:28:25 bmercer Exp $
 
-CONFIG=arm-none-eabi
+CONFIG?=   arm-none-eabi
 PKGNAME?=  ${CONFIG}-${DISTNAME}
+FULLPKGNAME?=  ${PKGNAME}
 CATEGORIES+=   devel
 
 # GPLv3
@@ -10,7 +11,7 @@ CATEGORIES+=  devel
 PERMIT_PACKAGE_CDROM=   Yes
 
 CONFIGURE_STYLE=gnu
-CONFIGURE_ARGS+=--target=arm-none-eabi\
+CONFIGURE_ARGS+=--target=${CONFIG}  \
--disable-shared\
--disable-nls   \
--disable-werror
diff --git a/devel/arm-none-eabi/binutils/Makefile 
b/devel/arm-none-eabi/binutils/Makefile
index 4c1255f..f701d38 100644
--- a/devel/arm-none-eabi/binutils/Makefile
+++ b/devel/arm-none-eabi/binutils/Makefile
@@ -1,11 +1,22 @@
 # $OpenBSD: Makefile,v 1.1.1.1 2015/05/28 23:28:25 bmercer Exp $
 
-COMMENT=   binutils for arm-none-eabi cross-development
+COMMENT=   binutils for ${CONFIG} cross-development
 
 V= 2.25
-#REVISION= 0
+REVISION=  0
 DISTNAME=  binutils-${V}
 
+FLAVORS=   aarch64 arm
+FLAVOR?=   arm
+
+.if "${FLAVOR}" == "aarch64"
+CONFIG=aarch64-none-elf
+.elif "${FLAVOR}" == "arm"
+CONFIG=arm-none-eabi
+.else
+ERRORS+=   "either aarch64 or arm FLAVOR should be set"
+.endif
+
 HOMEPAGE=  https://www.gnu.org/software/binutils/
 
 WANTLIB=   c z
@@ -19,4 +30,6 @@ CONFIGURE_ARGS+=--enable-commonbfdlib=no \
--enable-interwork   \
--enable-multilib
 
+SUBST_VARS +=  CONFIG
+
 .include 
diff --git a/devel/arm-none-eabi/binutils/pkg/DESCR 
b/devel/arm-none-eabi/binutils/pkg/DESCR
index 03d6502..f523cf9 100644
--- a/devel/arm-none-eabi/binutils/pkg/DESCR
+++ b/devel/arm-none-eabi/binutils/pkg/DESCR
@@ -1,4 +1,4 @@
-GNU Binutils collection, configured for the arm-none-eabi target.
+GNU Binutils collection, configured for the ${CONFIG} target.
   * ld - the GNU linker.
   * as - the GNU assembler.
 
diff --git a/devel/arm-none-eabi/binutils/pkg/PFRAG.aarch64 
b/devel/arm-none-eabi/binutils/pkg/PFRAG.

blink1: openbsd backend / remove libusb dependency

[Patrick Wildt]

Hi,

blink1 uses libusb-compat to talk to a USB device that speaks hid.  I
have come to realize that the usage of libusb by blink1 makes libusb
send 4 packets to each connected USB device when it tries to find which
USB devices are connected.  I have USB sticks that abort operation as
soon as they receive a "get config descriptor" while doing block read/
write operations.  This means that EHCI transfers time out and might
even throw a panic, simply by calling blink1-tool.

Instead of using and depending on libusb (especially the old "compat"
version) I propose to change blink1 to talk to USB hid devices only
through uhid(4).  This has the benefits that we don't depend on libusb,
only talk to uhid(4) devices and not _all_ USB devices, don't stress the
USB bus, and simplify the implementation.  Unfortunately this means we
implement another backend (that can probably be used my more BSDs).

Additionally it prolly make sense to debug libusb1 and make this whole
HIDAPI layer work without creating any other packet to foreign devices.
Still I think as a first step it's better to clean up and simplify the
blink1 USB layer by just making it talk to /dev/uhid.

Comments?

Patrick

diff --git a/misc/blink1/Makefile b/misc/blink1/Makefile
index 177de02..623f315 100644
--- a/misc/blink1/Makefile
+++ b/misc/blink1/Makefile
@@ -3,6 +3,7 @@
 COMMENT =  software tools for blink(1) LED notification light
 
 V =1.98
+REVISION = 0
 DISTNAME = ${GH_PROJECT}-${V}
 
 SO_V = 0.1
@@ -17,15 +18,13 @@ MAINTAINER =Joerg Jung 
 # Creative Commons - Attribution - ShareAlike 3.0
 PERMIT_PACKAGE_CDROM = Yes
 
-WANTLIB += c pthread usb
+WANTLIB += c
 
 GH_ACCOUNT =   todbot
 GH_PROJECT =   blink1
 GH_TAGNAME =   v${V}
 
-LIB_DEPENDS =  devel/libusb-compat
-
-MAKE_FLAGS =   CC="${CC}" USBLIB_TYPE=HIDDATA \
+MAKE_FLAGS =   CC="${CC}" USBLIB_TYPE=OPENBSD \
 GH_TAGNAME=${GH_TAGNAME} SO_V=${SO_V}
 MAKE_ENV = LDFLAGS="${LDFLAGS}"
 FAKE_FLAGS =   DESTDIR=""
diff --git a/misc/blink1/patches/patch-commandline_Makefile 
b/misc/blink1/patches/patch-commandline_Makefile
index bf32391..c582749 100644
--- a/misc/blink1/patches/patch-commandline_Makefile
+++ b/misc/blink1/patches/patch-commandline_Makefile
@@ -3,7 +3,7 @@ $OpenBSD: patch-commandline_Makefile,v 1.2 2015/12/23 10:53:53 
bluhm Exp $
 todo: submit to upstream
 
 --- commandline/Makefile.orig  Wed Sep  9 03:06:56 2015
-+++ commandline/Makefile   Wed Dec 23 11:33:08 2015
 commandline/Makefile   Tue Dec  6 13:23:19 2016
 @@ -113,9 +113,13 @@ ifeq "$(UNAME)" "FreeBSD"
OS=freebsd
  endif
@@ -19,7 +19,7 @@ todo: submit to upstream
  # deal with case of no git or no git tags, check for presence of "v" (i.e. 
"v1.93")
  ifneq ($(findstring v,$(GIT_TAG)), v)
GIT_TAG:="v0"
-@@ -278,6 +282,37 @@ INCLOCATION ?= $(PREFIX)/include
+@@ -278,6 +282,41 @@ INCLOCATION ?= $(PREFIX)/include
  
  endif
  
@@ -43,6 +43,10 @@ todo: submit to upstream
 +LIBS   += `pkg-config libusb --libs`
 +endif
 +
++ifeq "$(USBLIB_TYPE)" "OPENBSD"
++CFLAGS += -DUSE_OPENBSD -fPIC
++endif
++
 +LIBFLAGS = -shared -o $(LIBTARGET) $(LIBS)
 +EXE=
 +
@@ -57,7 +61,7 @@ todo: submit to upstream
  #  WRT Linux  
  ifeq "$(OS)" "wrtlinux"
  LIBTARGET = libblink1.so
-@@ -371,7 +406,7 @@ endif
+@@ -371,7 +410,7 @@ endif
  
  #CFLAGS += -O -Wall -std=gnu99 -I ../hardware/firmware 
  CFLAGS += -std=gnu99 
@@ -66,7 +70,7 @@ todo: submit to upstream
  CFLAGS += -DBLINK1_VERSION=\"$(BLINK1_VERSION)\"
  
  OBJS +=  blink1-lib.o 
-@@ -389,6 +424,7 @@ help:
+@@ -389,6 +428,7 @@ help:
@echo "make OS=windows ... build Windows  blink1-lib and blink1-tool" 
@echo "make OS=linux   ... build Linuxblink1-lib and blink1-tool" 
@echo "make OS=freebsd ... build FreeBSDblink1-lib and blink1-tool" 
@@ -74,7 +78,7 @@ todo: submit to upstream
@echo "make OS=macosx  ... build Mac OS X blink1-lib and blink1-tool" 
@echo "make OS=wrt ... build OpenWrt blink1-lib and blink1-tool"
@echo "make OS=wrtcross... build for OpenWrt using cross-compiler"
-@@ -409,7 +445,7 @@ $(OBJS): %.o: %.c
+@@ -409,7 +449,7 @@ $(OBJS): %.o: %.c
  
  blink1-tool: $(OBJS) blink1-tool.o
$(CC) $(CFLAGS) -c blink1-tool.c -o blink1-tool.o
@@ -83,7 +87,7 @@ todo: submit to upstream
  
  # FIXME: verify we don't need MONGOOSE_LIBS and pthread & dl are avilable 
everywhere
  blink1-tiny-server: $(OBJS) server/blink1-tiny-server.c
-@@ -428,9 +464,9 @@ package: lib blink1-tool
+@@ -428,9 +468,9 @@ package: lib blink1-tool
@#mkdir -f builds && cp blink1-tool-$(PKGOKS).zip builds
  
  install: all
diff --git 
a/misc/blink1/patches/patch-commandline_blink1-lib-lowlevel-openbsd_h 

Re: U-Boot for AArch64

[Patrick Wildt]

On Sat, Dec 10, 2016 at 11:23:54AM +1100, Jonathan Gray wrote:
> On Tue, Dec 06, 2016 at 06:31:59PM +0100, Patrick Wildt wrote:
> > Hi,
> > 
> > now that we have an AArch64-capable toolchain for our arm64 efforts, we
> > can start compiling 64-bit u-boots.  Instead of creating another port
> > for that we can make u-boot create different packages depending on the
> > flavor.
> > 
> > To upgrade from u-boot to u-boot-arm we'd need a Quirk as well.
> > 
> > Patrick
> 
> Setting FULLPKGNAME like that allows both FLAVORS to be installed
> at the same time?  The pine64 discussions on the u-boot list seem

Yes, exactly.  The idea was to be able to be able to use both at the
same time.

> to be going in the direction of a 32 bit config for the SPL while
> still only having a 64 bit target for the main u-boot image.
> 
> And 'make update-plist' would additionally need
> 'FLAVOR=aarch64 make update-list' when updating u-boot?

Yes, that's true.  One pass with ARM, copy the list to PFRAG.arm,
another pass with aarch64, copy the list to PFRAG.aarch64.  It's
a bit of a hassle.

> The quirks package is going to have to be added to the list manually
> copied over into the arm packages directory until there are
> arm packages built.
> 
> > 
> > diff --git a/sysutils/u-boot/Makefile b/sysutils/u-boot/Makefile
> > index 2856581..5b966e1 100644
> > --- a/sysutils/u-boot/Makefile
> > +++ b/sysutils/u-boot/Makefile
> > @@ -1,7 +1,14 @@
> >  #  $OpenBSD: Makefile,v 1.10 2016/11/20 01:47:00 jsg Exp $
> >  
> > +FLAVORS=   aarch64 arm
> > +FLAVOR?=   arm
> > +
> >  COMMENT=   U-Boot firmware
> > -DISTNAME=  u-boot-2016.11
> > +VERSION=   2016.11
> > +DISTNAME=  u-boot-${VERSION}
> > +PKGNAME=   u-boot-${FLAVOR}-${VERSION}
> > +FULLPKGNAME=   ${PKGNAME}
> > +REVISION=  0
> >  CATEGORIES=sysutils
> >  HOMEPAGE=  http://www.denx.de/wiki/U-Boot
> >  MAINTAINER=Jonathan Gray <j...@openbsd.org>
> > @@ -13,12 +20,26 @@ MASTER_SITES=   ftp://ftp.denx.de/pub/u-boot/
> >  EXTRACT_SUFX=  .tar.bz2
> >  PKG_ARCH=  *
> >  
> > -BUILD_DEPENDS= devel/arm-none-eabi/gcc-linaro \
> > -   devel/dtc
> > -MAKE_ENV+= CROSS_COMPILE="arm-none-eabi-" KBUILD_VERBOSE=1
> > +BUILD_DEPENDS= devel/dtc
> > +MAKE_ENV=  KBUILD_VERBOSE=1
> > +
> > +.if "${FLAVOR}" == "aarch64"
> > +BUILD_DEPENDS+=devel/arm-none-eabi/gcc-linaro,aarch64
> > +MAKE_ENV+= CROSS_COMPILE="aarch64-none-elf-"
> > +.elif "${FLAVOR}" == "arm"
> > +BUILD_DEPENDS+=devel/arm-none-eabi/gcc-linaro
> > +MAKE_ENV+= CROSS_COMPILE="arm-none-eabi-"
> > +.endif
> > +
> >  USE_GMAKE= Yes
> >  NO_TEST=   Yes
> >  
> > +.if "${FLAVOR}" == "aarch64"
> > +BOARDS=\
> > +   dragonboard410c \
> > +   pine64_plus \
> > +   rpi_3
> > +.elif "${FLAVOR}" == "arm"
> >  BOARDS=\
> > omap3_beagle \
> > omap4_panda \
> > @@ -52,6 +73,7 @@ BOARDS=\
> > rpi_3_32b \
> > vexpress_ca15_tc2 \
> > vexpress_ca9x4
> > +.endif
> >  
> >  FILES=\
> > MLO \
> > diff --git a/sysutils/u-boot/patches/patch-tools_relocate-rela_c 
> > b/sysutils/u-boot/patches/patch-tools_relocate-rela_c
> > new file mode 100644
> > index 000..b4aeff8
> > --- /dev/null
> > +++ b/sysutils/u-boot/patches/patch-tools_relocate-rela_c
> > @@ -0,0 +1,19 @@
> > +$OpenBSD$
> > +--- tools/relocate-rela.c.orig Sat Nov  5 17:01:51 2016
> >  tools/relocate-rela.c  Sat Nov  5 17:05:23 2016
> > +@@ -50,6 +50,7 @@ static bool supported_rela(Elf64_Rela *rela)
> > +   }
> > + }
> > + 
> > ++#if !defined(__OpenBSD__)
> > + static inline uint64_t swap64(uint64_t val)
> > + {
> > +   return ((val >> 56) & 0x00ffULL) |
> > +@@ -61,6 +62,7 @@ static inline uint64_t swap64(uint64_t val)
> > +  ((val << 40) & 0x00ffULL) |
> > +  ((val << 56) & 0xff00ULL);
> > + }
> > ++#endif
> > + 
> > + #if __BYTE_ORDER == __LITTLE_ENDIAN
> > + static inline uint64_t be64(uint64_t val)
> > diff --git a/sysutils/u-boot/pkg/PFRAG.aarch64 
> > b/sysutils/u-boot/pkg/PFRAG.aarch64
> > new file mode 100644
> > index 000..0854fee
> > --- /dev/null
> > +++ b/sysutils/u-boot/pkg/PFRAG.aarch64
> > @@ -0,0 +1,12 @@
> > +@comment $OpenBSD$
> > +share/u-boot/
> > 

Re: blink1: openbsd backend / remove libusb dependency

[Patrick Wildt]

On Tue, Dec 06, 2016 at 05:22:20PM +0100, Martin Pieuchot wrote:
> On 06/12/16(Tue) 16:40, Patrick Wildt wrote:
> > [...] 
> > blink1 uses libusb-compat to talk to a USB device that speaks hid.  I
> > have come to realize that the usage of libusb by blink1 makes libusb
> > send 4 packets to each connected USB device when it tries to find which
> > USB devices are connected.
> 
> That's a bug in libusb/kernel interface and should be fixed.  libusb1
> properly documents which functions MUST NOT generate traffics, and we
> do not respect that.
> 
> > [...] I have USB sticks that abort operation as
> > soon as they receive a "get config descriptor" while doing block read/
> > write operations.  This means that EHCI transfers time out and might
> > even throw a panic, simply by calling blink1-tool.
> > 
> > Instead of using and depending on libusb (especially the old "compat"
> > version) I propose to change blink1 to talk to USB hid devices only
> > through uhid(4).  This has the benefits that we don't depend on libusb,
> > only talk to uhid(4) devices and not _all_ USB devices, don't stress the
> > USB bus, and simplify the implementation.  Unfortunately this means we
> > implement another backend (that can probably be used my more BSDs).
> 
> Basically what you say is "let's not fix the bugs in libusb and keep the
> old unused interface".  I disagree with this approach.  libusb *is* a
> standard so better fix and improve it rather that work around it.
> 
> Improving libusb1 will result in better USB support for everybody.
> 

I fully agree that libusb has to be fixed.

blink(1) still uses the libusb-compat library in the hiddata backend.
The hiddata backend is supposedly only for low resource linuxes.  The
better backend would be hidapi, which uses libusb1 directly.  But that
doesn't work either (for other reasons, apart from the original).

I needed this bug workarounded right now, so this was the easiest
solution for now to share and talk about.  At least now I know that
you think uhid(4) should be gone completely and libusb is the way to
go.  Which means I have a workaround for now, but will throw away this
diff and concentrate on debugging blink1 with the hidapi backend in
combination with libusb.  Good.

Patrick

U-Boot for AArch64

[Patrick Wildt]

Hi,

now that we have an AArch64-capable toolchain for our arm64 efforts, we
can start compiling 64-bit u-boots.  Instead of creating another port
for that we can make u-boot create different packages depending on the
flavor.

To upgrade from u-boot to u-boot-arm we'd need a Quirk as well.

Patrick

diff --git a/sysutils/u-boot/Makefile b/sysutils/u-boot/Makefile
index 2856581..5b966e1 100644
--- a/sysutils/u-boot/Makefile
+++ b/sysutils/u-boot/Makefile
@@ -1,7 +1,14 @@
 #  $OpenBSD: Makefile,v 1.10 2016/11/20 01:47:00 jsg Exp $
 
+FLAVORS=   aarch64 arm
+FLAVOR?=   arm
+
 COMMENT=   U-Boot firmware
-DISTNAME=  u-boot-2016.11
+VERSION=   2016.11
+DISTNAME=  u-boot-${VERSION}
+PKGNAME=   u-boot-${FLAVOR}-${VERSION}
+FULLPKGNAME=   ${PKGNAME}
+REVISION=  0
 CATEGORIES=sysutils
 HOMEPAGE=  http://www.denx.de/wiki/U-Boot
 MAINTAINER=Jonathan Gray 
@@ -13,12 +20,26 @@ MASTER_SITES=   ftp://ftp.denx.de/pub/u-boot/
 EXTRACT_SUFX=  .tar.bz2
 PKG_ARCH=  *
 
-BUILD_DEPENDS= devel/arm-none-eabi/gcc-linaro \
-   devel/dtc
-MAKE_ENV+= CROSS_COMPILE="arm-none-eabi-" KBUILD_VERBOSE=1
+BUILD_DEPENDS= devel/dtc
+MAKE_ENV=  KBUILD_VERBOSE=1
+
+.if "${FLAVOR}" == "aarch64"
+BUILD_DEPENDS+=devel/arm-none-eabi/gcc-linaro,aarch64
+MAKE_ENV+= CROSS_COMPILE="aarch64-none-elf-"
+.elif "${FLAVOR}" == "arm"
+BUILD_DEPENDS+=devel/arm-none-eabi/gcc-linaro
+MAKE_ENV+= CROSS_COMPILE="arm-none-eabi-"
+.endif
+
 USE_GMAKE= Yes
 NO_TEST=   Yes
 
+.if "${FLAVOR}" == "aarch64"
+BOARDS=\
+   dragonboard410c \
+   pine64_plus \
+   rpi_3
+.elif "${FLAVOR}" == "arm"
 BOARDS=\
omap3_beagle \
omap4_panda \
@@ -52,6 +73,7 @@ BOARDS=\
rpi_3_32b \
vexpress_ca15_tc2 \
vexpress_ca9x4
+.endif
 
 FILES=\
MLO \
diff --git a/sysutils/u-boot/patches/patch-tools_relocate-rela_c 
b/sysutils/u-boot/patches/patch-tools_relocate-rela_c
new file mode 100644
index 000..b4aeff8
--- /dev/null
+++ b/sysutils/u-boot/patches/patch-tools_relocate-rela_c
@@ -0,0 +1,19 @@
+$OpenBSD$
+--- tools/relocate-rela.c.orig Sat Nov  5 17:01:51 2016
 tools/relocate-rela.c  Sat Nov  5 17:05:23 2016
+@@ -50,6 +50,7 @@ static bool supported_rela(Elf64_Rela *rela)
+   }
+ }
+ 
++#if !defined(__OpenBSD__)
+ static inline uint64_t swap64(uint64_t val)
+ {
+   return ((val >> 56) & 0x00ffULL) |
+@@ -61,6 +62,7 @@ static inline uint64_t swap64(uint64_t val)
+  ((val << 40) & 0x00ffULL) |
+  ((val << 56) & 0xff00ULL);
+ }
++#endif
+ 
+ #if __BYTE_ORDER == __LITTLE_ENDIAN
+ static inline uint64_t be64(uint64_t val)
diff --git a/sysutils/u-boot/pkg/PFRAG.aarch64 
b/sysutils/u-boot/pkg/PFRAG.aarch64
new file mode 100644
index 000..0854fee
--- /dev/null
+++ b/sysutils/u-boot/pkg/PFRAG.aarch64
@@ -0,0 +1,12 @@
+@comment $OpenBSD$
+share/u-boot/
+share/u-boot/dragonboard410c/
+share/u-boot/dragonboard410c/u-boot
+share/u-boot/dragonboard410c/u-boot.bin
+share/u-boot/pine64_plus/
+share/u-boot/pine64_plus/u-boot
+share/u-boot/pine64_plus/u-boot.bin
+share/u-boot/pine64_plus/u-boot.img
+share/u-boot/rpi_3/
+share/u-boot/rpi_3/u-boot
+share/u-boot/rpi_3/u-boot.bin
diff --git a/sysutils/u-boot/pkg/PFRAG.arm b/sysutils/u-boot/pkg/PFRAG.arm
new file mode 100644
index 000..129a42f
--- /dev/null
+++ b/sysutils/u-boot/pkg/PFRAG.arm
@@ -0,0 +1,151 @@
+@comment $OpenBSD$
+share/u-boot/
+share/u-boot/A10-OLinuXino-Lime/
+share/u-boot/A10-OLinuXino-Lime/u-boot
+share/u-boot/A10-OLinuXino-Lime/u-boot-sunxi-with-spl.bin
+share/u-boot/A10-OLinuXino-Lime/u-boot.bin
+share/u-boot/A10-OLinuXino-Lime/u-boot.img
+share/u-boot/A10s-OLinuXino-M/
+share/u-boot/A10s-OLinuXino-M/u-boot
+share/u-boot/A10s-OLinuXino-M/u-boot-sunxi-with-spl.bin
+share/u-boot/A10s-OLinuXino-M/u-boot.bin
+share/u-boot/A10s-OLinuXino-M/u-boot.img
+share/u-boot/A20-OLinuXino-Lime/
+share/u-boot/A20-OLinuXino-Lime/u-boot
+share/u-boot/A20-OLinuXino-Lime/u-boot-sunxi-with-spl.bin
+share/u-boot/A20-OLinuXino-Lime/u-boot.bin
+share/u-boot/A20-OLinuXino-Lime/u-boot.img
+share/u-boot/A20-OLinuXino-Lime2/
+share/u-boot/A20-OLinuXino-Lime2/u-boot
+share/u-boot/A20-OLinuXino-Lime2/u-boot-sunxi-with-spl.bin
+share/u-boot/A20-OLinuXino-Lime2/u-boot.bin
+share/u-boot/A20-OLinuXino-Lime2/u-boot.img
+share/u-boot/A20-OLinuXino_MICRO/
+share/u-boot/A20-OLinuXino_MICRO/u-boot
+share/u-boot/A20-OLinuXino_MICRO/u-boot-sunxi-with-spl.bin
+share/u-boot/A20-OLinuXino_MICRO/u-boot.bin
+share/u-boot/A20-OLinuXino_MICRO/u-boot.img
+share/u-boot/Bananapi/
+share/u-boot/Bananapi/u-boot
+share/u-boot/Bananapi/u-boot-sunxi-with-spl.bin
+share/u-boot/Bananapi/u-boot.bin
+share/u-boot/Bananapi/u-boot.img
+share/u-boot/Bananapro/
+share/u-boot/Bananapro/u-boot
+share/u-boot/Bananapro/u-boot-sunxi-with-spl.bin
+share/u-boot/Bananapro/u-boot.bin
+share/u-boot/Bananapro/u-boot.img
+share/u-boot/CHIP/

Re: [NEW] devel/aarch64-none-elf with binutils and gcc

[Patrick Wildt]

On Fri, Nov 25, 2016 at 05:57:24PM +0100, Patrick Wildt wrote:
> On Fri, Nov 25, 2016 at 10:54:57AM +0100, Patrick Wildt wrote:
> > Hi,
> > 
> > I would like to import two ports that will allow the cross-build of
> > u-boot for 64-bit ARM machines.  This is basically a copy of the
> > devel/arm-none-eabi toolchain with a different --target and without
> > gdb/newlib (+ one source code patch in gcc-linaro for aarch64,
> > patch-gcc_config_aarch64_geniterators_sh).
> > 
> > Snippet from the DESCRs:
> > 
> > binutils
> >   GNU Binutils collection, configured for the aarch64-none-elf target.
> > * ld - the GNU linker.
> > * as - the GNU assembler.
> > 
> > gcc-linaro
> >   GNU cross compiler suite, configured for the aarch64-none-elf target.
> > 
> > ok?
> > 
> > Patrick
> 
> After feedback from Landry I have tried to integrate it into
> devel/arm-none-eabi.  This port now has a flavor that generates an
> aarch64-none-elf package.  Does this look better?
> 
> Patrick

Ok, cleaned up a little bit again.  Looking a bit better now.

arm-none-eabi/binutils and arm-none-eabi/gcc gain a flavor: aarch64.
This flavor changes the CONFIG variable which then defines the target
binutils/gcc are configured for.  CONFIG is also used in the COMMENT,
so the comment shows the correct target in pkg_info.  The packages
created by that flavor will be aarch64-none-elf-gcc-linaro and
aarch64-none-elf-binutils.  ARM will stay arm-none-eabi-*.

If we also add a FLAVOR arm it looks like pkg_add cannot cope with a
port gaining a flavor without really changing its name.  Thus I have
not added an arm FLAVOR.  Considering the correct PFRAGs are included
depending on the enabled FLAVORS, we need to work around that.  To be
able to include the correct PFRAG, I set the -Darm= and -Daarch64
depending on the flavor.

FULLPKGNAME seems to be PKGNAME-FLAVOR, which would looks like
aarch64-none-elf-gcc-linaro-VERSION-aarch64.  I overwrite FULLPKGNAME
so that it stays aarch64-none-elf-gcc-linaro-VERSION.

Any comments?

Patrick

diff --git a/devel/arm-none-eabi/Makefile b/devel/arm-none-eabi/Makefile
index 773d78e..71e8b7a 100644
--- a/devel/arm-none-eabi/Makefile
+++ b/devel/arm-none-eabi/Makefile
@@ -2,7 +2,9 @@
 
 SUBDIR =
 SUBDIR += binutils
+SUBDIR += binutils,aarch64
 SUBDIR += gcc-linaro
+SUBDIR += gcc-linaro,aarch64
 SUBDIR += gdb
 SUBDIR += newlib
 
diff --git a/devel/arm-none-eabi/Makefile.inc b/devel/arm-none-eabi/Makefile.inc
index 6abb8bd..c20ac6d 100644
--- a/devel/arm-none-eabi/Makefile.inc
+++ b/devel/arm-none-eabi/Makefile.inc
@@ -1,7 +1,13 @@
 # $OpenBSD: Makefile.inc,v 1.1.1.1 2015/05/28 23:28:25 bmercer Exp $
 
-CONFIG=arm-none-eabi
+FLAVOR?=
+.if "${FLAVOR}" == "aarch64"
+CONFIG=aarch64-none-elf
+.endif
+
+CONFIG?=   arm-none-eabi
 PKGNAME?=  ${CONFIG}-${DISTNAME}
+FULLPKGNAME?=  ${PKGNAME}
 CATEGORIES+=   devel
 
 # GPLv3
@@ -10,7 +16,7 @@ CATEGORIES+=  devel
 PERMIT_PACKAGE_CDROM=   Yes
 
 CONFIGURE_STYLE=gnu
-CONFIGURE_ARGS+=--target=arm-none-eabi\
+CONFIGURE_ARGS+=--target=${CONFIG}  \
--disable-shared\
--disable-nls   \
--disable-werror
diff --git a/devel/arm-none-eabi/binutils/Makefile 
b/devel/arm-none-eabi/binutils/Makefile
index 4c1255f..92fc033 100644
--- a/devel/arm-none-eabi/binutils/Makefile
+++ b/devel/arm-none-eabi/binutils/Makefile
@@ -1,11 +1,21 @@
 # $OpenBSD: Makefile,v 1.1.1.1 2015/05/28 23:28:25 bmercer Exp $
 
-COMMENT=   binutils for arm-none-eabi cross-development
+COMMENT=   binutils for ${CONFIG} cross-development
 
 V= 2.25
-#REVISION= 0
+REVISION=  0
 DISTNAME=  binutils-${V}
 
+FLAVORS=   aarch64
+
+.if "${FLAVOR}" == "aarch64"
+PKG_ARGS+= -Daarch64=1
+PKG_ARGS+= -Darm=0
+.else
+PKG_ARGS+= -Daarch64=0
+PKG_ARGS+= -Darm=1
+.endif
+
 HOMEPAGE=  https://www.gnu.org/software/binutils/
 
 WANTLIB=   c z
@@ -19,4 +29,6 @@ CONFIGURE_ARGS+=--enable-commonbfdlib=no \
--enable-interwork   \
--enable-multilib
 
+SUBST_VARS +=  CONFIG
+
 .include 
diff --git a/devel/arm-none-eabi/binutils/pkg/DESCR 
b/devel/arm-none-eabi/binutils/pkg/DESCR
index 03d6502..f118507 100644
--- a/devel/arm-none-eabi/binutils/pkg/DESCR
+++ b/devel/arm-none-eabi/binutils/pkg/DESCR
@@ -1,4 +1,5 @@
-GNU Binutils collection, configured for the arm-none-eabi target.
+GNU Binutils collection, configured for the arm-none-eabi target, or
+using the aarch64 flavor configured for the aarch64-none-elf target.
   * ld - the GNU linker.
   * as - the GNU assembler.
 
diff --git a/devel/arm-none-eabi/binutils/pkg/PFRAG.aarch64 
b/devel/arm-none-eabi/binutils/pkg/PFRAG.aarch64
new file mode 100644
index 000..78e03e5
--- /dev/null
+++ b/devel/arm-none-e

Re: add OpenBSD defs to llvm aarch64 target

[Patrick Wildt]

On Tue, Dec 20, 2016 at 03:11:09AM +1100, Jonathan Gray wrote:
> Same change patrick made to llvm in base.
> 
> With this aarch64-unknown-openbsd6.0 defines now include
> 
> #define __ELF__ 1
> #define __OpenBSD__ 1
> #define __unix 1
> #define __unix__ 1
> #define unix 1
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/llvm/Makefile,v
> retrieving revision 1.125
> diff -u -p -r1.125 Makefile
> --- Makefile  2 Nov 2016 07:46:33 -   1.125
> +++ Makefile  19 Dec 2016 10:39:28 -
> @@ -11,7 +11,7 @@ COMMENT =   modular, fast C/C++/ObjC compi
>  LLVM_V = 3.9.0
>  DISTNAME =   llvm-${LLVM_V}.src
>  PKGNAME =llvm-${LLVM_V}
> -REVISION =   2
> +REVISION =   3
>  CATEGORIES = devel
>  DISTFILES =  llvm-${LLVM_V}.src${EXTRACT_SUFX} \
>   cfe-${LLVM_V}.src${EXTRACT_SUFX} \
> Index: patches/patch-tools_clang_lib_Basic_Targets_cpp
> ===
> RCS file: 
> /cvs/ports/devel/llvm/patches/patch-tools_clang_lib_Basic_Targets_cpp,v
> retrieving revision 1.17
> diff -u -p -r1.17 patch-tools_clang_lib_Basic_Targets_cpp
> --- patches/patch-tools_clang_lib_Basic_Targets_cpp   7 Oct 2016 08:55:30 
> -   1.17
> +++ patches/patch-tools_clang_lib_Basic_Targets_cpp   19 Dec 2016 10:50:39 
> -
> @@ -3,9 +3,10 @@ $OpenBSD: patch-tools_clang_lib_Basic_Ta
>  - Enable __float128 support on X86
>  - [OpenBSD] Add type sign information for OpenBSD
>  - Set ABI for ARM
> +- [OpenBSD] set OpenBSD defines for aarch64
>  
>  tools/clang/lib/Basic/Targets.cpp.orig   Mon Jul 25 12:21:28 2016
> -+++ tools/clang/lib/Basic/Targets.cppSat Sep 24 12:02:09 2016
> +--- tools/clang/lib/Basic/Targets.cpp.orig   Tue Jul 26 02:21:28 2016
>  tools/clang/lib/Basic/Targets.cppMon Dec 19 21:48:14 2016
>  @@ -531,6 +531,8 @@ class OpenBSDTargetInfo : public OSTargetInfo 
>   Builder.defineMacro("__ELF__");
>   if (Opts.POSIXThreads)
> @@ -64,3 +65,12 @@ $OpenBSD: patch-tools_clang_lib_Basic_Ta
>   else
> setABI("aapcs");
>   break;
> +@@ -8148,6 +8159,8 @@ static TargetInfo *AllocateTarget(const llvm::Triple &
> +   return new LinuxTargetInfo(Triple, Opts);
> + case llvm::Triple::NetBSD:
> +   return new NetBSDTargetInfo(Triple, Opts);
> ++case llvm::Triple::OpenBSD:
> ++  return new OpenBSDTargetInfo(Triple, Opts);
> + default:
> +   return new AArch64leTargetInfo(Triple, Opts);
> + }
> 

looks good to me

Re: build combined spl/uboot/dtb/atf images for Allwinner A64/H5

[Patrick Wildt]

On Sat, Aug 19, 2017 at 08:23:40PM +1000, Jonathan Gray wrote:
> With the not yet committed atf-allwinner port this builds complete
> images for Allwinner aarch64 targets.
> 
> Compile tested only, I have no Allwinner hardware.
> 
> Details are described in
> http://git.denx.de/?p=u-boot.git;a=blob_plain;f=board/sunxi/README.sunxi64;hb=HEAD
> 
> sunxi-spl.bin/u-boot.itb made available for boards with spi flash.
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/sysutils/u-boot/Makefile,v
> retrieving revision 1.23
> diff -u -p -r1.23 Makefile
> --- Makefile  19 Aug 2017 04:40:40 -  1.23
> +++ Makefile  19 Aug 2017 10:13:06 -
> @@ -7,6 +7,7 @@ FLAVOR?=  arm
>  
>  COMMENT= U-Boot firmware
>  VERSION= 2017.09-rc2
> +REVISION=0
>  DISTNAME=u-boot-${VERSION}
>  PKGNAME= u-boot-${FLAVOR}-${VERSION:S/-//}
>  FULLPKGNAME= ${PKGNAME}
> @@ -35,8 +36,10 @@ MAKE_ENV=  KBUILD_VERBOSE=1 \
>   PYTHON="${MODPY_BIN}"
>  
>  .if "${FLAVOR}" == "aarch64"
> -BUILD_DEPENDS+=  devel/arm-none-eabi/gcc-linaro,aarch64
> -MAKE_ENV+=   CROSS_COMPILE="aarch64-none-elf-"
> +BUILD_DEPENDS+=  devel/arm-none-eabi/gcc-linaro,aarch64 \
> + sysutils/atf-allwinner
> +MAKE_ENV+=   CROSS_COMPILE="aarch64-none-elf-" \
> + BL31="${LOCALBASE}/share/atf-allwinner/bl31.bin"

Cool stuff!  But I think this BL31 MAKE_ENV addition needs to be applied
only for the allwinner boards, because the rockchip will definitely need
a different ATF binary.

>  .elif "${FLAVOR}" == "arm"
>  BUILD_DEPENDS+=  devel/arm-none-eabi/gcc-linaro
>  MAKE_ENV+=   CROSS_COMPILE="arm-none-eabi-"
> @@ -120,7 +123,9 @@ FILES=\
>   u-boot-sunxi-with-spl.bin \
>   u-boot.imx \
>   u-boot-spl.kwb \
> - u-boot-with-spl.bin
> + u-boot-with-spl.bin \
> + u-boot.itb \
> + spl/sunxi-spl.bin
>  
>  pre-build:
>   ${SUBST_CMD} ${WRKBUILD}/tools/Makefile
> @@ -144,6 +149,11 @@ do-build:
>   u-boot-with-spl.bin && \
>   cat u-boot-dtb.bin >> u-boot-with-spl.bin
>  .endif
> + if [[ -f ${WRKSRC}/build/${BOARD}/spl/sunxi-spl.bin && \
> +   -f ${WRKSRC}/build/${BOARD}/u-boot.itb ]]; then \
> + cd ${WRKSRC}/build/${BOARD} && \
> + cat spl/sunxi-spl.bin u-boot.itb > 
> u-boot-sunxi-with-spl.bin ; \
> + fi
>  .endfor
>  
>  do-install:
> Index: pkg/PFRAG.aarch64
> ===
> RCS file: /cvs/ports/sysutils/u-boot/pkg/PFRAG.aarch64,v
> retrieving revision 1.3
> diff -u -p -r1.3 PFRAG.aarch64
> --- pkg/PFRAG.aarch64 30 Jul 2017 05:53:03 -  1.3
> +++ pkg/PFRAG.aarch64 19 Aug 2017 10:13:06 -
> @@ -1,29 +1,47 @@
>  @comment $OpenBSD: PFRAG.aarch64,v 1.3 2017/07/30 05:53:03 jsg Exp $
>  share/u-boot/
>  share/u-boot/bananapi_m64/
> +share/u-boot/bananapi_m64/sunxi-spl.bin
>  share/u-boot/bananapi_m64/u-boot
> +share/u-boot/bananapi_m64/u-boot-sunxi-with-spl.bin
>  share/u-boot/bananapi_m64/u-boot.bin
>  share/u-boot/bananapi_m64/u-boot.img
> +share/u-boot/bananapi_m64/u-boot.itb
>  share/u-boot/nanopi_neo2/
> +share/u-boot/nanopi_neo2/sunxi-spl.bin
>  share/u-boot/nanopi_neo2/u-boot
> +share/u-boot/nanopi_neo2/u-boot-sunxi-with-spl.bin
>  share/u-boot/nanopi_neo2/u-boot.bin
>  share/u-boot/nanopi_neo2/u-boot.img
> +share/u-boot/nanopi_neo2/u-boot.itb
>  share/u-boot/orangepi_pc2/
> +share/u-boot/orangepi_pc2/sunxi-spl.bin
>  share/u-boot/orangepi_pc2/u-boot
> +share/u-boot/orangepi_pc2/u-boot-sunxi-with-spl.bin
>  share/u-boot/orangepi_pc2/u-boot.bin
>  share/u-boot/orangepi_pc2/u-boot.img
> +share/u-boot/orangepi_pc2/u-boot.itb
>  share/u-boot/orangepi_prime/
> +share/u-boot/orangepi_prime/sunxi-spl.bin
>  share/u-boot/orangepi_prime/u-boot
> +share/u-boot/orangepi_prime/u-boot-sunxi-with-spl.bin
>  share/u-boot/orangepi_prime/u-boot.bin
>  share/u-boot/orangepi_prime/u-boot.img
> +share/u-boot/orangepi_prime/u-boot.itb
>  share/u-boot/orangepi_win/
> +share/u-boot/orangepi_win/sunxi-spl.bin
>  share/u-boot/orangepi_win/u-boot
> +share/u-boot/orangepi_win/u-boot-sunxi-with-spl.bin
>  share/u-boot/orangepi_win/u-boot.bin
>  share/u-boot/orangepi_win/u-boot.img
> +share/u-boot/orangepi_win/u-boot.itb
>  share/u-boot/pine64_plus/
> +share/u-boot/pine64_plus/sunxi-spl.bin
>  share/u-boot/pine64_plus/u-boot
> +share/u-boot/pine64_plus/u-boot-sunxi-with-spl.bin
>  share/u-boot/pine64_plus/u-boot.bin
>  share/u-boot/pine64_plus/u-boot.img
> +share/u-boot/pine64_plus/u-boot.itb
>  share/u-boot/rpi_3/
>  share/u-boot/rpi_3/u-boot
>  share/u-boot/rpi_3/u-boot.bin
> Index: pkg/PFRAG.arm
> ===
> RCS file: /cvs/ports/sysutils/u-boot/pkg/PFRAG.arm,v
> retrieving revision 1.7
> diff -u -p -r1.7 PFRAG.arm
> --- pkg/PFRAG.arm 1 Aug 2017 23:25:44 -   1.7
> +++ pkg/PFRAG.arm 19 Aug 2017 10:13:06 -
> @@ -2,101 +2,121 @@
>  @pkgpath 

Re: ARM Trusted Firmware for RK3399

[Patrick Wildt]

On Sat, Aug 19, 2017 at 05:46:18PM +0200, Mark Kettenis wrote:
> Here is a port for ARM Trusted Firmware 1.4 that builds firmware for
> the Rockchip RK3399.  I anticipate that this port will build firmware
> for other ARMv8 Rockchip SoCs as well; there is code for the RK3328
> and RK3368 in the tree as well.  So this installs the firmware as
> rk3399-bl31.elf instead of just bl31.elf.
> 
> There is support for other SoCs as well.  We currently don't support
> any of those though.  There is some qemu code as well that I haven't
> looked into.  So maybe this should be a general ATF port?  Since there
> already is a port named "atf", I would rename this one to
> "arm-trusted-firmware".
> 
> Note that the Allwinner ATF is built from different source code, so it
> can't easily be included in a general ATF port.
> 
> Thoughts?

I also felt that this should be a general port for multiple boards, like
we build u-boot.  So for now this will only build the rockchip boards,
but it's still using the "generic" upstream source code.

Patrick

u-boot: add marvell-based clearfog, espressobin and macchiatobin

[Patrick Wildt]

Hi,

I'd like to add the 32-bit Clearfog and the 64-bit EspressoBin and
Macchiatobin to our u-boot package.  While the Clearfog's u-boot-spl.kwb
can be flashed to an SD card right away (bs=512 seek=1), the u-boot
for the 64-bit boards needs to be part of a Marvell ATF build.  On the
Pine64 it's the other way around, as the ATF binaries are included in
the u-boot build.

ok?

Patrick

diff --git a/sysutils/u-boot/Makefile b/sysutils/u-boot/Makefile
index 9a79e1ac0d6..c6b9d0f6e5c 100644
--- a/sysutils/u-boot/Makefile
+++ b/sysutils/u-boot/Makefile
@@ -7,7 +7,7 @@ FLAVOR?=arm
 
 COMMENT=   U-Boot firmware
 VERSION=   2017.09-rc2
-REVISION=  0
+REVISION=  1
 DISTNAME=  u-boot-${VERSION}
 PKGNAME=   u-boot-${FLAVOR}-${VERSION:S/-//}
 FULLPKGNAME=   ${PKGNAME}
@@ -58,6 +58,8 @@ SUNXI64=\
pine64_plus \
sopine_baseboard
 BOARDS=\
+   mvebu_espressobin-88f3720 \
+   mvebu_mcbin-88f8040 \
rpi_3
 .elif "${FLAVOR}" == "arm"
 OMAP=\
@@ -110,6 +112,7 @@ BOARDS=\
${OMAP} \
${SUNXI} \
${IMX} \
+   clearfog \
rpi_2 \
rpi_3_32b \
tinker-rk3288 \
diff --git a/sysutils/u-boot/patches/patch-tools_kwbimage_c 
b/sysutils/u-boot/patches/patch-tools_kwbimage_c
new file mode 100644
index 000..53d66e78ce9
--- /dev/null
+++ b/sysutils/u-boot/patches/patch-tools_kwbimage_c
@@ -0,0 +1,16 @@
+$OpenBSD$
+
+Index: tools/kwbimage.c
+--- tools/kwbimage.c.orig
 tools/kwbimage.c
+@@ -17,6 +17,10 @@
+ #include 
+ #include "kwbimage.h"
+ 
++#ifndef EPROTO
++#define EPROTO EIO
++#endif
++
+ #ifdef CONFIG_KWB_SECURE
+ #include 
+ #include 
diff --git a/sysutils/u-boot/pkg/PFRAG.aarch64 
b/sysutils/u-boot/pkg/PFRAG.aarch64
index 23eb8c58f4f..d1cfe4148e2 100644
--- a/sysutils/u-boot/pkg/PFRAG.aarch64
+++ b/sysutils/u-boot/pkg/PFRAG.aarch64
@@ -8,6 +8,12 @@ share/u-boot/bananapi_m64/u-boot.bin
 share/u-boot/bananapi_m64/u-boot.img
 share/u-boot/bananapi_m64/u-boot.itb
 share/u-boot/nanopi_neo2/
+share/u-boot/mvebu_espressobin-88f3720/
+share/u-boot/mvebu_espressobin-88f3720/u-boot
+share/u-boot/mvebu_espressobin-88f3720/u-boot.bin
+share/u-boot/mvebu_mcbin-88f8040/
+share/u-boot/mvebu_mcbin-88f8040/u-boot
+share/u-boot/mvebu_mcbin-88f8040/u-boot.bin
 share/u-boot/nanopi_neo2/sunxi-spl.bin
 share/u-boot/nanopi_neo2/u-boot
 share/u-boot/nanopi_neo2/u-boot-sunxi-with-spl.bin
diff --git a/sysutils/u-boot/pkg/PFRAG.arm b/sysutils/u-boot/pkg/PFRAG.arm
index 77d1bd63dd2..8425d7ca6c8 100644
--- a/sysutils/u-boot/pkg/PFRAG.arm
+++ b/sysutils/u-boot/pkg/PFRAG.arm
@@ -131,6 +131,11 @@ share/u-boot/am57xx_evm/MLO
 share/u-boot/am57xx_evm/u-boot
 share/u-boot/am57xx_evm/u-boot.bin
 share/u-boot/am57xx_evm/u-boot.img
+share/u-boot/clearfog/
+share/u-boot/clearfog/u-boot
+share/u-boot/clearfog/u-boot-spl.kwb
+share/u-boot/clearfog/u-boot.bin
+share/u-boot/clearfog/u-boot.img
 share/u-boot/cm_fx6/
 share/u-boot/cm_fx6/SPL
 share/u-boot/cm_fx6/u-boot

Re: u-boot: add marvell-based clearfog, espressobin and macchiatobin

[Patrick Wildt]

On Thu, Aug 24, 2017 at 09:15:20AM +0200, Patrick Wildt wrote:
> Hi,
> 
> I'd like to add the 32-bit Clearfog and the 64-bit EspressoBin and
> Macchiatobin to our u-boot package.  While the Clearfog's u-boot-spl.kwb
> can be flashed to an SD card right away (bs=512 seek=1), the u-boot
> for the 64-bit boards needs to be part of a Marvell ATF build.  On the
> Pine64 it's the other way around, as the ATF binaries are included in
> the u-boot build.
> 
> ok?
> 
> Patrick

Immediately spotted _after_ sending the mail, of course, a line ordering
issue in PFRAG.aarch64.  Update version below.

diff --git a/sysutils/u-boot/Makefile b/sysutils/u-boot/Makefile
index 9a79e1ac0d6..c6b9d0f6e5c 100644
--- a/sysutils/u-boot/Makefile
+++ b/sysutils/u-boot/Makefile
@@ -7,7 +7,7 @@ FLAVOR?=arm
 
 COMMENT=   U-Boot firmware
 VERSION=   2017.09-rc2
-REVISION=  0
+REVISION=  1
 DISTNAME=  u-boot-${VERSION}
 PKGNAME=   u-boot-${FLAVOR}-${VERSION:S/-//}
 FULLPKGNAME=   ${PKGNAME}
@@ -58,6 +58,8 @@ SUNXI64=\
pine64_plus \
sopine_baseboard
 BOARDS=\
+   mvebu_espressobin-88f3720 \
+   mvebu_mcbin-88f8040 \
rpi_3
 .elif "${FLAVOR}" == "arm"
 OMAP=\
@@ -110,6 +112,7 @@ BOARDS=\
${OMAP} \
${SUNXI} \
${IMX} \
+   clearfog \
rpi_2 \
rpi_3_32b \
tinker-rk3288 \
diff --git a/sysutils/u-boot/patches/patch-tools_kwbimage_c 
b/sysutils/u-boot/patches/patch-tools_kwbimage_c
new file mode 100644
index 000..53d66e78ce9
--- /dev/null
+++ b/sysutils/u-boot/patches/patch-tools_kwbimage_c
@@ -0,0 +1,16 @@
+$OpenBSD$
+
+Index: tools/kwbimage.c
+--- tools/kwbimage.c.orig
 tools/kwbimage.c
+@@ -17,6 +17,10 @@
+ #include 
+ #include "kwbimage.h"
+ 
++#ifndef EPROTO
++#define EPROTO EIO
++#endif
++
+ #ifdef CONFIG_KWB_SECURE
+ #include 
+ #include 
diff --git a/sysutils/u-boot/pkg/PFRAG.aarch64 
b/sysutils/u-boot/pkg/PFRAG.aarch64
index 23eb8c58f4f..4221b6686b0 100644
--- a/sysutils/u-boot/pkg/PFRAG.aarch64
+++ b/sysutils/u-boot/pkg/PFRAG.aarch64
@@ -7,6 +7,12 @@ share/u-boot/bananapi_m64/u-boot-sunxi-with-spl.bin
 share/u-boot/bananapi_m64/u-boot.bin
 share/u-boot/bananapi_m64/u-boot.img
 share/u-boot/bananapi_m64/u-boot.itb
+share/u-boot/mvebu_espressobin-88f3720/
+share/u-boot/mvebu_espressobin-88f3720/u-boot
+share/u-boot/mvebu_espressobin-88f3720/u-boot.bin
+share/u-boot/mvebu_mcbin-88f8040/
+share/u-boot/mvebu_mcbin-88f8040/u-boot
+share/u-boot/mvebu_mcbin-88f8040/u-boot.bin
 share/u-boot/nanopi_neo2/
 share/u-boot/nanopi_neo2/sunxi-spl.bin
 share/u-boot/nanopi_neo2/u-boot
diff --git a/sysutils/u-boot/pkg/PFRAG.arm b/sysutils/u-boot/pkg/PFRAG.arm
index 77d1bd63dd2..8425d7ca6c8 100644
--- a/sysutils/u-boot/pkg/PFRAG.arm
+++ b/sysutils/u-boot/pkg/PFRAG.arm
@@ -131,6 +131,11 @@ share/u-boot/am57xx_evm/MLO
 share/u-boot/am57xx_evm/u-boot
 share/u-boot/am57xx_evm/u-boot.bin
 share/u-boot/am57xx_evm/u-boot.img
+share/u-boot/clearfog/
+share/u-boot/clearfog/u-boot
+share/u-boot/clearfog/u-boot-spl.kwb
+share/u-boot/clearfog/u-boot.bin
+share/u-boot/clearfog/u-boot.img
 share/u-boot/cm_fx6/
 share/u-boot/cm_fx6/SPL
 share/u-boot/cm_fx6/u-boot

Re: u-boot: add marvell-based clearfog, espressobin and macchiatobin

[Patrick Wildt]

On Thu, Aug 24, 2017 at 09:19:41AM +0200, Patrick Wildt wrote:
> On Thu, Aug 24, 2017 at 09:15:20AM +0200, Patrick Wildt wrote:
> > Hi,
> > 
> > I'd like to add the 32-bit Clearfog and the 64-bit EspressoBin and
> > Macchiatobin to our u-boot package.  While the Clearfog's u-boot-spl.kwb
> > can be flashed to an SD card right away (bs=512 seek=1), the u-boot
> > for the 64-bit boards needs to be part of a Marvell ATF build.  On the
> > Pine64 it's the other way around, as the ATF binaries are included in
> > the u-boot build.
> > 
> > ok?
> > 
> > Patrick
> 
> Immediately spotted _after_ sending the mail, of course, a line ordering
> issue in PFRAG.aarch64.  Update version below.

jsg@ reminded me that we should build the Turris Omnia as well, which is
basically like a Clearfog, but not the same.

ok?

diff --git a/sysutils/u-boot/Makefile b/sysutils/u-boot/Makefile
index 9a79e1ac0d6..ef8cc77c15f 100644
--- a/sysutils/u-boot/Makefile
+++ b/sysutils/u-boot/Makefile
@@ -7,7 +7,7 @@ FLAVOR?=arm
 
 COMMENT=   U-Boot firmware
 VERSION=   2017.09-rc2
-REVISION=  0
+REVISION=  1
 DISTNAME=  u-boot-${VERSION}
 PKGNAME=   u-boot-${FLAVOR}-${VERSION:S/-//}
 FULLPKGNAME=   ${PKGNAME}
@@ -58,6 +58,8 @@ SUNXI64=\
pine64_plus \
sopine_baseboard
 BOARDS=\
+   mvebu_espressobin-88f3720 \
+   mvebu_mcbin-88f8040 \
rpi_3
 .elif "${FLAVOR}" == "arm"
 OMAP=\
@@ -110,9 +112,11 @@ BOARDS=\
${OMAP} \
${SUNXI} \
${IMX} \
+   clearfog \
rpi_2 \
rpi_3_32b \
tinker-rk3288 \
+   turris_omnia \
vexpress_ca15_tc2 \
vexpress_ca9x4
 .endif
diff --git a/sysutils/u-boot/patches/patch-tools_kwbimage_c 
b/sysutils/u-boot/patches/patch-tools_kwbimage_c
new file mode 100644
index 000..53d66e78ce9
--- /dev/null
+++ b/sysutils/u-boot/patches/patch-tools_kwbimage_c
@@ -0,0 +1,16 @@
+$OpenBSD$
+
+Index: tools/kwbimage.c
+--- tools/kwbimage.c.orig
 tools/kwbimage.c
+@@ -17,6 +17,10 @@
+ #include 
+ #include "kwbimage.h"
+ 
++#ifndef EPROTO
++#define EPROTO EIO
++#endif
++
+ #ifdef CONFIG_KWB_SECURE
+ #include 
+ #include 
diff --git a/sysutils/u-boot/pkg/PFRAG.aarch64 
b/sysutils/u-boot/pkg/PFRAG.aarch64
index 23eb8c58f4f..4221b6686b0 100644
--- a/sysutils/u-boot/pkg/PFRAG.aarch64
+++ b/sysutils/u-boot/pkg/PFRAG.aarch64
@@ -7,6 +7,12 @@ share/u-boot/bananapi_m64/u-boot-sunxi-with-spl.bin
 share/u-boot/bananapi_m64/u-boot.bin
 share/u-boot/bananapi_m64/u-boot.img
 share/u-boot/bananapi_m64/u-boot.itb
+share/u-boot/mvebu_espressobin-88f3720/
+share/u-boot/mvebu_espressobin-88f3720/u-boot
+share/u-boot/mvebu_espressobin-88f3720/u-boot.bin
+share/u-boot/mvebu_mcbin-88f8040/
+share/u-boot/mvebu_mcbin-88f8040/u-boot
+share/u-boot/mvebu_mcbin-88f8040/u-boot.bin
 share/u-boot/nanopi_neo2/
 share/u-boot/nanopi_neo2/sunxi-spl.bin
 share/u-boot/nanopi_neo2/u-boot
diff --git a/sysutils/u-boot/pkg/PFRAG.arm b/sysutils/u-boot/pkg/PFRAG.arm
index 77d1bd63dd2..b47ff15172c 100644
--- a/sysutils/u-boot/pkg/PFRAG.arm
+++ b/sysutils/u-boot/pkg/PFRAG.arm
@@ -131,6 +131,11 @@ share/u-boot/am57xx_evm/MLO
 share/u-boot/am57xx_evm/u-boot
 share/u-boot/am57xx_evm/u-boot.bin
 share/u-boot/am57xx_evm/u-boot.img
+share/u-boot/clearfog/
+share/u-boot/clearfog/u-boot
+share/u-boot/clearfog/u-boot-spl.kwb
+share/u-boot/clearfog/u-boot.bin
+share/u-boot/clearfog/u-boot.img
 share/u-boot/cm_fx6/
 share/u-boot/cm_fx6/SPL
 share/u-boot/cm_fx6/u-boot
@@ -233,6 +238,11 @@ share/u-boot/tinker-rk3288/u-boot
 share/u-boot/tinker-rk3288/u-boot-with-spl.bin
 share/u-boot/tinker-rk3288/u-boot.bin
 share/u-boot/tinker-rk3288/u-boot.img
+share/u-boot/turris_omnia/
+share/u-boot/turris_omnia/u-boot
+share/u-boot/turris_omnia/u-boot-spl.kwb
+share/u-boot/turris_omnia/u-boot.bin
+share/u-boot/turris_omnia/u-boot.img
 share/u-boot/udoo/
 share/u-boot/udoo/SPL
 share/u-boot/udoo/u-boot

Re: Porting to ARMv8 (board, qemu, etc.)

[Patrick Wildt]

On Mon, Jan 29, 2018 at 12:07:50PM +0100, Artur Pedziwilk wrote:
> 
> 
> > On 11 Jan 2018, at 15:40, Karel Gardas  wrote:
> > 
> > - cloud/kvm solution. There are several cloud provides already 
> > selling/supporting Cavium ThunderX
> >  and for quite cheap money. Anyone has a luck with this solution? I guess 
> > OpenBSD would need to run on
> >  qemu-system-aarch64 first to support all those kvm/virtio devices needed 
> > and then grabed to cloud, but still
> >  any chance?
> 
> 
> Yesterday, I have managed to run the current of arm64 on scaleway.com...
> 
> ... by resizing the miniroot62.fs, partitioning it and installing it very 
> analogically to 
> Antoine's "create-ami.sh" - https://github.com/ajacoutot/aws-openbsd
> 
> Later I just simply "dd if=myimage.fs of=/dev/vdb bs=1m"
> from Linux instance with 2 disks attached and reboot the disk with new fresh 
> instance.
> It is basically working but many "Segmentation fault (core dumped)".
> I intend to keep that instance running and check it with incoming snapshots.
> 
> OpenBSD 6.2-current (GENERIC) #160: Wed Jan 24 18:26:59 MST 2018
> dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC
> real mem  = 2090483712 (1993MB)
> avail mem = 2002345984 (1909MB)
> mainbus0 at root: unknown model
> cpu0 at mainbus0: Cavium ThunderX T88 r1p1
> efi0 at mainbus0: UEFI 2.6
> efi0: EDK II rev 0x1
> psci0 at mainbus0: PSCI 0.2
> simplebus0 at mainbus0: "platform"
> virtio0 at mainbus0: Virtio Unknown (0) Device
> virtio1 at mainbus0: Virtio Unknown (0) Device
> virtio2 at mainbus0: Virtio Unknown (0) Device
> virtio3 at mainbus0: Virtio Unknown (0) Device
> virtio4 at mainbus0: Virtio Unknown (0) Device
> virtio5 at mainbus0: Virtio Unknown (0) Device
> virtio6 at mainbus0: Virtio Unknown (0) Device
> virtio7 at mainbus0: Virtio Unknown (0) Device
> virtio8 at mainbus0: Virtio Unknown (0) Device
> virtio9 at mainbus0: Virtio Unknown (0) Device
> virtio10 at mainbus0: Virtio Unknown (0) Device
> virtio11 at mainbus0: Virtio Unknown (0) Device
> virtio12 at mainbus0: Virtio Unknown (0) Device
> virtio13 at mainbus0: Virtio Unknown (0) Device
> virtio14 at mainbus0: Virtio Unknown (0) Device
> virtio15 at mainbus0: Virtio Unknown (0) Device
> virtio16 at mainbus0: Virtio Unknown (0) Device
> virtio17 at mainbus0: Virtio Unknown (0) Device
> virtio18 at mainbus0: Virtio Unknown (0) Device
> virtio19 at mainbus0: Virtio Unknown (0) Device
> virtio20 at mainbus0: Virtio Unknown (0) Device
> virtio21 at mainbus0: Virtio Unknown (0) Device
> virtio22 at mainbus0: Virtio Unknown (0) Device
> virtio23 at mainbus0: Virtio Unknown (0) Device
> virtio24 at mainbus0: Virtio Unknown (0) Device
> virtio25 at mainbus0: Virtio Unknown (0) Device
> virtio26 at mainbus0: Virtio Unknown (0) Device
> virtio27 at mainbus0: Virtio Unknown (0) Device
> virtio28 at mainbus0: Virtio Unknown (0) Device
> virtio29 at mainbus0: Virtio Unknown (0) Device
> virtio30 at mainbus0: Virtio Unknown (0) Device
> virtio31 at mainbus0: Virtio Unknown (0) Device
> pciecam0 at mainbus0
> pci0 at pciecam0
> "Red Hat Host" rev 0x00 at pci0 dev 0 function 0 not configured
> virtio32 at pci0 dev 1 function 0 "Qumranet Virtio Network" rev 0x00
> vio0 at virtio32: address de:2b:88:06:60:4f
> virtio32: irq
> virtio33 at pci0 dev 2 function 0 "Qumranet Virtio Storage" rev 0x00
> vioblk0 at virtio33
> scsibus0 at vioblk0: 2 targets
> sd0 at scsibus0 targ 0 lun 0:  SCSI3 0/direct fixed
> sd0: 47683MB, 512 bytes/sector, 97656250 sectors
> virtio33: irq
> pluart0 at mainbus0: console
> agintc0 at mainbus0 nirq 288, nredist 4
> agtimer0 at mainbus0: tick rate 10 KHz
> vscsi0 at root
> scsibus1 at vscsi0: 256 targets
> softraid0 at root
> scsibus2 at softraid0: 256 targets
> bootfile: sd0a:/bsd
> boot device: sd0
> root on sd0a (11af0f37e1af6b1a.a) swap on sd0b dump on sd0b
> 

First of all, I'm positively surprised.  When I worked on Scaleway's
bare metal ARMv7 instances, the system was supposed to boot with an
initramdisk which then mounts a network block device and pivot roots
into this mountpoint.  This would right now not be doable with Open-
BSD.  In this case these are virtual machines running on their Caviums,
which is "nicer" for us because it abstracts the NBD away and we only
see virtual disks.  On the other hand, we run on a virtual machine and
not on physical hardware.

There might be some quirks necessary for the ThunderX CPUs.  At least
afaik there are some quirks in the Linux kernel.

I think those random segfaults might even be visible with qemu running
on an x86 machine.  I'm not surprised.

Re: Porting to ARMv8 (board, qemu, etc.)

[Patrick Wildt]

On Mon, Jan 29, 2018 at 02:14:53PM +0100, Patrick Wildt wrote:
> On Mon, Jan 29, 2018 at 12:07:50PM +0100, Artur Pedziwilk wrote:
> > 
> > 
> > > On 11 Jan 2018, at 15:40, Karel Gardas <gard...@gmail.com> wrote:
> > > 
> > > - cloud/kvm solution. There are several cloud provides already 
> > > selling/supporting Cavium ThunderX
> > >  and for quite cheap money. Anyone has a luck with this solution? I guess 
> > > OpenBSD would need to run on
> > >  qemu-system-aarch64 first to support all those kvm/virtio devices needed 
> > > and then grabed to cloud, but still
> > >  any chance?
> > 
> > 
> > Yesterday, I have managed to run the current of arm64 on scaleway.com...
> > 
> > ... by resizing the miniroot62.fs, partitioning it and installing it very 
> > analogically to 
> > Antoine's "create-ami.sh" - https://github.com/ajacoutot/aws-openbsd
> > 
> > Later I just simply "dd if=myimage.fs of=/dev/vdb bs=1m"
> > from Linux instance with 2 disks attached and reboot the disk with new 
> > fresh instance.
> > It is basically working but many "Segmentation fault (core dumped)".
> > I intend to keep that instance running and check it with incoming snapshots.
> > 
> > OpenBSD 6.2-current (GENERIC) #160: Wed Jan 24 18:26:59 MST 2018
> > dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC
> > real mem  = 2090483712 (1993MB)
> > avail mem = 2002345984 (1909MB)
> > mainbus0 at root: unknown model
> > cpu0 at mainbus0: Cavium ThunderX T88 r1p1
> > efi0 at mainbus0: UEFI 2.6
> > efi0: EDK II rev 0x1
> > psci0 at mainbus0: PSCI 0.2
> > simplebus0 at mainbus0: "platform"
> > virtio0 at mainbus0: Virtio Unknown (0) Device
> > virtio1 at mainbus0: Virtio Unknown (0) Device
> > virtio2 at mainbus0: Virtio Unknown (0) Device
> > virtio3 at mainbus0: Virtio Unknown (0) Device
> > virtio4 at mainbus0: Virtio Unknown (0) Device
> > virtio5 at mainbus0: Virtio Unknown (0) Device
> > virtio6 at mainbus0: Virtio Unknown (0) Device
> > virtio7 at mainbus0: Virtio Unknown (0) Device
> > virtio8 at mainbus0: Virtio Unknown (0) Device
> > virtio9 at mainbus0: Virtio Unknown (0) Device
> > virtio10 at mainbus0: Virtio Unknown (0) Device
> > virtio11 at mainbus0: Virtio Unknown (0) Device
> > virtio12 at mainbus0: Virtio Unknown (0) Device
> > virtio13 at mainbus0: Virtio Unknown (0) Device
> > virtio14 at mainbus0: Virtio Unknown (0) Device
> > virtio15 at mainbus0: Virtio Unknown (0) Device
> > virtio16 at mainbus0: Virtio Unknown (0) Device
> > virtio17 at mainbus0: Virtio Unknown (0) Device
> > virtio18 at mainbus0: Virtio Unknown (0) Device
> > virtio19 at mainbus0: Virtio Unknown (0) Device
> > virtio20 at mainbus0: Virtio Unknown (0) Device
> > virtio21 at mainbus0: Virtio Unknown (0) Device
> > virtio22 at mainbus0: Virtio Unknown (0) Device
> > virtio23 at mainbus0: Virtio Unknown (0) Device
> > virtio24 at mainbus0: Virtio Unknown (0) Device
> > virtio25 at mainbus0: Virtio Unknown (0) Device
> > virtio26 at mainbus0: Virtio Unknown (0) Device
> > virtio27 at mainbus0: Virtio Unknown (0) Device
> > virtio28 at mainbus0: Virtio Unknown (0) Device
> > virtio29 at mainbus0: Virtio Unknown (0) Device
> > virtio30 at mainbus0: Virtio Unknown (0) Device
> > virtio31 at mainbus0: Virtio Unknown (0) Device
> > pciecam0 at mainbus0
> > pci0 at pciecam0
> > "Red Hat Host" rev 0x00 at pci0 dev 0 function 0 not configured
> > virtio32 at pci0 dev 1 function 0 "Qumranet Virtio Network" rev 0x00
> > vio0 at virtio32: address de:2b:88:06:60:4f
> > virtio32: irq
> > virtio33 at pci0 dev 2 function 0 "Qumranet Virtio Storage" rev 0x00
> > vioblk0 at virtio33
> > scsibus0 at vioblk0: 2 targets
> > sd0 at scsibus0 targ 0 lun 0: <VirtIO, Block Device, > SCSI3 0/direct fixed
> > sd0: 47683MB, 512 bytes/sector, 97656250 sectors
> > virtio33: irq
> > pluart0 at mainbus0: console
> > agintc0 at mainbus0 nirq 288, nredist 4
> > agtimer0 at mainbus0: tick rate 10 KHz
> > vscsi0 at root
> > scsibus1 at vscsi0: 256 targets
> > softraid0 at root
> > scsibus2 at softraid0: 256 targets
> > bootfile: sd0a:/bsd
> > boot device: sd0
> > root on sd0a (11af0f37e1af6b1a.a) swap on sd0b dump on sd0b
> > 
> 
> First of all, I'm positively surprised.  When I worked on Scaleway's
> bare metal ARMv7 instances, the system was supposed to boot with an
> initramdisk which then mounts a n

Re: WIP: LLVM 7.0.1

[Patrick Wildt]

On Wed, Jan 16, 2019 at 07:19:17PM -0500, Brad Smith wrote:
> Here is a work in progress diff to update the LLVM/Clang port to
> LLVM 7.0.1.
> 
> Code generation is broken at the moment on amd64. I don't know what
> the issue is. Clang crashes in the X86 backend. This only seems to
> affect amd64.
> 
> Any feedback and testing welcome.

Is the retpoline/retprotector stuff in there as well?  I'm doing the
base upgrade at the moment and I also had clang crashing there.  Thank-
fully mortimer@ found the bug and it's fixed in my current diff for
base.  Unfortunately lld is generating a weirdly linked kernel.

Re: ffmpeg on arm

[Patrick Wildt]

On Thu, Jul 25, 2019 at 06:40:35PM +, adr wrote:
> ffmpeg needs to be configured with --disable-fast-unaligned and
> --disable-neon, or it will fail (and any application using libav)
> with a bus error.

Not really surprised.  I figure it's because we require strict
alignment but the whole ecosystem didn't evolve with that in mind...

Re: Switch to LLVM 10 imminent

[Patrick Wildt]

Keep note that our base libc++ and libc++abi are still from version
8.0.1.  This means that it's very possible that version 10 is not
yet correctly patched to support OpenBSD.  Or maybe they added
something that is incompatible to us.

On Mon, Aug 03, 2020 at 08:58:44AM +0100, Julian Smith wrote:
> I'd like to try llvm-10 (latest git master), but when i try to build on
> OpenBSD-6.7 (amd64), but i get build failures such as:
> 
> llvm-project/libcxxabi/../libcxx/include/__config:1150:6: error: "No thread 
> API").
> 
> Is there a set of patches somewhere that i can use?
> 
> [ports/lang/clang/ doesn't seem to have anything relevant.]
> 
> Thanks,
> 
> - Jules
> 
> 
> On Sat, 1 Aug 2020 22:14:03 +0200
> Christian Weisgerber  wrote:
> 
> > I don't think there was any public announcement, but most will have
> > surmised it by now: The base compiler will soon switch from LLVM 8
> > to LLVM 10 on all CLANG_ARCHS.  This also concerns the linker on
> > LLD_ARCHS.
> > 
> > This will cause a certain amount of breakage in the ports tree.
> > We are working on it now.
> > 
> > I have uploaded the failure logs from early builds at
> > http://build-failures.rhaalovely.net/amd64-clang/
> > 
> > Note that the devel/pango failure prevented GTK and Qt and thus a
> > huge chunk of the tree from building.  More meaningful logs should
> > appear within 24 hours.
> > 
> > Principal sources of build failures:
> > * C++ incompatibilities, as always.
> > * Use of -Werror breaking on new warnings.
> > * Linking errors.
> > 
> > There are also silly problems such as configure scripts misrecognizing
> > LLVM 10 due to changes in the output of "cc -v" or "cc -dumpversion".
> > 
> > Anyway, I would like to encourage more people to join into the effort.
> > (And yes, I'm aware that there's no publically available snapshot
> > or patchset with LLVM 10...)
> > 
> 
> 
> 
> -- 
> http://op59.net
> 
> 

Re: update arm-trusted-firmware to 2.4

[Patrick Wildt]

Am Sun, Jan 10, 2021 at 09:56:02PM +1100 schrieb Jonathan Gray:
> On Fri, Jan 08, 2021 at 03:42:31PM -0500, Kurt Miller wrote:
> > On Fri, 2021-01-08 at 11:48 -0500, Kurt Miller wrote:
> > > On Fri, 2021-01-08 at 10:27 +1100, Jonathan Gray wrote:
> > > > 
> > > > On Thu, Jan 07, 2021 at 04:29:35PM -0500, Kurt Miller wrote:
> > > > > 
> > > > > 
> > > > > On Thu, 2020-12-31 at 19:24 +1100, Jonathan Gray wrote:
> > > > > > 
> > > > > > 
> > > > > > https://trustedfirmware-a.readthedocs.io/en/latest/change-log.html#version-2-4
> > > > > > 
> > > > > > Tests welcome as I don't have rk3328/rk3399/sun50i_a64 hardware.
> > > > > This update appears ok on rk3328 and rk3399, however my rockpro64
> > > > > will not boot with u-boot 2020.10:
> > > > > 
> > > > > Rock64 Gen3 w/ v2020.10 u-boot and atf 2.4 works
> > > > > Rockpro64 w/2020.10 u-boot and atf 2.4 and 2.3 fails
> > > > > Rockpro64 w/2020.07 u-boot and atf 2.4 and 2.3 works
> > > > > 
> > > > > With 2020.10 u-boot the rockpro64 freezes just after attempting to
> > > > > boot the kernel. Here's a diff of v2020.07 with atf 2.3 that works
> > > > > against v2020.10 with atf 2.3 that freezes:
> > > > > 
> > > > > rocky$ diff -u v2020.07.boot v2020-10.boot   
> > > > > --- v2020.07.boot Thu Jan  7 16:20:58 2021
> > > > > +++ v2020-10.boot Thu Jan  7 16:10:27 2021
> > > > > @@ -1,19 +1,18 @@
> > > > > -U-Boot TPL 2020.07 (Jul 07 2020 - 19:02:53)
> > > > > +U-Boot TPL 2020.10 (Jan 02 2021 - 11:16:03)
> > > > >  Channel 0: LPDDR4, 50MHz
> > > > >  BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
> > > > >  Channel 1: LPDDR4, 50MHz
> > > > >  BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
> > > > >  256B stride
> > > > > -256B stride
> > > > >  lpddr4_set_rate: change freq to 4 mhz 0, 1
> > > > >  lpddr4_set_rate: change freq to 8 mhz 1, 0
> > > > >  Trying to boot from BOOTROM
> > > > >  Returning to boot ROM...
> > > > >  
> > > > > -U-Boot SPL 2020.07 (Jul 07 2020 - 19:02:53 -0600)
> > > > > +U-Boot SPL 2020.10 (Jan 02 2021 - 11:16:03 -0700)
> > > > >  Trying to boot from MMC1
> > > > >  NOTICE:  BL31: v2.3():2.3
> > > > > -NOTICE:  BL31: Built : 18:41:43, Jul  7 2020
> > > > > +NOTICE:  BL31: Built : 10:45:12, Jan  2 2021
> > > > >  INFO:GICv3 with legacy support detected.
> > > > >  INFO:ARM GICv3 driver initialized in EL3
> > > > >  INFO:plat_rockchip_pmu_init(1624): pd status 3e
> > > > > @@ -24,7 +23,7 @@
> > > > >  INFO:SPSR = 0x3c9
> > > > >  
> > > > >  
> > > > > -U-Boot 2020.07 (Jul 07 2020 - 19:02:53 -0600)
> > > > > +U-Boot 2020.10 (Jan 02 2021 - 11:16:03 -0700)
> > > > >  
> > > > >  SoC: Rockchip rk3399
> > > > >  Reset cause: RST
> > > > > @@ -32,14 +31,29 @@
> > > > >  DRAM:  3.9 GiB
> > > > >  PMIC:  RK808 
> > > > >  MMC:   mmc@fe31: 2, mmc@fe32: 1, sdhci@fe33: 0
> > > > > -Loading Environment from SPI Flash... SF: Detected gd25q128 with 
> > > > > page size 256 Bytes, erase size 4 KiB, total 16
> > > > > MiB
> > > > > -*** Warning - bad CRC, using default environment
> > > > > +Loading Environment from SPIFlash... Invalid bus 0 (err=-19)
> > > > > +*** Warning - spi_flash_probe_bus_cs() failed, using default 
> > > > > environment
> > > > >  
> > > > >  In:serial
> > > > >  Out:   serial
> > > > >  Err:   serial
> > > > >  Model: Pine64 RockPro64 v2.1
> > > > >  Net:   eth0: ethernet@fe30
> > > > > +starting USB...
> > > > > +Bus usb@fe38: USB EHCI 1.00
> > > > > +Bus usb@fe3a: USB OHCI 1.0
> > > > > +Bus usb@fe3c: USB EHCI 1.00
> > > > > +Bus usb@fe3e: USB OHCI 1.0
> > > > > +Bus dwc3: usb maximum-speed not found
> > > > > +Register 2000140 NbrPorts 2
> > > > > +Starting the controller
> > > > > +USB XHCI 1.10
> > > > > +scanning bus usb@fe38 for devices... 1 USB Device(s) found
> > > > > +scanning bus usb@fe3a for devices... 1 USB Device(s) found
> > > > > +scanning bus usb@fe3c for devices... 1 USB Device(s) found
> > > > > +scanning bus usb@fe3e for devices... 1 USB Device(s) found
> > > > > +scanning bus dwc3 for devices... 1 USB Device(s) found
> > > > > +   scanning usb for storage devices... 0 Storage Device(s) found
> > > > >  Hit any key to stop autoboot:  0 
> > > > >  Card did not respond to voltage select!
> > > > >  switch to partitions #0, OK
> > > > > @@ -56,11 +70,14 @@
> > > > >  Scanning disk sd...@fe33.blk...
> > > > >  Disk sd...@fe33.blk not ready
> > > > >  Found 3 disks
> > > > > +No EFI system partition
> > > > >  BootOrder not defined
> > > > >  EFI boot manager: Cannot load any image
> > > > > -168728 bytes read in 14 ms (11.5 MiB/s)
> > > > > +168728 bytes read in 13 ms (12.4 MiB/s)
> > > > >  libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> > > > > +Booting /efi\boot\bootaa64.efi
> > > > >  disks: sd0*
> > > > >  >> OpenBSD/arm64 BOOTAA64 1.3
> > > > >  boot> 
> > > > > -booting sd0a:/bsd: 8657572+1775464+561576+826224 
> > > > > [629354+109+1059720+622048]=0xf87520
> > > > > +booting 

Re: update arm-trusted-firmware to 2.4

[Patrick Wildt]

On Tue, Jan 12, 2021 at 10:12:06AM -0500, Kurt Miller wrote:
> On Tue, 2021-01-12 at 15:09 +1100, Jonathan Gray wrote:
> > On Tue, Jan 12, 2021 at 07:58:36AM +1100, Jonathan Gray wrote:
> > > 
> > > On Mon, Jan 11, 2021 at 08:41:02PM +0100, Patrick Wildt wrote:
> > > > 
> > > > Am Sun, Jan 10, 2021 at 09:56:02PM +1100 schrieb Jonathan Gray:
> > > > > 
> > > > > On Fri, Jan 08, 2021 at 03:42:31PM -0500, Kurt Miller wrote:
> > > > > > 
> > > > > > On Fri, 2021-01-08 at 11:48 -0500, Kurt Miller wrote:
> > > > > > > 
> > > > > > > On Fri, 2021-01-08 at 10:27 +1100, Jonathan Gray wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On Thu, Jan 07, 2021 at 04:29:35PM -0500, Kurt Miller wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On Thu, 2020-12-31 at 19:24 +1100, Jonathan Gray wrote:
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > https://trustedfirmware-a.readthedocs.io/en/latest/change-log.html#version-2-4
> > > > > > > > > > 
> > > > > > > > > > Tests welcome as I don't have rk3328/rk3399/sun50i_a64 
> > > > > > > > > > hardware.
> > > > > > > > > This update appears ok on rk3328 and rk3399, however my 
> > > > > > > > > rockpro64
> > > > > > > > > will not boot with u-boot 2020.10:
> > > > > > > > > 
> > > > > > > > > Rock64 Gen3 w/ v2020.10 u-boot and atf 2.4 works
> > > > > > > > > Rockpro64 w/2020.10 u-boot and atf 2.4 and 2.3 fails
> > > > > > > > > Rockpro64 w/2020.07 u-boot and atf 2.4 and 2.3 works
> > > > > > > > > 
> > > > > > > > > With 2020.10 u-boot the rockpro64 freezes just after 
> > > > > > > > > attempting to
> > > > > > > > > boot the kernel. Here's a diff of v2020.07 with atf 2.3 that 
> > > > > > > > > works
> > > > > > > > > against v2020.10 with atf 2.3 that freezes:
> > > > > > > > > 
> > > > > > > > > rocky$ diff -u v2020.07.boot v2020-10.boot???
> > > > > > > > > --- v2020.07.boot Thu Jan??7 16:20:58 2021
> > > > > > > > > +++ v2020-10.boot Thu Jan??7 16:10:27 2021
> > > > > > > > > @@ -1,19 +1,18 @@
> > > > > > > > > -U-Boot TPL 2020.07 (Jul 07 2020 - 19:02:53)
> > > > > > > > > +U-Boot TPL 2020.10 (Jan 02 2021 - 11:16:03)
> > > > > > > > > ?Channel 0: LPDDR4, 50MHz
> > > > > > > > > ?BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
> > > > > > > > > ?Channel 1: LPDDR4, 50MHz
> > > > > > > > > ?BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
> > > > > > > > > ?256B stride
> > > > > > > > > -256B stride
> > > > > > > > > ?lpddr4_set_rate: change freq to 4 mhz 0, 1
> > > > > > > > > ?lpddr4_set_rate: change freq to 8 mhz 1, 0
> > > > > > > > > ?Trying to boot from BOOTROM
> > > > > > > > > ?Returning to boot ROM...
> > > > > > > > > ?
> > > > > > > > > -U-Boot SPL 2020.07 (Jul 07 2020 - 19:02:53 -0600)
> > > > > > > > > +U-Boot SPL 2020.10 (Jan 02 2021 - 11:16:03 -0700)
> > > > > > > > > ?Trying to boot from MMC1
> > > > > > > > > ?NOTICE:??BL31: v2.3():2.3
> > > > > > > > > -NOTICE:??BL31: Built : 18:41:43, Jul??7 2020
> > > > > > > > > +NOTICE:??BL31: Built : 10:45:12, Jan??2 2021
> > > > > > > > > ?INFO:GICv3 with legacy support detected.
> > > > > > > > > ?INFO:ARM GICv3 driver initialized in EL3
> > > > > > > > > ?INFO:plat_rockchip_pmu_init(1624): pd status 3e
> > > > > > > > > @@ -24,7 +23,7 @@
> > > >

Re: update arm-trusted-firmware to 2.4

[Patrick Wildt]

On Tue, Jan 12, 2021 at 05:00:15PM +0100, Patrick Wildt wrote:
> On Tue, Jan 12, 2021 at 10:12:06AM -0500, Kurt Miller wrote:
> > On Tue, 2021-01-12 at 15:09 +1100, Jonathan Gray wrote:
> > > On Tue, Jan 12, 2021 at 07:58:36AM +1100, Jonathan Gray wrote:
> > > > 
> > > > On Mon, Jan 11, 2021 at 08:41:02PM +0100, Patrick Wildt wrote:
> > > > > 
> > > > > Am Sun, Jan 10, 2021 at 09:56:02PM +1100 schrieb Jonathan Gray:
> > > > > > 
> > > > > > On Fri, Jan 08, 2021 at 03:42:31PM -0500, Kurt Miller wrote:
> > > > > > > 
> > > > > > > On Fri, 2021-01-08 at 11:48 -0500, Kurt Miller wrote:
> > > > > > > > 
> > > > > > > > On Fri, 2021-01-08 at 10:27 +1100, Jonathan Gray wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On Thu, Jan 07, 2021 at 04:29:35PM -0500, Kurt Miller wrote:
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > On Thu, 2020-12-31 at 19:24 +1100, Jonathan Gray wrote:
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > https://trustedfirmware-a.readthedocs.io/en/latest/change-log.html#version-2-4
> > > > > > > > > > > 
> > > > > > > > > > > Tests welcome as I don't have rk3328/rk3399/sun50i_a64 
> > > > > > > > > > > hardware.
> > > > > > > > > > This update appears ok on rk3328 and rk3399, however my 
> > > > > > > > > > rockpro64
> > > > > > > > > > will not boot with u-boot 2020.10:
> > > > > > > > > > 
> > > > > > > > > > Rock64 Gen3 w/ v2020.10 u-boot and atf 2.4 works
> > > > > > > > > > Rockpro64 w/2020.10 u-boot and atf 2.4 and 2.3 fails
> > > > > > > > > > Rockpro64 w/2020.07 u-boot and atf 2.4 and 2.3 works
> > > > > > > > > > 
> > > > > > > > > > With 2020.10 u-boot the rockpro64 freezes just after 
> > > > > > > > > > attempting to
> > > > > > > > > > boot the kernel. Here's a diff of v2020.07 with atf 2.3 
> > > > > > > > > > that works
> > > > > > > > > > against v2020.10 with atf 2.3 that freezes:
> > > > > > > > > > 
> > > > > > > > > > rocky$ diff -u v2020.07.boot v2020-10.boot???
> > > > > > > > > > --- v2020.07.boot   Thu Jan??7 16:20:58 2021
> > > > > > > > > > +++ v2020-10.boot   Thu Jan??7 16:10:27 2021
> > > > > > > > > > @@ -1,19 +1,18 @@
> > > > > > > > > > -U-Boot TPL 2020.07 (Jul 07 2020 - 19:02:53)
> > > > > > > > > > +U-Boot TPL 2020.10 (Jan 02 2021 - 11:16:03)
> > > > > > > > > > ?Channel 0: LPDDR4, 50MHz
> > > > > > > > > > ?BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
> > > > > > > > > > ?Channel 1: LPDDR4, 50MHz
> > > > > > > > > > ?BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB
> > > > > > > > > > ?256B stride
> > > > > > > > > > -256B stride
> > > > > > > > > > ?lpddr4_set_rate: change freq to 4 mhz 0, 1
> > > > > > > > > > ?lpddr4_set_rate: change freq to 8 mhz 1, 0
> > > > > > > > > > ?Trying to boot from BOOTROM
> > > > > > > > > > ?Returning to boot ROM...
> > > > > > > > > > ?
> > > > > > > > > > -U-Boot SPL 2020.07 (Jul 07 2020 - 19:02:53 -0600)
> > > > > > > > > > +U-Boot SPL 2020.10 (Jan 02 2021 - 11:16:03 -0700)
> > > > > > > > > > ?Trying to boot from MMC1
> > > > > > > > > > ?NOTICE:??BL31: v2.3():2.3
> > > > > > > > > > -NOTICE:??BL31: Built : 18:41:43, Jul??7 2020
> > > > > > > > > > +NOTICE:??BL31: Built : 1

Re: libc++ 10.0: games/dangerdeep

[Patrick Wildt]

Am Tue, Jan 05, 2021 at 09:07:44PM +0100 schrieb Christian Weisgerber:
> games/dangerdeep fails to build with libc++ 10.0.
> 
> Here's a build fix, adapted from FreeBSD (which has since removed
> the port because of the scons -> python2 dependency).
> 
> OK?

I'm not very versed in C++, but this looks good to me, ok patrick@

> Index: patches/patch-src_coastmap_h
> ===
> RCS file: /cvs/ports/games/dangerdeep/patches/patch-src_coastmap_h,v
> retrieving revision 1.1
> diff -u -p -r1.1 patch-src_coastmap_h
> --- patches/patch-src_coastmap_h  30 Apr 2017 08:24:33 -  1.1
> +++ patches/patch-src_coastmap_h  5 Jan 2021 20:03:40 -
> @@ -1,4 +1,5 @@
>  $OpenBSD: patch-src_coastmap_h,v 1.1 2017/04/30 08:24:33 espie Exp $
> +Index: src/coastmap.h
>  --- src/coastmap.h.orig
>  +++ src/coastmap.h
>  @@ -90,7 +90,7 @@ class coastsegment (public)
> @@ -10,3 +11,21 @@ $OpenBSD: patch-src_coastmap_h,v 1.1 201
>   
>   // some attributes used for map reading/processing
>   std::vector themap;  // pixel data of map file, y 
> points up, like in OpenGL
> +@@ -148,7 +148,7 @@ class coastmap
> + void process_coastline(int x, int y);
> + void process_segment(int x, int y);
> + 
> +-class worker : public thread
> ++class worker : public ::thread
> + {
> + coastmap& cm;
> + public:
> +@@ -160,7 +160,7 @@ class coastmap
> + }
> + };
> + 
> +-thread::auto_ptr myworker;
> ++::thread::auto_ptr myworker;
> + void construction_threaded();
> + 
> + public: 
> Index: patches/patch-src_game_h
> ===
> RCS file: /cvs/ports/games/dangerdeep/patches/patch-src_game_h,v
> retrieving revision 1.1
> diff -u -p -r1.1 patch-src_game_h
> --- patches/patch-src_game_h  30 Apr 2017 08:56:45 -  1.1
> +++ patches/patch-src_game_h  5 Jan 2021 20:03:40 -
> @@ -1,12 +1,25 @@
>  $OpenBSD: patch-src_game_h,v 1.1 2017/04/30 08:56:45 espie Exp $
> +Index: src/game.h
>  --- src/game.h.orig
>  +++ src/game.h
> -@@ -212,7 +212,7 @@ class game (protected)
> +@@ -210,9 +210,9 @@ class game (protected)
> + void simulate_objects_mt(double delta_t, unsigned idxoff, unsigned 
> idxmod, bool record,
> +  double& nearest_contact);
>   
> - class simulate_worker : public thread
> +-class simulate_worker : public thread
> ++class simulate_worker : public ::thread
>   {
>  -mutex mtx;
>  +dd::mutex mtx;
>   condvar cond;
>   condvar condfini;
>   game& gm;
> +@@ -230,7 +230,7 @@ class game (protected)
> + double sync();
> + };
> + 
> +-thread::auto_ptr myworker;
> ++::thread::auto_ptr myworker;
> + 
> + player_info playerinfo;
> + 
> -- 
> Christian "naddy" Weisgerber  na...@mips.inka.de
> 

Re: -current amd64 packages not updated? Impatient or broken?

[Patrick Wildt]

No, that's not correct.  The libc++ 11 (*not* LLVM 11) has not yet been
committed.  This issue is because of libunwind 11.  With libc++ 11 we
have made a separate ports build first, to check the fallout.  Once the
fallout is mostly fixed, we'll do the switch to libc++ 11.  Until then
snapshots are not harmed in anyway, apart from the libunwind update.

Am Thu, Jan 07, 2021 at 11:56:07AM -0600 schrieb Amit Kulkarni:
> Like naddy@ mentioned on ports@ they are trying to figure out the
> fallout from the switch to LLVM 11 as system compiler. This is why the
> packages are being delayed. Please wait a while till it is sorted out.
> 
> thanks
> 
> On Thu, Jan 7, 2021 at 10:56 AM Steve Williams
>  wrote:
> >
> > Hi,
> >
> > I hesitate to send this because perhaps I'm just too impatient, but then
> > again, perhaps not.  This is not critical/time sensitive.
> >
> > I just thought I'd check if there a problem with the current packages
> > folder from the mirrors?
> >
> > I am trying to update my development system (to resume work on a port).
> >
> > I did the initial upgrade on January 4, 2020 and my packages wouldn't
> > update because of missing library versions.  I was told this is just a
> > discrepancy between the OS and the packages and to "wait a few days" for
> > everything to synchronize.
> >  "Unfortunate timing as key system libraries have had version bumps
> > recently. Wait for a new package build (usually a few days on the faster
> > cpu architectures) and try again."
> >
> > I am watching the packages folder on various mirrors and they are all
> > from January 3, 2020, which is when my kernel is from.
> > pulseaudio-14.0.tgz03-Jan-2021
> >
> > I am currently on:
> > OpenBSD 6.8-current (GENERIC.MP) #259: Sun Jan  3 15:25:58 MST 2021
> >
> > This morning, I still can't add/update select packages.
> >
> > desktop# sysupgrade -s
> > Fetching from
> > https://cloudflare.cdn.openbsd.org/pub/OpenBSD//snapshots/amd64/
> > SHA256.sig   100%
> > |***|
> > 2144   00:00
> > Signature Verified
> > Already on latest snapshot.
> > desktop# pkg_add pulseaudio
> > quirks-3.506 signed on 2021-01-03T15:41:44Z
> > Can't install spidermonkey78-78.5.0v1 because of libraries
> > |library c++.5.0 not found
> > | /usr/lib/libc++.so.4.0 (system): bad major
> > | /usr/lib/libc++.so.6.0 (system): bad major
> > |library c++abi.3.0 not found
> > | /usr/lib/libc++abi.so.2.1 (system): bad major
> > | /usr/lib/libc++abi.so.4.0 (system): bad major
> > Direct dependencies for spidermonkey78-78.5.0v1 resolve to libffi-3.3
> > nspr-4.29 icu4c-68.2v0
> > Full dependency tree is libffi-3.3 nspr-4.29 icu4c-68.2v0
> > Can't install polkit-0.118: can't resolve spidermonkey78-78.5.0v1
> > Can't install consolekit2-1.2.2: can't resolve polkit-0.118
> > Can't install pulseaudio-14.0: can't resolve consolekit2-1.2.2
> > Couldn't install consolekit2-1.2.2 polkit-0.118 pulseaudio-14.0
> > spidermonkey78-78.5.0v1
> > desktop#
> >
> > Am I being too impatient?
> >
> > Thanks,
> > Steve Williams
> >
> >
> >
> 

Re: -current amd64 packages not updated? Impatient or broken?

[Patrick Wildt]

Oh, and another correction: it's libc++ 10.0.1, we're not going 11 yet.

Am Thu, Jan 07, 2021 at 06:59:52PM +0100 schrieb Patrick Wildt:
> No, that's not correct.  The libc++ 11 (*not* LLVM 11) has not yet been
> committed.  This issue is because of libunwind 11.  With libc++ 11 we
> have made a separate ports build first, to check the fallout.  Once the
> fallout is mostly fixed, we'll do the switch to libc++ 11.  Until then
> snapshots are not harmed in anyway, apart from the libunwind update.
> 
> Am Thu, Jan 07, 2021 at 11:56:07AM -0600 schrieb Amit Kulkarni:
> > Like naddy@ mentioned on ports@ they are trying to figure out the
> > fallout from the switch to LLVM 11 as system compiler. This is why the
> > packages are being delayed. Please wait a while till it is sorted out.
> > 
> > thanks
> > 
> > On Thu, Jan 7, 2021 at 10:56 AM Steve Williams
> >  wrote:
> > >
> > > Hi,
> > >
> > > I hesitate to send this because perhaps I'm just too impatient, but then
> > > again, perhaps not.  This is not critical/time sensitive.
> > >
> > > I just thought I'd check if there a problem with the current packages
> > > folder from the mirrors?
> > >
> > > I am trying to update my development system (to resume work on a port).
> > >
> > > I did the initial upgrade on January 4, 2020 and my packages wouldn't
> > > update because of missing library versions.  I was told this is just a
> > > discrepancy between the OS and the packages and to "wait a few days" for
> > > everything to synchronize.
> > >  "Unfortunate timing as key system libraries have had version bumps
> > > recently. Wait for a new package build (usually a few days on the faster
> > > cpu architectures) and try again."
> > >
> > > I am watching the packages folder on various mirrors and they are all
> > > from January 3, 2020, which is when my kernel is from.
> > > pulseaudio-14.0.tgz03-Jan-2021
> > >
> > > I am currently on:
> > > OpenBSD 6.8-current (GENERIC.MP) #259: Sun Jan  3 15:25:58 MST 2021
> > >
> > > This morning, I still can't add/update select packages.
> > >
> > > desktop# sysupgrade -s
> > > Fetching from
> > > https://cloudflare.cdn.openbsd.org/pub/OpenBSD//snapshots/amd64/
> > > SHA256.sig   100%
> > > |***|
> > > 2144   00:00
> > > Signature Verified
> > > Already on latest snapshot.
> > > desktop# pkg_add pulseaudio
> > > quirks-3.506 signed on 2021-01-03T15:41:44Z
> > > Can't install spidermonkey78-78.5.0v1 because of libraries
> > > |library c++.5.0 not found
> > > | /usr/lib/libc++.so.4.0 (system): bad major
> > > | /usr/lib/libc++.so.6.0 (system): bad major
> > > |library c++abi.3.0 not found
> > > | /usr/lib/libc++abi.so.2.1 (system): bad major
> > > | /usr/lib/libc++abi.so.4.0 (system): bad major
> > > Direct dependencies for spidermonkey78-78.5.0v1 resolve to libffi-3.3
> > > nspr-4.29 icu4c-68.2v0
> > > Full dependency tree is libffi-3.3 nspr-4.29 icu4c-68.2v0
> > > Can't install polkit-0.118: can't resolve spidermonkey78-78.5.0v1
> > > Can't install consolekit2-1.2.2: can't resolve polkit-0.118
> > > Can't install pulseaudio-14.0: can't resolve consolekit2-1.2.2
> > > Couldn't install consolekit2-1.2.2 polkit-0.118 pulseaudio-14.0
> > > spidermonkey78-78.5.0v1
> > > desktop#
> > >
> > > Am I being too impatient?
> > >
> > > Thanks,
> > > Steve Williams
> > >
> > >
> > >
> > 
> 

Re: UPDATE: OpenAL 1.21.1

[Patrick Wildt]

Am Thu, Apr 22, 2021 at 12:07:48AM -0400 schrieb Brad Smith:
> Here is an update to OpenAL 1.21.1.
> 

Looks good to me at least

> 
> Index: Makefile
> ===
> RCS file: /home/cvs/ports/audio/openal/Makefile,v
> retrieving revision 1.54
> diff -u -p -u -p -r1.54 Makefile
> --- Makefile  9 Jun 2020 13:22:42 -   1.54
> +++ Makefile  22 Apr 2021 03:32:23 -
> @@ -2,15 +2,15 @@
>  
>  COMMENT =cross-platform 3D audio API
>  
> -V =  1.20.1
> +V =  1.21.1
>  EPOCH =  0
>  DISTNAME =   openal-soft-$V
>  PKGNAME =openal-$V
>  CATEGORIES = audio
>  
> -SHARED_LIBS =openal  4.0
> +SHARED_LIBS =openal  4.1
>  
> -HOMEPAGE =   https://kcat.strangesoft.net/openal.html
> +HOMEPAGE =   https://openal-soft.org/
>  
>  MAINTAINER = David Carlier 
>  
> @@ -19,7 +19,7 @@ PERMIT_PACKAGE =Yes
>  
>  WANTLIB +=   c m mysofa pthread sndio z ${COMPILER_LIBCXX}
>  
> -MASTER_SITES =   ${HOMEPAGE:S,.html,-releases/,}
> +MASTER_SITES =   ${HOMEPAGE}openal-releases/
>  EXTRACT_SUFX =   .tar.bz2
>  
>  LIB_DEPENDS +=   audio/libmysofa
> Index: distinfo
> ===
> RCS file: /home/cvs/ports/audio/openal/distinfo,v
> retrieving revision 1.12
> diff -u -p -u -p -r1.12 distinfo
> --- distinfo  9 Jun 2020 13:22:42 -   1.12
> +++ distinfo  22 Apr 2021 03:25:10 -
> @@ -1,2 +1,2 @@
> -SHA256 (openal-soft-1.20.1.tar.bz2) = 
> ts6wUTJXMsI/XIttN9vYlTRRfmQ5qH6XCIK0R8MCXW0=
> -SIZE (openal-soft-1.20.1.tar.bz2) = 512971
> +SHA256 (openal-soft-1.21.1.tar.bz2) = 
> yK12fpoyMN9mdWohzI6/IYqdRyiPJRQBSDIgTmZq9dg=
> +SIZE (openal-soft-1.21.1.tar.bz2) = 524787
> Index: patches/patch-CMakeLists_txt
> ===
> RCS file: /home/cvs/ports/audio/openal/patches/patch-CMakeLists_txt,v
> retrieving revision 1.9
> diff -u -p -u -p -r1.9 patch-CMakeLists_txt
> --- patches/patch-CMakeLists_txt  9 Jun 2020 13:22:42 -   1.9
> +++ patches/patch-CMakeLists_txt  22 Apr 2021 03:28:15 -
> @@ -3,12 +3,12 @@ $OpenBSD: patch-CMakeLists_txt,v 1.9 202
>  Index: CMakeLists.txt
>  --- CMakeLists.txt.orig
>  +++ CMakeLists.txt
> -@@ -1347,7 +1347,7 @@ endif()
> - # Install alsoft.conf configuration file
> - IF(ALSOFT_CONFIG)
> - INSTALL(FILES alsoftrc.sample
> +@@ -1398,7 +1398,7 @@ endif()
> + 
> + if(ALSOFT_INSTALL_CONFIG)
> + install(FILES alsoftrc.sample
>  -DESTINATION ${CMAKE_INSTALL_DATADIR}/openal)
>  +DESTINATION ${CMAKE_INSTALL_DATADIR}/examples/openal)
> - MESSAGE(STATUS "Installing sample configuration")
> - MESSAGE(STATUS "")
> - ENDIF()
> + message(STATUS "Installing sample configuration")
> + endif()
> + 
> Index: patches/patch-alc_alconfig_cpp
> ===
> RCS file: /home/cvs/ports/audio/openal/patches/patch-alc_alconfig_cpp,v
> retrieving revision 1.1
> diff -u -p -u -p -r1.1 patch-alc_alconfig_cpp
> --- patches/patch-alc_alconfig_cpp9 Jun 2020 13:22:43 -   1.1
> +++ patches/patch-alc_alconfig_cpp22 Apr 2021 03:28:12 -
> @@ -3,7 +3,7 @@ $OpenBSD: patch-alc_alconfig_cpp,v 1.1 2
>  Index: alc/alconfig.cpp
>  --- alc/alconfig.cpp.orig
>  +++ alc/alconfig.cpp
> -@@ -326,7 +326,7 @@ void ReadALConfig()
> +@@ -318,7 +318,7 @@ void ReadALConfig()
>   
>   void ReadALConfig()
>   {
> Index: pkg/PLIST
> ===
> RCS file: /home/cvs/ports/audio/openal/pkg/PLIST,v
> retrieving revision 1.11
> diff -u -p -u -p -r1.11 PLIST
> --- pkg/PLIST 9 Jun 2020 13:22:43 -   1.11
> +++ pkg/PLIST 22 Apr 2021 03:52:32 -
> @@ -1,5 +1,4 @@
>  @comment $OpenBSD: PLIST,v 1.11 2020/06/09 13:22:43 ajacoutot Exp $
> -@bin bin/altonegen
>  @bin bin/makemhr
>  @bin bin/openal-info
>  include/AL/
> 

Re: openal: enable NEON on OpenBSD

[Patrick Wildt]

Am Thu, Apr 22, 2021 at 12:08:45AM -0400 schrieb Brad Smith:
> On 4/20/2021 3:38 PM, Patrick Wildt wrote:
> > Hi,
> > 
> > both our arm64 and armv7 require at least NEON support.  audio/openal
> > checks for NEON support by opening /proc/cpuinfo and parsing it, which
> > we obviously don't have.  I'd propose just patching it and enabling it
> > for OpenBSD.  At the very least, it gets rid of this obnoxious message:
> > 
> > Failed to open /proc/cpuinfo, cannot check for NEON support
> > 
> > Tested by running games/openal.
> > 
> > Opinions?
> 
> I just sent out an update to OpenAL where this bit of code has been removed.
> 
> https://github.com/kcat/openal-soft/commit/9d354f721c39dc643399b36297c57ef809451f6f
> 
> Please double check how things are with ARM with the latest code I sent over
> to you.

So I had a look at your openal 1.21.1 diff, and it looks like we don't
have to patch anything.

First they added

https://github.com/kcat/openal-soft/commit/c75c96ce2d2f3801c8e28462d529fe999d12db8f

which skips the cpuinfo dance if __ARM_NEON is defined.

Then, as you pointed out, the cpuinfo stuff was removed.

https://github.com/kcat/openal-soft/commit/9d354f721c39dc643399b36297c57ef809451f6f

In 1.21.1, the code now looks like this:

 #ifdef HAVE_NEON
 #ifdef __ARM_NEON
 ret.mCaps |= CPU_CAP_NEON;
+#error fu
 #elif defined(_WIN32) && (defined(_M_ARM) || defined(_M_ARM64))
 if(IsProcessorFeaturePresent(PF_ARM_NEON_INSTRUCTIONS_AVAILABLE))
 ret.mCaps |= CPU_CAP_NEON;
 #else
 #warning "Assuming NEON run-time support!"
 ret.mCaps |= CPU_CAP_NEON;
 #endif
 #endif

I added the #error fu, to check if the build fails, which means that we
have __ARM_NEON defined.  The build fails with that error, meaning that
I believe we can just update to 1.21.1 without having to patch it.

So yeah, I'm happy with that then!

Patrick

Re: games/openra: update to 20210321

[Patrick Wildt]

On Tue, May 04, 2021 at 09:52:16PM +0200, Tobias Heider wrote:
> On Mon, May 03, 2021 at 03:58:01PM -0600, Thomas Frohwein wrote:
> > Hi,
> > 
> > Here is a diff that updates OpenRA to the latest version 20210321. The
> > heavy lifting was done by patrick@; I added the nuget dependencies and
> > the workaround for the dllmap config files.
> > 
> > bcallah@: would appreciate if both distfiles could be hosted on the
> > nycbug mirror again.
> > 
> > Unfortunately the msbuild ports don't get nicer, so some dark magic is
> > required once again to make it work:
> > 
> > - nuget-openra-20210321.tar.xz is just an archive of the dependencies
> >   fetched by nuget run with a working internet connection. I checked
> >   that this builds with network interface down.
> > - DLLMAP_FILES doesn't work anymore because the the *.config files with
> >   dllmap are built "on the fly" during the install goal. Best option I
> >   could come up with (that doesn't hardcode the library versions like
> >   the included script configure-system-libraries.sh tries to do) was to
> >   copy the correct files from $FILESDIR (they are all trivial and
> >   small).
> > - The build system (MSBuild or mono) erros with LangVersion 7.3; but
> >   lowering it to 7.2 allows it to build without problems.
> > 
> > Tested in a brief single-player mission with Red Alert, and I checked
> > that the multiplayer lobby shows available servers/games.
> > 
> > ok? comments?
> 
> We tested the multiplayer with RA and CNC without problems.
> Patrick didn't stand a chance.
> 
> ok tobhe@

Sigh... Every. Single. Time.

ok patrick@

Re: lang/mono for arm64

[Patrick Wildt]

Cool, thanks, Robert.

> sthen | makes sense to have that mono diff, need to be sure it doesn't break 
> existing working archs (looked good from a quick read but i haven't tested)

The changes are all encapsulated in proper arch ifdefs.  To verify that
is the case I'll compile it on our two mono arches;  amd64 works, and I
will test i386 tomorrow morning.

Patrick

Am Fri, Apr 09, 2021 at 09:00:39PM +0200 schrieb Robert Nagy:
> Hi
> 
> I am okay with this and i do not see why it cannot make release.
> 
> On 09/04/21 17:15 +0200, Patrick Wildt wrote:
> > Hi,
> > 
> > to do some release tests with iked we wanted to play^Wtest games/openra
> > over IPsec.  Turns out that arm64 does not support lang/mono, but I have
> > gotten it to run.  With the following diff, games/openra builds and I
> > can even play it.
> > 
> > This doesn't need to make release, so no worries.  Would be nice for
> > others, but I myself run -current anyway.
> > 
> > The arch-defines.mk enables all mono-related packages.  In gcconfig.h
> > OPENBSD needs to be checked so make sure in case it's AArch64, it
> > doesn't define NOSYS.  Additionally apparently one has to check for
> > OPENBSD and __aarch64__ to define the mach type.  Then there's another
> > AARCH64 block where OS-related stuff has to be defined.  I simply used
> > the AMD64 block, but skipping ELFCLASS.  In boringssl we need to have
> > the 'find aarch64 crypto accel' code as well.  We don't have a nice API
> > yet to extract info, so let's for now only use NEON, which we require
> > on AArch64.  As far as I can see, ucontext is sigcontext, so I provide
> > the same defines as FreeBSD but with sigcontext context.
> > 
> > I can try to get the diffs upstreamed.
> > 
> > Patrick
> > 
> > diff --git a/infrastructure/mk/arch-defines.mk 
> > b/infrastructure/mk/arch-defines.mk
> > index 228c3991f50..965949a964b 100644
> > --- a/infrastructure/mk/arch-defines.mk
> > +++ b/infrastructure/mk/arch-defines.mk
> > @@ -21,7 +21,7 @@ LP64_ARCHS = aarch64 alpha amd64 mips64 mips64el 
> > powerpc64 sparc64
> >  GCC4_ARCHS = alpha hppa sh sparc64
> >  GCC3_ARCHS = m88k
> >  # XXX easier for ports that depend on mono
> > -MONO_ARCHS = amd64 i386
> > +MONO_ARCHS = amd64 i386 aarch64
> >  OCAML_NATIVE_ARCHS = i386 amd64
> >  OCAML_NATIVE_DYNLINK_ARCHS = i386 amd64
> >  GO_ARCHS = aarch64 amd64 arm arm64 armv7 i386
> > diff --git 
> > a/lang/mono/patches/patch-external_bdwgc_include_private_gcconfig_h 
> > b/lang/mono/patches/patch-external_bdwgc_include_private_gcconfig_h
> > new file mode 100644
> > index 000..e2d766861a7
> > --- /dev/null
> > +++ b/lang/mono/patches/patch-external_bdwgc_include_private_gcconfig_h
> > @@ -0,0 +1,51 @@
> > +$OpenBSD$
> > +
> > +Index: external/bdwgc/include/private/gcconfig.h
> > +--- external/bdwgc/include/private/gcconfig.h.orig
> >  external/bdwgc/include/private/gcconfig.h
> > +@@ -155,7 +155,7 @@ EXTERN_C_BEGIN
> > + # if defined(__aarch64__)
> > + #define AARCH64
> > + #if !defined(LINUX) && !defined(DARWIN) && !defined(FREEBSD) \
> > +-&& !defined(NN_BUILD_TARGET_PLATFORM_NX)
> > ++&& !defined(OPENBSD) && !defined(NN_BUILD_TARGET_PLATFORM_NX)
> > + #  define NOSYS
> > + #  define mach_type_known
> > + #endif
> > +@@ -348,6 +348,10 @@ EXTERN_C_BEGIN
> > + #define X86_64
> > + #define mach_type_known
> > + # endif
> > ++# if defined(OPENBSD) && defined(__aarch64__)
> > ++#   define AARCH64
> > ++#   define mach_type_known
> > ++# endif
> > + # if defined(LINUX) && (defined(i386) || defined(__i386__))
> > + #define I386
> > + #define mach_type_known
> > +@@ -2298,6 +2302,25 @@ EXTERN_C_BEGIN
> > +   extern char etext[];
> > + # define DATASTART GC_FreeBSDGetDataStart(0x1000, (ptr_t)etext)
> > + # define DATASTART_USES_BSDGETDATASTART
> > ++#   endif
> > ++#   ifdef OPENBSD
> > ++# define OS_TYPE "OPENBSD"
> > ++# ifndef GC_OPENBSD_THREADS
> > ++EXTERN_C_END
> > ++#   include 
> > ++#   include 
> > ++EXTERN_C_BEGIN
> > ++#   ifdef USRSTACK
> > ++# define STACKBOTTOM ((ptr_t)USRSTACK)
> > ++#   else
> > ++# define HEURISTIC2
> > ++#   endif
> > ++# endif
> > ++  extern int __data_start[];
> > ++  extern int _end[];
> > ++# define DATASTART ((ptr_t)__data_start)

Re: aarch64 bulk build report

[Patrick Wildt]

Am Sun, Apr 11, 2021 at 10:59:02PM -0600 schrieb phess...@openbsd.org:
> bulk build on arm64.ports.openbsd.org
> started on  Fri Apr 9 13:05:37 MDT 2021
> finished at Sun Apr 11 22:58:23 MDT 2021
> lasted 2D09h52m
> done with kern.version=OpenBSD 6.9 (GENERIC.MP) #1119: Fri Apr  9 03:23:43 
> MDT 2021
> 
> built packages:8798
> Apr 9:3480
> Apr 10:1279
> Apr 11:4038
> 
> 
> critical path missing pkgs:  
> http://build-failures.rhaalovely.net/aarch64/2021-04-09/summary.log
> 
> build failures: 1723

Oh, lots of No space left on device?

Re: lang/mono for arm64

[Patrick Wildt]

i386 builds as well, as expected!

> Move aarch64 to the front of the list.

Sure, will do that.

sthen, naddy: OK to put it in, or too late?

Am Sat, Apr 10, 2021 at 01:18:05AM +0200 schrieb Patrick Wildt:
> Cool, thanks, Robert.
> 
> > sthen | makes sense to have that mono diff, need to be sure it doesn't 
> > break existing working archs (looked good from a quick read but i haven't 
> > tested)
> 
> The changes are all encapsulated in proper arch ifdefs.  To verify that
> is the case I'll compile it on our two mono arches;  amd64 works, and I
> will test i386 tomorrow morning.
> 
> Patrick
> 
> Am Fri, Apr 09, 2021 at 09:00:39PM +0200 schrieb Robert Nagy:
> > Hi
> > 
> > I am okay with this and i do not see why it cannot make release.
> > 
> > On 09/04/21 17:15 +0200, Patrick Wildt wrote:
> > > Hi,
> > > 
> > > to do some release tests with iked we wanted to play^Wtest games/openra
> > > over IPsec.  Turns out that arm64 does not support lang/mono, but I have
> > > gotten it to run.  With the following diff, games/openra builds and I
> > > can even play it.
> > > 
> > > This doesn't need to make release, so no worries.  Would be nice for
> > > others, but I myself run -current anyway.
> > > 
> > > The arch-defines.mk enables all mono-related packages.  In gcconfig.h
> > > OPENBSD needs to be checked so make sure in case it's AArch64, it
> > > doesn't define NOSYS.  Additionally apparently one has to check for
> > > OPENBSD and __aarch64__ to define the mach type.  Then there's another
> > > AARCH64 block where OS-related stuff has to be defined.  I simply used
> > > the AMD64 block, but skipping ELFCLASS.  In boringssl we need to have
> > > the 'find aarch64 crypto accel' code as well.  We don't have a nice API
> > > yet to extract info, so let's for now only use NEON, which we require
> > > on AArch64.  As far as I can see, ucontext is sigcontext, so I provide
> > > the same defines as FreeBSD but with sigcontext context.
> > > 
> > > I can try to get the diffs upstreamed.
> > > 
> > > Patrick
> > > 
> > > diff --git a/infrastructure/mk/arch-defines.mk 
> > > b/infrastructure/mk/arch-defines.mk
> > > index 228c3991f50..965949a964b 100644
> > > --- a/infrastructure/mk/arch-defines.mk
> > > +++ b/infrastructure/mk/arch-defines.mk
> > > @@ -21,7 +21,7 @@ LP64_ARCHS = aarch64 alpha amd64 mips64 mips64el 
> > > powerpc64 sparc64
> > >  GCC4_ARCHS = alpha hppa sh sparc64
> > >  GCC3_ARCHS = m88k
> > >  # XXX easier for ports that depend on mono
> > > -MONO_ARCHS = amd64 i386
> > > +MONO_ARCHS = amd64 i386 aarch64
> > >  OCAML_NATIVE_ARCHS = i386 amd64
> > >  OCAML_NATIVE_DYNLINK_ARCHS = i386 amd64
> > >  GO_ARCHS = aarch64 amd64 arm arm64 armv7 i386
> > > diff --git 
> > > a/lang/mono/patches/patch-external_bdwgc_include_private_gcconfig_h 
> > > b/lang/mono/patches/patch-external_bdwgc_include_private_gcconfig_h
> > > new file mode 100644
> > > index 000..e2d766861a7
> > > --- /dev/null
> > > +++ b/lang/mono/patches/patch-external_bdwgc_include_private_gcconfig_h
> > > @@ -0,0 +1,51 @@
> > > +$OpenBSD$
> > > +
> > > +Index: external/bdwgc/include/private/gcconfig.h
> > > +--- external/bdwgc/include/private/gcconfig.h.orig
> > >  external/bdwgc/include/private/gcconfig.h
> > > +@@ -155,7 +155,7 @@ EXTERN_C_BEGIN
> > > + # if defined(__aarch64__)
> > > + #define AARCH64
> > > + #if !defined(LINUX) && !defined(DARWIN) && !defined(FREEBSD) \
> > > +-&& !defined(NN_BUILD_TARGET_PLATFORM_NX)
> > > ++&& !defined(OPENBSD) && !defined(NN_BUILD_TARGET_PLATFORM_NX)
> > > + #  define NOSYS
> > > + #  define mach_type_known
> > > + #endif
> > > +@@ -348,6 +348,10 @@ EXTERN_C_BEGIN
> > > + #define X86_64
> > > + #define mach_type_known
> > > + # endif
> > > ++# if defined(OPENBSD) && defined(__aarch64__)
> > > ++#   define AARCH64
> > > ++#   define mach_type_known
> > > ++# endif
> > > + # if defined(LINUX) && (defined(i386) || defined(__i386__))
> > > + #define I386
> > > + #define mach_type_known
> > > +@@ -2298,6 +2302,25 @@ EXTERN_C_BEGIN
> > > +   extern char etext[];
> > > + # define DATASTART GC_FreeBSDGetDataStart(0x1000, (ptr_t)etext)

openal: enable NEON on OpenBSD

[Patrick Wildt]

Hi,

both our arm64 and armv7 require at least NEON support.  audio/openal
checks for NEON support by opening /proc/cpuinfo and parsing it, which
we obviously don't have.  I'd propose just patching it and enabling it
for OpenBSD.  At the very least, it gets rid of this obnoxious message:

Failed to open /proc/cpuinfo, cannot check for NEON support

Tested by running games/openal.

Opinions?

Patrick

diff --git a/audio/openal/Makefile b/audio/openal/Makefile
index 871aa7bbf6c..a1de0e0467b 100644
--- a/audio/openal/Makefile
+++ b/audio/openal/Makefile
@@ -7,6 +7,7 @@ EPOCH = 0
 DISTNAME = openal-soft-$V
 PKGNAME =  openal-$V
 CATEGORIES =   audio
+REVISION = 0
 
 SHARED_LIBS =  openal  4.0
 
diff --git a/audio/openal/patches/patch-alc_helpers_cpp 
b/audio/openal/patches/patch-alc_helpers_cpp
new file mode 100644
index 000..f3f781d5afc
--- /dev/null
+++ b/audio/openal/patches/patch-alc_helpers_cpp
@@ -0,0 +1,23 @@
+$OpenBSD$
+
+Index: alc/helpers.cpp
+--- alc/helpers.cpp.orig
 alc/helpers.cpp
+@@ -161,6 +161,9 @@ void FillCPUCaps(int capfilter)
+ #endif
+ #endif
+ #ifdef HAVE_NEON
++#if defined(__OpenBSD__)
++caps |= CPU_CAP_NEON;
++#else
+ al::ifstream file{"/proc/cpuinfo"};
+ if(!file.is_open())
+ ERR("Failed to open /proc/cpuinfo, cannot check for NEON support\n");
+@@ -193,6 +196,7 @@ void FillCPUCaps(int capfilter)
+ }
+ }
+ }
++#endif
+ #endif
+ 
+ TRACE("Extensions:%s%s%s%s%s%s\n",

Re: audio/mumble: missing icons

[Patrick Wildt]

Am Sat, Apr 17, 2021 at 01:16:00AM +0200 schrieb Thomas L.:
> Hi,
> 
> I noticed that recently mumble shows me no icons in the toolbar and
> elsewhere. I already tried reverting the most recent changes in
> audio/mumble, but it seems like something else is amiss. To rule out
> broken configuration I tried creating a new user, but it shows the same
> behaviour. Can someone else confirm this or has an idea what changed?
> 
> Kind regards,
> 
> Thomas
> 

Hi,

I heard bluhm@ talk about the same issue this week.  Iirc he had to
*delete* some kde port or so, don't remember.  CCed him, I guess he
can tell you better than me what the cause is.

Patrick

lang/mono for arm64

[Patrick Wildt]

Hi,

to do some release tests with iked we wanted to play^Wtest games/openra
over IPsec.  Turns out that arm64 does not support lang/mono, but I have
gotten it to run.  With the following diff, games/openra builds and I
can even play it.

This doesn't need to make release, so no worries.  Would be nice for
others, but I myself run -current anyway.

The arch-defines.mk enables all mono-related packages.  In gcconfig.h
OPENBSD needs to be checked so make sure in case it's AArch64, it
doesn't define NOSYS.  Additionally apparently one has to check for
OPENBSD and __aarch64__ to define the mach type.  Then there's another
AARCH64 block where OS-related stuff has to be defined.  I simply used
the AMD64 block, but skipping ELFCLASS.  In boringssl we need to have
the 'find aarch64 crypto accel' code as well.  We don't have a nice API
yet to extract info, so let's for now only use NEON, which we require
on AArch64.  As far as I can see, ucontext is sigcontext, so I provide
the same defines as FreeBSD but with sigcontext context.

I can try to get the diffs upstreamed.

Patrick

diff --git a/infrastructure/mk/arch-defines.mk 
b/infrastructure/mk/arch-defines.mk
index 228c3991f50..965949a964b 100644
--- a/infrastructure/mk/arch-defines.mk
+++ b/infrastructure/mk/arch-defines.mk
@@ -21,7 +21,7 @@ LP64_ARCHS = aarch64 alpha amd64 mips64 mips64el powerpc64 
sparc64
 GCC4_ARCHS = alpha hppa sh sparc64
 GCC3_ARCHS = m88k
 # XXX easier for ports that depend on mono
-MONO_ARCHS = amd64 i386
+MONO_ARCHS = amd64 i386 aarch64
 OCAML_NATIVE_ARCHS = i386 amd64
 OCAML_NATIVE_DYNLINK_ARCHS = i386 amd64
 GO_ARCHS = aarch64 amd64 arm arm64 armv7 i386
diff --git a/lang/mono/patches/patch-external_bdwgc_include_private_gcconfig_h 
b/lang/mono/patches/patch-external_bdwgc_include_private_gcconfig_h
new file mode 100644
index 000..e2d766861a7
--- /dev/null
+++ b/lang/mono/patches/patch-external_bdwgc_include_private_gcconfig_h
@@ -0,0 +1,51 @@
+$OpenBSD$
+
+Index: external/bdwgc/include/private/gcconfig.h
+--- external/bdwgc/include/private/gcconfig.h.orig
 external/bdwgc/include/private/gcconfig.h
+@@ -155,7 +155,7 @@ EXTERN_C_BEGIN
+ # if defined(__aarch64__)
+ #define AARCH64
+ #if !defined(LINUX) && !defined(DARWIN) && !defined(FREEBSD) \
+-&& !defined(NN_BUILD_TARGET_PLATFORM_NX)
++&& !defined(OPENBSD) && !defined(NN_BUILD_TARGET_PLATFORM_NX)
+ #  define NOSYS
+ #  define mach_type_known
+ #endif
+@@ -348,6 +348,10 @@ EXTERN_C_BEGIN
+ #define X86_64
+ #define mach_type_known
+ # endif
++# if defined(OPENBSD) && defined(__aarch64__)
++#   define AARCH64
++#   define mach_type_known
++# endif
+ # if defined(LINUX) && (defined(i386) || defined(__i386__))
+ #define I386
+ #define mach_type_known
+@@ -2298,6 +2302,25 @@ EXTERN_C_BEGIN
+   extern char etext[];
+ # define DATASTART GC_FreeBSDGetDataStart(0x1000, (ptr_t)etext)
+ # define DATASTART_USES_BSDGETDATASTART
++#   endif
++#   ifdef OPENBSD
++# define OS_TYPE "OPENBSD"
++# ifndef GC_OPENBSD_THREADS
++EXTERN_C_END
++#   include 
++#   include 
++EXTERN_C_BEGIN
++#   ifdef USRSTACK
++# define STACKBOTTOM ((ptr_t)USRSTACK)
++#   else
++# define HEURISTIC2
++#   endif
++# endif
++  extern int __data_start[];
++  extern int _end[];
++# define DATASTART ((ptr_t)__data_start)
++# define DATAEND ((ptr_t)(&_end))
++# define DYNAMIC_LOADING
+ #   endif
+ #   ifdef NINTENDO_SWITCH
+   static int zero_fd = -1;
diff --git 
a/lang/mono/patches/patch-external_boringssl_crypto_cpu-aarch64-linux_c 
b/lang/mono/patches/patch-external_boringssl_crypto_cpu-aarch64-linux_c
new file mode 100644
index 000..472cc8637e0
--- /dev/null
+++ b/lang/mono/patches/patch-external_boringssl_crypto_cpu-aarch64-linux_c
@@ -0,0 +1,31 @@
+$OpenBSD$
+
+Index: external/boringssl/crypto/cpu-aarch64-linux.c
+--- external/boringssl/crypto/cpu-aarch64-linux.c.orig
 external/boringssl/crypto/cpu-aarch64-linux.c
+@@ -16,7 +16,9 @@
+ 
+ #if defined(OPENSSL_AARCH64) && !defined(OPENSSL_STATIC_ARMCAP)
+ 
++#if !defined(__OpenBSD__)
+ #include 
++#endif
+ 
+ #include 
+ 
+@@ -63,6 +65,15 @@ void OPENSSL_cpuid_setup(void) {
+   if (ID_AA64ISAR0_SHA2_VAL(isar0_val) >= ID_AA64ISAR0_SHA2_BASE) {
+ OPENSSL_armcap_P |= ARMV8_SHA256;
+   }
++}
++
++#elif defined(__OpenBSD__)
++
++#include 
++#include 
++
++void OPENSSL_cpuid_setup(void) {
++  OPENSSL_armcap_P |= ARMV7_NEON;
+ }
+ 
+ #else // linux
diff --git a/lang/mono/patches/patch-mono_utils_mono-sigcontext_h 
b/lang/mono/patches/patch-mono_utils_mono-sigcontext_h
new file mode 100644
index 000..0d036cac533
--- /dev/null
+++ b/lang/mono/patches/patch-mono_utils_mono-sigcontext_h
@@ -0,0 +1,18 @@
+$OpenBSD$
+
+Index: mono/utils/mono-sigcontext.h
+--- mono/utils/mono-sigcontext.h.orig
 mono/utils/mono-sigcontext.h
+@@ -472,6 +472,12 @@ typedef struct ucontext {
+   #define 

Re: audio/mumble: missing icons

[Patrick Wildt]

Am Thu, Apr 22, 2021 at 08:54:28PM + schrieb Klemens Nanni:
> On Sat, Apr 17, 2021 at 11:21:52AM +0200, Rafael Sadowski wrote:
> > On Sat Apr 17, 2021 at 10:06:32AM +0200, Alexander Bluhm wrote:
> > > On Sat, Apr 17, 2021 at 01:34:06AM +0200, Patrick Wildt wrote:
> > > > Am Sat, Apr 17, 2021 at 01:16:00AM +0200 schrieb Thomas L.:
> > > > > Hi,
> > > > > 
> > > > > I noticed that recently mumble shows me no icons in the toolbar and
> > > > > elsewhere. I already tried reverting the most recent changes in
> > > > > audio/mumble, but it seems like something else is amiss. To rule out
> > > > > broken configuration I tried creating a new user, but it shows the 
> > > > > same
> > > > > behaviour. Can someone else confirm this or has an idea what changed?
> > > > > 
> > > > > Kind regards,
> > > > > 
> > > > > Thomas
> > > > > 
> > > > 
> > > > Hi,
> > > > 
> > > > I heard bluhm@ talk about the same issue this week.  Iirc he had to
> > > > *delete* some kde port or so, don't remember.  CCed him, I guess he
> > > > can tell you better than me what the cause is.
> > > > 
> > > > Patrick
> > > 
> > > pkg_delete kiconthemes fixes the issue for me.
> > > pkg_add -Dsnap kiconthemes && mumble triggers the bug on -current.
> > > 
> > > bluhm
> > > 
> > 
> > Can't confirm. Both installed and none icon issues.
> 
> I can reproduce exactly what bluhm describes.
> rsadowski, do you have anything else installed that coulb be important?
> 
> With kiconthemes installed, mumble will print this upon startup:
> 
>   2021-04-22 18:12:20.932 Icon theme "breeze" not found.
> 
> So mumble seems to pick up kiconthemes which wants to use breeze by
> default or so -- I'm unfamiliar with KDE's theme/icon/etc. framework and
> currently don't have the time to further look into this.
> 
> > 
> > Pro Qt tip: Install qt5ct, run qt5ct, set QT_QPA_PLATFORMTHEME=qt5ct.
> > For more themes and icons install lightly, adwaita-qt, breeze, oxygen.
> 
> I have QT_QPA_PLATFORMTHEME=qt5ct in ~/.profile and ran qt5ct once to
> set Qt5 apps to a dark theme, but that doesn't change anything wrt.
> icons in Mumble for me.
> 
> > If you do not like the Qt style, install adwaita-qt and it will looks
> > like GNOME Shell.
> > 
> > Rafael
> > 
> 

Looks like we're not alone:

https://www.reddit.com/r/archlinux/comments/m6qvsa/mumble_no_icons_on_the_main_window_am_i_the_only/
https://www.reddit.com/r/openSUSE/comments/mcf946/broken_mumble_since_2_or_three_snapshots_on/

pkg_add: some XXX shows up

[Patrick Wildt]

Hi,

I was just running pkg_add on one of my machines and I saw this:

gstreamer1-plugins-base-1.18.4:.libs-avahi-0.8p0->avahi-glib-0.8p0: ok
XXX .libs-avahi-0.8p0
XXX .libs-avahi-0.8p0
XXX .libs-avahi-0.8p0
XXX .libs-avahi-0.8p0
XXX .libs-avahi-0.8p0
... (a few more times)

What's that?  Is it of significance?  Did I hit an debug case that
pkg_add (or whatever) has?

Patrick

www/mozilla-firefox: disable NEON in QCMS on AArch64 (for now)

[Patrick Wildt]

Hi,

on my ARM64 workstation firefox has recently begun crashing all the
time.  Turns out it's because QCMS (whatever that is), uses some HW
acceleration (SIMD using NEON/VFP) on ARM64, and the LLVM-backed Rust-
compiler seems to not produce a pseudo-op that instead of emitting
a proper ASM instruction creates a call to it:

 U llvm.fptosi.sat.v4i32.v4f32

This change is a workaround which simply makes QCMS not use NEON on
AArch64.  In the end the right fix would be in Rust/LLVM to create
proper ASM, but I don't know where to look.  Maybe a future update
of Rust/LLVM will fix it automatically.

This patch will continue to compile the NEON extensions, so nm(1)
will still show the reference, but the extensions won't be used.

Not sure this is worth committing.  For now I'll use this locally.

Patrick

diff --git a/www/mozilla-firefox/Makefile b/www/mozilla-firefox/Makefile
index 3de60915c21..1448b6f78ff 100644
--- a/www/mozilla-firefox/Makefile
+++ b/www/mozilla-firefox/Makefile
@@ -6,6 +6,7 @@ ONLY_FOR_ARCHS =amd64 aarch64
 # Don't forget to bump www/firefox-i18n after updates.
 
 MOZILLA_VERSION =  94.0
+REVISION = 0
 MOZILLA_BRANCH =   release
 MOZILLA_PROJECT =  firefox
 MOZILLA_CODENAME = browser
diff --git a/www/mozilla-firefox/patches/patch-gfx_qcms_src_transform_rs 
b/www/mozilla-firefox/patches/patch-gfx_qcms_src_transform_rs
new file mode 100644
index 000..1764109fba6
--- /dev/null
+++ b/www/mozilla-firefox/patches/patch-gfx_qcms_src_transform_rs
@@ -0,0 +1,26 @@
+$OpenBSD$
+
+Index: gfx/qcms/src/transform.rs
+--- gfx/qcms/src/transform.rs.orig
 gfx/qcms/src/transform.rs
+@@ -21,7 +21,7 @@
+ // WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ 
+ #![allow(clippy::missing_safety_doc)]
+-#[cfg(all(any(target_arch = "arm", target_arch = "aarch64"), feature = 
"neon"))]
++#[cfg(all(any(target_arch = "arm"), feature = "neon"))]
+ use crate::transform_neon::{
+ qcms_transform_data_bgra_out_lut_neon, 
qcms_transform_data_rgb_out_lut_neon,
+ qcms_transform_data_rgba_out_lut_neon,
+@@ -1367,10 +1367,8 @@ pub fn transform_create(
+ 
+ #[cfg(all(target_arch = "arm", feature = "neon"))]
+ let neon_supported = is_arm_feature_detected!("neon");
+-#[cfg(all(target_arch = "aarch64", feature = "neon"))]
+-let neon_supported = is_aarch64_feature_detected!("neon");
+ 
+-#[cfg(all(any(target_arch = "arm", target_arch = "aarch64"), 
feature = "neon"))]
++#[cfg(all(any(target_arch = "arm"), feature = "neon"))]
+ if neon_supported {
+ if in_type == RGB8 {
+ transform.transform_fn = 
Some(qcms_transform_data_rgb_out_lut_neon)

Re: www/mozilla-firefox: disable NEON in QCMS on AArch64 (for now)

[Patrick Wildt]

Am Tue, Nov 16, 2021 at 11:27:44AM +0100 schrieb Landry Breuil:
> Le Wed, Nov 10, 2021 at 03:32:21PM +0100, Patrick Wildt a écrit :
> > Hi,
> > 
> > on my ARM64 workstation firefox has recently begun crashing all the
> > time.  Turns out it's because QCMS (whatever that is), uses some HW
> > acceleration (SIMD using NEON/VFP) on ARM64, and the LLVM-backed Rust-
> > compiler seems to not produce a pseudo-op that instead of emitting
> > a proper ASM instruction creates a call to it:
> > 
> >  U llvm.fptosi.sat.v4i32.v4f32
> > 
> > This change is a workaround which simply makes QCMS not use NEON on
> > AArch64.  In the end the right fix would be in Rust/LLVM to create
> > proper ASM, but I don't know where to look.  Maybe a future update
> > of Rust/LLVM will fix it automatically.
> > 
> > This patch will continue to compile the NEON extensions, so nm(1)
> > will still show the reference, but the extensions won't be used.
> > 
> > Not sure this is worth committing.  For now I'll use this locally.
> 
> Sorry for not replying earlier, was offline.
> 
> I didnt even know firefox actually worked on arm64, which i never used
> :) as for the patch itself, i doubt it is upstreamable as is, but i'd
> like at least this to be reported upstream so that rust/qcms/aarch64
> experts can chime in on the subject. Can you take care of that, or
> should i proxy it ?
> 
> As you say, the right fix would be in rust, but my understanding is that
> rust on OpenBSD/arm64 doesnt produce the same working asm as
> Linux/aarch64 uses ?
> 
> Landry

The patch definitely isn't upstreamable, and I don't think I'd want to
upstream that. :D

The problem is somewhere in Rust/LLVM.  Basically QCMS is doing some
regular floating point to integer conversions.  And by regular I mean
that it's not doing fancy weird stuff, it's basically just doing
floating point calculations, it's all correct.

Now something in the compiler produces a pseudo-operation internally.
Typically, as soon as the compiler starts emitting ASM, this pseudo-op
is converted to an actual instruction.  It seems like this doesn't
happen in the compiler.

I would assume that a version update of the LLVM-backend in Rust will
at some point fix the issue.

Of course one problem could still be that for Linux some other codepath
is hit in the compiler, and it doesn't show that problem.  But, I don't
know how to fix that.  I don't even understand which codebase to look
into, and even then, LLVM is just so big, I don't know where to look...

That said, I guess this could be tested easily by extracting that single
rust file from QCMS and trying to compile it standalone, then looking at
what it links to.

Re: clang 13 and __STDC_NO_ATOMICS__

[Patrick Wildt]

On Mon, Nov 01, 2021 at 10:20:13PM -0400, Brad Smith wrote:
> 
> On 10/28/2021 8:42 AM, Jeremie Courreges-Anglas wrote:
> > On Thu, Oct 28 2021, Jeremie Courreges-Anglas  wrote:
> > > On Thu, Oct 28 2021, Christian Weisgerber  wrote:
> > > > I ran an amd64 bulk build with base clang updated to LLVM 13.
> > > > 
> > > > There is substantial fallout.  Java appears to be broken and there
> > > > are numerous failures caused by clang 13 issuing new warnings and
> > > > ports using -Werror.
> > > > 
> > > > Failure logs:
> > > > http://build-failures.rhaalovely.net/amd64-clang/2021-10-27/
> > > > 
> > > > The final error may be misleading.  For instance, devel/libdsm fails
> > > > with a linker error "undefined reference to pthread_create", but
> > > > the root cause is -Werror breaking a configure check.
> > > > 
> > > > Below there's a list of affected ports.  Several hundred more weren't
> > > > built because they depend on something that failed.
> > > > 
> > > > audio/cmus
> > > jsg@ pointed out that this new clang defines __STDC_NO_ATOMICS__
> > > which is most likely wrong.  This breaks at least cmus:
> > > 
> > >
> > > http://build-failures.rhaalovely.net/amd64-clang/2021-10-27/audio/cmus.log
> > Brad, are you sure that this change is 100% correct?
> > https://github.com/llvm/llvm-project/commit/d8cd7806310c51af912a647a6ca46de62ff13214
> > 
> > Should we drop the __STDC_NO_ATOMICS__ define?
> 
> The atomics part was my misunderstanding and is wrong. I have reverted it
> upstream and will
> have it merged into 13.
> 

v3 of my LLVM patchset (and also my llvm13 github branch) do now both
contain the partial revert.

Re: FYI - On the subject of non-OpenBSD developers asking "ok?"

[Patrick Wildt]

Am Fri, Jan 21, 2022 at 07:24:34PM +0100 schrieb Marc Espie:
> On Fri, Jan 21, 2022 at 07:06:22PM +0100, Stefan Sperling wrote:
> > On Fri, Jan 21, 2022 at 11:42:08AM -0600, joshua stein wrote:
> > > Using CVS and dealing with tarballs is probably pretty 
> > > ancient-feeling for many outsiders.  I don't know that more 
> > > documentation is really the problem.
> > > 
> > > I personally tend to ignore most ports@ emails that aren't diffs I 
> > > can easily view in my e-mail client because it's a hassle to save 
> > > the attachment, tar -t it to see what its directory structure is, 
> > > untar it in the proper place, try to build it, then provide feedback 
> > > by copying parts of the Makefile to an e-mail or doing some other 
> > > work to produce a diff.
> > 
> > I never understood why new ports have to submitted as a tarball.
> > Why not accept new ports as a diff which only creates new files?
> > It is trivial to create such a diff.
> 
> Give me the magical recipie that does NOT create directories in the actual
> CVS repository/is usable without write access to the OpenBSD CVS repo or
> a copy !
> 
> They DON'T create new files, they create NEW DIRECTORIES.
> 
> Unless I'm missing something, CVS makes it NEXT TO IMPOSSIBLE TO DO
> without a local repository!

Sounds like a reason to ditch CVS and switch to git.

Re: U-Boot 2022.10 and dtb from Linux 6.0.8

[Patrick Wildt]

Am Fri, Nov 18, 2022 at 12:53:44PM + schrieb Klemens Nanni:
> On Mon, Nov 14, 2022 at 11:37:05PM +0100, Patrick Wildt wrote:
> > Hi,
> > 
> > the u-boot and dtb ports haven't been updated in a while, mostly because
> > updating those regularly breaks working machines.  I think it's time for
> > another update, so here's a diff for both.
> > 
> > Before this heads into the tree it would be nice to get some testing
> > from people with Pinebook Pro, RockPro64, and/or especially a BeagleBone
> > Black.
> > 
> > I reverted the change that switches from the 'old' cpsw switch driver
> > model to the 'new' one.  This should allow is to update the dtbs.
> > 
> > I've personally verified that U-Boot+DTB boot fine on NanoPi R2s, but
> > we have many more combinations.
> > 
> > I can provide pre-built unsigned packages upon request.
> 
> I installed u-boot-aarch64-2022.10.tgz built with dtb-6.0.8.tgz and
> followed INSTALL.arm64 to flash the new files onto my Pinebook Pro's
> eMMC.
> 
> There's a u-boot logo visible in the upper right corner and OpenBSD
> still boots, but the screen remains black now.
> 
> Previously, I'd see X when xenodm started, now I don't see anything.
> No warnings or errors on serial console.
> 
> I also can't switch to another TTY to get a shell.
> 
> Reflashing u-boot from ports makes X work again, no OS changes needed.
> 
> I had the same issue on the same device when trying u-boot 2022.07 some
> months ago.

Are you seeing OpenBSD boot on the display?  Or do you *only* see a
U-Boot logo and nothing else?

Re: U-Boot 2022.10 and dtb from Linux 6.0.8

[Patrick Wildt]

Am Fri, Nov 25, 2022 at 12:52:24AM + schrieb Peter Stuge:
> Jan Stary wrote:
> > Here is the cpsw problem:
> > 
> > -cpsw0 at omsysc46: version 1.12 (0), address 90:59:af:82:2e:7e
> > +cpsw0 at omsysc46: version 1.12 (0), address 00:00:00:00:00:00
> 
> I confirm this on beaglebone black but I'm not sure it's actually a
> dtb bug, more on that below.
> 
> I could anyway DHCP and ping with great success with the zero address.
> 
> 
> > > I reverted the change that switches from the 'old' cpsw switch driver
> > > model to the 'new' one.  This should allow is to update the dtbs.
> > 
> > I don't know what the old/new model is,
> 
> I too am a bit confused, Patrick can you please clarify 'old' and 'new'?
> 
> 
> Does it have to do with these two sibling fragments?
> 
> ethernet@0 {
>   compatible = "ti,am335x-cpsw", "ti,cpsw";
> 
> switch@0 {
>   compatible = "ti,am335x-cpsw-switch", "ti,cpsw-switch";
> 
> (Only the former is (currently) matched by OpenBSD if_cpsw.c.)
> 

Yup.  Apparently the Linux device trees have both, and a commit in Linux
5.15 switched the beaglebone from the one representation style to the
other.

> 
> > but the version in this dtb breaks my bbb.
> 
> In a way it may be making things more correct, just not yet complete.

Eh, well yes and no.  If it causes a regression because our drivers
aren't expecting the changes in the .dts then it's a question of "does
anyone actually adjust our drivers?".  I don't have the machine, so
instead of re-writing cpsw(4) to fit the new-style I'd rather have a
small revert that makes OpenBSD continue to work on the machine.

> For one, both the dtb from Nov 1 snapshot miniroot-am335x-72.img and
> Patrick's dtb have mac-address = [00 00 00 00 00 00]; for both slaves
> (= PHYs). (Though I don't believe that this value is ever used.)
> 
> Working on the cpsw driver I was silently wondering where the nonzero
> MAC on my beaglebone black comes from and I still don't know the answer.
> 

Either local-mac-address or from hardware registers.  For cpsw(4) it's
local-mac-address.  U-Boot configures those on bootup.  Usually there
needs to be a /aliases/ethernet0 or so pointing to the correct node for
U-Boot to set it correctly.  It's possible that this changes as well.
I will have a look.

Cheers,
Patrick

> 
> Here's a boot log:
> 
> --8<-- Nov 1 snapshot miniroot
> U-Boot SPL 2021.10 (Aug 13 2022 - 07:42:11 -0600)
> Trying to boot from MMC1
> 
> 
> U-Boot 2021.10 (Aug 13 2022 - 07:42:11 -0600)
> 
> CPU  : AM335X-GP rev 2.1
> Model: TI AM335x BeagleBone Black
> DRAM:  512 MiB
> WDT:   Started with servicing (60s timeout)
> NAND:  0 MiB
> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... 
>  not set. Validating first E-fuse MAC
> Net:   eth2: ethernet@4a10, eth3: usb_ether
> Hit any key to stop autoboot:  0 
> -->8--
> 
> Does " not set. Validating first E-fuse MAC" mean that
> U-Boot reads the fused MAC_ID0 from the am335x control module and
> writes it into the CPSW registers?
> 
> 
> Booting Patrick's U-Boot (MLO and u-boot.img) with the older snapshot
> dtb I see the same message from U-Boot and cpsw0 has nonzero address.
> 
> After also copying Patrick's dtb to the memory card I still see the
> same message from U-Boot but cpsw0 now has zero address.
> 
> After writing the full Nov 1 snapshot again and copying only the new dtb
> over it I also see the message from U-Boot but cpsw0 again has zero address.
> 
> In all these tries, env print ethaddr in U-Boot always shows nonzero address.
> 
> 
> As I understand the driver, cpsw0 will always have a zero address if
> the "ti,cpsw" device tree node has either no child nodes at all or
> none named "local-mac-address".
> 
> If a "local-mac-address" child node exists then that address is used.
> 
> (if_cpsw.c:364 cpsw_attach() calling cpsw_get_port_config() ff.)
> 
> Neither the snapshot dtb nor Patrick's dtb contain "local-mac-address" so
> is U-Boot modifying only the older dtb (why!?) or what is going on here?
> 
> 
> //Peter
> 

Re: U-Boot 2022.10 and dtb from Linux 6.0.8

[Patrick Wildt]

Am Mon, Nov 28, 2022 at 12:22:30AM +0100 schrieb Patrick Wildt:
> Am Fri, Nov 25, 2022 at 12:52:24AM + schrieb Peter Stuge:
> > Jan Stary wrote:
> > > Here is the cpsw problem:
> > > 
> > > -cpsw0 at omsysc46: version 1.12 (0), address 90:59:af:82:2e:7e
> > > +cpsw0 at omsysc46: version 1.12 (0), address 00:00:00:00:00:00
> > 
> > I confirm this on beaglebone black but I'm not sure it's actually a
> > dtb bug, more on that below.
> > 
> > I could anyway DHCP and ping with great success with the zero address.
> > 
> > 
> > > > I reverted the change that switches from the 'old' cpsw switch driver
> > > > model to the 'new' one.  This should allow is to update the dtbs.
> > > 
> > > I don't know what the old/new model is,
> > 
> > I too am a bit confused, Patrick can you please clarify 'old' and 'new'?
> > 
> > 
> > Does it have to do with these two sibling fragments?
> > 
> > ethernet@0 {
> > compatible = "ti,am335x-cpsw", "ti,cpsw";
> > 
> > switch@0 {
> > compatible = "ti,am335x-cpsw-switch", "ti,cpsw-switch";
> > 
> > (Only the former is (currently) matched by OpenBSD if_cpsw.c.)
> > 
> 
> Yup.  Apparently the Linux device trees have both, and a commit in Linux
> 5.15 switched the beaglebone from the one representation style to the
> other.
> 
> > 
> > > but the version in this dtb breaks my bbb.
> > 
> > In a way it may be making things more correct, just not yet complete.
> 
> Eh, well yes and no.  If it causes a regression because our drivers
> aren't expecting the changes in the .dts then it's a question of "does
> anyone actually adjust our drivers?".  I don't have the machine, so
> instead of re-writing cpsw(4) to fit the new-style I'd rather have a
> small revert that makes OpenBSD continue to work on the machine.
> 
> > For one, both the dtb from Nov 1 snapshot miniroot-am335x-72.img and
> > Patrick's dtb have mac-address = [00 00 00 00 00 00]; for both slaves
> > (= PHYs). (Though I don't believe that this value is ever used.)
> > 
> > Working on the cpsw driver I was silently wondering where the nonzero
> > MAC on my beaglebone black comes from and I still don't know the answer.
> > 
> 
> Either local-mac-address or from hardware registers.  For cpsw(4) it's
> local-mac-address.  U-Boot configures those on bootup.  Usually there
> needs to be a /aliases/ethernet0 or so pointing to the correct node for
> U-Boot to set it correctly.  It's possible that this changes as well.
> I will have a look.

And that is exactly what happened, this should be reverted as well:

-   ethernet0 = _emac0;
-   ethernet1 = _emac1;
+   ethernet0 = _port1;
+   ethernet1 = _port2;

Following diff changes that, and also reverts the changes for
am335x-evm, am335x-evmsk and am335x-icev2, which are also included
in our miniroots.

Can you give this a shot?

I updated the dtb package that I uploaded and sent you the link
for recently.

Cheers,
Patrick

diff --git a/sysutils/dtb/Makefile b/sysutils/dtb/Makefile
index 23accca5c62..674663b3c47 100644
--- a/sysutils/dtb/Makefile
+++ b/sysutils/dtb/Makefile
@@ -1,9 +1,7 @@
 ONLY_FOR_ARCHS=${GCC4_ARCHS} ${CLANG_ARCHS}
 
 COMMENT=   Device Tree Blobs
-# 5.15 breaks cpsw(4) on bbb
-VERSION=   5.14
-REVISION=  1
+VERSION=   6.0.8
 
 # XXX Updating this port has a high chance of breaking drivers as breaking
 # XXX changes are frequently made to device trees in linux. See commit log
@@ -17,7 +15,7 @@ HOMEPAGE= https://www.devicetree.org
 # dual GPL/BSD
 PERMIT_PACKAGE=Yes
 
-MASTER_SITES=  https://cdn.kernel.org/pub/linux/kernel/v5.x/
+MASTER_SITES=  https://cdn.kernel.org/pub/linux/kernel/v6.x/
 EXTRACT_SUFX=  .tar.xz
 #MASTER_SITES= https://git.kernel.org/torvalds/t/
 PKG_ARCH=  *
diff --git a/sysutils/dtb/distinfo b/sysutils/dtb/distinfo
index 2a1c1224b86..269f5365e57 100644
--- a/sysutils/dtb/distinfo
+++ b/sysutils/dtb/distinfo
@@ -1,2 +1,2 @@
-SHA256 (linux-5.14.tar.xz) = fgaLXg0mpisQ5TILJdzldYjLvG94HAkEQhOMnJwycbI=
-SIZE (linux-5.14.tar.xz) = 120669872
+SHA256 (linux-6.0.8.tar.xz) = DeT4OZaVHG+vmyIl209kWILEexoJGYGQ+XvUbl9folc=
+SIZE (linux-6.0.8.tar.xz) = 133886436
diff --git 
a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3328-rock64_dts 
b/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3328-rock64_dts
index d4d21ab8799..d341db3426f 100644
--- a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3328-rock64_dts
+++ b/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3328-rock64_dts
@@ -1,8 +1,8 @@
 Index: arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
 ---

Re: U-Boot 2022.10 and dtb from Linux 6.0.8

[Patrick Wildt]

On Tue, Nov 22, 2022 at 04:18:55PM +0100, Jan Stary wrote:
> On Nov 22 15:42:20, mark.kette...@xs4all.nl wrote:
> > > Date: Tue, 22 Nov 2022 14:40:06 +0100
> > > From: Jan Stary 
> > > 
> > > On Nov 22 13:52:52, h...@stare.cz wrote:
> > > > On Nov 14 23:37:05, patr...@blueri.se wrote:
> > > > > the u-boot and dtb ports haven't been updated in a while, mostly 
> > > > > because
> > > > > updating those regularly breaks working machines.  I think it's time 
> > > > > for
> > > > > another update, so here's a diff for both.
> > > > > 
> > > > > Before this heads into the tree it would be nice to get some testing
> > > > > from people with Pinebook Pro, RockPro64, and/or especially a 
> > > > > BeagleBone
> > > > > Black.
> > > > 
> > > > This breakes my RPI4.
> > > > 
> > > > After replacing the DTBs on the dos partition
> > > > with those from the new dtb port, the rpi4
> > > > does not emit anything on the console,
> > > > and is not reachable over the network.
> > > > 
> > > > I will take the SD card out and remove the com0 boot.conf
> > > > to see what's happening once I am near the machine.
> > > 
> > > My bad, it goes to com0 by default, so I did set tty fb0
> > > (as per INSTALL.arm64). Then I see this (jpeg attached,
> > > as I have no cereal, and no ddb ps etc, as the usb keyboard
> > > does not attach either); in short,
> > > 
> > >   panic: bcm_dwctwo_attach: intr_established failed!
> > 
> > Replacing the DTBs with those from the dtb package is not supposed to
> > work.
> 
> Ah, in that case I misunderstood the whole effort.
> The entire content of the dtb package is /usr/local/share/dtb/.../*.dtb
> - what is supposed to happen with them, i.e. how does one "use" the package?
> 

The raspberry pi is an exception, as the dtb for the raspberry pi come
from a different firmware package.  So the ones from this dtb port
should not be tested on the raspberry pi.  Sorry, didn't think about
this when I sent out the diff, otherwise I would have mentioned it.

U-Boot 2022.10 and dtb from Linux 6.0.8

[Patrick Wildt]

Hi,

the u-boot and dtb ports haven't been updated in a while, mostly because
updating those regularly breaks working machines.  I think it's time for
another update, so here's a diff for both.

Before this heads into the tree it would be nice to get some testing
from people with Pinebook Pro, RockPro64, and/or especially a BeagleBone
Black.

I reverted the change that switches from the 'old' cpsw switch driver
model to the 'new' one.  This should allow is to update the dtbs.

I've personally verified that U-Boot+DTB boot fine on NanoPi R2s, but
we have many more combinations.

I can provide pre-built unsigned packages upon request.

Cheers,
Patrick

diff --git a/sysutils/dtb/Makefile b/sysutils/dtb/Makefile
index 23accca5c62..674663b3c47 100644
--- a/sysutils/dtb/Makefile
+++ b/sysutils/dtb/Makefile
@@ -1,9 +1,7 @@
 ONLY_FOR_ARCHS=${GCC4_ARCHS} ${CLANG_ARCHS}
 
 COMMENT=   Device Tree Blobs
-# 5.15 breaks cpsw(4) on bbb
-VERSION=   5.14
-REVISION=  1
+VERSION=   6.0.8
 
 # XXX Updating this port has a high chance of breaking drivers as breaking
 # XXX changes are frequently made to device trees in linux. See commit log
@@ -17,7 +15,7 @@ HOMEPAGE= https://www.devicetree.org
 # dual GPL/BSD
 PERMIT_PACKAGE=Yes
 
-MASTER_SITES=  https://cdn.kernel.org/pub/linux/kernel/v5.x/
+MASTER_SITES=  https://cdn.kernel.org/pub/linux/kernel/v6.x/
 EXTRACT_SUFX=  .tar.xz
 #MASTER_SITES= https://git.kernel.org/torvalds/t/
 PKG_ARCH=  *
diff --git a/sysutils/dtb/distinfo b/sysutils/dtb/distinfo
index 2a1c1224b86..269f5365e57 100644
--- a/sysutils/dtb/distinfo
+++ b/sysutils/dtb/distinfo
@@ -1,2 +1,2 @@
-SHA256 (linux-5.14.tar.xz) = fgaLXg0mpisQ5TILJdzldYjLvG94HAkEQhOMnJwycbI=
-SIZE (linux-5.14.tar.xz) = 120669872
+SHA256 (linux-6.0.8.tar.xz) = DeT4OZaVHG+vmyIl209kWILEexoJGYGQ+XvUbl9folc=
+SIZE (linux-6.0.8.tar.xz) = 133886436
diff --git 
a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3328-rock64_dts 
b/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3328-rock64_dts
index d4d21ab8799..d341db3426f 100644
--- a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3328-rock64_dts
+++ b/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3328-rock64_dts
@@ -1,8 +1,8 @@
 Index: arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
 --- arch/arm64/boot/dts/rockchip/rk3328-rock64.dts.orig
 +++ arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
-@@ -11,7 +11,7 @@
-   compatible = "pine64,rock64", "rockchip,rk3328";
+@@ -16,7 +16,7 @@
+   };
  
chosen {
 -  stdout-path = "serial2:150n8";
diff --git 
a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-firefly_dts 
b/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-firefly_dts
index 3f491bca66d..9284f71d631 100644
--- a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-firefly_dts
+++ b/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-firefly_dts
@@ -1,8 +1,8 @@
 Index: arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
 --- arch/arm64/boot/dts/rockchip/rk3399-firefly.dts.orig
 +++ arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
-@@ -14,7 +14,7 @@
-   compatible = "firefly,firefly-rk3399", "rockchip,rk3399";
+@@ -22,7 +22,7 @@
+   };
  
chosen {
 -  stdout-path = "serial2:150n8";
diff --git 
a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-nanopi4_dtsi 
b/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-nanopi4_dtsi
index 2ad73484b0b..735c90c8109 100644
--- 
a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-nanopi4_dtsi
+++ 
b/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-nanopi4_dtsi
@@ -1,9 +1,9 @@
 Index: arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
 --- arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi.orig
 +++ arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
-@@ -18,7 +18,7 @@
+@@ -24,7 +24,7 @@
+   };
  
- / {
chosen {
 -  stdout-path = "serial2:150n8";
 +  stdout-path = "serial2:115200n8";
diff --git 
a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-pinebook-pro_dts
 
b/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-pinebook-pro_dts
index 3126aee73a4..a45b88b43cf 100644
--- 
a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-pinebook-pro_dts
+++ 
b/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-pinebook-pro_dts
@@ -1,8 +1,8 @@
 Index: arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
 --- arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts.orig
 +++ arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
-@@ -19,7 +19,7 @@
-   compatible = "pine64,pinebook-pro", "rockchip,rk3399";
+@@ -26,7 +26,7 @@
+   };
  
chosen {
 -  stdout-path = "serial2:150n8";
diff --git 
a/sysutils/dtb/patches/patch-arch_arm64_boot_dts_rockchip_rk3399-rock-pi-4_dtsi 

devel/riscv-elf/binutils: remove info files and libdep.a

[Patrick Wildt]

Hi,

I was updating aarch64 and arm gcc+binutils based on devel/riscv-elf,
but as it turns out that there are some files that are not per cross-
compiler target, but somehow installed for all (and hence clashing
with arm/aarch64).

I'd propose disabling it.  The info ones are disabled like the other
ones, and libdep.a doesn't seem to be used by the build.

ok?

Patrick

diff --git a/devel/riscv-elf/binutils/Makefile 
b/devel/riscv-elf/binutils/Makefile
index f0b711c4eb6..c3d18f5cfc5 100644
--- a/devel/riscv-elf/binutils/Makefile
+++ b/devel/riscv-elf/binutils/Makefile
@@ -1,7 +1,7 @@
 COMMENT=   binutils for riscv-elf cross-development
 
 V= 2.40
-REVISION=  0
+REVISION=  1
 DISTNAME=  binutils-${V}
 
 HOMEPAGE=  https://www.gnu.org/software/binutils/
diff --git a/devel/riscv-elf/binutils/patches/patch-ld_Makefile_in 
b/devel/riscv-elf/binutils/patches/patch-ld_Makefile_in
index a4d808180c7..b121dc3e435 100644
--- a/devel/riscv-elf/binutils/patches/patch-ld_Makefile_in
+++ b/devel/riscv-elf/binutils/patches/patch-ld_Makefile_in
@@ -10,3 +10,12 @@ Index: ld/Makefile.in
  am__TEXINFO_TEX_DIR = $(srcdir)/../texinfo
  DVIS = ld.dvi
  PDFS = ld.pdf
+@@ -1042,7 +1042,7 @@ libldtestplug4_la_SOURCES = testplug4.c
+ libldtestplug4_la_CFLAGS = -g -O2
+ libldtestplug4_la_LDFLAGS = -no-undefined -rpath /nowhere
+ bfdplugindir = $(libdir)/bfd-plugins
+-bfdplugin_LTLIBRARIES = libdep.la
++bfdplugin_LTLIBRARIES =
+ libdep_la_SOURCES = libdep_plugin.c
+ libdep_la_LDFLAGS = -no-undefined -rpath /nowhere -module -avoid-version
+ libdep_la_LINK = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) \
diff --git a/devel/riscv-elf/binutils/patches/patch-libctf_Makefile_in 
b/devel/riscv-elf/binutils/patches/patch-libctf_Makefile_in
new file mode 100644
index 000..3740dbfedc7
--- /dev/null
+++ b/devel/riscv-elf/binutils/patches/patch-libctf_Makefile_in
@@ -0,0 +1,12 @@
+Index: libctf/Makefile.in
+--- libctf/Makefile.in.orig
 libctf/Makefile.in
+@@ -306,7 +306,7 @@ am__v_texidevnull_ = $(am__v_texidevnull_@AM_DEFAULT_V
+ am__v_texidevnull_0 = > /dev/null
+ am__v_texidevnull_1 = 
+ am__dirstamp = $(am__leading_dot)dirstamp
+-INFO_DEPS = doc/ctf-spec.info
++INFO_DEPS =
+ am__TEXINFO_TEX_DIR = $(srcdir)
+ DVIS = doc/ctf-spec.dvi
+ PDFS = doc/ctf-spec.pdf
diff --git a/devel/riscv-elf/binutils/patches/patch-libsframe_Makefile_in 
b/devel/riscv-elf/binutils/patches/patch-libsframe_Makefile_in
new file mode 100644
index 000..48a35044a59
--- /dev/null
+++ b/devel/riscv-elf/binutils/patches/patch-libsframe_Makefile_in
@@ -0,0 +1,12 @@
+Index: libsframe/Makefile.in
+--- libsframe/Makefile.in.orig
 libsframe/Makefile.in
+@@ -276,7 +276,7 @@ AM_V_texidevnull = $(am__v_texidevnull_@AM_V@)
+ am__v_texidevnull_ = $(am__v_texidevnull_@AM_DEFAULT_V@)
+ am__v_texidevnull_0 = > /dev/null
+ am__v_texidevnull_1 = 
+-INFO_DEPS = doc/sframe-spec.info
++INFO_DEPS =
+ am__TEXINFO_TEX_DIR = $(srcdir)
+ DVIS = doc/sframe-spec.dvi
+ PDFS = doc/sframe-spec.pdf
diff --git a/devel/riscv-elf/binutils/pkg/PLIST 
b/devel/riscv-elf/binutils/pkg/PLIST
index bfdfc295a3b..e726af29ebb 100644
--- a/devel/riscv-elf/binutils/pkg/PLIST
+++ b/devel/riscv-elf/binutils/pkg/PLIST
@@ -14,10 +14,6 @@
 @bin bin/${CONFIG}-size
 @bin bin/${CONFIG}-strings
 @bin bin/${CONFIG}-strip
-@info info/ctf-spec.info
-@info info/sframe-spec.info
-lib/bfd-plugins/
-@static-lib lib/bfd-plugins/libdep.a
 @man man/man1/${CONFIG}-addr2line.1
 @man man/man1/${CONFIG}-ar.1
 @man man/man1/${CONFIG}-as.1

devel/arm-none-eabi: update to binutils 2.40 and gcc 12.2.0

[Patrick Wildt]

Hi,

I figured since we've recently updated the riscv cross-compiler, we
should update the arm ones as well.  This changes the port to plain
gcc, away from gcc-linaro, hence a few Makefile changes accross the
tree.

The updated binutils/gcc seem to produce some PLIST changes in newlib,
but newlib isn't used for any other port anyway as far as I can see.

The U-Boots and m1n1 still compile, only ATF needs a patch to make LD
not complain about RWX sections.

One thing I do wonder is if the pkgpath in GCC's PFRAG.arm is necessary.
I remember we got this for gcc-linaro when we added the aarch64 flavor?

+@pkgpath devel/${CONFIG}/gcc,

I assume this will need a pkg_add quirk to move from gcc-linaro to gcc?

Cheers,
Patrick

diff --git a/devel/arm-none-eabi/Makefile b/devel/arm-none-eabi/Makefile
index 6dc255ac18a..6b2a345ca9f 100644
--- a/devel/arm-none-eabi/Makefile
+++ b/devel/arm-none-eabi/Makefile
@@ -1,8 +1,8 @@
 SUBDIR =
 SUBDIR += binutils
 SUBDIR += binutils,aarch64
-SUBDIR += gcc-linaro
-SUBDIR += gcc-linaro,aarch64
+SUBDIR += gcc
+SUBDIR += gcc,aarch64
 SUBDIR += gdb
 SUBDIR += newlib
 
diff --git a/devel/arm-none-eabi/Makefile.inc b/devel/arm-none-eabi/Makefile.inc
index 04ffd1531b6..393659f56e2 100644
--- a/devel/arm-none-eabi/Makefile.inc
+++ b/devel/arm-none-eabi/Makefile.inc
@@ -14,4 +14,4 @@ CONFIGURE_ARGS+=--target=${CONFIG}  \
--disable-nls   \
--disable-werror
 
-EXTRACT_SUFX?= .tar.bz2
+EXTRACT_SUFX?= .tar.xz
diff --git a/devel/arm-none-eabi/binutils/Makefile 
b/devel/arm-none-eabi/binutils/Makefile
index 2ad1d5c9dda..3eb5b12e68f 100644
--- a/devel/arm-none-eabi/binutils/Makefile
+++ b/devel/arm-none-eabi/binutils/Makefile
@@ -1,6 +1,6 @@
 COMMENT=   binutils for ${CONFIG} cross-development
 
-VERSION=   2.31.1
+VERSION=   2.40
 DISTNAME=  binutils-${VERSION}
 
 FLAVORS=   aarch64 arm
@@ -21,11 +21,13 @@ WANTLIB=c z
 MASTER_SITES=  ${MASTER_SITE_GNU:=binutils/}
 DIST_SUBDIR=   binutils
 
+USE_GMAKE= Yes
 USE_LIBTOOL=   No
 
 CONFIGURE_ARGS+=--enable-commonbfdlib=no \
--enable-interwork   \
-   --enable-multilib
+   --enable-multilib   \
+   --without-zstd
 
 SUBST_VARS +=  CONFIG
 
diff --git a/devel/arm-none-eabi/binutils/distinfo 
b/devel/arm-none-eabi/binutils/distinfo
index 1120f4a5a26..aa03d28255d 100644
--- a/devel/arm-none-eabi/binutils/distinfo
+++ b/devel/arm-none-eabi/binutils/distinfo
@@ -1,2 +1,2 @@
-SHA256 (binutils/binutils-2.31.1.tar.bz2) = 
/8w4JpW/lH2mE150NrjtUtmRzycNuJcZDxnW+YOFZNA=
-SIZE (binutils/binutils-2.31.1.tar.bz2) = 30110779
+SHA256 (binutils/binutils-2.40.tar.xz) = 
D4pMJy1/F/Np3tEKSsoouOMEgo6VUm2kgrDMxN/J2OE=
+SIZE (binutils/binutils-2.40.tar.xz) = 25241484
diff --git a/devel/arm-none-eabi/binutils/patches/patch-bfd_Makefile_in 
b/devel/arm-none-eabi/binutils/patches/patch-bfd_Makefile_in
new file mode 100644
index 000..0e55e0a6605
--- /dev/null
+++ b/devel/arm-none-eabi/binutils/patches/patch-bfd_Makefile_in
@@ -0,0 +1,12 @@
+Index: bfd/Makefile.in
+--- bfd/Makefile.in.orig
 bfd/Makefile.in
+@@ -266,7 +266,7 @@ am__v_texidevnull_ = $(am__v_texidevnull_@AM_DEFAULT_V
+ am__v_texidevnull_0 = > /dev/null
+ am__v_texidevnull_1 = 
+ am__dirstamp = $(am__leading_dot)dirstamp
+-INFO_DEPS = doc/bfd.info
++INFO_DEPS =
+ am__TEXINFO_TEX_DIR = $(srcdir)
+ DVIS = doc/bfd.dvi
+ PDFS = doc/bfd.pdf
diff --git a/devel/arm-none-eabi/binutils/patches/patch-bfd_doc_Makefile_in 
b/devel/arm-none-eabi/binutils/patches/patch-bfd_doc_Makefile_in
deleted file mode 100644
index 636b2f3c3ac..000
--- a/devel/arm-none-eabi/binutils/patches/patch-bfd_doc_Makefile_in
+++ /dev/null
@@ -1,12 +0,0 @@
-Index: bfd/doc/Makefile.in
 bfd/doc/Makefile.in.orig
-+++ bfd/doc/Makefile.in
-@@ -174,7 +174,7 @@ AM_V_texidevnull = $(am__v_texidevnull_@AM_V@)
- am__v_texidevnull_ = $(am__v_texidevnull_@AM_DEFAULT_V@)
- am__v_texidevnull_0 = > /dev/null
- am__v_texidevnull_1 = 
--INFO_DEPS = bfd.info
-+INFO_DEPS =
- am__TEXINFO_TEX_DIR = $(srcdir)
- DVIS = bfd.dvi
- PDFS = bfd.pdf
diff --git a/devel/arm-none-eabi/binutils/patches/patch-binutils_Makefile_in 
b/devel/arm-none-eabi/binutils/patches/patch-binutils_Makefile_in
new file mode 100644
index 000..88356d74858
--- /dev/null
+++ b/devel/arm-none-eabi/binutils/patches/patch-binutils_Makefile_in
@@ -0,0 +1,12 @@
+Index: binutils/Makefile.in
+--- binutils/Makefile.in.orig
 binutils/Makefile.in
+@@ -404,7 +404,7 @@ AM_V_texidevnull = $(am__v_texidevnull_@AM_V@)
+ am__v_texidevnull_ = $(am__v_texidevnull_@AM_DEFAULT_V@)
+ am__v_texidevnull_0 = > /dev/null
+ am__v_texidevnull_1 = 
+-INFO_DEPS = doc/binutils.info
++INFO_DEPS =
+ am__TEXINFO_TEX_DIR = $(srcdir)
+ DVIS = doc/binutils.dvi
+ PDFS = doc/binutils.pdf
diff --git 
a/devel/arm-none-eabi/binutils/patches/patch-binutils_doc_Makefile_in 
b/devel/arm-none-eabi/binutils/patches/patch-binutils_doc_Makefile_in
deleted file mode 100644
index 

Update riscv64 cross compiler toolchain for OpenSBI 1.2

[Patrick Wildt]

Hi,

I was looking at upgrading sysutils/opensbi to version 1.2, and then
realized that our current gcc/binutils fail to compile it because of
some instruction set errors (which I forgot to write down).

So I figured maybe we should update the toolchain to GCC 12.2.0 and
binutils 2.40.  Unfortunately that breaks the old U-Boot we have in
our tree, but there's an easy fix one can cherry pick from upstream:

https://source.denx.de/u-boot/u-boot/-/commit/1dde977518f13824b847e23275001191139bc384

Thoughts?

Cheers,
Patrick

diff --git a/devel/riscv-elf/binutils/Makefile 
b/devel/riscv-elf/binutils/Makefile
index d66ec64485a..19344dd842d 100644
--- a/devel/riscv-elf/binutils/Makefile
+++ b/devel/riscv-elf/binutils/Makefile
@@ -1,6 +1,6 @@
 COMMENT=   binutils for riscv-elf cross-development
 
-V= 2.31.1
+V= 2.40
 DISTNAME=  binutils-${V}
 
 HOMEPAGE=  https://www.gnu.org/software/binutils/
@@ -10,6 +10,7 @@ WANTLIB=  c
 MASTER_SITES=  ${MASTER_SITE_GNU:=binutils/}
 DIST_SUBDIR=   binutils
 
+USE_GMAKE= Yes
 USE_LIBTOOL=   No
 
 CONFIGURE_ARGS+=--enable-commonbfdlib=no \
diff --git a/devel/riscv-elf/binutils/distinfo 
b/devel/riscv-elf/binutils/distinfo
index e3af0893907..aa03d28255d 100644
--- a/devel/riscv-elf/binutils/distinfo
+++ b/devel/riscv-elf/binutils/distinfo
@@ -1,2 +1,2 @@
-SHA256 (binutils/binutils-2.31.1.tar.xz) = 
XSAIbs9XUsx9kTQkbpWI+iAXQNVA9+uE15Wx96k7yoY=
-SIZE (binutils/binutils-2.31.1.tar.xz) = 20467996
+SHA256 (binutils/binutils-2.40.tar.xz) = 
D4pMJy1/F/Np3tEKSsoouOMEgo6VUm2kgrDMxN/J2OE=
+SIZE (binutils/binutils-2.40.tar.xz) = 25241484
diff --git a/devel/riscv-elf/binutils/patches/patch-bfd_Makefile_in 
b/devel/riscv-elf/binutils/patches/patch-bfd_Makefile_in
new file mode 100644
index 000..0e55e0a6605
--- /dev/null
+++ b/devel/riscv-elf/binutils/patches/patch-bfd_Makefile_in
@@ -0,0 +1,12 @@
+Index: bfd/Makefile.in
+--- bfd/Makefile.in.orig
 bfd/Makefile.in
+@@ -266,7 +266,7 @@ am__v_texidevnull_ = $(am__v_texidevnull_@AM_DEFAULT_V
+ am__v_texidevnull_0 = > /dev/null
+ am__v_texidevnull_1 = 
+ am__dirstamp = $(am__leading_dot)dirstamp
+-INFO_DEPS = doc/bfd.info
++INFO_DEPS =
+ am__TEXINFO_TEX_DIR = $(srcdir)
+ DVIS = doc/bfd.dvi
+ PDFS = doc/bfd.pdf
diff --git a/devel/riscv-elf/binutils/patches/patch-bfd_doc_Makefile_in 
b/devel/riscv-elf/binutils/patches/patch-bfd_doc_Makefile_in
deleted file mode 100644
index 636b2f3c3ac..000
--- a/devel/riscv-elf/binutils/patches/patch-bfd_doc_Makefile_in
+++ /dev/null
@@ -1,12 +0,0 @@
-Index: bfd/doc/Makefile.in
 bfd/doc/Makefile.in.orig
-+++ bfd/doc/Makefile.in
-@@ -174,7 +174,7 @@ AM_V_texidevnull = $(am__v_texidevnull_@AM_V@)
- am__v_texidevnull_ = $(am__v_texidevnull_@AM_DEFAULT_V@)
- am__v_texidevnull_0 = > /dev/null
- am__v_texidevnull_1 = 
--INFO_DEPS = bfd.info
-+INFO_DEPS =
- am__TEXINFO_TEX_DIR = $(srcdir)
- DVIS = bfd.dvi
- PDFS = bfd.pdf
diff --git a/devel/riscv-elf/binutils/patches/patch-binutils_Makefile_in 
b/devel/riscv-elf/binutils/patches/patch-binutils_Makefile_in
new file mode 100644
index 000..88356d74858
--- /dev/null
+++ b/devel/riscv-elf/binutils/patches/patch-binutils_Makefile_in
@@ -0,0 +1,12 @@
+Index: binutils/Makefile.in
+--- binutils/Makefile.in.orig
 binutils/Makefile.in
+@@ -404,7 +404,7 @@ AM_V_texidevnull = $(am__v_texidevnull_@AM_V@)
+ am__v_texidevnull_ = $(am__v_texidevnull_@AM_DEFAULT_V@)
+ am__v_texidevnull_0 = > /dev/null
+ am__v_texidevnull_1 = 
+-INFO_DEPS = doc/binutils.info
++INFO_DEPS =
+ am__TEXINFO_TEX_DIR = $(srcdir)
+ DVIS = doc/binutils.dvi
+ PDFS = doc/binutils.pdf
diff --git a/devel/riscv-elf/binutils/patches/patch-binutils_doc_Makefile_in 
b/devel/riscv-elf/binutils/patches/patch-binutils_doc_Makefile_in
deleted file mode 100644
index c3a0c562359..000
--- a/devel/riscv-elf/binutils/patches/patch-binutils_doc_Makefile_in
+++ /dev/null
@@ -1,12 +0,0 @@
-Index: binutils/doc/Makefile.in
 binutils/doc/Makefile.in.orig
-+++ binutils/doc/Makefile.in
-@@ -177,7 +177,7 @@ AM_V_texidevnull = $(am__v_texidevnull_@AM_V@)
- am__v_texidevnull_ = $(am__v_texidevnull_@AM_DEFAULT_V@)
- am__v_texidevnull_0 = > /dev/null
- am__v_texidevnull_1 = 
--INFO_DEPS = binutils.info
-+INFO_DEPS =
- am__TEXINFO_TEX_DIR = $(srcdir)
- DVIS = binutils.dvi
- PDFS = binutils.pdf
diff --git a/devel/riscv-elf/binutils/patches/patch-gas_Makefile_in 
b/devel/riscv-elf/binutils/patches/patch-gas_Makefile_in
new file mode 100644
index 000..a6c27d79763
--- /dev/null
+++ b/devel/riscv-elf/binutils/patches/patch-gas_Makefile_in
@@ -0,0 +1,12 @@
+Index: gas/Makefile.in
+--- gas/Makefile.in.orig
 gas/Makefile.in
+@@ -270,7 +270,7 @@ AM_V_texidevnull = $(am__v_texidevnull_@AM_V@)
+ am__v_texidevnull_ = $(am__v_texidevnull_@AM_DEFAULT_V@)
+ am__v_texidevnull_0 = > /dev/null
+ am__v_texidevnull_1 = 
+-INFO_DEPS = doc/as.info
++INFO_DEPS =
+ TEXINFO_TEX = $(top_srcdir)/../texinfo.tex
+ am__TEXINFO_TEX_DIR = $(top_srcdir)/..
+ DVIS = doc/as.dvi

Re: U-Boot 2022.10 and dtb from Linux 6.0.8

[Patrick Wildt]

On Tue, May 09, 2023 at 09:54:59AM +1000, David Gwynne wrote:
> 
> 
> > On 8 May 2023, at 22:44, Mark Kettenis  wrote:
> > 
> >> From: Patrick Wildt 
> >> Date: Mon, 8 May 2023 14:14:27 +0200
> >> 
> >>> Am 07.05.2023 um 19:54 schrieb Klemens Nanni :
> >>> 
> >>> On Sun, May 07, 2023 at 06:30:55PM +0200, Mark Kettenis wrote:
> >>>> As I've said before, the u-boot developers have poor quality control
> >>>> and this will almost certainly break some targets.
> >>>> 
> >>>> I think the way forward is to have a u-boot port per SoC such that we
> >>>> can leave older SoCs using an older U-Boot version that we know to be
> >>>> good while newer SoCs can switch to a newer version after testing a
> >>>> few boards.
> >>> 
> >>> That should always work.  Not sure if pulling them out of the main u-boot
> >>> port one by one or all at once is better, though.
> >>> 
> >>> For the 2207.* update it seemed as if the Pinebook Pro's breakage alone 
> >>> kept
> >>> all others boards on outdated versions and we practically have no other 
> >>> way
> >>> of disentangling this mess, afaict.
> >>> 
> >>> We already have sysutils/u-boot-asahi.
> >>> 
> >>> Would mean some ports shuffling and installing more package where boot 
> >>> media
> >>> is built, but that doesn't seem like too much work.
> >> 
> >> Why don‘t we change the armv7 miniroots to not provide any U-Boot,
> >> like we already do on arm64,
> > 
> > Not against doing this, but by "old" I don't necessarily mean just
> > armv7.
> > 
> >> and then we can remove the whole U-Boot port and not have to
> >> maintain it?
> > 
> > Unfortunately there isn't a good source for pre-built U-Boot binaries,
> > let alone a source of pre-built U-Boot binaries that didn't somehow
> > fuck up EFI support.
> > 
> > So I think the u-boot port *is* useful even if we don't use it to
> > create bootable installer images.  But only as long as we don't ship a
> > package with broken images.  It is clear that we don't have the
> > manpower and infrastructure to test a large enough fraction of the
> > u-boot binaries that our current u-boot package produces.  Hence my
> > suggestion to split the package (and mostly forget about the older
> > ones where new versions of U-Boot don't really add any new
> > functionality).
> 
> I agree completely with Mark here.

Honestly I'm not going to do the work of splitting of this U-Boot port
into multiple "old but stable" ports.  I'd rather have an up-to-date
port where sometimes a machine doesn't boot because U-Boot people fucked
up, than an old version that only works on machines built in 2020.  If
someone wants to split the port off into multiple ports for their
favourite machine, please go ahead.  But I guess I'll just continue to
use a U-Boot git clone in my home directory to build one-time FW for my
needs.

Well actually, maybe we should just rm -rf the whole port, then there's
no frustration on either end. ;)

Cheers,
Patrick

Re: U-Boot 2022.10 and dtb from Linux 6.0.8

[Patrick Wildt]

> Am 07.05.2023 um 19:54 schrieb Klemens Nanni :
> 
> On Sun, May 07, 2023 at 06:30:55PM +0200, Mark Kettenis wrote:
>> As I've said before, the u-boot developers have poor quality control
>> and this will almost certainly break some targets.
>> 
>> I think the way forward is to have a u-boot port per SoC such that we
>> can leave older SoCs using an older U-Boot version that we know to be
>> good while newer SoCs can switch to a newer version after testing a
>> few boards.
> 
> That should always work.  Not sure if pulling them out of the main u-boot
> port one by one or all at once is better, though.
> 
> For the 2207.* update it seemed as if the Pinebook Pro's breakage alone kept
> all others boards on outdated versions and we practically have no other way
> of disentangling this mess, afaict.
> 
> We already have sysutils/u-boot-asahi.
> 
> Would mean some ports shuffling and installing more package where boot media
> is built, but that doesn't seem like too much work.

Why don‘t we change the armv7 miniroots to not provide any U-Boot, like we 
already do on arm64, and then we can remove the whole U-Boot port and not have 
to maintain it?

Re: U-Boot 2022.10 and dtb from Linux 6.0.8

[Patrick Wildt]

On Fri, Nov 18, 2022 at 12:53:44PM +, Klemens Nanni wrote:
> On Mon, Nov 14, 2022 at 11:37:05PM +0100, Patrick Wildt wrote:
> > Hi,
> > 
> > the u-boot and dtb ports haven't been updated in a while, mostly because
> > updating those regularly breaks working machines.  I think it's time for
> > another update, so here's a diff for both.
> > 
> > Before this heads into the tree it would be nice to get some testing
> > from people with Pinebook Pro, RockPro64, and/or especially a BeagleBone
> > Black.
> > 
> > I reverted the change that switches from the 'old' cpsw switch driver
> > model to the 'new' one.  This should allow is to update the dtbs.
> > 
> > I've personally verified that U-Boot+DTB boot fine on NanoPi R2s, but
> > we have many more combinations.
> > 
> > I can provide pre-built unsigned packages upon request.
> 
> I installed u-boot-aarch64-2022.10.tgz built with dtb-6.0.8.tgz and
> followed INSTALL.arm64 to flash the new files onto my Pinebook Pro's
> eMMC.
> 
> There's a u-boot logo visible in the upper right corner and OpenBSD
> still boots, but the screen remains black now.
> 
> Previously, I'd see X when xenodm started, now I don't see anything.
> No warnings or errors on serial console.
> 
> I also can't switch to another TTY to get a shell.
> 
> Reflashing u-boot from ports makes X work again, no OS changes needed.
> 
> I had the same issue on the same device when trying u-boot 2022.07 some
> months ago.

While I did not find the root cause of this back then, a U-Boot 2023.04
with a dtb from Linux 6.3 does seem to work on my machine.  Maybe that
was something caused by U-Boot that is now fixed.

ok?

Patrick

diff --git a/sysutils/u-boot/Makefile b/sysutils/u-boot/Makefile
index d2dd2fad980..4c8acde3638 100644
--- a/sysutils/u-boot/Makefile
+++ b/sysutils/u-boot/Makefile
@@ -7,8 +7,7 @@ FLAVORS=aarch64 arm riscv64
 FLAVOR?=   arm
 
 COMMENT=   U-Boot firmware
-VERSION=   2021.10
-REVISION=  6
+VERSION=   2023.04
 DISTNAME=  u-boot-${VERSION}
 PKGNAME=   u-boot-${FLAVOR}-${VERSION:S/-//}
 FULLPKGNAME=   ${PKGNAME}
@@ -24,7 +23,9 @@ PKG_ARCH= *
 
 BUILD_DEPENDS= devel/bison \
devel/dtc \
-   devel/swig
+   devel/swig \
+   security/gnutls \
+   sysutils/e2fsprogs
 
 # for pkg_resources used in tools/binman/control.py
 BUILD_DEPENDS+=devel/py-setuptools${MODPY_FLAVOR}
@@ -47,6 +48,7 @@ RK3328_BL31=  
"${LOCALBASE}/share/arm-trusted-firmware/rk3328-bl31.elf"
 RK3399_BL31=   "${LOCALBASE}/share/arm-trusted-firmware/rk3399-bl31.elf"
 SUNXI_BL31="${LOCALBASE}/share/arm-trusted-firmware/sun50i_a64-bl31.bin"
 SUNXI_H6_BL31= "${LOCALBASE}/share/arm-trusted-firmware/sun50i_h6-bl31.bin"
+SUNXI_SCP= /dev/null
 .elif "${FLAVOR}" == "arm"
 BUILD_DEPENDS+=devel/arm-none-eabi/gcc,arm
 MAKE_ENV+= CROSS_COMPILE="arm-none-eabi-"
@@ -163,7 +165,7 @@ FILES=\
u-boot-sunxi-with-spl.bin \
u-boot.imx \
u-boot-dtb.imx \
-   u-boot-spl.kwb \
+   u-boot-with-spl.kwb \
u-boot-with-spl.bin \
u-boot.itb \
u-boot-rockchip.bin \
@@ -210,20 +212,20 @@ do-build:
 .if "${BOARD:M*_h64*}"
cd ${WRKSRC} && \
mkdir -p build/${BOARD} && \
-   ${SETENV} ${MAKE_ENV} BL31=${SUNXI_H6_BL31} ${MAKE_PROGRAM} \
-   ${MAKE_FLAGS} O="build/${BOARD}" \
+   ${SETENV} ${MAKE_ENV} BL31=${SUNXI_H6_BL31} SCP=${SUNXI_SCP} \
+   ${MAKE_PROGRAM} ${MAKE_FLAGS} O="build/${BOARD}" \
-f ${MAKE_FILE} "${BOARD}"_defconfig && \
-   ${SETENV} ${MAKE_ENV} BL31=${SUNXI_H6_BL31} ${MAKE_PROGRAM} \
-   ${MAKE_FLAGS} O="build/${BOARD}" \
+   ${SETENV} ${MAKE_ENV} BL31=${SUNXI_H6_BL31} SCP=${SUNXI_SCP} \
+   ${MAKE_PROGRAM} ${MAKE_FLAGS} O="build/${BOARD}" \
-f ${MAKE_FILE} ${ALL_TARGET}
 .else
cd ${WRKSRC} && \
mkdir -p build/${BOARD} && \
-   ${SETENV} ${MAKE_ENV} BL31=${SUNXI_BL31} ${MAKE_PROGRAM} \
-   ${MAKE_FLAGS} O="build/${BOARD}" \
+   ${SETENV} ${MAKE_ENV} BL31=${SUNXI_BL31} SCP=${SUNXI_SCP} \
+   ${MAKE_PROGRAM} ${MAKE_FLAGS} O="build/${BOARD}" \
-f ${MAKE_FILE} "${BOARD}"_defconfig && \
-   ${SETENV} ${MAKE_ENV} BL31=${SUNXI_BL31} ${MAKE_PROGRAM} \
-   ${MAKE_FLAGS} O="build/${BOARD}" \
+   ${SETENV} ${MAKE_ENV} BL31=${SUNXI_BL31} SCP=${SUNXI_SCP} \
+   ${MAKE_PROGRAM} ${MAKE_FLAGS} O="build/${BOARD}" \
-f ${MAKE_FILE} ${ALL_TARGET}

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2016/11/19 06:37:51

Modified files:
databases/py-odbc: Makefile distinfo 
databases/py-odbc/patches: patch-setup_py 
databases/py-odbc/pkg: DESCR 
Added files:
databases/py-odbc/patches: patch-src_pyodbc_h 

Log message:
Update py-odbc to 3.0.10.

ok danj@

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2016/11/19 06:38:35

Modified files:
databases  : Makefile 

Log message:
+py-odbc,python3

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2016/12/07 10:28:27

Modified files:
devel/arm-none-eabi/newlib: Makefile 

Log message:
Missed bump, found by naddy.

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2016/12/06 10:25:29

Modified files:
devel/arm-none-eabi: Makefile 

Log message:
+arm-none-eabi/binutils,aarch64
+arm-none-eabi/gcc-linaro,aarch64

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2016/12/06 10:24:02

Modified files:
devel/arm-none-eabi: Makefile.inc 
devel/arm-none-eabi/binutils: Makefile 
devel/arm-none-eabi/binutils/pkg: DESCR PLIST 
devel/arm-none-eabi/gcc-linaro: Makefile 
devel/arm-none-eabi/gcc-linaro/pkg: DESCR PLIST 
Added files:
devel/arm-none-eabi/binutils/pkg: PFRAG.aarch64 PFRAG.arm 
devel/arm-none-eabi/gcc-linaro/patches: 

patch-gcc_config_aarch64_geniterators_sh 
devel/arm-none-eabi/gcc-linaro/pkg: PFRAG.aarch64 PFRAG.arm 

Log message:
Split devel/arm-none-eabi into two FLAVORs so that we can use the same
port to compile gcc and binutils targeted for either ARM or AArch64.

ok zhuk@ sthen@

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2016/12/11 07:08:39

Modified files:
sysutils/u-boot: Makefile 
sysutils/u-boot/pkg: PLIST 
Added files:
sysutils/u-boot/patches: patch-tools_relocate-rela_c 
sysutils/u-boot/pkg: PFRAG.aarch64 PFRAG.arm 

Log message:
Split sysutils/u-boot into two FLAVORs so that we can use the same
port to compile 32- and 64-bit ARM u-boots.

ok and with help from jsg@

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2016/12/11 07:10:52

Modified files:
devel/quirks   : Makefile 
devel/quirks/files: Quirks.pm 

Log message:
u-boot -> u-boot-arm

ok bmercer@

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2016/12/11 07:09:58

Modified files:
sysutils   : Makefile 

Log message:
+sysutils/u-boot,aarch64

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2017/05/08 23:58:36

Modified files:
devel/arm-none-eabi/gcc-linaro/patches: patch-gcc_configure 

Log message:
Fixup and remove duplicate addition of a patch.

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2017/05/08 03:04:54

Modified files:
devel/arm-none-eabi/gcc-linaro: Makefile distinfo 
devel/arm-none-eabi/gcc-linaro/patches: patch-Makefile_in 
patch-gcc_Makefile_in 

patch-gcc_config_arm_unknown-elf_h 
patch-gcc_config_host 
patch-libgcc_Makefile_in 
patch-libiberty_Makefile_in 
devel/arm-none-eabi/gcc-linaro/pkg: PFRAG.aarch64 PFRAG.arm 
Added files:
devel/arm-none-eabi/gcc-linaro/patches: patch-gcc_configure 
Removed files:
devel/arm-none-eabi/gcc-linaro/patches: 

patch-gcc_config_aarch64_geniterators_sh 
patch-gcc_gcc_c 

Log message:
Update to gcc-linaro-6.3-2017.02 so that we can continue to build
newer U-Boots whose SPL object files get too big to link.  U-Boot
will require gcc 6.0 or later for ARM starting with v2018.01.

ok jsg@

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2017/10/12 03:50:15

Log message:
Import Broadcom FullMAC chipset firmware for bwfm(4).

with and ok sthen@

Status:

Vendor Tag: patrick
Release Tags:   patrick_20171012

N ports/sysutils/firmware/bwfm/Makefile
N ports/sysutils/firmware/bwfm/distinfo
N ports/sysutils/firmware/bwfm/pkg/DESCR
N ports/sysutils/firmware/bwfm/pkg/PLIST

No conflicts created by this import

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2017/10/12 03:53:06

Modified files:
sysutils/firmware: Makefile 

Log message:
+bwfm

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2017/08/24 02:53:02

Modified files:
sysutils/u-boot: Makefile 
sysutils/u-boot/pkg: PFRAG.aarch64 PFRAG.arm 
Added files:
sysutils/u-boot/patches: patch-tools_kwbimage_c 

Log message:
Build u-boot for the Armada 38x (armv7) targets ClearFog and Turris
Omnia, and the EspressoBIN/MacchiatoBIN, which use 64-bit Armada SoCs.

ok jsg@ phessler@

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2018/02/23 00:45:07

Modified files:
sysutils/firmware/intel: Makefile 
sysutils/firmware/intel/pkg: PLIST 

Log message:
Loading the microcode earlier has apparently fixed naddy@'s issues
on the Skylake-based build servers.  Re-enable and ship the Skylake
microcode updates again.

Requested by naddy@
>From and ok sthen@

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2019/02/07 00:23:50

Modified files:
sysutils/arm-trusted-firmware: Makefile distinfo 
sysutils/arm-trusted-firmware/patches: 
   
patch-plat_rockchip_rk3399_include_shared_bl31_param_h 

Log message:
Update ARM Trusted Firmware to a more recent version.  Unfortunately
there has been no release since October '18, but the Allwinner SoC
and thus the Pinebook work a lot better using the recent upstreaming
efforts.  So we grab a recent commit from master as a "beta" version.

ok jsg@

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2019/02/07 00:29:04

Modified files:
sysutils/u-boot: Makefile 

Log message:
Switch from Allwinner's ATF to the official ARM Trusted Firmware
repository.  There has been plenty of upstreaming effort which
improves support for devices like the Pinebook.

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2019/04/09 16:32:48

Modified files:
sysutils/u-boot: Makefile 
Added files:
sysutils/u-boot/patches: patch-include_efi_h 
 patch-lib_efi_loader_efi_memory_c 

Log message:
Fix U-Boot's EFI boot support on 32-bit platforms.  One issue is that
the page mask that removes the lower bits was based on 1UL, which is
only 32-bit on ARMv7.  Thus on machines with 4GiB memory or more the
addresses are truncated and never end up in the EFI memory map.  The
second issue is that on 32-bit systems a function that returns a 64-
bit integer through a pointer was given a pointer to an address that
can only hold 32-bit values, causing a data abort.  The second issue
was fixed in U-Boot 2019.04.

ok phessler@ naddy@

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2021/05/12 07:52:49

Modified files:
games/openra   : Makefile distinfo 
games/openra/patches: patch-Makefile patch-launch-dedicated_sh 
  patch-launch-game_sh 
games/openra/pkg: PLIST 
Added files:
games/openra/files: Eluant.dll.config OpenAL-CS.Core.dll.config 
OpenRA.Platforms.Default.dll.config 
SDL2-CS.dll.config 
games/openra/patches: patch-OpenRA_Game_OpenRA_Game_csproj 
  patch-OpenRA_Launcher_OpenRA_Launcher_csproj 
  patch-OpenRA_Mods_Cnc_OpenRA_Mods_Cnc_csproj 
  
patch-OpenRA_Mods_Common_OpenRA_Mods_Common_csproj 
  
patch-OpenRA_Mods_Common_Widgets_Logic_MapChooserLogic_cs 
  patch-OpenRA_Mods_D2k_OpenRA_Mods_D2k_csproj 
  
patch-OpenRA_Platforms_Default_OpenRA_Platforms_Default_csproj 
  patch-OpenRA_Server_OpenRA_Server_csproj 
  patch-OpenRA_Test_OpenRA_Test_csproj 
  patch-OpenRA_Utility_OpenRA_Utility_csproj 
  
patch-OpenRA_WindowsLauncher_OpenRA_WindowsLauncher_csproj 
  patch-make_ps1 
  patch-packaging_functions_sh 
Removed files:
games/openra/patches: patch-thirdparty_Eluant_dll_config_in 
  patch-thirdparty_download_SharpFont_dll_config 

Log message:
Update to the OpenRA 20210321 release.  There have been a few changes
that we need to adjust to.  OpenRA update the language version to 7.3,
which seems to not compile with our mono/msbuild combination, hence
downgrade to 7.2 and re-work one part of the code that relies on 7.3
semantics.  OpenRA now depends on nuget, so there's a new distfile that
contains the nuget dependencies. Furthermore, add a workaround for the
dllmap config files.

Committing on behalf of thfr@
Tested by and ok bket@ tobhe@
Tested by patrick@ on arm64
Tested by thfr@

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2021/05/12 07:44:45

ports/games/openra/files

Update of /cvs/ports/games/openra/files
In directory cvs.openbsd.org:/tmp/cvs-serv1476/files

Log Message:
Directory /cvs/ports/games/openra/files added to the repository

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2021/05/11 12:51:46

Modified files:
games/openjk   : Makefile distinfo 

Log message:
Update to the latest upstream code for OpenJK.  This gives us a change in
the CMakefile to add -fsigned-char for clang as well, which fixes platforms
with unsigned chars like arm64 and ppc.

ok namn@

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2021/07/04 16:33:49

Modified files:
sysutils/ipmitool: Makefile 

Log message:
Both our arm64 and powerpc64 platforms support ipmi(4), so make sure to
enable the OpenIPMI interface for them as well.

Tested by myself on both arm64 and powerpc64 hardware
ok sthen@

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2021/04/10 09:31:33

Added files:
lang/mono/patches: 
   patch-external_bdwgc_include_private_gcconfig_h 
   patch-external_boringssl_crypto_cpu-aarch64-linux_c 
   patch-mono_utils_mono-sigcontext_h 

Log message:
Add support for OpenBSD/arm64 to lang/mono.  The port itself is in a good shape
for arm64, it just needs a few defines so that Mono recognizes the platform as
a valid one.  The garbage collector patch is copied from amd64, the ucontext
defines simply have to use the correct sigcontext members, and for BoringSSL
we need to provide the setup function that tells BoringSSL which crypto accel
is supported by the CPU.  For now this only enables NEON, which we have on all
OpenBSD/arm64 machines.

"makes sense, need to be sure it doesn't break existing working archs" sthen@
Tested by myself on arm64 by playing games/openra through iked(8) IPsec
Tested by myself on amd64 and i386
ok robert@ naddy@

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2021/04/10 09:36:13

Modified files:
infrastructure/mk: arch-defines.mk 

Log message:
Add aarch64 to MONO_ARCHS.

ok robert@ naddy@

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2021/10/29 05:13:06

Modified files:
sysutils/dtb   : Makefile 
Added files:
sysutils/dtb/patches: 
  
patch-arch_arm64_boot_dts_rockchip_rk3328-nanopi-r2s_dts 

Log message:
Set the baud rate for the NanoPi R2S like we do for other Rockchip-based SoCs.

ok jsg@

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2021/10/29 05:14:46

Modified files:
sysutils/u-boot: Makefile 
sysutils/u-boot/pkg: PFRAG.aarch64 
Added files:
sysutils/u-boot/patches: 
 patch-arch_arm_dts_rk3328-nanopi-r2s_dts 
 patch-configs_nanopi-r2s-rk3328_defconfig 

Log message:
Build nanopi-r2s-rk3328 as well.

ok jsg@

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2023/09/02 12:00:28

Modified files:
sysutils/dtb   : Makefile distinfo 
sysutils/dtb/patches: 
  
patch-arch_arm64_boot_dts_qcom_sc8280xp-lenovo-thinkpad-x13s_dts 
  patch-arch_arm64_boot_dts_qcom_sc8280xp_dtsi 
sysutils/dtb/pkg: PLIST 
sysutils/firmware/arm64-qcom-dtb: Makefile 
Added files:
sysutils/dtb/patches: 
  patch-arch_arm_boot_dts_nxp_imx_imx6q-cm-fx6_dts 
  
patch-arch_arm_boot_dts_ti_omap_am335x-bone-common_dtsi 
  
patch-arch_arm_boot_dts_ti_omap_am335x-boneblack-wireless_dts 
  
patch-arch_arm_boot_dts_ti_omap_am335x-bonegreen-wireless_dts 
  patch-arch_arm_boot_dts_ti_omap_am335x-evm_dts 
  patch-arch_arm_boot_dts_ti_omap_am335x-evmsk_dts 
  patch-arch_arm_boot_dts_ti_omap_am335x-icev2_dts 
  
patch-arch_arm_boot_dts_ti_omap_am335x-sancloud-bbe-common_dtsi 
  patch-arch_arm_boot_dts_ti_omap_am33xx_dtsi 
  
patch-arch_arm_boot_dts_ti_omap_omap3-beagle-xm_dts 
  patch-arch_arm_boot_dts_ti_omap_omap3-beagle_dts 
Removed files:
sysutils/dtb/patches: 
  patch-arch_arm_boot_dts_am335x-bone-common_dtsi 
  
patch-arch_arm_boot_dts_am335x-boneblack-wireless_dts 
  
patch-arch_arm_boot_dts_am335x-bonegreen-wireless_dts 
  patch-arch_arm_boot_dts_am335x-evm_dts 
  patch-arch_arm_boot_dts_am335x-evmsk_dts 
  patch-arch_arm_boot_dts_am335x-icev2_dts 
  
patch-arch_arm_boot_dts_am335x-sancloud-bbe-common_dtsi 
  patch-arch_arm_boot_dts_am33xx_dtsi 
  patch-arch_arm_boot_dts_imx6q-cm-fx6_dts 
  patch-arch_arm_boot_dts_omap3-beagle-xm_dts 
  patch-arch_arm_boot_dts_omap3-beagle_dts 

Log message:
update dtb to linux 6.5

ok tobhe@

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2022/12/12 11:46:51

Modified files:
sysutils/dtb   : Makefile distinfo 
sysutils/dtb/patches: 
  
patch-arch_arm64_boot_dts_qcom_sc8280xp-lenovo-thinkpad-x13s_dts 
  patch-arch_arm64_boot_dts_qcom_sc8280xp_dtsi 
  
patch-arch_arm64_boot_dts_rockchip_rk3399-rock-pi-4_dtsi 
sysutils/dtb/pkg: PLIST 
sysutils/firmware/arm64-qcom-dtb: Makefile 

Log message:
update dtb to linux 6.1 and update qcom for-next patchset

ok tobhe@

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2022/12/06 10:29:15

Modified files:
sysutils/firmware: Makefile 

Log message:
Hook up arm64-qcom-dtb

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2022/12/06 10:26:25

Log message:
Import firmware that provides dtbs for arm64-based Qualcomm SoCs.

discussed with many
ok phessler@ sthen@ tobhe@

Status:

Vendor Tag: pwildt
Release Tags:   pwildt_20221206

N ports/sysutils/firmware/arm64-qcom-dtb/Makefile
N ports/sysutils/firmware/arm64-qcom-dtb/pkg/DESCR
N ports/sysutils/firmware/arm64-qcom-dtb/pkg/PLIST

No conflicts created by this import

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2022/12/06 10:30:36

Modified files:
sysutils/dtb   : Makefile 

Log message:
An sysutils/dtb update should also bump sysutils/firmware/arm64-qcom-dtb.

ok phessler@ sthen@ tobhe@

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2022/12/08 15:53:09

Modified files:
sysutils/dtb   : Makefile 
sysutils/dtb/patches: 
  
patch-arch_arm64_boot_dts_qcom_sc8280xp-lenovo-thinkpad-x13s_dts 
sysutils/firmware/arm64-qcom-dtb: Makefile 

Log message:
Disable the PCIe controller that hosts the Lenovo x13's WWAN for now, as
we currently rely on the BIOS to set up the PCIe controllers and this does
not work on machines without a WWAN card.  Works around a panic on those.

ok kettenis@

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2022/11/30 03:00:25

Modified files:
sysutils/dtb   : Makefile 
sysutils/dtb/patches: 
  
patch-arch_arm64_boot_dts_qcom_sc8280xp-lenovo-thinkpad-x13s_dts 
  
patch-arch_arm64_boot_dts_qcom_sc8280xp-pmics_dtsi 

Log message:
Enable both touchpads to make the touchpads work on all machines.  Also
fix interrupts on the devices hanging off the SPMI bus.  The interrupts
one should head into upstream as well at some point, for the touchpad one
I'm not so sure.

ok tobhe@

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2022/11/30 02:56:42

Added files:
sysutils/dtb/patches: 
  
patch-arch_arm64_boot_dts_qcom_sc8280xp-lenovo-thinkpad-x13s_dts 
  
patch-arch_arm64_boot_dts_qcom_sc8280xp-pmics_dtsi 
  patch-arch_arm64_boot_dts_qcom_sc8280xp_dtsi 

Log message:
Apply current for-next patchset from Linux QCOM maintainers for the Lenovo
Thinkpad x13s.

ok tobhe@

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2022/11/28 08:16:20

Modified files:
sysutils/dtb   : Makefile distinfo 
sysutils/dtb/patches: 
  
patch-arch_arm64_boot_dts_rockchip_rk3328-rock64_dts 
  
patch-arch_arm64_boot_dts_rockchip_rk3399-firefly_dts 
  
patch-arch_arm64_boot_dts_rockchip_rk3399-nanopi4_dtsi 
  
patch-arch_arm64_boot_dts_rockchip_rk3399-pinebook-pro_dts 
  
patch-arch_arm64_boot_dts_rockchip_rk3399-rock-pi-4_dtsi 
  
patch-arch_arm64_boot_dts_rockchip_rk3399-rockpro64_dtsi 
  patch-arch_arm64_boot_dts_rockchip_rk3399_dtsi 
sysutils/dtb/pkg: PLIST 
Added files:
sysutils/dtb/patches: 
  patch-arch_arm_boot_dts_am335x-bone-common_dtsi 
  
patch-arch_arm_boot_dts_am335x-boneblack-wireless_dts 
  
patch-arch_arm_boot_dts_am335x-bonegreen-wireless_dts 
  patch-arch_arm_boot_dts_am335x-evm_dts 
  patch-arch_arm_boot_dts_am335x-evmsk_dts 
  patch-arch_arm_boot_dts_am335x-icev2_dts 
  
patch-arch_arm_boot_dts_am335x-sancloud-bbe-common_dtsi 
  patch-arch_arm_boot_dts_am33xx_dtsi 

Log message:
update dtb to linux 6.0.10

Includes a revert of the changes in linux 5.15 that switched the cpsw(4)
bindings to a different format.  This allows us to update the dtb port
without breaking cpsw(4) on the Beaglebone Black.  If we ever adjust
cpsw(4) to work with the new bindings, this could be dropped.

ok tobhe@

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2023/01/16 14:08:05

Modified files:
sysutils/dtb   : Makefile 
sysutils/dtb/patches: 
  
patch-arch_arm64_boot_dts_qcom_sc8280xp-lenovo-thinkpad-x13s_dts 
  
patch-arch_arm64_boot_dts_qcom_sc8280xp-pmics_dtsi 
sysutils/firmware/arm64-qcom-dtb: Makefile 

Log message:
Add an RTC node to the Lenovo Thinkpad x13s device tree.

Re: CVS: cvs.openbsd.org: ports

[Patrick Wildt]

On Thu, Feb 16, 2023 at 07:32:57AM +0100, Antoine Jacoutot wrote:
> On Wed, Feb 08, 2023 at 06:03:04AM -0700, Patrick Wildt wrote:
> > CVSROOT:/cvs
> > Module name:ports
> > Changes by: patr...@cvs.openbsd.org 2023/02/08 06:03:04
> > 
> > Modified files:
> > devel/riscv-elf/gcc: Makefile distinfo 
> > devel/riscv-elf/gcc/patches: patch-Makefile_in 
> >  patch-gcc_Makefile_in 
> >  patch-gcc_configure 
> >  patch-libgcc_Makefile_in 
> >  patch-libiberty_Makefile_in 
> > devel/riscv-elf/gcc/pkg: PLIST 
> > Removed files:
> > devel/riscv-elf/gcc/patches: patch-gcc_tree-vect-stmts_c 
> > 
> > Log message:
> > Update riscv-elf-gcc to 12.2.0
> > 
> > ok kevlo@
> 
> Fails to build because dpb junks libzstd.
> 
> 
> c++  -fno-PIE -c  -DIN_GCC_FRONTEND -O2 -pipe -DIN_GCC  
> -DCROSS_DIRECTORY_STRUCTURE  -fno-strict-aliasing -fno-exceptions -fno-rtti 
> -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
> -Wcast-qual -Wmissing-format-attr
> ibute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros 
> -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I. 
> -I/exopi-obj/pobj/riscv-elf-gcc-12.2.0/gcc-12.2.0/gcc 
> -I/exopi-obj/pobj/riscv-elf-gcc-12.2.0/gcc-12.2.0/gcc/. -I/ex
> opi-obj/pobj/riscv-elf-gcc-12.2.0/gcc-12.2.0/gcc/../include 
> -I/exopi-obj/pobj/riscv-elf-gcc-12.2.0/gcc-12.2.0/gcc/../libcpp/include 
> -I/exopi-obj/pobj/riscv-elf-gcc-12.2.0/gcc-12.2.0/gcc/../libcody 
> -I/usr/local/include  -I/exopi-obj/pobj/r
> iscv-elf-gcc-12.2.0/gcc-12.2.0/gcc/../libdecnumber 
> -I/exopi-obj/pobj/riscv-elf-gcc-12.2.0/gcc-12.2.0/gcc/../libdecnumber/dpd 
> -I../libdecnumber 
> -I/exopi-obj/pobj/riscv-elf-gcc-12.2.0/gcc-12.2.0/gcc/../libbacktrace  
> -I/usr/local/include -o
> cc1-checksum.o -MT cc1-checksum.o -MMD -MP -MF ./.deps/cc1-checksum.TPo 
> cc1-checksum.cc
> c++ -nopie   -O2 -pipe -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  
> -fno-strict-aliasing -fno-exceptions -fno-rtti -fasynchronous-unwind-tables 
> -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual 
> -Wmissing-format-attribute -Woverloaded-virt
> ual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   
> -DHAVE_CONFIG_H -L/usr/local/lib -o cc1 c/c-lang.o c-family/stub-objc.o 
> attribs.o c/c-errors.o c/c-decl.o c/c-typeck.o c/c-convert.o c/c-aux-info.o 
> c/c-objc-commo
> n.o c/c-parser.o c/c-fold.o c/gimple-parser.o c-family/c-common.o 
> c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o 
> c-family/c-gimplify.o c-family/c-indentation.o c-family/c-lex.o 
> c-family/c-omp.o c-family/c-opts.o c-family/c-
> pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o 
> c-family/c-semantics.o c-family/c-ada-spec.o c-family/c-ubsan.o 
> c-family/known-headers.o c-family/c-attribs.o c-family/c-warn.o 
> c-family/c-spellcheck.o default-c.o
> \
>   cc1-checksum.o libbackend.a main.o libcommon-target.a libcommon.a 
> ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a 
> ../libcpp/libcpp.a  /usr/local/lib/libiconv.a 
> ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a
> ../libdecnumber/libdecnumber.a   -L/usr/local/lib -lmpc -lmpfr -lgmp 
> -rdynamic  -L./../zlib -lz -lzstd
> ld: error: unable to find library -lzstd
> 
> 
> -- 
> Antoine

This seems to compile me without not having zstd installed.

ok?

diff --git a/devel/riscv-elf/gcc/Makefile b/devel/riscv-elf/gcc/Makefile
index 0c52745b3e9..e6eaf554355 100644
--- a/devel/riscv-elf/gcc/Makefile
+++ b/devel/riscv-elf/gcc/Makefile
@@ -3,6 +3,7 @@ COMMENT=gcc for riscv-elf cross-development
 VERSION=   12.2.0
 DISTNAME=  gcc-${VERSION}
 PKGNAME=   riscv-elf-gcc-${VERSION}
+REVISION=  0
 
 SUBST_VARS+=   VERSION
 
@@ -34,7 +35,8 @@ CONFIGURE_ARGS+=--enable-languages=${LANGS}   \
--disable-libcc1\
--disable-lto   \
--enable-cpp\
-   --without-isl
+   --without-isl   \
+   --without-zstd
 CONFIGURE_ENV= CPPFLAGS="-I${LOCALBASE}/include" \
LDFLAGS="-L${LOCALBASE}/lib"
 

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2023/02/19 06:55:04

Modified files:
devel/riscv-elf/gcc: Makefile 

Log message:
Add --without-zstd to the configure options, so that the build doesn't fail
on machines where archivers/zstd is not installed.

Reported by and ok aja@

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2023/02/20 18:53:21

Modified files:
sysutils/dtb   : Makefile distinfo 
sysutils/dtb/patches: 
  
patch-arch_arm64_boot_dts_qcom_sc8280xp-lenovo-thinkpad-x13s_dts 
  
patch-arch_arm64_boot_dts_qcom_sc8280xp-pmics_dtsi 
  patch-arch_arm64_boot_dts_rockchip_rk3399_dtsi 
sysutils/firmware/arm64-qcom-dtb: Makefile 
Removed files:
sysutils/dtb/patches: 
  patch-arch_arm64_boot_dts_qcom_sc8280xp_dtsi 

Log message:
update dtb to linux 6.2, which allows us to drop most of our qcom patchset

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2023/02/20 19:06:32

Modified files:
sysutils/dtb/pkg: PLIST 

Log message:
Update PLIST for linux 6.2, which I forgot to commit.

Caught by jsg@, thanks!

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2023/04/22 10:21:08

ports/devel/arm-none-eabi/gcc

Update of /cvs/ports/devel/arm-none-eabi/gcc
In directory cvs.openbsd.org:/tmp/cvs-serv23473/gcc

Log Message:
Directory /cvs/ports/devel/arm-none-eabi/gcc added to the repository

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2023/04/22 10:21:21

ports/devel/arm-none-eabi/gcc/patches

Update of /cvs/ports/devel/arm-none-eabi/gcc/patches
In directory cvs.openbsd.org:/tmp/cvs-serv11131/gcc/patches

Log Message:
Directory /cvs/ports/devel/arm-none-eabi/gcc/patches added to the repository

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2023/04/22 10:21:21

ports/devel/arm-none-eabi/gcc/pkg

Update of /cvs/ports/devel/arm-none-eabi/gcc/pkg
In directory cvs.openbsd.org:/tmp/cvs-serv11131/gcc/pkg

Log Message:
Directory /cvs/ports/devel/arm-none-eabi/gcc/pkg added to the repository

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2023/04/22 10:20:45

Modified files:
devel/arm-none-eabi/binutils: Makefile distinfo 
devel/arm-none-eabi/binutils/patches: patch-gprof_Makefile_in 
  patch-ld_Makefile_in 
  patch-libiberty_Makefile_in 
Added files:
devel/arm-none-eabi/binutils/patches: patch-bfd_Makefile_in 
  patch-binutils_Makefile_in 
  patch-gas_Makefile_in 
  patch-libctf_Makefile_in 
  patch-libsframe_Makefile_in 
Removed files:
devel/arm-none-eabi/binutils/patches: patch-bfd_doc_Makefile_in 
  patch-binutils_doc_Makefile_in 
  patch-gas_doc_Makefile_in 
  
patch-libiberty_testsuite_Makefile_in 

Log message:
Update arm-none-eabi binutils to 2.40

ok tobhe@

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2023/04/22 10:23:25

Added files:
devel/arm-none-eabi/gcc: Makefile distinfo 
devel/arm-none-eabi/gcc/patches: patch-Makefile_in 
 patch-gcc_Makefile_in 
 patch-gcc_common_opt 
 patch-gcc_config_arm_elf_h 
 patch-gcc_config_host 
 patch-gcc_configure 
 patch-libcc1_connection_cc 
 patch-libgcc_Makefile_in 
 patch-libiberty_Makefile_in 
 vecstep-gcc_tree-vect-loop_c 
devel/arm-none-eabi/gcc/pkg: DESCR PFRAG.aarch64 PFRAG.arm PLIST 

Log message:
Import arm-none-eabi gcc 12.2.0 as a replacement for gcc-linaro.

ok tobhe@

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2023/04/22 10:26:16

Modified files:
devel/arm-none-eabi: Makefile Makefile.inc 

Log message:
Switch over from arm-none-eabi gcc-linaro to gcc.

ok tobhe@

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2023/04/22 10:27:40

Modified files:
devel/arm-none-eabi/newlib: Makefile 
devel/arm-none-eabi/newlib/pkg: PLIST 

Log message:
arm-none-eabi binutils and gcc update influenced newlib PLIST contents.

ok tobhe@

CVS: cvs.openbsd.org: ports

[Patrick Wildt]

CVSROOT:/cvs
Module name:ports
Changes by: patr...@cvs.openbsd.org 2023/04/21 17:20:22

Modified files:
devel/riscv-elf/binutils: Makefile 
devel/riscv-elf/binutils/patches: patch-ld_Makefile_in 
devel/riscv-elf/binutils/pkg: PLIST 
Added files:
devel/riscv-elf/binutils/patches: patch-libctf_Makefile_in 
  patch-libsframe_Makefile_in 

Log message:
Get rid of additional info dep files that accidentally showed up in the port
during the last update.  While there, also get rid of the libdep plugin.
These files clashed with the work in progress update for the arm and aarch64
cross-toolchain.

ok tobhe@