Hi,
this diff updates the U-Boot ports to 2024.07. It builds, but I haven't
actually tried it on a machine so far; and I don't have all machines
either.
Would be happy if someone could give it a try. For now, sharing that it
doesn't get lost (or if someone wants to pick it up).
Cheers,
Patrick
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 Kl
> 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 p
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
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 i
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 othe
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. Unfortunate
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
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
&g
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
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
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, Rock
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.
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
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 instruc
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
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
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
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
> > th
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
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:
> >
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
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
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 2
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,
le 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
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 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
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+
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
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 lo
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:
>
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 ecos
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.
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 wrote:
> > >
> > > - cloud/kvm solution. There are several cloud
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 solut
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 C
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)
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
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
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 tre
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
> ===
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 cr
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
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
>
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
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
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
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
>
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_genit
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 =
= .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
+
+# BSD
+PERMIT_PACKAGE_CDROM = Yes
+
+WANTLIB = c
+
+BUILD_DEPENDS += devel/llvm
54 matches
Mail list logo
