On 7/28/20 9:20 AM, Sean Anderson wrote:
On 7/28/20 8:31 AM, Heinrich Schuchardt wrote:
Another issue I found is that the memory size is not correctly set on the Kendryte as reported by bdinfo.
DRAM bank = 0x0000000000000000 -> start = 0x0000000080000000 -> size = 0x0000000000400000 DRAM bank = 0x0000000000000001 -> start = 0x0000000080400000 -> size = 0x0000000000200000 DRAM bank = 0x0000000000000002 -> start = 0x0000000080600000 -> size = 0x0000000000200000 memstart = 0x0000000000000000 memsize = 0x00000000 <<<<<<<<<<
I would have expected memsize = 0x800000.
Ok, I will look into that.
Ok, so as far as I can tell, only setup_board_part1 sets bi_memstart or bi_memsize. Outside of M68K, MIPS, PPC, and SH, the only generic code which reads those variables is env_get_bootm_size. ARM and MICROBLAZE both use the first DRAM bank to get the size, and everything else gets it from the "bootm_size" environmental variable.
I was having some troube booting certain image types earlier, so perhaps I just need set bootm_size to something sane. The Andestech boards don't set it in include/config/*.h, but instead include it in their Linux boot example. Rick, can you comment on how bootm_size (or bi_memsize) should be set?
---
On the subject of RAM layout, I have been unable to access the "ai ram" (the 3rd bank) without hanging the board. This ram is supposed to be usable by the cpu while the kpu is unused. For an example of what I am testing:
=> md.l 0x80400000 80400000: 00000000 00000000 00000000 00000000 ................ 80400010: 00000000 00000000 00000000 00000000 ................ 80400020: 00000000 00000000 00000000 00000000 ................ 80400030: 00000000 00000000 00000000 00000000 ................ 80400040: 00000000 00000000 00000000 00000000 ................ 80400050: 00000000 00000000 00000000 00000000 ................ 80400060: 00000000 00000000 00000000 00000000 ................ 80400070: 00000000 00000000 00000000 00000000 ................ 80400080: 00000000 00000000 00000000 00000000 ................ 80400090: 00000000 00000000 00000000 00000000 ................ 804000a0: 00000000 00000000 00000000 00000000 ................ 804000b0: 00000000 00000000 00000000 00000000 ................ 804000c0: 00000000 00000000 00000000 00000000 ................ 804000d0: 00000000 00000000 00000000 00000000 ................ 804000e0: 00000000 00000000 00000000 00000000 ................ 804000f0: 00000000 00000000 00000000 00000000 ................ => md.l 0x80600000 80600000:<board hangs here>
I have tried this on two boards (a maix bit, and a maixdiuino), and gotten the same result. I have tried different combinations of gating the KPU clock, and asserting the reset, but I wasn't able to get it working that way either. I also tried accessing this memory via JTAG, but it hangs via that method as well. I talked to Palmer Dabbelt when he was submitting his K210 series for Linux, and he was able to access this ram bank with no issues. Can you try accessing this memory area?
--Sean