History log of /openbsd/sys/arch/octeon/dev/octboot.c (Results 1 – 5 of 5)
Revision Date Author Comments
# 45294497 10-Jan-2022 visa <visa@openbsd.org>

Initialize variables that are touched in the error path.

Reminded by LLVM scan-build.


# bc7ce91c 02-Sep-2020 deraadt <deraadt@openbsd.org>

vfs_shutdown() is neccessary to ensure buffer cache drain before reexec()
ok kettenis visa


# 68a1d3c6 13-Jun-2020 visa <visa@openbsd.org>

Remove a dead store.


# cf939257 26-May-2020 visa <visa@openbsd.org>

Rework kernel loading with octboot(4)

Load the kernel image from the filesystem upfront in rdboot and pass
the loaded image to octboot(4)'s kexec call in a memory buffer. As a
result, octboot(4) doe

Rework kernel loading with octboot(4)

Load the kernel image from the filesystem upfront in rdboot and pass
the loaded image to octboot(4)'s kexec call in a memory buffer. As a
result, octboot(4) does not rely on a mounted filesystem.

OK deraadt@

show more ...


# 3a62b615 17-Jul-2019 visa <visa@openbsd.org>

Add a bootloader for octeon.

The firmware on OCTEON machines usually does not provide an interface
for accessing devices, which has made it tricky to implement an OpenBSD
bootloader. To solve this d

Add a bootloader for octeon.

The firmware on OCTEON machines usually does not provide an interface
for accessing devices, which has made it tricky to implement an OpenBSD
bootloader. To solve this device access problem, this new loader has
been built on top of a small kernel. The kernel provides all the
necessary devices drivers, while most of the usual bootloader logic
is in a userspace program in a ramdisk.

The loader program is accompanied by a special device, octboot(4).
The main purpose of this device is to implement a mechanism for
loading and launching kernels. The mechanism has been inspired by Linux'
kexec(2) system call.

The bootloader will be enabled later when it is ready for general use.

Discussed with deraadt@

show more ...