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@X nodes, and having /memory/memory@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@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