On May 29, 10:34am, Martin Husemann wrote:
} On Tue, May 29, 2018 at 08:15:43AM +0000, Thomas Mueller wrote:
} 
} > Where do I find documentation on how to boot NetBSD amd64 or
} > possibly i386 in UEFI mode?
} 
} I'm working on a wiki page (and will change the NetBSD 8.0 install docs
} to point to that).
} 
} I can't answer how to boot into alternative operating systems (haven't tried
} that yet). But the basic installation goes like this:

     UEFI has a boot manager.  You configure it by manipulating
EFI variables (I don't know if NetBSD has a way of doing this).
Alternatively, you can install a 3rd party boot manager, such as
rEFInd.

}  - You want to boot from the uefi usb install image. This requires "secure
}    boot" to be disabled. Some firmwares require you to set a firmware
}    password before allowing to disable that
} 
} Assuming you have a scratch disk (called wd0) you want to fully
} use for NetBSD you do something like:
} 
}  gpt destroy wd0
}  gpt create wd0
}  gpt add -a 2m -l "EFI system" -t efi -s 128m wd0

     Obviously, if you want to install on a disk that already has other
OSes, you would skip these three steps.

}  gpt add -a 2m -l NetBSD -t ffs -s 118g wd0           # replace 118g as needed
}  gpt add -a 2m -l swap -t swap wd0    # this will use all remaining space

     Having a "small" NetBSD partition and using the remainder for
swap is probably not what you want.

}  dkctl wd0 listwedges
} 
} Now note which dk* is the EFI one and newfs it (also note the ffs one
} for later, see below):
} 
}  newfs_msdos /dev/rdk3        # replace dk3 with proper device

     Don't do this if the disk already has other OSes.

} Then make it bootable:
} 
}  mount -t msdos /dev/dk3 /mnt
}  mkdir -p /mnt/EFI/boot
}  cp /usr/mdec/*.efi /mnt/EFI/boot
}  umount /mnt

    This part is always needed.

} I have sysinst changes that will allow the remaining part to be handled
} by sysinst in NetBSD 8.0 (hope to finsih that soon).
} 
} But for now you will have to install manually. Check the dkctl output
} for which dk* is the ffs one and newfs/mount it:
} 
}  newfs -O 2 dk4               # replace dk4 by approrpiate device, see above
}  mount -o async /dev/dk4 /mnt
}  cd /mnt
} 
} Now extract (with tar xpzf) all sets you want, including the appropriate
} kernel. Also:
} 
}  cp /usr/mdec/boot .  # copy secondary bootloader (XXX is this needed for 
uefi)?

     No, it isn't needed for UEFI boot.

}  cd dev
}  sh MAKEDEV all
}  vi /etc/fstab
} 
} A fstab could look like:
} 
} NAME=NetBSD   /       ffs     rw      1 1
} NAME=swap     none    swap    sw,dp   0 0
} kernfs                /kern   kernfs  rw
} ptyfs         /dev/pts ptyfs  rw
} procfs                /proc   procfs  rw
} tmpfs /var/shm              tmpfs   rw,-m1777,-sram%25
} 
} Finally set rc_configured=YES in /mnt/etc/rc.conf, plus add hostname=
} and whatever settings you need.
} 
} Now reboot, remove install usb medium, and watch NetBSD boot from uefi.

     A brief explanation of the different booting methods would
probably help clear up the boot2 question.

     With BIOS booting, the BIOS simply loads the first sector on
the hard drive into memory and jumps to it.  Keep in mind that this
sector also contains the MBR partition table, so there is only 369
bytes available for the code.  This is the code that gets installed
when you do 'fdisk -i' and comes from /usr/mdec/mbr*.  This code
contains just enough smarts to find the first active MBR partition,
read the first sector from it, and jump to it.  That is the first
sector of /usr/mdec/bootxx_*, which is installed by installboot(8).
That code reads the next N sectors, where N varies by OS and file
system type, into memory and jumps to it.  This code finally has
enough smarts to understand a file system.  It searches the file
system for an OS dependent file (in the case of NetBSD, "boot"
which is commonly known as boot2), loads it and jumps to it.  boot2
is responsible for presenting the boot menu, loading the kernel
(and other stuff), setting up some information for the kernel,
switching the system into 32-bit mode, and starting the kernel.
If the kernel is an amd64 kernel, then one of the first things it
does is switch the system into 64-bit mode (formally known as "long
mode").

     UEFI is very different.  UEFI is essentially a mini-OS.  It
brings the processor into its native mode early on.  It provides
OS like services:  memory management, file system access, device
abstraction, etc..  A UEFI boot loader is really just an UEFI
application.  UEFI applications can do other things besides boot
an operating system.  efiboot is an UEFI application that does the
equivalent of boot2 replacing /boot (UEFI itself has done all the
earlier steps).  Note that our efiboot has a hack where it drops
a 64-bit system back down to 32-bit mode in order to be able to
load an unmodified kernel.  I think it would be better if our kernel
was modified with a UEFI entrypoint added, similar to the multiboot
entry point, which understood that it was running under UEFI and
would react accordingly.

}-- End of excerpt from Martin Husemann

Reply via email to