[U-Boot] [PATCH 06/11] imx: imx-common: introduce boot auxiliary core

[Stefan Agner]

Hi,

I would like to keep the discussion going and shed some light on the
image format introduced here, see below...

On 2016-01-07 00:38, Peng Fan wrote:
> Hi Stefan,
> On Wed, Jan 06, 2016 at 10:59:17PM -0800, Stefan Agner wrote:
>>On 2016-01-04 21:56, Peng Fan wrote:
>>> From: Peng Fan <peng.fan at nxp.com>
>>>
>>> To boot a auxiliary core in asymmetric multicore system, introduce the
>>> new command "bootaux" to do it. Example of boot auxliary core from
>>> 0x70000000 where stores the boot head information that should be
>>> parsed by auxiliary core, "bootaux 0x70000000".
>>
>>This reminds me of a question which was nagging me lately:
>>Is the M4 core of SoloX/MX7 running a boot ROM? Or who/what is "parsing
>>the boot head information"?
> 
> There is no bootrom for m4 core. The bootimage for M4 contains stack
> info and pc info. bootaux command will use the info extracted from bootimage.


So the image expected by bootaux is really a raw binary image, with the
only notion that the first two words need to be the stack pointer and
the reset handler (firmware entry point).

U-Boot has other commands which work with "raw" images, such as the
bootz command. The bootz command also expects a certain "raw" format,
hence I guess it is ok to introduce something like that also for the
auxiliary core.

Also, since every standard Cortex-M4 vector table begins with SP and
reset handler, it is very likely that a firmwares linker file put the
vector table also at the beginning of the image. Otherwise, one would
need to adopt the linker file to create a "compatible" image. Btw, as Ye
Li pointed out, the CPU needs those two words located at 0x0000000000,
this is what bootaux is actually doing, coping the information to the
right location for the M4 CPU. As an alternative, SCB_VTOR could be used
to point to the vector table. However that can only be controlled from
the M4 itself, hence is not an option for the bootaux command (as I did
it for the libopencm3 Cortex-M4 support for Vybrid, see
https://github.com/libopencm3/libopencm3/blob/master/lib/vf6xx/vector_chipset.c).

However, IMHO, this patch should at least add this
information/restriction to a README and maybe even give a hint in the
help text what is expected here....

The other restriction is that the binary needs to be loaded to the
location where the firmware has been linked to. Since the firmware is a
"raw" image, this information need to be carried along the binary (I
need to know that binary xyz.bin is linked to work at memory location
0x7F8000...). This is different to the bootz command: A raw Linux kernel
zImage has a position independent loader at the very beginning and hence
can be placed anywhere.

I don't really like that this information need to be carried along
separately.

In our downstream U-Boot for Vybrid, which has a M4 core too, I
introduced a m4boot command which makes use of the FIT image format to
carry this information, see:
http://git.toradex.com/cgit/u-boot-toradex.git/commit/?h=2015.04-toradex-next&id=d1d416f272e840e8139aec911f89a70fe5523eb2

It comes with the cost that each firmware need to be packed into a FIT
image using mkimage, but then one can just call m4boot <address of
image> and the command will make sure that the image is placed at the
right location in memory.

Another possible option would be to introduce elf support. I like this
approach since the Linux framework remoteproc also supports loading elf
firmwares, hence this would align nicely with what has been done in the
Linux kernel.

The elf format has all information required to load the firmware:
Sections and their location (in M4 terms) as well as the start address.
The platform data would only need to have a translation table for the
section addresses (0x1fff8000 <=> 0x7F8000) to be able to load the
firmware to the correct location. It comes with the cost of coping the
firmware to the right location, but it would be much easier to handle
elf firmware files.

Other opinions?

One more thing below:

> 
> See the following code:
> "
> int arch_auxiliary_core_up(u32 core_id, u32 boot_private_data)
> {
> 	struct src *src_reg;
> 	u32 stack, pc;
> 
> 	if (!boot_private_data)
> 		return 1;
> 
> 	stack = *(u32 *)boot_private_data;
> 	pc = *(u32 *)(boot_private_data + 4);
> 
> 	/* Set the stack and pc to M4 bootROM */
> 	writel(stack, M4_BOOTROM_BASE_ADDR);
> 	writel(pc, M4_BOOTROM_BASE_ADDR + 4);
> 
> 	/* Enable M4 */
> 	src_reg = (struct src *)SRC_BASE_ADDR;
> 	setbits_le32(&src_reg->scr, 0x00400000);
> 	clrbits_le32(&src_reg->scr, 0x00000010);
> 
> 	return 0;
> }
> 
> "
> 
>>
>>
>>> Introduce Kconfig option IMX_BOOTAUX.
>>>
>>> Signed-off-by: Ye.Li <ye.li at nxp.com>
>>> Signed-off-by: Peng Fan <peng.fan at nxp.com>
>>> ---
>>>  arch/arm/imx-common/Kconfig       |  6 ++++
>>>  arch/arm/imx-common/Makefile      |  1 +
>>>  arch/arm/imx-common/imx_bootaux.c | 59 +++++++++++++++++++++++++++++++++++++++
>>>  3 files changed, 66 insertions(+)
>>>  create mode 100644 arch/arm/imx-common/imx_bootaux.c
>>>
>>> diff --git a/arch/arm/imx-common/Kconfig b/arch/arm/imx-common/Kconfig
>>> index c4f48bb..1b7da5a 100644
>>> --- a/arch/arm/imx-common/Kconfig
>>> +++ b/arch/arm/imx-common/Kconfig
>>> @@ -11,3 +11,9 @@ config IMX_RDC
>>>  	  i.MX Resource domain controller is used to assign masters
>>>  	  and peripherals to differet domains. This can be used to
>>>  	  isolate resources.
>>> +
>>> +config IMX_BOOTAUX
>>> +	bool "Support boot auxiliary core"
>>> +	depends on ARCH_MX7 || ARCH_MX6
>>> +	help
>>> +	  bootaux [addr] to boot auxiliary core.
>>> diff --git a/arch/arm/imx-common/Makefile b/arch/arm/imx-common/Makefile
>>> index 568f41c..30e66ba 100644
>>> --- a/arch/arm/imx-common/Makefile
>>> +++ b/arch/arm/imx-common/Makefile
>>> @@ -28,6 +28,7 @@ obj-y 	+= cache.o init.o
>>>  obj-$(CONFIG_CMD_SATA) += sata.o
>>>  obj-$(CONFIG_IMX_VIDEO_SKIP) += video.o
>>>  obj-$(CONFIG_IMX_RDC) += rdc-sema.o
>>> +obj-$(CONFIG_IMX_BOOTAUX) += imx_bootaux.o
>>>  obj-$(CONFIG_SECURE_BOOT)    += hab.o
>>>  endif
>>>  ifeq ($(SOC),$(filter $(SOC),vf610))
>>> diff --git a/arch/arm/imx-common/imx_bootaux.c
>>> b/arch/arm/imx-common/imx_bootaux.c
>>> new file mode 100644
>>> index 0000000..da424a7
>>> --- /dev/null
>>> +++ b/arch/arm/imx-common/imx_bootaux.c
>>> @@ -0,0 +1,59 @@
>>> +/*
>>> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
>>> + *
>>> + * SPDX-License-Identifier:	GPL-2.0+
>>> + */
>>> +
>>> +#include <common.h>
>>> +#include <command.h>
>>> +
>>> +/* Allow for arch specific config before we boot */
>>> +static int __arch_auxiliary_core_up(u32 core_id, u32 boot_private_data)
>>> +{
>>> +	/* please define platform specific arch_auxiliary_core_up() */
>>> +	return CMD_RET_FAILURE;
>>> +}
>>> +
>>> +int arch_auxiliary_core_up(u32 core_id, u32 boot_private_data)
>>> +	__attribute__((weak, alias("__arch_auxiliary_core_up")));
>>> +
>>> +/* Allow for arch specific config before we boot */
>>> +static int __arch_auxiliary_core_check_up(u32 core_id)
>>> +{
>>> +	/* please define platform specific arch_auxiliary_core_check_up() */
>>> +	return 0;
>>> +}
>>> +
>>> +int arch_auxiliary_core_check_up(u32 core_id)
>>> +	__attribute__((weak, alias("__arch_auxiliary_core_check_up")));
>>> +
>>> +int do_bootaux(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
>>> +{
>>> +	ulong addr;
>>> +	int ret, up;
>>> +
>>> +	if (argc < 2)
>>> +		return CMD_RET_USAGE;
>>> +
>>> +	up = arch_auxiliary_core_check_up(0);
>>> +	if (up) {
>>> +		printf("## Auxiliary core is already up\n");
>>> +		return CMD_RET_SUCCESS;
>>> +	}
>>> +
>>> +	addr = simple_strtoul(argv[1], NULL, 16);
>>> +
>>> +	printf("## Starting auxiliary core at 0x%08lX ...\n", addr);
>>> +

A dcache flush is required after loading the firmware. This could be
also part of this command e.g. by using flush_dcache_all.

If we would make use of the elf format, then the main CPU would copy the
data to the target memory address, and we could explicitly flush only
the range required by the auxiliary core.

--
Stefan

>>> +	ret = arch_auxiliary_core_up(0, addr);
>>> +	if (ret)
>>> +		return CMD_RET_FAILURE;
>>> +
>>> +	return CMD_RET_SUCCESS;
>>> +}
>>> +
>>> +U_BOOT_CMD(
>>> +	bootaux, CONFIG_SYS_MAXARGS, 1,	do_bootaux,
>>> +	"Start auxiliary core",
>>
>>What kind of image are supported by the bootaux command? Afaik, this is
>>some special/binary only format right?
> 
> Yeah. I just got the image from our rtos team, I do not have detail
> info about the format.
> 



>>
>>Probably another discussion, but before polluting the command namespace:
>>Is that what we generally want?
> 
> Hmm, bootaux invokes
> arch_auxiliary_core_check_up
> arch_auxiliary_core_u
> 
> And arch code takes the responsibility to implement these two functions.
> 
> We try to make this common, but not sure whether this is ok for other SoCs.
> So I move the command to arch/arm/imx-common
> 
> Thanks,
> Peng.
>