Re: is anyone maintaining hifn(4)?

[emily ingalls <emily@ingalls.rocks>]

> Can you be more specific about the issues?  Can you say more about
> your use case?

i'll go into one of the issues in more detail below.

as far as my use case goes, i have quite a lot of old and slow hardware, which is one of the reasons i use and like netbsd, since it works on all of it. i like to test modern software with this hardware under netbsd, and fix issues when they crop up. much of my hardware is usable for many things, but consistently are slowed to a crawl by cryptographic operations. 

as an example, one of my 486 machines is currently running a rust-based server for the matrix chat protocol, called conduit (i have some other patches related to this that i'm going to be sending as well, in other parts of the kernel, which may serve to reduce userland maintenance burden related to 486 systems). it runs surprisingly well, but my experience with this and other servers on this machine is that tls is the slowest and most resource intensive part of the server. since these cards are already able to accelerate tls 1.2 via accelerating aes in cbc-mode, i'm interested in ensuring they work with the entire software stack, and installing them in several of my machines. if possible, i would also like this card to be able to accelerate aes in ccm-mode and gcm-mode. the chip offers acceleration for aes-ctr, which people who know more about aes than i do tell me should be usable for this purpose, so down the line i want to investigate that.

also, since soekris was the primary source of these cards that i am aware of, and they are no longer manufacturing them (and the remainder of their stock is presumably dwindling), i have been considering sourcing some hifn chips and producing new cards of my own. with an open source board design, for people with similar needs.

> What do you mean by `currently disabled'?  It looks like hifn(4) is
> included in amd64/GENERIC and i386/GENERIC, at least.

i saw a commit from 2020 that mentioned disabling hifn. i haven't tested this or tried to build hifn on current, so if this is wrong then just ignore me.

> If you have any patches, I'd be happy to take a look.  (Can't test on
> my device right now but I'll eventually have access to it again.)

sure. a small patch follows, which fixes three things:

first, the original code programmed a value that set a bit which is supposed to be disabled. since the reserved registers are not all zero, i assume them to be meaningful, and so this could cause undefined behavior in the chip's operation. 

second, the PLL register is hard-configured to rely on the host bus clock, and sets a fixed multiplier value based on that. the host bus clock is not necessarily stable or known, so this is not the best approach - since the device is pci 2.1 compatible and can support a 66mhz bus (and will report this), it's possible for it to be overclocked to twice what it is rated for. on other systems with slower bus clocks, it is possible that it could be underclocked. i looked at the hardware that i have (soekris vpn1401) as well as photos of all hifn7954/7955/7956 hardware i could find, and they appear all to have 33mhz reference clocks. since netbsd does not seem to have a way to query bus speed, i rewrote the register to instead rely on the onboard reference clock.

finally, the datasheet emphasizes a specific set of operations for correctly programming the PLL register, and says that doing otherwise may result in incorrect operation. i updated the code to do this, which requires three separate values to be programmed in order to reach the final setting, with a delay between.

i've tested this on several machines - on all the machines i have that already work with this card, it behaves identically in speed and correctness of operation. on a 486 machine with PCI that is my intended target for this card, the original driver would cause the machine to hang with no output during boot. with the new code, this no longer happens. i noticed that there's a similar reported issue with the soekris net4501 router hardware. i will soon own that hardware and will be testing with that as well.  there is still error on the 486 while enabling the card's cryptographic engine that i have not yet tracked down, but it does at least boot reliably now. expect a future patch once i find the issue.

if it's possible, at some point in the future i'd like to rewrite the driver so that the clock source and multiplier are configurable, rather than using a hard-coded value.

diff -r a/sys/dev/pci/hifn7751reg.h b/sys/dev/pci/hifn7751reg.h
364c364,373
< #define       HIFN_PLL_7956           0x00001d18      /* 7956 PLL config value */
---
> 
> /* 7956 PLL config values 
>  *
>  * set PLL to use onboard reference, rather than a potentially
>  * unknown and unstable bus clock. setting PLL correctly requires
>  * three steps. 
>  */
> #define HIFN_PLL_7956_INIT    0x00001c03 /* initial state, setting pll clock source */
> #define HIFN_PLL_7956_INIT2   0x00001c01 /* after PLL stabilizes, clear PLL bypass bit */
> #define       HIFN_PLL_7956           0x00001c19 /* set packet and key engines to use PLL */
hakase$ diff -u -p1 -r a/sys/dev/pci b/sys/dev/pci
diff: `-1' option is obsolete; use `-U 1'
diff: Try `diff --help' for more information.
hakase$ diff -u -r a/sys/dev/pci b/sys/dev/pci     
diff -u -r a/sys/dev/pci/hifn7751.c b/sys/dev/pci/hifn7751.c
--- a/sys/dev/pci/hifn7751.c    2018-12-27 06:03:54.000000000 -0800
+++ b/sys/dev/pci/hifn7751.c    2021-07-17 23:42:13.371790047 -0700
@@ -1073,6 +1073,17 @@
                WRITE_REG_0(sc, HIFN_0_PUCNFG, HIFN_PUCNFG_COMPSING |
                    HIFN_PUCNFG_TCALLPHASES |
                    HIFN_PUCNFG_TCDRVTOTEM | HIFN_PUCNFG_BUS32);
+               /* per datasheet: set PLL speed and charge current,
+                * and turn on the PLL bypass */
+               WRITE_REG_1(sc, HIFN_1_PLL, HIFN_PLL_7956_INIT);
+               /* then, wait at least 10ms for the PLL to lock */
+               kpause("hifnpll", false, mstohz(10), NULL);
+               /* then, disable PLL bypass */
+               WRITE_REG_1(sc, HIFN_1_PLL, HIFN_PLL_7956_INIT2);
+               /* pause again for good measure */
+               kpause("hifnpll", false, mstohz(10), NULL);
+               /* write the final PLL config value, with packet engine and
+                * key engine set to use the PLL output */
                WRITE_REG_1(sc, HIFN_1_PLL, HIFN_PLL_7956);
        } else {
                WRITE_REG_0(sc, HIFN_0_PUCNFG, HIFN_PUCNFG_COMPSING |
diff -u -r a/sys/dev/pci/hifn7751reg.h b/sys/dev/pci/hifn7751reg.h
--- a/sys/dev/pci/hifn7751reg.h 2005-12-11 04:22:49.000000000 -0800
+++ b/sys/dev/pci/hifn7751reg.h 2021-07-17 23:42:13.372045735 -0700
@@ -361,7 +361,16 @@
 /*
  * PLL config register
  */
-#define        HIFN_PLL_7956           0x00001d18      /* 7956 PLL config value */
+
+/* 7956 PLL config values 
+ *
+ * set PLL to use onboard reference, rather than a potentially
+ * unknown and unstable bus clock. setting PLL correctly requires
+ * three steps. 
+ */
+#define HIFN_PLL_7956_INIT     0x00001c03 /* initial state, setting pll clock source */
+#define HIFN_PLL_7956_INIT2    0x00001c01 /* after PLL stabilizes, clear PLL bypass bit */
+#define        HIFN_PLL_7956           0x00001c19 /* set packet and key engines to use PLL */
 
 /*********************************************************************
  * Structs for board commands
hakase$ diff -u -r a/sys/dev/pci b/sys/dev/pci 
diff -u -r a/sys/dev/pci/hifn7751.c b/sys/dev/pci/hifn7751.c
--- a/sys/dev/pci/hifn7751.c    2018-12-27 06:03:54.000000000 -0800
+++ b/sys/dev/pci/hifn7751.c    2021-07-17 23:42:13.371790047 -0700
@@ -1073,6 +1073,17 @@
                WRITE_REG_0(sc, HIFN_0_PUCNFG, HIFN_PUCNFG_COMPSING |
                    HIFN_PUCNFG_TCALLPHASES |
                    HIFN_PUCNFG_TCDRVTOTEM | HIFN_PUCNFG_BUS32);
+               /* per datasheet: set PLL speed and charge current,
+                * and turn on the PLL bypass */
+               WRITE_REG_1(sc, HIFN_1_PLL, HIFN_PLL_7956_INIT);
+               /* then, wait at least 10ms for the PLL to lock */
+               kpause("hifnpll", false, mstohz(10), NULL);
+               /* then, disable PLL bypass */
+               WRITE_REG_1(sc, HIFN_1_PLL, HIFN_PLL_7956_INIT2);
+               /* pause again for good measure */
+               kpause("hifnpll", false, mstohz(10), NULL);
+               /* write the final PLL config value, with packet engine and
+                * key engine set to use the PLL output */
                WRITE_REG_1(sc, HIFN_1_PLL, HIFN_PLL_7956);
        } else {
                WRITE_REG_0(sc, HIFN_0_PUCNFG, HIFN_PUCNFG_COMPSING |
diff -u -r a/sys/dev/pci/hifn7751reg.h b/sys/dev/pci/hifn7751reg.h
--- a/sys/dev/pci/hifn7751reg.h 2005-12-11 04:22:49.000000000 -0800
+++ b/sys/dev/pci/hifn7751reg.h 2021-07-17 23:42:13.372045735 -0700
@@ -361,7 +361,16 @@
 /*
  * PLL config register
  */
-#define        HIFN_PLL_7956           0x00001d18      /* 7956 PLL config value */
+
+/* 7956 PLL config values 
+ *
+ * set PLL to use onboard reference, rather than a potentially
+ * unknown and unstable bus clock. setting PLL correctly requires
+ * three steps. 
+ */
+#define HIFN_PLL_7956_INIT     0x00001c03 /* initial state, setting pll clock source */
+#define HIFN_PLL_7956_INIT2    0x00001c01 /* after PLL stabilizes, clear PLL bypass bit */
+#define        HIFN_PLL_7956           0x00001c19 /* set packet and key engines to use PLL */
 
 /*********************************************************************
  * Structs for board commands