[U-Boot] [PATCH 0/4] Deep sleep patches for Freescale QorIQ platforms
From: Tang Yuantian These patches depend on the following patches: https://patchwork.ozlabs.org/patch/389949/ https://patchwork.ozlabs.org/patch/389950/ https://patchwork.ozlabs.org/patch/389951/ https://patchwork.ozlabs.org/patch/389952/ Tang Yuantian (4): Add deep sleep framework support for Freescale QorIQ platforms ARM: HYP/non-sec: Make armv7_init_nonsec() usable before relocation arm: ls102xa: Fixed a register definition error arm: ls1021qds: Add deep sleep support arch/arm/cpu/armv7/virt-v7.c | 14 +++--- arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 2 +- board/freescale/ls1021aqds/ddr.c | 7 +++ board/freescale/ls1021aqds/ls1021aqds.c | 60 +++ common/board_f.c | 10 drivers/ddr/fsl/arm_ddr_gen3.c| 48 -- include/configs/ls1021aqds.h | 4 ++ include/fsl_ddr_sdram.h | 2 + include/fsl_sleep.h | 32 9 files changed, 167 insertions(+), 12 deletions(-) create mode 100644 include/fsl_sleep.h -- 2.1.0.27.g96db324 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] arm: ls102xa: Fixed a register definition error
From: Tang Yuantian
There are 8 SCFG_SPARECR registers in SCFG memory block, not one.
Signed-off-by: Tang Yuantian
---
arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
index 7995fe2..b5db720 100644
--- a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
+++ b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
@@ -182,7 +182,7 @@ struct ccsr_scfg {
u32 etsecmcr;
u32 sdhciovserlcr;
u32 resv14[61];
- u32 sparecr;
+ u32 sparecr[8];
};
/* Clocking */
--
2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] ARM: HYP/non-sec: Make armv7_init_nonsec() usable before relocation
From: Tang Yuantian
Defining variable gic_dist_addr as a globe one prevents function
armv7_init_nonsec() from being used before relocation which is
the case in the deep sleep resume process on Freescale QorIQ SoC
platforms.
This patch removes this limitation by adding a extra same meaning
local variable. In this way, no exsiting codes get corrupts.
Signed-off-by: Tang Yuantian
---
arch/arm/cpu/armv7/virt-v7.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/arch/arm/cpu/armv7/virt-v7.c b/arch/arm/cpu/armv7/virt-v7.c
index 651ca40..e1dfce9 100644
--- a/arch/arm/cpu/armv7/virt-v7.c
+++ b/arch/arm/cpu/armv7/virt-v7.c
@@ -75,6 +75,7 @@ int armv7_init_nonsec(void)
{
unsigned int reg;
unsigned itlinesnr, i;
+ unsigned long gic_base_addr;
/* check whether the CPU supports the security extensions */
reg = read_id_pfr1();
@@ -89,23 +90,24 @@ int armv7_init_nonsec(void)
* any access to it will trap.
*/
- gic_dist_addr = get_gicd_base_address();
- if (gic_dist_addr == -1)
+ gic_base_addr = get_gicd_base_address();
+ gic_dist_addr = gic_base_addr;
+ if (gic_base_addr == -1)
return -1;
/* enable the GIC distributor */
- writel(readl(gic_dist_addr + GICD_CTLR) | 0x03,
- gic_dist_addr + GICD_CTLR);
+ writel(readl(gic_base_addr + GICD_CTLR) | 0x03,
+ gic_base_addr + GICD_CTLR);
/* TYPER[4:0] contains an encoded number of available interrupts */
- itlinesnr = readl(gic_dist_addr + GICD_TYPER) & 0x1f;
+ itlinesnr = readl(gic_base_addr + GICD_TYPER) & 0x1f;
/* set all bits in the GIC group registers to one to allow access
* from non-secure state. The first 32 interrupts are private per
* CPU and will be set later when enabling the GIC for each core
*/
for (i = 1; i <= itlinesnr; i++)
- writel((unsigned)-1, gic_dist_addr + GICD_IGROUPRn + 4 * i);
+ writel((unsigned)-1, gic_base_addr + GICD_IGROUPRn + 4 * i);
#ifndef CONFIG_ARMV7_PSCI
smp_set_core_boot_addr((unsigned long)secure_ram_addr(_smp_pen), -1);
--
2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] arm: ls1021qds: Add deep sleep support
From: Tang Yuantian
Add deep sleep support on Freescale LS1021QDS platform.
Signed-off-by: Tang Yuantian
---
board/freescale/ls1021aqds/ddr.c| 7
board/freescale/ls1021aqds/ls1021aqds.c | 60 +
include/configs/ls1021aqds.h| 4 +++
3 files changed, 71 insertions(+)
diff --git a/board/freescale/ls1021aqds/ddr.c b/board/freescale/ls1021aqds/ddr.c
index 5898e33..6dad4cc 100644
--- a/board/freescale/ls1021aqds/ddr.c
+++ b/board/freescale/ls1021aqds/ddr.c
@@ -8,6 +8,9 @@
#include
#include
#include "ddr.h"
+#ifdef CONFIG_FSL_DEEP_SLEEP
+#include
+#endif
DECLARE_GLOBAL_DATA_PTR;
@@ -156,6 +159,10 @@ phys_size_t initdram(int board_type)
puts("Initializing DDRusing SPD\n");
dram_size = fsl_ddr_sdram();
+#ifdef CONFIG_FSL_DEEP_SLEEP
+ fsl_dp_ddr_restore();
+#endif
+
return dram_size;
}
diff --git a/board/freescale/ls1021aqds/ls1021aqds.c
b/board/freescale/ls1021aqds/ls1021aqds.c
index 12e83f7..e9dce36 100644
--- a/board/freescale/ls1021aqds/ls1021aqds.c
+++ b/board/freescale/ls1021aqds/ls1021aqds.c
@@ -253,3 +253,63 @@ u16 flash_read16(void *addr)
return (((val) >> 8) & 0x00ff) | (((val) << 8) & 0xff00);
}
+
+#ifdef CONFIG_FSL_DEEP_SLEEP
+/* determine if it is a warm boot */
+bool is_warm_boot(void)
+{
+#define DCFG_CCSR_CRSTSR_WDRFR (1 << 3)
+ struct ccsr_gur __iomem *gur = (void *)CONFIG_SYS_FSL_GUTS_ADDR;
+
+ if (in_be32(&gur->crstsr) & DCFG_CCSR_CRSTSR_WDRFR)
+ return 1;
+
+ return 0;
+}
+
+void fsl_dp_mem_setup(void)
+{
+ /* does not provide HW signals for power management */
+ QIXIS_WRITE(pwr_ctl[1], (QIXIS_READ(pwr_ctl[1]) & ~0x2));
+ udelay(1);
+}
+
+void fsl_dp_ddr_restore(void)
+{
+#define DDR_BUFF_LEN 128
+ u64 *src, *dst;
+ int i;
+ struct ccsr_scfg *scfg = (void *)CONFIG_SYS_FSL_SCFG_ADDR;
+
+ if (!is_warm_boot())
+ return;
+
+ /* get the address of ddr date from SPARECR3, little endian */
+ src = (u64 *)in_le32(&scfg->sparecr[2]);
+ dst = (u64 *)CONFIG_SYS_SDRAM_BASE;
+ for (i = 0; i < DDR_BUFF_LEN / 8; i++)
+ *dst++ = *src++;
+}
+
+int fsl_dp_resume(void)
+{
+ u32 start_addr;
+ void (*kernel_resume)(void);
+ struct ccsr_scfg *scfg = (void *)CONFIG_SYS_FSL_SCFG_ADDR;
+
+ if (!is_warm_boot())
+ return 0;
+
+ enable_devices_ns_access(ns_dev, ARRAY_SIZE(ns_dev));
+ armv7_init_nonsec();
+ cleanup_before_linux();
+
+ /* Get the entry address and jump to kernel */
+ start_addr = in_le32(&scfg->sparecr[1]);
+ debug("Entry address is 0x%08x\n", start_addr);
+ kernel_resume = (void (*)(void))start_addr;
+ secure_ram_addr(_do_nonsec_entry)(kernel_resume, 0, 0, 0);
+
+ return 0;
+}
+#endif
diff --git a/include/configs/ls1021aqds.h b/include/configs/ls1021aqds.h
index bb47813..448a07e 100644
--- a/include/configs/ls1021aqds.h
+++ b/include/configs/ls1021aqds.h
@@ -19,6 +19,10 @@
#define CONFIG_SKIP_LOWLEVEL_INIT
#define CONFIG_BOARD_EARLY_INIT_F
+#define CONFIG_FSL_DEEP_SLEEP
+#ifdef CONFIG_FSL_DEEP_SLEEP
+#define CONFIG_SILENT_CONSOLE
+#endif
/*
* Size of malloc() pool
*/
--
2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] Add deep sleep framework support for Freescale QorIQ platforms
From: Tang Yuantian
When Freescale QorIQ SoCs wake up from deep sleep, control is
passed to the primary core that starts executing uboot. After
re-initialized some IP blocks, like DDRC, kernel will take
responsibility to continue to restore environment it leaves before.
This patch adds the deep sleep framework support for all Freescale
QorIQ platforms that use generic_board configuation.
Signed-off-by: Tang Yuantian
---
common/board_f.c | 10 +
drivers/ddr/fsl/arm_ddr_gen3.c | 48 +-
include/fsl_ddr_sdram.h| 2 ++
include/fsl_sleep.h| 32
4 files changed, 87 insertions(+), 5 deletions(-)
create mode 100644 include/fsl_sleep.h
diff --git a/common/board_f.c b/common/board_f.c
index e6aa298..b736d29 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -56,6 +56,9 @@
#endif
#include
#include
+#ifdef CONFIG_FSL_DEEP_SLEEP
+#include
+#endif
/*
* Pointer to initial global data area
@@ -921,6 +924,9 @@ static init_fnc_t init_sequence_f[] = {
#if defined(CONFIG_MIPS) || defined(CONFIG_PPC)
init_func_ram,
#endif
+#ifdef CONFIG_FSL_DEEP_SLEEP
+ fsl_dp_resume,
+#endif
#ifdef CONFIG_POST
post_init_f,
#endif
@@ -1027,6 +1033,10 @@ void board_init_f(ulong boot_flags)
gd->flags = boot_flags;
gd->have_console = 0;
+#ifdef CONFIG_FSL_DEEP_SLEEP
+ if (is_warm_boot())
+ gd->flags |= GD_FLG_SILENT | GD_FLG_DISABLE_CONSOLE;
+#endif
if (initcall_run_list(init_sequence_f))
hang();
diff --git a/drivers/ddr/fsl/arm_ddr_gen3.c b/drivers/ddr/fsl/arm_ddr_gen3.c
index 59f2fd6..1a9d82b 100644
--- a/drivers/ddr/fsl/arm_ddr_gen3.c
+++ b/drivers/ddr/fsl/arm_ddr_gen3.c
@@ -12,6 +12,9 @@
#include
#include
#include
+#ifdef CONFIG_FSL_DEEP_SLEEP
+#include
+#endif
#if (CONFIG_CHIP_SELECTS_PER_CTRL > 4)
#error Invalid setting for CONFIG_CHIP_SELECTS_PER_CTRL
@@ -92,7 +95,6 @@ void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t *regs,
ddr_out32(&ddr->timing_cfg_0, regs->timing_cfg_0);
ddr_out32(&ddr->timing_cfg_1, regs->timing_cfg_1);
ddr_out32(&ddr->timing_cfg_2, regs->timing_cfg_2);
- ddr_out32(&ddr->sdram_cfg_2, regs->ddr_sdram_cfg_2);
ddr_out32(&ddr->sdram_mode, regs->ddr_sdram_mode);
ddr_out32(&ddr->sdram_mode_2, regs->ddr_sdram_mode_2);
ddr_out32(&ddr->sdram_mode_3, regs->ddr_sdram_mode_3);
@@ -105,8 +107,25 @@ void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t
*regs,
ddr_out32(&ddr->sdram_interval, regs->ddr_sdram_interval);
ddr_out32(&ddr->sdram_data_init, regs->ddr_data_init);
ddr_out32(&ddr->sdram_clk_cntl, regs->ddr_sdram_clk_cntl);
- ddr_out32(&ddr->init_addr, regs->ddr_init_addr);
- ddr_out32(&ddr->init_ext_addr, regs->ddr_init_ext_addr);
+#ifdef CONFIG_FSL_DEEP_SLEEP
+ if (is_warm_boot()) {
+ ddr_out32(&ddr->sdram_cfg_2,
+ regs->ddr_sdram_cfg_2 & ~SDRAM_CFG2_D_INIT);
+ ddr_out32(&ddr->init_addr, CONFIG_SYS_SDRAM_BASE);
+ ddr_out32(&ddr->init_ext_addr, (1 << 31));
+
+ /* DRAM VRef will not be trained */
+ temp_sdram_cfg = ddr_in32(&ddr->ddr_cdr2);
+ temp_sdram_cfg &= ~DDR_CDR2_VREF_TRAIN_EN;
+ ddr_out32(&ddr->ddr_cdr2, temp_sdram_cfg);
+ } else
+#endif
+ {
+ ddr_out32(&ddr->sdram_cfg_2, regs->ddr_sdram_cfg_2);
+ ddr_out32(&ddr->init_addr, regs->ddr_init_addr);
+ ddr_out32(&ddr->init_ext_addr, regs->ddr_init_ext_addr);
+ ddr_out32(&ddr->ddr_cdr2, regs->ddr_cdr2);
+ }
ddr_out32(&ddr->timing_cfg_4, regs->timing_cfg_4);
ddr_out32(&ddr->timing_cfg_5, regs->timing_cfg_5);
@@ -128,7 +147,6 @@ void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t *regs,
ddr_out32(&ddr->ddr_sdram_rcw_1, regs->ddr_sdram_rcw_1);
ddr_out32(&ddr->ddr_sdram_rcw_2, regs->ddr_sdram_rcw_2);
ddr_out32(&ddr->ddr_cdr1, regs->ddr_cdr1);
- ddr_out32(&ddr->ddr_cdr2, regs->ddr_cdr2);
ddr_out32(&ddr->err_disable, regs->err_disable);
ddr_out32(&ddr->err_int_en, regs->err_int_en);
for (i = 0; i < 32; i++) {
@@ -167,8 +185,20 @@ step2:
udelay(500);
asm volatile("dsb sy;isb");
+#ifdef CONFIG_FSL_DEEP_SLEEP
+ if (is_warm_boot()) {
+ /* enter self-refresh */
+ temp_sdram_cfg = ddr_in32(&ddr->sdram_cfg_2);
+ temp_sdram_cfg |= SDRAM_CFG2_FRC_SR;
+ ddr_out32(&ddr->sdram_cfg_2, temp_sdram_cfg);
+ /* do board specific memory setup */
+ fsl_dp_mem_setup();
+
+ temp_sdram_cfg = (ddr_in32(&ddr->sdram_cfg) | SDRAM_CFG_BI);
+ } else
+#endif
+ temp_sdram_cfg = (in_be32(&ddr->sdram_cfg) & ~SDRAM_CFG_BI);
/* Let the controller go */
- temp_sdram_c
Re: [U-Boot] [PATCH] tools: mkimage can read input on /dev/stdin
On Sun, Sep 28, 2014 at 8:49 AM, Wolfgang Denk wrote: > The case where mkimage is taking a single input file is quickly > becoming a rare corner case. > > The recommended way to build U-Boot images is (and has been for years, > even though marketing for this has been poor) to build FIT images. In > this case you typically have several inout files, which are not even > listed on the mkimage command line, but referenced in the fit-image.its > file you use. OK, in this case you could feed the fit-image.its > through stdin. But there are other file arguments - like when using > signed images. > > Even if you use the (deprecated) legacy image format, the case of using > a single input file is not the generic one. mkimage syntax is: > > mkimage ... -d data_file[:data_file...] ... > > and allows to provide several input files - pretty often you need the > kernel image and the DT blob. It is also not uncommon to have a > ramdisk image included. Thank you so much for you explanations. To tell the truth, I don't even know what a FIT image is, and even if I saw the usage accepted several files as input, I didn't search to understand why. > So if we add support to read from stdin instead from a file where we > pass the file name as an argument, we should probably do this in a > consistent way. It would be a frustrating experience to the end user > to learn that he can use stdin here but not there - so we would > probably have to rework all these use cases? And how should we > implement this - would a file name "-" mean stdin (1), or should we > simply pass "/dev/stdin" as file argument (2)? > > With (1), we need to change more code, while (2) could probably be > pretty transparent. If I understand well, your proposition for (1) would be to use mmap(2) for everything, but use read(2) for the special case "-". I'm not sure it is a good idea. The standard input can be handled like any other file. And note the input could also be a named pipe, that you won't be able to mmap. With the patch proposed, it would work just fine. Also, in the case you're having several files as input, they will be consumed one after the other. So if the input is "-d /dev/stdin:/dev/stdin:/dev/stdin", you can give the three files through stdin. > You see, even such a simple change like your suggestion needs some > deeper thought if you want to keep the design consistent. This is why > I am asking about your use case, and how it would fit into other > situations. Indeed! -- Julien Castets ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 03/15] cros_ec: power: Add a tunnelled version of the tps65090 driver
Dear Simon Glass,
On 24 September 2014 03:59, Simon Glass wrote:
> Unfortunately on Pit the AP has no direct access to the tps65090 but must
> talk through the EC (over SPI) to the EC's I2C bus.
>
> When driver model supports PMICs this will be relatively easy. In the
> meantime the best approach is to duplicate the driver. It will be
> refactored
> once driver model support is expanded.
>
> Signed-off-by: Simon Glass
> Tested-by: Ajay Kumar
> ---
>
> Changes in v3: None
> Changes in v2: None
>
> drivers/power/pmic/Makefile | 1 +
> drivers/power/pmic/pmic_tps65090_ec.c | 212
> ++
> include/power/tps65090_pmic.h | 6 +
> 3 files changed, 219 insertions(+)
> create mode 100644 drivers/power/pmic/pmic_tps65090_ec.c
>
> diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
> index a472f61..0b76611 100644
> --- a/drivers/power/pmic/Makefile
> +++ b/drivers/power/pmic/Makefile
> @@ -12,6 +12,7 @@ obj-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
> obj-$(CONFIG_POWER_MAX77686) += pmic_max77686.o
> obj-$(CONFIG_POWER_PFUZE100) += pmic_pfuze100.o
> obj-$(CONFIG_POWER_TPS65090) += pmic_tps65090.o
> +obj-$(CONFIG_POWER_TPS65090_EC) += pmic_tps65090_ec.o
> obj-$(CONFIG_POWER_TPS65217) += pmic_tps65217.o
> obj-$(CONFIG_POWER_TPS65218) += pmic_tps65218.o
> obj-$(CONFIG_POWER_TPS65910) += pmic_tps65910.o
> diff --git a/drivers/power/pmic/pmic_tps65090_ec.c
> b/drivers/power/pmic/pmic_tps65090_ec.c
> new file mode 100644
> index 000..93b7923
> --- /dev/null
> +++ b/drivers/power/pmic/pmic_tps65090_ec.c
> @@ -0,0 +1,212 @@
> +/*
> + * Copyright (c) 2013 The Chromium OS Authors. All rights reserved.
> + * Use of this source code is governed by a BSD-style license that can be
> + * found in the LICENSE file.
> + *
> + * Alternatively, this software may be distributed under the terms of the
> + * GNU General Public License ("GPL") version 2 as published by the Free
> + * Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +#define TPS65090_ADDR 0x48
> +
> +static struct tps65090 {
> + struct cros_ec_dev *dev;/* The CROS_EC device */
> +} config;
> +
> +/* TPS65090 register addresses */
> +enum {
> + REG_FET1_CTRL = 0x0f,
> + REG_FET2_CTRL,
> + REG_FET3_CTRL,
> + REG_FET4_CTRL,
> + REG_FET5_CTRL,
> + REG_FET6_CTRL,
> + REG_FET7_CTRL,
> + TPS65090_NUM_REGS,
> +};
> +
> +enum {
> + MAX_FET_NUM = 7,
> + MAX_CTRL_READ_TRIES = 5,
> +
> + /* TPS65090 FET_CTRL register values */
> + FET_CTRL_TOFET = 1 << 7, /* Timeout, startup, overload */
> + FET_CTRL_PGFET = 1 << 4, /* Power good for FET status */
> + FET_CTRL_WAIT = 3 << 2, /* Overcurrent timeout max */
> + FET_CTRL_ADENFET= 1 << 1, /* Enable output auto discharge
> */
> + FET_CTRL_ENFET = 1 << 0, /* Enable FET */
> +};
> +
> +/**
> + * tps65090_read - read a byte from tps6090
> + *
> + * @param reg The register address to read from.
> + * @param val We'll return value value read here.
> + * @return 0 if ok; error if EC returns failure.
> + */
> +static int tps65090_read(u32 reg, u8 *val)
> +{
> + return cros_ec_i2c_xfer(config.dev, TPS65090_ADDR, reg, 1,
> + val, 1, true);
> +}
> +
> +/**
> + * tps65090_write - write a byte to tps6090
> + *
> + * @param reg The register address to write to.
> + * @param val The value to write.
> + * @return 0 if ok; error if EC returns failure.
> + */
> +static int tps65090_write(u32 reg, u8 val)
> +{
> + return cros_ec_i2c_xfer(config.dev, TPS65090_ADDR, reg, 1,
> + &val, 1, false);
> +}
> +
> +/**
> + * Checks for a valid FET number
> + *
> + * @param fet_id FET number to check
> + * @return 0 if ok, -1 if FET value is out of range
> + */
> +static int tps65090_check_fet(unsigned int fet_id)
> +{
> + if (fet_id == 0 || fet_id > MAX_FET_NUM) {
> + debug("parameter fet_id is out of range, %u not in 1 ~
> %u\n",
> + fet_id, MAX_FET_NUM);
> + return -1;
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * Set the power state for a FET
> + *
> + * @param fet_id Fet number to set (1..MAX_FET_NUM)
> + * @param set 1 to power on FET, 0 to power off
> + * @return FET_ERR_COMMS if we got a comms error, FET_ERR_NOT_READY if the
> + * FET failed to change state. If all is ok, returns 0.
> + */
> +static int tps65090_fet_set(int fet_id, int set)
> +{
> + int retry;
> + u8 reg = 0, value;
> +
> + value = FET_CTRL_ADENFET | FET_CTRL_WAIT;
> + if (set)
> + value |= FET_CTRL_ENFET;
> +
> + if (tps65090_write(REG_FET1_CTRL + fet_id - 1, value))
> + return FET_ERR_COMMS;
> + /* Tr
[U-Boot] [PATCH] sun7i: Add support for Olimex A20-OLinuXino-LIME2
This adds support for the Olimex A20-OLinuXino-Lime2
https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXIno-LIME2
Differences to previous Lime boards are 1GB RAM and gigabit ethernet
Signed-off-by: Iain Paton
---
patch is substantially the same as the one previously posted to linux-sunxi
by HeHoPMaJIeH just updated for mainline.
The settings have been tested on real hardware, however I'm limited to the
two boards that I have. As yet there are no downloads available from Olimex
for this board, so it's unknown if they will go for a more conservative
setting.
board/sunxi/MAINTAINERS | 6 ++
board/sunxi/Makefile | 1 +
board/sunxi/dram_a20_olinuxino_l2.c | 31 +++
configs/A20-OLinuXino-Lime2_defconfig | 5 +
4 files changed, 43 insertions(+)
create mode 100644 board/sunxi/dram_a20_olinuxino_l2.c
create mode 100644 configs/A20-OLinuXino-Lime2_defconfig
diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
index 4f32195..4ed82cf 100644
--- a/board/sunxi/MAINTAINERS
+++ b/board/sunxi/MAINTAINERS
@@ -38,3 +38,9 @@ M:FUKAUMI Naoki
S: Maintained
F: board/sunxi/dram_a20_olinuxino_l.c
F: configs/A20-OLinuXino-Lime_defconfig
+
+A20-OLINUXINO-LIME2 BOARD
+M: Iain Paton
+S: Maintained
+F: board/sunxi/dram_a20_olinuxino_l2.c
+F: configs/A20-OLinuXino-Lime2_defconfig
diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile
index 56073a0..d63a6d2 100644
--- a/board/sunxi/Makefile
+++ b/board/sunxi/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_A10S_OLINUXINO_M)+=
dram_a10s_olinuxino_m.o
obj-$(CONFIG_A13_OLINUXINO)+= dram_a13_olinuxino.o
obj-$(CONFIG_A13_OLINUXINOM) += dram_a13_oli_micro.o
obj-$(CONFIG_A20_OLINUXINO_L) += dram_a20_olinuxino_l.o
+obj-$(CONFIG_A20_OLINUXINO_L2) += dram_a20_olinuxino_l2.o
obj-$(CONFIG_A20_OLINUXINO_M) += dram_sun7i_384_1024_iow16.o
# This is not a typo, uses the same mem settings as the a10s-olinuxino-m
obj-$(CONFIG_AUXTEK_T004) += dram_a10s_olinuxino_m.o
diff --git a/board/sunxi/dram_a20_olinuxino_l2.c
b/board/sunxi/dram_a20_olinuxino_l2.c
new file mode 100644
index 000..2115d37
--- /dev/null
+++ b/board/sunxi/dram_a20_olinuxino_l2.c
@@ -0,0 +1,31 @@
+/* this file is generated, don't edit it yourself */
+
+#include
+#include
+
+static struct dram_para dram_para = {
+ .clock = 480,
+ .type = 3,
+ .rank_num = 1,
+ .density = 4096,
+ .io_width = 16,
+ .bus_width = 32,
+ .cas = 9,
+ .zq = 0x7f,
+ .odt_en = 0,
+ .size = 1024,
+ .tpr0 = 0x42d899b7,
+ .tpr1 = 0xa090,
+ .tpr2 = 0x22a00,
+ .tpr3 = 0,
+ .tpr4 = 0,
+ .tpr5 = 0,
+ .emr1 = 0x4,
+ .emr2 = 0x10,
+ .emr3 = 0,
+};
+
+unsigned long sunxi_dram_init(void)
+{
+ return dramc_init(&dram_para);
+}
diff --git a/configs/A20-OLinuXino-Lime2_defconfig
b/configs/A20-OLinuXino-Lime2_defconfig
new file mode 100644
index 000..75ef872
--- /dev/null
+++ b/configs/A20-OLinuXino-Lime2_defconfig
@@ -0,0 +1,5 @@
+CONFIG_SPL=y
+CONFIG_SYS_EXTRA_OPTIONS="A20_OLINUXINO_L2,AXP209_POWER,SUNXI_GMAC,RGMII,AHCI,SATAPWR=SUNXI_GPC(3),USB_EHCI"
+CONFIG_FDTFILE="sun7i-a20-olinuxino-lime2.dtb"
++S:CONFIG_ARM=y
++S:CONFIG_TARGET_SUN7I=y
--
1.8.5.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] dm: do not check the existence of uclass operation
The function uclass_add() checks uc_drv->ops as follows:
if (uc_drv->ops) {
dm_warn("No ops for uclass id %d\n", id);
return -EINVAL;
}
It seems odd because it warns "No ops" when uc_drv->ops has
non-NULL pointer. (Looks opposite.)
Anyway, most of UCLASS_DRIVER entries have no .ops member.
This check makes no sense.
Signed-off-by: Masahiro Yamada
---
drivers/core/uclass.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
index 61ca17e..901b06e 100644
--- a/drivers/core/uclass.c
+++ b/drivers/core/uclass.c
@@ -60,10 +60,6 @@ static int uclass_add(enum uclass_id id, struct uclass **ucp)
id);
return -ENOENT;
}
- if (uc_drv->ops) {
- dm_warn("No ops for uclass id %d\n", id);
- return -EINVAL;
- }
uc = calloc(1, sizeof(*uc));
if (!uc)
return -ENOMEM;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] dm: do not check dm_root before searching in uclass_root
The function uclass_find() looks for a uclass in the linked
list of gd->uclass_root; gd->dm_root has nothing to do with
gd->uclass_root. Remove this confusing code.
Signed-off-by: Masahiro Yamada
---
drivers/core/uclass.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
index 901b06e..74df613 100644
--- a/drivers/core/uclass.c
+++ b/drivers/core/uclass.c
@@ -23,8 +23,6 @@ struct uclass *uclass_find(enum uclass_id key)
{
struct uclass *uc;
- if (!gd->dm_root)
- return NULL;
/*
* TODO(s...@chromium.org): Optimise this, perhaps moving the found
* node to the start of the list, or creating a linear array mapping
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] dm: fix comments
The struct udevice stands for a device, not a driver.
The driver_info.name is a driver's name, which is referenced
to bind devices.
Signed-off-by: Masahiro Yamada
---
include/dm/lists.h| 4 ++--
include/dm/platdata.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/dm/lists.h b/include/dm/lists.h
index 2356895..704e33e 100644
--- a/include/dm/lists.h
+++ b/include/dm/lists.h
@@ -38,7 +38,7 @@ struct uclass_driver *lists_uclass_lookup(enum uclass_id id);
* This searches the U_BOOT_DEVICE() structures and creates new devices for
* each one. The devices will have @parent as their parent.
*
- * @parent: parent driver (root)
+ * @parent: parent device (root)
* @early_only: If true, bind only drivers with the DM_INIT_F flag. If false
* bind all drivers.
*/
@@ -50,7 +50,7 @@ int lists_bind_drivers(struct udevice *parent, bool
pre_reloc_only);
* This creates a new device bound to the given device tree node, with
* @parent as its parent.
*
- * @parent: parent driver (root)
+ * @parent: parent device (root)
* @blob: device tree blob
* @offset: offset of this device tree node
* @devp: if non-NULL, returns a pointer to the bound device
diff --git a/include/dm/platdata.h b/include/dm/platdata.h
index 2bc8b14..7716f19 100644
--- a/include/dm/platdata.h
+++ b/include/dm/platdata.h
@@ -14,7 +14,7 @@
/**
* struct driver_info - Information required to instantiate a device
*
- * @name: Device name
+ * @name: Driver name
* @platdata: Driver-specific platform data
*/
struct driver_info {
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/4] dm: a collection of minor fixes in Driver-Model
Masahiro Yamada (4): dm: fix comments dm: do not check the existence of uclass operation dm: do not check dm_root before searching in uclass_root dm: simplify the loop in lists_driver_lookup_name() drivers/core/lists.c | 9 + drivers/core/uclass.c | 6 -- include/dm/lists.h| 4 ++-- include/dm/platdata.h | 2 +- 4 files changed, 4 insertions(+), 17 deletions(-) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] dm: simplify the loop in lists_driver_lookup_name()
if (strncmp(name, entry->name, len))
continue;
/* Full match */
if (len == strlen(entry->name))
return entry;
is equivalent to:
if (!strcmp(name, entry->name))
return entry;
The latter is simpler.
Signed-off-by: Masahiro Yamada
---
drivers/core/lists.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/core/lists.c b/drivers/core/lists.c
index 699f94b..3a1ea85 100644
--- a/drivers/core/lists.c
+++ b/drivers/core/lists.c
@@ -24,19 +24,12 @@ struct driver *lists_driver_lookup_name(const char *name)
ll_entry_start(struct driver, driver);
const int n_ents = ll_entry_count(struct driver, driver);
struct driver *entry;
- int len;
if (!drv || !n_ents)
return NULL;
- len = strlen(name);
-
for (entry = drv; entry != drv + n_ents; entry++) {
- if (strncmp(name, entry->name, len))
- continue;
-
- /* Full match */
- if (len == strlen(entry->name))
+ if (!strcmp(name, entry->name))
return entry;
}
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] environment expectations of config_distro_bootcmd.h
Is there any documentation as to what environment variables a platform
must provide if it uses config_distro_bootcmd.h. ${scriptaddr} seems
clear but what about e.g. kernel_addr_r and friends? I suppose the use
of the pxe commands has some implicit dependencies (pxe_addr_r?)
Along the same lines is there any documentation regarding which
variables a boot.scr which expects to be called via this mechanism can
rely on. e.g. devtype/devnum/bootpart/prefix etc. Also foo_addr_r again
I suppose?
There is some info in the README but it says things like "these
variables don't have to be defined for all boards" and worse "some
boards use these variables for other purposes." ;-)
Thanks,
Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] dm: fix comments
On 28 September 2014 07:52, Masahiro Yamada wrote: > > The struct udevice stands for a device, not a driver. > The driver_info.name is a driver's name, which is referenced > to bind devices. > > Signed-off-by: Masahiro Yamada Acked-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please sync u-boot-arm/master with u-boot/master
Hi Albert, Could you have your u-boot-arm/master branch fast-forwarded against Tom's one, please? I am thinking of sending a pull-req of u-boot-uniphier (probably in a week or so). My upcoming pull-req will depend on some commits that are already on Tom's branch, but that are not on your branch yet. If you could update your branch, that would be helpful. -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] dm: do not check the existence of uclass operation
On 28 September 2014 07:52, Masahiro Yamada wrote:
> The function uclass_add() checks uc_drv->ops as follows:
>
> if (uc_drv->ops) {
> dm_warn("No ops for uclass id %d\n", id);
> return -EINVAL;
> }
>
> It seems odd because it warns "No ops" when uc_drv->ops has
> non-NULL pointer. (Looks opposite.)
>
> Anyway, most of UCLASS_DRIVER entries have no .ops member.
> This check makes no sense.
>
> Signed-off-by: Masahiro Yamada
Acked-by: Simon Glass
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sun7i: Add support for Olimex A20-OLinuXino-LIME2
Hi,
On 09/28/2014 03:18 PM, Iain Paton wrote:
> This adds support for the Olimex A20-OLinuXino-Lime2
> https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXIno-LIME2
>
> Differences to previous Lime boards are 1GB RAM and gigabit ethernet
>
> Signed-off-by: Iain Paton
Thanks, I've added this to the u-boot-sunxi next tree:
http://git.denx.de/?p=u-boot/u-boot-sunxi.git;a=shortlog;h=refs/heads/next
I plan to include it in the next pull-req for v2014.10 .
Regards,
Hans
> ---
>
> patch is substantially the same as the one previously posted to linux-sunxi
> by HeHoPMaJIeH just updated for mainline.
> The settings have been tested on real hardware, however I'm limited to the
> two boards that I have. As yet there are no downloads available from Olimex
> for this board, so it's unknown if they will go for a more conservative
> setting.
>
> board/sunxi/MAINTAINERS | 6 ++
> board/sunxi/Makefile | 1 +
> board/sunxi/dram_a20_olinuxino_l2.c | 31 +++
> configs/A20-OLinuXino-Lime2_defconfig | 5 +
> 4 files changed, 43 insertions(+)
> create mode 100644 board/sunxi/dram_a20_olinuxino_l2.c
> create mode 100644 configs/A20-OLinuXino-Lime2_defconfig
>
> diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
> index 4f32195..4ed82cf 100644
> --- a/board/sunxi/MAINTAINERS
> +++ b/board/sunxi/MAINTAINERS
> @@ -38,3 +38,9 @@ M: FUKAUMI Naoki
> S: Maintained
> F: board/sunxi/dram_a20_olinuxino_l.c
> F: configs/A20-OLinuXino-Lime_defconfig
> +
> +A20-OLINUXINO-LIME2 BOARD
> +M: Iain Paton
> +S: Maintained
> +F: board/sunxi/dram_a20_olinuxino_l2.c
> +F: configs/A20-OLinuXino-Lime2_defconfig
> diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile
> index 56073a0..d63a6d2 100644
> --- a/board/sunxi/Makefile
> +++ b/board/sunxi/Makefile
> @@ -16,6 +16,7 @@ obj-$(CONFIG_A10S_OLINUXINO_M) +=
> dram_a10s_olinuxino_m.o
> obj-$(CONFIG_A13_OLINUXINO) += dram_a13_olinuxino.o
> obj-$(CONFIG_A13_OLINUXINOM) += dram_a13_oli_micro.o
> obj-$(CONFIG_A20_OLINUXINO_L)+= dram_a20_olinuxino_l.o
> +obj-$(CONFIG_A20_OLINUXINO_L2) += dram_a20_olinuxino_l2.o
> obj-$(CONFIG_A20_OLINUXINO_M)+= dram_sun7i_384_1024_iow16.o
> # This is not a typo, uses the same mem settings as the a10s-olinuxino-m
> obj-$(CONFIG_AUXTEK_T004)+= dram_a10s_olinuxino_m.o
> diff --git a/board/sunxi/dram_a20_olinuxino_l2.c
> b/board/sunxi/dram_a20_olinuxino_l2.c
> new file mode 100644
> index 000..2115d37
> --- /dev/null
> +++ b/board/sunxi/dram_a20_olinuxino_l2.c
> @@ -0,0 +1,31 @@
> +/* this file is generated, don't edit it yourself */
> +
> +#include
> +#include
> +
> +static struct dram_para dram_para = {
> + .clock = 480,
> + .type = 3,
> + .rank_num = 1,
> + .density = 4096,
> + .io_width = 16,
> + .bus_width = 32,
> + .cas = 9,
> + .zq = 0x7f,
> + .odt_en = 0,
> + .size = 1024,
> + .tpr0 = 0x42d899b7,
> + .tpr1 = 0xa090,
> + .tpr2 = 0x22a00,
> + .tpr3 = 0,
> + .tpr4 = 0,
> + .tpr5 = 0,
> + .emr1 = 0x4,
> + .emr2 = 0x10,
> + .emr3 = 0,
> +};
> +
> +unsigned long sunxi_dram_init(void)
> +{
> + return dramc_init(&dram_para);
> +}
> diff --git a/configs/A20-OLinuXino-Lime2_defconfig
> b/configs/A20-OLinuXino-Lime2_defconfig
> new file mode 100644
> index 000..75ef872
> --- /dev/null
> +++ b/configs/A20-OLinuXino-Lime2_defconfig
> @@ -0,0 +1,5 @@
> +CONFIG_SPL=y
> +CONFIG_SYS_EXTRA_OPTIONS="A20_OLINUXINO_L2,AXP209_POWER,SUNXI_GMAC,RGMII,AHCI,SATAPWR=SUNXI_GPC(3),USB_EHCI"
> +CONFIG_FDTFILE="sun7i-a20-olinuxino-lime2.dtb"
> ++S:CONFIG_ARM=y
> ++S:CONFIG_TARGET_SUN7I=y
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] dm: do not check dm_root before searching in uclass_root
Hi Masahiro,
On 28 September 2014 07:52, Masahiro Yamada wrote:
> The function uclass_find() looks for a uclass in the linked
> list of gd->uclass_root; gd->dm_root has nothing to do with
> gd->uclass_root. Remove this confusing code.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> drivers/core/uclass.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
> index 901b06e..74df613 100644
> --- a/drivers/core/uclass.c
> +++ b/drivers/core/uclass.c
> @@ -23,8 +23,6 @@ struct uclass *uclass_find(enum uclass_id key)
> {
> struct uclass *uc;
>
> - if (!gd->dm_root)
> - return NULL;
> /*
> * TODO(s...@chromium.org): Optimise this, perhaps moving the found
> * node to the start of the list, or creating a linear array mapping
This came in in commit:
c910e2e dm: Avoid accessing uclasses before they are ready
Please see that (and the test that was added) for an explanation.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] dm: simplify the loop in lists_driver_lookup_name()
Hi Masahiro,
On 28 September 2014 07:52, Masahiro Yamada wrote:
> if (strncmp(name, entry->name, len))
> continue;
>
> /* Full match */
> if (len == strlen(entry->name))
> return entry;
>
> is equivalent to:
>
> if (!strcmp(name, entry->name))
> return entry;
>
> The latter is simpler.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> drivers/core/lists.c | 9 +
> 1 file changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/drivers/core/lists.c b/drivers/core/lists.c
> index 699f94b..3a1ea85 100644
> --- a/drivers/core/lists.c
> +++ b/drivers/core/lists.c
> @@ -24,19 +24,12 @@ struct driver *lists_driver_lookup_name(const char *name)
> ll_entry_start(struct driver, driver);
> const int n_ents = ll_entry_count(struct driver, driver);
> struct driver *entry;
> - int len;
>
> if (!drv || !n_ents)
> return NULL;
>
> - len = strlen(name);
> -
> for (entry = drv; entry != drv + n_ents; entry++) {
> - if (strncmp(name, entry->name, len))
> - continue;
> -
> - /* Full match */
> - if (len == strlen(entry->name))
> + if (!strcmp(name, entry->name))
> return entry;
> }
The discussion on this was here:
>
> --
> 1.9.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] dm: simplify the loop in lists_driver_lookup_name()
Hi Masahiro,
On 28 September 2014 07:52, Masahiro Yamada wrote:
> if (strncmp(name, entry->name, len))
> continue;
>
> /* Full match */
> if (len == strlen(entry->name))
> return entry;
>
> is equivalent to:
>
> if (!strcmp(name, entry->name))
> return entry;
>
> The latter is simpler.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> drivers/core/lists.c | 9 +
> 1 file changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/drivers/core/lists.c b/drivers/core/lists.c
> index 699f94b..3a1ea85 100644
> --- a/drivers/core/lists.c
> +++ b/drivers/core/lists.c
> @@ -24,19 +24,12 @@ struct driver *lists_driver_lookup_name(const char *name)
> ll_entry_start(struct driver, driver);
> const int n_ents = ll_entry_count(struct driver, driver);
> struct driver *entry;
> - int len;
>
> if (!drv || !n_ents)
> return NULL;
>
> - len = strlen(name);
> -
> for (entry = drv; entry != drv + n_ents; entry++) {
> - if (strncmp(name, entry->name, len))
> - continue;
> -
> - /* Full match */
> - if (len == strlen(entry->name))
> + if (!strcmp(name, entry->name))
> return entry;
> }
The discussion on this was here:
http://lists.denx.de/pipermail/u-boot/2014-September/189336.html
I don't see a lot of value in the extra code, so I think we should
take this patch. If it is found to be a problem, we can go back to the
defensive code and add a test case so it is clear what exactly we are
defending against.
Acked-by: Simon Glass
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/7] ARM: sun6i: Add clock support
Hi, On 09/22/2014 02:47 PM, Chen-Yu Tsai wrote: > On Mon, Sep 22, 2014 at 2:35 AM, Ian Campbell wrote: >> On Mon, 2014-09-08 at 21:28 +0800, Chen-Yu Tsai wrote: >> >>> +#ifdef CONFIG_SPL_BUILD >> >> Since there is no SPL support this is dead code right now, correct? > > This was part of Hans' attempt to support SPL. It was not finished. > >> I'm wondering whether we should leave it out of mainline until the SPL >> stuff is done, so SPL will be upstreamed all at once. What do others >> think? > > Sounds reasonable. > >>> + /* Set PLL ldo voltage without this PLL6 does not work properly */ >> >> Is "this" here the doing it 3 times bit? If that's deliberate then >> please say so explicitly. e.g. "Set PLL LDO voltage 3 times, without ... >> etc"), if it's not deliberate then please fix ;-) > > Hans, if you could enlighten us? :) If you take a closer look at the code you will see not all 3 writes are the same: /* Set PLL ldo voltage without this PLL6 does not work properly */ writel(PRCM_PLL_CTRL_LDO_DIGITAL_EN | PRCM_PLL_CTRL_LDO_ANALOG_EN | PRCM_PLL_CTRL_EXT_OSC_EN | PRCM_PLL_CTRL_LDO_OUT_L(1140) | PRCM_PLL_CTRL_LDO_KEY, &prcm->pll_ctrl1); writel(PRCM_PLL_CTRL_LDO_DIGITAL_EN | PRCM_PLL_CTRL_LDO_ANALOG_EN | PRCM_PLL_CTRL_EXT_OSC_EN | PRCM_PLL_CTRL_LDO_OUT_L(1140) | PRCM_PLL_CTRL_LDO_KEY, &prcm->pll_ctrl1); writel(PRCM_PLL_CTRL_LDO_DIGITAL_EN | PRCM_PLL_CTRL_LDO_ANALOG_EN | PRCM_PLL_CTRL_EXT_OSC_EN | PRCM_PLL_CTRL_LDO_OUT_L(1140), &prcm->pll_ctrl1); This register is locked with a so called "key", the first write is to set the key (and has everything else the same in case the key is already written). The second write actually makes the changes, and the third write clears the key bits. I guess this may need some better comments :) Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] Re: [PATCH 0/7] ARM: sunxi: Add basic support for Allwinner A31 (sun6i)
Hi, On 09/18/2014 05:31 PM, Chen-Yu Tsai wrote: > Hi, > > On Thu, Sep 18, 2014 at 4:31 PM, Hans de Goede wrote: >> Hi, >> >> On 09/18/2014 06:27 AM, Siarhei Siamashka wrote: >>> On Tue, 09 Sep 2014 09:00:57 +0200 >>> Hans de Goede wrote: >>> Hi, On 09/08/2014 03:28 PM, Chen-Yu Tsai wrote: > Hi everyone, > > This series add basic support for Allwinner's A31 SoC. The patches, > excluding the first one, were cherry-picked from u-boot-sunxi. Due to > the difference between u-boot mainline and u-boot-sunxi, some patches > were rearranged or squashed to better fit the current state of u-boot, > and not introduce any build breaks. It follows Ian's initial merge > method of sun7i support: introducing various components first, then > enabling them in the last commit. I tried to keep the commits separate, > thus retaining the original author and Signed-off-bys. > > Patch 1 adds a wrapper around "func(USB, usb, 0)" in BOOT_TARGET_DEVICES > to deal with breakage when USB support is not enabled. > > Patch 2 adds memory addresses for some hardware blocks new in sun6i. > > Patch 3 adds support for the new PRCM (power reset and clock management) > block, which also contains PLL bias voltage control. > > Patch 4 adds support for the clock module. This patch is a bunch of > different sun6i related patches on the clock code, from when sun6i > support was introduced to u-boot-sunxi, up to its current form. > This is done to avoid various conflicts and needlessly introducing > then removing macros. > > Patch 5 adds mmc support on sun6i. > > Patch 6 adds uart0 muxing on sun6i. > > Patch 7 enables sun6i support and adds defconfig for the Colombus board. Chen, Many thanks for working on this! Just a quick not for people celebrating too early, this is the *incomplete* sun7i support from the linux-sunxi/u-boot-sunxi git repo. It is fine to merge this upstream, but this does not include SPL support. This allows replacing u-boot.bin on allwinnner sd-card images, which is very useful. But it does not get us all the way to booting sun7i devices we still need boot0 and boot1 binaries from allwinner for that (for now). >>> >>> If I understand it correctly, one of the things that needs to be done >>> in SPL is the initialization of the DRAM controller. A few weeks ago >>> Oliver has updated the http://linux-sunxi.org/DRAM_Controller page >>> and added a link to the 'dram_sun6i.c' file from the rhombus-tech.net >>> u-boot repository: >>> >>> http://git.rhombus-tech.net/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/sunxi/dram_sun6i.c;hb=refs/heads/allwinner-sunxi-a31 >>> Does this repository look like exactly the missing part of code? >> >> Yes it does, interesting. I had found that file before, but this one >> was missing in the repo I found then: >> >> http://git.rhombus-tech.net/?p=u-boot.git;a=blob;f=arch/arm/include/asm/arch-sunxi/dram.h;hb=refs/heads/allwinner-sunxi-a31 >> >> But with that one added, this is definitely interesting. > > The A31 Hummingbird's SDK has provided us with full boot0/boot1, > which also includes the dram code: > > http://dl.linux-sunxi.org/SDK/A31/unpacked-stripped/a31_v4.5_hummingbird_kfb_ok/lichee/boot-v1.0/boot/source/init_dram/ > > It is more complex than what we found in u-boot. > This code also shows what is encoded into the dram parameters > found in the fex files. Interesting, if I ever find the time I may look into adding what ever is missing from the u-boot dram init code by looking at the algorithm used in the boot0 code. But as said, that depends on me finding the time ... So if others want to work on this, please do. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 10/10] ARM: sun6i: Add Colombus board defconfig
On Thu, 2014-09-25 at 20:09 +0100, Ian Campbell wrote: > On Wed, 2014-09-24 at 16:01 +0800, Chen-Yu Tsai wrote: > > The Colombus board is an A31 evaluation board from WITS Technology. > > > > Signed-off-by: Chen-Yu Tsai > > > --- > > configs/Colombus_defconfig | 4 > > 1 file changed, 4 insertions(+) > > create mode 100644 configs/Colombus_defconfig > > > > diff --git a/configs/Colombus_defconfig b/configs/Colombus_defconfig > > new file mode 100644 > > index 000..16800de > > --- /dev/null > > +++ b/configs/Colombus_defconfig > > @@ -0,0 +1,4 @@ > > +CONFIG_SYS_EXTRA_OPTIONS="COLOMBUS" > > Does this do anything other than define an unused #define? > > Ah, I suppose eventually it will cause the inclusion of a suitable dram > file. Really ought to start moving things out of SYS_EXTRA though, but I > don't think you need to shave that yakk just to get this patch in, so: > > Acked-by: Ian Campbell Although I've just noticed that lacks a board/sunxi/MAINTAINERS entry. I think there is no need to resend the whole series, just this one patch. With this minor tweak I think it's time add this to u-boot-sunxi#next. Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [u-boot] [PATCH V1 1/1] mmc: sunxi: add SDHC support for sun6i/sun7i/sun8i
Hi, On 09/22/2014 12:26 PM, Wills Wang wrote: > Allwinner A20/A23/A31's SD/MMC host support SDHC High Capacity feature. > > Signed-off-by: Wills Wang Thanks, added to u-boot-sunxi next: http://git.denx.de/?p=u-boot/u-boot-sunxi.git;a=shortlog;h=refs/heads/next I plan to include it in the next pull-req for v2014.10 . Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 10/10] ARM: sun6i: Add Colombus board defconfig
On Sun, Sep 28, 2014 at 11:33 PM, Ian Campbell wrote: > On Thu, 2014-09-25 at 20:09 +0100, Ian Campbell wrote: >> On Wed, 2014-09-24 at 16:01 +0800, Chen-Yu Tsai wrote: >> > The Colombus board is an A31 evaluation board from WITS Technology. >> > >> > Signed-off-by: Chen-Yu Tsai >> >> > --- >> > configs/Colombus_defconfig | 4 >> > 1 file changed, 4 insertions(+) >> > create mode 100644 configs/Colombus_defconfig >> > >> > diff --git a/configs/Colombus_defconfig b/configs/Colombus_defconfig >> > new file mode 100644 >> > index 000..16800de >> > --- /dev/null >> > +++ b/configs/Colombus_defconfig >> > @@ -0,0 +1,4 @@ >> > +CONFIG_SYS_EXTRA_OPTIONS="COLOMBUS" >> >> Does this do anything other than define an unused #define? >> >> Ah, I suppose eventually it will cause the inclusion of a suitable dram >> file. Really ought to start moving things out of SYS_EXTRA though, but I >> don't think you need to shave that yakk just to get this patch in, so: >> >> Acked-by: Ian Campbell > > Although I've just noticed that lacks a board/sunxi/MAINTAINERS entry. > > I think there is no need to resend the whole series, just this one > patch. With this minor tweak I think it's time add this to > u-boot-sunxi#next. Actually I don't have this board. I think Maxime has one. Not sure if anyone else does. It was kind of a placeholder for all A31 boards. I suppose you could just drop this patch. I can send another one for the A31 Hummingbird, which I do have and can maintain. ChenYu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/7] ARM: sun6i: Add clock support
On Sun, 2014-09-28 at 17:23 +0200, Hans de Goede wrote: > If you take a closer look at the code you will see not all 3 writes are the > same: > > /* Set PLL ldo voltage without this PLL6 does not work properly */ > writel(PRCM_PLL_CTRL_LDO_DIGITAL_EN | PRCM_PLL_CTRL_LDO_ANALOG_EN | > PRCM_PLL_CTRL_EXT_OSC_EN | PRCM_PLL_CTRL_LDO_OUT_L(1140) | > PRCM_PLL_CTRL_LDO_KEY, &prcm->pll_ctrl1); > writel(PRCM_PLL_CTRL_LDO_DIGITAL_EN | PRCM_PLL_CTRL_LDO_ANALOG_EN | > PRCM_PLL_CTRL_EXT_OSC_EN | PRCM_PLL_CTRL_LDO_OUT_L(1140) | > PRCM_PLL_CTRL_LDO_KEY, &prcm->pll_ctrl1); > writel(PRCM_PLL_CTRL_LDO_DIGITAL_EN | PRCM_PLL_CTRL_LDO_ANALOG_EN | > PRCM_PLL_CTRL_EXT_OSC_EN | PRCM_PLL_CTRL_LDO_OUT_L(1140), > &prcm->pll_ctrl1); > > This register is locked with a so called "key", the first write is to set > the key (and has everything else the same in case the key is already > written). The second write actually makes the changes, and the third write > clears the key bits. Even after staring really hard I still don't see what differs in the first and second ones ;-) > I guess this may need some better comments :) Perhaps setclr_bits and friends might help make it obvious what is changing at each phase by allowing the other values to be omitted? Or maybe a #define for the settings themselves so that the remaining bits stand out more? Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 10/10] ARM: sun6i: Add Colombus board defconfig
Hi Ian, On 09/28/2014 05:33 PM, Ian Campbell wrote: > On Thu, 2014-09-25 at 20:09 +0100, Ian Campbell wrote: >> On Wed, 2014-09-24 at 16:01 +0800, Chen-Yu Tsai wrote: >>> The Colombus board is an A31 evaluation board from WITS Technology. >>> >>> Signed-off-by: Chen-Yu Tsai >> >>> --- >>> configs/Colombus_defconfig | 4 >>> 1 file changed, 4 insertions(+) >>> create mode 100644 configs/Colombus_defconfig >>> >>> diff --git a/configs/Colombus_defconfig b/configs/Colombus_defconfig >>> new file mode 100644 >>> index 000..16800de >>> --- /dev/null >>> +++ b/configs/Colombus_defconfig >>> @@ -0,0 +1,4 @@ >>> +CONFIG_SYS_EXTRA_OPTIONS="COLOMBUS" >> >> Does this do anything other than define an unused #define? >> >> Ah, I suppose eventually it will cause the inclusion of a suitable dram >> file. Really ought to start moving things out of SYS_EXTRA though, but I >> don't think you need to shave that yakk just to get this patch in, so: >> >> Acked-by: Ian Campbell > > Although I've just noticed that lacks a board/sunxi/MAINTAINERS entry. > > I think there is no need to resend the whole series, just this one > patch. With this minor tweak I think it's time add this to > u-boot-sunxi#next. Before you do that, note that I've just added 2 patches there, which I would like to get into v2014.10. Specifically I'm hoping that I can get some positive testing feedback on the bananapi gmac patch I've send (off-list), and I believe we really should try to get the bananapi fix into v2014.10, and if we're going todo a pull-req for v2014.10, we might as well include the 2 patches I've just added to next. Do you agree ? Still feel free to merge the sun6i series into next, I can just cherry pick the 3 patches in question directly into master when I'm ready to send the pull-req. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/7] ARM: sun6i: Add clock support
Hi, On 09/28/2014 05:37 PM, Ian Campbell wrote: > On Sun, 2014-09-28 at 17:23 +0200, Hans de Goede wrote: >> If you take a closer look at the code you will see not all 3 writes are the >> same: >> >> /* Set PLL ldo voltage without this PLL6 does not work properly */ >> writel(PRCM_PLL_CTRL_LDO_DIGITAL_EN | PRCM_PLL_CTRL_LDO_ANALOG_EN | >> PRCM_PLL_CTRL_EXT_OSC_EN | PRCM_PLL_CTRL_LDO_OUT_L(1140) | >> PRCM_PLL_CTRL_LDO_KEY, &prcm->pll_ctrl1); >> writel(PRCM_PLL_CTRL_LDO_DIGITAL_EN | PRCM_PLL_CTRL_LDO_ANALOG_EN | >> PRCM_PLL_CTRL_EXT_OSC_EN | PRCM_PLL_CTRL_LDO_OUT_L(1140) | >> PRCM_PLL_CTRL_LDO_KEY, &prcm->pll_ctrl1); >> writel(PRCM_PLL_CTRL_LDO_DIGITAL_EN | PRCM_PLL_CTRL_LDO_ANALOG_EN | >> PRCM_PLL_CTRL_EXT_OSC_EN | PRCM_PLL_CTRL_LDO_OUT_L(1140), >> &prcm->pll_ctrl1); >> >> This register is locked with a so called "key", the first write is to set >> the key (and has everything else the same in case the key is already >> written). The second write actually makes the changes, and the third write >> clears the key bits. > > Even after staring really hard I still don't see what differs in the > first and second ones ;-) Right, that is because there is no change between the first 2, I guess using setclr_bits to first only set the key, then only the bits, then only clear the key would be a good idea here :) Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 10/10] ARM: sun6i: Add Colombus board defconfig
On Sun, 2014-09-28 at 23:37 +0800, Chen-Yu Tsai wrote: > On Sun, Sep 28, 2014 at 11:33 PM, Ian Campbell wrote: > > On Thu, 2014-09-25 at 20:09 +0100, Ian Campbell wrote: > >> On Wed, 2014-09-24 at 16:01 +0800, Chen-Yu Tsai wrote: > >> > The Colombus board is an A31 evaluation board from WITS Technology. > >> > > >> > Signed-off-by: Chen-Yu Tsai > >> > >> > --- > >> > configs/Colombus_defconfig | 4 > >> > 1 file changed, 4 insertions(+) > >> > create mode 100644 configs/Colombus_defconfig > >> > > >> > diff --git a/configs/Colombus_defconfig b/configs/Colombus_defconfig > >> > new file mode 100644 > >> > index 000..16800de > >> > --- /dev/null > >> > +++ b/configs/Colombus_defconfig > >> > @@ -0,0 +1,4 @@ > >> > +CONFIG_SYS_EXTRA_OPTIONS="COLOMBUS" > >> > >> Does this do anything other than define an unused #define? > >> > >> Ah, I suppose eventually it will cause the inclusion of a suitable dram > >> file. Really ought to start moving things out of SYS_EXTRA though, but I > >> don't think you need to shave that yakk just to get this patch in, so: > >> > >> Acked-by: Ian Campbell > > > > Although I've just noticed that lacks a board/sunxi/MAINTAINERS entry. > > > > I think there is no need to resend the whole series, just this one > > patch. With this minor tweak I think it's time add this to > > u-boot-sunxi#next. > > Actually I don't have this board. I think Maxime has one. Not sure > if anyone else does. It was kind of a placeholder for all A31 boards. > > I suppose you could just drop this patch. I can send another one > for the A31 Hummingbird, which I do have and can maintain. Unless Maxime agrees to having his name in the MAINTAINERS file I think that would be best, actually if he does agree I see no reason not to have both ;-) Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] dm: do not check dm_root before searching in uclass_root
Simon,
2014-09-29 0:17 GMT+09:00 Simon Glass :
> Hi Masahiro,
>
> On 28 September 2014 07:52, Masahiro Yamada wrote:
>> The function uclass_find() looks for a uclass in the linked
>> list of gd->uclass_root; gd->dm_root has nothing to do with
>> gd->uclass_root. Remove this confusing code.
>>
>> Signed-off-by: Masahiro Yamada
>> ---
>>
>> drivers/core/uclass.c | 2 --
>> 1 file changed, 2 deletions(-)
>>
>> diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
>> index 901b06e..74df613 100644
>> --- a/drivers/core/uclass.c
>> +++ b/drivers/core/uclass.c
>> @@ -23,8 +23,6 @@ struct uclass *uclass_find(enum uclass_id key)
>> {
>> struct uclass *uc;
>>
>> - if (!gd->dm_root)
>> - return NULL;
>> /*
>> * TODO(s...@chromium.org): Optimise this, perhaps moving the found
>> * node to the start of the list, or creating a linear array mapping
>
> This came in in commit:
>
> c910e2e dm: Avoid accessing uclasses before they are ready
>
> Please see that (and the test that was added) for an explanation.
Commit c910e2e says:
dm: Avoid accessing uclasses before they are ready
Don't allow access to uclasses before they have been initialised.
I still don't get it.
The log did not help me because it is not saying 'why'.
What kind problem would happen if this check was dropped?
gd->dm_root is set when the root device is bound.
At the first call of uclass_find(), it is true gd->dm_root is NULL,
but gd->uclass_root is also empty.
This function, anyway, returns NULL.
The behavior is still the same, I think.
--
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCH 5/7] sun4i: Add support for a number of new sun4i boards
Hi,
On 09/18/2014 06:07 PM, Siarhei Siamashka wrote:
> On Sun, 27 Jul 2014 23:25:21 +0200
> Hans de Goede wrote:
>
>> Add support for boards which I own and which already have a dts file in the
>> upstream kernel.
>
> Hi Hans,
>
> It's good to know that you have all this hardware and can take care of
> maintaining it.
With maintaining being the key word here, I don't have the time to
extensively test things on all these different boards, but I do have
them around to test things if some board specific issues pop up.
>
>> Signed-off-by: Henrik Nordstrom
>> Signed-off-by: Stefan Roese
>> Signed-off-by: Hans de Goede
>> ---
>> board/sunxi/Makefile| 6 ++
>> board/sunxi/dram_a10_olinuxino_l.c | 31 +++
>> board/sunxi/dram_sun4i_360_1024_iow16.c | 31 +++
>> board/sunxi/dram_sun4i_360_1024_iow8.c | 31 +++
>> board/sunxi/dram_sun4i_360_512.c| 31 +++
>> board/sunxi/dram_sun4i_384_1024_iow8.c | 31 +++
>> boards.cfg | 6 ++
>> 7 files changed, 167 insertions(+)
>> create mode 100644 board/sunxi/dram_a10_olinuxino_l.c
>> create mode 100644 board/sunxi/dram_sun4i_360_1024_iow16.c
>> create mode 100644 board/sunxi/dram_sun4i_360_1024_iow8.c
>> create mode 100644 board/sunxi/dram_sun4i_360_512.c
>> create mode 100644 board/sunxi/dram_sun4i_384_1024_iow8.c
>>
>> diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile
>> index 03f55cc..b1db5d9 100644
>> --- a/board/sunxi/Makefile
>> +++ b/board/sunxi/Makefile
>> @@ -11,8 +11,14 @@
>> obj-y += board.o
>> obj-$(CONFIG_SUNXI_GMAC)+= gmac.o
>> obj-$(CONFIG_SUNXI_AHCI)+= ahci.o
>> +obj-$(CONFIG_A10_OLINUXINO_L) += dram_a10_olinuxino_l.o
>
> Which revision of A10-OLinuXino-LIME do you have? Revision A is known
> to have troubles running stable at 1008MHz CPU clock speed, as confirmed
> on a sample set of two boards (mine and Oliver Schinagl's):
> https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg04343.html
I have a revision A board.
> A bunch of revision C boards were all fine in Oliver's tests. And
> nobody has ever tested revision B so far, so we have no idea whether
> it is stable or not. A mysterious thing is that the Olimex
> representatives on IRC were not aware of any fixes of this kind
> applied to the PCB.
>
> My understanding is that the revision A was just a small pre-production
> batch, donated by OLIMEX to a number of open source developers. Some of
> these boards were distributed at FOSDEM. I'm not sure if we should
> really worry about the reliability of the revision A, because none of
> the 'normal' customers probably have such boards. We only need to
> clarify the status of revision B.
>
> But if we want to support the revision A too, then it probably needs
> its own config, which would somehow restrict the CPU clock speed.
My revision A was actually ordered normally, a couple of days before
the first batch sold-out. So it is likely that the entire first batch
was revision A.
Do you have any easy step-by-step document (or ready to use sdcard
image to download) to do some stress tests on my revision A ?
Maybe the first couple handed out to developers where hand soldered
or some such ? Either way it would be good to either confirm that
my revision A has the same issues, or not :)
>
>> obj-$(CONFIG_A13_OLINUXINOM)+= dram_a13_oli_micro.o
>> +obj-$(CONFIG_BA10_TV_BOX) += dram_sun4i_384_1024_iow8.o
>> obj-$(CONFIG_CUBIEBOARD)+= dram_cubieboard.o
>> obj-$(CONFIG_CUBIEBOARD2) += dram_cubieboard2.o
>> obj-$(CONFIG_CUBIETRUCK)+= dram_cubietruck.o
>> +obj-$(CONFIG_MELE_A1000)+= dram_sun4i_360_512.o
>> +obj-$(CONFIG_MELE_A1000G) += dram_sun4i_360_1024_iow8.o
>> +obj-$(CONFIG_MINI_X)+= dram_sun4i_360_512.o
>> +obj-$(CONFIG_MINI_X_1GB)+= dram_sun4i_360_1024_iow16.o
>> obj-$(CONFIG_R7DONGLE) += dram_r7dongle.o
>> diff --git a/board/sunxi/dram_a10_olinuxino_l.c
>> b/board/sunxi/dram_a10_olinuxino_l.c
>> new file mode 100644
>> index 000..24a1bd9
>> --- /dev/null
>> +++ b/board/sunxi/dram_a10_olinuxino_l.c
>> @@ -0,0 +1,31 @@
>> +/* this file is generated, don't edit it yourself */
>> +
>> +#include
>> +#include
>> +
>> +static struct dram_para dram_para = {
>> +.clock = 480,
>> +.type = 3,
>> +.rank_num = 1,
>> +.density = 4096,
>> +.io_width = 16,
>> +.bus_width = 16,
>> +.cas = 6,
>
> The CAS=6 is not quite right for the 480MHz DRAM clock speed if we
> are dealing with the typical DDR3 chips, with the timings mostly
> representing the standard JEDEC speed bins.
>
> CAS=6 is good up to 400MHz. CAS=7 is good up to 533MHz. And CAS=9 is
> good up to 667MHz.
>
>> +.zq = 123,
>> +.odt_en = 0,
>> +.size = 512,
>> +.tpr0 = 0x30926692,
>> +.tpr1 = 0x1090,
>> +.tpr2 = 0x1a0c8,
>
>
Re: [U-Boot] [PATCH 3/4] dm: do not check dm_root before searching in uclass_root
Hi Masahiro,
On 28 September 2014 09:54, Masahiro YAMADA wrote:
> Simon,
>
>
> 2014-09-29 0:17 GMT+09:00 Simon Glass :
>> Hi Masahiro,
>>
>> On 28 September 2014 07:52, Masahiro Yamada
>> wrote:
>>> The function uclass_find() looks for a uclass in the linked
>>> list of gd->uclass_root; gd->dm_root has nothing to do with
>>> gd->uclass_root. Remove this confusing code.
>>>
>>> Signed-off-by: Masahiro Yamada
>>> ---
>>>
>>> drivers/core/uclass.c | 2 --
>>> 1 file changed, 2 deletions(-)
>>>
>>> diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
>>> index 901b06e..74df613 100644
>>> --- a/drivers/core/uclass.c
>>> +++ b/drivers/core/uclass.c
>>> @@ -23,8 +23,6 @@ struct uclass *uclass_find(enum uclass_id key)
>>> {
>>> struct uclass *uc;
>>>
>>> - if (!gd->dm_root)
>>> - return NULL;
>>> /*
>>> * TODO(s...@chromium.org): Optimise this, perhaps moving the found
>>> * node to the start of the list, or creating a linear array mapping
>>
>> This came in in commit:
>>
>> c910e2e dm: Avoid accessing uclasses before they are ready
>>
>> Please see that (and the test that was added) for an explanation.
>
>
> Commit c910e2e says:
>
> dm: Avoid accessing uclasses before they are ready
>
> Don't allow access to uclasses before they have been initialised.
>
>
>
> I still don't get it.
> The log did not help me because it is not saying 'why'.
>
> What kind problem would happen if this check was dropped?
>
> gd->dm_root is set when the root device is bound.
> At the first call of uclass_find(), it is true gd->dm_root is NULL,
> but gd->uclass_root is also empty.
But 'empty' means the list is empty. For it to be empty it must be
initialised. But if you call the function before this list init
happens, then it will just crash.
We can use dm_root as an indicator that init has happened.
>
> This function, anyway, returns NULL.
> The behavior is still the same, I think.
You can try this by removing that code and seeing what the test does
(dm_test_uclass_before_ready()).
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] Re: [PATCH v2 10/10] ARM: sun6i: Add Colombus board defconfig
On Sun, 2014-09-28 at 17:40 +0200, Hans de Goede wrote: > Hi Ian, > > On 09/28/2014 05:33 PM, Ian Campbell wrote: > > On Thu, 2014-09-25 at 20:09 +0100, Ian Campbell wrote: > >> On Wed, 2014-09-24 at 16:01 +0800, Chen-Yu Tsai wrote: > >>> The Colombus board is an A31 evaluation board from WITS Technology. > >>> > >>> Signed-off-by: Chen-Yu Tsai > >> > >>> --- > >>> configs/Colombus_defconfig | 4 > >>> 1 file changed, 4 insertions(+) > >>> create mode 100644 configs/Colombus_defconfig > >>> > >>> diff --git a/configs/Colombus_defconfig b/configs/Colombus_defconfig > >>> new file mode 100644 > >>> index 000..16800de > >>> --- /dev/null > >>> +++ b/configs/Colombus_defconfig > >>> @@ -0,0 +1,4 @@ > >>> +CONFIG_SYS_EXTRA_OPTIONS="COLOMBUS" > >> > >> Does this do anything other than define an unused #define? > >> > >> Ah, I suppose eventually it will cause the inclusion of a suitable dram > >> file. Really ought to start moving things out of SYS_EXTRA though, but I > >> don't think you need to shave that yakk just to get this patch in, so: > >> > >> Acked-by: Ian Campbell > > > > Although I've just noticed that lacks a board/sunxi/MAINTAINERS entry. > > > > I think there is no need to resend the whole series, just this one > > patch. With this minor tweak I think it's time add this to > > u-boot-sunxi#next. > > Before you do that, note that I've just added 2 patches there, which I would > like to get into v2014.10. Specifically I'm hoping that I can get some > positive testing feedback on the bananapi gmac patch I've send (off-list), > and I believe we really should try to get the bananapi fix into v2014.10, > and if we're going todo a pull-req for v2014.10, we might as well include > the 2 patches I've just added to next. Do you agree ? You mean these two? sun7i: Add support for Olimex A20-OLinuXino-LIME2 mmc: sunxi: add SDHC support for sun6i/sun7i/sun8i The latter seems like a feature to me, or at least the changelog doesn't give any rationale why it should go in now rather than waiting for the next merge window (i.e. why it's a bugfix, what the upside is to justify its inclusion now). How much testing has it had and what are the potential downsides? WRT the new board (and new boards generally), I'm in two minds. On the one hand they are pretty low risk (can't regress anything else, at least not in this case), on the other we are 6 weeks past the close of the merge window and 2 from the release date, so we are pretty far along. Where do we draw the line? The gmac fix is a clear bug fix and once it is properly posted publicly I will ack and then I agree it should go in. > Still feel free to merge the sun6i series into next, I can just cherry pick > the 3 patches in question directly into master when I'm ready to send the > pull-req. Ack, that's what I expected to happen. Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/5] powerpc: ppc4xx: remove board support for CRAYL1
This board has been orphaned for more than 6 months.
Signed-off-by: Masahiro Yamada
---
arch/powerpc/cpu/ppc4xx/Kconfig | 4 -
board/cray/L1/.gitignore| 2 -
board/cray/L1/Kconfig | 12 --
board/cray/L1/L1.c | 350 ---
board/cray/L1/MAINTAINERS | 6 -
board/cray/L1/Makefile | 23 --
board/cray/L1/bootscript.hush | 117 ---
board/cray/L1/flash.c | 451
board/cray/L1/init.S| 117 ---
board/cray/L1/patchme | 30 ---
board/cray/L1/u-boot.lds.debug | 121 ---
board/cray/L1/x2c.awk | 6 -
configs/CRAYL1_defconfig| 3 -
doc/README.scrapyard| 1 +
include/configs/CRAYL1.h| 228
15 files changed, 1 insertion(+), 1470 deletions(-)
delete mode 100644 board/cray/L1/.gitignore
delete mode 100644 board/cray/L1/Kconfig
delete mode 100644 board/cray/L1/L1.c
delete mode 100644 board/cray/L1/MAINTAINERS
delete mode 100644 board/cray/L1/Makefile
delete mode 100644 board/cray/L1/bootscript.hush
delete mode 100644 board/cray/L1/flash.c
delete mode 100644 board/cray/L1/init.S
delete mode 100644 board/cray/L1/patchme
delete mode 100644 board/cray/L1/u-boot.lds.debug
delete mode 100644 board/cray/L1/x2c.awk
delete mode 100644 configs/CRAYL1_defconfig
delete mode 100644 include/configs/CRAYL1.h
diff --git a/arch/powerpc/cpu/ppc4xx/Kconfig b/arch/powerpc/cpu/ppc4xx/Kconfig
index 7c645f1..d525ad3 100644
--- a/arch/powerpc/cpu/ppc4xx/Kconfig
+++ b/arch/powerpc/cpu/ppc4xx/Kconfig
@@ -106,9 +106,6 @@ config TARGET_FX12MM
config TARGET_V5FX30TEVAL
bool "Support v5fx30teval"
-config TARGET_CRAYL1
- bool "Support CRAYL1"
-
config TARGET_CATCENTER
bool "Support CATcenter"
@@ -260,7 +257,6 @@ source "board/amcc/yosemite/Kconfig"
source "board/amcc/yucca/Kconfig"
source "board/avnet/fx12mm/Kconfig"
source "board/avnet/v5fx30teval/Kconfig"
-source "board/cray/L1/Kconfig"
source "board/csb272/Kconfig"
source "board/csb472/Kconfig"
source "board/dave/PPChameleonEVB/Kconfig"
diff --git a/board/cray/L1/.gitignore b/board/cray/L1/.gitignore
deleted file mode 100644
index cd76d66..000
--- a/board/cray/L1/.gitignore
+++ /dev/null
@@ -1,2 +0,0 @@
-bootscript.c
-bootscript.image
diff --git a/board/cray/L1/Kconfig b/board/cray/L1/Kconfig
deleted file mode 100644
index 35a290a..000
--- a/board/cray/L1/Kconfig
+++ /dev/null
@@ -1,12 +0,0 @@
-if TARGET_CRAYL1
-
-config SYS_BOARD
- default "L1"
-
-config SYS_VENDOR
- default "cray"
-
-config SYS_CONFIG_NAME
- default "CRAYL1"
-
-endif
diff --git a/board/cray/L1/L1.c b/board/cray/L1/L1.c
deleted file mode 100644
index d706ff1..000
--- a/board/cray/L1/L1.c
+++ /dev/null
@@ -1,350 +0,0 @@
-/*
- * (C) Copyright 2000
- * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#define L1_MEMSIZE (32*1024*1024)
-
-/* the std. DHCP stufff */
-#define DHCP_ROUTER 3
-#define DHCP_NETMASK 1
-#define DHCP_BOOTFILE 67
-#define DHCP_ROOTPATH 17
-#define DHCP_HOSTNAME 12
-
-/* some extras used by CRAY
- *
- * on the server this looks like:
- *
- * option L1-initrd-image code 224 = string;
- * option L1-initrd-image "/opt/craysv2/craymcu/l1/flash/initrd.image"
- */
-#define DHCP_L1_INITRD 224
-
-/* new, [better?] way via official vendor-extensions, defining an option
- * space.
- * on the server this looks like:
- *
- * option space CRAYL1;
- * option CRAYL1.initrd code 3 = string;
- * ..etc...
- */
-#define DHCP_VENDOR_SPECX 43
-#define DHCP_VX_INITRD 3
-#define DHCP_VX_BOOTCMD 4
-#define DHCP_VX_BOOTARGS 5
-#define DHCP_VX_ROOTDEV 6
-#define DHCP_VX_FROMFLASH7
-#define DHCP_VX_BOOTSCRIPT 8
-#define DHCP_VX_RCFILE 9
-#define DHCP_VX_MAGIC10
-
-/* Things DHCP server can tellme about. If there's no flash address, then
- * they dont participate in 'update' to flash, and we force their values
- * back to '0' every boot to be sure to get them fresh from DHCP. Yes, I
- * know this is a pain...
- *
- * If I get no bootfile, boot from flash. If rootpath, use that. If no
- * rootpath use initrd in flash.
- */
-typedef struct dhcp_item_s {
- u8 dhcp_option;
- u8 dhcp_vendor_option;
- char *dhcpvalue;
- char *envname;
-} dhcp_item_t;
-static dhcp_item_t Things[] = {
- {DHCP_ROUTER, 0, NULL, "gateway"},
- {DHCP_NETMASK, 0, NULL, "netmask"},
- {DHCP_BOOTFILE, 0, NULL, "bootfile"},
- {DHCP_ROOTPATH, 0, NULL, "rootpath"},
- {DHCP_HOSTNAME, 0, NULL, "hostname"},
- {DHCP_L1_INITRD, 0, NULL, "initrd"},
-/* and the other way.. */
- {DHCP_VENDOR_SPECX, DHCP_VX_INITRD, NULL, "initrd"},
- {DHCP_VENDOR_SPECX, DHCP_VX_BOOTCMD, NULL, "boot
[U-Boot] [PATCH 3/5] powerpc: ppc4xx: remove board support for bluestone
This board has been orphaned for more than 6 months.
It is the last board defining CONFIG_APM821XX.
The code inside #ifdef CONFIG_APM821XX should be removed too.
Signed-off-by: Masahiro Yamada
---
arch/powerpc/cpu/ppc4xx/Kconfig | 4 -
arch/powerpc/cpu/ppc4xx/cpu.c | 14 ---
arch/powerpc/cpu/ppc4xx/cpu_init.c | 4 +-
arch/powerpc/cpu/ppc4xx/speed.c | 75 +-
arch/powerpc/cpu/ppc4xx/start.S | 8 +-
arch/powerpc/include/asm/apm821xx.h | 59 ---
arch/powerpc/include/asm/ppc4xx-ebc.h | 3 +-
arch/powerpc/include/asm/ppc4xx-isram.h | 10 +-
arch/powerpc/include/asm/ppc4xx-sdram.h | 12 +--
arch/powerpc/include/asm/ppc4xx-uic.h | 5 +-
arch/powerpc/include/asm/ppc4xx.h | 4 -
board/amcc/bluestone/Kconfig| 12 ---
board/amcc/bluestone/MAINTAINERS| 6 --
board/amcc/bluestone/Makefile | 9 --
board/amcc/bluestone/bluestone.c| 99 ---
board/amcc/bluestone/config.mk | 18
board/amcc/bluestone/init.S | 45 -
configs/bluestone_defconfig | 3 -
doc/README.scrapyard| 1 +
include/configs/bluestone.h | 168
20 files changed, 19 insertions(+), 540 deletions(-)
delete mode 100644 arch/powerpc/include/asm/apm821xx.h
delete mode 100644 board/amcc/bluestone/Kconfig
delete mode 100644 board/amcc/bluestone/MAINTAINERS
delete mode 100644 board/amcc/bluestone/Makefile
delete mode 100644 board/amcc/bluestone/bluestone.c
delete mode 100644 board/amcc/bluestone/config.mk
delete mode 100644 board/amcc/bluestone/init.S
delete mode 100644 configs/bluestone_defconfig
delete mode 100644 include/configs/bluestone.h
diff --git a/arch/powerpc/cpu/ppc4xx/Kconfig b/arch/powerpc/cpu/ppc4xx/Kconfig
index d525ad3..56abe8d 100644
--- a/arch/powerpc/cpu/ppc4xx/Kconfig
+++ b/arch/powerpc/cpu/ppc4xx/Kconfig
@@ -52,9 +52,6 @@ config TARGET_ACADIA
config TARGET_BAMBOO
bool "Support bamboo"
-config TARGET_BLUESTONE
- bool "Support bluestone"
-
config TARGET_BUBINGA
bool "Support bubinga"
@@ -239,7 +236,6 @@ endchoice
source "board/amcc/acadia/Kconfig"
source "board/amcc/bamboo/Kconfig"
-source "board/amcc/bluestone/Kconfig"
source "board/amcc/bubinga/Kconfig"
source "board/amcc/canyonlands/Kconfig"
source "board/amcc/ebony/Kconfig"
diff --git a/arch/powerpc/cpu/ppc4xx/cpu.c b/arch/powerpc/cpu/ppc4xx/cpu.c
index 6a48526..aab65d4 100644
--- a/arch/powerpc/cpu/ppc4xx/cpu.c
+++ b/arch/powerpc/cpu/ppc4xx/cpu.c
@@ -234,20 +234,6 @@ static char *bootstrap_str[] = {
};
static char bootstrap_char[] = { 'A', 'B', 'C', 'D', 'E', 'G', 'F', 'H' };
#endif
-#if defined(CONFIG_APM821XX)
-#define SDR0_PINSTP_SHIFT 29
-static char *bootstrap_str[] = {
- "RESERVED",
- "RESERVED",
- "RESERVED",
- "NAND (8 bits)",
- "NOR (8 bits)",
- "NOR (8 bits) w/PLL Bypassed",
- "I2C (Addr 0x54)",
- "I2C (Addr 0x52)",
-};
-static char bootstrap_char[] = { 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H' };
-#endif
#if defined(SDR0_PINSTP_SHIFT)
static int bootstrap_option(void)
diff --git a/arch/powerpc/cpu/ppc4xx/cpu_init.c
b/arch/powerpc/cpu/ppc4xx/cpu_init.c
index 0b27d29..2256123 100644
--- a/arch/powerpc/cpu/ppc4xx/cpu_init.c
+++ b/arch/powerpc/cpu/ppc4xx/cpu_init.c
@@ -284,7 +284,7 @@ cpu_init_f (void)
reconfigure_pll(CONFIG_SYS_PLL_RECONFIG);
#if (defined(CONFIG_405EP) || defined (CONFIG_405EX)) && \
-!defined(CONFIG_APM821XX) &&!defined(CONFIG_SYS_4xx_GPIO_TABLE)
+!defined(CONFIG_SYS_4xx_GPIO_TABLE)
/*
* GPIO0 setup (select GPIO or alternate function)
*/
@@ -440,7 +440,7 @@ cpu_init_f (void)
#if defined(CONFIG_405EX) || \
defined(CONFIG_440SP) || defined(CONFIG_440SPE) || \
defined(CONFIG_460EX) || defined(CONFIG_460GT) || \
-defined(CONFIG_460SX) || defined(CONFIG_APM821XX)
+defined(CONFIG_460SX)
/*
* Set PLB4 arbiter (Segment 0 and 1) to 4 deep pipeline read
*/
diff --git a/arch/powerpc/cpu/ppc4xx/speed.c b/arch/powerpc/cpu/ppc4xx/speed.c
index 4baee77..3e1a701 100644
--- a/arch/powerpc/cpu/ppc4xx/speed.c
+++ b/arch/powerpc/cpu/ppc4xx/speed.c
@@ -171,7 +171,7 @@ ulong get_PCI_freq (void)
#elif defined(CONFIG_440)
#if defined(CONFIG_460EX) || defined(CONFIG_460GT) || \
-defined(CONFIG_460SX) || defined(CONFIG_APM821XX)
+defined(CONFIG_460SX)
static u8 pll_fwdv_multi_bits[] = {
/* values for: 1 - 16 */
0x00, 0x01, 0x0f, 0x04, 0x09, 0x0a, 0x0d, 0x0e, 0x03, 0x0c,
@@ -232,78 +232,6 @@ u32 get_cpr0_fbdv(unsigned long cpr_reg_fbdv)
return 0;
}
-#if defined(CONFIG_APM821XX)
-
-void get_sys_info(sys_info_t *sysInfo)
-{
- unsigned long plld;
- unsigned long temp;
- unsigned long mul;
- unsigned long cpudv;
- unsigned long plb2dv;
- unsigned long ddr2dv;
-
-
Re: [U-Boot] [PATCH v2 10/10] ARM: sun6i: Add Colombus board defconfig
On Sun, Sep 28, 2014 at 04:43:30PM +0100, Ian Campbell wrote: > > Actually I don't have this board. I think Maxime has one. Not sure > > if anyone else does. It was kind of a placeholder for all A31 boards. > > > > I suppose you could just drop this patch. I can send another one > > for the A31 Hummingbird, which I do have and can maintain. > > Unless Maxime agrees to having his name in the MAINTAINERS file I think > that would be best, actually if he does agree I see no reason not to > have both ;-) That's something I could live with :) Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/5] powerpc: remove some orphan boards
6 months have passed since these boards were moved to Orphan. I built all the other boards to confirm this series has no impact to them. Masahiro Yamada (5): powerpc: ppc4xx: remove board support for KAREF and METROBOX powerpc: ppc4xx: remove board support for CRAYL1 powerpc: ppc4xx: remove board support for bluestone powerpc: mpc83xx: remove board support for MERGERBOX and MVBLM7 powerpc: mpc5xxx: remove board support for MVBC_P and MVSMR arch/powerpc/cpu/mpc5xxx/Kconfig | 8 - arch/powerpc/cpu/mpc83xx/Kconfig | 8 - arch/powerpc/cpu/ppc4xx/Kconfig | 16 - arch/powerpc/cpu/ppc4xx/cpu.c| 14 - arch/powerpc/cpu/ppc4xx/cpu_init.c | 4 +- arch/powerpc/cpu/ppc4xx/speed.c | 75 +-- arch/powerpc/cpu/ppc4xx/start.S | 8 +- arch/powerpc/include/asm/apm821xx.h | 59 -- arch/powerpc/include/asm/ppc4xx-ebc.h| 3 +- arch/powerpc/include/asm/ppc4xx-isram.h | 10 +- arch/powerpc/include/asm/ppc4xx-sdram.h | 12 +- arch/powerpc/include/asm/ppc4xx-uic.h| 5 +- arch/powerpc/include/asm/ppc4xx.h| 4 - board/amcc/bluestone/Kconfig | 12 - board/amcc/bluestone/MAINTAINERS | 6 - board/amcc/bluestone/Makefile| 9 - board/amcc/bluestone/bluestone.c | 99 board/amcc/bluestone/config.mk | 18 - board/amcc/bluestone/init.S | 45 -- board/cray/L1/.gitignore | 2 - board/cray/L1/Kconfig| 12 - board/cray/L1/L1.c | 350 --- board/cray/L1/MAINTAINERS| 6 - board/cray/L1/Makefile | 23 - board/cray/L1/bootscript.hush| 117 board/cray/L1/flash.c| 451 --- board/cray/L1/init.S | 117 board/cray/L1/patchme| 30 - board/cray/L1/u-boot.lds.debug | 121 board/cray/L1/x2c.awk| 6 - board/matrix_vision/mergerbox/Kconfig| 12 - board/matrix_vision/mergerbox/MAINTAINERS| 6 - board/matrix_vision/mergerbox/Makefile | 8 - board/matrix_vision/mergerbox/README | 59 -- board/matrix_vision/mergerbox/fpga.c | 158 - board/matrix_vision/mergerbox/fpga.h | 13 - board/matrix_vision/mergerbox/mergerbox.c| 235 board/matrix_vision/mergerbox/mergerbox.h| 61 -- board/matrix_vision/mergerbox/pci.c | 128 board/matrix_vision/mergerbox/sm107.c| 120 board/matrix_vision/mvbc_p/Kconfig | 12 - board/matrix_vision/mvbc_p/MAINTAINERS | 6 - board/matrix_vision/mvbc_p/Makefile | 11 - board/matrix_vision/mvbc_p/README.mvbc_p | 73 --- board/matrix_vision/mvbc_p/fpga.c| 157 - board/matrix_vision/mvbc_p/fpga.h| 17 - board/matrix_vision/mvbc_p/mvbc_p.c | 255 board/matrix_vision/mvbc_p/mvbc_p.h | 43 -- board/matrix_vision/mvbc_p/mvbc_p_autoscript | 48 -- board/matrix_vision/mvblm7/.gitignore| 1 - board/matrix_vision/mvblm7/Kconfig | 12 - board/matrix_vision/mvblm7/MAINTAINERS | 6 - board/matrix_vision/mvblm7/Makefile | 14 - board/matrix_vision/mvblm7/README.mvblm7 | 84 --- board/matrix_vision/mvblm7/bootscript| 43 -- board/matrix_vision/mvblm7/fpga.c| 169 -- board/matrix_vision/mvblm7/fpga.h| 17 - board/matrix_vision/mvblm7/mvblm7.c | 136 - board/matrix_vision/mvblm7/mvblm7.h | 20 - board/matrix_vision/mvblm7/pci.c | 89 --- board/matrix_vision/mvsmr/.gitignore | 1 - board/matrix_vision/mvsmr/Kconfig| 12 - board/matrix_vision/mvsmr/MAINTAINERS| 6 - board/matrix_vision/mvsmr/Makefile | 18 - board/matrix_vision/mvsmr/README.mvsmr | 55 -- board/matrix_vision/mvsmr/bootscript | 42 -- board/matrix_vision/mvsmr/fpga.c | 112 board/matrix_vision/mvsmr/fpga.h | 15 - board/matrix_vision/mvsmr/mvsmr.c| 248 board/matrix_vision/mvsmr/mvsmr.h| 43 -- board/matrix_vision/mvsmr/u-boot.lds | 89 --- board/sandburst/common/flash.c | 493 board/sandburst/common/sb_common.c | 349 --- board/sandburst/common/sb_common.h | 60 -- board/sandburst/karef/Kconfig| 12 - board/sandburst/karef/MAINTAINERS| 6 - board/sandburst/karef/Makefile | 16 - board/sandburst/karef/config.mk | 21 - board/sandburst/karef/hal_ka_of_auto.h | 324 --- board/sandburst/karef/hal_ka_sc_auto.h | 836 --- board/sandburst/karef/init.S |
[U-Boot] [PATCH 4/5] powerpc: mpc83xx: remove board support for MERGERBOX and MVBLM7
These boards have been orphaned for more than 6 months. Signed-off-by: Masahiro Yamada --- arch/powerpc/cpu/mpc83xx/Kconfig | 8 - board/matrix_vision/mergerbox/Kconfig | 12 - board/matrix_vision/mergerbox/MAINTAINERS | 6 - board/matrix_vision/mergerbox/Makefile| 8 - board/matrix_vision/mergerbox/README | 59 --- board/matrix_vision/mergerbox/fpga.c | 158 board/matrix_vision/mergerbox/fpga.h | 13 - board/matrix_vision/mergerbox/mergerbox.c | 235 board/matrix_vision/mergerbox/mergerbox.h | 61 --- board/matrix_vision/mergerbox/pci.c | 128 --- board/matrix_vision/mergerbox/sm107.c | 120 -- board/matrix_vision/mvblm7/.gitignore | 1 - board/matrix_vision/mvblm7/Kconfig| 12 - board/matrix_vision/mvblm7/MAINTAINERS| 6 - board/matrix_vision/mvblm7/Makefile | 14 - board/matrix_vision/mvblm7/README.mvblm7 | 84 - board/matrix_vision/mvblm7/bootscript | 43 --- board/matrix_vision/mvblm7/fpga.c | 169 - board/matrix_vision/mvblm7/fpga.h | 17 - board/matrix_vision/mvblm7/mvblm7.c | 136 --- board/matrix_vision/mvblm7/mvblm7.h | 20 - board/matrix_vision/mvblm7/pci.c | 89 - configs/MERGERBOX_defconfig | 3 - configs/MVBLM7_defconfig | 3 - doc/README.scrapyard | 2 + include/configs/MERGERBOX.h | 599 -- include/configs/MVBLM7.h | 491 27 files changed, 2 insertions(+), 2495 deletions(-) delete mode 100644 board/matrix_vision/mergerbox/Kconfig delete mode 100644 board/matrix_vision/mergerbox/MAINTAINERS delete mode 100644 board/matrix_vision/mergerbox/Makefile delete mode 100644 board/matrix_vision/mergerbox/README delete mode 100644 board/matrix_vision/mergerbox/fpga.c delete mode 100644 board/matrix_vision/mergerbox/fpga.h delete mode 100644 board/matrix_vision/mergerbox/mergerbox.c delete mode 100644 board/matrix_vision/mergerbox/mergerbox.h delete mode 100644 board/matrix_vision/mergerbox/pci.c delete mode 100644 board/matrix_vision/mergerbox/sm107.c delete mode 100644 board/matrix_vision/mvblm7/.gitignore delete mode 100644 board/matrix_vision/mvblm7/Kconfig delete mode 100644 board/matrix_vision/mvblm7/MAINTAINERS delete mode 100644 board/matrix_vision/mvblm7/Makefile delete mode 100644 board/matrix_vision/mvblm7/README.mvblm7 delete mode 100644 board/matrix_vision/mvblm7/bootscript delete mode 100644 board/matrix_vision/mvblm7/fpga.c delete mode 100644 board/matrix_vision/mvblm7/fpga.h delete mode 100644 board/matrix_vision/mvblm7/mvblm7.c delete mode 100644 board/matrix_vision/mvblm7/mvblm7.h delete mode 100644 board/matrix_vision/mvblm7/pci.c delete mode 100644 configs/MERGERBOX_defconfig delete mode 100644 configs/MVBLM7_defconfig delete mode 100644 include/configs/MERGERBOX.h delete mode 100644 include/configs/MVBLM7.h diff --git a/arch/powerpc/cpu/mpc83xx/Kconfig b/arch/powerpc/cpu/mpc83xx/Kconfig index 6de9265..42e0e29 100644 --- a/arch/powerpc/cpu/mpc83xx/Kconfig +++ b/arch/powerpc/cpu/mpc83xx/Kconfig @@ -64,12 +64,6 @@ config TARGET_SUVD3 config TARGET_TUXX1 bool "Support tuxx1" -config TARGET_MERGERBOX - bool "Support MERGERBOX" - -config TARGET_MVBLM7 - bool "Support MVBLM7" - config TARGET_TQM834X bool "Support TQM834x" @@ -89,8 +83,6 @@ source "board/freescale/mpc837xemds/Kconfig" source "board/freescale/mpc837xerdb/Kconfig" source "board/ids/ids8313/Kconfig" source "board/keymile/km83xx/Kconfig" -source "board/matrix_vision/mergerbox/Kconfig" -source "board/matrix_vision/mvblm7/Kconfig" source "board/mpc8308_p1m/Kconfig" source "board/sbc8349/Kconfig" source "board/tqc/tqm834x/Kconfig" diff --git a/board/matrix_vision/mergerbox/Kconfig b/board/matrix_vision/mergerbox/Kconfig deleted file mode 100644 index 3857535..000 --- a/board/matrix_vision/mergerbox/Kconfig +++ /dev/null @@ -1,12 +0,0 @@ -if TARGET_MERGERBOX - -config SYS_BOARD - default "mergerbox" - -config SYS_VENDOR - default "matrix_vision" - -config SYS_CONFIG_NAME - default "MERGERBOX" - -endif diff --git a/board/matrix_vision/mergerbox/MAINTAINERS b/board/matrix_vision/mergerbox/MAINTAINERS deleted file mode 100644 index 20bd073..000 --- a/board/matrix_vision/mergerbox/MAINTAINERS +++ /dev/null @@ -1,6 +0,0 @@ -MERGERBOX BOARD -#M:Andre Schwarz -S: Orphan (since 2014-03) -F: board/matrix_vision/mergerbox/ -F: include/configs/MERGERBOX.h -F: configs/MERGERBOX_defconfig diff --git a/board/matrix_vision/mergerbox/Makefile b/board/matrix_vision/mergerbox/Makefile deleted file mode 100644 index 11a7fd2..000 --- a/board/matrix_vision/mergerbox/Makefile +++ /dev/null @@ -1,8 +0,0 @@ -# -# (C) Copyright 2006 -# Wolfgang Denk, DENX Software Engineering, w...@denx.de. -# -# SPDX-License-Identifier:
[U-Boot] [PATCH 5/5] powerpc: mpc5xxx: remove board support for MVBC_P and MVSMR
These boards have been orphaned for more than 6 months. Signed-off-by: Masahiro Yamada --- arch/powerpc/cpu/mpc5xxx/Kconfig | 8 - board/matrix_vision/mvbc_p/Kconfig | 12 -- board/matrix_vision/mvbc_p/MAINTAINERS | 6 - board/matrix_vision/mvbc_p/Makefile | 11 - board/matrix_vision/mvbc_p/README.mvbc_p | 73 --- board/matrix_vision/mvbc_p/fpga.c| 157 -- board/matrix_vision/mvbc_p/fpga.h| 17 -- board/matrix_vision/mvbc_p/mvbc_p.c | 255 --- board/matrix_vision/mvbc_p/mvbc_p.h | 43 board/matrix_vision/mvbc_p/mvbc_p_autoscript | 48 - board/matrix_vision/mvsmr/.gitignore | 1 - board/matrix_vision/mvsmr/Kconfig| 12 -- board/matrix_vision/mvsmr/MAINTAINERS| 6 - board/matrix_vision/mvsmr/Makefile | 18 -- board/matrix_vision/mvsmr/README.mvsmr | 55 - board/matrix_vision/mvsmr/bootscript | 42 board/matrix_vision/mvsmr/fpga.c | 112 -- board/matrix_vision/mvsmr/fpga.h | 15 -- board/matrix_vision/mvsmr/mvsmr.c| 248 -- board/matrix_vision/mvsmr/mvsmr.h| 43 board/matrix_vision/mvsmr/u-boot.lds | 89 configs/MVBC_P_defconfig | 4 - configs/MVSMR_defconfig | 3 - doc/README.scrapyard | 2 + include/configs/MVBC_P.h | 300 --- include/configs/MVSMR.h | 270 26 files changed, 2 insertions(+), 1848 deletions(-) delete mode 100644 board/matrix_vision/mvbc_p/Kconfig delete mode 100644 board/matrix_vision/mvbc_p/MAINTAINERS delete mode 100644 board/matrix_vision/mvbc_p/Makefile delete mode 100644 board/matrix_vision/mvbc_p/README.mvbc_p delete mode 100644 board/matrix_vision/mvbc_p/fpga.c delete mode 100644 board/matrix_vision/mvbc_p/fpga.h delete mode 100644 board/matrix_vision/mvbc_p/mvbc_p.c delete mode 100644 board/matrix_vision/mvbc_p/mvbc_p.h delete mode 100644 board/matrix_vision/mvbc_p/mvbc_p_autoscript delete mode 100644 board/matrix_vision/mvsmr/.gitignore delete mode 100644 board/matrix_vision/mvsmr/Kconfig delete mode 100644 board/matrix_vision/mvsmr/MAINTAINERS delete mode 100644 board/matrix_vision/mvsmr/Makefile delete mode 100644 board/matrix_vision/mvsmr/README.mvsmr delete mode 100644 board/matrix_vision/mvsmr/bootscript delete mode 100644 board/matrix_vision/mvsmr/fpga.c delete mode 100644 board/matrix_vision/mvsmr/fpga.h delete mode 100644 board/matrix_vision/mvsmr/mvsmr.c delete mode 100644 board/matrix_vision/mvsmr/mvsmr.h delete mode 100644 board/matrix_vision/mvsmr/u-boot.lds delete mode 100644 configs/MVBC_P_defconfig delete mode 100644 configs/MVSMR_defconfig delete mode 100644 include/configs/MVBC_P.h delete mode 100644 include/configs/MVSMR.h diff --git a/arch/powerpc/cpu/mpc5xxx/Kconfig b/arch/powerpc/cpu/mpc5xxx/Kconfig index cca58e5..8a477e7 100644 --- a/arch/powerpc/cpu/mpc5xxx/Kconfig +++ b/arch/powerpc/cpu/mpc5xxx/Kconfig @@ -97,12 +97,6 @@ config TARGET_MUCMC52 config TARGET_UC101 bool "Support uc101" -config TARGET_MVBC_P - bool "Support MVBC_P" - -config TARGET_MVSMR - bool "Support MVSMR" - config TARGET_PCM030 bool "Support pcm030" @@ -139,8 +133,6 @@ source "board/jupiter/Kconfig" source "board/manroland/hmi1001/Kconfig" source "board/manroland/mucmc52/Kconfig" source "board/manroland/uc101/Kconfig" -source "board/matrix_vision/mvbc_p/Kconfig" -source "board/matrix_vision/mvsmr/Kconfig" source "board/mcc200/Kconfig" source "board/motionpro/Kconfig" source "board/munices/Kconfig" diff --git a/board/matrix_vision/mvbc_p/Kconfig b/board/matrix_vision/mvbc_p/Kconfig deleted file mode 100644 index 4a68493..000 --- a/board/matrix_vision/mvbc_p/Kconfig +++ /dev/null @@ -1,12 +0,0 @@ -if TARGET_MVBC_P - -config SYS_BOARD - default "mvbc_p" - -config SYS_VENDOR - default "matrix_vision" - -config SYS_CONFIG_NAME - default "MVBC_P" - -endif diff --git a/board/matrix_vision/mvbc_p/MAINTAINERS b/board/matrix_vision/mvbc_p/MAINTAINERS deleted file mode 100644 index aad14ed..000 --- a/board/matrix_vision/mvbc_p/MAINTAINERS +++ /dev/null @@ -1,6 +0,0 @@ -MVBC_P BOARD -#M:Andre Schwarz -S: Orphan (since 2014-03) -F: board/matrix_vision/mvbc_p/ -F: include/configs/MVBC_P.h -F: configs/MVBC_P_defconfig diff --git a/board/matrix_vision/mvbc_p/Makefile b/board/matrix_vision/mvbc_p/Makefile deleted file mode 100644 index 4c19941..000 --- a/board/matrix_vision/mvbc_p/Makefile +++ /dev/null @@ -1,11 +0,0 @@ -# -# (C) Copyright 2003 -# Wolfgang Denk, DENX Software Engineering, w...@denx.de. -# -# (C) Copyright 2004-2008 -# Matrix-Vision GmbH, i...@matrix-vision.de -# -# SPDX-License-Identifier: GPL-2.0+ -# - -ob
Re: [U-Boot] [linux-sunxi] Re: [PATCH v2 10/10] ARM: sun6i: Add Colombus board defconfig
On 28/09/14 17:20, Ian Campbell wrote: > You mean these two? > sun7i: Add support for Olimex A20-OLinuXino-LIME2 > mmc: sunxi: add SDHC support for sun6i/sun7i/sun8i > > The latter seems like a feature to me, or at least the changelog doesn't > give any rationale why it should go in now rather than waiting for the > next merge window (i.e. why it's a bugfix, what the upside is to justify > its inclusion now). How much testing has it had and what are the > potential downsides? > > WRT the new board (and new boards generally), I'm in two minds. On the > one hand they are pretty low risk (can't regress anything else, at least > not in this case), on the other we are 6 weeks past the close of the > merge window and 2 from the release date, so we are pretty far along. > Where do we draw the line? FWIW, the Lime2 is very new, I had no expectations it would make it into 2014.10 - although I'd not complain if it does! Seems unlikely the dts will make it into 3.17 either, so there's probably no rush. Anyone needing either can pick up the patches themselves until next release. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: mkimage can read input on /dev/stdin
Dear Julien, In message you wrote: > > > So if we add support to read from stdin instead from a file where we > > pass the file name as an argument, we should probably do this in a > > consistent way. It would be a frustrating experience to the end user > > to learn that he can use stdin here but not there - so we would > > probably have to rework all these use cases? And how should we > > implement this - would a file name "-" mean stdin (1), or should we > > simply pass "/dev/stdin" as file argument (2)? > > > > With (1), we need to change more code, while (2) could probably be > > pretty transparent. > > If I understand well, your proposition for (1) would be to use mmap(2) > for everything, but use read(2) for the special case "-". I did not mean to suggest this. I probably makes more sense to use the same code everywhere. > I'm not sure it is a good idea. The standard input can be handled like > any other file. And note the input could also be a named pipe, that > you won't be able to mmap. With the patch proposed, it would work just > fine. But the patch would only be a part of the implementation. I think we should see it all together to be able to compare approaches. > Also, in the case you're having several files as input, they will be > consumed one after the other. So if the input is "-d > /dev/stdin:/dev/stdin:/dev/stdin", you can give the three files > through stdin. Ouch. That would be error prone as hell. Not all things that can be done should be done ;-) Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "Success covers a multitude of blunders." - George Bernard Shaw ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] patman: Check commit_match before stripping leading whitespace
Hi Scott,
On 25 September 2014 13:30, Scott Wood wrote:
> True commit lines start at column zero. Anything that is indented
> is part of the commit message instead. I noticed this by trying to
> run buildman with commit e3a4facdfc07179ebe017a07b8de6224a935a9f3
> as master, which contained a reference to a Linux commit inside
> the commit message. ProcessLine saw that as a genuite commit
> line, and thus buildman tried to build it, and died with an
> exception because that SHA is not present in the U-Boot tree.
>
> Signed-off-by: Scott Wood
> ---
> tools/patman/patchstream.py | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/tools/patman/patchstream.py b/tools/patman/patchstream.py
> index d630157..68e98b9 100644
> --- a/tools/patman/patchstream.py
> +++ b/tools/patman/patchstream.py
> @@ -139,6 +139,9 @@ class PatchStream:
> # Initially we have no output. Prepare the input line string
> out = []
> line = line.rstrip('\n')
> +
> +commit_match = re_commit.match(line) if self.is_log else None
> +
> if self.is_log:
> if line[:4] == '':
> line = line[4:]
> @@ -146,7 +149,6 @@ class PatchStream:
> # Handle state transition and skipping blank lines
> series_tag_match = re_series_tag.match(line)
> commit_tag_match = re_commit_tag.match(line)
> -commit_match = re_commit.match(line) if self.is_log else None
> cover_cc_match = re_cover_cc.match(line)
> signoff_match = re_signoff.match(line)
> tag_match = None
> --
> 1.9.1
>
Thanks for finding this bug.
This could use a test in tools/patman/test.py
The problem is that you are breaking the patch-processing part of this
code. It operates in two modes - see the comment at the top of
ProcessLine(). With your change it will not process patches correctly,
e.g. to add Commit-notes: to the patch.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] Re: [PATCH v2 10/10] ARM: sun6i: Add Colombus board defconfig
Hi, On 09/28/2014 06:20 PM, Ian Campbell wrote: > On Sun, 2014-09-28 at 17:40 +0200, Hans de Goede wrote: >> Hi Ian, >> >> On 09/28/2014 05:33 PM, Ian Campbell wrote: >>> On Thu, 2014-09-25 at 20:09 +0100, Ian Campbell wrote: On Wed, 2014-09-24 at 16:01 +0800, Chen-Yu Tsai wrote: > The Colombus board is an A31 evaluation board from WITS Technology. > > Signed-off-by: Chen-Yu Tsai > --- > configs/Colombus_defconfig | 4 > 1 file changed, 4 insertions(+) > create mode 100644 configs/Colombus_defconfig > > diff --git a/configs/Colombus_defconfig b/configs/Colombus_defconfig > new file mode 100644 > index 000..16800de > --- /dev/null > +++ b/configs/Colombus_defconfig > @@ -0,0 +1,4 @@ > +CONFIG_SYS_EXTRA_OPTIONS="COLOMBUS" Does this do anything other than define an unused #define? Ah, I suppose eventually it will cause the inclusion of a suitable dram file. Really ought to start moving things out of SYS_EXTRA though, but I don't think you need to shave that yakk just to get this patch in, so: Acked-by: Ian Campbell >>> >>> Although I've just noticed that lacks a board/sunxi/MAINTAINERS entry. >>> >>> I think there is no need to resend the whole series, just this one >>> patch. With this minor tweak I think it's time add this to >>> u-boot-sunxi#next. >> >> Before you do that, note that I've just added 2 patches there, which I would >> like to get into v2014.10. Specifically I'm hoping that I can get some >> positive testing feedback on the bananapi gmac patch I've send (off-list), >> and I believe we really should try to get the bananapi fix into v2014.10, >> and if we're going todo a pull-req for v2014.10, we might as well include >> the 2 patches I've just added to next. Do you agree ? > > You mean these two? > sun7i: Add support for Olimex A20-OLinuXino-LIME2 > mmc: sunxi: add SDHC support for sun6i/sun7i/sun8i Yes. > The latter seems like a feature to me, or at least the changelog doesn't > give any rationale why it should go in now rather than waiting for the > next merge window (i.e. why it's a bugfix, what the upside is to justify > its inclusion now). How much testing has it had and what are the > potential downsides? AFAIK the downside is that High Capacity cards will not work without it. Looking at the code if this bit is set, then for some commands drivers/mmc/mmc.c or-s in OCR_HCS into the mmc cmdarg, so I guess you're right that this may cause some undesirable side effects, so lets delay this one. > WRT the new board (and new boards generally), I'm in two minds. On the > one hand they are pretty low risk (can't regress anything else, at least > not in this case), on the other we are 6 weeks past the close of the > merge window and 2 from the release date, so we are pretty far along. > Where do we draw the line? Normally I would not include new boards at this moment in the cycle, but since we need to do a pull-req for the gmac anyways I thought it would be nice to have it included, esp. since many distros only spin things like sdcard boot images once, so if we do not include it now, many distros will not get it for a significant amount of time. Either way let me know how you want to proceed, if you think we should not include this, then I'll send a pull-req with only the gmac fix. > The gmac fix is a clear bug fix and once it is properly posted publicly > I will ack and then I agree it should go in. I was hoping for Stephen to get around to testing it today, and then I wanted to send it out with his Tested-by. I'll just go and send it as is for now. >> Still feel free to merge the sun6i series into next, I can just cherry pick >> the 3 patches in question directly into master when I'm ready to send the >> pull-req. > > Ack, that's what I expected to happen. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] sunxi: Fix gmac not working reliable on the Bananapi
In order for the gmac nic to work reliable on the Bananapi, we need to poke
these 2 undocumented bits in the gmac clk register. Since these are
undocumented, this commit only sets these bits on the Bananapi for now.
I'll contact Allwinner to try and get these bits documented, once they
are documented we can hopefully replace this hack with a better patch.
Reported-by: Karsten Merker
Signed-off-by: Hans de Goede
---
board/sunxi/gmac.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/board/sunxi/gmac.c b/board/sunxi/gmac.c
index e7ff952..f58c963 100644
--- a/board/sunxi/gmac.c
+++ b/board/sunxi/gmac.c
@@ -24,6 +24,15 @@ int sunxi_gmac_initialize(bd_t *bis)
CCM_GMAC_CTRL_GPIT_MII);
#endif
+ /*
+* HdG: this is necessary to get GMAC to work reliable on the
+* Bananapi. We don't know what these undocumented bits do, so this
+* is a Bananapi specific hack for now.
+*/
+#ifdef CONFIG_BANANAPI
+ setbits_le32(&ccm->gmac_clk_cfg, 0x3 << 10);
+#endif
+
/* Configure pin mux settings for GMAC */
for (pin = SUNXI_GPA(0); pin <= SUNXI_GPA(16); pin++) {
#ifdef CONFIG_RGMII
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] kconfig: add CONFIG_SUPPORT_SPL
Hi Masahiro, On 26 September 2014 03:40, Masahiro Yamada wrote: > CONFIG_SPL should not be enabled for boards that do not have SPL. > CONFIG_SUPPORT_SPL introduced by this commit should be "select"ed > by boards with SPL support and CONFIG_SPL should depend on it. > > Signed-off-by: Masahiro Yamada > --- > > Changes in v2: None > > Kconfig| 4 > arch/arm/Kconfig | 44 > ++ > arch/arm/cpu/arm926ejs/davinci/Kconfig | 4 > arch/arm/cpu/armv7/exynos/Kconfig | 7 ++ > arch/arm/cpu/armv7/omap3/Kconfig | 16 + > arch/microblaze/Kconfig| 1 + > arch/powerpc/cpu/mpc5xxx/Kconfig | 1 + > arch/powerpc/cpu/mpc83xx/Kconfig | 1 + > arch/powerpc/cpu/mpc85xx/Kconfig | 12 ++ > arch/powerpc/cpu/ppc4xx/Kconfig| 1 + > 10 files changed, 91 insertions(+) This looks right for the tegra and exynos boards. Acked-by: Simon Glass I'd like to get my exynos series in first though (I have one review comment from Minkyu on the latest rev, so will respin). Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] kconfig: fix another bug of "make savedefconfig"
On 26 September 2014 03:42, Masahiro Yamada wrote: > In some cases, the last lines of SPL or TPL are not output to a file. > The entries remaining in the "unmatched" variable must be flushed. > > Signed-off-by: Masahiro Yamada Acked-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 03/15] cros_ec: power: Add a tunnelled version of the tps65090 driver
Hi Minkyu,
On 28 September 2014 05:58, Minkyu Kang wrote:
> Dear Simon Glass,
>
> On 24 September 2014 03:59, Simon Glass wrote:
>>
>> Unfortunately on Pit the AP has no direct access to the tps65090 but must
>> talk through the EC (over SPI) to the EC's I2C bus.
>>
>> When driver model supports PMICs this will be relatively easy. In the
>> meantime the best approach is to duplicate the driver. It will be
>> refactored
>> once driver model support is expanded.
>>
>> Signed-off-by: Simon Glass
>> Tested-by: Ajay Kumar
>> ---
>>
>> Changes in v3: None
>> Changes in v2: None
>>
>> drivers/power/pmic/Makefile | 1 +
>> drivers/power/pmic/pmic_tps65090_ec.c | 212
>> ++
>> include/power/tps65090_pmic.h | 6 +
>> 3 files changed, 219 insertions(+)
>> create mode 100644 drivers/power/pmic/pmic_tps65090_ec.c
>>
>> diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
>> index a472f61..0b76611 100644
>> --- a/drivers/power/pmic/Makefile
>> +++ b/drivers/power/pmic/Makefile
>> @@ -12,6 +12,7 @@ obj-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
>> obj-$(CONFIG_POWER_MAX77686) += pmic_max77686.o
>> obj-$(CONFIG_POWER_PFUZE100) += pmic_pfuze100.o
>> obj-$(CONFIG_POWER_TPS65090) += pmic_tps65090.o
>> +obj-$(CONFIG_POWER_TPS65090_EC) += pmic_tps65090_ec.o
>> obj-$(CONFIG_POWER_TPS65217) += pmic_tps65217.o
>> obj-$(CONFIG_POWER_TPS65218) += pmic_tps65218.o
>> obj-$(CONFIG_POWER_TPS65910) += pmic_tps65910.o
>> diff --git a/drivers/power/pmic/pmic_tps65090_ec.c
>> b/drivers/power/pmic/pmic_tps65090_ec.c
>> new file mode 100644
>> index 000..93b7923
>> --- /dev/null
>> +++ b/drivers/power/pmic/pmic_tps65090_ec.c
>> @@ -0,0 +1,212 @@
>> +/*
>> + * Copyright (c) 2013 The Chromium OS Authors. All rights reserved.
>> + * Use of this source code is governed by a BSD-style license that can be
>> + * found in the LICENSE file.
>> + *
>> + * Alternatively, this software may be distributed under the terms of the
>> + * GNU General Public License ("GPL") version 2 as published by the Free
>> + * Software Foundation.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +DECLARE_GLOBAL_DATA_PTR;
>> +
>> +#define TPS65090_ADDR 0x48
>> +
>> +static struct tps65090 {
>> + struct cros_ec_dev *dev;/* The CROS_EC device */
>> +} config;
>> +
>> +/* TPS65090 register addresses */
>> +enum {
>> + REG_FET1_CTRL = 0x0f,
>> + REG_FET2_CTRL,
>> + REG_FET3_CTRL,
>> + REG_FET4_CTRL,
>> + REG_FET5_CTRL,
>> + REG_FET6_CTRL,
>> + REG_FET7_CTRL,
>> + TPS65090_NUM_REGS,
>> +};
>> +
>> +enum {
>> + MAX_FET_NUM = 7,
>> + MAX_CTRL_READ_TRIES = 5,
>> +
>> + /* TPS65090 FET_CTRL register values */
>> + FET_CTRL_TOFET = 1 << 7, /* Timeout, startup, overload
>> */
>> + FET_CTRL_PGFET = 1 << 4, /* Power good for FET status */
>> + FET_CTRL_WAIT = 3 << 2, /* Overcurrent timeout max */
>> + FET_CTRL_ADENFET= 1 << 1, /* Enable output auto discharge
>> */
>> + FET_CTRL_ENFET = 1 << 0, /* Enable FET */
>> +};
>> +
>> +/**
>> + * tps65090_read - read a byte from tps6090
>> + *
>> + * @param reg The register address to read from.
>> + * @param val We'll return value value read here.
>> + * @return 0 if ok; error if EC returns failure.
>> + */
>> +static int tps65090_read(u32 reg, u8 *val)
>> +{
>> + return cros_ec_i2c_xfer(config.dev, TPS65090_ADDR, reg, 1,
>> + val, 1, true);
>> +}
>> +
>> +/**
>> + * tps65090_write - write a byte to tps6090
>> + *
>> + * @param reg The register address to write to.
>> + * @param val The value to write.
>> + * @return 0 if ok; error if EC returns failure.
>> + */
>> +static int tps65090_write(u32 reg, u8 val)
>> +{
>> + return cros_ec_i2c_xfer(config.dev, TPS65090_ADDR, reg, 1,
>> + &val, 1, false);
>> +}
>> +
>> +/**
>> + * Checks for a valid FET number
>> + *
>> + * @param fet_id FET number to check
>> + * @return 0 if ok, -1 if FET value is out of range
>> + */
>> +static int tps65090_check_fet(unsigned int fet_id)
>> +{
>> + if (fet_id == 0 || fet_id > MAX_FET_NUM) {
>> + debug("parameter fet_id is out of range, %u not in 1 ~
>> %u\n",
>> + fet_id, MAX_FET_NUM);
>> + return -1;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +/**
>> + * Set the power state for a FET
>> + *
>> + * @param fet_id Fet number to set (1..MAX_FET_NUM)
>> + * @param set 1 to power on FET, 0 to power off
>> + * @return FET_ERR_COMMS if we got a comms error, FET_ERR_NOT_READY if
>> the
>> + * FET failed to change state. If all is ok, returns 0.
>> + */
>> +static int tps65090_fet_set(int fet_id, int set)
>> +{
>> + int retry;
>> + u8 reg = 0, value;
>> +
>> + value =
Re: [U-Boot] [PATCH 4/4] dm: simplify the loop in lists_driver_lookup_name()
Hi Masahiro, Simon,
On 09/28/14 18:22, Simon Glass wrote:
> Hi Masahiro,
>
> On 28 September 2014 07:52, Masahiro Yamada wrote:
>> if (strncmp(name, entry->name, len))
>> continue;
>>
>> /* Full match */
>> if (len == strlen(entry->name))
>> return entry;
>>
>> is equivalent to:
>>
>> if (!strcmp(name, entry->name))
>> return entry;
>>
>> The latter is simpler.
>>
>> Signed-off-by: Masahiro Yamada
>> ---
>>
>> drivers/core/lists.c | 9 +
>> 1 file changed, 1 insertion(+), 8 deletions(-)
>>
>> diff --git a/drivers/core/lists.c b/drivers/core/lists.c
>> index 699f94b..3a1ea85 100644
>> --- a/drivers/core/lists.c
>> +++ b/drivers/core/lists.c
>> @@ -24,19 +24,12 @@ struct driver *lists_driver_lookup_name(const char *name)
>> ll_entry_start(struct driver, driver);
>> const int n_ents = ll_entry_count(struct driver, driver);
>> struct driver *entry;
>> - int len;
>>
>> if (!drv || !n_ents)
>> return NULL;
>>
>> - len = strlen(name);
>> -
>> for (entry = drv; entry != drv + n_ents; entry++) {
>> - if (strncmp(name, entry->name, len))
>> - continue;
>> -
>> - /* Full match */
>> - if (len == strlen(entry->name))
>> + if (!strcmp(name, entry->name))
>> return entry;
>> }
>
> The discussion on this was here:
>
> http://lists.denx.de/pipermail/u-boot/2014-September/189336.html
>
> I don't see a lot of value in the extra code, so I think we should
> take this patch. If it is found to be a problem, we can go back to the
> defensive code and add a test case so it is clear what exactly we are
> defending against.
>
> Acked-by: Simon Glass
>
Following the discussion referenced above, we have here a classic
case of C language strings problem.
One can dig about it all over the Internet (for example here [1]).
I don't think we will invent a solution for that problem here.
Also we are not about to abandon the C language...
So, unless someone comes out with a real case to solve, I think
we should merge this.
Acked-by: Igor Grinberg
[1] http://www.sei.cmu.edu/library/abstracts/news-at-sei/feature120061.cfm
--
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ci_udc: force full-speed operation if !CONFIG_USB_GADGET_DUALSPEED
Signed-off-by: Eric Nelson --- drivers/usb/gadget/ci_udc.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c index 2572b34..9f2fd15 100644 --- a/drivers/usb/gadget/ci_udc.c +++ b/drivers/usb/gadget/ci_udc.c @@ -777,6 +777,11 @@ static int ci_pullup(struct usb_gadget *gadget, int is_on) /* select DEVICE mode */ writel(USBMODE_DEVICE, &udc->usbmode); +#if !defined(CONFIG_USB_GADGET_DUALSPEED) && defined(CONFIG_MX6) + /* force full-speed mode */ + writel(readl(&udc->portsc)|(1<<24), &udc->portsc); +#endif + writel(0x, &udc->epflush); /* Turn on the USB connection by enabling the pullup resistor */ -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ci_udc: force full-speed operation if !CONFIG_USB_GADGET_DUALSPEED
On Sunday, September 28, 2014 at 09:12:35 PM, Eric Nelson wrote: > Signed-off-by: Eric Nelson > --- > drivers/usb/gadget/ci_udc.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c > index 2572b34..9f2fd15 100644 > --- a/drivers/usb/gadget/ci_udc.c > +++ b/drivers/usb/gadget/ci_udc.c > @@ -777,6 +777,11 @@ static int ci_pullup(struct usb_gadget *gadget, int > is_on) /* select DEVICE mode */ > writel(USBMODE_DEVICE, &udc->usbmode); > > +#if !defined(CONFIG_USB_GADGET_DUALSPEED) && defined(CONFIG_MX6) > + /* force full-speed mode */ > + writel(readl(&udc->portsc)|(1<<24), &udc->portsc); > +#endif > + setbits_le32() and I'm sure you know better than to use 1 << 24 . Please define that bit proper. And you also know you should supply a commit message, right ? > writel(0x, &udc->epflush); > > /* Turn on the USB connection by enabling the pullup resistor */ Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] Re: [PATCH v2 10/10] ARM: sun6i: Add Colombus board defconfig
On Sun, 2014-09-28 at 20:10 +0200, Hans de Goede wrote: > On 09/28/2014 06:20 PM, Ian Campbell wrote: > > On Sun, 2014-09-28 at 17:40 +0200, Hans de Goede wrote: > >> Before you do that, note that I've just added 2 patches there, which I > >> would > >> like to get into v2014.10. Specifically I'm hoping that I can get some > >> positive testing feedback on the bananapi gmac patch I've send (off-list), > >> and I believe we really should try to get the bananapi fix into v2014.10, > >> and if we're going todo a pull-req for v2014.10, we might as well include > >> the 2 patches I've just added to next. Do you agree ? > > > > You mean these two? > > sun7i: Add support for Olimex A20-OLinuXino-LIME2 > > mmc: sunxi: add SDHC support for sun6i/sun7i/sun8i > > Yes. > > > The latter seems like a feature to me, or at least the changelog doesn't > > give any rationale why it should go in now rather than waiting for the > > next merge window (i.e. why it's a bugfix, what the upside is to justify > > its inclusion now). How much testing has it had and what are the > > potential downsides? > > AFAIK the downside is that High Capacity cards will not work without it. > > Looking at the code if this bit is set, then for some commands > drivers/mmc/mmc.c or-s in OCR_HCS into the mmc cmdarg, so I guess you're > right that this may cause some undesirable side effects, so lets delay > this one. OK. > > WRT the new board (and new boards generally), I'm in two minds. On the > > one hand they are pretty low risk (can't regress anything else, at least > > not in this case), on the other we are 6 weeks past the close of the > > merge window and 2 from the release date, so we are pretty far along. > > Where do we draw the line? > > Normally I would not include new boards at this moment in the cycle, but > since we need to do a pull-req for the gmac anyways I thought it would > be nice to have it included, esp. since many distros only spin things > like sdcard boot images once, so if we do not include it now, many distros > will not get it for a significant amount of time. There's always Just One More Board(tm) ;-) > Either way let me know how you want to proceed, if you think we should not > include this, then I'll send a pull-req with only the gmac fix. As I say I'm in two minds. I'm not really sure what the u-boot norm is on this, I was hoping someone might chime in (although it's not been very long and the thread topic doesn't exactly scream for attention). Maybe run it by Albert/Tom and see how they feel about such things in general? Where run it by might be two alternate PRs? Or a PR structured so the new board can trivially be dropped? > > The gmac fix is a clear bug fix and once it is properly posted publicly > > I will ack and then I agree it should go in. > > I was hoping for Stephen to get around to testing it today, and then I wanted > to send it out with his Tested-by. I'll just go and send it as is for now. s/Stephen/Karsten/? Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ci_udc: force full-speed operation if !CONFIG_USB_GADGET_DUALSPEED
Hi Marek, On 09/28/2014 01:28 PM, Marek Vasut wrote: > On Sunday, September 28, 2014 at 09:12:35 PM, Eric Nelson wrote: >> Signed-off-by: Eric Nelson >> --- >> drivers/usb/gadget/ci_udc.c | 5 + >> 1 file changed, 5 insertions(+) >> >> diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c >> index 2572b34..9f2fd15 100644 >> --- a/drivers/usb/gadget/ci_udc.c >> +++ b/drivers/usb/gadget/ci_udc.c >> @@ -777,6 +777,11 @@ static int ci_pullup(struct usb_gadget *gadget, int >> is_on) /* select DEVICE mode */ >> writel(USBMODE_DEVICE, &udc->usbmode); >> >> +#if !defined(CONFIG_USB_GADGET_DUALSPEED) && defined(CONFIG_MX6) >> +/* force full-speed mode */ >> +writel(readl(&udc->portsc)|(1<<24), &udc->portsc); >> +#endif >> + > > setbits_le32() and I'm sure you know better than to use 1 << 24 . Please > define > that bit proper. > Yep. Will do. > > And you also know you should supply a commit message, right ? > I'll give it another shot in V2. >> writel(0x, &udc->epflush); >> >> /* Turn on the USB connection by enabling the pullup resistor */ > Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCH 5/7] sun4i: Add support for a number of new sun4i boards
On Sun, 28 Sep 2014 21:34:57 +0200 Arnd Gronenberg wrote: > > On 09/28/2014 05:58 PM, Hans de Goede wrote: > > [...] > > > > On 09/18/2014 06:07 PM, Siarhei Siamashka wrote: > >> Which revision of A10-OLinuXino-LIME do you have? Revision A is known > >> to have troubles running stable at 1008MHz CPU clock speed, as confirmed > >> on a sample set of two boards (mine and Oliver Schinagl's): > >> > >> https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg04343.html > > > > I have a revision A board. > > My Olimex A10 OLinuXino Lime is also labelled "Rev. A"... It is running > stable at 1008MHz and I just tried Olivers djpeg test without any problems. > > I'm running Hans' u-boot-sunxi 2014.10-rc1-g7190869 and Linux mainline > 3.17.0-rc1-00158-g451fd72. Thanks for trying the test and sharing the results. You are extending our sample set from 2 boards to 3 (by the whole 50%) :-) But could you please check whether you really have libjpeg-turbo (with NEON optimizations) and not libjpeg from IJG? I did mention libjpeg-turbo a few times in my original e-mail, however somehow failed to communicate that it is strictly required to reproduce the problem. Sorry about this. One of the commenters in the old discussion thread already fell into this trap :-( Later I provided a script for automating everything by using a ruby script. The script performs downloading and compiling the "right" libjpeg-turbo and then runs tests for all cpufreq operating points. But since the mainline kernel does not have cpufreq support yet, this script will not help us here (and is not really needed). Anyway, please check whether you have libjpeg-turbo by running "djpeg -v" command. If your distro happens to have IJG libjpeg instead of libjpeg-turbo, then you can download and compile libjpeg-turbo from sources (it is quite a small package and does not require any dependencies). After that, you can run the test as demonstrated in the examples below. My results from A10-Lime revision A with the sunxi-3.4 kernel and u-boot v2014.10-rc2: $ djpeg -v libjpeg-turbo version 1.3.0 (build 20130811) $ cd /tmp && wget http://linux-sunxi.org/images/8/83/A10-LIME.jpg $ while true ; do djpeg A10-LIME.jpg | md5sum ; done bf66d2bd1a88c5720b0dc8d8ece43099 - bf66d2bd1a88c5720b0dc8d8ece43099 - 6047ca65e1412dd3f53b250239e4558b - bf66d2bd1a88c5720b0dc8d8ece43099 - 9d8eb11018cca04f70883c6ed9ddb9c6 - 7d2a4baa11e7015e2b8ae5717fce699b - 513bd48bcd3a67705324ec8658646e7d - f61c7c8f42b86ede28d48dfb350efd64 - 50a3b1ea14994d19a66238f2414d9f5c - 674f968fe8d7c79b2f7116c94b2fb02c - bf66d2bd1a88c5720b0dc8d8ece43099 - b57efa7bb81263a93f69fcbbbd06d590 - d1627d8fd02f54e0154fcced72be637b - ab92721819073d0fb4dd2a7a67afb0fc - 79cf9706c29c19b9325d3e04f34b5059 - bf66d2bd1a88c5720b0dc8d8ece43099 - 9ba81185fd5ed48277cc590fdb323955 - d43cdb0215bae6de33b7921b20c5545f - d1ef0584fdff38c84a7d24a32fde4de9 - 1cef1e0202605a93870279f23d93287f - f7fd0ae6b3beda26f61c2be566224ac3 - c346e833833f9b35093be336cadbcbc2 - 02c6e7e19882f438e5a9123a0d3e7ea2 - b9d788d94a469b3bad20a997a039ce88 - 8545180d6384a6319fbf672052d61549 - 455b8da5c39b21b5104c12b6d02e9ff8 - 670df0c3bf6becf5e4378e336d193f45 - 07e922c9510d9d75f701317ada24d1f9 - 8cdae0aa48061da5c45ac81159bdac53 - 4f3b47ad5603f7253c0a4b13a61987a5 - 02f6175d5fb8672e69c7e433451b5dbc - 1440adb6576c6d02cf05c31b3c2c2b7c - 618a736628096581dfd2d5421e061235 - 2a791022a39f7e8d57efa50cd801007b - 44d2e8dd4a205d3aadcfc25a446fe06e - 72e2d96eb5e0ea987763cfaa1f3ca0a5 - 4f4c11e23f09f2923f925e6bb0a88deb - f6ce3826e0e91ca75fbca378f21a6a72 - 6d2c6ac6eb8c96cad5b19e3287192802 - 8db6a3c5fb031317eb352110261e23fd - And results with the mainline kernel and u-boot v2014.10-rc2: $ djpeg -v libjpeg-turbo version 1.3.0 (build 20130811) $ cd /tmp && wget http://linux-sunxi.org/images/8/83/A10-LIME.jpg $ while true ; do djpeg A10-LIME.jpg | md5sum ; done bf66d2bd1a88c5720b0dc8d8ece43099 - bf66d2bd1a88c5720b0dc8d8ece43099 - bf66d2bd1a88c5720b0dc8d8ece43099 - bf66d2bd1a88c5720b0dc8d8ece43099 - bf66d2bd1a88c5720b0dc8d8ece43099 - bf66d2bd1a88c5720b0dc8d8ece43099 - bf66d2bd1a88c5720b0dc8d8ece43099 - bf66d2bd1a88c5720b0dc8d8ece43099 - bf66d2bd1a88c5720b0dc8d8ece43099 - bf66d2bd1a88c5720b0dc8d8ece43099 - bf66d2bd1a88c5720b0dc8d8ece43099 - bf66d2bd1a88c5720b0dc8d8ece43099 - bf66d2bd1a88c5720b0dc8d8ece43099 - bf66d2bd1a88c5720b0dc8d8ece43099 - bf66d2bd1a88c5720b0dc8d8ece43099 - bf66d2bd1a88c5720b0dc8d8ece43099 - bf66d2bd1a88c5720b0dc8d8ece43099 - bf66d2bd1a88c5720b0dc8d8ece43099 - bf66d2bd1a88c5720b0dc8d8ece43099 - bf66d2bd1a88c5720b0dc8d8ece43099 - bf66d2bd1a88c5720b0dc8d8ece43099 - bf66d2bd1a88c5720b0dc8d8ece43099 - bf66d2bd1a88c5720b0dc8d8ece43099 - bf66d2bd1a88c5720b0dc8d8ece43099 - bf66d2bd1a88c5720b0dc8d8ece43099 - bf66d2bd1a88c5720b0dc8d8ece43099 - ee013e5796bbfed7dcae4b7bae195fd7 - bf66d2bd1a88c5720b0dc8d8ece43099 - bf66d2bd1a88c5720b0dc8d8ece43099 - bf66d2bd1a88c5720b0dc8d8ece43099 - bf66d2bd
Re: [U-Boot] [PATCH v2 00/40] ARM: tegra: Add PCIe support
Hi Thierry, On 26 August 2014 09:33, Thierry Reding wrote: > From: Thierry Reding > > This series adds PCIe support for Tegra20, Tegra30 and Tegra124. The size > is > mostly due to the large number of infrastructure that's added (libfdt, > Tegra > specific drivers required by the PCIe driver). In this version I've > included > all patches that were previously split into three separate series. > Spreading > them over multiple series is probably not worth it since there might be > some > dependencies between them and only the end result gives a completely > working > setup. > FYI I have applied this series on top of driver model - it is at u-boot-dm.git branch 'norrin-working'. There were a quite few conflicts which I resolved (mostly with mainline I think). I tested it on beaver, trimslice and jetson-tk1. Are you going to respin it? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] usb: ci_udc: respect CONFIG_USB_GADGET_DUALSPEED
Force full-speed (12 Mbit/s) operation if CONFIG_USB_GADGET_DUALSPEED
is not defined.
The controller is capable of high-speed (480 Mbit/s) operation,
but some designs may require the use of lower-speed operation.
Signed-off-by: Eric Nelson
---
drivers/usb/gadget/ci_udc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c
index 2572b34..dbbeff7 100644
--- a/drivers/usb/gadget/ci_udc.c
+++ b/drivers/usb/gadget/ci_udc.c
@@ -766,6 +766,7 @@ void udc_disconnect(void)
static int ci_pullup(struct usb_gadget *gadget, int is_on)
{
+ u32 regval;
struct ci_udc *udc = (struct ci_udc *)controller.ctrl->hcor;
if (is_on) {
/* RESET */
@@ -777,6 +778,11 @@ static int ci_pullup(struct usb_gadget *gadget, int is_on)
/* select DEVICE mode */
writel(USBMODE_DEVICE, &udc->usbmode);
+#if !defined(CONFIG_USB_GADGET_DUALSPEED) && defined(CONFIG_MX6)
+ /* Port force Full-Speed Connect */
+ setbits_le32(&udc->portsc, PFSC);
+#endif
+
writel(0x, &udc->epflush);
/* Turn on the USB connection by enabling the pullup resistor */
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 0/15] samsung: Use common config files with Samsung boards
This series tries to unify the Samsung board configs into a few header
files for exynos5 and exynos4.
The purpose is to make it easier to move to driver model. In that case
I would like things like the GPIO drivers and serial drivers to work in
a standard way, and not need to support device tree and platform data at
the same time. That would be quite painful.
Another reason is that the Chrome OS EC drivers are currently included in
boards that don't have a Chrome OS EC. This concern was raised by the
Samsung maintainer (Minkyu) a while back.
There are still a few boards that don't use CONFIG_OF_CONTROL so I have
updated these rudimentary of device tree files based on feedback.
This series has the side-effect of getting the EC interface working
properly on Pit, so the keyboard works. It also provides access to the
TPS65090 PMIC, which means that the backlight is enabled.
Changes in v4:
- Address review nits from Minkyu
- Make this driver more like the one it came from
- Rebase on top of master (CONFIG_OF settings moved to Kconfig)
- Remove special FET_ERR_NOT_READY etc. as use standard errors
Changes in v3:
- Adjust device tree file based on Robert Baldyga's example
Changes in v2:
- Add new patch to enable keyboard on pit
- Add new patch to split out cros_ec drivers
- Add new patch to use 900MHz ARM frequeny in SPL for peach_pit
- Avoid using a common file, and just add a device tree
- Don't enable the cros_ec on smdk5420
- Fix 'cashe' typo in commit subject
- Fix device tree base addresses
- Leave CONFIG_SERIAL3 in the individual board files
- Leave in a few configs which are not in fact common to all boards
- Reduce the number of common elements to avoid needing #undefs later
- Slightly reword the commit message
Simon Glass (15):
Exynos: Use 900MHz ARM frequency in SPL for peach_pit
exynos5: Enable data cache
cros_ec: power: Add a tunnelled version of the tps65090 driver
cros_ec: exynos: Use the correct tps65090 driver in each case
dm: exynos: Split out the cros_ec drivers
exynos: dts: Add device tree node for cros_ec keyboard
exynos: Rename -dt config files to -common
exynos: Move common exynos settings into a common file
exynos: Move common smdk5420 things to common file
exynos: config: Move cros_ec and tps65090 out of smdk boards
config: Move arndale to use common exynos5250 file
config: Move smdkv310 to use common exynos4 file
samsung: Enable device tree for s5p_goni
samsung: Enable device tree for smdkc100
exynos: Enable pre-relocation malloc()
arch/arm/Kconfig | 13 +-
arch/arm/cpu/armv7/exynos/Kconfig | 1 +
arch/arm/cpu/armv7/s5pc1xx/Kconfig | 25 +++
arch/arm/dts/Makefile | 3 +
arch/arm/dts/exynos4210-smdkv310.dts | 21 ++
arch/arm/dts/exynos5420-peach-pit.dts | 57 +-
arch/arm/dts/s5pc1xx-goni.dts | 28 +++
arch/arm/dts/s5pc1xx-smdkc100.dts | 29 +++
arch/arm/include/asm/arch-s5pc1xx/periph.h | 61 ++
arch/arm/include/asm/arch-s5pc1xx/pinmux.h | 50 +
configs/s5p_goni_defconfig | 2 +
configs/smdkc100_defconfig | 2 +
configs/smdkv310_defconfig | 1 +
drivers/mmc/s5p_sdhci.c| 2 -
drivers/power/pmic/Makefile| 3 +-
drivers/power/pmic/pmic_tps65090_ec.c | 218 +
include/configs/arndale.h | 195 +-
include/configs/{exynos4-dt.h => exynos-common.h} | 110 +++
include/configs/exynos4-common.h | 68 +++
include/configs/{exynos5-dt.h => exynos5-common.h} | 126 ++--
include/configs/exynos5-dt-common.h| 35
.../{exynos5250-dt.h => exynos5250-common.h} | 7 +-
.../configs/{exynos5420.h => exynos5420-common.h} | 22 ++-
include/configs/odroid.h | 4 +-
include/configs/origen.h | 5 +-
include/configs/peach-pit.h| 16 +-
include/configs/s5p_goni.h | 9 +-
include/configs/s5pc210_universal.h| 5 +-
include/configs/smdk5250.h | 23 ++-
include/configs/smdk5420.h | 5 +-
include/configs/smdkc100.h | 6 +
include/configs/smdkv310.h | 61 +-
include/configs/snow.h | 25 ++-
include/configs/trats.h| 6 +-
include/configs/trats2.h | 6 +-
35 files changed, 760 insertions(+), 490 deletions(-)
create mode 100644 arch/arm/cpu/armv7/s5pc1xx/Kconfig
create mode 100644 arch/arm/dts/exynos4210-smdkv310.dts
create mode 100644 arch/arm/dts/s5pc1xx-goni.dts
create mode 100644 arch/arm/dts/s5pc1
[U-Boot] [PATCH v4 01/15] Exynos: Use 900MHz ARM frequency in SPL for peach_pit
The device seems to hang in SPL if the full speed is used when booting from
USB, perhaps because the PMIC has not been set to the maximum ARM core
voltage yet. Slow it down to a reliable speed.
Signed-off-by: Simon Glass
---
Changes in v4: None
Changes in v3: None
Changes in v2:
- Add new patch to use 900MHz ARM frequeny in SPL for peach_pit
arch/arm/dts/exynos5420-peach-pit.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/dts/exynos5420-peach-pit.dts
b/arch/arm/dts/exynos5420-peach-pit.dts
index 3ed70a8..207782e 100644
--- a/arch/arm/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/dts/exynos5420-peach-pit.dts
@@ -32,7 +32,7 @@
mem-manuf = "samsung";
mem-type = "ddr3";
clock-frequency = <8>;
- arm-frequency = <17>;
+ arm-frequency = <9>;
};
tmu@1006 {
--
2.1.0.rc2.206.gedb03e5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 0/15] samsung: Use common config files with Samsung boards
This series tries to unify the Samsung board configs into a few header
files for exynos5 and exynos4.
The purpose is to make it easier to move to driver model. In that case
I would like things like the GPIO drivers and serial drivers to work in
a standard way, and not need to support device tree and platform data at
the same time. That would be quite painful.
Another reason is that the Chrome OS EC drivers are currently included in
boards that don't have a Chrome OS EC. This concern was raised by the
Samsung maintainer (Minkyu) a while back.
There are still a few boards that don't use CONFIG_OF_CONTROL so I have
updated these rudimentary of device tree files based on feedback.
This series has the side-effect of getting the EC interface working
properly on Pit, so the keyboard works. It also provides access to the
TPS65090 PMIC, which means that the backlight is enabled.
Changes in v4:
- Address review nits from Minkyu
- Make this driver more like the one it came from
- Rebase on top of master (CONFIG_OF settings moved to Kconfig)
- Remove special FET_ERR_NOT_READY etc. and use standard errors
Changes in v3:
- Adjust device tree file based on Robert Baldyga's example
Changes in v2:
- Add new patch to enable keyboard on pit
- Add new patch to split out cros_ec drivers
- Add new patch to use 900MHz ARM frequeny in SPL for peach_pit
- Avoid using a common file, and just add a device tree
- Don't enable the cros_ec on smdk5420
- Fix 'cashe' typo in commit subject
- Fix device tree base addresses
- Leave CONFIG_SERIAL3 in the individual board files
- Leave in a few configs which are not in fact common to all boards
- Reduce the number of common elements to avoid needing #undefs later
- Slightly reword the commit message
Simon Glass (15):
Exynos: Use 900MHz ARM frequency in SPL for peach_pit
exynos5: Enable data cache
cros_ec: power: Add a tunnelled version of the tps65090 driver
cros_ec: exynos: Use the correct tps65090 driver in each case
dm: exynos: Split out the cros_ec drivers
exynos: dts: Add device tree node for cros_ec keyboard
exynos: Rename -dt config files to -common
exynos: Move common exynos settings into a common file
exynos: Move common smdk5420 things to common file
exynos: config: Move cros_ec and tps65090 out of smdk boards
config: Move arndale to use common exynos5250 file
config: Move smdkv310 to use common exynos4 file
samsung: Enable device tree for s5p_goni
samsung: Enable device tree for smdkc100
exynos: Enable pre-relocation malloc()
arch/arm/Kconfig | 13 +-
arch/arm/cpu/armv7/exynos/Kconfig | 1 +
arch/arm/cpu/armv7/s5pc1xx/Kconfig | 25 +++
arch/arm/dts/Makefile | 3 +
arch/arm/dts/exynos4210-smdkv310.dts | 21 ++
arch/arm/dts/exynos5420-peach-pit.dts | 57 +-
arch/arm/dts/s5pc1xx-goni.dts | 28 +++
arch/arm/dts/s5pc1xx-smdkc100.dts | 29 +++
arch/arm/include/asm/arch-s5pc1xx/periph.h | 61 ++
arch/arm/include/asm/arch-s5pc1xx/pinmux.h | 50 +
configs/s5p_goni_defconfig | 2 +
configs/smdkc100_defconfig | 2 +
configs/smdkv310_defconfig | 1 +
drivers/mmc/s5p_sdhci.c| 2 -
drivers/power/pmic/Makefile| 3 +-
drivers/power/pmic/pmic_tps65090_ec.c | 218 +
include/configs/arndale.h | 195 +-
include/configs/{exynos4-dt.h => exynos-common.h} | 110 +++
include/configs/exynos4-common.h | 68 +++
include/configs/{exynos5-dt.h => exynos5-common.h} | 126 ++--
include/configs/exynos5-dt-common.h| 35
.../{exynos5250-dt.h => exynos5250-common.h} | 7 +-
.../configs/{exynos5420.h => exynos5420-common.h} | 22 ++-
include/configs/odroid.h | 4 +-
include/configs/origen.h | 5 +-
include/configs/peach-pit.h| 16 +-
include/configs/s5p_goni.h | 9 +-
include/configs/s5pc210_universal.h| 5 +-
include/configs/smdk5250.h | 23 ++-
include/configs/smdk5420.h | 5 +-
include/configs/smdkc100.h | 6 +
include/configs/smdkv310.h | 61 +-
include/configs/snow.h | 25 ++-
include/configs/trats.h| 6 +-
include/configs/trats2.h | 6 +-
35 files changed, 760 insertions(+), 490 deletions(-)
create mode 100644 arch/arm/cpu/armv7/s5pc1xx/Kconfig
create mode 100644 arch/arm/dts/exynos4210-smdkv310.dts
create mode 100644 arch/arm/dts/s5pc1xx-goni.dts
create mode 100644 arch/arm/dts/s5pc
[U-Boot] [PATCH v4 12/15] config: Move smdkv310 to use common exynos4 file
Most of the smdkv310 features are common with other exynos4 boards. To
permit easier addition of driver model support, use the common file and
add a device tree file.
Signed-off-by: Simon Glass
---
Changes in v4:
- Rebase on top of master (CONFIG_OF settings moved to Kconfig)
Changes in v3: None
Changes in v2:
- Leave in a few configs which are not in fact common to all boards
arch/arm/cpu/armv7/exynos/Kconfig| 1 +
arch/arm/dts/Makefile| 1 +
arch/arm/dts/exynos4210-smdkv310.dts | 21 +
configs/smdkv310_defconfig | 1 +
include/configs/smdkv310.h | 61 ++--
5 files changed, 34 insertions(+), 51 deletions(-)
create mode 100644 arch/arm/dts/exynos4210-smdkv310.dts
diff --git a/arch/arm/cpu/armv7/exynos/Kconfig
b/arch/arm/cpu/armv7/exynos/Kconfig
index e7c93d8..7a0d182 100644
--- a/arch/arm/cpu/armv7/exynos/Kconfig
+++ b/arch/arm/cpu/armv7/exynos/Kconfig
@@ -5,6 +5,7 @@ choice
config TARGET_SMDKV310
bool "Exynos4210 SMDKV310 board"
+ select OF_CONTROL if !SPL_BUILD
config TARGET_TRATS
bool "Exynos4210 Trats board"
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 5f2b946..43a70e4 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1,4 +1,5 @@
dtb-$(CONFIG_EXYNOS4) += exynos4210-origen.dtb \
+ exynos4210-smdkv310.dtb \
exynos4210-universal_c210.dtb \
exynos4210-trats.dtb \
exynos4412-trats2.dtb \
diff --git a/arch/arm/dts/exynos4210-smdkv310.dts
b/arch/arm/dts/exynos4210-smdkv310.dts
new file mode 100644
index 000..c390c8f
--- /dev/null
+++ b/arch/arm/dts/exynos4210-smdkv310.dts
@@ -0,0 +1,21 @@
+/*
+ * Samsung's Exynos4210-based SMDKV310 board device tree source
+ *
+ * Copyright (c) 2014 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+/include/ "exynos4.dtsi"
+
+/ {
+ model = "Samsung SMDKV310 on Exynos4210";
+ compatible = "samsung,smdkv310", "samsung,exynos4210";
+
+ aliases {
+ serial0 = "/serial@1380";
+ console = "/serial@1382";
+ };
+
+};
diff --git a/configs/smdkv310_defconfig b/configs/smdkv310_defconfig
index 44da273..0d1a24f 100644
--- a/configs/smdkv310_defconfig
+++ b/configs/smdkv310_defconfig
@@ -2,3 +2,4 @@ CONFIG_SPL=y
+S:CONFIG_ARM=y
+S:CONFIG_ARCH_EXYNOS=y
+S:CONFIG_TARGET_SMDKV310=y
+CONFIG_DEFAULT_DEVICE_TREE="exynos4210-smdkv310"
diff --git a/include/configs/smdkv310.h b/include/configs/smdkv310.h
index 048c178..a2469eb 100644
--- a/include/configs/smdkv310.h
+++ b/include/configs/smdkv310.h
@@ -9,71 +9,42 @@
#ifndef __CONFIG_H
#define __CONFIG_H
+#include "exynos4-common.h"
+
+#undef CONFIG_BOARD_COMMON
+#undef CONFIG_USB_GADGET
+#undef CONFIG_USB_GADGET_S3C_UDC_OTG
+#undef CONFIG_CMD_USB_MASS_STORAGE
+#undef CONFIG_REVISION_TAG
+#undef CONFIG_CMD_THOR_DOWNLOAD
+#undef CONFIG_CMD_DFU
+
/* High Level Configuration Options */
-#define CONFIG_SAMSUNG 1 /* in a SAMSUNG core */
-#define CONFIG_S5P 1 /* S5P Family */
-#define CONFIG_EXYNOS4 /* EXYNOS4 Family */
#define CONFIG_EXYNOS4210 1 /* which is a EXYNOS4210 SoC */
#define CONFIG_SMDKV3101 /* working with
SMDKV310*/
-#include /* get chip and board defs */
-
-#define CONFIG_ARCH_CPU_INIT
-#define CONFIG_DISPLAY_CPUINFO
-#define CONFIG_DISPLAY_BOARDINFO
-#define CONFIG_BOARD_EARLY_INIT_F
-
/* Mach Type */
#define CONFIG_MACH_TYPE MACH_TYPE_SMDKV310
#define CONFIG_SYS_SDRAM_BASE 0x4000
#define CONFIG_SYS_TEXT_BASE 0x43E0
-/* input clock of PLL: SMDKV310 has 24MHz input clock */
-#define CONFIG_SYS_CLK_FREQ2400
-
-#define CONFIG_SETUP_MEMORY_TAGS
-#define CONFIG_CMDLINE_TAG
-#define CONFIG_INITRD_TAG
-#define CONFIG_CMDLINE_EDITING
-
/* Handling Sleep Mode*/
#define S5P_CHECK_SLEEP0x0BAD
#define S5P_CHECK_DIDLE0xBAD0
#define S5P_CHECK_LPA 0xABAD
-/* Size of malloc() pool */
-#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (1 << 20))
-
/* select serial console configuration */
#define CONFIG_SERIAL1 1 /* use SERIAL 1 */
-#define CONFIG_BAUDRATE115200
#define EXYNOS4_DEFAULT_UART_OFFSET0x01
-/* SD/MMC configuration */
-#define CONFIG_GENERIC_MMC
-#define CONFIG_MMC
-#define CONFIG_SDHCI
-#define CONFIG_S5P_SDHCI
-
-/* PWM */
-#define CONFIG_PWM 1
-
/* allow to overwrite serial and ethaddr */
#define CONFIG_ENV_OVERWRITE
-/* Command definition*/
-#include
-
#define CONFIG_CMD_PING
#define CONFIG_CMD_ELF
#define CONFIG_CMD_DHCP
-#define CONFIG_CMD_MMC
#define CONFIG_CMD_NET
-#define CONFIG_CMD_FAT
-
-#define CONFIG_BOOTDELAY 3
-#define CONFIG_ZERO_BOOTDELAY_CHECK
/* MM
[U-Boot] [PATCH v4 11/15] config: Move arndale to use common exynos5250 file
Most of the arndale features are common with other exynos5250 boards. To permit easier addition of driver model support, use the common file. Signed-off-by: Simon Glass --- Changes in v4: None Changes in v3: None Changes in v2: - Reduce the number of common elements to avoid needing #undefs later include/configs/arndale.h | 195 +--- include/configs/exynos-common.h | 1 - include/configs/exynos4-common.h| 2 + include/configs/exynos5-common.h| 12 --- include/configs/exynos5250-common.h | 5 - include/configs/exynos5420-common.h | 14 +++ include/configs/peach-pit.h | 10 ++ include/configs/smdk5250.h | 19 include/configs/smdk5420.h | 3 + include/configs/snow.h | 17 10 files changed, 66 insertions(+), 212 deletions(-) diff --git a/include/configs/arndale.h b/include/configs/arndale.h index 43077cf..f9ee40f 100644 --- a/include/configs/arndale.h +++ b/include/configs/arndale.h @@ -9,109 +9,19 @@ #ifndef __CONFIG_ARNDALE_H #define __CONFIG_ARNDALE_H -/* High Level Configuration Options */ -#define CONFIG_SAMSUNG /* in a SAMSUNG core */ -#define CONFIG_S5P /* S5P Family */ -#define CONFIG_EXYNOS5 /* which is in a Exynos5 Family */ -#define CONFIG_EXYNOS5250 - -#include /* get chip and board defs */ - -#define CONFIG_SYS_GENERIC_BOARD -#define CONFIG_ARCH_CPU_INIT -#define CONFIG_DISPLAY_CPUINFO -#define CONFIG_DISPLAY_BOARDINFO - - -/* Allow tracing to be enabled */ -#define CONFIG_TRACE -#define CONFIG_CMD_TRACE -#define CONFIG_TRACE_BUFFER_SIZE (16 << 20) -#define CONFIG_TRACE_EARLY_SIZE(8 << 20) -#define CONFIG_TRACE_EARLY -#define CONFIG_TRACE_EARLY_ADDR0x5000 - -/* Keep L2 Cache Disabled */ -#define CONFIG_SYS_DCACHE_OFF - -#define CONFIG_SYS_SDRAM_BASE 0x4000 -#define CONFIG_SYS_TEXT_BASE 0x43E0 - -/* input clock of PLL: SMDK5250 has 24MHz input clock */ -#define CONFIG_SYS_CLK_FREQ2400 - -#define CONFIG_SETUP_MEMORY_TAGS -#define CONFIG_CMDLINE_TAG -#define CONFIG_INITRD_TAG -#define CONFIG_CMDLINE_EDITING - -/* Power Down Modes */ -#define S5P_CHECK_SLEEP0x0BAD -#define S5P_CHECK_DIDLE0xBAD0 -#define S5P_CHECK_LPA 0xABAD - -/* Offset for inform registers */ -#define INFORM0_OFFSET 0x800 -#define INFORM1_OFFSET 0x804 - -/* Size of malloc() pool */ -#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (4 << 20)) - -/* select serial console configuration */ -#define CONFIG_BAUDRATE115200 -#define EXYNOS5_DEFAULT_UART_OFFSET0x01 -#define CONFIG_SILENT_CONSOLE - -/* Console configuration */ -#define CONFIG_CONSOLE_MUX -#define CONFIG_SYS_CONSOLE_IS_IN_ENV -#define EXYNOS_DEVICE_SETTINGS \ - "stdin=serial\0" \ - "stdout=serial\0" \ - "stderr=serial\0" - -#define CONFIG_EXTRA_ENV_SETTINGS \ - EXYNOS_DEVICE_SETTINGS +#include "exynos5250-common.h" /* SD/MMC configuration */ -#define CONFIG_GENERIC_MMC -#define CONFIG_MMC -#define CONFIG_SDHCI -#define CONFIG_S5P_SDHCI -#define CONFIG_DWMMC -#define CONFIG_EXYNOS_DWMMC #define CONFIG_SUPPORT_EMMC_BOOT -#define CONFIG_BOUNCE_BUFFER - - -#define CONFIG_BOARD_EARLY_INIT_F -#define CONFIG_SKIP_LOWLEVEL_INIT - -/* PWM */ -#define CONFIG_PWM /* allow to overwrite serial and ethaddr */ #define CONFIG_ENV_OVERWRITE -/* Command definition*/ -#include - -#define CONFIG_CMD_PING -#define CONFIG_CMD_ELF -#define CONFIG_CMD_MMC #define CONFIG_CMD_EXT2 -#define CONFIG_CMD_FAT -#define CONFIG_CMD_NET -#define CONFIG_CMD_HASH - -#define CONFIG_BOOTDELAY 3 -#define CONFIG_ZERO_BOOTDELAY_CHECK /* USB */ -#define CONFIG_CMD_USB #define CONFIG_USB_EHCI #define CONFIG_USB_EHCI_EXYNOS -#define CONFIG_USB_STORAGE #define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 3 #define CONFIG_USB_HOST_ETHER @@ -119,106 +29,23 @@ /* MMC SPL */ #define CONFIG_EXYNOS_SPL -#define COPY_BL2_FNPTR_ADDR0x02020030 - -#define CONFIG_SPL_LIBCOMMON_SUPPORT - -/* specific .lds file */ -#define CONFIG_SPL_LDSCRIPT"board/samsung/common/exynos-uboot-spl.lds" -#define CONFIG_SPL_TEXT_BASE 0x02023400 -#define CONFIG_SPL_MAX_FOOTPRINT (14 * 1024) - -#define CONFIG_BOOTCOMMAND "mmc read 40007000 451 2000; bootm 40007000" /* Miscellaneous configurable options */ -#define CONFIG_SYS_LONGHELP/* undef to save memory */ -#define CONFIG_SYS_HUSH_PARSER /* use "hush" command parser*/ #define CONFIG_SYS_PROMPT "ARNDALE # " -#define CONFIG_SYS_CBSIZE 256 /* Console I/O Buffer Size */ -#define CONFIG_SYS_PBSIZE 384 /* Print Buffer Size */ -#define CONFIG_SYS_MAXARGS 16 /* max number of command args */ #define CONF
[U-Boot] [PATCH v4 04/15] cros_ec: exynos: Use the correct tps65090 driver in each case
Exynos 5250 boards (snow, spring) use the I2C driver but Exynos 5420 boards cannot due to a hardware design decision. Select the correct driver to use in each case. Signed-off-by: Simon Glass Tested-by: Ajay Kumar --- Changes in v4: None Changes in v3: None Changes in v2: - Don't enable the cros_ec on smdk5420 - Slightly reword the commit message drivers/power/pmic/Makefile | 2 +- include/configs/exynos5250-dt.h | 1 + include/configs/peach-pit.h | 2 ++ 3 files changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile index 0b76611..e7b07eb 100644 --- a/drivers/power/pmic/Makefile +++ b/drivers/power/pmic/Makefile @@ -11,7 +11,7 @@ obj-$(CONFIG_POWER_MAX8997) += pmic_max8997.o obj-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o obj-$(CONFIG_POWER_MAX77686) += pmic_max77686.o obj-$(CONFIG_POWER_PFUZE100) += pmic_pfuze100.o -obj-$(CONFIG_POWER_TPS65090) += pmic_tps65090.o +obj-$(CONFIG_POWER_TPS65090_I2C) += pmic_tps65090.o obj-$(CONFIG_POWER_TPS65090_EC) += pmic_tps65090_ec.o obj-$(CONFIG_POWER_TPS65217) += pmic_tps65217.o obj-$(CONFIG_POWER_TPS65218) += pmic_tps65218.o diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h index c24984b..5504515 100644 --- a/include/configs/exynos5250-dt.h +++ b/include/configs/exynos5250-dt.h @@ -42,6 +42,7 @@ /* PMIC */ #define CONFIG_POWER_MAX77686 +#define CONFIG_POWER_TPS65090_I2C /* Sound */ #define CONFIG_CMD_SOUND diff --git a/include/configs/peach-pit.h b/include/configs/peach-pit.h index 987cef5..34734ad 100644 --- a/include/configs/peach-pit.h +++ b/include/configs/peach-pit.h @@ -30,4 +30,6 @@ #define LCD_BPPLCD_COLOR16 #endif +#define CONFIG_POWER_TPS65090_EC + #endif /* __CONFIG_PEACH_PIT_H */ -- 2.1.0.rc2.206.gedb03e5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 08/15] exynos: Move common exynos settings into a common file
Since exynos4 and exyno5 share many settings, we should move these into a common file to avoid duplication. In effect the changes are that all exynos boards now have EXT4 and FAT write support. This affects exynos5250 and exynos5420 which previously did not. This also disables the ext2 commands which are equivalent to ext4 anyway. Signed-off-by: Simon Glass --- Changes in v4: - Rebase on top of master (CONFIG_OF settings moved to Kconfig) Changes in v3: None Changes in v2: - Reduce the number of common elements to avoid needing #undefs later include/configs/exynos-common.h | 91 + include/configs/exynos4-common.h| 77 +-- include/configs/exynos5-common.h| 86 +-- include/configs/origen.h| 3 -- include/configs/s5pc210_universal.h | 3 -- include/configs/smdk5250.h | 4 -- include/configs/snow.h | 4 -- include/configs/trats.h | 4 -- include/configs/trats2.h| 4 -- 9 files changed, 105 insertions(+), 171 deletions(-) create mode 100644 include/configs/exynos-common.h diff --git a/include/configs/exynos-common.h b/include/configs/exynos-common.h new file mode 100644 index 000..7b9eda4 --- /dev/null +++ b/include/configs/exynos-common.h @@ -0,0 +1,91 @@ +/* + * Copyright (C) 2013 Samsung Electronics + * + * Common configuration settings for the SAMSUNG EXYNOS boards. + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#ifndef __EXYNOS_COMMON_H +#define __EXYNOS_COMMON_H + +/* High Level Configuration Options */ +#define CONFIG_SAMSUNG /* in a SAMSUNG core */ +#define CONFIG_S5P /* S5P Family */ + +#include /* get chip and board defs */ +#include + +#define CONFIG_SYS_GENERIC_BOARD +#define CONFIG_ARCH_CPU_INIT +#define CONFIG_DISPLAY_CPUINFO +#define CONFIG_DISPLAY_BOARDINFO +#define CONFIG_BOARD_COMMON +#define CONFIG_SKIP_LOWLEVEL_INIT +#define CONFIG_BOARD_EARLY_INIT_F + +/* Enable fdt support */ +#define CONFIG_OF_LIBFDT + +/* Keep L2 Cache Disabled */ +#define CONFIG_CMD_CACHE + +/* input clock of PLL: 24MHz input clock */ +#define CONFIG_SYS_CLK_FREQ2400 + +#define CONFIG_SETUP_MEMORY_TAGS +#define CONFIG_CMDLINE_TAG +#define CONFIG_INITRD_TAG +#define CONFIG_CMDLINE_EDITING +#define CONFIG_ENV_OVERWRITE + +/* Size of malloc() pool */ +#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (80 * SZ_1M)) + +/* select serial console configuration */ +#define CONFIG_BAUDRATE115200 + +/* SD/MMC configuration */ +#define CONFIG_GENERIC_MMC +#define CONFIG_MMC +#define CONFIG_S5P_SDHCI +#define CONFIG_SDHCI +#define CONFIG_DWMMC +#define CONFIG_EXYNOS_DWMMC +#define CONFIG_BOUNCE_BUFFER + +#define CONFIG_BOOTDELAY 3 +#define CONFIG_ZERO_BOOTDELAY_CHECK + +/* PWM */ +#define CONFIG_PWM + +/* Command definition*/ +#include + +#define CONFIG_CMD_MMC +#define CONFIG_CMD_EXT4 +#define CONFIG_CMD_EXT4_WRITE +#define CONFIG_CMD_FAT +#define CONFIG_FAT_WRITE + +#define CONFIG_DOS_PARTITION +#define CONFIG_EFI_PARTITION +#define CONFIG_CMD_PART +#define CONFIG_PARTITION_UUIDS + +/* Miscellaneous configurable options */ +#define CONFIG_SYS_LONGHELP/* undef to save memory */ +#define CONFIG_SYS_HUSH_PARSER /* use "hush" command parser*/ +#define CONFIG_SYS_CBSIZE 256 /* Console I/O Buffer Size */ +#define CONFIG_SYS_PBSIZE 384 /* Print Buffer Size */ +#define CONFIG_SYS_MAXARGS 16 /* max number of command args */ + +/* Boot Argument Buffer Size */ +#define CONFIG_SYS_BARGSIZECONFIG_SYS_CBSIZE + +/* FLASH and environment organization */ +#define CONFIG_SYS_NO_FLASH +#undef CONFIG_CMD_IMLS + +#endif /* __CONFIG_H */ diff --git a/include/configs/exynos4-common.h b/include/configs/exynos4-common.h index 38b8961..972add4 100644 --- a/include/configs/exynos4-common.h +++ b/include/configs/exynos4-common.h @@ -9,81 +9,29 @@ #ifndef __CONFIG_EXYNOS4_COMMON_H #define __CONFIG_EXYNOS4_COMMON_H -/* High Level Configuration Options */ -#define CONFIG_SAMSUNG /* in a SAMSUNG core */ -#define CONFIG_S5P /* S5P Family */ -#define CONFIG_EXYNOS4 /* which is in a Exynos4 Family */ +#define CONFIG_EXYNOS4 /* Exynos4 Family */ -#include /* get chip and board defs */ - -#define CONFIG_ARCH_CPU_INIT -#define CONFIG_DISPLAY_CPUINFO -#define CONFIG_DISPLAY_BOARDINFO -#define CONFIG_BOARD_COMMON -#define CONFIG_SYS_GENERIC_BOARD +#include "exynos-common.h" #define CONFIG_SYS_CACHELINE_SIZE 32 - -/* input clock of PLL: EXYNOS4 boards have 24MHz input clock */ -#define CONFIG_SYS_CLK_FREQ2400 - -#define CONFIG_SETUP_MEMORY_TAGS -#define CONFIG_CMDLINE_TAG #define CONFIG_REVISION_TAG -#define CONFIG_INITRD_TAG -#define CONFIG_CMDLINE_EDITING - -#include /*
[U-Boot] [PATCH v4 06/15] exynos: dts: Add device tree node for cros_ec keyboard
Add a keyboard definition so that the keyboard can be used on pit.
Signed-off-by: Simon Glass
---
Changes in v4: None
Changes in v3: None
Changes in v2:
- Add new patch to enable keyboard on pit
arch/arm/dts/exynos5420-peach-pit.dts | 55 +++
1 file changed, 55 insertions(+)
diff --git a/arch/arm/dts/exynos5420-peach-pit.dts
b/arch/arm/dts/exynos5420-peach-pit.dts
index 207782e..995e62b 100644
--- a/arch/arm/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/dts/exynos5420-peach-pit.dts
@@ -28,6 +28,61 @@
pmic = "/i2c@12ca";
};
+ cros-ec-keyb {
+ compatible = "google,cros-ec-keyb";
+ google,key-rows = <8>;
+ google,key-columns = <13>;
+ google,repeat-delay-ms = <240>;
+ google,repeat-rate-ms = <30>;
+ google,ghost-filter;
+ /*
+* Keymap entries take the form of 0xRRCC where
+* RR=Row CC=Column =Key Code
+* The values below are for a US keyboard layout and
+* are taken from the Linux driver. Note that the
+* 102ND key is not used for US keyboards.
+*/
+ linux,keymap = <
+ /* CAPSLCK F1 B F10 */
+ 0x0001003a 0x0002003b 0x00030030 0x00040044
+ /* N = R_ALT ESC */
+ 0x00060031 0x0008000d 0x000a0064 0x01010001
+ /* F4 G F7 H */
+ 0x0102003e 0x01030022 0x01040041 0x01060023
+ /* ' F9 BKSPACEL_CTRL */
+ 0x01080028 0x01090043 0x010b000e 0x021d
+ /* TAB F3 T F6 */
+ 0x0201000f 0x0202003d 0x02030014 0x02040040
+ /* ] Y 102ND [ */
+ 0x0205001b 0x02060015 0x02070056 0x0208001a
+ /* F8 GRAVE F2 5 */
+ 0x02090042 0x03010029 0x0302003c 0x03030006
+ /* F5 6 - \ */
+ 0x0304003f 0x03060007 0x0308000c 0x030b002b
+ /* R_CTRL A D F */
+ 0x0461 0x0401001e 0x04020020 0x04030021
+ /* S K J ; */
+ 0x0404001f 0x04050025 0x04060024 0x04080027
+ /* L ENTER Z C */
+ 0x04090026 0x040b001c 0x0501002c 0x0502002e
+ /* V X , M */
+ 0x0503002f 0x0504002d 0x05050033 0x05060032
+ /* L_SHIFT / . SPACE */
+ 0x0507002a 0x05080035 0x05090034 0x050B0039
+ /* 1 3 4 2 */
+ 0x06010002 0x06020004 0x06030005 0x06040003
+ /* 8 7 0 9 */
+ 0x06050009 0x06060008 0x0608000b 0x0609000a
+ /* L_ALT DOWN RIGHT Q */
+ 0x060a0038 0x060b006c 0x060c006a 0x07010010
+ /* E R W I */
+ 0x07020012 0x07030013 0x07040011 0x07050017
+ /* U R_SHIFTP O */
+ 0x07060016 0x07070036 0x07080019 0x07090018
+ /* UP LEFT*/
+ 0x070b0067 0x070c0069>;
+ };
+
dmc {
mem-manuf = "samsung";
mem-type = "ddr3";
--
2.1.0.rc2.206.gedb03e5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 03/15] cros_ec: power: Add a tunnelled version of the tps65090 driver
Unfortunately on Pit the AP has no direct access to the tps65090 but must
talk through the EC (over SPI) to the EC's I2C bus.
When driver model supports PMICs this will be relatively easy. In the
meantime the best approach is to duplicate the driver. It will be refactored
once driver model support is expanded.
Signed-off-by: Simon Glass
Tested-by: Ajay Kumar
---
Changes in v4:
- Address review nits from Minkyu
- Make this driver more like the one it came from
- Remove special FET_ERR_NOT_READY etc. and use standard errors
Changes in v3: None
Changes in v2: None
drivers/power/pmic/Makefile | 1 +
drivers/power/pmic/pmic_tps65090_ec.c | 218 ++
2 files changed, 219 insertions(+)
create mode 100644 drivers/power/pmic/pmic_tps65090_ec.c
diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
index a472f61..0b76611 100644
--- a/drivers/power/pmic/Makefile
+++ b/drivers/power/pmic/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
obj-$(CONFIG_POWER_MAX77686) += pmic_max77686.o
obj-$(CONFIG_POWER_PFUZE100) += pmic_pfuze100.o
obj-$(CONFIG_POWER_TPS65090) += pmic_tps65090.o
+obj-$(CONFIG_POWER_TPS65090_EC) += pmic_tps65090_ec.o
obj-$(CONFIG_POWER_TPS65217) += pmic_tps65217.o
obj-$(CONFIG_POWER_TPS65218) += pmic_tps65218.o
obj-$(CONFIG_POWER_TPS65910) += pmic_tps65910.o
diff --git a/drivers/power/pmic/pmic_tps65090_ec.c
b/drivers/power/pmic/pmic_tps65090_ec.c
new file mode 100644
index 000..ac0d44f
--- /dev/null
+++ b/drivers/power/pmic/pmic_tps65090_ec.c
@@ -0,0 +1,218 @@
+/*
+ * Copyright (c) 2013 The Chromium OS Authors.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define TPS65090_ADDR 0x48
+
+static struct tps65090 {
+ struct cros_ec_dev *dev;/* The CROS_EC device */
+} config;
+
+/* TPS65090 register addresses */
+enum {
+ REG_IRQ1 = 0,
+ REG_CG_CTRL0 = 4,
+ REG_CG_STATUS1 = 0xa,
+ REG_FET1_CTRL = 0x0f,
+ REG_FET2_CTRL,
+ REG_FET3_CTRL,
+ REG_FET4_CTRL,
+ REG_FET5_CTRL,
+ REG_FET6_CTRL,
+ REG_FET7_CTRL,
+ TPS65090_NUM_REGS,
+};
+
+enum {
+ IRQ1_VBATG = 1 << 3,
+ CG_CTRL0_ENC_MASK = 0x01,
+
+ MAX_FET_NUM = 7,
+ MAX_CTRL_READ_TRIES = 5,
+
+ /* TPS65090 FET_CTRL register values */
+ FET_CTRL_TOFET = 1 << 7, /* Timeout, startup, overload */
+ FET_CTRL_PGFET = 1 << 4, /* Power good for FET status */
+ FET_CTRL_WAIT = 3 << 2, /* Overcurrent timeout max */
+ FET_CTRL_ADENFET= 1 << 1, /* Enable output auto discharge */
+ FET_CTRL_ENFET = 1 << 0, /* Enable FET */
+};
+
+/**
+ * tps65090_read - read a byte from tps6090
+ *
+ * @param reg The register address to read from.
+ * @param val We'll return value value read here.
+ * @return 0 if ok; error if EC returns failure.
+ */
+static int tps65090_read(u32 reg, u8 *val)
+{
+ return cros_ec_i2c_xfer(config.dev, TPS65090_ADDR, reg, 1,
+ val, 1, true);
+}
+
+/**
+ * tps65090_write - write a byte to tps6090
+ *
+ * @param reg The register address to write to.
+ * @param val The value to write.
+ * @return 0 if ok; error if EC returns failure.
+ */
+static int tps65090_write(u32 reg, u8 val)
+{
+ return cros_ec_i2c_xfer(config.dev, TPS65090_ADDR, reg, 1,
+ &val, 1, false);
+}
+
+/**
+ * Checks for a valid FET number
+ *
+ * @param fet_id FET number to check
+ * @return 0 if ok, -EINVAL if FET value is out of range
+ */
+static int tps65090_check_fet(unsigned int fet_id)
+{
+ if (fet_id == 0 || fet_id > MAX_FET_NUM) {
+ debug("parameter fet_id is out of range, %u not in 1 ~ %u\n",
+ fet_id, MAX_FET_NUM);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+/**
+ * Set the power state for a FET
+ *
+ * @param fet_id Fet number to set (1..MAX_FET_NUM)
+ * @param set 1 to power on FET, 0 to power off
+ * @return -EIO if we got a comms error, -EAGAIN if the FET failed to
+ * change state. If all is ok, returns 0.
+ */
+static int tps65090_fet_set(int fet_id, bool set)
+{
+ int retry;
+ u8 reg, value;
+
+ value = FET_CTRL_ADENFET | FET_CTRL_WAIT;
+ if (set)
+ value |= FET_CTRL_ENFET;
+
+ if (tps65090_write(REG_FET1_CTRL + fet_id - 1, value))
+ return -EIO;
+
+ /* Try reading until we get a result */
+ for (retry = 0; retry < MAX_CTRL_READ_TRIES; retry++) {
+ if (tps65090_read(REG_FET1_CTRL + fet_id - 1, ®))
+ return -EIO;
+
+ /* Check that the fet went into the expected state */
+ if (!!(reg & FET_CTRL_PGFET) == set)
+ return 0;
+
+ /*
[U-Boot] [PATCH v4 09/15] exynos: Move common smdk5420 things to common file
A few things are common but are not in the common file. Fix this and
rename the file to fit with the other exynos*-common files.
Signed-off-by: Simon Glass
---
Changes in v4: None
Changes in v3: None
Changes in v2:
- Leave CONFIG_SERIAL3 in the individual board files
- Reduce the number of common elements to avoid needing #undefs later
include/configs/{exynos5420.h => exynos5420-common.h} | 8 +++-
include/configs/peach-pit.h | 4 +---
include/configs/smdk5420.h| 4 +---
3 files changed, 5 insertions(+), 11 deletions(-)
rename include/configs/{exynos5420.h => exynos5420-common.h} (88%)
diff --git a/include/configs/exynos5420.h b/include/configs/exynos5420-common.h
similarity index 88%
rename from include/configs/exynos5420.h
rename to include/configs/exynos5420-common.h
index d2a9556..27e7edc 100644
--- a/include/configs/exynos5420.h
+++ b/include/configs/exynos5420-common.h
@@ -9,7 +9,9 @@
#ifndef __CONFIG_EXYNOS5420_H
#define __CONFIG_EXYNOS5420_H
-#define CONFIG_EXYNOS5420 /* which is in a Exynos5 Family */
+#define CONFIG_EXYNOS5420
+
+#include
#define MACH_TYPE_SMDK5420 8002
#define CONFIG_MACH_TYPE MACH_TYPE_SMDK5420
@@ -31,10 +33,6 @@
#define CONFIG_MAX_I2C_NUM 11
-/* Enable FIT support and comparison */
-#define CONFIG_FIT
-#define CONFIG_FIT_BEST_MATCH
-
#define CONFIG_BOARD_REV_GPIO_COUNT2
#define CONFIG_BOOTCOMMAND "mmc read 20007000 451 2000; bootm 20007000"
diff --git a/include/configs/peach-pit.h b/include/configs/peach-pit.h
index 5e428cc..e9736fc 100644
--- a/include/configs/peach-pit.h
+++ b/include/configs/peach-pit.h
@@ -9,9 +9,7 @@
#ifndef __CONFIG_PEACH_PIT_H
#define __CONFIG_PEACH_PIT_H
-#include
-
-#include
+#include
/* select serial console configuration */
diff --git a/include/configs/smdk5420.h b/include/configs/smdk5420.h
index abda141..894ed11 100644
--- a/include/configs/smdk5420.h
+++ b/include/configs/smdk5420.h
@@ -9,9 +9,7 @@
#ifndef __CONFIG_SMDK5420_H
#define __CONFIG_SMDK5420_H
-#include
-
-#include
+#include
#define CONFIG_SMDK5420/* which is in a SMDK5420 */
--
2.1.0.rc2.206.gedb03e5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 05/15] dm: exynos: Split out the cros_ec drivers
With the driver model conversion we are going to be using driver model for SPI and not for I2C. This works OK so long as a board doesn't need both dm and non-dm versions of the cros_ec driver. Since pit uses SPI and snow uses I2C we need to split the configs so that only one driver is compiled for each platform. We can fix this later when driver model supports I2C. Signed-off-by: Simon Glass --- Changes in v4: None Changes in v3: None Changes in v2: - Add new patch to split out cros_ec drivers - Don't enable the cros_ec on smdk5420 include/configs/exynos5-dt.h| 2 -- include/configs/exynos5250-dt.h | 2 ++ include/configs/peach-pit.h | 1 + 3 files changed, 3 insertions(+), 2 deletions(-) diff --git a/include/configs/exynos5-dt.h b/include/configs/exynos5-dt.h index 68f3a41..0c400b1 100644 --- a/include/configs/exynos5-dt.h +++ b/include/configs/exynos5-dt.h @@ -69,8 +69,6 @@ /* Enable keyboard */ #define CONFIG_CROS_EC /* CROS_EC protocol */ -#define CONFIG_CROS_EC_SPI /* Support CROS_EC over SPI */ -#define CONFIG_CROS_EC_I2C /* Support CROS_EC over I2C */ #define CONFIG_CROS_EC_KEYB/* CROS_EC keyboard input */ #define CONFIG_CMD_CROS_EC #define CONFIG_KEYBOARD diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h index 5504515..05d33a7 100644 --- a/include/configs/exynos5250-dt.h +++ b/include/configs/exynos5250-dt.h @@ -22,6 +22,8 @@ #define CONFIG_SPL_MAX_FOOTPRINT (14 * 1024) +#define CONFIG_CROS_EC_I2C /* Support CROS_EC over I2C */ + /* USB */ #define CONFIG_CMD_USB #define CONFIG_USB_XHCI diff --git a/include/configs/peach-pit.h b/include/configs/peach-pit.h index 34734ad..8db889c 100644 --- a/include/configs/peach-pit.h +++ b/include/configs/peach-pit.h @@ -31,5 +31,6 @@ #endif #define CONFIG_POWER_TPS65090_EC +#define CONFIG_CROS_EC_SPI /* Support CROS_EC over SPI */ #endif /* __CONFIG_PEACH_PIT_H */ -- 2.1.0.rc2.206.gedb03e5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 10/15] exynos: config: Move cros_ec and tps65090 out of smdk boards
These boards do not in fact have a Chrome OS EC, nor a TPS565090 PMIC, so move the settings into a separate common file to be used by those that need it. Signed-off-by: Simon Glass --- Changes in v4: None Changes in v3: None Changes in v2: None include/configs/exynos5-common.h| 18 +++--- include/configs/exynos5-dt-common.h | 35 +++ include/configs/exynos5250-common.h | 3 --- include/configs/peach-pit.h | 1 + include/configs/snow.h | 4 5 files changed, 43 insertions(+), 18 deletions(-) create mode 100644 include/configs/exynos5-dt-common.h diff --git a/include/configs/exynos5-common.h b/include/configs/exynos5-common.h index 380a46f..3581a38 100644 --- a/include/configs/exynos5-common.h +++ b/include/configs/exynos5-common.h @@ -48,17 +48,10 @@ #define CONFIG_SYS_CONSOLE_IS_IN_ENV #define CONFIG_CONSOLE_MUX -/* Enable keyboard */ -#define CONFIG_CROS_EC /* CROS_EC protocol */ -#define CONFIG_CROS_EC_KEYB/* CROS_EC keyboard input */ -#define CONFIG_CMD_CROS_EC -#define CONFIG_KEYBOARD - -/* Console configuration */ #define EXYNOS_DEVICE_SETTINGS \ - "stdin=serial,cros-ec-keyb\0" \ - "stdout=serial,lcd\0" \ - "stderr=serial,lcd\0" + "stdin=serial\0" \ + "stdout=serial\0" \ + "stderr=serial\0" #define CONFIG_EXTRA_ENV_SETTINGS \ EXYNOS_DEVICE_SETTINGS @@ -185,11 +178,6 @@ #define CONFIG_ENV_SPI_MAX_HZ 5000 #endif -/* PMIC */ -#define CONFIG_POWER -#define CONFIG_POWER_I2C -#define CONFIG_POWER_TPS65090 - /* Ethernet Controllor Driver */ #ifdef CONFIG_CMD_NET #define CONFIG_SMC911X diff --git a/include/configs/exynos5-dt-common.h b/include/configs/exynos5-dt-common.h new file mode 100644 index 000..66547fa --- /dev/null +++ b/include/configs/exynos5-dt-common.h @@ -0,0 +1,35 @@ +/* + * Copyright (C) 2014 Google, Inc + * + * Configuration settings for generic Exynos 5 board + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#ifndef __CONFIG_EXYNOS5_DT_COMMON_H +#define __CONFIG_EXYNOS5_DT_COMMON_H + +#include "exynos5-common.h" + +/* PMIC */ +#define CONFIG_POWER +#define CONFIG_POWER_I2C +#define CONFIG_POWER_TPS65090 + +/* Enable keyboard */ +#define CONFIG_CROS_EC /* CROS_EC protocol */ +#define CONFIG_CROS_EC_KEYB/* CROS_EC keyboard input */ +#define CONFIG_CMD_CROS_EC +#define CONFIG_KEYBOARD + +/* Console configuration */ +#undef EXYNOS_DEVICE_SETTINGS +#define EXYNOS_DEVICE_SETTINGS \ + "stdin=serial,cros-ec-keyb\0" \ + "stdout=serial,lcd\0" \ + "stderr=serial,lcd\0" + +#define CONFIG_EXTRA_ENV_SETTINGS \ + EXYNOS_DEVICE_SETTINGS + +#endif diff --git a/include/configs/exynos5250-common.h b/include/configs/exynos5250-common.h index b4c1ccf..987eb15 100644 --- a/include/configs/exynos5250-common.h +++ b/include/configs/exynos5250-common.h @@ -22,8 +22,6 @@ #define CONFIG_SPL_MAX_FOOTPRINT (14 * 1024) -#define CONFIG_CROS_EC_I2C /* Support CROS_EC over I2C */ - /* USB */ #define CONFIG_CMD_USB #define CONFIG_USB_XHCI @@ -44,7 +42,6 @@ /* PMIC */ #define CONFIG_POWER_MAX77686 -#define CONFIG_POWER_TPS65090_I2C /* Sound */ #define CONFIG_CMD_SOUND diff --git a/include/configs/peach-pit.h b/include/configs/peach-pit.h index e9736fc..046813d 100644 --- a/include/configs/peach-pit.h +++ b/include/configs/peach-pit.h @@ -10,6 +10,7 @@ #define __CONFIG_PEACH_PIT_H #include +#include /* select serial console configuration */ diff --git a/include/configs/snow.h b/include/configs/snow.h index 0834cc9..dc09c66 100644 --- a/include/configs/snow.h +++ b/include/configs/snow.h @@ -10,6 +10,10 @@ #define __CONFIG_SNOW_H #include +#include +#define CONFIG_CROS_EC_I2C /* Support CROS_EC over I2C */ +#define CONFIG_POWER_TPS65090_I2C + #endif /* __CONFIG_SNOW_H */ -- 2.1.0.rc2.206.gedb03e5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 02/15] exynos5: Enable data cache
Things run faster when the data cache is enabled, so turn it on along with the 'dcache' command. Signed-off-by: Simon Glass Tested-by: Ajay Kumar --- Changes in v4: None Changes in v3: None Changes in v2: - Fix 'cashe' typo in commit subject include/configs/exynos5-dt.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/exynos5-dt.h b/include/configs/exynos5-dt.h index 1dc3002..68f3a41 100644 --- a/include/configs/exynos5-dt.h +++ b/include/configs/exynos5-dt.h @@ -33,8 +33,8 @@ #define CONFIG_TRACE_EARLY_ADDR0x5000 /* Keep L2 Cache Disabled */ -#define CONFIG_SYS_DCACHE_OFF #define CONFIG_SYS_CACHELINE_SIZE 64 +#define CONFIG_CMD_CACHE /* Enable ACE acceleration for SHA1 and SHA256 */ #define CONFIG_EXYNOS_ACE_SHA -- 2.1.0.rc2.206.gedb03e5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 07/15] exynos: Rename -dt config files to -common
We want exynos5250-dt.h to be a board which can support any exynos5250
device. This matches the naming used by Linux. As a first step, rename
the existing -dt files to -common to make it clear they are common files,
and not specific boards.
Signed-off-by: Simon Glass
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
include/configs/{exynos4-dt.h => exynos4-common.h} | 6 +++---
include/configs/{exynos5-dt.h => exynos5-common.h} | 6 +++---
include/configs/{exynos5250-dt.h => exynos5250-common.h} | 2 +-
include/configs/odroid.h | 2 +-
include/configs/origen.h | 2 +-
include/configs/peach-pit.h | 2 +-
include/configs/s5pc210_universal.h | 2 +-
include/configs/smdk5250.h | 2 +-
include/configs/smdk5420.h | 2 +-
include/configs/snow.h | 2 +-
include/configs/trats.h | 2 +-
include/configs/trats2.h | 2 +-
12 files changed, 16 insertions(+), 16 deletions(-)
rename include/configs/{exynos4-dt.h => exynos4-common.h} (97%)
rename include/configs/{exynos5-dt.h => exynos5-common.h} (98%)
rename include/configs/{exynos5250-dt.h => exynos5250-common.h} (97%)
diff --git a/include/configs/exynos4-dt.h b/include/configs/exynos4-common.h
similarity index 97%
rename from include/configs/exynos4-dt.h
rename to include/configs/exynos4-common.h
index 99472ac..38b8961 100644
--- a/include/configs/exynos4-dt.h
+++ b/include/configs/exynos4-common.h
@@ -6,8 +6,8 @@
* SPDX-License-Identifier:GPL-2.0+
*/
-#ifndef __CONFIG_H
-#define __CONFIG_H
+#ifndef __CONFIG_EXYNOS4_COMMON_H
+#define __CONFIG_EXYNOS4_COMMON_H
/* High Level Configuration Options */
#define CONFIG_SAMSUNG /* in a SAMSUNG core */
@@ -136,4 +136,4 @@
/* Enable devicetree support */
#define CONFIG_OF_LIBFDT
-#endif /* __CONFIG_H */
+#endif /* __CONFIG_EXYNOS4_COMMON_H */
diff --git a/include/configs/exynos5-dt.h b/include/configs/exynos5-common.h
similarity index 98%
rename from include/configs/exynos5-dt.h
rename to include/configs/exynos5-common.h
index 0c400b1..fede0e8 100644
--- a/include/configs/exynos5-dt.h
+++ b/include/configs/exynos5-common.h
@@ -6,8 +6,8 @@
* SPDX-License-Identifier:GPL-2.0+
*/
-#ifndef __CONFIG_H
-#define __CONFIG_H
+#ifndef __CONFIG_EXYNOS5_COMMON_H
+#define __CONFIG_EXYNOS5_COMMON_H
/* High Level Configuration Options */
#define CONFIG_SAMSUNG /* in a SAMSUNG core */
@@ -289,4 +289,4 @@
#define EXYNOS_USB_SECONDARY_BOOT 0xfeed0002
#define EXYNOS_IRAM_SECONDARY_BASE 0x02020018
-#endif /* __CONFIG_H */
+#endif /* __CONFIG_EXYNOS5_COMMON_H */
diff --git a/include/configs/exynos5250-dt.h
b/include/configs/exynos5250-common.h
similarity index 97%
rename from include/configs/exynos5250-dt.h
rename to include/configs/exynos5250-common.h
index 05d33a7..b4c1ccf 100644
--- a/include/configs/exynos5250-dt.h
+++ b/include/configs/exynos5250-common.h
@@ -10,7 +10,7 @@
#ifndef __CONFIG_5250_H
#define __CONFIG_5250_H
-#include
+#include
#define CONFIG_EXYNOS5250
#define CONFIG_SYS_SDRAM_BASE 0x4000
diff --git a/include/configs/odroid.h b/include/configs/odroid.h
index b616ac2..07a2ff6 100644
--- a/include/configs/odroid.h
+++ b/include/configs/odroid.h
@@ -12,7 +12,7 @@
#ifndef __CONFIG_ODROID_U3_H
#define __CONFIG_ODROID_U3_H
-#include
+#include
#define CONFIG_SYS_PROMPT "Odroid # " /* Monitor Command Prompt */
diff --git a/include/configs/origen.h b/include/configs/origen.h
index fb1536c..fc8a202 100644
--- a/include/configs/origen.h
+++ b/include/configs/origen.h
@@ -9,7 +9,7 @@
#ifndef __CONFIG_ORIGEN_H
#define __CONFIG_ORIGEN_H
-#include
+#include
#define CONFIG_SYS_PROMPT "ORIGEN # "
diff --git a/include/configs/peach-pit.h b/include/configs/peach-pit.h
index 8db889c..5e428cc 100644
--- a/include/configs/peach-pit.h
+++ b/include/configs/peach-pit.h
@@ -9,7 +9,7 @@
#ifndef __CONFIG_PEACH_PIT_H
#define __CONFIG_PEACH_PIT_H
-#include
+#include
#include
diff --git a/include/configs/s5pc210_universal.h
b/include/configs/s5pc210_universal.h
index 082d51c..e26522d 100644
--- a/include/configs/s5pc210_universal.h
+++ b/include/configs/s5pc210_universal.h
@@ -10,7 +10,7 @@
#ifndef __CONFIG_UNIVERSAL_H
#define __CONFIG_UNIVERSAL_H
-#include
+#include
#define CONFIG_SYS_PROMPT "Universal # " /* Monitor Command Prompt */
diff --git a/include/configs/smdk5250.h b/include/configs/smdk5250.h
index 6117094..56d41e6 100644
--- a/include/configs/smdk5250.h
+++ b/include/configs/smdk5250.h
@@ -9,7 +9,7 @@
#ifndef __CONFIG_SMDK_H
#define __CONFIG_SMDK_H
-#include
+#include
/* Enable FIT support and comparison */
diff --git a/include/configs/smdk5420.h b/include/configs/sm
Re: [U-Boot] [PATCH V2] usb: ci_udc: respect CONFIG_USB_GADGET_DUALSPEED
On Sun, Sep 28, 2014 at 05:36:56PM -0700, Eric Nelson wrote: > @@ -777,6 +778,11 @@ static int ci_pullup(struct usb_gadget *gadget, int > is_on) > /* select DEVICE mode */ > writel(USBMODE_DEVICE, &udc->usbmode); > > +#if !defined(CONFIG_USB_GADGET_DUALSPEED) && defined(CONFIG_MX6) why only MX6 ? -- balbi signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 15/15] exynos: Enable pre-relocation malloc()
Enable this feature to support driver model before relocation. Signed-off-by: Simon Glass --- Changes in v4: None Changes in v3: None Changes in v2: None include/configs/exynos-common.h | 5 +++-- include/configs/odroid.h| 2 -- include/configs/s5p_goni.h | 5 +++-- include/configs/smdkc100.h | 4 4 files changed, 10 insertions(+), 6 deletions(-) diff --git a/include/configs/exynos-common.h b/include/configs/exynos-common.h index 54b61d7..371f32d 100644 --- a/include/configs/exynos-common.h +++ b/include/configs/exynos-common.h @@ -38,8 +38,9 @@ #define CONFIG_CMDLINE_EDITING #define CONFIG_ENV_OVERWRITE -/* Size of malloc() pool */ -#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (80 * SZ_1M)) +/* Size of malloc() pool before and after relocation */ +#define CONFIG_SYS_MALLOC_F_LEN(1 << 10) +#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (80 << 20)) /* select serial console configuration */ #define CONFIG_BAUDRATE115200 diff --git a/include/configs/odroid.h b/include/configs/odroid.h index 07a2ff6..b928af8 100644 --- a/include/configs/odroid.h +++ b/include/configs/odroid.h @@ -37,8 +37,6 @@ #define CONFIG_SYS_TEXT_BASE 0x43e0 #include -/* Size of malloc() pool */ -#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (80 * SZ_1M)) /* select serial console configuration */ #define CONFIG_SERIAL1 diff --git a/include/configs/s5p_goni.h b/include/configs/s5p_goni.h index feb4d76..0c6e9c7 100644 --- a/include/configs/s5p_goni.h +++ b/include/configs/s5p_goni.h @@ -39,8 +39,9 @@ #define CONFIG_INITRD_TAG #define CONFIG_CMDLINE_EDITING -/* Size of malloc() pool.*/ -#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + 80 * SZ_1M) +/* Size of malloc() pool before and after relocation */ +#define CONFIG_SYS_MALLOC_F_LEN(1 << 10) +#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (80 << 20)) /* * select serial console configuration diff --git a/include/configs/smdkc100.h b/include/configs/smdkc100.h index 566028d..22835ff 100644 --- a/include/configs/smdkc100.h +++ b/include/configs/smdkc100.h @@ -47,6 +47,10 @@ * 1MB = 0x10, 0x10 = 1024 * 1024 */ #define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (1 << 20)) + +/* Small malloc pool before relocation */ +#define CONFIG_SYS_MALLOC_F_LEN(1 << 10) + /* * select serial console configuration */ -- 2.1.0.rc2.206.gedb03e5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 14/15] samsung: Enable device tree for smdkc100
Change this board to add a device tree.
Signed-off-by: Simon Glass
---
Changes in v4:
- Rebase on top of master (CONFIG_OF settings moved to Kconfig)
Changes in v3: None
Changes in v2:
- Avoid using a common file, and just add a device tree
- Fix device tree base addresses
arch/arm/Kconfig | 4
arch/arm/cpu/armv7/s5pc1xx/Kconfig | 5 +
arch/arm/dts/Makefile | 1 +
arch/arm/dts/s5pc1xx-smdkc100.dts | 29 +
configs/smdkc100_defconfig | 2 ++
include/configs/smdkc100.h | 2 ++
6 files changed, 39 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/dts/s5pc1xx-smdkc100.dts
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index d915eef..15fd196 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -432,9 +432,6 @@ config RMOBILE
config TARGET_CM_FX6
bool "Support cm_fx6"
-config TARGET_SMDKC100
- bool "Support smdkc100"
-
config TARGET_SOCFPGA_CYCLONE5
bool "Support socfpga_cyclone5"
@@ -655,7 +652,6 @@ source "board/ronetix/pm9261/Kconfig"
source "board/ronetix/pm9263/Kconfig"
source "board/ronetix/pm9g45/Kconfig"
source "board/samsung/smdk2410/Kconfig"
-source "board/samsung/smdkc100/Kconfig"
source "board/sandisk/sansa_fuze_plus/Kconfig"
source "board/scb9328/Kconfig"
source "board/schulercontrol/sc_sps_1/Kconfig"
diff --git a/arch/arm/cpu/armv7/s5pc1xx/Kconfig
b/arch/arm/cpu/armv7/s5pc1xx/Kconfig
index 1a8941d..2fbbc18 100644
--- a/arch/arm/cpu/armv7/s5pc1xx/Kconfig
+++ b/arch/arm/cpu/armv7/s5pc1xx/Kconfig
@@ -7,6 +7,10 @@ config TARGET_S5P_GONI
bool "S5P Goni board"
select OF_CONTROL if !SPL_BUILD
+config TARGET_SMDKC100
+ bool "Support smdkc100 board"
+ select OF_CONTROL if !SPL_BUILD
+
endchoice
config SYS_CPU
@@ -16,5 +20,6 @@ config SYS_SOC
default "s5pc1xx"
source "board/samsung/goni/Kconfig"
+source "board/samsung/smdkc100/Kconfig"
endif
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 076e0f7..c37580e 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1,3 +1,4 @@
+dtb-$(CONFIG_S5PC100) += s5pc1xx-smdkc100.dtb
dtb-$(CONFIG_S5PC110) += s5pc1xx-goni.dtb
dtb-$(CONFIG_EXYNOS4) += exynos4210-origen.dtb \
exynos4210-smdkv310.dtb \
diff --git a/arch/arm/dts/s5pc1xx-smdkc100.dts
b/arch/arm/dts/s5pc1xx-smdkc100.dts
new file mode 100644
index 000..42754ce
--- /dev/null
+++ b/arch/arm/dts/s5pc1xx-smdkc100.dts
@@ -0,0 +1,29 @@
+/*
+ * Samsung's Exynos4210-based SMDKV310 board device tree source
+ *
+ * Copyright (c) 2014 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+
+#include "skeleton.dtsi"
+
+/ {
+ model = "Samsung SMDKC100 based on S5PC100";
+ compatible = "samsung,smdkc100", "samsung,s5pc100";
+
+ aliases {
+ serial0 = "/serial@ec00";
+ console = "/serial@ec00";
+ };
+
+ serial@ec00 {
+ compatible = "samsung,exynos4210-uart";
+ reg = <0xec00 0x100>;
+ interrupts = <0 51 0>;
+ id = <0>;
+ };
+
+};
diff --git a/configs/smdkc100_defconfig b/configs/smdkc100_defconfig
index 7455235..041030f 100644
--- a/configs/smdkc100_defconfig
+++ b/configs/smdkc100_defconfig
@@ -1,2 +1,4 @@
CONFIG_ARM=y
CONFIG_TARGET_SMDKC100=y
+CONFIG_ARCH_S5PC1XX=y
+CONFIG_DEFAULT_DEVICE_TREE="s5pc1xx-smdkc100"
diff --git a/include/configs/smdkc100.h b/include/configs/smdkc100.h
index c9a2e15..566028d 100644
--- a/include/configs/smdkc100.h
+++ b/include/configs/smdkc100.h
@@ -217,4 +217,6 @@
#define CONFIG_ENV_SROM_BANK 3 /* Select SROM Bank-3 for Ethernet*/
#endif /* CONFIG_CMD_NET */
+#define CONFIG_OF_LIBFDT
+
#endif /* __CONFIG_H */
--
2.1.0.rc2.206.gedb03e5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 13/15] samsung: Enable device tree for s5p_goni
Change this board to add a device tree.
This also adds a pinmux header file although it is not used as yet.
Signed-off-by: Simon Glass
---
Changes in v4:
- Rebase on top of master (CONFIG_OF settings moved to Kconfig)
Changes in v3:
- Adjust device tree file based on Robert Baldyga's example
Changes in v2:
- Avoid using a common file, and just add a device tree
- Fix device tree base addresses
arch/arm/Kconfig | 9 +++--
arch/arm/cpu/armv7/s5pc1xx/Kconfig | 20 ++
arch/arm/dts/Makefile | 1 +
arch/arm/dts/s5pc1xx-goni.dts | 28 ++
arch/arm/include/asm/arch-s5pc1xx/periph.h | 61 ++
arch/arm/include/asm/arch-s5pc1xx/pinmux.h | 50
configs/s5p_goni_defconfig | 2 +
drivers/mmc/s5p_sdhci.c| 2 -
include/configs/s5p_goni.h | 4 +-
9 files changed, 170 insertions(+), 7 deletions(-)
create mode 100644 arch/arm/cpu/armv7/s5pc1xx/Kconfig
create mode 100644 arch/arm/dts/s5pc1xx-goni.dts
create mode 100644 arch/arm/include/asm/arch-s5pc1xx/periph.h
create mode 100644 arch/arm/include/asm/arch-s5pc1xx/pinmux.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 3efede2..d915eef 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -336,6 +336,9 @@ config TARGET_BCM958622HR
config ARCH_EXYNOS
bool "Samsung EXYNOS"
+config ARCH_S5PC1XX
+ bool "Samsung S5PC1XX"
+
config ARCH_HIGHBANK
bool "Calxeda Highbank"
@@ -429,9 +432,6 @@ config RMOBILE
config TARGET_CM_FX6
bool "Support cm_fx6"
-config TARGET_S5P_GONI
- bool "Support s5p_goni"
-
config TARGET_SMDKC100
bool "Support smdkc100"
@@ -547,6 +547,8 @@ source "arch/arm/cpu/arm926ejs/orion5x/Kconfig"
source "arch/arm/cpu/armv7/rmobile/Kconfig"
+source "arch/arm/cpu/armv7/s5pc1xx/Kconfig"
+
source "arch/arm/cpu/armv7/tegra-common/Kconfig"
source "arch/arm/cpu/arm926ejs/versatile/Kconfig"
@@ -652,7 +654,6 @@ source "board/raspberrypi/rpi_b/Kconfig"
source "board/ronetix/pm9261/Kconfig"
source "board/ronetix/pm9263/Kconfig"
source "board/ronetix/pm9g45/Kconfig"
-source "board/samsung/goni/Kconfig"
source "board/samsung/smdk2410/Kconfig"
source "board/samsung/smdkc100/Kconfig"
source "board/sandisk/sansa_fuze_plus/Kconfig"
diff --git a/arch/arm/cpu/armv7/s5pc1xx/Kconfig
b/arch/arm/cpu/armv7/s5pc1xx/Kconfig
new file mode 100644
index 000..1a8941d
--- /dev/null
+++ b/arch/arm/cpu/armv7/s5pc1xx/Kconfig
@@ -0,0 +1,20 @@
+if ARCH_S5PC1XX
+
+choice
+ prompt "S5PC1XX board select"
+
+config TARGET_S5P_GONI
+ bool "S5P Goni board"
+ select OF_CONTROL if !SPL_BUILD
+
+endchoice
+
+config SYS_CPU
+ default "armv7"
+
+config SYS_SOC
+ default "s5pc1xx"
+
+source "board/samsung/goni/Kconfig"
+
+endif
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 43a70e4..076e0f7 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1,3 +1,4 @@
+dtb-$(CONFIG_S5PC110) += s5pc1xx-goni.dtb
dtb-$(CONFIG_EXYNOS4) += exynos4210-origen.dtb \
exynos4210-smdkv310.dtb \
exynos4210-universal_c210.dtb \
diff --git a/arch/arm/dts/s5pc1xx-goni.dts b/arch/arm/dts/s5pc1xx-goni.dts
new file mode 100644
index 000..2e671bb
--- /dev/null
+++ b/arch/arm/dts/s5pc1xx-goni.dts
@@ -0,0 +1,28 @@
+/*
+ * Samsung's S5PC110-based Goni board device tree source
+ *
+ * Copyright (c) 2014 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+
+#include "skeleton.dtsi"
+
+/ {
+ model = "Samsung Goni based on S5PC110";
+ compatible = "samsung,goni", "samsung,s5pc110";
+
+ aliases {
+ serial2 = "/serial@e2900800";
+ console = "/serial@e2900800";
+ };
+
+ serial@e2900800 {
+ compatible = "samsung,exynos4210-uart";
+ reg = <0xe2900800 0x400>;
+ id = <2>;
+ };
+
+};
diff --git a/arch/arm/include/asm/arch-s5pc1xx/periph.h
b/arch/arm/include/asm/arch-s5pc1xx/periph.h
new file mode 100644
index 000..5c1c3d4
--- /dev/null
+++ b/arch/arm/include/asm/arch-s5pc1xx/periph.h
@@ -0,0 +1,61 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics
+ * Rajeshwari Shinde
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __ASM_ARM_ARCH_PERIPH_H
+#define __ASM_ARM_ARCH_PERIPH_H
+
+/*
+ * Peripherals required for pinmux configuration. List will
+ * grow with support for more devices getting added.
+ * Numbering based on interrupt table.
+ *
+ */
+enum periph_id {
+ PERIPH_ID_UART0 = 51,
+ PERIPH_ID_UART1,
+ PERIPH_ID_UART2,
+ PERIPH_ID_UART3,
+ PERIPH_ID_I2C0 = 56,
+ PERIPH_ID_I2C1,
+ PERIPH_ID_I2C2,
+ PERIPH_ID_I2C3,
+ PERIPH_ID_I2C4,
+ PERIPH_ID_I2C5,
+ PERIPH_ID_I2C6,
+ PERIPH_ID_I2C7,
+ PERIPH_ID_SPI0 = 68,
+ PERIPH_ID_SPI1,
+ PERIPH_ID_SPI2,
+ PERIPH_ID_SDMM
Re: [U-Boot] [PATCH V2] usb: ci_udc: respect CONFIG_USB_GADGET_DUALSPEED
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/28/2014 06:21 PM, Felipe Balbi wrote: > On Sun, Sep 28, 2014 at 05:36:56PM -0700, Eric Nelson wrote: >> @@ -777,6 +778,11 @@ static int ci_pullup(struct usb_gadget >> *gadget, int is_on) /* select DEVICE mode */ >> writel(USBMODE_DEVICE, &udc->usbmode); >> >> +#if !defined(CONFIG_USB_GADGET_DUALSPEED) && >> defined(CONFIG_MX6) > > why only MX6 ? > This shouldn't be the case. I'll fix in V3. I also just noticed an extraneous variable declaration. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUKLZJAAoJEFUqXmm9AiVrK9gH/0XPpea8XDasyCtElV3WolzP C4RaqGrL6iRL2haiuY4zhIHv3KMxg+1L2P6rGrbYFn7+15mNhSMwqkSleRcDL8bw 47j5snivpd0BEnznC+dIzc/vghJ+gpkZdwmnRsfAvfGN+PWV1jNJUSR+jFkzTS6F 19rp2TIoIR9XgFx9chHmluI1iWp39yXTFhgqXLoLLMYMR0qXKTp8TV7asXvWLBsw +Rrlqf58j3rEmhBA8zNDIbDJe/aQDKbxHcZrK386n2izBK3fZqf4Ew2Pln8vSToU jHLnEwUp0PoeolUg1EK3oAlitNnwE7GLxxEoxsA/v7KaLzyUoR/c4wpG5/pIu2A= =Hdj5 -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] usb: ci_udc: respect CONFIG_USB_GADGET_DUALSPEED
Force full-speed (12 Mbit/s) operation if CONFIG_USB_GADGET_DUALSPEED is not defined. The controller is capable of high-speed (480 Mbit/s) operation, but some designs may require the use of lower-speed operation. Signed-off-by: Eric Nelson --- V2 uses PFSC constant, setbits_le32, and expands commit message V3 removes restriction on i.MX6 and extraneous declaration drivers/usb/gadget/ci_udc.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c index 2572b34..b0ef35e 100644 --- a/drivers/usb/gadget/ci_udc.c +++ b/drivers/usb/gadget/ci_udc.c @@ -777,6 +777,11 @@ static int ci_pullup(struct usb_gadget *gadget, int is_on) /* select DEVICE mode */ writel(USBMODE_DEVICE, &udc->usbmode); +#if !defined(CONFIG_USB_GADGET_DUALSPEED) + /* Port force Full-Speed Connect */ + setbits_le32(&udc->portsc, PFSC); +#endif + writel(0x, &udc->epflush); /* Turn on the USB connection by enabling the pullup resistor */ -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] dm: do not check dm_root before searching in uclass_root
Hi Simon,
On Sun, 28 Sep 2014 10:18:59 -0600
Simon Glass wrote:
> Hi Masahiro,
>
> On 28 September 2014 09:54, Masahiro YAMADA wrote:
> > Simon,
> >
> >
> > 2014-09-29 0:17 GMT+09:00 Simon Glass :
> >> Hi Masahiro,
> >>
> >> On 28 September 2014 07:52, Masahiro Yamada
> >> wrote:
> >>> The function uclass_find() looks for a uclass in the linked
> >>> list of gd->uclass_root; gd->dm_root has nothing to do with
> >>> gd->uclass_root. Remove this confusing code.
> >>>
> >>> Signed-off-by: Masahiro Yamada
> >>> ---
> >>>
> >>> drivers/core/uclass.c | 2 --
> >>> 1 file changed, 2 deletions(-)
> >>>
> >>> diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
> >>> index 901b06e..74df613 100644
> >>> --- a/drivers/core/uclass.c
> >>> +++ b/drivers/core/uclass.c
> >>> @@ -23,8 +23,6 @@ struct uclass *uclass_find(enum uclass_id key)
> >>> {
> >>> struct uclass *uc;
> >>>
> >>> - if (!gd->dm_root)
> >>> - return NULL;
> >>> /*
> >>> * TODO(s...@chromium.org): Optimise this, perhaps moving the
> >>> found
> >>> * node to the start of the list, or creating a linear array
> >>> mapping
> >>
> >> This came in in commit:
> >>
> >> c910e2e dm: Avoid accessing uclasses before they are ready
> >>
> >> Please see that (and the test that was added) for an explanation.
> >
> >
> > Commit c910e2e says:
> >
> > dm: Avoid accessing uclasses before they are ready
> >
> > Don't allow access to uclasses before they have been initialised.
> >
> >
> >
> > I still don't get it.
> > The log did not help me because it is not saying 'why'.
> >
> > What kind problem would happen if this check was dropped?
> >
> > gd->dm_root is set when the root device is bound.
> > At the first call of uclass_find(), it is true gd->dm_root is NULL,
> > but gd->uclass_root is also empty.
>
> But 'empty' means the list is empty. For it to be empty it must be
> initialised. But if you call the function before this list init
> happens, then it will just crash.
>
> We can use dm_root as an indicator that init has happened.
>
> >
> > This function, anyway, returns NULL.
> > The behavior is still the same, I think.
>
> You can try this by removing that code and seeing what the test does
> (dm_test_uclass_before_ready()).
>
So, you are checking gd->dm_root
to make sure gd->uclass_root has been initialized.
Understood what you are trying to do, but it is unfortunate.
OK, let's see what will happen if uclass_get() is called before dm_init().
It is true uclass_find() will return NULL safely,
but uclass_add() will crash, I think.
It looks like uclass_add() is trying to add a created uclass
to the uninitialized gd->uclass_root.
here,
list_add(&uc->sibling_node, &DM_UCLASS_ROOT_NON_CONST);
I think it is as dangeous as searching something in an uninitialized list.
Unfortunately, we cannot use LIST_HEAD(uclass_root)
because it is in the global data.
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] Add snoop disable for slave port 0, port 1 and port 2
From: Jason Jin
Disable the snoop for slave interface 0, 1 and 2
to avoid the interleaving on the CCI400 BUS.
Signed-off-by: Jason Jin
Signed-off-by: Minghuan Lian
---
arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 1 +
board/freescale/ls1021aqds/ls1021aqds.c | 7 +++
board/freescale/ls1021atwr/ls1021atwr.c | 10 ++
3 files changed, 18 insertions(+)
diff --git a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
index 7995fe2..a1f4fdb 100644
--- a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
+++ b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
@@ -448,6 +448,7 @@ struct ccsr_ddr {
#define CCI400_CTRLORD_TERM_BARRIER0x0008
#define CCI400_CTRLORD_EN_BARRIER 0
+#define CCI400_SHAORD_NON_SHAREABLE0x0002
/* CCI-400 registers */
struct ccsr_cci400 {
diff --git a/board/freescale/ls1021aqds/ls1021aqds.c
b/board/freescale/ls1021aqds/ls1021aqds.c
index 12e83f7..e32dbeb 100644
--- a/board/freescale/ls1021aqds/ls1021aqds.c
+++ b/board/freescale/ls1021aqds/ls1021aqds.c
@@ -220,6 +220,13 @@ int board_init(void)
/* Set CCI-400 control override register to
* enable barrier transaction */
out_le32(&cci->ctrl_ord, CCI400_CTRLORD_EN_BARRIER);
+ /*
+* Set CCI-400 Slave interface S0, S1, S2 Shareable Override Register
+* All transactions are treated as non-shareable
+*/
+ out_le32(&cci->slave[0].sha_ord, CCI400_SHAORD_NON_SHAREABLE);
+ out_le32(&cci->slave[1].sha_ord, CCI400_SHAORD_NON_SHAREABLE);
+ out_le32(&cci->slave[2].sha_ord, CCI400_SHAORD_NON_SHAREABLE);
select_i2c_ch_pca9547(I2C_MUX_CH_DEFAULT);
diff --git a/board/freescale/ls1021atwr/ls1021atwr.c
b/board/freescale/ls1021atwr/ls1021atwr.c
index b522ff2..811c911 100644
--- a/board/freescale/ls1021atwr/ls1021atwr.c
+++ b/board/freescale/ls1021atwr/ls1021atwr.c
@@ -272,6 +272,16 @@ int board_early_init_f(void)
int board_init(void)
{
+ struct ccsr_cci400 *cci = (struct ccsr_cci400 *)CONFIG_SYS_CCI400_ADDR;
+
+ /*
+* Set CCI-400 Slave interface S0, S1, S2 Shareable Override Register
+* All transactions are treated as non-shareable
+*/
+ out_le32(&cci->slave[0].sha_ord, CCI400_SHAORD_NON_SHAREABLE);
+ out_le32(&cci->slave[1].sha_ord, CCI400_SHAORD_NON_SHAREABLE);
+ out_le32(&cci->slave[2].sha_ord, CCI400_SHAORD_NON_SHAREABLE);
+
#ifndef CONFIG_SYS_FSL_NO_SERDES
fsl_serdes_init();
config_serdes_mux();
--
2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] arm: ls102xa: Remove bit reversing for SCFG registers
SCFG_SCFGREVCR is SCFG bit reverse register. This register must be written with 0x before writing to any other SCFG register. Then other SCFG register could be written in big-endian mode. Address: 157_h base + 200h offset = 157_0200h Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15|16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 W/R SCFGREV Reset 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0-31 SCFGREV SCFG Bit Reverse Control Filed 32'h _ - No bit reverse is applied 32'h _ - Bit reverse is applied; so 31:0 will be stored/read as 0:31 This patch removes the bit reversing for SCFG registers in u-boot. It will be implemented through PBI commands in RCW .pbi write 0x570200, 0x .end So other SCFG register could be written in big-endian mode in u-boot or kernel directly. Signed-off-by: Alison Wang --- board/freescale/ls1021aqds/ls1021aqds.c | 2 -- board/freescale/ls1021atwr/ls1021atwr.c | 5 - 2 files changed, 7 deletions(-) diff --git a/board/freescale/ls1021aqds/ls1021aqds.c b/board/freescale/ls1021aqds/ls1021aqds.c index e32dbeb..56028f8 100644 --- a/board/freescale/ls1021aqds/ls1021aqds.c +++ b/board/freescale/ls1021aqds/ls1021aqds.c @@ -136,9 +136,7 @@ int board_early_init_f(void) struct ccsr_cci400 *cci = (struct ccsr_cci400 *)CONFIG_SYS_CCI400_ADDR; #ifdef CONFIG_TSEC_ENET - out_be32(&scfg->scfgrevcr, SCFG_SCFGREVCR_REV); out_be32(&scfg->etsecdmamcr, SCFG_ETSECDMAMCR_LE_BD_FR); - out_be32(&scfg->scfgrevcr, SCFG_SCFGREVCR_NOREV); #endif #ifdef CONFIG_FSL_IFC diff --git a/board/freescale/ls1021atwr/ls1021atwr.c b/board/freescale/ls1021atwr/ls1021atwr.c index 811c911..ff7130e 100644 --- a/board/freescale/ls1021atwr/ls1021atwr.c +++ b/board/freescale/ls1021atwr/ls1021atwr.c @@ -250,11 +250,8 @@ int board_early_init_f(void) struct ccsr_scfg *scfg = (struct ccsr_scfg *)CONFIG_SYS_FSL_SCFG_ADDR; #ifdef CONFIG_TSEC_ENET - out_be32(&scfg->scfgrevcr, SCFG_SCFGREVCR_REV); out_be32(&scfg->etsecdmamcr, SCFG_ETSECDMAMCR_LE_BD_FR); out_be32(&scfg->etsecmcr, SCFG_ETSECCMCR_GE2_CLK125); - udelay(10); - out_be32(&scfg->scfgrevcr, SCFG_SCFGREVCR_NOREV); #endif #ifdef CONFIG_FSL_IFC @@ -262,9 +259,7 @@ int board_early_init_f(void) #endif #ifdef CONFIG_FSL_DCU_FB - out_be32(&scfg->scfgrevcr, SCFG_SCFGREVCR_REV); out_be32(&scfg->pixclkcr, SCFG_PIXCLKCR_PXCKEN); - out_be32(&scfg->scfgrevcr, SCFG_SCFGREVCR_NOREV); #endif return 0; -- 2.1.0.27.g96db324 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] ls102xa: ifc: nor: fix the write issue when bytes unaligned.
From: Yuan Yao
Add define CONFIG_SYS_WRITE_SWAPPED_DATA.
For LS1021AQDS and LS1021QTWR nor flash read and write should swap the
bytes when handle unaligned tail bytes.
Signed-off-by: Yuan Yao
---
include/configs/ls1021aqds.h | 1 +
include/configs/ls1021atwr.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/include/configs/ls1021aqds.h b/include/configs/ls1021aqds.h
index bb47813..7e78e78 100644
--- a/include/configs/ls1021aqds.h
+++ b/include/configs/ls1021aqds.h
@@ -109,6 +109,7 @@ unsigned long get_board_ddr_clk(void);
#define CONFIG_SYS_FLASH_QUIET_TEST
#define CONFIG_FLASH_SHOW_PROGRESS 45
#define CONFIG_CFI_FLASH_USE_WEAK_ACCESSORS
+#define CONFIG_SYS_WRITE_SWAPPED_DATA
#define CONFIG_SYS_MAX_FLASH_BANKS 2 /* number of banks */
#define CONFIG_SYS_MAX_FLASH_SECT 1024/* sectors per device */
diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h
index 45b2272..2427f2e 100644
--- a/include/configs/ls1021atwr.h
+++ b/include/configs/ls1021atwr.h
@@ -93,6 +93,7 @@
#define CONFIG_SYS_FLASH_BANKS_LIST{ CONFIG_SYS_FLASH_BASE_PHYS }
#define CONFIG_CFI_FLASH_USE_WEAK_ACCESSORS
+#define CONFIG_SYS_WRITE_SWAPPED_DATA
/* CPLD */
--
2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] arm: ls102xa: Add SystemID EEPROM support for LS1021ATWR board
SystemID information could be read through I2C1 from EEPROM
on LS1021ATWR board.
As LS1 is a little-endian processor, getting the version ID by
be32_to_cpu() is wrong. Fix it by using e.version directly.
This change will be compatible for both ARM and PowerPC.
Signed-off-by: Alison Wang
---
board/freescale/common/sys_eeprom.c | 4 ++--
include/configs/ls1021atwr.h| 9 +
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/board/freescale/common/sys_eeprom.c
b/board/freescale/common/sys_eeprom.c
index 6144c53..3426b8a 100644
--- a/board/freescale/common/sys_eeprom.c
+++ b/board/freescale/common/sys_eeprom.c
@@ -90,7 +90,7 @@ static void show_eeprom(void)
/* EEPROM tag ID, either CCID or NXID */
#ifdef CONFIG_SYS_I2C_EEPROM_NXID
printf("ID: %c%c%c%c v%u\n", e.id[0], e.id[1], e.id[2], e.id[3],
- be32_to_cpu(e.version));
+ e.version);
#else
printf("ID: %c%c%c%c\n", e.id[0], e.id[1], e.id[2], e.id[3]);
#endif
@@ -485,7 +485,7 @@ int mac_read_from_eeprom(void)
#ifdef CONFIG_SYS_I2C_EEPROM_NXID
printf("%c%c%c%c v%u\n", e.id[0], e.id[1], e.id[2], e.id[3],
- be32_to_cpu(e.version));
+ e.version);
#else
printf("%c%c%c%c\n", e.id[0], e.id[1], e.id[2], e.id[3]);
#endif
diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h
index 2427f2e..b02fda2 100644
--- a/include/configs/ls1021atwr.h
+++ b/include/configs/ls1021atwr.h
@@ -155,6 +155,15 @@
#define CONFIG_SYS_I2C
#define CONFIG_SYS_I2C_MXC
+/* EEPROM */
+#define CONFIG_ID_EEPROM
+#define CONFIG_SYS_I2C_EEPROM_NXID
+#define CONFIG_SYS_EEPROM_BUS_NUM 1
+#define CONFIG_SYS_I2C_EEPROM_ADDR 0x53
+#define CONFIG_SYS_I2C_EEPROM_ADDR_LEN 1
+#define CONFIG_SYS_EEPROM_PAGE_WRITE_BITS 3
+#define CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS 5
+
/*
* MMC
*/
--
2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] ls102xa: ifc: nor: fix the write issue when bytes unaligned.
On 9/29/2014 8:23 AM, Alison Wang wrote: From: Yuan Yao Add define CONFIG_SYS_WRITE_SWAPPED_DATA. For LS1021AQDS and LS1021QTWR nor flash read and write should swap the bytes when handle unaligned tail bytes. Signed-off-by: Yuan Yao Subject and description of patch has mismatch. Subject say it is for "write" but description say for both read & write. Regards, Prabhakar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] arm: ls102xa: Remove bit reversing for SCFG registers
On 9/29/2014 8:23 AM, Alison Wang wrote: SCFG_SCFGREVCR is SCFG bit reverse register. This register must be written with 0x before writing to any other SCFG register. Then other SCFG register could be written in big-endian mode. Address: 157_h base + 200h offset = 157_0200h Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15|16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 W/R SCFGREV Reset 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0-31 SCFGREV SCFG Bit Reverse Control Filed 32'h _ - No bit reverse is applied 32'h _ - Bit reverse is applied; so 31:0 will be stored/read as 0:31 This patch removes the bit reversing for SCFG registers in u-boot. It will be implemented through PBI commands in RCW .pbi write 0x570200, 0x .end So other SCFG register could be written in big-endian mode in u-boot or kernel directly. If I understand correctly, below patch removes both setting 0x and 0x. does re-setting of SCFG_SCFGREVCR not a requirement? Just a suggestion: if SCFG_SCFGREVCR_REV and SCFG_SCFGREVCR_NOREV not required, remove the defines also. Signed-off-by: Alison Wang --- board/freescale/ls1021aqds/ls1021aqds.c | 2 -- board/freescale/ls1021atwr/ls1021atwr.c | 5 - 2 files changed, 7 deletions(-) diff --git a/board/freescale/ls1021aqds/ls1021aqds.c b/board/freescale/ls1021aqds/ls1021aqds.c index e32dbeb..56028f8 100644 --- a/board/freescale/ls1021aqds/ls1021aqds.c +++ b/board/freescale/ls1021aqds/ls1021aqds.c @@ -136,9 +136,7 @@ int board_early_init_f(void) struct ccsr_cci400 *cci = (struct ccsr_cci400 *)CONFIG_SYS_CCI400_ADDR; #ifdef CONFIG_TSEC_ENET - out_be32(&scfg->scfgrevcr, SCFG_SCFGREVCR_REV); out_be32(&scfg->etsecdmamcr, SCFG_ETSECDMAMCR_LE_BD_FR); - out_be32(&scfg->scfgrevcr, SCFG_SCFGREVCR_NOREV); #endif #ifdef CONFIG_FSL_IFC diff --git a/board/freescale/ls1021atwr/ls1021atwr.c b/board/freescale/ls1021atwr/ls1021atwr.c index 811c911..ff7130e 100644 --- a/board/freescale/ls1021atwr/ls1021atwr.c +++ b/board/freescale/ls1021atwr/ls1021atwr.c @@ -250,11 +250,8 @@ int board_early_init_f(void) struct ccsr_scfg *scfg = (struct ccsr_scfg *)CONFIG_SYS_FSL_SCFG_ADDR; #ifdef CONFIG_TSEC_ENET - out_be32(&scfg->scfgrevcr, SCFG_SCFGREVCR_REV); out_be32(&scfg->etsecdmamcr, SCFG_ETSECDMAMCR_LE_BD_FR); out_be32(&scfg->etsecmcr, SCFG_ETSECCMCR_GE2_CLK125); - udelay(10); - out_be32(&scfg->scfgrevcr, SCFG_SCFGREVCR_NOREV); #endif #ifdef CONFIG_FSL_IFC @@ -262,9 +259,7 @@ int board_early_init_f(void) #endif #ifdef CONFIG_FSL_DCU_FB - out_be32(&scfg->scfgrevcr, SCFG_SCFGREVCR_REV); out_be32(&scfg->pixclkcr, SCFG_PIXCLKCR_PXCKEN); - out_be32(&scfg->scfgrevcr, SCFG_SCFGREVCR_NOREV); #endif return 0; ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] exynos: update maintainer of Snow and SMDK5420 board
Hi Akshay, On Fri, 26 Sep 2014 03:29:51 + (GMT) Akshay Saraswat wrote: > > Hi Mr. Masahiro Yamada, > > Rajeshwari has left the organization and probably forgot transferring the > maintainership. > Yes, please transfer both the boards (Snow and SMDK5420) to my name. > > Regards, > Akshay Saraswat OK, then I will send v2. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] exynos: update maintainer of Snow and SMDK5420 board
On Mon, 29 Sep 2014 13:01:22 +0900 Masahiro Yamada wrote: > Hi Akshay, > > On Fri, 26 Sep 2014 03:29:51 + (GMT) > Akshay Saraswat wrote: > > > > > Hi Mr. Masahiro Yamada, > > > > Rajeshwari has left the organization and probably forgot transferring the > > maintainership. > > Yes, please transfer both the boards (Snow and SMDK5420) to my name. > > > > Regards, > > Akshay Saraswat > > OK, then I will send v2. > Please disregard this mail. (Something odd happened to my email client) V2 is alread on our patchwork. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] arm: ls102xa: Remove bit reversing for SCFG registers
Hi, Prabhakar, > On 9/29/2014 8:23 AM, Alison Wang wrote: > > SCFG_SCFGREVCR is SCFG bit reverse register. This register must be > > written with 0x before writing to any other SCFG register. > > Then other SCFG register could be written in big-endian mode. > > > > Address: 157_h base + 200h offset = 157_0200h > > Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15|16 17 18 19 20 21 22 23 > 24 25 26 27 28 29 30 31 > > W/R SCFGREV > > Reset 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > 0 > > 0 0 0 0 0 0 0 > > 0-31 > > SCFGREV SCFG Bit Reverse Control Filed 32'h _ - No bit > reverse > > is applied 32'h _ - Bit reverse is applied; so 31:0 will be > > stored/read as 0:31 > > > > This patch removes the bit reversing for SCFG registers in u-boot. It > > will be implemented through PBI commands in RCW .pbi write 0x570200, > > 0x .end So other SCFG register could be written in big-endian > > mode in u-boot or kernel directly. > > If I understand correctly, below patch removes both setting 0x > and 0x. > does re-setting of SCFG_SCFGREVCR not a requirement? [Alison Wang] Re-setting is not required. It is preferred to remain the bits reversed for other SCFG Registers. > > Just a suggestion: if SCFG_SCFGREVCR_REV and SCFG_SCFGREVCR_NOREV not > required, remove the defines also. [Alison Wang] ok. > > > Signed-off-by: Alison Wang > > --- > > board/freescale/ls1021aqds/ls1021aqds.c | 2 -- > > board/freescale/ls1021atwr/ls1021atwr.c | 5 - > > 2 files changed, 7 deletions(-) > > > > diff --git a/board/freescale/ls1021aqds/ls1021aqds.c > > b/board/freescale/ls1021aqds/ls1021aqds.c > > index e32dbeb..56028f8 100644 > > --- a/board/freescale/ls1021aqds/ls1021aqds.c > > +++ b/board/freescale/ls1021aqds/ls1021aqds.c > > @@ -136,9 +136,7 @@ int board_early_init_f(void) > > struct ccsr_cci400 *cci = (struct ccsr_cci400 > > *)CONFIG_SYS_CCI400_ADDR; > > > > #ifdef CONFIG_TSEC_ENET > > - out_be32(&scfg->scfgrevcr, SCFG_SCFGREVCR_REV); > > out_be32(&scfg->etsecdmamcr, SCFG_ETSECDMAMCR_LE_BD_FR); > > - out_be32(&scfg->scfgrevcr, SCFG_SCFGREVCR_NOREV); > > #endif > > > > #ifdef CONFIG_FSL_IFC > > diff --git a/board/freescale/ls1021atwr/ls1021atwr.c > > b/board/freescale/ls1021atwr/ls1021atwr.c > > index 811c911..ff7130e 100644 > > --- a/board/freescale/ls1021atwr/ls1021atwr.c > > +++ b/board/freescale/ls1021atwr/ls1021atwr.c > > @@ -250,11 +250,8 @@ int board_early_init_f(void) > > struct ccsr_scfg *scfg = (struct ccsr_scfg > > *)CONFIG_SYS_FSL_SCFG_ADDR; > > > > #ifdef CONFIG_TSEC_ENET > > - out_be32(&scfg->scfgrevcr, SCFG_SCFGREVCR_REV); > > out_be32(&scfg->etsecdmamcr, SCFG_ETSECDMAMCR_LE_BD_FR); > > out_be32(&scfg->etsecmcr, SCFG_ETSECCMCR_GE2_CLK125); > > - udelay(10); > > - out_be32(&scfg->scfgrevcr, SCFG_SCFGREVCR_NOREV); > > #endif > > > > #ifdef CONFIG_FSL_IFC > > @@ -262,9 +259,7 @@ int board_early_init_f(void) > > #endif > > > > #ifdef CONFIG_FSL_DCU_FB > > - out_be32(&scfg->scfgrevcr, SCFG_SCFGREVCR_REV); > > out_be32(&scfg->pixclkcr, SCFG_PIXCLKCR_PXCKEN); > > - out_be32(&scfg->scfgrevcr, SCFG_SCFGREVCR_NOREV); > > #endif > > > > return 0; Best Regards, Alison Wang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] Re: [PATCH] sunxi: Fix gmac not working reliable on the Bananapi
On Sun, 28 Sep 2014, Karsten Merker wrote:
On Sun, Sep 28, 2014 at 08:13:21PM +0200, Hans de Goede wrote:
In order for the gmac nic to work reliable on the Bananapi, we need to poke
these 2 undocumented bits in the gmac clk register. Since these are
undocumented, this commit only sets these bits on the Bananapi for now.
I'll contact Allwinner to try and get these bits documented, once they
are documented we can hopefully replace this hack with a better patch.
Reported-by: Karsten Merker
Signed-off-by: Hans de Goede
Tested-by: Karsten Merker
Tested-by: Zoltan HERPAI
---
board/sunxi/gmac.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/board/sunxi/gmac.c b/board/sunxi/gmac.c
index e7ff952..f58c963 100644
--- a/board/sunxi/gmac.c
+++ b/board/sunxi/gmac.c
@@ -24,6 +24,15 @@ int sunxi_gmac_initialize(bd_t *bis)
CCM_GMAC_CTRL_GPIT_MII);
#endif
+ /*
+* HdG: this is necessary to get GMAC to work reliable on the
+* Bananapi. We don't know what these undocumented bits do, so this
+* is a Bananapi specific hack for now.
+*/
+#ifdef CONFIG_BANANAPI
+ setbits_le32(&ccm->gmac_clk_cfg, 0x3 << 10);
+#endif
+
/* Configure pin mux settings for GMAC */
for (pin = SUNXI_GPA(0); pin <= SUNXI_GPA(16); pin++) {
#ifdef CONFIG_RGMII
--
2.1.0
Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCH 5/7] sun4i: Add support for a number of new sun4i boards
On 09/28/2014 05:58 PM, Hans de Goede wrote: [...] On 09/18/2014 06:07 PM, Siarhei Siamashka wrote: Which revision of A10-OLinuXino-LIME do you have? Revision A is known to have troubles running stable at 1008MHz CPU clock speed, as confirmed on a sample set of two boards (mine and Oliver Schinagl's): https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg04343.html I have a revision A board. My Olimex A10 OLinuXino Lime is also labelled "Rev. A"... It is running stable at 1008MHz and I just tried Olivers djpeg test without any problems. I'm running Hans' u-boot-sunxi 2014.10-rc1-g7190869 and Linux mainline 3.17.0-rc1-00158-g451fd72. A bunch of revision C boards were all fine in Oliver's tests. And nobody has ever tested revision B so far, so we have no idea whether it is stable or not. A mysterious thing is that the Olimex representatives on IRC were not aware of any fixes of this kind applied to the PCB. My understanding is that the revision A was just a small pre-production batch, donated by OLIMEX to a number of open source developers. Some of these boards were distributed at FOSDEM. I'm not sure if we should really worry about the reliability of the revision A, because none of the 'normal' customers probably have such boards. We only need to clarify the status of revision B. But if we want to support the revision A too, then it probably needs its own config, which would somehow restrict the CPU clock speed. I also ha My revision A was actually ordered normally, a couple of days before the first batch sold-out. So it is likely that the entire first batch was revision A. Do you have any easy step-by-step document (or ready to use sdcard image to download) to do some stress tests on my revision A ? Maybe the first couple handed out to developers where hand soldered or some such ? Either way it would be good to either confirm that my revision A has the same issues, or not :) I bought my revision A from a German distributor (exp-tech.de) and it doesn't look hand soldered (except for the through hole parts :-) ). If I correctly compared the schematics for revision A,B and C, there is only one change in regard to the DRAM: R8 (connected to ZQ) has a different value: - Revision A: 237 Ohm / 1% - Revision B: 430 Ohm / 1% - Revision C: 330 Ohm / 1% I checked R8 on my revision A's PCB: It is a 330 Ohm / 1%, therefore the value specified in the revision C schematic. So it may make sense to check R8 on the problematic revision A boards and replace it by a 330 Ohm resistor. The DRAM data sheet specifies this resistor with 240 Ohm / 1%... [...] Either way, these settings are outside of the valid range when running at 480MHz (which would be something like DDR3-960 in our case). [...] The current (probably incorrect) values work fine with my board (even though they may be out of spec), but the value of R8 may have some impact here. Best regards, Arnd -- Arnd Gronenberg, a...@gronenberg.com, DJ9PZ / AB2QP smime.p7s Description: S/MIME Cryptographic Signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCH 5/7] sun4i: Add support for a number of new sun4i boards
On Sun, 28 Sep 2014 17:58:41 +0200 Hans de Goede wrote: > Hi, > > On 09/18/2014 06:07 PM, Siarhei Siamashka wrote: > > On Sun, 27 Jul 2014 23:25:21 +0200 > > Hans de Goede wrote: > > > > Which revision of A10-OLinuXino-LIME do you have? Revision A is known > > to have troubles running stable at 1008MHz CPU clock speed, as confirmed > > on a sample set of two boards (mine and Oliver Schinagl's): > > https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg04343.html > > I have a revision A board. > > > A bunch of revision C boards were all fine in Oliver's tests. And > > nobody has ever tested revision B so far, so we have no idea whether > > it is stable or not. A mysterious thing is that the Olimex > > representatives on IRC were not aware of any fixes of this kind > > applied to the PCB. > > > > My understanding is that the revision A was just a small pre-production > > batch, donated by OLIMEX to a number of open source developers. Some of > > these boards were distributed at FOSDEM. I'm not sure if we should > > really worry about the reliability of the revision A, because none of > > the 'normal' customers probably have such boards. We only need to > > clarify the status of revision B. > > > > But if we want to support the revision A too, then it probably needs > > its own config, which would somehow restrict the CPU clock speed. > > My revision A was actually ordered normally, a couple of days before > the first batch sold-out. So it is likely that the entire first batch > was revision A. > > Do you have any easy step-by-step document (or ready to use sdcard > image to download) to do some stress tests on my revision A ? The easy step-by-step document was there since the beginning of May: https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg04343.html If you don't mind to download random binaries from the Internet, there was also a link to the static djpeg binary if you are unsure about the one used in your distro and don't want to waste time compiling libjpeg-turbo yourself. Also it looks like now we need to try a little bit harder with the mainline kernel, so I have posted some updates in my reply to Arnd Gronenberg: http://lists.denx.de/pipermail/u-boot/2014-September/190061.html Taking all of this into account and with the use of the djpeg static binary download, it's just a few lines to type in the console: cd /tmp && wget http://linux-sunxi.org/images/8/83/A10-LIME.jpg wget http://people.freedesktop.org/~siamashka/files/20140504/djpeg-static chmod +x djpeg-static while true ; do ./djpeg-static A10-LIME.jpg | md5sum ; done If identical hashes show up in each line of the output, then everything is fine. If some hashes end up to be different, then there is data corruption happening during JPEG decoding, which indicates hardware reliability issues. > Maybe the first couple handed out to developers where hand soldered > or some such ? Either way it would be good to either confirm that > my revision A has the same issues, or not :) My board looks fine (without any visible soldering problems). As discussed months ago on the linux-sunxi mailing list, we are suspecting that the root cause is some significant voltage drop on the dcdc2 power line between the PMIC and the SoC. So that if the current is high (under high CPU usage) then the SoC actually gets a substantially reduced voltage compared to the requested 1.4V from the PMIC. Newer revisions of the A10-Lime PCB might just have a beefier power line with reduced resistance, but that's only a speculation. By the way, it looks like the Banana Pi might suffer from the very same problem. Somebody has just submitted a FEX file update (FEX serves a similar purpose as DTS in the sunxi-3.4 kernel): https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg07629.html The commit message only says "Fix the unstable problem caused by dvfs table" without going into any details. The change that they are introducing is in fact moving the highest cpufreq operating point from "912MHz at 1.4V" to "912MHz at 1.425V". Supposedly to fix some reliability problems reproduced on some undisclosed use case. Now if we are trying to use the mainline kernel, then it does not have cpufreq support and the CPU clock frequency/voltage settings are inherited from u-boot. And u-boot currently configures them to, surprise surprise, "912MHz at 1.4V" which is expected to be unstable according to that FEX update submitter. This raises an obvious red flag. The libjpeg-turbo decoding test appears to be sensitive to the CPU clock frequency/voltage (at least for Cortex-A8), so somebody might want to give it a try also on the Banana Pi. Or if the libjpeg-turbo test does not reveal anything interesting, then we might want to ask the Banana Pi FEX update submitter to find out how the reliability problem is supposed to be reproduced. -- Best regards, Siarhei Siamashka ___ U-Boot mailing list U-Boot
Re: [U-Boot] [linux-sunxi] [PATCH 5/7] sun4i: Add support for a number of new sun4i boards
On Mon, 29 Sep 2014 08:38:42 +0300 Siarhei Siamashka wrote: > On Sun, 28 Sep 2014 17:58:41 +0200 > Hans de Goede wrote: > > > Do you have any easy step-by-step document (or ready to use sdcard > > image to download) to do some stress tests on my revision A ? > > The easy step-by-step document was there since the beginning of May: > https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg04343.html > > If you don't mind to download random binaries from the Internet, there > was also a link to the static djpeg binary if you are unsure about the > one used in your distro and don't want to waste time compiling > libjpeg-turbo yourself. > > Also it looks like now we need to try a little bit harder with the > mainline kernel, so I have posted some updates in my reply to > Arnd Gronenberg: > http://lists.denx.de/pipermail/u-boot/2014-September/190061.html > > Taking all of this into account and with the use of the djpeg static > binary download, it's just a few lines to type in the console: > > > cd /tmp && wget http://linux-sunxi.org/images/8/83/A10-LIME.jpg > wget http://people.freedesktop.org/~siamashka/files/20140504/djpeg-static > chmod +x djpeg-static while true ; do ./djpeg-static A10-LIME.jpg | > md5sum ; done Sorry, my e-mail client decided to unhelpfully reshuffle line breaks. This was supped to be: cd /tmp && wget http://linux-sunxi.org/images/8/83/A10-LIME.jpg wget http://people.freedesktop.org/~siamashka/files/20140504/djpeg-static chmod +x djpeg-static while true ; do ./djpeg-static A10-LIME.jpg | md5sum ; done -- Best regards, Siarhei Siamashka ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/mpc85xx:Update RESET_VECTOR_ADDRESS for 768KB u-boot size
U-boot binary size has been increased from 512KB to 768KB. So update CONFIG_RESET_VECTOR_ADDRESS to reflect the same for P1010 SPI Flash Secure boot target. Signed-off-by: Ruchika Gupta --- include/configs/P1010RDB.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/P1010RDB.h b/include/configs/P1010RDB.h index 54365a2..7039da4 100644 --- a/include/configs/P1010RDB.h +++ b/include/configs/P1010RDB.h @@ -53,7 +53,7 @@ #ifdef CONFIG_SECURE_BOOT #define CONFIG_RAMBOOT_SPIFLASH #define CONFIG_SYS_TEXT_BASE 0x1100 -#define CONFIG_RESET_VECTOR_ADDRESS0x1107fffc +#define CONFIG_RESET_VECTOR_ADDRESS0x110bfffc #else #define CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT #define CONFIG_SPL_DRIVERS_MISC_SUPPORT -- 1.8.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] mpc85xx: configs - Add hash command in freescale platforms
Hi York, The patch caused size issues, because the change for uboot image size to 768 K was missing for this target. I have sent a patch which fixes this issue. https://patchwork.ozlabs.org/patch/394275/ Can you pick up this patch before the rest of the patches. That would resolve the size problems. Regards, Ruchika > -Original Message- > From: Sun York-R58495 > Sent: Thursday, September 25, 2014 9:01 PM > To: Gupta Ruchika-R66431; u-boot@lists.denx.de > Subject: Re: [PATCH 2/2] mpc85xx: configs - Add hash command in freescale > platforms > > On 09/10/2014 08:58 PM, Ruchika Gupta wrote: > > Hardware accelerated support for SHA-1 and SHA-256 has been added. > > Hash command enabled along with hardware accelerated support for > > SHA-1 and SHA-256 for platforms which have CAAM block. > > > > Signed-off-by: Ruchika Gupta > > CC: York Sun > > --- > > The patch series is dependent on > > https://patchwork.ozlabs.org/patch/387174/ > > https://patchwork.ozlabs.org/patch/387175/ > > Ruchika, > > This patch further increases the size of image. This board failed to compile > > P1010RDB-PB_SPIFLASH_SECBOOT > > York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3][v3] mpc85xx: configs - Enable blob command in freescale platforms
Enable blob commands for platforms having SEC 4.0 or greater for secure boot scenarios Signed-off-by: Ruchika Gupta --- Changes from v2: Fixed the compilation issue for T208x platform include/configs/B4860QDS.h | 4 include/configs/BSC9132QDS.h | 4 include/configs/P1010RDB.h | 4 include/configs/P2041RDB.h | 4 include/configs/T1040QDS.h | 1 + include/configs/T104xRDB.h | 1 + include/configs/T208xQDS.h | 1 + include/configs/T208xRDB.h | 1 + include/configs/T4240QDS.h | 4 include/configs/T4240RDB.h | 1 + include/configs/corenet_ds.h | 4 11 files changed, 29 insertions(+) diff --git a/include/configs/B4860QDS.h b/include/configs/B4860QDS.h index 58932ad..9217f37 100644 --- a/include/configs/B4860QDS.h +++ b/include/configs/B4860QDS.h @@ -909,4 +909,8 @@ unsigned long get_board_ddr_clk(void); #include +#ifdef CONFIG_SECURE_BOOT +#define CONFIG_CMD_BLOB +#endif + #endif /* __CONFIG_H */ diff --git a/include/configs/BSC9132QDS.h b/include/configs/BSC9132QDS.h index 922ac00..32fc099 100644 --- a/include/configs/BSC9132QDS.h +++ b/include/configs/BSC9132QDS.h @@ -708,4 +708,8 @@ combinations. this should be removed later #include +#ifdef CONFIG_SECURE_BOOT +#define CONFIG_CMD_BLOB +#endif + #endif /* __CONFIG_H */ diff --git a/include/configs/P1010RDB.h b/include/configs/P1010RDB.h index 45ef53d..54365a2 100644 --- a/include/configs/P1010RDB.h +++ b/include/configs/P1010RDB.h @@ -960,4 +960,8 @@ extern unsigned long get_sdram_size(void); #include +#ifdef CONFIG_SECURE_BOOT +#define CONFIG_CMD_BLOB +#endif + #endif /* __CONFIG_H */ diff --git a/include/configs/P2041RDB.h b/include/configs/P2041RDB.h index 7ff2dd5..0b12cf5 100644 --- a/include/configs/P2041RDB.h +++ b/include/configs/P2041RDB.h @@ -747,4 +747,8 @@ unsigned long get_board_sys_clk(unsigned long dummy); #include +#ifdef CONFIG_SECURE_BOOT +#define CONFIG_CMD_BLOB +#endif + #endif /* __CONFIG_H */ diff --git a/include/configs/T1040QDS.h b/include/configs/T1040QDS.h index 5870a49..bbe54bf 100644 --- a/include/configs/T1040QDS.h +++ b/include/configs/T1040QDS.h @@ -822,6 +822,7 @@ unsigned long get_board_ddr_clk(void); #ifdef CONFIG_SECURE_BOOT #include +#define CONFIG_CMD_BLOB #endif #endif /* __CONFIG_H */ diff --git a/include/configs/T104xRDB.h b/include/configs/T104xRDB.h index db50b1a..0ecdfc0 100644 --- a/include/configs/T104xRDB.h +++ b/include/configs/T104xRDB.h @@ -865,6 +865,7 @@ #ifdef CONFIG_SECURE_BOOT #include +#define CONFIG_CMD_BLOB #endif #endif /* __CONFIG_H */ diff --git a/include/configs/T208xQDS.h b/include/configs/T208xQDS.h index 9a8a3b6..f40ad9a 100644 --- a/include/configs/T208xQDS.h +++ b/include/configs/T208xQDS.h @@ -913,6 +913,7 @@ unsigned long get_board_ddr_clk(void); #ifdef CONFIG_SECURE_BOOT #include +#define CONFIG_CMD_BLOB #undef CONFIG_CMD_USB #endif diff --git a/include/configs/T208xRDB.h b/include/configs/T208xRDB.h index 4ff31e6..8d4b02f 100644 --- a/include/configs/T208xRDB.h +++ b/include/configs/T208xRDB.h @@ -872,6 +872,7 @@ unsigned long get_board_ddr_clk(void); #ifdef CONFIG_SECURE_BOOT #include +#define CONFIG_CMD_BLOB #undef CONFIG_CMD_USB #endif diff --git a/include/configs/T4240QDS.h b/include/configs/T4240QDS.h index d2faf94..e3bbfeb 100644 --- a/include/configs/T4240QDS.h +++ b/include/configs/T4240QDS.h @@ -629,4 +629,8 @@ unsigned long get_board_ddr_clk(void); #include +#ifdef CONFIG_SECURE_BOOT +#define CONFIG_CMD_BLOB +#endif + #endif /* __CONFIG_H */ diff --git a/include/configs/T4240RDB.h b/include/configs/T4240RDB.h index b3fbbe3..82e5efd 100644 --- a/include/configs/T4240RDB.h +++ b/include/configs/T4240RDB.h @@ -755,6 +755,7 @@ unsigned long get_board_ddr_clk(void); * which is anyways not used in Secure Environment. */ #undef CONFIG_CMD_USB +#define CONFIG_CMD_BLOB #endif #endif /* __CONFIG_H */ diff --git a/include/configs/corenet_ds.h b/include/configs/corenet_ds.h index 4fd290e..b0c8277 100644 --- a/include/configs/corenet_ds.h +++ b/include/configs/corenet_ds.h @@ -749,4 +749,8 @@ #include +#ifdef CONFIG_SECURE_BOOT +#define CONFIG_CMD_BLOB +#endif + #endif /* __CONFIG_H */ -- 1.8.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3][v3] ls102x: Add support for secure boot and enable blob command
Signed-off-by: Ruchika Gupta --- Changes from v2: No changes configs/ls1021aqds_nor_SECURE_BOOT_defconfig | 3 +++ configs/ls1021atwr_nor_SECURE_BOOT_defconfig | 3 +++ include/configs/ls1021aqds.h | 4 include/configs/ls1021atwr.h | 4 4 files changed, 14 insertions(+) create mode 100644 configs/ls1021aqds_nor_SECURE_BOOT_defconfig create mode 100644 configs/ls1021atwr_nor_SECURE_BOOT_defconfig diff --git a/configs/ls1021aqds_nor_SECURE_BOOT_defconfig b/configs/ls1021aqds_nor_SECURE_BOOT_defconfig new file mode 100644 index 000..2b47995 --- /dev/null +++ b/configs/ls1021aqds_nor_SECURE_BOOT_defconfig @@ -0,0 +1,3 @@ +CONFIG_SYS_EXTRA_OPTIONS="SECURE_BOOT" +CONFIG_ARM=y +CONFIG_TARGET_LS1021AQDS=y diff --git a/configs/ls1021atwr_nor_SECURE_BOOT_defconfig b/configs/ls1021atwr_nor_SECURE_BOOT_defconfig new file mode 100644 index 000..eeeb0d5 --- /dev/null +++ b/configs/ls1021atwr_nor_SECURE_BOOT_defconfig @@ -0,0 +1,3 @@ +CONFIG_SYS_EXTRA_OPTIONS="SECURE_BOOT" +CONFIG_ARM=y +CONFIG_TARGET_LS1021ATWR=y diff --git a/include/configs/ls1021aqds.h b/include/configs/ls1021aqds.h index df2fc09..9c49fcf 100644 --- a/include/configs/ls1021aqds.h +++ b/include/configs/ls1021aqds.h @@ -392,4 +392,8 @@ unsigned long get_board_ddr_clk(void); #define CONFIG_CMD_HASH #define CONFIG_SHA_HW_ACCEL +#ifdef CONFIG_SECURE_BOOT +#define CONFIG_CMD_BLOB +#endif + #endif diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h index 7199c92..8a78d22 100644 --- a/include/configs/ls1021atwr.h +++ b/include/configs/ls1021atwr.h @@ -294,4 +294,8 @@ #define CONFIG_CMD_HASH #define CONFIG_SHA_HW_ACCEL +#ifdef CONFIG_SECURE_BOOT +#define CONFIG_CMD_BLOB +#endif + #endif -- 1.8.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3][v3] crypto/fsl: Add command for encapsulating/decapsulating blobs
Freescale's SEC block has built-in Blob Protocol which provides
a method for protecting user-defined data across system power
cycles. SEC block protects data in a data structure called a Blob,
which provides both confidentiality and integrity protection.
Encapsulating data as a blob
Each time that the Blob Protocol is used to protect data, a
different randomly generated key is used to encrypt the data.
This random key is itself encrypted using a key which is derived
from SoC's non volatile secret key and a 16 bit Key identifier.
The resulting encrypted key along with encrypted data is called a blob.
The non volatile secure key is available for use only during secure boot.
During decapsulation, the reverse process is performed to get back
the original data.
Commands added
--
blob enc - encapsulating data as a cryptgraphic blob
blob dec - decapsulating cryptgraphic blob to get the data
Commands Syntax
---
blob enc src dst len km
Encapsulate and create blob of data $len bytes long
at address $src and store the result at address $dst.
$km is the 16 byte key modifier is also required for
generation/use as key for cryptographic operation. Key
modifier should be 16 byte long.
blob dec src dst len km
Decapsulate the blob of data at address $src and
store result of $len byte at addr $dst.
$km is the 16 byte key modifier is also required for
generation/use as key for cryptographic operation. Key
modifier should be 16 byte long.
Signed-off-by: Ruchika Gupta
---
Changes from v2
No changes
common/Makefile | 2 +
common/cmd_blob.c | 109
drivers/crypto/fsl/Makefile | 1 +
drivers/crypto/fsl/fsl_blob.c | 61
drivers/crypto/fsl/jobdesc.c | 80 ++
drivers/crypto/fsl/jobdesc.h | 11
drivers/crypto/fsl/jr.c | 127 +-
include/fsl_sec.h | 34 ++-
8 files changed, 423 insertions(+), 2 deletions(-)
create mode 100644 common/cmd_blob.c
create mode 100644 drivers/crypto/fsl/fsl_blob.c
diff --git a/common/Makefile b/common/Makefile
index b19d379..c84b3bc 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -265,4 +265,6 @@ obj-y += aboot.o
obj-y += fb_mmc.o
endif
+obj-$(CONFIG_CMD_BLOB) += cmd_blob.o
+
CFLAGS_env_embedded.o := -Wa,--no-warn -DENV_CRC=$(shell tools/envcrc
2>/dev/null)
diff --git a/common/cmd_blob.c b/common/cmd_blob.c
new file mode 100644
index 000..82ecaf0
--- /dev/null
+++ b/common/cmd_blob.c
@@ -0,0 +1,109 @@
+/*
+ *
+ * Command for encapsulating/decapsulating blob of memory.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/**
+ * blob_decap() - Decapsulate the data as a blob
+ * @key_mod: - Pointer to key modifier/key
+ * @src: - Address of data to be decapsulated
+ * @dst: - Address of data to be decapsulated
+ * @len: - Size of data to be decapsulated
+ *
+ * Returns zero on success,and negative on error.
+ */
+__weak int blob_decap(u8 *key_mod, u8 *src, u8 *dst, u32 len)
+{
+ return 0;
+}
+
+/**
+ * blob_encap() - Encapsulate the data as a blob
+ * @key_mod: - Pointer to key modifier/key
+ * @src: - Address of data to be encapsulated
+ * @dst: - Address of data to be encapsulated
+ * @len: - Size of data to be encapsulated
+ *
+ * Returns zero on success,and negative on error.
+ */
+__weak int blob_encap(u8 *key_mod, u8 *src, u8 *dst, u32 len)
+{
+ return 0;
+}
+
+/**
+ * do_blob() - Handle the "blob" command-line command
+ * @cmdtp: Command data struct pointer
+ * @flag: Command flag
+ * @argc: Command-line argument count
+ * @argv: Array of command-line arguments
+ *
+ * Returns zero on success, CMD_RET_USAGE in case of misuse and negative
+ * on error.
+ */
+static int do_blob(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[])
+{
+ uint32_t key_addr, src_addr, dst_addr, len;
+ uint8_t *km_ptr, *src_ptr, *dst_ptr;
+ int enc, ret = 0;
+
+ if (argc != 6)
+ return CMD_RET_USAGE;
+
+ if (!strncmp(argv[1], "enc", 3))
+ enc = 1;
+ else if (!strncmp(argv[1], "dec", 3))
+ enc = 0;
+ else
+ return CMD_RET_USAGE;
+
+ src_addr = simple_strtoul(argv[2], NULL, 16);
+ dst_addr = simple_strtoul(argv[3], NULL, 16);
+ len = simple_strtoul(argv[4], NULL, 16);
+ key_addr = simple_strtoul(argv[5], NULL, 16);
+
+ km_ptr = (uint8_t *)key_addr;
+ src_ptr = (uint8_t *)src_addr;
+ dst_ptr = (uint8_t *)dst_addr;
+
+ if (enc)
+ ret = blob_encap(km_ptr, src_ptr, dst_ptr, len);
+ else
+ ret = blob_decap(km_ptr, src_ptr, dst_ptr, len);
+
+
Re: [U-Boot] [PATCH v8 08/12] dm: exynos: Move s5p_goni to generic board
On 09/15/2014 12:29 AM, Simon Glass wrote: > The generic board deadline is approaching, and we need this feature to > enable driver model. Enable CONFIG_SYS_GENERIC_BOARD for s5p_goni. > > Signed-off-by: Simon Glass > --- > > Changes in v8: > - Add new patch to move s5p_goni to generic board > > Changes in v7: None > Changes in v6: None > Changes in v5: None > Changes in v4: None > > include/configs/s5p_goni.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/configs/s5p_goni.h b/include/configs/s5p_goni.h > index ec78b6e..b7d9cb7 100644 > --- a/include/configs/s5p_goni.h > +++ b/include/configs/s5p_goni.h > @@ -289,4 +289,6 @@ > #define CONFIG_OF_SEPARATE > #define CONFIG_OF_LIBFDT > > +#define CONFIG_SYS_GENERIC_BOARD > + > #endif /* __CONFIG_H */ > Acked-by: Robert Baldyga Thanks, Robert Baldyga ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH][v2] powerpc/mpc85xx: SECURE BOOT - Bypass PAMU in case of secure boot
By default, PAMU's (IOMMU) are enabled in case of secure boot.
Disable/bypass them , once the control reached the bootloader.
For non-secure boot, PAMU's are already bypassed in the default
SoC configuration
Signed-off-by: Ruchika Gupta
---
Changes from v1:
PAMU is available only in platforms with CORENET.
Moved the changes under #define CONFIG_FSL_CORENET
to fix build issues for non-corenet platforms
arch/powerpc/cpu/mpc85xx/cpu_init.c | 9 -
arch/powerpc/include/asm/immap_85xx.h | 1 +
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index 21c3194..c522625 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -424,7 +424,8 @@ ulong cpu_init_f(void)
{
ulong flag = 0;
extern void m8560_cpm_reset (void);
-#ifdef CONFIG_SYS_DCSRBAR_PHYS
+#if defined(CONFIG_SYS_DCSRBAR_PHYS) || \
+ (defined(CONFIG_SECURE_BOOT) && defined(CONFIG_FSL_CORENET))
ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
#endif
#if defined(CONFIG_SECURE_BOOT)
@@ -456,6 +457,12 @@ ulong cpu_init_f(void)
#if defined(CONFIG_SYS_CPC_REINIT_F)
disable_cpc_sram();
#endif
+
+#if defined(CONFIG_FSL_CORENET)
+ /* Put PAMU in bypass mode */
+ out_be32(&gur->pamubypenr, FSL_CORENET_PAMU_BYPASS);
+#endif
+
#endif
#ifdef CONFIG_CPM2
diff --git a/arch/powerpc/include/asm/immap_85xx.h
b/arch/powerpc/include/asm/immap_85xx.h
index 88c1e08..0264523 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -1912,6 +1912,7 @@ defined(CONFIG_PPC_T1020) || defined(CONFIG_PPC_T1022)
u8 res24[64];
u32 pblsr; /* Preboot loader status */
u32 pamubypenr; /* PAMU bypass enable */
+#define FSL_CORENET_PAMU_BYPASS0x
u32 dmacr1; /* DMA control */
u8 res25[4];
u32 gensr1; /* General status */
--
1.8.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCH] sunxi: Fix gmac not working reliable on the Bananapi
On Sun, 28 Sep 2014 20:13:21 +0200
Hans de Goede wrote:
> In order for the gmac nic to work reliable on the Bananapi, we need to poke
> these 2 undocumented bits in the gmac clk register. Since these are
> undocumented, this commit only sets these bits on the Bananapi for now.
>
> I'll contact Allwinner to try and get these bits documented, once they
> are documented we can hopefully replace this hack with a better patch.
Could you please provide a bit more details in the commit message?
What are the symptoms of the problem? How did you come to the idea
to poke these bits? Does the GMAC driver in the linux kernel need a
similar fix/workaround? And if you apply it in the linux kernel, does
it provide any visible changes in performance or anything else?
Also as mentioned in another e-mail
http://lists.denx.de/pipermail/u-boot/2014-September/190096.html
u-boot configures the "912MHz @1.4V" CPU clock frequency/voltage
setup for sun7i hardware. And according to the information from Tony
Zhang, this is supposed to be unreliable for the Banana Pi. So what
happens to this GMAC bug if you just increase the dcdc2 voltage in
u-boot (or reduce the CPU clock frequency)?
I remember that some users suffered from GMAC problems, which turned
out to be caused by just overclocking the CPU to 1.2GHz (a "helful"
SD card image creator decided that the users would like to enjoy
better performance):
http://www.cubieforums.com/index.php/topic,2590.0.html
So it looks like GMAC might be one of those canaries, which die first
on wrong CPU clock frequency/voltage settings.
> Reported-by: Karsten Merker
> Signed-off-by: Hans de Goede
> ---
> board/sunxi/gmac.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/board/sunxi/gmac.c b/board/sunxi/gmac.c
> index e7ff952..f58c963 100644
> --- a/board/sunxi/gmac.c
> +++ b/board/sunxi/gmac.c
> @@ -24,6 +24,15 @@ int sunxi_gmac_initialize(bd_t *bis)
> CCM_GMAC_CTRL_GPIT_MII);
> #endif
>
> + /*
> + * HdG: this is necessary to get GMAC to work reliable on the
> + * Bananapi. We don't know what these undocumented bits do, so this
> + * is a Bananapi specific hack for now.
> + */
> +#ifdef CONFIG_BANANAPI
> + setbits_le32(&ccm->gmac_clk_cfg, 0x3 << 10);
> +#endif
> +
> /* Configure pin mux settings for GMAC */
> for (pin = SUNXI_GPA(0); pin <= SUNXI_GPA(16); pin++) {
> #ifdef CONFIG_RGMII
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ORIGEN: Enhance origen config to be more flexible on boot.
Ping.
Guillaume
Le 19/09/2014 15:32, Guillaume GARDET a écrit :
This patch enhances the boot of origen board by adding support to ext2, bootz,
initrd, bootenv loading and boot script.
It still keeps the previous mmc load command if boot script fails.
Signed-off-by: Guillaume GARDET
Cc: Minkyu Kang
---
include/configs/origen.h | 35 ++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/include/configs/origen.h b/include/configs/origen.h
index 5d24916..2117fe1 100644
--- a/include/configs/origen.h
+++ b/include/configs/origen.h
@@ -61,6 +61,10 @@
#undef CONFIG_CMD_PING
#define CONFIG_CMD_ELF
#define CONFIG_CMD_DHCP
+#define CONFIG_CMD_EXT2
+#define CONFIG_CMD_FS_GENERIC
+#define CONFIG_CMD_BOOTZ
+#define CONFIG_SUPPORT_RAW_INITRD
#undef CONFIG_CMD_NET
#undef CONFIG_CMD_NFS
@@ -68,7 +72,36 @@
#define COPY_BL2_FNPTR_ADDR 0x02020030
#define CONFIG_SPL_TEXT_BASE 0x02021410
-#define CONFIG_BOOTCOMMAND "fatload mmc 0 40007000 uImage; bootm 40007000"
+#define CONFIG_EXTRA_ENV_SETTINGS \
+ "loadaddr=0x40007000\0" \
+ "rdaddr=0x4800\0" \
+ "kerneladdr=0x40007000\0" \
+ "ramdiskaddr=0x4800\0" \
+ "console=ttySAC2,115200n8\0" \
+ "mmcdev=0\0" \
+ "bootenv=uEnv.txt\0" \
+ "loadbootenv=load mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \
+ "importbootenv=echo Importing environment from mmc ...; " \
+ "env import -t $loadaddr $filesize\0" \
+ "loadbootscript=load mmc ${mmcdev} ${loadaddr} boot.scr\0" \
+ "bootscript=echo Running bootscript from mmc${mmcdev} ...; " \
+ "source ${loadaddr}\0"
+#define CONFIG_BOOTCOMMAND \
+ "if mmc rescan; then " \
+ "echo SD/MMC found on device ${mmcdev}; " \
+ "if run loadbootenv; then " \
+ "echo Loaded environment from ${bootenv}; " \
+ "run importbootenv; " \
+ "fi; " \
+ "if test -n $uenvcmd; then " \
+ "echo Running uenvcmd ...; " \
+ "run uenvcmd; " \
+ "fi; " \
+ "if run loadbootscript; then " \
+ "run bootscript; " \
+ "fi; " \
+ "fi; " \
+ "load mmc ${mmcdev} ${loadaddr} uImage; bootm ${loadaddr} "
#define CONFIG_IDENT_STRING " for ORIGEN"
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARNDALE: Enhance arndale config to be more flexible on boot.
Ping.
Guillaume
Le 19/09/2014 15:31, Guillaume GARDET a écrit :
This patch enhances the boot of arndale board by adding support to bootz,
initrd, bootenv loading and boot script.
It still keeps the previous mmc load command if boot script fails.
Signed-off-by: Guillaume GARDET
Cc: Minkyu Kang
---
include/configs/arndale.h | 38 ++
1 file changed, 34 insertions(+), 4 deletions(-)
diff --git a/include/configs/arndale.h b/include/configs/arndale.h
index 75f9933..edf9ee6 100644
--- a/include/configs/arndale.h
+++ b/include/configs/arndale.h
@@ -72,9 +72,6 @@
"stdout=serial\0" \
"stderr=serial\0"
-#define CONFIG_EXTRA_ENV_SETTINGS \
- EXYNOS_DEVICE_SETTINGS
-
/* SD/MMC configuration */
#define CONFIG_GENERIC_MMC
#define CONFIG_MMC
@@ -103,8 +100,11 @@
#define CONFIG_CMD_MMC
#define CONFIG_CMD_EXT2
#define CONFIG_CMD_FAT
+#define CONFIG_CMD_FS_GENERIC
#define CONFIG_CMD_NET
#define CONFIG_CMD_HASH
+#define CONFIG_SUPPORT_RAW_INITRD
+#define CONFIG_CMD_BOOTZ
#define CONFIG_BOOTDELAY 3
#define CONFIG_ZERO_BOOTDELAY_CHECK
@@ -130,7 +130,37 @@
#define CONFIG_SPL_TEXT_BASE 0x02023400
#define CONFIG_SPL_MAX_FOOTPRINT (14 * 1024)
-#define CONFIG_BOOTCOMMAND "mmc read 40007000 451 2000; bootm 40007000"
+#define CONFIG_EXTRA_ENV_SETTINGS \
+ EXYNOS_DEVICE_SETTINGS \
+ "loadaddr=0x40007000\0" \
+ "rdaddr=0x4f00\0" \
+ "kerneladdr=0x40007000\0" \
+ "ramdiskaddr=0x4f00\0" \
+ "console=ttySAC2,115200n8\0" \
+ "mmcdev=1\0" \
+ "bootenv=uEnv.txt\0" \
+ "loadbootenv=load mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \
+ "importbootenv=echo Importing environment from mmc ...; " \
+ "env import -t $loadaddr $filesize\0" \
+ "loadbootscript=load mmc ${mmcdev} ${loadaddr} boot.scr\0" \
+ "bootscript=echo Running bootscript from mmc${mmcdev} ...; " \
+ "source ${loadaddr}\0"
+#define CONFIG_BOOTCOMMAND \
+ "if mmc rescan; then " \
+ "echo SD/MMC found on device ${mmcdev}; " \
+ "if run loadbootenv; then " \
+ "echo Loaded environment from ${bootenv}; " \
+ "run importbootenv; " \
+ "fi; " \
+ "if test -n $uenvcmd; then " \
+ "echo Running uenvcmd ...; " \
+ "run uenvcmd; " \
+ "fi; " \
+ "if run loadbootscript; then " \
+ "run bootscript; " \
+ "fi; " \
+ "fi; " \
+ "mmc read ${loadaddr} 451 2000; bootm ${loadaddr} "
/* Miscellaneous configurable options */
#define CONFIG_SYS_LONGHELP /* undef to save memory */
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
