While I would welcome removal of dead code or making it up to date, at this point, I would keep my fingers off of it. Since this patch os basis for followups, I really want it to land fast and with minimal delays. The argiuments about Xen is the last thing I need here. Especially as I need to return to this code and update it at least once more to build new font support (can not do this now due to cyclic dependency with tem and vgatext and gfx_private).

In general we should avoid resetting the display during the boot- we may have valueable messages there, this why the "native" loader boot does pass the console state down to kernel and we do try to pick the state and go on. However, the loader is not the only way to boot; some still use old grub, some use grub2, also ipxe - and the non-native boot loaders do not implement the smooth console; if we have no information about cursor location, we will get value (0, 0) and that means we better clear the screen quite like the old console did. Otherwise we will just scroll on as we go.

I agree, that makes sense. I think it's worth writing a comment here to make that intent clear.

I would rather leave it as is - the code is taken from libc (as noted) and therefore with known quality, and I actually wish to replace this with ddi_strtoul() because our main kernel already has it built in and we only need to add it for dboot. We can do the swap as soon as the surroundinng code changes are done (so I can avoid rewriting the changes:)

Not yet. Since those are set by boot loader, they will be documented there (eventually). Meanwhile, the entire environment block is visible with:
tr '\0' '\n' < /system/boot/environment

yes.

for SPARC boot library... well. I guess it is better to build this anyhow.
../../../common/util/strtoul.c:36:19: error: errno.h: No such file or directory
../../../common/util/strtoul.c:37:19: error: ctype.h: No such file or directory
../../../common/util/strtoul.c:38:20: error: limits.h: No such file or directory
../../../common/util/strtoul.c: In function 'strtoul':
../../../common/util/strtoul.c:67: error: 'errno' undeclared (first use in this function)
../../../common/util/strtoul.c:67: error: (Each undeclared identifier is reported only once
../../../common/util/strtoul.c:67: error: for each function it appears in.)
../../../common/util/strtoul.c:67: error: 'EINVAL' undeclared (first use in this function)
../../../common/util/strtoul.c:105: error: 'ULONG_MAX' undeclared (first use in this function)
../../../common/util/strtoul.c:133: error: 'ERANGE' undeclared (first use in this function)
*** Error code 1
dmake: Fatal error: Command failed for target `dboot/obj64/strtoul.o'

Yea, it still is more complicated because the i86pc unix also is using ddi_strtoul (built from the same source) + errno etc. I think, the best approach s to use this borrowed atoi() for now, and address the stroul() build later with separate update. I really do want to not to overcomplicate things:)

OK, fair enough. Sounds like something we should do for the future.

Default case here is that we have no output - we really can not have output anyhow if we do not support the presented depth and we have no way to announce about the fact...

Did add check with fallback:
        if (index >= sizeof (cmap4_to_24.red))
                index = 0;

The vga text mode is handled in boot_vga.c.
Also, just for an remark - after double checking, I did decisde to keep clear (that is, set cursor to 0,0) till we have new fonts in place. The problem is that otherwise we will get distorted screen due to font differences.

The local console. Serial console has terminal emulator at the other end of the serial link. Actually the reference to arrow keys is not 100% correct here, but almost. With "10195 uts: boot_keyboard should emit esc sequences for arrow keys" the kmdb will start to process arrow keys - we can see the history etc, but since the console can not process the emitted esc sequences, the screen will get filled up with noise.

And I did clear this comment a bit as the kmdb support is behind the corner anyhow.

yes, of course for < operator we still need signed variable:)

Not exactly. It is called flip-flop in some docs, for example, see page 28 at https://downloads.reactivemicro.com/Apple%20II%20Items/Hardware/SecondSite_VGA/Techincal/SecondSightVGARegisters.pdf
Basically, the atr base register is shared for reads and writes and to set it up for reads, one needs to read status register first.

Maybe worth a brief comment?

Yes, and the  comment below. The problem is, with large resolutions we will get 16x32 font, but from old ones, the largest is 19x22 (Gallant), and the difference is very noticeable and messy. So we just have to wait for now.