Hi Mark,
On Wed, 6 Dec 2023 at 13:00, Mark Kettenis <mark.kette...@xs4all.nl> wrote:
>
> > From: Ilias Apalodimas <ilias.apalodi...@linaro.org>
> > Date: Wed, 6 Dec 2023 12:31:15 +0200
> >
> > Hi Caleb,
> >
> > Late to the party, but I'll respond to as much as I can
> >
> > On Tue, 21 Nov 2023 at 19:09, Caleb Connolly <caleb.conno...@linaro.org>
> > wrote:
> > >
> > > Historically, Qualcomm boards in U-Boot have all had their own
> > > board/qualcomm/xyz directory, their own CONFIG_TARGET_XYZ option, their
> > > own hardcoded sysmap-xyz.c file, and their own U-Boot specific
> > > devicetree with little/no compatibility with upstream DT.
> > >
> > > This series makes a few final prepatory changes, and then replaces
> > > almost all of the board specific code with generic alternatives. The end
> > > result is that all Qualcomm boards both current and future (with the
> > > exception of the db410c and db820c) can be supported by a single U-Boot
> > > binary by just providing the correct DT. New boards can be added without
> > > introducing any addition mach/ or board/ code or config options.
> > >
> > > Due to the nature of this change, the patch ("mach-snapdragon:
> > > generalise board support") has become pretty big, I tried a few
> > > different ways to represent this in git history, but the other methods
> > > (e.g. adding a stub "generic" target and removing it again) were more
> > > confusing and made for much messier git history. The current patch is
> > > mostly atomic, but requires regenerating the config.
> > >
> > > The QCS404 EVB board had some code to enable the USB VBUS regulator,
> > > this is dropped in favour of a adding a new vbus-supply property to the
> > > dwc3-generic driver. This will also be used by the dragonboard845c in a
> > > future patch. This handles the common case of a board requiring some
> > > regulator be enabled for USB host mode.
> > >
> > > A more detailed description of the changes is below.
> > >
> > > == Memory map ==
> > >
> > > The memory map was historically hardcoded into U-Boot, this meant that
> > > U-Boot had to be built for a specific variant of a device. This is
> > > changed to instead read the memory map from the DT /memory node.
> > >
> > > Additionally, most boards mapped addresss 0x0 as valid, as a result if a
> > > null pointer access happens then it will cause a bus stall (and board
> > > hang). This is fixed so that null pointer accesses will now correctly
> > > throw an exception.
> > >
> > > == DT loading ==
> > >
> > > Previously, boards used the FDT blob embedded into U-Boot (via
> > > OF_SEPARATE). However, most Qualcomm boards run U-Boot as a secondary
> > > bootloader, so we can instead rely on the first-stage bootloader to
> > > populate some useful FDT properties for us (notably the /memory node and
> > > KASLR seed)
> >
> > Note that the kaslr-seed is not so useful when booting with EFI. The
> > kernel's EFI-stub ignores that and instead tries to randomize the
> > physical placement of the kernel if it finds an EFI_RNG protocol.
>
> OpenBSD will use it though. And other OSes might as well.
Yea, I remember that, but efi_try_purge_kaslr_seed() purges it anyway
if there's an EFI_RNG protocol installed.
U-Boot also has other ways of injecting it. Perhaps we could keep it
and combine rng-seeds in the future I guess.
Thanks
/Ilias
>
> > > and fetch the DTB that it provides. Combined with the memory
> > > map changes above, this let's us entirely avoid configuring the memory
> > > map explicitly.
