On Sun, 14 Apr 2013 22:04:19 -0700 ron minnich rminnich@gmail.com wrote:
What we do on ARM (see google/snow) for now is reserve a big chunk of memory in the coreboot tables for graphics. You could set the gtt to point to that.
I've seen the framebuffer address for google/snow,I've also seen it passing its address to various functions.
But I failed to find where it creates such tables and passes them in arm.
However I've investigated more and I found that: [...] Root Device assign_resources, bus 0 link: 0 pci_tolm: 0xd0000000 Base of stolen memory: 0xcf800000 Top of Low Used DRAM: 0xd0000000 IGD decoded, subtracting 8M UMA Available memory: 3399680K (3320M) Adding PCIe config bar [...]
Note that TSEG not valid(address=0, len=0) for that platform(Lenovo X60).
Removing SMM removes the corruption in coreboot, but not in the payload.
The BAR holding the framebuffer(which is at 0xd0020000) is here(from lspci): Region 2: Memory at d0000000 (32-bit, prefetchable) [size=256M]
Also before running videotest in grub, all the tables(coreboot,ACPI etc...) are there, but after, all the tables are gone.
Thanks a lot to phcoder/Vladimir Serbinenko because he wrote a coreboot framebuffer driver for grub.
Thanks to that I've done some test:
1) run lscoreboot or lsmmap or any command that list or uses the tables. => it works 2) run videotest => it works in qemu,fails on the X60. 3) the tables are gone on the X60.
Denis.