Re: [U-Boot] [PATCH 06/11] MX6: add struct for sharing data between SPL and uboot
On Mon, Apr 14, 2014 at 5:35 AM, Stefano Babic sba...@denx.de wrote: Hi Tim, I see checking your patch that the MXS uses the same concept. And as far as I can see, boot_mode_idx is used only to print the boot devioce Stefano, yes, that is where I got the concept from. However, we have not generally a concept to pass data between SPL and u-boot. My question is even if it is really needed. The size of DRAM is retrived at run time by u-boot running get_ram_size(), that is a better solution. I've been told this before, but I've found that get_ram_size() will hang on an i.MX6 if you pass it a maxsize larger than the memory in your system. Perhaps you can verify you see the same behavior? SPL is thought to generally load an image (of course, in most cases it is u-boot). In Falcon mode, the kernel is started without running u-boot, making this structure useless. Do we really need such a way (but then, it must be generalized as SPL API), or can we get rid of it ? As we have an EEPROM on the board that tells us the physical ram size, I use that to avoid the lockup. Eventually I would like to read and validate the entire EEPROM once in SPL and pass this to u-boot.img to avoid reading and validating it again. I think this is a good example of why sharing data between SPL and u-boot.img could be useful. Regards, Tim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/11] MX6: add boot device support SPL
On Mon, Apr 14, 2014 at 5:27 AM, Stefano Babic sba...@denx.de wrote:
Hi Tim,
diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
index 1725279..4ee62c7 100644
--- a/arch/arm/cpu/armv7/mx6/soc.c
+++ b/arch/arm/cpu/armv7/mx6/soc.c
@@ -305,6 +305,62 @@ const struct boot_mode soc_boot_modes[] = {
{NULL, 0},
};
+/* determine boot device from SRC_SBMR1 register (BOOT_CFG[4:1]) */
+enum boot_device get_boot_device(void)
+{
+ enum boot_device boot_dev;
+
+ uint soc_sbmr = readl(SRC_BASE_ADDR + 0x4); /* SRC_SBMR1 */
Use structure to access internal registers. The structure is already
defined in imx-regs.h.
Agreed - I will do this for v2.
+
+ /* BOOT_CFG1[7:4] - see IMX6DQRM Table 8-8 */
+ switch ((soc_sbmr 0x00FF) 4) {
+ /* EIM: See 8.5.1, Table 8-9 */
+ case 0x0:
+ /* BOOT_CFG1[3]: NOR/OneNAND Selection */
+ if ((soc_sbmr 0x0008) 3)
+ boot_dev = MX6_ONE_NAND_BOOT;
+ else
+ boot_dev = MX6_WEIM_NOR_BOOT;
+ break;
+ /* SATA: See 8.5.4, Table 8-20 */
+ case 0x2:
Can we use #defines for that ?
Yes, I'll add them to imx-regs.h.
+ boot_dev = MX6_SATA_BOOT;
+ break;
+ /* Serial ROM: See 8.5.5.1, Table 8-22 */
+ case 0x3:
+ /* BOOT_CFG4[2:0] */
+ switch ((soc_sbmr 0x0700) 24) {
+ case 0x0 ... 0x4:
+ boot_dev = MX6_SPI_NOR_BOOT;
+ break;
+ case 0x5 ... 0x7:
+ boot_dev = MX6_I2C_BOOT;
+ break;
+ }
+ break;
+ /* SD/eSD: 8.5.3, Table 8-15 */
+ case 0x4:
+ case 0x5:
+ boot_dev = MX6_SD_BOOT;
+ break;
+ /* MMC/eMMC: 8.5.3 */
+ case 0x6:
+ case 0x7:
+ boot_dev = MX6_MMC_BOOT;
+ break;
+ /* NAND Flash: 8.5.2 */
+ case 0x8 ... 0xf:
+ boot_dev = MX6_NAND_BOOT;
+ break;
+ default:
+ boot_dev = MX6_UNKNOWN_BOOT;
+ break;
+ }
+
The function can be used as well for MX5 SOCs. Move it into imx-common,
and use constants without SOC names. Instead of MX6_NAND_BOOT,
IMX_NAND_BOOT (or whatever you find makes sense..)
Are you saying the i.MX5's have the same register and meaning? I
figured the sbmr is different.
+ return boot_dev;
+}
+
+
void s_init(void)
{
struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
diff --git a/arch/arm/include/asm/arch-mx6/spl.h
b/arch/arm/include/asm/arch-mx6/spl.h
new file mode 100644
index 000..5611c71
--- /dev/null
+++ b/arch/arm/include/asm/arch-mx6/spl.h
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2013 TechNexion Ltd.
+ *
+ * Author: Richard Hu linux...@technexion.com
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#ifndef __ASM_ARCH_SPL_H__
+#define __ASM_ARCH_SPL_H__
+
+#define BOOT_DEVICE_MMC1 0
+#define BOOT_DEVICE_MMC2 1
+#define BOOT_DEVICE_MMC2_2 2
+#define BOOT_DEVICE_NAND 3
+#define BOOT_DEVICE_SATA 4
+#define BOOT_DEVICE_USBETH 5
+#define BOOT_DEVICE_NONE 6
+
They are only defines and are not yet related to i.MX6 anymnore, because
you have already mapped them. What about to move this defines into
imx-common ?
ok
+#endif /* __ASM_ARCH_SPL_H__ */
diff --git a/arch/arm/include/asm/imx-common/boot_mode.h
b/arch/arm/include/asm/imx-common/boot_mode.h
index de0205c..3686367 100644
--- a/arch/arm/include/asm/imx-common/boot_mode.h
+++ b/arch/arm/include/asm/imx-common/boot_mode.h
@@ -17,4 +17,21 @@ struct boot_mode {
void add_board_boot_modes(const struct boot_mode *p);
void boot_mode_apply(unsigned cfg_val);
extern const struct boot_mode soc_boot_modes[];
+
+/* boot devices */
+enum boot_device {
+ MX6_SD_BOOT,
+ MX6_MMC_BOOT,
+ MX6_NAND_BOOT,
+ MX6_SATA_BOOT,
+ MX6_WEIM_NOR_BOOT,
+ MX6_ONE_NAND_BOOT,
+ MX6_PATA_BOOT,
+ MX6_I2C_BOOT,
+ MX6_SPI_NOR_BOOT,
+ MX6_UNKNOWN_BOOT,
+ MX6_BOOT_DEV_NUM = MX6_UNKNOWN_BOOT,
+};
See my remark before.
ok
I hope to have a v2 posted soon.
Regards,
Tim
+enum boot_device get_boot_device(void);
+
#endif
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/11] MX6: provide linker script for SPL
On Mon, Apr 14, 2014 at 5:02 AM, Stefano Babic sba...@denx.de wrote: Hi Tim, snip This file is pretty identical to ./arch/arm/cpu/armv7/omap-common/u-boot-spl.lds. I understand that each SOC/arch could be a different set up, but I think we should introduce this diversity when it is needed, not as default. Maybe can we avoid to copy the file ? Stefano, Yes, I agree - the omap-common file will work for imx6 as well. I will use it and remove this patch. Regards, Tim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] PPC: 85xx: Remove IVOR reset
Am 17.04.2014 um 02:46 schrieb York Sun york...@freescale.com: On 04/11/2014 08:09 AM, Alexander Graf wrote: diff --git a/nand_spl/board/freescale/mpc8572ds/Makefile b/nand_spl/board/freescale/mpc8572ds/Makefile index c639b12..c58b7a4 100644 --- a/nand_spl/board/freescale/mpc8572ds/Makefile +++ b/nand_spl/board/freescale/mpc8572ds/Makefile @@ -78,11 +78,6 @@ $(obj)/resetvec.S: @rm -f $@ ln -s $(srctree)/$(CPUDIR)/resetvec.S $@ -$(obj)/fixed_ivor.S: -@rm -f $@ -ln -sf $(srctree)/arch/powerpc/cpu/mpc85xx/fixed_ivor.S $@ - -$(obj)/start.S: $(obj)/fixed_ivor.S @rm -f $@ ln -sf $(srctree)/arch/powerpc/cpu/mpc85xx/start.S $@ You forgot to add back $(obj)/start.S:. Don't send a new patch. I will fix it when I apply it. Oops :). Thanks a lot! Alex ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4] mpc85xx/t104x: Add deep sleep framework support
From: Tang Yuantian yuantian.t...@freescale.com
When T104x soc wakes 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.
Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
---
based on: git://git.denx.de/u-boot-mpc85xx.git
branch: next
tested on: t1040qds and t1040rdb platforms.
v4:
- refactor the framework. In the new patch, the entry is placed
just after DDRC's initialization when resume.
v3:
- fix out-of-tree compile warning
v2:
- added explaination for CONFIG_DEEP_SLEEP
- fixed some issues
README | 4 +++
arch/powerpc/cpu/mpc85xx/cpu_init.c | 8 ++
arch/powerpc/lib/board.c| 16
drivers/ddr/fsl/mpc85xx_ddr_gen3.c | 52 ++---
include/fsl_ddr_sdram.h | 4 +++
5 files changed, 80 insertions(+), 4 deletions(-)
diff --git a/README b/README
index 83a1b25..31e37cb 100644
--- a/README
+++ b/README
@@ -431,6 +431,10 @@ The following options need to be configured:
This CONFIG is defined when the CPC is configured as SRAM at the
time of U-boot entry and is required to be re-initialized.
+ CONFIG_DEEP_SLEEP
+ Inidcates this SoC supports deep sleep feature. If deep sleep is
+ supported, core will start to execute uboot when wakes up.
+
- Generic CPU options:
CONFIG_SYS_BIG_ENDIAN, CONFIG_SYS_LITTLE_ENDIAN
diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index 941c20e..867abb6 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -350,6 +350,7 @@ void cpu_init_f (void)
extern void m8560_cpm_reset (void);
#ifdef CONFIG_SYS_DCSRBAR_PHYS
ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
+ gd = (gd_t *)(CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_GBL_DATA_OFFSET);
#endif
#if defined(CONFIG_SECURE_BOOT)
struct law_entry law;
@@ -414,6 +415,13 @@ void cpu_init_f (void)
in_be32(gur-dcsrcr);
#endif
+#ifdef CONFIG_SYS_DCSRBAR_PHYS
+#ifdef CONFIG_DEEP_SLEEP
+ /* disable the console if boot from deep sleep */
+ if (in_be32(gur-scrtsr[0]) (1 3))
+ gd-flags |= GD_FLG_SILENT | GD_FLG_DISABLE_CONSOLE;
+#endif
+#endif
#ifdef CONFIG_SYS_FSL_ERRATUM_A007212
fsl_erratum_a007212_workaround();
#endif
diff --git a/arch/powerpc/lib/board.c b/arch/powerpc/lib/board.c
index f86c6f3..8b03d3a 100644
--- a/arch/powerpc/lib/board.c
+++ b/arch/powerpc/lib/board.c
@@ -343,6 +343,13 @@ void board_init_f(ulong bootflag)
#ifdef CONFIG_PRAM
ulong reg;
#endif
+#ifdef CONFIG_DEEP_SLEEP
+ const ccsr_gur_t *gur = (void __iomem *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
+ struct ccsr_scfg *scfg = (void *)CONFIG_SYS_MPC85xx_SCFG;
+ u32 start_addr;
+ typedef void (*func_t)(void);
+ func_t kernel_resume;
+#endif
/* Pointer is writable since we allocated a register for it */
gd = (gd_t *) (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_GBL_DATA_OFFSET);
@@ -360,6 +367,15 @@ void board_init_f(ulong bootflag)
if ((*init_fnc_ptr) () != 0)
hang();
+#ifdef CONFIG_DEEP_SLEEP
+ /* Jump to kernel in deep sleep case */
+ if (in_be32(gur-scrtsr[0]) (1 3)) {
+ start_addr = in_be32(scfg-sparecr[1]);
+ kernel_resume = (func_t)start_addr;
+ kernel_resume();
+ }
+#endif
+
#ifdef CONFIG_POST
post_bootmode_init();
post_run(NULL, POST_ROM | post_bootmode_get(NULL));
diff --git a/drivers/ddr/fsl/mpc85xx_ddr_gen3.c
b/drivers/ddr/fsl/mpc85xx_ddr_gen3.c
index c805086..4d5572e 100644
--- a/drivers/ddr/fsl/mpc85xx_ddr_gen3.c
+++ b/drivers/ddr/fsl/mpc85xx_ddr_gen3.c
@@ -15,6 +15,7 @@
#error Invalid setting for CONFIG_CHIP_SELECTS_PER_CTRL
#endif
+DECLARE_GLOBAL_DATA_PTR;
/*
* regs has the to-be-set values for DDR controller registers
@@ -43,6 +44,16 @@ void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t *regs,
u32 save1, save2;
#endif
+#ifdef CONFIG_DEEP_SLEEP
+ const ccsr_gur_t *gur = (void __iomem *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
+ bool sleep_flag = 0;
+#endif
+
+#ifdef CONFIG_DEEP_SLEEP
+ if (in_be32(gur-scrtsr[0]) (1 3))
+ sleep_flag = 1;
+#endif
+
switch (ctrl_num) {
case 0:
ddr = (void *)CONFIG_SYS_FSL_DDR_ADDR;
@@ -119,7 +130,13 @@ void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t
*regs,
out_be32(ddr-timing_cfg_0, regs-timing_cfg_0);
out_be32(ddr-timing_cfg_1, regs-timing_cfg_1);
out_be32(ddr-timing_cfg_2, regs-timing_cfg_2);
- out_be32(ddr-sdram_cfg_2, regs-ddr_sdram_cfg_2);
+#ifdef CONFIG_DEEP_SLEEP
+ if
[U-Boot] [PATCH 1/2] mpc85xx: Add deep sleep support on T1040QDS
From: Tang Yuantian yuantian.t...@freescale.com
Add deep sleep support on T1040QDS platform.
Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
---
board/freescale/t1040qds/t1040qds.c | 12
include/configs/T1040QDS.h | 4
2 files changed, 16 insertions(+)
diff --git a/board/freescale/t1040qds/t1040qds.c
b/board/freescale/t1040qds/t1040qds.c
index 3dec447..f1d7cde 100644
--- a/board/freescale/t1040qds/t1040qds.c
+++ b/board/freescale/t1040qds/t1040qds.c
@@ -18,6 +18,7 @@
#include asm/fsl_portals.h
#include asm/fsl_liodn.h
#include fm_eth.h
+#include asm/mpc85xx_gpio.h
#include ../common/qixis.h
#include t1040qds.h
@@ -245,3 +246,14 @@ int board_need_mem_reset(void)
{
return 1;
}
+
+#ifdef CONFIG_DEEP_SLEEP
+void board_mem_sleep_setup(void)
+{
+ /* does not provide HW signals for power management */
+ QIXIS_WRITE(pwr_ctl[1], (QIXIS_READ(pwr_ctl[1]) ~0x2));
+ /* Disable MCKE isolation */
+ gpio_set_value(2, 0);
+ udelay(1);
+}
+#endif
diff --git a/include/configs/T1040QDS.h b/include/configs/T1040QDS.h
index 030ea7e..745a2f2 100644
--- a/include/configs/T1040QDS.h
+++ b/include/configs/T1040QDS.h
@@ -43,6 +43,10 @@
#define CONFIG_SYS_BOOK3E_HV /* Category E.HV supported */
#define CONFIG_MP /* support multiple processors */
+/* support deep sleep */
+#define CONFIG_DEEP_SLEEP
+#define CONFIG_SILENT_CONSOLE
+
#ifndef CONFIG_SYS_TEXT_BASE
#define CONFIG_SYS_TEXT_BASE 0xeff4
#endif
--
1.8.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mpc85xx: Add deep sleep support on T104xRDB
From: Tang Yuantian yuantian.t...@freescale.com
Add deep sleep support on T104xRDB platforms.
Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
---
board/freescale/t104xrdb/t104xrdb.c | 10 ++
include/configs/T104xRDB.h | 4
2 files changed, 14 insertions(+)
diff --git a/board/freescale/t104xrdb/t104xrdb.c
b/board/freescale/t104xrdb/t104xrdb.c
index b48133a..fb5b849 100644
--- a/board/freescale/t104xrdb/t104xrdb.c
+++ b/board/freescale/t104xrdb/t104xrdb.c
@@ -17,6 +17,7 @@
#include asm/fsl_portals.h
#include asm/fsl_liodn.h
#include fm_eth.h
+#include asm/mpc85xx_gpio.h
#include t104xrdb.h
#include cpld.h
@@ -104,3 +105,12 @@ void ft_board_setup(void *blob, bd_t *bd)
fdt_fixup_fman_ethernet(blob);
#endif
}
+
+#ifdef CONFIG_DEEP_SLEEP
+void board_mem_sleep_setup(void)
+{
+ /* Disable MCKE isolation */
+ gpio_set_value(2, 0);
+ udelay(1);
+}
+#endif
diff --git a/include/configs/T104xRDB.h b/include/configs/T104xRDB.h
index eaaf37d..0159b97 100644
--- a/include/configs/T104xRDB.h
+++ b/include/configs/T104xRDB.h
@@ -25,6 +25,10 @@
#define CONFIG_SYS_BOOK3E_HV /* Category E.HV supported */
#define CONFIG_MP /* support multiple processors */
+/* support deep sleep */
+#define CONFIG_DEEP_SLEEP
+#define CONFIG_SILENT_CONSOLE
+
#ifndef CONFIG_SYS_TEXT_BASE
#define CONFIG_SYS_TEXT_BASE 0xeff4
#endif
--
1.8.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] usb: r8a66597: Fix initialization hub that using, R8A66597_MAX_ROOT_HUB
This driver is processed as two USB hub despite one. The number of root hub is defined in R8A66597_MAX_ROOT_HUB. This fixes that register is accessed by using the definition of R8A66597_MAX_ROOT_HUB. Signed-off-by: Yasuhisa Umano yasuhisa.umano...@renesas.com --- drivers/usb/host/r8a66597-hcd.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/r8a66597-hcd.c b/drivers/usb/host/r8a66597-hcd.c index dfe5423..c58d2a9 100644 --- a/drivers/usb/host/r8a66597-hcd.c +++ b/drivers/usb/host/r8a66597-hcd.c @@ -164,8 +164,8 @@ static int enable_controller(struct r8a66597 *r8a66597) r8a66597_bset(r8a66597, INTL, SOFCFG); r8a66597_write(r8a66597, 0, INTENB0); - r8a66597_write(r8a66597, 0, INTENB1); - r8a66597_write(r8a66597, 0, INTENB2); + for (port = 0; port R8A66597_MAX_ROOT_HUB; port++) + r8a66597_write(r8a66597, 0, get_intenb_reg(port)); r8a66597_bset(r8a66597, CONFIG_R8A66597_ENDIAN BIGEND, CFIFOSEL); r8a66597_bset(r8a66597, CONFIG_R8A66597_ENDIAN BIGEND, D0FIFOSEL); -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/5] net: rename and refactor eth_rand_ethaddr() function
Some functions in include/net.h are ported from
include/linux/etherdevice.h of Linux Kernel.
For ex.
is_zero_ether_addr()
is_multicast_ether_addr()
is_broadcast_ether_addr()
is_valid_ether_addr();
So, we should use the same function name as Linux Kernel,
eth_rand_addr(), for consistency.
Because eth_rand_addr() is impilemented as inline function,
it should not be surrounded by ifdef CONFIG_RANDOM_MACADDR.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---
board/buffalo/lsxl/lsxl.c | 2 +-
drivers/net/dm9000x.c | 2 +-
drivers/net/ftmac110.c| 2 +-
include/net.h | 36 +++-
net/eth.c | 22 --
5 files changed, 22 insertions(+), 42 deletions(-)
diff --git a/board/buffalo/lsxl/lsxl.c b/board/buffalo/lsxl/lsxl.c
index eca1683..659a124 100644
--- a/board/buffalo/lsxl/lsxl.c
+++ b/board/buffalo/lsxl/lsxl.c
@@ -231,7 +231,7 @@ static void rescue_mode(void)
printf(Entering rescue mode..\n);
#ifdef CONFIG_RANDOM_MACADDR
if (!eth_getenv_enetaddr(ethaddr, enetaddr)) {
- eth_random_enetaddr(enetaddr);
+ eth_random_addr(enetaddr);
if (eth_setenv_enetaddr(ethaddr, enetaddr)) {
printf(Failed to set ethernet address\n);
set_led(LED_ALARM_BLINKING);
diff --git a/drivers/net/dm9000x.c b/drivers/net/dm9000x.c
index b68d808..4de9d41 100644
--- a/drivers/net/dm9000x.c
+++ b/drivers/net/dm9000x.c
@@ -345,7 +345,7 @@ static int dm9000_init(struct eth_device *dev, bd_t *bd)
if (!is_valid_ether_addr(dev-enetaddr)) {
#ifdef CONFIG_RANDOM_MACADDR
printf(Bad MAC address (uninitialized EEPROM?),
randomizing\n);
- eth_random_enetaddr(dev-enetaddr);
+ eth_random_addr(dev-enetaddr);
printf(MAC: %pM\n, dev-enetaddr);
#else
printf(WARNING: Bad MAC address (uninitialized EEPROM?)\n);
diff --git a/drivers/net/ftmac110.c b/drivers/net/ftmac110.c
index 8eee272..98c4f09 100644
--- a/drivers/net/ftmac110.c
+++ b/drivers/net/ftmac110.c
@@ -425,7 +425,7 @@ int ftmac110_initialize(bd_t *bis)
dev-recv = ftmac110_recv;
if (!eth_getenv_enetaddr_by_index(eth, card_nr, dev-enetaddr))
- eth_random_enetaddr(dev-enetaddr);
+ eth_random_addr(dev-enetaddr);
/* allocate tx descriptors (it must be 16 bytes aligned) */
chip-txd = dma_alloc_coherent(
diff --git a/include/net.h b/include/net.h
index 0802fad..735b0b9 100644
--- a/include/net.h
+++ b/include/net.h
@@ -130,23 +130,6 @@ extern int eth_setenv_enetaddr(char *name, const uchar
*enetaddr);
extern int eth_getenv_enetaddr_by_index(const char *base_name, int index,
uchar *enetaddr);
-#ifdef CONFIG_RANDOM_MACADDR
-/*
- * The u-boot policy does not allow hardcoded ethernet addresses. Under the
- * following circumstances a random generated address is allowed:
- * - in emergency cases, where you need a working network connection to set
- *the ethernet address.
- *Eg. you want a rescue boot and don't have a serial port to access the
- *CLI to set environment variables.
- *
- * In these cases, we generate a random locally administered ethernet address.
- *
- * Args:
- * enetaddr - returns 6 byte hardware address
- */
-extern void eth_random_enetaddr(uchar *enetaddr);
-#endif
-
extern int usb_eth_initialize(bd_t *bi);
extern int eth_init(bd_t *bis);/* Initialize the
device */
extern int eth_send(void *packet, int length);/* Send a packet */
@@ -674,6 +657,25 @@ static inline int is_valid_ether_addr(const u8 *addr)
return !is_multicast_ether_addr(addr) !is_zero_ether_addr(addr);
}
+/**
+ * eth_random_addr - Generate software assigned random Ethernet address
+ * @addr: Pointer to a six-byte array containing the Ethernet address
+ *
+ * Generate a random Ethernet address (MAC) that is not multicast
+ * and has the local assigned bit set.
+ */
+static inline void eth_random_addr(uchar *addr)
+{
+ int i;
+ unsigned int seed = get_timer(0);
+
+ for (i = 0; i 6; i++)
+ addr[i] = rand_r(seed);
+
+ addr[0] = 0xfe;/* clear multicast bit */
+ addr[0] |= 0x02;/* set local assignment bit (IEEE802) */
+}
+
/* Convert an IP address to a string */
extern void ip_to_string(IPaddr_t x, char *s);
diff --git a/net/eth.c b/net/eth.c
index 32bd10c..99386e3 100644
--- a/net/eth.c
+++ b/net/eth.c
@@ -63,28 +63,6 @@ static int eth_mac_skip(int index)
return ((skip_state = getenv(enetvar)) != NULL);
}
-#ifdef CONFIG_RANDOM_MACADDR
-void eth_random_enetaddr(uchar *enetaddr)
-{
- uint32_t rval;
-
- srand(get_timer(0));
-
- rval = rand();
- enetaddr[0] = rval 0xff;
- enetaddr[1] = (rval 8) 0xff;
- enetaddr[2] = (rval 16) 0xff;
-
- rval = rand();
[U-Boot] [PATCH 4/5] fs: ubifs: drop __DATE__ and __TIME__
__DATE__ and __TIME__ should not be used anymore. Drop the debug message using them. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- fs/ubifs/super.c | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c index 67f115f..748ab67 100644 --- a/fs/ubifs/super.c +++ b/fs/ubifs/super.c @@ -734,7 +734,6 @@ static int mount_ubifs(struct ubifs_info *c) ubifs_msg(reserved for root: %llu bytes (%llu KiB), c-report_rp_size, c-report_rp_size 10); - dbg_msg(compiled on: __DATE__ at __TIME__); dbg_msg(min. I/O unit size: %d bytes, c-min_io_size); dbg_msg(LEB size:%d bytes (%d KiB), c-leb_size, c-leb_size 10); -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5] rand: do not surround function declarations by #ifdef
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- include/common.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/common.h b/include/common.h index cbd3c9e..49feac2 100644 --- a/include/common.h +++ b/include/common.h @@ -834,12 +834,10 @@ char *strmhz(char *buf, unsigned long hz); #include u-boot/crc.h /* lib/rand.c */ -#if defined(CONFIG_LIB_RAND) || defined(CONFIG_LIB_HW_RAND) #define RAND_MAX -1U void srand(unsigned int seed); unsigned int rand(void); unsigned int rand_r(unsigned int *seedp); -#endif /* common/console.c */ intconsole_init_f(void); /* Before relocation; uses the serial stuff */ -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/5] kbuild: build with -Werror=date-time if the compiler supports it
This commit has been imported from Linux Kernel: commit fe7c36c7bde12190341722af69358e42171162f3 Author: Josh Triplett j...@joshtriplett.org Date: Mon Dec 23 13:56:06 2013 -0800 Makefile: Build with -Werror=date-time if the compiler supports it GCC 4.9 and newer have a new warning -Wdate-time, which warns on any use of __DATE__, __TIME__, or __TIMESTAMP__, which would make the build non-deterministic. Now that the kernel does not use any of those macros, turn on -Werror=date-time if available, to keep it that way. The kernel already (optionally) records this information at build time in a single place; other kernel code should not duplicate that. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- Makefile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Makefile b/Makefile index 0191869..09a370f 100644 --- a/Makefile +++ b/Makefile @@ -578,6 +578,9 @@ KBUILD_AFLAGS += -Wa,-gstabs,-S endif endif +# Prohibit date/time macros, which would make the build non-deterministic +KBUILD_CFLAGS += $(call cc-option,-Werror=date-time) + ifneq ($(CONFIG_SYS_TEXT_BASE),) KBUILD_CPPFLAGS += -DCONFIG_SYS_TEXT_BASE=$(CONFIG_SYS_TEXT_BASE) endif -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/5] Do not use __DATE__ and __TIME__ anymore
The aim of this series is to prohibit using __DATE__ and __TIME__. Currently they are used in two files. [1] arch/blackfin/include/asm/net.h Blackfin is using __DATE__ as the seed for the random ethernet address. This feature will be replaced with genericly-used eth_random_addr(). [2] fs/ubifs/super.c __DATE__ and __TIME__ are used in dbg_msg(), so simply droppred. Masahiro Yamada (5): rand: do not surround function declarations by #ifdef net: rename and refactor eth_rand_ethaddr() function blackfin: replace bfin_gen_rand_mac() with eth_random_addr() fs: ubifs: drop __DATE__ and __TIME__ kbuild: build with -Werror=date-time if the compiler supports it Makefile | 3 +++ arch/blackfin/include/asm/net.h | 28 --- board/bct-brettl2/bct-brettl2.c | 3 +-- board/bf518f-ezbrd/bf518f-ezbrd.c | 3 +-- board/bf526-ezbrd/bf526-ezbrd.c | 3 +-- board/bf527-ezkit/bf527-ezkit.c | 3 +-- board/bf537-minotaur/bf537-minotaur.c | 3 +-- board/bf537-pnav/bf537-pnav.c | 3 +-- board/bf537-srv1/bf537-srv1.c | 3 +-- board/bf537-stamp/bf537-stamp.c | 3 +-- board/buffalo/lsxl/lsxl.c | 2 +- board/cm-bf527/cm-bf527.c | 3 +-- board/cm-bf537e/cm-bf537e.c | 3 +-- board/cm-bf537u/cm-bf537u.c | 3 +-- board/dnp5370/dnp5370.c | 3 +-- board/ip04/ip04.c | 3 +-- board/tcm-bf518/tcm-bf518.c | 3 +-- board/tcm-bf537/tcm-bf537.c | 3 +-- drivers/net/dm9000x.c | 2 +- drivers/net/ftmac110.c| 2 +- fs/ubifs/super.c | 1 - include/common.h | 2 -- include/configs/bct-brettl2.h | 1 + include/configs/bf518f-ezbrd.h| 2 +- include/configs/bf526-ezbrd.h | 2 +- include/configs/bf527-ezkit.h | 2 +- include/configs/bf537-minotaur.h | 1 + include/configs/bf537-pnav.h | 2 +- include/configs/bf537-srv1.h | 2 +- include/configs/bf537-stamp.h | 2 +- include/configs/cm-bf527.h| 2 +- include/configs/cm-bf537e.h | 2 +- include/configs/cm-bf537u.h | 2 +- include/configs/dnp5370.h | 2 ++ include/configs/ip04.h| 1 + include/configs/tcm-bf518.h | 2 +- include/configs/tcm-bf537.h | 2 +- include/net.h | 36 ++- net/eth.c | 22 - 39 files changed, 56 insertions(+), 114 deletions(-) delete mode 100644 arch/blackfin/include/asm/net.h -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5] blackfin: replace bfin_gen_rand_mac() with eth_random_addr()
bfin_gen_rand_mac() uses __DATE__ as the seed for random ethernet
address. This is not good.
In the first place, it should not be implemented as a Bfin-specific
function. Use eth_random_addr() instead.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
Cc: Sonic Zhang sonic.zh...@analog.com
---
arch/blackfin/include/asm/net.h | 28
board/bct-brettl2/bct-brettl2.c | 3 +--
board/bf518f-ezbrd/bf518f-ezbrd.c | 3 +--
board/bf526-ezbrd/bf526-ezbrd.c | 3 +--
board/bf527-ezkit/bf527-ezkit.c | 3 +--
board/bf537-minotaur/bf537-minotaur.c | 3 +--
board/bf537-pnav/bf537-pnav.c | 3 +--
board/bf537-srv1/bf537-srv1.c | 3 +--
board/bf537-stamp/bf537-stamp.c | 3 +--
board/cm-bf527/cm-bf527.c | 3 +--
board/cm-bf537e/cm-bf537e.c | 3 +--
board/cm-bf537u/cm-bf537u.c | 3 +--
board/dnp5370/dnp5370.c | 3 +--
board/ip04/ip04.c | 3 +--
board/tcm-bf518/tcm-bf518.c | 3 +--
board/tcm-bf537/tcm-bf537.c | 3 +--
include/configs/bct-brettl2.h | 1 +
include/configs/bf518f-ezbrd.h| 2 +-
include/configs/bf526-ezbrd.h | 2 +-
include/configs/bf527-ezkit.h | 2 +-
include/configs/bf537-minotaur.h | 1 +
include/configs/bf537-pnav.h | 2 +-
include/configs/bf537-srv1.h | 2 +-
include/configs/bf537-stamp.h | 2 +-
include/configs/cm-bf527.h| 2 +-
include/configs/cm-bf537e.h | 2 +-
include/configs/cm-bf537u.h | 2 +-
include/configs/dnp5370.h | 2 ++
include/configs/ip04.h| 1 +
include/configs/tcm-bf518.h | 2 +-
include/configs/tcm-bf537.h | 2 +-
31 files changed, 31 insertions(+), 69 deletions(-)
delete mode 100644 arch/blackfin/include/asm/net.h
diff --git a/arch/blackfin/include/asm/net.h b/arch/blackfin/include/asm/net.h
deleted file mode 100644
index 97cb466..000
--- a/arch/blackfin/include/asm/net.h
+++ /dev/null
@@ -1,28 +0,0 @@
-/*
- * net.h - misc Blackfin network helpers
- *
- * Copyright (c) 2008-2009 Analog Devices Inc.
- *
- * Licensed under the GPL-2 or later.
- */
-
-#ifndef __ASM_BFIN_RAND_MAC__
-#define __ASM_BFIN_RAND_MAC__
-
-/* If the board does not have a real MAC assigned to it, then generate a
- * locally administrated pseudo-random one based on CYCLES and compile date.
- */
-static inline void bfin_gen_rand_mac(uchar *mac_addr)
-{
- /* make something up */
- const char s[] = __DATE__;
- size_t i;
- u32 cycles;
- for (i = 0; i 6; ++i) {
- asm(%0 = CYCLES; : =r (cycles));
- mac_addr[i] = cycles ^ s[i];
- }
- mac_addr[0] = (mac_addr[0] | 0x02) ~0x01; /* make it local unicast */
-}
-
-#endif
diff --git a/board/bct-brettl2/bct-brettl2.c b/board/bct-brettl2/bct-brettl2.c
index de5b9ff..6be9b18 100644
--- a/board/bct-brettl2/bct-brettl2.c
+++ b/board/bct-brettl2/bct-brettl2.c
@@ -12,7 +12,6 @@
#include asm/blackfin.h
#include asm/portmux.h
#include asm/gpio.h
-#include asm/net.h
#include net.h
#include netdev.h
#include miiphy.h
@@ -33,7 +32,7 @@ int checkboard(void)
static void board_init_enetaddr(uchar *mac_addr)
{
puts(Warning: Generating 'random' MAC address\n);
- bfin_gen_rand_mac(mac_addr);
+ eth_random_addr(mac_addr);
eth_setenv_enetaddr(ethaddr, mac_addr);
}
diff --git a/board/bf518f-ezbrd/bf518f-ezbrd.c
b/board/bf518f-ezbrd/bf518f-ezbrd.c
index 09a2353..3a94a57 100644
--- a/board/bf518f-ezbrd/bf518f-ezbrd.c
+++ b/board/bf518f-ezbrd/bf518f-ezbrd.c
@@ -13,7 +13,6 @@
#include netdev.h
#include spi.h
#include asm/blackfin.h
-#include asm/net.h
#include asm/portmux.h
#include asm/mach-common/bits/otp.h
#include asm/sdh.h
@@ -48,7 +47,7 @@ static void board_init_enetaddr(uchar *mac_addr)
if (!valid_mac) {
puts(Warning: Generating 'random' MAC address\n);
- bfin_gen_rand_mac(mac_addr);
+ eth_random_addr(mac_addr);
}
eth_setenv_enetaddr(ethaddr, mac_addr);
diff --git a/board/bf526-ezbrd/bf526-ezbrd.c b/board/bf526-ezbrd/bf526-ezbrd.c
index 4695b11..368d6be 100644
--- a/board/bf526-ezbrd/bf526-ezbrd.c
+++ b/board/bf526-ezbrd/bf526-ezbrd.c
@@ -12,7 +12,6 @@
#include net.h
#include netdev.h
#include asm/blackfin.h
-#include asm/net.h
#include asm/mach-common/bits/otp.h
DECLARE_GLOBAL_DATA_PTR;
@@ -45,7 +44,7 @@ static void board_init_enetaddr(uchar *mac_addr)
if (!valid_mac) {
puts(Warning: Generating 'random' MAC address\n);
- bfin_gen_rand_mac(mac_addr);
+ eth_random_addr(mac_addr);
}
eth_setenv_enetaddr(ethaddr, mac_addr);
diff --git a/board/bf527-ezkit/bf527-ezkit.c b/board/bf527-ezkit/bf527-ezkit.c
index 211cf24..88e1869 100644
--- a/board/bf527-ezkit/bf527-ezkit.c
+++
Re: [U-Boot] [PATCH v3 0/5] ARM: refactor start.S files
Hi Gerhard, On Wed, 16 Apr 2014 23:57:11 +0200, Gerhard Sittig g...@denx.de wrote: On Tue, 2014-04-15 at 16:13 +0200, Albert ARIBAUD wrote: [ ... deeply nested 'git send-email' thread ... ] May I suggest the following git config option? [sendemail] chainreplyto = false This creates shallow threads, and improves consumption on the receivers' side, allowing to more quickly tell patches from review feedback, and better follow the series' structure. Just a thought, not picking at this specific submission, only following up when I saw one of those occurances (thus the list reply, too, for the archives) ... Thanks for th tip! Setting added on my ~/.gitconfig. virtually yours Gerhard Sittig Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] net: rename and refactor eth_rand_ethaddr() function
On Thu, Apr 17, 2014 at 3:00 AM, Masahiro Yamada yamad...@jp.panasonic.com wrote: Some functions in include/net.h are ported from include/linux/etherdevice.h of Linux Kernel. For ex. is_zero_ether_addr() is_multicast_ether_addr() is_broadcast_ether_addr() is_valid_ether_addr(); So, we should use the same function name as Linux Kernel, eth_rand_addr(), for consistency. Because eth_rand_addr() is impilemented as inline function, it should not be surrounded by ifdef CONFIG_RANDOM_MACADDR. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Acked-by: Joe Hershberger joe.hershber...@ni.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] e1000: remove redundant assignment
On Wed, Apr 16, 2014 at 6:15 AM, David Müller d.muel...@elsoft.ch wrote: Signed-off-by: David Mueller d.muel...@elsoft.ch Joe Hershberger joe.hershber...@gmail.com Acked-by: Joe Hershberger joe.hershber...@ni.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] usb: r8a66597: Fix initilization size of r8a66597 info, structure
Initialization of r8a66597 info structure is not enough. Because initilization was used size of pointer. This fixes that use size of r8a6659 info structure. Signed-off-by: Yasuhisa Umano yasuhisa.umano...@renesas.com --- drivers/usb/host/r8a66597-hcd.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/r8a66597-hcd.c b/drivers/usb/host/r8a66597-hcd.c index c58d2a9..8e82212 100644 --- a/drivers/usb/host/r8a66597-hcd.c +++ b/drivers/usb/host/r8a66597-hcd.c @@ -807,7 +807,7 @@ int usb_lowlevel_init(int index, enum usb_init_type init, void **controller) R8A66597_DPRINT(%s\n, __func__); - memset(r8a66597, 0, sizeof(r8a66597)); + memset(r8a66597, 0, sizeof(struct r8a66597)); r8a66597-reg = CONFIG_R8A66597_BASE_ADDR; disable_controller(r8a66597); -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/13] ARMv7: add PSCI support to u-boot
Hi Marc, On Wed, 16 Apr 2014 17:09:07 +0100, Marc Zyngier marc.zyng...@arm.com wrote: On 16/04/14 15:45, Albert ARIBAUD wrote: Hi Marc, On Sat, 15 Feb 2014 13:36:24 +, Marc Zyngier marc.zyngier-5wv7dgni...@public.gmane.org wrote: PSCI is an ARM standard that provides a generic interface that supervisory software can use to manage power in the following situations: - Core idle management - CPU hotplug - big.LITTLE migration models - System shutdown and reset It basically allows the kernel to offload these tasks to the firmware, and rely on common kernel side code. More importantly, it gives a way to ensure that CPUs enter the kernel at the appropriate exception level (ie HYP mode, to allow the use of the virtualization extensions), even across events like CPUs being powered off/on or suspended. The main idea here is to turn some of the existing u-boot code into a separate section that can live in secure RAM (or a reserved page of memory), containing a secure monitor that will implement the PSCI operations. This code will still be alive when u-boot is long gone, hence the need for a piece of memory that will not be touched by the OS. This patch series contains 4 parts: - the first four patches are just bug fixes - the next two refactor the HYP/non-secure code to allow relocation in secure memory - the next four contain the generic PSCI code and DT infrastructure - the last three implement the CPU_ON method of the Allwinner A20 (aka sun7i). I realize the A20 u-boot code is not upstream yet (BTW is anyone actively working on that?), but hopefully that should give a good idea of how things are structured so far. The patches are against the mainline u-boot tree as of today, merged with the sunxi u-boot tree of the day and the first 10 patches will directly apply to mainline u-boot. As for using this code, it goes like this: sun7i# ext2load mmc 0:1 0x40008000 zImage ; ext2load mmc 0:1 0x6000 sun7i-a20-cubietruck.dtb 2270120 bytes read in 117 ms (18.5 MiB/s) 9138 bytes read in 3 ms (2.9 MiB/s) sun7i# fdt addr 0x6000 ; fdt resize ; fdt set ethernet0 mac-address [5a fe b0 07 b0 07] sun7i# setenv bootargs console=ttyS0,115200 earlyprintk ip=dhcp root=/dev/nfs nfsroot=/backup/a20_root,tcp sun7i# bootz 0x40008000 - 0x6000 The kernel now boots in HYP mode, finds its secondary CPU without any SMP code present in the kernel, and runs KVM out of the box. I've been told the Xen/ARM guys managed to do the same fairly easily. This code has also been tested on a VExpress TC2, running KVM with all 5 CPUs, in order to make sure there was no obvious regression. I'm wildly cross-posting this patch series, including to lists I'm not subscribed to. Please keep me on Cc for any comment you may have. The code is also available at: git://git.kernel.org/pub/scm/linux/kernel/git/maz/u-boot.git wip/psci Cheers, M. Marc, I'm unclear what you want to do with this series. You mention that its first 10 patches will apply to U-Boot, but I am not sure whether you are just indicating that it is possible to apply them or asking for these 10 patches to go in U-Boot mainline. Or is it something else yet? Well, I rarely write code just for the sake of forking a critical project ;-) So let's be 100% explicit: Yes, I'm hereby asking for these patches to be merged. They offer a service that is required by the Linux kernel as well as Xen. They are in active use on the Allwinner sun7i platform as well as Versatile Express (though the later doesn't have a PSCI implementation). Now, given that two months have gone past without much comment other than the odd hey, works great, I don't really know where to take that. Are you willing to review the patches? Well, I rarely ask about patches just for the sake of conversation. O:-) So yes, I am willing to review them -- and I suspect others are, as well. Nobody commented the V3 series on the U-Boot list -- save for Jon's comment about the series needing a rebase -- which could mean no one here is unhappy with them... or they were discussed and possibly acted upon on linux-sunxi, where the replies were redirected. I don't follow linux-sunx closely, so I couldn't tell. :) Still, I am trying to figure out the whole Allwinner nebula and see how things are supposed to work out between their various SoCs and make sure to avoid duplicate/incompatible effort (you're mentioning the A20, there seems to be A31 work underway too elsewhere). I am starting to wonder whether an ARM allwinner sub-repo might make sense. Tom, Wolfgang? Thanks, M. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: make imxheader size align on page size
Hi Stefan, On 16/04/2014 15:36, Stefan Agner wrote: Can you better explain this ? There is only one board in mainline with vf610. CONFIG_SYS_TEXT_BASE is set to 0x3f008000. I cannot get the offset in your example. Are you referring to NAND page ? But if the header must be aligned with the NAND page, this is pretty bad because we have to adjust the header depending on the selected NAND chip. I do not see this limitation in the manual. I've not submitted my board yet, I altered it to use 0x3f400800 as CONFIG_SYS_TEXT_BASE. I just realize that a header length of 0x7fc doesn't fit with 0x3f400404 even though (that would be 0x3f44 if anything). But the mkimage utility reports Load Address: 3f400420 Entry Point: 3f400800 I'm a bit confused now, why is the header only 0x400 now? Ok I checked this again, the header total size is _not_ 0x7fc, thats imximage_init_loadsize, which is the header size + flash load size (0x400 for NAND). The header total size is 0x3fc (sizeof(imx_header_v2_t)) right now. This patch would make alter it to be exactly 0x400. This renforces my suspect. Making the image bigger, it seems that the SOC loads more data as before. However, reading in the manual, the initial load image (what the SOC should load initially) is 4K (Table 19.37), and adding 4 bytes should have no influence. In case this discussion ends up adding this padding word, I will send a new patch with correct numbers and better description. It is not clear what is the cause of the issue and then which is the solution. Adding the pad at the moment seems only a work-around for you. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/13] ARMv7: add PSCI support to u-boot
On Thu, Apr 17 2014 at 9:34:24 am BST, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Marc, On Wed, 16 Apr 2014 17:09:07 +0100, Marc Zyngier marc.zyng...@arm.com wrote: On 16/04/14 15:45, Albert ARIBAUD wrote: Hi Marc, On Sat, 15 Feb 2014 13:36:24 +, Marc Zyngier marc.zyngier-5wv7dgni...@public.gmane.org wrote: PSCI is an ARM standard that provides a generic interface that supervisory software can use to manage power in the following situations: - Core idle management - CPU hotplug - big.LITTLE migration models - System shutdown and reset It basically allows the kernel to offload these tasks to the firmware, and rely on common kernel side code. More importantly, it gives a way to ensure that CPUs enter the kernel at the appropriate exception level (ie HYP mode, to allow the use of the virtualization extensions), even across events like CPUs being powered off/on or suspended. The main idea here is to turn some of the existing u-boot code into a separate section that can live in secure RAM (or a reserved page of memory), containing a secure monitor that will implement the PSCI operations. This code will still be alive when u-boot is long gone, hence the need for a piece of memory that will not be touched by the OS. This patch series contains 4 parts: - the first four patches are just bug fixes - the next two refactor the HYP/non-secure code to allow relocation in secure memory - the next four contain the generic PSCI code and DT infrastructure - the last three implement the CPU_ON method of the Allwinner A20 (aka sun7i). I realize the A20 u-boot code is not upstream yet (BTW is anyone actively working on that?), but hopefully that should give a good idea of how things are structured so far. The patches are against the mainline u-boot tree as of today, merged with the sunxi u-boot tree of the day and the first 10 patches will directly apply to mainline u-boot. As for using this code, it goes like this: sun7i# ext2load mmc 0:1 0x40008000 zImage ; ext2load mmc 0:1 0x6000 sun7i-a20-cubietruck.dtb 2270120 bytes read in 117 ms (18.5 MiB/s) 9138 bytes read in 3 ms (2.9 MiB/s) sun7i# fdt addr 0x6000 ; fdt resize ; fdt set ethernet0 mac-address [5a fe b0 07 b0 07] sun7i# setenv bootargs console=ttyS0,115200 earlyprintk ip=dhcp root=/dev/nfs nfsroot=/backup/a20_root,tcp sun7i# bootz 0x40008000 - 0x6000 The kernel now boots in HYP mode, finds its secondary CPU without any SMP code present in the kernel, and runs KVM out of the box. I've been told the Xen/ARM guys managed to do the same fairly easily. This code has also been tested on a VExpress TC2, running KVM with all 5 CPUs, in order to make sure there was no obvious regression. I'm wildly cross-posting this patch series, including to lists I'm not subscribed to. Please keep me on Cc for any comment you may have. The code is also available at: git://git.kernel.org/pub/scm/linux/kernel/git/maz/u-boot.git wip/psci Cheers, M. Marc, I'm unclear what you want to do with this series. You mention that its first 10 patches will apply to U-Boot, but I am not sure whether you are just indicating that it is possible to apply them or asking for these 10 patches to go in U-Boot mainline. Or is it something else yet? Well, I rarely write code just for the sake of forking a critical project ;-) So let's be 100% explicit: Yes, I'm hereby asking for these patches to be merged. They offer a service that is required by the Linux kernel as well as Xen. They are in active use on the Allwinner sun7i platform as well as Versatile Express (though the later doesn't have a PSCI implementation). Now, given that two months have gone past without much comment other than the odd hey, works great, I don't really know where to take that. Are you willing to review the patches? Well, I rarely ask about patches just for the sake of conversation. O:-) So yes, I am willing to review them -- and I suspect others are, as well. Nobody commented the V3 series on the U-Boot list -- save for Jon's comment about the series needing a rebase -- which could mean no one here is unhappy with them... or they were discussed and possibly acted upon on linux-sunxi, where the replies were redirected. I don't follow linux-sunx closely, so I couldn't tell. :) No, so far there hasn't been much discussion, and people seem happy with it. I have a couple of fixes lined up, but nothing major. Also, a number of the patches are actually fixes that should really make it into the U-Boot tree, no matter if the PSCI code is merged or not. Some of them make the kernel go completely bonkers, other introduce the risk of U-Boot falling over in style. Still, I am trying to figure out the whole Allwinner nebula and see how things are supposed to work out between their various SoCs and make sure to avoid
Re: [U-Boot] [PATCH 05/11] MX6: add boot device support SPL
Hi Tim,
On 17/04/2014 08:16, Tim Harvey wrote:
+ boot_dev = MX6_SATA_BOOT;
+ break;
+ /* Serial ROM: See 8.5.5.1, Table 8-22 */
+ case 0x3:
+ /* BOOT_CFG4[2:0] */
+ switch ((soc_sbmr 0x0700) 24) {
+ case 0x0 ... 0x4:
+ boot_dev = MX6_SPI_NOR_BOOT;
+ break;
+ case 0x5 ... 0x7:
+ boot_dev = MX6_I2C_BOOT;
+ break;
+ }
+ break;
+ /* SD/eSD: 8.5.3, Table 8-15 */
+ case 0x4:
+ case 0x5:
+ boot_dev = MX6_SD_BOOT;
+ break;
+ /* MMC/eMMC: 8.5.3 */
+ case 0x6:
+ case 0x7:
+ boot_dev = MX6_MMC_BOOT;
+ break;
+ /* NAND Flash: 8.5.2 */
+ case 0x8 ... 0xf:
+ boot_dev = MX6_NAND_BOOT;
+ break;
+ default:
+ boot_dev = MX6_UNKNOWN_BOOT;
+ break;
+ }
+
The function can be used as well for MX5 SOCs. Move it into imx-common,
and use constants without SOC names. Instead of MX6_NAND_BOOT,
IMX_NAND_BOOT (or whatever you find makes sense..)
Are you saying the i.MX5's have the same register and meaning? I
figured the sbmr is different.
The register is the same, and mostly with the same meaning. You do not
need to care about it. Just put it into imx-common, and when someone
will add support for MX5, this function will be analyzed and modified
instead of adding a new one.
+ return boot_dev;
+}
+
+
void s_init(void)
{
struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
diff --git a/arch/arm/include/asm/arch-mx6/spl.h
b/arch/arm/include/asm/arch-mx6/spl.h
new file mode 100644
index 000..5611c71
--- /dev/null
+++ b/arch/arm/include/asm/arch-mx6/spl.h
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2013 TechNexion Ltd.
+ *
+ * Author: Richard Hu linux...@technexion.com
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#ifndef __ASM_ARCH_SPL_H__
+#define __ASM_ARCH_SPL_H__
+
+#define BOOT_DEVICE_MMC1 0
+#define BOOT_DEVICE_MMC2 1
+#define BOOT_DEVICE_MMC2_2 2
+#define BOOT_DEVICE_NAND 3
+#define BOOT_DEVICE_SATA 4
+#define BOOT_DEVICE_USBETH 5
+#define BOOT_DEVICE_NONE 6
+
They are only defines and are not yet related to i.MX6 anymnore, because
you have already mapped them. What about to move this defines into
imx-common ?
ok
Masahiro has sent this week a patch to consolidate names, that are
duplicated for all architecture:
http://patchwork.ozlabs.org/patch/339438/
I think it is a very good idea to follow his approach.
I hope to have a v2 posted soon.
Please only wait until I send my remark regarding the patches with pinmux.
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: Handle switch error status bit in MMC card status
Hi Pantelis, From: Gabbasov, Andrew Sent: Thursday, April 03, 2014 13:32 To: Pantelis Antoniou Cc: u-boot@lists.denx.de Subject: RE: [U-Boot] [PATCH] mmc: Handle switch error status bit in MMC card status Hi Pantelis, From: Pantelis Antoniou [pa...@antoniou-consulting.com] Sent: Wednesday, April 02, 2014 14:14 To: Gabbasov, Andrew Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] mmc: Handle switch error status bit in MMC card status Hi Andrew, In general looks good; only a small nag. On Mar 24, 2014, at 9:39 AM, Andrew Gabbasov wrote: MMC switch command for unsupported feature (e.g. bus width) sets a switch error bit in card status. This bit should be checked, and, if it's set, no access with new controller settings should be performed. [ skipped ] @@ -505,7 +507,7 @@ static int mmc_change_freq(struct mmc *mmc) err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_HS_TIMING, 1); if (err) - return err; + return ((err == SWITCH_ERR) ? 0 : err); Change to: return err == SWITCH_ERR ? 0 : err; No need for parentheses. Thank you for the review. I'm sending a v2 patch with his change and also re-based to current master head. Did you have a chance to look at the v2 patch (sent separately)? WIll you Ack it? Thanks! Best regards, Andrew ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/11] MX6: add struct for sharing data between SPL and uboot
Hi Tim, On 17/04/2014 08:07, Tim Harvey wrote: On Mon, Apr 14, 2014 at 5:35 AM, Stefano Babic sba...@denx.de wrote: Hi Tim, I see checking your patch that the MXS uses the same concept. And as far as I can see, boot_mode_idx is used only to print the boot devioce Stefano, yes, that is where I got the concept from. Well, it slipped into mainline, but adding such a structure only to have a better print is not very useful... I've been told this before, but I've found that get_ram_size() will hang on an i.MX6 if you pass it a maxsize larger than the memory in your system. Perhaps you can verify you see the same behavior? get_ram_size() works if the memory is accessible, that means that no exception is generated when it tries to access. If the RAM controller is programmed for a larger amount of memory, because you can have board with different capacity of RAM, get_ram_size() finds dynamically the soldered value. However, if the RAM controller is programmed for an amount of RAM smaller as what get_ram_size() tries to identify, an exception is raised. In get_ram_size(start, size) we pass the maximum amount of memory that the function is allowed to check. I can imagine we are running in this case. Checking on i.MX6, we have both boards checking the size with get_ram_size() as mx6sabresd, as well as boards fixing at compile time the value of the RAM (nitrogen6x). SPL is thought to generally load an image (of course, in most cases it is u-boot). In Falcon mode, the kernel is started without running u-boot, making this structure useless. Do we really need such a way (but then, it must be generalized as SPL API), or can we get rid of it ? As we have an EEPROM on the board that tells us the physical ram size, I use that to avoid the lockup. It seems weird. There is several boards in mainline (I am sure about Freescale's PowerPC) discovering the mounted RAM. Of course, this is simpler if many parameters (row/columns/...) are the same, I am not sure about this. Are we sure it is not possible here ? What does it happen with an inconsistent value in EEprom ? Eventually I would like to read and validate the entire EEPROM once in SPL and pass this to u-boot.img to avoid reading and validating it again. I think this is a good example of why sharing data between SPL and u-boot.img could be useful. I am not sure, and I doubt it is a good idea to use persistent data to store that. It is potentially dangerous, and if some reasons the EEprom is changed, the board could not boot at all. On the other side, I like the current concept that the SPL is simply a loader and can load images of different types, and fixing an API between SPL and U-Boot goes against this concept. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/13] ARMv7: add PSCI support to u-boot
Hi Marc, On Thu, 17 Apr 2014 09:58:19 +0100, Marc Zyngier marc.zyng...@arm.com wrote: On Thu, Apr 17 2014 at 9:34:24 am BST, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Marc, On Wed, 16 Apr 2014 17:09:07 +0100, Marc Zyngier marc.zyng...@arm.com wrote: On 16/04/14 15:45, Albert ARIBAUD wrote: Hi Marc, On Sat, 15 Feb 2014 13:36:24 +, Marc Zyngier marc.zyngier-5wv7dgni...@public.gmane.org wrote: PSCI is an ARM standard that provides a generic interface that supervisory software can use to manage power in the following situations: - Core idle management - CPU hotplug - big.LITTLE migration models - System shutdown and reset It basically allows the kernel to offload these tasks to the firmware, and rely on common kernel side code. More importantly, it gives a way to ensure that CPUs enter the kernel at the appropriate exception level (ie HYP mode, to allow the use of the virtualization extensions), even across events like CPUs being powered off/on or suspended. The main idea here is to turn some of the existing u-boot code into a separate section that can live in secure RAM (or a reserved page of memory), containing a secure monitor that will implement the PSCI operations. This code will still be alive when u-boot is long gone, hence the need for a piece of memory that will not be touched by the OS. This patch series contains 4 parts: - the first four patches are just bug fixes - the next two refactor the HYP/non-secure code to allow relocation in secure memory - the next four contain the generic PSCI code and DT infrastructure - the last three implement the CPU_ON method of the Allwinner A20 (aka sun7i). I realize the A20 u-boot code is not upstream yet (BTW is anyone actively working on that?), but hopefully that should give a good idea of how things are structured so far. The patches are against the mainline u-boot tree as of today, merged with the sunxi u-boot tree of the day and the first 10 patches will directly apply to mainline u-boot. As for using this code, it goes like this: sun7i# ext2load mmc 0:1 0x40008000 zImage ; ext2load mmc 0:1 0x6000 sun7i-a20-cubietruck.dtb 2270120 bytes read in 117 ms (18.5 MiB/s) 9138 bytes read in 3 ms (2.9 MiB/s) sun7i# fdt addr 0x6000 ; fdt resize ; fdt set ethernet0 mac-address [5a fe b0 07 b0 07] sun7i# setenv bootargs console=ttyS0,115200 earlyprintk ip=dhcp root=/dev/nfs nfsroot=/backup/a20_root,tcp sun7i# bootz 0x40008000 - 0x6000 The kernel now boots in HYP mode, finds its secondary CPU without any SMP code present in the kernel, and runs KVM out of the box. I've been told the Xen/ARM guys managed to do the same fairly easily. This code has also been tested on a VExpress TC2, running KVM with all 5 CPUs, in order to make sure there was no obvious regression. I'm wildly cross-posting this patch series, including to lists I'm not subscribed to. Please keep me on Cc for any comment you may have. The code is also available at: git://git.kernel.org/pub/scm/linux/kernel/git/maz/u-boot.git wip/psci Cheers, M. Marc, I'm unclear what you want to do with this series. You mention that its first 10 patches will apply to U-Boot, but I am not sure whether you are just indicating that it is possible to apply them or asking for these 10 patches to go in U-Boot mainline. Or is it something else yet? Well, I rarely write code just for the sake of forking a critical project ;-) So let's be 100% explicit: Yes, I'm hereby asking for these patches to be merged. They offer a service that is required by the Linux kernel as well as Xen. They are in active use on the Allwinner sun7i platform as well as Versatile Express (though the later doesn't have a PSCI implementation). Now, given that two months have gone past without much comment other than the odd hey, works great, I don't really know where to take that. Are you willing to review the patches? Well, I rarely ask about patches just for the sake of conversation. O:-) So yes, I am willing to review them -- and I suspect others are, as well. Nobody commented the V3 series on the U-Boot list -- save for Jon's comment about the series needing a rebase -- which could mean no one here is unhappy with them... or they were discussed and possibly acted upon on linux-sunxi, where the replies were redirected. I don't follow linux-sunx closely, so I couldn't tell. :) No, so far there hasn't been much discussion, and people seem happy with it. I have a couple of fixes lined up, but nothing major. Also, a number of the patches are actually fixes that should really make it into the U-Boot tree, no matter if the PSCI code is merged or not. Some of them make the kernel go completely bonkers, other introduce the
Re: [U-Boot] [PATCH v4] arm: ep9315: Return back Cirrus Logic EDB9315A board support
Hi Sergey,
On Thu, 6 Mar 2014 21:20:20 +0400, Sergey Kostanbaev
sergey.kostanb...@gmail.com wrote:
diff --git a/arch/arm/cpu/arm920t/ep93xx/lowlevel_init.S
b/arch/arm/cpu/arm920t/ep93xx/lowlevel_init.S
index bf2fa2a..3ac0f88 100644
--- a/arch/arm/cpu/arm920t/ep93xx/lowlevel_init.S
+++ b/arch/arm/cpu/arm920t/ep93xx/lowlevel_init.S
@@ -1,49 +1,456 @@
/*
* Low-level initialization for EP93xx
*
- * Copyright (C) 2009 Matthias Kaehlcke matth...@kaehlcke.net
+ * Copyright (C) 2013
+ * Sergey Kostanabev sergey.kostanbaev at fairwaves.ru
*
- * Copyright (C) 2006 Dominic Rath dominic.r...@gmx.de
+ * Copyright (C) 2006 Cirrus Logic Inc.
Why do you remove existing copyright attributions?
[...]
+ * Determine the size of the SDRAM. Use data=address for the scan.
+
+ * Input:r0 - Start SDRAM address
+ * Return: r0 - Single block size
+ * r1 - Valid block mask
+ * r2 - Total block count
+ * Modifies: r0-r5
+ */
+ep93xx_sdram_size:
Is this needed? Can't the general get_ram_size() function be used?
diff --git a/arch/arm/include/asm/arch-ep93xx/ep93xx.h
b/arch/arm/include/asm/arch-ep93xx/ep93xx.h
index 9e7f2f3..71aa601 100644
--- a/arch/arm/include/asm/arch-ep93xx/ep93xx.h
+++ b/arch/arm/include/asm/arch-ep93xx/ep93xx.h
@@ -580,3 +658,11 @@ struct syscon_regs {
/*
* 0x8095 - 0x9000: Reserved
*/
+
+/*
+ * During low_level init we store memory layout in memory at specific
location
+ */
+#define UBOOT_MEMORYCNF_BANK_SIZE0x2000
+#define UBOOT_MEMORYCNF_BANK_MASK0x2004
+#define UBOOT_MEMORYCNF_BANK_COUNT 0x2008
+
Remove blank line at EOF.
diff --git a/board/cirrus/edb93xx/u-boot.lds b/board/cirrus/edb93xx/u-boot.lds
Does this board need a specific .lds file?
[...]
+ /DISCARD/ : { *(.dynsym) }
+ /DISCARD/ : { *(.dynstr*) }
+ /DISCARD/ : { *(.dynamic*) }
+ /DISCARD/ : { *(.plt*) }
+ /DISCARD/ : { *(.interp*) }
+ /DISCARD/ : { *(.gnu*) }
We don't /DISCARD/ these sections any more. If for some reason the
generic .lds fils cannot be used, then adapt this one to current
practice.
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] Is there generic code to detect nand chip's ecc bits?
Hi, Scott: I have a question about nand chip's ecc bits: Nand chip usually declared its ecc bits for each 512 bytes in its data sheet. Such as: Some nand chips required 4bit ECC for each 512 bytes. Some nand chips required 2bit ECC for each 512 bytes. So, my question is: Could ecc bits be got from nand chip's flash id? Or other generic method to retrieve ECC bits required for every nand chip? Best wishes, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/13] ARMv7: add PSCI support to u-boot
On Thu, 2014-04-17 at 09:58 +0100, Marc Zyngier wrote: Ian Campbell (cc-ed) is actively pushing out patches to support the A20 in mainline U-Boot (I believe you've been on the receiving end of these), Need to make a few more cleanups based on the review but v$NEXT should be along soon. and I plan to rebase my series on top of his. In fact I was banking on it and have deliberately left SMP support out of the upstreaming series. Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] Do not use __DATE__ and __TIME__ anymore
Dear Masahiro, In message 1397721632-18797-1-git-send-email-yamad...@jp.panasonic.com you wrote: The aim of this series is to prohibit using __DATE__ and __TIME__. What is bad about using these? 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 It is easier to change the specification to fit the program than vice versa. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] net: rename and refactor eth_rand_ethaddr() function
Dear Masahiro, In message 1397721632-18797-3-git-send-email-yamad...@jp.panasonic.com you wrote: Some functions in include/net.h are ported from include/linux/etherdevice.h of Linux Kernel. For ex. is_zero_ether_addr() is_multicast_ether_addr() is_broadcast_ether_addr() is_valid_ether_addr(); So, we should use the same function name as Linux Kernel, eth_rand_addr(), for consistency. Because eth_rand_addr() is impilemented as inline function, it should not be surrounded by ifdef CONFIG_RANDOM_MACADDR. None of this is mentioned in the description of this patch series in your cover letter. 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 It is common sense to take a method and try it. If it fails, admit it frankly and try another. But above all, try something. - Franklin D. Roosevelt ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] usb: r8a66597: Fix initialization hub that using, R8A66597_MAX_ROOT_HUB
On Thursday, April 17, 2014 at 09:48:32 AM, yasuhisa umano wrote: This driver is processed as two USB hub despite one. The number of root hub is defined in R8A66597_MAX_ROOT_HUB. This fixes that register is accessed by using the definition of R8A66597_MAX_ROOT_HUB. Signed-off-by: Yasuhisa Umano yasuhisa.umano...@renesas.com Is there any reason why those two patches were sent twice please ? They seem the same in both cases. Otherwise, I'm fine with those patches. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] Do not use __DATE__ and __TIME__ anymore
Hi Wolfgang On Thu, 17 Apr 2014 13:07:32 +0200 Wolfgang Denk w...@denx.de wrote: Dear Masahiro, In message 1397721632-18797-1-git-send-email-yamad...@jp.panasonic.com you wrote: The aim of this series is to prohibit using __DATE__ and __TIME__. What is bad about using these? include/generated/timestamp_autogenerated.h provides us the last build date correctly because it is touched every time. __DATE__ or __TIME__ might give us unexpectedly old date because it is not updated unless the source file is modified. One more reason. Using __DATE__ / __TIME__ here and there makes the binary comparison difficult. I often use MD5SUM comparison to confirm that my changes to the build system still produce the same output. I want to generate the completely same result if the source code is the same. This can be achieved by simply disabling the timestamp file and version file. I want to gather timestamp stuff to one place for easy control of it. 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 06/11] MX6: add struct for sharing data between SPL and uboot
Hi Igor, hi Tim On 17/04/2014 13:22, Igor Grinberg wrote: get_ram_size() works on cm-fx6 all DRAM configurations. As on most boards in mainline ;-) SPL is thought to generally load an image (of course, in most cases it is u-boot). In Falcon mode, the kernel is started without running u-boot, making this structure useless. Do we really need such a way (but then, it must be generalized as SPL API), or can we get rid of it ? As we have an EEPROM on the board that tells us the physical ram size, I use that to avoid the lockup. It seems weird. There is several boards in mainline (I am sure about Freescale's PowerPC) discovering the mounted RAM. Of course, this is simpler if many parameters (row/columns/...) are the same, I am not sure about this. Even if the parameters are different, this should not result in lockup... AFAICS, lockup of that type has nothing to do with the DRAM itself, but the controller configuration. Exactly, this is what I meant. Thanks for clarifying it better. Are we sure it is not possible here ? What does it happen with an inconsistent value in EEprom ? Eventually I would like to read and validate the entire EEPROM once in SPL and pass this to u-boot.img to avoid reading and validating it again. I think this is a good example of why sharing data between SPL and u-boot.img could be useful. I am not sure, and I doubt it is a good idea to use persistent data to store that. It is potentially dangerous, and if some reasons the EEprom is changed, the board could not boot at all. This is more a question of design and definition of what purpose the eeprom should serve, so I would let the vendor decide if he wants to depend on eeprom or not. Agree. Parsing and evaluating vendor specific information can be done inside board specific part, as now in read_eeprom inside gw_ventana.c. Anyway, if there is a way to detect at runtime the hardware configuration, it remains a better way as to store the size into the Eeprom. Best regards, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/11] MX6: add struct for sharing data between SPL and uboot
Hi Stefano, Tim, On 04/17/14 12:30, Stefano Babic wrote: Hi Tim, On 17/04/2014 08:07, Tim Harvey wrote: On Mon, Apr 14, 2014 at 5:35 AM, Stefano Babic sba...@denx.de wrote: Hi Tim, I see checking your patch that the MXS uses the same concept. And as far as I can see, boot_mode_idx is used only to print the boot devioce Stefano, yes, that is where I got the concept from. Well, it slipped into mainline, but adding such a structure only to have a better print is not very useful... I've been told this before, but I've found that get_ram_size() will hang on an i.MX6 if you pass it a maxsize larger than the memory in your system. Perhaps you can verify you see the same behavior? get_ram_size() works if the memory is accessible, that means that no exception is generated when it tries to access. If the RAM controller is programmed for a larger amount of memory, because you can have board with different capacity of RAM, get_ram_size() finds dynamically the soldered value. However, if the RAM controller is programmed for an amount of RAM smaller as what get_ram_size() tries to identify, an exception is raised. In get_ram_size(start, size) we pass the maximum amount of memory that the function is allowed to check. I can imagine we are running in this case. Checking on i.MX6, we have both boards checking the size with get_ram_size() as mx6sabresd, as well as boards fixing at compile time the value of the RAM (nitrogen6x). get_ram_size() works on cm-fx6 all DRAM configurations. SPL is thought to generally load an image (of course, in most cases it is u-boot). In Falcon mode, the kernel is started without running u-boot, making this structure useless. Do we really need such a way (but then, it must be generalized as SPL API), or can we get rid of it ? As we have an EEPROM on the board that tells us the physical ram size, I use that to avoid the lockup. It seems weird. There is several boards in mainline (I am sure about Freescale's PowerPC) discovering the mounted RAM. Of course, this is simpler if many parameters (row/columns/...) are the same, I am not sure about this. Even if the parameters are different, this should not result in lockup... AFAICS, lockup of that type has nothing to do with the DRAM itself, but the controller configuration. Are we sure it is not possible here ? What does it happen with an inconsistent value in EEprom ? Eventually I would like to read and validate the entire EEPROM once in SPL and pass this to u-boot.img to avoid reading and validating it again. I think this is a good example of why sharing data between SPL and u-boot.img could be useful. I am not sure, and I doubt it is a good idea to use persistent data to store that. It is potentially dangerous, and if some reasons the EEprom is changed, the board could not boot at all. This is more a question of design and definition of what purpose the eeprom should serve, so I would let the vendor decide if he wants to depend on eeprom or not. On the other side, I like the current concept that the SPL is simply a loader and can load images of different types, and fixing an API between SPL and U-Boot goes against this concept. I agree on this one, there is no real need (at least currently) to introduce such an API. Also, there are cases (e.g. cm-fx6) where the DRAM size can be determined by just reading the MMDC configuration and thus spare additional get_ram_size() call from U-Boot. -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: make imxheader size align on page size
Hi Stefan, On 16/04/2014 15:17, Stefan Agner wrote: Quite possible that an altered/correct FCB would actually work. But speaking about FCB, is there already something for Vybrid? I'm currently try to create an Image with FCB+IVT V2 header using the mxsboot utility, mxsboot is not the right tool. There are some discussion about this some time ago. The best thing is that mkimage can be improved to add the FCB when the image is generated. As far as I know, nobody has started to develop it - patches are welcome, if you decide to do it ;-) Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: consolidate arch/arm/include/asm/arch-*/spl.h
Hi Masahiro,
On 16/04/2014 08:44, Masahiro Yamada wrote:
arch/arm/include/asm/spl.h requires all SoCs to have
arch/arm/include/asm/arch-*/spl.h.
But many of them just define BOOT_DEVICE_* macros.
Those macros are used in the switch (boot_device) { ... }
statement in common/spl/spl.c.
So they should not be archtecture specific, but described as
a simpile enumeration.
Absolutely right !
This commit merge most of arch/arm/include/asm/arch-*/spl.h
into arch/arm/include/asm/spl.h.
With a little more effort, arch-zynq/spl.h and arch-socfpga/spl.h
will be merged, while I am not sure about OMAP and Exynos.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
Cc: Tom Rini tr...@ti.com
Cc: Michal Simek michal.si...@xilinx.com
Cc: Andreas Bießmann andreas.de...@googlemail.com
Cc: Stephen Warren swar...@nvidia.com
Cc: Tom Warren twar...@nvidia.com
CC: Stefano Babic sba...@denx.de
CC: Minkyu Kang mk7.k...@samsung.com
Cc: Dinh Nguyen dingu...@altera.com
---
arch/arm/cpu/arm720t/tegra-common/spl.c | 2 +-
arch/arm/include/asm/arch-at91/spl.h | 24
arch/arm/include/asm/arch-davinci/spl.h | 16
arch/arm/include/asm/arch-mx35/spl.h | 22 --
arch/arm/include/asm/arch-mx5/spl.h | 13 -
arch/arm/include/asm/arch-tegra114/spl.h | 22 --
arch/arm/include/asm/arch-tegra124/spl.h | 13 -
arch/arm/include/asm/arch-tegra20/spl.h | 12
arch/arm/include/asm/arch-tegra30/spl.h | 12
arch/arm/include/asm/spl.h | 18 ++
board/denx/m53evk/m53evk.c | 2 +-
11 files changed, 20 insertions(+), 136 deletions(-)
delete mode 100644 arch/arm/include/asm/arch-at91/spl.h
delete mode 100644 arch/arm/include/asm/arch-davinci/spl.h
delete mode 100644 arch/arm/include/asm/arch-mx35/spl.h
delete mode 100644 arch/arm/include/asm/arch-mx5/spl.h
delete mode 100644 arch/arm/include/asm/arch-tegra114/spl.h
delete mode 100644 arch/arm/include/asm/arch-tegra124/spl.h
delete mode 100644 arch/arm/include/asm/arch-tegra20/spl.h
delete mode 100644 arch/arm/include/asm/arch-tegra30/spl.h
diff --git a/arch/arm/cpu/arm720t/tegra-common/spl.c
b/arch/arm/cpu/arm720t/tegra-common/spl.c
index 5171a8f..8147806 100644
--- a/arch/arm/cpu/arm720t/tegra-common/spl.c
+++ b/arch/arm/cpu/arm720t/tegra-common/spl.c
@@ -14,7 +14,7 @@
#include asm/arch/pinmux.h
#include asm/arch/tegra.h
#include asm/arch-tegra/board.h
-#include asm/arch/spl.h
+#include asm/spl.h
#include cpu.h
void spl_board_init(void)
diff --git a/arch/arm/include/asm/arch-at91/spl.h
b/arch/arm/include/asm/arch-at91/spl.h
deleted file mode 100644
index d8a87da..000
--- a/arch/arm/include/asm/arch-at91/spl.h
+++ /dev/null
@@ -1,24 +0,0 @@
-/*
- * Copyright (C) 2013 Atmel Corporation
- * Bo Shen voice.s...@atmel.com
- *
- * SPDX-License-Identifier: GPL-2.0+
- */
-
-#ifndef _ASM_ARCH_SPL_H_
-#define _ASM_ARCH_SPL_H_
-
-enum {
- BOOT_DEVICE_NONE,
-#ifdef CONFIG_SYS_USE_MMC
- BOOT_DEVICE_MMC1,
- BOOT_DEVICE_MMC2,
- BOOT_DEVICE_MMC2_2,
-#elif CONFIG_SYS_USE_NANDFLASH
- BOOT_DEVICE_NAND,
-#elif CONFIG_SYS_USE_SERIALFLASH
- BOOT_DEVICE_SPI,
-#endif
-};
-
-#endif
diff --git a/arch/arm/include/asm/arch-davinci/spl.h
b/arch/arm/include/asm/arch-davinci/spl.h
deleted file mode 100644
index 5afe0d4..000
--- a/arch/arm/include/asm/arch-davinci/spl.h
+++ /dev/null
@@ -1,16 +0,0 @@
-/*
- * (C) Copyright 2012
- * Texas Instruments, www.ti.com
- *
- * SPDX-License-Identifier: GPL-2.0+
- */
-#ifndef _ASM_ARCH_SPL_H_
-#define _ASM_ARCH_SPL_H_
-
-#define BOOT_DEVICE_NAND 1
-#define BOOT_DEVICE_SPI 2
-#define BOOT_DEVICE_MMC1 3
-#define BOOT_DEVICE_MMC2 4 /* dummy */
-#define BOOT_DEVICE_MMC2_2 5 /* dummy */
-
-#endif
diff --git a/arch/arm/include/asm/arch-mx35/spl.h
b/arch/arm/include/asm/arch-mx35/spl.h
deleted file mode 100644
index d0efec2..000
--- a/arch/arm/include/asm/arch-mx35/spl.h
+++ /dev/null
@@ -1,22 +0,0 @@
-/*
- * (C) Copyright 2012
- * Texas Instruments, www.ti.com
- *
- * SPDX-License-Identifier: GPL-2.0+
- */
-#ifndef _ASM_ARCH_SPL_H_
-#define _ASM_ARCH_SPL_H_
-
-#define BOOT_DEVICE_NONE 0
-#define BOOT_DEVICE_XIP 1
-#define BOOT_DEVICE_XIPWAIT 2
-#define BOOT_DEVICE_NAND 3
-#define BOOT_DEVICE_ONENAND 4
-#define BOOT_DEVICE_MMC1 5
-#define BOOT_DEVICE_MMC2 6
-#define BOOT_DEVICE_MMC2_2 7
-#define BOOT_DEVICE_NOR 8
-#define BOOT_DEVICE_I2C 9
-#define BOOT_DEVICE_SPI 10
-
-#endif
diff --git a/arch/arm/include/asm/arch-mx5/spl.h
b/arch/arm/include/asm/arch-mx5/spl.h
deleted file mode 100644
index 20c6cae..000
---
Re: [U-Boot] [PATCH 01/11] SPL: NAND: remove CONFIG_SYS_NAND_PAGE_SIZE
On Mon, Apr 14, 2014 at 4:38 AM, Stefano Babic sba...@denx.de wrote: On 03/04/2014 08:01, Tim Harvey wrote: We only need to read in the size of struct image_header and thus don't need to know the page size of the nand device. Signed-off-by: Tim Harvey thar...@gateworks.com --- common/spl/spl_nand.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/spl/spl_nand.c b/common/spl/spl_nand.c index 9da0218..062461b 100644 --- a/common/spl/spl_nand.c +++ b/common/spl/spl_nand.c @@ -76,7 +76,7 @@ void spl_nand_load_image(void) #endif /* Load u-boot */ nand_spl_load_image(CONFIG_SYS_NAND_U_BOOT_OFFS, - CONFIG_SYS_NAND_PAGE_SIZE, (void *)header); + sizeof(*header), (void *)header); spl_parse_image_header(header); nand_spl_load_image(CONFIG_SYS_NAND_U_BOOT_OFFS, spl_image.size, (void *)spl_image.load_addr); Acked-by: Stefano Babic sba...@denx.de Best regards, Stefano Babic Scott, This should have been addressed to you in the first place as its NAND and not IMX specific. It's been +1'd and ack'd, so if you agree with it and commit it I'll remove it from my next patch series regarding IMX6 SPL NAND support. Tim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] Do not use __DATE__ and __TIME__ anymore
Dear Masahiro, In message 20140417204113.6cec.aa925...@jp.panasonic.com you wrote: I want to gather timestamp stuff to one place for easy control of it. All understood - but this should be documented in the commit message. 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 We are Microsoft. Unix is irrelevant. Openness is futile. Prepare to be assimilated. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 0/2] eMMC: support for Read Protected Memory Block (RPMB)
This serie of patches adds some functions and a sub-command of 'mmc' for programming the authentication key and for reading and writing the RPMB partition of an eMMC according to the JEDEC standard No. 64-A441 The sub-command rpmb is enabled by the flag CONFIG_SUPPORT_EMMC_RPMB defined in the board configuration file. It has been tested on a SabreSDP iMX6 board. Changes in V2: - use ALLOC_CACHE_ALIGN_BUFFER in rpmb.c instead of a static buffer for the RPMB frames. Pierre Aubert (2): eMMC: add support for operations in RPMB partition eMMC: cmd_mmc.c adds the 'rpmb' sub-command for the 'mmc' command common/cmd_mmc.c | 128 - drivers/mmc/Makefile |1 + drivers/mmc/rpmb.c | 323 ++ include/mmc.h| 10 ++- lib/Makefile |3 + 5 files changed, 463 insertions(+), 2 deletions(-) create mode 100644 drivers/mmc/rpmb.c -- 1.7.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 2/2] eMMC: cmd_mmc.c adds the 'rpmb' sub-command for the 'mmc' command
This sub-command adds support for the RPMB partition of an eMMC:
* mmc rpmb key address of the authentication key
Programs the authentication key in the eMMC This key can not
be overwritten.
* mmc rpmb read address block #count [address of key]
Reads #count blocks of 256 bytes in the RPMB partition
beginning at block number block. If the optionnal
address of the authentication key is provided, the
Message Authentication Code (MAC) is verified on each
block.
* mmc rpmb write address block #count address of key
Writes #count blocks of 256 bytes in the RPMB partition
beginning at block number block. The datas are signed
with the key provided.
* mmc rpmb counter
Returns the 'Write counter' of the RPMB partition.
The sub-command is conditional on compilation flag CONFIG_SUPPORT_EMMC_RPMB
Signed-off-by: Pierre Aubert p.aub...@staubli.com
CC: Pantelis Antoniou pa...@antoniou-consulting.com
---
common/cmd_mmc.c | 128 +-
1 files changed, 127 insertions(+), 1 deletions(-)
diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
index c1916c9..3cf11e7 100644
--- a/common/cmd_mmc.c
+++ b/common/cmd_mmc.c
@@ -130,7 +130,123 @@ U_BOOT_CMD(
display MMC info,
- display info of the current MMC device
);
+#ifdef CONFIG_SUPPORT_EMMC_RPMB
+static int confirm_key_prog(void)
+{
+ puts(Warning: Programming authentication key can be done only once !\n
+ Use this command only if you are sure of what you are
doing,\n
+Really perform the key programming ? );
+ if (getc() == 'y') {
+ int c;
+
+ putc('y');
+ c = getc();
+ putc('\n');
+ if (c == '\r')
+ return 1;
+ }
+ puts(Authentication key programming aborted\n);
+ return 0;
+}
+static int do_mmcrpmb(int argc, char * const argv[])
+{
+ enum rpmb_state {
+ RPMB_INVALID,
+ RPMB_READ,
+ RPMB_WRITE,
+ RPMB_KEY,
+ RPMB_COUNTER,
+ } state;
+
+ state = RPMB_INVALID;
+ if (argc == 4 strcmp(argv[2], key) == 0)
+ state = RPMB_KEY;
+ if ((argc == 6 || argc == 7) strcmp(argv[2], read) == 0)
+ state = RPMB_READ;
+ else if (argc == 7 strcmp(argv[2], write) == 0)
+ state = RPMB_WRITE;
+ else if (argc == 3 strcmp(argv[2], counter) == 0)
+ state = RPMB_COUNTER;
+
+ if (state != RPMB_INVALID) {
+ struct mmc *mmc = find_mmc_device(curr_device);
+ void *key_addr;
+ char original_part;
+ int ret;
+
+ if (!mmc) {
+ printf(no mmc device at slot %x\n, curr_device);
+ return CMD_RET_FAILURE;
+ }
+ mmc_init(mmc);
+ if (IS_SD(mmc)) {
+ printf(It is not a EMMC device\n);
+ return CMD_RET_FAILURE;
+ }
+ /* Switch to the RPMB partition */
+ original_part = mmc-part_num;
+ if (mmc-part_num != MMC_PART_RPMB) {
+ if (mmc_switch_part(curr_device, MMC_PART_RPMB) != 0)
+ return CMD_RET_FAILURE;
+ mmc-part_num = MMC_PART_RPMB;
+ }
+ ret = CMD_RET_SUCCESS;
+ if (state == RPMB_KEY) {
+ key_addr = (void *)simple_strtoul(argv[3], NULL, 16);
+ if (confirm_key_prog()) {
+ if (mmc_rpmb_set_key(mmc, key_addr)) {
+ printf(ERROR - Key already programmed
?\n);
+ ret = CMD_RET_FAILURE;
+ }
+ } else {
+ ret = CMD_RET_FAILURE;
+ }
+ } else if (state == RPMB_COUNTER) {
+ unsigned long counter;
+ if (mmc_rpmb_get_counter(mmc, counter))
+ ret = CMD_RET_FAILURE;
+ else
+ printf(Write counter= %lx\n, counter);
+ } else {
+ u16 blk, cnt;
+ void *addr;
+ int n;
+
+ addr = (void *)simple_strtoul(argv[3], NULL, 16);
+ blk = simple_strtoul(argv[4], NULL, 16);
+ cnt = simple_strtoul(argv[5], NULL, 16);
+
+ if (state == RPMB_READ) {
+ key_addr = (argc == 7) ?
+ (void *)simple_strtoul(argv[6],
+ NULL, 16) :
+ NULL;
+ n
[U-Boot] [PATCH V2 1/2] eMMC: add support for operations in RPMB partition
This patch adds functions for read, write and authentication
key programming for the Replay Protected Memory Block partition
in the eMMC.
Signed-off-by: Pierre Aubert p.aub...@staubli.com
CC: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/mmc/Makefile |1 +
drivers/mmc/rpmb.c | 323 ++
include/mmc.h| 10 ++-
lib/Makefile |3 +
4 files changed, 336 insertions(+), 1 deletions(-)
create mode 100644 drivers/mmc/rpmb.c
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index 931922b..4c6ab9e 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_DWMMC) += dw_mmc.o
obj-$(CONFIG_EXYNOS_DWMMC) += exynos_dw_mmc.o
obj-$(CONFIG_ZYNQ_SDHCI) += zynq_sdhci.o
obj-$(CONFIG_SOCFPGA_DWMMC) += socfpga_dw_mmc.o
+obj-$(CONFIG_SUPPORT_EMMC_RPMB) += rpmb.o
ifdef CONFIG_SPL_BUILD
obj-$(CONFIG_SPL_MMC_BOOT) += fsl_esdhc_spl.o
else
diff --git a/drivers/mmc/rpmb.c b/drivers/mmc/rpmb.c
new file mode 100644
index 000..05936f5
--- /dev/null
+++ b/drivers/mmc/rpmb.c
@@ -0,0 +1,323 @@
+/*
+ * Copyright 2014, Staubli Faverges
+ * Pierre Aubert
+ *
+ * eMMC- Replay Protected Memory Block
+ * According to JEDEC Standard No. 84-A441
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include config.h
+#include common.h
+#include mmc.h
+#include sha256.h
+#include mmc_private.h
+
+/* Request codes */
+#define RPMB_REQ_KEY 1
+#define RPMB_REQ_WCOUNTER 2
+#define RPMB_REQ_WRITE_DATA3
+#define RPMB_REQ_READ_DATA 4
+#define RPMB_REQ_STATUS5
+
+/* Response code */
+#define RPMB_RESP_KEY 0x0100
+#define RPMB_RESP_WCOUNTER 0x0200
+#define RPMB_RESP_WRITE_DATA 0x0300
+#define RPMB_RESP_READ_DATA0x0400
+
+/* Error codes */
+#define RPMB_OK0
+#define RPMB_ERR_GENERAL 1
+#define RPMB_ERR_AUTH 2
+#define RPMB_ERR_COUNTER 3
+#define RPMB_ERR_ADDRESS 4
+#define RPMB_ERR_WRITE 5
+#define RPMB_ERR_READ 6
+#define RPMB_ERR_KEY 7
+#define RPMB_ERR_CNT_EXPIRED 0x80
+#define RPMB_ERR_MSK 0x7
+
+/* Sizes of RPMB data frame */
+#define RPMB_SZ_STUFF 196
+#define RPMB_SZ_MAC32
+#define RPMB_SZ_DATA 256
+#define RPMB_SZ_NONCE 16
+
+#define SHA256_BLOCK_SIZE 64
+
+/* Error messages */
+static const char * const rpmb_err_msg[] = {
+ ,
+ General failure,
+ Authentication failure,
+ Counter failure,
+ Address failure,
+ Write failure,
+ Read failure,
+ Authentication key not yet programmed,
+};
+
+
+/* Structure of RPMB data frame. */
+struct s_rpmb {
+ unsigned char stuff[RPMB_SZ_STUFF];
+ unsigned char mac[RPMB_SZ_MAC];
+ unsigned char data[RPMB_SZ_DATA];
+ unsigned char nonce[RPMB_SZ_NONCE];
+ unsigned long write_counter;
+ unsigned short address;
+ unsigned short block_count;
+ unsigned short result;
+ unsigned short request;
+};
+
+static int mmc_set_blockcount(struct mmc *mmc, unsigned int blockcount,
+ bool is_rel_write)
+{
+ struct mmc_cmd cmd = {0};
+
+ cmd.cmdidx = MMC_CMD_SET_BLOCK_COUNT;
+ cmd.cmdarg = blockcount 0x;
+ if (is_rel_write)
+ cmd.cmdarg |= 1 31;
+ cmd.resp_type = MMC_RSP_R1;
+
+ return mmc_send_cmd(mmc, cmd, NULL);
+}
+static int mmc_rpmb_request(struct mmc *mmc, const struct s_rpmb *s,
+ unsigned int count, bool is_rel_write)
+{
+ struct mmc_cmd cmd = {0};
+ struct mmc_data data;
+ int ret;
+
+ ret = mmc_set_blockcount(mmc, count, is_rel_write);
+ if (ret) {
+#ifdef CONFIG_MMC_RPMB_TRACE
+ printf(%s:mmc_set_blockcount- %d\n, __func__, ret);
+#endif
+ return 1;
+ }
+
+ cmd.cmdidx = MMC_CMD_WRITE_MULTIPLE_BLOCK;
+ cmd.cmdarg = 0;
+ cmd.resp_type = MMC_RSP_R1b;
+
+ data.src = (const char *)s;
+ data.blocks = 1;
+ data.blocksize = MMC_MAX_BLOCK_LEN;
+ data.flags = MMC_DATA_WRITE;
+
+ ret = mmc_send_cmd(mmc, cmd, data);
+ if (ret) {
+#ifdef CONFIG_MMC_RPMB_TRACE
+ printf(%s:mmc_send_cmd- %d\n, __func__, ret);
+#endif
+ return 1;
+ }
+ return 0;
+}
+static int mmc_rpmb_response(struct mmc *mmc, struct s_rpmb *s,
+unsigned short expected)
+{
+ struct mmc_cmd cmd = {0};
+ struct mmc_data data;
+ int ret;
+
+ ret = mmc_set_blockcount(mmc, 1, false);
+ if (ret) {
+#ifdef CONFIG_MMC_RPMB_TRACE
+ printf(%s:mmc_set_blockcount- %d\n, __func__, ret);
+#endif
+ return -1;
+ }
+ cmd.cmdidx = MMC_CMD_READ_MULTIPLE_BLOCK;
+ cmd.cmdarg = 0;
+ cmd.resp_type = MMC_RSP_R1;
+
+ data.dest = (char *)s;
+ data.blocks = 1;
+ data.blocksize =
Re: [U-Boot] [PATCH 1/2] usb: r8a66597: Fix initialization hub that using, R8A66597_MAX_ROOT_HUB
On Thursday, April 17, 2014 at 09:48:32 AM, yasuhisa umano wrote: This driver is processed as two USB hub despite one. The number of root hub is defined in R8A66597_MAX_ROOT_HUB. This fixes that register is accessed by using the definition of R8A66597_MAX_ROOT_HUB. Signed-off-by: Yasuhisa Umano yasuhisa.umano...@renesas.com --- drivers/usb/host/r8a66597-hcd.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/r8a66597-hcd.c b/drivers/usb/host/r8a66597-hcd.c index dfe5423..c58d2a9 100644 --- a/drivers/usb/host/r8a66597-hcd.c +++ b/drivers/usb/host/r8a66597-hcd.c @@ -164,8 +164,8 @@ static int enable_controller(struct r8a66597 *r8a66597) r8a66597_bset(r8a66597, INTL, SOFCFG); r8a66597_write(r8a66597, 0, INTENB0); - r8a66597_write(r8a66597, 0, INTENB1); - r8a66597_write(r8a66597, 0, INTENB2); + for (port = 0; port R8A66597_MAX_ROOT_HUB; port++) + r8a66597_write(r8a66597, 0, get_intenb_reg(port)); Hmm, looking at get_intenb_reg(), this is slightly dangerous, but I will trust you you know what you are doing . I am a bit worried someone might set R8A66597_MAX_ROOT_HUB to value 2 and will wonder why doesn't it work. Anyway, I will apply this and if you feel my rant is valid, submit subsequent patch. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] usb: r8a66597: Fix initilization size of r8a66597 info, structure
On Thursday, April 17, 2014 at 10:20:29 AM, yasuhisa umano wrote: Initialization of r8a66597 info structure is not enough. Because initilization was used size of pointer. This fixes that use size of r8a6659 info structure. Signed-off-by: Yasuhisa Umano yasuhisa.umano...@renesas.com --- drivers/usb/host/r8a66597-hcd.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/r8a66597-hcd.c b/drivers/usb/host/r8a66597-hcd.c index c58d2a9..8e82212 100644 --- a/drivers/usb/host/r8a66597-hcd.c +++ b/drivers/usb/host/r8a66597-hcd.c @@ -807,7 +807,7 @@ int usb_lowlevel_init(int index, enum usb_init_type init, void **controller) R8A66597_DPRINT(%s\n, __func__); - memset(r8a66597, 0, sizeof(r8a66597)); + memset(r8a66597, 0, sizeof(struct r8a66597)); Let's use sizeof(*r8a66597) instead . This is more scalable as you won't need to adjust this code when you change the data type of the *r8a66597 pointer, I will adjust that and apply with sizeof(*r8a66597); , does that work for you? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] pull request for u-boot-tegra/master into ARM/master
Albert,
Please pull u-boot-tegra/master into ARM/master. Thanks!
./MAKEALL -s tegra AOK, checkpatch.pl is OK, and ./MAKEALL -a arm only
shows failures that were already present in ARM/master.
The following changes since commit 1b82491ee6ee1e986e5521b33692a00e1f38fe75:
board:tricorder: fixup SPL OOB layout (2014-04-11 10:08:42 -0400)
are available in the git repository at:
git://git.denx.de/u-boot-tegra.git master
for you to fetch changes up to d381294aef4a5b6ddeda3685519330a5b73d884f:
ARM: tegra: pack pinmux data tables tighter (2014-04-17 08:41:06 -0700)
Stefan Agner (3):
usb: tegra: fix USB2 powerdown for Tegra30 and later
usb: tegra: fix PHY configuration
usb: tegra: combine header file
Stephen Warren (14):
ARM: tegra: pinctrl: remove func_safe
ARM: tegra: pinctrl: remove vddio
ARM: tegra: pinctrl: make pmux_func values consistent on Tegra20
ARM: tegra: prototype pinmux_init() in board.h
ARM: tegra: use apb_misc.h in more places
ARM: tegra: pinctrl: remove duplication
ARM: tegra: reduce public pinmux API
ARM: tegra: pinmux naming consistency fixes
ARM: tegra: Tegra20 pinmux cleanup
ARM: tegra: Tegra30 pinmux cleanup
ARM: tegra: Tegra114 pinmux cleanup
ARM: tegra: Tegra124 pinmux cleanup
ARM: tegra: add Jetson TK1 board
ARM: tegra: pack pinmux data tables tighter
arch/arm/cpu/arm720t/tegra-common/spl.c| 6 +-
arch/arm/cpu/arm720t/tegra114/cpu.c| 4 +-
arch/arm/cpu/arm720t/tegra124/cpu.c| 4 +-
arch/arm/cpu/tegra-common/Makefile | 6 +-
arch/arm/cpu/tegra-common/pinmux-common.c | 508 +++
arch/arm/cpu/tegra114-common/funcmux.c | 32 +-
arch/arm/cpu/tegra114-common/pinmux.c | 895
+--
arch/arm/cpu/tegra124-common/funcmux.c | 38 +-
arch/arm/cpu/tegra124-common/pinmux.c | 898
+--
arch/arm/cpu/tegra20-common/emc.c | 2 +-
arch/arm/cpu/tegra20-common/funcmux.c | 185 ++--
arch/arm/cpu/tegra20-common/pinmux.c | 416 +++--
arch/arm/cpu/tegra20-common/warmboot.c | 8 +-
arch/arm/cpu/tegra20-common/warmboot_avp.c | 6 +-
arch/arm/cpu/tegra30-common/funcmux.c | 20 +-
arch/arm/cpu/tegra30-common/pinmux.c | 948
++--
arch/arm/dts/Makefile | 1 +
arch/arm/dts/tegra124-jetson-tk1.dts | 84 ++
.../asm/{arch-tegra20 = arch-tegra}/apb_misc.h| 2 +
arch/arm/include/asm/arch-tegra/board.h| 1 +
arch/arm/include/asm/arch-tegra/pinmux.h | 185
arch/arm/include/asm/arch-tegra/usb.h | 223 -
arch/arm/include/asm/arch-tegra114/pinmux.h| 836 ++
arch/arm/include/asm/arch-tegra114/usb.h | 156
arch/arm/include/asm/arch-tegra124/pinmux.h| 866 +++---
arch/arm/include/asm/arch-tegra124/usb.h | 268 --
arch/arm/include/asm/arch-tegra20/pinmux.h | 372 +++-
arch/arm/include/asm/arch-tegra20/usb.h| 155
arch/arm/include/asm/arch-tegra30/pinmux.h | 963
-
arch/arm/include/asm/arch-tegra30/usb.h| 168
.../common/pinmux-config-tamonten-ng.h | 492 +--
board/avionic-design/common/tamonten-ng.c | 12 +-
board/avionic-design/common/tamonten.c | 4 +-
board/compal/paz00/paz00.c | 22 +-
board/compulab/trimslice/trimslice.c | 4 +-
board/nvidia/cardhu/cardhu.c | 6 +-
board/nvidia/cardhu/pinmux-config-cardhu.h | 498 +--
board/nvidia/common/board.c| 9 +-
board/nvidia/dalmore/dalmore.c | 9 +-
board/nvidia/dalmore/pinmux-config-dalmore.h | 388 -
board/nvidia/harmony/harmony.c | 18 +-
board/nvidia/jetson-tk1/Makefile | 9 +
board/nvidia/jetson-tk1/jetson-tk1.c | 23 +
board/nvidia/jetson-tk1/pinmux-config-jetson-tk1.h | 227 +
board/nvidia/seaboard/seaboard.c | 6 +-
board/nvidia/venice2/as3722_init.h | 4 +
board/nvidia/venice2/pinmux-config-venice2.h | 360
board/nvidia/venice2/venice2.c | 15 +-
.../colibri_t20-common/colibri_t20-common.c| 8 +-
board/toradex/colibri_t20_iris/colibri_t20_iris.c | 4 +-
boards.cfg | 1 +
drivers/spi/tegra20_sflash.c | 6 +-
drivers/usb/host/ehci-tegra.c | 28 +-
drivers/video/tegra.c | 4 +-
include/configs/jetson-tk1.h | 79 ++
55
[U-Boot] [PATCH] usb:gadget:f_thor: fix write to filesystem by add dfu_flush()
Since dfu read/write operations needs to be flushed manually,
writing to filesystem on MMC by thor was broken. MMC raw write
actually is working fine because current dfu_flush() function
writes filesystem only. This commit adds dfu_flush() to f_thor
and now filesystem write is working.
This change was tested on Trats2 board.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Marek Vasut ma...@denx.de
Cc: Heiko Schocher h...@denx.de
Cc: Tom Rini tr...@ti.com
---
drivers/usb/gadget/f_thor.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/gadget/f_thor.c b/drivers/usb/gadget/f_thor.c
index f5c0224..ba47945 100644
--- a/drivers/usb/gadget/f_thor.c
+++ b/drivers/usb/gadget/f_thor.c
@@ -204,14 +204,14 @@ static long long int download_head(unsigned long long
total,
static int download_tail(long long int left, int cnt)
{
+ struct dfu_entity *dfu_entity = dfu_get_entity(alt_setting_num);
void *transfer_buffer = dfu_get_buf();
int ret;
debug(%s: left: %llu cnt: %d\n, __func__, left, cnt);
if (left) {
- ret = dfu_write(dfu_get_entity(alt_setting_num),
- transfer_buffer, left, cnt++);
+ ret = dfu_write(dfu_entity, transfer_buffer, left, cnt++);
if (ret) {
error(DFU write failed [%d]: left: %llu, ret, left);
return ret;
@@ -225,11 +225,16 @@ static int download_tail(long long int left, int cnt)
* This also frees memory malloc'ed by dfu_get_buf(), so no explicit
* need fo call dfu_free_buf() is needed.
*/
- ret = dfu_write(dfu_get_entity(alt_setting_num),
- transfer_buffer, 0, cnt);
+ ret = dfu_write(dfu_entity, transfer_buffer, 0, cnt);
if (ret)
error(DFU write failed [%d] cnt: %d, ret, cnt);
+ ret = dfu_flush(dfu_entity, transfer_buffer, 0, cnt);
+ if (ret) {
+ error(DFU flush failed!);
+ return ret;
+ }
+
return ret;
}
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb:gadget:f_thor: fix write to filesystem by add dfu_flush()
On Thursday, April 17, 2014 at 07:31:00 PM, Przemyslaw Marczak wrote:
Since dfu read/write operations needs to be flushed manually,
writing to filesystem on MMC by thor was broken. MMC raw write
actually is working fine because current dfu_flush() function
writes filesystem only. This commit adds dfu_flush() to f_thor
and now filesystem write is working.
This change was tested on Trats2 board.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Marek Vasut ma...@denx.de
Cc: Heiko Schocher h...@denx.de
Cc: Tom Rini tr...@ti.com
---
drivers/usb/gadget/f_thor.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/gadget/f_thor.c b/drivers/usb/gadget/f_thor.c
index f5c0224..ba47945 100644
--- a/drivers/usb/gadget/f_thor.c
+++ b/drivers/usb/gadget/f_thor.c
@@ -204,14 +204,14 @@ static long long int download_head(unsigned long long
total,
static int download_tail(long long int left, int cnt)
{
+ struct dfu_entity *dfu_entity = dfu_get_entity(alt_setting_num);
void *transfer_buffer = dfu_get_buf();
int ret;
debug(%s: left: %llu cnt: %d\n, __func__, left, cnt);
if (left) {
- ret = dfu_write(dfu_get_entity(alt_setting_num),
- transfer_buffer, left, cnt++);
+ ret = dfu_write(dfu_entity, transfer_buffer, left, cnt++);
if (ret) {
error(DFU write failed [%d]: left: %llu, ret, left);
return ret;
@@ -225,11 +225,16 @@ static int download_tail(long long int left, int cnt)
* This also frees memory malloc'ed by dfu_get_buf(), so no explicit
* need fo call dfu_free_buf() is needed.
*/
- ret = dfu_write(dfu_get_entity(alt_setting_num),
- transfer_buffer, 0, cnt);
+ ret = dfu_write(dfu_entity, transfer_buffer, 0, cnt);
if (ret)
error(DFU write failed [%d] cnt: %d, ret, cnt);
Please split this into two patches, one which does cleanup (that's the part
above) and one which fixes the functionality (that's the part below).
+ ret = dfu_flush(dfu_entity, transfer_buffer, 0, cnt);
+ if (ret) {
+ error(DFU flush failed!);
+ return ret;
+ }
+
return ret;
}
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] am33xx: add SSC enable macro
On Thu, Apr 10, 2014 at 11:35:25AM +0200, yegorsli...@googlemail.com wrote: From: Yegor Yefremov yegorsli...@googlemail.com Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com --- arch/arm/include/asm/arch-am33xx/clock.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/include/asm/arch-am33xx/clock.h b/arch/arm/include/asm/arch-am33xx/clock.h index 7637457..f00fad3 100644 --- a/arch/arm/include/asm/arch-am33xx/clock.h +++ b/arch/arm/include/asm/arch-am33xx/clock.h @@ -42,6 +42,8 @@ #define MODULE_CLKCTRL_IDLEST_DISABLED 3 /* CM_CLKMODE_DPLL */ +#define CM_CLKMODE_DPLL_SSC_EN_SHIFT 12 +#define CM_CLKMODE_DPLL_SSC_EN_MASK (1 12) #define CM_CLKMODE_DPLL_REGM4XEN_SHIFT 11 #define CM_CLKMODE_DPLL_REGM4XEN_MASK(1 11) #define CM_CLKMODE_DPLL_LPMODE_EN_SHIFT 10 OK, but what's going to use this? Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Updating master with next
I've now merged next into master and pushed, along with re-applying the change that makes non-COFNIG_SYS_GENERIC_BOARD boards complain at run-time. I'm going to be grabbing some other patches shortly, of the type that easily conflict and I don't want to have to have them be rebased again. -- Tom 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] patman: Don't request full names from get_maintainer
The Linux get_maintainer.pl can often produce a whole lot of results. As a result you'll sometimes blow your CC field over 1024 characters and that can cause listservs to reject your message. As a stopgap, call get_maintainer.pl with --non so it doesn't include real names. This will dramatically reduce the number of characters. Signed-off-by: Doug Anderson diand...@chromium.org --- tools/patman/get_maintainer.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/patman/get_maintainer.py b/tools/patman/get_maintainer.py index 00b4939..a5160bc 100644 --- a/tools/patman/get_maintainer.py +++ b/tools/patman/get_maintainer.py @@ -43,5 +43,5 @@ def GetMaintainer(fname, verbose=False): print WARNING: Couldn't find get_maintainer.pl return [] -stdout = command.Output(get_maintainer, '--norolestats', fname) +stdout = command.Output(get_maintainer, '--norolestats', '--non', fname) return stdout.splitlines() -- 1.9.1.423.g4596e3a ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] blackfin: replace bfin_gen_rand_mac() with eth_random_addr()
On Thu 17 Apr 2014 17:00:30 Masahiro Yamada wrote: --- a/include/configs/tcm-bf537.h +++ b/include/configs/tcm-bf537.h @@ -73,7 +73,7 @@ #define CONFIG_HOSTNAME tcm-bf537 /* Uncomment next line to use fixed MAC address */ /* #define CONFIG_ETHADDR02:80:ad:20:31:e8 */ - +#define CONFIG_LIB_RAND this should be in bfin_adi_common.h instead. i think that replaces the majority of your config updates (if not all). -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] Do not use __DATE__ and __TIME__ anymore
On Thu 17 Apr 2014 17:00:27 Masahiro Yamada wrote: The aim of this series is to prohibit using __DATE__ and __TIME__. as long as the version.h isn't impacted, this should fine. i don't think it is as it looks like the build will generate U_BOOT_DATE and U_BOOT_TIME into a const string by hand. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] buildman: make output dir configurable
Add an option to specify the output directory to override the
default path '../'. This is useful for building in a ramdisk.
Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com
Cc: Simon Glass s...@chromium.org
---
Changes for v2:
- improved help message
---
tools/buildman/buildman.py | 3 +++
tools/buildman/control.py | 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/tools/buildman/buildman.py b/tools/buildman/buildman.py
index 8822efe..73a5483 100755
--- a/tools/buildman/buildman.py
+++ b/tools/buildman/buildman.py
@@ -101,6 +101,9 @@ parser.add_option('-T', '--threads', type='int',
default=None, help='Number of builder threads to use')
parser.add_option('-u', '--show_unknown', action='store_true',
default=False, help='Show boards with unknown build result')
+parser.add_option('-o', '--output-dir', type='string',
+ dest='output_dir', default='..',
+ help='Directory where all builds happen and buildman has its workspace
(default is ../)')
parser.usage = buildman -b branch [options]
diff --git a/tools/buildman/control.py b/tools/buildman/control.py
index 8e6a08f..d2f4102 100644
--- a/tools/buildman/control.py
+++ b/tools/buildman/control.py
@@ -145,7 +145,7 @@ def DoBuildman(options, args):
options.step = len(series.commits) - 1
# Create a new builder with the selected options
-output_dir = os.path.join('..', options.branch)
+output_dir = os.path.join(options.output_dir, options.branch)
builder = Builder(toolchains, output_dir, options.git_dir,
options.threads, options.jobs, checkout=True,
show_unknown=options.show_unknown, step=options.step)
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] buildman: make output dir configurable
On 17 April 2014 13:13, Daniel Schwierzeck daniel.schwierz...@gmail.com wrote: Add an option to specify the output directory to override the default path '../'. This is useful for building in a ramdisk. Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com Cc: Simon Glass s...@chromium.org Thanks. Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] pcnet driver fixes
Hi Tom, 2014-04-07 17:41 GMT+02:00 Paul Burton paul.bur...@imgtec.com: This series fixes issues with the pcnet driver its memory accesses. Previously the network interface on the MIPS Malta board was unreliable would often time out whilst transferring files via TFTP, but with this series applied it is now stable. Paul Burton (3): pcnet: access descriptor rings init block uncached pcnet: align rx buffers for cache invalidation pcnet: force ordering of descriptor accesses In patchwork someone assigned all patches in this series to you. Is that intentional or shall I pick them up for MIPS tree? -- - Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/13] ARMv7: add PSCI support to u-boot
No, so far there hasn't been much discussion, and people seem happy with it. I have a couple of fixes lined up, but nothing major. So, I think PSCI 0.2 calls for function numbers in the 0x8400 range. Seems like we'll have to fix this in one of your patches: /* PSCI interface */ #define ARM_PSCI_FN_BASE0x95c1ba5e to be: #define ARM_PSCI_FN_BASE0x8400 Just thought I'd toss that out there, you know, if you were collecting fixes for a repost of your patches... :-) jdl On Thu, Apr 17, 2014 at 3:58 AM, Marc Zyngier marc.zyng...@arm.com wrote: On Thu, Apr 17 2014 at 9:34:24 am BST, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Marc, On Wed, 16 Apr 2014 17:09:07 +0100, Marc Zyngier marc.zyng...@arm.com wrote: On 16/04/14 15:45, Albert ARIBAUD wrote: Hi Marc, On Sat, 15 Feb 2014 13:36:24 +, Marc Zyngier marc.zyngier-5wv7dgni...@public.gmane.org wrote: PSCI is an ARM standard that provides a generic interface that supervisory software can use to manage power in the following situations: - Core idle management - CPU hotplug - big.LITTLE migration models - System shutdown and reset It basically allows the kernel to offload these tasks to the firmware, and rely on common kernel side code. More importantly, it gives a way to ensure that CPUs enter the kernel at the appropriate exception level (ie HYP mode, to allow the use of the virtualization extensions), even across events like CPUs being powered off/on or suspended. The main idea here is to turn some of the existing u-boot code into a separate section that can live in secure RAM (or a reserved page of memory), containing a secure monitor that will implement the PSCI operations. This code will still be alive when u-boot is long gone, hence the need for a piece of memory that will not be touched by the OS. This patch series contains 4 parts: - the first four patches are just bug fixes - the next two refactor the HYP/non-secure code to allow relocation in secure memory - the next four contain the generic PSCI code and DT infrastructure - the last three implement the CPU_ON method of the Allwinner A20 (aka sun7i). I realize the A20 u-boot code is not upstream yet (BTW is anyone actively working on that?), but hopefully that should give a good idea of how things are structured so far. The patches are against the mainline u-boot tree as of today, merged with the sunxi u-boot tree of the day and the first 10 patches will directly apply to mainline u-boot. As for using this code, it goes like this: sun7i# ext2load mmc 0:1 0x40008000 zImage ; ext2load mmc 0:1 0x6000 sun7i-a20-cubietruck.dtb 2270120 bytes read in 117 ms (18.5 MiB/s) 9138 bytes read in 3 ms (2.9 MiB/s) sun7i# fdt addr 0x6000 ; fdt resize ; fdt set ethernet0 mac-address [5a fe b0 07 b0 07] sun7i# setenv bootargs console=ttyS0,115200 earlyprintk ip=dhcp root=/dev/nfs nfsroot=/backup/a20_root,tcp sun7i# bootz 0x40008000 - 0x6000 The kernel now boots in HYP mode, finds its secondary CPU without any SMP code present in the kernel, and runs KVM out of the box. I've been told the Xen/ARM guys managed to do the same fairly easily. This code has also been tested on a VExpress TC2, running KVM with all 5 CPUs, in order to make sure there was no obvious regression. I'm wildly cross-posting this patch series, including to lists I'm not subscribed to. Please keep me on Cc for any comment you may have. The code is also available at: git://git.kernel.org/pub/scm/linux/kernel/git/maz/u-boot.git wip/psci Cheers, M. Marc, I'm unclear what you want to do with this series. You mention that its first 10 patches will apply to U-Boot, but I am not sure whether you are just indicating that it is possible to apply them or asking for these 10 patches to go in U-Boot mainline. Or is it something else yet? Well, I rarely write code just for the sake of forking a critical project ;-) So let's be 100% explicit: Yes, I'm hereby asking for these patches to be merged. They offer a service that is required by the Linux kernel as well as Xen. They are in active use on the Allwinner sun7i platform as well as Versatile Express (though the later doesn't have a PSCI implementation). Now, given that two months have gone past without much comment other than the odd hey, works great, I don't really know where to take that. Are you willing to review the patches? Well, I rarely ask about patches just for the sake of conversation. O:-) So yes, I am willing to review them -- and I suspect others are, as well. Nobody commented the V3 series on the U-Boot list -- save for Jon's comment about the series needing a rebase -- which could mean no one here is unhappy with them... or they were discussed and possibly acted upon on linux-sunxi, where the replies were redirected. I don't
Re: [U-Boot] [PATCH V2 2/2] eMMC: cmd_mmc.c adds the 'rpmb' sub-command for the 'mmc' command
Dear Pierre Aubert,
In message 1397747435-24042-3-git-send-email-p.aub...@staubli.com you wrote:
This sub-command adds support for the RPMB partition of an eMMC:
* mmc rpmb key address of the authentication key
Programs the authentication key in the eMMC This key can not
be overwritten.
* mmc rpmb read address block #count [address of key]
Reads #count blocks of 256 bytes in the RPMB partition
beginning at block number block. If the optionnal
address of the authentication key is provided, the
Message Authentication Code (MAC) is verified on each
block.
* mmc rpmb write address block #count address of key
Writes #count blocks of 256 bytes in the RPMB partition
beginning at block number block. The datas are signed
with the key provided.
* mmc rpmb counter
Returns the 'Write counter' of the RPMB partition.
The sub-command is conditional on compilation flag CONFIG_SUPPORT_EMMC_RPMB
Such new options must be documented in the README.
Signed-off-by: Pierre Aubert p.aub...@staubli.com
CC: Pantelis Antoniou pa...@antoniou-consulting.com
---
common/cmd_mmc.c | 128
+-
1 files changed, 127 insertions(+), 1 deletions(-)
diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
index c1916c9..3cf11e7 100644
--- a/common/cmd_mmc.c
+++ b/common/cmd_mmc.c
@@ -130,7 +130,123 @@ U_BOOT_CMD(
display MMC info,
- display info of the current MMC device
);
+#ifdef CONFIG_SUPPORT_EMMC_RPMB
+static int confirm_key_prog(void)
+{
+ puts(Warning: Programming authentication key can be done only once !\n
+ Use this command only if you are sure of what you are
doing,\n
+ Really perform the key programming ? );
+ if (getc() == 'y') {
Would it not makes sense to flush the input before reading the char,
so that you don;t react on any type-ahead that might already be
buffered?
+ int c;
+
+ putc('y');
+ c = getc();
+ putc('\n');
+ if (c == '\r')
+ return 1;
+ }
Should we allow for 'Y? And for yes / Yes?
We have getenv_yesno() - maybe we should provide a similar function
that can be used in other places where such interactive confirmation
is needed?
+ if (state != RPMB_INVALID) {
Change this into
if (state == RPMB_INVALID)
return CMD_RET_USAGE;
and avoid one level of indentation; this will make the code much
easier to read.
+ if (IS_SD(mmc)) {
Is IS_SD() a reliable test for eMMC devics, or would that also return
true in other cases?
+ if (confirm_key_prog()) {
+ if (mmc_rpmb_set_key(mmc, key_addr)) {
+ printf(ERROR - Key already programmed
?\n);
+ ret = CMD_RET_FAILURE;
+ }
+ } else {
+ ret = CMD_RET_FAILURE;
+ }
You should really avoid deep nesting and take early exits.
You can write this as:
if (!confirm_key_prog())
return CMD_RET_FAILURE;
if (mmc_rpmb_set_key(mmc, key_addr)) {
printf(ERROR - Key already programmed ?\n);
ret = CMD_RET_FAILURE;
}
Please fix globally.
+ } else if (state == RPMB_COUNTER) {
+ unsigned long counter;
+ if (mmc_rpmb_get_counter(mmc, counter))
Please insert a blank line between declarations and code.
+ printf(%d RPMB blocks %s: %s\n,
+n, argv[2], (n == cnt) ? OK : ERROR);
As the input is in hex, it is usually also a good idea to (also) print
the count in hex.
#endif /* CONFIG_SUPPORT_EMMC_BOOT */
+#ifdef CONFIG_SUPPORT_EMMC_RPMB
+ } else if (strcmp(argv[1], rpmb) == 0) {
+ return do_mmcrpmb(argc, argv);
+#endif /* CONFIG_SUPPORT_EMMC_RPMB */
I think that now, with more subcommands being added, we should
convert the mmc code to proper subcommand handling. [It might even
make sense to do so for mmc rpmb, too.]
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
The computer programmer is a creator of universes for which he alone
is responsible. Universes of virtually unlimited complexity can be
created in the form of computer programs. - Joseph Weizenbaum,
_Computer Power and Human Reason_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MAKEALL: remove hard-coded MIPS boards
iDo not initialize list_MIPS with hard-coded board names.
Use targets_by_arch() instead.
Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com
---
MAKEALL | 40 +---
1 file changed, 1 insertion(+), 39 deletions(-)
diff --git a/MAKEALL b/MAKEALL
index c54240c..020e65f 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -418,47 +418,9 @@ LIST_arm=$(targets_by_arch arm | \
## MIPS Systems(default = big endian)
#
-LIST_mips4kc= \
- qemu_mips \
- vct_platinum\
- vct_platinum_small \
- vct_platinum_onenand\
- vct_platinum_onenand_small \
- vct_platinumavc \
- vct_platinumavc_small \
- vct_platinumavc_onenand \
- vct_platinumavc_onenand_small \
- vct_premium \
- vct_premium_small \
- vct_premium_onenand \
- vct_premium_onenand_small \
-
-
-LIST_au1xx0= \
- dbau1000\
- dbau1100\
- dbau1500\
- dbau1550\
-
-
-LIST_mips=\
- ${LIST_mips4kc} \
- ${LIST_mips5kc} \
- ${LIST_au1xx0} \
-
+LIST_mips=$(targets_by_arch mips)
#
-## MIPS Systems(little endian)
-#
-
-LIST_au1xx0_el= \
- dbau1550_el \
- pb1000 \
-
-LIST_mips_el= \
- ${LIST_au1xx0_el} \
-
-#
## OpenRISC Systems
#
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Fwd: [PATCH v3 00/13] ARMv7: add PSCI support to u-boot
[ Drat. I meant to send this to the U-Boot list, not just Albert. --jdl] -- Forwarded message -- From: Jon Loeliger loeli...@gmail.com Date: Thu, Apr 17, 2014 at 11:36 AM Subject: Re: [U-Boot] [PATCH v3 00/13] ARMv7: add PSCI support to u-boot To: Albert ARIBAUD albert.u.b...@aribaud.net On Thu, Apr 17, 2014 at 3:34 AM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Marc, So yes, I am willing to review them -- and I suspect others are, as well. Nobody commented the V3 series on the U-Boot list -- save for Jon's comment about the series needing a rebase -- which could mean no one here is unhappy with them... So, not *unhappy* with them, but definitely some review is needed. Also, there are aspects of the implementation that will need to be generalized a bit. For example, the sunxi code uses a magic register in its implementation that allows a core to come out of reset at a known (ie, given) non-0 address. My A9 core has CPUs coming out of reset at a fixed address of 0. That means my secure text must be at 0, and it must have a secure vector with a secure reset laid down at 0. Ultimately, this means that a small modification (adding a secure vector text section) to the LDS file will be needed to ensure that it is placed at 0 within the secure text section itself. No, I don't have all this working quite yet. :-) jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] support for maxim dallas rtcds1347
I am writing the support for rtc ds1347 my driver file resides in drivers/rtc/ds1347.c who is the custodian for the rtc subsystem of uboot or just i have to mail patch to u-boot@lists.denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] env_flash.c: Drop unused variables
With 7ce1526 we no longer need 'len' or 'res', so drop these variables.
Signed-off-by: Tom Rini tr...@ti.com
---
common/env_flash.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/common/env_flash.c b/common/env_flash.c
index b3ad908..004e884 100644
--- a/common/env_flash.c
+++ b/common/env_flash.c
@@ -224,9 +224,8 @@ int env_init(void)
int saveenv(void)
{
env_t env_new;
- ssize_t len;
int rc = 1;
- char*res, *saved_data = NULL;
+ char*saved_data = NULL;
#if CONFIG_ENV_SECT_SIZE CONFIG_ENV_SIZE
ulong up_data = 0;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] am335x_evm: Drop SPI SPL support from the default build
This is only useful with the _spiboot build target anyhow, so only include it then. Drop CONFIG_SPL_OS_BOOT support then as the flash is small and didn't include a spot for the device tree already. Signed-off-by: Tom Rini tr...@ti.com --- include/configs/am335x_evm.h | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index ebe2ab3..036c609 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -213,14 +213,6 @@ #define CONFIG_SPL_ENV_SUPPORT #define CONFIG_SPL_NET_VCI_STRING AM335x U-Boot SPL -/* SPI flash. */ -#define CONFIG_SPL_SPI_SUPPORT -#define CONFIG_SPL_SPI_FLASH_SUPPORT -#define CONFIG_SPL_SPI_LOAD -#define CONFIG_SPL_SPI_BUS 0 -#define CONFIG_SPL_SPI_CS 0 -#define CONFIG_SYS_SPI_U_BOOT_OFFS 0x2 - #define CONFIG_SPL_LDSCRIPT$(CPUDIR)/am33xx/u-boot-spl.lds #ifdef CONFIG_NAND @@ -362,6 +354,15 @@ * 0x442000 - 0x80 : Userland */ #if defined(CONFIG_SPI_BOOT) +/* SPL related */ +#undef CONFIG_SPL_OS_BOOT /* Not supported by existing map */ +#define CONFIG_SPL_SPI_SUPPORT +#define CONFIG_SPL_SPI_FLASH_SUPPORT +#define CONFIG_SPL_SPI_LOAD +#define CONFIG_SPL_SPI_BUS 0 +#define CONFIG_SPL_SPI_CS 0 +#define CONFIG_SYS_SPI_U_BOOT_OFFS 0x2 + #define CONFIG_ENV_IS_IN_SPI_FLASH #define CONFIG_SYS_REDUNDAND_ENVIRONMENT #define CONFIG_ENV_SPI_MAX_HZ CONFIG_SF_DEFAULT_SPEED @@ -437,7 +438,6 @@ #define CONFIG_SYS_FLASH_CFI_WIDTH FLASH_CFI_16BIT #define CONFIG_SYS_MONITOR_BASECONFIG_SYS_FLASH_BASE /* Reduce SPL size by removing unlikey targets */ -#undef CONFIG_SPL_SPI_SUPPORT #ifdef CONFIG_NOR_BOOT #define CONFIG_ENV_IS_IN_FLASH #define CONFIG_ENV_SECT_SIZE (128 10) /* 128 KiB */ -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] am43xx_evm: Drop SPI SPL
QSPI booting on this board does not use SPL, so drop SPI-SPL related options. Signed-off-by: Tom Rini tr...@ti.com --- include/configs/am43xx_evm.h |8 1 file changed, 8 deletions(-) diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h index 4e56ffc..d5e6c4b 100644 --- a/include/configs/am43xx_evm.h +++ b/include/configs/am43xx_evm.h @@ -98,14 +98,6 @@ #define CONFIG_SF_DEFAULT_SPEED4800 #define CONFIG_DEFAULT_SPI_MODESPI_MODE_3 -/* SPI SPL */ -#define CONFIG_SPL_SPI_SUPPORT -#define CONFIG_SPL_SPI_LOAD -#define CONFIG_SPL_SPI_FLASH_SUPPORT -#define CONFIG_SPL_SPI_BUS 0 -#define CONFIG_SPL_SPI_CS 0 -#define CONFIG_SYS_SPI_U_BOOT_OFFS 0x2 - /* Enhance our eMMC support / experience. */ #define CONFIG_CMD_GPT #define CONFIG_EFI_PARTITION -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] usb: r8a66597: Fix initialization hub that using, R8A66597_MAX_ROOT_HUB
Hi Sorry. I failed to send patchs to ML by setting of MUA. Best regards, Yasuhisa (2014/04/17 19:47), Marek Vasut wrote: On Thursday, April 17, 2014 at 09:48:32 AM, yasuhisa umano wrote: This driver is processed as two USB hub despite one. The number of root hub is defined in R8A66597_MAX_ROOT_HUB. This fixes that register is accessed by using the definition of R8A66597_MAX_ROOT_HUB. Signed-off-by: Yasuhisa Umano yasuhisa.umano...@renesas.com Is there any reason why those two patches were sent twice please ? They seem the same in both cases. Otherwise, I'm fine with those patches. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] usb: r8a66597: Fix initialization hub that using, R8A66597_MAX_ROOT_HUB
Hi, Thanks for your comment. (2014/04/17 23:07), Marek Vasut wrote: On Thursday, April 17, 2014 at 09:48:32 AM, yasuhisa umano wrote: This driver is processed as two USB hub despite one. The number of root hub is defined in R8A66597_MAX_ROOT_HUB. This fixes that register is accessed by using the definition of R8A66597_MAX_ROOT_HUB. Signed-off-by: Yasuhisa Umano yasuhisa.umano...@renesas.com --- drivers/usb/host/r8a66597-hcd.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/r8a66597-hcd.c b/drivers/usb/host/r8a66597-hcd.c index dfe5423..c58d2a9 100644 --- a/drivers/usb/host/r8a66597-hcd.c +++ b/drivers/usb/host/r8a66597-hcd.c @@ -164,8 +164,8 @@ static int enable_controller(struct r8a66597 *r8a66597) r8a66597_bset(r8a66597, INTL, SOFCFG); r8a66597_write(r8a66597, 0, INTENB0); - r8a66597_write(r8a66597, 0, INTENB1); - r8a66597_write(r8a66597, 0, INTENB2); + for (port = 0; port R8A66597_MAX_ROOT_HUB; port++) + r8a66597_write(r8a66597, 0, get_intenb_reg(port)); Hmm, looking at get_intenb_reg(), this is slightly dangerous, but I will trust you you know what you are doing . I am a bit worried someone might set R8A66597_MAX_ROOT_HUB to value 2 and will wonder why doesn't it work. I understood your point. Certainly, current　device drivers support only the initialization of 1 or 2 interrupt for hub. If this driver has a hub of more future, I will send the patch. Anyway, I will apply this and if you feel my rant is valid, submit subsequent patch. Thank you. Best regards, Marek Vasut Best regards, Yasuhisa ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] usb: r8a66597: Fix initilization size of r8a66597 info, structure
Hi, Thanks for your comment. (2014/04/17 23:09), Marek Vasut wrote: On Thursday, April 17, 2014 at 10:20:29 AM, yasuhisa umano wrote: Initialization of r8a66597 info structure is not enough. Because initilization was used size of pointer. This fixes that use size of r8a6659 info structure. Signed-off-by: Yasuhisa Umano yasuhisa.umano...@renesas.com --- drivers/usb/host/r8a66597-hcd.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/r8a66597-hcd.c b/drivers/usb/host/r8a66597-hcd.c index c58d2a9..8e82212 100644 --- a/drivers/usb/host/r8a66597-hcd.c +++ b/drivers/usb/host/r8a66597-hcd.c @@ -807,7 +807,7 @@ int usb_lowlevel_init(int index, enum usb_init_type init, void **controller) R8A66597_DPRINT(%s\n, __func__); - memset(r8a66597, 0, sizeof(r8a66597)); + memset(r8a66597, 0, sizeof(struct r8a66597)); Let's use sizeof(*r8a66597) instead . This is more scalable as you won't need to adjust this code when you change the data type of the *r8a66597 pointer, I will adjust that and apply with sizeof(*r8a66597); , does that work for you? Indeed. I will check your point and resend updated patch. Best regards, Marek Vasut Best regards, Yasuhisa ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2 v2] usb: r8a66597: Fix initilization size of r8a66597 info structure
Initialization of r8a66597 info structure is not enough. Because initilization was used size of pointer. This fixes that use size of r8a6659 info structure. Signed-off-by: Yasuhisa Umano yasuhisa.umano...@renesas.com --- v2 : Change from sizeof(struct r8a66597) to sizeof(*r8a66597) drivers/usb/host/r8a66597-hcd.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/r8a66597-hcd.c b/drivers/usb/host/r8a66597-hcd.c index c58d2a9..5114544 100644 --- a/drivers/usb/host/r8a66597-hcd.c +++ b/drivers/usb/host/r8a66597-hcd.c @@ -807,7 +807,7 @@ int usb_lowlevel_init(int index, enum usb_init_type init, void **controller) R8A66597_DPRINT(%s\n, __func__); - memset(r8a66597, 0, sizeof(r8a66597)); + memset(r8a66597, 0, sizeof(*r8a66597)); r8a66597-reg = CONFIG_R8A66597_BASE_ADDR; disable_controller(r8a66597); -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2 v2] usb: r8a66597: Fix initialization hub that using R8A66597_MAX_ROOT_HUB
This driver is processed as two USB hub despite one. The number of root hub is defined in R8A66597_MAX_ROOT_HUB. This fixes that register is accessed by using the definition of R8A66597_MAX_ROOT_HUB. Signed-off-by: Yasuhisa Umano yasuhisa.umano...@renesas.com --- v2 : No changes drivers/usb/host/r8a66597-hcd.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/r8a66597-hcd.c b/drivers/usb/host/r8a66597-hcd.c index dfe5423..c58d2a9 100644 --- a/drivers/usb/host/r8a66597-hcd.c +++ b/drivers/usb/host/r8a66597-hcd.c @@ -164,8 +164,8 @@ static int enable_controller(struct r8a66597 *r8a66597) r8a66597_bset(r8a66597, INTL, SOFCFG); r8a66597_write(r8a66597, 0, INTENB0); - r8a66597_write(r8a66597, 0, INTENB1); - r8a66597_write(r8a66597, 0, INTENB2); + for (port = 0; port R8A66597_MAX_ROOT_HUB; port++) + r8a66597_write(r8a66597, 0, get_intenb_reg(port)); r8a66597_bset(r8a66597, CONFIG_R8A66597_ENDIAN BIGEND, CFIFOSEL); r8a66597_bset(r8a66597, CONFIG_R8A66597_ENDIAN BIGEND, D0FIFOSEL); -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
