Re: [U-Boot] [PATCH] watchdog disable for socfpga
Hi Pavel,
On Tue, 2014-09-09 at 14:03 +0200, ZY - pavel wrote:
This adds watchdog disable. It is neccessary for running Linux kernel.
Signed-off-by: Pavel Machek pa...@denx.de
diff --git a/arch/arm/cpu/armv7/socfpga/reset_manager.c
b/arch/arm/cpu/armv7/socfpga/reset_manager.c
index e320c01..5503059 100644
--- a/arch/arm/cpu/armv7/socfpga/reset_manager.c
+++ b/arch/arm/cpu/armv7/socfpga/reset_manager.c
@@ -14,6 +14,19 @@ DECLARE_GLOBAL_DATA_PTR;
static const struct socfpga_reset_manager *reset_manager_base =
(void *)SOCFPGA_RSTMGR_ADDRESS;
+#define RSTMGR_PERMODRST_L4WD0_LSB 6
Would suggest to put this into header file.
Thanks
Chin Liang
+
+/* Disable the watchdog (toggle reset to watchdog) */
+void watchdog_disable(void)
+{
+ /* assert reset for watchdog */
+ setbits_le32(reset_manager_base-per_mod_reset,
+ (1RSTMGR_PERMODRST_L4WD0_LSB));
+ /* deassert watchdog from reset (watchdog in not running state) */
+ clrbits_le32(reset_manager_base-per_mod_reset,
+ (1RSTMGR_PERMODRST_L4WD0_LSB));
+}
+
/*
* Write the reset manager register to cause reset
*/
diff --git a/arch/arm/include/asm/arch-socfpga/reset_manager.h
b/arch/arm/include/asm/arch-socfpga/reset_manager.h
index 3e95476..eb95c5b 100644
--- a/arch/arm/include/asm/arch-socfpga/reset_manager.h
+++ b/arch/arm/include/asm/arch-socfpga/reset_manager.h
@@ -10,6 +10,8 @@
void reset_cpu(ulong addr);
void reset_deassert_peripherals_handoff(void);
+void watchdog_disable(void);
+
struct socfpga_reset_manager {
u32 status;
u32 ctrl;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] watchdog disable for socfpga
Hi Pavel, On Tue, 2014-09-09 at 15:09 +0200, ZY - pavel wrote: On Tue 2014-09-09 14:31:46, Marek Vasut wrote: On Tuesday, September 09, 2014 at 02:30:01 PM, Pavel Machek wrote: On Tue 2014-09-09 14:20:23, Marek Vasut wrote: On Tuesday, September 09, 2014 at 02:03:28 PM, Pavel Machek wrote: This adds watchdog disable. It is neccessary for running Linux kernel. Why do we not enable WDT in Linux instead ? Also, I recall there was a call to explicitly enable the L4 watchdog, so why do we not get rid of that instead ? Booting linux kernel without watchdog support should be valid operation. If you watchdog is enabled, then not so much. Also, why can we not just disable the WDT in U-Boot instead using a config option ? It seems that watchdog is enabled by default (by hardware or SPL), so yes, watchdog disable operation (and this patch) in u-boot is a good idea. If refer to http://rocketboards.org/gitweb/?p=u-boot-socfpga.git;a=blob_plain;f=arch/arm/cpu/armv7/socfpga/s_init.c;hb=fe010493a1754e761f77ba19243ba93a9d038443, its current disable during U-Boot initialization, s_init. Thanks Chin Liang Pavel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] watchdog disable for socfpga
On Friday, September 12, 2014 at 08:10:22 AM, Chin Liang See wrote: Hi Pavel, On Tue, 2014-09-09 at 14:03 +0200, ZY - pavel wrote: This adds watchdog disable. It is neccessary for running Linux kernel. Signed-off-by: Pavel Machek pa...@denx.de diff --git a/arch/arm/cpu/armv7/socfpga/reset_manager.c b/arch/arm/cpu/armv7/socfpga/reset_manager.c index e320c01..5503059 100644 --- a/arch/arm/cpu/armv7/socfpga/reset_manager.c +++ b/arch/arm/cpu/armv7/socfpga/reset_manager.c @@ -14,6 +14,19 @@ DECLARE_GLOBAL_DATA_PTR; static const struct socfpga_reset_manager *reset_manager_base = (void *)SOCFPGA_RSTMGR_ADDRESS; +#define RSTMGR_PERMODRST_L4WD0_LSB 6 Would suggest to put this into header file. Thanks I agree. We're currently working on a proper cleanup, so please give us a few days to prepare a series. 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] base addresses for more subsystems
On Tue, 2014-09-09 at 14:05 +0200, ZY - pavel wrote: Add base addresses for more subsystems. Signed-off-by: Pavel Machek pa...@denx.de diff --git a/arch/arm/include/asm/arch-socfpga/socfpga_base_addrs.h b/arch/arm/include/asm/arch-socfpga/socfpga_base_addrs.h index 2d3152d..39a7874 100644 --- a/arch/arm/include/asm/arch-socfpga/socfpga_base_addrs.h +++ b/arch/arm/include/asm/arch-socfpga/socfpga_base_addrs.h @@ -7,9 +7,15 @@ #ifndef _SOCFPGA_BASE_ADDRS_H_ #define _SOCFPGA_BASE_ADDRS_H_ +#define SOCFPGA_EMAC0_ADDRESS 0xff70 +#define SOCFPGA_EMAC1_ADDRESS 0xff702000 +#define SOCFPGA_SDMMC_ADDRESS 0xff704000 +#define SOCFPGA_FPGAMGRREGS_ADDRESS 0xff706000 #define SOCFPGA_L3REGS_ADDRESS 0xff80 +#define SOCFPGA_FPGAMGRDATA_ADDRESS 0xffb9 #define SOCFPGA_UART0_ADDRESS 0xffc02000 #define SOCFPGA_UART1_ADDRESS 0xffc03000 +#define SOCFPGA_SDR_ADDRESS 0xffc2 #define SOCFPGA_OSC1TIMER0_ADDRESS 0xffd0 #define SOCFPGA_L4WD0_ADDRESS 0xffd02000 #define SOCFPGA_CLKMGR_ADDRESS 0xffd04000 Acked-by: Chin Liang See cl...@altera.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] test: dfu: script: wrong md5sum on nand partitions
when uplaoding a file, at least from a nand partition, the complete
mtd nand partition size is transferred. This leads in a wrong md5sum
as the filesize is different between the downloaded file and the
uploaded file. Limit the uploaded filesize to the downloaded
fixes this.
Signed-off-by: Heiko Schocher h...@denx.de
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Stephen Warren swar...@nvidia.com
Cc: Roger Meier r.me...@siemens.com
---
Tested this on the siemens boards, with current ml I get:
Init script for generating data necessary for DFU test script OK
=
DFU EP0 transmission test program
Trouble shoot - disable DBG (even the KERN_DEBUG) in the UDC driver
@ - TRATS2 # dfu 0 mmc 0
=
File: dat_960.img
TX: md5sum:2947e8f573bc34ba3791f991bd2da869
RX: md5sum:cde0b2024d8ddb55eee9d4b51264ad67
--- FAILED
with this patch:
Init script for generating data necessary for DFU test script OK
=
DFU EP0 transmission test program
Trouble shoot - disable DBG (even the KERN_DEBUG) in the UDC driver
@ - TRATS2 # dfu 0 mmc 0
=
File: dat_960.img
TX: md5sum:2947e8f573bc34ba3791f991bd2da869
RX: md5sum:2947e8f573bc34ba3791f991bd2da869
--- OK
---
test/dfu/dfu_gadget_test.sh | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/test/dfu/dfu_gadget_test.sh b/test/dfu/dfu_gadget_test.sh
index 2f5b7db..5084a29 100755
--- a/test/dfu/dfu_gadget_test.sh
+++ b/test/dfu/dfu_gadget_test.sh
@@ -45,6 +45,7 @@ dfu_test_file () {
printf $COLOUR_GREEN
=
$COLOUR_DEFAULT\n
printf File:$COLOUR_GREEN %s $COLOUR_DEFAULT\n $1
+filesize=$(stat -c '%s' $1)
dfu-util -D $1 -a $TARGET_ALT_SETTING $LOG_FILE 21 || die $?
echo -n TX:
@@ -54,9 +55,11 @@ dfu_test_file () {
dfu-util -D ${DIR}/dfudummy.bin -a $TARGET_ALT_SETTING_B $LOG_FILE 21
|| die $?
+N_FILE_FULL=$DIR$RCV_DIR${1:2}_rcv_full
N_FILE=$DIR$RCV_DIR${1:2}_rcv
-dfu-util -U $N_FILE -a $TARGET_ALT_SETTING $LOG_FILE 21 || die $?
+dfu-util -U $N_FILE_FULL -a $TARGET_ALT_SETTING $LOG_FILE 21 || die $?
+dd if=$N_FILE_FULL of=$N_FILE bs=$filesize count=1 $LOG_FILE 21 ||
die $?
echo -n RX:
calculate_md5sum $N_FILE
--
1.8.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/2] mtd: nand: add Freescale vf610_nfc driver
On 11/09/2014 20:57, Bill Pringlemeir wrote: On 11 Sep 2014, ste...@agner.ch wrote: This adds initial support for Freescale NFC (NAND Flash Controller) found in ARM Vybrid SoC's, Power Architecture MPC5125 and others. The driver is called vf610_nfc since this is the first supported and tested hardware platform supported by the driver. Signed-off-by: Stefan Agner ste...@agner.ch Acked-by: Bill Pringlemeir bpringlem...@nbsps.com Thanks. I will merge it into u-boot-imx. 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 v4 1/6] nand: denali: add Denali NAND driver for SPL
Hi Masahiro,
On Fri, 2014-09-05 at 14:50 +0900, Masahiro Yamada wrote:
The SPL-mode driver for Denali(Cadence) NAND Flash Memory Controller IP.
This driver requires two CONFIG macros:
- CONFIG_SPL_NAND_DENALI
Define to enable this driver.
- CONFIG_SYS_NAND_BAD_BLOCK_POS
Specify bad block mark position in the oob space. Typically 0.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
Cc: Chin Liang See cl...@altera.com
Cc: Scott Wood scottw...@freescale.com
---
Changes in v4:
- Add a workaround to not depend on the Denali driver
posted by Chin Liang See.
This driver has been taking too long:
http://patchwork.ozlabs.org/patch/381305/
Yup, hopefully v10 would be the final patch.
Changes in v3: None
Changes in v2:
- Avoid unaligned access
- Replace a magic number 0x2000 with PIPELINE_ACCESS
drivers/mtd/nand/Makefile | 1 +
drivers/mtd/nand/denali_spl.c | 245
++
2 files changed, 246 insertions(+)
create mode 100644 drivers/mtd/nand/denali_spl.c
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index bf1312a..f90f9a0 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -12,6 +12,7 @@ NORMAL_DRIVERS=y
endif
obj-$(CONFIG_SPL_NAND_AM33XX_BCH) += am335x_spl_bch.o
+obj-$(CONFIG_SPL_NAND_DENALI) += denali_spl.o
obj-$(CONFIG_SPL_NAND_DOCG4) += docg4_spl.o
obj-$(CONFIG_SPL_NAND_SIMPLE) += nand_spl_simple.o
obj-$(CONFIG_SPL_NAND_LOAD) += nand_spl_load.o
diff --git a/drivers/mtd/nand/denali_spl.c b/drivers/mtd/nand/denali_spl.c
new file mode 100644
index 000..ab23743
--- /dev/null
+++ b/drivers/mtd/nand/denali_spl.c
@@ -0,0 +1,245 @@
+/*
+ * Copyright (C) 2014 Panasonic Corporation
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include common.h
+#include asm/io.h
+#include asm/unaligned.h
+#include linux/mtd/nand.h
+#if 0
+#include denali.h
+#else
+/* workaround until denali.h is merged */
+#define TRANSFER_SPARE_REG 0x10
+#define ECC_ENABLE 0xe0
+#define PAGES_PER_BLOCK 0x150
+#define DEVICE_MAIN_AREA_SIZE0x170
+#define DEVICE_SPARE_AREA_SIZE 0x180
+
+#define INTR_STATUS(__bank) (0x410 + ((__bank) * 0x50))
+#define INTR_STATUS__ECC_UNCOR_ERR 0x0001
+#define INTR_STATUS__LOAD_COMP 0x0040
+
+#define INDEX_CTRL_REG0x0
+#define INDEX_DATA_REG0x10
+#define MODE_010x0400
+#define MODE_100x0800
+#endif
+
+#define SPARE_ACCESS 0x41
+#define MAIN_ACCESS 0x42
+#define PIPELINE_ACCESS 0x2000
+
+#define BANK(x) ((x) 24)
+
+static void __iomem *denali_flash_mem =
+ (void __iomem *)CONFIG_SYS_NAND_DATA_BASE;
+static void __iomem *denali_flash_reg =
+ (void __iomem *)CONFIG_SYS_NAND_REGS_BASE;
+
+static const int flash_bank;
+static uint8_t page_buffer[NAND_MAX_PAGESIZE];
+static int page_size, oob_size, pages_per_block;
+
+static void index_addr(uint32_t address, uint32_t data)
+{
+ writel(address, denali_flash_mem + INDEX_CTRL_REG);
+ writel(data, denali_flash_mem + INDEX_DATA_REG);
+}
+
+static int wait_for_irq(uint32_t irq_mask)
+{
+ unsigned long timeout = 100;
+ uint32_t intr_status;
+
+ do {
+ intr_status = readl(denali_flash_reg + INTR_STATUS(flash_bank));
+
+ if (intr_status INTR_STATUS__ECC_UNCOR_ERR) {
+ debug(Uncorrected ECC detected\n);
+ return -EIO;
+ }
+
+ if (intr_status irq_mask)
+ break;
+
+ udelay(1);
+ timeout--;
+ } while (timeout);
+
+ if (!timeout) {
+ debug(Timeout with interrupt status %08x\n, intr_status);
+ return -EIO;
+ }
+
+ return 0;
+}
+
+static void read_data_from_flash_mem(uint8_t *buf, int len)
+{
+ int i;
+ uint32_t *buf32;
+
+ /* transfer the data from the flash */
+ buf32 = (uint32_t *)buf;
+
+ /*
+ * Let's take care of unaligned access although it rarely happens.
+ * Avoid put_unaligned() for the normal use cases since it leads to
+ * a bit performance regression.
+ */
+ if ((unsigned long)buf32 % 4) {
+ for (i = 0; i len / 4; i++)
+ put_unaligned(readl(denali_flash_mem + INDEX_DATA_REG),
+ buf32++);
+ } else {
+ for (i = 0; i len / 4; i++)
+ *buf32++ = readl(denali_flash_mem + INDEX_DATA_REG);
+ }
+
+ if (len % 4) {
+ u32 tmp;
+
+ tmp = cpu_to_le32(readl(denali_flash_mem + INDEX_DATA_REG));
+ buf = (uint8_t *)buf32;
+ for (i = 0; i len %
Re: [U-Boot] [PATCH] dw_mmc: cleanups
Hi,
On Thu, 2014-09-11 at 11:06 +0900, Jaehoon Chung wrote:
Hi, Pavel.
It looks good to me.
If you're ok, can i suggest one thing?
On 09/05/2014 07:49 PM, Pavel Machek wrote:
dw_mmc driver was responding to errors with debug(). Change that to
prinf so that any errors are immediately obvious. Also adjust english
in comments.
Signed-off-by: Pavel Machek pa...@denx.de
diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 0df30bc..4c16e7f 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -260,7 +262,7 @@ static int dwmci_setup_bus(struct dwmci_host *host, u32
freq)
do {
status = dwmci_readl(host, DWMCI_CMD);
if (timeout-- 0) {
- printf(TIMEOUT error!!\n);
+ printf(dwmci_setup_bus: timeout!\n);
return -ETIMEDOUT;
}
} while (status DWMCI_CMD_START);
@@ -275,7 +277,7 @@ static int dwmci_setup_bus(struct dwmci_host *host, u32
freq)
do {
status = dwmci_readl(host, DWMCI_CMD);
if (timeout-- 0) {
- printf(TIMEOUT error!!\n);
+ printf(dwmci_setup_bus: timeout!\n);
According to your the main purpose, this patch is goal that noticed
where/what error is occurred.
Then i think good that add the __LINE__.
Because there are same message like dwmci_setup_bus: tiemout!\n at some
place.
Then i think we don't need to discuss about this patch with Marek. :)
This patch looks good except need to distinguish the error location as
pointed by Jaehoon.
Thanks
Chin Liang
Best Regards,
Jaehoon Chung
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/t4rdb: Add support of CPLD
This support of CPLD includes
- Files and register definitions
- Command to switch alternate bank
- Command to switch default bank
Signed-off-by: Chunhe Lan chunhe@freescale.com
---
board/freescale/t4rdb/Makefile |1 +
board/freescale/t4rdb/cpld.c | 136 ++
board/freescale/t4rdb/cpld.h | 49 ++
board/freescale/t4rdb/law.c |3 +
board/freescale/t4rdb/t4240rdb.c | 12
board/freescale/t4rdb/tlb.c |5 ++
include/configs/T4240RDB.h | 23 +++
7 files changed, 229 insertions(+), 0 deletions(-)
create mode 100644 board/freescale/t4rdb/cpld.c
create mode 100644 board/freescale/t4rdb/cpld.h
diff --git a/board/freescale/t4rdb/Makefile b/board/freescale/t4rdb/Makefile
index f7f7fc0..3886e3d 100644
--- a/board/freescale/t4rdb/Makefile
+++ b/board/freescale/t4rdb/Makefile
@@ -5,6 +5,7 @@
#
obj-$(CONFIG_T4240RDB) += t4240rdb.o
+obj-y += cpld.o
obj-y += ddr.o
obj-y += eth.o
obj-$(CONFIG_PCI) += pci.o
diff --git a/board/freescale/t4rdb/cpld.c b/board/freescale/t4rdb/cpld.c
new file mode 100644
index 000..d5f3812
--- /dev/null
+++ b/board/freescale/t4rdb/cpld.c
@@ -0,0 +1,136 @@
+/**
+ * Copyright 2014 Freescale Semiconductor
+ *
+ * Author: Chunhe Lan chunhe@freescale.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ *
+ * This file provides support for the board-specific CPLD used on some
Freescale
+ * reference boards.
+ *
+ * The following macros need to be defined:
+ *
+ * CONFIG_SYS_CPLD_BASE - The virtual address of the base of the
+ * CPLD register map
+ *
+ */
+
+#include common.h
+#include command.h
+#include asm/io.h
+
+#include cpld.h
+
+u8 cpld_read(unsigned int reg)
+{
+ void *p = (void *)CONFIG_SYS_CPLD_BASE;
+
+ return in_8(p + reg);
+}
+
+void cpld_write(unsigned int reg, u8 value)
+{
+ void *p = (void *)CONFIG_SYS_CPLD_BASE;
+
+ out_8(p + reg, value);
+}
+
+/**
+ * Set the boot bank to the alternate bank
+ */
+void cpld_set_altbank(void)
+{
+ u8 val, curbank, altbank, override;
+
+ val = CPLD_READ(vbank);
+ curbank = val CPLD_BANK_SEL_MASK;
+
+ switch (curbank) {
+ case CPLD_SELECT_BANK0:
+ altbank = CPLD_SELECT_BANK4;
+ CPLD_WRITE(vbank, altbank);
+ override = CPLD_READ(software_on);
+ CPLD_WRITE(software_on, override | CPLD_BANK_SEL_EN);
+ CPLD_WRITE(sys_reset, CPLD_SYSTEM_RESET);
+ break;
+ case CPLD_SELECT_BANK4:
+ altbank = CPLD_SELECT_BANK0;
+ CPLD_WRITE(vbank, altbank);
+ override = CPLD_READ(software_on);
+ CPLD_WRITE(software_on, override | CPLD_BANK_SEL_EN);
+ CPLD_WRITE(sys_reset, CPLD_SYSTEM_RESET);
+ break;
+ default:
+ printf(CPLD Altbank Fail: Invalid value!\n);
+ return;
+ }
+}
+
+/**
+ * Set the boot bank to the default bank
+ */
+void cpld_set_defbank(void)
+{
+ u8 val;
+
+ val = CPLD_DEFAULT_BANK;
+
+ CPLD_WRITE(global_reset, val);
+}
+
+#ifdef DEBUG
+static void cpld_dump_regs(void)
+{
+ printf(chip_id1= 0x%02x\n, CPLD_READ(chip_id1));
+ printf(chip_id2= 0x%02x\n, CPLD_READ(chip_id2));
+ printf(sw_maj_ver = 0x%02x\n, CPLD_READ(sw_maj_ver));
+ printf(sw_min_ver = 0x%02x\n, CPLD_READ(sw_min_ver));
+ printf(hw_ver = 0x%02x\n, CPLD_READ(hw_ver));
+ printf(software_on = 0x%02x\n, CPLD_READ(software_on));
+ printf(cfg_rcw_src = 0x%02x\n, CPLD_READ(cfg_rcw_src));
+ printf(res0= 0x%02x\n, CPLD_READ(res0));
+ printf(vbank = 0x%02x\n, CPLD_READ(vbank));
+ printf(sw1_sysclk = 0x%02x\n, CPLD_READ(sw1_sysclk));
+ printf(sw2_status = 0x%02x\n, CPLD_READ(sw2_status));
+ printf(sw3_status = 0x%02x\n, CPLD_READ(sw3_status));
+ printf(sw4_status = 0x%02x\n, CPLD_READ(sw4_status));
+ printf(sys_reset = 0x%02x\n, CPLD_READ(sys_reset));
+ printf(global_reset= 0x%02x\n, CPLD_READ(global_reset));
+ printf(res1= 0x%02x\n, CPLD_READ(res1));
+ putc('\n');
+}
+#endif
+
+#ifndef CONFIG_SPL_BUILD
+int do_cpld(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ int rc = 0;
+
+ if (argc = 1)
+ return cmd_usage(cmdtp);
+
+ if (strcmp(argv[1], reset) == 0) {
+ if (strcmp(argv[2], altbank) == 0)
+ cpld_set_altbank();
+ else
+ cpld_set_defbank();
+#ifdef DEBUG
+ } else if (strcmp(argv[1], dump) == 0) {
+ cpld_dump_regs();
+#endif
+ } else
+ rc = cmd_usage(cmdtp);
+
+ return rc;
+}
+
+U_BOOT_CMD(
+ cpld, CONFIG_SYS_MAXARGS, 1, do_cpld,
+ Reset the board or alternate bank,
+ reset - reset to default bank\n
+
Re: [U-Boot] [PATCH] sort drivers/mmc/Makefile
On Tue, 2014-09-09 at 15:16 +0200, ZY - pavel wrote: Sort drivers/mmc makefile, as requested by wd. Signed-off-by: Pavel Machek pa...@denx.de diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile index 464cee1..461d7d8 100644 --- a/drivers/mmc/Makefile +++ b/drivers/mmc/Makefile @@ -5,37 +5,39 @@ # SPDX-License-Identifier: GPL-2.0+ # +obj-$(CONFIG_ARM_PL180_MMCI) += arm_pl180_mmci.o +obj-$(CONFIG_BCM2835_SDHCI) += bcm2835_sdhci.o obj-$(CONFIG_BFIN_SDH) += bfin_sdh.o obj-$(CONFIG_DAVINCI_MMC) += davinci_mmc.o +obj-$(CONFIG_DWMMC) += dw_mmc.o +obj-$(CONFIG_EXYNOS_DWMMC) += exynos_dw_mmc.o obj-$(CONFIG_FSL_ESDHC) += fsl_esdhc.o obj-$(CONFIG_FTSDC010) += ftsdc010_mci.o obj-$(CONFIG_FTSDC021) += ftsdc021_sdhci.o obj-$(CONFIG_GENERIC_MMC) += mmc.o obj-$(CONFIG_GENERIC_ATMEL_MCI) += gen_atmel_mci.o +obj-$(CONFIG_KONA_SDHCI) += kona_sdhci.o obj-$(CONFIG_MMC_SPI) += mmc_spi.o -obj-$(CONFIG_ARM_PL180_MMCI) += arm_pl180_mmci.o +obj-$(CONFIG_MMC_SUNXI) += sunxi_mmc.o obj-$(CONFIG_MV_SDHCI) += mv_sdhci.o +obj-$(CONFIG_MVEBU_MMC) += mvebu_mmc.o obj-$(CONFIG_MXC_MMC) += mxcmmc.o obj-$(CONFIG_MXS_MMC) += mxsmmc.o obj-$(CONFIG_OMAP_HSMMC) += omap_hsmmc.o obj-$(CONFIG_PXA_MMC_GENERIC) += pxa_mmc_gen.o -obj-$(CONFIG_SDHCI) += sdhci.o -obj-$(CONFIG_BCM2835_SDHCI) += bcm2835_sdhci.o -obj-$(CONFIG_KONA_SDHCI) += kona_sdhci.o +obj-$(CONFIG_SUPPORT_EMMC_RPMB) += rpmb.o obj-$(CONFIG_S3C_SDI) += s3c_sdi.o obj-$(CONFIG_S5P_SDHCI) += s5p_sdhci.o +obj-$(CONFIG_SDHCI) += sdhci.o obj-$(CONFIG_SH_MMCIF) += sh_mmcif.o +obj-$(CONFIG_SOCFPGA_DWMMC) += socfpga_dw_mmc.o obj-$(CONFIG_SPEAR_SDHCI) += spear_sdhci.o obj-$(CONFIG_TEGRA_MMC) += tegra_mmc.o -obj-$(CONFIG_DWMMC) += dw_mmc.o -obj-$(CONFIG_EXYNOS_DWMMC) += exynos_dw_mmc.o -obj-$(CONFIG_MMC_SUNXI) += sunxi_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 obj-$(CONFIG_GENERIC_MMC) += mmc_write.o endif -obj-$(CONFIG_MVEBU_MMC) += mvebu_mmc.o + Acked-by: Chin Liang See cl...@altera.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] imx: ddr: Move mx6q_4x_mt41j128.cfg to mx6sabresd board dir
Hi everybody, On 02/09/2014 01:51, Fabio Estevam wrote: On Mon, Sep 1, 2014 at 8:34 PM, Eric Nelson eric.nel...@boundarydevices.com wrote: I believe that the Wand board is using the configuration files from the nitrogen6x tree. Yes, I should have said As it stands today only mx6qsabresd and congatec share the same mx6q_4x_mt41j128.cfg script. I try to sumarize the result of the discussion. This file was factorized, but it was proofed that calibration data are very board specific, and factorizing this file is not correct. I agree with Fabio and Eric that it is very unlike to have the same calibration data for different boards and the reuse of the same data is not correct. However, with this statement the patch should also unbind the congatec board from the sabresd, not only change the reference. A congatec specific board must be also created in congatec/cgtqmx6eval, and it is only a case that it has the same values of the sabresd. 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 v4 1/2] mtd: nand: add Freescale vf610_nfc driver
Hi Stefan, On 11/09/2014 15:07, Stefan Agner wrote: This adds initial support for Freescale NFC (NAND Flash Controller) found in ARM Vybrid SoC's, Power Architecture MPC5125 and others. The driver is called vf610_nfc since this is the first supported and tested hardware platform supported by the driver. Signed-off-by: Stefan Agner ste...@agner.ch --- By applying I have seen some other minor issues. checkpatch reports some warnings, can you fix them ? WARNING: line over 80 characters #200: FILE: drivers/mtd/nand/vf610_nfc.c:157: +#define mtd_to_nfc(_mtd) (struct vf610_nfc *)((struct nand_chip *)_mtd-priv)-priv; CHECK: Alignment should match open parenthesis #367: FILE: drivers/mtd/nand/vf610_nfc.c:324: + vf610_nfc_set_field(mtd, NFC_COL_ADDR, COL_ADDR_MASK, + COL_ADDR_SHIFT, column); CHECK: Alignment should match open parenthesis #371: FILE: drivers/mtd/nand/vf610_nfc.c:328: + vf610_nfc_set_field(mtd, NFC_ROW_ADDR, ROW_ADDR_MASK, + ROW_ADDR_SHIFT, page); CHECK: Alignment should match open parenthesis #388: FILE: drivers/mtd/nand/vf610_nfc.c:345: + vf610_nfc_send_commands(nfc-regs, NAND_CMD_SEQIN, +command, PROGRAM_PAGE_CMD_CODE); CHECK: Alignment should match open parenthesis #409: FILE: drivers/mtd/nand/vf610_nfc.c:366: + vf610_nfc_send_commands(nfc-regs, NAND_CMD_READ0, + NAND_CMD_READSTART, READ_PAGE_CMD_CODE); CHECK: Alignment should match open parenthesis #417: FILE: drivers/mtd/nand/vf610_nfc.c:374: + vf610_nfc_send_commands(nfc-regs, command, + NAND_CMD_ERASE2, ERASE_CMD_CODE); WARNING: line over 80 characters #428: FILE: drivers/mtd/nand/vf610_nfc.c:385: + vf610_nfc_send_command(nfc-regs, command, STATUS_READ_CMD_CODE); WARNING: line over 80 characters #460: FILE: drivers/mtd/nand/vf610_nfc.c:417: + vf610_nfc_memcpy(buf, nfc-regs + NFC_MAIN_AREA(0) + c, l); CHECK: Alignment should match open parenthesis #668: FILE: drivers/mtd/nand/vf610_nfc.c:625: + vf610_nfc_set_field(mtd, NFC_FLASH_CONFIG, + CONFIG_ECC_MODE_MASK, CHECK: Alignment should match open parenthesis #690: FILE: drivers/mtd/nand/vf610_nfc.c:647: + vf610_nfc_set_field(mtd, NFC_FLASH_CONFIG, CONFIG_PAGE_CNT_MASK, + CONFIG_PAGE_CNT_SHIFT, 1); CHECK: Alignment should match open parenthesis #694: FILE: drivers/mtd/nand/vf610_nfc.c:651: + vf610_nfc_set_field(mtd, NFC_FLASH_CONFIG, + CONFIG_ECC_SRAM_ADDR_MASK, CHECK: Alignment should match open parenthesis #737: FILE: drivers/mtd/nand/vf610_nfc.c:694: + vf610_nfc_set_field(mtd, NFC_FLASH_CONFIG, + CONFIG_ECC_MODE_MASK, drivers/mtd/nand/Makefile| 1 + drivers/mtd/nand/vf610_nfc.c | 721 +++ 2 files changed, 722 insertions(+) create mode 100644 drivers/mtd/nand/vf610_nfc.c diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index bf1312a..eef86d1 100644 --- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -51,6 +51,7 @@ obj-$(CONFIG_NAND_KB9202) += kb9202_nand.o obj-$(CONFIG_NAND_KIRKWOOD) += kirkwood_nand.o obj-$(CONFIG_NAND_KMETER1) += kmeter1_nand.o obj-$(CONFIG_NAND_MPC5121_NFC) += mpc5121_nfc.o +obj-$(CONFIG_NAND_VF610_NFC) += vf610_nfc.o obj-$(CONFIG_NAND_MXC) += mxc_nand.o obj-$(CONFIG_NAND_MXS) += mxs_nand.o obj-$(CONFIG_NAND_NDFC) += ndfc.o diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c new file mode 100644 index 000..f0eba9a --- /dev/null +++ b/drivers/mtd/nand/vf610_nfc.c @@ -0,0 +1,721 @@ +/* + * Copyright 2009-2014 Freescale Semiconductor, Inc. and others + * + * Description: MPC5125, VF610, MCF54418 and Kinetis K70 Nand driver. + * Ported to U-Boot by Stefan Agner + * Based on RFC driver posted on Kernel Mailing list by Bill Pringlemeir + * Jason ported to M54418TWR and MVFA5. + * Authors: Stefan Agner stefan.ag...@toradex.com + * Bill Pringlemeir bpringlem...@nbsps.com + * Shaohui Xie b21...@freescale.com + * Jason Jin jason@freescale.com + * + * Based on original driver mpc5121_nfc.c. + * + * This 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. + * + * Limitations: + * - Untested on MPC5125 and M54418. + * - DMA not used. + * - 2K pages or less. + * - Only 2K page w. 64+OOB and hardware ECC. + */ + +#include common.h +#include malloc.h + +#include linux/mtd/mtd.h +#include linux/mtd/nand.h +#include linux/mtd/partitions.h + +#include nand.h +#include errno.h +#include asm/io.h + +/*
Re: [U-Boot] [PATCH v4 1/6] nand: denali: add Denali NAND driver for SPL
Hi.
Changes in v4:
- Add a workaround to not depend on the Denali driver
posted by Chin Liang See.
This driver has been taking too long:
http://patchwork.ozlabs.org/patch/381305/
Yup, hopefully v10 would be the final patch.
I hope so.
+static int nand_block_isbad(int block)
+{
+ int ret;
+
+ ret = nand_read_oob(page_buffer, block * pages_per_block);
+ if (ret 0)
+ return ret;
+
+ return page_buffer[CONFIG_SYS_NAND_BAD_BLOCK_POS] != 0xff;
+}
+
+/* nand_init() - initialize data to make nand usable by SPL */
+void nand_init(void)
+{
+ /* access to main area */
+ writel(0, denali_flash_reg + TRANSFER_SPARE_REG);
+
+ page_size = readl(denali_flash_reg + DEVICE_MAIN_AREA_SIZE);
+ oob_size = readl(denali_flash_reg + DEVICE_SPARE_AREA_SIZE);
+ pages_per_block = readl(denali_flash_reg + PAGES_PER_BLOCK);
I believe this will work for ONFI NAND devices only.
For non-ONFI, the value might not correct.
I don't think so.
It depends on the hardware; in my understanding
Denali IP is capable of detecting MAIN_AREA_SIZE etc.
for non-ONFI devices. At least this is working with non-ONFI devices
on some Panasonic boards.
If it does not work for Altera SoCs (and if you are planning to use
this driver), these three registers should be set in advance
in an earlier board init.
+}
+
+int nand_spl_load_image(uint32_t offs, unsigned int size, void *dst)
+{
+ int block, page, column, readlen;
+ int ret;
+ int force_bad_block_check = 1;
+
+ page = offs / page_size;
+ column = offs % page_size;
+
+ block = page / pages_per_block;
+ page = page % pages_per_block;
+
+ while (size) {
I believe we need to error out when reading beyond last block.
How do you know the number of blocks of non-ONFI devices?
Scan nand_ids.c for SPL?
+ if (force_bad_block_check || page == 0) {
+ ret = nand_block_isbad(block);
+ if (ret 0)
+ return ret;
+
+ if (ret) {
+ block++;
+ continue;
+ }
+ }
+
+ force_bad_block_check = 0;
I believe we still need to check the subsequent block whether is bad or
not too. This can be enable when cross the block boundary.
I am afraid you are misunderstanding my code.
This function does bad block checking for every block.
Here,
if (force_bad_block_check || page == 0) {
ret = nand_block_isbad(block);
page == 0 means the beginning of each block.
Currently U-Boot has drivers/mtd/nand/nand_spl_simple.c which handling
the SPL NAND image load. Wonder this driver will be integrated into
nand_spl_simple.c once drivers/mtd/nand/denali.c is applied?
I am not planning to do so because:
[1] nand_spl_simple.c requires CONFIG_SYS_NAND_BLOCK_SIZE,
CONFIG_SYS_NAND_PAGE_SIZE,
CONFIG_SYS_NAND_PAGE_COUNT; we need to specify the device attributes at
compilation,
which the Denali IP is able to detect at run time.
It is not acceptable for us because we need (want) the run time configuration.
[2] nand_spl_simple.c is so generic that it cannot use the hardware
acceleration of
the Denali IP, that is, slower booting.
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] imx: imx6q/dlsabreauto: Add PMIC Pfuze100 support
Hi Ye,
On 10/09/2014 07:52, Ye.Li wrote:
Initialize the Pfuze100 at board late init.
Signed-off-by: Ye.Li b37...@freescale.com
---
board/freescale/mx6qsabreauto/mx6qsabreauto.c | 52
-
include/configs/mx6qsabreauto.h |6 +++
2 files changed, 57 insertions(+), 1 deletions(-)
diff --git a/board/freescale/mx6qsabreauto/mx6qsabreauto.c
b/board/freescale/mx6qsabreauto/mx6qsabreauto.c
index bfb9b6a..76b024b 100644
--- a/board/freescale/mx6qsabreauto/mx6qsabreauto.c
+++ b/board/freescale/mx6qsabreauto/mx6qsabreauto.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2012 Freescale Semiconductor, Inc.
+ * Copyright (C) 2012-2014 Freescale Semiconductor, Inc.
*
* Author: Fabio Estevam fabio.este...@freescale.com
*
@@ -23,6 +23,8 @@
#include netdev.h
#include asm/arch/sys_proto.h
#include i2c.h
+#include power/pmic.h
+#include power/pfuze100_pmic.h
DECLARE_GLOBAL_DATA_PTR;
@@ -43,6 +45,8 @@ DECLARE_GLOBAL_DATA_PTR;
#define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
+#define I2C_PMIC 1
+
int dram_init(void)
{
gd-ram_size = (phys_size_t)CONFIG_DDR_MB * 1024 * 1024;
@@ -259,6 +263,51 @@ int board_init(void)
return 0;
}
+static int pfuze_init(void)
+{
+ struct pmic *p;
+ int ret;
+ unsigned int reg;
+
+ ret = power_pfuze100_init(I2C_PMIC);
+ if (ret)
+ return ret;
+
+ p = pmic_get(PFUZE100);
+ ret = pmic_probe(p);
+ if (ret)
+ return ret;
+
+ pmic_reg_read(p, PFUZE100_DEVICEID, reg);
+ printf(PMIC: PFUZE100 ID=0x%02x\n, reg);
+
+ /* Set SW1AB stanby volage to 0.975V */
+ pmic_reg_read(p, PFUZE100_SW1ABSTBY, reg);
+ reg = ~0x3f;
+ reg |= 0x1b;
+ pmic_reg_write(p, PFUZE100_SW1ABSTBY, reg);
+
+ /* Set SW1AB/VDDARM step ramp up time from 16us to 4us/25mV */
+ pmic_reg_read(p, PUZE_100_SW1ABCONF, reg);
+ reg = ~0xc0;
+ reg |= 0x40;
+ pmic_reg_write(p, PUZE_100_SW1ABCONF, reg);
+
+ /* Set SW1C standby voltage to 0.975V */
+ pmic_reg_read(p, PFUZE100_SW1CSTBY, reg);
+ reg = ~0x3f;
+ reg |= 0x1b;
+ pmic_reg_write(p, PFUZE100_SW1CSTBY, reg);
+
+ /* Set SW1C/VDDSOC step ramp up time from 16us to 4us/25mV */
+ pmic_reg_read(p, PFUZE100_SW1CCONF, reg);
+ reg = ~0xc0;
+ reg |= 0x40;
+ pmic_reg_write(p, PFUZE100_SW1CCONF, reg);
+
+ return 0;
+}
The initialization, with the exception of VGEN3/VGEN5, is identical to
the sabresd. Any possibility to improve code and factorize the function
for sabre* boards ?
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 0/8] samsung: Use common config files with Samsung boards (help wanted)
Hello Simon, On 09/09/2014 12:31 PM, Przemyslaw Marczak wrote: Hi, I will test this patch set on a trats2 board - today evening. On 09/09/2014 08:05 AM, Simon Glass wrote: Hi Minkyu, On 25 July 2014 08:43, Simon Glass s...@chromium.org wrote: Hi Lucasz, On 24 July 2014 09:34, Lukasz Majewski l.majew...@samsung.com wrote: Hi Simon, This series tries to unify the Samsung board configs into a few header files for exynos5 and exynos5. The purpose is to make it easier to move to driver model. In that case I would like things like the GPIO drivers and serial drivers to work in a standard way, and not need to support device tree and platform data at the same time. That would be quite painful. Another reason is that the Chrome OS EC drivers are currently included in boards that don't have a Chrome OS EC. This concern was raised by the Samsung maintainer (Minkyu) a while back. There are still a few boards that don't use CONFIG_OF_CONTROL so I have updated these with the most rudimentary of device tree files. Unfortunately I don't have boards for most of these (for testing) and I am hoping that the maintainers can come to the rescue and fix up any patches that have problems. I am also worried that I have used a common exynos file for things like smdkv310, when in fact they have some other chip in common. So maintainers, please can you test this and re-issue the patch, or make comments on my attempts? We will do our best to test our Exynos4 based boards. Thanks - please feel free to re-issue the patches and I will drop mine (if you cc me). Can you please review this series? We are already at rc2. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Best regards, It works fine on trats2. I'm currently working on PMIC framework at the top of your u-boot-dm/working branch and it also works fine on Trats2. Best regards -- Przemyslaw Marczak Samsung RD Institute Poland Samsung Electronics p.marc...@samsung.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] imx: Support i.MX6 High Assurance Boot authentication
Hi Nitin,
On 04/09/2014 03:18, Nitin Garg wrote:
When CONFIG_SECURE_BOOT is enabled, the signed images
like kernel and dtb can be authenticated using iMX6 CAAM.
The added command hab_auth_img can be used for HAB
authentication of images. The command takes the image
DDR location, IVT (Image Vector Table) offset inside
image as parameters. Detailed info about signing images
can be found in Freescale AppNote AN4581.
Signed-off-by: Nitin Garg nitin.g...@freescale.com
---
Changes in v3:
- Remove typecast of get_cpu_rev since its not required
Changes in v2:
- Cleaned up clock code as per review comments
- Removed dead code as per review comments
- Re-written commit log as per review comments
arch/arm/cpu/armv7/mx6/clock.c| 32 ++-
arch/arm/cpu/armv7/mx6/hab.c | 165
-
arch/arm/cpu/armv7/mx6/soc.c | 15 +++
arch/arm/include/asm/arch-mx6/clock.h |4 +
4 files changed, 214 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
index 820b8d5..db6a8fc 100644
--- a/arch/arm/cpu/armv7/mx6/clock.c
+++ b/arch/arm/cpu/armv7/mx6/clock.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2010-2011 Freescale Semiconductor, Inc.
+ * Copyright (C) 2010-2014 Freescale Semiconductor, Inc.
*
* SPDX-License-Identifier: GPL-2.0+
*/
@@ -543,6 +543,36 @@ int enable_pcie_clock(void)
BM_ANADIG_PLL_ENET_ENABLE_PCIE);
}
+#ifdef CONFIG_SECURE_BOOT
+void hab_caam_clock_enable(void)
+{
+ struct mxc_ccm_reg *const imx_ccm =
+ (struct mxc_ccm_reg *)CCM_BASE_ADDR;
+
+ /*CG4 ~ CG6, enable CAAM clocks*/
+ setbits_le32(imx_ccm-CCGR0, MXC_CCM_CCGR0_CAAM_WRAPPER_IPG_MASK |
+ MXC_CCM_CCGR0_CAAM_WRAPPER_ACLK_MASK |
+ MXC_CCM_CCGR0_CAAM_SECURE_MEM_MASK);
+
+ /* Enable EMI slow clk */
+ setbits_le32(imx_ccm-CCGR6, MXC_CCM_CCGR6_EMI_SLOW_MASK);
+}
+
+void hab_caam_clock_disable(void)
+{
+ struct mxc_ccm_reg *const imx_ccm =
+ (struct mxc_ccm_reg *)CCM_BASE_ADDR;
+
+ /*CG4 ~ CG6, disable CAAM clocks*/
+ clrbits_le32(imx_ccm-CCGR0, MXC_CCM_CCGR0_CAAM_WRAPPER_IPG_MASK |
+ MXC_CCM_CCGR0_CAAM_WRAPPER_ACLK_MASK |
+ MXC_CCM_CCGR0_CAAM_SECURE_MEM_MASK);
+
+ /* Disable EMI slow clk */
+ clrbits_le32(imx_ccm-CCGR6, MXC_CCM_CCGR6_EMI_SLOW_MASK);
+}
+#endif
Generally, we have in clock.c one function per clock, getting as
enable_uart_clkparameter a boolean for enabling/disabling (i.e.
enable_ocotp_clk(), enable_uart_clk(),...)
Please stick with the same rule.
+
unsigned int mxc_get_clock(enum mxc_clock clk)
{
switch (clk) {
diff --git a/arch/arm/cpu/armv7/mx6/hab.c b/arch/arm/cpu/armv7/mx6/hab.c
index f6810a6..61a94a1 100644
--- a/arch/arm/cpu/armv7/mx6/hab.c
+++ b/arch/arm/cpu/armv7/mx6/hab.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2010-2013 Freescale Semiconductor, Inc.
+ * Copyright (C) 2010-2014 Freescale Semiconductor, Inc.
*
* SPDX-License-Identifier:GPL-2.0+
*/
@@ -7,8 +7,12 @@
#include common.h
#include asm/io.h
#include asm/arch/hab.h
+#include asm/arch/clock.h
#include asm/arch/sys_proto.h
+/* HAB (High Assurance Boot) debug */
+#undef DEBUG_AUTHENTICATE_IMAGE
This is never defined, you do not need to undefine it.
+
/* start of HAB API updates */
#define hab_rvt_report_event_p \
@@ -71,6 +75,41 @@
((hab_rvt_exit_t *)HAB_RVT_EXIT)\
)
+#define IVT_SIZE 0x20
+#define ALIGN_SIZE 0x1000
+#define CSF_PAD_SIZE 0x2000
+
+/*
+ * ++ 0x0 (DDR_UIMAGE_START) -
+ * | Header | |
+ * ++ 0x40|
+ * || |
+ * || |
+ * || |
+ * || |
+ * | Image Data | |
+ * .| |
+ * .|Stuff to be authenticated +
+ * .| ||
+ * || ||
+ * || ||
+ * ++ ||
+ * || ||
+ * | Fill Data | ||
+ * || ||
+ * ++ Align to ALIGN_SIZE ||
+ * |IVT | ||
Re: [U-Boot] [PATCH 1/2] SPI: mxc_spi: remove second reset from ECSPI config handler
Hi Markus, On 01/09/2014 10:46, Markus Niebel wrote: From: Markus Niebel markus.nie...@tq-group.com the second reset prevents other registers to be written. This will prevent to have the correct signal levels for SCLK before writing to the config reg in spi_xchg_single. Tested with GPIO based chipselect and SPI_MODE_3 on i.MX6S Signed-off-by: Markus Niebel markus.nie...@tq-group.com --- drivers/spi/mxc_spi.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c index 2d5f385..6a05d15 100644 --- a/drivers/spi/mxc_spi.c +++ b/drivers/spi/mxc_spi.c @@ -163,9 +163,6 @@ static s32 spi_cfg_mxc(struct mxc_spi_slave *mxcs, unsigned int cs, reg_ctrl = (reg_ctrl ~MXC_CSPICTRL_POSTDIV(0x0F)) | MXC_CSPICTRL_POSTDIV(post_div); - /* We need to disable SPI before changing registers */ - reg_ctrl = ~MXC_CSPICTRL_EN; - if (mode SPI_CS_HIGH) ss_pol = 1; Acked-by: Stefano Babic sba...@denx.de Jagannadha, this series is currently assigned to me in patchwork. Should I merge into u-boot-imx or do you prefer to merge the two patches into u-boot-spi ? 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 1/2] SPI: mxc_spi: remove second reset from ECSPI config handler
I will pick! On 12 September 2014 14:20, Stefano Babic sba...@denx.de wrote: Hi Markus, On 01/09/2014 10:46, Markus Niebel wrote: From: Markus Niebel markus.nie...@tq-group.com the second reset prevents other registers to be written. This will prevent to have the correct signal levels for SCLK before writing to the config reg in spi_xchg_single. Tested with GPIO based chipselect and SPI_MODE_3 on i.MX6S Signed-off-by: Markus Niebel markus.nie...@tq-group.com --- drivers/spi/mxc_spi.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c index 2d5f385..6a05d15 100644 --- a/drivers/spi/mxc_spi.c +++ b/drivers/spi/mxc_spi.c @@ -163,9 +163,6 @@ static s32 spi_cfg_mxc(struct mxc_spi_slave *mxcs, unsigned int cs, reg_ctrl = (reg_ctrl ~MXC_CSPICTRL_POSTDIV(0x0F)) | MXC_CSPICTRL_POSTDIV(post_div); - /* We need to disable SPI before changing registers */ - reg_ctrl = ~MXC_CSPICTRL_EN; - if (mode SPI_CS_HIGH) ss_pol = 1; Acked-by: Stefano Babic sba...@denx.de Jagannadha, this series is currently assigned to me in patchwork. Should I merge into u-boot-imx or do you prefer to merge the two patches into u-boot-spi ? 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 = -- Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/1] net: dns: fix for DNS queries sent to the wrong MAC address
When a DNS query is sent out, the ethernet packet can get directed to the MAC address of a server that was communicated to before. This is wrong when the previously stored MAC address corresponds to a different server's IP address, i.e. when the IP address of the previous and the current communication are different. The error can get reproduced by running a sequence of e.g. a TFTP download and a DNS query, where the TFTP and DNS servers reside on individual machines. The fix is to clear the server's MAC address that might be left from a previous operation, and to fetch the peer's MAC address in a new ARP lookup, before the DNS query is sent. This is the approach taken in other network services, like 8e52533d1095 (net: tftpsrv: Get correct client MAC address). Reported-by: Dirk Zimoch dirk.zim...@psi.ch Signed-off-by: Gerhard Sittig g...@denx.de --- This patch suffers from a checkpatch warning about CamelCase, which cannot get resolved, as it is a consequence of established identifier names in the network part of the code base. changes in v2: - adjust the recipients lists to include the network custodian - drop an obvious/redundant comment as recommended by Joe Hershberger --- net/dns.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/net/dns.c b/net/dns.c index ff9ddffc9d0a..dd4532015045 100644 --- a/net/dns.c +++ b/net/dns.c @@ -202,5 +202,8 @@ DnsStart(void) NetSetTimeout(DNS_TIMEOUT, DnsTimeout); net_set_udp_handler(DnsHandler); + /* Clear a previous MAC address, the server IP might have changed. */ + memset(NetServerEther, 0, sizeof(NetServerEther)); + DnsSend(); } -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/mpc85xx: Add DSP side awareness for Freescale Heterogeneous SoCs
The code provides framework for heterogeneous multicore chips based on StarCore
and Power Architecture which are chasis-2 compliant, like B4860 and B4420
It will make u-boot recognize all non-ppc cores and peripherals like
SC3900/DSP CPUs, MAPLE, CPRI and print their configuration in u-boot logs.
Example boot logs of B4420:
Clock Configuration:
CPU0:1600 MHz, CPU1:1600 MHz,
DSP CPU0:1200 MHz, DSP CPU1:1200 MHz,
CCB:666.667 MHz,
DDR:800 MHz (1600 MT/s data rate) (Asynchronous), IFC:166.667 MHz
CPRI:600 MHz
MAPLE:600 MHz, MAPLE-ULB:800 MHz, MAPLE-eTVPE:1000 MHz
FMAN1: 666.667 MHz
QMAN: 333.333 MHz
Top level changes include:
(1) Top level CONFIG to identify HETEROGENUOUS clusters
(2) CONFIGS for SC3900/DSP components
(3) Global structure updated for dsp cores and other components
(3) APIs to get DSP num cores and their Mask like:
cpu_dsp_mask, cpu_num_dspcores etc same as that of PowerPC
(5) Code to fetch and print SC cores and other heterogenous
device's frequencies
(6) README added for the same
Signed-off-by: Shaveta Leekha shav...@freescale.com
---
arch/powerpc/cpu/mpc85xx/cpu.c| 25 ++
arch/powerpc/cpu/mpc85xx/speed.c | 133 +
arch/powerpc/cpu/mpc8xxx/cpu.c| 83 ++-
arch/powerpc/include/asm/config_mpc85xx.h | 13 +++-
arch/powerpc/include/asm/processor.h |1 +
doc/README.Heterogeneous-SoCs | 105 +++
include/common.h |2 +
include/e500.h|9 ++
8 files changed, 368 insertions(+), 3 deletions(-)
create mode 100644 doc/README.Heterogeneous-SoCs
diff --git a/arch/powerpc/cpu/mpc85xx/cpu.c b/arch/powerpc/cpu/mpc85xx/cpu.c
index 6274f92..43f5331 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu.c
@@ -71,7 +71,9 @@ int checkcpu (void)
#endif /* CONFIG_FSL_CORENET */
unsigned int i, core, nr_cores = cpu_numcores();
+ unsigned int j, dsp_core, dsp_numcores = cpu_num_dspcores();
u32 mask = cpu_mask();
+ u32 dsp_mask = cpu_dsp_mask();
svr = get_svr();
major = SVR_MAJ(svr);
@@ -166,6 +168,16 @@ int checkcpu (void)
printf(CPU%d:%-4s MHz, , core,
strmhz(buf1, sysinfo.freq_processor[core]));
}
+
+#ifdef CONFIG_HETROGENOUS_CLUSTERS
+ for_each_cpu(j, dsp_core, dsp_numcores, dsp_mask) {
+ if (!(j 3))
+ printf(\n );
+ printf(DSP CPU%d:%-4s MHz, , j,
+ strmhz(buf1, sysinfo.freq_processor_dsp[dsp_core]));
+ }
+#endif
+
printf(\n CCB:%-4s MHz,, strmhz(buf1, sysinfo.freq_systembus));
printf(\n);
@@ -224,6 +236,19 @@ int checkcpu (void)
printf( QE:%-4s MHz\n, strmhz(buf1, sysinfo.freq_qe));
#endif
+#if defined(CONFIG_SYS_CPRI)
+ printf( );
+ printf(CPRI:%-4s MHz, strmhz(buf1, sysinfo.freq_cpri));
+#endif
+
+#if defined(CONFIG_SYS_MAPLE)
+ printf(\n );
+ printf(MAPLE:%-4s MHz, , strmhz(buf1, sysinfo.freq_maple));
+ printf(MAPLE-ULB:%-4s MHz, , strmhz(buf1, sysinfo.freq_maple_ulb));
+ printf(MAPLE-eTVPE:%-4s MHz\n,
+ strmhz(buf1, sysinfo.freq_maple_etvpe));
+#endif
+
#ifdef CONFIG_SYS_DPAA_FMAN
for (i = 0; i CONFIG_SYS_NUM_FMAN; i++) {
printf( FMAN%d: %s MHz\n, i + 1,
diff --git a/arch/powerpc/cpu/mpc85xx/speed.c b/arch/powerpc/cpu/mpc85xx/speed.c
index 3236f6a..9a2b487 100644
--- a/arch/powerpc/cpu/mpc85xx/speed.c
+++ b/arch/powerpc/cpu/mpc85xx/speed.c
@@ -35,6 +35,7 @@ void get_sys_info(sys_info_t *sys_info)
volatile ccsr_clk_t *clk = (void *)(CONFIG_SYS_FSL_CORENET_CLK_ADDR);
unsigned int cpu;
#ifdef CONFIG_SYS_FSL_QORIQ_CHASSIS2
+ unsigned int dsp_cpu;
int cc_group[12] = CONFIG_SYS_FSL_CLUSTER_CLOCKS;
#endif
@@ -68,6 +69,7 @@ void get_sys_info(sys_info_t *sys_info)
[14] = 4, /* CC4 PPL / 4 */
};
uint i, freq_c_pll[CONFIG_SYS_FSL_NUM_CC_PLLS];
+ uint rcw_tmp1, rcw_tmp2;
#if !defined(CONFIG_FM_PLAT_CLK_DIV) || !defined(CONFIG_PME_PLAT_CLK_DIV)
uint rcw_tmp;
#endif
@@ -164,6 +166,16 @@ void get_sys_info(sys_info_t *sys_info)
sys_info-freq_processor[cpu] =
freq_c_pll[cplx_pll] / core_cplx_pll_div[c_pll_sel];
}
+
+ for_each_cpu(i, dsp_cpu, cpu_num_dspcores(), cpu_dsp_mask()) {
+ int cluster = fsl_qoriq_dsp_core_to_cluster(dsp_cpu);
+ u32 c_pll_sel = (in_be32(clk-clkcsr[cluster].clkcncsr) 27)
+0xf;
+ u32 cplx_pll = core_cplx_PLL[c_pll_sel];
+ cplx_pll += cc_group[cluster] - 1;
+ sys_info-freq_processor_dsp[dsp_cpu] =
+freq_c_pll[cplx_pll] /
Re: [U-Boot] [PATCH v3 1/4] imx: mx6slevk: Add I2C1 support
Hi Ye,
On 11/09/2014 05:13, Ye.Li wrote:
Add I2C1 pin and pad settings, and enable the MXC I2C driver.
I see two different topics in this patch:
1. Add I2C1 pins to mx6sl pins. This is general, and not related to a
specific board.
2. Add I2C1 support to 6slevk board, as in subject.
Please spliut this patch to address ewach related issue.
Thanks,
Stefano Babic
Signed-off-by: Ye.Li b37...@freescale.com
---
Changes since v1:
- None
Changes since v2:
- None
arch/arm/include/asm/arch-mx6/mx6sl_pins.h |5 +
board/freescale/mx6slevk/mx6slevk.c| 26 ++
include/configs/mx6slevk.h |6 ++
3 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx6/mx6sl_pins.h
b/arch/arm/include/asm/arch-mx6/mx6sl_pins.h
index 045ccc4..ac84270 100644
--- a/arch/arm/include/asm/arch-mx6/mx6sl_pins.h
+++ b/arch/arm/include/asm/arch-mx6/mx6sl_pins.h
@@ -34,5 +34,10 @@ enum {
MX6_PAD_FEC_REF_CLK__FEC_REF_OUT=
IOMUX_PAD(0x424, 0x134, 0x10, 0x000, 0, 0),
MX6_PAD_FEC_RX_ER__GPIO_4_19=
IOMUX_PAD(0x0428, 0x0138, 5, 0x, 0, 0),
MX6_PAD_FEC_TX_CLK__GPIO_4_21 =
IOMUX_PAD(0x0434, 0x0144, 5, 0x, 0, 0),
+
+ MX6_PAD_I2C1_SDA__I2C1_SDA =
IOMUX_PAD(0x0450, 0x0160, 0x10, 0x0720, 2, 0),
+ MX6_PAD_I2C1_SDA__GPIO_3_13 =
IOMUX_PAD(0x0450, 0x0160, 5, 0x, 0, 0),
+ MX6_PAD_I2C1_SCL__I2C1_SCL =
IOMUX_PAD(0x044C, 0x015C, 0x10, 0x071C, 2, 0),
+ MX6_PAD_I2C1_SCL__GPIO_3_12 =
IOMUX_PAD(0x044C, 0x015C, 5, 0x, 0, 0),
};
#endif /* __ASM_ARCH_MX6_MX6SL_PINS_H__ */
diff --git a/board/freescale/mx6slevk/mx6slevk.c
b/board/freescale/mx6slevk/mx6slevk.c
index a990b4c..fedd5c3 100644
--- a/board/freescale/mx6slevk/mx6slevk.c
+++ b/board/freescale/mx6slevk/mx6slevk.c
@@ -13,12 +13,14 @@
#include asm/arch/sys_proto.h
#include asm/gpio.h
#include asm/imx-common/iomux-v3.h
+#include asm/imx-common/mxc_i2c.h
#include asm/io.h
#include linux/sizes.h
#include common.h
#include fsl_esdhc.h
#include mmc.h
#include netdev.h
+#include i2c.h
DECLARE_GLOBAL_DATA_PTR;
@@ -37,8 +39,29 @@ DECLARE_GLOBAL_DATA_PTR;
#define SPI_PAD_CTRL (PAD_CTL_HYS | PAD_CTL_SPEED_MED | \
PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST)
+#define I2C_PAD_CTRL(PAD_CTL_PKE | PAD_CTL_PUE |\
+ PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \
+ PAD_CTL_DSE_40ohm | PAD_CTL_HYS | \
+ PAD_CTL_ODE | PAD_CTL_SRE_FAST)
+
#define ETH_PHY_RESETIMX_GPIO_NR(4, 21)
+#define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
+
+/* I2C1 for PMIC */
+struct i2c_pads_info i2c_pad_info0 = {
+ .sda = {
+ .i2c_mode = MX6_PAD_I2C1_SDA__I2C1_SDA | PC,
+ .gpio_mode = MX6_PAD_I2C1_SDA__GPIO_3_13 | PC,
+ .gp = IMX_GPIO_NR(3, 13),
+ },
+ .scl = {
+ .i2c_mode = MX6_PAD_I2C1_SCL__I2C1_SCL | PC,
+ .gpio_mode = MX6_PAD_I2C1_SCL__GPIO_3_12 | PC,
+ .gp = IMX_GPIO_NR(3, 12),
+ },
+};
+
int dram_init(void)
{
gd-ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE);
@@ -162,6 +185,9 @@ int board_init(void)
#ifdef CONFIG_FEC_MXC
setup_fec();
#endif
+
+ setup_i2c(0, CONFIG_SYS_I2C_SPEED, 0x7f, i2c_pad_info0);
+
return 0;
}
diff --git a/include/configs/mx6slevk.h b/include/configs/mx6slevk.h
index 3d05a64..bf5066f 100644
--- a/include/configs/mx6slevk.h
+++ b/include/configs/mx6slevk.h
@@ -60,6 +60,12 @@
#define CONFIG_PHYLIB
#define CONFIG_PHY_SMSC
+/* I2C Configs */
+#define CONFIG_CMD_I2C
+#define CONFIG_SYS_I2C
+#define CONFIG_SYS_I2C_MXC
+#define CONFIG_SYS_I2C_SPEED 10
+
/* allow to overwrite serial and ethaddr */
#define CONFIG_ENV_OVERWRITE
#define CONFIG_CONS_INDEX1
--
=
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 3/4] imx: mx6sabresd: Add clear print for pfuze200
Hi Ye, On 11/09/2014 05:13, Ye.Li wrote: Add clear print log to show pfuze200 or pfuze100 found on mx6sabresd. Signed-off-by: Ye.Li b37...@freescale.com --- Changes since v1: - None Changes since v2: - None board/freescale/mx6sabresd/mx6sabresd.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/board/freescale/mx6sabresd/mx6sabresd.c b/board/freescale/mx6sabresd/mx6sabresd.c index 5f65f1b..72d6562 100644 --- a/board/freescale/mx6sabresd/mx6sabresd.c +++ b/board/freescale/mx6sabresd/mx6sabresd.c @@ -472,7 +472,8 @@ static int pfuze_init(void) return ret; pmic_reg_read(p, PFUZE100_DEVICEID, reg); - printf(PMIC: PFUZE100 ID=0x%02x\n, reg); + printf(PMIC: PFUZE%s ID=0x%02x\n, + ((reg 0xf) == 0) ? 100 : 200, reg); /* Increase VGEN3 from 2.5 to 2.8V */ pmic_reg_read(p, PFUZE100_VGEN3VOL, reg); This is completely unrelated to the series - it can be applied independently from the other patches. You do not need to resend this one but please send in future patches belonging to the same series if they are related to the same issue or to the same set of issues. This simplifies review and merging - thanks ! Acked-by: Stefano Babic sba...@denx.de 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] imx: imx6q/dlsabreauto: Add PMIC Pfuze100 support
On 9/12/2014 4:17 PM, Stefano Babic wrote:
Hi Ye,
On 10/09/2014 07:52, Ye.Li wrote:
Initialize the Pfuze100 at board late init.
Signed-off-by: Ye.Li b37...@freescale.com
---
board/freescale/mx6qsabreauto/mx6qsabreauto.c | 52
-
include/configs/mx6qsabreauto.h |6 +++
2 files changed, 57 insertions(+), 1 deletions(-)
diff --git a/board/freescale/mx6qsabreauto/mx6qsabreauto.c
b/board/freescale/mx6qsabreauto/mx6qsabreauto.c
index bfb9b6a..76b024b 100644
--- a/board/freescale/mx6qsabreauto/mx6qsabreauto.c
+++ b/board/freescale/mx6qsabreauto/mx6qsabreauto.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2012 Freescale Semiconductor, Inc.
+ * Copyright (C) 2012-2014 Freescale Semiconductor, Inc.
*
* Author: Fabio Estevam fabio.este...@freescale.com
*
@@ -23,6 +23,8 @@
#include netdev.h
#include asm/arch/sys_proto.h
#include i2c.h
+#include power/pmic.h
+#include power/pfuze100_pmic.h
DECLARE_GLOBAL_DATA_PTR;
@@ -43,6 +45,8 @@ DECLARE_GLOBAL_DATA_PTR;
#define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
+#define I2C_PMIC1
+
int dram_init(void)
{
gd-ram_size = (phys_size_t)CONFIG_DDR_MB * 1024 * 1024;
@@ -259,6 +263,51 @@ int board_init(void)
return 0;
}
+static int pfuze_init(void)
+{
+struct pmic *p;
+int ret;
+unsigned int reg;
+
+ret = power_pfuze100_init(I2C_PMIC);
+if (ret)
+return ret;
+
+p = pmic_get(PFUZE100);
+ret = pmic_probe(p);
+if (ret)
+return ret;
+
+pmic_reg_read(p, PFUZE100_DEVICEID, reg);
+printf(PMIC: PFUZE100 ID=0x%02x\n, reg);
+
+/* Set SW1AB stanby volage to 0.975V */
+pmic_reg_read(p, PFUZE100_SW1ABSTBY, reg);
+reg = ~0x3f;
+reg |= 0x1b;
+pmic_reg_write(p, PFUZE100_SW1ABSTBY, reg);
+
+/* Set SW1AB/VDDARM step ramp up time from 16us to 4us/25mV */
+pmic_reg_read(p, PUZE_100_SW1ABCONF, reg);
+reg = ~0xc0;
+reg |= 0x40;
+pmic_reg_write(p, PUZE_100_SW1ABCONF, reg);
+
+/* Set SW1C standby voltage to 0.975V */
+pmic_reg_read(p, PFUZE100_SW1CSTBY, reg);
+reg = ~0x3f;
+reg |= 0x1b;
+pmic_reg_write(p, PFUZE100_SW1CSTBY, reg);
+
+/* Set SW1C/VDDSOC step ramp up time from 16us to 4us/25mV */
+pmic_reg_read(p, PFUZE100_SW1CCONF, reg);
+reg = ~0xc0;
+reg |= 0x40;
+pmic_reg_write(p, PFUZE100_SW1CCONF, reg);
+
+return 0;
+}
The initialization, with the exception of VGEN3/VGEN5, is identical to
the sabresd. Any possibility to improve code and factorize the function
for sabre* boards ?
Best regards,
Stefano Babic
Yes. The pfuze codes are similar on these boards. I will try to factorize the
function. How about moving the common codes to board/freescale/imx ?
Best regards,
Ye Li
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] imx: mx6slevk: Add I2C1 support
Hi Stefano,
On 9/12/2014 6:08 PM, Stefano Babic wrote:
Hi Ye,
On 11/09/2014 05:13, Ye.Li wrote:
Add I2C1 pin and pad settings, and enable the MXC I2C driver.
I see two different topics in this patch:
1. Add I2C1 pins to mx6sl pins. This is general, and not related to a
specific board.
2. Add I2C1 support to 6slevk board, as in subject.
Please spliut this patch to address ewach related issue.
Thanks,
Stefano Babic
Signed-off-by: Ye.Li b37...@freescale.com
---
Changes since v1:
- None
Changes since v2:
- None
arch/arm/include/asm/arch-mx6/mx6sl_pins.h |5 +
board/freescale/mx6slevk/mx6slevk.c| 26 ++
include/configs/mx6slevk.h |6 ++
3 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx6/mx6sl_pins.h
b/arch/arm/include/asm/arch-mx6/mx6sl_pins.h
index 045ccc4..ac84270 100644
--- a/arch/arm/include/asm/arch-mx6/mx6sl_pins.h
+++ b/arch/arm/include/asm/arch-mx6/mx6sl_pins.h
@@ -34,5 +34,10 @@ enum {
MX6_PAD_FEC_REF_CLK__FEC_REF_OUT=
IOMUX_PAD(0x424, 0x134, 0x10, 0x000, 0, 0),
MX6_PAD_FEC_RX_ER__GPIO_4_19=
IOMUX_PAD(0x0428, 0x0138, 5, 0x, 0, 0),
MX6_PAD_FEC_TX_CLK__GPIO_4_21 =
IOMUX_PAD(0x0434, 0x0144, 5, 0x, 0, 0),
+
+MX6_PAD_I2C1_SDA__I2C1_SDA =
IOMUX_PAD(0x0450, 0x0160, 0x10, 0x0720, 2, 0),
+MX6_PAD_I2C1_SDA__GPIO_3_13 =
IOMUX_PAD(0x0450, 0x0160, 5, 0x, 0, 0),
+MX6_PAD_I2C1_SCL__I2C1_SCL =
IOMUX_PAD(0x044C, 0x015C, 0x10, 0x071C, 2, 0),
+MX6_PAD_I2C1_SCL__GPIO_3_12 =
IOMUX_PAD(0x044C, 0x015C, 5, 0x, 0, 0),
};
#endif /* __ASM_ARCH_MX6_MX6SL_PINS_H__ */
diff --git a/board/freescale/mx6slevk/mx6slevk.c
b/board/freescale/mx6slevk/mx6slevk.c
index a990b4c..fedd5c3 100644
--- a/board/freescale/mx6slevk/mx6slevk.c
+++ b/board/freescale/mx6slevk/mx6slevk.c
@@ -13,12 +13,14 @@
#include asm/arch/sys_proto.h
#include asm/gpio.h
#include asm/imx-common/iomux-v3.h
+#include asm/imx-common/mxc_i2c.h
#include asm/io.h
#include linux/sizes.h
#include common.h
#include fsl_esdhc.h
#include mmc.h
#include netdev.h
+#include i2c.h
DECLARE_GLOBAL_DATA_PTR;
@@ -37,8 +39,29 @@ DECLARE_GLOBAL_DATA_PTR;
#define SPI_PAD_CTRL (PAD_CTL_HYS | PAD_CTL_SPEED_MED | \
PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST)
+#define I2C_PAD_CTRL(PAD_CTL_PKE | PAD_CTL_PUE |\
+PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \
+PAD_CTL_DSE_40ohm | PAD_CTL_HYS | \
+PAD_CTL_ODE | PAD_CTL_SRE_FAST)
+
#define ETH_PHY_RESET IMX_GPIO_NR(4, 21)
+#define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
+
+/* I2C1 for PMIC */
+struct i2c_pads_info i2c_pad_info0 = {
+.sda = {
+.i2c_mode = MX6_PAD_I2C1_SDA__I2C1_SDA | PC,
+.gpio_mode = MX6_PAD_I2C1_SDA__GPIO_3_13 | PC,
+.gp = IMX_GPIO_NR(3, 13),
+},
+.scl = {
+.i2c_mode = MX6_PAD_I2C1_SCL__I2C1_SCL | PC,
+.gpio_mode = MX6_PAD_I2C1_SCL__GPIO_3_12 | PC,
+.gp = IMX_GPIO_NR(3, 12),
+},
+};
+
int dram_init(void)
{
gd-ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE);
@@ -162,6 +185,9 @@ int board_init(void)
#ifdef CONFIG_FEC_MXC
setup_fec();
#endif
+
+setup_i2c(0, CONFIG_SYS_I2C_SPEED, 0x7f, i2c_pad_info0);
+
return 0;
}
diff --git a/include/configs/mx6slevk.h b/include/configs/mx6slevk.h
index 3d05a64..bf5066f 100644
--- a/include/configs/mx6slevk.h
+++ b/include/configs/mx6slevk.h
@@ -60,6 +60,12 @@
#define CONFIG_PHYLIB
#define CONFIG_PHY_SMSC
+/* I2C Configs */
+#define CONFIG_CMD_I2C
+#define CONFIG_SYS_I2C
+#define CONFIG_SYS_I2C_MXC
+#define CONFIG_SYS_I2C_SPEED 10
+
/* allow to overwrite serial and ethaddr */
#define CONFIG_ENV_OVERWRITE
#define CONFIG_CONS_INDEX 1
I will split this patch to two in v4.
Best regards,
Ye Li
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: imx6q/dlsabreauto: Add PMIC Pfuze100 support
Hi Ye,
On 12/09/2014 12:27, Li Ye-B37916 wrote:
On 9/12/2014 4:17 PM, Stefano Babic wrote:
Hi Ye,
On 10/09/2014 07:52, Ye.Li wrote:
Initialize the Pfuze100 at board late init.
Signed-off-by: Ye.Li b37...@freescale.com
---
board/freescale/mx6qsabreauto/mx6qsabreauto.c | 52
-
include/configs/mx6qsabreauto.h |6 +++
2 files changed, 57 insertions(+), 1 deletions(-)
diff --git a/board/freescale/mx6qsabreauto/mx6qsabreauto.c
b/board/freescale/mx6qsabreauto/mx6qsabreauto.c
index bfb9b6a..76b024b 100644
--- a/board/freescale/mx6qsabreauto/mx6qsabreauto.c
+++ b/board/freescale/mx6qsabreauto/mx6qsabreauto.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2012 Freescale Semiconductor, Inc.
+ * Copyright (C) 2012-2014 Freescale Semiconductor, Inc.
*
* Author: Fabio Estevam fabio.este...@freescale.com
*
@@ -23,6 +23,8 @@
#include netdev.h
#include asm/arch/sys_proto.h
#include i2c.h
+#include power/pmic.h
+#include power/pfuze100_pmic.h
DECLARE_GLOBAL_DATA_PTR;
@@ -43,6 +45,8 @@ DECLARE_GLOBAL_DATA_PTR;
#define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
+#define I2C_PMIC 1
+
int dram_init(void)
{
gd-ram_size = (phys_size_t)CONFIG_DDR_MB * 1024 * 1024;
@@ -259,6 +263,51 @@ int board_init(void)
return 0;
}
+static int pfuze_init(void)
+{
+ struct pmic *p;
+ int ret;
+ unsigned int reg;
+
+ ret = power_pfuze100_init(I2C_PMIC);
+ if (ret)
+ return ret;
+
+ p = pmic_get(PFUZE100);
+ ret = pmic_probe(p);
+ if (ret)
+ return ret;
+
+ pmic_reg_read(p, PFUZE100_DEVICEID, reg);
+ printf(PMIC: PFUZE100 ID=0x%02x\n, reg);
+
+ /* Set SW1AB stanby volage to 0.975V */
+ pmic_reg_read(p, PFUZE100_SW1ABSTBY, reg);
+ reg = ~0x3f;
+ reg |= 0x1b;
+ pmic_reg_write(p, PFUZE100_SW1ABSTBY, reg);
+
+ /* Set SW1AB/VDDARM step ramp up time from 16us to 4us/25mV */
+ pmic_reg_read(p, PUZE_100_SW1ABCONF, reg);
+ reg = ~0xc0;
+ reg |= 0x40;
+ pmic_reg_write(p, PUZE_100_SW1ABCONF, reg);
+
+ /* Set SW1C standby voltage to 0.975V */
+ pmic_reg_read(p, PFUZE100_SW1CSTBY, reg);
+ reg = ~0x3f;
+ reg |= 0x1b;
+ pmic_reg_write(p, PFUZE100_SW1CSTBY, reg);
+
+ /* Set SW1C/VDDSOC step ramp up time from 16us to 4us/25mV */
+ pmic_reg_read(p, PFUZE100_SW1CCONF, reg);
+ reg = ~0xc0;
+ reg |= 0x40;
+ pmic_reg_write(p, PFUZE100_SW1CCONF, reg);
+
+ return 0;
+}
The initialization, with the exception of VGEN3/VGEN5, is identical to
the sabresd. Any possibility to improve code and factorize the function
for sabre* boards ?
Best regards,
Stefano Babic
Yes. The pfuze codes are similar on these boards. I will try to factorize the
function. How about moving the common codes to board/freescale/imx ?
Agree. The imx directory can contain all common code shared among
Freescale's board.
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 v10] nand/denali: Adding Denali NAND driver support
On Fri, 12 Sep 2014 00:42:17 -0500 Chin Liang See cl...@altera.com wrote: To add the Denali NAND driver support into U-Boot. This driver is leveraged from Linux with commit ID fdbad98dff8007f2b8bee6698b5d25ebba0471c9. For Denali controller 64 variance, you need to declare macro CONFIG_SYS_NAND_DENALI_64BIT. Signed-off-by: Chin Liang See cl...@altera.com Cc: Scott Wood scottw...@freescale.com Cc: Masahiro Yamada yamad...@jp.panasonic.com --- Changes for v10 - Updated the commit message to include Linux driver commit ID, usage of macro CONFIG_SYS_NAND_DENALI_64BIT - Removed casting for memcpy function - Removed NAND_CMD_LOCK_TIGHT support as no longer in latest NAND driver Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Reviewed-by: Masahiro Yamada yamad...@jp.panasonic.com Tested-by: Masahiro Yamada yamad...@jp.panasonic.com I am looking forward to get this driver in. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 0/2] arm: vf610: add NAND flash support
This patch set adds NAND Flash Controller (NFC) support for Freescale Vybrid ARM SoCs (vf610). The driver is based on Bill Pringlemeirs prelineary patch sent in January 2014 to the MTD mailing list: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/226623.html Changes in v5 - Fix style issues Changes in v4 - Drop preparation patches 1 and 2 since they are already merged upstream - Add memcpy accessor function vf610_nfc_memcpy - Remove disabled code Changes in v3 - Further optimizations in vf610_nfc_send_command(s) to avoid performance hit by additional barriers introduced through using writel/readl - Removed unnecessary barrier and added comment - Use void __iomem * as memory base data type - Set page to -1 on read error to allow reread of pages by the higher layers - Minor style fixes Changes in v2: - Renamed the driver from fsl_nfc to vf610_nfc - Use writel/readl in register access functions - Optimized some register accesses by read/write value only once in code - Use CONFIG_SYS_NAND_SELF_INIT and fix board_nand_init implementation - Removed uncommented code/fixed comments - Add CONFIG_USE_ARCH_MEMCPY for improved NAND performance - Use hweight32 for improved count_written_bits performance - Implement page_read/page_write rather than reuse MTD stacks version Stefan Agner (2): mtd: nand: add Freescale vf610_nfc driver arm: vf610: add NAND support for vf610twr board/freescale/vf610twr/vf610twr.c | 47 ++- configs/vf610twr_defconfig | 2 +- configs/vf610twr_nand_defconfig | 3 + drivers/mtd/nand/Makefile | 1 + drivers/mtd/nand/vf610_nfc.c| 724 include/configs/vf610twr.h | 46 ++- 6 files changed, 818 insertions(+), 5 deletions(-) create mode 100644 configs/vf610twr_nand_defconfig create mode 100644 drivers/mtd/nand/vf610_nfc.c -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 2/2] arm: vf610: add NAND support for vf610twr
This adds NAND support for the Vybrid tower system (TWR-VF65GS10)
provided by the vf610_nfc driver. Full 16-Bit bus width is
supported. Also an aditional config vf610twr_nand is introduced
which gets the environment from NAND. However, booting U-Boot from
NAND is not yet possible due to missing boot configuration block
(BCB).
Signed-off-by: Stefan Agner ste...@agner.ch
---
board/freescale/vf610twr/vf610twr.c | 47 ++---
configs/vf610twr_defconfig | 2 +-
configs/vf610twr_nand_defconfig | 3 +++
include/configs/vf610twr.h | 46 +++-
4 files changed, 93 insertions(+), 5 deletions(-)
create mode 100644 configs/vf610twr_nand_defconfig
diff --git a/board/freescale/vf610twr/vf610twr.c
b/board/freescale/vf610twr/vf610twr.c
index 54a9f2c..4d09796 100644
--- a/board/freescale/vf610twr/vf610twr.c
+++ b/board/freescale/vf610twr/vf610twr.c
@@ -278,6 +278,39 @@ static void setup_iomux_i2c(void)
imx_iomux_v3_setup_multiple_pads(i2c0_pads, ARRAY_SIZE(i2c0_pads));
}
+#ifdef CONFIG_NAND_VF610_NFC
+static void setup_iomux_nfc(void)
+{
+ static const iomux_v3_cfg_t nfc_pads[] = {
+ VF610_PAD_PTD31__NF_IO15,
+ VF610_PAD_PTD30__NF_IO14,
+ VF610_PAD_PTD29__NF_IO13,
+ VF610_PAD_PTD28__NF_IO12,
+ VF610_PAD_PTD27__NF_IO11,
+ VF610_PAD_PTD26__NF_IO10,
+ VF610_PAD_PTD25__NF_IO9,
+ VF610_PAD_PTD24__NF_IO8,
+ VF610_PAD_PTD23__NF_IO7,
+ VF610_PAD_PTD22__NF_IO6,
+ VF610_PAD_PTD21__NF_IO5,
+ VF610_PAD_PTD20__NF_IO4,
+ VF610_PAD_PTD19__NF_IO3,
+ VF610_PAD_PTD18__NF_IO2,
+ VF610_PAD_PTD17__NF_IO1,
+ VF610_PAD_PTD16__NF_IO0,
+ VF610_PAD_PTB24__NF_WE_B,
+ VF610_PAD_PTB25__NF_CE0_B,
+ VF610_PAD_PTB27__NF_RE_B,
+ VF610_PAD_PTC26__NF_RB_B,
+ VF610_PAD_PTC27__NF_ALE,
+ VF610_PAD_PTC28__NF_CLE
+ };
+
+ imx_iomux_v3_setup_multiple_pads(nfc_pads, ARRAY_SIZE(nfc_pads));
+}
+#endif
+
+
static void setup_iomux_qspi(void)
{
static const iomux_v3_cfg_t qspi0_pads[] = {
@@ -354,6 +387,8 @@ static void clock_init(void)
CCM_CCGR7_SDHC1_CTRL_MASK);
clrsetbits_le32(ccm-ccgr9, CCM_REG_CTRL_MASK,
CCM_CCGR9_FEC0_CTRL_MASK | CCM_CCGR9_FEC1_CTRL_MASK);
+ clrsetbits_le32(ccm-ccgr10, CCM_REG_CTRL_MASK,
+ CCM_CCGR10_NFC_CTRL_MASK);
clrsetbits_le32(anadig-pll2_ctrl, ANADIG_PLL2_CTRL_POWERDOWN,
ANADIG_PLL2_CTRL_ENABLE | ANADIG_PLL2_CTRL_DIV_SELECT);
@@ -373,14 +408,17 @@ static void clock_init(void)
CCM_CACRR_IPG_CLK_DIV(1) | CCM_CACRR_BUS_CLK_DIV(2) |
CCM_CACRR_ARM_CLK_DIV(0));
clrsetbits_le32(ccm-cscmr1, CCM_REG_CTRL_MASK,
- CCM_CSCMR1_ESDHC1_CLK_SEL(3) | CCM_CSCMR1_QSPI0_CLK_SEL(3));
+ CCM_CSCMR1_ESDHC1_CLK_SEL(3) | CCM_CSCMR1_QSPI0_CLK_SEL(3) |
+ CCM_CSCMR1_NFC_CLK_SEL(0));
clrsetbits_le32(ccm-cscdr1, CCM_REG_CTRL_MASK,
CCM_CSCDR1_RMII_CLK_EN);
clrsetbits_le32(ccm-cscdr2, CCM_REG_CTRL_MASK,
- CCM_CSCDR2_ESDHC1_EN | CCM_CSCDR2_ESDHC1_CLK_DIV(0));
+ CCM_CSCDR2_ESDHC1_EN | CCM_CSCDR2_ESDHC1_CLK_DIV(0) |
+ CCM_CSCDR2_NFC_EN);
clrsetbits_le32(ccm-cscdr3, CCM_REG_CTRL_MASK,
CCM_CSCDR3_QSPI0_EN | CCM_CSCDR3_QSPI0_DIV(1) |
- CCM_CSCDR3_QSPI0_X2_DIV(1) | CCM_CSCDR3_QSPI0_X4_DIV(3));
+ CCM_CSCDR3_QSPI0_X2_DIV(1) | CCM_CSCDR3_QSPI0_X4_DIV(3) |
+ CCM_CSCDR3_NFC_PRE_DIV(5));
clrsetbits_le32(ccm-cscmr2, CCM_REG_CTRL_MASK,
CCM_CSCMR2_RMII_CLK_SEL(0));
}
@@ -411,6 +449,9 @@ int board_early_init_f(void)
setup_iomux_enet();
setup_iomux_i2c();
setup_iomux_qspi();
+#ifdef CONFIG_NAND_VF610_NFC
+ setup_iomux_nfc();
+#endif
return 0;
}
diff --git a/configs/vf610twr_defconfig b/configs/vf610twr_defconfig
index 10e6432..7de374a 100644
--- a/configs/vf610twr_defconfig
+++ b/configs/vf610twr_defconfig
@@ -1,3 +1,3 @@
-CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=board/freescale/vf610twr/imximage.cfg
+CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=board/freescale/vf610twr/imximage.cfg,ENV_IS_IN_MMC
CONFIG_ARM=y
CONFIG_TARGET_VF610TWR=y
diff --git a/configs/vf610twr_nand_defconfig b/configs/vf610twr_nand_defconfig
new file mode 100644
index 000..e78db26
--- /dev/null
+++ b/configs/vf610twr_nand_defconfig
@@ -0,0 +1,3 @@
+CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=board/freescale/vf610twr/imximage.cfg,ENV_IS_IN_NAND
+CONFIG_ARM=y
+CONFIG_TARGET_VF610TWR=y
diff --git a/include/configs/vf610twr.h b/include/configs/vf610twr.h
index 0342550..6fd0b17 100644
--- a/include/configs/vf610twr.h
+++
[U-Boot] [PATCH v5 1/2] mtd: nand: add Freescale vf610_nfc driver
This adds initial support for Freescale NFC (NAND Flash Controller) found in ARM Vybrid SoC's, Power Architecture MPC5125 and others. The driver is called vf610_nfc since this is the first supported and tested hardware platform supported by the driver. Signed-off-by: Stefan Agner ste...@agner.ch Acked-by: Bill Pringlemeir bpringlem...@nbsps.com --- drivers/mtd/nand/Makefile| 1 + drivers/mtd/nand/vf610_nfc.c | 724 +++ 2 files changed, 725 insertions(+) create mode 100644 drivers/mtd/nand/vf610_nfc.c diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index bf1312a..eef86d1 100644 --- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -51,6 +51,7 @@ obj-$(CONFIG_NAND_KB9202) += kb9202_nand.o obj-$(CONFIG_NAND_KIRKWOOD) += kirkwood_nand.o obj-$(CONFIG_NAND_KMETER1) += kmeter1_nand.o obj-$(CONFIG_NAND_MPC5121_NFC) += mpc5121_nfc.o +obj-$(CONFIG_NAND_VF610_NFC) += vf610_nfc.o obj-$(CONFIG_NAND_MXC) += mxc_nand.o obj-$(CONFIG_NAND_MXS) += mxs_nand.o obj-$(CONFIG_NAND_NDFC) += ndfc.o diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c new file mode 100644 index 000..7feb3a7 --- /dev/null +++ b/drivers/mtd/nand/vf610_nfc.c @@ -0,0 +1,724 @@ +/* + * Copyright 2009-2014 Freescale Semiconductor, Inc. and others + * + * Description: MPC5125, VF610, MCF54418 and Kinetis K70 Nand driver. + * Ported to U-Boot by Stefan Agner + * Based on RFC driver posted on Kernel Mailing list by Bill Pringlemeir + * Jason ported to M54418TWR and MVFA5. + * Authors: Stefan Agner stefan.ag...@toradex.com + * Bill Pringlemeir bpringlem...@nbsps.com + * Shaohui Xie b21...@freescale.com + * Jason Jin jason@freescale.com + * + * Based on original driver mpc5121_nfc.c. + * + * This 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. + * + * Limitations: + * - Untested on MPC5125 and M54418. + * - DMA not used. + * - 2K pages or less. + * - Only 2K page w. 64+OOB and hardware ECC. + */ + +#include common.h +#include malloc.h + +#include linux/mtd/mtd.h +#include linux/mtd/nand.h +#include linux/mtd/partitions.h + +#include nand.h +#include errno.h +#include asm/io.h + +/* Register Offsets */ +#define NFC_FLASH_CMD1 0x3F00 +#define NFC_FLASH_CMD2 0x3F04 +#define NFC_COL_ADDR 0x3F08 +#define NFC_ROW_ADDR 0x3F0c +#define NFC_ROW_ADDR_INC 0x3F14 +#define NFC_FLASH_STATUS1 0x3F18 +#define NFC_FLASH_STATUS2 0x3F1c +#define NFC_CACHE_SWAP 0x3F28 +#define NFC_SECTOR_SIZE0x3F2c +#define NFC_FLASH_CONFIG 0x3F30 +#define NFC_IRQ_STATUS 0x3F38 + +/* Addresses for NFC MAIN RAM BUFFER areas */ +#define NFC_MAIN_AREA(n) ((n) * 0x1000) + +#define PAGE_2K0x0800 +#define OOB_64 0x0040 + +/* + * NFC_CMD2[CODE] values. See section: + * - 31.4.7 Flash Command Code Description, Vybrid manual + * - 23.8.6 Flash Command Sequencer, MPC5125 manual + * + * Briefly these are bitmasks of controller cycles. + */ +#define READ_PAGE_CMD_CODE 0x7EE0 +#define PROGRAM_PAGE_CMD_CODE 0x7FC0 +#define ERASE_CMD_CODE 0x4EC0 +#define READ_ID_CMD_CODE 0x4804 +#define RESET_CMD_CODE 0x4040 +#define STATUS_READ_CMD_CODE 0x4068 + +/* NFC ECC mode define */ +#define ECC_BYPASS 0 +#define ECC_45_BYTE6 + +/*** Register Mask and bit definitions */ + +/* NFC_FLASH_CMD1 Field */ +#define CMD_BYTE2_MASK 0xFF00 +#define CMD_BYTE2_SHIFT24 + +/* NFC_FLASH_CM2 Field */ +#define CMD_BYTE1_MASK 0xFF00 +#define CMD_BYTE1_SHIFT24 +#define CMD_CODE_MASK 0x0000 +#define CMD_CODE_SHIFT 8 +#define BUFNO_MASK 0x0006 +#define BUFNO_SHIFT1 +#define START_BIT (10) + +/* NFC_COL_ADDR Field */ +#define COL_ADDR_MASK 0x +#define COL_ADDR_SHIFT 0 + +/* NFC_ROW_ADDR Field */ +#define ROW_ADDR_MASK 0x00FF +#define ROW_ADDR_SHIFT 0 +#define ROW_ADDR_CHIP_SEL_RB_MASK 0xF000 +#define ROW_ADDR_CHIP_SEL_RB_SHIFT 28 +#define ROW_ADDR_CHIP_SEL_MASK 0x0F00 +#define ROW_ADDR_CHIP_SEL_SHIFT24 + +/* NFC_FLASH_STATUS2 Field */ +#define STATUS_BYTE1_MASK 0x00FF + +/* NFC_FLASH_CONFIG
[U-Boot] A minor question on a Driver Model function
Hi Simon,
I have a qustion about lists_driver_lookup_name() function.
for (entry = drv; entry != drv + n_ents; entry++) {
if (strncmp(name, entry-name, len))
continue;
/* Full match */
if (len == strlen(entry-name))
return entry;
}
Why is this not like follows?
for (entry = drv; entry != drv + n_ents; entry++) {
if (!strcmp(name, entry-name))
return entry;
}
It seems equivalent to the former and simpler.
Am I missing something?
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 v3 3/4] imx: mx6sabresd: Add clear print for pfuze200
Hi Stefano, On 9/12/2014 6:13 PM, Stefano Babic wrote: Hi Ye, On 11/09/2014 05:13, Ye.Li wrote: Add clear print log to show pfuze200 or pfuze100 found on mx6sabresd. Signed-off-by: Ye.Li b37...@freescale.com --- Changes since v1: - None Changes since v2: - None board/freescale/mx6sabresd/mx6sabresd.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/board/freescale/mx6sabresd/mx6sabresd.c b/board/freescale/mx6sabresd/mx6sabresd.c index 5f65f1b..72d6562 100644 --- a/board/freescale/mx6sabresd/mx6sabresd.c +++ b/board/freescale/mx6sabresd/mx6sabresd.c @@ -472,7 +472,8 @@ static int pfuze_init(void) return ret; pmic_reg_read(p, PFUZE100_DEVICEID, reg); -printf(PMIC: PFUZE100 ID=0x%02x\n, reg); +printf(PMIC: PFUZE%s ID=0x%02x\n, +((reg 0xf) == 0) ? 100 : 200, reg); /* Increase VGEN3 from 2.5 to 2.8V */ pmic_reg_read(p, PFUZE100_VGEN3VOL, reg); This is completely unrelated to the series - it can be applied independently from the other patches. You do not need to resend this one but please send in future patches belonging to the same series if they are related to the same issue or to the same set of issues. This simplifies review and merging - thanks ! Acked-by: Stefano Babic sba...@denx.de Best regards, Stefano Babic Thanks for your comments. I feel this patch has somewhat relation with others, that in 4/4 the pfuze mode setup needs to consider the pfuze chip type. Of course, this patch can be applied independently. I will be more careful about the patch set in future. Best regards, Ye Li ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] boot count feature with eMMC booting
I want to implement fail-safe booting feature in my project. Basically my logic is, i will increase any u-boot environment variable each time and up on successful bring up, i want to decrease the value of that again. If the value of u-boot environment variable is more than 5, it will boot from the other image. As i am using the eMMC for booting, i am not getting how i will access the u-boot environment variable from the linux application. I also dont know whether i can save the environment variable in the eMMC or not? What mechanism i should use to achieve this feature. I have read about the fw_printenv and fw_savenv, but from where this utility will access the variable. Thanks, Jags Gediya ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-arm/master
Hello Tom, The following changes since commit d6c1ffc7d23f4fe4ae8c91101861055b8e1501b6: Prepare v2014.10-rc2 (2014-09-02 16:58:29 -0400) are available in the git repository at: git://git.denx.de/u-boot-arm master for you to fetch changes up to a7f99bf139b3aaa0d5494693fd0395084355e41a: arm: Fix _start for CONFIG_SYS_DV_NOR_BOOT_CFG (2014-09-11 18:04:39 +0200) NOTE that 7 boards still fail building, two with warnings (k2e_evm k2hk_evm), five with errors (openrd_client tricorder_flash tricorder openrd_ultimate openrd_base). Ajay Kumar (8): exynos_fb: Remove usage of static defines arm: exynos: Add RPLL for Exynos5420 arm: exynos: Add get_lcd_clk and set_lcd_clk callbacks for Exynos5420 video: exynos_fimd: Add framework to disable FIMD sysmmu ARM: exynos: Add missing declaration for gpio_direction_input exynos5420: add callbacks needed for exynos_fb driver ARM: exynos: peach_pit: Add DT nodes for fimd and parade bridge chip CONFIGS: peach-pit: Enable display for peach_pit board Albert ARIBAUD (2): Merge branch 'u-boot-samsung/master' into 'u-boot-arm/master' Merge branch 'u-boot-sunxi/master' into 'u-boot-arm/master' Benoît Thébaudeau (2): arm: Make reset position-independent arm: Fix _start for CONFIG_SYS_DV_NOR_BOOT_CFG Enric Balletbo i Serra (1): AM335x: igep0033: Convert to generic board and use ti_am335x_common.h. FUKAUMI Naoki (1): sun7i: Add support for Olimex A20-OLinuXino-LIME Guillaume GARDET (1): omap3_beagle: Add boot script support to omap3 beagle board Ian Campbell (1): sunxi: Correct typo CONFIG_FTDFILE = CONFIG_FDTFILE Jeroen Hofstee (8): board_r: ARM[64] do not set gd again ARM: SPL: do not set gd again cc-option: also detect unsupported warnings options ARM: make gd a function for clang eabi_compat: add __aeabi_memcpy __aeabi_memset clang: workaround for generated constants Makefile: default to cc for host compiler README.clang: build command with clang Khoronzhuk, Ivan (3): ARM: keystone: clock: use correct BWADJ field mask for PASSPLLCTL0 keystone2: use readl/writel functions instead of redefinition mtd: nand: davinci_nand: correct keystone RBL layout definition Masahiro Yamada (3): arm: am335x: add Kconfig range attribute to prevent invalid CONS_INDEX MAINTAINERS: update the maintainer of Arndale board kconfig: remove redundant SPL from CONFIG_SYS_EXTRA_OPTIONS Przemyslaw Marczak (13): samsung: misc: fix soc revision setting in the set_board_info() exynos: pinmux: fix the gpio names for exynos4x12 mmc arch:exynos: boot mode: add get_boot_mode(), code cleanup board:samsung: check the boot device and init the right mmc driver. samsung: misc: add function for setting $dfu_alt_info samsung:board: misc_init_r: call set_dfu_alt_info() arm:reset: call the reset_misc() before the cpu reset samsung: board: enable support of multiple board types samsung: misc: use board specific functions to set env board info odroid: add board file for Odroid X2/U3 based on Samsung Exynos4412 odroid: add odroid U3/X2 device tree description odroid: kconfig: add odroid_defconfig odroid: set MPLL clock to 880MHz R Sricharan (1): ARM: DRA72: DDR3: Add emif settings for 666MHz clock Rostislav Lisovy (2): mtd: nand: omap_gpmc: Enable multiple NAND flash devices mtd: nand: omap_gpmc: Fix 'bit-flip' errors Vadim Bendebury (1): video: Add driver for Parade PS8625 dP to LVDS bridge Kbuild | 3 +- Makefile | 4 +- arch/arm/cpu/armv7/exynos/Kconfig | 4 + arch/arm/cpu/armv7/exynos/clock.c | 83 +++-- arch/arm/cpu/armv7/exynos/clock_init.h | 3 + arch/arm/cpu/armv7/exynos/clock_init_exynos5.c | 13 arch/arm/cpu/armv7/exynos/exynos5_setup.h | 2 +- arch/arm/cpu/armv7/exynos/pinmux.c | 4 +- arch/arm/cpu/armv7/exynos/power.c | 7 ++ arch/arm/cpu/armv7/exynos/spl_boot.c | 7 +- arch/arm/cpu/armv7/keystone/clock.c| 2 +- arch/arm/cpu/armv7/keystone/psc.c | 44 +-- arch/arm/cpu/armv7/omap5/hw_data.c | 39 +- arch/arm/cpu/armv7/omap5/sdram.c | 60 ++- arch/arm/dts/Makefile | 3 +- arch/arm/dts/exynos4412-odroid.dts | 70 ++ arch/arm/dts/exynos5420-peach-pit.dts | 30 arch/arm/dts/exynos54xx.dtsi | 10 +++ arch/arm/include/asm/arch-exynos/clk.h | 1 + arch/arm/include/asm/arch-exynos/gpio.h| 1 + arch/arm/include/asm/arch-exynos/power.h | 21 ++ arch/arm/include/asm/arch-exynos/spl.h | 17 +
[U-Boot] [PULL] Please pull u-boot-imx
Hi Albert, please pull from u-boot-imx, thanks ! The board cm_fx6 cannot be built due to a couple of missing patches that are already merged into u-boot-spi. Please ignore this issue, the board will be compiled clean at the next iteration after Jagan's tree will be merged by Tom. The following changes since commit a6bc0195dba895fa0e9facc718d17eb098695685: Merge branch 'u-boot-sunxi/master' into 'u-boot-arm/master' (2014-09-09 09:19:10 +0200) are available in the git repository at: git://www.denx.de/git/u-boot-imx.git master for you to fetch changes up to 4c97f16911e229f6d5bbea5bee52449916e5fa92: imx: mx6slevk: Change to use generic board (2014-09-11 11:04:26 +0200) Fabio Estevam (9): net: fec_mxc: Adjust RX DMA alignment for mx6solox net: fec_mxc: Poll FEC_TBD_READY after polling TDAR tools: imximage: Fix the maximum DCD size for mx53/mx6 mx6dlsabresd: Use its own DCD table mx6qsabreauto: Remove imx6q-sabreauto.dts mx6: imx-regs: Provide a structure for GPC registers pcie_imx: Add mx6solox support mx6sxsabresd: Add PCI support README.imximage: Fix the maximum DCD size Guillaume GARDET (1): imx: nitrogen6x: Replace 'fatload' by 'load' command in env settings to be filesystem independent Nikita Kiryanov (16): mx6: add clock enabling functions compulab: eeprom: add support for defining eeprom i2c bus sata: dwc_ahsata: implement sata_port_status i2c: imx: add macros to setup pads for multiple SoC types arm: mx6: ddr: cleanup arm: mx6: ddr: do not write into reserved bit arm: mx6: ddr: configure MMDC for slow_pd arm: mx6: ddr: fix cs0_end calculation arm: mx6: add get_cpu_type() arm: mx6: add support for Compulab cm-fx6 CoM arm: mx6: cm_fx6: add nand support arm: mx6: cm_fx6: add ethernet support arm: mx6: cm_fx6: add usb support arm: mx6: cm_fx6: add i2c support arm: mx6: cm_fx6: use eeprom arm: mx6: cm_fx6: add sata support Nikolay Dimitrov (1): mx6: Fix ECSPI typo in soc_boot_modes Stefan Agner (2): arm: vf610: lpuart: fix status register handling arm: vf610: lpuart: disable FIFO on initializaton Stefano Babic (1): imx: Fix build of mx6sxsabresd Thierry Reding (1): imx: ventana: Avoid undefined behaviour Tim Harvey (6): imx: ventana: updated notes regarding NAND boot errata imx: ventana: base SPL MMDC calibration on width and size not board imx: ventana: add GW5520 support imx: ventana: added cputype env var pci: add support for board_pci_fixup_dev function imx: ventana: add pci fixup for PLX PEX860x switch GPIO Ye.Li (4): iMX6: Disable the L2 before chaning the PL310 latency imximage: Fix imximage IVT bug for EIM-NOR boot imx: mx6q/dlarm2: Change to use generic board imx: mx6slevk: Change to use generic board arch/arm/Kconfig| 4 + arch/arm/cpu/armv7/mx6/clock.c | 107 +- arch/arm/cpu/armv7/mx6/ddr.c| 277 arch/arm/cpu/armv7/mx6/soc.c| 11 +- arch/arm/dts/Makefile | 1 - arch/arm/dts/imx6q-sabreauto.dts| 13 - arch/arm/include/asm/arch-mx6/clock.h | 5 + arch/arm/include/asm/arch-mx6/imx-regs.h| 13 + arch/arm/include/asm/arch-mx6/iomux.h | 9 + arch/arm/include/asm/arch-mx6/sys_proto.h | 5 +- arch/arm/include/asm/imx-common/mxc_i2c.h | 33 ++ board/compulab/cm_fx6/Kconfig | 23 ++ board/compulab/cm_fx6/MAINTAINERS | 6 + board/compulab/cm_fx6/Makefile | 12 + board/compulab/cm_fx6/cm_fx6.c | 483 board/compulab/cm_fx6/common.c | 84 + board/compulab/cm_fx6/common.h | 37 +++ board/compulab/cm_fx6/imximage.cfg | 8 + board/compulab/cm_fx6/spl.c | 366 + board/compulab/common/eeprom.c | 13 +- board/freescale/mx6sabresd/mx6dlsabresd.cfg | 131 board/gateworks/gw_ventana/eeprom.c | 3 + board/gateworks/gw_ventana/gsc.c| 4 + board/gateworks/gw_ventana/gw_ventana.c | 118 ++- board/gateworks/gw_ventana/gw_ventana_spl.c | 189 ++- board/gateworks/gw_ventana/ventana_eeprom.h | 1 + configs/cm_fx6_defconfig| 4 + configs/mx6dlsabresd_defconfig | 2 +- doc/README.imximage | 2 +- drivers/block/dwc_ahsata.c | 17 + drivers/net/fec_mxc.c | 42 ++- drivers/pci/pci.c | 4 + drivers/pci/pcie_imx.c | 40 ++- drivers/serial/serial_lpuart.c | 19 +- include/configs/cm_fx6.h| 290 + include/configs/cm_t335.h
Re: [U-Boot] [PATCH 0/8] samsung: Use common config files with Samsung boards (help wanted)
Hi Przemyslaw, On 12 September 2014 02:39, Przemyslaw Marczak p.marc...@samsung.com wrote: Hello Simon, On 09/09/2014 12:31 PM, Przemyslaw Marczak wrote: Hi, I will test this patch set on a trats2 board - today evening. On 09/09/2014 08:05 AM, Simon Glass wrote: Hi Minkyu, On 25 July 2014 08:43, Simon Glass s...@chromium.org wrote: Hi Lucasz, On 24 July 2014 09:34, Lukasz Majewski l.majew...@samsung.com wrote: Hi Simon, This series tries to unify the Samsung board configs into a few header files for exynos5 and exynos5. The purpose is to make it easier to move to driver model. In that case I would like things like the GPIO drivers and serial drivers to work in a standard way, and not need to support device tree and platform data at the same time. That would be quite painful. Another reason is that the Chrome OS EC drivers are currently included in boards that don't have a Chrome OS EC. This concern was raised by the Samsung maintainer (Minkyu) a while back. There are still a few boards that don't use CONFIG_OF_CONTROL so I have updated these with the most rudimentary of device tree files. Unfortunately I don't have boards for most of these (for testing) and I am hoping that the maintainers can come to the rescue and fix up any patches that have problems. I am also worried that I have used a common exynos file for things like smdkv310, when in fact they have some other chip in common. So maintainers, please can you test this and re-issue the patch, or make comments on my attempts? We will do our best to test our Exynos4 based boards. Thanks - please feel free to re-issue the patches and I will drop mine (if you cc me). Can you please review this series? We are already at rc2. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Best regards, It works fine on trats2. I'm currently working on PMIC framework at the top of your u-boot-dm/working branch and it also works fine on Trats2. OK good, thanks for testing. I'll go through the feedback and see if I can give the patches another spin. It would be great if we can get exynos DM support in mainline for the upcoming release. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] test: dfu: script: wrong md5sum on nand partitions
On 09/12/2014 12:27 AM, Heiko Schocher wrote: when uplaoding a file, at least from a nand partition, the complete mtd nand partition size is transferred. This leads in a wrong md5sum as the filesize is different between the downloaded file and the uploaded file. Limit the uploaded filesize to the downloaded fixes this. I was going to say that it'd be better to fix U-Boot's NAND code to transfer the correct amount of data. However, I suppose the correct amount *is* the whole partition for anything other than a filesystem file. As such, I'd suggest replacing nand in the patch description with something else, since presumably the exact same issue applies to partitions on eMMC. The issue applies to any partition. I wonder if there's a way to distinguish between file tests and partition tests in dfu_gadget_test.sh, so that the $N_FILE_FULL - $N_FILE conversion can be applied only for partitions. Otherwise, a file upload/download test could end up changing (increasing) the file length and this bug wouldn't be detected. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7] ARM: sunxi: Fix build break when CONFIG_USB_EHCI is not defined
On Fri, Sep 12, 2014 at 2:57 AM, Ian Campbell i...@hellion.org.uk wrote: On Thu, 2014-09-11 at 19:19 +0200, Hans de Goede wrote: Hi Chen, On 09/11/2014 07:07 PM, Chen-Yu Tsai wrote: Hi Ian, Hans, On Mon, Sep 8, 2014 at 9:28 PM, Chen-Yu Tsai w...@csie.org wrote: BOOT_TARGET_DEVICES includes USB unconditionally. This breaks when CONFIG_CMD_USB is not defined. Use a secondary macro to conditionally include it when CONFIG_EHCI is enabled, as we do for CONFIG_AHCI. The other patches are for the next release, but maybe this fix could go into 2014.10? I agree that this is a benign bug fix, but since we don't have any boards not setting CONFIG_EHCI atm I don't really see the value for getting it into 2014.10. FWIW I was planning on putting the whole series in #next until the next merge window as soon as I find a some spare moments to look through it (sorry, might take me a few more days, I'm travelling at the w/e). OK. Thanks for the heads up. ChenYu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
Hi Wolfgang, On 09/11/2014 09:46 AM, Wolfgang Denk wrote: Dear Michal, In message 54112b64.5010...@monstr.eu you wrote: I am not sure if you need to have separate repo to work like this. I am keeping zynq patches in my microblaze repo and sending pull request to Albert (or Tom now) and there is no problem with that. Well, technically of course this works, but it is far from perfect. It works only for those who actually know about this. But anybody looking at the U-Boot site for any zynq related stuff will have hard times to find it. Please don't get me wrong I am just trying to understand what happened. We have MAINTAINERS file where we can simply add person who is responsible for specific SOC. I also believe that this is exactly reason why to have it. From that file everybody can find out who should take the patches and and almost doesn't matter if git is at denx.de or somewhere else. But still all ARM patches should go through our ARM custodian not directly to Tom. get_maintainer.pl should also keep all interested people in the loop. I think it is much better to make this knowledge public information - and one easy way to do this is to have a separate repository for it, which is listed on the custodians page, so everybody looking for it will find all relevant information. Isn't that MAINTAINERS file already publicly available? Of course if you want to add the same information on wiki, I can't see any problem there. But creating separate repository for every SoC in u-boot seems to me just too much. In socfpga case I think there are guys from Altera who maintain it. Well, they maintain the stuff at rocketboards.org ; there are efforts on the way to mainline stuff, but the process is not exactly satisfactory. I highly appreciate that Marek volunteers to put efforts in this. Definitely I also really appreciate that Marek volunteers to be responsible for socfpga. But that means that guys who are responsible for socfpga failed and they are not responding for patches which others are sending to mailing list for review. I am not closely following them but did this really happen? If they don't want to maintain their socfpga in mainline and Marek wants to do it I will definitely support Marek in this new possition to get things done properly but also I just want to make sure that this is really happen and isn't it just the part of misunderstanding how u-boot community is working. As far as I am concerned, I support both Marek's and Masahiro's requests. @ Marek and Masahiro: if we reach an agreement to create such repos, please send me your SSH public keys that shall be used for these. Also, what should the names be - u-boot-socfpga ? And u-boot-uniphier ? [But is there not a chance that Pana- sonic might have other SoCs that might be mainlines? So maybe we should use u-boot-panasonic instead?] If they want to have separate repository because they think that it is better then their current one then sure why not to create them. Having arm SOC sub maintainers is definitely good concept but I am just not sure that creating separate repository fully solve this. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-arm/master
On Fri, Sep 12, 2014 at 03:42:19PM +0200, Albert ARIBAUD wrote: Hello Tom, The following changes since commit d6c1ffc7d23f4fe4ae8c91101861055b8e1501b6: Prepare v2014.10-rc2 (2014-09-02 16:58:29 -0400) are available in the git repository at: git://git.denx.de/u-boot-arm master for you to fetch changes up to a7f99bf139b3aaa0d5494693fd0395084355e41a: arm: Fix _start for CONFIG_SYS_DV_NOR_BOOT_CFG (2014-09-11 18:04:39 +0200) NOTE that 7 boards still fail building, two with warnings (k2e_evm k2hk_evm), five with errors (openrd_client tricorder_flash tricorder openrd_ultimate openrd_base). Ajay Kumar (8): exynos_fb: Remove usage of static defines arm: exynos: Add RPLL for Exynos5420 arm: exynos: Add get_lcd_clk and set_lcd_clk callbacks for Exynos5420 video: exynos_fimd: Add framework to disable FIMD sysmmu ARM: exynos: Add missing declaration for gpio_direction_input exynos5420: add callbacks needed for exynos_fb driver ARM: exynos: peach_pit: Add DT nodes for fimd and parade bridge chip CONFIGS: peach-pit: Enable display for peach_pit board Albert ARIBAUD (2): Merge branch 'u-boot-samsung/master' into 'u-boot-arm/master' Merge branch 'u-boot-sunxi/master' into 'u-boot-arm/master' Benoît Thébaudeau (2): arm: Make reset position-independent arm: Fix _start for CONFIG_SYS_DV_NOR_BOOT_CFG Enric Balletbo i Serra (1): AM335x: igep0033: Convert to generic board and use ti_am335x_common.h. FUKAUMI Naoki (1): sun7i: Add support for Olimex A20-OLinuXino-LIME Guillaume GARDET (1): omap3_beagle: Add boot script support to omap3 beagle board Ian Campbell (1): sunxi: Correct typo CONFIG_FTDFILE = CONFIG_FDTFILE Jeroen Hofstee (8): board_r: ARM[64] do not set gd again ARM: SPL: do not set gd again cc-option: also detect unsupported warnings options ARM: make gd a function for clang eabi_compat: add __aeabi_memcpy __aeabi_memset clang: workaround for generated constants Makefile: default to cc for host compiler README.clang: build command with clang Khoronzhuk, Ivan (3): ARM: keystone: clock: use correct BWADJ field mask for PASSPLLCTL0 keystone2: use readl/writel functions instead of redefinition mtd: nand: davinci_nand: correct keystone RBL layout definition Masahiro Yamada (3): arm: am335x: add Kconfig range attribute to prevent invalid CONS_INDEX MAINTAINERS: update the maintainer of Arndale board kconfig: remove redundant SPL from CONFIG_SYS_EXTRA_OPTIONS Przemyslaw Marczak (13): samsung: misc: fix soc revision setting in the set_board_info() exynos: pinmux: fix the gpio names for exynos4x12 mmc arch:exynos: boot mode: add get_boot_mode(), code cleanup board:samsung: check the boot device and init the right mmc driver. samsung: misc: add function for setting $dfu_alt_info samsung:board: misc_init_r: call set_dfu_alt_info() arm:reset: call the reset_misc() before the cpu reset samsung: board: enable support of multiple board types samsung: misc: use board specific functions to set env board info odroid: add board file for Odroid X2/U3 based on Samsung Exynos4412 odroid: add odroid U3/X2 device tree description odroid: kconfig: add odroid_defconfig odroid: set MPLL clock to 880MHz R Sricharan (1): ARM: DRA72: DDR3: Add emif settings for 666MHz clock Rostislav Lisovy (2): mtd: nand: omap_gpmc: Enable multiple NAND flash devices mtd: nand: omap_gpmc: Fix 'bit-flip' errors Vadim Bendebury (1): video: Add driver for Parade PS8625 dP to LVDS bridge Kbuild | 3 +- Makefile | 4 +- arch/arm/cpu/armv7/exynos/Kconfig | 4 + arch/arm/cpu/armv7/exynos/clock.c | 83 +++-- arch/arm/cpu/armv7/exynos/clock_init.h | 3 + arch/arm/cpu/armv7/exynos/clock_init_exynos5.c | 13 arch/arm/cpu/armv7/exynos/exynos5_setup.h | 2 +- arch/arm/cpu/armv7/exynos/pinmux.c | 4 +- arch/arm/cpu/armv7/exynos/power.c | 7 ++ arch/arm/cpu/armv7/exynos/spl_boot.c | 7 +- arch/arm/cpu/armv7/keystone/clock.c| 2 +- arch/arm/cpu/armv7/keystone/psc.c | 44 +-- arch/arm/cpu/armv7/omap5/hw_data.c | 39 +- arch/arm/cpu/armv7/omap5/sdram.c | 60 ++- arch/arm/dts/Makefile | 3 +- arch/arm/dts/exynos4412-odroid.dts | 70 ++ arch/arm/dts/exynos5420-peach-pit.dts | 30 arch/arm/dts/exynos54xx.dtsi | 10 +++ arch/arm/include/asm/arch-exynos/clk.h | 1 +
Re: [U-Boot] u-boot-socfpga repository
Dear Michal, In message 541334d0.80...@monstr.eu you wrote: But creating separate repository for every SoC in u-boot seems to me just too much. We're not talking about one repo for every SoC here. Definitely I also really appreciate that Marek volunteers to be responsible for socfpga. But that means that guys who are responsible for socfpga failed and they are not responding for patches which others are sending to mailing list for review. I am not closely following them but did this really happen? I think the problem is that so far nobody feels responsible for systematically mainlining the code. There are some patches here and there, but usually you cannot build a useful and working U-Boot image from the existing mainline code. If they don't want to maintain their socfpga in mainline and Marek wants to do it I will definitely support Marek in this new possition to get things done properly but also I just want to make sure that this is really happen and isn't it just the part of misunderstanding how u-boot community is working. Probably both. Having arm SOC sub maintainers is definitely good concept but I am just not sure that creating separate repository fully solve this. You are right - the repository is just one necessary step. A custodian who knows how the community works and who is willing to collect patches and synchronize efforts is also needed - this is where Marek volunteered for now. If someone from Altera is willing to take over, such a switch would be trivial to perform. 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 Build a system that even a fool can use and only a fool will want to use it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
Dear Dinh, In message 54133b22.2090...@opensource.altera.com you wrote: So I suggest we create u-boot-socfpga now, as this will be needed in any case when any significant amount of patches is coming in for mainline. For now, we assing Marek as custodian - he has volunteered, and he already has a reputation in the community. As soon as Vince starts actively working here on the mailing list, we can switch this role to him. NO..we'd like to maintain the u-boot-socfpga-next git repo at rocketboards.org. Altera(myself, Chin-Liang, and Vince) will actively maintain it from now on. I'm sorry, but that's not the way how the U-Boot community works. To get patches or new code into U-Boot mainline, these have to be submitted to the U-Boot mailing list (among other purposes for archival and that they get stored in the patchwork database). Then a peer review takes place, and the responsible custodian finally applies these patches to the respective custodian repository. Finally, he sends a pull request to the next higher custodian - in case of SoCFPGA that would be Albert as ARM custodian. There is nothing wrong with you maintaining u-boot-socfpga-next at rocketboards.org. It's just that such code does not get into mainline other than by the procedure described before. So we need the custodian repository in any way (unless Albert says he wants to take stuff directly into the ARM repo - but from the amount of work that is going on this seems unwise). Vince may of course volunteer as custodian for the new u-boot-socfpga repository, but that would be a community decision, and like everybody else in that role he needs to earn some reputation first - we haven't seen him at work so far. In the meantime, it appears to make sense that Marek fills in the gap. 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 You get a wonderful view from the point of no return. - Terry Pratchett, _Making_Money_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] (no subject)
Hello, I need to get this new version of u-boot for my PandaBoard A6 rev. I tried Linaro release 14.08 from July 2014 but all I get is the error: U-Boot SPL 2013.01.-rc1-g43ee87a (May 25 2014 - 07:45:31) OMAP4430 ES2.3 SDRAM: identified size not same as expected size identified: 0 expected: 4000 Is this fix applied to u-boot, and where can I get it ? Regards. Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom More information can be found at www.csr.com. Keep up to date with CSR on our technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube, www.youtube.com/user/CSRplc, Facebook, www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at www.twitter.com/CSR_plc. New for 2014, you can now access the wide range of products powered by aptX at www.aptx.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
On 09/12/2014 12:25 AM, Wolfgang Denk wrote: Dear Dinh, In message 54122de5.1080...@opensource.altera.com you wrote: Understood...You have just lit a fire in our arses! We have added a resource internally, Vince Bridgers, to help us upstream more u-boot support. Also, now that Linux support for SOCFPGA is decent, I will focus more on u-boot. That's great to hear, thank. So I suggest we create u-boot-socfpga now, as this will be needed in any case when any significant amount of patches is coming in for mainline. For now, we assing Marek as custodian - he has volunteered, and he already has a reputation in the community. As soon as Vince starts actively working here on the mailing list, we can switch this role to him. NO..we'd like to maintain the u-boot-socfpga-next git repo at rocketboards.org. Altera(myself, Chin-Liang, and Vince) will actively maintain it from now on. I went back to the mailing list last night and you're right, there were quite a few patches that had Chin-Liang's ACK, but sat idle. I'll start to pull those patches in ASAP. Thanks, Dinh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] (no subject)
Hi Il 12/set/2014 21:53 Mariusz Boguszewski mariusz.boguszew...@csr.com ha scritto: Hello, I need to get this new version of u-boot for my PandaBoard A6 rev. I tried Linaro release 14.08 from July 2014 but all I get is the error: U-Boot SPL 2013.01.-rc1-g43ee87a (May 25 2014 - 07:45:31) OMAP4430 ES2.3 SDRAM: identified size not same as expected size identified: 0 expected: 4000 Try to enable auto detection Michael Is this fix applied to u-boot, and where can I get it ? Regards. Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom More information can be found at www.csr.com. Keep up to date with CSR on our technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube, www.youtube.com/user/CSRplc, Facebook, www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at www.twitter.com/CSR_plc. New for 2014, you can now access the wide range of products powered by aptX at www.aptx.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
Hi all Il 12/set/2014 21:53 Dinh Nguyen dingu...@opensource.altera.com ha scritto: On 09/12/2014 12:25 AM, Wolfgang Denk wrote: Dear Dinh, In message 54122de5.1080...@opensource.altera.com you wrote: Understood...You have just lit a fire in our arses! We have added a resource internally, Vince Bridgers, to help us upstream more u-boot support. Also, now that Linux support for SOCFPGA is decent, I will focus more on u-boot. That's great to hear, thank. So I suggest we create u-boot-socfpga now, as this will be needed in any case when any significant amount of patches is coming in for mainline. For now, we assing Marek as custodian - he has volunteered, and he already has a reputation in the community. As soon as Vince starts actively working here on the mailing list, we can switch this role to him. NO..we'd like to maintain the u-boot-socfpga-next git repo at rocketboards.org. Altera(myself, Chin-Liang, and Vince) will actively maintain it from now on. I went back to the mailing list last night and you're right, there were quite a few patches that had Chin-Liang's ACK, but sat idle. I'll start to pull those patches in ASAP. If patches are in U-Boot mailing list, i don't see any problem to pull from their server. You should only agree how review process should be done. Michael Thanks, Dinh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-dm.git
Hi Tom (Rini), On 10 September 2014 13:04, Simon Glass s...@chromium.org wrote: Hi Tom, This pull includes driver model implementations for serial (uclass, sandbox and Tegra) as well as GPIO for Tegra, I've held off on exynos until we resolve some questions there. I'm not 100% sure it will make the release. Sorry I forgot to cc you on this pull request. Please let me know I need to re-issue it. The following changes since commit b7a809957bcd72c2efa49ce733774b1e28878585: Merge branch 'master' of git://www.denx.de/git/u-boot-microblaze (2014-09-10 06:59:49 -0400) are available in the git repository at: git://git.denx.de/u-boot-dm.git for you to fetch changes up to 858530a8c0a7ce7e573e513934804a00d6676813: dm: tegra: Enable driver model for serial (2014-09-10 13:00:02 -0600) Simon Glass (17): dm: Move pre-reloc init earlier to cope with board_early_init_f() Set up stdio earlier when using driver model dm: Make driver model available before board_init() dm: tegra: Set up a pre-reloc malloc() tegra: Convert tegra GPIO driver to use driver model serial: Set up the 'priv' pointer when creating a serial device dm: fdt: Add a function to look up a chosen node dm: Adjust lists_bind_fdt() to return the bound device dm: Add a uclass for serial devices sandbox: Convert serial driver to use driver model sandbox: serial: Support a coloured console sandbox: dts: Add a serial console node dm: serial: Move baud rate calculation to ns16550.c dm: serial: Collect common baud rate code in ns16550 dm: serial: Add driver model support for ns16550 tegra: dts: Add serial port details dm: tegra: Enable driver model for serial arch/arm/dts/tegra114-dalmore.dts | 4 + arch/arm/dts/tegra114.dtsi | 53 + arch/arm/dts/tegra124-jetson-tk1.dts | 4 + arch/arm/dts/tegra124-venice2.dts | 4 + arch/arm/dts/tegra124.dtsi | 66 + arch/arm/dts/tegra20-colibri_t20_iris.dts | 4 + arch/arm/dts/tegra20-harmony.dts | 4 + arch/arm/dts/tegra20-medcom-wide.dts | 4 + arch/arm/dts/tegra20-paz00.dts | 4 + arch/arm/dts/tegra20-plutux.dts| 4 + arch/arm/dts/tegra20-seaboard.dts | 4 + arch/arm/dts/tegra20-tec.dts | 4 + arch/arm/dts/tegra20-trimslice.dts | 4 + arch/arm/dts/tegra20-ventana.dts | 4 + arch/arm/dts/tegra20-whistler.dts | 4 + arch/arm/dts/tegra20.dtsi | 51 ++--- arch/arm/dts/tegra30-beaver.dts| 4 + arch/arm/dts/tegra30-cardhu.dts| 4 + arch/arm/dts/tegra30-tamonten.dtsi | 4 + arch/arm/dts/tegra30.dtsi | 66 + arch/arm/include/asm/arch-tegra/gpio.h | 15 ++-- arch/sandbox/dts/sandbox.dts | 10 +++ board/nvidia/seaboard/seaboard.c | 2 +- common/board_f.c | 4 +- common/board_r.c | 19 +++-- common/stdio.c | 18 - doc/device-tree-bindings/serial/ns16550.txt| 10 +++ doc/device-tree-bindings/serial/sandbox-serial.txt | 13 drivers/core/lists.c | 10 ++- drivers/core/root.c| 2 +- drivers/gpio/tegra_gpio.c | 327 ++-- drivers/serial/Makefile| 7 +- drivers/serial/ns16550.c | 203 -- drivers/serial/sandbox.c | 140 +++--- drivers/serial/serial-uclass.c | 213 drivers/serial/serial.c| 1 + drivers/serial/serial_ns16550.c| 14 +--- drivers/serial/serial_tegra.c | 38 ++ include/configs/sandbox.h | 3 + include/configs/tegra-common.h | 11 ++- include/dm/lists.h | 6 +- include/dm/uclass-id.h | 1 + include/dt-bindings/clock/tegra114-car.h | 342 include/dt-bindings/clock/tegra124-car.h | 342
Re: [U-Boot] u-boot-socfpga repository
Hi guys, I'm going to jump in here with an end-user's perspective, along with an offer of assistance/contribution. I'm interested in using Altera's SOCs in my designs. Altera guys - if you look over on the Altera Forum, you will see that I am very active over there (basically answering everyone's FPGA questions). Up until now I have avoided any SoC development kits as I considered the software support to not have matured enough. I consider mature code to be code that I can checkout from mainline, where mainline is U-Boot via the Denx repos, and Linux via the Kernel repos. Freescale has done this forever, and I hold their processors and code in high regard. Texas Instruments has recently realized that this is the way to go, and have invested significantly in this area - as demonstrated by Tom Rini. TI have dedicated a page to mainlining: http://www.ti.com/lsds/ti/tools-software/mainlinelinux.page TI have similarly gained my respect. The fact that discussion is now occurring for Altera's SoCs indicates to me that a certain level of maturity has been reached and that it is now time for me to consider using these devices. I'd like to help, and I'm sure Ira Snyder will help too (most likely more so than me). I would like to obtain some SoC development kits so as to help with the SoC experience for end-users. To aid in this development, I'd like some recommendations on what hardware to buy. I've included the list below the body of this email (to save cluttering the flow of this discussion). Its possible for me to obtain one or more of these boards. Which ones are supported in mainline U-Boot and Linux? What will it take to make it easier for the end-user like myself? I would like to be able to buy something like the Critical Link or Denx modules and simply plug them into my custom hardware, configure the FPGA fabric with whatever custom magic I need, have Ira develop a custom drive to that magic and just have things *WORK*. As an end-user, I don't want to have to pull a dozen patches off the mailing list to get a working system. Altera's success in the SoC market depends on getting it right with respect to integration with the open-source community. That integration involves playing by the established set of rules. Wolfgang and his (creation and) support of U-Boot is of immeasurable value to the open-source community. Altera developers, please follow Wolfgang's advice. Cheers, Dave Hawkins, California Institute of Technology. -- 1. Cyclone V SoC Development Kit http://www.altera.com/products/devkits/altera/kit-cyclone-v-soc.html This is the main kit that most people are probably developing with. At $1,795 its pretty expensive, but I could request a couple of kits from the Altera University Program. 2. Arria V SoC kit http://www.altera.com/products/devkits/altera/kit-arria-v-soc.html At $3,495 this is also very expensive. This board still ships with ES (Engineering Sample), so I would not buy this yet. 3. Terasic/Arrow SOCKit http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=EnglishNo=816 At $299 this is pretty reasonable. 4. SOC System-on-Modules http://www.altera.com/devices/processor/soc-fpga/cyclone-v-soc/module/system-module.html eg, Critical Link MitySOM http://www.criticallink.com/product/mitysom-5csx/ http://www.mouser.com/ProductDetail/Critical-Link/5CSX-H6-42A-RC/?qs=sGAEpiMZZMvtrnhC60i%252bOnQkBUtKjKom2RbBJy3SVoI%3d Each module is about $600 at Mouser. 5. Denx MCV board http://www.denx-cs.de/?q=MCV These modules look reasonably priced. The CriticalLink and Denx modules look suitable for my intended application, i.e., as the controller for a much larger FPGA board. Wolfgang - feel free to advise me to use the Denx modules, and I'll take a more critical look at the data sheets to check they have the features I want to use. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
Hi Il 12/set/2014 23:16 David Hawkins d...@ovro.caltech.edu ha scritto: Hi guys, I'm going to jump in here with an end-user's perspective, along with an offer of assistance/contribution. I'm interested in using Altera's SOCs in my designs. Altera guys - if you look over on the Altera Forum, you will see that I am very active over there (basically answering everyone's FPGA questions). Up until now I have avoided any SoC development kits as I considered the software support to not have matured enough. I consider mature code to be code that I can checkout from mainline, where mainline is U-Boot via the Denx repos, and Linux via the Kernel repos. Freescale has done this forever, and I hold their processors and code in high regard. Texas Instruments has recently realized that this is the way to go, and have invested significantly in this area - as demonstrated by Tom Rini. TI have dedicated a page to mainlining: http://www.ti.com/lsds/ti/tools-software/mainlinelinux.page TI have similarly gained my respect. The fact that discussion is now occurring for Altera's SoCs indicates to me that a certain level of maturity has been reached and that it is now time for me to consider using these devices. I'd like to help, and I'm sure Ira Snyder will help too (most likely more so than me). I would like to obtain some SoC development kits so as to help with the SoC experience for end-users. To aid in this development, I'd like some recommendations on what hardware to buy. I've included the list below the body of this email (to save cluttering the flow of this discussion). Its possible for me to obtain one or more of these boards. Which ones are supported in mainline U-Boot and Linux? What will it take to make it easier for the end-user like myself? I would like to be able to buy something like the Critical Link or Denx modules and simply plug them into my custom hardware, configure the FPGA fabric with whatever custom magic I need, have Ira develop a custom drive to that magic and just have things *WORK*. As an end-user, I don't want to have to pull a dozen patches off the mailing list to get a working system. Altera's success in the SoC market depends on getting it right with respect to integration with the open-source community. That integration involves playing by the established set of rules. Wolfgang and his (creation and) support of U-Boot is of immeasurable value to the open-source community. Altera developers, please follow Wolfgang's advice. Cheers, Dave Hawkins, California Institute of Technology. We know and thank you very much for price list ;) Michael -- 1. Cyclone V SoC Development Kit http://www.altera.com/products/devkits/altera/kit-cyclone-v-soc.html This is the main kit that most people are probably developing with. At $1,795 its pretty expensive, but I could request a couple of kits from the Altera University Program. 2. Arria V SoC kit http://www.altera.com/products/devkits/altera/kit-arria-v-soc.html At $3,495 this is also very expensive. This board still ships with ES (Engineering Sample), so I would not buy this yet. 3. Terasic/Arrow SOCKit http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=EnglishNo=816 At $299 this is pretty reasonable. 4. SOC System-on-Modules http://www.altera.com/devices/processor/soc-fpga/cyclone-v-soc/module/system-module.html eg, Critical Link MitySOM http://www.criticallink.com/product/mitysom-5csx/ http://www.mouser.com/ProductDetail/Critical-Link/5CSX-H6-42A-RC/?qs=sGAEpiMZZMvtrnhC60i%252bOnQkBUtKjKom2RbBJy3SVoI%3d Each module is about $600 at Mouser. 5. Denx MCV board http://www.denx-cs.de/?q=MCV These modules look reasonably priced. The CriticalLink and Denx modules look suitable for my intended application, i.e., as the controller for a much larger FPGA board. Wolfgang - feel free to advise me to use the Denx modules, and I'll take a more critical look at the data sheets to check they have the features I want to use. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
Hi Michael, We know and thank you very much for price list ;) I hope my incomplete list of vendors did not offend you. I'm board vendor agnostic. If your company has an Altera SoC board, I'm more than happy to look at it too. Feel free to offer alternative options :) Cheers, Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
Hi Dave Il 12/set/2014 23:23 David Hawkins d...@ovro.caltech.edu ha scritto: Hi Michael, We know and thank you very much for price list ;) I hope my incomplete list of vendors did not offend you. I'm board vendor agnostic. If your company has an Altera SoC board, I'm more than happy to look at it too. Feel free to offer alternative options :) It was just nice. I'm agree with you but I don't see any problem to have different host domain at the end. Michael PS: tools take to much time to build design on my laptop Cheers, Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
On 09/12/2014 02:46 PM, Wolfgang Denk wrote: Dear Dinh, In message 54133b22.2090...@opensource.altera.com you wrote: So I suggest we create u-boot-socfpga now, as this will be needed in any case when any significant amount of patches is coming in for mainline. For now, we assing Marek as custodian - he has volunteered, and he already has a reputation in the community. As soon as Vince starts actively working here on the mailing list, we can switch this role to him. NO..we'd like to maintain the u-boot-socfpga-next git repo at rocketboards.org. Altera(myself, Chin-Liang, and Vince) will actively maintain it from now on. I'm sorry, but that's not the way how the U-Boot community works. To get patches or new code into U-Boot mainline, these have to be submitted to the U-Boot mailing list (among other purposes for archival and that they get stored in the patchwork database). Then a peer review takes place, and the responsible custodian finally applies these patches to the respective custodian repository. Finally, he sends a pull request to the next higher custodian - in case of SoCFPGA that would be Albert as ARM custodian. Does the above process differ from the Linux community process in anyway? If not, then I've been doing the same for the Linux support for SOCFPGA on the rocketboards. The ARM-SOC maintainers have been pulling from the git repo at rocketboards for quite some time now. I think I can probably do the same for u-boot. Dinh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
On 09/12/2014 04:05 PM, David Hawkins wrote: Hi guys, I'm going to jump in here with an end-user's perspective, along with an offer of assistance/contribution. I'm interested in using Altera's SOCs in my designs. Altera guys - if you look over on the Altera Forum, you will see that I am very active over there (basically answering everyone's FPGA questions). Awesome...thank you for your support! Up until now I have avoided any SoC development kits as I considered the software support to not have matured enough. I consider mature code to be code that I can checkout from mainline, where mainline is U-Boot via the Denx repos, and Linux via the Kernel repos. For Linux, we have done a better job than u-boot. You should be able to have most of what you need from kernel.org for the Altera Devkits and Terasic SocKit board. The most important piece maybe the FPGA manager, otherwise the SOCFPGA platform is just any other A9 board. The FPGA manager is in-flight: https://lkml.org/lkml/2014/8/1/517 For U-boot, the upstreaming process has been slow. I admit it, but it is very high on our to-do list. Freescale has done this forever, and I hold their processors and code in high regard. I used to work at Freescale's doing the i.MX parts. I hope these were the processors you had in the mind? Texas Instruments has recently realized that this is the way to go, and have invested significantly in this area - as demonstrated by Tom Rini. TI have dedicated a page to mainlining: http://www.ti.com/lsds/ti/tools-software/mainlinelinux.page TI have similarly gained my respect. The fact that discussion is now occurring for Altera's SoCs indicates to me that a certain level of maturity has been reached and that it is now time for me to consider using these devices. I'd like to help, and I'm sure Ira Snyder will help too (most likely more so than me). I would like to obtain some SoC development kits so as to help with the SoC experience for end-users. To aid in this development, I'd like some recommendations on what hardware to buy. I've included the list below the body of this email (to save cluttering the flow of this discussion). Its possible for me to obtain one or more of these boards. Which ones are supported in mainline U-Boot and Linux? What will it take to make it easier for the end-user like myself? Echoing earlier...There is good Linux support for the Altera Cyclone5 and Arria5 devkit and Terasic SoCkit from kernel.org. I would like to be able to buy something like the Critical Link or Denx modules and simply plug them into my custom hardware, configure the FPGA fabric with whatever custom magic I need, have Ira develop a custom drive to that magic and just have things *WORK*. As an end-user, I don't want to have to pull a dozen patches off the mailing list to get a working system. Altera's success in the SoC market depends on getting it right with respect to integration with the open-source community. That integration involves playing by the established set of rules. Wolfgang and his (creation and) support of U-Boot is of immeasurable value to the open-source community. Altera developers, please follow Wolfgang's advice. Wolfgang's advice is valuable and noted. However, it is in Altera's best interest that we have 1 central gathering point for all our opensource software support. I maintain a linux-next git repo at rocketboards for patches that have been properly reviewed, and acked-by that are destined for kernel.org. The logic should follow that I(Altera) would do the same for u-boot patches at rocketboards that are destined for mainline u-boot at denx. Thanks, Dinh Cheers, Dave Hawkins, California Institute of Technology. -- 1. Cyclone V SoC Development Kit http://www.altera.com/products/devkits/altera/kit-cyclone-v-soc.html This is the main kit that most people are probably developing with. At $1,795 its pretty expensive, but I could request a couple of kits from the Altera University Program. 2. Arria V SoC kit http://www.altera.com/products/devkits/altera/kit-arria-v-soc.html At $3,495 this is also very expensive. This board still ships with ES (Engineering Sample), so I would not buy this yet. 3. Terasic/Arrow SOCKit http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=EnglishNo=816 At $299 this is pretty reasonable. 4. SOC System-on-Modules http://www.altera.com/devices/processor/soc-fpga/cyclone-v-soc/module/system-module.html eg, Critical Link MitySOM http://www.criticallink.com/product/mitysom-5csx/ http://www.mouser.com/ProductDetail/Critical-Link/5CSX-H6-42A-RC/?qs=sGAEpiMZZMvtrnhC60i%252bOnQkBUtKjKom2RbBJy3SVoI%3d Each module is about $600 at Mouser. 5. Denx MCV board http://www.denx-cs.de/?q=MCV These modules look reasonably
Re: [U-Boot] u-boot-socfpga repository
Dear Dinh, In message 54136276.6040...@opensource.altera.com you wrote: To get patches or new code into U-Boot mainline, these have to be submitted to the U-Boot mailing list (among other purposes for archival and that they get stored in the patchwork database). Then a peer review takes place, and the responsible custodian finally applies these patches to the respective custodian repository. Finally, he sends a pull request to the next higher custodian - in case of SoCFPGA that would be Albert as ARM custodian. Does the above process differ from the Linux community process in anyway? If not, then I've been doing the same for the Linux support for SOCFPGA on the rocketboards. The ARM-SOC maintainers have been pulling from the git repo at rocketboards for quite some time now. I think I can probably do the same for u-boot. I think we are a bit more critical here in U-Boot. The repositories we pull from are maintained by community-assigned custodians, who have a proven track record not only as experienced developers, but also for working with the community and being able to negotiate conflicts. If Vince gets appointed as custodian for socfpga, there should be no problem for him to automatically synchronize your u-boot-socfpga-next.git repository with the U-Boot u-boot-socfpga one. On the other hand - what exactly is the code you are referring to in u-boot-socfpga-next.git ? At the moment, I see this: - git clone git://git.rocketboards.org/u-boot-socfpga-next.git Cloning into 'u-boot-socfpga-next'... warning: You appear to have cloned an empty repository. Checking connectivity... done. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Only in our dreams we are free. The rest of the time we need wages. - Terry Pratchett, _Wyrd Sisters_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
On 09/12/2014 05:14 PM, Wolfgang Denk wrote: Dear Dinh, In message 54136276.6040...@opensource.altera.com you wrote: To get patches or new code into U-Boot mainline, these have to be submitted to the U-Boot mailing list (among other purposes for archival and that they get stored in the patchwork database). Then a peer review takes place, and the responsible custodian finally applies these patches to the respective custodian repository. Finally, he sends a pull request to the next higher custodian - in case of SoCFPGA that would be Albert as ARM custodian. Does the above process differ from the Linux community process in anyway? If not, then I've been doing the same for the Linux support for SOCFPGA on the rocketboards. The ARM-SOC maintainers have been pulling from the git repo at rocketboards for quite some time now. I think I can probably do the same for u-boot. I think we are a bit more critical here in U-Boot. The repositories we pull from are maintained by community-assigned custodians, who have a proven track record not only as experienced developers, but also for working with the community and being able to negotiate conflicts. If Vince gets appointed as custodian for socfpga, there should be no problem for him to automatically synchronize your u-boot-socfpga-next.git repository with the U-Boot u-boot-socfpga one. Then I vote for myself as the custodian for u-boot-socfpga. By the way, what is the difference between a Maintainer and a custodian? I don't understand why if Chin-Liang and myself are listed as Maintainer(s) for SOCFPGA, we would have to rely on Marek to pull in our patches for SOCFPGA? On the other hand - what exactly is the code you are referring to in u-boot-socfpga-next.git ? At the moment, I see this: - git clone git://git.rocketboards.org/u-boot-socfpga-next.git Cloning into 'u-boot-socfpga-next'... warning: You appear to have cloned an empty repository. Checking connectivity... done. Yes, this is the repo will be the one that we will use. I have a couple of other things on my plate at the moment and will populate this repo shortly. Dinh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
Dear Dinh, In message 5413667d.50...@opensource.altera.com you wrote: Wolfgang's advice is valuable and noted. However, it is in Altera's best interest that we have 1 central gathering point for all our opensource software support. Full agreement here. But I would like to point out that your point of view appears to be biased: U-Boot mainline is a community project, and the community is very much vendor-independent. So the question we're trying to solve here is not what is optimal for Altera, but what is optimal for the community. As is, current mainline U-Boot is not really working well on most SoCFPGA systems. Progress is dissatisfactory slow. Marek volunteers to help out now, and you promise to chime in very soon. I see no conflict here. Let us create the u-boot-socfpga repository we need in any case, and agree with Marek as custodian until Vince has gathered enough reputation to relieve Marek. I talked to him - he is not clinging to that job, he just sees the need to get the current problems solved now, not in some uncertain future. Please try to understand that this is totally unrelated to what you do at u-boot-socfpga-next - it does not influence your work there in any way. Ideally, your u-boot-socfpga-next and the mainline u-boot-socfpga repositories would be just redundant copies. On the other hand, setting up u-boot-socfpga now allows the community to make some progress until you (rsp. Vince) start populating u-boot-socfpga-next and gather experience working with the community. So it is actually in both the community's and Altera's best interest to get a mainline u-boot-socfpga set up without further delay. 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 Well, the way I see it, logic is only a way of being ignorant by num- bers. - Terry Pratchett, _Small Gods_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
Dear Dinh, In message 541373ad.4020...@opensource.altera.com you wrote: Then I vote for myself as the custodian for u-boot-socfpga. By the way, May I ask what made you change your mind like that? First you wrote that Vince was assigned to to that, and now it's suddenly you? As far as I can see, you have not participated in any SoCPGA related code reviews or discussions in 2014 at all, so what would be the difference? what is the difference between a Maintainer and a custodian? I don't understand why if Chin-Liang and myself are listed as Maintainer(s) for SOCFPGA, we would have to rely on Marek to pull in our patches for SOCFPGA? A maintainer is someone who developed some piece of code and feels responsible for it - who is available as contact person for questions, or who will be asked to fix any bugs in that code. A Custodian is one that guards and protects or maintains [1], i. e. he is responsible for maintaining the design principles of U-Boot and the code quality even for code he did not work on himself, and for patches submitted by others. This is a job that carries a much higher responsibility than just maintaining your own code. He will interface to the actual maintainers of the respective code, negotiatiate solutions and decide in case of conflicts. [1] http://www.merriam-webster.com/dictionary/custodian Yes, this is the repo will be the one that we will use. I have a couple of other things on my plate at the moment and will populate this repo shortly. Thats great, as it means you will not lose any efforts when we start with u-boot-socfpga now, as you then can start with synchronized repositories right from the beginning. 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 In the long run, every program becomes rococo, and then rubble. - Alan Perlis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
Hi all, Texas Instruments has recently realized that this is the way to go, and have invested significantly in this area - as demonstrated by Tom Rini. TI have dedicated a page to mainlining: http://www.ti.com/lsds/ti/tools-software/mainlinelinux.page TI also has a very nice article in Electronic Products on the benefits of mainlining Linux ... http://www.electronicproducts.com/Software/Development_Tools_and_Software/The_benefits_of_Mainline_Linux_and_the_mindset_of_upstream_development.aspx Altera would benefit from a similar philosophy. Cheers, Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/8] U-Boot port to Xtensa architecture
Hi Michal, On Fri, Aug 29, 2014 at 6:46 AM, Michal Simek mon...@monstr.eu wrote: On 08/29/2014 02:25 PM, Max Filippov wrote: On Fri, Aug 29, 2014 at 3:50 PM, Michal Simek mon...@monstr.eu wrote: Any link to bitstreams? I have ml605 and kc705 here and will be nice to test it. The board alone is not enough to boot xtensa software, as the JTAG connector capable of loading code into CPU goes on a separate daughterboard that plugs into FMC connectors. I will check if I can share a bitstream and if it may be somehow used with the FPGA board alone. Any link to that FMC connector and connections there? However you should be able to test with qemu, as it simulates all necessary hardware. Some examples are listed here: http://wiki.linux-xtensa.org/index.php/Xtensa_on_QEMU I am more interested to see this work on real HW than on qemu. Tensilica IP group is willing to provide you the bitstream and the related documentation, but for its own protection it wants you to sign a license agreement. It is said to be short and written in plain language. I will provide additional details privately. -- Thanks. -- Max ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
