System memory in jz4780
valerij zaporogeci <[email protected]> Fri, 7 Apr 2017 21:42:34 +0300
| Newsgroups | gmane.os.netbsd.ports.evbmips |
|---|---|
| Message-ID | <CANPuzFxCQC1dea2jABO1CTHYGZcfamPKqSfcgNojyOvreDBb7Q@mail.gmail.com> |
Hi, NetBSD developers. I have a question, maybe you could answer it. It relates to Ingenic jz4780 SoC found in CI20 board. It has TCSM - tightly coupled shared memory, from where ROM code's payload runs before it initializes SDRAM. The payload is u-boot for example. Processor address of TCSM is f4000000. It's kseg3, a mapped segment. The question is how it works at the time the payload runs? Architecturally it only could run if this area had appropriate tlb entries. I've checked all the 32 tlb entries and didn't find there anything valid. Don't you know how this works? Has Ingenic introduced yet another unmapped region in the above part of kseg3? Does NetBSD use these virtual addresses (>= f4000000)? Do they work? And yet another question. Suppose I map SDRAM this way - BASE (in DDRC) is 0x00 and MASK is 0x80. This means I have addresses from 0-7fffffff (2 GB) for SDRAM and since there is only 1GB of SDRAM, the whole space will be split into two subspaces - lower and higher aliases. Namely - [0 - 3f ff ff ff] and [40 00 00 00 - 7f ff ff ff]. Physical addresses of the range between 10 00 00 00 - 1f ff ff ff are reserved for ROM, I/O and other. This is 256 MB. If I used the higher aliases for this range (thus 50 00 00 00 - 6f ff ff ff) for SDRAM accesses, would they get into SDRAM? They should, but I am not sure, the specification isn't clear. How NetBSD does overcome this 256MB reserved sub-range of the system space when referencing SDRAM physical pages?