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.
Details
Details
- Reviewers
andrew manu emaste - Group Reviewers
arm64 - Commits
- rGa3ceeef26bc8: arm64: lop off another 24MB of KVA for early device mappings
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 54582 Build 51471: arc lint + arc unit
Event Timeline
Comment Actions
Is there any downside of the increase (beyond the tiny increase in time spent in pmap_bootstrap_l3)?
Comment Actions
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.