svn commit: r331209 - head

[Warner Losh]

On Mon, Mar 19, 2018 at 12:09 PM, Rodney W. Grimes <
freebsd at pdx.rh.cn85.dnsmgr.net> wrote:

> > On Mon, Mar 19, 2018 at 11:51 AM, Andriy Gapon <avg at freebsd.org> wrote:
> >
> > > On 19/03/2018 18:20, John Baldwin wrote:
> > > > On Monday, March 19, 2018 03:27:53 PM Kyle Evans wrote:
> > > >> Author: kevans
> > > >> Date: Mon Mar 19 15:27:53 2018
> > > >> New Revision: 331209
> > > >> URL: https://svnweb.freebsd.org/changeset/base/331209
> > > >>
> > > >> Log:
> > > >>   Add note to UPDATING about UEFI changes requiring loader(8) update
> > > >>
> > > >>   These problems have only been observed with boards using U-Boot
> (e.g.
> > > ARM)
> > > >>   where virtual addresses are already set in the memory map by the
> > > firmware
> > > >>   and the firmware is expecting a call to SetVirtualAddressMap to be
> > > made.
> > > >>   I refrain from mentioning this in the note because this could
> also be
> > > the
> > > >>   case on some not-yet-tested firmware on amd64 and it's not a bad
> > > >>   recommendation for the general case.
> > > >
> > > > How does this fit with the recommended installation steps of doing
> > > > 'make installkernel' and rebooting before doing a 'make
> installworld'?
> > >
> > > Installation of /boot/loader along with likes of cat and cut has always
> > > puzzled
> > > me very much.
> > >
> >
> > Historical reason. We've always installed /boot/loader with installworld.
> > We also install the other boot loaders, but don't deploy them (so
> there's a
> > new /boot/boot, but it isn't installed into /).
>
> More complete historical information.  The "boot" code use to live in
> hidden places in the MBR, and the {disk,bsd}label, so installing it
> into the file system had 0 effect, as the actuall in use running
> code was hidden and had to be replaced using either fdisk or
> {disk,bsd}label.
>

Right. That's still the case, but these bits are considered 'static' and
uninteresting to update.


> When "loader" was added this should of probably changed with
> preseverations of old code and ways to get back to it incase
> things went a foul, and ways to update it in a more controlled
> manner than installworld.  And more approprate timing of
> installing it (should it now go with installkernel?).


No. Where it is fine. The arm64 thing is actually fixed in the kernel so we
don't need to cope with it.

Warner


> > To get around this issue, though, is trivial:
> >
> > make installkenrel
> > cd stand
> > make install
> > reboot
> > make installworld
> >
> > in this weird case.
> >
> > Warner
>
> --
> Rod Grimes
> rgrimes at freebsd.org
>