On Thu, 2020-02-27 at 08:38 +0100, Ard Biesheuvel wrote: > On Thu, 27 Feb 2020 at 00:35, Atish Patra <Atish.Patra@xxxxxxx> > wrote: > > On Mon, 2020-02-17 at 09:37 +0100, Ard Biesheuvel wrote: > > > On Mon, 17 Feb 2020 at 02:17, Atish Patra <Atish.Patra@xxxxxxx> > > > wrote: > > > > On Mon, 2020-02-10 at 17:02 +0100, Ard Biesheuvel wrote: > > > > > get_dram_base() is only called from arm-stub.c so move it > > > > > into > > > > > the same source file as its caller. > > > > > > > > > > > > > Just FYI: riscv efi stub port is also going to use > > > > get_dram_base(). > > > > However, I have renamed arm-stub.c to generic efi-stub.c so > > > > that > > > > arm, > > > > arm64 and riscv can reuse it. Thus, Moving get_dram_base() into > > > > arm- > > > > stub.c works for riscv as well. I will rebase my patches on top > > > > of > > > > this > > > > series. > > > > > > > > > > Thanks Atish. I was hoping it would turn out like this, which is > > > why > > > I > > > am pushing this series now. > > > > > > I haven't looked at your code yet, but please avoid using the > > > command > > > line based initrd/dtb loading routines. I am proposing a cleaner > > > way > > > to provide the initrd from firmware [0], and dtb loading by the > > > stub > > > should not be done in the first place. > > > > > > [0] > > > https://lore.kernel.org/linux-efi/20200216141104.21477-1-ardb@xxxxxxxxxx/ > > > > Sorry I missed this email earlier. Yes I am not using initrd or dtb > > loading from U-Boot command line. > > > > If you use arm-stub.c mostly unmodified, you will be using initrd= > command line loading, Do you mean the code path enters to "initrd=" loading part ? I think that code path has a minor issue where it prints even if the there was no "initrd=" supplied in the command line. "Loaded initrd from command line option\n" This happens because efi_load_initrd returns EFI_SUCCESS in absense of command string as well. https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git/tree/drivers/firmware/efi/libstub/arm-stub.c?h=next#n281 > and it would be better to disable that, and only > enable it if there is a request for it (which I doubt will happen). -- Regards, Atish
