summaryrefslogtreecommitdiff
path: root/sys/arch/loongson/stand
AgeCommit message (Collapse)Author
2010-04-03Minor reliability fixes:Miod Vallat
- clear initrd signature before returning to PMON or to the loaded kernel - fail /etc/boot.conf access when loading from an initrd image, instead of letting it point to the beginning of the kernel image and have the code complain of lines being too long. Bump minor version.
2010-02-19do NOT install the loongson mbr on other architectures!Theo de Raadt
2010-02-17If PMON has loaded an initrd binary, and this binary looks like a validMiod Vallat
ELF image, assume it's the kernel and try to boot it immediately. This allows a Gdium system with both the bootloader and the kernel image on an ext2fs partition, with `al' pointing to the bootblocks and `rd' pointing to the kernel in PMON environment, to boot a kernel with proper kernel symbols, for the first time. (please don't get me started on how reliable `load -k' is on the Gdium) Bump bootblocks version to 0.2.
2010-02-17descend into mbr; ok miod@Otto Moerbeek
2010-02-17proto mbr for loongsonOtto Moerbeek
2010-02-17Split boot/Makefile in case we need to build several boot.${VENDOR} compiledMiod Vallat
from the same sources with different CFLAGS; the need for this has not arisen yet but I fear it will hit the fan soon enough; no functional change in the meantime.
2010-02-16Actually, both the Gdium and the Lemote PMON reset the USB controllersMiod Vallat
before transferring control to any binary, so trying to boot anything on the Gdium without bringing half the kernel code is a no-go. So, only keep `wd' as a possible boot device, for the Lemote systems, and complain loudly if run on a Gdium.
2010-02-14Work in progress standalone boot blocks for OpenBSD/loongson systems. WillMiod Vallat
load a kernel from the OpenBSD partition, with symbols. However: - does not work on gdium (usb i/o errors) - no countdown due to PMON limitations, so either `bsd' in the PMON environment contains a kernel filename to load, and it will get loaded immediately, or it doesn't (e.g. the variable does no exist) and you get a prompt and can pass options to the kernel. Note that /etc/boot.conf commands can still be used in both cases. - does not work for me when loaded automatically from PMON (put in the `al' environment variable). However, `boot $al' works fine. Need to investigate.