NetBSD/sys/arch/next68k/stand/boot
cl fcc21e91ba move structs nextstep_disklabel/cpu_partition and appendant #defines
to sys/sys/bootblock.h
- rename to next68k_disklabel and next68k_partition
- use {u,}int{8,16,32}_t instead of char/short/int (suggested by D. Laight)
2003-10-27 16:48:08 +00:00
..
boot.c Fix NULL change lossage. 2003-10-23 18:56:49 +00:00
conf.c Move UCB-licensed code from 4-clause to 3-clause licence. 2003-08-07 16:26:28 +00:00
devopen.c
dmareg.h Comprehensive patches from Christian Limpach: 2002-09-11 01:46:29 +00:00
en.c DMA, not dma nor Dma. 2003-05-03 18:10:37 +00:00
enreg.h Determine turbo-ness based on the ROM machine type here, too. 2002-09-11 02:17:14 +00:00
installboot.sh Apply patches from Christian Limpach: 2002-07-11 16:03:09 +00:00
machdep.c Apply patches from Christian Limpach: 2002-07-11 16:03:09 +00:00
Makefile Use ${HOST_SH} instead of `sh'. 2003-10-26 07:25:33 +00:00
newvers.sh
README
rtc.c
scsi.c DMA, not dma nor Dma. 2003-05-03 18:10:37 +00:00
scsireg.h
scsivar.h
sd.c move structs nextstep_disklabel/cpu_partition and appendant #defines 2003-10-27 16:48:08 +00:00
srt0.s
version

$NetBSD: README,v 1.1.1.1 1998/06/09 07:53:06 dbj Exp $

NeXT standalone bootblocks.
Rolf Grossmann, Dec 1994

Started work based on files from hp300/stand. boot.c was from post-1.0 
sparc/stand/boot.c, modified to work for the needs of the NeXT PROM,
i.e. it wants to call the kernel, so the bootblock has to return the
entry point.

The code does not try multiple names for te kernel, as I've seen it in
some other architectures' boot code. (The copied code simply didn't do
that ;)) It also doesn't prompt if the argument to boot ends with a
questionmark '?', like the NeXT bootblock does. Do we need this? (Why
should the bootblock as again when you can specify everything on the
boot command line?)

Most files have nothing to do with their original version anymore. The whole
code is a mixture of my own ideas, various other netbsd code I've looked at
(like the sparc scsi code, the independent scsi code, and the needs of the
standalone library).

In contrast to NeXT's bootblocks, mine keep the PROM's idea of what the
boot parameters are, i.e. logical disk number (the number the disk would
get as sd*), the lun and the partition.

TODO
 Make some additional improvements