Page MenuHomeFreeBSD

arm64: lop off another 24MB of KVA for early device mappings
ClosedPublic

Authored by kevans on Nov 23 2023, 6:07 AM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Nov 7, 7:52 PM
Unknown Object (File)
Thu, Nov 7, 7:24 PM
Unknown Object (File)
Thu, Nov 7, 5:41 PM
Unknown Object (File)
Mon, Oct 28, 7:02 PM
Unknown Object (File)
Fri, Oct 18, 8:18 PM
Unknown Object (File)
Fri, Oct 18, 8:17 PM
Unknown Object (File)
Fri, Oct 18, 8:04 PM
Unknown Object (File)
Fri, Oct 18, 7:40 PM
Subscribers

Details

Summary

This grows the block enough to fit a 4K 32-bit depth framebuffer; some
firmware would present smaller GOP modes to be able to boot with a
smaller framebuffer on these devices, but the Windows Devkit firmware
is simply not that nice. Instead, it offers exactly one GOP mode that
matches the current resolution of the attached display, so with limited
control over resolution on most of my displays it'd be nice if we could
Just Work(TM) at 4K.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Is there any downside of the increase (beyond the tiny increase in time spent in pmap_bootstrap_l3)?

Is there any downside of the increase (beyond the tiny increase in time spent in pmap_bootstrap_l3)?

I couldn't find one... it's allocated from the very top of KVA (with kernel growing from the bottom), with 512GB of KVA to work with it seems like we'll have bigger issues to solve if this ends up becoming a problem.

This revision is now accepted and ready to land.Nov 23 2023, 3:02 PM