Electron752
Posts: 142
Joined: Mon Mar 02, 2015 7:09 pm

Re: RPI2 framebuffer not displaying fully

Sat Mar 25, 2017 4:05 pm

Hi, I saw someone mention about 2GB. It is possible to change total_mem to 2048. I tried it and things boot in 64 bit, but I'm still seeing 1GB. Is that kind of memory actually available, and do I need to modify the DT to get it? Or am I just dreaming and need to go back to bed?

LdB
Posts: 1178
Joined: Wed Dec 07, 2016 2:29 pm

Re: RPI2 framebuffer not displaying fully

Sun Mar 26, 2017 11:49 am

Electron752 wrote:Hi, I saw someone mention about 2GB. It is possible to change total_mem to 2048. I tried it and things boot in 64 bit, but I'm still seeing 1GB. Is that kind of memory actually available, and do I need to modify the DT to get it? Or am I just dreaming and need to go back to bed?
The memory just rolls around at the whatever boundary is set. I use that feature to autodetect memory size in part of my startup assembler code which I assume is the MMU that does that. I strongly suspect that the MMU physical limit is 1024MB because they actually give up 1MB of memory on a Pi2/Pi3 to allow for the peripheral space. So only 1023Mb of the 1024MB on the memory chip is physically accessed. I don't think they would do that if more address space was available it's more work that just pushing the peripheral space into the next address.

I don't think the VC uses the MMU but you have played with that more than me and possibly it can address more but I am pretty sure 1024MB is max address space on the ARM

Electron752
Posts: 142
Joined: Mon Mar 02, 2015 7:09 pm

Re: RPI2 framebuffer not displaying fully

Sun Mar 26, 2017 1:25 pm

No, I actually haven't done anything with the VC. All I did was download the open source VC toolkit that's floating around and compiled a few of the example hello work programs. I didn't even run them actually.

I guess what I was thinking is that with ARM64, it has a very large virtual address space right. No reason some of those virtual addresses have to be directly hooked into physical RAM. One could in theory add some external RAM onto GPIO pins or something, and use some of the physical RAM as a cache. The page tables for the MMU on the ARM could pull in and out this external RAM on demand, possibly.

I even saw a driver floating around somewhere for a secondary memory interface on the BCM2835. I don't know if it works or anything.

The idea is something like external RAM could be used as a stepping stone until the underlying hardware could be improved to integrate some of this functionality onto the silicon. Nobody says the other parts of the chip would even need to have accesss to this external RAM.

LdB
Posts: 1178
Joined: Wed Dec 07, 2016 2:29 pm

Re: RPI2 framebuffer not displaying fully

Mon Mar 27, 2017 6:52 am

Yes it's called bank switching
https://en.wikipedia.org/wiki/Bank_switching
You call also connect up a disk on chip or any of the other myriad of things.
None of which is very exciting unless you have a particular use for the banks.

It's something from what I understand that will never appear of the PI in their design because they already have track routing issues under the SOC. The whole project almost didn't get off the ground because of that problem.

From what has been stated from the foundation in terms of even getting a true USB3 hub you probably have zero probability of getting a memory bank option for what would be a few edge case applications that could ever use it.

As with what they said with the USB3 case you might as well ask them to design a whole new SOC if you go that far.

I would take an RTC first over anything else so at least you can keep time and date when you don't have the unit connected to the internet. In baremetal it's annoying having most of your file write times with some stupid and totally whacky date time because you have no idea what the date and time are unless you buy or design one to plug onto the IO bus.

Return to “Bare metal, Assembly language”