And I did a regression test to ensure that the h3 still works.
One thing missing for the h5 is multiprocessor support (starting other cores). I am just not going to tackle this right now. My time would be better spent going on to yet another board. The most likely candidate would be the 32 bit dual core ARM (with FPGA) in my Zynq boards.
A big mystery is how U-boot could use the network on the h5 with the "dc ivac" issue. It might be good to closely look at the emac drive that U-boot uses.
It would be interesting to develop and test the code to jump from EL2 to EL1. There is a slim chance that this would "fix" the "dc ivac" problem. Such code would not be specific to the H5.
My Nanopi Neo Plus 2 boards have 8G of emmc on board. This raises two thoughts. One is that I could put U-boot itself into emmc. The easiest way to do this is to get an SD card set up to boot debian, but it could be done using U-boot iself, via TFTP and the mmc commands in Uboot. I have learned by painful experience that this can be dangerous, depending on the boot order enforced by the bootrom. If the system will always boot from the SD card first if it is present, we will be OK. I was burned by the Rockchip rom which has NOR flash first.
The h5 TRM shows the boot order as SDC0 -- EMMC2 -- SDC2 -- nand -- spi-nor Section 5.3 of the TRM describes the SMHC (SD/MMC host controller). There are 3 devices and how they relate to the documented bootrom boot order names will take some study and experimentation. The board schematic may make clear what is going on. What we don't want is to write something broken to emmc and then find that our SD card is actually SDC2 and the board is bricked. Why does the boot order specify EMMC2 rather than EMMC0? What about EMMC1?
A second project related to emmc would be to put the Kyu image in a "partition" on emmc so that Kyu could be booted without the network. This is something I have never done, but could be ideal for some projects. Issues involving this could be sorted out with an SD card first.
Multicore will involve several investigations. The work on H3 will provide a loose guide. The first question is whether cores have already been started and parked by ATF, or whether we need to use the same undocumented registers as for the H3. If ATF has them parked, we will need to grab them using calls to ATF (psci). Calls to ATF running at EL3 are called SMC (secure monitor calls). Learning about PSCI here would be beneficial for other 64 bit boards (such as Rockchip) that are in my future.
ATF itself would be worth further study. This could be highly relevant for multicore-psci as just mentioned, but the ATF codebase looks clean and well done and ought to reward study.
Thinking about ATF makes me think about U-boot itself. I was unable to build U-boot from source and get the result to run. This deserves further work.
Tom's software pages / tom@mmto.org