[U-Boot] [PATCH 3/9] efi_loader: Add PE image loader

[Leif Lindholm]

On Fri, Jan 15, 2016 at 12:45:46AM +0100, Alexander Graf wrote:
> On 26.12.15 17:26, Leif Lindholm wrote:
> >> new file mode 100644
> >> index 0000000..688e177
> >> --- /dev/null
> >> +++ b/lib/efi_loader/efi_image_loader.c
> >> @@ -0,0 +1,203 @@
> >> +/*
> >> + *  EFI image loader
> >> + *
> >> + *  based partly on wine code
> >> + *
> >> + *  Copyright (c) 2015 Alexander Graf
> >> + *
> >> + *  This library is free software; you can redistribute it and/or
> >> + *  modify it under the terms of the GNU Lesser General Public
> >> + *  License as published by the Free Software Foundation; either
> >> + *  version 2.1 of the License, or (at your option) any later version.
> >> + *
> >> + *  This library is distributed in the hope that it will be useful,
> >> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> >> + *  Lesser General Public License for more details.
> >> + *
> >> + *  You should have received a copy of the GNU Lesser General Public
> >> + *  License along with this library; if not, write to the Free Software
> >> + *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
> >> + *
> >> + *  SPDX-License-Identifier:     LGPL-2.1+
> >> + */
> >> +
> >> +#include <common.h>
> >> +#include <pe.h>
> >> +#include <efi_loader.h>
> >> +#include <asm/global_data.h>
> >> +
> >> +DECLARE_GLOBAL_DATA_PTR;
> >> +
> >> +#define ROUND_UP(val, round) ((val + (round - 1)) & ~(round - 1))
> >> +#define MB (1024 * 1024)
> >> +
> >> +const efi_guid_t efi_guid_device_path = DEVICE_PATH_GUID;
> >> +const efi_guid_t efi_guid_loaded_image = LOADED_IMAGE_GUID;
> >> +
> >> +efi_status_t efi_return_handle(void *handle, efi_guid_t *protocol,
> >> +			void **protocol_interface, void *agent_handle,
> >> +			void *controller_handle, uint32_t attributes)
> >> +{
> >> +	*protocol_interface = handle;
> >> +	return EFI_SUCCESS;
> >> +}
> >> +
> >> +/*
> >> + * EFI payloads potentially want to load pretty big images into memory,
> >> + * so our small malloc region isn't enough for them. However, they usually
> >> + * don't need a smart allocator either.
> >> + *
> >> + * So instead give them a really dumb one. We just reserve EFI_LOADER_POOL_SIZE
> >> + * bytes from 16MB below the malloc region start to give the stack some space.
> > 
> > Is there any chance you could break out the memory allocation and
> > memory map management as a separate patch, rather than spread across
> > 3,4 and 6?
> 
> Uh, sure, I can try. I'm not sure it'll end up more readable than now
> though :).

Heh, ok. It was a theory.

> > Assigning a specific 128MB pool for LOADER_DATA memory can have
> > unexpected side effects.
> 
> Like for example?

Like applications running out of memory when there's plenty left in
the system. OK, so not "unexpected" unexpected, but "may cause valid
programs to break". My initial comment was because I was scratching my
head over how GRUB managed to allocate its heap at all.

/
    Leif