Re: Add support for RK356x eMMC controller

[Patrick Wildt]

On Mon, Feb 26, 2024 at 04:47:53PM +0100, Mizsei Zolt??n wrote:
> Hi,
> 
> on NetBSD  the following is used to support the eMMC modules on RK356x. Would 
> it possible to implement asomething similar for OpenBSD?
> 
> https://github.com/NetBSD/src/commit/f30b89bb4385f5fe218ff86be5d458a51fc62d4c
> 
> For more info see the original commit message below:
> 
> "acpi: sdhc: Add support for RK356x eMMC controller.
> RK356x has a DesignWare eMMC controller that is somewhat SDHCI compliant,
> with one major problem -- the clock divisor doesn't actually work. To
> change the clock card on Rockchip SoCs, the clock frequency needs to be
> adjusted in the Clock & Reset Unit (CRU) directly.
> 
> The RK356x UEFI implementation introduces a DSM that allows drivers to
> request firmware assistance in setting the card clock rate, for instances
> like this where the divisor is broken.

RK356x is not a viable platform for use with ACPI.  I'd recommend to
switch to a Linux-mainline device tree and use a current U-Boot, if
possible.

Re: [arm64] [sound] simpleaudio, but no audio to attach

[Patrick Wildt]

On Wed, Apr 19, 2023 at 06:09:06AM -, Stuart Henderson wrote:
> On 2023-04-18, S V  wrote:
> > Hello, misc@!
> >
> > I'm using ARM64/current and see that my audio chip got detected by 
> > simpleaudio
> > but OpenBSD can't attach audio to it
> >
> > Any suggestions on there to start reading? I'm not developer,
> > but I tried to read different match/attach functions
> > in simpleaudio.c/audio.c with no result for now.
> 
> Fortunately you don't need to be a programmer to add some code that
> will help you figure out more about what's going on.
> 
> Try adding printf()s to simpleaudio_attach_deferred() to check if that
> function is called and, if so, see how far it gets.
> 
> I guess it might hit one of the "return"s before actually attaching, so
> for example you could add printf before+after the various return
> statements to see if they were triggered.
> 
> While you can just printf some text that you write to identify them,
> you can save a bit of time by sprinkling some of these which use the
> C features to include the function name/line number:
> 
>   printf("... %s line %d\n", __func__, __LINE__);

Yup.  Also we don't appear to have support for nuvoton,nau8822, so that
might be a hindrance.  simpleaudio is merely a meta-node that combines
all the necessary HW pieces for a audio path.  This usually needs some-
thing that does I2S (transfers audio), speakers and... probably some-
thing else I forgot.  Your simpleaudio node shows two pieces, referenced
through the phandles 0031 and 0032.  You should look these up
to see what drivers you need to implement.

Re: VMware Tools driver to advertise OS as 'FreeBSD 64-bit' OS, not 32-bit version

[Patrick Wildt]

On Fri, Oct 28, 2022 at 12:26:07PM -0700, Mike Larkin wrote:
> On Fri, Oct 28, 2022 at 12:30:11PM -0600, Theo de Raadt wrote:
> > Kalabic S,  wrote:
> >
> > > To be more precise, I wanted to say sticking with FreeBSD means
> > > sticking with whatever behavior VMware will keep consistent and
> > > support in the future. For "Others" option I don't think they care and
> > > is more probable to vary.
> >
> > I cannot tell the difference.  I think you are completely unqualified
> > to know what "they will not change" fakery vmware is doing with the MSR's
> > and clock related registers... it is actually possible that when they
> > *know* it is one particular operating system they do something sophisticated
> > to fool that one specific operating system, whereas when they don't know
> > what the operating system is, they reduce the amount of trickery.
> >
> > You don't know.  I don't know.  None of us know.
> >
> > But can you please stop making claims you can't back.
> >
> 
> I think it's reasonable to try and claim that whatever we are, we are the
> closest to "that thing". Meaning, the OP said we should claim we are FreeBSD
> 64 bit or 32 bit or whatever. Fine, but let's spend some time to actually
> figure out *what* we should say we are before we just pick something randomly
> because "it fixed my machine". Maybe we should say we're Windows? Maybe we
> should say we're Linux? My point, and I think Theo's as well, is we don't
> know and just randomly taking a diff because it fixes one scenario on one
> version of ESXi is shortsighted.
> 
> So I would ask the OP to:
> 
>  - try different OS choices
>  - on different versions of ESX
>  - on different versions of VMware fusion
>  - on different versions of VMware workstation
>  - on different versions of OpenBSD VMs
>  - on different archs (i386/amd64) of OpenBSD VMs
> 
> ... and then report back what the findings are.
> 
> -ml

Hi,

>From what I've been told from someone in the know:

* What we report in vmt(4) doesn't influence what machine is modeled,
  that's just for what's shown in vCenter.  We should probably show
  something useful.  I kinda liked that OpenBSD 7.2 GENEIRC.MP#31 string
  that jmatthew@ showed, but that's another discussion.

* The guest type configured in the .vmx influences the VM model.  Just
  assume the ESXi version has a workaround for FreeBSD to run fine on
  that ESXi, it could be possible that it actually degrades OpenBSD
  performance/stability.  In general it makes more sense to opt for the
  Other 64-Bit guest type (for amd64).

I personally sometimes use Windows 11 guest types on things like VMware
Fusion or Parallels, but that's mostly because they sometimes have some
funky devices and I'm doing that for testing w/ graphics.  For ESXi I'd
opt for Other 64-Bit.

Cheers,
Patrick

Re: ix(4) stopped working after upgrade to OpenBSD 6.8

[Patrick Wildt]

Am Sun, Jan 16, 2022 at 06:38:08PM - schrieb Stuart Henderson:
> On 2022-01-16, Ax0n  wrote:
> > I have a SuperMicro X9DRH-7TF that's been chugging along diligently in a
> > data center. I've been upgrading the vmm instances it hosts but I let the
> > host get pretty far behind. After running sysupgrade to 6.8, the system
> > never came back online. I have the Supermicro BMC IPMI, so I used that to
> > mount remote CD-ROMs to complete the upgrade to 6.9 and 7.0. The network
> > still doesn't work, from the install images or after it's been upgraded.
> > There have been "mem address conflict" messages on this hardware for as
> > long as I can remember. OpenBSD 6.4 at least. They may or may not be a red
> > herring.
> >
> > I mounted the OpenBSD 6.7 cd67.iso and I was able to get it on the network
> > again. Somewhere between 6.7 and 6.8, ix(4) broke with this hardware, an
> > integrated dual-port Intel X540.
> 
> Do both ix0 and ix1 break, or just ix1?
> 
> One important difference visible in dmesg is that ix starts using MSI-X.

Can you give this a go?  I remember issues with broken MSI-X bars or so,
but that was on some Ryzen.

Patrick

diff --git a/sys/arch/amd64/pci/pci_machdep.c b/sys/arch/amd64/pci/pci_machdep.c
index 72456c32829..1cdc33757ee 100644
--- a/sys/arch/amd64/pci/pci_machdep.c
+++ b/sys/arch/amd64/pci/pci_machdep.c
@@ -96,6 +96,8 @@
 #include 
 #endif
 
+intpci_check_msix_bar(pci_chipset_tag_t, pcitag_t);
+
 /*
  * Memory Mapped Configuration space access.
  *
@@ -497,6 +499,36 @@ msix_delroute(struct pic *pic, struct cpu_info *ci, int 
pin, int vec, int type)
pci_msix_table_unmap(pc, tag, memt, memh);
 }
 
+/*
+ * BIOS assigns BAR addresses for every PCI device, but some BIOS are bugged 
and
+ * map an illegal address, say for instance an address outside the ppb(4) 
range.
+ * When this occurs, OpenBSD rewrites the BAR address as 0.
+ * This BAR might be the MSI-X BAR, therefore we consider address 0 as a bad 
BAR
+ * address and fail MSI-X mapping. It's not greatest solution but since we
+ * never correct bad addresses for BARs, this at least prevents us from using
+ * MSI-X when we know it won't work.
+ */
+int
+pci_check_msix_bar(pci_chipset_tag_t pc, pcitag_t tag)
+{
+   pcireg_t table;
+   bus_addr_t base;
+   int bir, off;
+
+   if (pci_get_capability(pc, tag, PCI_CAP_MSIX, , NULL) == 0)
+   return (ENODEV);
+
+   table = pci_conf_read(pc, tag, off + PCI_MSIX_TABLE);
+   bir = (table & PCI_MSIX_TABLE_BIR);
+   bir = PCI_MAPREG_START + bir * 4;
+
+   if (pci_mem_find(pc, tag, bir, , NULL, NULL) ||
+   base == 0)
+   return (ENODEV);
+
+   return (0);
+}
+
 int
 pci_intr_map_msix(struct pci_attach_args *pa, int vec, pci_intr_handle_t *ihp)
 {
@@ -507,7 +539,8 @@ pci_intr_map_msix(struct pci_attach_args *pa, int vec, 
pci_intr_handle_t *ihp)
KASSERT(PCI_MSIX_VEC(vec) == vec);
 
if ((pa->pa_flags & PCI_FLAGS_MSI_ENABLED) == 0 || mp_busses == NULL ||
-   pci_get_capability(pc, tag, PCI_CAP_MSIX, NULL, ) == 0)
+   (pci_get_capability(pc, tag, PCI_CAP_MSIX, NULL, ) == 0) ||
+   pci_check_msix_bar(pc, tag))
return 1;
 
if (vec > PCI_MSIX_MC_TBLSZ(reg))
diff --git a/sys/dev/pci/pci_map.c b/sys/dev/pci/pci_map.c
index 3cc0e61c0df..9567e83c363 100644
--- a/sys/dev/pci/pci_map.c
+++ b/sys/dev/pci/pci_map.c
@@ -135,7 +135,12 @@ obsd_pci_mem_find(pci_chipset_tag_t pc, pcitag_t tag, int 
reg, pcireg_t type,
u_int64_t waddress, wmask;
int s, is64bit;
 
-   is64bit = (PCI_MAPREG_MEM_TYPE(type) == PCI_MAPREG_MEM_TYPE_64BIT);
+   if (type == -1)
+   is64bit = (PCI_MAPREG_MEM_TYPE(pci_conf_read(pc, tag, reg))
+   == PCI_MAPREG_MEM_TYPE_64BIT);
+   else
+   is64bit = (PCI_MAPREG_MEM_TYPE(type) ==
+   PCI_MAPREG_MEM_TYPE_64BIT);
 
if (reg < PCI_MAPREG_START ||
 #if 0

Re: unknown warning option '-Wno-unused-but-set-variable'

[Patrick Wildt]

Kernel Makefiles were adjusted to compile with clang 13.  Either take
out the warnings so you can compile with old-clang, or rebuild clang.

What should have been done was to add no-op arguments for these warnings
into clang 11 to ease the transition to clang 13, but somehow no one did
it, huh.

Patrick

Am Fri, Dec 17, 2021 at 07:23:06PM +0100 schrieb Jan Stary:
> This is current/i386 on an ALIX.1E (dmesg below).
> The kernel does not build with the current cvs:
> 
> cat /usr/src/sys/arch/i386/i386/genassym.cf 
> /usr/src/sys/arch/i386/i386/genassym.cf |  sh /usr/src/sys/kern/genassym.sh 
> cc -no-integrated-as -g -Werror -Wall -Wimplicit-function-declaration  
> -Wno-pointer-sign  -Wframe-larger-than=2047 -Wno-address-of-packed-member 
> -Wno-constant-conversion  -Wno-unused-but-set-variable 
> -Wno-gnu-folding-constant  -ffreestanding -fno-pie -mretpoline -O2  -pipe 
> -nostdinc -I/usr/src/sys -I/usr/src/sys/arch/i386/compile/GENERIC/obj 
> -I/usr/src/sys/arch  -I/usr/src/sys/dev/pci/drm/include
> -I/usr/src/sys/dev/pci/drm/include/uapi  -I/usr/src/sys/dev/pci/drm/i915 
> -DDDB -DDIAGNOSTIC -DKTRACE -DACCOUNTING -DKMEMSTATS -DPTRACE -DPOOL_DEBUG 
> -DCRYPTO -DSYSVMSG -DSYSVSEM -DSYSVSHM -DUVM_SWAP_ENCRYPT -DFFS -DFFS2 
> -DFFS_SOFTUPDATES -DUFS_DIRHASH -DQUOTA -DEXT2FS -DMFS -DNFSCLIENT 
> -DNFSSERVER -DCD9660 -DUDF -DMSDOSFS -DFIFO -DFUSE -DSOCKET_SPLICE -DTCP_ECN 
> -DTCP_SIGNATURE -DINET6 -DIPSEC -DPPP_BSDCOMP -DPPP_DEFLATE -DPIPEX 
> -DMROUTING -DMPLS -DBOOT_CONFIG -DUSER_PCICONF -DAPERTURE -DMTRR -DNTFS 
> -DHIBERNATE -DPCIVERBOSE -DEISAVERBOSE -DUSBVERBOSE -DWSDISPLAY_COMPAT_USL 
> -DWSDISPLAY_COMPAT_RAWKBD -DWSDISPLAY_DEFAULTSCREENS="6" -DX86EMU 
> -DONEWIREVERBOSE -DMAXUSERS=80 -D_KERNEL -MD -MP -MF assym.P > assym.h.tmp
> error: unknown warning option '-Wno-unused-but-set-variable'; did you mean 
> '-Wno-unused-const-variable'? [-Werror,-Wunknown-warning-option]
> *** Error 1 in /usr/src/sys/arch/i386/compile/GENERIC (Makefile:1286 
> 'assym.h')
> 
> 
>   Jan
> 
> 
> OpenBSD 7.0-current (GENERIC) #345: Thu Dec 16 13:19:22 MST 2021
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> real mem  = 259207168 (247MB)
> avail mem = 238182400 (227MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 07/19/10, BIOS32 rev. 0 @ 0xfa950
> apm0 at bios0: Power Management spec V1.2 (slowidle)
> pcibios0 at bios0: rev 2.1 @ 0xf/0xdfb4
> pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdf30/128 (6 entries)
> pcibios0: PCI Exclusive IRQs: 5 10 11
> pcibios0: no compatible PCI ICU found: ICU vendor 0x1022 product 0x2090
> pcibios0: Warning, unable to fix up PCI interrupt routing
> pcibios0: PCI bus #0 is the last bus
> bios0: ROM list: 0xc/0x8000 0xc8000/0xa800 0xef000/0x1000!
> cpu0 at mainbus0: (uniprocessor)
> cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 
> 499 MHz, 05-0a-02
> cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
> mtrr: K6-family MTRR support (2 registers)
> amdmsr0 at mainbus0
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x33
> vga1 at pci0 dev 1 function 1 "AMD Geode LX Video" rev 0x00
> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
> wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
> glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
> vr0 at pci0 dev 13 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11, 
> address 00:0d:b9:0e:9e:f4
> ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 
> 0x004063, model 0x0034
> glxpcib0 at pci0 dev 15 function 0 "AMD CS5536 ISA" rev 0x03: rev 3, 32-bit 
> 3579545Hz timer, watchdog, gpio, i2c
> gpio0 at glxpcib0: 32 pins
> iic0 at glxpcib0
> pciide0 at pci0 dev 15 function 2 "AMD CS5536 IDE" rev 0x01: DMA, channel 0 
> wired to compatibility, channel 1 wired to compatibility
> wd0 at pciide0 channel 0 drive 0: 
> wd0: 1-sector PIO, LBA48, 15279MB, 31293360 sectors
> wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
> pciide0: channel 1 ignored (disabled)
> auglx0 at pci0 dev 15 function 3 "AMD CS5536 Audio" rev 0x01: irq 11, CS5536 
> AC97
> ac97: codec id 0x414c4770 (Avance Logic ALC203 rev 0)
> ac97: codec features headphone, 20 bit DAC, 18 bit ADC, No 3D Stereo
> audio0 at auglx0
> ohci0 at pci0 dev 15 function 4 "AMD CS5536 USB" rev 0x02: irq 5, version 
> 1.0, legacy support
> ehci0 at pci0 dev 15 function 5 "AMD CS5536 USB" rev 0x02: irq 5
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 configuration 1 interface 0 "AMD EHCI root hub" rev 2.00/1.00 
> addr 1
> isa0 at glxpcib0
> isadma0 at isa0
> com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> com0: console
> com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
> pckbc0 at isa0 port 0x60/5 irq 1 irq 12
> pckbd0 at pckbc0 (kbd slot)
> wskbd0 at pckbd0: console keyboard, using wsdisplay0
> pcppi0 at isa0 

Re: lm(4) temperature

[Patrick Wildt]

Am Sat, Nov 27, 2021 at 03:35:05PM +0100 schrieb Jan Stary:
> > > This is current/i386 on an ALIX.1E (dmesg below).
> > > I am trying to monitor the CPU temperature with
> > > 
> > > wbsio0 at isa0 port 0x2e/2: W83627HF rev 0x41
> > > lm1 at wbsio0 port 0x290/8: W83627HF
> > > 
> > > $ sysctl hw.sensors.lm1
> > > hw.sensors.lm1.temp0=69.00 degC
> > > hw.sensors.lm1.temp1=57.00 degC
> > > hw.sensors.lm1.temp2=49.00 degC
> > > hw.sensors.lm1.volt0=1.26 VDC (VCore A)
> > > hw.sensors.lm1.volt1=2.64 VDC (VCore B)
> > > hw.sensors.lm1.volt2=3.42 VDC (+3.3V)
> > > hw.sensors.lm1.volt3=5.11 VDC (+5V)
> > > hw.sensors.lm1.volt4=0.00 VDC (+12V)
> > > hw.sensors.lm1.volt5=-14.91 VDC (-12V)
> > > hw.sensors.lm1.volt6=-7.71 VDC (-5V)
> > > hw.sensors.lm1.volt7=5.07 VDC (5VSB)
> > > hw.sensors.lm1.volt8=0.00 VDC (VBAT)
> > > 
> > > There are three temperatures reported,
> > > and dev/ic/lm78var.h talks about Temperature 1, 2, 3;
> > > but man lm(4) only says
> > > 
> > >   Temp uK Motherboard Temperature
> > > 
> > > Does anyone know what exactly they are?
> > 
> > 
> > There is a chip in the machine.
> > It has pins.
> > Those pins are monitored by the driver, as specific registers.
> > 
> > The pins wired to who the hell knows where by each board manufacturer.
> > 
> > Sometimes the chips need special registers and capacitors
> > 
> > Quite often, the board engineer sent to add this part to the board
> > choose the wrong registers and capacitors, and sometimes they compensate
> > for these errors with private tables in the BIOS or various monitoring
> > programs which move around machine to machine.
> > 
> > 
> > We monitor registers.  We assume the vendor did the right thing.
> > 
> > No that I've described what a shitshow it is, I hope you can adjust your
> > expectations.
> 
> OK, with expectations adjusted,
> does anyone know what the three numbers
> are _supposed_ to be?
> 

Yes.  Temperature readings from multiple places on the motherboard.

Re: iked choosing the wrong policy?

[Patrick Wildt]

On Tue, Jul 27, 2021 at 09:55:34AM +0200, Claudio Jeker wrote:
> On Tue, Jul 27, 2021 at 07:32:09AM -, Stuart Henderson wrote:
> > On 2021-07-27, Vladimir Nikishkin  wrote:
> > > Hello, everyone.
> > >
> > > This is my iked.conf:
> > >
> > > ```
> > > ikev2 "for-phone" passive esp \
> > > from any to 10.0.3.2/32 \
> > > local egress peer any \
> > ...
> > > dstid phone.mine \
> > 
> > > ikev2 "for-laptop" passive esp \
> > > from any to 10.0.3.3/32 \
> > > local egress peer any \
> > ...
> > > dstid laptop.mine \
> > 
> > Two policies with "peer any" doesn't work.
> > 
> > > How to correct the setup?
> > 
> > Maybe it's possible by modifying the code, I'm not sure if the
> > id is sent early enough though so it might not be possible.
> 
> This is one of the biggest annoyances of iked. It does not even help to
> use different IPs and 'local' to split up the rules. Would love if someone
> would fix this.

Using differnt IPs for local should work.  The trouble is not in iked,
but in the IKEv2 protocol.  The IDs are only shared in the second part
of the handshake.  So until then, there's no way for the daemon to find
the correct policy, apart from looking at local or peer address.

That's why the settings for the IKE-SA should be similar across all
policies thate could be valid, and the Child-SA can then (afaik) have
different settings.

But still, using different IPs for local should work in -current.

Re: spamd IPv6 listener 6.9amd64

[Patrick Wildt]

Am Wed, May 12, 2021 at 09:46:28AM -0400 schrieb Aisha Tammy:
> afaik spamd(8) does not support ipv6 (yet).
> I also do not know if there is any ongoing effort for ipv6 to be added.
> 
> On 5/12/21 9:24 AM, Martin wrote:
> > Hi list,
> > 
> > I can't find in spamd(8) how to enable IPv6 listener in addition to IPv4 
> > one.
> > 
> > Is it possible to set spamd(8) to listen on both IPv4 and IPv6?
> > 
> > Martin
> > 

I'm using rspamd, that's a pretty good application.

Re: Q: dmesg: dt: 443 probes

[Patrick Wildt]

Am Tue, May 04, 2021 at 03:38:14PM - schrieb Stuart Henderson:
> On 2021-05-04, Why 42? The lists account.  wrote:
> >
> > On Mon, May 03, 2021 at 12:59:27AM +0200, Patrick Wildt wrote:
> >> > ...
> >> > But when I do (as root): "sysctl kern.allowdt=1" it returns this error:
> >> > sysctl: kern.allowdt: Operation not permitted
> >> 
> >> Similarly to kern.allowkmem, you can only set it when the securelevel is
> >> still 'low'.  That's for security.  You need to add kern.allowdt=1 to
> >> sysctl.conf, and then reboot.  Then it'll be enabled after reboot.
> >
> > Thanks Patrick! After the reboot I was able to experiment with btrace.
> >
> > Do you use it, do you have any examples that might help to get started?
> 
> Here's one example:
> https://marc.info/?l=openbsd-bugs=158583371404603=2

That's exactly the one I use.  Though with varying hz (1-60)

Re: Q: dmesg: dt: 443 probes

[Patrick Wildt]

Am Sun, May 02, 2021 at 11:49:10PM +0200 schrieb Why 42? The lists account.:
> 
> Actually I do notice one thing, having just upgraded to:
> kern.version=OpenBSD 6.9-current (GENERIC.MP) #492: Sat May  1 17:37:28 MDT 
> 2021
> 
> I checked the output from dmesg and I have a new boot time message:
> dt: 443 probes
> 
> man dt tells me that dt is dynamic tracing and that I can enable it by
> setting kern.allowdt.
> 
> But when I do (as root): "sysctl kern.allowdt=1" it returns this error:
> sysctl: kern.allowdt: Operation not permitted

Similarly to kern.allowkmem, you can only set it when the securelevel is
still 'low'.  That's for security.  You need to add kern.allowdt=1 to
sysctl.conf, and then reboot.  Then it'll be enabled after reboot.

> What am I missing?
> 
> Cheers,
> Robb.
> 
> FYI: This is on an Intel NUC:
> bios0 at mainbus0: SMBIOS rev. 3.2 @ 0x7a9a4000 (77 entries)
> bios0: vendor Intel Corp. version "BECFL357.86A.0087.2020.1209.1115" date 
> 12/09/2020
> bios0: Intel(R) Client Systems NUC8i5BEH
> 

Re: gl.inet Brume (GL-MV1000): sdcard works with 6.8 but not -current

[Patrick Wildt]

Am Sun, Apr 04, 2021 at 11:32:10PM +0200 schrieb Mark Kettenis:
> > From: Darren Tucker 
> > Date: Sun, 4 Apr 2021 09:18:30 +1000
> > 
> > On Sun, 4 Apr 2021 at 01:32, Patrick Wildt  wrote:
> > 
> >  [...]
> >  Maybe you both can try my revert and make sure it doesn't introduce any
> >  other regressions?
> > 
> > That also seems to work on the Brume in question:
> 
> Works for the Turris MOX as well.
> 
> Do you want to commit the revert Darren?

Just committed it myself.  Sorry for the regression.

Re: gl.inet Brume (GL-MV1000): sdcard works with 6.8 but not -current

[Patrick Wildt]

Am Fri, Apr 02, 2021 at 12:56:24PM +1100 schrieb Darren Tucker:
> On Fri, Apr 02, 2021 at 01:01:30AM +0200, Mark Kettenis wrote:
> > Hi Darren,
> > 
> > This got broken when Patrick fixed something related to slow mode for
> > the Marvel ARMADA 8040 SoC.  The diff below fixes it for me on my
> > Turris MOX which uses the same SoC.  Not entirely sure what is going
> > wrong here since looking at the Linux code suggests that Patrick's fix
> > should work on the ARMADA 3720 as well.
> 
> Confirmed that this fixes it.  dmesg at end of mail.

Damn.  I'm sorry, it wasn't my intention to break anything with that.
As far as I remember, that particular change was an attempt to reduce
diff.  This one wasn't even needed to fix my ClearFog GT8K.

By the way, U-Boot always sets slow mode for legacy and high speed,
which is similar to what we had before.

I would actually propose reverting my change completely.  My GT 8K still
works, but even better: it seems to make the SD card show up on my early
revision MacchiatoBin.

-sdmmc1: can't enable card
 scsibus2 at sdmmc0: 2 targets, initiator 0
 sd1 at scsibus2 targ 1 lun 0:  removable
 sd1: 7456MB, 512 bytes/sector, 15269888 sectors
+scsibus3 at sdmmc1: 2 targets, initiator 0
+sd2 at scsibus3 targ 1 lun 0:  removable
+sd2: 7632MB, 512 bytes/sector, 15630336 sectors

Maybe you both can try my revert and make sure it doesn't introduce any
other regressions?

> > That BRUME thingy looks cute, but has a bit of an issue.  It doesn't
> > really have three Ethernet ports.  Instead those ports are part of a
> > switch that also connects to an Ethernet interface on the SoC.
> 
> Yeah I noticed that.  Single ethernet plus programmable switch seems to
> be pretty common in this class of device.

And if someone wants to program it, feel free to, mvsw(4) exists for a
reason, might just need some code. :)

diff --git a/sys/dev/fdt/sdhc_fdt.c b/sys/dev/fdt/sdhc_fdt.c
index 56bf15c46fa..cc0239df682 100644
--- a/sys/dev/fdt/sdhc_fdt.c
+++ b/sys/dev/fdt/sdhc_fdt.c
@@ -430,8 +430,8 @@ phy_init:
XENON_EMMC_PHY_TIMING_ADJUST);
reg |= XENON_EMMC_PHY_TIMING_ADJUST_SAMPL_INV_QSP_PHASE_SELECT;
reg &= ~XENON_EMMC_PHY_TIMING_ADJUST_SLOW_MODE;
-   if ((timing == SDMMC_TIMING_LEGACY ||
-   timing == SDMMC_TIMING_HIGHSPEED) && sc->sc_slow_mode)
+   if (timing == SDMMC_TIMING_LEGACY ||
+   timing == SDMMC_TIMING_HIGHSPEED || sc->sc_slow_mode)
reg |= XENON_EMMC_PHY_TIMING_ADJUST_SLOW_MODE;
bus_space_write_4(sc->sc_iot, sc->sc_ioh,
XENON_EMMC_PHY_TIMING_ADJUST, reg);

Re: IKEv2 on Windows 10

[Patrick Wildt]

Am Wed, Jan 13, 2021 at 01:12:09AM -0700 schrieb Ian Timothy:
> Hi,
> 
> I'm trying to get IKEv2 VPN working with Windows 10. I'm able to use PSK with 
> macOS without issue. Changing to EAP MSCHAP for use with Windows results in 
> the following error:
> 
> "The network connection between your computer and the VPN server could not be 
> established because the remote server is not responding. The could be because 
> one of the network devices (e.g. firewalls, NAT, routers, etc.) between your 
> computer and the remote server is not configured to allow VPN connections."
> 
> I’ve worked through many examples online, but I’m not sure what's the next 
> step to troubleshoot this?
> 
> Thanks!
> 
> 
> 
> # uname -rsv
> OpenBSD 6.8 GENERIC.MP#2
> 
> 
> #
> # iked.conf
> #
> 
> ikev2 "vpn-psk" passive esp \
>   from 0.0.0.0/0 to 0.0.0.0/0 \

Hi,

if you're using config address (as in giving peers a tunnel IP), you
need to configure

from 0.0.0.0/0 to 0.0.0.0 \

The "to" becomes a /32, a /0 is wrong.  This is because of internal
semantics.  Anyway, this confusing bit has been changed in -current,
as you can read here:

https://www.openbsd.org/faq/current.html

But unless you're using current, you still need the line above.

But since you're complaining about EAP MSCHAP, I don't know what's the
issue there.  Maybe tobhe@ or sthen@ have an idea.

Patrick

>   local egress peer any \
>   srcid vpn.company.com \
>   eap "mschap-v2" \
>   config address 10.0.2.0/24 \
>   config netmask 255.255.0.0 \
>   config name-server 10.0.0.1 \
>   tag "$name-$id" 
> 
> # Changing 'eap "mschap-v2"' to 'psk "password"' works just fine for macOS.
> 
> 
> #
> # Generate certificates
> #
> 
> pkg_add zip
> 
> ikectl ca vpn create
> ikectl ca vpn install
> 
> # CN should be same as srcid in iked.conf
> ikectl ca vpn certificate vpn.company.com create
> ikectl ca vpn certificate vpn.company.com install
> 
> # CN should be same as client ip address
> ikectl ca vpn certificate 10.0.2.100 create
> ikectl ca vpn certificate 10.0.2.100 export
> 
> 
> #
> # Windows config
> #
> 
> - VPN device
>- General tab
>   - Server: vpn.company.com
>- Security tab
>   - VPN type: IKEv2
>   - Authentication: Use machine certificates
> 
> - Certs install
>- ca.crt --> Certificates (Local Computer)/Trusted Root Certification 
> Authorities/Certificates
>- 10.0.2.100 --> Certificates (Local Computer)/Personal/Certificates
> 
> 
> #
> # iked log
> #
> 
> doas iked -dvv
> create_ike: using signature for peer 
> ikev2 "vpn-eap" passive tunnel esp inet from 0.0.0.0/0 to 0.0.0.0/0 local 
> 23.AAA.AAA.129 peer any ikesa enc aes-128-gcm,aes-256-gcm prf 
> hmac-sha2-256,hmac-sha2-384,hmac-sha2-512,hmac-sha1 group 
> curve25519,ecp521,ecp384,ecp256,modp4096,modp3072,modp2048,modp1536,modp1024 
> ikesa enc aes-256,aes-192,aes-128,3des prf 
> hmac-sha2-256,hmac-sha2-384,hmac-sha2-512,hmac-sha1 auth 
> hmac-sha2-256,hmac-sha2-384,hmac-sha2-512,hmac-sha1 group 
> curve25519,ecp521,ecp384,ecp256,modp4096,modp3072,modp2048,modp1536,modp1024 
> childsa enc aes-128-gcm,aes-256-gcm esn,noesn childsa enc 
> aes-256,aes-192,aes-128 auth 
> hmac-sha2-256,hmac-sha2-384,hmac-sha2-512,hmac-sha1 esn,noesn srcid 
> vpn.ipaperbox.com lifetime 10800 bytes 536870912 eap "MSCHAP_V2" config 
> address 10.0.2.0 config netmask 255.255.0.0 config name-server 10.0.0.1
> /etc/iked.conf: loaded 2 configuration rules
> ca_privkey_serialize: type RSA_KEY length 1192
> ca_pubkey_serialize: type RSA_KEY length 270
> config_new_user: inserting new user windows
> user "windows" "password"
> config_getpolicy: received policy
> ca_privkey_to_method: type RSA_KEY method RSA_SIG
> config_getpfkey: received pfkey fd 3
> ca_getkey: received private key type RSA_KEY length 1192
> config_getcompile: compilation done
> config_getsocket: received socket fd 4
> config_getsocket: received socket fd 5
> config_getsocket: received socket fd 6
> config_getsocket: received socket fd 7
> config_getstatic: dpd_check_interval 60
> config_getstatic: no enforcesingleikesa
> config_getstatic: no fragmentation
> config_getstatic: mobike
> config_getstatic: nattport 4500
> ca_getkey: received public key type RSA_KEY length 270
> ca_dispatch_parent: config reset
> ca_reload: loaded ca file ca.crt
> ca_reload: loaded crl file ca.crl
> ca_reload: /C=US/ST=State/L=City/O=Company Name/OU=Information 
> Systems/CN=vpn.company.com/emailAddress=t...@company.com
> ca_reload: loaded 1 ca certificate
> ca_reload: loaded cert file 10.0.0.1.crt
> ca_validate_cert: /C=US/ST=State/L=City/O=Company Name/OU=Information 
> Systems/CN=vpn.company.com/emailAddress=t...@company.com subject issuer 
> mismatch
> ca_reload: local cert type X509_CERT
> config_getocsp: ocsp_url none tolerate 0 maxage -1
> ikev2_dispatch_cert: updated local CERTREQ type X509_CERT length 20
> ikev2_dispatch_cert: updated local CERTREQ type X509_CERT length 20
> 
> policy_lookup: setting policy 'vpn-eap'
> 

Re: 4G mini PCI-e modem support?

[Patrick Wildt]

Am Fri, Jan 08, 2021 at 02:29:02PM + schrieb Peter Kay:
> There appear to be no 4G modem support at the moment, specifically a
> mini PCI-e one so I can stick it in a PC engines apu4d4 and have a
> backup connection.
> 
> Presuming a driver would need to be written, but just checking if I've
> missed anything?

There's umb(4).  It supports USB's MBIM standard.  There are some MBIM
compatible chips around, one for instance is this one:

https://www.varia-store.com/de/produkt/87272-simcom-sim7600e-h-mpcie-eu-lte-cat-4-modul.html

You'll probably need to switch it into MBIM mode once via a specific
AT-command over the serial, but otherwise it should do.

I'm sure there are plenty of other MBIM-compatible devices, this is just
the one from the top of my head.

Re: M2 SSD in a PCI-E adapter

[Patrick Wildt]

Am Fri, Jan 08, 2021 at 08:46:20AM -0700 schrieb Todd C. Miller:
> On Fri, 08 Jan 2021 16:19:02 +0100, Jan Stary wrote:
> 
> > I know the disk itself works: this is the disk plugged into
> > an M.2 slot in a Dell Latitude E5570 (full dmesg below):
> > sd0 at scsibus1 targ 0 lun 0:  
> > naa.5001b448b85325
> > 30
> > sd0: 238475MB, 512 bytes/sector, 488397168 sectors, thin
> 
> That is not an NVME SSD, it is an M.2 SATA SSD.  You need a different
> adaptor.
> 
>  - todd
> 

Yes, todd is right.  It's a M2 SATA SSD, but the Adapter will only
work with M2 NVMe SSDs.  So you might need a different adapter.  Some-
thing like these two could maybe work:

https://www.delock.de/produkte/1140_M-2/89388/merkmale.html
https://www.delock.de/produkte/1140_M-2/89379/merkmale.html

Both say "supports Key B+M on SATA basis" and both have active chipsets
which should be PCIe AHCI-compatible controller.

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: -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]

I committed an update to libunwind which made a major bump necessary.
Maybe I should have asked ports to run with the build first, so that
base and packages would be aligned.  Too late for that now.  Time will
fix it though.

Am Thu, Jan 07, 2021 at 09:54:39AM -0700 schrieb Steve Williams:
> 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.tgz    03-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: clock not set on boot

[Patrick Wildt]

On Sat, Dec 05, 2020 at 09:10:19PM +, Maurice McCarthy wrote:
> Perhaps add
> 
> ntpd_flags="-s"
> 
> to /etc/rc.conf.local
> 

-s doesn't exist anymore.

Re: PayPal pool for developer M1 Mac mini for OpenBSD port

[Patrick Wildt]

This really has shown how much interest there is in having OpenBSD
running on those machines.  Still, we would all not be here without
the OpenBSD project itself.  Not being able to host hackathons due to
COVID-19 leaves an impact, and I hope that soon(TM) we'll be able to
get back together to shut up and hack.

I'm sure you all love using OpenBSD and hacking on OpenBSD as much as I
do, so to help OpenBSD run infrastructure, organize hackathons and to
flourish even more, please consider donating!

https://www.openbsdfoundation.org/donations.html
https://www.openbsd.org/donations.html

Also a shoutout to marcan, who'll be doing a lot of reverse engineering
on the M1.  He's pretty good, and I'm supporting his project by being a
patron.  I'm looking forward to his work, because of all the people out
there who can do it, he's definitely one of them.

https://www.patreon.com/marcan

Patrick

Am Thu, Dec 03, 2020 at 02:33:34PM -0700 schrieb Ben Goren:
> Oh, wow — it hasn’t even been a full day since I sent this out...and already 
> enough of you have chipped in enough to buy not just a single M1 system for 
> Patrick, but also a second one for his partner in crime, Mark Kettenis.
> 
> Thank you to all! This show of generosity and support and excitement is most 
> welcome. (And, frankly, a bit overwhelming.)
> 
> If anybody reading this still wishes to donate to the cause, despite the 
> immediate needs being met, the money will be put to good use. There are other 
> developers who will eventually need their own hardware, and there are always 
> other sorts of expenses related to development. Feel free to chip in at 
> Patrick’s original link:
> 
> https://www.paypal.com/pools/c/8uPSkfNJMp
> 
> ...or, of course, to the OpenBSD general fund (which can *ALWAYS* use 
> donations):
> 
> https://www.openbsd.org/donations.html
> 
> Thanks again, everybody!
> 
> b&
> 
> > On Dec 2, 2020, at 2:59 PM, Ben Goren  wrote:
> > Greetings, all!
> > 
> > Patrick Wildt has set up a PayPal pool to raise funds to purchase an M1 Mac 
> > mini so he can start porting OpenBSD to the platform. If you’d like to be 
> > able to run OpenBSD on an M1 system, now would be a great time to throw 
> > some pennies his way.
> > 
> > The donation link: https://paypal.me/pools/c/8uPSkfNJMp
> > 
> > Read below for an idea of what one might expect if we can get a machine 
> > into Patrick’s hands.
> > 
> > Cheers,
> > 
> > b&
> > 
> > Patrick wrote:
> > 
> >> Yes, kettenis@ and me are the two ones doing the major work on porting
> >> to new devices.  Not sure if kettenis@ is interested, but I can ask him.
> >> I definitely am, a Mac Mini as a dedicated machine to do stuff with and
> >> not care about what is installed would really help.
> >> 
> >> Marcan has started a crowdfunding on Patreon.  He's a really capable
> >> person, and he'll definitely lay a lot of groundwork needed for porting
> >> OpenBSD to the platform.  He apparenetly will also do his work in a
> >> dual-licensed fashion, so the BSDs will easily profit from it.
> >> 
> >> So, the first steps are basically to follow Marcan's work and use all
> >> that information and code to port OpenBSD as well.
> >> 
> >> This *will* take some time, because essentially there are only the
> >> binary drivers, but it's doable and I think with a bit of patience
> >> we will have OpenBSD running on the M1 as well.
> >> 
> >> Biggest hurdle, as always, will be support for graphics acceleration.

Re: Snapshot crash on boot, "entry point at: 0x1001000" (Intel Gemini Lake)

[Patrick Wildt]

On Sun, Nov 08, 2020 at 06:30:25PM +0400, Michel von Behr wrote:
> Upgrading to snapshot did the trick - thanks for the great work!
> 
> FWIW, I still see a quick message "entry point at: ..." just blinking, but
> the system boots normally. There are a few devices not identified, most
> importantly the Touchpad (i.e., HTIX5288). Below is dmesg:

That message is *not* an error message.  It simply tells you where to
which address the bootloader will now jump.  I'd be concerned if it
didn't show up. ;)

> OpenBSD 6.8-current (GENERIC.MP ) #164: Thu Nov  5
> 15:11:03 MST 2020
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
> real mem = 8388608000 (8000MB)
> avail mem = 8119074816 (7742MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x7a01f000 (78 entries)
> bios0: vendor American Megatrends Inc. version "E.G140J.D8.E1.016.bin" date
> 11/29/2019
> bios0: Default string LapBook Pro
> acpi0 at bios0: ACPI 6.1
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP FPDT FIDT MSDM MCFG HPET LPIT APIC NPKT SSDT SSDT
> SSDT SSDT SSDT SSDT SSDT SSDT SSDT UEFI TPM2 DBGP DBG2 WDAT WSMT
> acpi0: wakeup devices LID0(S3) HDAS(S3) XHC_(S3) XDCI(S4) RP01(S4) PXSX(S4)
> RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4)
> RP06(S4) PXSX(S4)
> acpitimer0 at acpi0: 3579545 Hz, 32 bits
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xe000, bus 0-255
> acpihpet0 at acpi0: 1920 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Celeron(R) N4100 CPU @ 1.10GHz, 1097.34 MHz, 06-7a-01
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
> cpu0: 4MB 64b/line 16-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 19MHz
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Celeron(R) N4100 CPU @ 1.10GHz, 1096.97 MHz, 06-7a-01
> cpu1:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
> cpu1: 4MB 64b/line 16-way L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 4 (application processor)
> cpu2: Intel(R) Celeron(R) N4100 CPU @ 1.10GHz, 1096.97 MHz, 06-7a-01
> cpu2:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
> cpu2: 4MB 64b/line 16-way L2 cache
> cpu2: smt 0, core 2, package 0
> cpu3 at mainbus0: apid 6 (application processor)
> cpu3: Intel(R) Celeron(R) N4100 CPU @ 1.10GHz, 1096.97 MHz, 06-7a-01
> cpu3:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
> cpu3: 4MB 64b/line 16-way L2 cache
> cpu3: smt 0, core 3, package 0
> ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 120 pins
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (RP01)
> acpiprt2 at acpi0: bus -1 (RP02)
> acpiprt3 at acpi0: bus 1 (RP03)
> acpiprt4 at acpi0: bus -1 (RP04)
> acpiprt5 at acpi0: bus -1 (RP05)
> acpiprt6 at acpi0: bus -1 (RP06)
> acpiec0 at acpi0
> acpi0: GPE 0x26 already enabled
> glkgpio0 at acpi0 GPO3 uid 4 addr 0xd0c8/0x82f irq 14, 35 pins
> acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
> acpiac0 at acpi0: AC unit offline
> acpibat0 at acpi0: BAT0 model "Li-ion Battery" serial 00 type Lion oem "GLK
> MRD"
> acpibtn0 at acpi0: LID0
> "HTIX5288" at acpi0 not configured
> "ID9001" at acpi0 

Re: Anyone tried NanoPi R2S or a 2 LAN SBC?

[Patrick Wildt]

On Tue, Aug 18, 2020 at 09:59:29PM +0200, Dani Deni wrote:
> Hello,
> 
> trying to find a low powered single board computer with two gigabit LAN for
> router purposes.
> 
> already checked the https://www.openbsd.org/arm64.html page, but google
> doesn't brings up any arm64 based SBC with 2 gigabit network ports that
> OpenBSD supports.
> 
> or the NanoPi R2S can run OpenBSD? Anyone tried?
> 
> https://www.friendlyarm.com/index.php?route=product/product_id=282
> 
> 22$ ! cheap, low power usage and two gbit ethernet! It would be great if
> they wouldn't officially advert it with some custom OS :(

I have one, and I actually ordered a few more.  First thing you need is
U-Boot.  There is a patchset on the u-boot mailing lists.

The DTB part of that u-boot is good enough to boot, but I don't see the
USB show up.  I think for that we'd need to find another DTB.

Also, if you look through the lists, there's someone who already made it
work before.

The price itself isn't as nice anymore once you order it with a few
things, like case and... shipping costs.

Re: IKEDv2 and alias addresses

[Patrick Wildt]

On Fri, Jun 19, 2020 at 11:19:11AM -0400, Sonic wrote:
> With IKEDv1 I was able to use alias addresses for the VPN tunnels with
> a Listen-on directive in isakmpd.conf:
> ==
> [General]
> Listen-on=  1.2.3.7
> ==
> 
> So far my attempts with IKEDv2 have been unsuccessful at using alias
> addresses. Is it possible?
> 
> Thanks!
> 
> Chris

iked(8) listens on all addresses.  It binds on 0.0.0.0:500 and receives
all IKE messages that arrive, unless there's an isakmpd(8) runnin on the
same address.  Thus there's no need to specify an additional address,
because it's already listening on all addresses.

If you want to use a specific address for a policy, you can use the
"local" keyword to specify it.  This is part of the policy, not a global
option.

Then iked(8) continues to losten on 0.0.0.0:500, but the policy will
only match if the IP address match to the one specified as "local".

Patrick

Re: IKEv2 difference with 6.7

[Patrick Wildt]

On Tue, Jun 16, 2020 at 02:11:21PM -0400, Daniel Ouellet wrote:
> 
> 
> On 6/16/20 1:35 PM, Patrick Wildt wrote:
> > On Tue, Jun 16, 2020 at 01:09:32PM -0400, Daniel Ouellet wrote:
> >> Hi Tobias,
> >>
> >> I put below the full configuration and the flows as well with the 6.6
> >> binary and switch to the 6.7 binary without any other changes as well as
> >> the full config.
> >>
> >> The config may be a bit weird at first as I tunnel routable IP's over
> >> the iked over a Verizon Fios line. You can't get routable IP's from Fios
> >>  and I have needs for it. So that was my way around it for years now.
> >>
> >> Anyway, here below:
> >>
> >> gateway$ doas cat /etc/ipsec.conf
> >> flow esp out from ::/0 to ::/0 type deny
> >> flow esp from 66.63.44.64/27 to 66.63.44.96/28 type bypass
> >> flow esp from 66.63.44.96/28 to 66.63.44.64/27 type bypass
> >> flow esp from 66.63.44.67 to 66.63.44.97 type bypass
> >> flow esp from 66.63.44.90 to 66.63.44.97 type bypass
> >>
> >> (This above was to allow the two local subnet to take to one an other as
> >> they are in different dmz. I can delete that config and it changed
> >> nothing anyway. Just wanted to write why in case you wonder.)
> >>
> >> gateway$ doas cat /etc/iked.conf
> >> # All IP from 66.63.44.79 are Etienne computer to Riot on AS 6507 in
> >> Ashburn.
> >> ikev2 "VPN" active esp inet from re0 to tunnel.realconnect.com
> >>
> >> ikev2 "Flow" active \
> >> from re1 to tunnel.realconnect.com \
> >> from re1 to stats.realconnect.com \
> >> from 66.63.44.66 to 0.0.0.0/0 \
> >> from 66.63.44.67 to 66.63.0.0/18 \
> >> from home.ouellet.us to 0.0.0.0/0 \
> >> from 66.63.44.96/28 to 0.0.0.0/0 \
> >>from 66.63.44.79 to 43.229.64.0/22 \
> >>from 66.63.44.79 to 45.7.36.0/22 \
> >>from 66.63.44.79 to 103.240.224.0/22 \
> >>from 66.63.44.79 to 104.160.128.0/19 \
> >>from 66.63.44.79 to 162.249.72.0/21 \
> >>from 66.63.44.79 to 185.40.64.0/22 \
> >>from 66.63.44.79 to 192.64.168.0/21 \
> >> peer tunnel.realconnect.com
> >>
> >> (Here above for the 66.63.44.79, again a weird stuff, that's only for my
> >> older son. When he play LoL over Fios it suck! But when I tunnel it to
> >> my tunnel and then directly to Equinix where Riot is and I peer at, all
> >> is great and hard to believe I am sure, but latency is much lower. Again
> >> not relevant, just in case you wonder. I know, it's stupid, but I do a
> >> lots of work from home and I need to keep the family happy too. (;)
> >>
> >> On 6/16/20 6:09 AM, Tobias Heider wrote:
> >>> Hi Daniel,
> >>>
> >>> On Mon, Jun 15, 2020 at 08:04:43PM -0400, Daniel Ouellet wrote:
> >>>>> Probably related to the following change documented in
> >>>>> https://www.openbsd.org/faq/upgrade67.html:
> >>>>>
> >>>>> iked(8)/isakmpd(8). The type of incoming ipsec(4) flows installed by 
> >>>>> iked(8) or
> >>>>> isakmpd(8) was changed from "use" to "require". This means unencrypted 
> >>>>> traffic
> >>>>> matching the flows will no longer be accepted. Flows of type "use" can 
> >>>>> still be
> >>>>> set up manually in ipsec.conf(5). 
> >>>>
> >>>> I have what appear to be similar problem. I used iked form 5.6 all the
> >>>> way to 6.6 no problem, wel some, but I worked it out. All in archive.
> >>>>
> >>>> But going from 6.6 to 6.7 I can't get it to work anymore. Nothing
> >>>> changed, same configuration, just a sysupgrade and that's it.
> >>>>
> >>>> I read this and I can understand the words, but may be I am think, but I
> >>>> don't understand what to do with it.
> >>>
> >>> The default behavior if IPsec flows was changed to not accept unencrypted
> >>> packets matching a registered flow.
> >>> You can list your flows with 'ipsecctl -sf'.
> >>
> >> gateway$ doas ipsecctl -sf
> >> flow esp in from 0.0.0.0/0 to 66.63.44.66 peer 66.63.5.250 srcid
> >> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use
> >> flow esp in from 0.0.0.0/0 to 66.63.44.90 peer 66.63.5.250 srci

Re: IKEv2 difference with 6.7

[Patrick Wildt]

On Tue, Jun 16, 2020 at 01:09:32PM -0400, Daniel Ouellet wrote:
> Hi Tobias,
> 
> I put below the full configuration and the flows as well with the 6.6
> binary and switch to the 6.7 binary without any other changes as well as
> the full config.
> 
> The config may be a bit weird at first as I tunnel routable IP's over
> the iked over a Verizon Fios line. You can't get routable IP's from Fios
>  and I have needs for it. So that was my way around it for years now.
> 
> Anyway, here below:
> 
> gateway$ doas cat /etc/ipsec.conf
> flow esp out from ::/0 to ::/0 type deny
> flow esp from 66.63.44.64/27 to 66.63.44.96/28 type bypass
> flow esp from 66.63.44.96/28 to 66.63.44.64/27 type bypass
> flow esp from 66.63.44.67 to 66.63.44.97 type bypass
> flow esp from 66.63.44.90 to 66.63.44.97 type bypass
> 
> (This above was to allow the two local subnet to take to one an other as
> they are in different dmz. I can delete that config and it changed
> nothing anyway. Just wanted to write why in case you wonder.)
> 
> gateway$ doas cat /etc/iked.conf
> # All IP from 66.63.44.79 are Etienne computer to Riot on AS 6507 in
> Ashburn.
> ikev2 "VPN" active esp inet from re0 to tunnel.realconnect.com
> 
> ikev2 "Flow" active \
> from re1 to tunnel.realconnect.com \
> from re1 to stats.realconnect.com \
> from 66.63.44.66 to 0.0.0.0/0 \
> from 66.63.44.67 to 66.63.0.0/18 \
> from home.ouellet.us to 0.0.0.0/0 \
> from 66.63.44.96/28 to 0.0.0.0/0 \
>   from 66.63.44.79 to 43.229.64.0/22 \
>   from 66.63.44.79 to 45.7.36.0/22 \
>   from 66.63.44.79 to 103.240.224.0/22 \
>   from 66.63.44.79 to 104.160.128.0/19 \
>   from 66.63.44.79 to 162.249.72.0/21 \
>   from 66.63.44.79 to 185.40.64.0/22 \
>   from 66.63.44.79 to 192.64.168.0/21 \
> peer tunnel.realconnect.com
> 
> (Here above for the 66.63.44.79, again a weird stuff, that's only for my
> older son. When he play LoL over Fios it suck! But when I tunnel it to
> my tunnel and then directly to Equinix where Riot is and I peer at, all
> is great and hard to believe I am sure, but latency is much lower. Again
> not relevant, just in case you wonder. I know, it's stupid, but I do a
> lots of work from home and I need to keep the family happy too. (;)
> 
> On 6/16/20 6:09 AM, Tobias Heider wrote:
> > Hi Daniel,
> > 
> > On Mon, Jun 15, 2020 at 08:04:43PM -0400, Daniel Ouellet wrote:
> >>> Probably related to the following change documented in
> >>> https://www.openbsd.org/faq/upgrade67.html:
> >>>
> >>> iked(8)/isakmpd(8). The type of incoming ipsec(4) flows installed by 
> >>> iked(8) or
> >>> isakmpd(8) was changed from "use" to "require". This means unencrypted 
> >>> traffic
> >>> matching the flows will no longer be accepted. Flows of type "use" can 
> >>> still be
> >>> set up manually in ipsec.conf(5). 
> >>
> >> I have what appear to be similar problem. I used iked form 5.6 all the
> >> way to 6.6 no problem, wel some, but I worked it out. All in archive.
> >>
> >> But going from 6.6 to 6.7 I can't get it to work anymore. Nothing
> >> changed, same configuration, just a sysupgrade and that's it.
> >>
> >> I read this and I can understand the words, but may be I am think, but I
> >> don't understand what to do with it.
> > 
> > The default behavior if IPsec flows was changed to not accept unencrypted
> > packets matching a registered flow.
> > You can list your flows with 'ipsecctl -sf'.
> 
> gateway$ doas ipsecctl -sf
> flow esp in from 0.0.0.0/0 to 66.63.44.66 peer 66.63.5.250 srcid
> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use
> flow esp in from 0.0.0.0/0 to 66.63.44.90 peer 66.63.5.250 srcid
> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use
> flow esp in from 0.0.0.0/0 to 66.63.44.96/28 peer 66.63.5.250 srcid
> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use
> flow esp in from 43.229.64.0/22 to 66.63.44.79 peer 66.63.5.250 srcid
> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use
> flow esp in from 45.7.36.0/22 to 66.63.44.79 peer 66.63.5.250 srcid
> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use
> flow esp in from 66.63.0.0/18 to 66.63.44.67 peer 66.63.5.250 srcid
> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use
> flow esp in from 66.63.5.245 to 66.63.44.65 peer 66.63.5.250 srcid
> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use
> flow esp in from 66.63.5.250 to 66.63.44.65 peer 66.63.5.250 srcid
> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use
> flow esp in from 66.63.5.250 to 72.83.103.147 peer 66.63.5.250 srcid
> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use
> flow esp in from 103.240.224.0/22 to 66.63.44.79 peer 66.63.5.250 srcid
> FQDN/gateway.ouellet.us dstid FQDN/tunnel.realconnect.com type use
> flow esp in from 104.160.128.0/19 to 66.63.44.79 peer 66.63.5.250 srcid
> FQDN/gateway.ouellet.us dstid 

Re: uvideo0: can't find interface assoc descriptor

[Patrick Wildt]

On Sat, May 30, 2020 at 07:47:17PM +0200, Jan Stary wrote:
> On May 30 18:50:12, h...@stare.cz wrote:
> > This is current/amd64 on a MacBook2,1 (dmesg below)
> > With the latest upgrade, it has lost video0:
> > 
> > uvideo0 at uhub0 port 4 configuration 1 interface 0 "Micron Built-in 
> > iSight" rev 2.00/1.84 addr 2
> > uvideo0: can't find interface assoc descriptor
> 
> Similar thing happens with current/i386 on a MacBook1,1 (dmesg below):
> uvideo0: can't find video interface
> 
>   Jan

Yeah, this is due to the change to support multiple cameras in one
device.  You can try this diff, let me know if this works on both
of your machines.

Patrick

diff --git a/sys/dev/usb/uvideo.c b/sys/dev/usb/uvideo.c
index d33e3079acd..da00d0d3d0d 100644
--- a/sys/dev/usb/uvideo.c
+++ b/sys/dev/usb/uvideo.c
@@ -510,6 +510,8 @@ uvideo_attach(struct device *parent, struct device *self, 
void *aux)
int i;
 
sc->sc_udev = uaa->device;
+   sc->sc_iface = uaa->ifaceno;
+   sc->sc_nifaces = uaa->nifaces;
 
/* Find the first unclaimed video interface. */
for (i = 0; i < uaa->nifaces; i++) {
@@ -521,10 +523,8 @@ uvideo_attach(struct device *parent, struct device *self, 
void *aux)
if (id->bInterfaceClass == UICLASS_VIDEO)
break;
}
-   if (i == uaa->nifaces) {
-   printf("%s: can't find video interface\n", DEVNAME(sc));
-   return;
-   }
+   if (i == uaa->nifaces)
+   goto attach;
 
/* Find out which interface association we belong to. */
usbd_desc_iter_init(sc->sc_udev, );
@@ -540,30 +540,38 @@ uvideo_attach(struct device *parent, struct device *self, 
void *aux)
break;
desc = usbd_desc_iter_next();
}
-   if (desc == NULL) {
-   printf("%s: can't find interface assoc descriptor\n",
-   DEVNAME(sc));
-   return;
-   }
+   if (desc != NULL) {
+   /*
+* Claim all interfaces of our association.  Interfaces must be
+* claimed during attach, during attach hooks is too late.
+*/
+   for (i = iad->bFirstInterface;
+   i < iad->bFirstInterface + iad->bInterfaceCount; i++) {
+   if (usbd_iface_claimed(sc->sc_udev, i)) {
+   printf("%s: interface already claimed\n",
+   DEVNAME(sc));
+   return;
+   }
+   usbd_claim_iface(sc->sc_udev, i);
+   }
 
-   /*
-* Claim all interfaces of our association.  Interfaces must be
-* claimed during attach, during attach hooks is too late.
-*/
-   for (i = iad->bFirstInterface;
-   i < iad->bFirstInterface + iad->bInterfaceCount; i++) {
-   if (usbd_iface_claimed(sc->sc_udev, i)) {
-   printf("%s: interface already claimed\n",
-   DEVNAME(sc));
-   return;
+   /* Remember our association by saving the first interface. */
+   sc->sc_iface = iad->bFirstInterface;
+   sc->sc_nifaces = iad->bInterfaceCount;
+   } else {
+   /* No association, so simply claim them all. */
+   for (i = 0; i < uaa->nifaces; i++) {
+   if (usbd_iface_claimed(sc->sc_udev, i))
+   continue;
+   id = 
usbd_get_interface_descriptor(>sc_udev->ifaces[i]);
+   if (id == NULL)
+   continue;
+   if (id->bInterfaceClass == UICLASS_VIDEO)
+   usbd_claim_iface(sc->sc_udev, i);
}
-   usbd_claim_iface(sc->sc_udev, i);
}
 
-   /* Remember our association by saving the first interface. */
-   sc->sc_iface = iad->bFirstInterface;
-   sc->sc_nifaces = iad->bInterfaceCount;
-
+attach:
/* maybe the device has quirks */
sc->sc_quirk = uvideo_lookup(uaa->vendor, uaa->product);
 

Re: bwfm NVRAM file

[Patrick Wildt]

On Fri, Mar 13, 2020 at 12:12:18PM +0100, Rob Schmersel wrote:
> Hello,
> 
> In order to use a SDIO based bwfm device a "NVRAM" configuration file
> will be needed besides the firmware file. This configuration file is
> expected to be in the /etc/firmware directory, in the form of
>  brcmfmac{chip}-sdio.txt OR brcmfmac{chip}-sdio.nvram
> 
> The need for this configuration file is not described in the man page.
> However the device will not be usable without one and an error message
> will be shown in the dmesg:
>   "failed loadfirmware of file: brcmfmac{chip}-sdio.txt"
> 
> Can I suggest to below attached patch. 
> 
> I'm a bit unsure on how to indicate where the configuration file comes from:
> Under Linux it is recommended that you read the NVRAM contents from
> EFI, which I don't think is possible to do under OpenBSD
> 
> Hunting down the configuration file through your favorite search engine
> can be a frustrating excercise, although you can find them
> occasionally included in a windows driver or a linux distro.
> 
> Question: Are there plans to include the NVRAM files in bwfm_firmware
> package?

It all depends!  The NVRAM file is board-design-specific.  So, let's
assume OpenBSD and NetBSD would each build their own machine, using
the same chip and firmware.  The NVRAM file contains a configuration
for the chip, so that it e.g. can limit TX/antenna gain or whatever.
This is important for stuff like CE certification.  There are quite a
few settings, so it's very likely that the one board's chip needs a
different configuration than the other one's chip.

So where do we get this file?  If it's an x86-based machine, it's
likely they stored it as EFI variable.  In OpenBSD, so far only the
ARM ports support calling into the Runtime Services using efi(4).
Since we don't have support for efi(4) on x86, OpenBSD cannot read
the EFI variables.  For that you'll have to boot Linux, or some
other OS that has that feature.  On some other x86 machines, the
vendor might provide the file as part of a Windows firmware package.

Is it different on ARMs?  Well, yes, but not sure if worse or even
better.  The NVRAM file can usually be found on the vendor's Github.

linux-firmware.git has started collecting and distributing some of
the files.  So that will be a helpful source for us.  Otherwise we
will have to collect them ourselves.

For ARM there's still one commit left so that we can supply per-
board NVRAM files more easily.  In essence: We're working on it!

Patrick

Re: Solid-Run's HoneyComb LX2K for OpenBSD

[Patrick Wildt]

On Tue, Dec 10, 2019 at 10:25:57PM +1100, VanL wrote:
> 
> > How good are the chances of the 'HoneyComb LX2K' running OpenBSD?  [1]
> >
> > Footnotes: 
> > [1]  https://www.solid-run.com/nxp-lx2160a-family/honeycomb-workstation/
> 
> For future reference, the more specific place to ask is a...@openbsd.org
> and the places to see before asking are:
> 
>   https://ftp.openbsd.org/pub/OpenBSD/snapshots/arm64/INSTALL.arm64
>   https://ftp.openbsd.org/pub/OpenBSD/6.6/arm64/INSTALL.arm64
>   https://www.openbsd.org/arm64.html

I thought about buying one, but that SoC is from another architecture
team at NXP which means that we'd need to another stack of drivers just
to support the SoC used there.  Though with ACPI some things might get
easier.

So, as of now, I don't think there's a chance OpenBSD runs on that LX2K
hardware, unless someone from us gets such a machine and starts writing
support for it.

Patrick

Re: OpenBSD -current on T495

[Patrick Wildt]

On Sat, Nov 09, 2019 at 12:08:35PM +0100, Thomas de Grivel wrote:
> Everything works except wifi, suspend/resume and screen backlight, and
> mute speakers button.

Hi,

I have an X395 which is basically the same machine.

For Wifi I have temporarily replaced the Intel WiFi with a bwfm(4), the
Dell Wireless DW1820a (note the a), which has two antenna connectors.
There's the DW1830 which has three.  My X395 has two connectors, so I
just put in the DW1820a.  Both can be purchased cheaply on eBay.

The mute speaker button works for me, but the light doesn't show up.

I will try to have a look at suspend/resume at one of the next OpenBSD
hackathons.

For the screen backlight I have come up with a diff, but it's not yet
ready to be committed, as it should be done in a different fashion.
Still, I have attached the diff if you want to give it a go.

Patrick

diff --git a/sys/dev/acpi/acpivideo.c b/sys/dev/acpi/acpivideo.c
index 9498465a418..a46a99a67f7 100644
--- a/sys/dev/acpi/acpivideo.c
+++ b/sys/dev/acpi/acpivideo.c
@@ -149,7 +149,7 @@ acpi_foundvout(struct aml_node *node, void *arg)
if (node->parent != sc->sc_devnode)
return (0);
 
-   if (aml_searchname(node, "_BCM") && aml_searchname(node, "_BQC")) {
+   if (aml_searchname(node, "_BCM")) {
memset(, 0, sizeof(aaa));
aaa.aaa_iot = sc->sc_acpi->sc_iot;
aaa.aaa_memt = sc->sc_acpi->sc_memt;
diff --git a/sys/dev/acpi/acpivout.c b/sys/dev/acpi/acpivout.c
index 5fb6973f595..b1957b0c652 100644
--- a/sys/dev/acpi/acpivout.c
+++ b/sys/dev/acpi/acpivout.c
@@ -60,6 +60,7 @@ struct acpivout_softc {
 
int *sc_bcl;
size_t  sc_bcl_len;
+   int sc_bcl_cur;
 };
 
 void   acpivout_brightness_cycle(struct acpivout_softc *);
@@ -113,10 +114,16 @@ acpivout_attach(struct device *parent, struct device 
*self, void *aux)
aml_register_notify(sc->sc_devnode, aaa->aaa_dev,
acpivout_notify, sc, ACPIDEV_NOPOLL);
 
+   acpivout_get_bcl(sc);
+   if (!sc->sc_bcl_len)
+   return;
+
+   sc->sc_bcl_cur = sc->sc_bcl[sc->sc_bcl_len - 1];
+   sc->sc_bcl_cur = acpivout_get_brightness(sc);
+   acpivout_set_brightness(sc, sc->sc_bcl_cur);
+
ws_get_param = acpivout_get_param;
ws_set_param = acpivout_set_param;
-
-   acpivout_get_bcl(sc);
 }
 
 int
@@ -130,12 +137,15 @@ acpivout_notify(struct aml_node *node, int notify, void 
*arg)
break;
case NOTIFY_BRIGHTNESS_UP:
acpivout_brightness_step(sc, 1);
+   wsdisplay_change_brightness(1);
break;
case NOTIFY_BRIGHTNESS_DOWN:
acpivout_brightness_step(sc, -1);
+   wsdisplay_change_brightness(-1);
break;
case NOTIFY_BRIGHTNESS_ZERO:
acpivout_brightness_zero(sc);
+   wsdisplay_change_brightness(0);
break;
case NOTIFY_DISPLAY_OFF:
/* TODO: D3 state change */
@@ -200,7 +210,9 @@ acpivout_get_brightness(struct acpivout_softc *sc)
struct aml_value res;
int level;
 
-   aml_evalname(sc->sc_acpi, sc->sc_devnode, "_BQC", 0, NULL, );
+   if (aml_evalname(sc->sc_acpi, sc->sc_devnode, "_BQC", 0, NULL, ))
+   return sc->sc_bcl_cur;
+
level = aml_val2int();
aml_freevalue();
DPRINTF(("%s: BQC = %d\n", DEVNAME(sc), level));
@@ -242,6 +254,7 @@ acpivout_set_brightness(struct acpivout_softc *sc, int 
level)
aml_evalname(sc->sc_acpi, sc->sc_devnode, "_BCM", 1, , );
 
aml_freevalue();
+   sc->sc_bcl_cur = level;
 }
 
 void
diff --git a/sys/dev/pci/drm/amd/amdgpu/amdgpu_kms.c 
b/sys/dev/pci/drm/amd/amdgpu/amdgpu_kms.c
index 02a90069f8d..4bad51b7d5f 100644
--- a/sys/dev/pci/drm/amd/amdgpu/amdgpu_kms.c
+++ b/sys/dev/pci/drm/amd/amdgpu/amdgpu_kms.c
@@ -1656,7 +1656,7 @@ amdgpu_wsioctl(void *v, u_long cmd, caddr_t data, int 
flag, struct proc *p)
case WSDISPLAYIO_PARAM_BRIGHTNESS:
dp->min = 0;
dp->max = bd->props.max_brightness;
-   dp->curval = bd->ops->get_brightness(bd);
+   dp->curval = bd->props.brightness;
return (dp->max > dp->min) ? 0 : -1;
}
break;
diff --git a/sys/dev/wscons/wsdisplay.c b/sys/dev/wscons/wsdisplay.c
index 61ccd2dae43..eda5c9d8843 100644
--- a/sys/dev/wscons/wsdisplay.c
+++ b/sys/dev/wscons/wsdisplay.c
@@ -3369,3 +3369,43 @@ mouse_remove(struct wsscreen *scr)
 }
 
 #endif /* HAVE_WSMOUSED_SUPPORT */
+
+int
+wsdisplay_change_brightness(int dir)
+{
+   struct wsdisplay_softc *sc;
+   struct wsdisplay_param dp;
+   int step, ret;
+
+   sc = (struct wsdisplay_softc *)device_lookup(_cd, 0);
+   if (sc == NULL)
+   return ENODEV;
+
+   memset(, 0, sizeof(dp));
+   dp.param = WSDISPLAYIO_PARAM_BRIGHTNESS;
+   ret = 

Re: Broadcom firmwares and nvram files

[Patrick Wildt]

On Sun, Nov 03, 2019 at 10:05:38AM +0100, Patrick Wildt wrote:
> On Sun, Nov 03, 2019 at 12:08:08AM +0100, Stefano Enrico Mendola wrote:
> > Hi,
> > 
> > my bad, I thought the grepped output was enough.
> > Here's the complete dmesg(8) output. =
> > OpenBSD 6.6 (GENERIC.MP) #372: Sat Oct 12 10:56:27 MDT 2019
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > real mem = 2056568832 (1961MB)
> > avail mem = 1981595648 (1889MB)
> > mpath0 at root
> > scsibus0 at mpath0: 256 targets
> > mainbus0 at root
> > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7c31a010 (16 entries)
> > bios0: vendor American Megatrends Inc. version "X205TA.212" date
> > 09/04/2015
> > bios0: ASUSTeK COMPUTER INC. X205TA
> > acpi0 at bios0: ACPI 5.0
> > acpi0: sleep states S0 S5
> > acpi0: tables DSDT FACP TCPA UEFI OEM0 DBG2 HPET LPIT APIC MCFG SSDT SSDT
> > SSDT SSDT FPDT SSDT SSDT SSDT SSDT TPM2 BGRT CSRT MSDM
> > acpi0: wakeup devices WLAN(S0)
> > acpihpet0 at acpi0: 14318179 Hz
> > acpimadt0 at acpi0 addr 0xfee0
> > cpu0 at mainbus0: apid 0 (boot processor)
> > cpu0: Intel(R) Atom(TM) CPU Z3735F @ 1.33GHz, 1333.58 MHz, 06-37-08
> > cpu0:
> > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
> > cpu0: 1MB 64b/line 16-way L2 cache
> > cpu0: smt 0, core 0, package 0
> > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> > cpu0: apic clock running at 83MHz
> > cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE
> > cpu1 at mainbus0: apid 2 (application processor)
> > cpu1: Intel(R) Atom(TM) CPU Z3735F @ 1.33GHz, 1333.33 MHz, 06-37-08
> > cpu1:
> > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
> > cpu1: 1MB 64b/line 16-way L2 cache
> > cpu1: smt 0, core 1, package 0
> > cpu2 at mainbus0: apid 4 (application processor)
> > cpu2: Intel(R) Atom(TM) CPU Z3735F @ 1.33GHz, 1333.34 MHz, 06-37-08
> > cpu2:
> > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
> > cpu2: 1MB 64b/line 16-way L2 cache
> > cpu2: smt 0, core 2, package 0
> > cpu3 at mainbus0: apid 6 (application processor)
> > cpu3: Intel(R) Atom(TM) CPU Z3735F @ 1.33GHz, 1333.34 MHz, 06-37-08
> > cpu3:
> > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
> > cpu3: 1MB 64b/line 16-way L2 cache
> > cpu3: smt 0, core 3, package 0
> > ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 87 pins, remapped
> > acpimcfg0 at acpi0
> > acpimcfg0: addr 0xe000, bus 0-255
> > acpiprt0 at acpi0: bus 0 (PCI0)
> > acpiec0 at acpi0: not present
> > acpicpu0 at acpi0: C3(10@1000 mwait.1@0x64), C2(10@500 mwait.1@0x51),
> > C1(1000@1 mwait.1), PSS
> > acpicpu1 at acpi0: C3(10@1000 mwait.1@0x64), C2(10@500 mwait.1@0x51),
> > C1(1000@1 mwait.1), PSS
> > acpicpu2 at acpi0: C3(10@1000 mwait.1@0x64), C2(10@500 mwait.1@0x51),
> > C1(1000@1 mwait.1), PSS
> > acpicpu3 at acpi0: C3(10@1000 mwait.1@0x64), C2(10@500 mwait.1@0x51),
> > C1(1000@1 mwait.1), PSS
> > acpipwrres0 at acpi0: PLPE
> > acpipwrres1 at acpi0: USBC, resource for XHC1, EHC1, OTG1
> > acpipwrres2 at acpi0: CLK0, resource for CAM1
> > acpipwrres3 at acpi0: CLK1, resource for CAM0
> > acpipwrres4 at acpi0: P28X
> > acpipwrres5 at acpi0: P18X
> > acpipwrres6 at acpi0: P28P
> > acpipwrres7 at acpi0: P18P
> > acpipwrres8 at acpi0: P28T, resource for CAM0, CAM1
> > acpipwrres9 at acpi0: P18T, resource for CAM0, CAM1
> > acpipwrres10 at acpi0: P1XT
> > acpitz0 at acpi0: no critical temperature

Re: Broadcom firmwares and nvram files

[Patrick Wildt]

On Sun, Nov 03, 2019 at 12:08:08AM +0100, Stefano Enrico Mendola wrote:
> Hi,
> 
> my bad, I thought the grepped output was enough.
> Here's the complete dmesg(8) output. =
> OpenBSD 6.6 (GENERIC.MP) #372: Sat Oct 12 10:56:27 MDT 2019
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 2056568832 (1961MB)
> avail mem = 1981595648 (1889MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7c31a010 (16 entries)
> bios0: vendor American Megatrends Inc. version "X205TA.212" date
> 09/04/2015
> bios0: ASUSTeK COMPUTER INC. X205TA
> acpi0 at bios0: ACPI 5.0
> acpi0: sleep states S0 S5
> acpi0: tables DSDT FACP TCPA UEFI OEM0 DBG2 HPET LPIT APIC MCFG SSDT SSDT
> SSDT SSDT FPDT SSDT SSDT SSDT SSDT TPM2 BGRT CSRT MSDM
> acpi0: wakeup devices WLAN(S0)
> acpihpet0 at acpi0: 14318179 Hz
> acpimadt0 at acpi0 addr 0xfee0
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Atom(TM) CPU Z3735F @ 1.33GHz, 1333.58 MHz, 06-37-08
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
> cpu0: 1MB 64b/line 16-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 83MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Atom(TM) CPU Z3735F @ 1.33GHz, 1333.33 MHz, 06-37-08
> cpu1:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
> cpu1: 1MB 64b/line 16-way L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 4 (application processor)
> cpu2: Intel(R) Atom(TM) CPU Z3735F @ 1.33GHz, 1333.34 MHz, 06-37-08
> cpu2:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
> cpu2: 1MB 64b/line 16-way L2 cache
> cpu2: smt 0, core 2, package 0
> cpu3 at mainbus0: apid 6 (application processor)
> cpu3: Intel(R) Atom(TM) CPU Z3735F @ 1.33GHz, 1333.34 MHz, 06-37-08
> cpu3:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
> cpu3: 1MB 64b/line 16-way L2 cache
> cpu3: smt 0, core 3, package 0
> ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 87 pins, remapped
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xe000, bus 0-255
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiec0 at acpi0: not present
> acpicpu0 at acpi0: C3(10@1000 mwait.1@0x64), C2(10@500 mwait.1@0x51),
> C1(1000@1 mwait.1), PSS
> acpicpu1 at acpi0: C3(10@1000 mwait.1@0x64), C2(10@500 mwait.1@0x51),
> C1(1000@1 mwait.1), PSS
> acpicpu2 at acpi0: C3(10@1000 mwait.1@0x64), C2(10@500 mwait.1@0x51),
> C1(1000@1 mwait.1), PSS
> acpicpu3 at acpi0: C3(10@1000 mwait.1@0x64), C2(10@500 mwait.1@0x51),
> C1(1000@1 mwait.1), PSS
> acpipwrres0 at acpi0: PLPE
> acpipwrres1 at acpi0: USBC, resource for XHC1, EHC1, OTG1
> acpipwrres2 at acpi0: CLK0, resource for CAM1
> acpipwrres3 at acpi0: CLK1, resource for CAM0
> acpipwrres4 at acpi0: P28X
> acpipwrres5 at acpi0: P18X
> acpipwrres6 at acpi0: P28P
> acpipwrres7 at acpi0: P18P
> acpipwrres8 at acpi0: P28T, resource for CAM0, CAM1
> acpipwrres9 at acpi0: P18T, resource for CAM0, CAM1
> acpipwrres10 at acpi0: P1XT
> acpitz0 at acpi0: no critical temperature defined
> "INT3396" at acpi0 not configured
> bytgpio0 at acpi0: GPO2 uid 3 addr 0xfed0e000/0x1000 irq 50, 44 pins
> bytgpio1 at acpi0: GPO0 uid 1 addr 0xfed0c000/0x1000 irq 49, 102 pins
> dwiic0 at acpi0 I2C5 addr 0x90932000/0x1000 irq 36
> iic0 at dwiic0
> tipmic0 at iic0 addr 0x5e irq 67
> bytgpio2 at acpi0: GPO1 uid 2 addr 0xfed0d000/0x1000 irq 48, 28 pins
> "80860F0A" at acpi0 not configured
> dwiic1 at acpi0 I2C1 addr 0x9091a000/0x1000 irq 32
> iic1 at dwiic1
> ihidev0 at iic1 addr 0x68 irq 71, vendor 0xb05 product 0x8585, PDEC3393
> ihidev0: 9 report ids
> ikbd0 at ihidev0 reportid 1: 8 variable keys, 6 key codes
> wskbd0 at ikbd0 mux 1
> hid at ihidev0 

Re: syspatch Octeon and arm64 alternatives

[Patrick Wildt]

On Wed, Jul 17, 2019 at 02:32:22PM -0400, Predrag Punosevac wrote:
> Hi Misc,
> 
> Are there any plans to build syspathes for Octeon platform in the
> future? Octeon platform has matured nicely since the introduction in
> 2013 and is becoming my goto platform for SOHO environments. Apart of
> the lack of hardware clocks the main nuisance is the lack of binary
> patches. 
> 
> 
> I know that arm64 is vigorously developed and I do have few ROCK64
> boards but is there a consumer grade network hardware built on the top
> of arm64? Can one run OpenBSD on something like SG-1100
> 
> https://www.netgate.com/solutions/pfsense/sg-1100.html
> 
> and how does it compare to edgerouter 4
> 
> https://www.ui.com/edgemax/edgerouter-4/
> 
> Thanks,
> Predrag
> 

Hi,

the SG-1100 is using the same SoC as the Turris Mox, which I intend
to support.  I recently received mine.  As long as the SG-1100 uses
a recent (as in 2017/2018) U-Boot it should be possible to support
that hardware once the Turris Mox support got better.

That said, I would assume that the USB 3.0 ports work already and the
the WAN port should do as well.  The eMMC is not yet supported.  If I
had one I could have a look.

Patrick

Re: IPsec performance regression between 6.3 and 6.4

[Patrick Wildt]

Hi,

we recently found that the switch to constant-time AES has quite a heavy
impact on IPsec performance.  But since according to CVS that was part
of OpenBSD 6.2 already, it's probably something else.

https://github.com/openbsd/src/commit/d223d7cb85c1f2f705da547a0134b949655abe6a

Patrick

On Wed, Jul 17, 2019 at 12:26:31PM +, pierre1.bar...@orange.com wrote:
> Hello,
> 
> I'm currently doing some IPsec performance testing between OpenBSD 6.3 and 
> 6.5.
> Dmesg and ipsec.conf is below for information.
> 
> Testing with iperf3 and 1500B packets, throughput drops around 1/3, from 919 
> Mbps to 623 Mbps.
> I also tried 6.4, which has similar perfomance to 6.5.
> I went through plus64.html without finding a change that could explain this.
> 
> 
> Could someone explain me what caused such a performance drop ?
> Is there any solutions or plans to get the original performance back ?
> 
> Thank you
> 
> 
> root@bsdWAN ~ # cat /etc/ipsec.conf
> # Conf transport
> ike esp transport proto gre \
>   from 192.168.3.254 to 192.168.3.1 peer 192.168.3.1 \
>   main auth hmac-sha2-256 enc aes-256 group modp1024 lifetime 86400 \
>   quick auth hmac-sha2-256 enc aes-256 group modp1024 lifetime 28800 \
>   psk "mekmitasdigoat"
> 
> root@bsdWAN ~ # dmesg
> OpenBSD 6.5 (GENERIC.MP) #2: Tue May 14 10:19:35 UTC 2019
> root@openbsd65.local:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 8395776000 (8006MB)
> avail mem = 8131694592 (7754MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x8ef68000 (45 entries)
> bios0: vendor Dell Inc. version "1.4.5" date 08/09/2016
> bios0: Dell Inc. PowerEdge R330
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S5
> acpi0: tables DSDT FACP BOOT SSDT SLIC HPET LPIT APIC MCFG WDAT SSDT DBGP 
> DBG2 SSDT SSDT SSDT SSDT SSDT SSDT PRAD HEST BERT ERST EINJ DMAR FPDT
> acpi0: wakeup devices PEGP(S0) PEG0(S0) PEGP(S0) PEG1(S0) PEGP(S0) PEG2(S0) 
> XHC_(S0) XDCI(S0) PXSX(S0) RP01(S0) PXSX(S0) RP02(S0) PXSX(S0) RP03(S0) 
> PXSX(S0) RP04(S0) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpihpet0 at acpi0: 2399 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Xeon(R) CPU E3-1220 v5 @ 3.00GHz, 3293.54 MHz, 06-5e-03
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 24MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Xeon(R) CPU E3-1220 v5 @ 3.00GHz, 3292.34 MHz, 06-5e-03
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 4 (application processor)
> cpu2: Intel(R) Xeon(R) CPU E3-1220 v5 @ 3.00GHz, 3292.34 MHz, 06-5e-03
> cpu2: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
> cpu2: 256KB 64b/line 8-way L2 cache
> cpu2: smt 0, core 2, package 0
> cpu3 at mainbus0: apid 6 (application processor)
> cpu3: Intel(R) Xeon(R) CPU E3-1220 v5 @ 3.00GHz, 3292.34 MHz, 06-5e-03
> cpu3: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
> cpu3: 256KB 64b/line 8-way L2 cache
> cpu3: smt 0, 

Re: bwfm bcm43569

[Patrick Wildt]

On Tue, Jun 25, 2019 at 12:06:51AM +0300, 3 wrote:
> i know that wifi adapters never worked in obsd(excluding those
> adapters for which drivers were written by vendors), but i found one
> that shows signs of life in 11n(11ac 2t2r supported by chip). it can
> be bought anywhere where there are samsung tv. moreover it even works
> in hostap mode(unlike the buggy athn).
> but without a ton of bugs not done:
> bwfm0: could not read register: TIMEOUT
> bwfm0: could not open rx pipe: IN_USE
> bwfm0: could not init bus
> bwfm0: firmware did not start up
> .and sometimes kernel panic on boot, but works would still!
> meet https://wikidevi.com/wiki/Samsung_WCH730B
> bwfm0 at uhub0 port 1 configuration 1 interface 0 "Broadcom BCMUSB 802.11 
> Wireless Adapter" rev 2.10/0.01 addr 2
> photo without cover: http://pichost.org/images/2019/06/24/Untitled-138.jpg 
> it is shown where to solder the wires for wifi. on the right through
> two pins(ground is first) is bluetooth, but for obsd this does not
> matter(thx theo).  
> data sheet for chip: https://www.cypress.com/file/310246/download

Did you solder that yourself?  As long as nothing has changed, bwfm(4)
on USB worked fine with the one USB one that I had:  The official
raspberry Pi USB WiFi stick that they sold before they put the WiFi
chip onto the board itself.  I wouldn't blame that on the driver.
Did you try the stick with Linux?  If it works with Linux then maybe
it's my fault after all.

Patrick

Re: Lenovo w/ AMD Ryzen CPU

[Patrick Wildt]

I'd love to have one as well...

On Tue, May 28, 2019 at 11:16:51AM -0600, Theo de Raadt wrote:
> I am hoping to get one also... and as a rule whatever I get my hands on tends 
> to work out well.
> 
> danieljb...@icloud.com wrote:
> 
> > I just ordered some E495s (not 'T', but pretty similar). I think
> > they're supposed to arrive today. I'll do a test boot and send in a
> > dmesg.
> > 
> > On Tue, May 28, 2019 at 10:44:44AM -0400, David Anthony wrote:
> > > All,
> > > 
> > > The Lenovo release of T*95 series laptops with AMD Ryzen CPU appears 
> > > imminent. 
> > > 
> > > Would these be poor choices for OpenBSD? Are there any anticipated 
> > > ???gotchas??? that I should be aware of? Any thoughts would be greatly 
> > > appreciated.
> > > 
> > > Respectfully,
> > > David Anthony
> > > 
> > 
> 

Re: Installer doesn't see sd0 on qemu guest 6.5-current

[Patrick Wildt]

As you can see in dmesg, it actually sees sd0, and it does not detach.
Instead, the device node just isn't in /dev, because the insaller does
create that on the fly.  Since you are not using the installer, you
have to manually type cd /dev && sh MAKEDEV sd0

On Sat, Jun 01, 2019 at 09:08:58PM +0300, Maksym Sheremet wrote:
> There is a 6.5-current VM running with QEMU on linux host. Usually the
> VM is being updated to the latest snapshot once per 10 days. Everything
> was OK with with 2019-04-21 snapshot. The problem has been appeared
> since 2019-05-01 snapshot.
> 
> The VM is installed on a dedicated drive with FDE. It is detected as sd0
> by bsd.rd booted from install65.iso. But once installer is started the
> drive disappears. Here is full output:
> 
> >> OpenBSD/amd64 CDBOOT 3.43
> boot> 
> cannot open cd0a:/etc/random.seed: No such file or directory
> booting cd0a:/6.5/amd64/bsd.rd: 3691345+1532928+3889096+0+598016
> [373454+128+451752+300829]=0xa58318
> entry point at 0x81001000
> Copyright (c) 1982, 1986, 1989, 1991, 1993
>  The Regents of the University of California.  All rights reserved.
> Copyright (c) 1995-2019 OpenBSD. All rights reserved.
>  https://www.OpenBSD.org
> 
> OpenBSD 6.5-current (RAMDISK_CD) #50: Fri May 31 20:22:49 MDT 2019
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
> real mem = 2130558976 (2031MB)
> avail mem = 2062069760 (1966MB)
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5b10 (9 entries)
> bios0: vendor SeaBIOS version "1.12.0-20181126_142135-anatol"
> date 04/01/2014
> bios0: QEMU Standard PC (i440FX + PIIX, 1996)
> acpi0 at bios0: rev 0
> acpi0: tables DSDT FACP APIC
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: QEMU Virtual CPU version 2.5+, 2295.00 MHz, 06-06-03
> cpu0:
> FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,x2APIC,HV,NXE,LONG,LAHF,MELTDOWN
> cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
> 64b/line 16-way L2 cache
> cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
> cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
> cpu0: apic clock running at 1000MHz
> ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpicpu at acpi0 not configured
> "ACPI0006" at acpi0 not configured
> "PNP0A03" at acpi0 not configured
> acpicmos0 at acpi0
> "PNP0A06" at acpi0 not configured
> "PNP0A06" at acpi0 not configured
> "PNP0A06" at acpi0 not configured
> "QEMU0002" at acpi0 not configured
> "ACPI0010" at acpi0 not configured
> pvbus0 at mainbus0: KVM
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
> "Intel 82371SB ISA" rev 0x00 at pci0 dev 1 function 0 not configured
> pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA,
> channel 0 wired to compatibility, channel 1 wired to compatibility
> pciide0: channel 0 disabled (no drives)
> pciide0: channel 1 disabled (no drives)
> uhci0 at pci0 dev 1 function 2 "Intel 82371SB USB" rev 0x01: apic 0
> int 11
> "Intel 82371AB Power" rev 0x03 at pci0 dev 1 function 3 not configured
> vga1 at pci0 dev 2 function 0 "Bochs VGA" rev 0x02
> vga1: aperture needed
> wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation)
> virtio0 at pci0 dev 3 function 0 "Qumranet Virtio Network" rev 0x00
> vio0 at virtio0: address 08:00:27:77:c1:d5
> virtio0: msix shared
> virtio1 at pci0 dev 5 function 0 "Qumranet Virtio Storage" rev 0x00
> vioblk0 at virtio1
> scsibus0 at vioblk0: 2 targets
> sd0 at scsibus0 targ 0 lun 0:  SCSI3 0/direct
> fixed
> sd0: 114473MB, 512 bytes/sector, 234441632 sectors
> virtio1: msix shared
> virtio2 at pci0 dev 6 function 0 "Qumranet Virtio Memory Balloon" rev
> 0x00
> virtio2: no matching child driver; not configured
> ahci0 at pci0 dev 7 function 0 "Intel 82801I AHCI" rev 0x02: apic 0
> int 11, AHCI 1.0
> ahci0: port 0: 1.5Gb/s
> scsibus1 at ahci0: 32 targets
> cd0 at scsibus1 targ 0 lun 0:  ATAPI 5/cdrom
> removable
> usb0 at uhci0: USB revision 1.0
> uhub0 at usb0 configuration 1 interface 0 "Intel UHCI root hub" rev
> 1.00/1.00 addr 1
> isa0 at mainbus0
> com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> com0: console
> pckbc0 at isa0 port 0x60/5 irq 1 irq 12
> pckbd0 at pckbc0 (kbd slot)
> wskbd0 at pckbd0: console keyboard, using wsdisplay1
> softraid0 at root
> scsibus2 at softraid0: 256 targets
> root on rd0a swap on rd0b dump on rd0b
> erase ^?, werase ^W, kill ^U, intr ^C, status ^T
> 
> Welcome to the OpenBSD/amd64 6.5 installation program.
> (I)nstall, (U)pgrade, (A)utoinstall or (S)hell? s
> # bioctl -c C -l /dev/sd0a softraid0
> bioctl: could not open /dev/sd0a: No such file or directory
> # ls /dev
> MAKEDEV cua01   klogrcd0c   rrd0c   rwd0g   rwd0o   ttyC0   wd0gwd0o
> bio diskmap kmemrd0arst0rwd0h   rwd0p   urandom wd0hwd0p
> bpf enrst0  

Re: Duplicity & /etc/daily.local

[Patrick Wildt]

On Mon, May 20, 2019 at 11:50:13PM +0200, Noth wrote:
> Hi misc@,
> 
> 
>   I'm trying to run daily backups to a sftp server for various VMs and
> devices on my network, and want to use /etc/daily.local for this. I'm
> calling this script from the daily.local file:
> 
> env 'GNUPG="/usr/local/bin/gpg" PASSPHRASE="mypassword"'
> /root/duplicity-hostname.sh
> 
> but unfortunately duplicity can't find gnupg and errors out with this error
> message:
> 
> Traceback (innermost last):
>   File "/usr/local/bin/duplicity", line 1562, in 
> with_tempdir(main)
>   File "/usr/local/bin/duplicity", line 1548, in with_tempdir
> fn()
>   File "/usr/local/bin/duplicity", line 1387, in main
> action = commandline.ProcessCommandLine(sys.argv[1:])
>   File "/usr/local/lib/python2.7/site-packages/duplicity/commandline.py", 
> line 1088, in ProcessCommandLine
> globals.gpg_profile = gpg.GPGProfile()
>   File "/usr/local/lib/python2.7/site-packages/duplicity/gpg.py", line 92, in 
> __init__
> self.gpg_version = self.get_gpg_version(globals.gpg_binary)
>   File "/usr/local/lib/python2.7/site-packages/duplicity/gpg.py", line 107, 
> in get_gpg_version
> res = gnupg.run(["--version"], create_fhs=["stdout"])
>   File "/usr/local/lib/python2.7/site-packages/duplicity/gpginterface.py", 
> line 374, in run
> create_fhs, attach_fhs)
>   File "/usr/local/lib/python2.7/site-packages/duplicity/gpginterface.py", 
> line 423, in _attach_fork_exec
> self._as_child(process, gnupg_commands, args)
>   File "/usr/local/lib/python2.7/site-packages/duplicity/gpginterface.py", 
> line 462, in _as_child
> os.execvp(command[0], command)
>   File "/usr/local/lib/python2.7/os.py", line 346, in execvp
> _execvpe(file, args)
>   File "/usr/local/lib/python2.7/os.py", line 382, in _execvpe
> func(fullname, *argrest)
>  OSError: [Errno 2] No such file or directory
> 
> GPGError: failed to determine gnupg version of None from
> 
> 
> duplicity-hostname.sh content:
> 
> #!/bin/ksh
> PASSPHRASE=mypassword
> /usr/local/bin/duplicity incremental /var sftp://user@backuphost:/hostname/var
> /usr/local/bin/duplicity incremental /etc sftp://user@backuphost:/hostname/etc
> /usr/local/bin/duplicity incremental /root 
> sftp://user@backuphost:/hostname/root
> 
> Can daily.local even handle this or is the environment too limited?
> 
> Cheers,
> 
> Noth
> 

I have the same setup and it failed for me as well.  I somehow managed
to fix it by setting PATH and also exporting TERM:

PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games
TERM=xterm
export PATH TERM

And you should probably also do something like:

. /root/.passphrase
test -n "$PASSPHRASE" || exit 0
export PASSPHRASE

Patrick

Re: I am sorry

[Patrick Wildt]

On Mon, Feb 04, 2019 at 12:52:48PM -0800, Chris Cappuccio wrote:
> Leonid Bobrov [mazoc...@disroot.org] wrote:
> > Hi, dear OpenBSD community.
> > 
> > Please forgive me for drama I made earlier at mailing list and
> > IRC channel. I am not a troll, I promise, I want to contribute to
> > OpenBSD in any way I can, please give me a chance.
> > 
> 
> This is the internet. Nobody remembers or cares.
> 
> > All this time I had a depression and recently I've visited a doctor
> > and now I am taking tranquilizer and antidepressant pills and feel
> > myself much better, tomorrow I am going to visit a doctor once more.
> > 
> 
> Throw 'em away. Wear your flag proud. 
> 
> > I am sorry for all offending words I told you, I am sorry for yelling
> > at you, I admit I was wrong. I was very desperate and anxious.
> 
> Recant your apology! Double down!!
> 

That sounds rather negative.  In case it's true I'm happy he gets some
treatment for a serious condition.  Let's hope it lets him live a happy
life.

Re: Need an advice: Raspberry Pi3 B+ or Pine64 ROCK64

[Patrick Wildt]

On Mon, Aug 27, 2018 at 01:49:47PM +0200, Karel Gardas wrote:
> On Sun, 26 Aug 2018 15:52:48 +0200
> Patrick Wildt  wrote:
> 
> > On the MacchiatoBin we don't support the onboard ethernet yet.  On the
> > EspressoBin we do support the ethernet controller, but the connected
> > switch is a mess that I don't dare to support.  Got other stuff to do.
> > Though I am working on partial EspressoBin support for the upcoming
> > Turris Mox.
> 
> What do you plan to support on Mox? Just basic module? If so, do you plan to 
> support USB too so one can at least connect second NIC over USB? I see CZ.NIC 
> does not make module with just another NIC and if you claim switch is a mess 
> I'm curious how to make from this a router with >1NIC.
> 
> Thanks!
> Karel

I pledged for the basic module, module B (mPCIe) and module D (SFP).
The SoC actually has 2x Gigabit Ethernet NICs.  I figure they will use
the first NIC for the basic module Ethernet and the other NIC will be
connected to the SGMII line that runs over the connector.  So in my
setup I will have the SFP slot connected to the second NIC.

Their C and E modules provide further ports using a managed switch.
Using that one as a dumb switch should be possible, but dynamically
configuring port groups on the switch is something that we have no
support for at the moment.  You might be able to change u-boot to
initialize the switch with a VLAN tagged mode, but I cannot give any
promises.  If you're interested you can probably tag with ccardenas@,
who'd probably like to support the switch as well.

USB works out of the box.  The Ethernet controller should work as well,
same as the Clearfog.  SD card support is ongoing effort, but shouldn't
be too much work since I got it going on the Armada 8040 as well.  PCIe
hopefully follows afterwards.

Patrick

Re: Need an advice: Raspberry Pi3 B+ or Pine64 ROCK64

[Patrick Wildt]

On Sun, Aug 26, 2018 at 11:00:26AM +, Stuart Henderson wrote:
> On 2018-08-26, Carlos López  wrote:
> >
> >
> > On 26/08/2018 11:46, Joel Wirāmu Pauling wrote:
> >> netboot works fine. However almost all of the Arm platforms including
> >> the Rpi3 make terrible gateways and in general l3 packet path
> >> machines.
> >> 
> >> I have a bunch of various SBC and they all suck pretty bad for network
> >> tasks. Fine for random server tasks but don't put them in your network
> >> path unless you like artificial bottlenecks.
> >> 
> >> The Machiattobin and/or Espressobin platforms are probably the best
> >> for network appliance usage. I haven't got one to see if Openbsd works
> >> on them at all tho.
> >> 
> >> 
> >
> > Uhmm ... Interesting point Joel ... Searching both SBC, maybe 
> > Espressobin is best option than Machiattobin ...
> >
> > Has anyone tried any of them?
> 
> The MACCHIATObin is listed on arm64.html as having some support, the
> ESPRESSObin isn't.

On the MacchiatoBin we don't support the onboard ethernet yet.  On the
EspressoBin we do support the ethernet controller, but the connected
switch is a mess that I don't dare to support.  Got other stuff to do.
Though I am working on partial EspressoBin support for the upcoming
Turris Mox.

That said, if 32-bit ARM is OK look at the Clearfog Base.  If you're
willing to spend a bit more, SolidRun has nice 64-bit machines.  But
on those we still need to write the ethernet driver.

Patrick

Re: Is BCM4360 802.11ac (on MacBook Air 6.1) supported?

[Patrick Wildt]

On Fri, Jul 27, 2018 at 08:33:27AM +0200, Stefan Sperling wrote:
> On Thu, Jul 26, 2018 at 09:33:43PM +0200, MiKi wrote:
> > Hi,
> > 
> > I installed OpenBSD 6.3 in a MacBook Air 6.1 everything works fine but
> > except the wireless card.
> > 
> > It have a Broadcom BCM4360 802.11ac (rev3) card, the device is showed on
> > dmesg but left undetected as a device in ifconfig, I take a look on bwi(4)
> > and this exact model wasn't listed.
> > 
> > I also checked the new driver bwfm(4) that seems a newer driver for Broadcom
> > AC cards, but it haven't any listing.
> > 
> > Also I have nothing pending to install with fw_update
> > 
> > So, is this card definitely unsupported? if not, can someone give me some
> > pointers to get it work?
> 
> This card might be supported by bwfm(4) in -current.
> 

It is not.  It looks like this is a SoftMAC chip which can not be
supported by the bwfm(4) FullMAC driver.  Even FreeBSD, who have worked
on improving their SoftMAC support, do not seem to support that chip.

Re: Setting up IKEv2 IPSec connection to Algo VPN

[Patrick Wildt]

On Mon, Feb 19, 2018 at 04:04:38PM -0700, Alec Newman wrote:
> Hello,
> 
> I was experimenting with setting up a VPN server on AWS using Algo (
> https://github.com/trailofbits/algo) that I'd like to connect to using an
> OpenBSD laptop.
> 
> They don't explicitly provide an OpenBSD client configuration but from what
> I can tell it should be doable with OpenBSD's built in tools.  It appears
> to be IKEv2 so from what I can tell I just need the correct /etc/iked.conf
> and copy the right keys/certificates into the right places in /etc/iked.
> 
> This is the StrongSwan config file provided for the client (VPN server's IP
> address replaced with $REMOTEGW and username replaced with $USER).
> 
> conn ikev2-$REMOTEGW
> fragmentation=yes
> rekey=no

Does this mean it does reauthentication instead of rekeying?  Could
become an issue at some point, especially if strongswan does make-
before-break and you have long running connections.

> dpdaction=clear
> keyexchange=ikev2
> compress=no
> dpddelay=35s
> 
> ike=aes128gcm16-prfsha512-ecp256!
> esp=aes128gcm16-ecp256!
> 
> right=$REMOTEGW
> rightid=$REMOTEGW
> rightsubnet=0.0.0.0/0
> rightauth=pubkey
> 
> leftsourceip=%config
> leftauth=pubkey
> leftcert=$USER.crt
> leftfirewall=yes
> left=%defaultroute
> 
> auto=add
> 
> I tried copying the certifcate produced by algo named $REMOTEGW.crt to
> /etc/iked/pubkeys/ipv4/$REMOTEGW but when I restart iked with rcctl restart
> iked I get "iked[37566]: set_policy: could not find pubkey for
> /etc/iked/pubkeys/ipv4/$REMOTEGW" in /var/log/messages.  The certificate is
> in the PEM format, which appears to be what is required, so I'm unsure what
> problem iked is having.

In a current iked(8) setup you have to store your own certificate (with
the private key in a different directory) and its full chain.  Also you
have to store the remote gateway's full chain (but not necessarily the
remote gateway's certificate).  In addition, you have to make sure the
certs use the X509v3 something something DNS extension.

openssl x509 -in fubar.crt -text should show this if you look for
X509v3.

> Any insight or help would be appreciated.  I'd be happy to provide more
> information if necessary.
> 
> Thanks,
> Alec

Re: iked with Windows 10 MS-ChapV2

[Patrick Wildt]

On Wed, Jan 03, 2018 at 03:11:01AM +, Michael Lam wrote:
> Hi all,
> 
> Does anyone have experience with using iked with a Windows 10 and EAP
> mschap-v2 authentication in a road warrior setup?

You mean Windows 10 connecting as a road warrior to iked?

> I tried but it doesn’t work. It always return error saying no local
> certificate found. On a side note - Windows seems to report it’s IP address
> as peerid.

Make sure you load the complete certificate chain for your _local_ iked
certifikate to /etc/iked/ca/.  This is, so far, required.  I have some
upcoming diff that removes the requirement to trust all CAs of your
local certificate.

Patrick

> On the OpenBSD side, I am using the latest iked from cvs and a valid
> letsencrypt certificate. The resulting server does not have issue with iOS
> configuration but never got pass   Windows 10.
> 
> The same certififcate works properly with strongswan in a freebsd ikev2
> setup hence server certificate issue can be eliminated.
> 
> Will post logs and config once I am back home.
> -- 
> 
> Rgds, Michael

Re: ikectl errors

[Patrick Wildt]

On Thu, Nov 02, 2017 at 11:25:18PM +, Andreas Thulin wrote:
> Hi again,
> 
> found this on cvsweb.openbsd.org:
> 
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin/iked/ca.c?sortby=date
> 
> ”In the subjectAltName comparison, the bzero before the while-loop was
> lost while applying the diff. This is means sanid could be passed
> uninitialized to ca_x509_subjectaltname_cmp(), where ibuf_release()
> could try to release a pointer which is essentially stack garbage.
> While there I realized that the bzero() in the loop is essentially
> fatal, since every mismatch leads to a silent leak of ibufs. Since
> ca_x509_subjectaltname_cmp() releases and initializes the passed
> iked_id, we can safely call it multiple times after initializing
> sanid once before the loop.”
> 
> Ignorant question: Does this mean a) that I should (try and probably fail
> to) patch myself, b) that the change may become a syspatch, or c) that the
> next release will include the patch? I’m running 6.2-stable.

This is a fixup for a change in -current, 6.2-stable is all fine.  So
unless you were running -current, all good.

Patrick

> Thanks again for the tip!
> 
> BR, Andreas

Re: Pinebook (if anyones up for it)

[Patrick Wildt]

On Mon, Aug 14, 2017 at 10:08:13PM +0300, valerij zaporogeci wrote:
> 2017-08-14 10:21 GMT+03:00, Alex Naumov :
> > Hello,
> >
> > there is one enthusiast, who wants to make it possible:
> > http://openbsd-archive.7691.n7.nabble.com/Working-on-support-for-Pinebook-td318562.html
> >
> > I don't know the current state, but I also have a Pinebook and would
> > like to run OpenBSD on it.
> >
> >
> > Some info you can find there: https://www.openbsd.org/arm64.html
> > ==
> > The Pine64 currently requires an image based on a non-redistributable
> > boot0 file from Allwinner to be installed on the system disk. This
> > will hopefully be resolved by a replacement in a future U-Boot
> > release. The install media does not include these boot images or a
> > Pine64 device tree. For similar reasons we do not provide install
> > media for the Firefly-RK3399 either.
> > ==

Correction: The problem of the boot0 file has been solved thanks to
changes in u-boot.  Work on install media for the Pine64 is now in
progress, without unredistributable blobs.

> >
> > So, it seems that it's impossible yet.
> >
> >
> > Cheers,
> > Alex
> >
> 
> this boot0 thing is a part of the firmware. why its redistributability
> state should influence an OS support? are x86 BIOS parts all
> redistributable?
> 
> Is it obtainable? This is that "security world" thing and it will be
> anywhere where the Security Extension is implemented. I have Pine64+
> board and am planning to do my project on it, which is a UEFI
> implementation. x^D Will be OpenBSD happy if there were UEFI on it as
> a FW and that boot0 thing is a part of UEFI installation?
> 

Re: solidrun marvell macchiatobin

[Patrick Wildt]

On Wed, May 31, 2017 at 09:19:31PM +0200, Hrvoje Popovski wrote:
> Hi arm gurus,
> 
> does openbsd support solid-run marvell armada family boards?
> 
> primary this little cute firewall :)
> 
> https://www.solid-run.com/marvell-armada-family/armada-8040-community-board/
> 
> 
> if there are any interest in this box i'm willing to donate it for
> development ..
> 
> 

Are you following my Twitter or what? ;)  I just posted a picture
of that board, arrived on the doorsteps today.  I'll be having a
look.

Patrick

Re: OpenBSD 6.1: BOOTIA32 3.32 issue

[Patrick Wildt]

On Wed, May 10, 2017 at 03:14:30PM +0200, Stefan Sperling wrote:
> On Tue, May 09, 2017 at 09:47:14PM +0200, Michele Curti wrote:
> > On Tue, May 09, 2017 at 09:36:02PM +0200, Michele Curti wrote:
> > > On Tue, May 09, 2017 at 10:20:03AM +0200, Michele Curti wrote:
> > > > Hi all, I tried to upgrade to OpenBSD 6.1 on an Asus X205TA (bay
> > > > trail, 32 bit efi, 64 bit os) but the bootloader do not correctly
> > > > detect the internal disk.
> > > > 
> > > > I also tried a fresh install, but things do not change.  Boot fails
> > > > and when I do a "machine diskinfo" I got a lot of "?" symbols (a video
> > > > here https://www.youtube.com/watch?v=fsomNX-oFTQ )
> > > > 
> > > > How can I debug the issue?
> > > > 
> > > 
> > > Compiling bootia32.efi :p
> > > 
> > > With sys/arch/amd64/stand/efiboot/efiboot.c revision 1.15 it works,
> > > revision 1.16 it fails.
> > > 
> > > I'll try to understand, thanks, Michele
> > 
> > 
> > With the following diff it works, bye!
> 
> Looks good to me. Is anyone handling this patch?
> 
> > Index: efiboot/efiboot.c
> > ===
> > RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/efiboot.c,v
> > retrieving revision 1.17
> > diff -u -p -r1.17 efiboot.c
> > --- efiboot/efiboot.c   3 Mar 2017 08:56:18 -   1.17
> > +++ efiboot/efiboot.c   9 May 2017 19:44:30 -
> > @@ -92,7 +92,7 @@ efi_main(EFI_HANDLE image, EFI_SYSTEM_TA
> > if (DevicePathType(dp) == MEDIA_DEVICE_PATH &&
> > DevicePathSubType(dp) == MEDIA_HARDDRIVE_DP) {
> > bios_bootdev = 0x80;
> > -   efi_bootdp = dp0;
> > +   efi_bootdp = dp;
> > break;
> > }
> > }
> > 
> 

I don't think this is the correct fix.  It might solve your issue, but I
don't think it's completely right.  So EFI has those so called device
paths.  A path is basically a list of nodes.  To compare two paths you
need to compare the whole path and not just a single node of it.  If you
store dp instead of dp0 you will basically only save a part of the path,
not the full path.

What you can do is print the full path of efi_bootdp like..

for (dp = efi_bootdp; !IsDevicePathEnd(dp);
dp = NextDevicePathNode(dp)) {
printf("%x %x - ", DevicePathType(dp), DevicePathSubType(dp));
}
printf("\n");

And do the same for the DPs that are being put into the
efi_device_path_cmp function.  That will at least print the types, but
not the content of the nodes.  That's a start into figuring out why it
does not correctly compare the paths.

Maybe there's a bug in the compare code?

Re: armv7 on Wandboard Quad

[Patrick Wildt]

On Thu, Aug 11, 2016 at 11:06:45PM -0400, Joe Gidi wrote:
> The recent flurry of activity on the armv7 port prompted me to buy a
> Wandboard Quad so I could try a new hardware platform.
> 
> As you'd expect with OpenBSD, installation was dead simple and
> trouble-free. I grabbed the latest snapshot miniroot-wandboard-60.fs file
> from my local mirror, dd'ed it to an SD card, stuck the card in the top
> slot on the Wandboard (there are 2 slots, but reportedly only the upper
> slot is bootable), plugged in a null modem cable for a serial console, and
> connected the power. The board booted into bsd.rd and installed as usual.
> 
> I have not done any extensive testing yet, but I'm including the results
> of 'openssl speed' and 'md5 -t' as a crude benchmark of CPU performance.
> According to the specs this board is supposed to run at 1 GHz, but mine
> seems to boot up at 792 MHz instead. This is probably configurable
> somewhere, maybe within U-Boot, but I have not explored that yet.

792 MHz is the default on i.MX6.  With more drivers one could change
voltages and clock up the processor to up to 1.2 GHz.

> 
> The only oddity I've noticed so far is that the dmesg lists a third sdmmc
> device when there are only two physical slots. I have not tried using a
> second SD card in the lower slot, but I expect it will work fine.

The SoC itself has 3 SD card controllers.  How many are exposed on the
board is up to the board designer.  In this case the 3rd SD card slot
is probably used internally for the SDIO-connected WiFi chip.

> 
> Following are the 'openssl speed' and 'md5 -t' results, as well as a
> 'sysctl hw' and dmesg. Thanks to the developers who have been working so
> hard on this platform!
> 
> -
> 
> LibreSSL 2.5.0
> built on: date not available
> options:bn(64,32) rc4(ptr,int) des(idx,cisc,16,long) aes(partial)
> idea(int) blowfish(idx)
> compiler: information not available
> The 'numbers' are in 1000s of bytes per second processed.
> type 16 bytes 64 bytes256 bytes   1024 bytes   8192 bytes
> md2  0.00 0.00 0.00 0.00 0.00
> md4   5540.83k19327.23k54267.22k98484.31k
> 130551.44k
> md5   3898.23k13996.04k39344.72k70417.97k
> 92032.51k
> hmac(md5) 5377.17k17490.31k45299.67k75457.88k
> 93493.12k
> sha1  4189.54k13547.88k31824.09k47186.54k
> 54307.03k
> rmd1603442.88k10034.65k20882.65k28884.62k
> 32726.90k
> rc4  36176.50k39058.88k41778.77k42090.15k
> 42149.34k
> des cbc  10151.93k10928.95k2.44k11247.22k
> 11167.70k
> des ede3  3902.13k 3980.65k 4026.57k 4035.98k
> 4063.23k
> idea cbc  9638.86k10107.32k10328.62k10367.06k
> 10341.03k
> seed cbc 0.00 0.00 0.00 0.00 0.00
> rc2 cbc   8145.03k 8492.99k 8667.56k 8636.19k
> 8686.25k
> rc5-32/12 cbc0.00 0.00 0.00 0.00 0.00
> blowfish cbc 19748.39k21868.33k22328.32k22642.08k
> 22533.46k
> cast cbc 16150.69k17645.76k17825.76k17988.95k
> 17978.85k
> aes-128 cbc  22743.94k25601.49k26023.59k26640.15k
> 26514.77k
> aes-192 cbc  20264.96k21907.75k22725.95k22938.63k
> 22964.91k
> aes-256 cbc  18069.54k19826.97k20212.04k20643.84k
> 20665.69k
> camellia-128 cbc15796.13k17206.26k17443.81k17585.24k
> 17547.70k
> camellia-192 cbc12598.56k13344.47k13663.91k13637.51k
> 13711.39k
> camellia-256 cbc12589.03k13301.57k13394.74k13732.18k
> 13811.33k
> sha2566371.41k14286.47k24558.90k29677.75k
> 32049.83k
> sha5121830.57k 7313.82k10421.41k14217.95k
> 15816.24k
> whirlpool  652.76k 1310.27k 2135.72k 2523.48k
> 2627.37k
> aes-128 ige  21055.95k24409.04k25611.40k26153.44k
> 26313.36k
> aes-192 ige  18235.72k20863.64k21903.22k22177.25k
> 22287.14k
> aes-256 ige  16439.16k18527.72k19414.61k19495.67k
> 19528.32k
> ghash24031.10k27179.35k28220.35k28742.31k
> 29040.37k
> aes-128 gcm   4901.14k 9394.71k12110.58k13078.04k
> 13660.57k
> aes-256 gcm   4411.09k 8215.83k10625.54k11448.94k
> 11909.91k
> chacha20 poly1305 1767.92k 6481.10k11053.23k13396.59k
> 14307.42k
>   signverifysign/s verify/s
> rsa  512 bits 0.001200s 0.000130s833.5   7687.6
> rsa 1024 bits 0.006262s 0.000380s159.7   2629.4
> rsa 2048 bits 0.041883s 0.001331s 23.9751.1
> rsa 4096 bits 0.301765s 0.005084s  3.3196.7
>   signverifysign/s verify/s
> dsa  512 bits 0.001289s 0.001322s775.9756.4
> dsa 1024 bits 0.003830s 0.004121s261.1242.7
> dsa 2048 bits 

Re: Raspberrypi 3 was released

[Patrick Wildt]

On Mon, Mar 14, 2016 at 09:07:37AM +, Roderick wrote:
> What about AMD Opteron A-Series? Does OpenBSD run on it?
> 
> http://www.amd.com/en-us/products/server/opteron-a-series
> 
> Rodrigo.
> 

The raspberry pi 3 has its good and bad sides.  It's easy to use,
everywhere available and rather cheap.  Yes, there's the ODROID-C2
which is similarly cheap and better, but the raspberry pi might
actually be easier to support.

First of all, the blobs.  Every ARM machine has some kind of blob.  Some
are hidden, like stored on a flash.  Some are visible, e. g. stored on
the SD card.  The raspberry pi is of the latter.  Its blobs have to be
stored on the SD card so that it can boot.  The Cubox-i is similar, it
also needs a blob on the SD card.  The difference though is that the
cubox blobs can be compiled from some u-boot repository on github.  The
raspberry pi blobs are not open source.

Still, both have blobs that run as part of the boot stage, and are not
driver blobs that have to be run on the CPU, like a kernel module.
Though, the raspberry pi blobs are a bit special.  They actually run on
the GPU, not the CPU, and take care of the boot stage.  This means that
the GPU is booted first, from a blob stored on the SD card, which then
loads the kernel from the SD card into memory, and then starts the CPU.

That's not nice.  There's no IOMMU, though we can't secure ourselves
against malicious memory access from the GPU.  But I'm not sure that's
much worse than other machines, where the blob isn't visible.

The USB Controller is crap, but it's the same as the octeon, so we got a
driver for that.  HDMI is controlled by the GPU.  For a simple
framebuffer the GPU provides an interface to ask for framebuffer memory.
This means it's comparatively easy to actually have HDMI output: you
just ask the GPU's API to kindly provide it.

Making OpenBSD run on the raspberry pi is feasible, though (without
adding hacks) it's only feasible with proper device tree support, which
is a work in progress at the moment.

The AMD machine is quite nice actually.  As it's based on a Cortex-A57,
which is backwards compatible to 32-bit armv7, it might be possible to
run OpenBSD/ARMv7 on it.

For that we will need some kind of mechanism to boot a 32-bit kernel.
The machine, as far as I know, boots using UEFI.  So maybe we'll need
an efiboot for ARMv8, which can boot an ARMv7 kernel.  Or maybe one can
use u-boot as a payload for EFI?  No idea.  Also one needs to port the
10 GbE ethernet controller driver, or write a new one.  The one in linux
is dual-licensed, so in theory it could be pulled over.

Oh, and that machine is kind of expensive.  But there'll be $300 USD
96boards (enterprise edition) available this year, which is much cheaper
than the original devkit from AMD.

That's my brain dump, hopefully that clears some things up.

Patrick

Re: ARM Firewall Hardware

[Patrick Wildt]

 Am 16.01.2015 um 08:49 schrieb Jonathan Gray j...@jsg.id.au:
 
 On Fri, Jan 16, 2015 at 07:59:49AM +0100, Christer Solskogen wrote:
 On Wed, Jan 14, 2015 at 7:19 PM, Christer Solskogen
 christer.solsko...@gmail.com wrote:
 On Wed, Jan 14, 2015 at 3:39 PM, Jonathan Gray j...@jsg.id.au wrote:
 I've updated the kernel at
 http://jsg.id.au/openbsd/bsd.IMX.umg
 
 
 And we have lift-off!
 
 
 Will the changes go in-tree soon? :-)
 
 The diffs are up for review, I'll likely commit them sometime soon if I
 don't hear any objections.
 
 A new snapshot with the changes should hit the mirrors in a day or two.
 
 Keep in mind not everything will work.  Looking at
 http://compulab.co.il/utilite-computer/web/wp-content/uploads/2013/07/Utilite-block-diagram.png
 imx PCIE isn't supported currently so the I211 em(4) won't attach.
 The i2c connected eeprom with the mac address for the ixmnet(4) interface
 and the i2c connected rtc won't work.  And I don't see how
 audio/video/wifi could work currently.

Got PCIe to work. Unfortunately the i211 em(4) doesn’t attach as it
doesn’t have the usual eeprom, but some kind of OTP which needs
to be read differently.  I wrote a working diff and mail it to jsg@ for
advice and review.

Unfortunately the i211’s mac address isn’t in the Utilite’s em(4) OTP
either, which it usually should be.  Apparently they put in the cheapest
hardware to „make it work“.  The mac address is stored in another
eeprom connected to i2c.

I don’t really see a way to make em(4) get that mac address. It’d
probably either need a huge hack or some other API that does
not exist. :( As of now I made it use a random address every time.

 
 For the mac address eeprom at least there is some code in Bitrig
 which could be used.

Re: ARM Firewall Hardware

[Patrick Wildt]

 Am 16.01.2015 um 08:49 schrieb Jonathan Gray j...@jsg.id.au:
 
 On Fri, Jan 16, 2015 at 07:59:49AM +0100, Christer Solskogen wrote:
 On Wed, Jan 14, 2015 at 7:19 PM, Christer Solskogen
 christer.solsko...@gmail.com wrote:
 On Wed, Jan 14, 2015 at 3:39 PM, Jonathan Gray j...@jsg.id.au wrote:
 I've updated the kernel at
 http://jsg.id.au/openbsd/bsd.IMX.umg
 
 
 And we have lift-off!
 
 
 Will the changes go in-tree soon? :-)
 
 The diffs are up for review, I'll likely commit them sometime soon if I
 don't hear any objections.
 
 A new snapshot with the changes should hit the mirrors in a day or two.
 
 Keep in mind not everything will work.  Looking at
 http://compulab.co.il/utilite-computer/web/wp-content/uploads/2013/07/Utilite-block-diagram.png
 imx PCIE isn't supported currently so the I211 em(4) won't attach.
 The i2c connected eeprom with the mac address for the ixmnet(4) interface
 and the i2c connected rtc won't work.  And I don't see how
 audio/video/wifi could work currently.
 
 For the mac address eeprom at least there is some code in Bitrig
 which could be used.
 

I do have some PCIe code, but as I already stated somewhere it’s
functional enough to have the em(4) or other devices work. :(

Re: OpenBSD on Intel Galileo

[Patrick Wildt]

 Am 14.01.2015 um 09:43 schrieb Stuart Henderson s...@spacehopper.org:
 
 On 2015-01-13, Patrick Wildt m...@patrick-wildt.de wrote:
 Hi,
 
 Yes, it’s kinda possible.  I tried that early 2014 or so. You need to have 
 some kind of EFI-Grub2 on an sdcard iirc. Then you exit the in-built grub, 
 open the EFI shell and have it boot grub2.
 
 Using kopenbsd you can try to load an OpenBSD kernel, but it doesn’t work 
 out of the box.
 
 The serial line is not in the ISA(?) space, but memory mapped somewhere 
 else, so you do not get serial output.  The grub boot options pass the 
 actual address to the linux kernel, so that’s where you can find out which 
 one it is.
 
 After doing a hack to make that work, I got the following output: 
 http://gbpaste.org/Pd5Vv
 
 I fear I do not have the diffs and blobs anymore.
 
 If you can have grub chain to OpenBSD's boot loader, you can set the port 
 address
 with 'machine comaddr'.
 

Yes, that is right. But it does not fix two other issues.

First, you need I386_BUS_SPACE_MEM instead of I386_BUS_SPACE_IO.  The console 
is memory mapped and not accessible via outb/inb.

Second, registers need to be accessed in 4x space mode. Means, the register you 
want to access has to be multiplied by 4 before accessing it.

All those issues are caused by the console being connected via PCI (puc(4)) as 
far as I can see.

Re: OpenBSD on Intel Galileo

[Patrick Wildt]

Hi,

Yes, it’s kinda possible.  I tried that early 2014 or so. You need to have some 
kind of EFI-Grub2 on an sdcard iirc. Then you exit the in-built grub, open the 
EFI shell and have it boot grub2.

Using kopenbsd you can try to load an OpenBSD kernel, but it doesn’t work out 
of the box.

The serial line is not in the ISA(?) space, but memory mapped somewhere else, 
so you do not get serial output.  The grub boot options pass the actual address 
to the linux kernel, so that’s where you can find out which one it is.

After doing a hack to make that work, I got the following output: 
http://gbpaste.org/Pd5Vv

I fear I do not have the diffs and blobs anymore.

\Patrick

 Am 13.01.2015 um 13:10 schrieb Lampshade lampsh...@poczta.fm:
 
 Hello
 Anybody tried to boot OpenBSD on Intel Galileo board? 
 Is this possible?
 Have a good day

Re: OpenBSD on Intel Galileo

[Patrick Wildt]

I had the machine I worked on for this was some OpenBSD VM I purged some time 
ago.

I was grepping through IRC logs and actually found a diff:

#somewhere_20140227.log:[00:23:44] Bluerise This is my galileo workaround: 
http://gbpaste.org/CfG4P

I’m glad I keep logs… Good luck!

 Am 13.01.2015 um 14:50 schrieb Amit Kulkarni amitk...@gmail.com:
 
 Dude...the reason is given right there, in the message.
 
 why not publish the hack , for education purpose ?
 
 
 I fear I do not have the diffs and blobs anymore.

Re: ARM Firewall Hardware

[Patrick Wildt]

Looks like the Utilite wasn’t added in the console init code:

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/armv7/imx/imx_machdep.c.diff?r1=1.7r2=1.8

 Am 12.01.2015 um 18:57 schrieb Christer Solskogen 
 christer.solsko...@gmail.com:
 
 On Mon, Jan 12, 2015 at 3:30 PM, Jonathan Gray j...@jsg.id.au wrote:
 
 The serial console output would be a good starting point.
 
 (bsd.umg is really bsd.rd.IMX.umg)
 
 CM-FX6 # tftp 0x1080 bsd.umg
 Using FEC device
 TFTP from server 192.168.0.4; our IP address is 192.168.0.9
 Filename 'bsd.umg'.
 Load address: 0x1080
 Loading: #
 #
 #
 #
 #
 #
 #
 ##
 1.2 MiB/s
 done
 Bytes transferred = 7461928 (71dc28 hex)
 CM-FX6 # bootm
 ## Booting kernel from Legacy Image at 1080 ...
   Image Name:   boot
   Created:  2015-01-09   8:29:22 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:7461864 Bytes = 7.1 MiB
   Load Address: 1080
   Entry Point:  1080
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
 
 Starting kernel ...
 
 And here it hangs forever.
 
 -- 
 chs

Re: ARM Firewall Hardware

[Patrick Wildt]

 Am 11.01.2015 um 14:27 schrieb Christer Solskogen 
 christer.solsko...@gmail.com:
 
 On Mon, Jan 5, 2015 at 10:31 AM, f5b f...@163.com wrote:
 according
 http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/armv7/armv7/armv7.c?rev=1.4
 
 
 Only one board supported in current with two  Gigabit ports ,Compulab 
 UTILITE  box ?
 Anyone can make sure?
 
 OpenBSD still does not boot on that board. Bitrig boots fine.
 (used snapshot from 10th of january)
 
 -- 
 chs
 

One Port is limited to 540MBit/s by design. The other one is connected to the 
PCIe 1x
slot which I still cannot get to run properly.

It detects the device easily, but „talking“ to it doesn’t work. It looks like 
there’s some kind
of DMA issue I haven’t figured out.

Otherwise that device runs great here. I’m using it as build machine, with the 
in-built
SSD.

Re: ARM Firewall Hardware

[Patrick Wildt]

You mean the i.MX6 SoC? Yeah, that one is limited to 540 MBit/s by design.

In comparison to the i.MX series the LayerScape models are supposed to be 
network processors. So, even though they have a tendency to fuck things up, I 
don't think they also do that on something that already worked with PPC for 
some time.

I have not yet run performance tests on the TWR-LS1021A.

\Patrick

 Am 05.01.2015 um 14:54 schrieb Diana Eichert deich...@wrench.com:
 
 Do the 1Gb interfaces support real 1Gb/sec?  I know there
 was some arm h/w with 1Gb interfaces that would not run
 at 1Gb speed.
 
 diana
 
 
 On Mon, 5 Jan 2015, Patrick Wildt wrote:
 
 Until recently there has not been ARM hardware that actually has more
 than two Gigabit Ethernet ports.  As of now there are two options:
 
 There’s the Banana Pi R1, which basically is a bigger Banana Pi with
 5 Gigabit Ports connected to a Broadcom BCM53125 Switch.
 
 The BPI-R1, also called Lamobo R1 is based on an Allwinner A20.
 There currently seems to be only minimal support for the SoC in
 OpenBSD.
 
 FreeScale has recently been working on ARM-based network chips.
 They already had QorIQ network chips based on PowerPC and now
 basically replaced the PPC core with an ARM one, keeping the „old“
 peripherals.
 
 They are be working on LS1 and LS2 SoCs of varying performance.
 One of them is a dual-core Cortex A7, another one a Cortex A9,
 a rather slow ARM11 and even a few ARM 64-bit cores.
 
 As far as I know they already supply development boards[0] and
 reference design[1] hardware for the LS1021A, the dual core Cortex A7.
 
 That hardware is really interesting, but rather expensive and not
 supported by OpenBSD.
 
 \Patrick
 
 [0]
 http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=TWR-LS1021A
 [1]
 http://cache.freescale.com/files/32bit/doc/quick_ref_guide/LS1021A-IOTGS.pdf
 
 On Sun, Jan 04, 2015 at 10:41:14PM -0500, Predrag Punosevac wrote:
 I started entertain the idea of getting ARM based hardware for my new
 home firewall.
 
 Are there ARM based consumer motherboards with Gigabit lan controller
 which can be used for home firewall hobby project? How close is armv7 or
 any other OpenBSD version of being fully functional on such hardware?
 
 Cheers,
 Predrag

Re: ARM Firewall Hardware

[Patrick Wildt]

Until recently there has not been ARM hardware that actually has more
than two Gigabit Ethernet ports.  As of now there are two options:

There’s the Banana Pi R1, which basically is a bigger Banana Pi with
5 Gigabit Ports connected to a Broadcom BCM53125 Switch.

The BPI-R1, also called Lamobo R1 is based on an Allwinner A20.
There currently seems to be only minimal support for the SoC in
OpenBSD.

FreeScale has recently been working on ARM-based network chips.
They already had QorIQ network chips based on PowerPC and now
basically replaced the PPC core with an ARM one, keeping the „old“
peripherals.

They are be working on LS1 and LS2 SoCs of varying performance.
One of them is a dual-core Cortex A7, another one a Cortex A9,
a rather slow ARM11 and even a few ARM 64-bit cores.

As far as I know they already supply development boards[0] and
reference design[1] hardware for the LS1021A, the dual core Cortex A7.

That hardware is really interesting, but rather expensive and not
supported by OpenBSD.

\Patrick

[0]
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=TWR-LS1021A
[1]
http://cache.freescale.com/files/32bit/doc/quick_ref_guide/LS1021A-IOTGS.pdf

On Sun, Jan 04, 2015 at 10:41:14PM -0500, Predrag Punosevac wrote:
 I started entertain the idea of getting ARM based hardware for my new
 home firewall.
 
 Are there ARM based consumer motherboards with Gigabit lan controller
 which can be used for home firewall hobby project? How close is armv7 or
 any other OpenBSD version of being fully functional on such hardware?
 
 Cheers,
 Predrag

Re: Boot OpenBSD on Utilite

[Patrick Wildt]

Hello from Munich,

The Utilite is not yet supported.  I have ordered one myself but I don’t
think it has been shipped yet.

I will have a look at the CM-FX6 documentation later today and will
send you a mail with a kernel and some infos on how to boot it.

The pdf has been filtered in this mailing list.  You can re-send it to
my mail address if you like.

\Patrick

Am 26.10.2013 um 10:38 schrieb Peter Bauer peter.ba...@inode.at:

 Hello from Vienna,
 
 I tried to boot OpenBSD on my Utilite pro
 and got the following result.
 
 1. Downloaded miniroot
   http://ftp.uio.no/OpenBSD/snapshots/armv7/miniroot-imx-54.fs
 
 2. Because booting from ext filesystem did not work for me I Put the
   contents on a FAT formatted SD card and renamed the bootscript to
   boot.scr
 
 3. modified boot.scr, just removed the entry to try boot from sata
 
 
 4. tried a boot:
   mmc2 is current device
   reading boot.scr
 
   362 bytes read
   Running bootscript from mmc ...
   ## Executing script at 1080
   Bad data crc
 
   My u-boot version is:
   2009.08-cm-fx6-0.85+tools (Aug 08 2013)
 
 
 What could I try next ? What image could I try for a TFTP boot ?
 I am new to U-boot, so if you can pass me some info how to boot
 via TFTP (u-boot syntax).
 
 I noticed the first line of the boot script looks a bit garbled when
 viewing it with an editor like nano or gedit.
 
 'V2\8E\D5RS\AC\E9\00\00
/\00\00\00\00\00\00\00\00\CC\F9\9C\00boot
 \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00
 \00\00\00\00\00\00
'\00\00\00\00; setenv loadaddr 0x1880 ; setenv
 bootargs sd0i:/bsd.umg ; for dtype in sata mmc ; do for disk in 0 1 ; do
 ${dtype} dev ${disk} ; for fs in fat ext2 ; do if ${fs}load ${dtype}
 ${disk}:1 ${loadaddr} bsd.umg ; then  bootm ${loadaddr} ; fi ; done;
 done; done; echo; echo failed to load bsd.umg
 
 
 Attached you can find the current Utilite boot environment. 
 
 
 Best Regards,
 Peter Bauer
 http://bitkistl.blogspot.com
 
 [demime 1.01d removed an attachment of type application/pdf which had a name 
 of utilite.u-boot.environment.pdf]

Re: open bsd router

[Patrick Wildt]

Hey,

The PC Engines Alix boards are working quite well.

If you're looking for ARM machines, you'd rather have a look at 
http://cubox-i.com or http://utilite-computer.com .
Note that the second Gigabit Ethernet in the Utilite is connected via PCI-e and 
will need to be worked on.

\Patrick

Am 03.10.2013 um 23:37 schrieb alexey.kurin...@gmail.com:

 Hi. I want to buy some single board (arm cpu) computer for installing open 
 bsd and run services NAT, vpn, webserver,
 etc... Primary experiments for work and fun.
 Hours of googling and reading. I found many deviceses, many of it's listed 
 there 
 http://www.element14.com/community/community/knode/single-board_computers/blog?start=0
 Exist good industrial boards, but low price start for it when buying =1k 
 boards
 
 My favorite:
 http://www.pcengines.ch/product.htm
 http://en.wikipedia.org/wiki/Raspberry_Pi
 
 Question is - what boards succesfully used by members of misc@openbsd.org 
 list? I glad to read members IMHO about used boards.
 
 Sorry for ugly english.

Re: Freescale i.MX 6

[Patrick Wildt]

Hey,

I have added support for the i.MX6 SoC to the tree.  The platform is now called 
armv7
instead of beagle.  There might be some changes needed to support the Utilite, 
too.
Apart from that it should be usable.

\Patrick

Am 27.09.2013 um 13:04 schrieb Christer Solskogen 
christer.solsko...@gmail.com:

 Hi!
 
 There was a mention of this platform earlier, but is this platform
 usable yet? I'm getting myself a Utilite, and was hoping I could use
 OpenBSD in it. This is ARM, but as far as I understood the platform is
 beagle, am I right?
 
 -- 
 chs,

Re: Freescale i.MX 6

[Patrick Wildt]

Thanks to Christer I have just placed an order for an Utilite, too. :)

Thank you very much!

\Patrick

Am 27.09.2013 um 21:54 schrieb Christer Solskogen 
christer.solsko...@gmail.com:

 On Fri, Sep 27, 2013 at 1:31 PM, Patrick Wildt m...@patrick-wildt.de wrote:
 Hey,
 
 I have added support for the i.MX6 SoC to the tree.  The platform is now 
 called armv7
 instead of beagle.  There might be some changes needed to support the 
 Utilite, too.
 Apart from that it should be usable.
 
 
 Okay, which image / kernel can I use to test this? I ordered mine
 today, so it will take at least six weeks before it gets here.
 Also, if you want one, order it and I'll send you money for it.
 
 -- 
 chs

Re: divert-to with bridge

[Patrick Wildt]

Hi Luiz,

I actually have seen that on a bridge setup I had, too.

Although the divert-to points to localhost, I see the packet trying to pass out 
on the interface to the original destination, as your data shows, too.
No idea why that's happening though.

\Patrick

Am 23.05.2013 um 22:45 schrieb Luiz Gustavo S. Costa 
luizgust...@mundounix.com.br:

 Hi List !
 
 I'm trying to implement a firewall with squid TPROXY in an environment with 
 bridge.
 
 vio0 = external if
 vio1 = internal if
 bridge0 = (vio0 + vio1)
 
 I have these rules, the connections pass through it, but nothing comes on the 
 side of the divert-to (did tests with nc -l 3128)
 
 [17:31:25] root:logs # cat /etc/pf.conf
 pass in log quick on vio1 inet proto tcp from any to any port 80 divert-to 
 127.0.0.1 port 3128
 
 pass out log quick on vio0 inet proto tcp from any to any port 80 divert-reply
 
 pass all
 
 [17:39:40] root:~ # pfctl -vvsr
 @0 pass in log quick on vio1 inet proto tcp from any to any port = 80 flags 
 S/SA divert-to 127.0.0.1 port 3128
  [ Evaluations: 92Packets: 194   Bytes: 43964   States: 1 
 ]
  [ Inserted: uid 0 pid 22438 State Creations: 21]
 @1 pass out log quick on vio0 inet proto tcp from any to any port = 80 flags 
 S/SA divert-reply
  [ Evaluations: 49Packets: 194   Bytes: 43964   States: 1 
 ]
  [ Inserted: uid 0 pid 22438 State Creations: 21]
 @2 pass all flags S/SA
  [ Evaluations: 50Packets: 93Bytes: 13453   States: 6 
 ]
  [ Inserted: uid 0 pid 22438 State Creations: 50]
 
 [17:35:54] root:~ # tcpdump -n -e -ttt -i pflog0
 tcpdump: WARNING: snaplen raised from 116 to 160
 tcpdump: listening on pflog0, link-type PFLOG
 May 23 17:36:13.429174 rule 0/(match) pass in on vio1: 192.168.15.13.38330  
 74.125.234.238.80: S 2238109532:2238109532(0) win 14600 mss 
 1460,sackOK,timestamp 45163358 0,nop,wscale 7 (DF)
 tcpdump: WARNING: compensating for unaligned libpcap packets
 May 23 17:36:13.429228 rule 1/(match) pass out on vio0: 192.168.15.13.38330  
 74.125.234.238.80: S 2238109532:2238109532(0) win 14600 mss 
 1460,sackOK,timestamp 45163358 0,nop,wscale 7 (DF)
 
 but, command nc not receiving any packet or connection.
 
 divert-to not working with bridge ?
 
 My reference is this - 
 http://wiki.squid-cache.org/ConfigExamples/Intercept/OpenBsdPf
 
 Thanks
 
 ---
 Luiz Gustavo Costa (Powered by BSD)
 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+
 mundoUnix - Consultoria em Software Livre
 http://www.mundounix.com.br
 ICQ: 2890831 / MSN: cont...@mundounix.com.br
 Tel: 55 (21) 4063-7110 / 8194-1905 / (11) 4063-0407
 Blog: http://www.luizgustavo.pro.br

Re: OpenBSD on Ouya/Tegra3

[Patrick Wildt]

I don't know much about Ouya or the Tegra3, but usually you'll
need to ask the following:

a) Can I access the bootloader? (Is it u-boot? Can I boot my own stuff?)
b) Is there an (easily) accessible serial console?
c) How good is the documentation?

Once that's solved it's probably not that hard to port OpenBSD.
You just have to adjust some addresses and write drivers.
UART is the starting point there.

Also, see inline comments.

\Patrick

Am 24.05.2013 um 05:17 schrieb jordon open...@sirjorj.com:

 With Ouya consoles starting to make it to market, I'm wondering if
 there's a chance that OpenBSD could be ported to it.  This is something
 I would love to help with but have no idea where to begin.  The
 documentation for the Tegra3 is available from nvidia's website, though
 you have to register and then request access to the Tegra section (I
 left most of the questions blank and just put I want to see the
 documentation for the reasons and was granted access in about 3
 minutes).
 
 I have some microcontroller experience (PIC18 and currently playing
 with a PIC32), and I did play with an ARM dev kit for a bit a long time
 ago, but I have some questions on how OpenBSD/ARM works.  When I was
 working with an ARM, the entire program was stored in the on-chip flash
 memory - like a microcontroller.  With a larger OS like OpenBSD, what
 is stored on the chip and what is loaded from external storage?  Is the
 entire kernel stored on chip or just a bootloader?

Beagle- and PandaBoard don't seem to have on-chip flash, the whole
system is stored on external storage (sdcard, usb).
There are other boards though, which have their system on on-chip flash.

 As I understand, not all ARM chips are equal - each one pretty much
 needs its own port, and currently BeagleBoard is the main one getting
 worked on.  Right?

All BeagleBoard, BeagleBone and PandaBoard. They all work with
the beagle port.

 So... is this worth pursuing?  The idea of a $99 cube that could run
 OpenBSD is pretty intriguing, but how possible is it?  Are there
 licensing strings attached to Tegra3 that would make this difficult?

No idea. It really depends on how accessible it is (in terms of booting
custom stuff and having a serial console). And, of course, if blobs
are needed for (proper) usage.

 jordon

Re: Openbsd openrisc opencores arm

[Patrick Wildt]

Am 25.03.2013 um 17:17 schrieb Chris Cappuccio ch...@nmedia.net:

 Nick Holland [n...@holland-consulting.net] wrote:

 The problem with ARM is there is no ARM reference platform.
 Every machine is significantly different than every other machine,
 technical details of how it is built are not published (why should they
 be? They aren't being sold as general purpose computers).

 I do not get the excitement over ARM.  Sorry.  Its design complete and
 total chaos at this point.

 There is maybe one sort-of exception to this mess:

 The openly documented Freescale iMX6 platform.


http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX6QnodeId=
018rH3ZrDRB24Afpsp=1tab=Documentation_Tab

 It could stay around for a while. There is an open laptop
 design built around it that looks like fun:

 http://www.bunniestudios.com/blog/?p=2686

 And a certain Dale Rahn even wrote support for iMX6 in a source
 tree that could drop in to OpenBSD...

 If someone really wants to play with newer ARM stuff on OpenBSD,
 try to find some iMX6 hardware, and start with Dale's improved
 sys/arch/arm, sys/arch/imx and sys/arch/beagle

I have all that running on OpenBSD. I'm slowly sorting out diffs so we can get
it (armv7, panda, imx) into OpenBSD without breaking zaurus.
Without that constrain, I could basically just drop it in.

I'd recommend one of the following, where I got the first one from:
http://boundarydevices.com/products/sabre-lite-imx6-sbc/
http://boundarydevices.com/products/nitrogen6x-board-imx6-arm-cortex-a9-sbc/

Of course, there are other boards, even tablets and mini-usb/hdmi-sticks, but
those boards are imho very good.


 Chris

Re: Running OpenBSD on Raspberry Pi

[Patrick Wildt]

Hello,

I'm currently working on porting OpenBSD to the Freescale i.MX6, an ARM
Cortex-A9 (1-4 cores).
It is already supporting USB and SDMMC, works like a charm.
The i.MX6 itself got some interesting features like PCIe, SATA and Gigabit
Ethernet.

So, if 200$ don't sound too much, that might be an alternative.

\Patrick

http://boundarydevices.com/products/sabre-lite-imx6-sbc/
http://boundarydevices.com/products/nitrogen6x-board-imx6-arm-cortex-a9-sbc/

Am 09.01.2013 um 20:21 schrieb Gene gh5...@gmail.com:

 On Wed, Jan 9, 2013 at 10:54 AM, Andres Genovez andresgeno...@gmail.com
wrote:
 2012/12/31 BARDOU Pierre bardo...@mipih.fr

 Hello,

 I would be very interested by an OpenBSD port too.
 Usage : home router with firewall, DNS and DHCP.

 I am looking into FreeBSD and NetBSD ports, but I would prefer to have
the
 latest PF and OpenSSH versions... plus I am more used to OpenBSD and I
like
 using it :-)

 If somebody knows X86 hardware able to do the same (routing/firewlling 20
 mbps traffic, VLAN, fits in a tiny box, power consumption below 5W, price
 around 50$) as the raspberry I am interested BTW.

 I am interested too, can somebody give an advice on what hardware to use?
 maybe 5 lan or at least two lan? an below 100?


 For under $100 USD your best bet is to look for a used computer on
 craigslist or a yard sale and install another NIC in it.  But, this
 will not get you at 5 watts or less.

 For under $200 look at either PC Engines ALIX boards or Soekris.  eBay
 has plenty of them.  You can manage 5W or less this route.

 For the Raspberry Pi you will not get OpenBSD.  You will have to use
 Linux and configure it manually, including recompiling the kernel with
 iptables support.  You *might* be able to get under $100, but it won't
 be under 5 watts and it will be a jalopy.  USB ethernet adapters start
 around $25 new.

 -Gene