Some ports used a messy uarti8250 clone that had its
own backdoor unbuffered uart interface (serialputc()...),
which is really not needed at all, as devuart provides
one with uartputc(), once one sets uartcons variable.
There was some ugly interleaving of prints for mpinit,
which was because uartreset() (called from chandevreset)
would set serialoq ealy before the clocks are ticking,
so the coming up processors would use the buffered uart
while cpuidprint uses the unbufferd one...
Instead, we set serialoq in uartini() (called from
chandevinit) which is guaranteed to be done after
mpinit has completed.
Handle the mapping from MPIDR_EL1 to machno with a
mpidindex() function, that uses a new MPIDMASK
constant from mem.h that signifies the cpuid bits.
This way, other affinity arrangements can be supported
by just changing the MPIDMASK constant.
The 802.11 signal strength was specific to the
pcmcia wavelan driver. I do not think anyone
has one at this point.
Ethernet used to only consider /net/ether0/stats file,
but with usb ethernets or multiple ethernet devices
it seems misleading and arbitrary.
Instead, sum up all the statistics counters of
all ethernet devices found and preset that for the graph.
Keep emmc as sdM and sdhc as sdN (pi4 only), so ether4330
works in both pi3 and pi4 configurations.
ether4330 is commented out in pi3 config as we'r currenly
lacking a sdhost driver so we loose the sdcard if we use it.
devsd/sdmmc: provide annexsdio() function to take over a
sdio controller from devsd. this removes the tight
coupling between ether4330.
devsd: get rid of legacy function pointer in SDifc struct.
ether4330: cleanup code, fix bugs, set bus speed to 50Mhz,
provide multicast and promiscuous mode support.
One might think that specifying the listen address
is enougth to prevent running a open resolver,
but this does not work for global IPv6 addresses.
The -L flag allows answering recursive queries
ONLY for IP addresses that are directly reachable
on a interface.
To properly handle TCP fallback for servers,
we have to avoid sending responses too big
for the client to accept.
We used to accept up to 8K of UDP requests
(and responses when resolving).
Instead, we now advertise a UDP response size
of 1232 (assuming 1280 MTU) to the client
and take even smaller values into account
from clients (tho not smaller than 512).
This makes sure we truncate packets, signaling
the client that it must retry with TCP.
Note that we still accept up to 8K of
UDP data regardless (for lucky clients).