[cc'ing the boot architecture list; this conversation should be in public]
On Wed, May 29, 2013 at 11:19 AM, Leif Lindholm
<leif.lindholm(a)linaro.org> wrote:
> Hi Yi,
>
> On 28 May 2013 15:52, Li Yi <yi.li(a)linaro.org> wrote:
>> just modify linux loader , add SMBIOS address information into fdt. then
>> I will modify the dmidecode to parse the /dev/devicetree to find SMBIOS
>> table pointer. Maybe this way can skip grub and kernel's modification.
>
> Ok, yes, that should work.
>
>> the only problem I care about is the address wrote into fdt ,it is a
>> real physical address, does dmidecode (tool) can read this address ,and do
>> the right thing? it need to be proved.
>
> Yes - UEFI is guaranteed to run with a 1:1 mapping, so the address you see it
> at in the UEFI linux loader is the physical address.
>
>> Grant: if kernel will use the SMBIOS's region memory, can I reserve the
>> 64M memory from the top total ,then kernel will know it's reserved ,will not
>> use the region again ,right?
>
> That should be enough.
Yes, but you shouldn't even need to do that. I just looked at the
LinuxLoader code, in particular the UEFI FDT code, and I've noticed
that the reserved regions should already be set up. Look in
ArmPkg/Library/BdsLib/BdsLinuxFdt.c, about line 420. The function
PrepareFdt() retrieves the UEFI memory map and calls fdt_add_mem_rsv()
for each region.
It does use the function IsLinuxReservedRegion() to filter the
regions, so if SMBIOS uses a different region type then you'll need to
add that type to the list.
So, if I'm correct, it should be sufficient to merely enable SMBIOS
support in UEFI and the kernel will automatically mark the SMBIOS
region as reserved. You can verify this by adding "memblock=debug" to
the kernel command line and looking at the kernel boot output. You'll
see something like this:
memblock_reserve: [0x00000000008400-0x0000000042e98c]
arm_memblock_init+0x4c/0x150
memblock_reserve: [0x00000004000000-0x0000000452f400]
arm_memblock_init+0xcc/0x150
memblock_reserve: [0x00000000004000-0x00000000008000]
arm_memblock_init+0xf0/0x150
memblock_reserve: [0x00000004530000-0x00000004537350]
arm_dt_memblock_reserve+0x30/0xb0
MEMBLOCK configuration:
memory size = 0x8000000 reserved size = 0x960cdc
memory.cnt = 0x1
memory[0x0] [0x00000000000000-0x00000007ffffff], 0x8000000 bytes
reserved.cnt = 0x4
reserved[0x0] [0x00000000004000-0x00000000007fff], 0x4000 bytes
reserved[0x1] [0x00000000008400-0x0000000042e98b], 0x42658c bytes
reserved[0x2] [0x00000004000000-0x0000000452f3ff], 0x52f400 bytes
reserved[0x3] [0x00000004530000-0x0000000453734f], 0x7350 bytes
Memory policy: ECC disabled, Data cache writeback
memblock_reserve: [0x00000007fff000-0x00000008000000]
memblock_alloc_base_nid+0x68/0x84
memblock_reserve: [0x00000007ffe000-0x00000007fff000]
memblock_alloc_base_nid+0x68/0x84
memblock_reserve: [0x00000007ffdf10-0x00000007ffe000]
memblock_alloc_base_nid+0x68/0x84
memblock_reserve: [0x00000007ffc000-0x00000007ffd000]
memblock_alloc_base_nid+0x68/0x84
memblock_reserve: [0x00000007ffb000-0x00000007ffc000]
memblock_alloc_base_nid+0x68/0x84
memblock_reserve: [0x00000007ffa000-0x00000007ffb000]
memblock_alloc_base_nid+0x68/0x84
Note: this only works with the UEFI LinuxLoader. The GRUB code doesn't
currently add the UEFI reserved regions to the FDT reserved map.
g.
Hi Roy,
Here are some very quick notes on what I found on writing UEFI applications.
I found a library called "gnuefi" which allows building EFI
applications apart from the Tianocore build tree. It looks
interesting, but has not been ported to ARM. I don't yet know if it is
worthwhile pursuing.
http://gnu-efi.sourceforge.net/
As mentioned, the Linux kernel has an EFI stub already. I could tell
you which files to look at, but really just doing a "git grep
EFI_STUB" in the kernel tree will show you all the files that you need
to care about. :-)
You'll need to figure out how to get a UEFI PE-COFF header into the
LInux kernel zImage wrapper. It shouldn't be too hard. You'll need to
look at the startup code in arch/arm/boot/compressed/head.S. The
PE-COFF header will need to go somewhere after the start: label. You
should be able to see the existing LInux kernel "header" (not much of
a header, more of a magic number) about 10 lines down from the start
label.
That's all I can write at the moment. We can talk more tomorrow.
g.
