Tarl Neustaedter wrote:
I see that for PPC in packages/video.c::init_video the framebuffer is allocated using OFMEM and then mapped 1:1. Blue has suggested that if direct access to the framebuffer is not required then we could try a similar dynamic allocation for SPARC - does anyone how/where OpenBoot stores its VGA framebuffer?
Assuming the AST driver is VGA (I think it is, but I'm not all that familiar with VGA), it does a simple map-in of BAR 10 for size 80.0000, and smaller amounts for BARs 14 and 18. That probably lands it in the 0xfexx.xxxx window.
Look at the Debian sparc-utils prtconf example output, I see the following for the SS-5:
Node 0xffd41b1c address: ffdcd000 character-set: 'ISO8859-1' intr: 00000039.00000000 reg: 00000003.00000000.01000000 dblbuf: 00000000 vmsize: 00000001 depth: 00000008 height: 00000384 awidth: 00000480 linebytes: 00000480 width: 00000480 emulation: 'cgsix' montype: 00000004 boardrev: 000000a1 pixfreq: 066ff300 hfreq: 00011880 vfreq: 0000004c hbporch: 000000c0 hsync: 00000080 hfporch: 00000020 vbporch: 00000021 vsync: 00000008 vfporch: 00000002 fbmapped: 00100000 global-data: ffef8f00 oscillators: '84375000,64125000,108000000,94500000' chiprev: 0000000b device_type: 'display' model: 'SUNW,501-2325' name: 'cgsix'
This seems to suggest memory within the 0xff rather than the 0xfe range. Interestingly enough, the screen device looks like this:
screen: '/iommu@0,10000000/sbus@0,10001000/cgsix@3,0'
Perhaps it's hiding on the SBUS and so it doesn't need a direct mapping? Does the IOMMU allow paged access into SBUS space to avoid having to map it in its entirety?
ATB,
Mark.