> -Original Message-
> From: Udit Kumar [mailto:udit.ku...@nxp.com]
> Sent: Wednesday, May 02, 2018 12:31 PM
> To: Chang, Abner (HPS SW/FW Technologist) ; Ard
> Biesheuvel
> Cc: Architecture Mailman List ; arm.ebbr-
> disc...@arm.com
> Subject: RE: [Arm.ebbr-discuss] ebbr: boot behaviour
> -Original Message-
> From: Udit Kumar [mailto:udit.ku...@nxp.com]
> Sent: Wednesday, May 02, 2018 12:26 PM
> To: Chang, Abner (HPS SW/FW Technologist) ;
> Alexander Graf ; William Mills
> Cc: boot-architecture@lists.linaro.org; n...@arm.com; Rod Dorris
> ; arm.ebbr-disc...@arm.com
> Su
> > Also, eMMC controllers (which are more widely used on mobile platforms
> > as the only available storage controller) use DMA under the OS, which
> > complicates things even further when attempting to share such a
> > controller between the OS and the firmware.
> Agree with this. May need other
> We probably don't need to provide a genetic DT driver in UEFI U-Boot, instead,
> we will have to mention how SoC/platform vendors publish DTB/DTBO in EBBR
> spec.
> For example,
> The EFI_CONFIGURATION_TABLE in EFI System table could be used to publish
> the pointer to DTB and DTBO. Declare two G
Deferred probe will currently wait forever on dependent devices to probe,
but sometimes a driver will never exist. It's also not always critical for
a driver to exist. Platforms can rely on default configuration from the
bootloader or reset defaults for things such as pinctrl and power domains.
Thi
