From: Darwin Rambo <drambo@broadcom.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] arm: Add support for semihosting for armv8 fastmodel targets.
Date: Wed, 12 Mar 2014 09:41:20 -0700 [thread overview]
Message-ID: <53208E30.1010304@broadcom.com> (raw)
In-Reply-To: <20140312162431.GT16805@bill-the-cat>
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@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!
>
next prev parent reply other threads:[~2014-03-12 16:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-12 16:04 [U-Boot] [PATCH] arm: Add support for semihosting for armv8 fastmodel targets Darwin Rambo
2014-03-12 16:24 ` Tom Rini
2014-03-12 16:41 ` Darwin Rambo [this message]
2014-03-12 17:18 ` Tom Rini
2014-03-12 17:47 ` Darwin Rambo
2014-03-12 16:41 ` Albert ARIBAUD
2014-03-12 16:45 ` Darwin Rambo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53208E30.1010304@broadcom.com \
--to=drambo@broadcom.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.