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.
Nov 27 2018
is it too late to commit this to 12?
Oct 22 2018
Oct 13 2018
Sep 15 2018
Sep 9 2018
Sep 6 2018
re-did diff to include all lines
applied diff to most recently obtained revision (r338415), added as-is. No build nor startup problems noted.
Jul 1 2018
cosmetic things, added the Makefile line to build the rpi3 patch
Jun 23 2018
Jun 22 2018
verified working ok in r335524 which includes the name change applied to spigen ( https://reviews.freebsd.org/rS335506 ) on RPi 1 B.
Jun 21 2018
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.
Jun 16 2018
Jun 15 2018
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).
Jun 14 2018
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.
Jun 13 2018
Jun 12 2018
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.
Jun 7 2018
may need an overlay for RPi 2
Jun 4 2018
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.
May 18 2018
May 17 2018
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).
May 10 2018
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.
May 5 2018
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...
May 4 2018
updated 'dtso' formatting to latest spec in accordance with r332483 commit comment
added DTSO= section to sys/modules/dtb/rpi/Makefile (as recommended)
May 3 2018
removed recommended port; added to base instead, to be installed in /boot/dtb/overlays/
removing the port diff; putting 2 overlays into base
Apr 30 2018
Apr 27 2018
Apr 26 2018
- 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.
- 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.
- removed save/restore of clock freq and mode (it's not necessary)
- check for clock == 0 and fail with EINVAL
Apr 24 2018
Apr 18 2018
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)
Apr 16 2018
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').
Apr 14 2018
Apr 12 2018
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.
Apr 11 2018
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.