[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFECyb83kmpj20nX3fw5HXw_hFyzj45aFga6nhG04qdKc-6jJw@mail.gmail.com>
Date: Tue, 14 Jan 2014 11:35:25 -0800
From: Roy Franz <roy.franz@...aro.org>
To: Rob Herring <robherring2@...il.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Matt Fleming <matt.fleming@...el.com>,
Russell King - ARM Linux <linux@....linux.org.uk>,
Linaro Patches <patches@...aro.org>,
Leif Lindholm <leif.lindholm@...aro.org>,
Mark Salter <msalter@...hat.com>,
Grant Likely <grant.likely@...aro.org>,
Dave P Martin <dave.martin@....com>
Subject: Re: [PATCH V6 6/8] Add EFI stub for ARM
On Tue, Jan 14, 2014 at 11:29 AM, Rob Herring <robherring2@...il.com> wrote:
> On Fri, Jan 10, 2014 at 10:30 AM, Roy Franz <roy.franz@...aro.org> wrote:
>> This patch adds EFI stub support for the ARM Linux kernel. The EFI stub
>> operates similarly to the x86 stub: it is a shim between the EFI firmware
>> and the normal zImage entry point, and sets up the environment that the
>> zImage is expecting. This includes loading the initrd (optionaly) and
>> device tree from the system partition based on the kernel command line.
>> The stub updates the device tree as necessary, adding entries for EFI
>> runtime services. The PE/COFF "MZ" header at offset 0 results in the
>> first instruction being an add that corrupts r5, which is not used by
>> the zImage interface.
>>
>> Signed-off-by: Roy Franz <roy.franz@...aro.org>
>> Acked-by: Grant Likely <grant.likely@...aro.org>
>> ---
>
> [snip]
>
>> + /* Look up the base of DRAM from the device tree. */
>> + fdt = (void *)fdt_addr;
>> + node = fdt_subnode_offset(fdt, 0, "memory");
>> + region = fdt_getprop(fdt, node, "reg", NULL);
>> + if (region) {
>> + dram_base = fdt64_to_cpu(region->base);
>
> This will not work if the address is 32-bit size.
>
>> + } else {
>> + /* There is no way to get amount or addresses of physical
>> + * memory installed using EFI calls. If the device tree
>> + * we read from disk doesn't have this, there is no way
>> + * for us to construct this informaion.
>> + */
>> + pr_efi_err(sys_table, "No 'memory' node in device tree.\n");
>> + goto fail_free_fdt;
>
> The current pc can't be used to determine the DRAM base like AUTO_ZRELADDR?
>
> Rob
Hi Rob,
UEFI may load the stub based kernel anywhere, so we don't get any
useful information from where we were loaded.
I am currently working on getting the base address from the EFI memory
map, so all of the above code will go away, the only FDT
operations that the stub will perform is to add the EFI related fields.
Roy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists