<div dir="ltr"><div dir="ltr"><div>Hi,</div><div>Thank you.</div><div><br></div><div>But, this feels like a mystery to me. How did the OI text installer load just<br>fine without this patch but the OmniOS image couldn't!</div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Aug 27, 2025 at 9:43 PM Joshua M. Clulow via oi-dev <<a href="mailto:oi-dev@openindiana.org">oi-dev@openindiana.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 27 Aug 2025 at 20:56, Atiq Rahman <<a href="mailto:atiqcx@gmail.com" target="_blank">atiqcx@gmail.com</a>> wrote:<br>
> > I assume you did see “Booting..” text, then it cleared the screen and thats it.<br>
> Yep, I did see that (a few lines including booting) before it showed the cursor only screen. (photo: p1)<br>
><br>
> > ok framebuffer get<br>
> output on photo (p2)<br>
<br>
Based on the photograph, it seems like your framebuffer base address<br>
is 0x7a_1000_0000 which is above the 32-bit boundary.  When you enable<br>
"prom_debug" and "kbm_debug", there is some early boot code which<br>
can't use a 64-bit address to write to the display.  This ultimately<br>
causes the writes to go off into space, and may collide with other<br>
memory that upsets the boot process.<br>
<br>
This is described in a ticket I'm working on at the moment for another<br>
system that has this problem:<br>
<br>
    17548 early boot framebuffer reach exceeds grasp<br>
        <a href="https://www.illumos.org/issues/17548" rel="noreferrer" target="_blank">https://www.illumos.org/issues/17548</a><br>
        <a href="https://code.illumos.org/c/illumos-gate/+/4350" rel="noreferrer" target="_blank">https://code.illumos.org/c/illumos-gate/+/4350</a><br>
<br>
Should hopefully be finished soon!<br>
<br>
<br>
Cheers.<br>
<br>
-- <br>
Joshua M. Clulow<br>
</blockquote></div></div>