10234 uts: early start frame buffer console support

Review Request #1366 — Created Jan. 14, 2019 and submitted

1367, 1368
uts: implement env module support and use data from boot loader
uts: vgareg.h update and remove boot_vga.h
uts: do not reset serial console
uts: identify FB types

  • 0
  • 0
  • 14
  • 8
  • 22
Description From Last Updated
  1. Lot of change here. This looks mostly good... one thing I'd like us to consider is nuking the xpv support -- I am fairly confident that nobody is using the legacy Xen stuff, and that Xen itself has changed so that this would all need to be redesigned anyway. That should probably be discussed with a wider audience, but I think ditching Xen for now might make your job a bit easier.

    1. 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).

  2. usr/src/uts/i86pc/boot/boot_console.c (Diff revision 1)

    Why is this conditional on cursor position now?

    1. 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.

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

  3. usr/src/uts/i86pc/boot/boot_console.c (Diff revision 1)

    I think better approach here would be to use continue, and eliminate the check after the switch statement. As this logic stands now, its harder to follow the flow.

    1. 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:)

  4. usr/src/uts/i86pc/boot/boot_console.c (Diff revision 1)

    Are these tem.* properties documented anywhere?

    1. 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
  2. usr/src/uts/i86pc/boot/boot_console.c (Diff revision 1)
    Is there a reason these aren't in a header file?
  3. usr/src/uts/i86pc/boot/boot_console.c (Diff revision 1)

    Any reason we're not using VGA_TEXT_ROWS and VGA_TEXT_COLS for this? As I assume that's what we're basing it on.

  4. usr/src/uts/i86pc/boot/boot_console.c (Diff revision 1)
    I assume the removal here is for the same reason as in the console case above?
  5. usr/src/uts/i86pc/boot/boot_console.c (Diff revision 1)
    common/util/strtoul seems like it's already been built to handle building in this environment.
    1. 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'
    2. 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:)

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

  6. usr/src/uts/i86pc/boot/boot_console.c (Diff revision 1)
    Remove the two '.' after tem logic?
  7. usr/src/uts/i86pc/boot/boot_fb.c (Diff revision 1)
  8. usr/src/uts/i86pc/boot/boot_fb.c (Diff revision 1)
    Maybe prefix these?
  9. usr/src/uts/i86pc/boot/boot_fb.c (Diff revision 1)
    If we have a height or width that are unsigned, these could become negative when casting them to shorts.
  10. usr/src/uts/i86pc/boot/boot_fb.c (Diff revision 1)
    Do we have something guaranteeing elsewhere that we won't have a bad value passed here that'll cause us to end up in the default case?
    It may make sense to actually use an enum to represent the values so it's easier to know if we've missed a case.
    1. 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...

  11. usr/src/uts/i86pc/boot/boot_fb.c (Diff revision 1)
    See earlier note above.
  12. usr/src/uts/i86pc/boot/boot_fb.c (Diff revision 1)
    What makes sure that we don't index into these array beyond their bounds?
    1. Did add check with fallback:

              if (index >= sizeof (cmap4_to_24.red))
                      index = 0;
  13. usr/src/uts/i86pc/boot/boot_fb.c (Diff revision 1)
    Why do we only want to do this if console is CONS_FRAMEBUFFER?
    1. 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.

  14. usr/src/uts/i86pc/boot/boot_fb.c (Diff revision 1)
    Arrow keys work for me in kmdb on the serial console today. Which case are you referring to here?
    1. 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.

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

  15. usr/src/uts/i86pc/boot/boot_fb.c (Diff revision 1)

    size is a uint32_t, j is an int.

  16. usr/src/uts/i86pc/boot/boot_fb.c (Diff revision 1)
    Size is a uint32_t, j is an int.
  17. usr/src/uts/i86pc/boot/boot_fb.c (Diff revision 1)
    Just to confirm, width here is in uint32_t units right? It's not a number of bytes, but a number of logical cells wide.
    1. yes, of course for < operator we still need signed variable:)

  18. usr/src/uts/i86pc/boot/boot_vga.c (Diff revision 1)
    Are the inb's here that we're ignoring the data from trying to act as a flush to make sure the status is up to date?
    1. 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.

    2. Maybe worth a brief comment?
  19. usr/src/uts/i86pc/dboot/dboot_startkern.c (Diff revision 1)
    Is this why we're allocating two of them? Is there a reason we're not asking the compiler to align that variable?
  20. usr/src/uts/i86pc/sys/framebuffer.h (Diff revision 1)
    Is there a reason that we're using a uint32_t for what I think is basically tracking a boolean? It's fine, just a bit surprising.
  21. usr/src/uts/i86pc/sys/framebuffer.h (Diff revision 1)
    __packed or pragma pack?
  22. usr/src/uts/i86pc/sys/framebuffer.h (Diff revision 1)
  1. Thanks for the clean up, this generally looks good.

  2. usr/src/uts/i86pc/boot/boot_console.c (Diff revisions 1 - 4)
    Will we remove the _NEWFONT definition once that work comes in? Is this a temporary ifdef?
    1. 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.

  1. Ship It!
Review request changed

Status: Closed (submitted)