On 24/06/2016 08:41, Claudio Fontana wrote: >> I use qboot for similar goals, you mention that PAM is necessary because of >> how qboot probes parallel flash, >> however in my custom platform I removed PAM completely from QEMU, and >> everything seems to work without any problems.. > > Btw before you ask: yes I am booting with pflash.
By default low memory points to PCI address space 00000000000f0000-00000000000fffff (prio 1, RW): alias pam-ram @pc.ram 00000000000f0000-00000000000fffff [disabled] 00000000000f0000-00000000000fffff (prio 1, RW): alias pam-pci @pc.ram 00000000000f0000-00000000000fffff [disabled] 00000000000f0000-00000000000fffff (prio 1, R-): alias pam-rom @pc.ram 00000000000f0000-00000000000fffff [disabled] 00000000000f0000-00000000000fffff (prio 1, RW): alias pam-pci @pci 00000000000f0000-00000000000fffff All that qboot does is enabling pam-ram: // Make ram from 0xc0000-0xf0000 read-write int i; for (i=0; i<6; i++) { int pam = pambase + 1 + i; pci_config_writeb(bdf, pam, 0x33); } // Make ram from 0xf0000-0x100000 read-write and shadow BIOS // We're still running from 0xffff0000 pci_config_writeb(bdf, pambase, 0x30); memcpy(low_start, bios_start, 0x10000); So if you remove PAM but you are leaving 0xC000-0x10000 pointing to RAM, you are effectively moving qboot's PAM configuration to QEMU. :) Of these writes, only the last write is strictly necessary. qboot currently uses 0xe0000-0xf0000 for the ACPI tables but we could move them to the EBDA instead and save the initial loop. But I'd like to see a trace saying how much time is spent configuring PAM exactly. Paolo