Kendryte build warnings

[Sean Anderson]

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