[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