[U-Boot] [PATCH] arm: Add support for semihosting for armv8 fastmodel targets.
Darwin Rambo
drambo at broadcom.com
Wed Mar 12 17:41:20 CET 2014
On 14-03-12 09:24 AM, Tom Rini wrote:
> On Wed, Mar 12, 2014 at 09:04:01AM -0700, Darwin Rambo wrote:
>
>> The reason for this change is to be able to use the ARM Trusted Firmware
>> (ATF) to load the various ATF images, plus u-boot, which can then load
>> the kernel/ramdisk/dtb with calls to an external host from a standard
>> fastmodel armv8 board file using semihosting, and then launch the kernel
>> without a bootwrapper. This gives us a more realistic boot sequence.
>>
>> Rather than create a new armv8 board similar to armltd/vexpress64, add
>> semihosting calls to the existing one, enabled with CONFIG_SEMIHOSTING.
>> Also add a new board config file vexpress_aemv8a_semi.h. This change is
>> tested and works on the ARM foundation model.
>>
>> Support for armv7 in fastmodel is less useful due to the wide range of
>> available silicon but this change contains an untested armv7 placeholder
>> if desired.
>>
>> The level of semihosting support is minimal, restricted to just what it
>> takes to load images to memory. If more semihosting functionality is
>> required, such as file seek, outputting strings, reading characters, etc,
>> then it can be easily added later.
>>
>> Signed-off-by: Darwin Rambo <drambo at broadcom.com>
>
> At the high-level, I'm fine with this. But as an implementation detail
> we need to either leverage vexpress_common.h or create a
> vexpress_arm64_common.h or something. There's a lot in common between
> these two configs, and some further clean-up we need to do to the first
> one anyhow.
Let me try to digest this to see what is truly common and get back to
you. Thanks.
>
> Next:
>> +#ifdef CONFIG_BOARD_LATE_INIT
>> +int board_late_init(void)
>> +{
>> +#ifdef CONFIG_SEMIHOSTING
>> +
>> + /*
>> + * We require that the board include file defines these env variables:
>> + * - kernel_addr
>> + * - initrd_addr
>> + * - fdt_addr
>> + *
>> + * For the "fdt chosen" startup macro, this code will then define:
>> + * - initrd_end (based on initrd_base plus actual initrd_size)
>> + *
>> + * We will then load the kernel, initrd, and fdt into the specified
>> + * locations in memory in a similar way that the ATF fastmodel code
>> + * uses semihosting calls to load other boot stages and u-boot itself.
>> + */
>> +
>> + /* Env variable strings */
>> + char *kernel_addr_str = getenv("kernel_addr");
>> + char *initrd_addr_str = getenv("initrd_addr");
>> + char *fdt_addr_str = getenv("fdt_addr");
>> + char initrd_end_str[64];
>
> First, we need to document this stuff in a README file as well. Second,
> I'd like to see kernel_addr_r / ramdisk_addr_r / fdt_addr_r used to
> match-up with what Dennis Gilmore has been working on to get a common
> env working.
Okay, thanks.
>
> [snip]
>> + /* Assumes kernel is lower in memory than fdt */
>> + smh_load(CONFIG_KNLNAME, kernel_addr, fdt_addr - kernel_addr, 1);
>> +
>> + /* Load fdt to memory */
>> + smh_load(CONFIG_FDTNAME, fdt_addr, 0x20000, 1);
>> +
>> + /* Load initrd to memory */
>> + smh_load(CONFIG_RDNAME, initrd_addr, initrd_size, 1);
>
> Is there a reason we can't also get these from the environment? Or a
> limitation of (how we support) the simulator that we don't have
> persistent r/w environment right now?
These names can also come from the environment, there's r/w capability
there, just no physical eMMC. Thanks.
>
> Thanks!
>
More information about the U-Boot
mailing list