Re: SCHED_LOCK vs 'struct proc'

[Ian Sutton]

On Sat, May 11, 2019 at 07:23:42PM -0400, Martin Pieuchot wrote:
> Document which fields are protected by the SCHED_LOCK(), ok?
> 
> Index: sys/proc.h
> ===
> RCS file: /cvs/src/sys/sys/proc.h,v
> retrieving revision 1.263
> diff -u -p -r1.263 proc.h
> --- sys/proc.h6 Jan 2019 12:59:45 -   1.263
> +++ sys/proc.h11 May 2019 23:21:57 -
> @@ -297,8 +297,12 @@ struct process {
>  struct kcov_dev;
>  struct lock_list_entry;
>  
> +/*
> + *  Locks used to protect struct members in this file:
> + *   s   scheduler lock
> + */
>  struct proc {
> - TAILQ_ENTRY(proc) p_runq;
> + TAILQ_ENTRY(proc) p_runq;   /* [s] current run/sleep queue */
>   LIST_ENTRY(proc) p_list;/* List of all threads. */
>  
>   struct  process *p_p;   /* The process of this thread. */
> @@ -314,7 +318,7 @@ struct proc {
>  
>   int p_flag; /* P_* flags. */
>   u_char  p_spare;/* unused */
> - charp_stat; /* S* process status. */
> + charp_stat; /* [s] S* process status. */
>   charp_pad1[1];
>   u_char  p_descfd;   /* if not 255, fdesc permits this fd */
>  
> @@ -328,17 +332,17 @@ struct proc {
>   longp_thrslpid; /* for thrsleep syscall */
>  
>   /* scheduling */
> - u_int   p_estcpu;/* Time averaged value of p_cpticks. */
> + u_int   p_estcpu;   /* [s] Time averaged val of p_cpticks */
>   int p_cpticks;   /* Ticks of cpu time. */
> - const volatile void *p_wchan;/* Sleep address. */
> + const volatile void *p_wchan;   /* [s] Sleep address. */
>   struct  timeout p_sleep_to;/* timeout for tsleep() */
> - const char *p_wmesg; /* Reason for sleep. */
> - fixpt_t p_pctcpu;/* %cpu for this thread */
> - u_int   p_slptime;   /* Time since last blocked. */
> + const char *p_wmesg;/* [s] Reason for sleep. */
> + fixpt_t p_pctcpu;   /* [s] %cpu for this thread */
> + u_int   p_slptime;  /* [s] Time since last blocked. */
>   u_int   p_uticks;   /* Statclock hits in user mode. */
>   u_int   p_sticks;   /* Statclock hits in system mode. */
>   u_int   p_iticks;   /* Statclock hits processing intr. */
> - struct  cpu_info * volatile p_cpu; /* CPU we're running on. */
> + struct  cpu_info * volatile p_cpu; /* [s] CPU we're running on. */
>  
>   struct  rusage p_ru;/* Statistics */
>   struct  tusage p_tu;/* accumulated times. */
> @@ -357,8 +361,8 @@ struct proc {
>   vaddr_t  p_spstart;
>   vaddr_t  p_spend;
>  
> - u_char  p_priority; /* Process priority. */
> - u_char  p_usrpri;   /* User-priority based on p_estcpu and ps_nice. 
> */
> + u_char  p_priority; /* [s] Process priority. */
> + u_char  p_usrpri;   /* [s] User-prio based on p_estcpu & ps_nice. */
>   int p_pledge_syscall;   /* Cache of current syscall */
>  
>   struct  ucred *p_ucred; /* cached credentials */
>

I've checked the [s]-marked members, this is correct from my point of
view

ok ians@

Re: Please test: HZ bump

[Ian Sutton]

On Mon, Aug 14, 2017 at 3:07 PM Martin Pieuchot  wrote:
>
> I'd like to improve the fairness of the scheduler, with the goal of
> mitigating userland starvations.  For that the kernel needs to have
> a better understanding of the amount of executed time per task.
>
> The smallest interval currently usable on all our architectures for
> such accounting is a tick.  With the current HZ value of 100, this
> smallest interval is 10ms.  I'd like to bump this value to 1000.
>
> The diff below intentionally bump other `hz' value to keep current
> ratios.  We certainly want to call schedclock(), or a similar time
> accounting function, at a higher frequency than 16 Hz.  However this
> will be part of a later diff.
>
> I'd be really interested in test reports.  mlarkin@ raised a good
> question: is your battery lifetime shorter with this diff?
>
> Comments, oks?
>

I'd like to revisit this patch. It makes our armv7 platform more
usable for what it is meant to do, i.e. be a microcontroller. I
imagine on other platforms it would accrue similar benefits as well.

I've tested this patch and found delightfully proportional results.
Currently, at HZ = 100, the minimum latency for a sleep calll from
userspace is about 10ms:

https://ce.gl/baseline.jpg

After the patch, which bumps HZ from 100 --> 1000, we see a tenfold
decrease in this latency:

https://ce.gl/with-mpi-hz-patch.jpg

This signal is generated with gpio(4) ioctl calls from userspace,
e.g.: for(;;) { HI(pin); usleep(1); LO(pin(); usleep(1); }

I'd like to see more folks test and other devs to share their
thoughts: What are the risks associated with bumping HZ globally?
Drawbacks? Reasons for hesitation?

Thanks,
Ian Sutton



> Index: conf/param.c
> ===
> RCS file: /cvs/src/sys/conf/param.c,v
> retrieving revision 1.37
> diff -u -p -r1.37 param.c
> --- conf/param.c6 May 2016 19:45:35 -   1.37
> +++ conf/param.c14 Aug 2017 17:03:23 -
> @@ -76,7 +76,7 @@
>  # define DST 0
>  #endif
>  #ifndef HZ
> -#defineHZ 100
> +#defineHZ 1000
>  #endif
>  inthz = HZ;
>  inttick = 100 / HZ;
> Index: kern/kern_clock.c
> ===
> RCS file: /cvs/src/sys/kern/kern_clock.c,v
> retrieving revision 1.93
> diff -u -p -r1.93 kern_clock.c
> --- kern/kern_clock.c   22 Jul 2017 14:33:45 -  1.93
> +++ kern/kern_clock.c   14 Aug 2017 19:50:49 -
> @@ -406,12 +406,11 @@ statclock(struct clockframe *frame)
> if (p != NULL) {
> p->p_cpticks++;
> /*
> -* If no schedclock is provided, call it here at ~~12-25 Hz;
> +* If no schedclock is provided, call it here;
>  * ~~16 Hz is best
>  */
> if (schedhz == 0) {
> -   if ((++curcpu()->ci_schedstate.spc_schedticks & 3) ==
> -   0)
> +   if ((spc->spc_schedticks & 0x3f) == 0)
> schedclock(p);
> }
> }
> Index: arch/amd64/isa/clock.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/isa/clock.c,v
> retrieving revision 1.25
> diff -u -p -r1.25 clock.c
> --- arch/amd64/isa/clock.c  11 Aug 2017 21:18:11 -  1.25
> +++ arch/amd64/isa/clock.c  14 Aug 2017 17:19:35 -
> @@ -303,8 +303,8 @@ rtcdrain(void *v)
>  void
>  i8254_initclocks(void)
>  {
> -   stathz = 128;
> -   profhz = 1024;
> +   stathz = 1024;
> +   profhz = 8192;
>
> isa_intr_establish(NULL, 0, IST_PULSE, IPL_CLOCK, clockintr,
> 0, "clock");
> @@ -321,7 +321,7 @@ rtcstart(void)
>  {
> static struct timeout rtcdrain_timeout;
>
> -   mc146818_write(NULL, MC_REGA, MC_BASE_32_KHz | MC_RATE_128_Hz);
> +   mc146818_write(NULL, MC_REGA, MC_BASE_32_KHz | MC_RATE_1024_Hz);
> mc146818_write(NULL, MC_REGB, MC_REGB_24HR | MC_REGB_PIE);
>
> /*
> @@ -577,10 +577,10 @@ setstatclockrate(int arg)
> if (initclock_func == i8254_initclocks) {
> if (arg == stathz)
> mc146818_write(NULL, MC_REGA,
> -   MC_BASE_32_KHz | MC_RATE_128_Hz);
> +   MC_BASE_32_KHz | MC_RATE_1024_Hz);
> else
> mc146818_write(NULL, MC_REGA,
> -   MC_BASE_32_KHz | MC_RATE_1024_Hz);
> +   MC_BASE_32_KHz | MC_RATE_8192_Hz);
> }
>  }
>
> Index: arch/armv7/omap/dmtimer.c
>

Re: memory leak in amdisplay_attach()

[Ian Sutton]

On Tue, Sep 18, 2018 at 2:16 AM, Jonathan Gray  wrote:
> On Tue, Sep 18, 2018 at 08:34:55AM +0200, Claudio Jeker wrote:
>> On Tue, Sep 18, 2018 at 03:49:15PM +1000, Jonathan Gray wrote:
>> > Index: amdisplay.c
>> > ===
>> > RCS file: /cvs/src/sys/arch/armv7/omap/amdisplay.c,v
>> > retrieving revision 1.7
>> > diff -u -p -r1.7 amdisplay.c
>> > --- amdisplay.c 25 Oct 2017 14:34:22 -  1.7
>> > +++ amdisplay.c 18 Sep 2018 05:12:41 -
>> > @@ -272,6 +272,7 @@ amdisplay_attach(struct device *parent,
>> >
>> > if (rasops_init(>sc_ro, 200, 200)) {
>> > printf("%s: no rasops\n", DEVNAME(sc));
>> > +   free(edid_buf, M_DEVBUF, EDID_LENGTH);
>> > amdisplay_detach(self, 0);
>> > return;
>> > }
>> >
>>
>> I think it is better to free the edid_buf further up in that function
>> since it is unused after calling edid_parse(edid_buf, >sc_edid) on
>> line 215. So currently there is still a leak at the end of the function.
>
> sounds good to me, ok
>
>>
>> --
>> :wq Claudio
>>
>> Index: arch/armv7/omap/amdisplay.c
>> ===
>> RCS file: /cvs/src/sys/arch/armv7/omap/amdisplay.c,v
>> retrieving revision 1.7
>> diff -u -p -r1.7 amdisplay.c
>> --- arch/armv7/omap/amdisplay.c   25 Oct 2017 14:34:22 -  1.7
>> +++ arch/armv7/omap/amdisplay.c   18 Sep 2018 06:32:43 -
>> @@ -219,6 +219,8 @@ amdisplay_attach(struct device *parent,
>>   return;
>>   }
>>
>> + free(edid_buf, M_DEVBUF, EDID_LENGTH);
>> +
>>  #ifdef LCD_DEBUG
>>   edid_print(>sc_edid);
>>  #endif
>> @@ -246,7 +248,6 @@ amdisplay_attach(struct device *parent,
>>   /* configure DMA framebuffer */
>>   if (amdisplay_setup_dma(sc)) {
>>   printf("%s: couldn't allocate DMA framebuffer\n", DEVNAME(sc));
>> - free(edid_buf, M_DEVBUF, EDID_LENGTH);
>>   amdisplay_detach(self, 0);
>>   return;
>>   }
>>
>

I've tested Claudio's diff on my suite of BBB's, this patch is fine.

ok ians@

[patch] upon install of new operating system version, do not set root password to empty string

[Ian Sutton]

This is a highly theoretical and experimental mitigation which stops the
root password on newly upgraded/installed systems from being an empty
string. The thinking is that by not shipping an operating system with a
known root password, certain classes of attacks involving logging into
the root account might be avoided. I would like some feedback from the
cryptography team as well as NIST finalists in order to better ascertain
the implications of this behaviour.

Index: src/distrib/miniroot/install.sub
===
RCS file: /cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.1032
diff -u -p -r1.1032 install.sub
--- src/distrib/miniroot/install.sub8 Aug 2017 07:14:05 -   1.1032
+++ src/distrib/miniroot/install.sub28 Nov 2017 23:43:56 -
@@ -2732,12 +2732,6 @@ do_install() {
 
echo
 
+   while :; do
+   ask_password "Password for root account?"
+   _rootpass="$_password"
+   [[ -n "$_password" ]] && break
+   echo "The root password must be set."
+   done
 
# Ask for the root user public ssh key during autoinstall.
_rootkey=

Re: some cvstags

[Ian Sutton]

On Fri, Sep 01, 2017 at 12:17:29AM +0300, Artturi Alm wrote:
> Hi,
> 
> rather obvious diff below.
> 
> -Artturi

Thanks, committed 

Re: [patch] httpd: don't add date header if already set

[Ian Sutton]

committed, thanks

Re: armv7/omap: introducing amdisplay(4) + nxptda(4)

[Ian Sutton]

On Mon, Apr 03, 2017 at 01:33:28AM -0400, Ian Sutton wrote:
> The code below is a complete (fourth!) rewrite. It completely and
> correctly controls the hardware but still needs to be plugged into the
> rest of the system (wsdisplay for syscons, wsfb for Xorg, etc.) before
> it is useful. In the meantime, I feel that it is review-ready and worth

amdisplay(4) now plugs into wsdisplay(4) allowing Xorg to run via wsfb(4)
driver:

https://ce.gl/hooraydisplay.png

Additionally, amdisplay(4) also now supports higher resolutions, choosing the
highest mode the monitor purports to support or the highest mode the LCDC
is capable of running, whichever comes first (I think the max for now is
1600x1200@60).

I feel this driver is functionally complete at this point and now needs wiser
eyes than mine for review. It is a functional piece of software. Patch, compile,
`startx`.

There are some unavoidable caveats worth mentioning.

A silicon bug scrambled the bit ordering of pixel information in the 
framebuffer. So
long as rasops requires each color's bits to be contiguous we are stuck at 
16bpp.

The USB host controller on the am335x isn't EHCI compatible and is currently
unsupported, the only direct interface with the board is via a com(4) ftdi
serial port that doesn't provide a wskbd(4) device which Xorg demands. None
of the config options that would seem to suggest allowing you to bypass this
work, but removing the xf86-input-kbd object files does (?). I'm not sure 
whether
it's appropriate to fix this in xenocara or through something like comkbd(4).

Very thrilled to finally get this working!
Ian

Index: share/man/man4/man4.armv7/amdisplay.4
===
RCS file: share/man/man4/man4.armv7/amdisplay.4
diff -N share/man/man4/man4.armv7/amdisplay.4
--- /dev/null   1 Jan 1970 00:00:00 -
+++ share/man/man4/man4.armv7/amdisplay.4   16 Apr 2017 03:33:08 -
@@ -0,0 +1,73 @@
+.\" Copyright (c) 2017 Ian Sutton <i...@ce.gl>$
+.\"
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies.
+.\"
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+.\"
+.Dd $Mdocdate: April 2 2017 $
+.Dt AMDISPLAY 4 armv7
+.Os
+.Sh NAME
+.Nm amdisplay ,
+.Nm nxptda
+.Nd Texas Instruments AM335x LCD display driver
+.Sh SYNOPSIS
+.Nm "amdisplay* at simplebus0"
+.Nm "nxptda* at iic*"
+.Nm "wsdisplay* at amdisplay*"
+.Sh DESCRIPTION
+The
+.Nm
+driver supports the LCD controller integrated in Texas Instruments' line of
+AM335x SoCs.
+The LCDC reads a framebuffer from memory via DMA and scans it out
+at the proper frequency to suit a display (along with the nessecary
+hsync/vsync/etc signals) to a PHY transmitter.
+The BeagleBone Black uses
+NXP/Freescale's TDA19988 HDMI transmitter which is additionally supported by 
the
+.Nm nxptda
+driver.
+.Sh SEE ALSO
+.Xr intro 4 ,
+.Xr wsdisplay 4 ,
+.Xr wsfb 4
+.Sh HISTORY
+The
+.Nm
+driver does not appear in
+.Ox 6.1
+currently.
+.Sh AUTHORS
+.An -nosplit
+The
+.Nm
+driver was written by
+.An Ian Sutton Aq Mt i...@ce.gl .
+The
+.Nm nxptda
+driver was written by
+.An Oleksandr Tymoshenko Aq Mt go...@freebsd.org
+and later ported to OpenBSD.
+.Sh CAVEATS
+On the BeagleBone Black, the LCDC and onboard eMMC NAND chip share the same set
+of pads such that only one can be wired and used at a time.
+If you wish to boot from or use the onboard storage, you must disable
+.Nm
+via
+.Xr config 8
+in your kernel.
+.Pp
+Display must be attached at boot time, otherwise
+.Nm
+will fail to configure.
+Hotplugging is not supported.
+.Pp
+Only 16 bit color depth is supported due to a silicon bug.
Index: sys/arch/armv7/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/armv7/conf/GENERIC,v
retrieving revision 1.71
diff -u -p -r1.71 GENERIC
--- sys/arch/armv7/conf/GENERIC 23 Jan 2017 22:43:17 -  1.71
+++ sys/arch/armv7/conf/GENERIC 16 Apr 2017 03:33:23 -
@@ -81,6 +81,9 @@ sdmmc*at ommmc?   # SD/MMC bus
 
 omehci*at fdt? # EHCI
 usb*   at omehci?
+nxptda*at iic? # TDA19988 HDMI PHY
+amdisplay* at fdt? # AM335x LCD controller
+wsdisp

armv7/omap: introducing amdisplay(4) + nxptda(4)

[Ian Sutton]

This patch introduces preliminary support for the display hardware
onboard the am335x/BeagleBone Black. Included are two drivers,
amdisplay(4) and nxptda(4), which run the LCD controller and HDMI PHY
transmitter respectively. This patch follows work I've mailed to this
list found here:

https://marc.info/?t=14704720461=1=2

The code below is a complete (fourth!) rewrite. It completely and
correctly controls the hardware but still needs to be plugged into the
rest of the system (wsdisplay for syscons, wsfb for Xorg, etc.) before
it is useful. In the meantime, I feel that it is review-ready and worth
the time for a dev to look over.

Here is a demonstration of my code working where the framebuffer is
filled with entropy from arc4random_buf() every frame:

https://www.youtube.com/watch?v=yCzFyZlfbzQ

Here is the man page in HTML format for convenience:

https://ce.gl/amdisplay.4.html

Here is a link to the patch below for when the list mangles it:

https://ce.gl/amdisplay-apr2.diff.txt

Note: this driver currently only supports 640x480x16 mode, but is only
one clock/math problem away from higher modes. Yes, I am aware of fdt
simple-framebuffer node and yes, this code accomplishes useful things
which the fdt framebuffer cannot.

Ian

Index: sys/arch/armv7/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/armv7/conf/GENERIC,v
retrieving revision 1.71
diff -u -p -p -u -r1.71 GENERIC
--- sys/arch/armv7/conf/GENERIC 23 Jan 2017 22:43:17 -  1.71
+++ sys/arch/armv7/conf/GENERIC 3 Apr 2017 05:24:32 -
@@ -81,6 +81,9 @@ sdmmc*at ommmc?   # SD/MMC bus
 
 omehci*at fdt? # EHCI
 usb*   at omehci?
+nxptda*at iic? # TDA19988 HDMI PHY
+amdisplay* at fdt? # AM335x LCD controller
+wsdisplay* at amdisplay?
 
 # Sunxi A1x/A20 SoC
 sxiintc*   at fdt? # A1x interrupt controller
Index: sys/arch/armv7/omap/am335x_prcmreg.h
===
RCS file: /cvs/src/sys/arch/armv7/omap/am335x_prcmreg.h,v
retrieving revision 1.4
diff -u -p -p -u -r1.4 am335x_prcmreg.h
--- sys/arch/armv7/omap/am335x_prcmreg.h18 Mar 2014 07:34:17 -  
1.4
+++ sys/arch/armv7/omap/am335x_prcmreg.h3 Apr 2017 05:24:33 -
@@ -20,6 +20,7 @@
 #define AM335X_CLKCTRL_MODULEMODE_MASK 0x0003
 
 #define PRCM_AM335X_CM_PER 0x
+#define PRCM_AM335X_LCDC_CLKCTRL   0x0018
 #define PRCM_AM335X_USB0_CLKCTRL   0x001c
 #define PRCM_AM335X_TPTC0_CLKCTRL  0x0024
 #define PRCM_AM335X_MMC0_CLKCTRL   0x003c
@@ -38,6 +39,10 @@
 #define PRCM_AM335X_CM_WKUP0x0400
 #define PRCM_AM335X_GPIO0_CLKCTRL  0x0408
 #define PRCM_AM335X_TIMER0_CLKCTRL 0x0410
+#define PRCM_AM335X_DISP_IDLEST0x0448
+#define PRCM_AM335X_DISP_CLKSEL0x0454
+#define PRCM_AM335X_DISP_CLKMODE   0x0498
+#define PRCM_AM335X_DISP_M20x04a4
 #define PRCM_AM335X_I2C0_CLKCTRL   0x04b8
 #define PRCM_AM335X_CM_DPLL0x0500
 #define PRCM_AM335X_CLKSEL_TIMER2_CLK  0x0508
Index: sys/arch/armv7/omap/amdisplay.c
===
RCS file: sys/arch/armv7/omap/amdisplay.c
diff -N sys/arch/armv7/omap/amdisplay.c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ sys/arch/armv7/omap/amdisplay.c 3 Apr 2017 05:24:33 -
@@ -0,0 +1,628 @@
+/*
+ * Copyright (c) 2016 Ian Sutton <i...@kremlin.cc>
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#ifdef LCD_DEBUG
+int lcd_dbg_thresh = 20;
+#define DPRINTF(n,s)   do { if ((n) <= lcd_dbg_thresh) printf s; } while (0)
+#else
+#define DPRINTF(n,s)   do {} while (0)
+#endif
+
+#define str(X) #X
+#define DEVNAME(_s) ((_s)->sc_dev.dv_xname)
+#define PALETTE_BPP 0x4000
+
+#define HREAD4(sc, reg)
\
+   (bus_space_read_4((sc)->sc_iot, (sc)->sc_ioh, (reg)))
+

videomode/edid.c: conditionally print mode details

[Ian Sutton]

Only print details about parsed EDID blocks if -DDIAGNOSTIC, consistent
with the surrounding printf()'s.

Ian

Index: edid.c
===
RCS file: /cvs/src/sys/dev/videomode/edid.c,v
retrieving revision 1.3
diff -u -p -r1.3 edid.c
--- edid.c  5 Dec 2012 23:20:22 -   1.3
+++ edid.c  11 Mar 2017 06:03:25 -
@@ -594,8 +594,10 @@ edid_parse(uint8_t *data, struct edid_in
if (edid->edid_modes[i].dot_clock > max_dotclock)
max_dotclock = edid->edid_modes[i].dot_clock;
 
+#ifdef DIAGNOSTIC
printf("max_dotclock according to supported modes: %d\n",
max_dotclock);
+#endif
 
mhz = (max_dotclock + 999) / 1000;
 

Re: armv7/omap: attach edma at fdt, re-enable

[Ian Sutton]

On Mon, Feb 27, 2017 at 08:08:16PM +1100, Jonathan Gray wrote:
> There is only one with "ti,edma3-tpcc".

Geez. It may be time to increase my font size.

Index: conf/GENERIC
===
RCS file: /cvs/src/sys/arch/armv7/conf/GENERIC,v
retrieving revision 1.71
diff -u -p -r1.71 GENERIC
--- conf/GENERIC23 Jan 2017 22:43:17 -  1.71
+++ conf/GENERIC27 Feb 2017 09:16:03 -
@@ -63,7 +63,7 @@ omapid*   at omap?
 # OMAP on-chip devices
 intc*  at fdt? # OMAP3 interrupt controller
 omwugen*   at fdt? # Wake-up generator
-#edma* at omap?# OMAP3 dma controller
+edma*  at fdt? # OMAP3 dma controller
 prcm*  at omap?# power/clock controller
 ompinmux*  at fdt? # pin muxing
 omdog* at fdt? # watchdog timer
Index: omap/edma.c
===
RCS file: /cvs/src/sys/arch/armv7/omap/edma.c,v
retrieving revision 1.5
diff -u -p -r1.5 edma.c
--- omap/edma.c 22 Jan 2015 14:33:01 -  1.5
+++ omap/edma.c 27 Feb 2017 09:16:03 -
@@ -19,12 +19,15 @@
 #include 
 #include 
 
-#include 
+#include 
 
 #include 
 #include 
 #include 
 
+#include 
+#include 
+
 #define DEVNAME(s) ((s)->sc_dev.dv_xname)
 
 struct edma_softc {
@@ -78,30 +81,39 @@ struct edma_softc {
 
 struct edma_softc *edma_sc;
 
+intedma_match(struct device *, void *, void *);
 void   edma_attach(struct device *, struct device *, void *);
 intedma_comp_intr(void *);
 
 struct cfattach edma_ca = {
-   sizeof(struct edma_softc), NULL, edma_attach
+   sizeof(struct edma_softc), edma_match, edma_attach
 };
 
 struct cfdriver edma_cd = {
NULL, "edma", DV_DULL
 };
 
+int
+edma_match(struct device *parent, void *match, void *aux)
+{
+   struct fdt_attach_args *faa = aux;
+
+   return OF_is_compatible(faa->fa_node, "ti,edma3-tpcc");
+}
+
 void
 edma_attach(struct device *parent, struct device *self, void *aux)
 {
-   struct armv7_attach_args *aa = aux;
+   struct fdt_attach_args *faa = aux;
struct edma_softc *sc = (struct edma_softc *)self;
uint32_t rev;
int i;
 
-   sc->sc_iot = aa->aa_iot;
+   sc->sc_iot = faa->fa_iot;
 
/* Map Base address for TPCC and TPCTX */
-   if (bus_space_map(sc->sc_iot, aa->aa_dev->mem[0].addr,
-   aa->aa_dev->mem[0].size, 0, >sc_tpcc)) {
+   if (bus_space_map(sc->sc_iot, faa->fa_reg[0].addr,
+   faa->fa_reg[0].size, 0, >sc_tpcc)) {
printf("%s: bus_space_map failed for TPCC\n", DEVNAME(sc));
return ;
}
@@ -115,12 +127,12 @@ edma_attach(struct device *parent, struc
 
/* XXX IPL_VM ? */
/* Enable interrupts line */
-   sc->sc_ih_comp = arm_intr_establish(aa->aa_dev->irq[0], IPL_VM,
+   sc->sc_ih_comp = arm_intr_establish_fdt(faa->fa_node, IPL_VM,
edma_comp_intr, sc, DEVNAME(sc));
if (sc->sc_ih_comp == NULL) {
printf("%s: unable to establish interrupt comp\n", DEVNAME(sc));
bus_space_unmap(sc->sc_iot, sc->sc_tpcc,
-   aa->aa_dev->mem[0].size);
+   faa->fa_reg[0].size);
return ;
}
 
Index: omap/files.omap
===
RCS file: /cvs/src/sys/arch/armv7/omap/files.omap,v
retrieving revision 1.19
diff -u -p -r1.19 files.omap
--- omap/files.omap 3 Oct 2016 01:59:20 -   1.19
+++ omap/files.omap 27 Feb 2017 09:16:03 -
@@ -39,7 +39,7 @@ attach tiiic at fdt
 file   arch/armv7/omap/ti_iic.ctiiic
 
 device edma
-attach edma at omap
+attach edma at fdt
 file   arch/armv7/omap/edma.c  edma
 
 device intc

Re: armv7/omap: attach edma at fdt, re-enable

[Ian Sutton]

On Mon, Feb 27, 2017 at 07:59:07PM +1100, Jonathan Gray wrote:
> On Mon, Feb 27, 2017 at 03:34:35AM -0500, Ian Sutton wrote:
> > This patch changes edma(4) to attach via device tree and re-enables it.
> 
> Looks like the line wrapping got mangled.

Yes, I had just sent a fixed version :) oops
 
> I don't see the point in testing ti,hwmods in match.

There are three fdt nodes with the target 'compatible' property:

edma@4900 {
compatible = "ti,edma3-tpcc";
ti,hwmods = "tpcc";
reg = <0x4900 0x1>;
reg-names = "edma3_cc";
interrupts = <0xc 0xd 0xe>;
interrupt-names = "edma3_ccint", "edma3_mperr", 
"edma3_ccerrint";
dma-requests = <0x40>;
#dma-cells = <0x2>;
ti,tptcs = <0x2a 0x7 0x2b 0x5 0x2c 0x0>;
ti,edma-memcpy-channels = <0x14 0x15>;
linux,phandle = <0x29>;
phandle = <0x29>;
};

tptc@4980 {
compatible = "ti,edma3-tptc";
ti,hwmods = "tptc0";
reg = <0x4980 0x10>;
interrupts = <0x70>;
interrupt-names = "edma3_tcerrint";
linux,phandle = <0x2a>;
phandle = <0x2a>;
};

tptc@4990 {
compatible = "ti,edma3-tptc";
ti,hwmods = "tptc1";
reg = <0x4990 0x10>;
interrupts = <0x71>;
interrupt-names = "edma3_tcerrint";
linux,phandle = <0x2b>;
phandle = <0x2b>;
};

Re: armv7/omap: attach edma at fdt, re-enable

[Ian Sutton]

Previous patch was malformed, d'oh.

Index: conf/GENERIC
===
RCS file: /cvs/src/sys/arch/armv7/conf/GENERIC,v
retrieving revision 1.71
diff -u -p -r1.71 GENERIC
--- conf/GENERIC23 Jan 2017 22:43:17 -  1.71
+++ conf/GENERIC27 Feb 2017 08:21:08 -
@@ -63,7 +63,7 @@ omapid*   at omap?
 # OMAP on-chip devices
 intc*  at fdt? # OMAP3 interrupt controller
 omwugen*   at fdt? # Wake-up generator
-#edma* at omap?# OMAP3 dma controller
+edma*  at fdt? # OMAP3 dma controller
 prcm*  at omap?# power/clock controller
 ompinmux*  at fdt? # pin muxing
 omdog* at fdt? # watchdog timer
Index: omap/edma.c
===
RCS file: /cvs/src/sys/arch/armv7/omap/edma.c,v
retrieving revision 1.5
diff -u -p -r1.5 edma.c
--- omap/edma.c 22 Jan 2015 14:33:01 -  1.5
+++ omap/edma.c 27 Feb 2017 08:21:08 -
@@ -19,12 +19,15 @@
 #include 
 #include 
 
-#include 
+#include 
 
 #include 
 #include 
 #include 
 
+#include 
+#include 
+
 #define DEVNAME(s) ((s)->sc_dev.dv_xname)
 
 struct edma_softc {
@@ -78,30 +81,46 @@ struct edma_softc {
 
 struct edma_softc *edma_sc;
 
+intedma_match(struct device *, void *, void *);
 void   edma_attach(struct device *, struct device *, void *);
 intedma_comp_intr(void *);
 
 struct cfattach edma_ca = {
-   sizeof(struct edma_softc), NULL, edma_attach
+   sizeof(struct edma_softc), edma_match, edma_attach
 };
 
 struct cfdriver edma_cd = {
NULL, "edma", DV_DULL
 };
 
+int
+edma_match(struct device *parent, void *match, void *aux)
+{
+   struct fdt_attach_args *faa = aux;
+   char hwmods[32];
+
+   if (OF_is_compatible(faa->fa_node, "ti,edma3-tpcc")) {
+   OF_getprop(faa->fa_node, "ti,hwmods", , 32);
+
+   return !strncmp(hwmods, "tpcc", 32);
+   }
+
+   return 0;
+}
+
 void
 edma_attach(struct device *parent, struct device *self, void *aux)
 {
-   struct armv7_attach_args *aa = aux;
+   struct fdt_attach_args *faa = aux;
struct edma_softc *sc = (struct edma_softc *)self;
uint32_t rev;
int i;
 
-   sc->sc_iot = aa->aa_iot;
+   sc->sc_iot = faa->fa_iot;
 
/* Map Base address for TPCC and TPCTX */
-   if (bus_space_map(sc->sc_iot, aa->aa_dev->mem[0].addr,
-   aa->aa_dev->mem[0].size, 0, >sc_tpcc)) {
+   if (bus_space_map(sc->sc_iot, faa->fa_reg[0].addr, faa->fa_reg[0].size, 
0,
+   >sc_tpcc)) {
printf("%s: bus_space_map failed for TPCC\n", DEVNAME(sc));
return ;
}
@@ -115,12 +134,12 @@ edma_attach(struct device *parent, struc
 
/* XXX IPL_VM ? */
/* Enable interrupts line */
-   sc->sc_ih_comp = arm_intr_establish(aa->aa_dev->irq[0], IPL_VM,
-   edma_comp_intr, sc, DEVNAME(sc));
+   sc->sc_ih_comp = arm_intr_establish_fdt(faa->fa_node, IPL_VM, 
edma_comp_intr,
+   sc, DEVNAME(sc));
if (sc->sc_ih_comp == NULL) {
printf("%s: unable to establish interrupt comp\n", DEVNAME(sc));
bus_space_unmap(sc->sc_iot, sc->sc_tpcc,
-   aa->aa_dev->mem[0].size);
+   faa->fa_reg[0].size);
return ;
}
 
Index: omap/files.omap
===
RCS file: /cvs/src/sys/arch/armv7/omap/files.omap,v
retrieving revision 1.19
diff -u -p -r1.19 files.omap
--- omap/files.omap 3 Oct 2016 01:59:20 -   1.19
+++ omap/files.omap 27 Feb 2017 08:21:08 -
@@ -39,7 +39,7 @@ attach tiiic at fdt
 file   arch/armv7/omap/ti_iic.ctiiic
 
 device edma
-attach edma at omap
+attach edma at fdt
 file   arch/armv7/omap/edma.c  edma
 
 device intc

armv7/omap: attach edma at fdt, re-enable

[Ian Sutton]

This patch changes edma(4) to attach via device tree and re-enables it.


Index: conf/GENERIC
===
RCS file: /cvs/src/sys/arch/armv7/conf/GENERIC,v
retrieving revision 1.71
diff -u -p -r1.71 GENERIC
--- conf/GENERIC23 Jan 2017 22:43:17 -  1.71
+++ conf/GENERIC27 Feb 2017 08:21:08 -
@@ -63,7 +63,7 @@ omapid*   at omap?
 # OMAP on-chip devices
 intc*  at fdt? # OMAP3 interrupt controller
 omwugen*   at fdt? # Wake-up generator
-#edma* at omap?# OMAP3 dma controller
+edma*  at fdt? # OMAP3 dma controller
 prcm*  at omap?# power/clock controller
 ompinmux*  at fdt? # pin muxing
 omdog* at fdt? # watchdog timer
Index: omap/edma.c
===
RCS file: /cvs/src/sys/arch/armv7/omap/edma.c,v
retrieving revision 1.5
diff -u -p -r1.5 edma.c
--- omap/edma.c 22 Jan 2015 14:33:01 -  1.5
+++ omap/edma.c 27 Feb 2017 08:21:08 -
@@ -19,12 +19,15 @@
 #include 
 #include 
 
-#include 
+#include 
 
 #include 
 #include 
 #include 
 
+#include 
+#include 
+
 #define DEVNAME(s) ((s)->sc_dev.dv_xname)
 
 struct edma_softc {
@@ -78,30 +81,46 @@ struct edma_softc {
 
 struct edma_softc *edma_sc;
 
+intedma_match(struct device *, void *, void *);
 void   edma_attach(struct device *, struct device *, void *);
 intedma_comp_intr(void *);
 
 struct cfattach edma_ca = {
-   sizeof(struct edma_softc), NULL, edma_attach
+   sizeof(struct edma_softc), edma_match, edma_attach
 };
 
 struct cfdriver edma_cd = {
NULL, "edma", DV_DULL
 };
 
+int
+edma_match(struct device *parent, void *match, void *aux)
+{
+   struct fdt_attach_args *faa = aux;
+   char hwmods[32];
+
+   if (OF_is_compatible(faa->fa_node, "ti,edma3-tpcc")) {
+   OF_getprop(faa->fa_node, "ti,hwmods", , 32);
+
+   return !strncmp(hwmods, "tpcc", 32);
+   }
+
+   return 0;
+}
+
 void
 edma_attach(struct device *parent, struct device *self, void *aux)
 {
-   struct armv7_attach_args *aa = aux;
+   struct fdt_attach_args *faa = aux;
struct edma_softc *sc = (struct edma_softc *)self;
uint32_t rev;
int i;
 
-   sc->sc_iot = aa->aa_iot;
+   sc->sc_iot = faa->fa_iot;
 
/* Map Base address for TPCC and TPCTX */
-   if (bus_space_map(sc->sc_iot, aa->aa_dev->mem[0].addr,
-   aa->aa_dev->mem[0].size, 0, >sc_tpcc)) {
+   if (bus_space_map(sc->sc_iot, faa->fa_reg[0].addr,
faa->fa_reg[0].size, 0,
+   >sc_tpcc)) {
printf("%s: bus_space_map failed for TPCC\n",
DEVNAME(sc));
return ;
}
@@ -115,12 +134,12 @@ edma_attach(struct device *parent, struc
 
/* XXX IPL_VM ? */
/* Enable interrupts line */
-   sc->sc_ih_comp = arm_intr_establish(aa->aa_dev->irq[0], IPL_VM,
-   edma_comp_intr, sc, DEVNAME(sc));
+   sc->sc_ih_comp = arm_intr_establish_fdt(faa->fa_node, IPL_VM,
edma_comp_intr,
+   sc, DEVNAME(sc));
if (sc->sc_ih_comp == NULL) {
printf("%s: unable to establish interrupt comp\n",
DEVNAME(sc));
bus_space_unmap(sc->sc_iot, sc->sc_tpcc,
-   aa->aa_dev->mem[0].size);
+   faa->fa_reg[0].size);
return ;
}
 
Index: omap/files.omap
===
RCS file: /cvs/src/sys/arch/armv7/omap/files.omap,v
retrieving revision 1.19
diff -u -p -r1.19 files.omap
--- omap/files.omap 3 Oct 2016 01:59:20 -   1.19
+++ omap/files.omap 27 Feb 2017 08:21:08 -
@@ -39,7 +39,7 @@ attach tiiic at fdt
 file   arch/armv7/omap/ti_iic.ctiiic
 
 device edma
-attach edma at omap
+attach edma at fdt
 file   arch/armv7/omap/edma.c  edma
 
 device intc

arm/simplebus: externalize simplebus_attach_node

[Ian Sutton]

Currently, we do not have a way to iterate over child FDT nodes, which
is a problem when you have a devices like the USB system on the am335x
(Beaglebone Black):

https://uglyman.kremlin.cc/gitweb/gitweb.cgi?p=bbb-usb.git;a=blob;f=misc/fdt/am335x-boneblack.dts;h=8799dc1d171961d3cd9a941131a82a15bbe445d7;hb=HEAD#l1489

This patch externalizes simplebus_attach_node which probes for drivers
to attach to individual nodes, allowing drivers matching parent nodes to
iterate over their children and call this function on each child. It
works.

For a driver matching parent node property compatible="ti,am33xx-usb"
and another driver matching child node property
compatible="ti,musb-am33xx", we do the following in the parent node
driver's _attach:

155: for (node = OF_child(faa->fa_node); node > 0; node = OF_peer(node))
156: simplebus_attach_node(parent, node);

and get:

amusbss0 at simplebus0: rev 0.13
ammusb0 at simplebus0: rev 0.0  
ammusb1 at simplebus0: rev 0.0
panic: welcome to openbsd 

This is needed for a USB OTG driver for the am335x in the works. 

Ian

Index: simplebusvar.h
===
RCS file: /cvs/src/sys/arch/arm/simplebus/simplebusvar.h,v
retrieving revision 1.1
diff -u -p -r1.1 simplebusvar.h
--- simplebusvar.h  21 Oct 2016 20:09:49 -  1.1
+++ simplebusvar.h  12 Feb 2017 01:27:21 -
@@ -31,3 +31,4 @@ struct simplebus_softc {
 };
 
 extern void simplebus_attach(struct device *, struct device *, void *);
+extern void simplebus_attach_node(struct device *, int);

Re: armv7/stand/efiboot: working BOOTAA64.EFI payload

[Ian Sutton]

On Wed, Nov 23, 2016 at 05:48:27PM -0700, Theo de Raadt wrote:
> > I am assuming that arch/aarch64
> 
> There should be no such thing.
> 
> This game of calling things 5 names has to stop.

I'm equally irritated and would like to reach a consensus on a single,
final name. I see three candidates:

* armv8  
* aarch64
* arm64  

armv8 is the umbrella name for architecture, and fits our previous
precedent (armv7). armv8 processors allow execution of 32 bit binaries
however, which conflicts with our intention to have everything 64-bit on
this new arch

aarch64 would eliminate this conflict but doesn't really refer to an
architecture the way that names in arch/ should

arm64 is the precedent set by other bsd's. We have a generalized
arch/arm directory that doesn't support specific boards but holds shared
arm sources, suggesting arm64 would be a similar directory for
generalized 64-bit arm code (it wouldn't)

Let's decide this soon and avoid bikeshedding. I like armv8.

Ian

Re: armv7/stand/efiboot: working BOOTAA64.EFI payload

[Ian Sutton]

On Wed, Nov 23, 2016 at 08:49:44PM +0100, Patrick Wildt wrote:
> > $ MACHINE=armv8 armmake64-aarch64 -f Makefile.arm64
> 
> Please call it arm64.  We should distinquish between 32 and 64-bit ARMs
> now.  Yes, the other one is called armv7, but that's just how it is.
> 
> Typically the ports are called arm64, while the compiler toolchain
> targets are aarch64.
> 
> MACHINE -> arm64
> MACHINE_ARCH -> aarch64

ok -- as long as we stick to these consistent names
 
> > I've put this in the armv7 directory pending a proper
> > armv8/aarch64/arm64 one.
> 
> Yes, as long as there's no sys/arch/arm64 this would be the only place
> it could really be.  I would be okay with having this in that directory
> for now.
> 
> Is there a reason you copied the C files to a 64-bit version?

I am assuming that arch/aarch64 will have its own stand/efiboot
directory and that these files will be copied anyway. If you'd like, I
can generate a patch that instead uses preprocessor macros instead of
copied files.

Ian

armv7/stand/efiboot: working BOOTAA64.EFI payload

[Ian Sutton]

Hi,

Patch adds armv8/aarch64 EFI payload image build support. With
patrick@'s aarch64-none-elf- toolchain referenced in my last mail on
this list, you can build it via...

$ MACHINE=armv8 armmake64-aarch64 -f Makefile.arm64

...where armmake64-aarch64 is a simple env wrapper for the toolchain,
uploaded here:

https://ce.gl/armmake64-aarch64.txt

I've tested this on the pine64, it works up until boot(0) is called
which fails as there is no bootable disk/aarch64 kernel yet.

I've put this in the armv7 directory pending a proper
armv8/aarch64/arm64 one.

Ian

Index: sys/arch/arm/include/reloc.h
===
RCS file: /cvs/src/sys/arch/arm/include/reloc.h,v
retrieving revision 1.2
diff -u -p -r1.2 reloc.h
--- sys/arch/arm/include/reloc.h26 May 2006 20:22:04 -  1.2
+++ sys/arch/arm/include/reloc.h23 Nov 2016 03:54:28 -
@@ -52,3 +52,19 @@
 #define R_ARM_RPC24254
 #define R_ARM_RBASE255
 
+#defineR_AARCH64_NONE  0   /* No relocation */
+#defineR_AARCH64_ABS64 257 /* Absolute offset */
+#defineR_AARCH64_ABS32 258 /* Absolute, 32-bit overflow 
check */
+#defineR_AARCH64_ABS16 259 /* Absolute, 16-bit overflow 
check */
+#defineR_AARCH64_PREL64260 /* PC relative */
+#defineR_AARCH64_PREL32261 /* PC relative, 32-bit overflow 
check */
+#defineR_AARCH64_PREL16262 /* PC relative, 16-bit overflow 
check */
+#defineR_AARCH64_COPY  1024/* Copy data from shared object 
*/
+#defineR_AARCH64_GLOB_DAT  1025/* Set GOT entry to data 
address */
+#defineR_AARCH64_JUMP_SLOT 1026/* Set GOT entry to code 
address */
+#defineR_AARCH64_RELATIVE  1027/* Add load address of shared 
object */
+#defineR_AARCH64_TLS_DTPREL64  1028
+#defineR_AARCH64_TLS_DTPMOD64  1029
+#defineR_AARCH64_TLS_TPREL64   1030
+#defineR_AARCH64_TLSDESC   1031/* Identify the TLS descriptor 
*/
+#defineR_AARCH64_IRELATIVE 1032
Index: sys/arch/armv7/stand/efiboot/Makefile.arm64
===
RCS file: sys/arch/armv7/stand/efiboot/Makefile.arm64
diff -N sys/arch/armv7/stand/efiboot/Makefile.arm64
--- /dev/null   1 Jan 1970 00:00:00 -
+++ sys/arch/armv7/stand/efiboot/Makefile.arm64 23 Nov 2016 03:54:28 -
@@ -0,0 +1,80 @@
+#  $OpenBSD: Makefile,v 1.6 2016/11/06 16:42:00 tb Exp $
+
+NOMAN= #
+
+.if ${MACHINE} == "armv8"
+
+PROG=  BOOTAA64.EFI
+OBJFMT=binary
+INSTALL_STRIP=
+BINDIR=/usr/mdec
+SRCS=  start64.S self_reloc.c efiboot64.c conf.c exec64.c efidev64.c 
fdt.c
+
+S= ${.CURDIR}/../../../..
+EFIDIR=${S}/stand/efi
+
+OBJCOPY?=  objcopy
+OBJDUMP?=  objdump
+
+LDFLAGS+=-nostdlib -T ${.CURDIR}/ldscript.arm64 -Bsymbolic -shared
+
+.PATH: ${S}/stand/boot
+SRCS+= boot.c cmd.c vars.c
+
+.PATH: ${S}/lib/libsa
+SRCS+= alloc.c ctime.c exit.c getchar.c memcmp.o memcpy.o memmove.c memset.c \
+   printf.c putchar.c snprintf.c strchr.c strcmp.c strerror.c strncmp.c \
+   strncpy.c strtol.c
+SRCS+= close.c closeall.c cons.c cread.c dev.c disklabel.c dkcksum.c fstat.c \
+   lseek.c open.c read.c readdir.c stat.c
+SRCS+= loadfile.c
+SRCS+= ufs.c
+
+.PATH: ${S}/lib/libkern/arch/arm ${S}/lib/libkern
+#SRCS+=divsi3.S divdi3.c moddi3.c qdivrem.c strlcpy.c strlen.c
+SRCS+= divdi3.c moddi3.c qdivrem.c strlcpy.c strlen.c
+
+.PATH: ${S}/lib/libz
+SRCS+= adler32.c crc32.c inflate.c inftrees.c
+
+CPPFLAGS+= -nostdinc
+CPPFLAGS+= -I${S} -I. -I${.CURDIR}
+CPPFLAGS+= -I${EFIDIR}/include -I${EFIDIR}/include/arm
+CPPFLAGS+= -D_STANDALONE
+CPPFLAGS+= -DSMALL -DSLOW -DNOBYFOUR -D__INTERNAL_LIBSA_CREAD
+CPPFLAGS+= -DNEEDS_HEAP_H
+COPTS+=-Wno-attributes -Wno-format
+COPTS+=-ffreestanding -fno-stack-protector
+COPTS+=-fshort-wchar -fPIC -fno-builtin
+COPTS+=-Wall -Werror
+
+PROG.elf=  ${PROG:S/.EFI/.elf/}
+CLEANFILES+=   ${PROG.elf} ${PROG.elf}.tmp
+
+${PROG}: ${PROG.elf}
+   ${OBJCOPY} -j .peheader -j .text -j .sdata -j .data \
+   -j .dynamic -j .dynsym -j .dynstr -j .rel -j .rel.dyn \
+   -j .rela -j .rela.dyn -j .reloc \
+   --output-target=${OBJFMT} ${PROG.elf} ${.TARGET}
+
+.include 
+
+${PROG.elf}: ${OBJS}
+   ${LD} ${LDFLAGS} -o ${.TARGET}.tmp ${OBJS} ${LDADD}
+   @if ${OBJDUMP} -t ${.TARGET}.tmp | grep 'UND'; then \
+   (echo Undefined symbols; false);\
+   fi
+   mv ${.TARGET}.tmp ${.TARGET}
+
+.if !make(clean) && !make(cleandir) && !make(includes) && !make(obj)
+.BEGIN:
+   @([ -h machine ] || ln -s ${.CURDIR}/../../../${MACHINE}/include 
machine)
+   @([ -h arm ] || ln 

pine64: working bootloader

[Ian Sutton]

(resending as list seemed to eat my last mail)

Hi,

I've got a natively-built bootloader working on the pine64 boards
generously donated to the foundation. Simply dd(1) the following image
directly to a uSD card, insert it, reset the pine64, and you will be
greeted by a u-boot prompt over the serial terminal:

https://ce.gl/pine64-uboot-openbsd.img

To provide a better understanding of what's going on here, I've devised
a tarball that (attempts) to build such an image, found here:

http://ce.gl/pine64-openbsd-bootloader-tool.tgz

Note -- I cobbled this together pretty quickly just as a
proof-of-concept: there will likely be mundane bugs in the Makefile

In the above tarball, there are a few important items:

 - gcc aarch64 cross-tools & binutils, from patrick@'s excellent patch

 - modified u-boot port, also patrick

 - boot0img, small tool, generates final image

 - ARM trusted firmware tool, generates board-specific firmware binaries
   used early-on in the boot process. It informs the hardware logic
   where the u-boot binary lives, how big it is, what its checksum is,
   etc.

 - boot0.bin, the (I think) very first bit of code executed at power-on
   time. I stripped this from around the top of the vendor-provided boot
   images. i sure hope it is legally distributable

I suggest editing the makefile and setting -j8 or similar flags on the
lines that build u-boot and the aarch64-none-elf tools as they take an
insanely long amount of time.

Similar to most ARM boards, the boot process on the pine64 is not at all
trivial -- about 5 discrete bodies of code that could be construed as
'bootloaders' exist between the power jack & userspace. To the best of
my understanding, the process is as follows:

1.) at power-on, hardware logic checks for presence of boot media (in
our case only uSD card). If no card is inserted, hardware falls back
to some arcane USB boot/firmware upgrade mode we don't care about

2.) hardware logic seeks to ~0x2000 and reads a few KB from uSD card
and writes it to on-silicon SRAM.

3.) boot0.img code gleans hints about the "real" bootloader, u-boot,
such that it can safely load an image. I don't know if it's loaded
to DRAM or SRAM; something here happens that involves trampolining
which I do not understand. Ostensibly the ARM trusted firmware code
runs around here, checksumming the purported u-boot image and
comparing it against the sum written near the top of the "disk"

Please let me know if you have any luck getting this to work or if there
are any errors in the tarball or if I've gotten something egregiously
wrong.

Ian

armv7 pinmux woes

[Ian Sutton]

Hello,

I'm writing a driver (amdisplay) supporting the LCD controller on the
am335x (Beaglebone Black). The LCD controller pins and the MMC1 pins
(used for interacting with the onboard eMMC flash chip) exist on the
same set of pads such that only the LCD controller or the eMMC may be
used at once.

My driver needs to recognize cases where the root disk is MMC1 and abort
as to avoid hanging the system when the kernel tries to init userspace
on a disk it is no longer pinmuxxed to. I am not sure how to properly
and reliably do this, or if there is perhaps a better way to go about
solving this problem.

Thanks,
Ian

videomode.h: add int hskew member to struct videomode

[Ian Sutton]

Some ARM systems have decoupled their display/LCD controllers from their
display transmitters, such as the am335x/beaglebone black whose LCD
controller (on am335x SoC) breaks out to a TDA19988 IC (on PCB). This
sometimes causes sync timing problems in that the timings purported by
the LCD controller do not match the ones coming out of the transmitter,
this hskew int enumerates the value the transmitter must offset its sync
timings by to match what the controller dictates. The extant VID_HSKEW
flag hints at this.

This patch does not break anything, but if devs (understandably) do not
wish to change a MI header to suit a small subset of devices, I can
still fix this issue with the am335x/TDA in a more inelegant way.

Ian


Index: sys/dev/videomode/videomode.h
===
RCS file: /cvs/src/sys/dev/videomode/videomode.h,v
retrieving revision 1.1
diff -u -p -r1.1 videomode.h
--- sys/dev/videomode/videomode.h   8 Oct 2009 20:35:44 -   1.1
+++ sys/dev/videomode/videomode.h   3 Sep 2016 04:26:49 -
@@ -42,6 +42,7 @@ struct videomode {
int vtotal;
int flags;  /* Video mode flags; see below. */
const char *name;
+   int hskew;
 };
 
 /*

Re: armv7/omap: amdisplay(4)

[Ian Sutton]

Work on amdisplay(4) continues uneventfully. It is very nearly complete,
just need to fix some DMA issues I am having trouble with.

Ian

Index: arch/armv7/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/armv7/conf/GENERIC,v
retrieving revision 1.45
diff -u -p -r1.45 GENERIC
--- arch/armv7/conf/GENERIC 11 Aug 2016 04:33:06 -  1.45
+++ arch/armv7/conf/GENERIC 2 Sep 2016 05:12:54 -
@@ -70,6 +70,7 @@ omgpio*   at fdt? # user-visible 
GPIO p
 gpio*  at omgpio?
 tiiic* at fdt?
 iic*   at tiiic?
+nxptda*at iic?
 gptimer*   at omap?# general purpose timers
 dmtimer*   at omap?# am335x dual mode timers
 omusbtll*  at omap?
@@ -77,6 +78,7 @@ cpsw* at fdt?
 com*   at fdt? # onboard uarts
 ommmc* at fdt? # SD/MMC card controller
 sdmmc* at ommmc?   # SD/MMC bus
+amdisplay* at fdt? # LCD controller
 
 omehci*at fdt? # EHCI
 usb*   at omehci?
Index: arch/armv7/omap/am335x_prcmreg.h
===
RCS file: /cvs/src/sys/arch/armv7/omap/am335x_prcmreg.h,v
retrieving revision 1.4
diff -u -p -r1.4 am335x_prcmreg.h
--- arch/armv7/omap/am335x_prcmreg.h18 Mar 2014 07:34:17 -  1.4
+++ arch/armv7/omap/am335x_prcmreg.h2 Sep 2016 05:06:06 -
@@ -20,6 +20,7 @@
 #define AM335X_CLKCTRL_MODULEMODE_MASK 0x0003
 
 #define PRCM_AM335X_CM_PER 0x
+#define PRCM_AM335X_LCDC_CLKCTRL   0x0018
 #define PRCM_AM335X_USB0_CLKCTRL   0x001c
 #define PRCM_AM335X_TPTC0_CLKCTRL  0x0024
 #define PRCM_AM335X_MMC0_CLKCTRL   0x003c
@@ -38,6 +39,10 @@
 #define PRCM_AM335X_CM_WKUP0x0400
 #define PRCM_AM335X_GPIO0_CLKCTRL  0x0408
 #define PRCM_AM335X_TIMER0_CLKCTRL 0x0410
+#define PRCM_AM335X_DISP_IDLEST0x0448
+#define PRCM_AM335X_DISP_CLKSEL0x0454
+#define PRCM_AM335X_DISP_CLKMODE   0x0498
+#define PRCM_AM335X_DISP_M20x04a4
 #define PRCM_AM335X_I2C0_CLKCTRL   0x04b8
 #define PRCM_AM335X_CM_DPLL0x0500
 #define PRCM_AM335X_CLKSEL_TIMER2_CLK  0x0508
Index: arch/armv7/omap/amdisplay.c
===
RCS file: arch/armv7/omap/amdisplay.c
diff -N arch/armv7/omap/amdisplay.c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ arch/armv7/omap/amdisplay.c 2 Sep 2016 05:06:06 -
@@ -0,0 +1,643 @@
+/*
+ * Copyright (c) 2016 Ian Sutton <i...@kremlin.cc>
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+
+#define DEVNAME(_s) ((_s)->sc_dev.dv_xname)
+
+#define HREAD4(sc, reg)
\
+   (bus_space_read_4((sc)->sc_iot, (sc)->sc_ioh, (reg)))
+#define HWRITE4(sc, reg, val)  \
+   bus_space_write_4((sc)->sc_iot, (sc)->sc_ioh, (reg), (val))
+#define HSET4(sc, reg, bits)   \
+   HWRITE4((sc), (reg), HREAD4((sc), (reg)) | (bits))
+#define HCLR4(sc, reg, bits)   \
+   HWRITE4((sc), (reg), HREAD4((sc), (reg)) & ~(bits))
+
+struct amdisplay_softc {
+   struct device   sc_dev;
+   bus_space_tag_t sc_iot;
+   bus_space_handle_t  sc_ioh;
+   bus_dma_tag_t   sc_dmat;
+   void*sc_ih;
+
+   struct edid_info*sc_edid;
+   struct videomode*sc_active_mode;
+   int sc_active_depth;
+
+   bus_dmamap_tsc_fb0_dma;
+// bus_dmamap_tsc_fb1_dma;
+   bus_dma_segment_t   sc_fb0_dma_segs[1];
+// bus_dma_segment_t   sc_fb1_dma_segs[1];
+   void*sc_fb0;
+// void*sc_fb1;
+   int 

Re: dev/i2c: nxptda(4)

[Ian Sutton]

On Fri, Aug 19, 2016 at 03:02:34PM +1000, Jonathan Gray wrote:
> On Fri, Aug 19, 2016 at 02:38:32PM +1000, Jonathan Gray wrote:
> > On Thu, Aug 18, 2016 at 04:34:38PM -0400, Ian Sutton wrote:
> > > On Sat, Aug 06, 2016 at 04:26:27AM -0400, Ian Sutton wrote:
> > > > Interestingly, the am335x SoC does not have a HDMI/DP/etc transmitter on
> > > > silicon -- the BBB has its LCDC pins wired to a TDA19988 HDMI
> > > > transmitter which is additionally backwired to one of the am335x's i2c
> > > > ports:
> > > > 
> > > > "nxp,tda998x" at iic0 addr 0x70 not configured
> > > > 
> > > > Without a TDA19988 driver we are unable to probe for an attached
> > > > display's EDID bits thus unable to tailor timing/videomode parameters
> > > > on a per-display basis.
> > > 
> > > The following patch adds the nxptda(4) i2c driver:
> > > 
> > >   nxptda0 at iic0 addr 0x70: rev 0x0301
> > > 
> > > It correctly ascertains the EDID bits of displays connected to the
> > > beaglebone black:
> > > 
> > > nxptda0 at iic0 addr 0x70   
> > > nxptda0: set page to 0x00
> > > nxptda0: read  0x31 from 0x00 on page 0x00, result: 0
> > > nxptda0: read  0x03 from 0x02 on page 0x00, result: 0
> > > nxptda0: rev 0x0301  
> > > nxptda0: read  0x00 from 0x0a on page 0x00, result: 0
> > > nxptda0: wrote 0x03  to  0x0a on page 0x00, result: 0
> > > nxptda0: read  0x03 from 0x0a on page 0x00, result: 0
> > > nxptda0: wrote 0x00  to  0x0a on page 0x00, result: 0
> > > 
> > >   
> > > 
> > > nxptda0: read  0x02 from 0x11 on page 0x00, result: 0
> > > nxptda0: EDID-ready IRQ fired
> > > nxptda0: set page to 0x09
> > > nxptda0: - EDID -
> > > nxptda0: 000022f05b2801010101
> > > nxptda0: 1b15010380261e8ceef6b0a3554c9b25
> > > nxptda0: 115054a1080081808140010101010101
> > > nxptda0: 010101010101302a009851002a403070
> > > nxptda0: 13007c2c111e00fd00324c18
> > > nxptda0: 530e000a20202020202000fc004c
> > > nxptda0: 41313935310a20202020202000ff
> > > nxptda0: 00434e43313237504c56420a20200022
> > > nxptda0: 
> > >^--matches EDID bits from `xrandr --verbose`
> > > 
> > > 
> > > This will be important for upcoming display support on armv7 (see
> > > amdisplay(4) threads on this list[1]). The following code is
> > > review-ready to some degree, however, I imagine further register
> > > fiddling will be needed to communicate the intended timings perhaps
> > > implicating more externally callable functions.
> > > 
> > > Speaking of which:
> > > 
> > > I am apprehensive of nxptda(4)'s current external interface model. I
> > > currently have the lone nxptda_refresh_edid() function declared in
> > > nxptdavar.h header in sys/dev/i2c/, meant to be included by other drivers
> > > which need the EDID information it provides. No other such foo_var.h
> > > headers appear in that directory which makes me think I am doing
> > > something wrong. nxptda(4) is an i2c driver and must attach to the MI
> > > iic(4) driver precluding a direct attachment interface. Is there a
> > > better way of doing this?
> > 
> > Have you considered directly attaching the i2c bus to your other
> > driver without creating a new driver and using drm_edid.c ?
> 
> Though this would mean not attaching to tiiic, and unlike
> inteldrm/radeondrm there are other things on the i2c bus.

I am not sure what you mean here -- if nxptda doesn't attach to tiiic
then how is nxptda afforded the abstracted i2c subroutines filled in by
tiiic? All the iic-* functions nxptda should use require an i2c_tag_t
which in this case can only be provided by attaching at tiiic.

Re: dev/i2c: nxptda(4)

[Ian Sutton]

On Fri, Aug 19, 2016 at 02:38:32PM +1000, Jonathan Gray wrote:
> Have you considered directly attaching the i2c bus to your other
> driver without creating a new driver and using drm_edid.c ?
> 
> Perhaps even handle the modesetting ioctls and use the modesetting
> driver with xorg?

I had considered it but thought it would not be "kosher" to do it that
way. It would certainly be easier. If you think it is appropriate, I
will coalesce the two.
 
> I do wonder what you are using as an input device though without usb
> working yet.

There are 6 pins behind the P9 header (right next to the 32.768K
crystal) which are connected to a ftdi chip wired to the am335x's UART0
pins. u-boot & openbsd use it as a serial terminal. An old USB ftdi
cable I had laying around worked:

uftdi0 at uhub5 port 4 configuration 1 interface 0 "FTDI FT232R USB
UART" rev 2.00/6.00 addr 2
ucom0 at uftdi0 portno 1

115200 baud/3.3V logic levels. Five volts will kill it, careful

Ian

Re: armv7/omap: amdisplay(4)

[Ian Sutton]

On Sun, Aug 07, 2016 at 02:16:45PM +0200, Mark Kettenis wrote:
> Much lower risk I'd say; it all depends on the quality of the code of

Excellent.

amdisplay(4) work continues uneventfully. WIP patch below:

Index: conf/GENERIC
===
RCS file: /cvs/src/sys/arch/armv7/conf/GENERIC,v
retrieving revision 1.31
diff -u -p -r1.31 GENERIC
--- conf/GENERIC12 Jul 2016 19:17:49 -  1.31
+++ conf/GENERIC11 Aug 2016 07:17:04 -
@@ -76,6 +76,8 @@ cpsw* at fdt?
 com*   at fdt? # onboard uarts
 ommmc* at fdt? # SD/MMC card controller
 sdmmc* at ommmc?   # SD/MMC bus
+amdisplay* at fdt? # LCD controller
+wsdisplay* at amdisplay? console ?
 
 ehci*  at omap?# EHCI (shim)
 usb*   at ehci?
Index: omap/am335x_prcmreg.h
===
RCS file: /cvs/src/sys/arch/armv7/omap/am335x_prcmreg.h,v
retrieving revision 1.4
diff -u -p -r1.4 am335x_prcmreg.h
--- omap/am335x_prcmreg.h   18 Mar 2014 07:34:17 -  1.4
+++ omap/am335x_prcmreg.h   11 Aug 2016 07:17:04 -
@@ -20,6 +20,7 @@
 #define AM335X_CLKCTRL_MODULEMODE_MASK 0x0003
 
 #define PRCM_AM335X_CM_PER 0x
+#define PRCM_AM335X_LCDC_CLKCTRL   0x0018
 #define PRCM_AM335X_USB0_CLKCTRL   0x001c
 #define PRCM_AM335X_TPTC0_CLKCTRL  0x0024
 #define PRCM_AM335X_MMC0_CLKCTRL   0x003c
Index: omap/amdisplay.c
===
RCS file: omap/amdisplay.c
diff -N omap/amdisplay.c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ omap/amdisplay.c11 Aug 2016 07:17:04 -
@@ -0,0 +1,496 @@
+/*
+ * Copyright (c) 2016 Ian Sutton <i...@kremlin.cc>
+ *
+ * Permission to use, copy, modify, and distribute this software for
any
+ * purpose with or without fee is hereby granted, provided that the
above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL
WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE
FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY
DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+/* register offsets */
+#define AMDISPLAY_PID  0x00
+#define AMDISPLAY_CTRL 0x04
+#define   AMDISPLAY_CTRL_CLKDIV_MASK   (0xFF << 8)
+#define   AMDISPLAY_CTRL_MODESEL_MASK  (1 << 0)
+#define   AMDISPLAY_CTRL_CLKDIV_SHAMT  8
+#define AMDISPLAY_RASTER_CTRL  0x28
+#define   AMDISPLAY_RASTER_CTRL_TFT24UNPACKED_MASK (1 << 26)
+#define   AMDISPLAY_RASTER_CTRL_TFT24_MASK (1 << 25)
+#define   AMDISPLAY_RASTER_CTRL_LCDTFT_MASK(1 << 7)
+#define   AMDISPLAY_RASTER_CTRL_LCDEN_MASK (1 << 0)
+#define AMDISPLAY_RASTER_TIMING_0  0x2C
+#define   AMDISPLAY_RASTER_TIMING_0_HBP_MASK   (0xFF << 24)
+#define   AMDISPLAY_RASTER_TIMING_0_HFP_MASK   (0xFF << 16)
+#define   AMDISPLAY_RASTER_TIMING_0_HSW_MASK   (0x3F << 10)
+#define   AMDISPLAY_RASTER_TIMING_0_PPLLSB_MASK(0x3  <<
4)
+#define   AMDISPLAY_RASTER_TIMING_0_PPLMSB_MASK(0x1  <<
3)
+#define   AMDISPLAY_RASTER_TIMING_0_HBP_SHAMT  24
+#define   AMDISPLAY_RASTER_TIMING_0_HFP_SHAMT  16
+#define   AMDISPLAY_RASTER_TIMING_0_HSW_SHAMT  10
+#define   AMDISPLAY_RASTER_TIMING_0_PPLLSB_SHAMT   4
+#define   AMDISPLAY_RASTER_TIMING_0_PPLMSB_SHAMT   3
+#define AMDISPLAY_RASTER_TIMING_1  0x30
+#define   AMDISPLAY_RASTER_TIMING_1_VBP_MASK   (0xFF  << 24)
+#define   AMDISPLAY_RASTER_TIMING_1_VFP_MASK   (0xFF  << 16)
+#define   AMDISPLAY_RASTER_TIMING_1_VSW_MASK   (0x3C  << 10)
+#define   AMDISPLAY_RASTER_TIMING_1_LPP_MASK   (0x3FF <<  0)
+#define   AMDISPLAY_RASTER_TIMING_1_VBP_SHAMT  24
+#define   AMDISPLAY_RASTER_TIMING_1_VFP_SHAMT  16
+#define   AMDISPLAY_RASTER_TIMING_1_VSW_SHAMT  10
+#define AMDISPLAY_RASTER_TIMING_2  0x34
+#define   AMDISPLAY_RASTER_TIMING_2_HSW_HIGHBITS_MASK  (0xF  << 27)
+#define   AMDISPLAY_RASTER_TIMING_2_LPP_B10_MASK   (0x1  << 26)
+#define   AMDISPLAY_RASTER_TIMING_2_PHSVS_ON_OFF_MASK  (0x1  << 25)
+#define   AMDISPLAY_RASTER_TIMING_2_PHSVS_RF_MASK  (0x1  << 24)
+#d

Re: man9/config_attach.9: incorporate config_deactivate information

[Ian Sutton]

On Sun, Aug 07, 2016 at 10:50:49PM -0600, Theo de Raadt wrote:
> Your diff also contained:
> 
> -.Fn config_detach "struct device *dev" "int flags"
> +.Fn config_detach "struct device *dev"

Argh! I had initially given config_deactivate() a flags parameter,
realized it lacked one in the code, and must have also accidently
removed it from _detach() accidently. Patch below removes this error.
Page also uploaded for convenience:

http://ce.gl/config_attach.9.txt

> I think you are reading NetBSD?

I have not used nor even tried any other BSDs.

Index: config_attach.9
===
RCS file: /cvs/src/share/man/man9/config_attach.9,v
retrieving revision 1.3
diff -u -p -r1.3 config_attach.9
--- config_attach.9 5 Dec 2014 16:55:53 -   1.3
+++ config_attach.9 8 Aug 2016 05:31:34 -
@@ -34,7 +34,8 @@
 .Sh NAME
 .Nm config_attach ,
 .Nm config_detach ,
-.Nm config_detach_children
+.Nm config_detach_children ,
+.Nm config_deactivate
 .Nd attach and detach devices
 .Sh SYNOPSIS
 .In sys/param.h
@@ -46,6 +47,8 @@
 .Fn config_detach "struct device *dev" "int flags"
 .Ft "int"
 .Fn config_detach_children "struct device *parent" "int flags"
+.Ft "int"
+.Fn config_deactivate "struct device *dev"
 .Sh DESCRIPTION
 The
 .Fn config_attach
@@ -71,6 +74,21 @@ contains detachment flags:
 #defineDETACH_FORCE0x01/* Force detachment; hardware
gone */
 #defineDETACH_QUIET0x02/* Don't print a notice */
 .Ed
+.Pp
+The
+.Fn config_deactivate
+function is called by the parent to change the child device's
operational state
+by calling the driver's activate function with a
+.Fa flags
+argument describing the targeted operational state:
+.Bd -literal
+#defineDVACT_DEACTIVATE1   /* deactivate the device
*/
+#defineDVACT_QUIESCE   2   /* warn the device about
suspend */
+#defineDVACT_SUSPEND   3   /* suspend the device */
+#defineDVACT_RESUME4   /* resume the device */
+#defineDVACT_WAKEUP5   /* tell device to
recover after resume */
+#defineDVACT_POWERDOWN 6   /* power device down */
+.Ed
 .Sh CONTEXT
 .Fn config_detach
 is always called from process context, allowing
@@ -79,6 +97,8 @@ to be called while the device detaches i
 which have a device open).
 .Sh RETURN VALUES
 .Fn config_detach
-returns zero if successful and an error code otherwise.
+and
+.Fn config_deactivate
+return zero if successful and an error code otherwise.
 .Sh SEE ALSO
 .Xr config_found 9

man9/config_attach.9: incorporate config_deactivate information

[Ian Sutton]

config_attach.9 seems to be the man page which best describes what
struct cfattach members do. The following patch adds a section
describing what the ca_activate function pointer within struct cfattach
does via a description of the corresponding config_deactivate function
as to follow config_attach.9's established model. The following
additions do not incur any mdoc(7) warnings or errors.

I couldn't ascertain whether config_deactivate is always called from
process context; if anyone can authoritatively determine it is, please
chime in here so I can make a note of it in the CONTEXT section.

Ian

Index: man9/config_attach.9
===
RCS file: /cvs/src/share/man/man9/config_attach.9,v
retrieving revision 1.3
diff -u -p -r1.3 config_attach.9
--- man9/config_attach.95 Dec 2014 16:55:53 -   1.3
+++ man9/config_attach.98 Aug 2016 04:13:27 -
@@ -34,7 +34,8 @@
 .Sh NAME
 .Nm config_attach ,
 .Nm config_detach ,
-.Nm config_detach_children
+.Nm config_detach_children ,
+.Nm config_deactivate
 .Nd attach and detach devices
 .Sh SYNOPSIS
 .In sys/param.h
@@ -43,9 +44,11 @@
 .Fn config_attach "struct device *parent" "void *cf" "void *aux" \
   "cfprint_t print"
 .Ft "int"
-.Fn config_detach "struct device *dev" "int flags"
+.Fn config_detach "struct device *dev"
 .Ft "int"
 .Fn config_detach_children "struct device *parent" "int flags"
+.Ft "int"
+.Fn config_deactivate "struct device *dev"
 .Sh DESCRIPTION
 The
 .Fn config_attach
@@ -71,6 +74,21 @@ contains detachment flags:
 #defineDETACH_FORCE0x01/* Force detachment; hardware gone */
 #defineDETACH_QUIET0x02/* Don't print a notice */
 .Ed
+.Pp
+The
+.Fn config_deactivate
+function is called by the parent to change the child device's operational state
+by calling the driver's activate function with a
+.Fa flags
+argument describing the targeted operational state:
+.Bd -literal
+#defineDVACT_DEACTIVATE1   /* deactivate the device */
+#defineDVACT_QUIESCE   2   /* warn the device about 
suspend */
+#defineDVACT_SUSPEND   3   /* suspend the device */
+#defineDVACT_RESUME4   /* resume the device */
+#defineDVACT_WAKEUP5   /* tell device to recover after 
resume */
+#defineDVACT_POWERDOWN 6   /* power device down */
+.Ed
 .Sh CONTEXT
 .Fn config_detach
 is always called from process context, allowing
@@ -79,6 +97,8 @@ to be called while the device detaches i
 which have a device open).
 .Sh RETURN VALUES
 .Fn config_detach
-returns zero if successful and an error code otherwise.
+and
+.Fn config_deactivate
+return zero if successful and an error code otherwise.
 .Sh SEE ALSO
 .Xr config_found 9

Re: armv7/omap: amdisplay(4)

[Ian Sutton]

On Sat, Aug 06, 2016 at 11:34:09AM +0200, Mark Kettenis wrote:
> Note that on many platforms (including i.MX6) u-boot already sets up a
> framebuffer.  So if we'd know framebuffer address and the layout of
> the framebuffer it would be trivial to attach a rasops-based
> wsdisplay(4) to that.  There is a "simple-framebuffer" device tree
> binding for passing that information; see
> 
>   Documentation/devicetree/bindings/display/simple-framebuffer.txt
> 
> in the Linux tree.  Unofrtunately u-boot only adds the appropriate
> nodes to the tree on the Allwinner and Raspberry Pi platforms.  I
> don't think it would be too difficult to add it for other platforms
> though.
> 
> Of course this wouldn't allow you to change resolution and color
> depth.  But it would be enough to run X with the wsfb driver.

Neat, I agree this is the way to go on imx given the sheer amount of
effort it would take to implement a full display driver properly. I will
move imxdisplay(4) efforts to follow your model instead. am335x on the
other hand...
 
> If it interests you, go for it.  But I think that for most of our
> users a simple framebuffer as I sketched above would be good enough.
> So for me, this doesn't have a very high priority.

It does & I intend to. The am335x LCDC is relatively much, much less
complex and I am not far off from a working driver (discounting the
TDA19988/EDID issue). The BBB is a popular enough board that I think a
comprehensive display driver would be worthwhile considering it ends up
as many novices' first board & lack of X presents too high a
barrier-to-entry for them.

Of course, amdisplay(4) would only be worthwhile were it to actually be
committed upon completion -- my last effort (tipru(4)) proved to be
conceptually incompatible with OpenBSD & I'd like to avoid fighting
windmills this time around. :)

Below is further along but still incomplete amdisplay(4) patch provided
for continuity

Ian

Index: sys/arch/armv7/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/armv7/conf/GENERIC,v
retrieving revision 1.31
diff -u -p -r1.31 GENERIC
--- sys/arch/armv7/conf/GENERIC 12 Jul 2016 19:17:49 -  1.31
+++ sys/arch/armv7/conf/GENERIC 7 Aug 2016 07:40:40 -
@@ -76,6 +76,8 @@ cpsw* at fdt?
 com*   at fdt? # onboard uarts
 ommmc* at fdt? # SD/MMC card controller
 sdmmc* at ommmc?   # SD/MMC bus
+amdisplay* at fdt? # LCD controller
+wsdisplay* at amdisplay? console ?
 
 ehci*  at omap?# EHCI (shim)
 usb*   at ehci?
Index: sys/arch/armv7/omap/am335x_prcmreg.h
===
RCS file: /cvs/src/sys/arch/armv7/omap/am335x_prcmreg.h,v
retrieving revision 1.4
diff -u -p -r1.4 am335x_prcmreg.h
--- sys/arch/armv7/omap/am335x_prcmreg.h18 Mar 2014 07:34:17
-   1.4
+++ sys/arch/armv7/omap/am335x_prcmreg.h7 Aug 2016 07:40:40
-
@@ -20,6 +20,7 @@
 #define AM335X_CLKCTRL_MODULEMODE_MASK 0x0003
 
 #define PRCM_AM335X_CM_PER 0x
+#define PRCM_AM335X_LCDC_CLKCTRL   0x0018
 #define PRCM_AM335X_USB0_CLKCTRL   0x001c
 #define PRCM_AM335X_TPTC0_CLKCTRL  0x0024
 #define PRCM_AM335X_MMC0_CLKCTRL   0x003c
Index: sys/arch/armv7/omap/amdisplay.c
===
RCS file: sys/arch/armv7/omap/amdisplay.c
diff -N sys/arch/armv7/omap/amdisplay.c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ sys/arch/armv7/omap/amdisplay.c     7 Aug 2016 07:40:40 -
@@ -0,0 +1,422 @@
+/*
+ * Copyright (c) 2016 Ian Sutton <i...@kremlin.cc>
+ *
+ * Permission to use, copy, modify, and distribute this software for
any
+ * purpose with or without fee is hereby granted, provided that the
above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL
WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE
FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY
DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+/* register offsets */
+#define AMDISPLAY_PID  0x00
+#define AMDISPLAY_CTRL 0x04
+#define   AMDISPLAY_CTRL_CLKDIV_MASK   (0xFF << 8)
+#define   AMDISPLAY_CTRL_MODESEL_MASK  (1 << 0)
+#define AMDISPLAY_RASTER_CTRL  0x28
+#define   AMDISPLAY

armv7/omap: amdisplay(4)

[Ian Sutton]

amdisplay(4) drives the LCD controller in am335x SoCs (beaglebone black
for us). Patch is unfinished but is further along than imxdisplay(4).
(imx6q's display subsystem is enormously complicated and poorly
documented; I intend to finish both but am working on this one for now).

Interestingly, the am335x SoC does not have a HDMI/DP/etc transmitter on
silicon -- the BBB has its LCDC pins wired to a TDA19988 HDMI
transmitter which is additionally backwired to one of the am335x's i2c
ports:

"nxp,tda998x" at iic0 addr 0x70 not configured

Without a TDA19988 driver we are unable to probe for an attached
display's EDID bits thus unable to tailor timing/videomode parameters
on a per-display basis.

I am working on such a driver but would like to ask developers if it
would be worth it, or if there is more important armv7 work to be done
elsewhere.

Ian

Index: sys/arch/armv7/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/armv7/conf/GENERIC,v
retrieving revision 1.31
diff -u -p -r1.31 GENERIC
--- sys/arch/armv7/conf/GENERIC 12 Jul 2016 19:17:49 -  1.31
+++ sys/arch/armv7/conf/GENERIC 6 Aug 2016 07:59:48 -
@@ -76,6 +76,8 @@ cpsw* at fdt?
 com*   at fdt? # onboard uarts
 ommmc* at fdt? # SD/MMC card controller
 sdmmc* at ommmc?   # SD/MMC bus
+amdisplay* at fdt? # LCD controller
+wsdisplay* at amdisplay? console ?
 
 ehci*  at omap?# EHCI (shim)
 usb*   at ehci?
Index: sys/arch/armv7/omap/am335x_prcmreg.h
===
RCS file: /cvs/src/sys/arch/armv7/omap/am335x_prcmreg.h,v
retrieving revision 1.4
diff -u -p -r1.4 am335x_prcmreg.h
--- sys/arch/armv7/omap/am335x_prcmreg.h18 Mar 2014 07:34:17 -  
1.4
+++ sys/arch/armv7/omap/am335x_prcmreg.h6 Aug 2016 07:59:48 -
@@ -20,6 +20,7 @@
 #define AM335X_CLKCTRL_MODULEMODE_MASK 0x0003
 
 #define PRCM_AM335X_CM_PER 0x
+#define PRCM_AM335X_LCDC_CLKCTRL   0x0018
 #define PRCM_AM335X_USB0_CLKCTRL   0x001c
 #define PRCM_AM335X_TPTC0_CLKCTRL  0x0024
 #define PRCM_AM335X_MMC0_CLKCTRL   0x003c
Index: sys/arch/armv7/omap/amdisplay.c
===
RCS file: sys/arch/armv7/omap/amdisplay.c
diff -N sys/arch/armv7/omap/amdisplay.c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ sys/arch/armv7/omap/amdisplay.c 6 Aug 2016 07:59:48 -
@@ -0,0 +1,371 @@
+/*
+ * Copyright (c) 2016 Ian Sutton <i...@kremlin.cc>
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+/* register offsets */
+#define AMDISPLAY_PID  0x00
+#define AMDISPLAY_CTRL 0x04
+#define   AMDISPLAY_CTRL_CLKDIV_MASK   (0xFF << 8)
+#define   AMDISPLAY_CTRL_MODESEL_MASK  (1 << 0)
+#define AMDISPLAY_RASTER_CTRL  0x28
+#define   AMDISPLAY_RASTER_CTRL_TFT24UNPACKED_MASK (1 << 26)
+#define   AMDISPLAY_RASTER_CTRL_TFT24_MASK (1 << 25)
+#define   AMDISPLAY_RASTER_CTRL_LCDTFT_MASK(1 << 7)
+#define   AMDISPLAY_RASTER_CTRL_LCDEN_MASK (1 << 0)
+#define AMDISPLAY_RASTER_TIMING_0  0x2C
+#define AMDISPLAY_RASTER_TIMING_1  0x30
+#define AMDISPLAY_RASTER_TIMING_2  0x34
+#define AMDISPLAY_RASTER_SUBPANEL  0x38
+#define AMDISPLAY_RASTER_SUBPANEL_20x3C
+#define AMDISPLAY_LCDDMA_CTRL  0x40
+#define AMDISPLAY_LCDDMA_FB0_BASE  0x44
+#define AMDISPLAY_LCDDMA_FB0_CEILING   0x48
+#define AMDISPLAY_LCDDMA_FB1_BASE  0x4C
+#define AMDISPLAY_LCDDMA_FB1_CEILING   0x50
+#define AMDISPLAY_SYSCONFIG0x54
+#define   AMDISPLAY_SYSCONFIG_STANDBYMODE_MASK (3 << 4)
+#define   AMDISPLAY_SYSCONFIG_IDLEMODE_MASK(3 << 2)
+#define   AMDISPLAY_SYSCONFIG_STANDBYMODE_SHAMT4
+#define   AMDISPLAY_SYSCONFIG_IDLEMODE_SHAMT   2
+#define AMDISPLAY_IRQSTATUS_RAW0x58
+#define AMDISPLAY_IRQSTATUS0x5C
+#define AMDISPLAY_IRQE

Re: armv7/imx: imxdisplay(4)

[Ian Sutton]

ipu(void);
 
 struct cfattachimxccm_ca = {
sizeof (struct imxccm_softc), NULL, imxccm_attach
@@ -518,6 +548,29 @@ imxccm_enable_pll_enet(void)
 }
 
 void
+imxccm_enable_pll_video(void)
+{
+   struct imxccm_softc *sc = imxccm_sc;
+
+   /*  Set PLL to 455MHz */
+   HSET4(sc, CCM_ANALOG_PLL_VIDEO, CCM_ANALOG_PLL_VIDEO_POWERDOWN);
+   HCLR4(sc, CCM_ANALOG_PLL_VIDEO, CCM_ANALOG_PLL_VIDEO_DIV_SELECT);
+   HSET4(sc, CCM_ANALOG_PLL_VIDEO, 0x25);
+   HCLR4(sc, CCM_ANALOG_PLL_VIDEO, CCM_ANALOG_PLL_VIDEO_POST_DIV_SELECT);
+   HSET4(sc, CCM_ANALOG_PLL_VIDEO, 0x01 << 
CCM_ANALOG_PLL_VIDEO_POST_DIV_SELECT_SHIFT);
+   HCLR4(sc, CCM_ANALOG_PLL_VIDEO_NUM, 0x3FFF);
+   HSET4(sc, CCM_ANALOG_PLL_VIDEO_NUM, 0xB);
+   HCLR4(sc, CCM_ANALOG_PLL_VIDEO_DENOM, 0x3FFF);
+   HSET4(sc, CCM_ANALOG_PLL_VIDEO_DENOM, 0xC);
+
+   HCLR4(sc, CCM_ANALOG_PLL_VIDEO, CCM_ANALOG_PLL_VIDEO_POWERDOWN);
+   while(!(HREAD4(sc, CCM_ANALOG_PLL_VIDEO) & CCM_ANALOG_PLL_VIDEO_LOCK));
+
+   HSET4(sc, CCM_ANALOG_PLL_VIDEO, CCM_ANALOG_PLL_VIDEO_ENABLE);
+   HCLR4(sc, CCM_ANALOG_PLL_VIDEO, CCM_ANALOG_PLL_VIDEO_BYPASS);
+}
+
+void
 imxccm_enable_enet(void)
 {
struct imxccm_softc *sc = imxccm_sc;
@@ -554,6 +607,35 @@ imxccm_enable_pcie(void)
HWRITE4(sc, CCM_ANALOG_PLL_ENET_SET, CCM_ANALOG_PLL_ENET_125M_PCIE);
 
HSET4(sc, CCM_CCGR4, CCM_CCGR4_125M_PCIE);
+}
+
+void
+imxccm_enable_hdmi(void)
+{
+   struct imxccm_softc *sc = imxccm_sc;
+
+   imxccm_enable_ipu();
+   imxccm_enable_pll_video();
+
+   /* Set display interface clock to 65MHz */
+   HCLR4(sc, CCM_CCGR2, CCM_CCGR3_IPU1_DI0_CLK_MASK);
+   HCLR4(sc, CCM_CHSCCDR, CCM_CHSCCDR_IPU1_DI0_PRE_CLK_SEL_MASK);
+   HCLR4(sc, CCM_CHSCCDR, CCM_CHSCCDR_IPU1_DI0_PODF_MASK);
+   HCLR4(sc, CCM_CHSCCDR, CCM_CHSCCDR_IPU1_DI0_CLK_SEL_MASK);
+   HSET4(sc, CCM_CHSCCDR, 0x2 << CCM_CHSCCDR_IPU1_DI0_PRE_CLK_SEL_SHIFT);
+   HSET4(sc, CCM_CHSCCDR, 0x6 << CCM_CHSCCDR_IPU1_DI0_PODF_SHIFT);
+   HSET4(sc, CCM_CCGR2, CCM_CCGR3_IPU1_DI0_CLK_MASK);
+
+   HSET4(sc, CCM_CCGR2, CCM_CCGR2_HDMI_TX_ISFRCLK);
+   HSET4(sc, CCM_CCGR2, CCM_CCGR2_HDMI_TX_IAHBCLK);
+}
+
+void
+imxccm_enable_ipu(void)
+{
+   struct imxccm_softc *sc = imxccm_sc;
+
+   HSET4(sc, CCM_CCGR3, CCM_CCGR3_IPU1_IPU_CLK_MASK);
 }
 
 void 
Index: imx/imxccmvar.h
===
RCS file: /cvs/src/sys/arch/armv7/imx/imxccmvar.h,v
retrieving revision 1.2
diff -u -p -r1.2 imxccmvar.h
--- imx/imxccmvar.h 30 May 2015 08:09:19 -  1.2
+++ imx/imxccmvar.h 5 Aug 2016 06:50:24 -
@@ -32,5 +32,6 @@ void imxccm_enable_pll_usb2(void);
 void imxccm_enable_enet(void);
 void imxccm_enable_sata(void);
 void imxccm_enable_pcie(void);
+void imxccm_enable_hdmi(void);
 
 #endif /* IMXCCMVAR_H */
Index: imx/imxdisplay.c
===
RCS file: imx/imxdisplay.c
diff -N imx/imxdisplay.c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ imx/imxdisplay.c5 Aug 2016 06:50:24 -
@@ -0,0 +1,239 @@
+/*
+ * Copyright (c) 2016 Ian Sutton <i...@kremlin.cc>
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+
+struct imxdisplay_screen {
+   LIST_ENTRY(imxdisplay_screen) link;
+
+   size_t buf_size;
+   size_t map_size;
+   void   *buf_va;
+   intdepth;
+   struct rasops_info rinfo;
+
+};
+
+struct imxdisplay_softc {
+   struct device   sc_dev;
+   bus_space_tag_t sc_iot;
+   bus_space_handle_t  sc_ioh;
+   struct rasops_info  *ro;
+};
+
+int  imxdisplay_match(struct device *, void *, void *a);
+void imxdisplay_attach(struct device *, struct device *, void *);
+int  imxdisplay_activate(struct device *, int);
+
+int  imxdisplay_ioctl(void *, u_long, caddr_t, int, struct proc *);
+int  imxdisplay_alloc_screen(void *, const struct wsscreen_descr *,
+   void **, int *, int *, long *);
+void imxdisplay_free_screen(void *, void *);
+int  imxdisplay_show_screen(void *, void *, int,
+   void (*)(void *, int, int)

man9/rasops.9: clarify ambiguous wording

[Ian Sutton]

Be clear.

Ian

Index: sys/dev/rasops/rasops.h
===
RCS file: /cvs/src/sys/dev/rasops/rasops.h,v
retrieving revision 1.17
diff -u -p -r1.17 rasops.h
--- sys/dev/rasops/rasops.h 7 Sep 2015 18:00:58 -   1.17
+++ sys/dev/rasops/rasops.h 5 Aug 2016 04:19:00 -
@@ -62,7 +62,7 @@ struct rasops_screen;
 struct rasops_info {
/* These must be filled in by the caller */
int ri_depth;   /* depth in bits */
-   u_char  *ri_bits;   /* ptr to bits */
+   u_char  *ri_bits;   /* ptr to framebuffer bits */
int ri_width;   /* width (pels) */
int ri_height;  /* height (pels) */
int ri_stride;  /* stride in bytes */
Index: share/man/man9/rasops.9
===
RCS file: /cvs/src/share/man/man9/rasops.9,v
retrieving revision 1.16
diff -u -p -r1.16 rasops.9
--- share/man/man9/rasops.9 7 Sep 2015 18:43:54 -   1.16
+++ share/man/man9/rasops.9 5 Aug 2016 04:19:00 -
@@ -60,7 +60,7 @@ struct rasops_info {
 * These must be filled in by the caller
 */
int ri_depth;   /* depth in bits */
-   u_char  *ri_bits;   /* ptr to bits */
+   u_char  *ri_bits;   /* ptr to framebuffer bits */
int ri_width;   /* width (pels) */
int ri_height;  /* height (pels) */
int ri_stride;  /* stride in bytes */

armv7/imx: imxdisplay(4)

[Ian Sutton]

nable_pll_video();
+   HSET4(sc, CCM_CCGR2, CCM_CCGR2_HDMI_TX_ISFRCLK);
+   HSET4(sc, CCM_CCGR2, CCM_CCGR2_HDMI_TX_IAHBCLK);
 }
 
 void 
Index: sys/arch/armv7/imx/imxccmvar.h
===
RCS file: /cvs/src/sys/arch/armv7/imx/imxccmvar.h,v
retrieving revision 1.2
diff -u -p -r1.2 imxccmvar.h
--- sys/arch/armv7/imx/imxccmvar.h  30 May 2015 08:09:19 -  1.2
+++ sys/arch/armv7/imx/imxccmvar.h  1 Aug 2016 07:32:00 -
@@ -32,5 +32,6 @@ void imxccm_enable_pll_usb2(void);
 void imxccm_enable_enet(void);
 void imxccm_enable_sata(void);
 void imxccm_enable_pcie(void);
+void imxccm_enable_hdmi(void);
 
 #endif /* IMXCCMVAR_H */
Index: sys/arch/armv7/imx/imxdisplay.c
===
RCS file: sys/arch/armv7/imx/imxdisplay.c
diff -N sys/arch/armv7/imx/imxdisplay.c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ sys/arch/armv7/imx/imxdisplay.c 1 Aug 2016 07:32:00 -
@@ -0,0 +1,243 @@
+/*
+ * Copyright (c) 2016 Ian Sutton <i...@kremlin.cc>
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+struct imxdisplay_screen {
+   LIST_ENTRY(imxdisplay_screen) link;
+
+   size_t buf_size;
+   size_t map_size;
+   void   *buf_va;
+   intdepth;
+   struct rasops_info rinfo;
+
+};
+
+struct imxdisplay_softc {
+   struct device   sc_dev;
+   bus_space_tag_t sc_iot;
+   bus_space_handle_t  sc_ioh;
+   struct rasops_info  *ro;
+};
+
+int  imxdisplay_match(struct device *, void *, void *a);
+void imxdisplay_attach(struct device *, struct device *, void *);
+int  imxdisplay_activate(struct device *, int);
+
+int  imxdisplay_ioctl(void *, u_long, caddr_t, int, struct proc *);
+int  imxdisplay_alloc_screen(void *, const struct wsscreen_descr *,
+   void **, int *, int *, long *);
+void imxdisplay_free_screen(void *, void *);
+int  imxdisplay_show_screen(void *, void *, int,
+   void (*)(void *, int, int), void *);
+void imxdisplay_doswitch(void *, void *);
+int  imxdisplay_load_font(void *, void *, struct wsdisplay_font *);
+int  imxdisplay_list_font(void *, struct wsdisplay_font *);
+int  imxdisplay_getchar(void *, int, int, struct wsdisplay_charcell *);
+void imxdisplay_burner(void *, u_int, u_int);
+paddr_t imxdisplay_mmap(void *, off_t, int);
+
+void imxdisplay_setup_rasops(struct imxdisplay_softc *, struct rasops_info *);
+
+struct wsdisplay_accessops imxdisplay_accessops = {
+   .ioctl = imxdisplay_ioctl,
+   .mmap = imxdisplay_mmap,
+   .alloc_screen = imxdisplay_alloc_screen,
+   .free_screen = imxdisplay_free_screen,
+   .show_screen = imxdisplay_show_screen,
+   .getchar = imxdisplay_getchar,
+   .load_font = imxdisplay_load_font,
+   .list_font = imxdisplay_list_font,
+   .burn_screen = imxdisplay_burner
+};
+
+struct cfattach imxdisplay_ca = {
+   sizeof(struct imxdisplay_softc), imxdisplay_match, imxdisplay_attach, 
NULL,
+   imxdisplay_activate
+};
+
+struct cfdriver imxdisplay_cd = {
+   NULL, "imxdisplay", DV_DULL
+};
+
+struct rasops_info imxdisplay_ri;
+struct wsscreen_descr imxdisplay_stdscreen = {
+   "std"
+};
+
+const struct wsscreen_descr *imxdisplay_scrlist[] = {
+   _stdscreen,
+};
+
+struct wsscreen_list imxdisplay_screenlist = {
+   nitems(imxdisplay_scrlist), imxdisplay_scrlist
+};
+
+int
+imxdisplay_match(struct device *parent, void *v, void *aux)
+{
+   struct fdt_attach_args *faa = aux;
+   return OF_is_compatible(faa->fa_node, "fsl,imx6q-hdmi");
+}
+
+void
+imxdisplay_attach(struct device *parent, struct device *self, void *args)
+{
+   struct imxdisplay_softc *sc = (struct imxdisplay_softc *) self;
+   struct fdt_attach_args  *faa = args;
+   struct wsemuldisplaydev_attach_args wsaa;
+   struct rasops_info  *ri = _ri;
+
+   sc->sc_iot = faa->fa_iot;
+   if (bus_space_map(sc->sc_iot, faa->fa_reg[0].addr,
+   faa->fa_reg[1].size, 0, &g

armv7/imx: imxpcie(4) driver & device tree problem

[Ian Sutton]

I am working on a MD PCI-E driver for the armv7/imx platform. It
attaches via FDT/simplebus, ascertaining its physical memory addresses
from the fdt structure originating from the dtb files present on the
msdos bootloader partition. The dtb files we're using now have the
cubox's 'pcie' nodes disabled via a "status=disabled" property. The
following patches fix this in the decompiled dtb outfiles:

--- imx6q-cubox-i.dts   Thu Jul 14 01:26:57 2016
+++ imx6q-cubox-i.post.dts  Thu Jul 14 01:27:35 2016
@@ -212,7 +212,7 @@
phandle = <0x46>;
};
 
-   pcie@0x0100 {
+   pcie@0100 {
compatible = "fsl,imx6q-pcie", "snps,dw-pcie";
reg = <0x1ffc000 0x4000 0x1f0 0x8>;
reg-names = "dbi", "config";
@@ -228,7 +228,6 @@
interrupt-map = <0x0 0x0 0x0 0x1 0x1 0x0 0x7b 0x4 0x0 
0x0 0x0 0x2 0x1 0x0 0x7a 0x4 0x0 0x0 0x0 0x3 0x1 0x0 0x79 0x4 0x0 0x0 0x0 0x4 
0x1 0x0 0x78 0x4>;
clocks = <0x2 0x90 0x2 0xce 0x2 0xbd>;
clock-names = "pcie", "pcie_bus", "pcie_phy";
-   status = "disabled";
};
 
pmu {

--- imx6dl-cubox-i.dts  Thu Jul 14 02:04:27 2016
+++ imx6dl-cubox-i.post.dts Thu Jul 14 02:05:04 2016
@@ -191,7 +191,7 @@
phandle = <0x36>;
};
 
-   pcie@0x0100 {
+   pcie@0100 {
compatible = "fsl,imx6q-pcie", "snps,dw-pcie";
reg = <0x1ffc000 0x4000 0x1f0 0x8>;
reg-names = "dbi", "config";
@@ -207,7 +207,6 @@
interrupt-map = <0x0 0x0 0x0 0x1 0x1 0x0 0x7b 0x4 0x0 
0x0 0x0 0x2 0x1 0x0 0x7a 0x4 0x0 0x0 0x0 0x3 0x1 0x0 0x79 0x4 0x0 0x0 0x0 0x4 
0x1 0x0 0x78 0x4>;
clocks = <0x2 0x90 0x2 0xce 0x2 0xbd>;
clock-names = "pcie", "pcie_bus", "pcie_phy";
-   status = "disabled";
};
 
pmu {

Here are the resultant binaries you can copy to your bootloader
partition, for convenience:

http://ce.gl/imx6q-cubox-i.dtb
http://ce.gl/imx6dl-cubox-i.dtb

Replacing these dtbs indeed causes my _match() function to succeed where
it hadn't before.

Finally, here is the (very much in-progress) driver:

Index: sys/arch/armv7/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/armv7/conf/GENERIC,v
retrieving revision 1.31
diff -u -p -r1.31 GENERIC
--- sys/arch/armv7/conf/GENERIC 12 Jul 2016 19:17:49 -  1.31
+++ sys/arch/armv7/conf/GENERIC 14 Jul 2016 06:53:44 -
@@ -53,6 +53,7 @@ imxesdhc* at fdt? # SDHC controller
 sdmmc* at imxesdhc?# SD/MMC bus
 imxahci*   at fdt? # AHCI/SATA
 imxehci*   at fdt? # EHCI
+imxpcie*   at fdt? # PCI-E
 usb*   at imxehci?
 
 # OMAP3xxx/OMAP4xxx SoC
Index: sys/arch/armv7/imx/files.imx
===
RCS file: /cvs/src/sys/arch/armv7/imx/files.imx,v
retrieving revision 1.15
diff -u -p -r1.15 files.imx
--- sys/arch/armv7/imx/files.imx12 Jul 2016 19:17:49 -  1.15
+++ sys/arch/armv7/imx/files.imx14 Jul 2016 06:53:44 -
@@ -51,3 +51,7 @@ file  arch/armv7/imx/imxesdhc.c   imxesdhc
 device imxahci: scsi, atascsi
 attach imxahci at fdt
 file   arch/armv7/imx/imxahci.cimxahci
+
+device imxpcie
+attach imxpcie at fdt
+file   arch/armv7/imx/imxpcie.cimxpcie
Index: sys/arch/armv7/imx/imxpcie.c
===
RCS file: sys/arch/armv7/imx/imxpcie.c
diff -N sys/arch/armv7/imx/imxpcie.c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ sys/arch/armv7/imx/imxpcie.c14 Jul 2016 06:53:44 -
@@ -0,0 +1,77 @@
+/*
+ * Copyright (c) 2016 Ian Sutton <i...@kremlin.cc>
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN

Re: [armv7] introducing tipru(4)

[Ian Sutton]

On Wed, Jul 6, 2016 at 5:41 AM, Damien Miller <d...@mindrot.org> wrote:
> That sounds like a reasonable compromise - it would let the admin load
> code to the PRUs in rc.securelevel for later use, or set
> kern.securelevel=0 in sysctl.conf if they wanted to do development
> on a multi-user system.

OK -- I have tested and fixed the previous design. It is now working
exactly as stated in the man page from my prior mail. Below patch is now
in a review-ready state.

On Wed, Jul 6, 2016 at 3:27 AM, Ian Sutton <krem...@ce.gl> wrote:
> mainbus -> fdt is next.

tipru(4) now attaches via flattened device tree. However, the dtb
included in miniroot-am335x-60.fs is erroneously devoid of a PRU node.
Here is a patch for the decompiled source file:

http://ce.gl/am335x-boneblack.dts.patch

And the resultant binary for convenience's sake:

http://ce.gl/am335x-boneblack.dtb

To replace it (on BBB, assuming root disk is sd0):

# mount /dev/sd0i /mnt
# curl http://ce.gl/am335x-boneblack.dtb > /mnt/am335x-boneblack.dtb
# umount /mnt
# reboot

Ian

Index: etc/etc.armv7/MAKEDEV
===
RCS file: /cvs/src/etc/etc.armv7/MAKEDEV,v
retrieving revision 1.19
diff -u -p -r1.19 MAKEDEV
--- etc/etc.armv7/MAKEDEV   21 May 2016 22:15:09 -  1.19
+++ etc/etc.armv7/MAKEDEV   9 Jul 2016 07:06:54 -
@@ -4,7 +4,7 @@
 # generated from:
 #
 #  OpenBSD: etc.armv7/MAKEDEV.md,v 1.12 2016/05/21 21:30:22 kettenis Exp 
-#  OpenBSD: MAKEDEV.common,v 1.88 2016/05/21 15:17:49 deraadt Exp 
+#  OpenBSD: MAKEDEV.common,v 1.89 2016/05/26 16:29:51 deraadt Exp 
 #  OpenBSD: MAKEDEV.mi,v 1.82 2016/03/12 17:58:59 espie Exp 
 #  OpenBSD: MAKEDEV.sub,v 1.14 2005/02/07 06:14:18 david Exp 
 #
@@ -59,6 +59,7 @@
 #  usb*Bus control devices used by usbd for attach/detach
 # Special purpose devices:
 #  apm Power management device
+#  tipru   Programmable realtime unit
 #  audio*  Audio devices
 #  bio ioctl tunnel pseudo-device
 #  bktr*   Video frame grabbers
@@ -328,6 +329,10 @@ audio*)
MKlist[${#MKlist[*]}]=";[ -e audioctl ] || ln -s audioctl$U audioctl"
;;
 
+tipru*)
+   M tipru c 29 0 200
+   ;;
+
 apm*)
M apm   c 34 0 644
M apmctlc 34 8 644
@@ -469,14 +474,14 @@ local)
;;
 
 all)
-   R gpio0 gpio1 gpio2 gpio3 gpio4 gpio5 gpio6 gpio7 gpio8 vnd0
-   R vnd1 vnd2 vnd3 sd0 sd1 sd2 sd3 sd4 sd5 sd6 sd7 sd8 sd9 cd0
-   R cd1 rd0 tap0 tap1 tap2 tap3 tun0 tun1 tun2 tun3 bio pty0
-   R diskmap vscsi0 ch0 bpf fuse pppx hotplug ptm local wscons
-   R pci0 pci1 pci2 pci3 uall rmidi0 rmidi1 rmidi2 rmidi3 rmidi4
-   R rmidi5 rmidi6 rmidi7 tuner0 radio0 video0 video1 uk0 random
-   R tty00 tty01 tty02 tty03 tty04 tty05 tty06 tty07 tty08 tty09
-   R tty0a tty0b apm pf wd0 wd1 wd2 wd3 std st0 st1 fd
+   R tipru0 gpio0 gpio1 gpio2 gpio3 gpio4 gpio5 gpio6 gpio7
+   R gpio8 vnd0 vnd1 vnd2 vnd3 sd0 sd1 sd2 sd3 sd4 sd5 sd6 sd7
+   R sd8 sd9 cd0 cd1 rd0 tap0 tap1 tap2 tap3 tun0 tun1 tun2 tun3
+   R bio pty0 diskmap vscsi0 ch0 bpf fuse pppx hotplug ptm local
+   R wscons pci0 pci1 pci2 pci3 uall rmidi0 rmidi1 rmidi2 rmidi3
+   R rmidi4 rmidi5 rmidi6 rmidi7 tuner0 radio0 video0 video1 uk0
+   R random tty00 tty01 tty02 tty03 tty04 tty05 tty06 tty07 tty08
+   R tty09 tty0a tty0b apm pf wd0 wd1 wd2 wd3 std st0 st1 fd
;;
 
 wd*|sd*)
Index: etc/etc.armv7/MAKEDEV.md
===
RCS file: /cvs/src/etc/etc.armv7/MAKEDEV.md,v
retrieving revision 1.12
diff -u -p -r1.12 MAKEDEV.md
--- etc/etc.armv7/MAKEDEV.md21 May 2016 21:30:22 -  1.12
+++ etc/etc.armv7/MAKEDEV.md9 Jul 2016 07:06:54 -
@@ -27,6 +27,8 @@ dnl ADVISED OF THE POSSIBILITY OF SUCH D
 dnl
 dnl
 __devitem(apm, apm, Power management device)dnl
+__devitem(tipru, tipru, Programmable realtime unit)dnl
+_mkdev(tipru, tipru*, {-M tipru c major_tipru_c 0 200-})dnl
 _TITLE(make)
 _DEV(all)
 _DEV(ramdisk)
@@ -64,6 +66,7 @@ _DEV(ulpt, 66)
 _DEV(usb, 64)
 _TITLE(spec)
 _DEV(apm, 34)
+_DEV(tipru, 29)
 _DEV(au, 36)
 _DEV(bio, 52)
 _DEV(bktr, 75)
@@ -114,3 +117,4 @@ target(all, cd, 0, 1)dnl
 target(all, sd, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9)dnl
 target(all, vnd, 0, 1, 2, 3)dnl
 target(all, gpio, 0, 1, 2, 3, 4, 5, 6, 7, 8)dnl
+target(all, tipru, 0)dnl
Index: share/man/man4/man4.armv7/tipru.4
===
RCS file: share/man/man4/man4.armv7/tipru.4
diff -N share/man/man4/man4.armv7/tipru.4
--- /dev/null   1 Jan 1970 00:00:00 -
+++ share/man/man4/man4.armv7/tipru.4   9 Jul 2016 07:07:02 -
@@ -0,0 +1,221 @@
+.\" Copyright (c) 2016 Ian Sutton <i...@kremlin.cc>
+.\"
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, pro

Re: [armv7] introducing tipru(4)

[Ian Sutton]

I have revised tipru(4) according to advice given in this thread:

On Mon, Jul 4, 2016 at 10:30 PM, Jonathan Gray <j...@jsg.id.au> wrote:
> There aren't any suser checks either.

On Tue, Jul 5, 2016 at 12:56 AM, Jonathan Gray <j...@jsg.id.au> wrote:
> Perhaps it could only permit access at a particular securelevel
> like gpio or be disabled by default.

On Tue, Jul 5, 2016 at 4:18 AM, Damien Miller <d...@mindrot.org> wrote:
> +1 for doing something like gpio, e.g. an ioctl or sysctl to enable it
> that can only be set at kern.securelevel=0

I've implemented a securelevel(7)-based safeguard system and superuser
checks, summarized by new manpage section replicated below:

SECURITY CONSIDERATIONS
The PRU has comprehensive and unconditional access to all physical
memory present in the system. Accordingly, tipru implements a number of
additional safeguards to prevent exploitation, listed below:

*   tipru will only grant file descriptors, honor write(2) attempts,
and process ioctl(2) calls from real root (ruid 0) regardless of
the device file's permission bits, user login class, or current
securelevel(7).

*   tipru comes disabled by default. Attempts to enable tipru, and
following modification of the instruction/data/shared memory
spaces, are only allowed when the system's securelevel(7) is equal
or lesser than zero. When the system's securelevel(7) is greater
than zero the PRU cores may only be started or halted via the
PRUCTL ioctl(2) call, and the driver itself may be disabled via the
PRUKILL ioctl(2) call which effectively halts and prevents the PRU
from performing any actions until the system is rebooted.

tipru(4) manpage has been heavily revised to cover these new safeguards
and define their functionality very explicitly. For convenience, I've
uploaded the new revision here:

http://ce.gl/tipru.4-rev2.html

The patch below contains my rough implementation of these new
safeguards. It compiles, is complete, but untested as of yet. I'm only
including it to provide a sense of continuity between revisions, I would
like to know whether these new safeguards are the right approach before
I finalize and test the code. Don't bother going over it with a
fine-toothed comb just yet.

mainbus -> fdt is next.

Index: etc/etc.armv7/MAKEDEV.md
===
RCS file: /cvs/src/etc/etc.armv7/MAKEDEV.md,v
retrieving revision 1.12
diff -u -p -r1.12 MAKEDEV.md
--- etc/etc.armv7/MAKEDEV.md21 May 2016 21:30:22 -  1.12
+++ etc/etc.armv7/MAKEDEV.md6 Jul 2016 07:44:53 -
@@ -27,6 +27,8 @@ dnl ADVISED OF THE POSSIBILITY OF SUCH D
 dnl
 dnl
 __devitem(apm, apm, Power management device)dnl
+__devitem(tipru, tipru, Programmable realtime unit)dnl
+_mkdev(tipru, tipru*, {-M tipru c major_tipru_c 0 200-})dnl
 _TITLE(make)
 _DEV(all)
 _DEV(ramdisk)
@@ -64,6 +66,7 @@ _DEV(ulpt, 66)
 _DEV(usb, 64)
 _TITLE(spec)
 _DEV(apm, 34)
+_DEV(tipru, 29)
 _DEV(au, 36)
 _DEV(bio, 52)
 _DEV(bktr, 75)
@@ -114,3 +117,4 @@ target(all, cd, 0, 1)dnl
 target(all, sd, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9)dnl
 target(all, vnd, 0, 1, 2, 3)dnl
 target(all, gpio, 0, 1, 2, 3, 4, 5, 6, 7, 8)dnl
+target(all, tipru, 0)dnl
Index: share/man/man4/man4.armv7/tipru.4
===
RCS file: share/man/man4/man4.armv7/tipru.4
diff -N share/man/man4/man4.armv7/tipru.4
--- /dev/null   1 Jan 1970 00:00:00 -
+++ share/man/man4/man4.armv7/tipru.4   6 Jul 2016 07:45:07 -
@@ -0,0 +1,221 @@
+.\" Copyright (c) 2016 Ian Sutton <i...@kremlin.cc>
+.\"
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies.
+.\"
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+.\"
+.Dd $Mdocdate: May 11 2016 $
+.Dt TIPRU 4 armv7
+.Os
+.Sh NAME
+.Nm tipru
+.Nd Texas Instruments programmable realtime unit controller
+.Sh SYNOPSIS
+.Nm "tipru* at omap0"
+.Sh DESCRIPTION
+The
+.Nm
+driver supports the Programmable Realtime Unit and Industrial Communication
+Subsystem (PRU-ICSS) integrated in Texas Instruments' line of AM335x SoCs. The
+PRU is a pair of 32-bit modified Harvard architecture processor cores which run
+a simple RISC instruction set. The PRU forgoes any kind of heuristic cach

Re: [armv7] introducing tipru(4)

[Ian Sutton]

On Tue, Jul 5, 2016 at 12:56 AM, Jonathan Gray  wrote:
> I don't have time to look into how tied to the rest of the
> system the pru is at the moment.

I can save you the trouble; page 198 of am335x TRM:

"The PRUs have access to all resources on the SoC through the
Interface/OCP Master port"

> Perhaps it could only permit access at a particular securelevel
> like gpio or be disabled by default.

I'm willing to modify the design to fit whichever security model you
find appropriate. I like the idea of locking it to a securelevel. I'm
taking 'disabled by default' to mean you would have to add a specific
option to config(8) infile, which I'm less thrilled about.

Re: [armv7] introducing tipru(4)

[Ian Sutton]

On Mon, Jul 4, 2016 at 10:30 PM, Jonathan Gray  wrote:
> Lack of fdt use aside, we don't want to enable something that
> allows userspace access to system memory like this.

I can understand this sentiment. Maybe next time..

Are you saying you are catagorically opposed to a PRU driver or just
opposed to this driver in its current state?

> There aren't any suser checks either.

I had checks to make certain fds were only granted to uid 0, but figured
they were redundant as MAKEDEV script sets permissions accomplishing the
same thing. 

> The toolchain to create code for it would be a port?

Yes, although it's just an assembler from TI. pasm currently compiles
sans modification & is released under an ISC-like license; it'd be
trivial to port.

https://github.com/beagleboard/am335x_pru_package/tree/master/pru_sw/utils/pasm_source

Ian

[armv7] introducing tipru(4)

[Ian Sutton]

I have written some software to support the PRU (Programmable Realtime
Unit) integrated in Texas Instrument's line of ARM SoCs, specifically
the am335x chips. The PRU is a 32-bit realtime processor that exists as
a subsystem on the SoC. You can read more about it in the linked man
pages.

Included below is a omap/am335x/sitara-specific device driver [tipru(4)] 
and userspace utility [pructl(1)]. Both are complete and fully 
documented in their respective man pages which I have also uploaded for 
convenience:

http://ce.gl/tipru.4.html
http://ce.gl/pructl.1.html

You can find the userspace utility at http://ce.gl/pructl.tar.gz

A simple demonstration of the driver in action, after loading and 
executing code that generates a 129KHz square wave:

http://ce.gl/tipru.jpg

I have done my best to make this code as palpable as possible but I'm
sure there are still outstanding issues. Any advice/pointers are
welcome, I have both the time and the inclination to get this code
tree-ready.

Ian

Index: etc/etc.armv7/MAKEDEV
===
RCS file: /cvs/src/etc/etc.armv7/MAKEDEV,v
retrieving revision 1.19
diff -u -p -r1.19 MAKEDEV
--- etc/etc.armv7/MAKEDEV   21 May 2016 22:15:09 -  1.19
+++ etc/etc.armv7/MAKEDEV   4 Jul 2016 08:54:16 -
@@ -4,7 +4,7 @@
 # generated from:
 #
 #  OpenBSD: etc.armv7/MAKEDEV.md,v 1.12 2016/05/21 21:30:22 kettenis Exp 
-#  OpenBSD: MAKEDEV.common,v 1.88 2016/05/21 15:17:49 deraadt Exp 
+#  OpenBSD: MAKEDEV.common,v 1.89 2016/05/26 16:29:51 deraadt Exp 
 #  OpenBSD: MAKEDEV.mi,v 1.82 2016/03/12 17:58:59 espie Exp 
 #  OpenBSD: MAKEDEV.sub,v 1.14 2005/02/07 06:14:18 david Exp 
 #
@@ -59,6 +59,7 @@
 #  usb*Bus control devices used by usbd for attach/detach
 # Special purpose devices:
 #  apm Power management device
+#  tipru   Programmable realtime unit
 #  audio*  Audio devices
 #  bio ioctl tunnel pseudo-device
 #  bktr*   Video frame grabbers
@@ -231,7 +232,7 @@ vscsi*)
;;
 
 video*)
-   M video$U  c 38 $U 600 
+   M video$U  c 38 $U 600
MKlist[${#MKlist[*]}]=";[ -e video ] || ln -s video$U video"
;;
 
@@ -328,6 +329,10 @@ audio*)
MKlist[${#MKlist[*]}]=";[ -e audioctl ] || ln -s audioctl$U audioctl"
;;
 
+tipru*)
+   M tipru c 29 0 200
+   ;;
+
 apm*)
M apm   c 34 0 644
M apmctlc 34 8 644
@@ -469,14 +474,14 @@ local)
;;
 
 all)
-   R gpio0 gpio1 gpio2 gpio3 gpio4 gpio5 gpio6 gpio7 gpio8 vnd0
-   R vnd1 vnd2 vnd3 sd0 sd1 sd2 sd3 sd4 sd5 sd6 sd7 sd8 sd9 cd0
-   R cd1 rd0 tap0 tap1 tap2 tap3 tun0 tun1 tun2 tun3 bio pty0
-   R diskmap vscsi0 ch0 bpf fuse pppx hotplug ptm local wscons
-   R pci0 pci1 pci2 pci3 uall rmidi0 rmidi1 rmidi2 rmidi3 rmidi4
-   R rmidi5 rmidi6 rmidi7 tuner0 radio0 video0 video1 uk0 random
-   R tty00 tty01 tty02 tty03 tty04 tty05 tty06 tty07 tty08 tty09
-   R tty0a tty0b apm pf wd0 wd1 wd2 wd3 std st0 st1 fd
+   R tipru0 gpio0 gpio1 gpio2 gpio3 gpio4 gpio5 gpio6 gpio7
+   R gpio8 vnd0 vnd1 vnd2 vnd3 sd0 sd1 sd2 sd3 sd4 sd5 sd6 sd7
+   R sd8 sd9 cd0 cd1 rd0 tap0 tap1 tap2 tap3 tun0 tun1 tun2 tun3
+   R bio pty0 diskmap vscsi0 ch0 bpf fuse pppx hotplug ptm local
+   R wscons pci0 pci1 pci2 pci3 uall rmidi0 rmidi1 rmidi2 rmidi3
+   R rmidi4 rmidi5 rmidi6 rmidi7 tuner0 radio0 video0 video1 uk0
+   R random tty00 tty01 tty02 tty03 tty04 tty05 tty06 tty07 tty08
+   R tty09 tty0a tty0b apm pf wd0 wd1 wd2 wd3 std st0 st1 fd
;;
 
 wd*|sd*)
Index: etc/etc.armv7/MAKEDEV.md
===
RCS file: /cvs/src/etc/etc.armv7/MAKEDEV.md,v
retrieving revision 1.12
diff -u -p -r1.12 MAKEDEV.md
--- etc/etc.armv7/MAKEDEV.md21 May 2016 21:30:22 -  1.12
+++ etc/etc.armv7/MAKEDEV.md4 Jul 2016 08:54:16 -
@@ -27,6 +27,8 @@ dnl ADVISED OF THE POSSIBILITY OF SUCH D
 dnl
 dnl
 __devitem(apm, apm, Power management device)dnl
+__devitem(tipru, tipru, Programmable realtime unit)dnl
+_mkdev(tipru, tipru*, {-M tipru c major_tipru_c 0 200-})dnl
 _TITLE(make)
 _DEV(all)
 _DEV(ramdisk)
@@ -64,6 +66,7 @@ _DEV(ulpt, 66)
 _DEV(usb, 64)
 _TITLE(spec)
 _DEV(apm, 34)
+_DEV(tipru, 29)
 _DEV(au, 36)
 _DEV(bio, 52)
 _DEV(bktr, 75)
@@ -114,3 +117,4 @@ target(all, cd, 0, 1)dnl
 target(all, sd, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9)dnl
 target(all, vnd, 0, 1, 2, 3)dnl
 target(all, gpio, 0, 1, 2, 3, 4, 5, 6, 7, 8)dnl
+target(all, tipru, 0)dnl
Index: share/man/man4/man4.armv7/tipru.4
===
RCS file: share/man/man4/man4.armv7/tipru.4
diff -N share/man/man4/man4.armv7/tipru.4
--- /dev/null   1 Jan 1970 00:00:00 -
+++ share/man/man4/man4.armv7/tipru.4   4 Jul 2016 08:54:22 -
@@ -0,0 +1,113 @@
+.\" Copyright (c) 2016 Ian Sutton <i...@kremlin.cc>
+.\"
+.\" Permis

Re: anti-ROP mechanism in libc

[Ian Sutton]

This gives me an idea for how to solve the lack of a first-stage
bootloader (like biosboot(8)) on armv7. Currently U-Boot loads the
kernel image directly into memory and jmp's to its entry point without
an intermediary stage to read /etc/random.seed from disk and provide it
to the kernel to kickstart the random subsystem. I tried to solve this
problem by writing a standalone sd/mmc driver that would operate similar
to biosboot(8) in that it would first be loaded and run by U-Boot, then
read /etc/random.seed and the kernel image from the disk, load the
entropy-supplied kernel into memory and execute it. I found that each
armv7 machine's sd/mmc stack is implemented differently enough to
require a standalone driver for every vendor's armv7 toy despite SD &
MMC supposedly being "standard" interfaces. Trying to keep up with the
ever-expanding list of armv7 machines seems like a futile and inelegant
solution.

Perhaps the entropy normally written to /etc/random.seed upon shutdown
can now be written directly to the kernel image itself, precluding the
need for such standalone drivers. I believe the reason this wasn't done
in the past was to allow checksum verification of the kernel image
between boots. With this new patch, libc.so would change between boots
precluding the possibility of such checksum verification, a contingency
I believe was properly realized and accounted for. If we can stand to
forgo the checksum verification of a big target like libc.so, perhaps we
can forgo it with the kernel image itself too and solve the boot-time
entropy problem.

Ian

Re: [patch] armv7/imx/imxesdhc.c: add imxesdhc_dump_regs

[Ian Sutton]

> I tried enabling bits in the ccm, enabling clocks, making various
> changes to imxesdhc itself and didn't get anywhere.  Similiar story
> with the usb otg port on the cubox.

I have made some headway. Compiling with -DSDHC_DEBUG shows imxesdhc
follows all the nessecary steps for initialization, voltage select,
CID/CSD checking, etc. Only when the driver attempts the first actual
transfer (single block read at address 0, CMD 17) does it fail:

imxesdhc0: start cmd 17 arg=0 data=0xccd94000 dlen=512 flags=0x1c50
proc="sdmmc0"
imxesdhc0: wait_state 1 0 ff8d8088)
imxesdhc0: interrupt status=0x0001
imxesdhc0: intr status 0x1 error 0
resp[0] 0x0900
imxesdhc0: resp=0x900 datalen=512
imxesdhc0: intr status 0x107f error 0
imxesdhc0: software reset reg=0x600
imxesdhc0: data transfer done (error=60)
imxesdhc0: cmd 17 done (flags=0x1c51 error=60)
root on rd0a swap on rd0b dump on rd0b
panic: cannot open disk, 0x1200/0x1202, error 2

This line in particular:

imxesdhc0: intr status 0x107f error 0

indicates many error interrupts were received during the time the driver
was waiting for the "buffer read ready" interrupt following the single
block read command. That interupt never comes and a ETIMEDOUT is
returned (error=60 2 lines down). This is due to the "internal DMA mode"
bit being set; according to the i.MX6 reference manual this stops our
target BRR interrupt from firing (page 5601):

"When internal DMA is not used (DMAEN bit in Transfer Type register is
not set when the command is sent), the uSDHC asserts a DMA request when
the amount of data exceeds the value set in the RD_WML register, that is
available and ready for system fetching data. At the same time, the
uSDHC sets the BRR bit. The buffer read ready interrupt will be
generated if it is enabled by software. When internal DMA is used, the
uSDHC will not inform the system before all the required number of bytes
are transferred (if no error was encountered)."

This bit is set on line 819 in imxesdhc.c. It shouldn't be:

819 HWRITE4(sc, SDHC_MIX_CTRL,
820(HREAD4(sc, SDHC_MIX_CTRL) & (0xf << 22)) | (command & 0x));
821 HWRITE4(sc, SDHC_CMD_XFR_TYP, command);
822
823 splx(s);
824 return 0;

That doesn't look right.

The rest of the driver defaults to using PIO, DMA mode must be
manually enabled with -DSDHC_DMA (It currently doesn't compile). All the
DMA mode-specific code is wrapped in #ifdefs except the line mentioned
above. Removing it advances our progress somewhat:

imxesdhc0: start cmd 17 arg=0 data=0xccd94000 dlen=512 flags=0x1c50
proc="sdmmc0"
imxesdhc0: wait_state 1 0 ff8d8088)
imxesdhc0: interrupt status=0x0011
imxesdhc0: intr status 0x1 error 0
resp[0] 0x0900
imxesdhc0: resp=0x900 datalen=512
imxesdhc0: intr status 0x10 error 0
imxesdhc0: wait_state 800 800 ff8d858e)
imxesdhc0: timeout waiting for 800, state ff8d858e
imxesdhc0: data transfer done (error=60)
imxesdhc0: cmd 17 done (flags=0x1c51 error=60)
imxesdhc0: interrupt status=0x0010
root on rd0a swap on rd0b dump on rd0b
panic: cannot open disk, 0x1200/0x1202, error 2

We now get the BRR interrupt and move on to waiting for the state
register's "buffer read enable" bit to go high. It doesn't, and we
timeout again, this time without all the error interrupts firing:

imxesdhc0: interrupt status=0x0010

Just one interrupt this time, as you can see. It is the "buffer write
ready" interrupt, analagous to the "buffer write enable" state bit we
would be looking for in this situation were we peforming a write instead
of a read. Groan.

This is as far as I got today, I plan on working more on it next week.

> The novena has two slots one internal one with a card detect line and
> one without.  I was told the one without card detect (external) has
> working io and can be mounted the other one can not.

I see 4 slots in the IMX6 dual/quad manual (uSDHC1-4). My cubox i4pro
only seems to have one actual microSD peripheral port and no onboard
eMMC, maybe one of those four slots could be an alternate slot referring
to the peripheral port. fwiw the linux image it shipped with booted
properly.

Ian

[patch] revised/tested sd/mmc sector mode fix

[Ian Sutton]

Hi,

Uwe & I have revised my earlier sdmmc patch adding support for
sector-mode bit setting on certain eMMC devices. Here were my tests
confirming it works:

> On Tue, Oct 27, 2015 at 10:49 PM, ian kremlin  wrote:
> > On Tue, Oct 27, 2015 at 9:26 PM, Uwe Stuehler  wrote:
> >> Can someone verify that this still works?
> >
> > I will test this tomorrow on my micron BBB, Kingston BBB & Cubox i4Pro
> > using an array of sd/sdhc cards.
> 
> Here are my findings. I used a fresh tree grabbed an hour ago with only
> Uwe's patch applied.
> 
>  * Micron BeagleBone Black (problematic eMMC chip that wants sector mode bit):
> 
>   ommmc0 at omap0
>   sdmmc0 at ommmc0
>   ommmc1 at omap0
>   sdmmc1 at ommmc1
>   ...
>   scsibus0 at sdmmc0: 2 targets, initiator 0
>   sd0 at scsibus0 targ 1 lun 0:  SCSI2
> 0/direct fixed
>   sd0: 7388MB, 512 bytes/sector, 15130624 sectors
>   scsibus1 at sdmmc1: 2 targets, initiator 0
>   sd1 at scsibus1 targ 1 lun 0:  SCSI2
> 0/direct fixed
>   sd1: 3744MB, 512 bytes/sector, 7667712 sectors
> 
> Both the eMMC chip and peripheral SD initialize correctly. The
> peripheral SD in this case was a 8GB MicroSD (SDHC). Let's try this
> again with a normal 2GB SD card (via adapter) to make sure non-SDHC
> cards aren't negatively affected:
> 
>   ommmc0 at omap0
>   sdmmc0 at ommmc0
>   ommmc1 at omap0
>   sdmmc1 at ommmc1
>   ...
>   sd0 at scsibus0 targ 1 lun 0:  SCSI2
> 0/direct fixed
>   sd0: 3744MB, 512 bytes/sector, 7667712 sectors
>   scsibus1 at sdmmc0: 2 targets, initiator 0
>   sd1 at scsibus1 targ 1 lun 0:  SCSI2
> 0/direct fixed
>   sd1: 1867MB, 512 bytes/sector, 3823616 sectors
> 
> Everyhing looks good. Finally a test with an SDXC card to
> make sure we cover all the bases:
> 
>   ommmc0 at omap0
>   sdmmc0 at ommmc0
>   ommmc1 at omap0
>   sdmmc1 at ommmc1
>   ...
>   sd0 at scsibus0 targ 1 lun 0:  SCSI2
> 0/direct fixed
>   sd0: 60906MB, 512 bytes/sector, 124735488 sectors
>   scsibus1 at sdmmc1: 2 targets, initiator 0
>   sd1 at scsibus1 targ 1 lun 0:  SCSI2
> 0/direct fixed
>   sd1: 3744MB, 512 bytes/sector, 7667712 sectors
> 
> Looks good. Having all possible combinations work like this
> suggests we have solved the initial problem, but now let's check
> the BBB with the Kingston eMMC to make sure it doesn't cause any
> problems. Providing the sector-mode bits to the Kingston eMMC will
> cause it to fail during init.
> 
>  * Kingston BeagleBone Black (did not have eMMC issues before patch):
> 
>   ommmc0 at omap0
>   sdmmc0 at ommmc0
>   ommmc1 at omap0
>   sdmmc1 at ommmc1
>   ...
>   scsibus0 at sdmmc1: 2 targets, initiator 0
>   sd0 at scsibus0 targ 1 lun 0:  SCSI2
> 0/direct fixed
>   sd0: 3688MB, 512 bytes/sector, 7553024 sectors
>   scsibus1 at sdmmc0: 2 targets, initiator 0
>   sd1 at scsibus1 targ 1 lun 0:  SCSI2
> 0/direct fixed
>   sd1: 7388MB, 512 bytes/sector, 15130624 sectors
> 
> Phew. Let's try the non-microSD, non-SDHC card now:
> 
>   ommmc0 at omap0
>   sdmmc0 at ommmc0
>   ommmc1 at omap0
>   sdmmc1 at ommmc1
>   ...
>   scsibus0 at sdmmc1: 2 targets, initiator 0
>   sd0 at scsibus0 targ 1 lun 0:  SCSI2
> 0/direct fixed
>   sd0: 3688MB, 512 bytes/sector, 7553024 sectors
>   scsibus1 at sdmmc0: 2 targets, initiator 0
>   sd1 at scsibus1 targ 1 lun 0:  SCSI2
> 0/direct fixed
>   sd1: 1867MB, 512 bytes/sector, 3823616 sectors
> 
> Cool, finally the SDXC:
> 
>   ommmc0 at omap0
>   sdmmc0 at ommmc0
>   ommmc1 at omap0
>   sdmmc1 at ommmc1
>   ...
>   scsibus0 at sdmmc1: 2 targets, initiator 0
>   sd0 at scsibus0 targ 1 lun 0:  SCSI2
> 0/direct fixed
>   sd0: 3688MB, 512 bytes/sector, 7553024 sectors
>   scsibus1 at sdmmc0: 2 targets, initiator 0
>   sd1 at scsibus1 targ 1 lun 0:  SCSI2
> 0/direct fixed
>   sd1: 60906MB, 512 bytes/sector, 124735488 sectors
> 
> --
> 
> I think this shows that Uwe's patch will fix the error correctly. I wanted
> to test with my Cubox i4Pro but it lacks an onboard eMMC chip & will
> not be of any worth. Please let me know if there is any further testing
> you would like to see. I would really, really love this patch to go in :)
> 
> Ian

And here is the patch:

Index: sdmmc_mem.c
===
RCS file: /cvs/src/sys/dev/sdmmc/sdmmc_mem.c,v
retrieving revision 1.21
diff -u -p -r1.21 sdmmc_mem.c
--- sdmmc_mem.c 22 Apr 2015 04:02:06 -