[PATCH 00/21] Qualcomm generic board support

[Mark Kettenis]

> From: Ilias Apalodimas <ilias.apalodimas at 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.connolly at 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.

> >  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.