Re: [U-Boot] [PATCH v2 1/6] dm: SMEM (Shared memory) uclass
Hi Simon
On Tue, Jun 26, 2018 at 6:59 AM Simon Glass wrote:
> Hi Ramon,
>
> On 21 June 2018 at 20:11, Ramon Fried wrote:
> > This is a uclass for Shared memory manager drivers.
> >
> > A Shared Memory Manager driver implements an interface for allocating
> > and accessing items in the memory area shared among all of the
> > processors.
> >
> > Signed-off-by: Ramon Fried
> >
> > ---
> >
> > Changes in v2:
> > (As suggested by Simon Glass)
> > - Introduced a new dm class (CLASS_SMEM) instead of CLASS_SOC.
> > - Added sandbox driver
> > - Added testing for DM class.
> >
> > drivers/Makefile | 1 +
> > drivers/smem/Kconfig | 2 +
> > drivers/smem/Makefile | 5 +++
> > drivers/smem/smem-uclass.c | 53
> > include/dm/uclass-id.h | 1 +
> > include/smem.h | 84 ++
> > 6 files changed, 146 insertions(+)
> > create mode 100644 drivers/smem/Kconfig
> > create mode 100644 drivers/smem/Makefile
> > create mode 100644 drivers/smem/smem-uclass.c
> > create mode 100644 include/smem.h
> >
>
> Reviewed-by: Simon Glass
>
> A few nits below.
>
> > diff --git a/drivers/Makefile b/drivers/Makefile
> > index a213ea9671..ba4a561358 100644
> > --- a/drivers/Makefile
> > +++ b/drivers/Makefile
> > @@ -98,6 +98,7 @@ obj-y += pwm/
> > obj-y += reset/
> > obj-y += input/
> > # SOC specific infrastructure drivers.
> > +obj-y += smem/
> > obj-y += soc/
> > obj-$(CONFIG_REMOTEPROC) += remoteproc/
> > obj-y += thermal/
> > diff --git a/drivers/smem/Kconfig b/drivers/smem/Kconfig
> > new file mode 100644
> > index 00..64337a8b8e
> > --- /dev/null
> > +++ b/drivers/smem/Kconfig
> > @@ -0,0 +1,2 @@
> > +menuconfig SMEM
> > + bool "SMEM (Shared Memory mamanger) support"
> > diff --git a/drivers/smem/Makefile b/drivers/smem/Makefile
> > new file mode 100644
> > index 00..ca55c4512d
> > --- /dev/null
> > +++ b/drivers/smem/Makefile
> > @@ -0,0 +1,5 @@
> > +# SPDX-License-Identifier: GPL-2.0+
> > +#
> > +# Makefile for the U-Boot SMEM interface drivers
> > +
> > +obj-$(CONFIG_SMEM) += smem-uclass.o
> > diff --git a/drivers/smem/smem-uclass.c b/drivers/smem/smem-uclass.c
> > new file mode 100644
> > index 00..07ed1a92d8
> > --- /dev/null
> > +++ b/drivers/smem/smem-uclass.c
> > @@ -0,0 +1,53 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (c) 2018 Ramon Fried
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +int smem_alloc(struct udevice *dev, unsigned int host,
> > + unsigned int item, size_t size)
> > +{
> > + struct smem_ops *ops = smem_get_ops(dev);
> > +
> > + if (!ops->alloc)
> > + return -ENOSYS;
> > +
> > + return ops->alloc(host, item, size);
> > +}
> > +
> > +void *smem_get(struct udevice *dev, unsigned int host,
> > + unsigned int item, size_t *size)
> > +{
> > + struct smem_ops *ops = smem_get_ops(dev);
> > +
> > + if (!ops->get)
> > + return NULL;
> > +
> > + return ops->get(host, item, size);
> > +}
> > +
> > +int smem_get_free_space(struct udevice *dev, unsigned int host, size_t
> *free)
> > +{
> > + struct smem_ops *ops = smem_get_ops(dev);
> > +
> > + int ret;
> > +
> > + if (!ops->get_free_space)
> > + return -ENOSYS;
> > +
> > + ret = ops->get_free_space(host);
> > + if (ret > 0)
> > + *free = ret;
> > + else
> > + return ret;
>
> It seems odd that get_free_space() has a different return value than
> smem_get_free_space(). Can you make the latter return the amount of
> free space? If not, change the op to return it in a param. You can use
> long as the return value if that helps.
>
I fixed smem_get_free_space() to look the same as get_free_space().
> > +
> > + return 0;
> > +}
> > +
> > +UCLASS_DRIVER(smem) = {
> > + .id = UCLASS_SMEM,
> > + .name = "smem",
> > +};
> > diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
> > index d7f9df3583..a39643ec5e 100644
> > --- a/include/dm/uclass-id.h
> > +++ b/include/dm/uclass-id.h
> > @@ -74,6 +74,7 @@ enum uclass_id {
> > UCLASS_RTC, /* Real time clock device */
> > UCLASS_SCSI,/* SCSI device */
> > UCLASS_SERIAL, /* Serial UART */
> > + UCLASS_SMEM,/* Shared memory interface */
> > UCLASS_SPI, /* SPI bus */
> > UCLASS_SPMI,/* System Power Management Interface bus
> */
> > UCLASS_SPI_FLASH, /* SPI flash */
> > diff --git a/include/smem.h b/include/smem.h
> > new file mode 100644
> > index 00..201960232c
> > --- /dev/null
> > +++ b/include/smem.h
> > @@ -0,0 +1,84 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ */
> > +/*
> > + * header file for smem driver.
>
> If you have a README somewhere please point to it here.
>
> > + *
> > + * Copyright (c) 2018
Re: [U-Boot] [PATCH v2 4/6] dts: db820c: added smem nodes
On 21 June 2018 at 20:11, Ramon Fried wrote: > Added necessary nodes for Qualcomm smem driver. > > Signed-off-by: Ramon Fried > --- > > Changes in v2: None > > arch/arm/dts/dragonboard820c-uboot.dtsi | 4 > arch/arm/dts/dragonboard820c.dts| 16 > 2 files changed, 20 insertions(+) > Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/6] drivers: smem: sandbox
On 21 June 2018 at 20:11, Ramon Fried wrote: > Add Sandbox driver for SMEM. mostly stub operations. > > Signed-off-by: Ramon Fried > --- > > Changes in v2: None > > arch/sandbox/dts/test.dts | 4 > configs/sandbox64_defconfig | 2 ++ > configs/sandbox_defconfig | 2 ++ > drivers/smem/Kconfig| 9 > drivers/smem/Makefile | 1 + > drivers/smem/sandbox_smem.c | 45 + > 6 files changed, 63 insertions(+) > create mode 100644 drivers/smem/sandbox_smem.c Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/6] soc: qualcomm: Add Shared Memory Manager driver
Hi Ramon, On 21 June 2018 at 20:11, Ramon Fried wrote: > The Shared Memory Manager driver implements an interface for allocating > and accessing items in the memory area shared among all of the > processors in a Qualcomm platform. > > Adapted from the Linux driver (4.17) > > Changes from the original Linux driver: > * Removed HW spinlock mechanism, which is irrelevant > in U-boot particualar use case, which is just reading from the smem. U-Boot > * adaptaion from Linux driver model to U-boot's. Adapted (I think) > > Cc: Bjorn Andersson > Signed-off-by: Ramon Fried > > --- > > Changes in v2: > - Applied checkpatch fixes (also sent these to Linux upstream) > - Changed UCLASS_SOC to UCLASS_SMEM > - Removed function exports and registered functionality through .ops > > MAINTAINERS | 1 + > arch/arm/Kconfig| 2 + > drivers/Kconfig | 2 + > drivers/smem/Kconfig| 13 + > drivers/smem/Makefile | 1 + > drivers/smem/msm_smem.c | 941 > 6 files changed, 960 insertions(+) > create mode 100644 drivers/smem/msm_smem.c > Reviewed-by: Simon Glass with nits as noted. > diff --git a/MAINTAINERS b/MAINTAINERS > index b2c9717cb7..b691bae13c 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -187,6 +187,7 @@ ARM SNAPDRAGON > M: Ramon Fried > S: Maintained > F: arch/arm/mach-snapdragon/ > +F: drivers/smem/msm_smem.c > > ARM STI > M: Patrice Chotard > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 22234cde2a..badf4cacb8 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -728,6 +728,8 @@ config ARCH_SNAPDRAGON > select SPMI > select OF_CONTROL > select OF_SEPARATE > + select SMEM > + select MSM_SMEM > > config ARCH_SOCFPGA > bool "Altera SOCFPGA family" > diff --git a/drivers/Kconfig b/drivers/Kconfig > index 9e21b28750..c72abf8932 100644 > --- a/drivers/Kconfig > +++ b/drivers/Kconfig > @@ -84,6 +84,8 @@ source "drivers/scsi/Kconfig" > > source "drivers/serial/Kconfig" > > +source "drivers/smem/Kconfig" > + > source "drivers/sound/Kconfig" > > source "drivers/spi/Kconfig" > diff --git a/drivers/smem/Kconfig b/drivers/smem/Kconfig > index 64337a8b8e..77ad02e236 100644 > --- a/drivers/smem/Kconfig > +++ b/drivers/smem/Kconfig > @@ -1,2 +1,15 @@ > menuconfig SMEM > bool "SMEM (Shared Memory mamanger) support" manager > + > +if SMEM > + > +config MSM_SMEM > +bool "Qualcomm Shared Memory Manager (SMEM)" > +depends on DM > +depends on ARCH_SNAPDRAGON > +help > + enable support for the Qualcomm Shared Memory Manager. Enable > + The driver provides an interface to items in a heap shared among all > + processors in a Qualcomm platform. > + > +endif # menu "SMEM Support" > diff --git a/drivers/smem/Makefile b/drivers/smem/Makefile > index ca55c4512d..605b8fc290 100644 > --- a/drivers/smem/Makefile > +++ b/drivers/smem/Makefile > @@ -3,3 +3,4 @@ > # Makefile for the U-Boot SMEM interface drivers > > obj-$(CONFIG_SMEM) += smem-uclass.o > +obj-$(CONFIG_MSM_SMEM) += msm_smem.o > diff --git a/drivers/smem/msm_smem.c b/drivers/smem/msm_smem.c > new file mode 100644 > index 00..183ab7b54b > --- /dev/null > +++ b/drivers/smem/msm_smem.c > @@ -0,0 +1,941 @@ > +// SPDX-License-Identifier: GPL-2.0+ > +/* > + * Copyright (c) 2015, Sony Mobile Communications AB. > + * Copyright (c) 2012-2013, The Linux Foundation. All rights reserved. > + * Copyright (c) 2018, Ramon Fried > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 and > + * only version 2 as published by the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. Can you drop the license? The SPDX should be enough. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +DECLARE_GLOBAL_DATA_PTR; > + > +/* > + * The Qualcomm shared memory system is an allocate only heap structure that allocate-only > + * consists of one of more memory areas that can be accessed by the > processors > + * in the SoC. > + * > + * All systems contains a global heap, accessible by all processors in the > SoC, > + * with a table of contents data structure (@smem_header) at the beginning of > + * the main shared memory block. > + * > + * The global header contains meta data for allocations as well as a fixed > list > + * of 512 entries (@smem_global_entry) that can be initialized to reference > + * parts of the shared memory space. > + * > + * > + * In addition to this global heap a set of "private" heaps can be set up at heap, a > + * boot time with access
Re: [U-Boot] [PATCH v2 3/6] dts: db410c: added smem nodes
On 21 June 2018 at 20:11, Ramon Fried wrote: > Added necessary nodes for Qualcomm smem driver. > > Signed-off-by: Ramon Fried > --- > > Changes in v2: None > > arch/arm/dts/dragonboard410c-uboot.dtsi | 5 + > arch/arm/dts/dragonboard410c.dts| 16 > 2 files changed, 21 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/6] dm: SMEM (Shared memory) uclass
Hi Ramon,
On 21 June 2018 at 20:11, Ramon Fried wrote:
> This is a uclass for Shared memory manager drivers.
>
> A Shared Memory Manager driver implements an interface for allocating
> and accessing items in the memory area shared among all of the
> processors.
>
> Signed-off-by: Ramon Fried
>
> ---
>
> Changes in v2:
> (As suggested by Simon Glass)
> - Introduced a new dm class (CLASS_SMEM) instead of CLASS_SOC.
> - Added sandbox driver
> - Added testing for DM class.
>
> drivers/Makefile | 1 +
> drivers/smem/Kconfig | 2 +
> drivers/smem/Makefile | 5 +++
> drivers/smem/smem-uclass.c | 53
> include/dm/uclass-id.h | 1 +
> include/smem.h | 84 ++
> 6 files changed, 146 insertions(+)
> create mode 100644 drivers/smem/Kconfig
> create mode 100644 drivers/smem/Makefile
> create mode 100644 drivers/smem/smem-uclass.c
> create mode 100644 include/smem.h
>
Reviewed-by: Simon Glass
A few nits below.
> diff --git a/drivers/Makefile b/drivers/Makefile
> index a213ea9671..ba4a561358 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -98,6 +98,7 @@ obj-y += pwm/
> obj-y += reset/
> obj-y += input/
> # SOC specific infrastructure drivers.
> +obj-y += smem/
> obj-y += soc/
> obj-$(CONFIG_REMOTEPROC) += remoteproc/
> obj-y += thermal/
> diff --git a/drivers/smem/Kconfig b/drivers/smem/Kconfig
> new file mode 100644
> index 00..64337a8b8e
> --- /dev/null
> +++ b/drivers/smem/Kconfig
> @@ -0,0 +1,2 @@
> +menuconfig SMEM
> + bool "SMEM (Shared Memory mamanger) support"
> diff --git a/drivers/smem/Makefile b/drivers/smem/Makefile
> new file mode 100644
> index 00..ca55c4512d
> --- /dev/null
> +++ b/drivers/smem/Makefile
> @@ -0,0 +1,5 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# Makefile for the U-Boot SMEM interface drivers
> +
> +obj-$(CONFIG_SMEM) += smem-uclass.o
> diff --git a/drivers/smem/smem-uclass.c b/drivers/smem/smem-uclass.c
> new file mode 100644
> index 00..07ed1a92d8
> --- /dev/null
> +++ b/drivers/smem/smem-uclass.c
> @@ -0,0 +1,53 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2018 Ramon Fried
> + */
> +
> +#include
> +#include
> +#include
> +
> +int smem_alloc(struct udevice *dev, unsigned int host,
> + unsigned int item, size_t size)
> +{
> + struct smem_ops *ops = smem_get_ops(dev);
> +
> + if (!ops->alloc)
> + return -ENOSYS;
> +
> + return ops->alloc(host, item, size);
> +}
> +
> +void *smem_get(struct udevice *dev, unsigned int host,
> + unsigned int item, size_t *size)
> +{
> + struct smem_ops *ops = smem_get_ops(dev);
> +
> + if (!ops->get)
> + return NULL;
> +
> + return ops->get(host, item, size);
> +}
> +
> +int smem_get_free_space(struct udevice *dev, unsigned int host, size_t *free)
> +{
> + struct smem_ops *ops = smem_get_ops(dev);
> +
> + int ret;
> +
> + if (!ops->get_free_space)
> + return -ENOSYS;
> +
> + ret = ops->get_free_space(host);
> + if (ret > 0)
> + *free = ret;
> + else
> + return ret;
It seems odd that get_free_space() has a different return value than
smem_get_free_space(). Can you make the latter return the amount of
free space? If not, change the op to return it in a param. You can use
long as the return value if that helps.
> +
> + return 0;
> +}
> +
> +UCLASS_DRIVER(smem) = {
> + .id = UCLASS_SMEM,
> + .name = "smem",
> +};
> diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
> index d7f9df3583..a39643ec5e 100644
> --- a/include/dm/uclass-id.h
> +++ b/include/dm/uclass-id.h
> @@ -74,6 +74,7 @@ enum uclass_id {
> UCLASS_RTC, /* Real time clock device */
> UCLASS_SCSI,/* SCSI device */
> UCLASS_SERIAL, /* Serial UART */
> + UCLASS_SMEM,/* Shared memory interface */
> UCLASS_SPI, /* SPI bus */
> UCLASS_SPMI,/* System Power Management Interface bus */
> UCLASS_SPI_FLASH, /* SPI flash */
> diff --git a/include/smem.h b/include/smem.h
> new file mode 100644
> index 00..201960232c
> --- /dev/null
> +++ b/include/smem.h
> @@ -0,0 +1,84 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * header file for smem driver.
If you have a README somewhere please point to it here.
> + *
> + * Copyright (c) 2018 Ramon Fried
> + */
> +
> +#ifndef _smemh_
> +#define _smemh_
> +
> +/* struct smem_ops: Operations for the SMEM uclass */
> +struct smem_ops {
> + /**
> +* alloc() - allocate space for a smem item
> +*
> +* @host: remote processor id, or -1
What does -1 mean? Please expand commment
> +* @item: smem item handle
How does one choose this? What does it mean? Can you expand this comment a bit?
Re: [U-Boot] [PATCH v2 6/6] test: smem: add basic smem test
On 21 June 2018 at 20:11, Ramon Fried wrote: > Add basic smem sandbox testing. > > Signed-off-by: Ramon Fried > > --- > Tom, this patch depends on https://patchwork.ozlabs.org/patch/932965/ > > Changes in v2: None > > test/dm/Makefile | 1 + > test/dm/smem.c | 29 + > 2 files changed, 30 insertions(+) > create mode 100644 test/dm/smem.c Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/3] common: Generic loader for file system
Hi,
On 25 June 2018 at 07:28, wrote:
> From: Tien Fong Chee
>
> This is file system generic loader which can be used to load
> the file image from the storage into target such as memory.
> The consumer driver would then use this loader to program whatever,
> ie. the FPGA device.
>
> Signed-off-by: Tien Fong Chee
> ---
> drivers/misc/Kconfig | 10 ++
> drivers/misc/Makefile| 1 +
> drivers/misc/fs_loader.c | 238
> +++
> include/dm/uclass-id.h | 1 +
> include/fs_loader.h | 28 ++
> 5 files changed, 278 insertions(+)
> create mode 100644 drivers/misc/fs_loader.c
> create mode 100644 include/fs_loader.h
This is definitely looking good. I think we need to figure out the
binding to devices, to use phandles instead of strings. Also we need a
sandbox driver and test.
I'm a little worried that you are blazing a trail here, but it is a
valuable trail :-)
Tom, do you have any ideas / thoughts on the design?
>
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index 17b3a80..4163b4f 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -277,4 +277,14 @@ config GDSYS_RXAUI_CTRL
> depends on MISC
> help
> Support gdsys FPGA's RXAUI control.
> +
> +config FS_LOADER
> + bool "Enable loader driver for file system"
> + help
> + This is file system generic loader which can be used to load
> + the file image from the storage into target such as memory.
> +
> + The consumer driver would then use this loader to program whatever,
> + ie. the FPGA device.
> +
> endmenu
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index 4ce9d21..67a36f8 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -54,3 +54,4 @@ obj-$(CONFIG_STM32_RCC) += stm32_rcc.o
> obj-$(CONFIG_STM32MP_FUSE) += stm32mp_fuse.o
> obj-$(CONFIG_SYS_DPAA_QBMAN) += fsl_portals.o
> obj-$(CONFIG_GDSYS_RXAUI_CTRL) += gdsys_rxaui_ctrl.o
> +obj-$(CONFIG_FS_LOADER) += fs_loader.o
> diff --git a/drivers/misc/fs_loader.c b/drivers/misc/fs_loader.c
> new file mode 100644
> index 000..0dc385f
> --- /dev/null
> +++ b/drivers/misc/fs_loader.c
> @@ -0,0 +1,238 @@
> +/*
> + * Copyright (C) 2018 Intel Corporation
> + *
> + * SPDX-License-Identifier:GPL-2.0
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +struct firmware_priv {
> + const char *name; /* Filename */
> + u32 offset; /* Offset of reading a file */
> +};
> +
> +static int select_fs_dev(struct device_platdata *plat)
> +{
> + int ret;
> +
> + if (!strcmp("mmc", plat->name)) {
> + ret = fs_set_blk_dev("mmc", plat->devpart, FS_TYPE_ANY);
> + } else if (!strcmp("usb", plat->name)) {
> + ret = fs_set_blk_dev("usb", plat->devpart, FS_TYPE_ANY);
> + } else if (!strcmp("sata", plat->name)) {
> + ret = fs_set_blk_dev("sata", plat->devpart, FS_TYPE_ANY);
For these I think you can look up the phandle to obtain the device,
then check its uclass to find out its type.
> + } else if (!strcmp("ubi", plat->name)) {
> + if (plat->ubivol)
> + ret = fs_set_blk_dev("ubi", NULL, FS_TYPE_UBIFS);
> + else
> + ret = -ENODEV;
> + } else {
> + debug("Error: unsupported storage device.\n");
> + return -ENODEV;
> + }
> +
> + if (ret)
> + debug("Error: could not access storage.\n");
> +
> + return ret;
> +}
> +
> +static void set_storage_devpart(struct device_platdata *plat, char *devpart)
> +{
> + plat->devpart = devpart;
> +}
> +
> +static void set_storage_mtdpart(struct device_platdata *plat, char *mtdpart)
> +{
> + plat->mtdpart = mtdpart;
> +}
> +
> +static void set_storage_ubivol(struct device_platdata *plat, char *ubivol)
> +{
> + plat->ubivol = ubivol;
> +}
> +
> +/**
> + * _request_firmware_prepare - Prepare firmware struct.
> + *
> + * @firmware_p: Pointer to pointer to firmware image.
> + * @name: Name of firmware file.
> + * @dbuf: Address of buffer to load firmware into.
> + * @size: Size of buffer.
> + * @offset: Offset of a file for start reading into buffer.
> + *
> + * Return: Negative value if fail, 0 for successful.
> + */
> +static int _request_firmware_prepare(struct firmware **firmware_p,
Can you please move this to be the last arg and rename to firmwarep?
> + const char *name, void *dbuf,device to ubi
> + size_t size, u32 offset)
> +{
> + struct firmware *firmware;
> + struct firmware_priv *fw_priv;
> +
> + *firmware_p = NULL;
> +
> + if (!name || name[0] == '\0')
> + return -EINVAL;
> +
> + firmware = calloc(1, sizeof(*firmware));
> + if
Re: [U-Boot] Sharing code between U-Boot and its secure monitor
Hi,
On 25 June 2018 at 14:44, Stephen Warren wrote:
> On 06/24/2018 12:17 AM, Alexander Graf wrote:
>>
>>
>>
>>> Am 22.06.2018 um 21:24 schrieb Stephen Warren :
>>>
>>> I am writing more secure monitor (PSCI) support for Jetson TK1. In
>>> particular, this code will support resume from the LP0 system suspend state,
>>> which entails signing a block of code for the boot ROM to validate during
>>> resume. The signing code uses lib/aes.c. This code is linked into U-Boot in
>>> the "main" part of U-Boot, rather than into the secure section that contains
>>> the monitor code. The monitor should only call code within the monitor
>>> section, not within the main part of U-Boot (in general, the monitor
>>> continues to run after U-Boot has been replaced in RAM, so cannot call code
>>> in U-Boot since it may no longer exist, and even if it does, that code is
>>> not in the secure DRAM carve-out, and hence it's not secure to call it). So,
>>> I need to duplicate the lib/aes.c object code into the monitor. The question
>>> is: what's the best way to do that.
>>>
>>> So far, here's what I implemented:
>>>
>>> a) Edit lib/aes.c to mark each function with an optional attribute which
>>> will force the object code into the secure section when compiled for the
>>> monitor:
>>>
>>> -static const u8 sbox[256] = {
>>> +static const u8 mon_rodata sbox[256] = {
>>>
>>> -void aes_cbc_decrypt_blocks(...
>>> +void mon_text aes_cbc_decrypt_blocks(...
>>>
>>> ... where mon_text evaluates to:
>>>
>>> +#define mon_rodata
>>> +#define mon_text
>>>
>>> or:
>>>
>>> +#define mon_data__attribute__((section("._secure.data")))
>>> +#define mon_rodata__attribute__((section("._secure.rodata")))
>>> +#define mon_text__attribute__((section("._secure.text")))
>>
>>
>> Please check my recent fix to rename the efi sections. Gcc may under some
>> conditions generate implicit symbols, such as rodata constants. You can only
>> catch them if your text section for the function starts with .text.
>>
>>>
>>> b) Since the main U-Boot and the monitor code are part of the same ELF
>>> file, the same symbol name cannot exist in both. So, we must play similar
>>> games in order to rename the symbols:
>>>
>>> -void aes_cbc_decrypt_blocks(...
>>> +void mon_text MON_SYM(aes_cbc_decrypt_blocks)(...
>>>
>>> (all call sites have to be updated similarly)
>>>
>>> ... where MON_SYM(x) is either:
>>>
>>> +#define MON_SYM(x) x
>>>
>>> or:
>>>
>>> +#define MON_SYM(x) mon_##x
>>>
>>> c) In the monitor, create a file mon_aes.c that sets up all the macros
>>> mentioned above, then #includes the main lib/aes.c. Add this file to a
>>> Makefile.
>>>
>>> +#include "mon_section.h"
>>> +#include "../../../../../lib/aes.c"
>>>
>>> This is all rather nasty and invasive, especially when you consider more
>>> widely used utility functions such as malloc(), printf(), udelay(), etc..
>>> Instead, I wonder if we can:
>>>
>>> a) Link the monitor to an ELF file and extract a binary. We won't need
>>> any special section or symbol name logic here, since we can assume that all
>>> of .text/.data are part of the monitor. Simple and non-invasive!
>>>
>>> b) Link the LP0 resume code to an ELF file and extract a binary. (It's
>>> nice to separate this block of code since it runs on a different CPU to the
>>> main U-Boot or monitor, and hence gets compiled with different compiler
>>> flags).
>>>
>>> c) Include the binaries from (a) and (b) above in the main U-Boot ELF
>>> file or binary somehow; perhaps use binman to allow the main U-Boot to know
>>> where those merged binaries end up in memory.
>>>
>>> In a slightly different context, I've talked to Simon in the past about
>>> building many separate binaries from U-Boot's source and chaining between
>>> them and merging them together and he objected to that approach. However, I
>>> wonder if this new requirement changes anything?
>>>
>>> Thanks for any thoughts.
>>
>>
>> This looks quite similar to efi runtime services requirements to me. Maybe
>> we can share code.
>>
>> The way those work is that we mark all functions and data required in
>> special sections too. We also include all relocations inside a special
>> section as well though.
>>
>> If you follow the same scheme, you could simply clone parts of U-Boot at
>> runtime with different relocations to either main U-Boot or mon. During that
>> relocation you could also find out if there is any relication that is
>> unreachable from mon code. That could trigger a warning that CI should be
>> able to quickly find.
>
>
> So we'd have the following chunks of code (lets say sections):
>
> 1) U-Boot only
> 2) Monitor (or UEFI) only
> 3) Shared code between 1 and 2.
>
> ... then memcpy (3) to two places, one for (1) and one for (2)?
>
> On the surface that seems plausible, but what happens if we have the
> following main chunks of code:
>
> 1) U-Boot
> 2) Monitor
> 3) UEFI
> 4) Something else.
>
> Now we either have a relatively large and bloated dumping ground for all
> common
Re: [U-Boot] [PATCH v8 14/30] efi: Don't build sandbox with __attribute__((ms_abi))
Hi Alex, On 25 June 2018 at 05:23, Alexander Graf wrote: > On 06/23/2018 04:16 PM, Simon Glass wrote: >> >> Hi Alex, >> >> On 23 June 2018 at 01:28, Alexander Graf wrote: >>> >>> >>> On 22.06.18 21:28, Simon Glass wrote: Hi Alex, On 22 June 2018 at 06:11, Alexander Graf wrote: > > On 06/21/2018 09:45 PM, Simon Glass wrote: >> >> Hi Alex, >> >> On 21 June 2018 at 03:59, Alexander Graf wrote: >>> >>> On 06/21/2018 04:02 AM, Simon Glass wrote: Hi Alex, On 20 June 2018 at 02:56, Alexander Graf wrote: > > On 06/20/2018 12:02 AM, Simon Glass wrote: >> >> Hi Alex, >> >> On 18 June 2018 at 08:46, Alexander Graf wrote: >>> >>> On 06/18/2018 04:08 PM, Simon Glass wrote: There appears to be a bug [1] in gcc when using varargs with this attribute. Disable it for sandbox so that functions which use that can work correctly, such as install_multiple_protocol_interfaces(). [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70955 Signed-off-by: Simon Glass >>> >>> >>> See my patch instead please. >> >> OK I see it now. Do you know what gcc fixes this problem? > > > The bug you found was really just a gcc bug that hit early gcc6 > versions. > I > doubt you're running into it :). OK, so in fact gcc does not support varargs problems with the ms_abi? >>> >>> >>> Gcc needs to know whether varargs are sysv varargs or ms varargs. And >>> it >>> differentiates between the two with different variable types for >>> va_list. >>> >> Have you seen the builtin_va_list, etc. > > > I think this sentence is missing content? I thought that builtin_va_list and friends would work regardless of the calling standard being used. But it looks (from your patch) like you have to explicitly use __builtin_ms_va_list. Is that right? >>> >>> I'm fairly sure builtin_va_list is just gcc's way of mapping the sysv >>> va_list, but I'm not 100% sure. I can double check with our compiler >>> people next week. >> >> OK looking forward to hearing. I'm not sure when the builtin came in, >> but if it has been around for a while, and it supports both calling >> standards, then it would be nice to use it. > > > So according to our toolchain people the builtin is really just the internal > gcc name for va_list, so it still adheres to the default calling ABI in its > semantics. > > Apparently what one *can* do is to add -mabi=ms to the compiler flags which > basically makes every function follow the ms abi. If that is set *maybe* > va_list will also adhere to it. > > However, both him and me like the explicit approach (of this patch) better. > > He also quickly explained why the function abi can't directly have an effect > on va_list. Basically at the parsing stage, gcc does not know if you want to > use a va_list for yourself or to pass it into a function you call. And > depending on that, you may want either a sysv abi va_list or an ms_abi > va_list. Eek that sounds complicated, but good to know. So it seems like your solution is the best option. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/3] doc: dtbinding: Add file system firmware loader binding document
Hi,
On 25 June 2018 at 07:28, wrote:
> From: Tien Fong Chee
>
> Add a document to describe file system firmware loader binding
> information.
>
> Signed-off-by: Tien Fong Chee
> ---
> doc/device-tree-bindings/chosen.txt | 22
> doc/device-tree-bindings/misc/fs_loader.txt | 52
> +
> 2 files changed, 74 insertions(+)
> create mode 100644 doc/device-tree-bindings/misc/fs_loader.txt
>
> diff --git a/doc/device-tree-bindings/chosen.txt
> b/doc/device-tree-bindings/chosen.txt
> index c96b8f7..738673c 100644
> --- a/doc/device-tree-bindings/chosen.txt
> +++ b/doc/device-tree-bindings/chosen.txt
> @@ -73,3 +73,25 @@ Example
> u-boot,spl-boot-order = "same-as-spl", ,
> "/sdhci@fe33";
> };
> };
> +
> +firmware-loader property
> +
> +Multiple file system firmware loader nodes could be defined in device trees
> for
> +multiple storage type and their default partition, then a property
> +"firmware-loader" can be used to pass default firmware loader
> +node(default storage type) to the firmware loader driver.
> +
> +Example
> +---
> +/ {
> + chosen {
> + firmware-loader = _loader0;
> + };
> +
> + fs_loader0: fs_loader@0 {
This should be :
> + fs_loader0: fs-loader@0 {
since hyphen is used for node and property names. Underscore is used
for phandles (so you have that correct).
> + u-boot,dm-pre-reloc;
> + compatible = "fs_loader";
How about u-boot,fs-loader since this is U-Boot specific I think.
> + storage_device = "mmc";
storage-device
> + devpart = "0:1";
I think you should use a phandle to the node containing the mmc device to use.
storage-device = <_3 1>;
for example (meaning use that MMC, partition 1.
> + };
> +};
> diff --git a/doc/device-tree-bindings/misc/fs_loader.txt
> b/doc/device-tree-bindings/misc/fs_loader.txt
> new file mode 100644
> index 000..78bea66
> --- /dev/null
> +++ b/doc/device-tree-bindings/misc/fs_loader.txt
> @@ -0,0 +1,52 @@
> +* File system firmware loader
> +
> +Required properties:
> +
> +
> +- compatible: should contain "fs_loader"
> +- storage_device: which storage device loading from, could be:
> + - mmc, usb, sata, and ubi.
> +- devpart: which storage device and partition the image loading from,
> + this property is required for mmc, usb and sata.
> +- mdtpart: which partition of ubi the image loading from, this property is
> + required for ubi.
> +- ubivol: which volume of ubi the image loading from, this proprety is
> required
> + for ubi.
> +
> +Example of storage device and partition search set for mmc, usb, sata and
> +ubi in device tree source as shown in below:
> +
> + Example of storage type and device partition search set for mmc, usb,
> + sata and ubi as shown in below:
> + Example for mmc:
> + fs_loader0: fs_loader@0 {
> + u-boot,dm-pre-reloc;
> + compatible = "fs_loader";
> + storage_device = "mmc";
> + devpart = "0:1";
> + };
> +
> + Example for usb:
> + fs_loader1: fs_loader@1 {
> + u-boot,dm-pre-reloc;
> + compatible = "fs_loader";
> + storage_device = "usb";
> + devpart = "0:1";
> + };
> +
> + Example for sata:
> + fs_loader2: fs_loader@2 {
> + u-boot,dm-pre-reloc;
> + compatible = "fs_loader";
> + storage_device = "sata";
> + devpart = "0:1";
> + };
> +
> + Example for ubi:
> + fs_loader3: fs_loader@3 {
> + u-boot,dm-pre-reloc;
> + compatible = "fs_loader";
> + storage_device = "ubi";
> + mtdpart = "UBI",
> + ubivol = "ubi0";
I'm not sure about ubi. It needs to refer to a particular device I
suppose. How do we know the mapping from ubi to device?
> + };
> --
> 2.2.0
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/3] Remove unused _relocate arguments
Hi Ivan, On Tue, Jun 26, 2018 at 2:12 AM, Ivan Gorinov wrote: > EFI image handle and system table are not used in _relocate(). > > v2: > Separated the changes in efi_main() arguments and calling convention. > > Ivan Gorinov (3): > x86: Remove unused _relocate arguments This does not apply cleanly on current u-boot/master. Can you please rebase this series? Applying: x86: Remove unused _relocate arguments error: patch failed: arch/x86/lib/reloc_ia32_efi.c:11 error: arch/x86/lib/reloc_ia32_efi.c: patch does not apply error: patch failed: arch/x86/lib/reloc_x86_64_efi.c:13 error: arch/x86/lib/reloc_x86_64_efi.c: patch does not apply Patch failed at 0001 x86: Remove unused _relocate arguments > arm: Remove unused _relocate arguments > riscv: Remove unused _relocate arguments > > arch/arm/lib/crt0_aarch64_efi.S | 2 -- > arch/arm/lib/crt0_arm_efi.S | 2 -- > arch/arm/lib/reloc_aarch64_efi.c | 3 +-- > arch/arm/lib/reloc_arm_efi.c | 3 +-- > arch/riscv/lib/reloc_riscv_efi.c | 3 +-- > arch/x86/lib/crt0_x86_64_efi.S | 3 --- > arch/x86/lib/reloc_ia32_efi.c| 3 +-- > arch/x86/lib/reloc_x86_64_efi.c | 3 +-- > 8 files changed, 5 insertions(+), 17 deletions(-) > Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 11/21] efi_loader: Introduce ms abi vararg helpers
Hi Alex, On Tue, Jun 26, 2018 at 12:47 AM, Alexander Graf wrote: > On 06/23/2018 10:37 AM, Bin Meng wrote: >> >> Hi Alex, >> >> On Thu, Jun 21, 2018 at 11:13 PM, Alexander Graf wrote: Varargs differ between sysv and ms abi. On x86_64 we have to follow the ms abi though, so we also need to make sure we use x86_64 varargs helpers. This patch introduces generic efi vararg helpers that adhere to the respective EFI ABI. That way we can deal with them properly from efi loader code and properly interpret variable arguments. This fixes the InstallMultipleProtocolInterfaces tests in the efi selftests on x86_64 for me. Signed-off-by: Alexander Graf >>> >>> Thanks, applied to efi-next >>> >> I applied this patch on my x86 tree and tested there, but >> qemu-x86_64_defconfig still fails when 'bootefi selftest'. Anything I >> am missing? > > > Where does it fail? There is basically this pitfall and setjmp/longjmp that > can easily go wrong. It just reboots without printing any error message. You can reproduce this in the latest u-boot/master. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Logo for U-Boot
On 06/25/2018 07:52 AM, Stefan Roese wrote: > On 24.06.2018 20:07, Simon Glass wrote: >> Hi Heinrich, >> >> On 11 June 2018 at 09:54, Heinrich Schuchardt wrote: >>> On 06/11/2018 03:03 PM, Tom Rini wrote: On Sat, Jun 09, 2018 at 10:21:53PM +0200, Heinrich Schuchardt wrote: > On 06/09/2018 07:34 PM, Simon Glass wrote: >> Hi, >> >> On 6 May 2018 at 12:31, Tom Rini wrote: >>> On Sun, May 06, 2018 at 09:49:42PM +0200, Alexander Graf wrote: >>> On 06.05.18 18:02, Heinrich Schuchardt wrote: > On 05/04/2018 11:18 AM, Marek Vasut wrote: >> On 05/04/2018 08:46 AM, Alexander Graf wrote: >>> On 05/04/2018 01:04 AM, Marek Vasut wrote: On 05/03/2018 11:57 PM, Alexander Graf wrote: > > On 01.05.18 04:09, Marek Vasut wrote: >> On 04/30/2018 08:22 PM, Heinrich Schuchardt wrote: >>> U-Boot has currently no logo that we can use in >>> presentations. >>> >>> On the U-Boot IRC channel the following propositions >>> where made: >>> >>> Source: >>> https://commons.wikimedia.org/wiki/File:Circle-icons-submarine.svg >>> >>> License: GPL2+ >>> (Alex used this in some presentations.) >> Yellow submarine, nice. >> >> Maybe we should make it a bit more toward teal and orange >> to improve >> the >> contrast ? Although, maybe just replacing the depressive gray >> background >> with a light blue one would do. > How about this? > > http://csgraf.de/tmp2/uboot.svg Lacks the teal. >>> >>> >>> I don't want teal :) >> >> Without teal, the contrast of the image isn't good enough. >> >> And I think you might want to check with more people, since >> clearly it's >> just the two of us discussing it now :) > Find Marek's darling appended >>> >>> It's a little hard to quote things inline like this. But, did you >>> create your own image inspired by the wikimedia one? I ask >>> because the >>> wikimedia one is GPLv2 or later, but an original one that we >>> could dual >>> license (for both a new framebuffer logo, and for printed materials, >>> etc, where a CC license works better) would be good. >>> I tend to agree that it looks nice :). It may mean we need a new web design too though, as the colors in the logo probably don't work terribly well with the current blue. >>> >>> We can worry about that later. >> >> I think the logo as here is fine: >> >> https://www.xypron.de/projects/u-boot/images/Circle-icons-submarine-orange-teal.svg >> > > This logo was GPLv2+. Tom, didn't you say we needed something with > creative commons license? So, while I'm Not A Lawyer(TM), there is a reason lawyers have made licenses that are still "open source" but for other things. One of the uses of a logo is to be printed. What on earth does GPLv2 (or later) compliance look like for a brochure or a t-shirt? That's not the (usual) spirit behind why you would put a license like that on a thing like this. This is why currently projects use one of the Creative Commons 4.0 licenses for images, hardware design, etc. And further pushing my "not a lawyer", it's generally accepted that you can go from CC-4.0 to GPLv3 (or later), you can't go the other direction. And I'd also really rather not put people that want to use our logo in the position of worrying about what GPLv2 compliance on an image looks like (as it's not clear), I'm strongly in favor of a CC'd image. If anyone can contact the actual author of the wikimedia image (it's not the person that uploaded it, I dug that far) and have them agree to re-license as CC, I'd be happy to go that route. Thanks! >>> >>> I have raised that question on: >>> >>> https://commons.wikimedia.org/wiki/User_talk:CFCF#Circle-icons-submarine.svg >>> >> >> It looks like the answer was not what you needed, or perhaps I am >> reading it incorrectly? >> >> Here are two versions, both with 'U-Boot' text inside the logo. I >> think this is important since otherwise the logo could be for >> anything. > > Yes, i agree. The text should be added. > >> https://drive.google.com/open?id=1TdX0JS_Zr6ZGtUt6F-6y8rUv2Hq2QlOp >> >> https://drive.google.com/open?id=1UxMY67es8OGIDMST-3G0Pc0aTjbasxTY > > I'm in favor of the 2nd version with the complete text. I vote for the first version or even version without text. Icons with text are so 90ies :) -- Best regards, Marek Vasut ___ U-Boot mailing list
Re: [U-Boot] Pull request: u-boot-spi/master
On Tue, Jun 26, 2018 at 12:19:03AM +0530, Jagan Teki wrote: > Hi Tom, > > Please pull this PR. > > thanks, > Jagan. > > The following changes since commit 77b5ba5d2b94c5b028991c82782493f64bd4f392: > > Merge branch 'master' of git://git.denx.de/u-boot-uniphier (2018-06-22 > 13:12:53 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-spi.git master > > for you to fetch changes up to 51dce7d2bfdecd974412634e4a0758ac55edcc00: > > mtd: spi: Correct parameters for s25fs512s flash (2018-06-25 15:50:33 +0530) > > > Ashish Kumar (1): > mtd: spi: Correct parameters for s25fs512s flash > > Hannes Schmelzer (2): > spi: omap3: pre-initialize bus-speed with max. slave-speed > spi: omap3: fix set_speed and set_mode dm callbacks > > Michael Trimarchi (2): > spi: mxc: Fix compilation problem of DM_SPI class driver > spi: mxc_spi: Fix chipselect on DM_SPI driver uclass > > Vipul Kumar (1): > spi: zynq_qspi: Fixed incorrect return value error I thought we had a change or two from Marek that were bug fixes that should be brought in? Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ubifs: avoid memory corruption during ubifsmount
Patrice, Am Montag, 25. Juni 2018, 13:54:12 CEST schrieb Patrice Chotard: > Sometimes, at boot time, following issue appears: > Error reading superblock on volume 'ubi0:boot' errno=-22! > > This error is coming from wrong ubi_num and wrong ubi_id in the superblock. > (ubi_num = -1 and vol_id = -1). > It appears that following line in sget function: > hlist_add_head(>s_instances, >fs_supers); > corrupts the superblock structure. Hmm, how can hlist_add_head() corrupt the structure? This seems fishy to me, I fear that this is not the root cause of the problem you are facing. > By checking ubifs source code, s_instances parameter is not used anymore. > So, by setting this parameter and the associated source code under > __UBOOT__ compilation switch solves this issue. Yes, we can clean up this. But as I said, we need to dig deeper to explain the corruption you see. Thanks, //richard ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Sharing code between U-Boot and its secure monitor
On 06/24/2018 12:17 AM, Alexander Graf wrote:
Am 22.06.2018 um 21:24 schrieb Stephen Warren :
I am writing more secure monitor (PSCI) support for Jetson TK1. In particular, this code
will support resume from the LP0 system suspend state, which entails signing a block of
code for the boot ROM to validate during resume. The signing code uses lib/aes.c. This
code is linked into U-Boot in the "main" part of U-Boot, rather than into the
secure section that contains the monitor code. The monitor should only call code within
the monitor section, not within the main part of U-Boot (in general, the monitor
continues to run after U-Boot has been replaced in RAM, so cannot call code in U-Boot
since it may no longer exist, and even if it does, that code is not in the secure DRAM
carve-out, and hence it's not secure to call it). So, I need to duplicate the lib/aes.c
object code into the monitor. The question is: what's the best way to do that.
So far, here's what I implemented:
a) Edit lib/aes.c to mark each function with an optional attribute which will
force the object code into the secure section when compiled for the monitor:
-static const u8 sbox[256] = {
+static const u8 mon_rodata sbox[256] = {
-void aes_cbc_decrypt_blocks(...
+void mon_text aes_cbc_decrypt_blocks(...
... where mon_text evaluates to:
+#define mon_rodata
+#define mon_text
or:
+#define mon_data__attribute__((section("._secure.data")))
+#define mon_rodata__attribute__((section("._secure.rodata")))
+#define mon_text__attribute__((section("._secure.text")))
Please check my recent fix to rename the efi sections. Gcc may under some
conditions generate implicit symbols, such as rodata constants. You can only
catch them if your text section for the function starts with .text.
b) Since the main U-Boot and the monitor code are part of the same ELF file,
the same symbol name cannot exist in both. So, we must play similar games in
order to rename the symbols:
-void aes_cbc_decrypt_blocks(...
+void mon_text MON_SYM(aes_cbc_decrypt_blocks)(...
(all call sites have to be updated similarly)
... where MON_SYM(x) is either:
+#define MON_SYM(x) x
or:
+#define MON_SYM(x) mon_##x
c) In the monitor, create a file mon_aes.c that sets up all the macros
mentioned above, then #includes the main lib/aes.c. Add this file to a Makefile.
+#include "mon_section.h"
+#include "../../../../../lib/aes.c"
This is all rather nasty and invasive, especially when you consider more widely
used utility functions such as malloc(), printf(), udelay(), etc.. Instead, I
wonder if we can:
a) Link the monitor to an ELF file and extract a binary. We won't need any
special section or symbol name logic here, since we can assume that all of
.text/.data are part of the monitor. Simple and non-invasive!
b) Link the LP0 resume code to an ELF file and extract a binary. (It's nice to
separate this block of code since it runs on a different CPU to the main U-Boot
or monitor, and hence gets compiled with different compiler flags).
c) Include the binaries from (a) and (b) above in the main U-Boot ELF file or
binary somehow; perhaps use binman to allow the main U-Boot to know where those
merged binaries end up in memory.
In a slightly different context, I've talked to Simon in the past about
building many separate binaries from U-Boot's source and chaining between them
and merging them together and he objected to that approach. However, I wonder
if this new requirement changes anything?
Thanks for any thoughts.
This looks quite similar to efi runtime services requirements to me. Maybe we
can share code.
The way those work is that we mark all functions and data required in special
sections too. We also include all relocations inside a special section as well
though.
If you follow the same scheme, you could simply clone parts of U-Boot at
runtime with different relocations to either main U-Boot or mon. During that
relocation you could also find out if there is any relication that is
unreachable from mon code. That could trigger a warning that CI should be able
to quickly find.
So we'd have the following chunks of code (lets say sections):
1) U-Boot only
2) Monitor (or UEFI) only
3) Shared code between 1 and 2.
... then memcpy (3) to two places, one for (1) and one for (2)?
On the surface that seems plausible, but what happens if we have the
following main chunks of code:
1) U-Boot
2) Monitor
3) UEFI
4) Something else.
Now we either have a relatively large and bloated dumping ground for all
common code:
5) Common code, which gets copied 4 other places, and contains many
functions some of the copy targets don't need.
... or many combinations:
5) Code shared between 1, 2, 3, 4
6) Code shared between 1, 2, 3
7) Code shared between 1, 2, 4
8) Code shared between 1, 3, 4
...
Or a per-function section and the relocator iterates over each
per-function section separately, and works out which of 1..4 it gets
copied
Re: [U-Boot] [RFC PATCH 00/20] SPI-NAND support
On Mon, Jun 25, 2018 at 09:58:39PM +0200, Boris Brezillon wrote: > On Tue, 26 Jun 2018 00:07:10 +0530 > Jagan Teki wrote: > > > >> I think I have to repeat my previous statement here. It would be very > > >> unfortunate if u-boot decides to take this direction (see Richard's > > >> reply), especially since I see absolutely no benefit in doing what you > > >> suggest. Having MTD devices registered to the uboot DM is something I > > >> can understand, deciding to no longer support the standard MTD API is > > >> something I don't. > > > > > I agree. We want U-Boot to be able to leverage as much as possible from > > > the Linux kernel with as little re-working as possible. > > > > I'm not denying that, but the basic design flow must follow u-boot > > driver model. this is what everyone told from the beginning when I > > started spi-nor work. Initially I did the design like this and > > leverage with existing MTD, everyone NAK and suggested to use > > driver-model on each stage with MTD dm abstraction. > > So > > - After 2 years of work > > - With nearly 10 versions [4] > > - Adding MIGRATION expire date for spi drivers dm conversion > > - Simon Reviewed-by and > > - Planning to apply after v2018.09. > > > > but now all want the existing MTD, I don't understand what I can do > > further on this? > > I didn't follow the initial discussion, but I can understand your > frustration. Still, I think there's a misunderstanding here. I recommend > that you have a second look at the different patches in this series. > You'll see that everything Miquel did complies with the DM, and that > the thing you're complaining about (MTD API not using udevice and not > prefixed with dm_) is just a tiny detail compared to the rest. > > Keeping the MTD API is not incompatible with the conversion of > all MTD provider drivers to the DM. I think we all agree on that MTD > providers should be converted to the DM progressively, and the work > Miquel did allows such a smooth transition because both non-DM drivers > and DM-compliant drivers can co-exist without impacting MTD users. > > Sorry to say that, but your approach based on full-conversion is just an > utopia. There's no way we can do that in a single step. > > So the question here is more, should we block all developments until we > have a perfect solution (I don't think perfection can be achieved > without trying things and making mistake), or should we move forward, > one step after the other and keep the "conversion of all MTD > drivers to the DM" as a long term goal? And furthermore, we _really_ need to get this area un-blocked. I feel bad that Jagan's series went on for so long, but I think it also highlights the problem with a convert-everything-at-once-try-and-be-perfect approach. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 00/20] SPI-NAND support
On Tue, 26 Jun 2018 00:07:10 +0530 Jagan Teki wrote: > >> I think I have to repeat my previous statement here. It would be very > >> unfortunate if u-boot decides to take this direction (see Richard's > >> reply), especially since I see absolutely no benefit in doing what you > >> suggest. Having MTD devices registered to the uboot DM is something I > >> can understand, deciding to no longer support the standard MTD API is > >> something I don't. > > > I agree. We want U-Boot to be able to leverage as much as possible from > > the Linux kernel with as little re-working as possible. > > I'm not denying that, but the basic design flow must follow u-boot > driver model. this is what everyone told from the beginning when I > started spi-nor work. Initially I did the design like this and > leverage with existing MTD, everyone NAK and suggested to use > driver-model on each stage with MTD dm abstraction. > So > - After 2 years of work > - With nearly 10 versions [4] > - Adding MIGRATION expire date for spi drivers dm conversion > - Simon Reviewed-by and > - Planning to apply after v2018.09. > > but now all want the existing MTD, I don't understand what I can do > further on this? I didn't follow the initial discussion, but I can understand your frustration. Still, I think there's a misunderstanding here. I recommend that you have a second look at the different patches in this series. You'll see that everything Miquel did complies with the DM, and that the thing you're complaining about (MTD API not using udevice and not prefixed with dm_) is just a tiny detail compared to the rest. Keeping the MTD API is not incompatible with the conversion of all MTD provider drivers to the DM. I think we all agree on that MTD providers should be converted to the DM progressively, and the work Miquel did allows such a smooth transition because both non-DM drivers and DM-compliant drivers can co-exist without impacting MTD users. Sorry to say that, but your approach based on full-conversion is just an utopia. There's no way we can do that in a single step. So the question here is more, should we block all developments until we have a perfect solution (I don't think perfection can be achieved without trying things and making mistake), or should we move forward, one step after the other and keep the "conversion of all MTD drivers to the DM" as a long term goal? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Pull request: u-boot-spi/master
Hi Tom, Please pull this PR. thanks, Jagan. The following changes since commit 77b5ba5d2b94c5b028991c82782493f64bd4f392: Merge branch 'master' of git://git.denx.de/u-boot-uniphier (2018-06-22 13:12:53 -0400) are available in the Git repository at: git://git.denx.de/u-boot-spi.git master for you to fetch changes up to 51dce7d2bfdecd974412634e4a0758ac55edcc00: mtd: spi: Correct parameters for s25fs512s flash (2018-06-25 15:50:33 +0530) Ashish Kumar (1): mtd: spi: Correct parameters for s25fs512s flash Hannes Schmelzer (2): spi: omap3: pre-initialize bus-speed with max. slave-speed spi: omap3: fix set_speed and set_mode dm callbacks Michael Trimarchi (2): spi: mxc: Fix compilation problem of DM_SPI class driver spi: mxc_spi: Fix chipselect on DM_SPI driver uclass Vipul Kumar (1): spi: zynq_qspi: Fixed incorrect return value error drivers/mtd/spi/spi_flash_ids.c | 2 +- drivers/spi/mxc_spi.c | 8 drivers/spi/omap3_spi.c | 18 -- drivers/spi/zynq_qspi.c | 2 +- 4 files changed, 14 insertions(+), 16 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [Question] uclass to be used for SoC devices
On Mon, Jun 25, 2018 at 7:32 PM, Grygorii Strashko wrote: > Hi All, > > I have question about uclass to be used for SoC devices (./drivers/soc/). > Now there is only ./drivers/soc/keystone/keystone_serdes.c which is not DM > converted, > but we are going to add more drivers for SoC specific components soon and > internally I've used UCLASS_MISC for now. Is it acceptable? > Or new uclass need to be introduced, like UCLASS_SOC The QCom smem driver [1] is based on a kernel drivers/soc driver, you might want to check some of the threads around that for some initial discussion. [1] https://lists.denx.de/pipermail/u-boot/2018-June/332578.html ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd:spi: Correct parameters for s25fs512s flash
On Mon, Jun 25, 2018 at 3:45 PM, Ashish Kumar wrote: > Change sector size to 256KiB in table spi_flash_ids. > > Signed-off-by: Ashish Kumar > --- Applied to u-boot-spi/master ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 00/20] SPI-NAND support
On Mon, Jun 25, 2018 at 8:25 PM, Tom Rini wrote: > On Mon, Jun 25, 2018 at 04:46:56PM +0200, Boris Brezillon wrote: >> On Mon, 25 Jun 2018 19:58:37 +0530 >> Jagan Teki wrote: >> >> > >>> - convert fsl-qspi to spi-mem >> > >> >> > >> We're not targeting the fsl-qspi controller here but a simple SPI >> > >> controller that is already upstreamed. But yes, the fsl-qspi driver >> > >> will have to be patched to support the spi-mem interface at some point. >> > > >> > > Can you point me that simple spi-mem controller driver? >> >> It's not a controller that implements spi-mem operations but a simple >> SPI controller (one that knows how to do regular SPI transfers and >> nothing more). But the spi-mem layer knows how to send spi_mem_op using >> regular transfer and that's why it works without any modification at >> the driver level. >> >> >> > >>> >> > >>> For spi-nor interface design, we have an example code here[2] >> > >>> >> > >>> I've paused this [2] series because of dm conversion of spi-drivers >> > >>> otherwise I need add legacy code like mmc-legacy.c, so if we really >> > >>> move to spi-mem design and okay with above design. I will try to move >> > >>> the current spi flash to add MTD driver-model so-that we can add >> > >>> spi-mem, spi-nand on top of it or we can work together to convert them >> > >>> all. >> > >> >> > >> Why can't we do things iteratively. I mean, if the long term goal is to >> > >> convert everything to the driver model, then this patchset is going in >> > >> the right direction: >> > >> - addition of DM helpers to the MTD_UCLASS >> > >> - addition of the spi-mem interface properly integrated in the DM >> > >>model of the SPI framework >> > >> - addition of a SPI NAND driver, again properly integrated in the DM >> > >> - integration of DM-ready MTD drivers and old MTD drivers in a single >> > >>view exposed by the cmd/mtd.c command set >> > >> >> > >> I'd really like to limit the scope of this development to these topics, >> > >> which doesn't prevent you from converting other part of u-boot to the >> > >> spi-mem approach (SPI NOR is one example). >> > >> >> > >> I hope you understand our concerns and the fact that what you're asking >> > >> us to do as a dependency of getting SPI NAND support + cmd/mtd.c merged >> > >> is way more than we can actually provide. >> > > >> > > To answer all these questions, I think we need to decide whether we go >> > > for MTD dm abstraction or existing MTD layer. >> > > >> > > When I say MTD dm abstraction, all mtd operation prototypes are in the >> > > form of udevice unlike existing MTD has mtd_info. when I initially >> > > supporting spi-nor (during Linux early spi-nor) I've reused existing >> > > MTD and written something like what Miquel did using mtd_info ops [3]. >> > > but then developers on ML, proposed the new drivers should be form of >> > > driver-model abstraction, so I've added mtd driver model ops [4]. >> > > >> > > I understand the new MTD dm abstraction in U-Boot is not possible for >> > > direct syncing from Linux, but we really want the u-boot way of >> > > handling drivers and trying to copy code from Linux by removing >> > > __UBOOT__ or any Linux specific macros. Since this is pretty much big >> > > task, ie the reason I'm asking for single driver from each MTD device >> > > so-that once the clear stack is ready other drivers can convert >> > > one-by-one. >> >> I think I have to repeat my previous statement here. It would be very >> unfortunate if u-boot decides to take this direction (see Richard's >> reply), especially since I see absolutely no benefit in doing what you >> suggest. Having MTD devices registered to the uboot DM is something I >> can understand, deciding to no longer support the standard MTD API is >> something I don't. > > I agree. We want U-Boot to be able to leverage as much as possible from > the Linux kernel with as little re-working as possible. I'm not denying that, but the basic design flow must follow u-boot driver model. this is what everyone told from the beginning when I started spi-nor work. Initially I did the design like this and leverage with existing MTD, everyone NAK and suggested to use driver-model on each stage with MTD dm abstraction. So - After 2 years of work - With nearly 10 versions [4] - Adding MIGRATION expire date for spi drivers dm conversion - Simon Reviewed-by and - Planning to apply after v2018.09. but now all want the existing MTD, I don't understand what I can do further on this? [4] https://patchwork.ozlabs.org/user/todo/uboot/?series=20450 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [Question] uclass to be used for SoC devices
Hi All, I have question about uclass to be used for SoC devices (./drivers/soc/). Now there is only ./drivers/soc/keystone/keystone_serdes.c which is not DM converted, but we are going to add more drivers for SoC specific components soon and internally I've used UCLASS_MISC for now. Is it acceptable? Or new uclass need to be introduced, like UCLASS_SOC -- regards, -grygorii ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/3] arm: Remove unused _relocate arguments
EFI image handle and system table are not used in _relocate().
Signed-off-by: Ivan Gorinov
---
arch/arm/lib/crt0_aarch64_efi.S | 2 --
arch/arm/lib/crt0_arm_efi.S | 2 --
arch/arm/lib/reloc_aarch64_efi.c | 3 +--
arch/arm/lib/reloc_arm_efi.c | 3 +--
4 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/arm/lib/crt0_aarch64_efi.S b/arch/arm/lib/crt0_aarch64_efi.S
index 5b6c384..0db4360 100644
--- a/arch/arm/lib/crt0_aarch64_efi.S
+++ b/arch/arm/lib/crt0_aarch64_efi.S
@@ -122,8 +122,6 @@ _start:
mov x29, sp
stp x0, x1, [sp, #16]
- mov x2, x0
- mov x3, x1
adr x0, ImageBase
adrpx1, _DYNAMIC
add x1, x1, #:lo12:_DYNAMIC
diff --git a/arch/arm/lib/crt0_arm_efi.S b/arch/arm/lib/crt0_arm_efi.S
index 0f296f3..23db49f 100644
--- a/arch/arm/lib/crt0_arm_efi.S
+++ b/arch/arm/lib/crt0_arm_efi.S
@@ -119,8 +119,6 @@ section_table:
_start:
stmfd sp!, {r0-r2, lr}
- mov r2, r0
- mov r3, r1
adr r1, .L_DYNAMIC
ldr r0, [r1]
add r1, r0, r1
diff --git a/arch/arm/lib/reloc_aarch64_efi.c b/arch/arm/lib/reloc_aarch64_efi.c
index 38c13d3..1cf5cdc 100644
--- a/arch/arm/lib/reloc_aarch64_efi.c
+++ b/arch/arm/lib/reloc_aarch64_efi.c
@@ -38,8 +38,7 @@
#include
-efi_status_t _relocate(long ldbase, Elf64_Dyn *dyn, efi_handle_t image,
- struct efi_system_table *systab)
+efi_status_t _relocate(long ldbase, Elf64_Dyn *dyn)
{
long relsz = 0, relent = 0;
Elf64_Rela *rel = 0;
diff --git a/arch/arm/lib/reloc_arm_efi.c b/arch/arm/lib/reloc_arm_efi.c
index 6232e3f..336a98a 100644
--- a/arch/arm/lib/reloc_arm_efi.c
+++ b/arch/arm/lib/reloc_arm_efi.c
@@ -14,8 +14,7 @@
#include
#include
-efi_status_t _relocate(long ldbase, Elf32_Dyn *dyn, efi_handle_t image,
- struct efi_system_table *systab)
+efi_status_t _relocate(long ldbase, Elf32_Dyn *dyn)
{
long relsz = 0, relent = 0;
Elf32_Rel *rel = 0;
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 3/3] riscv: Remove unused _relocate arguments
EFI image handle and system table are not used in _relocate().
Signed-off-by: Ivan Gorinov
---
arch/riscv/lib/reloc_riscv_efi.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/riscv/lib/reloc_riscv_efi.c b/arch/riscv/lib/reloc_riscv_efi.c
index 8b4b2b1..2fbbfcb 100644
--- a/arch/riscv/lib/reloc_riscv_efi.c
+++ b/arch/riscv/lib/reloc_riscv_efi.c
@@ -50,8 +50,7 @@
#define ELF_R_TYPE ELF32_R_TYPE
#endif
-efi_status_t _relocate(long ldbase, Elf_Dyn *dyn, efi_handle_t image,
- struct efi_system_table *systab)
+efi_status_t _relocate(long ldbase, Elf_Dyn *dyn)
{
long relsz = 0, relent = 0;
Elf_Rela *rel = 0;
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/3] x86: Remove unused _relocate arguments
EFI image handle and system table are not used in _relocate().
Signed-off-by: Ivan Gorinov
---
arch/x86/lib/crt0_x86_64_efi.S | 3 ---
arch/x86/lib/reloc_ia32_efi.c | 3 +--
arch/x86/lib/reloc_x86_64_efi.c | 3 +--
3 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/arch/x86/lib/crt0_x86_64_efi.S b/arch/x86/lib/crt0_x86_64_efi.S
index bb8d3cf..47ed5af 100644
--- a/arch/x86/lib/crt0_x86_64_efi.S
+++ b/arch/x86/lib/crt0_x86_64_efi.S
@@ -18,9 +18,6 @@ _start:
pushq %rcx
pushq %rdx
- mov %rcx, %r8
- mov %rdx, %r9
-
lea image_base(%rip), %rcx
lea _DYNAMIC(%rip), %rdx
diff --git a/arch/x86/lib/reloc_ia32_efi.c b/arch/x86/lib/reloc_ia32_efi.c
index f0bd2db..4fb0e56 100644
--- a/arch/x86/lib/reloc_ia32_efi.c
+++ b/arch/x86/lib/reloc_ia32_efi.c
@@ -11,8 +11,7 @@
#include
#include
-efi_status_t _relocate(long ldbase, Elf32_Dyn *dyn, efi_handle_t image,
- struct efi_system_table *systab)
+efi_status_t _relocate(long ldbase, Elf32_Dyn *dyn)
{
long relsz = 0, relent = 0;
Elf32_Rel *rel = 0;
diff --git a/arch/x86/lib/reloc_x86_64_efi.c b/arch/x86/lib/reloc_x86_64_efi.c
index adc80ea..9361235 100644
--- a/arch/x86/lib/reloc_x86_64_efi.c
+++ b/arch/x86/lib/reloc_x86_64_efi.c
@@ -13,8 +13,7 @@
#include
#include
-efi_status_t _relocate(long ldbase, Elf64_Dyn *dyn, efi_handle_t image,
- struct efi_system_table *systab)
+efi_status_t _relocate(long ldbase, Elf64_Dyn *dyn)
{
long relsz = 0, relent = 0;
Elf64_Rel *rel = 0;
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/3] Remove unused _relocate arguments
EFI image handle and system table are not used in _relocate(). v2: Separated the changes in efi_main() arguments and calling convention. Ivan Gorinov (3): x86: Remove unused _relocate arguments arm: Remove unused _relocate arguments riscv: Remove unused _relocate arguments arch/arm/lib/crt0_aarch64_efi.S | 2 -- arch/arm/lib/crt0_arm_efi.S | 2 -- arch/arm/lib/reloc_aarch64_efi.c | 3 +-- arch/arm/lib/reloc_arm_efi.c | 3 +-- arch/riscv/lib/reloc_riscv_efi.c | 3 +-- arch/x86/lib/crt0_x86_64_efi.S | 3 --- arch/x86/lib/reloc_ia32_efi.c| 3 +-- arch/x86/lib/reloc_x86_64_efi.c | 3 +-- 8 files changed, 5 insertions(+), 17 deletions(-) -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] net: mv88e61xx: add configuration for RGMII delay
On Mon, Jun 25, 2018 at 5:34 AM, Chris Packham wrote:
> Some hardware designs connect a CPU MAC directly to the RGMII interface
> of a mv88e61xx device. On such devices a delay on the RX/TX lines is
> required, this can either be achieved by adding extra length to the
> traces on the PCB or by implementing the delay in silicon. This is
> an implementation of the latter.
>
> Signed-off-by: Chris Packham
> ---
>
> drivers/net/phy/Kconfig | 4
> drivers/net/phy/mv88e61xx.c | 26 ++
> 2 files changed, 30 insertions(+)
>
> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> index f5821dfed96d..98cd57eea977 100644
> --- a/drivers/net/phy/Kconfig
> +++ b/drivers/net/phy/Kconfig
> @@ -59,6 +59,10 @@ config MV88E61XX_PHY_PORTS
> config MV88E61XX_FIXED_PORTS
> hex "Bitmask of PHYless serdes Ports"
>
> +config MV88E61XX_RGMII_DELAY
> + bool "Add delay to RGMII outputs"
> + default n
Not sure why you would need this line. default n is implied, no?
> +
> endif # MV88E61XX_SWITCH
>
> config PHYLIB_10G
> diff --git a/drivers/net/phy/mv88e61xx.c b/drivers/net/phy/mv88e61xx.c
> index ea54a1531053..d258ba1ef0f3 100644
> --- a/drivers/net/phy/mv88e61xx.c
> +++ b/drivers/net/phy/mv88e61xx.c
> @@ -69,6 +69,7 @@
> #define PORT_REG_CTRL 0x04
> #define PORT_REG_VLAN_MAP 0x06
> #define PORT_REG_VLAN_ID 0x07
> +#define PORT_REG_RGMII_TIMING 0x1A
>
> /* Phy registers */
> #define PHY_REG_CTRL1 0x10
> @@ -122,6 +123,9 @@
> #define PORT_REG_VLAN_MAP_TABLE_SHIFT 0
> #define PORT_REG_VLAN_MAP_TABLE_WIDTH 11
>
> +#define PORT_REG_RGMII_TIMING_RX_DELAY BIT(10)
> +#define PORT_REG_RGMII_TIMING_TX_DELAY BIT(9)
> +
> #define SERDES_REG_CTRL_1_FORCE_LINK BIT(10)
>
> #define PHY_REG_CTRL1_ENERGY_DET_SHIFT 8
> @@ -705,6 +709,24 @@ unforce:
> return res;
> }
>
> +static int mv88e61xx_rgmii_timing_cfg(struct phy_device *phydev)
> +{
> +#ifdef CONFIG_MV88E61XX_RGMII_DELAY
It seems like this would be more appropriate as a device tree property
rather than a board config.
> + int val;
> +
> + val = mv88e61xx_port_read(phydev, 6, PORT_REG_RGMII_TIMING);
> + if (val < 0)
> + return val;
> +
> + val |= PORT_REG_RGMII_TIMING_RX_DELAY |
> + PORT_REG_RGMII_TIMING_TX_DELAY;
> +
> + return mv88e61xx_port_write(phydev, 6, PORT_REG_RGMII_TIMING, val);
> +#else
> + return 0;
> +#endif
> +}
> +
> static int mv88e61xx_fixed_port_setup(struct phy_device *phydev, u8 port)
> {
> int val;
> @@ -774,6 +796,10 @@ static int mv88e61xx_set_cpu_port(struct phy_device
> *phydev)
> return val;
> }
> } else {
> + val = mv88e61xx_rgmii_timing_cfg(phydev);
> + if (val < 0)
> + return val;
> +
> val = mv88e61xx_fixed_port_setup(phydev,
> CONFIG_MV88E61XX_CPU_PORT);
> if (val < 0)
> --
> 2.18.0
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 02/13] sunxi: add basical memory map definitions of H6 SoC
On Mon, Jun 25, 2018 at 08:50:08PM +0800, Icenowy Zheng wrote: > > > 于 2018年6月25日 GMT+08:00 下午8:33:34, Maxime Ripard > 写到: > >On Mon, Jun 25, 2018 at 06:37:12PM +0800, Icenowy Zheng wrote: > >> The Allwinner H6 SoC come with a totally new memory map. > >> > >> Add basical definition of the new memory map into a header file, and > >let > >> the cpu.h header include it in the situation of H6. > >> > >> Signed-off-by: Icenowy Zheng > >> --- > >> arch/arm/include/asm/arch-sunxi/cpu.h | 2 + > >> .../include/asm/arch-sunxi/cpu_sun50i_h6.h| 73 > >+++ > >> 2 files changed, 75 insertions(+) > >> create mode 100644 arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h > >> > >> diff --git a/arch/arm/include/asm/arch-sunxi/cpu.h > >b/arch/arm/include/asm/arch-sunxi/cpu.h > >> index caec865264..08be963e8e 100644 > >> --- a/arch/arm/include/asm/arch-sunxi/cpu.h > >> +++ b/arch/arm/include/asm/arch-sunxi/cpu.h > >> @@ -9,6 +9,8 @@ > >> > >> #if defined(CONFIG_MACH_SUN9I) > >> #include > >> +#elif defined(CONFIG_MACH_SUN50I_H6) > >> +#include > >> #else > >> #include > >> #endif > >> diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h > >b/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h > >> new file mode 100644 > >> index 00..b12f2dd1a2 > >> --- /dev/null > >> +++ b/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h > >> @@ -0,0 +1,73 @@ > >> +/* > >> + * (C) Copyright 2017 Icenowy Zheng > >> + * > >> + * SPDX-License-Identifier: GPL-2.0+ > >> + */ > >> + > >> +#ifndef _SUNXI_CPU_SUN50I_H6_H > >> +#define _SUNXI_CPU_SUN50I_H6_H > >> + > >> +#define SUNXI_SRAM_A1_BASE0x0002 > > > >Isn't that the same thing than SUNXI_SRAM_ADDRESS? Having it defined > >twice and expecting the value to be matching seems a bit weird. > > This assumes SPL will be in SRAM A1, which may change. Then let's deal with this when it will change. Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 11/21] efi_loader: Introduce ms abi vararg helpers
On 06/23/2018 10:37 AM, Bin Meng wrote: Hi Alex, On Thu, Jun 21, 2018 at 11:13 PM, Alexander Graf wrote: Varargs differ between sysv and ms abi. On x86_64 we have to follow the ms abi though, so we also need to make sure we use x86_64 varargs helpers. This patch introduces generic efi vararg helpers that adhere to the respective EFI ABI. That way we can deal with them properly from efi loader code and properly interpret variable arguments. This fixes the InstallMultipleProtocolInterfaces tests in the efi selftests on x86_64 for me. Signed-off-by: Alexander Graf Thanks, applied to efi-next I applied this patch on my x86 tree and tested there, but qemu-x86_64_defconfig still fails when 'bootefi selftest'. Anything I am missing? Where does it fail? There is basically this pitfall and setjmp/longjmp that can easily go wrong. Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] x86: doc: Update EFI loader support
On 06/23/2018 12:03 PM, Bin Meng wrote: CONFIG_EFI_LOADER is fully supported on x86 now. Signed-off-by: Bin Meng Reviewed-by: Alexander Graf Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] doc: vxworks: Mention chain-loading an x86 kernel via 'bootefi'
On 06/23/2018 12:03 PM, Bin Meng wrote: This updates the doc to mention chain-loading an x86 kernel via 'bootefi' command, along with several typos fix. Signed-off-by: Bin Meng Reviewed-by: Alexander Graf Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] efi_loader: Install ACPI configuration tables
On 06/24/2018 12:12 PM, Heinrich Schuchardt wrote:
/On 06/23/2018 12:03 PM, Bin Meng wrote:
ACPI tables can be passed via EFI configuration table to an EFI
application. This is only supported on x86 so far.
Signed-off-by: Bin Meng
---
cmd/bootefi.c | 5 +
include/efi_api.h | 8
include/efi_loader.h | 8
lib/efi_loader/Makefile | 1 +
lib/efi_loader/efi_acpi.c | 42 ++
5 files changed, 64 insertions(+)
create mode 100644 lib/efi_loader/efi_acpi.c
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index f55a40d..cd755b6 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -61,6 +61,11 @@ efi_status_t efi_init_obj_list(void)
if (ret != EFI_SUCCESS)
goto out;
#endif
+#ifdef CONFIG_GENERATE_ACPI_TABLE
+ ret = efi_acpi_register();
+ if (ret != EFI_SUCCESS)
+ goto out;
+#endif
#ifdef CONFIG_GENERATE_SMBIOS_TABLE
ret = efi_smbios_register();
if (ret != EFI_SUCCESS)
diff --git a/include/efi_api.h b/include/efi_api.h
index 094be6e..69dcbac 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -286,6 +286,14 @@ struct efi_runtime_services {
EFI_GUID(0xeb9d2d31, 0x2d88, 0x11d3, \
0x9a, 0x16, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
+#define ACPI_TABLE_GUID \
+ EFI_GUID(0xeb9d2d30, 0x2d88, 0x11d3, \
+0x9a, 0x16, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
+
+#define ACPI_20_TABLE_GUID \
+ EFI_GUID(0x8868e871, 0xe4f1, 0x11d3, \
+0xbc, 0x22, 0x00, 0x80, 0xc7, 0x3c, 0x88, 0x81)
+
struct efi_configuration_table
{
efi_guid_t guid;
diff --git a/include/efi_loader.h b/include/efi_loader.h
index c66252a..d837e7b 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -215,6 +215,14 @@ efi_status_t efi_net_register(void);
efi_status_t efi_watchdog_register(void);
/* Called by bootefi to make SMBIOS tables available */
/**
+ * efi_acpi_register() - write out ACPI tables
+ *
+ * Called by bootefi to make ACPI tables available
+ *
+ * @return 0 if OK, -ENOMEM if no memory is available for the tables
+ */
+efi_status_t efi_acpi_register(void);
+/**
* efi_smbios_register() - write out SMBIOS tables
*
* Called by bootefi to make SMBIOS tables available
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index c6046e3..d6402c4 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -22,4 +22,5 @@ obj-$(CONFIG_LCD) += efi_gop.o
obj-$(CONFIG_DM_VIDEO) += efi_gop.o
obj-$(CONFIG_PARTITIONS) += efi_disk.o
obj-$(CONFIG_NET) += efi_net.o
+obj-$(CONFIG_GENERATE_ACPI_TABLE) += efi_acpi.o
obj-$(CONFIG_GENERATE_SMBIOS_TABLE) += efi_smbios.o
diff --git a/lib/efi_loader/efi_acpi.c b/lib/efi_loader/efi_acpi.c
new file mode 100644
index 000..b09292c
--- /dev/null
+++ b/lib/efi_loader/efi_acpi.c
@@ -0,0 +1,42 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * EFI application ACPI tables support
+ *
+ * Copyright (C) 2018, Bin Meng
+ */
+
+#include
+#include
+#include
+
+static const efi_guid_t acpi_guid = ACPI_20_TABLE_GUID;
+
+/*
+ * Install the ACPI table as a configuration table.
+ *
+ * @return status code
+ */
+efi_status_t efi_acpi_register(void)
+{
+ /* Map within the low 32 bits, to allow for 32bit ACPI tables */
+ u64 acpi = U32_MAX;
+ efi_status_t ret;
+
+ /* Reserve 64kiB page for ACPI */
+ ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
+EFI_RUNTIME_SERVICES_DATA, 16, );
+ if (ret != EFI_SUCCESS)
+ return ret;
+
+ /*
+* Generate ACPI tables - we know that efi_allocate_pages() returns
+* a 4k-aligned address, so it is safe to assume that
+* write_acpi_tables() will write the table at that address.
+*/
+ assert(!(acpi & 0xf));
+ write_acpi_tables(acpi);
+
+ /* And expose them to our EFI payload */
+ return efi_install_configuration_table(_guid,
+ (void *)(uintptr_t)acpi);
The maximum number of configuration tables is currently hard coded as 2
in efi_boottime.c. I think this limit should be raised. 16 seems
reasonable looking at which tables the Linux EFI stub or iPXE can process.
How about we just move efi_conf_table from .bss into something
dynamically allocated? If we wanted to keep things simple, we could even
just always allocate a full page on the first invocation of
efi_install_configuration_table() and just check against that size limit
going forward.
Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [u-boot-release] [PATCH] configs: Disable 4k erase sector size for spansion "s25fs512s" flash
On 06/25/2018 03:31 AM, Ashish Kumar wrote: > 4K erase size is used only in case of hydrid mode which is not > supported on any NXP platform with flash "s25fs512s". > Supported mode is uniform sector, with erase size 256kiB. > > Signed-off-by: Ashish Kumar > --- > configs/ls1046aqds_qspi_defconfig| 1 + > configs/ls1046aqds_sdcard_qspi_defconfig | 1 + > configs/ls1046ardb_qspi_SECURE_BOOT_defconfig| 1 + > configs/ls1046ardb_qspi_defconfig| 1 + > configs/ls1088aqds_qspi_SECURE_BOOT_defconfig| 1 + > configs/ls1088aqds_qspi_defconfig| 1 + > configs/ls1088aqds_sdcard_qspi_defconfig | 1 + > configs/ls1088ardb_qspi_SECURE_BOOT_defconfig| 1 + > configs/ls1088ardb_qspi_defconfig| 1 + > configs/ls1088ardb_sdcard_qspi_SECURE_BOOT_defconfig | 1 + > configs/ls1088ardb_sdcard_qspi_defconfig | 1 + > configs/ls2080aqds_qspi_defconfig| 1 + > configs/ls2088ardb_qspi_SECURE_BOOT_defconfig| 1 + > configs/ls2088ardb_qspi_defconfig| 1 + > 14 files changed, 14 insertions(+) > > diff --git a/configs/ls1046aqds_qspi_defconfig > b/configs/ls1046aqds_qspi_defconfig > index 4f3290c..a770039 100644 > --- a/configs/ls1046aqds_qspi_defconfig > +++ b/configs/ls1046aqds_qspi_defconfig > @@ -41,6 +41,7 @@ CONFIG_SPI=y > CONFIG_DM_SPI=y > CONFIG_FSL_DSPI=y > CONFIG_FSL_QSPI=y > +CONFIG_SPI_FLASH_USE_4K_SECTORS=n Ashish, Did you get the defconfig by "savedefconfig"? I think the correct setting is # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] gpio: omap_gpio: Convert to auto-alloc feature when DT is supported
The omap_gpio driver has a TODO that says when every board is converted
to DM and DT, the omap_gpio_bind can stop using calloc and switch
to auto-alloc.
This patch converts this driver to auto-calloc when DT is enabled.
Signed-off-by: Adam Ford
diff --git a/drivers/gpio/omap_gpio.c b/drivers/gpio/omap_gpio.c
index 79a975ce71..651f6994e4 100644
--- a/drivers/gpio/omap_gpio.c
+++ b/drivers/gpio/omap_gpio.c
@@ -302,6 +302,7 @@ static int omap_gpio_probe(struct udevice *dev)
return 0;
}
+#if !CONFIG_IS_ENABLED(OF_CONTROL)
static int omap_gpio_bind(struct udevice *dev)
{
struct omap_gpio_platdata *plat = dev_get_platdata(dev);
@@ -334,6 +335,7 @@ static int omap_gpio_bind(struct udevice *dev)
return 0;
}
+#endif
static const struct udevice_id omap_gpio_ids[] = {
{ .compatible = "ti,omap3-gpio" },
@@ -342,12 +344,33 @@ static const struct udevice_id omap_gpio_ids[] = {
{ }
};
+#if CONFIG_IS_ENABLED(OF_CONTROL)
+static int omap_gpio_ofdata_to_platdata(struct udevice *dev)
+{
+ struct omap_gpio_platdata *plat = dev_get_platdata(dev);
+ fdt_addr_t addr;
+
+ addr = devfdt_get_addr(dev);
+ if (addr == FDT_ADDR_T_NONE)
+ return -EINVAL;
+
+ plat->base = addr;
+ return 0;
+}
+#endif
+
U_BOOT_DRIVER(gpio_omap) = {
.name = "gpio_omap",
.id = UCLASS_GPIO,
+#if CONFIG_IS_ENABLED(OF_CONTROL)
+ .ofdata_to_platdata = of_match_ptr(omap_gpio_ofdata_to_platdata),
+ .bind = dm_scan_fdt_dev,
+ .platdata_auto_alloc_size = sizeof(struct omap_gpio_platdata),
+#else
+ .bind = omap_gpio_bind,
+#endif
.ops= _omap_ops,
.of_match = omap_gpio_ids,
- .bind = omap_gpio_bind,
.probe = omap_gpio_probe,
.priv_auto_alloc_size = sizeof(struct gpio_bank),
.flags = DM_FLAG_PRE_RELOC,
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 00/20] SPI-NAND support
On 25.06.2018 16:55, Tom Rini wrote: On Mon, Jun 25, 2018 at 04:46:56PM +0200, Boris Brezillon wrote: On Mon, 25 Jun 2018 19:58:37 +0530 Jagan Teki wrote: - convert fsl-qspi to spi-mem We're not targeting the fsl-qspi controller here but a simple SPI controller that is already upstreamed. But yes, the fsl-qspi driver will have to be patched to support the spi-mem interface at some point. Can you point me that simple spi-mem controller driver? It's not a controller that implements spi-mem operations but a simple SPI controller (one that knows how to do regular SPI transfers and nothing more). But the spi-mem layer knows how to send spi_mem_op using regular transfer and that's why it works without any modification at the driver level. For spi-nor interface design, we have an example code here[2] I've paused this [2] series because of dm conversion of spi-drivers otherwise I need add legacy code like mmc-legacy.c, so if we really move to spi-mem design and okay with above design. I will try to move the current spi flash to add MTD driver-model so-that we can add spi-mem, spi-nand on top of it or we can work together to convert them all. Why can't we do things iteratively. I mean, if the long term goal is to convert everything to the driver model, then this patchset is going in the right direction: - addition of DM helpers to the MTD_UCLASS - addition of the spi-mem interface properly integrated in the DM model of the SPI framework - addition of a SPI NAND driver, again properly integrated in the DM - integration of DM-ready MTD drivers and old MTD drivers in a single view exposed by the cmd/mtd.c command set I'd really like to limit the scope of this development to these topics, which doesn't prevent you from converting other part of u-boot to the spi-mem approach (SPI NOR is one example). I hope you understand our concerns and the fact that what you're asking us to do as a dependency of getting SPI NAND support + cmd/mtd.c merged is way more than we can actually provide. To answer all these questions, I think we need to decide whether we go for MTD dm abstraction or existing MTD layer. When I say MTD dm abstraction, all mtd operation prototypes are in the form of udevice unlike existing MTD has mtd_info. when I initially supporting spi-nor (during Linux early spi-nor) I've reused existing MTD and written something like what Miquel did using mtd_info ops [3]. but then developers on ML, proposed the new drivers should be form of driver-model abstraction, so I've added mtd driver model ops [4]. I understand the new MTD dm abstraction in U-Boot is not possible for direct syncing from Linux, but we really want the u-boot way of handling drivers and trying to copy code from Linux by removing __UBOOT__ or any Linux specific macros. Since this is pretty much big task, ie the reason I'm asking for single driver from each MTD device so-that once the clear stack is ready other drivers can convert one-by-one. I think I have to repeat my previous statement here. It would be very unfortunate if u-boot decides to take this direction (see Richard's reply), especially since I see absolutely no benefit in doing what you suggest. Having MTD devices registered to the uboot DM is something I can understand, deciding to no longer support the standard MTD API is something I don't. I agree. We want U-Boot to be able to leverage as much as possible from the Linux kernel with as little re-working as possible. I wholeheartedly agree on this. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 00/20] SPI-NAND support
On Mon, Jun 25, 2018 at 04:46:56PM +0200, Boris Brezillon wrote: > On Mon, 25 Jun 2018 19:58:37 +0530 > Jagan Teki wrote: > > > >>> - convert fsl-qspi to spi-mem > > >> > > >> We're not targeting the fsl-qspi controller here but a simple SPI > > >> controller that is already upstreamed. But yes, the fsl-qspi driver > > >> will have to be patched to support the spi-mem interface at some point. > > > > > > Can you point me that simple spi-mem controller driver? > > It's not a controller that implements spi-mem operations but a simple > SPI controller (one that knows how to do regular SPI transfers and > nothing more). But the spi-mem layer knows how to send spi_mem_op using > regular transfer and that's why it works without any modification at > the driver level. > > > > >>> > > >>> For spi-nor interface design, we have an example code here[2] > > >>> > > >>> I've paused this [2] series because of dm conversion of spi-drivers > > >>> otherwise I need add legacy code like mmc-legacy.c, so if we really > > >>> move to spi-mem design and okay with above design. I will try to move > > >>> the current spi flash to add MTD driver-model so-that we can add > > >>> spi-mem, spi-nand on top of it or we can work together to convert them > > >>> all. > > >> > > >> Why can't we do things iteratively. I mean, if the long term goal is to > > >> convert everything to the driver model, then this patchset is going in > > >> the right direction: > > >> - addition of DM helpers to the MTD_UCLASS > > >> - addition of the spi-mem interface properly integrated in the DM > > >>model of the SPI framework > > >> - addition of a SPI NAND driver, again properly integrated in the DM > > >> - integration of DM-ready MTD drivers and old MTD drivers in a single > > >>view exposed by the cmd/mtd.c command set > > >> > > >> I'd really like to limit the scope of this development to these topics, > > >> which doesn't prevent you from converting other part of u-boot to the > > >> spi-mem approach (SPI NOR is one example). > > >> > > >> I hope you understand our concerns and the fact that what you're asking > > >> us to do as a dependency of getting SPI NAND support + cmd/mtd.c merged > > >> is way more than we can actually provide. > > > > > > To answer all these questions, I think we need to decide whether we go > > > for MTD dm abstraction or existing MTD layer. > > > > > > When I say MTD dm abstraction, all mtd operation prototypes are in the > > > form of udevice unlike existing MTD has mtd_info. when I initially > > > supporting spi-nor (during Linux early spi-nor) I've reused existing > > > MTD and written something like what Miquel did using mtd_info ops [3]. > > > but then developers on ML, proposed the new drivers should be form of > > > driver-model abstraction, so I've added mtd driver model ops [4]. > > > > > > I understand the new MTD dm abstraction in U-Boot is not possible for > > > direct syncing from Linux, but we really want the u-boot way of > > > handling drivers and trying to copy code from Linux by removing > > > __UBOOT__ or any Linux specific macros. Since this is pretty much big > > > task, ie the reason I'm asking for single driver from each MTD device > > > so-that once the clear stack is ready other drivers can convert > > > one-by-one. > > I think I have to repeat my previous statement here. It would be very > unfortunate if u-boot decides to take this direction (see Richard's > reply), especially since I see absolutely no benefit in doing what you > suggest. Having MTD devices registered to the uboot DM is something I > can understand, deciding to no longer support the standard MTD API is > something I don't. I agree. We want U-Boot to be able to leverage as much as possible from the Linux kernel with as little re-working as possible. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH u-boot 2/2] boards: amlogic: Add FriendlyElec NanoPi K2 board support
From: Thomas McKahan This adds platform code for the FriendlyElec NanoPi K2 board based on a Meson GXBB (S905) SoC with the Meson GXBB configuration. This initial submission only supports: - UART - MMC/SDCard - Ethernet - Reset Controller - Clock controller Cc: Yuefei Tan Signed-off-by: Thomas McKahan Signed-off-by: Neil Armstrong --- arch/arm/dts/Makefile | 1 + arch/arm/mach-meson/Kconfig | 8 +++ board/amlogic/nanopi-k2/Kconfig | 12 + board/amlogic/nanopi-k2/MAINTAINERS | 6 +++ board/amlogic/nanopi-k2/Makefile| 7 +++ board/amlogic/nanopi-k2/README | 99 + board/amlogic/nanopi-k2/nanopi-k2.c | 61 +++ configs/nanopi-k2_defconfig | 40 +++ include/configs/nanopi-k2.h | 18 +++ 9 files changed, 252 insertions(+) create mode 100644 board/amlogic/nanopi-k2/Kconfig create mode 100644 board/amlogic/nanopi-k2/MAINTAINERS create mode 100644 board/amlogic/nanopi-k2/Makefile create mode 100644 board/amlogic/nanopi-k2/README create mode 100644 board/amlogic/nanopi-k2/nanopi-k2.c create mode 100644 configs/nanopi-k2_defconfig create mode 100644 include/configs/nanopi-k2.h diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index bcbaae2..62fc442 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -55,6 +55,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \ dtb-$(CONFIG_ARCH_MESON) += \ meson-gxbb-nanopi-k2.dtb \ meson-gxbb-odroidc2.dtb \ + meson-gxbb-nanopi-k2.dtb \ meson-gxl-s905x-p212.dtb \ meson-gxl-s905x-libretech-cc.dtb \ meson-gxl-s905x-khadas-vim.dtb diff --git a/arch/arm/mach-meson/Kconfig b/arch/arm/mach-meson/Kconfig index 9a06ccc..cc3383a 100644 --- a/arch/arm/mach-meson/Kconfig +++ b/arch/arm/mach-meson/Kconfig @@ -29,6 +29,12 @@ config TARGET_ODROID_C2 with 2 GiB of RAM, Gigabit Ethernet, HDMI, 4 USB, micro-SD slot, eMMC, IR receiver and a 40-pin GPIO header. +config TARGET_NANOPI_K2 + bool "NANOPI_K2" + help + NANOPI_K2 is a single board computer based on Meson GXBaby + with 2 GiB of RAM, Gigabit Ethernet,AP6212 Wifi, HDMI, 4 USB, + micro-SD slot, eMMC, IR receiver and a 40-pin GPIO header. endif if MESON_GXL @@ -64,6 +70,8 @@ config SYS_MALLOC_F_LEN source "board/amlogic/odroid-c2/Kconfig" +source "board/amlogic/nanopi-k2/Kconfig" + source "board/amlogic/p212/Kconfig" source "board/amlogic/libretech-cc/Kconfig" diff --git a/board/amlogic/nanopi-k2/Kconfig b/board/amlogic/nanopi-k2/Kconfig new file mode 100644 index 000..374bda2 --- /dev/null +++ b/board/amlogic/nanopi-k2/Kconfig @@ -0,0 +1,12 @@ +if TARGET_NANOPI_K2 + +config SYS_BOARD + default "nanopi-k2" + +config SYS_VENDOR + default "amlogic" + +config SYS_CONFIG_NAME + default "nanopi-k2" + +endif diff --git a/board/amlogic/nanopi-k2/MAINTAINERS b/board/amlogic/nanopi-k2/MAINTAINERS new file mode 100644 index 000..0452bd1 --- /dev/null +++ b/board/amlogic/nanopi-k2/MAINTAINERS @@ -0,0 +1,6 @@ +NANOPI-K2 +M: Neil Armstrong +S: Maintained +F: board/amlogic/nanopi-k2/ +F: include/configs/nanopi-k2.h +F: configs/nanopi-k2_defconfig diff --git a/board/amlogic/nanopi-k2/Makefile b/board/amlogic/nanopi-k2/Makefile new file mode 100644 index 000..7d9b666 --- /dev/null +++ b/board/amlogic/nanopi-k2/Makefile @@ -0,0 +1,7 @@ +# +# (C) Copyright 2018 Thomas McKahan +# +# SPDX-License-Identifier: GPL-2.0+ +# + +obj-y := nanopi-k2.o diff --git a/board/amlogic/nanopi-k2/README b/board/amlogic/nanopi-k2/README new file mode 100644 index 000..d450d3c --- /dev/null +++ b/board/amlogic/nanopi-k2/README @@ -0,0 +1,99 @@ +U-Boot for NanoPi-K2 + + +NanoPi-K2 is a single board computer manufactured by FriendlyElec +with the following specifications: + + - Amlogic S905 ARM Cortex-A53 quad-core SoC @ 1.5GHz + - ARM Mali 450 GPU + - 2GB DDR3 SDRAM + - Gigabit Ethernet + - HDMI 2.0 4K/60Hz display + - 40-pin GPIO header + - 4 x USB 2.0 Host, 1 x USB OTG + - eMMC, microSD + - Infrared receiver + +Schematics are available on the manufacturer website. + +Currently the u-boot port supports the following devices: + - serial + - eMMC, microSD + - Ethernet + +u-boot compilation +== + + > export ARCH=arm + > export CROSS_COMPILE=aarch64-none-elf- + > make nanopi-k2_defconfig + > make + +Image creation +== + +Amlogic doesn't provide sources for the firmware and for tools needed +to create the bootloader image, so it is necessary to obtain them from +the git tree published by the board vendor: + + > wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz + > wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz + > tar xvfJ
[U-Boot] [PATCH u-boot 1/2] ARM: dts: sync meson-gxbb-nanopi-k2 from Linux 4.17
Get the meson-gxbb-nanopi-k2.dts file from Linux 4.17.
Signed-off-by: Neil Armstrong
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/meson-gxbb-nanopi-k2.dts | 323 ++
2 files changed, 324 insertions(+)
create mode 100644 arch/arm/dts/meson-gxbb-nanopi-k2.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 493652e..bcbaae2 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -53,6 +53,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3399-puma-ddr1866.dtb \
rv1108-evb.dtb
dtb-$(CONFIG_ARCH_MESON) += \
+ meson-gxbb-nanopi-k2.dtb \
meson-gxbb-odroidc2.dtb \
meson-gxl-s905x-p212.dtb \
meson-gxl-s905x-libretech-cc.dtb \
diff --git a/arch/arm/dts/meson-gxbb-nanopi-k2.dts
b/arch/arm/dts/meson-gxbb-nanopi-k2.dts
new file mode 100644
index 000..7d5709c
--- /dev/null
+++ b/arch/arm/dts/meson-gxbb-nanopi-k2.dts
@@ -0,0 +1,323 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2017 Andreas Färber
+ */
+
+/dts-v1/;
+
+#include "meson-gxbb.dtsi"
+#include
+
+/ {
+ compatible = "friendlyarm,nanopi-k2", "amlogic,meson-gxbb";
+
+ aliases {
+ serial0 = _AO;
+ ethernet0 =
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x8000>;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ stat {
+ label = "nanopi-k2:blue:stat";
+ gpios = <_ao GPIOAO_13 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ panic-indicator;
+ };
+ };
+
+ vdd_5v: regulator-vdd-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "VDD_5V";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ };
+
+ vddio_ao18: regulator-vddio-ao18 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDIO_AO18";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ };
+
+ vddio_ao3v3: regulator-vddio-ao3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDIO_AO3.3V";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
+
+ vddio_tf: regulator-vddio-tf {
+ compatible = "regulator-gpio";
+
+ regulator-name = "VDDIO_TF";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+
+ gpios = <_ao GPIOAO_2 GPIO_ACTIVE_HIGH>;
+ gpios-states = <0>;
+
+ states = <330 0>,
+<180 1>;
+
+ regulator-settling-time-up-us = <100>;
+ regulator-settling-time-down-us = <5000>;
+ };
+
+ wifi_32k: wifi-32k {
+ compatible = "pwm-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ pwms = <_ef 0 30518 0>; /* PWM_E at 32.768KHz */
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = < GPIOX_6 GPIO_ACTIVE_LOW>;
+ clocks = <_32k>;
+ clock-names = "ext_clock";
+ };
+
+ vcc1v8: regulator-vcc1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC1.8V";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ };
+
+ vcc3v3: regulator-vcc3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC3.3V";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
+
+ emmc_pwrseq: emmc-pwrseq {
+ compatible = "mmc-pwrseq-emmc";
+ reset-gpios = < BOOT_9 GPIO_ACTIVE_LOW>;
+ };
+};
+
+ {
+ status = "okay";
+ pinctrl-0 = <_rgmii_pins>;
+ pinctrl-names = "default";
+
+ phy-handle = <_phy0>;
+ phy-mode = "rgmii";
+
+ amlogic,tx-delay-ns = <2>;
+
+ snps,reset-gpio = < GPIOZ_14 0>;
+ snps,reset-delays-us = <0 1 100>;
+ snps,reset-active-low;
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eth_phy0: ethernet-phy@0 {
+ /* Realtek RTL8211F (0x001cc916) */
+ reg = <0>;
+ interrupt-parent = <_intc>;
+ /* MAC_INTR on GPIOZ_15 */
+ interrupts = <29 IRQ_TYPE_LEVEL_LOW>;
+ };
+ };
[U-Boot] [PATCH u-boot 0/2] Add support for the FriendlyElec NanoPi K2 board
This adds platform code for the FriendlyElec NanoPi K2 board based on a Meson GXBB (S905) SoC with the Meson GXBB configuration. This initial submission only supports: - UART - MMC/SDCard - Ethernet - Reset Controller - Clock controller A sync with Linux 4.17 to get the device tree is also necessary. Neil Armstrong (1): ARM: dts: sync meson-gxbb-nanopi-k2 from Linux 4.17 Thomas McKahan (1): boards: amlogic: Add FriendlyElec NanoPi K2 board support arch/arm/dts/Makefile | 2 + arch/arm/dts/meson-gxbb-nanopi-k2.dts | 323 ++ arch/arm/mach-meson/Kconfig | 8 + board/amlogic/nanopi-k2/Kconfig | 12 ++ board/amlogic/nanopi-k2/MAINTAINERS | 6 + board/amlogic/nanopi-k2/Makefile | 7 + board/amlogic/nanopi-k2/README| 99 +++ board/amlogic/nanopi-k2/nanopi-k2.c | 61 +++ configs/nanopi-k2_defconfig | 40 + include/configs/nanopi-k2.h | 18 ++ 10 files changed, 576 insertions(+) create mode 100644 arch/arm/dts/meson-gxbb-nanopi-k2.dts create mode 100644 board/amlogic/nanopi-k2/Kconfig create mode 100644 board/amlogic/nanopi-k2/MAINTAINERS create mode 100644 board/amlogic/nanopi-k2/Makefile create mode 100644 board/amlogic/nanopi-k2/README create mode 100644 board/amlogic/nanopi-k2/nanopi-k2.c create mode 100644 configs/nanopi-k2_defconfig create mode 100644 include/configs/nanopi-k2.h -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 00/20] SPI-NAND support
On Mon, 25 Jun 2018 19:58:37 +0530 Jagan Teki wrote: > >>> - convert fsl-qspi to spi-mem > >> > >> We're not targeting the fsl-qspi controller here but a simple SPI > >> controller that is already upstreamed. But yes, the fsl-qspi driver > >> will have to be patched to support the spi-mem interface at some point. > > > > Can you point me that simple spi-mem controller driver? It's not a controller that implements spi-mem operations but a simple SPI controller (one that knows how to do regular SPI transfers and nothing more). But the spi-mem layer knows how to send spi_mem_op using regular transfer and that's why it works without any modification at the driver level. > >>> > >>> For spi-nor interface design, we have an example code here[2] > >>> > >>> I've paused this [2] series because of dm conversion of spi-drivers > >>> otherwise I need add legacy code like mmc-legacy.c, so if we really > >>> move to spi-mem design and okay with above design. I will try to move > >>> the current spi flash to add MTD driver-model so-that we can add > >>> spi-mem, spi-nand on top of it or we can work together to convert them > >>> all. > >> > >> Why can't we do things iteratively. I mean, if the long term goal is to > >> convert everything to the driver model, then this patchset is going in > >> the right direction: > >> - addition of DM helpers to the MTD_UCLASS > >> - addition of the spi-mem interface properly integrated in the DM > >>model of the SPI framework > >> - addition of a SPI NAND driver, again properly integrated in the DM > >> - integration of DM-ready MTD drivers and old MTD drivers in a single > >>view exposed by the cmd/mtd.c command set > >> > >> I'd really like to limit the scope of this development to these topics, > >> which doesn't prevent you from converting other part of u-boot to the > >> spi-mem approach (SPI NOR is one example). > >> > >> I hope you understand our concerns and the fact that what you're asking > >> us to do as a dependency of getting SPI NAND support + cmd/mtd.c merged > >> is way more than we can actually provide. > > > > To answer all these questions, I think we need to decide whether we go > > for MTD dm abstraction or existing MTD layer. > > > > When I say MTD dm abstraction, all mtd operation prototypes are in the > > form of udevice unlike existing MTD has mtd_info. when I initially > > supporting spi-nor (during Linux early spi-nor) I've reused existing > > MTD and written something like what Miquel did using mtd_info ops [3]. > > but then developers on ML, proposed the new drivers should be form of > > driver-model abstraction, so I've added mtd driver model ops [4]. > > > > I understand the new MTD dm abstraction in U-Boot is not possible for > > direct syncing from Linux, but we really want the u-boot way of > > handling drivers and trying to copy code from Linux by removing > > __UBOOT__ or any Linux specific macros. Since this is pretty much big > > task, ie the reason I'm asking for single driver from each MTD device > > so-that once the clear stack is ready other drivers can convert > > one-by-one. I think I have to repeat my previous statement here. It would be very unfortunate if u-boot decides to take this direction (see Richard's reply), especially since I see absolutely no benefit in doing what you suggest. Having MTD devices registered to the uboot DM is something I can understand, deciding to no longer support the standard MTD API is something I don't. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 00/20] SPI-NAND support
Am Montag, 25. Juni 2018, 16:27:45 CEST schrieb Jagan Teki: > I understand the new MTD dm abstraction in U-Boot is not possible for > direct syncing from Linux, but we really want the u-boot way of > handling drivers and trying to copy code from Linux by removing > __UBOOT__ or any Linux specific macros. Since this is pretty much big > task, ie the reason I'm asking for single driver from each MTD device > so-that once the clear stack is ready other drivers can convert > one-by-one. Do you have the man power to massage/backport all Linux changes/fixes to u-boot? Thanks, //richard ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 00/20] SPI-NAND support
+ Simon + Tom On Mon, Jun 25, 2018 at 7:57 PM, Jagan Teki wrote: > + Simon > + Tom > (suggesting MTD driver model abstraction layer) > > On Mon, Jun 25, 2018 at 2:39 PM, Boris Brezillon > wrote: >> +Richard to comment on the MTD abstraction stuff and how uboot port >> of UBI might be impacted by some changes requested here. >> >> Hi Jagan, >> >> On Mon, 25 Jun 2018 13:59:37 +0530 >> Jagan Teki wrote: >> >>> >>> I've looked the code on the respective patches, look like most of the >>> code copy from Linux by adding __UBOOT__. I have no issue with Linux >>> copy but we need to structure the code according to U-Boot in the form >>> of driver-model (this series lack with that). >>> >>> Here are my suggestions, based the MTD work so-far >>> >>> First we need to design MTD driver-model which can capable to drive >>> one driver from each interface. (not converting all interface drivers >>> at once, that is taking more time and other issues) >>> >>> Like Linux MTD, U-Boot should have MTD dm for underlying flash devices >>> like nand, parallel nor, spinor etc. So to drive this theory with >>> driver model(with an example of block layer) mtd is common device >>> interaction for most of memory technology flashes like nand, >>> parallel nor, spinor etc, these are treated as interface types wrt >>> u-boot driver model. >>> >>> Once the respective interface driver bind happen, the uclass driver >>> will pass an 'interface type' to mtd layer to create device for it, >>> for example once spinor ULASS_SPI_NOR driver bind happen, the uclass >>> driver of spinor will pass MTD_IF_TYPE_SPI_NOR >>> interface type to create mtd device for spinor devices. >>> >>> So If we add this design to SPI-NAND changes, we need to implement >>> - MTD dm core that can driver all interfaces >> >> That's already what the MTD framework provides, and Miquel even added >> some stuff to integrate the MTD layer even further in the DM. It's >> probably not perfect yet, but the changes are, IMHO, going in the right >> direction. >> >> Now, if you're talking about the new MTD API that creates helper >> functions prefixed with dm_, sorry, but I don't see the point. We >> already have plenty of MTD users in u-boot, they all manipulate MTD >> objects and go through the standard MTD API to do that. What you >> suggest would make things messier for several reasons: >> >> 1/ we won't be able to easily port Linux code to u-boot. Look at the >>JFFS2 UBI support. They all use mtd_info objects. What's the point of >>changing that except making things harder to port. >> >> 2/ Not all MTD providers will be converted to the device model at once, >>so how do you plan to deal with that? >> >> 3/ What's the benefit of exposing yet another way to manipulate MTD >>devices? >> >>> - one driver for raw nand >> >> Unfortunately, that's not how it works right now, and clearly, we >> don't have time to work on this raw NAND rework right now. >> >>> - one driver for spinand >> >> I think that's already the case. >> >>> - spi-mem >> >> It's also what Miquel is doing in this series. >> >>> - convert fsl-qspi to spi-mem >> >> We're not targeting the fsl-qspi controller here but a simple SPI >> controller that is already upstreamed. But yes, the fsl-qspi driver >> will have to be patched to support the spi-mem interface at some point. > > Can you point me that simple spi-mem controller driver? > >> >>> - implement command to handle >> >> This I don't get. What do you mean by "implement command to handle"? >> Are we talking about cmd/mtd.c? I think the work Miquel has done is >> already a good start, what's missing in there? >> >>> >>> For spi-nor interface design, we have an example code here[2] >>> >>> I've paused this [2] series because of dm conversion of spi-drivers >>> otherwise I need add legacy code like mmc-legacy.c, so if we really >>> move to spi-mem design and okay with above design. I will try to move >>> the current spi flash to add MTD driver-model so-that we can add >>> spi-mem, spi-nand on top of it or we can work together to convert them >>> all. >> >> Why can't we do things iteratively. I mean, if the long term goal is to >> convert everything to the driver model, then this patchset is going in >> the right direction: >> - addition of DM helpers to the MTD_UCLASS >> - addition of the spi-mem interface properly integrated in the DM >>model of the SPI framework >> - addition of a SPI NAND driver, again properly integrated in the DM >> - integration of DM-ready MTD drivers and old MTD drivers in a single >>view exposed by the cmd/mtd.c command set >> >> I'd really like to limit the scope of this development to these topics, >> which doesn't prevent you from converting other part of u-boot to the >> spi-mem approach (SPI NOR is one example). >> >> I hope you understand our concerns and the fact that what you're asking >> us to do as a dependency of getting SPI NAND support + cmd/mtd.c merged >> is way more than we can actually
Re: [U-Boot] [RFC PATCH 00/20] SPI-NAND support
+ Simon + Tom (suggesting MTD driver model abstraction layer) On Mon, Jun 25, 2018 at 2:39 PM, Boris Brezillon wrote: > +Richard to comment on the MTD abstraction stuff and how uboot port > of UBI might be impacted by some changes requested here. > > Hi Jagan, > > On Mon, 25 Jun 2018 13:59:37 +0530 > Jagan Teki wrote: > >> >> I've looked the code on the respective patches, look like most of the >> code copy from Linux by adding __UBOOT__. I have no issue with Linux >> copy but we need to structure the code according to U-Boot in the form >> of driver-model (this series lack with that). >> >> Here are my suggestions, based the MTD work so-far >> >> First we need to design MTD driver-model which can capable to drive >> one driver from each interface. (not converting all interface drivers >> at once, that is taking more time and other issues) >> >> Like Linux MTD, U-Boot should have MTD dm for underlying flash devices >> like nand, parallel nor, spinor etc. So to drive this theory with >> driver model(with an example of block layer) mtd is common device >> interaction for most of memory technology flashes like nand, >> parallel nor, spinor etc, these are treated as interface types wrt >> u-boot driver model. >> >> Once the respective interface driver bind happen, the uclass driver >> will pass an 'interface type' to mtd layer to create device for it, >> for example once spinor ULASS_SPI_NOR driver bind happen, the uclass >> driver of spinor will pass MTD_IF_TYPE_SPI_NOR >> interface type to create mtd device for spinor devices. >> >> So If we add this design to SPI-NAND changes, we need to implement >> - MTD dm core that can driver all interfaces > > That's already what the MTD framework provides, and Miquel even added > some stuff to integrate the MTD layer even further in the DM. It's > probably not perfect yet, but the changes are, IMHO, going in the right > direction. > > Now, if you're talking about the new MTD API that creates helper > functions prefixed with dm_, sorry, but I don't see the point. We > already have plenty of MTD users in u-boot, they all manipulate MTD > objects and go through the standard MTD API to do that. What you > suggest would make things messier for several reasons: > > 1/ we won't be able to easily port Linux code to u-boot. Look at the >JFFS2 UBI support. They all use mtd_info objects. What's the point of >changing that except making things harder to port. > > 2/ Not all MTD providers will be converted to the device model at once, >so how do you plan to deal with that? > > 3/ What's the benefit of exposing yet another way to manipulate MTD >devices? > >> - one driver for raw nand > > Unfortunately, that's not how it works right now, and clearly, we > don't have time to work on this raw NAND rework right now. > >> - one driver for spinand > > I think that's already the case. > >> - spi-mem > > It's also what Miquel is doing in this series. > >> - convert fsl-qspi to spi-mem > > We're not targeting the fsl-qspi controller here but a simple SPI > controller that is already upstreamed. But yes, the fsl-qspi driver > will have to be patched to support the spi-mem interface at some point. Can you point me that simple spi-mem controller driver? > >> - implement command to handle > > This I don't get. What do you mean by "implement command to handle"? > Are we talking about cmd/mtd.c? I think the work Miquel has done is > already a good start, what's missing in there? > >> >> For spi-nor interface design, we have an example code here[2] >> >> I've paused this [2] series because of dm conversion of spi-drivers >> otherwise I need add legacy code like mmc-legacy.c, so if we really >> move to spi-mem design and okay with above design. I will try to move >> the current spi flash to add MTD driver-model so-that we can add >> spi-mem, spi-nand on top of it or we can work together to convert them >> all. > > Why can't we do things iteratively. I mean, if the long term goal is to > convert everything to the driver model, then this patchset is going in > the right direction: > - addition of DM helpers to the MTD_UCLASS > - addition of the spi-mem interface properly integrated in the DM >model of the SPI framework > - addition of a SPI NAND driver, again properly integrated in the DM > - integration of DM-ready MTD drivers and old MTD drivers in a single >view exposed by the cmd/mtd.c command set > > I'd really like to limit the scope of this development to these topics, > which doesn't prevent you from converting other part of u-boot to the > spi-mem approach (SPI NOR is one example). > > I hope you understand our concerns and the fact that what you're asking > us to do as a dependency of getting SPI NAND support + cmd/mtd.c merged > is way more than we can actually provide. To answer all these questions, I think we need to decide whether we go for MTD dm abstraction or existing MTD layer. When I say MTD dm abstraction, all mtd operation prototypes are in
[U-Boot] [PATCH v3 2/3] doc: dtbinding: Add file system firmware loader binding document
From: Tien Fong Chee
Add a document to describe file system firmware loader binding
information.
Signed-off-by: Tien Fong Chee
---
doc/device-tree-bindings/chosen.txt | 22
doc/device-tree-bindings/misc/fs_loader.txt | 52 +
2 files changed, 74 insertions(+)
create mode 100644 doc/device-tree-bindings/misc/fs_loader.txt
diff --git a/doc/device-tree-bindings/chosen.txt
b/doc/device-tree-bindings/chosen.txt
index c96b8f7..738673c 100644
--- a/doc/device-tree-bindings/chosen.txt
+++ b/doc/device-tree-bindings/chosen.txt
@@ -73,3 +73,25 @@ Example
u-boot,spl-boot-order = "same-as-spl", ,
"/sdhci@fe33";
};
};
+
+firmware-loader property
+
+Multiple file system firmware loader nodes could be defined in device trees for
+multiple storage type and their default partition, then a property
+"firmware-loader" can be used to pass default firmware loader
+node(default storage type) to the firmware loader driver.
+
+Example
+---
+/ {
+ chosen {
+ firmware-loader = _loader0;
+ };
+
+ fs_loader0: fs_loader@0 {
+ u-boot,dm-pre-reloc;
+ compatible = "fs_loader";
+ storage_device = "mmc";
+ devpart = "0:1";
+ };
+};
diff --git a/doc/device-tree-bindings/misc/fs_loader.txt
b/doc/device-tree-bindings/misc/fs_loader.txt
new file mode 100644
index 000..78bea66
--- /dev/null
+++ b/doc/device-tree-bindings/misc/fs_loader.txt
@@ -0,0 +1,52 @@
+* File system firmware loader
+
+Required properties:
+
+
+- compatible: should contain "fs_loader"
+- storage_device: which storage device loading from, could be:
+ - mmc, usb, sata, and ubi.
+- devpart: which storage device and partition the image loading from,
+ this property is required for mmc, usb and sata.
+- mdtpart: which partition of ubi the image loading from, this property is
+ required for ubi.
+- ubivol: which volume of ubi the image loading from, this proprety is required
+ for ubi.
+
+Example of storage device and partition search set for mmc, usb, sata and
+ubi in device tree source as shown in below:
+
+ Example of storage type and device partition search set for mmc, usb,
+ sata and ubi as shown in below:
+ Example for mmc:
+ fs_loader0: fs_loader@0 {
+ u-boot,dm-pre-reloc;
+ compatible = "fs_loader";
+ storage_device = "mmc";
+ devpart = "0:1";
+ };
+
+ Example for usb:
+ fs_loader1: fs_loader@1 {
+ u-boot,dm-pre-reloc;
+ compatible = "fs_loader";
+ storage_device = "usb";
+ devpart = "0:1";
+ };
+
+ Example for sata:
+ fs_loader2: fs_loader@2 {
+ u-boot,dm-pre-reloc;
+ compatible = "fs_loader";
+ storage_device = "sata";
+ devpart = "0:1";
+ };
+
+ Example for ubi:
+ fs_loader3: fs_loader@3 {
+ u-boot,dm-pre-reloc;
+ compatible = "fs_loader";
+ storage_device = "ubi";
+ mtdpart = "UBI",
+ ubivol = "ubi0";
+ };
--
2.2.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 3/3] common: Generic loader for file system
From: Tien Fong Chee
This is file system generic loader which can be used to load
the file image from the storage into target such as memory.
The consumer driver would then use this loader to program whatever,
ie. the FPGA device.
Signed-off-by: Tien Fong Chee
---
drivers/misc/Kconfig | 10 ++
drivers/misc/Makefile| 1 +
drivers/misc/fs_loader.c | 238 +++
include/dm/uclass-id.h | 1 +
include/fs_loader.h | 28 ++
5 files changed, 278 insertions(+)
create mode 100644 drivers/misc/fs_loader.c
create mode 100644 include/fs_loader.h
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 17b3a80..4163b4f 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -277,4 +277,14 @@ config GDSYS_RXAUI_CTRL
depends on MISC
help
Support gdsys FPGA's RXAUI control.
+
+config FS_LOADER
+ bool "Enable loader driver for file system"
+ help
+ This is file system generic loader which can be used to load
+ the file image from the storage into target such as memory.
+
+ The consumer driver would then use this loader to program whatever,
+ ie. the FPGA device.
+
endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 4ce9d21..67a36f8 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -54,3 +54,4 @@ obj-$(CONFIG_STM32_RCC) += stm32_rcc.o
obj-$(CONFIG_STM32MP_FUSE) += stm32mp_fuse.o
obj-$(CONFIG_SYS_DPAA_QBMAN) += fsl_portals.o
obj-$(CONFIG_GDSYS_RXAUI_CTRL) += gdsys_rxaui_ctrl.o
+obj-$(CONFIG_FS_LOADER) += fs_loader.o
diff --git a/drivers/misc/fs_loader.c b/drivers/misc/fs_loader.c
new file mode 100644
index 000..0dc385f
--- /dev/null
+++ b/drivers/misc/fs_loader.c
@@ -0,0 +1,238 @@
+/*
+ * Copyright (C) 2018 Intel Corporation
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct firmware_priv {
+ const char *name; /* Filename */
+ u32 offset; /* Offset of reading a file */
+};
+
+static int select_fs_dev(struct device_platdata *plat)
+{
+ int ret;
+
+ if (!strcmp("mmc", plat->name)) {
+ ret = fs_set_blk_dev("mmc", plat->devpart, FS_TYPE_ANY);
+ } else if (!strcmp("usb", plat->name)) {
+ ret = fs_set_blk_dev("usb", plat->devpart, FS_TYPE_ANY);
+ } else if (!strcmp("sata", plat->name)) {
+ ret = fs_set_blk_dev("sata", plat->devpart, FS_TYPE_ANY);
+ } else if (!strcmp("ubi", plat->name)) {
+ if (plat->ubivol)
+ ret = fs_set_blk_dev("ubi", NULL, FS_TYPE_UBIFS);
+ else
+ ret = -ENODEV;
+ } else {
+ debug("Error: unsupported storage device.\n");
+ return -ENODEV;
+ }
+
+ if (ret)
+ debug("Error: could not access storage.\n");
+
+ return ret;
+}
+
+static void set_storage_devpart(struct device_platdata *plat, char *devpart)
+{
+ plat->devpart = devpart;
+}
+
+static void set_storage_mtdpart(struct device_platdata *plat, char *mtdpart)
+{
+ plat->mtdpart = mtdpart;
+}
+
+static void set_storage_ubivol(struct device_platdata *plat, char *ubivol)
+{
+ plat->ubivol = ubivol;
+}
+
+/**
+ * _request_firmware_prepare - Prepare firmware struct.
+ *
+ * @firmware_p: Pointer to pointer to firmware image.
+ * @name: Name of firmware file.
+ * @dbuf: Address of buffer to load firmware into.
+ * @size: Size of buffer.
+ * @offset: Offset of a file for start reading into buffer.
+ *
+ * Return: Negative value if fail, 0 for successful.
+ */
+static int _request_firmware_prepare(struct firmware **firmware_p,
+ const char *name, void *dbuf,
+ size_t size, u32 offset)
+{
+ struct firmware *firmware;
+ struct firmware_priv *fw_priv;
+
+ *firmware_p = NULL;
+
+ if (!name || name[0] == '\0')
+ return -EINVAL;
+
+ firmware = calloc(1, sizeof(*firmware));
+ if (!firmware)
+ return -ENOMEM;
+
+ fw_priv = calloc(1, sizeof(*fw_priv));
+ if (!fw_priv) {
+ free(firmware);
+ return -ENOMEM;
+ }
+
+ fw_priv->name = name;
+ fw_priv->offset = offset;
+ firmware->data = dbuf;
+ firmware->size = size;
+ firmware->priv = fw_priv;
+ *firmware_p = firmware;
+
+ return 0;
+}
+
+/**
+ * fw_get_filesystem_firmware - load firmware into an allocated buffer.
+ * @plat: Platform data such as storage and partition firmware loading from.
+ * @firmware_p: pointer to firmware image.
+ *
+ * Return: Size of total read, negative value when error.
+ */
+static int fw_get_filesystem_firmware(struct device_platdata *plat,
+struct firmware *firmware_p)
+{
+
[U-Boot] [PATCH v3 0/3] Generic file system firmware loader DM
From: Tien Fong Chee This patchset contains generic file system loader DM which is very close to Linux firmware loader but for U-Boot framework. Generic file system firmware loader can be used load whatever into target location, and then consumer driver would use it to program whatever, ie. the FPGA. This version mainly resolved comments from Simon and Marek in [v2]. Patch set for sandbox will be sent out separately. This series is working on top of u-boot-socfpga.git - http://git.denx.de/u-boot.git . [v2]: https://www.mail-archive.com/u-boot@lists.denx.de/msg286979.html [v1]: https://www.mail-archive.com/u-boot@lists.denx.de/msg286294.html v2 -> v3 changes - Node for this driver go in /chosen - Update firmware doc and device tree binding doc. Tien Fong Chee (3): doc: Add new doc for file system firmware loader driver model doc: dtbinding: Add file system firmware loader binding document common: Generic loader for file system doc/device-tree-bindings/chosen.txt | 22 +++ doc/device-tree-bindings/misc/fs_loader.txt | 52 ++ doc/driver-model/fs_firmware_loader.txt | 129 +++ drivers/misc/Kconfig| 10 ++ drivers/misc/Makefile | 1 + drivers/misc/fs_loader.c| 238 include/dm/uclass-id.h | 1 + include/fs_loader.h | 28 8 files changed, 481 insertions(+) create mode 100644 doc/device-tree-bindings/misc/fs_loader.txt create mode 100644 doc/driver-model/fs_firmware_loader.txt create mode 100644 drivers/misc/fs_loader.c create mode 100644 include/fs_loader.h -- 2.2.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 1/3] doc: Add new doc for file system firmware loader driver model
From: Tien Fong Chee
Provide information about
- overview of file system firmware loader driver model
- describe storage device and partition in device tree source
- describe fie system firmware loader API
Signed-off-by: Tien Fong Chee
---
doc/driver-model/fs_firmware_loader.txt | 129
1 file changed, 129 insertions(+)
create mode 100644 doc/driver-model/fs_firmware_loader.txt
diff --git a/doc/driver-model/fs_firmware_loader.txt
b/doc/driver-model/fs_firmware_loader.txt
new file mode 100644
index 000..102e14b
--- /dev/null
+++ b/doc/driver-model/fs_firmware_loader.txt
@@ -0,0 +1,129 @@
+# Copyright (C) 2018 Intel Corporation
+#
+# SPDX-License-Identifier:GPL-2.0
+
+Introduction
+
+
+This is file system firmware loader for U-Boot framework, which has very close
+to some Linux Firmware API. For the details of Linux Firmware API, you can
refer
+to https://01.org/linuxgraphics/gfx-docs/drm/driver-api/firmware/index.html.
+
+File system firmware loader can be used to load whatever(firmware, image,
+and binary) from the storage device in file system format into target location
+such as memory, then consumer driver such as FPGA driver can program FPGA image
+from the target location into FPGA.
+
+To enable firmware loader, CONFIG_FS_LOADER need to be set at
+_defconfig such as "CONFIG_FS_LOADER=y".
+
+Firmware Loader API core features
+-
+
+Firmware storage device described in device tree source
+---
+ For passing data like storage device and partition where the firmware
+ loading from to the firmware loader driver, those data could be
+ defined in fs_loader node as shown in below:
+
+ fs_loader0: fs_loader@0 {
+ u-boot,dm-pre-reloc;
+ compatible = "fs_loader";
+ storage_device = "mmc";
+ devpart = "0:1";
+ };
+
+ Then, firmware_loader property would be set with the path of fs_loader
+ node under /chosen node such as:
+ /{
+ chosen {
+ firmware_loader = _loader0;
+ };
+ };
+
+ Example of storage type and device partition search set for mmc, usb,
+ sata and ubi as shown in below:
+ Example for mmc:
+ fs_loader0: fs_loader@0 {
+ u-boot,dm-pre-reloc;
+ compatible = "fs_loader";
+ storage_device = "mmc";
+ devpart = "0:1";
+ };
+
+ Example for usb:
+ fs_loader1: fs_loader@1 {
+ u-boot,dm-pre-reloc;
+ compatible = "fs_loader";
+ storage_device = "usb";
+ devpart = "0:1";
+ };
+
+ Example for sata:
+ fs_loader2: fs_loader@2 {
+ u-boot,dm-pre-reloc;
+ compatible = "fs_loader";
+ storage_device = "sata";
+ devpart = "0:1";
+ };
+
+ Example for ubi:
+ fs_loader3: fs_loader@3 {
+ u-boot,dm-pre-reloc;
+ compatible = "fs_loader";
+ storage_device = "ubi";
+ mtdpart = "UBI",
+ ubivol = "ubi0";
+ };
+
+
+ However, the property of devpart, mtdpart, and ubivol values from
+ fs_loader node can be overwritten with value which is defined in the
+ environment variable "fw_dev_part", "fw_ubi_mtdpart", and
+ "fw_ubi_volume" respectively.
+ For example: env_set("fw_dev_part", "0:2");
+
+File system firmware Loader API
+---
+
+int request_firmware_into_buf(struct device_platdata *plat,
+struct firmware **firmware_p,
+const char *name,
+void *buf, size_t size, u32 offset)
+
+Load firmware into a previously allocated buffer
+
+Parameters:
+
+1. struct device_platdata *plat
+ Platform data such as storage and partition firmware loading from
+
+2. struct firmware **firmware_p
+ pointer to firmware image
+
+3. const char *name
+ name of firmware file
+
+4. void *buf
+ address of buffer to load firmware into
+
+5. size_t size
+ size of buffer
+
+6. u32 offset
+ offset of a file for start reading into buffer
+
+return:
+ size of total read
+ -ve when error
+
+Description:
+ The firmware is loaded directly into the buffer pointed to by buf and
+ the @firmware_p data member is pointed at buf
+
+Example of creating firmware loader instance and calling
+request_firmware_into_buf API:
+ if (uclass_get_device(UCLASS_FS_FIRMWARE_LOADER, 0, )) {
+ request_firmware_into_buf(dev->plat, , filename,
+buffer_location, buffer_size, offset_ofreading);
+ }
--
2.2.0
___
Re: [U-Boot] [linux-sunxi] [PATCH 00/13] Allwinner H6 support (w/ SPL)
On Mon, Jun 25, 2018 at 6:19 PM, Icenowy Zheng wrote: > > > 于 2018年6月25日 GMT+08:00 下午8:40:21, Jagan Teki 写到: >>On Mon, Jun 25, 2018 at 4:07 PM, Icenowy Zheng wrote: >>> This patch trys to add support for Allwinner H6 SoC to U-Boot. >>> >>> Allwinner H6 is a quite new Allwinner SoC, with several parts changed >>a >>> lot (memory map, DRAM controller, CCU, so on). The position which SPL >>> will be loaded (SRAM A1) also changed to 0x2. >>> >>> The Pine H64 board support comes with this patchset, as this is the >>> first H6 board that I can get (being early bird). >>> >>> Icenowy Zheng (13): >>> sunxi: change SUNXI_HIGH_SRAM option to SUNXI_SRAM_ADDRESS >>> sunxi: add basical memory map definitions of H6 SoC >>> sunxi: change RMR64's RVBAR address for H6 >>> sunxi: change ATF position for H6 >>> sunxi: add config for SPL at 0x2 on H6 >>> sunxi: change GIC address on H6 >>> sunxi: add clock code for H6 >>> sunxi: use sun6i-style watchdog for H6 >>> sunxi: add UART0 setup for H6 >>> sunxi: add MMC support for H6 >>> sunxi: add DRAM support to H6 >>> sunxi: add support for Allwinner H6 SoC >>> sunxi: add support for Pine H64 board >> >>is it on top of master? unable to apply for testing on master, point >>me the branch would help. > > sunxi/next. please send it, on top of master ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] lib: fdtdec: Add new variable ram_start to global data
On Mon, Jun 25, 2018 at 08:15:34AM +0200, Michal Simek wrote: > Hi, > > On 22.6.2018 21:28, Simon Glass wrote: > > Hi, > > > > On 22 June 2018 at 01:41, Michal Simek wrote: > >> Hi Simon, > >> > >> On 18.6.2018 08:18, Siva Durga Prasad Paladugu wrote: > >>> Added new variable ram_start to global data structure for holding > >>> the start address of first bank of RAM, and then use this ram_start > >>> for calculating ram_top properly. This patch fixes the erroneous > >>> calculation of ram_top incase of non zero ram start address. > >>> This patch also renames fdtdec_setup_memory_size() to > >>> fdtdec_setup_mem_size_start() as this routine now takes care > >>> of memory size and start. > >>> > >>> Signed-off-by: Siva Durga Prasad Paladugu > >>> Signed-off-by: Michal Simek > >>> --- > >>> Changes from v2: > >>> - Used new varibale ram_start > >>> - Rename fdtdec_setup_memory_size > >>> > >>> Changes from v1: > >>> - None > >>> --- > >>> arch/arm/mach-mvebu/arm64-common.c | 2 +- > >>> board/emulation/qemu-arm/qemu-arm.c | 2 +- > >>> board/renesas/alt/alt.c | 2 +- > >>> board/renesas/blanche/blanche.c | 2 +- > >>> board/renesas/draak/draak.c | 2 +- > >>> board/renesas/eagle/eagle.c | 2 +- > >>> board/renesas/gose/gose.c| 2 +- > >>> board/renesas/koelsch/koelsch.c | 2 +- > >>> board/renesas/lager/lager.c | 2 +- > >>> board/renesas/porter/porter.c| 2 +- > >>> board/renesas/salvator-x/salvator-x.c| 2 +- > >>> board/renesas/silk/silk.c| 2 +- > >>> board/renesas/stout/stout.c | 2 +- > >>> board/renesas/ulcb/ulcb.c| 2 +- > >>> board/st/stm32f429-discovery/stm32f429-discovery.c | 2 +- > >>> board/st/stm32f429-evaluation/stm32f429-evaluation.c | 2 +- > >>> board/st/stm32f469-discovery/stm32f469-discovery.c | 2 +- > >>> board/st/stm32h743-disco/stm32h743-disco.c | 2 +- > >>> board/st/stm32h743-eval/stm32h743-eval.c | 2 +- > >>> board/xilinx/zynq/board.c| 2 +- > >>> board/xilinx/zynqmp/zynqmp.c | 2 +- > >>> board/xilinx/zynqmp_r5/board.c | 2 +- > >>> common/board_f.c | 4 ++-- > >>> include/asm-generic/global_data.h| 1 + > >>> include/fdtdec.h | 16 > >>> +--- > >>> lib/fdtdec.c | 3 ++- > >>> tools/patman/func_test.py| 2 +- > >>> tools/patman/test/-cover-letter.patch| 2 +- > >>> ...orrect-cast-for-sandbox-in-fdtdec_setup_memory_.patch | 4 ++-- > >>> tools/patman/test/test01.txt | 2 +- > >>> 30 files changed, 41 insertions(+), 37 deletions(-) > > > > [...] > > > >> sjg: Do you see any issue with this patch? > > > > I think it is OK. Would like to get more people to look at it though. > > > >> > >> I can't see the reason for fixing tools/patman but I will wait for you. > > > > Changing patman tests is OK with me. Keeps thing consistent. > > thanks Simon. > > Tom: Do you see any issue with this change? Yes, thanks. You can take it via your tree once Marek has had a chance to test things. Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 02/13] sunxi: add basical memory map definitions of H6 SoC
于 2018年6月25日 GMT+08:00 下午8:33:34, Maxime Ripard 写到: >On Mon, Jun 25, 2018 at 06:37:12PM +0800, Icenowy Zheng wrote: >> The Allwinner H6 SoC come with a totally new memory map. >> >> Add basical definition of the new memory map into a header file, and >let >> the cpu.h header include it in the situation of H6. >> >> Signed-off-by: Icenowy Zheng >> --- >> arch/arm/include/asm/arch-sunxi/cpu.h | 2 + >> .../include/asm/arch-sunxi/cpu_sun50i_h6.h| 73 >+++ >> 2 files changed, 75 insertions(+) >> create mode 100644 arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h >> >> diff --git a/arch/arm/include/asm/arch-sunxi/cpu.h >b/arch/arm/include/asm/arch-sunxi/cpu.h >> index caec865264..08be963e8e 100644 >> --- a/arch/arm/include/asm/arch-sunxi/cpu.h >> +++ b/arch/arm/include/asm/arch-sunxi/cpu.h >> @@ -9,6 +9,8 @@ >> >> #if defined(CONFIG_MACH_SUN9I) >> #include >> +#elif defined(CONFIG_MACH_SUN50I_H6) >> +#include >> #else >> #include >> #endif >> diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h >b/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h >> new file mode 100644 >> index 00..b12f2dd1a2 >> --- /dev/null >> +++ b/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h >> @@ -0,0 +1,73 @@ >> +/* >> + * (C) Copyright 2017 Icenowy Zheng >> + * >> + * SPDX-License-Identifier: GPL-2.0+ >> + */ >> + >> +#ifndef _SUNXI_CPU_SUN50I_H6_H >> +#define _SUNXI_CPU_SUN50I_H6_H >> + >> +#define SUNXI_SRAM_A1_BASE 0x0002 > >Isn't that the same thing than SUNXI_SRAM_ADDRESS? Having it defined >twice and expecting the value to be matching seems a bit weird. This assumes SPL will be in SRAM A1, which may change. > >Maxime ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCH 00/13] Allwinner H6 support (w/ SPL)
于 2018年6月25日 GMT+08:00 下午8:40:21, Jagan Teki 写到: >On Mon, Jun 25, 2018 at 4:07 PM, Icenowy Zheng wrote: >> This patch trys to add support for Allwinner H6 SoC to U-Boot. >> >> Allwinner H6 is a quite new Allwinner SoC, with several parts changed >a >> lot (memory map, DRAM controller, CCU, so on). The position which SPL >> will be loaded (SRAM A1) also changed to 0x2. >> >> The Pine H64 board support comes with this patchset, as this is the >> first H6 board that I can get (being early bird). >> >> Icenowy Zheng (13): >> sunxi: change SUNXI_HIGH_SRAM option to SUNXI_SRAM_ADDRESS >> sunxi: add basical memory map definitions of H6 SoC >> sunxi: change RMR64's RVBAR address for H6 >> sunxi: change ATF position for H6 >> sunxi: add config for SPL at 0x2 on H6 >> sunxi: change GIC address on H6 >> sunxi: add clock code for H6 >> sunxi: use sun6i-style watchdog for H6 >> sunxi: add UART0 setup for H6 >> sunxi: add MMC support for H6 >> sunxi: add DRAM support to H6 >> sunxi: add support for Allwinner H6 SoC >> sunxi: add support for Pine H64 board > >is it on top of master? unable to apply for testing on master, point >me the branch would help. sunxi/next. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6cuboxi: Move the default environment for all devices
On Mon, Jun 25, 2018 at 7:39 AM, Baruch Siach wrote: > From: Jon Nettleton > > Previously we had stored the environment right after the > u-boot.img on the disk. I never liked this because with dtbs > being included and such the image could grow in size. Instead > we move the environment to be negatively offset from the 1MB > mark. Almost all our images start at 4MB's, and most standard > images start at 1MB, and all our storage devices are a minimum > 1MB. Therefore we can store env there for all classes of devices > and have plenty of space in case u-boot.img needs to grow. > > Signed-off-by: Jon Nettleton > Signed-off-by: Baruch Siach Looks good: Reviewed-by: Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCH 00/13] Allwinner H6 support (w/ SPL)
On Mon, Jun 25, 2018 at 4:07 PM, Icenowy Zheng wrote: > This patch trys to add support for Allwinner H6 SoC to U-Boot. > > Allwinner H6 is a quite new Allwinner SoC, with several parts changed a > lot (memory map, DRAM controller, CCU, so on). The position which SPL > will be loaded (SRAM A1) also changed to 0x2. > > The Pine H64 board support comes with this patchset, as this is the > first H6 board that I can get (being early bird). > > Icenowy Zheng (13): > sunxi: change SUNXI_HIGH_SRAM option to SUNXI_SRAM_ADDRESS > sunxi: add basical memory map definitions of H6 SoC > sunxi: change RMR64's RVBAR address for H6 > sunxi: change ATF position for H6 > sunxi: add config for SPL at 0x2 on H6 > sunxi: change GIC address on H6 > sunxi: add clock code for H6 > sunxi: use sun6i-style watchdog for H6 > sunxi: add UART0 setup for H6 > sunxi: add MMC support for H6 > sunxi: add DRAM support to H6 > sunxi: add support for Allwinner H6 SoC > sunxi: add support for Pine H64 board is it on top of master? unable to apply for testing on master, point me the branch would help. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 00/20] SPI-NAND support
Am Montag, 25. Juni 2018, 11:09:41 CEST schrieb Boris Brezillon: > +Richard to comment on the MTD abstraction stuff and how uboot port > of UBI might be impacted by some changes requested here. > > Hi Jagan, > > On Mon, 25 Jun 2018 13:59:37 +0530 > Jagan Teki wrote: > > > > > I've looked the code on the respective patches, look like most of the > > code copy from Linux by adding __UBOOT__. I have no issue with Linux > > copy but we need to structure the code according to U-Boot in the form > > of driver-model (this series lack with that). > > > > Here are my suggestions, based the MTD work so-far > > > > First we need to design MTD driver-model which can capable to drive > > one driver from each interface. (not converting all interface drivers > > at once, that is taking more time and other issues) > > > > Like Linux MTD, U-Boot should have MTD dm for underlying flash devices > > like nand, parallel nor, spinor etc. So to drive this theory with > > driver model(with an example of block layer) mtd is common device > > interaction for most of memory technology flashes like nand, > > parallel nor, spinor etc, these are treated as interface types wrt > > u-boot driver model. > > > > Once the respective interface driver bind happen, the uclass driver > > will pass an 'interface type' to mtd layer to create device for it, > > for example once spinor ULASS_SPI_NOR driver bind happen, the uclass > > driver of spinor will pass MTD_IF_TYPE_SPI_NOR > > interface type to create mtd device for spinor devices. > > > > So If we add this design to SPI-NAND changes, we need to implement > > - MTD dm core that can driver all interfaces > > That's already what the MTD framework provides, and Miquel even added > some stuff to integrate the MTD layer even further in the DM. It's > probably not perfect yet, but the changes are, IMHO, going in the right > direction. > > Now, if you're talking about the new MTD API that creates helper > functions prefixed with dm_, sorry, but I don't see the point. We > already have plenty of MTD users in u-boot, they all manipulate MTD > objects and go through the standard MTD API to do that. What you > suggest would make things messier for several reasons: > > 1/ we won't be able to easily port Linux code to u-boot. Look at the >JFFS2 UBI support. They all use mtd_info objects. What's the point of >changing that except making things harder to port. > > 2/ Not all MTD providers will be converted to the device model at once, >so how do you plan to deal with that? > > 3/ What's the benefit of exposing yet another way to manipulate MTD >devices? > > > - one driver for raw nand > > Unfortunately, that's not how it works right now, and clearly, we > don't have time to work on this raw NAND rework right now. > > > - one driver for spinand > > I think that's already the case. > > > - spi-mem > > It's also what Miquel is doing in this series. > > > - convert fsl-qspi to spi-mem > > We're not targeting the fsl-qspi controller here but a simple SPI > controller that is already upstreamed. But yes, the fsl-qspi driver > will have to be patched to support the spi-mem interface at some point. > > > - implement command to handle > > This I don't get. What do you mean by "implement command to handle"? > Are we talking about cmd/mtd.c? I think the work Miquel has done is > already a good start, what's missing in there? > > > > > For spi-nor interface design, we have an example code here[2] > > > > I've paused this [2] series because of dm conversion of spi-drivers > > otherwise I need add legacy code like mmc-legacy.c, so if we really > > move to spi-mem design and okay with above design. I will try to move > > the current spi flash to add MTD driver-model so-that we can add > > spi-mem, spi-nand on top of it or we can work together to convert them > > all. > > Why can't we do things iteratively. I mean, if the long term goal is to > convert everything to the driver model, then this patchset is going in > the right direction: > - addition of DM helpers to the MTD_UCLASS > - addition of the spi-mem interface properly integrated in the DM >model of the SPI framework > - addition of a SPI NAND driver, again properly integrated in the DM > - integration of DM-ready MTD drivers and old MTD drivers in a single >view exposed by the cmd/mtd.c command set > > I'd really like to limit the scope of this development to these topics, > which doesn't prevent you from converting other part of u-boot to the > spi-mem approach (SPI NOR is one example). > > I hope you understand our concerns and the fact that what you're asking > us to do as a dependency of getting SPI NAND support + cmd/mtd.c merged > is way more than we can actually provide. +1 As someone who is concerned that UBI and UBIFS are sane within u-boot I'm not at all in favor of adding such a layer. The current MTD framework does not need another abstraction level. It will make keeping u-boot in sync
Re: [U-Boot] [PATCH 02/13] sunxi: add basical memory map definitions of H6 SoC
On Mon, Jun 25, 2018 at 06:37:12PM +0800, Icenowy Zheng wrote: > The Allwinner H6 SoC come with a totally new memory map. > > Add basical definition of the new memory map into a header file, and let > the cpu.h header include it in the situation of H6. > > Signed-off-by: Icenowy Zheng > --- > arch/arm/include/asm/arch-sunxi/cpu.h | 2 + > .../include/asm/arch-sunxi/cpu_sun50i_h6.h| 73 +++ > 2 files changed, 75 insertions(+) > create mode 100644 arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h > > diff --git a/arch/arm/include/asm/arch-sunxi/cpu.h > b/arch/arm/include/asm/arch-sunxi/cpu.h > index caec865264..08be963e8e 100644 > --- a/arch/arm/include/asm/arch-sunxi/cpu.h > +++ b/arch/arm/include/asm/arch-sunxi/cpu.h > @@ -9,6 +9,8 @@ > > #if defined(CONFIG_MACH_SUN9I) > #include > +#elif defined(CONFIG_MACH_SUN50I_H6) > +#include > #else > #include > #endif > diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h > b/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h > new file mode 100644 > index 00..b12f2dd1a2 > --- /dev/null > +++ b/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h > @@ -0,0 +1,73 @@ > +/* > + * (C) Copyright 2017 Icenowy Zheng > + * > + * SPDX-License-Identifier: GPL-2.0+ > + */ > + > +#ifndef _SUNXI_CPU_SUN50I_H6_H > +#define _SUNXI_CPU_SUN50I_H6_H > + > +#define SUNXI_SRAM_A1_BASE 0x0002 Isn't that the same thing than SUNXI_SRAM_ADDRESS? Having it defined twice and expecting the value to be matching seems a bit weird. Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 01/13] sunxi: change SUNXI_HIGH_SRAM option to SUNXI_SRAM_ADDRESS
On Mon, Jun 25, 2018 at 06:37:11PM +0800, Icenowy Zheng wrote: > The new Allwinner H6 SoC has its SRAM A1 at neither 0x0 nor 0x1, but > it's at 0x2. Thus the SUNXI_HIGH_SRAM option needs to be refactored > to support this new configuration. > > Change it to SUNXI_SRAM_ADDRESS, which holds the real address of SRAM > A1 in the memory map. > > Signed-off-by: Icenowy Zheng Acked-by: Maxime Ripard Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-x86
On Sun, Jun 24, 2018 at 09:15:32AM +0800, Bin Meng wrote: > Hi Tom, > > This mainly fixes the broken EFI x86 payload support, and some other > small enhancements. > > The following changes since commit 77b5ba5d2b94c5b028991c82782493f64bd4f392: > > Merge branch 'master' of git://git.denx.de/u-boot-uniphier > (2018-06-22 13:12:53 -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-x86.git > > for you to fetch changes up to dd099ec44b5d0a5d2dff537fc5b3b3441a49eec6: > > cmd: efi: Fix wrong memory descriptor end address (2018-06-24 08:56:33 > +0800) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] doc: Replace DocBook with sphinx-based docs
Hi Tom, On Mon, Jun 18, 2018 at 9:04 PM, Tom Rini wrote: > On Thu, Jun 14, 2018 at 10:44:53AM +0200, Mario Six wrote: > >> The Linux kernel moved to sphinx-based documentation and got rid of the >> DocBook based documentation quite a while ago. Hence, the DocBook >> documentation for U-Boot should be converted as well. >> >> To achieve this, import the necessary files from Linux v4.17-r6, and >> convert the current DocBook documentation (three files altogether) to >> sphinx/reStructuredText. >> >> For now, all old DocBook documentation was merged into a single >> handbook, tentatively named "U-Boot Hacker Manual". >> >> For some source files, the documentation style was changed to comply >> with kernel-doc; no functional changes were applied. >> >> Signed-off-by: Mario Six > > I like this idea, thanks for doing it. While I wish more stuff was done > for DocBook, and rST isn't my favorite style, it's worth I think > strongly considering the switch to as I expect some of my own usage > issues to be better by now or be addressed sooner rather than later as > more people pick up the tools, find problems, and fix them. > > -- > Tom > First, thanks for the review! Should I send a proper patch, or are you going to pull it in as-is? While we're on the subject of documentation: I was looking for a place to document the fact that sphinx-based docs are now available, and found myself unsure of where to put that information, so I took a look at all the available sources of documentation: There's the wiki, the README, the docbook/sphinx documents (pretty much a proxy for the embedded documentation in the source files), and the documents located under doc/. The wiki contains mostly "user documentation" (most of it in the manual), like documentation for the command-line commands, and environment variables, but it seems to be quite outdated in a lot of places. But there are also sections on development methods, code quality or design principles, most of which seem to be current. The README contains "overview documentation" (for lack of a better term), is aimed at both "users" and "developers", and is current in some, but outdated in lots of other places (e.g. some of the mentioned boards don't even exist in the sources anymore). The docbook/sphinx documents, seem to be more "developer-centric", since it's (for now) generated from the embedded API docs, which are, as far as I can tell, pretty up-to-date if they exist. Also, infering from the "Bootloader Hackers Manual" title from the docbook documents, there at least seemed to be the idea to make some kind of developer manual in the past. The documents under doc/ are a aggregation of documentation on specific topics, like docs for special driver subsystems, or descriptions of the operation of subsystems (like the DM overview), as well as guides for specific technologies, and how-tos (like the DM-conversion guides). All with varying degrees of currentness. Hence, my two questions are as follows: Where should which kind of documentation (aside from the API documentation, obviously) go? Especially considerig the aspect that it's desireable that we keep the duplication to a minimum (there seems to be at least some duplication between the README and the manual from the wiki). And: What kinds of documentation should exist? I think, e.g., a kind of developer's manual that explains concepts, teaches best practices, and also explains the rationales behind some decisions would be pretty useful (the sphinx-based documentation would be suitable for this, I think), as would be a manual that explains how to build, install and use U-Boot (which would be pretty much the manual from the wiki, just updated). Best regards, Mario ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ubifs: avoid memory corruption during ubifsmount
Sometimes, at boot time, following issue appears:
Error reading superblock on volume 'ubi0:boot' errno=-22!
This error is coming from wrong ubi_num and wrong ubi_id in the superblock.
(ubi_num = -1 and vol_id = -1).
It appears that following line in sget function:
hlist_add_head(>s_instances, >fs_supers);
corrupts the superblock structure.
By checking ubifs source code, s_instances parameter is not used anymore.
So, by setting this parameter and the associated source code under
__UBOOT__ compilation switch solves this issue.
Signed-off-by: Christophe Kerello
Signed-off-by: Patrice Chotard
---
fs/ubifs/super.c | 8
fs/ubifs/ubifs.h | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
index abdef1e6ab8d..9603163d8a04 100644
--- a/fs/ubifs/super.c
+++ b/fs/ubifs/super.c
@@ -2360,7 +2360,9 @@ static struct super_block *alloc_super(struct
file_system_type *type, int flags)
return ERR_PTR(err);
}
+#ifndef __UBOOT__
INIT_HLIST_NODE(>s_instances);
+#endif
INIT_LIST_HEAD(>s_inodes);
s->s_time_gran = 10;
s->s_flags = flags;
@@ -2429,14 +2431,12 @@ retry:
#ifndef __UBOOT__
strlcpy(s->s_id, type->name, sizeof(s->s_id));
list_add_tail(>s_list, _blocks);
-#else
- strncpy(s->s_id, type->name, sizeof(s->s_id));
-#endif
hlist_add_head(>s_instances, >fs_supers);
-#ifndef __UBOOT__
spin_unlock(_lock);
get_filesystem(type);
register_shrinker(>s_shrink);
+#else
+ strncpy(s->s_id, type->name, sizeof(s->s_id));
#endif
return s;
}
diff --git a/fs/ubifs/ubifs.h b/fs/ubifs/ubifs.h
index 78c3a68216e1..512fdaa1444d 100644
--- a/fs/ubifs/ubifs.h
+++ b/fs/ubifs/ubifs.h
@@ -316,8 +316,8 @@ struct super_block {
struct backing_dev_info *s_bdi;
#endif
struct mtd_info *s_mtd;
- struct hlist_node s_instances;
#ifndef __UBOOT__
+ struct hlist_node s_instances;
struct quota_info s_dquot;/* Diskquota specific options */
#endif
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] bootefi disk probe once?
Hi Bin, On 06/25/2018 03:44 AM, Bin Meng wrote: Hi Alex, Heinrich, During testing bootefi command, I found that: If I type 'bootefi' at first time, and forgot to probe the disk before, I got: Found 0 disks Later I did the disk probe (eg: usb start, or scsi scan), and re-run 'bootefi', the disk was not probed for the 2nd time by 'bootefi'. Is this bug, or intended design? Phew, it's the way things work today. We basically create our object model on the first bootefi invocation. Any later invocation just reuses the existing object model and any new object on the U-Boot side doesn't automatically get instantiated as a new EFI object. The reason it works that way is that previous EFI applications (such as iPXE) may leave objects around after they exit, similar to DOS TSR programs. Those objects should not disappear when you invoke the next bootefi command. I think ideally this should be fixed long term by merging DM and EFI object support. But this is nothing we can quickly change. Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v8 14/30] efi: Don't build sandbox with __attribute__((ms_abi))
On 06/23/2018 04:16 PM, Simon Glass wrote: Hi Alex, On 23 June 2018 at 01:28, Alexander Graf wrote: On 22.06.18 21:28, Simon Glass wrote: Hi Alex, On 22 June 2018 at 06:11, Alexander Graf wrote: On 06/21/2018 09:45 PM, Simon Glass wrote: Hi Alex, On 21 June 2018 at 03:59, Alexander Graf wrote: On 06/21/2018 04:02 AM, Simon Glass wrote: Hi Alex, On 20 June 2018 at 02:56, Alexander Graf wrote: On 06/20/2018 12:02 AM, Simon Glass wrote: Hi Alex, On 18 June 2018 at 08:46, Alexander Graf wrote: On 06/18/2018 04:08 PM, Simon Glass wrote: There appears to be a bug [1] in gcc when using varargs with this attribute. Disable it for sandbox so that functions which use that can work correctly, such as install_multiple_protocol_interfaces(). [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70955 Signed-off-by: Simon Glass See my patch instead please. OK I see it now. Do you know what gcc fixes this problem? The bug you found was really just a gcc bug that hit early gcc6 versions. I doubt you're running into it :). OK, so in fact gcc does not support varargs problems with the ms_abi? Gcc needs to know whether varargs are sysv varargs or ms varargs. And it differentiates between the two with different variable types for va_list. Have you seen the builtin_va_list, etc. I think this sentence is missing content? I thought that builtin_va_list and friends would work regardless of the calling standard being used. But it looks (from your patch) like you have to explicitly use __builtin_ms_va_list. Is that right? I'm fairly sure builtin_va_list is just gcc's way of mapping the sysv va_list, but I'm not 100% sure. I can double check with our compiler people next week. OK looking forward to hearing. I'm not sure when the builtin came in, but if it has been around for a while, and it supports both calling standards, then it would be nice to use it. So according to our toolchain people the builtin is really just the internal gcc name for va_list, so it still adheres to the default calling ABI in its semantics. Apparently what one *can* do is to add -mabi=ms to the compiler flags which basically makes every function follow the ms abi. If that is set *maybe* va_list will also adhere to it. However, both him and me like the explicit approach (of this patch) better. He also quickly explained why the function abi can't directly have an effect on va_list. Basically at the parsing stage, gcc does not know if you want to use a va_list for yourself or to pass it into a function you call. And depending on that, you may want either a sysv abi va_list or an ms_abi va_list. Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/7] video_display: Add Xilinx LogiCore DP TX
Hi Anatolij,
On Sat, May 26, 2018 at 12:24 AM, Anatolij Gustschin wrote:
> Hi Mario,
>
> Please test the patch with ./scripts/checkpatch.pl, there are warnings/
> errors reported that need fixing:
> ...
> total: 1 errors, 31 warnings, 26 checks, 2746 lines checked
>
Right, sorry, will be fixed in v3.
> On Wed, 23 May 2018 14:10:47 +0200
> Mario Six mario@gdsys.cc wrote:
> ...
>> diff --git a/drivers/video/Makefile b/drivers/video/Makefile
>> index cf7ad281c3b..fa4ac715fcf 100644
>> --- a/drivers/video/Makefile
>> +++ b/drivers/video/Makefile
>> @@ -21,6 +21,7 @@ obj-$(CONFIG_VIDEO_IVYBRIDGE_IGD) += ivybridge_igd.o
>>
>> obj-$(CONFIG_ATI_RADEON_FB) += ati_radeon_fb.o videomodes.o
>> obj-$(CONFIG_ATMEL_HLCD) += atmel_hlcdfb.o
>> +obj-$(CONFIG_LOGICORE_DP_TX) += logicore_dp_tx.o
>
> Please add new driver entry sorted alphabetically. I know there are
> already not sorted entries in the list here, but we shouldn't add more.
>
OK, I'll add a patch that sorts the entries, and add the new entry with respect
to the new ordering.
> ...
>> diff --git a/drivers/video/logicore_dp_dpcd.h
>> b/drivers/video/logicore_dp_dpcd.h
>> new file mode 100644
>> index 000..68582945514
>> --- /dev/null
>> +++ b/drivers/video/logicore_dp_dpcd.h
> ...
>> +struct main_stream_attributes {
>> + /* Pixel clock of the stream (in Hz). */
>> + u32 pixel_clock_hz;
>> + /* Miscellaneous stream attributes 0 as specified by the DisplayPort
>> + * 1.2 specification.
>> + */
>
> Please fix multi-line comment style throughout this patch, we use this style:
> /*
> * multi-line
> * comment
> */
>
Will be fixed in v3.
> ...
>> +static u32 get_reg(struct udevice *dev, u32 reg)
>> +{
>> + struct dp_tx *dp_tx = dev_get_priv(dev);
>> + u32 value = 0;
>> + int res;
>> +
>> + // TODO error handling
>
> please no C++ comments.
>
Overlooked that one. Will be fixed in v3.
> ...
>> +bool is_connected(struct udevice *dev)
>> +{
>
> shouldn't it be static?
>
Yes, good idea, I'll declare it static for v3.
> ...
>> +
>> +bool is_link_rate_valid(struct udevice *dev, u8 link_rate)
>> +{
>
> ...
>> +bool is_lane_count_valid(struct udevice *dev, u8 lane_count)
>> +{
>
> Are these functions supposed to be used externally? If not, please add
> static. Otherwise move them to /* external API */ section.
>
No, the U-Boot driver doesn't use them outside the file. I'll mark them static
in v3.
> ...
>> +int logicore_dp_tx_enable(struct udevice *dev, int panel_bpp,
>> + const struct display_timing *timing)
>> +{
>
> should be static?
>
Dito.
> ...
>> +int logicore_dp_tx_probe(struct udevice *dev)
>> +{
>
> should be static?
>
> ...
>> +struct dm_display_ops logicore_dp_tx_ops = {
>> + .enable = logicore_dp_tx_enable,
>> +};
>
> should be static, too.
>
Dito.
> ...
>> diff --git a/drivers/video/logicore_dp_tx_regif.h
>> b/drivers/video/logicore_dp_tx_regif.h
>> new file mode 100644
>> index 000..c4105605c9b
>> --- /dev/null
>> +++ b/drivers/video/logicore_dp_tx_regif.h
> ...
>> + /* core ID */
>> + REG_VERSION = 0x0F8,
>> + REG_CORE_ID = 0x0FC,
>
> here a space and tabs follow '=', please use tabs only.
>
> ...
>> + REG_USER_PIXEL_WIDTH = 0x1B8,
>> + REG_USER_DATA_COUNT_PER_LANE =0x1BC,
>
> spaces around '=', checkpatch will report style issues like this.
>
I'll fix the whitespace issues in v3.
> ...
>> +/*
>> + * PHY_STATUS_ALL_LANES_READY_MASK seems zo be missing lanes 0 and 1 in
>
> s/zo/to ?
>
Yeah, that's a typo. Will fix in v3.
> Thanks,
>
Thanks for reviewing, and best regards,
Mario
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] mx6cuboxi: Move the default environment for all devices
From: Jon Nettleton Previously we had stored the environment right after the u-boot.img on the disk. I never liked this because with dtbs being included and such the image could grow in size. Instead we move the environment to be negatively offset from the 1MB mark. Almost all our images start at 4MB's, and most standard images start at 1MB, and all our storage devices are a minimum 1MB. Therefore we can store env there for all classes of devices and have plenty of space in case u-boot.img needs to grow. Signed-off-by: Jon Nettleton Signed-off-by: Baruch Siach --- include/configs/mx6cuboxi.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/mx6cuboxi.h b/include/configs/mx6cuboxi.h index a647aaba685c..7fa63fd93550 100644 --- a/include/configs/mx6cuboxi.h +++ b/include/configs/mx6cuboxi.h @@ -146,6 +146,6 @@ /* Environment organization */ #define CONFIG_ENV_SIZE(8 * 1024) -#define CONFIG_ENV_OFFSET (8 * 64 * 1024) +#define CONFIG_ENV_OFFSET (SZ_1M - CONFIG_ENV_SIZE) #endif /* __MX6CUBOXI_CONFIG_H */ -- 2.18.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 13/13] sunxi: add support for Pine H64 board
Pine H64 is a SBC with Allwinner H6 SoC produced by Pine64. It features
1GiB/2GiB/4GiB(3GiB usable) DRAM, two USB 2.0 ports, one USB 3.0 port
and a mPCIE slot.
Add support for it.
Signed-off-by: Icenowy Zheng
---
arch/arm/dts/Makefile | 2 +
arch/arm/dts/sun50i-h6-pine-h64.dts | 64 +
board/sunxi/MAINTAINERS | 5 +++
configs/pine_h64_defconfig | 15 +++
4 files changed, 86 insertions(+)
create mode 100644 arch/arm/dts/sun50i-h6-pine-h64.dts
create mode 100644 configs/pine_h64_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index ab0b2568ea..0ef2165e3c 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -376,6 +376,8 @@ dtb-$(CONFIG_MACH_SUN50I_H5) += \
sun50i-h5-orangepi-pc2.dtb \
sun50i-h5-orangepi-prime.dtb \
sun50i-h5-orangepi-zero-plus2.dtb
+dtb-$(CONFIG_MACH_SUN50I_H6) += \
+ sun50i-h6-pine-h64.dtb
dtb-$(CONFIG_MACH_SUN50I) += \
sun50i-a64-bananapi-m64.dtb \
sun50i-a64-nanopi-a64.dtb \
diff --git a/arch/arm/dts/sun50i-h6-pine-h64.dts
b/arch/arm/dts/sun50i-h6-pine-h64.dts
new file mode 100644
index 00..8e4f3b38fe
--- /dev/null
+++ b/arch/arm/dts/sun50i-h6-pine-h64.dts
@@ -0,0 +1,64 @@
+/*
+ * Copyright (c) 2017 Icenowy Zheng
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "sun50i-h6.dtsi"
+
+#include
+
+/ {
+ model = "Pine H64";
+ compatible = "pine64,pine-h64", "allwinner,sun50i-h6";
+
+ aliases {
+ serial0 =
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+ {
+ status = "okay";
+};
diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
index 5d31bcbdcd..59fc5c372c 100644
--- a/board/sunxi/MAINTAINERS
+++ b/board/sunxi/MAINTAINERS
@@ -352,6 +352,11 @@ M: Andre Przywara
S: Maintained
F: configs/pine64_plus_defconfig
+PINE H64 BOARD
+M: Icenowy Zheng
+S: Maintained
+F: configs/pine_h64_defconfig
+
R16 EVB PARROT BOARD
M: Quentin Schulz
S: Maintained
diff --git a/configs/pine_h64_defconfig b/configs/pine_h64_defconfig
new file mode 100644
index 00..e9596c0284
--- /dev/null
+++ b/configs/pine_h64_defconfig
@@ -0,0 +1,15 @@
+CONFIG_ARM=y
+CONFIG_ARCH_SUNXI=y
+CONFIG_MACH_SUN50I_H6=y
+CONFIG_DRAM_ODT_EN=y
+CONFIG_MMC0_CD_PIN="PF6"
+CONFIG_MMC_SUNXI_SLOT_EXTRA=2
+# CONFIG_PSCI_RESET is not set
+CONFIG_DEFAULT_DEVICE_TREE="sun50i-h6-pine-h64"
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_SPL=y
+# CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_FPGA is not set
+# CONFIG_SPL_DOS_PARTITION is not set
+# CONFIG_SPL_ISO_PARTITION is not set
+# CONFIG_SPL_EFI_PARTITION is not set
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 10/13] sunxi: add MMC support for H6
The Allwinner H6 SoC has 3 MMC controllers like the ones in A64, with
the MMC2 come with the capability to do crypto by EMCE.
Add MMC support for H6. EMCE support is not added yet.
Signed-off-by: Icenowy Zheng
---
arch/arm/include/asm/arch-sunxi/mmc.h | 2 +-
board/sunxi/board.c | 7 +++
drivers/mmc/sunxi_mmc.c | 13 -
3 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/mmc.h
b/arch/arm/include/asm/arch-sunxi/mmc.h
index 69f737f3bf..4fce9218ff 100644
--- a/arch/arm/include/asm/arch-sunxi/mmc.h
+++ b/arch/arm/include/asm/arch-sunxi/mmc.h
@@ -46,7 +46,7 @@ struct sunxi_mmc {
u32 chda; /* 0x90 */
u32 cbda; /* 0x94 */
u32 res2[26];
-#ifdef CONFIG_SUNXI_GEN_SUN6I
+#if defined(CONFIG_SUNXI_GEN_SUN6I) || defined(CONFIG_MACH_SUN50I_H6)
u32 res3[64];
#endif
u32 fifo; /* 0x100 / 0x200 FIFO access address */
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index a5789090c0..4853fe7e00 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -444,6 +444,13 @@ static void mmc_pinmux_setup(int sdc)
sunxi_gpio_set_pull(pin, SUNXI_GPIO_PULL_UP);
sunxi_gpio_set_drv(pin, 2);
}
+#elif defined(CONFIG_MACH_SUN50I_H6)
+ /* SDC2: PC4-PC14 */
+ for (pin = SUNXI_GPC(4); pin <= SUNXI_GPC(14); pin++) {
+ sunxi_gpio_set_cfgpin(pin, SUNXI_GPC_SDC2);
+ sunxi_gpio_set_pull(pin, SUNXI_GPIO_PULL_UP);
+ sunxi_gpio_set_drv(pin, 2);
+ }
#elif defined(CONFIG_MACH_SUN9I)
/* SDC2: PC6-PC16 */
for (pin = SUNXI_GPC(6); pin <= SUNXI_GPC(16); pin++) {
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 5292f2d3cc..2f6e9058d1 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -71,10 +71,12 @@ static int mmc_resource_init(int sdc_no)
priv->reg = (struct sunxi_mmc *)SUNXI_MMC2_BASE;
priv->mclkreg = >sd2_clk_cfg;
break;
+#ifdef SUNXI_MMC3_BASE
case 3:
priv->reg = (struct sunxi_mmc *)SUNXI_MMC3_BASE;
priv->mclkreg = >sd3_clk_cfg;
break;
+#endif
default:
printf("Wrong mmc number %d\n", sdc_no);
return -1;
@@ -117,6 +119,9 @@ static int mmc_set_mod_clk(struct sunxi_mmc_priv *priv,
unsigned int hz)
#ifdef CONFIG_MACH_SUN9I
pll = CCM_MMC_CTRL_PLL_PERIPH0;
pll_hz = clock_get_pll4_periph0();
+#elif defined(CONFIG_MACH_SUN50I_H6)
+ pll = CCM_MMC_CTRL_PLL6X2;
+ pll_hz = clock_get_pll6() * 2;
#else
pll = CCM_MMC_CTRL_PLL6;
pll_hz = clock_get_pll6();
@@ -495,7 +500,7 @@ struct mmc *sunxi_mmc_init(int sdc_no)
cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34;
cfg->host_caps = MMC_MODE_4BIT;
-#if defined(CONFIG_MACH_SUN50I) || defined(CONFIG_MACH_SUN8I)
+#if defined(CONFIG_MACH_SUN50I) || defined(CONFIG_MACH_SUN8I) ||
defined(CONFIG_MACH_SUN50I_H6)
if (sdc_no == 2)
cfg->host_caps = MMC_MODE_8BIT;
#endif
@@ -510,6 +515,7 @@ struct mmc *sunxi_mmc_init(int sdc_no)
/* config ahb clock */
debug("init mmc %d clock and io\n", sdc_no);
+#if !defined(CONFIG_MACH_SUN50I_H6)
setbits_le32(>ahb_gate0, 1 << AHB_GATE_OFFSET_MMC(sdc_no));
#ifdef CONFIG_SUNXI_GEN_SUN6I
@@ -520,6 +526,11 @@ struct mmc *sunxi_mmc_init(int sdc_no)
/* sun9i has a mmc-common module, also set the gate and reset there */
writel(SUNXI_MMC_COMMON_CLK_GATE | SUNXI_MMC_COMMON_RESET,
SUNXI_MMC_COMMON_BASE + 4 * sdc_no);
+#endif
+#else /* CONFIG_MACH_SUN50I_H6 */
+ setbits_le32(>sd_gate_reset, 1 << sdc_no);
+ /* unassert reset */
+ setbits_le32(>sd_gate_reset, 1 << (RESET_SHIFT + sdc_no));
#endif
ret = mmc_set_mod_clk(priv, 2400);
if (ret)
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 11/13] sunxi: add DRAM support to H6
The Allwinner H6 SoC comes with a set of new DRAM controller+PHY combo.
Both the controller and the PHY seem to be originate from DesignWare,
and are similar to the ones in ZynqMP SoCs.
This commit introduces an initial DRAM driver for H6, which contains
only LPDDR3 support. The currently known SBCs with H6 all come with
LPDDR3 memory, including Pine H64 and several Orange Pi's.
The BSP DRAM initialization code is closed source and violates GPL. Code
in this commit is written by experimenting, referring the code/document
of other users of the IPs (mainly the ZynqMP, as it's the only found PHY
reference) and disassebling the BSP blob.
Thanks for Jernej Skrabec for review and fix some issues in this driver
(including the most critical one which made it to work), and rewrite
some code from register dump!
Signed-off-by: Icenowy Zheng
---
arch/arm/include/asm/arch-sunxi/dram.h| 2 +
.../include/asm/arch-sunxi/dram_sun50i_h6.h | 276 +++
arch/arm/mach-sunxi/Kconfig | 6 +
arch/arm/mach-sunxi/Makefile | 1 +
arch/arm/mach-sunxi/dram_sun50i_h6.c | 708 ++
5 files changed, 993 insertions(+)
create mode 100644 arch/arm/include/asm/arch-sunxi/dram_sun50i_h6.h
create mode 100644 arch/arm/mach-sunxi/dram_sun50i_h6.c
diff --git a/arch/arm/include/asm/arch-sunxi/dram.h
b/arch/arm/include/asm/arch-sunxi/dram.h
index 80abac95b8..cc11fca8ef 100644
--- a/arch/arm/include/asm/arch-sunxi/dram.h
+++ b/arch/arm/include/asm/arch-sunxi/dram.h
@@ -28,6 +28,8 @@
#include
#elif defined(CONFIG_MACH_SUN9I)
#include
+#elif defined(CONFIG_MACH_SUN50I_H6)
+#include
#else
#include
#endif
diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h6.h
b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h6.h
new file mode 100644
index 00..fe138b8cc0
--- /dev/null
+++ b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h6.h
@@ -0,0 +1,276 @@
+/*
+ * H6 dram controller register and constant defines
+ *
+ * (C) Copyright 2017 Icenowy Zheng
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _SUNXI_DRAM_SUN50I_H6_H
+#define _SUNXI_DRAM_SUN50I_H6_H
+
+enum sunxi_dram_type {
+ SUNXI_DRAM_TYPE_DDR3 = 3,
+ SUNXI_DRAM_TYPE_DDR4,
+ SUNXI_DRAM_TYPE_LPDDR2 = 6,
+ SUNXI_DRAM_TYPE_LPDDR3,
+};
+
+/*
+ * The following information is mainly retrieved by disassembly and some FPGA
+ * test code of sun50iw3 platform.
+ */
+struct sunxi_mctl_com_reg {
+ u32 cr; /* 0x000 control register */
+ u8 reserved_0x004[4]; /* 0x004 */
+ u32 unk_0x008; /* 0x008 */
+ u32 tmr;/* 0x00c timer register */
+ u8 reserved_0x010[4]; /* 0x010 */
+ u32 unk_0x014; /* 0x014 */
+ u8 reserved_0x018[8]; /* 0x018 */
+ u32 maer0; /* 0x020 master enable register 0 */
+ u32 maer1; /* 0x024 master enable register 1 */
+ u32 maer2; /* 0x028 master enable register 2 */
+ u8 reserved_0x02c[468]; /* 0x02c */
+ u32 bwcr; /* 0x200 bandwidth control register */
+ u8 reserved_0x204[12]; /* 0x204 */
+ /*
+* The last master configured by BSP libdram is at 0x49x, so the
+* size of this struct array is set to 41 (0x29) now.
+*/
+ struct {
+ u32 cfg0; /* 0x0 */
+ u32 cfg1; /* 0x4 */
+ u8 reserved_0x8[8]; /* 0x8 */
+ } master[41]; /* 0x210 + index * 0x10 */
+};
+check_member(sunxi_mctl_com_reg, master[40].reserved_0x8, 0x498);
+
+/*
+ * The following register information are retrieved from some similar DRAM
+ * controllers, including the DRAM controllers in Allwinner A23/A80 SoCs,
+ * Rockchip RK3328 SoC, NXP i.MX7 SoCs and Xilinx Zynq UltraScale+ SoCs.
+ *
+ * The DRAM controller in Allwinner A23/A80 SoCs and NXP i.MX7 SoCs seems
+ * to be older than the one in Allwinner H6, as the DRAMTMG9 register
+ * is missing in these SoCs. (From the product specifications of these
+ * SoCs they're not capable of DDR4)
+ *
+ * Information sources:
+ * - dram_sun9i.h and dram_sun8i_a23.h in the same directory.
+ * - sdram_rk3328.h from the RK3328 TPL DRAM patchset
+ * - i.MX 7Solo Applications Processor Reference Manual (IMX7SRM)
+ * - Zynq UltraScale+ MPSoC Register Reference (UG1087)
+ */
+struct sunxi_mctl_ctl_reg {
+ u32 mstr; /* 0x000 */
+ u32 statr; /* 0x004 unused */
+ u32 mstr1; /* 0x008 unused */
+ u32 unk_0x00c; /* 0x00c */
+ u32 mrctrl0;/* 0x010 unused */
+ u32 mrctrl1;/* 0x014 unused */
+ u32 mrstatr;/* 0x018 unused */
+ u32 mrctrl2;/* 0x01c unused */
+ u32 derateen; /* 0x020 unused */
+ u32 derateint; /* 0x024 unused */
+ u8 reserved_0x028[8]; /* 0x028 */
+ u32 pwrctl; /*
[U-Boot] [PATCH 09/13] sunxi: add UART0 setup for H6
The UART0 on H6 is available at PH bank (and PF bank, but the PF one is
muxed with SD card).
Add pinmux configuration.
Signed-off-by: Icenowy Zheng
---
arch/arm/include/asm/arch-sunxi/gpio.h | 1 +
arch/arm/mach-sunxi/board.c| 4
2 files changed, 5 insertions(+)
diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h
b/arch/arm/include/asm/arch-sunxi/gpio.h
index 24f85206c8..5acc3033f5 100644
--- a/arch/arm/include/asm/arch-sunxi/gpio.h
+++ b/arch/arm/include/asm/arch-sunxi/gpio.h
@@ -198,6 +198,7 @@ enum sunxi_gpio_number {
#define SUN6I_GPH_TWI2 2
#define SUN6I_GPH_UART02
#define SUN9I_GPH_UART02
+#define SUN50I_H6_GPH_UART02
#define SUNXI_GPI_SDC3 2
#define SUN7I_GPI_TWI3 3
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index 8105a7dbfc..b04a005efc 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -108,6 +108,10 @@ static int gpio_init(void)
sunxi_gpio_set_cfgpin(SUNXI_GPB(8), SUN50I_GPB_UART0);
sunxi_gpio_set_cfgpin(SUNXI_GPB(9), SUN50I_GPB_UART0);
sunxi_gpio_set_pull(SUNXI_GPB(9), SUNXI_GPIO_PULL_UP);
+#elif CONFIG_CONS_INDEX == 1 && defined(CONFIG_MACH_SUN50I_H6)
+ sunxi_gpio_set_cfgpin(SUNXI_GPH(0), SUN50I_H6_GPH_UART0);
+ sunxi_gpio_set_cfgpin(SUNXI_GPH(1), SUN50I_H6_GPH_UART0);
+ sunxi_gpio_set_pull(SUNXI_GPH(1), SUNXI_GPIO_PULL_UP);
#elif CONFIG_CONS_INDEX == 1 && defined(CONFIG_MACH_SUN8I_A83T)
sunxi_gpio_set_cfgpin(SUNXI_GPB(9), SUN8I_A83T_GPB_UART0);
sunxi_gpio_set_cfgpin(SUNXI_GPB(10), SUN8I_A83T_GPB_UART0);
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 12/13] sunxi: add support for Allwinner H6 SoC
Allwinner H6 is a new SoC from Allwinner features USB3 and PCIe
interfaces.
This patch adds support for it.
As this is a new SoC supported by mainline U-Boot, the MMC env support
is dropped and only FAT env is available.
Signed-off-by: Icenowy Zheng
---
arch/arm/dts/sun50i-h6.dtsi| 140 +
arch/arm/mach-sunxi/Kconfig| 17 +++-
arch/arm/mach-sunxi/cpu_info.c | 2 +
common/spl/Kconfig | 2 +-
4 files changed, 159 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/dts/sun50i-h6.dtsi
diff --git a/arch/arm/dts/sun50i-h6.dtsi b/arch/arm/dts/sun50i-h6.dtsi
new file mode 100644
index 00..50f9146318
--- /dev/null
+++ b/arch/arm/dts/sun50i-h6.dtsi
@@ -0,0 +1,140 @@
+/*
+ * Copyright (C) 2017 Icenowy Zheng
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include
+
+/ {
+ interrupt-parent = <>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ compatible = "arm,cortex-a53", "arm,armv8";
+ device_type = "cpu";
+ reg = <0>;
+ };
+
+ cpu1: cpu@1 {
+ compatible = "arm,cortex-a53", "arm,armv8";
+ device_type = "cpu";
+ reg = <1>;
+ };
+
+ cpu2: cpu@2 {
+ compatible = "arm,cortex-a53", "arm,armv8";
+ device_type = "cpu";
+ reg = <2>;
+ };
+
+ cpu3: cpu@3 {
+ compatible = "arm,cortex-a53", "arm,armv8";
+ device_type = "cpu";
+ reg = <3>;
+ };
+ };
+
+ osc24M: osc24M_clk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <2400>;
+ clock-output-names = "osc24M";
+ };
+
+ osc32k: osc32k_clk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+ clock-output-names = "osc32k";
+ };
+
+ iosc: internal-osc-clk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <1600>;
+ clock-accuracy = <3>;
+ clock-output-names = "iosc";
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = ,
+,
+,
+;
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ gic: interrupt-controller@3021000 {
+ compatible = "arm,gic-400";
+ reg = <0x03021000 0x1000>,
+
[U-Boot] [PATCH 07/13] sunxi: add clock code for H6
The new Allwinner H6 SoC has a brand new CCU layout.
Add clock code for it.
Signed-off-by: Icenowy Zheng
---
arch/arm/include/asm/arch-sunxi/clock.h | 2 +
.../include/asm/arch-sunxi/clock_sun50i_h6.h | 320 ++
arch/arm/mach-sunxi/Makefile | 1 +
arch/arm/mach-sunxi/clock_sun50i_h6.c | 94 +
4 files changed, 417 insertions(+)
create mode 100644 arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
create mode 100644 arch/arm/mach-sunxi/clock_sun50i_h6.c
diff --git a/arch/arm/include/asm/arch-sunxi/clock.h
b/arch/arm/include/asm/arch-sunxi/clock.h
index 3747f74d36..ecbef85f83 100644
--- a/arch/arm/include/asm/arch-sunxi/clock.h
+++ b/arch/arm/include/asm/arch-sunxi/clock.h
@@ -17,6 +17,8 @@
/* clock control module regs definition */
#if defined(CONFIG_MACH_SUN8I_A83T)
#include
+#elif defined(CONFIG_MACH_SUN50I_H6)
+#include
#elif defined(CONFIG_MACH_SUN6I) || defined(CONFIG_MACH_SUN8I) || \
defined(CONFIG_MACH_SUN50I)
#include
diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
b/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
new file mode 100644
index 00..e36937059b
--- /dev/null
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
@@ -0,0 +1,320 @@
+/*
+ * Allwinner H6 clock register definitions
+ *
+ * (C) Copyright 2017 Icenowy Zheng
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _SUNXI_CLOCK_SUN50I_H6_H
+#define _SUNXI_CLOCK_SUN50I_H6_H
+
+struct sunxi_ccm_reg {
+ u32 pll1_cfg; /* 0x000 pll1 (cpux) control */
+ u8 reserved_0x004[12];
+ u32 pll5_cfg; /* 0x010 pll5 (ddr) control */
+ u8 reserved_0x014[12];
+ u32 pll6_cfg; /* 0x020 pll6 (periph0) control */
+ u8 reserved_0x020[4];
+ u32 pll_periph1_cfg;/* 0x028 pll periph1 control */
+ u8 reserved_0x028[4];
+ u32 pll7_cfg; /* 0x030 pll7 (gpu) control */
+ u8 reserved_0x034[12];
+ u32 pll3_cfg; /* 0x040 pll3 (video0) control */
+ u8 reserved_0x044[4];
+ u32 pll_video1_cfg; /* 0x048 pll video1 control */
+ u8 reserved_0x04c[12];
+ u32 pll4_cfg; /* 0x058 pll4 (ve) control */
+ u8 reserved_0x05c[4];
+ u32 pll10_cfg; /* 0x060 pll10 (de) control */
+ u8 reserved_0x064[12];
+ u32 pll9_cfg; /* 0x070 pll9 (hsic) control */
+ u8 reserved_0x074[4];
+ u32 pll2_cfg; /* 0x078 pll2 (audio) control */
+ u8 reserved_0x07c[148];
+ u32 pll5_pat; /* 0x110 pll5 (ddr) pattern */
+ u8 reserved_0x114[20];
+ u32 pll_periph1_pat0; /* 0x128 pll periph1 pattern0 */
+ u32 pll_periph1_pat1; /* 0x12c pll periph1 pattern1 */
+ u32 pll7_pat0; /* 0x130 pll7 (gpu) pattern0 */
+ u32 pll7_pat1; /* 0x134 pll7 (gpu) pattern1 */
+ u8 reserved_0x138[8];
+ u32 pll3_pat0; /* 0x140 pll3 (video0) pattern0 */
+ u32 pll3_pat1; /* 0x144 pll3 (video0) pattern1 */
+ u32 pll_video1_pat0;/* 0x148 pll video1 pattern0 */
+ u32 pll_video1_pat1;/* 0x14c pll video1 pattern1 */
+ u8 reserved_0x150[8];
+ u32 pll4_pat0; /* 0x158 pll4 (ve) pattern0 */
+ u32 pll4_pat1; /* 0x15c pll4 (ve) pattern1 */
+ u32 pll10_pat0; /* 0x160 pll10 (de) pattern0 */
+ u32 pll10_pat1; /* 0x164 pll10 (de) pattern1 */
+ u8 reserved_0x168[8];
+ u32 pll9_pat0; /* 0x170 pll9 (hsic) pattern0 */
+ u32 pll9_pat1; /* 0x174 pll9 (hsic) pattern1 */
+ u32 pll2_pat0; /* 0x178 pll2 (audio) pattern0 */
+ u32 pll2_pat1; /* 0x17c pll2 (audio) pattern1 */
+ u8 reserved_0x180[384];
+ u32 pll1_bias; /* 0x300 pll1 (cpux) bias */
+ u8 reserved_0x304[12];
+ u32 pll5_bias; /* 0x310 pll5 (ddr) bias */
+ u8 reserved_0x314[12];
+ u32 pll6_bias; /* 0x320 pll6 (periph0) bias */
+ u8 reserved_0x324[4];
+ u32 pll_periph1_bias; /* 0x328 pll periph1 bias */
+ u8 reserved_0x32c[4];
+ u32 pll7_bias; /* 0x330 pll7 (gpu) bias */
+ u8 reserved_0x334[12];
+ u32 pll3_bias; /* 0x340 pll3 (video0) bias */
+ u8 reserved_0x344[4];
+ u32 pll_video1_bias;/* 0x348 pll video1 bias */
+ u8 reserved_0x34c[12];
+ u32 pll4_bias; /* 0x358 pll4 (ve) bias */
+ u8 reserved_0x35c[4];
+ u32 pll10_bias; /* 0x360 pll10 (de) bias */
+ u8 reserved_0x364[12];
+ u32 pll9_bias; /* 0x370 pll9 (hsic) bias */
+ u8 reserved_0x374[4];
+ u32 pll2_bias; /* 0x378 pll2 (audio) bias */
+ u8 reserved_0x37c[132];
+ u32 pll1_tun; /* 0x400 pll1 (cpux) tunning */
+ u8 reserved_0x404[252];
+ u32 cpu_axi_cfg;/* 0x500 CPUX/AXI clock control*/
+ u8
[U-Boot] [PATCH 05/13] sunxi: add config for SPL at 0x20000 on H6
On the new Allwinner H6 SoC, the SRAM A2 address (SPL load address) is at 0x2, which is different with any old Allwinner SoCs. Add SPL position and size configuration for this. Signed-off-by: Icenowy Zheng --- include/configs/sunxi-common.h | 5 + 1 file changed, 5 insertions(+) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 0196dd0431..9e1c5fb2a6 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -200,6 +200,11 @@ #else #define LOW_LEVEL_SRAM_STACK 0x00018000 #endif /* !CONFIG_ARM64 */ +#elif CONFIG_SUNXI_SRAM_ADDRESS == 0x2 +#define CONFIG_SPL_TEXT_BASE 0x20060 /* sram start+header */ +#define CONFIG_SPL_MAX_SIZE0x7fa0 /* 32 KiB */ +/* end of SRAM A2 on H6 for now */ +#define LOW_LEVEL_SRAM_STACK 0x00118000 #else #define CONFIG_SPL_TEXT_BASE 0x60/* sram start+header */ #define CONFIG_SPL_MAX_SIZE0x5fa0 /* 24KB on sun4i/sun7i */ -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 04/13] sunxi: change ATF position for H6
H6 has different SRAM A2 address, so the ATF load address is also different. Add judgment code to sunxi 64-bit FIT generation script. It will judge the SoC by the device tree's name. Signed-off-by: Icenowy Zheng --- board/sunxi/mksunxi_fit_atf.sh | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/board/sunxi/mksunxi_fit_atf.sh b/board/sunxi/mksunxi_fit_atf.sh index 36abe9efed..8540c3d88e 100755 --- a/board/sunxi/mksunxi_fit_atf.sh +++ b/board/sunxi/mksunxi_fit_atf.sh @@ -13,6 +13,12 @@ if [ ! -f $BL31 ]; then BL31=/dev/null fi +if [ "$(basename $1 .dtb | cut -d - -f 1-2)" = "sun50i-h6" ]; then + BL31_ADDR=0x104000 +else + BL31_ADDR=0x44000 +fi + cat << __HEADER_EOF /dts-v1/; @@ -35,8 +41,8 @@ cat << __HEADER_EOF type = "firmware"; arch = "arm64"; compression = "none"; - load = <0x44000>; - entry = <0x44000>; + load = <$BL31_ADDR>; + entry = <$BL31_ADDR>; }; __HEADER_EOF -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 06/13] sunxi: change GIC address on H6
As the Allwinner H6 chip has a new memory map, its GIC MMIO address is thus different. Change the address on H6. Signed-off-by: Icenowy Zheng --- include/configs/sun50i.h | 5 + 1 file changed, 5 insertions(+) diff --git a/include/configs/sun50i.h b/include/configs/sun50i.h index b7b67a1ddc..1b3e84c4e9 100644 --- a/include/configs/sun50i.h +++ b/include/configs/sun50i.h @@ -18,8 +18,13 @@ #define CONFIG_SUNXI_USB_PHYS 1 +#ifndef CONFIG_MACH_SUN50I_H6 #define GICD_BASE 0x1c81000 #define GICC_BASE 0x1c82000 +#else +#define GICD_BASE 0x3021000 +#define GICC_BASE 0x3022000 +#endif /* * Include common sunxi configuration where most the settings are -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 08/13] sunxi: use sun6i-style watchdog for H6
The H6 SoC has a sun6i-style watchdog in its timer part.
Enable the usage of it.
Signed-off-by: Icenowy Zheng
---
arch/arm/include/asm/arch-sunxi/timer.h | 2 +-
arch/arm/mach-sunxi/board.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/timer.h
b/arch/arm/include/asm/arch-sunxi/timer.h
index ccdf942534..938067924e 100644
--- a/arch/arm/include/asm/arch-sunxi/timer.h
+++ b/arch/arm/include/asm/arch-sunxi/timer.h
@@ -77,7 +77,7 @@ struct sunxi_timer_reg {
struct sunxi_tgp tgp[4];
u8 res5[8];
u32 cpu_cfg;
-#elif defined(CONFIG_SUNXI_GEN_SUN6I)
+#elif defined(CONFIG_SUNXI_GEN_SUN6I) || defined(CONFIG_MACH_SUN50I_H6)
u8 res3[16];
struct sunxi_wdog wdog[5]; /* We have 5 watchdogs */
#endif
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index 1753faec1d..8105a7dbfc 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -287,7 +287,7 @@ void reset_cpu(ulong addr)
/* sun5i sometimes gets stuck without this */
writel(WDT_MODE_RESET_EN | WDT_MODE_EN, >mode);
}
-#elif defined(CONFIG_SUNXI_GEN_SUN6I)
+#elif defined(CONFIG_SUNXI_GEN_SUN6I) || defined(CONFIG_MACH_SUN50I_H6)
static const struct sunxi_wdog *wdog =
((struct sunxi_timer_reg *)SUNXI_TIMER_BASE)->wdog;
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 03/13] sunxi: change RMR64's RVBAR address for H6
Allwinner H6 has a different RVBAR address with A64/H5. Add conditional RVBAR configuration into the code which does RMR switch. Signed-off-by: Icenowy Zheng --- arch/arm/include/asm/arch-sunxi/boot0.h | 4 arch/arm/mach-sunxi/rmr_switch.S| 6 ++ 2 files changed, 10 insertions(+) diff --git a/arch/arm/include/asm/arch-sunxi/boot0.h b/arch/arm/include/asm/arch-sunxi/boot0.h index 9c6d82dda1..5176fdcfdc 100644 --- a/arch/arm/include/asm/arch-sunxi/boot0.h +++ b/arch/arm/include/asm/arch-sunxi/boot0.h @@ -27,7 +27,11 @@ .word 0xf57ff06f // isb sy .word 0xe320f003 // wfi .word 0xeafd // b @wfi +#ifndef CONFIG_MACH_SUN50I_H6 .word 0x017000a0 // writeable RVBAR mapping address +#else + .word 0x09010040 // writeable RVBAR mapping address +#endif #ifdef CONFIG_SPL_BUILD .word CONFIG_SPL_TEXT_BASE #else diff --git a/arch/arm/mach-sunxi/rmr_switch.S b/arch/arm/mach-sunxi/rmr_switch.S index cefa93001b..fafd306f95 100644 --- a/arch/arm/mach-sunxi/rmr_switch.S +++ b/arch/arm/mach-sunxi/rmr_switch.S @@ -26,9 +26,15 @@ @ reference and to be able to regenerate a (probably fixed) version of this @ code found in encoded form in boot0.h. +#include + .text +#ifndef CONFIG_MACH_SUN50I_H6 ldr r1, =0x017000a0 @ MMIO mapped RVBAR[0] register +#else + ldr r1, =0x09010040 @ MMIO mapped RVBAR[0] register +#endif ldr r0, =0x57aA7add @ start address, to be replaced str r0, [r1] dsb sy -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 01/13] sunxi: change SUNXI_HIGH_SRAM option to SUNXI_SRAM_ADDRESS
The new Allwinner H6 SoC has its SRAM A1 at neither 0x0 nor 0x1, but it's at 0x2. Thus the SUNXI_HIGH_SRAM option needs to be refactored to support this new configuration. Change it to SUNXI_SRAM_ADDRESS, which holds the real address of SRAM A1 in the memory map. Signed-off-by: Icenowy Zheng --- arch/arm/include/asm/arch-sunxi/spl.h | 6 +- arch/arm/mach-sunxi/Kconfig | 14 +- include/configs/sunxi-common.h| 19 +++ 3 files changed, 17 insertions(+), 22 deletions(-) diff --git a/arch/arm/include/asm/arch-sunxi/spl.h b/arch/arm/include/asm/arch-sunxi/spl.h index a70b1797e5..e166568d11 100644 --- a/arch/arm/include/asm/arch-sunxi/spl.h +++ b/arch/arm/include/asm/arch-sunxi/spl.h @@ -12,11 +12,7 @@ #define SPL_SIGNATURE "SPL" /* marks "sunxi" SPL header */ #define SPL_HEADER_VERSION 2 -#ifdef CONFIG_SUNXI_HIGH_SRAM -#define SPL_ADDR 0x1 -#else -#define SPL_ADDR 0x0 -#endif +#define SPL_ADDR CONFIG_SUNXI_SRAM_ADDRESS /* The low 8-bits of the 'boot_media' field in the SPL header */ #define SUNXI_BOOTED_FROM_MMC0 0 diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig index 0a7bd3086a..e3c19b7464 100644 --- a/arch/arm/mach-sunxi/Kconfig +++ b/arch/arm/mach-sunxi/Kconfig @@ -73,16 +73,15 @@ config SUN8I_RSB with various RSB based devices, such as AXP223, AXP8XX PMICs, and AC100/AC200 ICs. -config SUNXI_HIGH_SRAM - bool - default n +config SUNXI_SRAM_ADDRESS + hex + default 0x1 if MACH_SUN9I || MACH_SUN50I || MACH_SUN50I_H5 + default 0x0 ---help--- Older Allwinner SoCs have their mask boot ROM mapped just below 4GB, with the first SRAM region being located at address 0. Some newer SoCs map the boot ROM at address 0 instead and move the - SRAM to 64KB, just behind the mask ROM. - Chips using the latter setup are supposed to select this option to - adjust the addresses accordingly. + SRAM to a different address. # Note only one of these may be selected at a time! But hidden choices are # not supported by Kconfig @@ -252,7 +251,6 @@ config MACH_SUN9I select CPU_V7 select DRAM_SUN9I select SUN6I_PRCM - select SUNXI_HIGH_SRAM select SUNXI_GEN_SUN6I select SUN8I_RSB select SUPPORT_SPL @@ -264,7 +262,6 @@ config MACH_SUN50I select PHY_SUN4I_USB select SUNXI_DE2 select SUNXI_GEN_SUN6I - select SUNXI_HIGH_SRAM select SUPPORT_SPL select SUNXI_DRAM_DW select SUNXI_DRAM_DW_32BIT @@ -275,7 +272,6 @@ config MACH_SUN50I_H5 bool "sun50i (Allwinner H5)" select ARM64 select MACH_SUNXI_H3_H5 - select SUNXI_HIGH_SRAM select FIT select SPL_LOAD_FIT diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 9d9e9ce173..0196dd0431 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -83,20 +83,19 @@ #define CONFIG_SPL_BSS_MAX_SIZE0x0008 /* 512 KiB */ -#ifdef CONFIG_SUNXI_HIGH_SRAM /* * The A80's A1 sram starts at 0x0001 rather then at 0x and is * slightly bigger. Note that it is possible to map the first 32 KiB of the * A1 at 0x like with older SoCs by writing 0x16aa0001 to the * undocumented 0x008000e0 SYS_CTRL register. Where the 16aa is a key and * the 1 actually activates the mapping of the first 32 KiB to 0x. + * A64 and H5 also has SRAM A1 at 0x0001, but no magic remap register + * is known yet. + * H6 has SRAM A1 at 0x0002. */ -#define CONFIG_SYS_INIT_RAM_ADDR 0x1 -#define CONFIG_SYS_INIT_RAM_SIZE 0x08000 /* FIXME: 40 KiB ? */ -#else -#define CONFIG_SYS_INIT_RAM_ADDR 0x0 -#define CONFIG_SYS_INIT_RAM_SIZE 0x8000 /* 32 KiB */ -#endif +#define CONFIG_SYS_INIT_RAM_ADDR CONFIG_SUNXI_SRAM_ADDRESS +/* FIXME: this may be larger on some SoCs */ +#define CONFIG_SYS_INIT_RAM_SIZE 0x8000 /* 32 KiB */ #define CONFIG_SYS_INIT_SP_OFFSET \ (CONFIG_SYS_INIT_RAM_SIZE - GENERATED_GBL_DATA_SIZE) @@ -188,7 +187,11 @@ #define CONFIG_SPL_BOARD_LOAD_IMAGE #endif -#ifdef CONFIG_SUNXI_HIGH_SRAM +/* + * We cannot use expressions here, because expressions won't be evaluated in + * autoconf.mk. + */ +#if CONFIG_SUNXI_SRAM_ADDRESS == 0x1 #define CONFIG_SPL_TEXT_BASE 0x10060 /* sram start+header */ #define CONFIG_SPL_MAX_SIZE0x7fa0 /* 32 KiB */ #ifdef CONFIG_ARM64 -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 02/13] sunxi: add basical memory map definitions of H6 SoC
The Allwinner H6 SoC come with a totally new memory map. Add basical definition of the new memory map into a header file, and let the cpu.h header include it in the situation of H6. Signed-off-by: Icenowy Zheng --- arch/arm/include/asm/arch-sunxi/cpu.h | 2 + .../include/asm/arch-sunxi/cpu_sun50i_h6.h| 73 +++ 2 files changed, 75 insertions(+) create mode 100644 arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h diff --git a/arch/arm/include/asm/arch-sunxi/cpu.h b/arch/arm/include/asm/arch-sunxi/cpu.h index caec865264..08be963e8e 100644 --- a/arch/arm/include/asm/arch-sunxi/cpu.h +++ b/arch/arm/include/asm/arch-sunxi/cpu.h @@ -9,6 +9,8 @@ #if defined(CONFIG_MACH_SUN9I) #include +#elif defined(CONFIG_MACH_SUN50I_H6) +#include #else #include #endif diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h b/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h new file mode 100644 index 00..b12f2dd1a2 --- /dev/null +++ b/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h @@ -0,0 +1,73 @@ +/* + * (C) Copyright 2017 Icenowy Zheng + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#ifndef _SUNXI_CPU_SUN50I_H6_H +#define _SUNXI_CPU_SUN50I_H6_H + +#define SUNXI_SRAM_A1_BASE 0x0002 +#define SUNXI_SRAM_C_BASE 0x00028000 +#define SUNXI_SRAM_A2_BASE 0x0010 + +#define SUNXI_DE3_BASE 0x0100 +#define SUNXI_SS_BASE 0x01904000 +#define SUNXI_EMCE_BASE0x01905000 + +#define SUNXI_SRAMC_BASE 0x0300 +#define SUNXI_CCM_BASE 0x03001000 +#define SUNXI_DMA_BASE 0x03002000 +/* SID address space starts at 0x03006000, but e-fuse is at offset 0x200 */ +#define SUNXI_SIDC_BASE0x03006000 +#define SNUXI_SID_BASE 0x03006200 +#define SUNXI_TIMER_BASE 0x03009000 +#define SUNXI_PIO_BASE 0x0300B000 +#define SUNXI_PSI_BASE 0x0300C000 + +#define SUNXI_GIC400_BASE 0x0302 +#define SUNXI_IOMMU_BASE 0x030F + +#define SUNXI_DRAM_COM_BASE0x04002000 +#define SUNXI_DRAM_CTL0_BASE 0x04003000 +#define SUNXI_DRAM_PHY0_BASE 0x04005000 +#define SUNXI_NFC_BASE 0x04011000 +#define SUNXI_MMC0_BASE0x0402 +#define SUNXI_MMC1_BASE0x04021000 +#define SUNXI_MMC2_BASE0x04022000 + +#define SUNXI_UART0_BASE 0x0500 +#define SUNXI_UART1_BASE 0x05000400 +#define SUNXI_UART2_BASE 0x05000800 +#define SUNXI_UART3_BASE 0x05000C00 +#define SUNXI_TWI0_BASE0x05002000 +#define SUNXI_TWI1_BASE0x05002400 +#define SUNXI_TWI2_BASE0x05002800 +#define SUNXI_TWI3_BASE0x05002C00 +#define SUNXI_SPI0_BASE0x0501 +#define SUNXI_SPI1_BASE0x05011000 +#define SUNXI_GMAC_BASE0x0502 +#define SUNXI_USB0_BASE0x0510 +#define SUNXI_XHCI_BASE0x0520 +#define SUNXI_USB3_BASE0x05311000 +#define SUNXI_PCIE_BASE0x0540 + +#define SUNXI_HDMI_BASE0x0600 +#define SUNXI_TCON_TOP_BASE0x0651 +#define SUNXI_TCON_LCD0_BASE 0x06511000 +#define SUNXI_TCON_TV0_BASE0x06515000 + +#define SUNXI_RTC_BASE 0x0700 +#define SUNXI_R_CPUCFG_BASE0x07000400 +#define SUNXI_PRCM_BASE0x0701 +#define SUNXI_R_PIO_BASE 0x07022000 +#define SUNXI_R_UART_BASE 0x0708 +#define SUNXI_R_TWI_BASE 0x07081400 + +#ifndef __ASSEMBLY__ +void sunxi_board_init(void); +void sunxi_reset(void); +int sunxi_get_sid(unsigned int *sid); +#endif + +#endif /* _SUNXI_CPU_SUN9I_H */ -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 00/13] Allwinner H6 support (w/ SPL)
This patch trys to add support for Allwinner H6 SoC to U-Boot. Allwinner H6 is a quite new Allwinner SoC, with several parts changed a lot (memory map, DRAM controller, CCU, so on). The position which SPL will be loaded (SRAM A1) also changed to 0x2. The Pine H64 board support comes with this patchset, as this is the first H6 board that I can get (being early bird). Icenowy Zheng (13): sunxi: change SUNXI_HIGH_SRAM option to SUNXI_SRAM_ADDRESS sunxi: add basical memory map definitions of H6 SoC sunxi: change RMR64's RVBAR address for H6 sunxi: change ATF position for H6 sunxi: add config for SPL at 0x2 on H6 sunxi: change GIC address on H6 sunxi: add clock code for H6 sunxi: use sun6i-style watchdog for H6 sunxi: add UART0 setup for H6 sunxi: add MMC support for H6 sunxi: add DRAM support to H6 sunxi: add support for Allwinner H6 SoC sunxi: add support for Pine H64 board arch/arm/dts/Makefile | 2 + arch/arm/dts/sun50i-h6-pine-h64.dts | 64 ++ arch/arm/dts/sun50i-h6.dtsi | 140 arch/arm/include/asm/arch-sunxi/boot0.h | 4 + arch/arm/include/asm/arch-sunxi/clock.h | 2 + .../include/asm/arch-sunxi/clock_sun50i_h6.h | 320 arch/arm/include/asm/arch-sunxi/cpu.h | 2 + .../include/asm/arch-sunxi/cpu_sun50i_h6.h| 73 ++ arch/arm/include/asm/arch-sunxi/dram.h| 2 + .../include/asm/arch-sunxi/dram_sun50i_h6.h | 276 +++ arch/arm/include/asm/arch-sunxi/gpio.h| 1 + arch/arm/include/asm/arch-sunxi/mmc.h | 2 +- arch/arm/include/asm/arch-sunxi/spl.h | 6 +- arch/arm/include/asm/arch-sunxi/timer.h | 2 +- arch/arm/mach-sunxi/Kconfig | 37 +- arch/arm/mach-sunxi/Makefile | 2 + arch/arm/mach-sunxi/board.c | 6 +- arch/arm/mach-sunxi/clock_sun50i_h6.c | 94 +++ arch/arm/mach-sunxi/cpu_info.c| 2 + arch/arm/mach-sunxi/dram_sun50i_h6.c | 708 ++ arch/arm/mach-sunxi/rmr_switch.S | 6 + board/sunxi/MAINTAINERS | 5 + board/sunxi/board.c | 7 + board/sunxi/mksunxi_fit_atf.sh| 10 +- common/spl/Kconfig| 2 +- configs/pine_h64_defconfig| 15 + drivers/mmc/sunxi_mmc.c | 13 +- include/configs/sun50i.h | 5 + include/configs/sunxi-common.h| 24 +- 29 files changed, 1802 insertions(+), 30 deletions(-) create mode 100644 arch/arm/dts/sun50i-h6-pine-h64.dts create mode 100644 arch/arm/dts/sun50i-h6.dtsi create mode 100644 arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h create mode 100644 arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h create mode 100644 arch/arm/include/asm/arch-sunxi/dram_sun50i_h6.h create mode 100644 arch/arm/mach-sunxi/clock_sun50i_h6.c create mode 100644 arch/arm/mach-sunxi/dram_sun50i_h6.c create mode 100644 configs/pine_h64_defconfig -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [UBOOT PATCH v3 3/3] spi: xilinx_spi: Added support to read JEDEC-id twice at the boot time
Hi Jagan,
> -Original Message-
> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> Sent: Monday, June 25, 2018 3:47 PM
> To: Vipul Kumar
> Cc: U-Boot Mailing List ; Michal Simek
>
> Subject: Re: [U-Boot] [UBOOT PATCH v3 3/3] spi: xilinx_spi: Added support to
> read JEDEC-id twice at the boot time
>
> On Thu, Jun 21, 2018 at 2:53 PM, Vipul Kumar
> wrote:
> > This patch is for the startup block issue in the spi controller.
> > SPI clock is passing through STARTUP block to FLASH. STARTUP block
> > don't provide clock as soon as QSPI provides command. So, first
> > command fails.
>
> Does this a controller issue?
Yes, this is a controller issue.
>
> >
> > This patch added support to read JEDEC id in xilinx_spi_xfer ().
> >
> > Signed-off-by: Vipul Kumar
> > ---
> > Changes in v3:
> > - No change
> > ---
> > drivers/spi/xilinx_spi.c | 41
> > +
> > 1 file changed, 41 insertions(+)
> >
> > diff --git a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c index
> > 4026540..61301c2 100644
> > --- a/drivers/spi/xilinx_spi.c
> > +++ b/drivers/spi/xilinx_spi.c
> > @@ -204,6 +204,40 @@ static u32 xilinx_spi_read_rxfifo(struct udevice
> *bus, u8 *rxp, u32 rxbytes)
> > return i;
> > }
> >
> > +static void xilinx_startup_block(struct udevice *dev, unsigned int bytes,
> > +const void *dout, void *din) {
> > + struct udevice *bus = dev_get_parent(dev);
> > + struct xilinx_spi_priv *priv = dev_get_priv(bus);
> > + struct xilinx_spi_regs *regs = priv->regs;
> > + struct dm_spi_slave_platdata *slave_plat =
> dev_get_parent_platdata(dev);
> > + const unsigned char *txp = dout;
> > + unsigned char *rxp = din;
> > + static int startup;
> > + u32 reg, count;
> > + u32 txbytes = bytes;
> > + u32 rxbytes = bytes;
> > +
> > + /*
> > +* This loop runs two times. First time to send the command.
> > +* Second time to transfer data. After transferring data,
> > +* it sets txp to the initial value for the normal operation.
> > +*/
> > + for ( ; startup < 2; startup++) {
> > + count = xilinx_spi_fill_txfifo(bus, txp, txbytes);
> > + reg = readl(>spicr) & ~SPICR_MASTER_INHIBIT;
> > + writel(reg, >spicr);
> > + count = xilinx_spi_read_rxfifo(bus, rxp, rxbytes);
> > + txp = din;
> > +
> > + if (startup) {
> > + spi_cs_deactivate(dev);
> > + spi_cs_activate(dev, slave_plat->cs);
> > + txp = dout;
> > + }
> > + }
> > +}
> > +
> > static int xilinx_spi_xfer(struct udevice *dev, unsigned int bitlen,
> > const void *dout, void *din, unsigned long
> > flags) { @@ -236,6 +270,13 @@ static int xilinx_spi_xfer(struct
> > udevice *dev, unsigned int bitlen,
> > if (flags & SPI_XFER_BEGIN)
> > spi_cs_activate(dev, slave_plat->cs);
> >
> > + /*
> > +* This is the work around for the startup block issue in
> > +* the spi controller. SPI clock is passing through STARTUP
> > +* block to FLASH. STARTUP block don't provide clock as soon
> > +* as QSPI provides command. So first command fails.
> > +*/
> > + xilinx_startup_block(dev, bytes, dout, din);
>
> But not every spi_xfer from flash side is to read JEDEC ID? during probe of
> sf,
> the relevant spi_xfer is to read JEDEC ID
Inside xilinx_startup_block() function, we are using static variable, so that
code will execute only first time.
Regards,
Vipul
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] ARM: kirkwood: add SBx81LIFXCAT board
This is a series of line cards for Allied Telesis's SBx8100 chassis
switch. The CPU block is common to the SBx81GP24 and SBx81GT24 cards
cards collectively referred to as SBx81LIFXCAT in u-boot.
Signed-off-by: Chris Packham
---
arch/arm/dts/kirkwood-atl-sbx81lifxcat.dts| 145 ++
arch/arm/mach-kirkwood/Kconfig| 4 +
board/alliedtelesis/SBx81LIFXCAT/Kconfig | 12 ++
board/alliedtelesis/SBx81LIFXCAT/MAINTAINERS | 7 +
board/alliedtelesis/SBx81LIFXCAT/Makefile | 7 +
board/alliedtelesis/SBx81LIFXCAT/kwbimage.cfg | 49 ++
.../alliedtelesis/SBx81LIFXCAT/sbx81lifxcat.c | 134
configs/SBx81LIFXCAT_defconfig| 44 ++
include/configs/SBx81LIFXCAT.h| 114 ++
9 files changed, 516 insertions(+)
create mode 100644 arch/arm/dts/kirkwood-atl-sbx81lifxcat.dts
create mode 100644 board/alliedtelesis/SBx81LIFXCAT/Kconfig
create mode 100644 board/alliedtelesis/SBx81LIFXCAT/MAINTAINERS
create mode 100644 board/alliedtelesis/SBx81LIFXCAT/Makefile
create mode 100644 board/alliedtelesis/SBx81LIFXCAT/kwbimage.cfg
create mode 100644 board/alliedtelesis/SBx81LIFXCAT/sbx81lifxcat.c
create mode 100644 configs/SBx81LIFXCAT_defconfig
create mode 100644 include/configs/SBx81LIFXCAT.h
diff --git a/arch/arm/dts/kirkwood-atl-sbx81lifxcat.dts
b/arch/arm/dts/kirkwood-atl-sbx81lifxcat.dts
new file mode 100644
index ..c23444993623
--- /dev/null
+++ b/arch/arm/dts/kirkwood-atl-sbx81lifxcat.dts
@@ -0,0 +1,145 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+
+#include "kirkwood.dtsi"
+#include "kirkwood-98dx4122.dtsi"
+
+/ {
+ model = "Allied Telesis SBx81LIFXCAT Board";
+ compatible = "atl,SBx8LIFXCAT", "marvell,kirkwood-98DX4122",
+"marvell,kirkwood";
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x0800>; /* 128 MB */
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,115200n8 earlyprintk";
+ stdout-path =
+ };
+
+ aliases {
+ ethernet0 =
+ i2c0 =
+ spi0 =
+ };
+
+ dsa {
+ compatible = "marvell,dsa";
+ #address-cells = <2>;
+ #size-cells = <0>;
+ dsa,ethernet = <>;
+ dsa,mii-bus = <>;
+ status = "okay";
+
+ switch@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1 0>;
+
+ port@0 {
+ reg = <0>;
+ label = "internal0";
+ };
+ port@1 {
+ reg = <1>;
+ label = "internal1";
+ };
+ port@8 {
+ reg = <8>;
+ label = "internal8";
+ phy-mode = "rgmii-id";
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+ port@9 {
+ reg = <9>;
+ label = "internal9";
+ phy-mode = "rgmii-id";
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+ port@10 {
+ reg = <10>;
+ label = "cpu";
+ };
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+
+ ledn {
+ label = "status:ledn";
+ gpios = < 14 GPIO_ACTIVE_HIGH>;
+ };
+
+ ledp {
+ label = "status:ledp";
+ gpios = < 15 GPIO_ACTIVE_HIGH>;
+ };
+ };
+};
+
+ {
+ status = "okay";
+
+ flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "st,m25p128", "jedec,spi-nor", "spi-flash";
+ reg = <0>;
+ spi-max-frequency = <5000>;
+ mode = <0>;
+
+ partition@u-boot {
+ reg = <0x 0x00c0>;
+ label = "u-boot";
+ };
+ partition@u-boot-env {
+ reg = <0x00c0 0x0004>;
+ label = "u-boot-env";
+ };
+ partition@unused {
+ reg = <0x0010 0x00f0>;
+ label = "unused";
+
[U-Boot] [PATCH 1/2] net: mv88e61xx: add configuration for RGMII delay
Some hardware designs connect a CPU MAC directly to the RGMII interface
of a mv88e61xx device. On such devices a delay on the RX/TX lines is
required, this can either be achieved by adding extra length to the
traces on the PCB or by implementing the delay in silicon. This is
an implementation of the latter.
Signed-off-by: Chris Packham
---
drivers/net/phy/Kconfig | 4
drivers/net/phy/mv88e61xx.c | 26 ++
2 files changed, 30 insertions(+)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index f5821dfed96d..98cd57eea977 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -59,6 +59,10 @@ config MV88E61XX_PHY_PORTS
config MV88E61XX_FIXED_PORTS
hex "Bitmask of PHYless serdes Ports"
+config MV88E61XX_RGMII_DELAY
+ bool "Add delay to RGMII outputs"
+ default n
+
endif # MV88E61XX_SWITCH
config PHYLIB_10G
diff --git a/drivers/net/phy/mv88e61xx.c b/drivers/net/phy/mv88e61xx.c
index ea54a1531053..d258ba1ef0f3 100644
--- a/drivers/net/phy/mv88e61xx.c
+++ b/drivers/net/phy/mv88e61xx.c
@@ -69,6 +69,7 @@
#define PORT_REG_CTRL 0x04
#define PORT_REG_VLAN_MAP 0x06
#define PORT_REG_VLAN_ID 0x07
+#define PORT_REG_RGMII_TIMING 0x1A
/* Phy registers */
#define PHY_REG_CTRL1 0x10
@@ -122,6 +123,9 @@
#define PORT_REG_VLAN_MAP_TABLE_SHIFT 0
#define PORT_REG_VLAN_MAP_TABLE_WIDTH 11
+#define PORT_REG_RGMII_TIMING_RX_DELAY BIT(10)
+#define PORT_REG_RGMII_TIMING_TX_DELAY BIT(9)
+
#define SERDES_REG_CTRL_1_FORCE_LINK BIT(10)
#define PHY_REG_CTRL1_ENERGY_DET_SHIFT 8
@@ -705,6 +709,24 @@ unforce:
return res;
}
+static int mv88e61xx_rgmii_timing_cfg(struct phy_device *phydev)
+{
+#ifdef CONFIG_MV88E61XX_RGMII_DELAY
+ int val;
+
+ val = mv88e61xx_port_read(phydev, 6, PORT_REG_RGMII_TIMING);
+ if (val < 0)
+ return val;
+
+ val |= PORT_REG_RGMII_TIMING_RX_DELAY |
+ PORT_REG_RGMII_TIMING_TX_DELAY;
+
+ return mv88e61xx_port_write(phydev, 6, PORT_REG_RGMII_TIMING, val);
+#else
+ return 0;
+#endif
+}
+
static int mv88e61xx_fixed_port_setup(struct phy_device *phydev, u8 port)
{
int val;
@@ -774,6 +796,10 @@ static int mv88e61xx_set_cpu_port(struct phy_device
*phydev)
return val;
}
} else {
+ val = mv88e61xx_rgmii_timing_cfg(phydev);
+ if (val < 0)
+ return val;
+
val = mv88e61xx_fixed_port_setup(phydev,
CONFIG_MV88E61XX_CPU_PORT);
if (val < 0)
--
2.18.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] configs: Disable 4k erase sector size for spansion "s25fs512s" flash
4K erase size is used only in case of hydrid mode which is not supported on any NXP platform with flash "s25fs512s". Supported mode is uniform sector, with erase size 256kiB. Signed-off-by: Ashish Kumar --- configs/ls1046aqds_qspi_defconfig| 1 + configs/ls1046aqds_sdcard_qspi_defconfig | 1 + configs/ls1046ardb_qspi_SECURE_BOOT_defconfig| 1 + configs/ls1046ardb_qspi_defconfig| 1 + configs/ls1088aqds_qspi_SECURE_BOOT_defconfig| 1 + configs/ls1088aqds_qspi_defconfig| 1 + configs/ls1088aqds_sdcard_qspi_defconfig | 1 + configs/ls1088ardb_qspi_SECURE_BOOT_defconfig| 1 + configs/ls1088ardb_qspi_defconfig| 1 + configs/ls1088ardb_sdcard_qspi_SECURE_BOOT_defconfig | 1 + configs/ls1088ardb_sdcard_qspi_defconfig | 1 + configs/ls2080aqds_qspi_defconfig| 1 + configs/ls2088ardb_qspi_SECURE_BOOT_defconfig| 1 + configs/ls2088ardb_qspi_defconfig| 1 + 14 files changed, 14 insertions(+) diff --git a/configs/ls1046aqds_qspi_defconfig b/configs/ls1046aqds_qspi_defconfig index 4f3290c..a770039 100644 --- a/configs/ls1046aqds_qspi_defconfig +++ b/configs/ls1046aqds_qspi_defconfig @@ -41,6 +41,7 @@ CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_FSL_DSPI=y CONFIG_FSL_QSPI=y +CONFIG_SPI_FLASH_USE_4K_SECTORS=n CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y diff --git a/configs/ls1046aqds_sdcard_qspi_defconfig b/configs/ls1046aqds_sdcard_qspi_defconfig index 45d80b9..79b1d04 100644 --- a/configs/ls1046aqds_sdcard_qspi_defconfig +++ b/configs/ls1046aqds_sdcard_qspi_defconfig @@ -48,6 +48,7 @@ CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_FSL_DSPI=y CONFIG_FSL_QSPI=y +CONFIG_SPI_FLASH_USE_4K_SECTORS=n CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y diff --git a/configs/ls1046ardb_qspi_SECURE_BOOT_defconfig b/configs/ls1046ardb_qspi_SECURE_BOOT_defconfig index adc5db3..3c18913 100644 --- a/configs/ls1046ardb_qspi_SECURE_BOOT_defconfig +++ b/configs/ls1046ardb_qspi_SECURE_BOOT_defconfig @@ -37,6 +37,7 @@ CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_FSL_QSPI=y +CONFIG_SPI_FLASH_USE_4K_SECTORS=n CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y diff --git a/configs/ls1046ardb_qspi_defconfig b/configs/ls1046ardb_qspi_defconfig index c87fe97..b375572 100644 --- a/configs/ls1046ardb_qspi_defconfig +++ b/configs/ls1046ardb_qspi_defconfig @@ -38,6 +38,7 @@ CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_FSL_QSPI=y +CONFIG_SPI_FLASH_USE_4K_SECTORS=n CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y diff --git a/configs/ls1088aqds_qspi_SECURE_BOOT_defconfig b/configs/ls1088aqds_qspi_SECURE_BOOT_defconfig index 20376be..f95f30f 100644 --- a/configs/ls1088aqds_qspi_SECURE_BOOT_defconfig +++ b/configs/ls1088aqds_qspi_SECURE_BOOT_defconfig @@ -31,6 +31,7 @@ CONFIG_FSL_ESDHC=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_SPANSION=y +CONFIG_SPI_FLASH_USE_4K_SECTORS=n CONFIG_NETDEVICES=y CONFIG_E1000=y CONFIG_PCI=y diff --git a/configs/ls1088aqds_qspi_defconfig b/configs/ls1088aqds_qspi_defconfig index cf2b4e3..aca13ee 100644 --- a/configs/ls1088aqds_qspi_defconfig +++ b/configs/ls1088aqds_qspi_defconfig @@ -31,6 +31,7 @@ CONFIG_FSL_ESDHC=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_SPANSION=y +CONFIG_SPI_FLASH_USE_4K_SECTORS=n CONFIG_NETDEVICES=y CONFIG_E1000=y CONFIG_PCI=y diff --git a/configs/ls1088aqds_sdcard_qspi_defconfig b/configs/ls1088aqds_sdcard_qspi_defconfig index 8d854da..7a7ab43 100644 --- a/configs/ls1088aqds_sdcard_qspi_defconfig +++ b/configs/ls1088aqds_sdcard_qspi_defconfig @@ -41,6 +41,7 @@ CONFIG_FSL_ESDHC=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_SPANSION=y +CONFIG_SPI_FLASH_USE_4K_SECTORS=n CONFIG_NETDEVICES=y CONFIG_E1000=y CONFIG_PCI=y diff --git a/configs/ls1088ardb_qspi_SECURE_BOOT_defconfig b/configs/ls1088ardb_qspi_SECURE_BOOT_defconfig index db95289..908488a 100644 --- a/configs/ls1088ardb_qspi_SECURE_BOOT_defconfig +++ b/configs/ls1088ardb_qspi_SECURE_BOOT_defconfig @@ -31,6 +31,7 @@ CONFIG_FSL_ESDHC=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_SPANSION=y +CONFIG_SPI_FLASH_USE_4K_SECTORS=n CONFIG_NETDEVICES=y CONFIG_E1000=y CONFIG_PCI=y diff --git a/configs/ls1088ardb_qspi_defconfig b/configs/ls1088ardb_qspi_defconfig index fbb75df..b8cd7e8 100644 --- a/configs/ls1088ardb_qspi_defconfig +++ b/configs/ls1088ardb_qspi_defconfig @@ -31,6 +31,7 @@ CONFIG_FSL_ESDHC=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_SPANSION=y +CONFIG_SPI_FLASH_USE_4K_SECTORS=n CONFIG_NETDEVICES=y CONFIG_E1000=y CONFIG_PCI=y diff --git a/configs/ls1088ardb_sdcard_qspi_SECURE_BOOT_defconfig b/configs/ls1088ardb_sdcard_qspi_SECURE_BOOT_defconfig index e4f0068..297f215 100644 --- a/configs/ls1088ardb_sdcard_qspi_SECURE_BOOT_defconfig +++ b/configs/ls1088ardb_sdcard_qspi_SECURE_BOOT_defconfig @@ -44,6 +44,7
Re: [U-Boot] [UBOOT PATCH v3 3/3] spi: xilinx_spi: Added support to read JEDEC-id twice at the boot time
On Thu, Jun 21, 2018 at 2:53 PM, Vipul Kumar wrote:
> This patch is for the startup block issue in the spi controller.
> SPI clock is passing through STARTUP block to FLASH. STARTUP block
> don't provide clock as soon as QSPI provides command. So, first
> command fails.
Does this a controller issue?
>
> This patch added support to read JEDEC id in xilinx_spi_xfer ().
>
> Signed-off-by: Vipul Kumar
> ---
> Changes in v3:
> - No change
> ---
> drivers/spi/xilinx_spi.c | 41 +
> 1 file changed, 41 insertions(+)
>
> diff --git a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c
> index 4026540..61301c2 100644
> --- a/drivers/spi/xilinx_spi.c
> +++ b/drivers/spi/xilinx_spi.c
> @@ -204,6 +204,40 @@ static u32 xilinx_spi_read_rxfifo(struct udevice *bus,
> u8 *rxp, u32 rxbytes)
> return i;
> }
>
> +static void xilinx_startup_block(struct udevice *dev, unsigned int bytes,
> +const void *dout, void *din)
> +{
> + struct udevice *bus = dev_get_parent(dev);
> + struct xilinx_spi_priv *priv = dev_get_priv(bus);
> + struct xilinx_spi_regs *regs = priv->regs;
> + struct dm_spi_slave_platdata *slave_plat =
> dev_get_parent_platdata(dev);
> + const unsigned char *txp = dout;
> + unsigned char *rxp = din;
> + static int startup;
> + u32 reg, count;
> + u32 txbytes = bytes;
> + u32 rxbytes = bytes;
> +
> + /*
> +* This loop runs two times. First time to send the command.
> +* Second time to transfer data. After transferring data,
> +* it sets txp to the initial value for the normal operation.
> +*/
> + for ( ; startup < 2; startup++) {
> + count = xilinx_spi_fill_txfifo(bus, txp, txbytes);
> + reg = readl(>spicr) & ~SPICR_MASTER_INHIBIT;
> + writel(reg, >spicr);
> + count = xilinx_spi_read_rxfifo(bus, rxp, rxbytes);
> + txp = din;
> +
> + if (startup) {
> + spi_cs_deactivate(dev);
> + spi_cs_activate(dev, slave_plat->cs);
> + txp = dout;
> + }
> + }
> +}
> +
> static int xilinx_spi_xfer(struct udevice *dev, unsigned int bitlen,
> const void *dout, void *din, unsigned long flags)
> {
> @@ -236,6 +270,13 @@ static int xilinx_spi_xfer(struct udevice *dev, unsigned
> int bitlen,
> if (flags & SPI_XFER_BEGIN)
> spi_cs_activate(dev, slave_plat->cs);
>
> + /*
> +* This is the work around for the startup block issue in
> +* the spi controller. SPI clock is passing through STARTUP
> +* block to FLASH. STARTUP block don't provide clock as soon
> +* as QSPI provides command. So first command fails.
> +*/
> + xilinx_startup_block(dev, bytes, dout, din);
But not every spi_xfer from flash side is to read JEDEC ID? during
probe of sf, the relevant spi_xfer is to read JEDEC ID
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] mtd:spi: Correct parameters for s25fs512s flash
Change sector size to 256KiB in table spi_flash_ids.
Signed-off-by: Ashish Kumar
---
drivers/mtd/spi/spi_flash_ids.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/spi/spi_flash_ids.c b/drivers/mtd/spi/spi_flash_ids.c
index c45d2e8..54d491c 100644
--- a/drivers/mtd/spi/spi_flash_ids.c
+++ b/drivers/mtd/spi/spi_flash_ids.c
@@ -110,7 +110,7 @@ const struct spi_flash_info spi_flash_ids[] = {
{"s25fl256s_256k", INFO(0x010219, 0x4d00, 256 * 1024, 128, RD_FULL |
WR_QPP) },
{"s25fs256s_64k", INFO6(0x010219, 0x4d0181, 64 * 1024, 512, RD_FULL |
WR_QPP | SECT_4K) },
{"s25fl256s_64k", INFO(0x010219, 0x4d01, 64 * 1024, 512, RD_FULL |
WR_QPP) },
- {"s25fs512s", INFO6(0x010220, 0x4d0081, 128 * 1024, 512, RD_FULL |
WR_QPP | SECT_4K) },
+ {"s25fs512s", INFO6(0x010220, 0x4d0081, 256 * 1024, 256, RD_FULL |
WR_QPP | SECT_4K) },
{"s25fl512s_256k", INFO(0x010220, 0x4d00, 256 * 1024, 256, RD_FULL |
WR_QPP) },
{"s25fl512s_64k", INFO(0x010220, 0x4d01, 64 * 1024, 1024, RD_FULL |
WR_QPP) },
{"s25fl512s_512k", INFO(0x010220, 0x4f00, 256 * 1024, 256, RD_FULL |
WR_QPP) },
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [UBOOT PATCH v3 2/3] spi: xilinx_spi: Modify transfer logic xilinx_spi_xfer() function
On Thu, Jun 21, 2018 at 2:53 PM, Vipul Kumar wrote:
> This patch modify xilinx_spi_xfer() function and add rxfifo() and
> txfifo() functions to add the modularity so that these functions
> can be used by other functions within the same file.
>
> This patch also added support to read fifo_size from dts.
>
> Signed-off-by: Vipul Kumar
> Signed-off-by: Siva Durga Prasad Paladugu
> ---
> - Changes in v3:
> - Added fifo_depth read support and removed from 1/3
> ---
> drivers/spi/xilinx_spi.c | 102
> +++
> 1 file changed, 67 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c
> index cc5ac51..4026540 100644
> --- a/drivers/spi/xilinx_spi.c
> +++ b/drivers/spi/xilinx_spi.c
> @@ -19,6 +19,7 @@
> #include
> #include
> #include
> +#include
>
> /*
> * [0]: http://www.xilinx.com/support/documentation
> @@ -77,6 +78,8 @@
> #define CONFIG_XILINX_SPI_IDLE_VAL GENMASK(7, 0)
> #endif
>
> +#define XILINX_SPISR_TIMEOUT 1 /* in milliseconds */
> +
> /* xilinx spi register set */
> struct xilinx_spi_regs {
> u32 __space0__[7];
> @@ -101,6 +104,7 @@ struct xilinx_spi_priv {
> struct xilinx_spi_regs *regs;
> unsigned int freq;
> unsigned int mode;
> + unsigned int fifo_depth;
> };
>
> static int xilinx_spi_probe(struct udevice *bus)
> @@ -110,6 +114,9 @@ static int xilinx_spi_probe(struct udevice *bus)
>
> priv->regs = (struct xilinx_spi_regs *)devfdt_get_addr(bus);
>
> + priv->fifo_depth = fdtdec_get_int(gd->fdt_blob, dev_of_offset(bus),
> + "fifo-size", 0);
> +
> writel(SPISSR_RESET_VALUE, >srr);
>
> return 0;
> @@ -157,6 +164,46 @@ static int xilinx_spi_release_bus(struct udevice *dev)
> return 0;
> }
>
> +static u32 xilinx_spi_fill_txfifo(struct udevice *bus, const u8 *txp,
> + u32 txbytes)
> +{
> + struct xilinx_spi_priv *priv = dev_get_priv(bus);
> + struct xilinx_spi_regs *regs = priv->regs;
> + unsigned char d;
> + u32 i = 0;
> +
> + while (txbytes && !(readl(>spisr) & SPISR_TX_FULL) &&
> + i < priv->fifo_depth) {
> + d = txp ? *txp++ : CONFIG_XILINX_SPI_IDLE_VAL;
> + debug("spi_xfer: tx:%x ", d);
> + /* write out and wait for processing (receive data) */
> + writel(d & SPIDTR_8BIT_MASK, >spidtr);
> + txbytes--;
> + i++;
> + }
need space
> + return i;
> +}
> +
> +static u32 xilinx_spi_read_rxfifo(struct udevice *bus, u8 *rxp, u32 rxbytes)
> +{
> + struct xilinx_spi_priv *priv = dev_get_priv(bus);
> + struct xilinx_spi_regs *regs = priv->regs;
> + unsigned char d;
> + unsigned int i = 0;
> +
> + while (rxbytes && !(readl(>spisr) & SPISR_RX_EMPTY)) {
> + d = readl(>spidrr) & SPIDRR_8BIT_MASK;
> + if (rxp)
> + *rxp++ = d;
> + debug("spi_xfer: rx:%x\n", d);
> + rxbytes--;
> + i++;
> + }
> + debug("Rx_done\n");
> +
> + return i;
> +}
Reviewed-by: Jagan Teki
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [UBOOT PATCH v3 1/3] spi: xilinx: Read reg base address from DTS file
On Thu, Jun 21, 2018 at 2:53 PM, Vipul Kumar wrote: > From: Michal Simek > > This patch added support to read register base address > from DTS file. > > Signed-off-by: Michal Simek > Signed-off-by: Vipul Kumar > --- > Changes in v3: > - Read reg in probe function > - Removed xilinx_spi_ofdata_to_platdata function > - Removed reading of fifo_depth > --- Reviewed-by: Jagan Teki ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Fwd: Re: [PATCH v3 2/6] spi: omap3_spi: Full dm conversion
On Mon, Jun 25, 2018 at 3:29 PM, Hannes Schmelzer wrote: > > On 06/24/2018 09:24 PM, Jagan Teki wrote: >> >> On Fri, Jun 22, 2018 at 7:01 PM, Hannes Schmelzer >> wrote: >>> >>> Hi Jagan, >>> >>> anything open ? >>> are the patches ready to apply? >> >> I'm waiting for the board that are using driver should ready for >> dm_spi, and I hope these are not done yet and indeed waiting for board >> maintainers to convert the same. >> >> If possible can you group all you changes along with mine and send >> again to ML, so-that we can force the boards to use DM_SPI >> >> Jagan. > > Hi Jagan, > > actually board maintainers of am335x boards aren't able to convert their > boards to DM_SPI, > since the DM_SPI implementation in master branch doesn't work. > > For this i've sent patches: > > http://patchwork.ozlabs.org/patch/924433/ > http://patchwork.ozlabs.org/patch/924434/ > > I can convert my brppt1 board after this patch has been applied. > Once DM_SPI is working again i will post the series for converting brppt1 > board to DM. > Maybe then others will follow because they have an example to look for if > something doesn't work. Thanks. Applied to u-boot-spi/master. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 6/7] cmd: Add axi command
Hi Simon,
On Fri, May 25, 2018 at 4:41 AM, Simon Glass wrote:
> Hi Mario,
>
> On 23 May 2018 at 06:10, Mario Six wrote:
>> Add a command to debug the AXI bus.
>>
>> Signed-off-by: Mario Six
>>
>> ---
>>
>> v1 -> v2:
>> No changes
>>
>> ---
>> cmd/Kconfig | 8 ++
>> cmd/Makefile | 1 +
>> cmd/axi.c| 310
>> +++
>> 3 files changed, 319 insertions(+)
>> create mode 100644 cmd/axi.c
>
> Reviewed-by: Simon Glass
>
> Comments below.
>
>>
>> diff --git a/cmd/Kconfig b/cmd/Kconfig
>> index 38406fcfdac..0f730f7a397 100644
>> --- a/cmd/Kconfig
>> +++ b/cmd/Kconfig
>> @@ -995,6 +995,14 @@ config CMD_USB_MASS_STORAGE
>> help
>> USB mass storage support
>>
>> +config CMD_AXI
>> + bool "axi"
>> + depends on AXI
>> + help
>> + Enable the command "axi" for accessing AXI (Advanced eXtensible
>> + Interface) busses, a on-chip interconnect specification for
>> managing
>> + functional blocks in SoC designs, which is also often used in
>> designs
>> + involving FPGAs (e.g. communication with IP cores in Xilinx
>> FPGAs).
>> endmenu
>>
>>
>> diff --git a/cmd/Makefile b/cmd/Makefile
>> index 0d7322ee0a4..cfca11499ec 100644
>> --- a/cmd/Makefile
>> +++ b/cmd/Makefile
>> @@ -145,6 +145,7 @@ obj-$(CONFIG_CMD_ZFS) += zfs.o
>> obj-$(CONFIG_CMD_DFU) += dfu.o
>> obj-$(CONFIG_CMD_GPT) += gpt.o
>> obj-$(CONFIG_CMD_ETHSW) += ethsw.o
>> +obj-$(CONFIG_CMD_AXI) += axi.o
>>
>> # Power
>> obj-$(CONFIG_CMD_PMIC) += pmic.o
>> diff --git a/cmd/axi.c b/cmd/axi.c
>> new file mode 100644
>> index 000..d8001875e2c
>> --- /dev/null
>> +++ b/cmd/axi.c
>> @@ -0,0 +1,310 @@
>> +/*
>> + * (C) Copyright 2016
>> + * Dirk Eibach, Guntermann & Drunck GmbH, dirk.eib...@gdsys.cc
>> + *
>> + * (C) Copyright 2017
>> + * Mario Six, Guntermann & Drunck GmbH, mario@gdsys.cc
>> + *
>> + * SPDX-License-Identifier:GPL-2.0+
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +static struct udevice *axi_cur_bus;
>> +static uint dp_last_size;
>> +static uint dp_last_addr;
>> +static uint dp_last_length = 0x40;
>> +
>> +static void show_bus(struct udevice *bus)
>> +{
>> + struct udevice *dev;
>> +
>> + printf("Bus %d:\t%s", bus->req_seq, bus->name);
>> + if (device_active(bus))
>> + printf(" (active %d)", bus->seq);
>> + printf("\n");
>> + for (device_find_first_child(bus, );
>> +dev;
>> +device_find_next_child())
>> + printf(" %s\n", dev->name);
>> +}
>> +
>> +static int do_axi_show_bus(cmd_tbl_t *cmdtp, int flag, int argc,
>> + char * const argv[])
>> +{
>> + if (argc == 1) {
>> + /* show all busses */
>> + struct udevice *bus;
>> +
>> + for (uclass_first_device(UCLASS_AXI, );
>> +bus;
>> +uclass_next_device())
>> + show_bus(bus);
>> + } else {
>> + int i;
>> +
>> + /* show specific bus */
>> + i = simple_strtoul(argv[1], NULL, 10);
>> +
>> + struct udevice *bus;
>> + int ret;
>> +
>> + ret = uclass_get_device_by_seq(UCLASS_AXI, i, );
>
> Here you probe the bus, whereas above you don't. Is that intended?
>
Right, I should probably make sure that the busses are probed in either case,
good point.
Will be fixed in v3.
>> + if (ret) {
>> + printf("Invalid bus %d: err=%d\n", i, ret);
>> + return CMD_RET_FAILURE;
>> + }
>> + show_bus(bus);
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int cmd_axi_set_bus_num(unsigned int busnum)
>> +{
>> + struct udevice *bus;
>> + struct udevice *dummy;
>> + int ret;
>> +
>> + /* Make sure that all sequence numbers are initialized */
>> + for (uclass_first_device(UCLASS_AXI, );
>> +dummy;
>> +uclass_next_device())
>> + ;
>> +
>> + ret = uclass_get_device_by_seq(UCLASS_AXI, busnum, );
>
> Here you probe the bus which seems right to me.
>
I'll use this same approach in the other function as well.
>> + if (ret) {
>> + debug("%s: No bus %d\n", __func__, busnum);
>> + return ret;
>> + }
>> + axi_cur_bus = bus;
>> +
>> + return 0;
>> +}
>> +
> [..]
>
> Regards,
> Simon
Best regards,
Mario
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Fwd: Re: [PATCH v3 2/6] spi: omap3_spi: Full dm conversion
On 06/24/2018 09:24 PM, Jagan Teki wrote: On Fri, Jun 22, 2018 at 7:01 PM, Hannes Schmelzer wrote: Hi Jagan, anything open ? are the patches ready to apply? I'm waiting for the board that are using driver should ready for dm_spi, and I hope these are not done yet and indeed waiting for board maintainers to convert the same. If possible can you group all you changes along with mine and send again to ML, so-that we can force the boards to use DM_SPI Jagan. Hi Jagan, actually board maintainers of am335x boards aren't able to convert their boards to DM_SPI, since the DM_SPI implementation in master branch doesn't work. For this i've sent patches: http://patchwork.ozlabs.org/patch/924433/ http://patchwork.ozlabs.org/patch/924434/ I can convert my brppt1 board after this patch has been applied. Once DM_SPI is working again i will post the series for converting brppt1 board to DM. Maybe then others will follow because they have an example to look for if something doesn't work. cheers, Hannes ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] spi: mxc_spi: Fix chipselect on DM_SPI driver uclass
On Thu, Jun 21, 2018 at 2:21 AM, Michael Trimarchi wrote: > CS GPIO activation low/high is determinated by the device tree > so we don't need to take in accoung in cs_activate and cs_deactivate > > Signed-off-by: Michael Trimarchi > --- Applied to u-boot-spi/master ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/7] test: Add AXI test
Hi Simon, On Fri, May 25, 2018 at 4:41 AM, Simon Glass wrote: > On 23 May 2018 at 06:10, Mario Six wrote: >> Add tests for the AXI uclass. >> >> Signed-off-by: Mario Six >> >> --- >> >> v1 -> v2: >> * Fixed asserts (moved expected values first) >> >> --- >> test/dm/Makefile | 1 + >> test/dm/axi.c| 74 >> >> 2 files changed, 75 insertions(+) >> create mode 100644 test/dm/axi.c > > Reviewed-by: Simon Glass > > Can you please use lower-case hex? > OK, will switch to lower-case for v3. Best regards, Mario ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/7] axi: Add AXI sandbox driver and simple emulator
Hi Simon,
On Fri, May 25, 2018 at 4:41 AM, Simon Glass wrote:
> Hi Mario,
>
> On 23 May 2018 at 06:10, Mario Six wrote:
>> Add test infrastructure and tests for the AXI uclass.
>>
>> Signed-off-by: Mario Six
>>
>> ---
>>
>> v1 -> v2:
>> * Spelled out abbreviations in Kconfig help
>> * Expanded emulation documentation
>> * Renamed storage pointer to storep
>> * Expanded AXI emulator usage documentation
>> * Switched AXI emulator to aligned access
>>
>> ---
>> drivers/axi/Kconfig | 7 +++
>> drivers/axi/Makefile | 3 ++
>> drivers/axi/axi-emul-uclass.c | 68 ++
>> drivers/axi/axi_sandbox.c | 77 +
>> drivers/axi/sandbox_store.c | 110
>> ++
>> include/axi.h | 84
>> include/dm/uclass-id.h| 1 +
>> 7 files changed, 350 insertions(+)
>> create mode 100644 drivers/axi/axi-emul-uclass.c
>> create mode 100644 drivers/axi/axi_sandbox.c
>> create mode 100644 drivers/axi/sandbox_store.c
>>
>
> Reviewed-by: Simon Glass
>
> Some nits below.
>
>> diff --git a/drivers/axi/axi_sandbox.c b/drivers/axi/axi_sandbox.c
>> new file mode 100644
>> index 000..7a485b114bf
>> --- /dev/null
>> +++ b/drivers/axi/axi_sandbox.c
>> @@ -0,0 +1,77 @@
>> +/*
>> + * (C) Copyright 2018
>> + * Mario Six, Guntermann & Drunck GmbH, mario@gdsys.cc
>> + *
>> + * SPDX-License-Identifier:GPL-2.0+
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +
>> +/*
>> + * This driver implements a AXI bus for the sandbox architecture for testing
>> + * purposes.
>> + *
>> + * The bus forwards every access to it to a special AXI emulation device
>> (which
>> + * it gets via the axi_emul_get_ops function) that implements a simple
>> + * read/write storage.
>> + *
>> + * The emulator device must still be contained in the device tree in the
>> usual
>> + * way, since configuration data for the storage is read from the DT.
>> + */
>> +
>> +int axi_sandbox_read(struct udevice *bus, ulong address, void *data,
>> +enum axi_size_t size)
>
> Can this and the write() function below be static?
>
Yes, sure, will be fixed in v3.
>> +{
>> + struct axi_emul_ops *ops;
>> + struct udevice *emul;
>> + int ret;
>> +
>> + /* Get emulator device */
>> + ret = axi_sandbox_get_emul(bus, address, size, );
>> + if (ret)
>> + return ret == -ENODEV ? 0 : ret;
>> + /* Forward all reads to the AXI emulator */
>> + ops = axi_emul_get_ops(emul);
>> + if (!ops || !ops->read)
>> + return -ENOSYS;
>> +
>> + return ops->read(emul, address, data, size);
>> +}
>> +
>> +int axi_sandbox_write(struct udevice *bus, ulong address, void *data,
>> + enum axi_size_t size)
>> +{
>> + struct axi_emul_ops *ops;
>> + struct udevice *emul;
>> + int ret;
>> +
>> + /* Get emulator device */
>> + ret = axi_sandbox_get_emul(bus, address, size, );
>> + if (ret)
>> + return ret == -ENODEV ? 0 : ret;
>> + /* Forward all writes to the AXI emulator */
>> + ops = axi_emul_get_ops(emul);
>> + if (!ops || !ops->write)
>> + return -ENOSYS;
>> +
>> + return ops->write(emul, address, data, size);
>> +}
>> +
>> +static const struct udevice_id axi_sandbox_ids[] = {
>> + { .compatible = "sandbox,axi" },
>> + { /* sentinel */ }
>> +};
>> +
>> +static const struct axi_ops axi_sandbox_ops = {
>> + .read = axi_sandbox_read,
>> + .write = axi_sandbox_write,
>> +};
>> +
>> +U_BOOT_DRIVER(axi_sandbox_bus) = {
>> + .name = "axi_sandbox_bus",
>> + .id = UCLASS_AXI,
>> + .of_match = axi_sandbox_ids,
>> + .ops= _sandbox_ops,
>> +};
>> diff --git a/drivers/axi/sandbox_store.c b/drivers/axi/sandbox_store.c
>> new file mode 100644
>> index 000..61c7aea22c8
>> --- /dev/null
>> +++ b/drivers/axi/sandbox_store.c
>> @@ -0,0 +1,110 @@
>> +/*
>> + * (C) Copyright 2018
>> + * Mario Six, Guntermann & Drunck GmbH, mario@gdsys.cc
>> + *
>> + * SPDX-License-Identifier:GPL-2.0+
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +
>> +struct sandbox_store_priv {
>> + u8 *store;
>> +};
>> +
>> +void copy_axi_data(void *src, void *dst, enum axi_size_t size)
>> +{
>> + u8 *dst8 = dst;
>> + u16 *dst16 = dst;
>> + u32 *dst32 = dst;
>
> Can you put these declarations in the case statements instead? I'm not
> sure what coverity with think of this aliasing.
>
Yeah, coverity probably won't like that. I'll put the casts in the case
statements for v3.
>> +
>> + switch (size) {
>> + case AXI_SIZE_8:
>> + *dst8 = *((u8 *)src);
>> + break;
>> + case AXI_SIZE_16:
>> + *dst16 = be16_to_cpu(*((u16 *)src));
>> + break;
>> + case
Re: [U-Boot] [PATCH v2 1/7] drivers: Add AXI uclass
Hi Simon,
On Fri, May 25, 2018 at 4:41 AM, Simon Glass wrote:
> On 23 May 2018 at 06:10, Mario Six wrote:
>> Add a uclass for AXI (Advanced eXtensible Interface) busses, and a
>> driver for the gdsys IHS AXI bus on IHS FPGAs.
>>
>> Signed-off-by: Mario Six
>>
>> ---
>>
>> v1 -> v2:
>> * Spelled out all abbreviations in the Kconfig help
>> * Split commit into uclass addition and driver addition
>>
>> ---
>> drivers/Kconfig | 2 ++
>> drivers/Makefile | 1 +
>> drivers/axi/Kconfig | 13 +
>> drivers/axi/Makefile | 8 ++
>> drivers/axi/axi-uclass.c | 40 ++
>> include/axi.h| 75
>>
>> include/dm/uclass-id.h | 1 +
>> 7 files changed, 140 insertions(+)
>> create mode 100644 drivers/axi/Kconfig
>> create mode 100644 drivers/axi/Makefile
>> create mode 100644 drivers/axi/axi-uclass.c
>> create mode 100644 include/axi.h
>
> Reviewed-by: Simon Glass
>
> One little nit:
>
>> diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
>> index d7f9df3583a..0aad4bc14d7 100644
>> --- a/include/dm/uclass-id.h
>> +++ b/include/dm/uclass-id.h
>> @@ -43,6 +43,7 @@ enum uclass_id {
>> UCLASS_I2C_GENERIC, /* Generic I2C device */
>> UCLASS_I2C_MUX, /* I2C multiplexer */
>> UCLASS_IDE, /* IDE device */
>> + UCLASS_AXI, /* AXI busses */
>
> AXI bus
>
Sure, will fix for v3.
>> UCLASS_IRQ, /* Interrupt controller */
>> UCLASS_KEYBOARD,/* Keyboard input device */
>> UCLASS_LED, /* Light-emitting diode (LED) */
>> --
>> 2.11.0
>>
>
Best regards,
Mario
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 10/11] cpu: Add MPC83xx CPU driver
Hi Simon,
On Fri, May 25, 2018 at 4:42 AM, Simon Glass wrote:
> Hi Mario,
>
> On 24 May 2018 at 02:42, Mario Six wrote:
>> Add a CPU driver for the MPC83xx architecture.
>>
>> Signed-off-by: Mario Six
>>
>> ---
>>
>> v2 -> v3:
>> * Added driver files to MAINTAINERS
>>
>> v1 -> v2:
>> * Removed cpu_print_info
>> * Fixed CPU info printing
>> * Removed usage of uclass_{first,next}_device_compat
>> * Removed printing of reset status
>>
>> ---
>> MAINTAINERS | 2 +
>> arch/powerpc/cpu/mpc83xx/cpu.c | 2 +
>> arch/powerpc/cpu/mpc83xx/cpu_init.c | 2 +
>> arch/powerpc/include/asm/processor.h | 2 +
>> drivers/cpu/Kconfig | 7 +
>> drivers/cpu/Makefile | 1 +
>> drivers/cpu/mpc83xx_cpu.c| 265
>> +++
>> drivers/cpu/mpc83xx_cpu.h| 172 +++
>> include/cpu.h| 1 +
>> 9 files changed, 454 insertions(+)
>> create mode 100644 drivers/cpu/mpc83xx_cpu.c
>> create mode 100644 drivers/cpu/mpc83xx_cpu.h
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index f03cfcc73b0..11965be1402 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -475,6 +475,8 @@ F: drivers/clk/mpc83xx_clk.c
>> F: drivers/clk/mpc83xx_clk.h
>> F: include/dt-bindings/clk/mpc83xx-clk.h
>> F: drivers/timer/mpc83xx_timer.c
>> +F: drivers/cpu/mpc83xx_cpu.c
>> +F: drivers/cpu/mpc83xx_cpu.h
>> F: arch/powerpc/cpu/mpc83xx/
>> F: arch/powerpc/include/asm/arch-mpc83xx/
>>
>> diff --git a/arch/powerpc/cpu/mpc83xx/cpu.c b/arch/powerpc/cpu/mpc83xx/cpu.c
>> index ffb42415feb..b29f271e9bc 100644
>> --- a/arch/powerpc/cpu/mpc83xx/cpu.c
>> +++ b/arch/powerpc/cpu/mpc83xx/cpu.c
>> @@ -25,6 +25,7 @@
>>
>> DECLARE_GLOBAL_DATA_PTR;
>>
>> +#ifndef CONFIG_CPU_MPC83XX
>> int checkcpu(void)
>> {
>> volatile immap_t *immr;
>> @@ -114,6 +115,7 @@ int checkcpu(void)
>>
>> return 0;
>> }
>> +#endif
>>
>> #ifndef CONFIG_SYSRESET
>> int
>> diff --git a/arch/powerpc/cpu/mpc83xx/cpu_init.c
>> b/arch/powerpc/cpu/mpc83xx/cpu_init.c
>> index fcac9f63a81..1555205e069 100644
>> --- a/arch/powerpc/cpu/mpc83xx/cpu_init.c
>> +++ b/arch/powerpc/cpu/mpc83xx/cpu_init.c
>> @@ -464,6 +464,7 @@ static int print_83xx_arb_event(int force)
>> }
>> #endif /* CONFIG_DISPLAY_AER_ */
>>
>> +#ifndef CONFIG_CPU_MPC83XX
>> /*
>> * Figure out the cause of the reset
>> */
>> @@ -505,3 +506,4 @@ int prt_83xx_rsr(void)
>>
>> return 0;
>> }
>> +#endif
>> diff --git a/arch/powerpc/include/asm/processor.h
>> b/arch/powerpc/include/asm/processor.h
>> index 6fbe8c46b31..f97ce48cc27 100644
>> --- a/arch/powerpc/include/asm/processor.h
>> +++ b/arch/powerpc/include/asm/processor.h
>> @@ -1325,7 +1325,9 @@ void ll_puts(const char *);
>> /* In misc.c */
>> void _nmask_and_or_msr(unsigned long nmask, unsigned long or_val);
>>
>> +#ifndef CONFIG_CPU_MPC83XX
>> int prt_83xx_rsr(void);
>> +#endif
>>
>> #endif /* ndef ASSEMBLY*/
>>
>> diff --git a/drivers/cpu/Kconfig b/drivers/cpu/Kconfig
>> index 0d1424d38e9..d4052005e24 100644
>> --- a/drivers/cpu/Kconfig
>> +++ b/drivers/cpu/Kconfig
>> @@ -6,3 +6,10 @@ config CPU
>> multiple CPUs, then normally have to be set up in U-Boot so that
>> they can work correctly in the OS. This provides a framework for
>> finding out information about available CPUs and making changes.
>> +
>> +config CPU_MPC83XX
>> + bool "Enable MPC83xx CPU driver"
>> + depends on CPU
>> + select CLK_MPC83XX
>> + help
>> + Support CPU cores for SoCs of the MPC83xx series.
>> diff --git a/drivers/cpu/Makefile b/drivers/cpu/Makefile
>> index db515f6f177..29d7da42fad 100644
>> --- a/drivers/cpu/Makefile
>> +++ b/drivers/cpu/Makefile
>> @@ -7,3 +7,4 @@
>> obj-$(CONFIG_CPU) += cpu-uclass.o
>>
>> obj-$(CONFIG_ARCH_BMIPS) += bmips_cpu.o
>> +obj-$(CONFIG_CPU_MPC83XX) += mpc83xx_cpu.o
>> diff --git a/drivers/cpu/mpc83xx_cpu.c b/drivers/cpu/mpc83xx_cpu.c
>> new file mode 100644
>> index 000..550a7ad89f1
>> --- /dev/null
>> +++ b/drivers/cpu/mpc83xx_cpu.c
>> @@ -0,0 +1,265 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * (C) Copyright 2018
>> + * Mario Six, Guntermann & Drunck GmbH, mario@gdsys.cc
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include "mpc83xx_cpu.h"
>> +
>> +struct mpc83xx_cpu_priv {
>> + struct mpc83xx_cpu_info info;
>> +};
>> +
>> +int checkcpu(void)
>> +{
>> + struct udevice *cpu;
>> +
>> + for (uclass_first_device(UCLASS_CPU, );
>> +cpu;
>> +uclass_next_device()) {
>> + }
>
> Can you please create a function in the CPU uclass to do this in a
> separate patch? (probe all CPUs). It should return an error if
> something goes wrong, but not print anything.
>
> Then you can call it here.
>
OK, will add a function like that in v4.
> [...]
>
>> diff --git
Re: [U-Boot] [PATCH v3 09/11] board_f: Use static print_cpuinfo if CONFIG_CPU is active
Hi Simon,
On Fri, May 25, 2018 at 4:42 AM, Simon Glass wrote:
> Hi Mario,
>
> On 24 May 2018 at 02:42, Mario Six wrote:
>> When the DM CPU drivers are active, printing information about a CPU
>> should be delegated to a matching driver.
>>
>> Hence, add a static print_cpuinfo that implements this delegation when
>> DM CPU drivers are active.
>>
>> Signed-off-by: Mario Six
>>
>> ---
>>
>> v2 -> v3:
>> No changes
>>
>> v1 -> v2:
>> New in v2
>>
>> ---
>> common/board_f.c | 16
>> include/init.h | 2 ++
>> 2 files changed, 18 insertions(+)
>
> Reviewed-by: Simon Glass
>
> See below
>
>>
>> diff --git a/common/board_f.c b/common/board_f.c
>> index a716eeb8990..327c7d83e2c 100644
>> --- a/common/board_f.c
>> +++ b/common/board_f.c
>> @@ -11,6 +11,7 @@
>>
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -165,6 +166,21 @@ static int print_resetinfo(void)
>> }
>> #endif
>>
>> +#if defined(CONFIG_DISPLAY_CPUINFO) && defined(CONFIG_CPU)
>> +static int print_cpuinfo(void)
>> +{
>> + struct udevice *dev;
>> + char desc[512];
>> +
>> + uclass_first_device_err(UCLASS_CPU, );
>> +
>> + cpu_get_desc(dev, desc, sizeof(desc));
>
> If this returns an error, I think you should print the error instead
>
OK, will be fixed in v4.
>> + printf("%s", desc);
>> +
>> + return 0;
>> +}
>> +#endif
>> +
>> static int announce_dram_init(void)
>> {
>> puts("DRAM: ");
>> diff --git a/include/init.h b/include/init.h
>> index f114a889631..38c9680c7a7 100644
>> --- a/include/init.h
>> +++ b/include/init.h
>> @@ -107,7 +107,9 @@ int arch_reserve_stacks(void);
>> */
>> int init_cache_f_r(void);
>>
>> +#ifndef CONFIG_CPU
>> int print_cpuinfo(void);
>> +#endif
>> int timer_init(void);
>> int reserve_mmu(void);
>> int misc_init_f(void);
>> --
>> 2.11.0
>>
>
> Regards,
> SImon
Best regards,
Mario
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 07/11] timer: Add MPC83xx timer driver
Hi Simon,
On Fri, May 25, 2018 at 4:42 AM, Simon Glass wrote:
> Hi Mario,
>
> On 24 May 2018 at 02:42, Mario Six wrote:
>> Add a timer driver for the MPC83xx architecture.
>>
>> Signed-off-by: Mario Six
>>
>> ---
>>
>> v2 -> v3:
>> * Got rid of the static variables
>> * Added driver files to MAINTAINERS
>>
>> v1 -> v2:
>> * Removed now-superfluous comments
>> * Removed usage of uclass_{first,next}_device_compat
>> * Switched to usage of new board uclass (instead of devinfo)
>>
>> ---
>> MAINTAINERS| 1 +
>> arch/powerpc/cpu/mpc83xx/cpu.c | 4 +-
>> arch/powerpc/lib/Makefile | 4 +
>> arch/powerpc/lib/interrupts.c | 5 +-
>> drivers/timer/Kconfig | 7 ++
>> drivers/timer/Makefile | 1 +
>> drivers/timer/mpc83xx_timer.c | 182
>> +
>> 7 files changed, 201 insertions(+), 3 deletions(-)
>> create mode 100644 drivers/timer/mpc83xx_timer.c
>>
> [..]
>
>> diff --git a/drivers/timer/Makefile b/drivers/timer/Makefile
>> index ee2fcb1fa71..75360d81de3 100644
>> --- a/drivers/timer/Makefile
>> +++ b/drivers/timer/Makefile
>> @@ -16,3 +16,4 @@ obj-$(CONFIG_ATCPIT100_TIMER) += atcpit100_timer.o
>> obj-$(CONFIG_ROCKCHIP_TIMER) += rockchip_timer.o
>> obj-$(CONFIG_ATMEL_PIT_TIMER) += atmel_pit_timer.o
>> obj-$(CONFIG_STM32_TIMER) += stm32_timer.o
>> +obj-$(CONFIG_MPC83XX_TIMER) += mpc83xx_timer.o
>> diff --git a/drivers/timer/mpc83xx_timer.c b/drivers/timer/mpc83xx_timer.c
>> new file mode 100644
>> index 000..148fb2550ca
>> --- /dev/null
>> +++ b/drivers/timer/mpc83xx_timer.c
>> @@ -0,0 +1,182 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * (C) Copyright 2018
>> + * Mario Six, Guntermann & Drunck GmbH, mario@gdsys.cc
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +DECLARE_GLOBAL_DATA_PTR;
>> +
>> +struct mpc83xx_timer_priv {
>> + uint decrementer_count; /* count value for 1e6/HZ microseconds */
>> + ulong timestamp;
>> +};
>> +
>> +static inline unsigned long get_dec(void)
>> +{
>> + unsigned long val;
>> +
>> + asm volatile ("mfdec %0" : "=r" (val) : );
>> +
>> + return val;
>> +}
>> +
>> +static inline void set_dec(unsigned long val)
>> +{
>> + if (val)
>> + asm volatile ("mtdec %0"::"r" (val));
>> +}
>> +
>> +/* TODO(mario@gdsys.cc): This should really be done by timer_init, and
>> the
>> + * interrupt init should go into a interrupt driver.
>> + */
>> +int interrupt_init(void)
>> +{
>> + immap_t *immr = (immap_t *)CONFIG_SYS_IMMR;
>> + struct udevice *csb;
>> + struct udevice *board;
>> + struct udevice *timer = gd->timer;
>> + struct mpc83xx_timer_priv *timer_priv = dev_get_priv(timer);
>> + struct clk clock;
>> + int ret;
>> +
>> + if (get_board()) {
>> + debug("%s: board device could not be fetched.\n", __func__);
>> + return -ENOENT;
>> + }
>> +
>> + ret = uclass_get_device_by_phandle(UCLASS_SIMPLE_BUS, board,
>> + "csb", );
>> + if (ret) {
>> + debug("%s: Could not retrieve CSB device (error: %d)",
>> + __func__, ret);
>> + return ret;
>> + }
>> +
>> + ret = clk_get_by_index(csb, 0, );
>> + if (ret) {
>> + debug("%s: Could not retrieve clock (error: %d)",
>> + __func__, ret);
>> + return ret;
>> + }
>> +
>> + timer_priv->decrementer_count = (clk_get_rate() / 4)
>> + / CONFIG_SYS_HZ;
>> + /* Enable e300 time base */
>> + setbits_be32(>sysconf.spcr, 0x0040);
>> +
>> + set_dec(timer_priv->decrementer_count);
>> +
>> + set_msr(get_msr() | MSR_EE);
>> +
>> + return 0;
>> +}
>> +
>> +void timer_interrupt(struct pt_regs *regs)
>> +{
>> + struct udevice *timer = gd->timer;
>> + struct mpc83xx_timer_priv *priv = dev_get_priv(timer);
>> +
>> + /* Restore Decrementer Count */
>> + set_dec(priv->decrementer_count);
>> +
>> + priv->timestamp++;
>> +
>> +#if defined(CONFIG_WATCHDOG) || defined(CONFIG_HW_WATCHDOG)
>> + if ((timestamp % (CONFIG_SYS_WATCHDOG_FREQ)) == 0)
>> + WATCHDOG_RESET();
>> +#endif/* CONFIG_WATCHDOG || CONFIG_HW_WATCHDOG */
>> +
>> +#ifdef CONFIG_LED_STATUS
>> + status_led_tick(priv->timestamp);
>> +#endif /* CONFIG_LED_STATUS */
>> +
>> +#ifdef CONFIG_SHOW_ACTIVITY
>> + board_show_activity(priv->timestamp);
>> +#endif /* CONFIG_SHOW_ACTIVITY */
>> +}
>> +
>> +ulong get_timer(ulong base)
>
> How come you are defining that? The standard one should work, and it
> calls get_ticks() which should call your driver.
>
I see. I wasn't aware of the fact that the default timer driver infrastructure
already does that, so I copied the old get_timer implementation over to this
driver.
Re: [U-Boot] [PATCH v3 06/11] clk: Add MPC83xx clock driver
Hi Simon,
On Fri, May 25, 2018 at 4:42 AM, Simon Glass wrote:
> Hi Mario,
>
> On 24 May 2018 at 02:42, Mario Six wrote:
>> Add a clock driver for the MPC83xx architecture.
>>
>> Signed-off-by: Mario Six
>>
>> ---
>>
>> v2 -> v3:
>> * Added driver files to MAINTAINERS
>>
>> v1 -> v2:
>> * Added binding of sysreset driver
>>
>> ---
>> MAINTAINERS | 3 +
>> arch/powerpc/cpu/mpc83xx/speed.c | 4 +
>> arch/powerpc/include/asm/config.h | 2 +-
>> drivers/clk/Kconfig | 6 +
>> drivers/clk/Makefile | 1 +
>> drivers/clk/mpc83xx_clk.c | 426
>> ++
>> drivers/clk/mpc83xx_clk.h | 121 ++
>> include/dt-bindings/clk/mpc83xx-clk.h | 33 +++
>> 8 files changed, 595 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/clk/mpc83xx_clk.c
>> create mode 100644 drivers/clk/mpc83xx_clk.h
>> create mode 100644 include/dt-bindings/clk/mpc83xx-clk.h
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index b43e4bc179d..ab0f6a0a5d0 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -471,6 +471,9 @@ T: git git://git.denx.de/u-boot-mpc83xx.git
>> F: drivers/ram/mpc83xx_sdram.c
>> F: include/dt-bindings/memory/mpc83xx-sdram.h
>> F: drivers/sysreset/sysreset_mpc83xx.c
>> +F: drivers/clk/mpc83xx_clk.c
>> +F: drivers/clk/mpc83xx_clk.h
>> +F: include/dt-bindings/clk/mpc83xx-clk.h
>> F: arch/powerpc/cpu/mpc83xx/
>> F: arch/powerpc/include/asm/arch-mpc83xx/
>>
>> diff --git a/arch/powerpc/cpu/mpc83xx/speed.c
>> b/arch/powerpc/cpu/mpc83xx/speed.c
>> index f0945281cd2..39bc1c53406 100644
>> --- a/arch/powerpc/cpu/mpc83xx/speed.c
>> +++ b/arch/powerpc/cpu/mpc83xx/speed.c
>> @@ -6,6 +6,8 @@
>> * Copyright (C) 2004-2007 Freescale Semiconductor, Inc.
>> */
>>
>> +#ifndef CONFIG_CLK_MPC83XX
>> +
>> #include
>> #include
>> #include
>> @@ -590,3 +592,5 @@ U_BOOT_CMD(clocks, 1, 0, do_clocks,
>> "print clock configuration",
>> "clocks"
>> );
>> +
>> +#endif
>> diff --git a/arch/powerpc/include/asm/config.h
>> b/arch/powerpc/include/asm/config.h
>> index 284cfe21ab0..7bc8f5006ec 100644
>> --- a/arch/powerpc/include/asm/config.h
>> +++ b/arch/powerpc/include/asm/config.h
>> @@ -78,7 +78,7 @@
>> /* All PPC boards must swap IDE bytes */
>> #define CONFIG_IDE_SWAP_IO
>>
>> -#if defined(CONFIG_DM_SERIAL)
>> +#if defined(CONFIG_DM_SERIAL) && !defined(CONFIG_CLK_MPC83XX)
>> /*
>> * TODO: Convert this to a clock driver exists that can give us the UART
>> * clock here.
>> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
>> index edb4ca58ea5..e6ebff0a9d4 100644
>> --- a/drivers/clk/Kconfig
>> +++ b/drivers/clk/Kconfig
>> @@ -98,4 +98,10 @@ config ICS8N3QV01
>> Crystal Oscillator). The output frequency can be programmed via an
>> I2C interface.
>>
>> +config CLK_MPC83XX
>> + bool "Enable MPC83xx clock driver"
>> + depends on CLK
>> + help
>> + Support for the clock driver of the MPC83xx series of SoCs.
>> +
>> endmenu
>> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
>> index 58139b13a89..58f497d3a15 100644
>> --- a/drivers/clk/Makefile
>> +++ b/drivers/clk/Makefile
>> @@ -16,6 +16,7 @@ obj-$(CONFIG_CLK_BCM6345) += clk_bcm6345.o
>> obj-$(CONFIG_CLK_BOSTON) += clk_boston.o
>> obj-$(CONFIG_CLK_EXYNOS) += exynos/
>> obj-$(CONFIG_CLK_HSDK) += clk-hsdk-cgu.o
>> +obj-$(CONFIG_CLK_MPC83XX) += mpc83xx_clk.o
>> obj-$(CONFIG_CLK_RENESAS) += renesas/
>> obj-$(CONFIG_CLK_STM32F) += clk_stm32f.o
>> obj-$(CONFIG_CLK_STM32MP1) += clk_stm32mp1.o
>> diff --git a/drivers/clk/mpc83xx_clk.c b/drivers/clk/mpc83xx_clk.c
>> new file mode 100644
>> index 000..80be597332d
>> --- /dev/null
>> +++ b/drivers/clk/mpc83xx_clk.c
>> @@ -0,0 +1,426 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * (C) Copyright 2017
>> + * Mario Six, Guntermann & Drunck GmbH, mario@gdsys.cc
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include "mpc83xx_clk.h"
>> +
>> +DECLARE_GLOBAL_DATA_PTR;
>> +
>> +static u32 *speed;
>> +
>> +struct mpc83xx_clk_priv {
>> + u32 *speed;
>> +};
>> +
>> +static const char * const names[] = {
>> + [MPC83XX_CLK_CORE] = "Core",
>> + [MPC83XX_CLK_CSB] = "Coherent System Bus",
>> + [MPC83XX_CLK_QE] = "QE",
>> + [MPC83XX_CLK_BRG] = "BRG",
>> + [MPC83XX_CLK_LBIU] = "Local Bus Controller",
>> + [MPC83XX_CLK_LCLK] = "Local Bus",
>> + [MPC83XX_CLK_MEM] = "DDR",
>> + [MPC83XX_CLK_MEM_SEC] = "DDR Secondary",
>> + [MPC83XX_CLK_ENC] = "SEC",
>> + [MPC83XX_CLK_I2C1] = "I2C1",
>> + [MPC83XX_CLK_I2C2] = "I2C2",
>> + [MPC83XX_CLK_TDM] = "TDM",
>> + [MPC83XX_CLK_SDHC] = "SDHC",
>> + [MPC83XX_CLK_TSEC1] = "TSEC1",
>> + [MPC83XX_CLK_TSEC2] = "TSEC2",
>> + [MPC83XX_CLK_USBDR] = "USB DR",
>> + [MPC83XX_CLK_USBMPH] = "USB MPH",
Re: [U-Boot] [PATCH v3 03/11] test: Add tests for sysreset_get_status
Hi Simon,
On Fri, May 25, 2018 at 4:41 AM, Simon Glass wrote:
> On 24 May 2018 at 02:42, Mario Six wrote:
>> Add some tests for sysreset_get_status.
>>
>> Signed-off-by: Mario Six
>>
>> ---
>>
>> v2 -> v3:
>> New in v3.
>>
>> ---
>> drivers/sysreset/sysreset_sandbox.c | 16
>> test/dm/sysreset.c | 19 +++
>> 2 files changed, 35 insertions(+)
>
> Reviewed-by: Simon Glass
>
>>
>> diff --git a/drivers/sysreset/sysreset_sandbox.c
>> b/drivers/sysreset/sysreset_sandbox.c
>> index f12c4e84198..e03b5c122fe 100644
>> --- a/drivers/sysreset/sysreset_sandbox.c
>> +++ b/drivers/sysreset/sysreset_sandbox.c
>> @@ -29,6 +29,13 @@ static int sandbox_warm_sysreset_request(struct udevice
>> *dev,
>> return -EINPROGRESS;
>> }
>>
>> +int sandbox_warm_sysreset_get_status(struct udevice *dev, char *buf, int
>> size)
>> +{
>> + strncpy(buf, "Reset Status: WARM", size);
>
> strlcpy() might be better.
>
OK, will use strlcpy() in v4.
Best regards,
Mario
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1] cmd: ubi: print load size after establishing volume size
From: Stefan Agner
When using static volumes, the file size stored in the volume is
determined at runtime. Currently the ubi command prints the file
size specified on the console, which leads to a rather confusing
series of messages:
# ubi read ${fdt_addr_r} testvol
Read 0 bytes from volume testvol to 8200
No size specified -> Using max size (179924992)
Make sure to print the actual size read in any case:
# ubi read ${fdt_addr_r} testvol
No size specified -> Using max size (179924992)
Read 179924992 bytes from volume testvol to 8200
Signed-off-by: Stefan Agner
---
cmd/ubi.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/cmd/ubi.c b/cmd/ubi.c
index ac9a582437..9c3cabc262 100644
--- a/cmd/ubi.c
+++ b/cmd/ubi.c
@@ -356,6 +356,8 @@ int ubi_volume_read(char *volume, char *buf, size_t size)
size = vol->used_bytes;
}
+ printf("Read %u bytes from volume %s to %p\n", size, volume, buf);
+
if (vol->corrupted)
printf("read from corrupted volume %d", vol->vol_id);
if (offp + size > vol->used_bytes)
@@ -674,9 +676,6 @@ static int do_ubi(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
}
if (argc == 3) {
- printf("Read %lld bytes from volume %s to %lx\n", size,
- argv[3], addr);
-
return ubi_volume_read(argv[3], (char *)addr, size);
}
}
--
2.18.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
