riscv: Sipeed Maix support

[Sean Anderson]

I've been working on adding support for the Sipeed Maix-series boards,
specifically the Bit <https://wiki.sipeed.com/en/maix/board/bit.html>.
The majority of the work has been going toward the Kendryte K210 CPU,
and should be generalizable to all of the Maix boards. I've gotten
u-boot to reach the relocation stage (at which point if fails silently).
However, before continuing, I'd like to get some feedback on what I've
already written. My current code is located at
<https://github.com/Forty-Bot/u-boot/tree/maix_v1>.

How is the function fdtdec_setup_memory_banksize_fdt supposed to work?
I've tried different combinations of having a single /memory node,
having multiple /memory at X nodes, and having /memory/memory at foo nodes,
but it never seems to detect anything other than a start and size of
0x0. I've added the device_type = "memory" property, but it doesn't seem
to detect anything. The k210 has two banks of sram adjacent in address
space, each with their own clock. Should these count toward
NR_DRAM_BANKS? Should they be separate top-level memory nodes in the
device tree, or part of a single memory node using ranges to keep the
parent address space?

What configuration should be located in board/*/*/Kconfig and what
should be located in include/configs? It seems like generally only SYS_
configs are in include/configs, but some like SYS_BOARD or SYS_VENDOR
are located in the board Kconfig.

What should the max frequency be for the MicroSD card slot (located in
arch/riscv/dts/k210-maix.dts)? Most other devicetrees I've seen have
some kind of sdhci controller, but this slot is wired directly to one of
the spi controllers.

What does /cpus/timebase-frequency represent? How does it differ from
/cpus/cpu at X/cpu-frequency?

The instruction and data cache line sizes are not specified in the data
sheet. Is it better to over- or underestimate them until they can be
determined?

I'm not sure which drivers (if any) correspond to the gpio, timer,
watchdog, and rtc devices. There are also missing drivers for the kpu,
fft, sha256, aes, dvp, and sysctl devices, but those seem like
non-standard IP blocks at first glance. There are some good descriptions
of the registers at
<https://github.com/laanwj/k210-sdk-stuff/blob/master/doc/memory_map.md>,
which are themselves derived from
<https://github.com/kendryte/kendryte-standalone-sdk/>.

Is the way the sysctl device (located on line 326 of
arch/riscv/dts/k210.dtsi) described reasonable? The primary function of
this device is to control clocks and resets, but there are also several
other functions thrown in. For example, there are dma- and power-related
registers located in that address range as well. Presumably a future
k220 could add more (unrelated) functionality to this region.

Which devices should have status = "disabled" in
arch/riscv/dts/k210.dtsi? From looking at other dtsi files, it seems
like only "core devices" should be left enabled, but I'm not sure how to
make that decision for this cpu.

How does the gpio/pin-controller model work? Should the device tree
describe the default configuration, even if it can be changed at
runtime?

There is a region of memory used by the kpu (neural network accelerator)
as scratch memory. When the kpu is disabled, this region may be treated
like any other region of memory. I've left this region out of the device
tree, but since the kpu is unlikely to be needed when u-boot is running,
should this region of memory be added? Perhaps it should be documented
as reserved-memory and referenced by the kpu device?

There is a region of memory at 0x40000000 which is a non-cached version
of memory at 0x80000000. How should this be described? I believe using
this lower region of memory is necessary for interfacing with the DMA
controller.

This cpu uses both the Andes PLIC and SiFive Clint devices. Currently
they both provide riscv_*_ipi functions, despite their other
functionalities as interrupt controllers and counter controllers,
respectively. Commit b380dbb adds a simple ifdef to disable the ipi
functions of the Andes plic, as IPIs are handled by the clint on the
k210. However, presumably this situation is not unique, and there could
be other processors which include both devices. I think there should be
some kind of kconfig for this, but I'm not sure how it should be worded.
Part of this problem could be fixed by making both devices proper
interrupt-controllers.

The mcounteren CSR raises an exception when written to in
arch/riscv/cpu/cpu.c (c.f. commit b768942). The datasheet claims the
k210 "Support for different privilege levels to improve safety," so
perhaps the k210 only has M and U privilege levels. The exact bits which
cause a problem will need further investigation.

The magic bytes for the device tree get zeroed-out by something prior to
being parsed by u-boot. Trying to write to the magic byte location
causes the device to become unresponsive. The tree is otherwise intact.
The current fix is to just disable the check at runtime (commit
7dee06b), but this is obviously not ideal. I'd appreciate any
suggestions for debugging this.

	--Sean