On Sun, 14 Apr 2013 22:04:19 -0700 ron minnich <[email protected]> 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. -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
