efi/metadata: Make a note that efi_map_header isn't standard

efi_map_header is similar to, but not at all the same as the UEFI
EFI_MEMORY_ATTRIBUTES_TABLE (we could easily have used the latter
thoug

efi/metadata: Make a note that efi_map_header isn't standard

efi_map_header is similar to, but not at all the same as the UEFI
EFI_MEMORY_ATTRIBUTES_TABLE (we could easily have used the latter
though, with one fewer non-standard types, but we can't change
it easily now due to the last 10 years of boot loaders passing
this in).

Sponsored by: Netflix

show more ...

riscv/stand: pass boot hart in loader metadata

Use the RISCV_EFI_BOOT_PROTOCOL to fetch the boot hart ID, and
communicate this to the kernel via new metadata field
(MODINFOMD_BOOT_HART).

If the boo

riscv/stand: pass boot hart in loader metadata

Use the RISCV_EFI_BOOT_PROTOCOL to fetch the boot hart ID, and
communicate this to the kernel via new metadata field
(MODINFOMD_BOOT_HART).

If the boot hart is not found this way, fall back to the (now
deprecated) device-tree method.

The assumption that a hart ID can be represented with a 32-bit unsigned
integer is unchanged in the kernel, but from the loader we pass the full
64-bit value. This ensures that this API won't need to change in the
future, should the wider value become necessary.

Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48887

show more ...

riscv: enable EFI framebuffer

Pass framebuffer information from loader(8) to the kernel via the
MODINFOMD_EFI_FB metadata field.

Enable the vt_efifb driver. A small tweak is required to work around

riscv: enable EFI framebuffer

Pass framebuffer information from loader(8) to the kernel via the
MODINFOMD_EFI_FB metadata field.

Enable the vt_efifb driver. A small tweak is required to work around the
lack of VM_MEMATTR_WRITE_COMBINING on this platform; we use
VM_MEMATTR_UNCACHEABLE instead.

Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D48884

show more ...

sys: Remove $FreeBSD$: two-line .h pattern

Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.

Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix

show more ...

RISC-V boot1.efi and loader.efi support

This implementation doesn't have any major deviations from the other EFI
ports. I've copied the boilerplate from arm and arm64.

I've tested this with the fol

RISC-V boot1.efi and loader.efi support

This implementation doesn't have any major deviations from the other EFI
ports. I've copied the boilerplate from arm and arm64.

I've tested this with the following boot flows:
OpenSBI (M-mode) -> u-boot (S-mode) -> loader.efi -> FreeBSD
OpenSBI (M-mode) -> u-boot (S-mode) -> boot1.efi -> loader.efi -> FreeBSD

Due to the way that u-boot handles secondary CPUs, OpenSBI >= v0.7 is required,
as the HSM extension is needed to bring them up explicitly. Because of this,
using BBL as the SBI implementation will not be possible. Additionally, there
are a few recent u-boot changes that are required as well, all of which will be
present in the upcoming v2020.07 release.

Looks good: emaste
Differential Revision: https://reviews.freebsd.org/D25135

show more ...

RISC-V: copy the DTB to early KVA

The location of the device-tree blob is passed to the kernel by the
previous booting stage (i.e. BBL or OpenSBI). Currently, we leave it
untouched and mark the 1MB

RISC-V: copy the DTB to early KVA

The location of the device-tree blob is passed to the kernel by the
previous booting stage (i.e. BBL or OpenSBI). Currently, we leave it
untouched and mark the 1MB of memory holding it as unavailable.

Instead, do what is done by other fake_preload_metadata() routines and
copy to the DTB to KVA space. This is more in line with what loader(8)
will provide us in the future, and it allows us to reclaim the hole in
physical memory.

Reviewed by: markj, kp (earlier version)
Differential Revision: https://reviews.freebsd.org/D24152

show more ...

efi/metadata: Make a note that efi_map_header isn't standard

efi_map_header is similar to, but not at all the same as the UEFI
EFI_MEMORY_ATTRIBUTES_TABLE (we could easily have used the latter
thoug

efi/metadata: Make a note that efi_map_header isn't standard

efi_map_header is similar to, but not at all the same as the UEFI
EFI_MEMORY_ATTRIBUTES_TABLE (we could easily have used the latter
though, with one fewer non-standard types, but we can't change
it easily now due to the last 10 years of boot loaders passing
this in).

Sponsored by: Netflix

show more ...

riscv/stand: pass boot hart in loader metadata

Use the RISCV_EFI_BOOT_PROTOCOL to fetch the boot hart ID, and
communicate this to the kernel via new metadata field
(MODINFOMD_BOOT_HART).

If the boo

riscv/stand: pass boot hart in loader metadata

Use the RISCV_EFI_BOOT_PROTOCOL to fetch the boot hart ID, and
communicate this to the kernel via new metadata field
(MODINFOMD_BOOT_HART).

If the boot hart is not found this way, fall back to the (now
deprecated) device-tree method.

The assumption that a hart ID can be represented with a 32-bit unsigned
integer is unchanged in the kernel, but from the loader we pass the full
64-bit value. This ensures that this API won't need to change in the
future, should the wider value become necessary.

Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48887

show more ...

riscv: enable EFI framebuffer

Pass framebuffer information from loader(8) to the kernel via the
MODINFOMD_EFI_FB metadata field.

Enable the vt_efifb driver. A small tweak is required to work around

riscv: enable EFI framebuffer

Pass framebuffer information from loader(8) to the kernel via the
MODINFOMD_EFI_FB metadata field.

Enable the vt_efifb driver. A small tweak is required to work around the
lack of VM_MEMATTR_WRITE_COMBINING on this platform; we use
VM_MEMATTR_UNCACHEABLE instead.

Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D48884

show more ...

sys: Remove $FreeBSD$: two-line .h pattern

Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.

Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix

show more ...

RISC-V boot1.efi and loader.efi support

This implementation doesn't have any major deviations from the other EFI
ports. I've copied the boilerplate from arm and arm64.

I've tested this with the fol

RISC-V boot1.efi and loader.efi support

This implementation doesn't have any major deviations from the other EFI
ports. I've copied the boilerplate from arm and arm64.

I've tested this with the following boot flows:
OpenSBI (M-mode) -> u-boot (S-mode) -> loader.efi -> FreeBSD
OpenSBI (M-mode) -> u-boot (S-mode) -> boot1.efi -> loader.efi -> FreeBSD

Due to the way that u-boot handles secondary CPUs, OpenSBI >= v0.7 is required,
as the HSM extension is needed to bring them up explicitly. Because of this,
using BBL as the SBI implementation will not be possible. Additionally, there
are a few recent u-boot changes that are required as well, all of which will be
present in the upcoming v2020.07 release.

Looks good: emaste
Differential Revision: https://reviews.freebsd.org/D25135

show more ...

RISC-V: copy the DTB to early KVA

The location of the device-tree blob is passed to the kernel by the
previous booting stage (i.e. BBL or OpenSBI). Currently, we leave it
untouched and mark the 1MB

RISC-V: copy the DTB to early KVA

The location of the device-tree blob is passed to the kernel by the
previous booting stage (i.e. BBL or OpenSBI). Currently, we leave it
untouched and mark the 1MB of memory holding it as unavailable.

Instead, do what is done by other fake_preload_metadata() routines and
copy to the DTB to KVA space. This is more in line with what loader(8)
will provide us in the future, and it allows us to reclaim the hole in
physical memory.

Reviewed by: markj, kp (earlier version)
Differential Revision: https://reviews.freebsd.org/D24152

show more ...

efi/metadata: Make a note that efi_map_header isn't standard

efi_map_header is similar to, but not at all the same as the UEFI
EFI_MEMORY_ATTRIBUTES_TABLE (we could easily have used the latter
thoug

efi/metadata: Make a note that efi_map_header isn't standard

efi_map_header is similar to, but not at all the same as the UEFI
EFI_MEMORY_ATTRIBUTES_TABLE (we could easily have used the latter
though, with one fewer non-standard types, but we can't change
it easily now due to the last 10 years of boot loaders passing
this in).

Sponsored by: Netflix

show more ...

riscv/stand: pass boot hart in loader metadata

Use the RISCV_EFI_BOOT_PROTOCOL to fetch the boot hart ID, and
communicate this to the kernel via new metadata field
(MODINFOMD_BOOT_HART).

If the boo

riscv/stand: pass boot hart in loader metadata

Use the RISCV_EFI_BOOT_PROTOCOL to fetch the boot hart ID, and
communicate this to the kernel via new metadata field
(MODINFOMD_BOOT_HART).

If the boot hart is not found this way, fall back to the (now
deprecated) device-tree method.

The assumption that a hart ID can be represented with a 32-bit unsigned
integer is unchanged in the kernel, but from the loader we pass the full
64-bit value. This ensures that this API won't need to change in the
future, should the wider value become necessary.

Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48887

show more ...

riscv: enable EFI framebuffer

Pass framebuffer information from loader(8) to the kernel via the
MODINFOMD_EFI_FB metadata field.

Enable the vt_efifb driver. A small tweak is required to work around

riscv: enable EFI framebuffer

Pass framebuffer information from loader(8) to the kernel via the
MODINFOMD_EFI_FB metadata field.

Enable the vt_efifb driver. A small tweak is required to work around the
lack of VM_MEMATTR_WRITE_COMBINING on this platform; we use
VM_MEMATTR_UNCACHEABLE instead.

Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D48884

show more ...

sys: Remove $FreeBSD$: two-line .h pattern

Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.

Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix

show more ...

RISC-V boot1.efi and loader.efi support

This implementation doesn't have any major deviations from the other EFI
ports. I've copied the boilerplate from arm and arm64.

I've tested this with the fol

RISC-V boot1.efi and loader.efi support

This implementation doesn't have any major deviations from the other EFI
ports. I've copied the boilerplate from arm and arm64.

I've tested this with the following boot flows:
OpenSBI (M-mode) -> u-boot (S-mode) -> loader.efi -> FreeBSD
OpenSBI (M-mode) -> u-boot (S-mode) -> boot1.efi -> loader.efi -> FreeBSD

Due to the way that u-boot handles secondary CPUs, OpenSBI >= v0.7 is required,
as the HSM extension is needed to bring them up explicitly. Because of this,
using BBL as the SBI implementation will not be possible. Additionally, there
are a few recent u-boot changes that are required as well, all of which will be
present in the upcoming v2020.07 release.

Looks good: emaste
Differential Revision: https://reviews.freebsd.org/D25135

show more ...

RISC-V: copy the DTB to early KVA

The location of the device-tree blob is passed to the kernel by the
previous booting stage (i.e. BBL or OpenSBI). Currently, we leave it
untouched and mark the 1MB

RISC-V: copy the DTB to early KVA

The location of the device-tree blob is passed to the kernel by the
previous booting stage (i.e. BBL or OpenSBI). Currently, we leave it
untouched and mark the 1MB of memory holding it as unavailable.

Instead, do what is done by other fake_preload_metadata() routines and
copy to the DTB to KVA space. This is more in line with what loader(8)
will provide us in the future, and it allows us to reclaim the hole in
physical memory.

Reviewed by: markj, kp (earlier version)
Differential Revision: https://reviews.freebsd.org/D24152

show more ...