Some framebuffer properties obtained from the device tree were not being
properly converted to host endian.
Replace OF_getprop calls by OF_getencprop where needed to fix this.
This fixes boot on PowerPC64 LE, when using ofwfb as the system console.
Reviewed by: bdragon
Sponsored by: Eldorado Research Institute (eldorado.org.br)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D27475
- Implements little-endian support (powerpc64le)
- Adds 'hw.ofwfb.physaddr' kernel parameter so user can manually
provide correct address if it's not detected correctly
- Adds 'hw.ofwfb.argb32_pixel' so user can set it manually if
colors are inverted due to incorrect pixel format (default = 1)
- Automatically selects RGBA32 pixel format if NVidia graphic adapter
is detected (sets hw.ofwfb.argb32_pixel=0)
Machines equipped with NVidia graphic adapters tend to use RGBA32
pixel format. By default ARGB32 pixel format is used, proved to work
on machines equipped with ATI graphic adapter and the onboard adapter
used on Talos II and Blackbird machines from Raptor Computing Systems.
Original patch developed by bdragon
Reviewed by: bdragon, luporl
MFC after: 3 days
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D28604
This change enables the use of OpenFirmware Console (ofwcons), even when VGA is
available, allowing early kernel messages to be seen, that is important in case
of crashes before VGA console initialization.
This is specially useful in virtualized environments, where the user/developer
doesn't have full control of the virtualization engine (e.g. OpenStack).
The old behavior is preserved by default and, in order to use ofwcons, a few
tunables that have been introduced need to be set:
- hw.ofwfb.disable=1 - disable OFW FrameBuffer device
- machdep.ofw.mtx_spin=1 - change PPC OFW mutex to SPIN type, to match kernel
console's mutex type
- debug.quiesce_ofw=0 - don't call OFW quiesce, needed to keep ofwcons I/O
working
More details can be found at differential revision D20640.
Reviewed by: jhibbits
Differential Revision: https://reviews.freebsd.org/D20640
/chosen/stdout-path is a string, not ihandle. Treat it as such.
With this, ofwfb now starts correctly on a POWER9 system when launched from
the local console (not serial).
The FDT implementation of OF_instance_to_package() backend checks the
cross-reference to get the node. On failure, this returns the input handle
unchanged. In the case of ofwfb attachment, if /chosen/stdout property does not
exist, sc->sc_handle is either garbage or 0, which then gets propagated to node.
This will prevent "screen" from being used, resulting in not properly attaching.
Correct this by matching the code in ofwfb_probe().
overscan and synthesize it from the display depth and screen width.
This may not be right, but it sometimes right and is better than
returning CN_DEAD.
MMU is disabled.
This expands some earlier logic and avoids a number of potential problems:
1. The CPU may not be able to access the framebuffer in real mode (real
mode does not necessarily encompass all available memory, especially
under a hypervisor).
2. Real mode accesses generally assume cacheability, so it might not
even have worked.
3. The difference in cacheability between real mode and later (and
potentially earlier) points in the boot with the MMU on may cause
ERAT parity problems, resulting in a machine check.
This fixes real-mode (usefdt=1) early boot on the G5 iMac, which was
previously broken as a result of issue #3. Late boot will require some
other fixups.
accomplishes a few things:
- Makes NULL an invalid address in the kernel, which is useful for catching
bugs.
- Lays groundwork for radix-tree translation on POWER9, which requires the
direct map be at high memory.
- Similarly lays groundwork for a direct map on 64-bit Book-E.
The new base address is chosen as the base of the fourth radix quadrant
(the minimum kernel address in this translation mode) and because all
supported CPUs ignore at least the first two bits of addresses in real
mode, allowing direct-map addresses to be used in real-mode handlers.
This is required by Linux and is part of the architecture standard
starting in POWER ISA 3, so can be relied upon.
Reviewed by: jhibbits, Breno Leitao
Differential Revision: D14499
Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
will allow for code that uses the old fdt_get_range and fdt_regsize
functions to find a range, map it, access, then unmap to replace this, up
to and including the map, with a call to OF_decode_addr.
As this function should only be used in the early boot code the unmap is
mostly do document we no longer need the mapping as it's a no-op, at least
on arm.
Reviewed by: jhibbits
Sponsored by: ABT Systems Ltd
Differential Revision: https://reviews.freebsd.org/D5258
There were two issues:
1. The area given to vt_is_cursor_in_area() was adding the drawable
area offset, something already handled by this function.
2. The cursor was shifted on the screen by the offset of this area
and thus was misplaced or not erased. Furthermore, when reaching
the bottom or right borders, the cursor was either totally
removed or not erased correctly.
MFC after: 1 week
This allows backends to verify they do not draw outside of this area.
This fixes a bug in vt_vga where the text was happily drawn over the
right and bottom margins, when using the Gallant font.
MFC after: 1 week
Rename vt_generate_vga_palette() to vt_generate_cons_palette() and
change it to build a palette where the color index is the same than in
terminal escape codes, not the VGA index. That's what TCHAR_CREATE()
uses and passes to vt(4).
The main differences between both orders are:
o Blue and red are swapped (1 <-> 4)
o Yellow and cyan are swapped (3 <-> 6)
The problem remained unnoticed, because the RGB bit indexes passed to
vt_generate_vga_palette() were reversed. This inversion was cancelled
by the colors inversions in the generated palette. For instance, red
(0xff0000) and blue (0x0000ff) have bytes in opposite order, but were
swapped in the palette. But after changing the value of blue (see last
paragraph), the modified color was in fact the red one.
This commit includes a fix to creator_vt.c, submitted by Nathan
Whitehorn: fb_cmsize is set to 16. Before this, the generated palette
would be overwritte. This fixes colors on sparc64 with a Creator3D
adapter.
While here, tune the palette to better match console colors and improve
the readability (especially the dark blue).
Submitted by: nwhitehorn (fix to creator_vt.c)
MFC after: 1 week
the right register bank for the framebuffer. Disable the assigned-addresses
path on SPARC since it is just a hack for IBM PPC systems and was neither
relevant for nor worked on SPARC anyway.
framebuffer drivers. This lets ofwfb work with xf86-video-scfb and makes
the driver much more generic and less PCI-centric. This changes some
user-visible behavior and will require updates to the xorg-server port
on PowerPC when using ATI graphics cards.
The last obstacle to switching PowerPC entirely to vt is that the Playstation 3
framebuffer driver needs to be ported over. This only applies for powerpc64,
however.
on my G4 iBook by more than half. Still 10% slower than syscons, but that's
much better than a factor of 2.
The slowness had to do with pathological write performance on 8-bit
framebuffers, which are almost universally used on Open Firmware systems.
Writing 1 byte at a time, potentially nonconsecutively, resulted in many
extra PCI write cycles. This patch, in the common case where it's writing
one or several characters in an 8x8 font, gangs the writes together into
a set of 32-bit writes. This is a port of r143830 to vt(4).
The EFI framebuffer is also extremely slow, probably for the same reason,
and the same patch will likely help there.