this prevents less trusted processes from connecting to servers
after the kernel initializations are done.
this works so long as we don't have disconnects from the kernel
servers. In order to support disconnects we will also need a
way to re-enumerate the SID to guarantee that we don't have a re-use
problem. But for now, the kernel is not designed with any practical
disconnect mechanism; there is no code that calls the Quit mechanism
on any server.
the connection number is re-used for all objects created
within a process space, so you can't `Drop` the connection
immediately when an object goes out of scope. You have to
make sure all instance of the object go out of scope. This
patch adds reference counting to all the objects so that
the `Drop` function works as intended.
the concurrency issues on I2C are getting hairy, and it was probably a
dubious decision from the start to merge I2C into the LLIO block; but
originally this was motivated by the idea of keeping all the
"miscellaneous slow stuff" in one process to keep the memory footprint
small and make code a bit more readable.
Keeping I2C in the same process space as the LLIO but splitting it
into its own thread and server splits the difference, by giving us
more options to deal with the concurrency, without inflating the size
of the kernel binary and allocating a lot of extra static data.
Here's an arcane bug for you:
When powering down, the Spartan 7 3.3V I/O drivers will
output a roughly 800us wide glitch as 3.3V falls below around
1.7V, if the 0.95V core voltage comes down first (which it does
because we have an active discharge on 0.95V, but not on 3.3V).
In this case, it's just wide and high enough to cause the
BOOST mode line to engage, which takes the BOOST output
and ties it to VBUS, which is just enough for the system to
think you're powering it back on again. Which is not what
you want when powering down.
The ultimate fix was to put a heftier pull-down on the BOOST
line so that it can't trip the BOOST output into the VBUS.
Another option could be more active discharge FETs, but that
would require a full board spin and we are already at certification,
so we'll stick with the stronger pull-down on BOOST. It seems to
be a robust fix in the worst corner cases we can find.
The downside is that when powering an external USB device,
you are burning an extra 30mW of power overcoming the pull-down,
but typically, any external USB devices plugged into Precursor
will burn far in excess of that, so the delta should be negligible.
There is an issue with the rtc commandline time checking
with respect to unhooking its callback, maybe related to
the new disconnect/destroy server code
