I forgot to mention, someone suggested modifying everything so that only a single overlay is used for all 3 RPi versions. It would require that the compat strings in the single overlay include all 3 of the driver specs. In the past when I have attempted multiple compat strings, the overlay wouldn't load. It is possible I was doing something else wrong, however. Not sure if this should become a blocking issue or not.

is it too late to commit this to 12?

re-did diff to include all lines

applied diff to most recently obtained revision (r338415), added as-is. No build nor startup problems noted.

cosmetic things, added the Makefile line to build the rpi3 patch

verified working ok in r335524 which includes the name change applied to spigen ( https://reviews.freebsd.org/rS335506 ) on RPi 1 B.

additional things that showed up after the last diff

cleaned up a couple of nitty style-related things. Ian go ahead and edit whatever you see fit for style etc.. Thanks also, because I probably wouldn't know what to do anyway.

made changes to accomodate latest changes to D15301 . Removed reliance on sysctl info (can be added later, as needed).

need to verify this is correct by booting it up

applied Ian's comments, added definition for 'options SPIGEN_LEGACY_CDEVNAME' in opt_spi.h . builds, have not tested the bootup (yet). will do that next.

gonzo - I added you as a reviewer since you apparently did the last commit to the driver, and because it's related to the RPi audio.

It looks like there are no pinctrl combinations that can give you simultaneous pl011 and mu serial drivers on the RPi 2. manually tweeking the GPIO pins for the serial console will effectively switch between the two types, but only if you can bring up the 'mu ' driver with it NOT connected to active pins (which appears is not possible; ian suggested that without proper pinctrl support, the driver may constantly interrupt on a 'break' state, which explains what I've seen). However, one of the changes here should be retained since the RPi zero needs the 'mu' driver (it similarly has a bluetooth wired to the pl011 like the RPi 3).

apparently the problem is a bit worse that I thought. the stack backtrace for thread 10000 points to line 300 in init_main.c where the code is attempting to print "done" (for verbose kernel bootup) after completing 'configure_final'. This is the point where the console breaks into ddb.

added some diagnostics to the uart_mu driver. a quick check shows rapid looping on 'uart_mu_bus_ipend' during startup. Additional test code only spat out a message when 'uart_mu_bus_ipend' would return a non-zero value (which apparently it does not).

the overlay file in sys/gnu/dts/arm/bcm283x.dtsi has several clock entries for 'aux' related to uart1:

whoops - sorry people - I posted that last comment to the wrong Phab (it was for D15787

for reference, this is what ofwdump believes those settings should be:

I have not figured out why the kernel hangs (yet). I plan on working on it though. Step 1 will be to doctor up the 'mu' source with a bunch of printf()'s so I can see what it's up to, and at some point I may have to set up a complex remote debug environment for it. It might be as simple as having the wrong interrupt or clock assigned by the pre-defined DTB for the RPI2.

removed some commented-out code, minor edits

Requires D15301 to work properly, i.e. allows the overlay to create the actual devices in reverse order without affecting the ability to relate the 'spigen' device name to its bus and CS number. The fdt library itself causes this to happen; that is, for an overlay the devices are inserted at the beginning of the section, as they are created, resulting in a kind of reversed sort of how they're specified in the overlay. but relying on the order in which the devices are created is undesirable. That is where D15301 comes in, and now the overlays won't have to specify spigen devices in reverse order.

may need an overlay for RPi 2

for RPi it needs support added to the bcm2835_spi driver. See D15031

updated a few comments. RPi 1,2 testing has been pretty good on my end. still needs RPi3 testing though.

updated to be compatible with https://reviews.freebsd.org/D15301 changes. canonicalizes device file name so that a symlink can be used. Determines unit number from device file name using the canonicalized device name itself, or a matching 'spigen=' entry in '%location' (see D15301).

update '%location' in spibus sysctl handler to reflect the spibus unit (and for spigen, spigenN.M name) in addition to the cs .

ian pointed out that uftdi has a '%location' sysctl that contains useful information, including the 'ugen' device alias.
"dev.uftdi.0.%location: bus=7 hubaddr=3 port=2 devaddr=4 interface=0 ugen=ugen7.4"

jhibbits suggested in IRC: it'd be better to have /dev/spi/X.Y, and have /dev/spigenN be a symlink, like USB is

this always creates the 'spigen#' device (based on unit number) as before, but then adds an alias 'spigenM.N' where 'M' is the spibus unit number, and 'N' is the cs pin ID, for each spigen device created.

when this is all done, spigen will probably need a man page, to document the behavior, as well as documenting the sysctl API. I could make it a part of this change to add one...

updated 'dtso' formatting to latest spec in accordance with r332483 commit comment

added DTSO= section to sys/modules/dtb/rpi/Makefile (as recommended)

removed recommended port; added to base instead, to be installed in /boot/dtb/overlays/

removing the port diff; putting 2 overlays into base

1. making the sysctl variables all read-only so you can still view them. changing the values happens with each transaction via spibus ivars. This could be made into a 'debug build only' feature.
2. placed '#ifdef' block around assignment of CS_CSPOLn bits. This feature is effectively broken since there's no apparent method to set them all before any transaction happens. Once there is such a method, they should probably be set just one time and not per transaction. I will investigate doing this on load, and see if it is possible that the cs information is made available while creating the spigen devices.
3. removed save/restore of clock freq and mode (it's not necessary)
4. check for clock == 0 and fail with EINVAL

fixed bug related to '-C' (removed the 3 lines of code I mentioned in an inline comment), and another bug in 'verbose' output (newlines being done wrong)

making some of the requested changes, waiting on others.

it seemed to me that a port was the better choice, although I'm not opposed at all to having it in the base.

made recommended changes by ian (some 'hungarians' might remain, if you want to extend the definition to include things like 'hdev' and 'popt').

this one passes 'igor' on the man page, builds properly. no known issues with it. I think it's ready to ship.

re-arranged the order in which the mode and clock speed are set up. changed the method of setting clock polarity to use the individual 'CSPOL' bits instead of the 'global' one that applies to all CS lines (that would only have worked if all 3 lines have the same polarity). This should correct for the mode 3 glitch (still need to test it). however, it does not fully handle the potential problems with CS polarity; in short, unless you set up all of the CS polarity bits before any transaction occurs, any 'active high' CS device could act as if it were selected while the CS is in its default 'high' state, likely causing contention between slave devices. For now, the actual code is in the proposed patch as-is, and I'll research this further.

I'm making additional (igor-based, other) changes to man page. will update once complete. Otherwise, it's essentially done.

applied man page changes to spi.8 (thanks) . may tweek it again based on 'igor'.

verified mode and speed appear to be working (as assigned via spigen) although some weirdness in mode 3 causes the first received bit to be dropped. This could be my hardware doing it, and not the broadcom. but it's worth noting. it might be clock glitches or timing of the first clock pulse following cs, which can't be delayed with the existing spibus and driver. Applying a delay might help this, or not. Otherwise, it appears to be working properly unless someone can demonstrate a problem that i wasn't able to detect. Worst case I could set up a 2-channel o-scope to trigger off of the first clock pulse and display the bits and their timing, if any of this becomes suspect.