On 22.02.19 19:02, Tim Harvey wrote:
> The thunderx-81xx is a device-tree implementation supporting the Cavium
> Octeon-TX CN80xx/CN81xx SoC which combines 64bit ARM cores with thunderx
> peripherals.
> 
> Signed-off-by: Tim Harvey <thar...@gateworks.com>
> ---
>  arch/arm/dts/Makefile           |   1 +
>  arch/arm/dts/thunderx-81xx.dts  |  36 +++
>  arch/arm/dts/thunderx-81xx.dtsi | 440 ++++++++++++++++++++++++++++++++

Are those a 1:1 copy from Linux? If so, it would be good to indicate so.
If not, we may want to use the Linux provided ones instead.

>  board/cavium/thunderx/Kconfig   |   4 +
>  configs/thunderx_81xx_defconfig |  29 +++
>  include/configs/thunderx_81xx.h |  71 ++++++
>  6 files changed, 581 insertions(+)
>  create mode 100644 arch/arm/dts/thunderx-81xx.dts
>  create mode 100644 arch/arm/dts/thunderx-81xx.dtsi
>  create mode 100644 configs/thunderx_81xx_defconfig
>  create mode 100644 include/configs/thunderx_81xx.h
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 87ccd96596..64e1ee77d0 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -193,6 +193,7 @@ dtb-$(CONFIG_AM43XX) += am437x-gp-evm.dtb 
> am437x-sk-evm.dtb       \
>       am4372-generic.dtb
>  dtb-$(CONFIG_TI816X) += dm8168-evm.dtb
>  dtb-$(CONFIG_THUNDERX_88XX) += thunderx-88xx.dtb
> +dtb-$(CONFIG_THUNDERX_81XX) += thunderx-81xx.dtb
>  
>  dtb-$(CONFIG_ARCH_SOCFPGA) +=                                \
>       socfpga_arria5_socdk.dtb                        \
> diff --git a/arch/arm/dts/thunderx-81xx.dts b/arch/arm/dts/thunderx-81xx.dts
> new file mode 100644
> index 0000000000..d065a36f96
> --- /dev/null
> +++ b/arch/arm/dts/thunderx-81xx.dts
> @@ -0,0 +1,36 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR X11
> +/*
> + * Cavium Thunder DTS file - Thunder board description

The board name is not terribly descriptive. What board is this for? A
model? An evaluation system?

> + *
> + * Copyright (C) 2018, Cavium Inc.
> + *
> + */
> +
> +/dts-v1/;
> +
> +/include/ "thunderx-81xx.dtsi"
> +
> +/ {
> +     model = "Cavium ThunderX CN81XX board";
> +     compatible = "cavium,thunder-81xx";
> +

[...]

> diff --git a/include/configs/thunderx_81xx.h b/include/configs/thunderx_81xx.h
> new file mode 100644
> index 0000000000..10c4a89232
> --- /dev/null
> +++ b/include/configs/thunderx_81xx.h
> @@ -0,0 +1,71 @@
> +// SPDX-License-Identifier: GPL-2.0+ 
> +/*
> + * Copyright (C) 2018, Cavium Inc.
> + */
> +
> +#ifndef __THUNDERX_81XX_H__
> +#define __THUNDERX_81XX_H__
> +
> +#include <linux/sizes.h>
> +
> +#define CONFIG_THUNDERX
> +
> +#define CONFIG_SYS_64BIT
> +
> +#define MEM_BASE                     0x00500000

Why? Are the reserved bits below? In that case, we only need to mark
them as reserved, not modify the base, right?

> +
> +#define CONFIG_SYS_LOWMEM_BASE               MEM_BASE
> +
> +/* Link Definitions */
> +#define CONFIG_SYS_INIT_SP_ADDR              (CONFIG_SYS_SDRAM_BASE + 
> 0xffff0)
> +
> +/* SMP Spin Table Definitions */
> +#define CPU_RELEASE_ADDR             (CONFIG_SYS_SDRAM_BASE + 0x7fff0)
> +
> +/* Generic Timer Definitions */
> +#define COUNTER_FREQUENCY            (0x1800000)     /* 24MHz */
> +
> +#define CONFIG_SYS_MEMTEST_START     MEM_BASE
> +#define CONFIG_SYS_MEMTEST_END               (MEM_BASE + PHYS_SDRAM_1_SIZE)
> +
> +/* Size of malloc() pool */
> +#define CONFIG_SYS_MALLOC_LEN                (CONFIG_ENV_SIZE + 1 * SZ_1M)
> +
> +/* Generic Interrupt Controller Definitions */
> +#define GICD_BASE                    (0x801000000000)
> +#define GICR_BASE                    (0x801000002000)
> +#define CONFIG_SYS_SERIAL0           0x87e024000000
> +#define CONFIG_SYS_SERIAL1           0x87e025000000
> +
> +/* Miscellaneous configurable options */
> +#define CONFIG_SYS_LOAD_ADDR         (MEM_BASE)
> +
> +/* Physical Memory Map */
> +#define PHYS_SDRAM_1                 (MEM_BASE)        /* SDRAM Bank #1 */
> +#define PHYS_SDRAM_1_SIZE            (0x80000000-MEM_BASE)   /* 2048 MB */
> +#define CONFIG_SYS_SDRAM_BASE                PHYS_SDRAM_1
>

In fact, are all of these actually used? I thought I got rid of most of
the manual header based memory layout bits for aarch64 years ago :).

> +#define CONFIG_EXTRA_ENV_SETTINGS \
> +     "loadaddr=0x02000000\0" \
> +     "kernel_addr_r=0x02000000\0" \
> +     "pxefile_addr_r=0x02000000\0" \
> +     "fdt_addr_r=0x03000000\0" \
> +     "scriptaddr=0x03100000\0" \
> +     "pxe_addr_r=0x03200000\0" \
> +     "ramdisk_addr_r=0x03300000\0" \
> +     BOOTENV
> +
> +#define BOOT_TARGET_DEVICES(func)
> +
> +#include <config_distro_bootcmd.h>
> +
> +#define CONFIG_ENV_SIZE                      0x1000

That sounds quite small for a distro env.


Alex

> +
> +/* Monitor Command Prompt */
> +#define CONFIG_SYS_CBSIZE            512     /* Console I/O Buffer Size */
> +#define CONFIG_SYS_MAXARGS           64              /* max command args */
> +#define CONFIG_NO_RELOCATION         1
> +#define PLL_REF_CLK                  50000000        /* 50 MHz */
> +#define NS_PER_REF_CLK_TICK          (1000000000/PLL_REF_CLK)
> +
> +#endif /* __THUNDERX_81XX_H__ */
> 
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Reply via email to