Hi Max,
On 8 July 2016 at 09:41, Max Filippov <jcmvb...@gmail.com> wrote:
> From: Chris Zankel <ch...@zankel.net>
>
> The Xtensa processor architecture is a configurable, extensible,
> and synthesizable 32-bit RISC processor core provided by Cadence.
>
> This is the first part of the basic architecture port with changes to
> common files. The 'arch/xtensa' directory, and boards and additional
> drivers will be in separate commits.
>
> Signed-off-by: Chris Zankel <ch...@zankel.net>
> Signed-off-by: Max Filippov <jcmvb...@gmail.com>
> ---
> MAINTAINERS | 5 +++
> MAKEALL | 6 +++
> Makefile | 10 ++++-
> cmd/bdinfo.c | 22 ++++++++++
> common/board_f.c | 7 ++--
> common/image.c | 1 +
> doc/README.xtensa | 100
> ++++++++++++++++++++++++++++++++++++++++++++
> examples/standalone/stubs.c | 47 +++++++++++++++++++++
> include/image.h | 1 +
> include/linux/stat.h | 4 +-
> 10 files changed, 197 insertions(+), 6 deletions(-)
> create mode 100644 doc/README.xtensa
Reviewed-by: Simon Glass <s...@chromium.org>
nits below
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1db8243..24afa88 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -453,6 +453,11 @@ S: Maintained
> T: git git://git.denx.de/u-boot-x86.git
> F: arch/x86/
>
> +XTENSA
> +M: Max Filippov <jcmvb...@gmail.com>
> +S: Maintained
> +F: arch/xtensa/
> +
> THE REST
> M: Tom Rini <tr...@konsulko.com>
> L: u-boot@lists.denx.de
> diff --git a/MAKEALL b/MAKEALL
> index 7e42f10..e669aa9 100755
> --- a/MAKEALL
> +++ b/MAKEALL
This is deprecated and will be removed soon, so you don't need to
update it. See buildman.
> @@ -497,6 +497,12 @@ LIST_nds32="$(targets_by_arch nds32)"
>
> LIST_arc="$(targets_by_arch arc)"
>
> +#########################################################################
> +## Xtensa Systems
> +#########################################################################
> +
> +LIST_xtensa="$(targets_by_arch xtensa)"
> +
> #-----------------------------------------------------------------------
>
> get_target_location() {
> diff --git a/Makefile b/Makefile
> index 09a18e1..083af95 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -556,6 +556,14 @@ else
> include/config/auto.conf: ;
> endif # $(dot-config)
>
> +#
> +# Xtensa linker script cannot be preprocessed with -ansi because of
> +# preprocessor operations on strings that don't make C identifiers.
> +#
> +ifeq ($(CONFIG_XTENSA),)
> +LDPPFLAGS += -ansi
> +endif
> +
> ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
> KBUILD_CFLAGS += -Os
> else
> @@ -1310,7 +1318,7 @@ $(timestamp_h): $(srctree)/Makefile FORCE
>
> # ---------------------------------------------------------------------------
> quiet_cmd_cpp_lds = LDS $@
> -cmd_cpp_lds = $(CPP) -Wp,-MD,$(depfile) $(cpp_flags) $(LDPPFLAGS) -ansi \
> +cmd_cpp_lds = $(CPP) -Wp,-MD,$(depfile) $(cpp_flags) $(LDPPFLAGS) \
> -D__ASSEMBLY__ -x assembler-with-cpp -P -o $@ $<
>
> u-boot.lds: $(LDSCRIPT) prepare FORCE
> diff --git a/cmd/bdinfo.c b/cmd/bdinfo.c
> index 1c4bed9..076b950 100644
> --- a/cmd/bdinfo.c
> +++ b/cmd/bdinfo.c
> @@ -563,6 +563,28 @@ int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc, char
> * const argv[])
> return 0;
> }
>
> +#elif defined(CONFIG_XTENSA)
> +
> +int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> +{
> + bd_t *bd = gd->bd;
> +
> + print_num("boot_params", (ulong)bd->bi_boot_params);
> + print_num("memstart", (ulong)bd->bi_memstart);
> + print_lnum("memsize", (u64)bd->bi_memsize);
> + print_num("flashstart", (ulong)bd->bi_flashstart);
> + print_num("flashsize", (ulong)bd->bi_flashsize);
> + print_num("flashoffset", (ulong)bd->bi_flashoffset);
> +
> +#if defined(CONFIG_CMD_NET)
> + print_eth(0);
> + printf("ip_addr = %s\n", getenv("ipaddr"));
> +#endif
> + printf("baudrate = %d bps\n", gd->baudrate);
It would be great if you could put this in a common function so that
other archs can call it. There is a lot of duplication in this file.
> +
> + return 0;
> +}
> +
> #else
> #error "a case for this architecture does not exist!"
> #endif
> diff --git a/common/board_f.c b/common/board_f.c
> index d405b5b..5c4f9fb 100644
> --- a/common/board_f.c
> +++ b/common/board_f.c
> @@ -270,7 +270,8 @@ static int setup_mon_len(void)
> gd->mon_len = (ulong)&__bss_end - (ulong)_start;
> #elif defined(CONFIG_SANDBOX) || defined(CONFIG_EFI_APP)
> gd->mon_len = (ulong)&_end - (ulong)_init;
> -#elif defined(CONFIG_BLACKFIN) || defined(CONFIG_NIOS2)
> +#elif defined(CONFIG_BLACKFIN) || defined(CONFIG_NIOS2) || \
> + defined(CONFIG_XTENSA)
> gd->mon_len = CONFIG_SYS_MONITOR_LEN;
> #elif defined(CONFIG_NDS32)
> gd->mon_len = (ulong)(&__bss_end) - (ulong)(&_start);
> @@ -961,7 +962,7 @@ static init_fnc_t init_sequence_f[] = {
> * - board info struct
> */
> setup_dest_addr,
> -#if defined(CONFIG_BLACKFIN)
> +#if defined(CONFIG_BLACKFIN) || defined(CONFIG_XTENSA)
> /* Blackfin u-boot monitor should be on top of the ram */
> reserve_uboot,
> #endif
> @@ -993,7 +994,7 @@ static init_fnc_t init_sequence_f[] = {
> # endif
> #endif /* CONFIG_DM_VIDEO */
> reserve_trace,
> -#if !defined(CONFIG_BLACKFIN)
> +#if !defined(CONFIG_BLACKFIN) && !defined(CONFIG_XTENSA)
> reserve_uboot,
> #endif
> #ifndef CONFIG_SPL_BUILD
> diff --git a/common/image.c b/common/image.c
> index 0be09e5..7d25e10 100644
> --- a/common/image.c
> +++ b/common/image.c
> @@ -93,6 +93,7 @@ static const table_entry_t uimage_arch[] = {
> { IH_ARCH_ARM64, "arm64", "AArch64", },
> { IH_ARCH_ARC, "arc", "ARC", },
> { IH_ARCH_X86_64, "x86_64", "AMD x86_64", },
> + { IH_ARCH_XTENSA, "xtensa", "Xtensa", },
> { -1, "", "", },
> };
>
> diff --git a/doc/README.xtensa b/doc/README.xtensa
> new file mode 100644
> index 0000000..a461714
> --- /dev/null
> +++ b/doc/README.xtensa
> @@ -0,0 +1,100 @@
> +U-Boot for the Xtensa Architecture
> +==================================
> +
> +Xtensa Architecture and Diamond Cores
> +-------------------------------------
> +
> +Xtensa is a configurable processor architecture from Tensilica, Inc.
> +Diamond Cores are pre-configured instances available for license and
> +SoC cores in the same manner as ARM, MIPS, etc.
> +
> +Xtensa licensees create their own Xtensa cores with selected features
> +and custom instructions, registers and co-processors. The custom core
> +is configured with Tensilica tools and built with Tensilica's Xtensa
> +Processor Generator.
> +
> +There are an effectively infinite number of CPUs in the Xtensa
> +architecture family. It is, however, not feasible to support individual
> +Xtensa CPUs in U-Boot. Therefore, there is only a single 'xtensa' CPU
> +in the cpu tree of U-Boot.
> +
> +In the same manner as the Linux port to Xtensa, U-Boot adapts to an
> +individual Xtensa core configuration using a set of macros provided with
> +the particular core. This is part of what is known as the hardware
> +abstraction layer (HAL). For the purpose of U-Boot, the HAL consists only
> +of a few header files. These provide CPP macros that customize sources,
> +Makefiles, and the linker script.
> +
> +
> +Adding support for an additional processor configuration
> +--------------------------------------------------------
> +
> +The header files for one particular processor configuration are inside
> +a variant specific directory located in the arch/xtensa/include/asm
variant-specific
> +directory. The name of that directory starts with 'arch-' followed by
> +the name for the processor configuration, for example, arch-dc233c for
> +the Diamond DC233 processor.
> +
> + core.h Definitions for the core itself.
> +
> +The following files are part of the overlay but not used by U-Boot.
> +
> + tie.h Co-processors and custom extensions defined
> + in the Tensilica Instruction Extension (TIE)
> + language.
> + tie-asm.h Assembly macros to access custom-defined registers
> + and states.
> +
> +
> +Global Data Pointer, Exported Function Stubs, and the ABI
> +---------------------------------------------------------
> +
> +To support standalone applications launched with the "go" command,
> +U-Boot provides a jump table of entrypoints to exported functions
> +(grep for EXPORT_FUNC). The implementation for Xtensa depends on
> +which ABI (or function calling convention) is used.
> +
> +Windowed ABI presents unique difficulties with the approach based on
> +keeping global data pointer in dedicated register. Because the register
> +window rotates during a call, there is no register that is constantly
> +available for the gd pointer. Therefore, a global variable is used in
> +the same manner as i386.
Or you could make gd a simple global variable. It you keep it in the
data section that should work.
> Another difficulty arises from the requirement
> +to have an 'entry' at the beginning of a function, which rotates the
> +register file and reserves a stack frame. This is an integral part of
> +the windowed ABI implemented in hardware. It makes using a jump table
> +to an arbitrary (separately compiled) function a bit tricky. Use of a
> +simple wrapper is also very tedious due to the need to move all
> +possible register arguments and adjust the stack to handle arguments
> +that cannot be passed in registers. The most efficient approach is to
> +have the jump table perform the 'entry' so as to pretend it's the start
> +of the real function. This requires decoding the target function's
> +'entry' instruction to determine the stack frame size, and adjusting
> +the stack pointer accordingly, then jumping into the target function
> +just after the 'entry'. Decoding depends on the processor's endianness
> +so uses the HAL. The implementation (12 instructions) is in
> +examples/stubs.c.
> +
> +
> +Access to Invalid Memory Addresses
> +----------------------------------
> +
> +U-Boot does not check if memory addresses given as arguments to commands
> +such as "md" are valid. The expectation appears to be that if the user
> +requests to look at invalid memory he should expect to see garbage, and
> +writes to invalid memory should be ignored.
> +
> +On many processors, and indeed many Xtensa configurations, this is
> +acceptable. However on some configurations (particularly those with an
> +MMU such as would be used with Linux) an exception is generated for an
> +invalid memory access, which results in a hang if not handled.
> +
> +U-Boot for Xtensa provides a special memory exception handler to prevent
> +hanging. The memory exception handler simply skips over the offending
> +instruction. It is called for all memory exception causes that might
> +be triggered by bad user input. While this is simplistic, it's better
> +than hanging in most cases, while keeping U-Boot small and simple.
Wouldn't it be better to print an exception message? See for example
ARM's do_prefetch_abort().
[snip]
Regards,
Simon
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
