Page 1 of 1
[SOLVED] GOP framebuffer outside of physical RAM
Posted: Tue Dec 01, 2020 5:12 pm
by peachsmith
I'm almost ready to set up my own paging structures in my 64-bit UEFI kernel, but something's bugging me.
The base address of the LFB appears to be outside of the RAM I've provided to qemu.
I passed the argument -m 512M when running the qemu-system-x86_64 command like so:
Code: Select all
qemu-system-x86_64 -serial stdio -L $(OVMF_DIR) -bios OVMF.fd -cdrom myos.iso -m 512M
So I would expect the limit of RAM to be something like 0x20000000, but my gop->Mode->FrameBufferBase appears to be 0x80000000.
Oddly enough, when I write to this location, pixels get plotted on the screen.
Since the FrameBufferBase field in the EFI_GRAPHICS_OUTPUT_PROTOCOL_MODE struct is a EFI_PHYSICAL_ADDRESS, does that mean that the address could be completely outside of the memory given to qemu?
I feel like there's some super obvious rule in the spec I'm just completely overlooking, but I definitely need to understand this before I start assigning my own virtual addresses to things.
Re: GOP framebuffer is apparently outside of physical RAM
Posted: Tue Dec 01, 2020 5:23 pm
by Octocontrabass
The frame buffer is not RAM, it's MMIO. (Which is typically backed by RAM, but that's beside the point.)
Re: GOP framebuffer is apparently outside of physical RAM
Posted: Tue Dec 01, 2020 5:49 pm
by zaval
and also, if you provided 512MB of RAM, it doesn't neccessarily mean, that RAM will be mapped at the System Address space range of 0 through 1F FF FF FF*. did you check the memory map?
as an example, Allwinner A20 (32 bit ARMv7) chip has SDRAM at 0x4000 0000 ... 0xBFFF FFFF.
Re: GOP framebuffer is apparently outside of physical RAM
Posted: Tue Dec 01, 2020 6:11 pm
by peachsmith
Octocontrabass wrote:The frame buffer is not RAM, it's MMIO.
Ah. So a physical address used for MMIO does not necessarily always map to a physical location in RAM at any given time and is therefore not restricted by the amount of RAM present in the system.
Good to know.
zaval wrote:did you check the memory map?
Yes indeed.
Just for completeness, here's my memory map:
Code: Select all
Type Address Pages
Boot Service Code 0000000000000000 1
Conventional 0000000000001000 159
Conventional 0000000000100000 1792
ACPI NVS 0000000000800000 8
Conventional 0000000000808000 8
ACPI NVS 0000000000810000 240
Boot Service Data 0000000000900000 3072
Conventional 0000000001500000 109110
Boot Service Data 000000001BF36000 32
Conventional 000000001BF56000 9422
Loader Code 000000001E424000 20
Conventional 000000001E438000 17
Boot Service Data 000000001E449000 533
Conventional 000000001E65E000 1
Loader Data 000000001E65F000 2
Boot Service Data 000000001E661000 6
Conventional 000000001E667000 1
Boot Service Data 000000001E668000 1210
Boot Service Code 000000001EB22000 172
Boot Service Data 000000001EBCE000 151
Boot Service Code 000000001EC65000 62
Boot Service Data 000000001ECA3000 4
Boot Service Code 000000001ECA7000 63
Boot Service Data 000000001ECE6000 5
Boot Service Code 000000001ECEB000 34
Boot Service Data 000000001ED0D000 1
Boot Service Code 000000001ED0E000 30
Boot Service Data 000000001ED2C000 11
Boot Service Code 000000001ED37000 11
Boot Service Data 000000001ED42000 5
Boot Service Code 000000001ED47000 32
Boot Service Data 000000001ED67000 4
Boot Service Code 000000001ED6B000 48
Boot Service Data 000000001ED9B000 8
Boot Service Code 000000001EDA3000 13
Boot Service Data 000000001EDB0000 2
Boot Service Code 000000001EDB2000 46
Boot Service Data 000000001EDE0000 5
Boot Service Code 000000001EDE5000 27
Boot Service Data 000000001EE00000 515
Boot Service Code 000000001F003000 9
Boot Service Data 000000001F00C000 5
Boot Service Code 000000001F011000 42
Boot Service Data 000000001F03B000 2
Boot Service Code 000000001F03D000 45
Boot Service Data 000000001F06A000 5
Boot Service Code 000000001F06F000 18
Boot Service Data 000000001F081000 4
Boot Service Code 000000001F085000 7
Boot Service Data 000000001F08C000 7
Boot Service Code 000000001F093000 13
Boot Service Data 000000001F0A0000 1
Boot Service Code 000000001F0A1000 6
Boot Service Data 000000001F0A7000 4
Boot Service Code 000000001F0AB000 13
Boot Service Data 000000001F0B8000 3
Boot Service Code 000000001F0BB000 39
Boot Service Data 000000001F0E2000 5
Boot Service Code 000000001F0E7000 8
Boot Service Data 000000001F0EF000 1
Boot Service Code 000000001F0F0000 17
Boot Service Data 000000001F101000 4
Boot Service Code 000000001F105000 36
Boot Service Data 000000001F129000 7
Boot Service Code 000000001F130000 12
Boot Service Data 000000001F13C000 1
Boot Service Code 000000001F13D000 2
Boot Service Data 000000001F13F000 3
Boot Service Code 000000001F142000 8
Boot Service Data 000000001F14A000 3
Boot Service Code 000000001F14D000 5
Boot Service Data 000000001F152000 10
Boot Service Code 000000001F15C000 17
Boot Service Data 000000001F16D000 1
Boot Service Code 000000001F16E000 2
Boot Service Data 000000001F170000 2
Boot Service Code 000000001F172000 2
Boot Service Data 000000001F174000 4
Boot Service Code 000000001F178000 6
Boot Service Data 000000001F17E000 1024
Boot Service Code 000000001F57E000 6
Boot Service Data 000000001F584000 1
Boot Service Code 000000001F585000 9
Boot Service Data 000000001F58E000 3
Boot Service Code 000000001F591000 18
Boot Service Data 000000001F5A3000 844
Runtime Data 000000001F8EF000 256
Runtime Code 000000001F9EF000 256
Reserved 000000001FAEF000 128
ACPI Reclaim 000000001FB6F000 16
ACPI NVS 000000001FB7F000 128
Boot Service Data 000000001FBFF000 513
Conventional 000000001FE00000 132
Boot Service Data 000000001FE84000 32
Boot Service Code 000000001FEA4000 38
Boot Service Data 000000001FECA000 9
Boot Service Code 000000001FED3000 33
Runtime Data 000000001FEF4000 132
ACPI NVS 000000001FF78000 136
Re: GOP framebuffer is apparently outside of physical RAM
Posted: Tue Dec 01, 2020 6:21 pm
by zaval
nice map btw, not as awfully fragmented as uboot's one.
then, in your case, framebuffer isn't (main) RAM at all, like octocontrabass pointed.
Re: GOP framebuffer is apparently outside of physical RAM
Posted: Tue Dec 01, 2020 6:54 pm
by peachsmith
zaval wrote:nice map btw
Ha, thanks. It comes courtesy of OVMF, I think.
Re: GOP framebuffer is apparently outside of physical RAM
Posted: Wed Dec 02, 2020 4:50 am
by linguofreak
peachsmith wrote:Octocontrabass wrote:The frame buffer is not RAM, it's MMIO.
Ah. So a physical address used for MMIO does not necessarily always map to a physical location in RAM at any given time and is therefore not restricted by the amount of RAM present in the system.
Good to know.
None of the RAM that you put into a DIMM slot on physical hardware is, at least on most hardware, *ever* used for the framebuffer at *any* time. Your graphics controller has its own RAM that it uses to store the image to be displayed on screen (otherwise, it would have to contend with the CPU for bus cycles to read the framebuffer out of main RAM as it plotted pixels to the screen).
In general, MMIO looks to the CPU to be just like RAM, and for certain devices (such as a framebuffer), you may actually be reading/writing to RAM on the device, but the RAM you're writing to, once again, is not the RAM that's installed in the DIMM slots on your motherboard. And for other devices, a write to a certain address might just act as a command to the device, and reading from that address may not return the same data that you wrote. The read might just return zero, or random garbage, or might even be interpreted as a command by the device(!), or, depending on the platform and device, might do something nasty like raise a bus fault. I think I've even heard of architectures where attempting to read/write an address that neither RAM nor any device was listening on could lock up the bus.
Re: GOP framebuffer is apparently outside of physical RAM
Posted: Wed Dec 02, 2020 5:13 am
by thewrongchristian
linguofreak wrote:
None of the RAM that you put into a DIMM slot on physical hardware is, at least on most hardware, *ever* used for the framebuffer at *any* time. Your graphics controller has its own RAM that it uses to store the image to be displayed on screen (otherwise, it would have to contend with the CPU for bus cycles to read the framebuffer out of main RAM as it plotted pixels to the screen).
Any PC with integrated GFX (probably on the order of 90% of PCs sold) are exactly like that. The CPU relies on its caches to isolate it from slow memory access and contention with the GPU.
Luckily, GPU access will be burst mode accesses, transferring a large amount in a small time, which modern RAM is not too bad at doing.
Re: GOP framebuffer is apparently outside of physical RAM
Posted: Wed Dec 02, 2020 7:42 am
by peachsmith
linguofreak wrote:a write to a certain address might just act as a command to the device
Looks like I originally had a fundamental misunderstanding of what an "address" was.
I thought a physical address was a location in RAM and any MMIO was just using that location. But apparently an address is just a numerical abstraction over some arbitrary thing that can potentially contain a value.
Re: GOP framebuffer is apparently outside of physical RAM
Posted: Fri Dec 11, 2020 11:59 am
by eekee
peachsmith wrote:I thought a physical address was a location in RAM and any MMIO was just using that location. But apparently an address is just a numerical abstraction over some arbitrary thing that can potentially contain a value.
Yup. I remember my surprise at the first memory map I saw; it was pretty-much the same realisation of a disconnect between address and memory.
It was a 6502-powered machine with RAM from 0 to the 48K mark, ROM from 56K to 64K, and in between were these IO registers which were not memory in the same way. Eventually I got used to it, and then I thought other CPUs were strange with their extra instructions for i/o.
