bdragon28
commented
3 years ago More musing on this:
FreeBSD can cope with all of the PCI BARs being passed through in assigned-addresses. It has heuristics to identify which one is the framebuffer by looking for an entry in assigned-addresses which is large enough to contain the computed framebuffer size (based on stride * height) and is prefetchable.
As long as the device shutdown involves resetting the framebuffer base to the start of the framebuffer memory range, things should work fine. (This appears to be the case for ast)
Linux has similar logic in offb_init_nodriver().
It might be best to just copy the PCI BARs instead of trying to recalculate the base, and ensure the drivers' shutdown behavior resets the base address to the start of framebuffer memory (pci side wise), since we want to turn off stuff like double buffering anyway during kexec when using a raw framebuffer, because if it's been flipping back and forth between two pages constantly, it would become indeterminate what the correct base address at the moment the driver is shut down would be.
Recent versions of Petitboot are setting the physical address of the framebuffer, on the device tree, to a wrong value (assigned-addresses property of vga node). This was seem on a Talos II machine, with latest firmware release, when trying to boot FreeBSD through the VGA console, there is no video output at all.
The problem seems to be in 30-dtb-updates, that relies on an ioctl to /dev/fb0 to get its physical address, but recent Linux kernels hide it by default, returning 0 instead. However, setting CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM to force the kernel to leak the address didn't work for me, as the ast (ASPEED) driver was also changed to use drm_fb_helper, that doesn't set smem_start for devices using a shadow buffer.