Re: [U-Boot] [PATCH] usb: ums: add error handling for failed registration
Hi Marek, On Thursday, May 01, 2014 at 11:42:10 PM, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com Without this, if g_dnl_register() fails, the UMS code continues on blindly and crashes. This fix makes it simply print an error message instead. Signed-off-by: Stephen Warren swar...@nvidia.com Acked-by: Marek Vasut ma...@denx.de Lukasz, can you pick this please? Best regards, Marek Vasut Applied to u-boot-dfu. Thanks. -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/8] ums: support block devices not MMC devices
Hi Marek, On Monday, May 05, 2014 at 06:40:11 PM, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com The USB Mass Storage function could equally well support a SATA device as support an MMC device. Update struct ums to contain a block device descriptor, not an MMC device descriptor. Cc: Lukasz Majewski l.majew...@samsung.com Signed-off-by: Stephen Warren swar...@nvidia.com Acked-by: Przemyslaw Marczak p.marc...@samsung.com Lukasz, I think this series is yours, right ? :) We feel a bit responsible for the gadget code :-). Przemek (If he don't mind :-)) will look into the v2 of the UMS, since Stephen has sent it yesterday, and if nothing breaks I will pull them to u-boot-dfu branch. Best regards, Marek Vasut -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/3] usb:gadget:f_thor: code cleanup in function download_tail()
Hello Heiko, On 04/28/2014 06:57 PM, Przemyslaw Marczak wrote: In thor's download_tail() function, dfu_get_entity() is called before each dfu_write() call and the returned entity pointers are the same. So dfu_get_entity() can be called just once and this patch changes this. Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com Cc: Lukasz Majewski l.majew...@samsung.com Cc: Marek Vasut ma...@denx.de Cc: Heiko Schocher h...@denx.de Cc: Tom Rini tr...@ti.com --- Changes v2: - separate fix and cleanup into two commits Changes v3: - download_tail(): add exit label Changes v4: - none --- Could you look at those changes, please? Thank you -- 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] Verified boot and Legacy Kernel Images
Hello Mike, Am 05.05.2014 16:27, schrieb Mike Pearce: Please help as I am confused. I implemented verified boot on 2014.04 using CONFIG_OF_SEPARATE and it works fine with FIT images. However it still boots the resident legacy kernal that has not been signed. This means that anyone wishing to circumvent the signed hash can do so by replacing the image file with a legacy one. That makes for a security hole and so I must have done something wrong. No, you did nothing wrong ... When I look at function bootm_find_os() from file cmd_bootm.c its switch statement provides this behaviour - case IMAGE_FORMAT_LEGACY: cool, its a go from me. Verify using an unsigned hash. break; #if defined(CONFIG_FIT) case IMAGE_FORMAT_FIT: do the signed hash checks when loading the image. break; What I cannot find in the code is anything that I can compile in to prevent an unsigned legacy kernel from booting. The defines I already used include #define CONFIG_OF_LIBFDT #define CONFIG_CMD_HASH #define CONFIG_HASH_VERIFY #define CONFIG_FIT_SIGNATURE #define CONFIG_RSA See this thread: http://lists.denx.de/pipermail/u-boot/2014-May/178800.html in particular Simons statement: http://lists.denx.de/pipermail/u-boot/2014-May/178922.html - Currently, nothing prevents to boot an unsigned legacy kernel ... Patches are welcome ;-) bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/12] MX6: add boot device support for SPL
On Mon, 5 May 2014 08:46:24 -0700
Tim Harvey thar...@gateworks.com wrote:
+cc Edward Lin
On Mon, May 5, 2014 at 2:14 AM, Stefano Babic sba...@denx.de wrote:
Hi Tim,
...
--- /dev/null
+++ b/arch/arm/imx-common/spl.c
@@ -0,0 +1,79 @@
+/*
+ * Copyright (C) 2014 Gateworks Corporation
+ * Author: Tim Harvey thar...@gateworks.com
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
Just a little remark. Do you have written the function on your own or
have you ported it from Freescale's 2009.08 ? Apart names, it looks similar.
If this is the case, you should also add Freescale's Copyright to the
header.
Hi Stefano,
I've never looked at Freescales 2009.08 code myself (I have an
aversion to vendor specific forks of u-boot almost 5 years old heh),
but its likely bits of the function came from there originally but my
inspiration likely came from Edward Lin's patch a while back. A
switch/case seems the logical approach given the bitfield from the
IMX6 reference manual with several don't-cares spread around and I
felt that was much easier to read than trying to convert it all the
shifts and masks.
I can add additional copyright's if anyone feels its necessary - I've
added Edward to the cc to see if he feels its necessary.
Tim
+#include common.h
+#include asm/io.h
+#include asm/arch/imx-regs.h
+#include asm/spl.h
+#include spl.h
+
+#if defined(CONFIG_MX6)
+/* determine boot device from SRC_SBMR1 register (BOOT_CFG[4:1]) */
+u32 spl_boot_device(void)
+{
+ struct src *psrc = (struct src *)SRC_BASE_ADDR;
+ unsigned reg = readl(psrc-sbmr1);
+
+ /* BOOT_CFG1[7:4] - see IMX6DQRM Table 8-8 */
+ switch ((reg 0x00FF) 4) {
+ /* EIM: See 8.5.1, Table 8-9 */
+ case 0x0:
+ /* BOOT_CFG1[3]: NOR/OneNAND Selection */
+ if ((reg 0x0008) 3)
+ return BOOT_DEVICE_ONENAND;
+ else
+ return BOOT_DEVICE_NOR;
+ break;
+ /* SATA: See 8.5.4, Table 8-20 */
+ case 0x2:
+ return BOOT_DEVICE_SATA;
+ /* Serial ROM: See 8.5.5.1, Table 8-22 */
+ case 0x3:
+ /* BOOT_CFG4[2:0] */
+ switch ((reg 0x0700) 24) {
+ case 0x0 ... 0x4:
+ return BOOT_DEVICE_SPI;
+ case 0x5 ... 0x7:
+ return BOOT_DEVICE_I2C;
+ }
+ break;
+ /* SD/eSD: 8.5.3, Table 8-15 */
+ case 0x4:
+ case 0x5:
+ return BOOT_DEVICE_MMC1;
+ /* MMC/eMMC: 8.5.3 */
+ case 0x6:
+ case 0x7:
+ return BOOT_DEVICE_MMC1;
+ /* NAND Flash: 8.5.2 */
+ case 0x8 ... 0xf:
+ return BOOT_DEVICE_NAND;
+ }
+ return BOOT_DEVICE_NONE;
+}
+#endif
+
+#if defined(CONFIG_SPL_MMC_SUPPORT)
+/* called from spl_mmc to see type of boot mode for storage (RAW or FAT)
*/
+u32 spl_boot_mode(void)
+{
+ switch (spl_boot_device()) {
+ /* for MMC return either RAW or FAT mode */
+ case BOOT_DEVICE_MMC1:
+ case BOOT_DEVICE_MMC2:
+#ifdef CONFIG_SPL_FAT_SUPPORT
+ return MMCSD_MODE_FAT;
+#else
+ return MMCSD_MODE_RAW;
+#endif
+ break;
+ default:
+ puts(spl: ERROR: unsupported device\n);
+ hang();
+ }
+}
+#endif
Tim, Stefano,
that piece of code indeed originates from Freescale's 2009.08 u-boot.
(Edward has changed jobs, so the CC:d address is of no use.)
regards,
//Tapani
ps: Tim, thanks for getting the SPL framework mainlined!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] fs:ext4:write:fix: Reinitialize global variables after updating a file
This bug shows up when file stored on the ext4 file system is updated.
The ext4fs_delete_file() is responsible for deleting file's (e.g. uImage)
data.
However some global data (especially ext4fs_indir2_block), which is used
during file deletion are left unchanged.
The ext4fs_indir2_block pointer stores reference to old ext4 double
indirect allocated blocks. When it is unchanged, after file deletion,
ext4fs_write_file() uses the same pointer (since it is already initialized
- i.e. not NULL) to return number of blocks to write. This trunks larger
file when previous one was smaller.
Lets consider following scenario:
1. Flash target with ext4 formatted boot.img (which has uImage [*] on itself)
2. Developer wants to upload their custom uImage [**]
- When new uImage [**] is smaller than the [*] - everything works
correctly - we are able to store the whole smaller file with corrupted
ext4fs_indir2_block pointer
- When new uImage [**] is larger than the [*] - theCRC is corrupted,
since truncation on data stored at eMMC was done.
3. When uImage CRC error appears, then reboot and LTHOR/DFU reflashing causes
proper setting of ext4fs_indir2_block() and after that uImage[**]
is successfully stored (correct uImage [*] metadata is stored at an
eMMC on the first flashing).
Due to above the bug was very difficult to reproduce.
This patch sets default values for all ext4fs_indir* pointers/variables.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
Changes for v2:
- Add comment describing the purpose of ext4fs_reinit_global() function
---
fs/ext4/ext4_common.c | 35 ++-
fs/ext4/ext4_write.c |1 +
include/ext4fs.h |1 +
3 files changed, 28 insertions(+), 9 deletions(-)
diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c
index 62e2e80..1c11721 100644
--- a/fs/ext4/ext4_common.c
+++ b/fs/ext4/ext4_common.c
@@ -1841,16 +1841,20 @@ long int read_allocated_block(struct ext2_inode *inode,
int fileblock)
return blknr;
}
-void ext4fs_close(void)
+/**
+ * ext4fs_reinit_global() - Reinitialize values of ext4 write implementation's
+ * global pointers
+ *
+ * This function assures that for a file with the same name but different size
+ * the sequential store on the ext4 filesystem will be correct.
+ *
+ * In this function the global data, responsible for internal representation
+ * of the ext4 data are initialized to the reset state. Without this, during
+ * replacement of the smaller file with the bigger truncation of new file was
+ * performed.
+ */
+void ext4fs_reinit_global(void)
{
- if ((ext4fs_file != NULL) (ext4fs_root != NULL)) {
- ext4fs_free_node(ext4fs_file, ext4fs_root-diropen);
- ext4fs_file = NULL;
- }
- if (ext4fs_root != NULL) {
- free(ext4fs_root);
- ext4fs_root = NULL;
- }
if (ext4fs_indir1_block != NULL) {
free(ext4fs_indir1_block);
ext4fs_indir1_block = NULL;
@@ -1870,6 +1874,19 @@ void ext4fs_close(void)
ext4fs_indir3_blkno = -1;
}
}
+void ext4fs_close(void)
+{
+ if ((ext4fs_file != NULL) (ext4fs_root != NULL)) {
+ ext4fs_free_node(ext4fs_file, ext4fs_root-diropen);
+ ext4fs_file = NULL;
+ }
+ if (ext4fs_root != NULL) {
+ free(ext4fs_root);
+ ext4fs_root = NULL;
+ }
+
+ ext4fs_reinit_global();
+}
int ext4fs_iterate_dir(struct ext2fs_node *dir, char *name,
struct ext2fs_node **fnode, int *ftype)
diff --git a/fs/ext4/ext4_write.c b/fs/ext4/ext4_write.c
index 3db22f8..c42add9 100644
--- a/fs/ext4/ext4_write.c
+++ b/fs/ext4/ext4_write.c
@@ -562,6 +562,7 @@ static int ext4fs_delete_file(int inodeno)
ext4fs_update();
ext4fs_deinit();
+ ext4fs_reinit_global();
if (ext4fs_init() != 0) {
printf(error in File System init\n);
diff --git a/include/ext4fs.h b/include/ext4fs.h
index aacb147..fbbb002 100644
--- a/include/ext4fs.h
+++ b/include/ext4fs.h
@@ -133,6 +133,7 @@ int ext4fs_open(const char *filename);
int ext4fs_read(char *buf, unsigned len);
int ext4fs_mount(unsigned part_length);
void ext4fs_close(void);
+void ext4fs_reinit_global(void);
int ext4fs_ls(const char *dirname);
int ext4fs_exists(const char *filename);
void ext4fs_free_node(struct ext2fs_node *node, struct ext2fs_node *currroot);
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] fs:ext4:cleanup: Remove superfluous code
Code responsible for handling situation when ext4 has block size of 1024B
can be ordered to take less space.
This patch does that for ext4 common and write files.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
Changes for v2:
- Remove () parenthesis around pointers
---
fs/ext4/ext4_common.c |6 ++
fs/ext4/ext4_write.c | 56 +
2 files changed, 21 insertions(+), 41 deletions(-)
diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c
index 02da75c..62e2e80 100644
--- a/fs/ext4/ext4_common.c
+++ b/fs/ext4/ext4_common.c
@@ -904,10 +904,8 @@ long int ext4fs_get_new_blk_no(void)
restart:
fs-curr_blkno++;
/* get the blockbitmap index respective to blockno */
- if (fs-blksz != 1024) {
- bg_idx = fs-curr_blkno / blk_per_grp;
- } else {
- bg_idx = fs-curr_blkno / blk_per_grp;
+ bg_idx = fs-curr_blkno / blk_per_grp;
+ if (fs-blksz == 1024) {
remainder = fs-curr_blkno % blk_per_grp;
if (!remainder)
bg_idx--;
diff --git a/fs/ext4/ext4_write.c b/fs/ext4/ext4_write.c
index b674b6f..3db22f8 100644
--- a/fs/ext4/ext4_write.c
+++ b/fs/ext4/ext4_write.c
@@ -116,10 +116,8 @@ static void delete_single_indirect_block(struct ext2_inode
*inode)
if (inode-b.blocks.indir_block != 0) {
debug(SIPB releasing %u\n, inode-b.blocks.indir_block);
blknr = inode-b.blocks.indir_block;
- if (fs-blksz != 1024) {
- bg_idx = blknr / blk_per_grp;
- } else {
- bg_idx = blknr / blk_per_grp;
+ bg_idx = blknr / blk_per_grp;
+ if (fs-blksz == 1024) {
remainder = blknr % blk_per_grp;
if (!remainder)
bg_idx--;
@@ -181,11 +179,9 @@ static void delete_double_indirect_block(struct ext2_inode
*inode)
break;
debug(DICB releasing %u\n, *di_buffer);
- if (fs-blksz != 1024) {
- bg_idx = (*di_buffer) / blk_per_grp;
- } else {
- bg_idx = (*di_buffer) / blk_per_grp;
- remainder = (*di_buffer) % blk_per_grp;
+ bg_idx = *di_buffer / blk_per_grp;
+ if (fs-blksz == 1024) {
+ remainder = *di_buffer % blk_per_grp;
if (!remainder)
bg_idx--;
}
@@ -213,10 +209,8 @@ static void delete_double_indirect_block(struct ext2_inode
*inode)
/* removing the parent double indirect block */
blknr = inode-b.blocks.double_indir_block;
- if (fs-blksz != 1024) {
- bg_idx = blknr / blk_per_grp;
- } else {
- bg_idx = blknr / blk_per_grp;
+ bg_idx = blknr / blk_per_grp;
+ if (fs-blksz == 1024) {
remainder = blknr % blk_per_grp;
if (!remainder)
bg_idx--;
@@ -293,12 +287,9 @@ static void delete_triple_indirect_block(struct ext2_inode
*inode)
for (j = 0; j fs-blksz / sizeof(int); j++) {
if (*tip_buffer == 0)
break;
- if (fs-blksz != 1024) {
- bg_idx = (*tip_buffer) / blk_per_grp;
- } else {
- bg_idx = (*tip_buffer) / blk_per_grp;
-
- remainder = (*tip_buffer) % blk_per_grp;
+ bg_idx = *tip_buffer / blk_per_grp;
+ if (fs-blksz == 1024) {
+ remainder = *tip_buffer % blk_per_grp;
if (!remainder)
bg_idx--;
}
@@ -336,12 +327,9 @@ static void delete_triple_indirect_block(struct ext2_inode
*inode)
* removing the grand parent blocks
* which is connected to inode
*/
- if (fs-blksz != 1024) {
- bg_idx = (*tigp_buffer) / blk_per_grp;
- } else {
- bg_idx = (*tigp_buffer) / blk_per_grp;
-
- remainder = (*tigp_buffer) % blk_per_grp;
+ bg_idx = *tigp_buffer / blk_per_grp;
+ if (fs-blksz == 1024) {
+
[U-Boot] [PATCH v2 0/2] fs:ext4: Fixes and code cleanup
This code fixes problem with storing file with the same name multiple times on the same ext4 fs (with different sizes). Code reorganization and cleanup is also included. Lukasz Majewski (2): fs:ext4:cleanup: Remove superfluous code fs:ext4:write:fix: Reinitialize global variables after updating a file fs/ext4/ext4_common.c | 41 --- fs/ext4/ext4_write.c | 57 + include/ext4fs.h |1 + 3 files changed, 49 insertions(+), 50 deletions(-) -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Exynos5: config: Enable FIT
Dear Akshay Saraswat, On 28/04/14 22:57, Akshay Saraswat wrote: Adding two configs: * CONFIG_FIT - Enable FIT image support. * CONFIG_FIT_BEST_MATCH - Enable fetching correct DTB from FIT image by comparing compatibles. Change in V2: - Added Acked-by. change log should be move under --- line. Signed-off-by: Akshay Saraswat aksha...@samsung.com Acked-by: Simon Glass s...@chromium.org --- include/configs/exynos5-dt.h | 4 1 file changed, 4 insertions(+) diff --git a/include/configs/exynos5-dt.h b/include/configs/exynos5-dt.h index 414db42..dee53e9 100644 --- a/include/configs/exynos5-dt.h +++ b/include/configs/exynos5-dt.h @@ -288,4 +288,8 @@ #define CONFIG_CMD_BOOTZ +/* Enable FIT support and comparison */ +#define CONFIG_FIT +#define CONFIG_FIT_BEST_MATCH Is it exynos5 common feature? I think it's a board specific feature. + #endif /* __CONFIG_H */ Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/12] MX6: add boot device support for SPL
Hi Tim, On 06/05/2014 08:36, Tapani Utriainen wrote: Tim, Stefano, that piece of code indeed originates from Freescale's 2009.08 u-boot. (Edward has changed jobs, so the CC:d address is of no use.) I supposed this. Tim, please add Freescale's Copyright, too. Thanks, 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] mx6sabred: Add PFUZE100 PMIC support
Hi Fabio, On 05/05/2014 18:08, Fabio Estevam wrote: On Mon, May 5, 2014 at 12:56 PM, Fabio Estevam feste...@gmail.com wrote: On Mon, May 5, 2014 at 12:32 PM, Tim Harvey thar...@gateworks.com wrote: Hi Fabio, Yes, I think Stefano is correct in that power_init_board() is the right place to put pmic init. He asked me to do that to my recent series as well and it worked fine. Note that in that series I do have a patch that will rename pmic_init() for the PFUZE100 to power_pfuze100_init() [1]. I'm hoping that will make it in soon. Thanks, Tim. Stefano, It seems that I need to wait for Tim's series to be applied, otherwise there will be a build breakage. In the meantime I converted the current patch to using power_init_board() instead, but this causes problems: = pmic list PMIC devices: name: PFUZE100_PMIC bus: I2C_1 = pmic PFUZE100_PMIC dump PMIC: PFUZE100_PMIC wait_for_sr_state: failed sr=81 cr=a0 state=2020 i2c_init_transfer: failed for chip 0x8 retry=0 wait_for_sr_state: failed sr=81 cr=a0 state=2020 i2c_init_transfer: failed for chip 0x8 retry=1 wait_for_sr_state: failed sr=81 cr=a0 state=2020 i2c_init_transfer: failed for chip 0x8 retry=2 i2c_init_transfer: give up i2c_regs=021a PMIC: Registers dump failed With the previous misc_init_r() approach the 'dump' command worked correctly. Any suggestions? Checkin in arch/arm/lib/board.c, I see that power_init_board() is called quite early (that makes sense, as power can be necessary to go on). Can you try moving power_init_board() later ? Anyway, I2C is already set (by board_init, called previously) and malloc is also available. Regards, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mkimage : Split out and clean pbl_crc32 for use by other image types
Hi Charles,
On 06/05/2014 00:46, Charles Manning wrote:
The crc32 used by pblimgae is NOT the same as zlib crc32.
The pbl_crc32 is useful for other purposes in mkimage so split it out.
While we are about it, clean up redundant and confusing code.
Signed-off-by: Charles Manning cdhmann...@gmail.com
---
tools/Makefile|1 +
tools/pbl_crc32.c | 56
+
tools/pbl_crc32.h | 13 +
tools/pblimage.c | 47 +---
4 files changed, 71 insertions(+), 46 deletions(-)
create mode 100644 tools/pbl_crc32.c
create mode 100644 tools/pbl_crc32.h
diff --git a/tools/Makefile b/tools/Makefile
index c34df4f..2f30749 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -86,6 +86,7 @@ dumpimage-mkimage-objs := aisimage.o \
omapimage.o \
os_support.o \
pblimage.o \
+ pbl_crc32.o \
sha1.o \
sha256.o \
ublimage.o \
diff --git a/tools/pbl_crc32.c b/tools/pbl_crc32.c
new file mode 100644
index 000..6e6735a
--- /dev/null
+++ b/tools/pbl_crc32.c
@@ -0,0 +1,56 @@
+/*
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ *
+ * Cleaned up and refactored by Charles Manning.
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+#include pblimage.h
+
+static uint32_t crc_table[256];
+static int crc_table_valid;
+
+static void make_crc_table(void)
+{
+ uint32_t mask;
+ int i, j;
+ uint32_t poly; /* polynomial exclusive-or pattern */
+
+ if (crc_table_valid)
+ return;
+
+ /*
+ * the polynomial used by PBL is 1 + x1 + x2 + x4 + x5 + x7 + x8 + x10
+ * + x11 + x12 + x16 + x22 + x23 + x26 + x32.
+ */
+ poly = 0x04c11db7;
+
+ for (i = 0; i 256; i++) {
+ mask = i 24;
+ for (j = 0; j 8; j++) {
+ if (mask 0x8000)
+ mask = (mask 1) ^ poly;
+ else
+ mask = 1;
+ }
+ crc_table[i] = mask;
+ }
+
+ crc_table_valid = 1;
+}
+
+uint32_t pbl_crc32(uint32_t in_crc, const char *buf, uint32_t len)
+{
+ uint32_t crc32_val;
+ int i;
+
+ make_crc_table();
+
+ crc32_val = ~in_crc;
+
+ for (i = 0; i len; i++)
+ crc32_val = (crc32_val 8) ^
+ crc_table[(crc32_val 24) ^ (*buf++ 0xff)];
+
+ return crc32_val;
+}
diff --git a/tools/pbl_crc32.h b/tools/pbl_crc32.h
new file mode 100644
index 000..4ab55ee
--- /dev/null
+++ b/tools/pbl_crc32.h
@@ -0,0 +1,13 @@
+/*
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef PBLCRC32_H
+#define PBLCRC32_H
+
+#include stdint.h
+uint32_t pbl_crc32(uint32_t in_crc, const char *buf, uint32_t len);
+
+#endif
diff --git a/tools/pblimage.c b/tools/pblimage.c
index ef3d7f6..6e6e801 100644
--- a/tools/pblimage.c
+++ b/tools/pblimage.c
@@ -6,6 +6,7 @@
#include imagetool.h
#include image.h
#include pblimage.h
+#include pbl_crc32.h
/*
* Initialize to an invalid value.
@@ -137,52 +138,6 @@ static void pbl_parser(char *name)
fclose(fd);
}
-static uint32_t crc_table[256];
-
-static void make_crc_table(void)
-{
- uint32_t mask;
- int i, j;
- uint32_t poly; /* polynomial exclusive-or pattern */
-
- /*
- * the polynomial used by PBL is 1 + x1 + x2 + x4 + x5 + x7 + x8 + x10
- * + x11 + x12 + x16 + x22 + x23 + x26 + x32.
- */
- poly = 0x04c11db7;
-
- for (i = 0; i 256; i++) {
- mask = i 24;
- for (j = 0; j 8; j++) {
- if (mask 0x8000)
- mask = (mask 1) ^ poly;
- else
- mask = 1;
- }
- crc_table[i] = mask;
- }
-}
-
-unsigned long pbl_crc32(unsigned long crc, const char *buf, uint32_t len)
-{
- uint32_t crc32_val = 0x;
- uint32_t xor = 0x0;
- int i;
-
- make_crc_table();
-
- for (i = 0; i len; i++)
- crc32_val = (crc32_val 8) ^
- crc_table[(crc32_val 24) ^ (*buf++ 0xff)];
-
- crc32_val = crc32_val ^ xor;
- if (crc32_val 0) {
- crc32_val += 0x;
- crc32_val += 1;
- }
- return crc32_val;
-}
-
static uint32_t reverse_byte(uint32_t val)
{
uint32_t temp;
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:
Re: [U-Boot] [PATCH 2/2] mkimage: Refactor mxsimage to use common crc32 code
Hi Charles,
On 06/05/2014 00:46, Charles Manning wrote:
mxsimage uses the same crc32 function as pblimage.
Signed-off-by: Charles Manning cdhmann...@gmail.com
---
tools/mxsimage.c | 28 +++-
1 file changed, 3 insertions(+), 25 deletions(-)
diff --git a/tools/mxsimage.c b/tools/mxsimage.c
index 045b35a..0c4348c 100644
--- a/tools/mxsimage.c
+++ b/tools/mxsimage.c
@@ -19,6 +19,7 @@
#include imagetool.h
#include mxsimage.h
+#include pbl_crc32.h
#include image.h
@@ -231,29 +232,6 @@ static int sb_aes_reinit(struct sb_image_ctx *ictx, int
enc)
}
/*
- * CRC32
- */
-static uint32_t crc32(uint8_t *data, uint32_t len)
-{
- const uint32_t poly = 0x04c11db7;
- uint32_t crc32 = 0x;
- unsigned int byte, bit;
-
- for (byte = 0; byte len; byte++) {
- crc32 ^= data[byte] 24;
-
- for (bit = 8; bit 0; bit--) {
- if (crc32 (1UL 31))
- crc32 = (crc32 1) ^ poly;
- else
- crc32 = (crc32 1);
- }
- }
-
- return crc32;
-}
-
-/*
* Debug
*/
static void soprintf(struct sb_image_ctx *ictx, const char *fmt, ...)
@@ -998,7 +976,7 @@ static int sb_build_command_load(struct sb_image_ctx
*ictx,
ccmd-load.address = dest;
ccmd-load.count= cctx-length;
- ccmd-load.crc32= crc32(cctx-data, cctx-length);
+ ccmd-load.crc32= pbl_crc32(0, cctx-data, cctx-length);
cctx-size = sizeof(*ccmd) + cctx-length;
@@ -1834,7 +1812,7 @@ static int sb_verify_command(struct sb_image_ctx *ictx,
EVP_DigestUpdate(ictx-md_ctx, cctx-data, asize);
sb_aes_crypt(ictx, cctx-data, cctx-data, asize);
- if (ccmd-load.crc32 != crc32(cctx-data, asize)) {
+ if (ccmd-load.crc32 != pbl_crc32(0, cctx-data, asize)) {
fprintf(stderr,
ERR: SB LOAD command payload CRC32
invalid!\n);
return -EINVAL;
Good idea to factorize these functions, 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] DA850EVM with USE_NAND config does not pad the AIS file
Tom, Thank you very much for your investigations :-) --On April 26, 2014 13:34 -0400 Tom Taylor ttaylor.ta...@gmail.com wrote: I'm a U-Boot newbie so please feel free to correct how I'm reporting this issue.. I recently downloaded the 2014.04-rc3 snapshot to build U-Boot for my custom DA850-based board. The only change was to add a new target dav850evm_nand in boards.cfg with the added parameter USE_NAND. The resulting AIS file was programmed into EVM-compatible NAND using standard sfh_OMAP-L138 method. The board failed to boot, and stayed in a loop printing the SPL console message repeatedly. After some debugging with CCS 5.5 and an XDS100v2, I found that incorrect code was being loaded into the 0xc108000 RAM destination. The da850evm.h file defines CONFIG_SYS_NAND_U_BOOT_OFFS as 0x28000, which corresponds to an AIS offset of 0x8000 but the u-boot header did not appear there in the AIS file. A search revealed that the Makefile catenated u-boot immediately after the SPL without any padding. Further investigation revealed that the target Makefile needs CONFIG_SPL_MAX_SIZE to be defined as 0x8000 in order for the padding to be performed properly; however, this constant was apparently deleted during a series of changes in April, 2013 to accommodate separate code and BSS size limits for another target. In its place, CONFIG_SPL_MAX_FOOTPRINT was defined as 32768. Unfortunately, the da850evm Makefile does not refer to this constant. To solve the problem, I added the following 2 lines in my custom-modified da850evm.h: # define CONFIG_SPL_PAD_TO0x8000 # define CONFIG_SPL_MAX_SIZE 0x8000 although the first line may not be strictly required. Yes, CONFIG_SPL_PAD_TO is currently not used for the 'make u-boot.ais' target in the Makefile. Instead, the Makefile uses CONFIG_SPL_MAX_SIZE for padding the SPL, which is probably wrong. This solved the problem and allowed the board to boot. Doesn't this mean that other similar targets may be broken? I think yes. I think the right fix would be to change the Makefile to use CONFIG_SPL_PAD_TO instead of CONFIG_SPL_MAX_SIZE for the u-boot.ais target. diff --git a/Makefile b/Makefile index ff38a43..869f442 100644 --- a/Makefile +++ b/Makefile @@ -890,7 +890,7 @@ MKIMAGEFLAGS_u-boot-spl.ais = -s -n $(if $(CONFIG_AIS_CONFIG_FILE), \ spl/u-boot-spl.ais: spl/u-boot-spl.bin FORCE $(call if_changed,mkimage) -OBJCOPYFLAGS_u-boot.ais = -I binary -O binary --pad-to=$(CONFIG_SPL_MAX_SIZE) +OBJCOPYFLAGS_u-boot.ais = -I binary -O binary --pad-to=$(CONFIG_SPL_PAD_TO) u-boot.ais: spl/u-boot-spl.ais u-boot.img FORCE $(call if_changed,pad_cat) And then check all ARM926EJS/Davinci configurations that use SPL: (extending Tom Rini's grep command from his email) $ git grep -l ARM926EJS include/configs/ | xargs grep -l DAVINCI | xargs grep -l _SPL_ include/configs/cam_enc_4xx.h include/configs/da830evm.h include/configs/da850evm.h include/configs/hawkboard.h include/configs/ipam390.h For the cam_enc_4xx CONFIG_SPL_PAD_TO is already defined, so it should work fine after fixing the Makefile. Heiko, any comments on this? Are you actually using the u-boot.ais target? da830evm and hawkboard did not use CONFIG_SPL_MAX_SIZE, so no need to fix them. da850evm: We should add CONFIG_SPL_PAD_TO as already suggested by you. ipam390.h: I think the #define CONFIG_SPL_MAX_SIZE 0x2 should be removed or replaced by #define CONFIG_SPL_PAD_TO 0x2. But actually the board has been added after the commits that replace CONFIG_SPL_MAX_SIZE by CONFIG_SPL_MAX_FOOTPRINT, so why didn't that issue come up when adding the board to mainline? Heiko, any comments? Are you using make u-boot.ais here or something else? Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dwc_ahsata: return failure for MX6 if not IMX6Q
Hi Tim,
On 06/05/2014 07:22, Tim Harvey wrote:
The IMX6QUAD/DUAL have SATA, but the IMX6SOLO/DL do not. Return an error
indicating no such port instead of attempting a memory access that results
in a data abort and reset. This dynamic detection is necessary for bootloaders
that support multiple variants of the IMX6 SoC.
Right !
Signed-off-by: Tim Harvey thar...@gateworks.com
---
drivers/block/dwc_ahsata.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/block/dwc_ahsata.c b/drivers/block/dwc_ahsata.c
index 3569214..638a585 100644
--- a/drivers/block/dwc_ahsata.c
+++ b/drivers/block/dwc_ahsata.c
@@ -17,6 +17,7 @@
#include asm/io.h
#include linux/bitops.h
#include asm/arch/clock.h
+#include asm/arch/sys_proto.h
#include dwc_ahsata.h
struct sata_port_regs {
@@ -558,6 +559,12 @@ int init_sata(int dev)
u32 linkmap;
struct ahci_probe_ent *probe_ent = NULL;
+#if defined(CONFIG_MX6)
+ if (!is_cpu_type(MXC_CPU_MX6Q)) {
+ printf(No device detected!\n);
Change only printf with puts. We use puts() in u-boot when we print a
fixed string.
Really I had drop the whole line. It is not that a SATA device is not
attached or not detected, but it is that a SATA is not possible at all.
It is like this is an error, but it is not: it is the real use case.
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 V2 1/8] ums: support block devices not MMC devices
Hi, On 05/06/2014 08:21 AM, Lukasz Majewski wrote: Hi Marek, On Monday, May 05, 2014 at 06:40:11 PM, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com The USB Mass Storage function could equally well support a SATA device as support an MMC device. Update struct ums to contain a block device descriptor, not an MMC device descriptor. Cc: Lukasz Majewski l.majew...@samsung.com Signed-off-by: Stephen Warren swar...@nvidia.com Acked-by: Przemyslaw Marczak p.marc...@samsung.com Lukasz, I think this series is yours, right ? :) We feel a bit responsible for the gadget code :-). Przemek (If he don't mind :-)) will look into the v2 of the UMS, since Stephen has sent it yesterday, and if nothing breaks I will pull them to u-boot-dfu branch. Best regards, Marek Vasut Patch number 7 can be applied with am -3, beside this Trats2 is working fine. Thanks -- 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 v5 4/5] samsung: misc: menu: increase delay in menu main loop
On 05/05/2014 03:35 PM, Gerhard Sittig wrote: On Wed, 2014-04-30 at 13:28 +0200, Przemyslaw Marczak wrote: Increase menu loop delay to 200 ms helps choose the right menu option by user. Before this, each time key was pressed the current menu option was changed few times. Now it changes only once and also changes few times if key is pressed for a longer time. Since this description better reflects the motivation of the change, and because there appears to be no need to actually de-bounce the keys, I think this patch is good. virtually yours Gerhard Sittig Thanks:) -- 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
[U-Boot] [PATCH 1/2] mtd: nand: am335x_spl_bch.c: Fix problem with NAND_CMD_RNDOUT
From: Marek Belisko marek.beli...@gmail.com
On some NAND devices (e.g. Hynix H27U2G8F2CTR-BI on Siemens DXR2 /
Draco boards) the SPL issues the following bit-flip error messages:
nand: bit-flip corrected @oob=0
...
This patch makes sure that only the required address cycles are sent
to the NAND chip.
The same issue has been reported by Bacem Daassi:
http://e2e.ti.com/support/arm/sitara_arm/f/791/t/259699.aspx
The issue is mainly due to a NAND protocol violation in the omap driver since
the Random Data Output command (05h-E0h) expects to see only the column address
that should be addressed within the already loaded read page into the read
buffer. Only 2 address cycles with ALE active should be provided between the
05h and E0h commands. The Page read command expects the full address footprint
(2bytes for column address + 3bytes for row address), but once the page is
loaded into the read buffer, Random Data Output should be used with only 2bytes
for column address.
Signed-off-by: Marek Belisko marek.beli...@gmail.com
Signed-off-by: Stefan Roese s...@denx.de
Tested-by: Samuel Egli samuel.e...@siemens.com
Cc: Pekon Gupta pe...@ti.com
Cc: Scott Wood scottw...@freescale.com
---
drivers/mtd/nand/am335x_spl_bch.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/am335x_spl_bch.c
b/drivers/mtd/nand/am335x_spl_bch.c
index c84851b..dd76149 100644
--- a/drivers/mtd/nand/am335x_spl_bch.c
+++ b/drivers/mtd/nand/am335x_spl_bch.c
@@ -64,14 +64,18 @@ static int nand_command(int block, int page, uint32_t offs,
NAND_CTRL_ALE | NAND_CTRL_CHANGE); /* A[7:0] */
hwctrl(mtd, (offs 8) 0xff, NAND_CTRL_ALE); /* A[11:9] */
/* Row address */
- hwctrl(mtd, (page_addr 0xff), NAND_CTRL_ALE); /* A[19:12] */
- hwctrl(mtd, ((page_addr 8) 0xff),
+
+ if (cmd != NAND_CMD_RNDOUT) {
+ hwctrl(mtd, (page_addr 0xff), NAND_CTRL_ALE); /* A[19:12] */
+ hwctrl(mtd, ((page_addr 8) 0xff),
NAND_CTRL_ALE); /* A[27:20] */
#ifdef CONFIG_SYS_NAND_5_ADDR_CYCLE
- /* One more address cycle for devices 128MiB */
- hwctrl(mtd, (page_addr 16) 0x0f,
+ /* One more address cycle for devices 128MiB */
+ hwctrl(mtd, (page_addr 16) 0x0f,
NAND_CTRL_ALE); /* A[31:28] */
#endif
+ }
+
hwctrl(mtd, NAND_CMD_NONE, NAND_NCE | NAND_CTRL_CHANGE);
if (cmd == NAND_CMD_READ0) {
--
1.9.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] mtd: nand: nand_base.c: Fix address cycle problem with NAND_CMD_RNDOUT
From: Pekon Gupta pe...@ti.com
On some NAND devices (e.g. Hynix H27U2G8F2CTR-BI on Siemens DXR2 /
Draco boards) the SPL issues the following bit-flip error messages:
nand: bit-flip corrected @oob=0
...
This patch makes sure that only the required address cycles are sent
to the NAND chip.
The same issue has been reported by Bacem Daassi:
http://e2e.ti.com/support/arm/sitara_arm/f/791/t/259699.aspx
The issue is mainly due to a NAND protocol violation in the omap driver since
the Random Data Output command (05h-E0h) expects to see only the column address
that should be addressed within the already loaded read page into the read
buffer. Only 2 address cycles with ALE active should be provided between the
05h and E0h commands. The Page read command expects the full address footprint
(2bytes for column address + 3bytes for row address), but once the page is
loaded into the read buffer, Random Data Output should be used with only 2bytes
for column address.
Signed-off-by: Pekon Gupta pe...@ti.com
Signed-off-by: Stefan Roese s...@denx.de
Tested-by: Samuel Egli samuel.e...@siemens.com
Cc: Marek Belisko marek.beli...@gmail.com
Cc: Scott Wood scottw...@freescale.com
---
drivers/mtd/nand/nand_base.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 1ce55fd..f11fce4 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -674,7 +674,7 @@ static void nand_command_lp(struct mtd_info *mtd, unsigned
int command,
ctrl = ~NAND_CTRL_CHANGE;
chip-cmd_ctrl(mtd, column 8, ctrl);
}
- if (page_addr != -1) {
+ if (page_addr != -1 command != NAND_CMD_RNDOUT) {
chip-cmd_ctrl(mtd, page_addr, ctrl);
chip-cmd_ctrl(mtd, page_addr 8,
NAND_NCE | NAND_ALE);
--
1.9.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 5/5] samsung: misc: remove download mode info screen
Hello Minkyu,
On 05/05/2014 03:27 PM, Minkyu Kang wrote:
Dear Przemyslaw Marczak,
On 30 April 2014 20:28, Przemyslaw Marczak p.marc...@samsung.com
mailto:p.marc...@samsung.com wrote:
This change removes LCD menu download mode info screen.
Now key press timeout is checked in function download_menu()
and menu options are displayed directly after PWR + VOLUP keys.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
mailto:p.marc...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com mailto:mk7.k...@samsung.com
---
Changes v4:
- new commit
Changes v5:
- none
---
board/samsung/common/misc.c | 73
+++--
1 file changed, 31 insertions(+), 42 deletions(-)
diff --git a/board/samsung/common/misc.c b/board/samsung/common/misc.c
index 2ea275e..03106fd 100644
--- a/board/samsung/common/misc.c
+++ b/board/samsung/common/misc.c
@@ -261,7 +261,7 @@ static void display_download_menu(int mode)
selection[mode] = [=];
lcd_clear();
- lcd_printf(\n\t\tDownload Mode Menu\n);
+ lcd_printf(\n\n\t\tDownload Mode Menu\n\n);
for (i = 0; i = BOOT_MODE_EXIT; i++)
lcd_printf(\t%s %s - %s\n\n, selection[i],
@@ -274,10 +274,38 @@ static void download_menu(void)
int mode = 0;
int last_mode = 0;
int run;
- int key;
+ int key = 0;
+ int timeout = 15; /* sec */
+ int i;
display_download_menu(mode);
+ lcd_puts(\n);
+
+ /* Start count if no key is pressed */
+ while (check_keys())
+ continue;
+
+ while (timeout--) {
+ lcd_printf(\r\tNormal boot will start in: %2.d
seconds.,
+ timeout);
+
+ /* about 1000 ms in for loop */
+ for (i = 0; i 10; i++) {
+ mdelay(100);
+ key = check_keys();
+ if (key)
+ break;
+ }
+ if (key)
maybe, unnecessary if statement.
Please take a notice that there are two loops: while and for,
so the second if (key) is necessary for break a while loop on user
event.
+ break;
+ }
+
+ if (!key) {
+ lcd_clear();
+ return;
+ }
+
while (1) {
run = 0;
@@ -315,45 +343,6 @@ static void download_menu(void)
lcd_clear();
}
-static void display_mode_info(void)
-{
- lcd_position_cursor(4, 4);
- lcd_printf(%s\n, U_BOOT_VERSION);
- lcd_puts(\nDownload Mode Menu\n);
-#ifdef CONFIG_SYS_BOARD
- lcd_printf(Board name: %s\n, CONFIG_SYS_BOARD);
-#endif
- lcd_printf(Press POWER KEY to display MENU options.);
-}
-
-static int boot_menu(void)
-{
- int key = 0;
- int timeout = 10;
-
- display_mode_info();
-
- while (timeout--) {
- lcd_printf(\rNormal boot will start in: %d
seconds., timeout);
- mdelay(1000);
-
- key = key_pressed(KEY_POWER);
- if (key)
- break;
- }
-
- lcd_clear();
-
- /* If PWR pressed - show download menu */
- if (key) {
- printf(Power pressed - go to download menu\n);
- download_menu();
- printf(Download mode exit.\n);
- }
-
- return 0;
-}
-
void check_boot_mode(void)
{
int pwr_key;
@@ -366,7 +355,7 @@ void check_boot_mode(void)
power_key_pressed(KEY_PWR_INTERRUPT_REG);
if (key_pressed(KEY_VOLUMEUP))
- boot_menu();
+ download_menu();
else if (key_pressed(KEY_VOLUMEDOWN))
mode_leave_menu(BOOT_MODE_THOR);
}
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de mailto:U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Thanks,
Minkyu Kang.
--
from. prom.
www.promsoft.net http://www.promsoft.net
Thank you
--
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 1/2] mtd: nand: am335x_spl_bch.c: Fix problem with NAND_CMD_RNDOUT
From: Stefan Roese [mailto:s...@denx.de]
From: Marek Belisko marek.beli...@gmail.com
On some NAND devices (e.g. Hynix H27U2G8F2CTR-BI on Siemens DXR2 /
Draco boards) the SPL issues the following bit-flip error messages:
nand: bit-flip corrected @oob=0
...
This patch makes sure that only the required address cycles are sent
to the NAND chip.
The same issue has been reported by Bacem Daassi:
http://e2e.ti.com/support/arm/sitara_arm/f/791/t/259699.aspx
The issue is mainly due to a NAND protocol violation in the omap driver since
the Random Data Output command (05h-E0h) expects to see only the column address
that should be addressed within the already loaded read page into the read
buffer. Only 2 address cycles with ALE active should be provided between the
05h and E0h commands. The Page read command expects the full address footprint
(2bytes for column address + 3bytes for row address), but once the page is
loaded into the read buffer, Random Data Output should be used with only 2bytes
for column address.
Signed-off-by: Marek Belisko marek.beli...@gmail.com
Signed-off-by: Stefan Roese s...@denx.de
Tested-by: Samuel Egli samuel.e...@siemens.com
Cc: Pekon Gupta pe...@ti.com
Cc: Scott Wood scottw...@freescale.com
---
Thanks Stefan,
I was just about to re-send same patch with Marek's authorship.
But as this is change in common code, can you please add below reference
to datasheets from other NAND device vendors, in you commit message.
NAND_CMD_RNDOUT (05h-E0h) needs only two cycles of column address to access
data
from different column within the same page. So expected sequence on NAND
data-bus is
05h column-addr-byte1 column-address-byte2 E0h
References in datasheets of parts from different NAND vendors
+++-
|Vendor | Datasheet/Part#| Reference
+++-
|Spansion| S34ML{01|02|04}G2 | Figure 6.12 Random Data Output In a Page
|Micron | MT29F{16|32|64|128}G08A| Figure 47: CHANGE READ COLUMN (05h-E0h)
Operation
|Macronix| MX30LF1G08AA | Figure 10. AC Waveforms for Random Data
Output
|Toshiba | TC58NVG1S3ETAI0| Figure Column Address Change in Read Cycle
Timing Diagram (2/2)
+++-
Though most NAND Devices mentioned above tend to work even if extra cycles of
page-address is issued between 05h E0h command. But Spansion devices
break on this non-compliance.
This patch fixes chip-cmdfunc() for all devices, as datasheet of all mentioned
vendor expect same sequence.
Also, same change is required in drivers/mtd/nand/nand_spl_simple.c
So, you can as well just put both in same patch.
with regards, Pekon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] mtd: nand: Fix address cycle problem with NAND_CMD_RNDOUT
From: Marek Belisko marek.beli...@gmail.com
From: Marek Belisko marek.beli...@gmail.com
On some NAND devices (e.g. Hynix H27U2G8F2CTR-BI on Siemens DXR2 /
Draco boards) the NAND subsystem (SPL U-Boot drivers) issues the following
bit-flip error messages:
nand: bit-flip corrected @oob=0
...
NAND_CMD_RNDOUT (05h-E0h) needs only two cycles of column address to access data
from different column within the same page. So expected sequence on NAND
data-bus is
05h column-addr-byte1 column-address-byte2 E0h
References in datasheets of parts from different NAND vendors
+++-
|Vendor | Datasheet/Part#| Reference
+++-
|Spansion| S34ML{01|02|04}G2 | Figure 6.12 Random Data Output In a Page
|Micron | MT29F{16|32|64|128}G08A| Figure 47: CHANGE READ COLUMN (05h-E0h)
Operation
|Macronix| MX30LF1G08AA | Figure 10. AC Waveforms for Random Data
Output
|Toshiba | TC58NVG1S3ETAI0| Figure Column Address Change in Read Cycle
Timing
||| Diagram (2/2)
+++-
Though most NAND Devices mentioned above tend to work even if extra cycles of
page-address is issued between 05h E0h command. But Spansion devices
break on this non-compliance.
This patch fixes chip-cmdfunc() for all devices, as datasheet of all mentioned
vendor expect same sequence.
The same issue has been reported by Bacem Daassi:
http://e2e.ti.com/support/arm/sitara_arm/f/791/t/259699.aspx
The issue is mainly due to a NAND protocol violation in the omap driver since
the Random Data Output command (05h-E0h) expects to see only the column address
that should be addressed within the already loaded read page into the read
buffer. Only 2 address cycles with ALE active should be provided between the
05h and E0h commands. The Page read command expects the full address footprint
(2bytes for column address + 3bytes for row address), but once the page is
loaded into the read buffer, Random Data Output should be used with only 2bytes
for column address.
Signed-off-by: Marek Belisko marek.beli...@gmail.com
Signed-off-by: Stefan Roese s...@denx.de
Tested-by: Samuel Egli samuel.e...@siemens.com
Cc: Pekon Gupta pe...@ti.com
Cc: Scott Wood scottw...@freescale.com
---
v2:
- Marek as author
- Added additional comment / datasheet reference to the commit
text from Pekon (thanks)
- Added fix to nand_spl_simple.c
- Squashed all three drivers fixes into one patch
drivers/mtd/nand/am335x_spl_bch.c | 12
drivers/mtd/nand/nand_base.c | 2 +-
drivers/mtd/nand/nand_spl_simple.c | 12
3 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/mtd/nand/am335x_spl_bch.c
b/drivers/mtd/nand/am335x_spl_bch.c
index c84851b..9b547ce 100644
--- a/drivers/mtd/nand/am335x_spl_bch.c
+++ b/drivers/mtd/nand/am335x_spl_bch.c
@@ -63,15 +63,19 @@ static int nand_command(int block, int page, uint32_t offs,
hwctrl(mtd, offs 0xff,
NAND_CTRL_ALE | NAND_CTRL_CHANGE); /* A[7:0] */
hwctrl(mtd, (offs 8) 0xff, NAND_CTRL_ALE); /* A[11:9] */
+
/* Row address */
- hwctrl(mtd, (page_addr 0xff), NAND_CTRL_ALE); /* A[19:12] */
- hwctrl(mtd, ((page_addr 8) 0xff),
+ if (cmd != NAND_CMD_RNDOUT) {
+ hwctrl(mtd, (page_addr 0xff), NAND_CTRL_ALE); /* A[19:12] */
+ hwctrl(mtd, ((page_addr 8) 0xff),
NAND_CTRL_ALE); /* A[27:20] */
#ifdef CONFIG_SYS_NAND_5_ADDR_CYCLE
- /* One more address cycle for devices 128MiB */
- hwctrl(mtd, (page_addr 16) 0x0f,
+ /* One more address cycle for devices 128MiB */
+ hwctrl(mtd, (page_addr 16) 0x0f,
NAND_CTRL_ALE); /* A[31:28] */
#endif
+ }
+
hwctrl(mtd, NAND_CMD_NONE, NAND_NCE | NAND_CTRL_CHANGE);
if (cmd == NAND_CMD_READ0) {
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 1ce55fd..f11fce4 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -674,7 +674,7 @@ static void nand_command_lp(struct mtd_info *mtd, unsigned
int command,
ctrl = ~NAND_CTRL_CHANGE;
chip-cmd_ctrl(mtd, column 8, ctrl);
}
- if (page_addr != -1) {
+ if (page_addr != -1 command != NAND_CMD_RNDOUT) {
chip-cmd_ctrl(mtd, page_addr, ctrl);
chip-cmd_ctrl(mtd, page_addr 8,
NAND_NCE | NAND_ALE);
diff --git a/drivers/mtd/nand/nand_spl_simple.c
b/drivers/mtd/nand/nand_spl_simple.c
index cead4b5..f45aa21 100644
--- a/drivers/mtd/nand/nand_spl_simple.c
+++ b/drivers/mtd/nand/nand_spl_simple.c
@@ -88,15 +88,19 @@ static int
[U-Boot] Loading uImage into RAM
I'm trying to understand how u-boot loads zImage into RAM. mkimage is called as mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008040 -d arch/arm/boot/zImage /bootImage/uImage Here, 'a' stands for load address and 'e' stands for entry point (64 bytes are used for wrapping?). However, when loading uImage from u-boot, boot operation starts at address 0x8010. Furthermore, u-boot recognizes the load address and entry point as 0x80008000. Loading from NAND 128MiB 3,3V 8-bit, offset 0x1c Image Name: Linux-2.6.27.8 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1735148 Bytes = 1.7 MB Load Address: 80008000 Entry Point: 80008000 ## Booting kernel from Legacy Image at 8010 ... Image Name: Linux-2.6.27.8 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1735148 Bytes = 1.7 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Could you help me with this? abdullah ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/8] ums: support block devices not MMC devices
Hi Stephen, From: Stephen Warren swar...@nvidia.com The USB Mass Storage function could equally well support a SATA device as support an MMC device. Update struct ums to contain a block device descriptor, not an MMC device descriptor. Cc: Lukasz Majewski l.majew...@samsung.com Signed-off-by: Stephen Warren swar...@nvidia.com Acked-by: Przemyslaw Marczak p.marc...@samsung.com --- v2: (The series) rebased onto latest u-boot-usb/master to pick up Mateusz's DFU changes. Applied to u-boot-dfu branch. Thanks Stephen for your effort. -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mtd: nand: Fix address cycle problem with NAND_CMD_RNDOUT
+ Bacem Daasi bacem.daa...@spansion.com
who was first to identify and root-cause the issue. So giving some credit to
him..
From: Stefan Roese [mailto:s...@denx.de]
From: Marek Belisko marek.beli...@gmail.com
On some NAND devices (e.g. Hynix H27U2G8F2CTR-BI on Siemens DXR2 /
Draco boards) the NAND subsystem (SPL U-Boot drivers) issues the following
bit-flip error messages:
nand: bit-flip corrected @oob=0
...
NAND_CMD_RNDOUT (05h-E0h) needs only two cycles of column address to access
data
from different column within the same page. So expected sequence on NAND
data-bus is
05h column-addr-byte1 column-address-byte2 E0h
References in datasheets of parts from different NAND vendors
+++-
|Vendor | Datasheet/Part#| Reference
+++-
|Spansion| S34ML{01|02|04}G2 | Figure 6.12 Random Data Output In a Page
|Micron | MT29F{16|32|64|128}G08A| Figure 47: CHANGE READ COLUMN (05h-E0h)
Operation
|Macronix| MX30LF1G08AA | Figure 10. AC Waveforms for Random Data
Output
|Toshiba | TC58NVG1S3ETAI0| Figure Column Address Change in Read Cycle
Timing
||| Diagram (2/2)
+++-
Though most NAND Devices mentioned above tend to work even if extra cycles of
page-address is issued between 05h E0h command. But Spansion devices
break on this non-compliance.
This patch fixes chip-cmdfunc() for all devices, as datasheet of all mentioned
vendor expect same sequence.
The same issue has been reported by Bacem Daassi:
http://e2e.ti.com/support/arm/sitara_arm/f/791/t/259699.aspx
The issue is mainly due to a NAND protocol violation in the omap driver since
the Random Data Output command (05h-E0h) expects to see only the column address
that should be addressed within the already loaded read page into the read
buffer. Only 2 address cycles with ALE active should be provided between the
05h and E0h commands. The Page read command expects the full address footprint
(2bytes for column address + 3bytes for row address), but once the page is
loaded into the read buffer, Random Data Output should be used with only 2bytes
for column address.
Signed-off-by: Marek Belisko marek.beli...@gmail.com
Signed-off-by: Stefan Roese s...@denx.de
Tested-by: Samuel Egli samuel.e...@siemens.com
Cc: Pekon Gupta pe...@ti.com
Cc: Scott Wood scottw...@freescale.com
---
v2:
- Marek as author
- Added additional comment / datasheet reference to the commit
text from Pekon (thanks)
- Added fix to nand_spl_simple.c
- Squashed all three drivers fixes into one patch
drivers/mtd/nand/am335x_spl_bch.c | 12
drivers/mtd/nand/nand_base.c | 2 +-
drivers/mtd/nand/nand_spl_simple.c | 12
3 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/mtd/nand/am335x_spl_bch.c
b/drivers/mtd/nand/am335x_spl_bch.c
index c84851b..9b547ce 100644
--- a/drivers/mtd/nand/am335x_spl_bch.c
+++ b/drivers/mtd/nand/am335x_spl_bch.c
@@ -63,15 +63,19 @@ static int nand_command(int block, int page, uint32_t offs,
hwctrl(mtd, offs 0xff,
NAND_CTRL_ALE | NAND_CTRL_CHANGE); /* A[7:0] */
hwctrl(mtd, (offs 8) 0xff, NAND_CTRL_ALE); /* A[11:9] */
+
/* Row address */
- hwctrl(mtd, (page_addr 0xff), NAND_CTRL_ALE); /* A[19:12] */
- hwctrl(mtd, ((page_addr 8) 0xff),
+ if (cmd != NAND_CMD_RNDOUT) {
+ hwctrl(mtd, (page_addr 0xff), NAND_CTRL_ALE); /* A[19:12] */
+ hwctrl(mtd, ((page_addr 8) 0xff),
NAND_CTRL_ALE); /* A[27:20] */
#ifdef CONFIG_SYS_NAND_5_ADDR_CYCLE
- /* One more address cycle for devices 128MiB */
- hwctrl(mtd, (page_addr 16) 0x0f,
+ /* One more address cycle for devices 128MiB */
+ hwctrl(mtd, (page_addr 16) 0x0f,
NAND_CTRL_ALE); /* A[31:28] */
#endif
+ }
+
hwctrl(mtd, NAND_CMD_NONE, NAND_NCE | NAND_CTRL_CHANGE);
if (cmd == NAND_CMD_READ0) {
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 1ce55fd..f11fce4 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -674,7 +674,7 @@ static void nand_command_lp(struct mtd_info *mtd, unsigned
int command,
ctrl = ~NAND_CTRL_CHANGE;
chip-cmd_ctrl(mtd, column 8, ctrl);
}
- if (page_addr != -1) {
+ if (page_addr != -1 command != NAND_CMD_RNDOUT) {
chip-cmd_ctrl(mtd, page_addr, ctrl);
chip-cmd_ctrl(mtd, page_addr 8,
NAND_NCE | NAND_ALE);
diff --git a/drivers/mtd/nand/nand_spl_simple.c
b/drivers/mtd/nand/nand_spl_simple.c
index cead4b5..f45aa21 100644
---
[U-Boot] Pull request: u-boot-dfu
Hi Marek,
The following changes since commit
af41d6b4cb1602abebaaa9c8774a9b0ece564796:
common: fixed linker-list example (2014-05-05 10:24:13 +0200)
are available in the git repository at:
ssh://gu-...@git.denx.de/u-boot-dfu master
for you to fetch changes up to c805776ce7079c7b7dd54c644b499e1b8f6296b1:
ums: allow the user to specify the device type (2014-05-06 11:13:23
+0200)
Stephen Warren (9):
usb: ums: add error handling for failed registration
ums: support block devices not MMC devices
ums: remove UMS_{NUM,START}_SECTORS + UMS_START_SECTOR
ums: remove error-checking of MMC device size
ums: remove ums_disk_init()
ums: move IO support code to common location
ums: use get_device() not find_mmc_device();
ums: move all variable declarations to the start of the block
ums: allow the user to specify the device type
board/samsung/common/Makefile |1 -
board/samsung/common/ums.c| 74
--
common/cmd_usb_mass_storage.c | 91
+++
include/usb_mass_storage.h| 13 ++---
4 files changed, 81 insertions(+), 98 deletions(-)
delete mode 100644 board/samsung/common/ums.c
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Loading uImage into RAM
Hi Abdullah, On Tue, May 6, 2014 at 10:55 AM, Abdullah YILDIZ abdullah.ma...@gmail.com wrote: I'm trying to understand how u-boot loads zImage into RAM. mkimage is called as mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008040 -d arch/arm/boot/zImage /bootImage/uImage Here, 'a' stands for load address and 'e' stands for entry point (64 bytes are used for wrapping?). However, when loading uImage from u-boot, boot operation starts at address 0x8010. Furthermore, u-boot recognizes the load address and entry point as 0x80008000. Kernel uImage is loaded from NAND to ram at address which $loadaddr points to (check print $loadaddr) or env command which loading kerenl image from NAND. Then by bootm command is copied to address which is specified in mkimage (e.g. 0x80008000). Hope this helps. Loading from NAND 128MiB 3,3V 8-bit, offset 0x1c Image Name: Linux-2.6.27.8 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1735148 Bytes = 1.7 MB Load Address: 80008000 Entry Point: 80008000 ## Booting kernel from Legacy Image at 8010 ... Image Name: Linux-2.6.27.8 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1735148 Bytes = 1.7 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Could you help me with this? abdullah ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Loading uImage into RAM
Hi Belisko, On Tue, May 6, 2014 at 12:34 PM, Belisko Marek marek.beli...@gmail.com wrote: Hi Abdullah, On Tue, May 6, 2014 at 10:55 AM, Abdullah YILDIZ abdullah.ma...@gmail.com wrote: I'm trying to understand how u-boot loads zImage into RAM. mkimage is called as mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008040 -d arch/arm/boot/zImage /bootImage/uImage Why is entry point different from load address of uImage? Here, 'a' stands for load address and 'e' stands for entry point (64 bytes are used for wrapping?). However, when loading uImage from u-boot, boot operation starts at address 0x8010. Furthermore, u-boot recognizes the load address and entry point as 0x80008000. Kernel uImage is loaded from NAND to ram at address which $loadaddr points to (check print $loadaddr) or env command which loading kerenl image from NAND. Then by bootm command is copied to address which is specified in mkimage (e.g. 0x80008000). Hope this helps. Kind regards. abdullah ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Loading uImage into RAM
Hi Abdullah, On Tue, May 6, 2014 at 11:54 AM, Abdullah YILDIZ abdullah.ma...@gmail.com wrote: Hi Belisko, On Tue, May 6, 2014 at 12:34 PM, Belisko Marek marek.beli...@gmail.com wrote: Hi Abdullah, On Tue, May 6, 2014 at 10:55 AM, Abdullah YILDIZ abdullah.ma...@gmail.com wrote: I'm trying to understand how u-boot loads zImage into RAM. mkimage is called as mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008040 -d arch/arm/boot/zImage /bootImage/uImage Why is entry point different from load address of uImage? It is set to skip 64bytes (0x40) of mkimage header. Here, 'a' stands for load address and 'e' stands for entry point (64 bytes are used for wrapping?). However, when loading uImage from u-boot, boot operation starts at address 0x8010. Furthermore, u-boot recognizes the load address and entry point as 0x80008000. Kernel uImage is loaded from NAND to ram at address which $loadaddr points to (check print $loadaddr) or env command which loading kerenl image from NAND. Then by bootm command is copied to address which is specified in mkimage (e.g. 0x80008000). Hope this helps. Kind regards. abdullah BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] DA850EVM with USE_NAND config does not pad the AIS file
Tom, Thank you very much for your investigations :-) --On April 26, 2014 13:34 -0400 Tom Taylor ttaylor.ta...@gmail.com wrote: I'm a U-Boot newbie so please feel free to correct how I'm reporting this issue.. I recently downloaded the 2014.04-rc3 snapshot to build U-Boot for my custom DA850-based board. The only change was to add a new target dav850evm_nand in boards.cfg with the added parameter USE_NAND. The resulting AIS file was programmed into EVM-compatible NAND using standard sfh_OMAP-L138 method. The board failed to boot, and stayed in a loop printing the SPL console message repeatedly. After some debugging with CCS 5.5 and an XDS100v2, I found that incorrect code was being loaded into the 0xc108000 RAM destination. The da850evm.h file defines CONFIG_SYS_NAND_U_BOOT_OFFS as 0x28000, which corresponds to an AIS offset of 0x8000 but the u-boot header did not appear there in the AIS file. A search revealed that the Makefile catenated u-boot immediately after the SPL without any padding. Further investigation revealed that the target Makefile needs CONFIG_SPL_MAX_SIZE to be defined as 0x8000 in order for the padding to be performed properly; however, this constant was apparently deleted during a series of changes in April, 2013 to accommodate separate code and BSS size limits for another target. In its place, CONFIG_SPL_MAX_FOOTPRINT was defined as 32768. Unfortunately, the da850evm Makefile does not refer to this constant. To solve the problem, I added the following 2 lines in my custom-modified da850evm.h: # define CONFIG_SPL_PAD_TO0x8000 # define CONFIG_SPL_MAX_SIZE 0x8000 although the first line may not be strictly required. Yes, CONFIG_SPL_PAD_TO is currently not used for the 'make u-boot.ais' target in the Makefile. Instead, the Makefile uses CONFIG_SPL_MAX_SIZE for padding the SPL, which is probably wrong. This solved the problem and allowed the board to boot. Doesn't this mean that other similar targets may be broken? I think yes. I think the right fix would be to change the Makefile to use CONFIG_SPL_PAD_TO instead of CONFIG_SPL_MAX_SIZE for the u-boot.ais target. diff --git a/Makefile b/Makefile index ff38a43..869f442 100644 --- a/Makefile +++ b/Makefile @@ -890,7 +890,7 @@ MKIMAGEFLAGS_u-boot-spl.ais = -s -n $(if $(CONFIG_AIS_CONFIG_FILE), \ spl/u-boot-spl.ais: spl/u-boot-spl.bin FORCE $(call if_changed,mkimage) -OBJCOPYFLAGS_u-boot.ais = -I binary -O binary --pad-to=$(CONFIG_SPL_MAX_SIZE) +OBJCOPYFLAGS_u-boot.ais = -I binary -O binary --pad-to=$(CONFIG_SPL_PAD_TO) u-boot.ais: spl/u-boot-spl.ais u-boot.img FORCE $(call if_changed,pad_cat) And then check all ARM926EJS/Davinci configurations that use SPL: (extending Tom Rini's grep command from his email) $ git grep -l ARM926EJS include/configs/ | xargs grep -l DAVINCI | xargs grep -l _SPL_ include/configs/cam_enc_4xx.h include/configs/da830evm.h include/configs/da850evm.h include/configs/hawkboard.h include/configs/ipam390.h For the cam_enc_4xx CONFIG_SPL_PAD_TO is already defined, so it should work fine after fixing the Makefile. Heiko, any comments on this? Are you actually using the u-boot.ais target? da830evm and hawkboard did not use CONFIG_SPL_MAX_SIZE, so no need to fix them. da850evm: We should add CONFIG_SPL_PAD_TO as already suggested by you. ipam390.h: I think the #define CONFIG_SPL_MAX_SIZE 0x2 should be removed or replaced by #define CONFIG_SPL_PAD_TO 0x2. But actually the board has been added after the commits that replace CONFIG_SPL_MAX_SIZE by CONFIG_SPL_MAX_FOOTPRINT, so why didn't that issue come up when adding the board to mainline? Heiko, any comments? Are you using make u-boot.ais here or something else? Christian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sf: params: Added support for Spansion S25FL512S_512K
Hi Jagan,
On 04/25/2014 03:47 PM, Michal Simek wrote:
From: Siva Durga Prasad Paladugu siva.durga.palad...@xilinx.com
Added support for Spansion chip S25FL512S_512K.
Signed-off-by: Siva Durga Prasad Paladugu siva...@xilinx.com
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
drivers/mtd/spi/sf_params.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
index eb372b7..ac886fd 100644
--- a/drivers/mtd/spi/sf_params.c
+++ b/drivers/mtd/spi/sf_params.c
@@ -60,6 +60,7 @@ const struct spi_flash_params spi_flash_params_table[] = {
{S25FL256S_64K, 0x010219, 0x4d01,64 * 1024, 512, RD_FULL,
WR_QPP},
{S25FL512S_256K, 0x010220, 0x4d00, 256 * 1024, 256, RD_FULL,
WR_QPP},
{S25FL512S_64K, 0x010220, 0x4d01,64 * 1024, 1024, RD_FULL,
WR_QPP},
+ {S25FL512S_512K, 0x010220, 0x4f00, 256 * 1024, 256, RD_FULL,
WR_QPP},
#endif
#ifdef CONFIG_SPI_FLASH_STMICRO /* STMICRO */
{M25P10, 0x202011, 0x0, 32 * 1024, 4, 0,
0},
--
1.8.2.3
can you please add this patch to your spi custodian repo?
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
[U-Boot] [GIT PULL] Network zynq gem changes
Hi Ben and Tom, please pull these two patches to network tree or to mainline tree. Both changes are easy one. Thanks, Michal The following changes since commit 52fded7b94d98c73a824e4a9d90596a33a1cbb8a: Merge branch 'next' of git://git.denx.de/u-boot-sh (2014-05-02 11:48:07 -0400) are available in the git repository at: git://www.denx.de/git/u-boot-microblaze.git net for you to fetch changes up to 2fd2489b7aa36478433ae2a1f4de9f66e0a80322: net: zynq: Fix sparse warnings in gem (2014-05-06 13:41:55 +0200) Michal Simek (2): net: zynq: Use predefined macros instead of hardcoded value net: zynq: Fix sparse warnings in gem drivers/net/zynq_gem.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- 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
[U-Boot] [GIT PULL] Microblaze changes
Hi Tom, please pull this one microblaze patch which I have in my queue. Thanks, Michal The following changes since commit 52fded7b94d98c73a824e4a9d90596a33a1cbb8a: Merge branch 'next' of git://git.denx.de/u-boot-sh (2014-05-02 11:48:07 -0400) are available in the git repository at: git://www.denx.de/git/u-boot-microblaze.git master for you to fetch changes up to d1d37b5cab119096bb60c686eff7ea39cfebed25: microblaze: Wire up OF support for emaclite (2014-05-06 13:32:30 +0200) Stephan Linz (1): microblaze: Wire up OF support for emaclite include/configs/microblaze-generic.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i2c: zynq: Fixed compilation errors when using DEBUG
Hello Michael, Am 06.05.2014 13:39, schrieb Michal Simek: Hi Heiko, On 04/25/2014 03:46 PM, Michal Simek wrote: From: Jesper B. Christensenjesper.christen...@cobham.com Signed-off-by: Jesper B. Christensenjesper.christen...@cobham.com Signed-off-by: Michal Simekmichal.si...@xilinx.com --- drivers/i2c/zynq_i2c.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/i2c/zynq_i2c.c b/drivers/i2c/zynq_i2c.c index f1f6513..b3264af 100644 --- a/drivers/i2c/zynq_i2c.c +++ b/drivers/i2c/zynq_i2c.c @@ -142,7 +142,7 @@ static u32 zynq_i2c_wait(struct zynq_i2c_registers *zynq_i2c, u32 mask) break; } #ifdef DEBUG - zynq_i2c_debug_status(zynq_i2c)); + zynq_i2c_debug_status(zynq_i2c); #endif /* Clear interrupt status flags */ writel(int_status mask,zynq_i2c-interrupt_status); @@ -235,7 +235,7 @@ static int zynq_i2c_read(struct i2c_adapter *adap, u8 dev, uint addr, clrbits_le32(zynq_i2c-control, ZYNQ_I2C_CONTROL_HOLD); #ifdef DEBUG - zynq_i2c_debug_status(); + zynq_i2c_debug_status(zynq_i2c); #endif return 0; } -- 1.8.2.3 Can you please add this patch to your i2c custodian repo? Added it to my ToDo list in patchwork bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i2c: zynq: Fixed compilation errors when using DEBUG
Hi Heiko, On 04/25/2014 03:46 PM, Michal Simek wrote: From: Jesper B. Christensen jesper.christen...@cobham.com Signed-off-by: Jesper B. Christensen jesper.christen...@cobham.com Signed-off-by: Michal Simek michal.si...@xilinx.com --- drivers/i2c/zynq_i2c.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/i2c/zynq_i2c.c b/drivers/i2c/zynq_i2c.c index f1f6513..b3264af 100644 --- a/drivers/i2c/zynq_i2c.c +++ b/drivers/i2c/zynq_i2c.c @@ -142,7 +142,7 @@ static u32 zynq_i2c_wait(struct zynq_i2c_registers *zynq_i2c, u32 mask) break; } #ifdef DEBUG - zynq_i2c_debug_status(zynq_i2c)); + zynq_i2c_debug_status(zynq_i2c); #endif /* Clear interrupt status flags */ writel(int_status mask, zynq_i2c-interrupt_status); @@ -235,7 +235,7 @@ static int zynq_i2c_read(struct i2c_adapter *adap, u8 dev, uint addr, clrbits_le32(zynq_i2c-control, ZYNQ_I2C_CONTROL_HOLD); #ifdef DEBUG - zynq_i2c_debug_status(); + zynq_i2c_debug_status(zynq_i2c); #endif return 0; } -- 1.8.2.3 Can you please add this patch to your i2c custodian repo? 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
[U-Boot] [GIT PULL] Serial changes for zynq.
Hi Tom, [cc: Albert] please pull these two serial patches to your tree. If this should go through Albert's tree please let me know. Thanks, Michal The following changes since commit 52fded7b94d98c73a824e4a9d90596a33a1cbb8a: Merge branch 'next' of git://git.denx.de/u-boot-sh (2014-05-02 11:48:07 -0400) are available in the git repository at: git://www.denx.de/git/u-boot-microblaze.git serial for you to fetch changes up to 870e0bda43c9ea18a5f2fae5e48905c3b44ea18b: serial: zynq: Fix typo in suffix function name (2014-05-06 13:47:42 +0200) Michal Simek (2): serial: zynq: Remove sparse warnings serial: zynq: Fix typo in suffix function name drivers/serial/serial.c | 4 ++-- drivers/serial/serial_zynq.c | 18 +- 2 files changed, 11 insertions(+), 11 deletions(-) -- 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] [PATCH] env_eeprom: Assign default environment during board_init_f
Hi Tom,
On 04/25/2014 03:49 PM, Michal Simek wrote:
From: Siva Durga Prasad Paladugu siva.durga.palad...@xilinx.com
Assign default environment and set env valid during board_init_f
before relocation as the actual environment will be read from
eeprom later.
Signed-off-by: Siva Durga Prasad Paladugu siva...@xilinx.com
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
common/env_eeprom.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/common/env_eeprom.c b/common/env_eeprom.c
index 0db2bb6..a4020bc 100644
--- a/common/env_eeprom.c
+++ b/common/env_eeprom.c
@@ -224,6 +224,7 @@ int env_init(void)
#else
int env_init(void)
{
+#ifdef ENV_IS_EMBEDDED
ulong crc, len, new;
unsigned off;
uchar buf[64];
@@ -256,6 +257,10 @@ int env_init(void)
gd-env_addr= 0;
gd-env_valid = 0;
}
+#else
+ gd-env_addr = (ulong)default_environment[0];
+ gd-env_valid = 1;
+#endif
return 0;
}
--
1.8.2.3
Any comment on 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] [PATCH] fat: Define MAX_CLUSTSIZE only if not defined in config
Hi Tom, On 04/25/2014 03:48 PM, Michal Simek wrote: From: Siva Durga Prasad Paladugu siva.durga.palad...@xilinx.com Define MAX_CLUSTSIZE only if not defined in board specific config file as this size can be decreased to save memory in some memory constrained cases. Signed-off-by: Siva Durga Prasad Paladugu siva...@xilinx.com Signed-off-by: Michal Simek michal.si...@xilinx.com --- include/fat.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/fat.h b/include/fat.h index c8eb7cc..1213060 100644 --- a/include/fat.h +++ b/include/fat.h @@ -18,7 +18,9 @@ #define VFAT_MAXSEQ 9 /* Up to 9 of 13 2-byte UTF-16 entries */ #define PREFETCH_BLOCKS 2 +#ifndef MAX_CLUSTSIZE #define MAX_CLUSTSIZE65536 +#endif #define DIRENTSPERBLOCK (mydata-sect_size / sizeof(dir_entry)) #define DIRENTSPERCLUST ((mydata-clust_size * mydata-sect_size) / \ sizeof(dir_entry)) -- 1.8.2.3 Any problem with this patch? 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
[U-Boot] [GIT PULL] fpga changes
Hi Tom, [cc: Albert] please pull these fpga changes to your tree. On Friday I have sent the next set of fpga changes which we have in our tree but I want to give more time to review them. And also I have based Xilinx ARM Zynq changes based on these patches that's why I would like to add these patches to your tree and then talk to Albert regarding zynq changes. Thanks, Michal The following changes since commit 52fded7b94d98c73a824e4a9d90596a33a1cbb8a: Merge branch 'next' of git://git.denx.de/u-boot-sh (2014-05-02 11:48:07 -0400) are available in the git repository at: git://www.denx.de/git/u-boot-microblaze.git fpga for you to fetch changes up to eeaf3aa5d3ac84015e0999ec437198682d1a776d: fpga: zynq: Use helper function zynq_validate_bitstream (2014-05-06 14:22:16 +0200) Michal Simek (7): fpga: spartan2: Avoid CamelCase fpga: spartan3: Avoid CamelCase fpga: virtex2: Avoid CamelCase fpga: xilinx: Avoid CamelCase for in Xilinx_desc fpga: xilinx: Fix the rest of CamelCases fpga: xilinx: Simplify load/dump/info function handling fpga: zynq: Remove sparse warnings Siva Durga Prasad Paladugu (2): fpga: zynq: Use helper functions for zynq dma fpga: zynq: Use helper function zynq_validate_bitstream board/armadeus/apf27/fpga.c | 6 +-- board/astro/mcf5373l/fpga.c | 6 +-- board/balloon3/balloon3.c| 4 +- board/esd/pmc440/fpga.c | 8 +-- board/gen860t/fpga.c | 6 +-- board/matrix_vision/mvsmr/fpga.c | 6 +-- board/spear/x600/fpga.c | 4 +- board/teejet/mt_ventoux/mt_ventoux.c | 4 +- board/xilinx/zynq/board.c| 14 +++--- drivers/fpga/spartan2.c | 46 + drivers/fpga/spartan3.c | 46 + drivers/fpga/virtex2.c | 40 --- drivers/fpga/xilinx.c| 179 +++--- drivers/fpga/zynqpl.c| 234 -- include/spartan2.h | 72 +-- include/spartan3.h | 84 +++ include/virtex2.h| 66 include/xilinx.h | 65 +--- include/zynqpl.h | 16 +++--- 19 files changed, 416 insertions(+), 490 deletions(-) -- 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] [PATCH] kbuild: Fix trailing whitespaces
Hi Tom, On 04/24/2014 03:24 PM, Michal Simek wrote: Trivial fix. Signed-off-by: Michal Simek michal.si...@xilinx.com --- Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 0191869..3e324f9 100644 --- a/Makefile +++ b/Makefile @@ -285,7 +285,7 @@ export KBUILD_CHECKSRC KBUILD_SRC KBUILD_EXTMOD # cmd_cc_o_c = $(CC) $(c_flags) -c -o $@ $ # # If $(quiet) is empty, the whole command will be printed. -# If it is set to quiet_, only the short version will be printed. +# If it is set to quiet_, only the short version will be printed. # If it is set to silent_, nothing will be printed at all, since # the variable $(silent_cmd_cc_o_c) doesn't exist. # @@ -966,7 +966,7 @@ ifeq ($(CONFIG_KALLSYMS),y) $(call cmd,u-boot__) common/system_map.o endif -# The actual objects are generated when descending, +# The actual objects are generated when descending, # make sure no implicit rule kicks in $(sort $(u-boot-init) $(u-boot-main)): $(u-boot-dirs) ; @@ -1405,7 +1405,7 @@ endif $(build)=$(build-dir) $(@:.ko=.o) $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost -# FIXME Should go into a make.lib or something +# FIXME Should go into a make.lib or something # === quiet_cmd_rmdirs = $(if $(wildcard $(rm-dirs)),CLEAN $(wildcard $(rm-dirs))) -- 1.8.2.3 Can you please apply this trivial patch to your tree? 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] [PATCH] mx6sabred: Add PFUZE100 PMIC support
On Tue, May 6, 2014 at 5:07 AM, Stefano Babic sba...@denx.de wrote: Checkin in arch/arm/lib/board.c, I see that power_init_board() is called quite early (that makes sense, as power can be necessary to go on). Can you try moving power_init_board() later ? Anyway, I2C is already set (by board_init, called previously) and malloc is also available. I tried putting power_init_board() after misc_init_r() and even in this case the 'pmic dump' command fails. On the v3 version I call the pmic initialization inside board_late_init(). Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] xil_printf in ps7_init.c for u-boot-spl (zynq)
Hi, On 05/03/2014 11:01 AM, Heshsham Abdul Basit wrote: Hi, To build u-boot-spl I had to put ps7_init.c and ps7_init.h in /board/xilinx/zynq. Then when I compile I get boot.bin in the TOPDIR. The functions defined in ps7_init.* are called in spl.c. For debug purpose I wanted put some xil-printf statements in my ps7_init files. But it does not work, says ; undefined reference to xil_printf I included xil-printf.h in the ps7_init.c file, now it is unable to locate this file. I can find this file somewhere else and copy paset here, but I think then it would complain about other missing files and parameters. So how do I use printf statements in ps7_init.c file correctly. such as this: // Get the PS_VERSION on run time unsigned long si_ver = ps7GetSiliconVersion (); xil_printf (\n ps7 Silicon Version : %d.0, si_ver); If xil_printf is not valid here, then is there any other method to display messages such as prointing si_ver wrt above snippet? You should use just printf or puts which are standard u-boot method how to print something on console. I have never debug that but you have to ensure that you can use console at that time. I would say that MIO setting for console has to be done. Or you have second option which I haven't tried which is to use DCC port where I believe you don't need to setup any MIO pin. 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] Loading uImage into RAM
Dear Belisko Marek, In message CAAfyv34gspt4whV-sa=mo0fFunZfX8FA6+=e7jrdpz59hyg...@mail.gmail.com you wrote: Hi Abdullah, On Tue, May 6, 2014 at 11:54 AM, Abdullah YILDIZ abdullah.ma...@gmail.com wrote: Hi Belisko, On Tue, May 6, 2014 at 12:34 PM, Belisko Marek marek.beli...@gmail.com wrote: Hi Abdullah, On Tue, May 6, 2014 at 10:55 AM, Abdullah YILDIZ abdullah.ma...@gmail.com wrote: I'm trying to understand how u-boot loads zImage into RAM. mkimage is called as mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008040 -d arch/arm/boot/zImage /bootImage/uImage Why is entry point different from load address of uImage? It is set to skip 64bytes (0x40) of mkimage header. Actually the configuration given here looks bogus. The 64 byte header of the legacy image format does NOT get copied to the address range starting at load address, so you actually start execution at a 64 byte offset within your binary. This is likely incorrect. A common error is to misunderstand that the loadaddr variable used in U-Boot as target address for the image download has _nothing_ to do with the loadaddr parameter of the mkimage command , which gives the address where the bootm command will copy the image to (eventually uncompressing it). Unfortunately ARM never adapted to use this. 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 Die Scheu vor Verantwortung ist die Krankheit unserer Zeit. -- Otto von Bismarck ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] Exynos5: config: Enable FIT
Adding two configs: * CONFIG_FIT - Enable FIT image support. * CONFIG_FIT_BEST_MATCH - Enable fetching correct DTB from FIT image by comparing compatibles. Signed-off-by: Akshay Saraswat aksha...@samsung.com Acked-by: Simon Glass s...@chromium.org --- Changes in V3: - Repositioned change-log. - Made config addition board specific instead of SoC specific. Changes in V2: - Added Acked-by. include/configs/smdk5250.h | 4 include/configs/smdk5420.h | 4 include/configs/snow.h | 4 3 files changed, 12 insertions(+) diff --git a/include/configs/smdk5250.h b/include/configs/smdk5250.h index 183aae7..66fa179 100644 --- a/include/configs/smdk5250.h +++ b/include/configs/smdk5250.h @@ -14,4 +14,8 @@ #undef CONFIG_DEFAULT_DEVICE_TREE #define CONFIG_DEFAULT_DEVICE_TREE exynos5250-smdk5250 +/* Enable FIT support and comparison */ +#define CONFIG_FIT +#define CONFIG_FIT_BEST_MATCH + #endif /* __CONFIG_SMDK_H */ diff --git a/include/configs/smdk5420.h b/include/configs/smdk5420.h index b96eea8..58f706a 100644 --- a/include/configs/smdk5420.h +++ b/include/configs/smdk5420.h @@ -51,4 +51,8 @@ #define CONFIG_MAX_I2C_NUM 11 +/* Enable FIT support and comparison */ +#define CONFIG_FIT +#define CONFIG_FIT_BEST_MATCH + #endif /* __CONFIG_5420_H */ diff --git a/include/configs/snow.h b/include/configs/snow.h index ed5c0b6..673fa14 100644 --- a/include/configs/snow.h +++ b/include/configs/snow.h @@ -14,4 +14,8 @@ #undef CONFIG_DEFAULT_DEVICE_TREE #define CONFIG_DEFAULT_DEVICE_TREE exynos5250-snow +/* Enable FIT support and comparison */ +#define CONFIG_FIT +#define CONFIG_FIT_BEST_MATCH + #endif /* __CONFIG_SNOW_H */ -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v12 2/2] S5P: Exynos: Config: Enable GPIO CMD config
Enabling configs for GPIO CMD, EXYNOS4 family and replacing exynos_gpio_get with new linear GPIO pin number required because of the new function asking only 2 arguments (pin and value) instead of 3 (bank, pin and value). Signed-off-by: Akshay Saraswat aksha...@samsung.com Acked-by: Przemyslaw Marczak p.marc...@samsung.com --- Changes in v12: - Added change log in this patch. - Added Acked-by: Przemyslaw Marczak. Changes in v10: - Replaced exynos_gpio_get calls with corresponding pin number. Changes in V8: - Changed Subject to reflect affected SoCs/boards. Changes in V6: - Isolated config changes in a new patch. include/configs/exynos5-dt.h| 2 ++ include/configs/s5p_goni.h | 4 ++-- include/configs/s5pc210_universal.h | 16 include/configs/smdkv310.h | 1 + include/configs/trats.h | 8 include/configs/trats2.h| 4 ++-- 6 files changed, 19 insertions(+), 16 deletions(-) diff --git a/include/configs/exynos5-dt.h b/include/configs/exynos5-dt.h index 414db42..5a9b1b4 100644 --- a/include/configs/exynos5-dt.h +++ b/include/configs/exynos5-dt.h @@ -288,4 +288,6 @@ #define CONFIG_CMD_BOOTZ +#define CONFIG_CMD_GPIO + #endif /* __CONFIG_H */ diff --git a/include/configs/s5p_goni.h b/include/configs/s5p_goni.h index 991c43e..799d4fe 100644 --- a/include/configs/s5p_goni.h +++ b/include/configs/s5p_goni.h @@ -214,8 +214,8 @@ /* * I2C Settings */ -#define CONFIG_SOFT_I2C_GPIO_SCL s5pc110_gpio_get(j4, 3) -#define CONFIG_SOFT_I2C_GPIO_SDA s5pc110_gpio_get(j4, 0) +#define CONFIG_SOFT_I2C_GPIO_SCL S5PC110_GPIO_J43 +#define CONFIG_SOFT_I2C_GPIO_SDA S5PC110_GPIO_J40 #define CONFIG_SYS_I2C #define CONFIG_SYS_I2C_SOFT/* I2C bit-banged */ diff --git a/include/configs/s5pc210_universal.h b/include/configs/s5pc210_universal.h index 2da8871..b368266 100644 --- a/include/configs/s5pc210_universal.h +++ b/include/configs/s5pc210_universal.h @@ -170,8 +170,8 @@ /* * I2C Settings */ -#define CONFIG_SOFT_I2C_GPIO_SCL exynos4_gpio_get(1, b, 7) -#define CONFIG_SOFT_I2C_GPIO_SDA exynos4_gpio_get(1, b, 6) +#define CONFIG_SOFT_I2C_GPIO_SCL EXYNOS4_GPIO_B7 +#define CONFIG_SOFT_I2C_GPIO_SDA EXYNOS4_GPIO_B6 #define CONFIG_CMD_I2C @@ -196,10 +196,10 @@ */ #define CONFIG_SOFT_SPI #define CONFIG_SOFT_SPI_MODE SPI_MODE_3 -#define CONFIG_SOFT_SPI_GPIO_SCLK exynos4_gpio_get(2, y3, 1) -#define CONFIG_SOFT_SPI_GPIO_MOSI exynos4_gpio_get(2, y3, 3) -#define CONFIG_SOFT_SPI_GPIO_MISO exynos4_gpio_get(2, y3, 0) -#define CONFIG_SOFT_SPI_GPIO_CS exynos4_gpio_get(2, y4, 3) +#define CONFIG_SOFT_SPI_GPIO_SCLK EXYNOS4_GPIO_Y31 +#define CONFIG_SOFT_SPI_GPIO_MOSI EXYNOS4_GPIO_Y33 +#define CONFIG_SOFT_SPI_GPIO_MISO EXYNOS4_GPIO_Y30 +#define CONFIG_SOFT_SPI_GPIO_CS EXYNOS4_GPIO_Y43 #define SPI_DELAY udelay(1) #undef SPI_INIT @@ -231,8 +231,8 @@ int universal_spi_read(void); #define KEY_PWR_INTERRUPT_REG MAX8998_REG_IRQ1 #define KEY_PWR_INTERRUPT_MASK (1 7) -#define KEY_VOL_UP_GPIOexynos4_gpio_get(2, x2, 0) -#define KEY_VOL_DOWN_GPIO exynos4_gpio_get(2, x2, 1) +#define KEY_VOL_UP_GPIOEXYNOS4_GPIO_X20 +#define KEY_VOL_DOWN_GPIO EXYNOS4_GPIO_X21 #endif /* __ASSEMBLY__ */ /* LCD console */ diff --git a/include/configs/smdkv310.h b/include/configs/smdkv310.h index 1388f49..34adfaf 100644 --- a/include/configs/smdkv310.h +++ b/include/configs/smdkv310.h @@ -12,6 +12,7 @@ /* High Level Configuration Options */ #define CONFIG_SAMSUNG 1 /* in a SAMSUNG core */ #define CONFIG_S5P 1 /* S5P Family */ +#define CONFIG_EXYNOS4 /* EXYNOS4 Family */ #define CONFIG_EXYNOS4210 1 /* which is a EXYNOS4210 SoC */ #define CONFIG_SMDKV3101 /* working with SMDKV310*/ diff --git a/include/configs/trats.h b/include/configs/trats.h index 5d8bd60..6cade07 100644 --- a/include/configs/trats.h +++ b/include/configs/trats.h @@ -207,8 +207,8 @@ #define CONFIG_SYS_I2C_INIT_BOARD /* I2C FG */ -#define CONFIG_SOFT_I2C_GPIO_SCL exynos4_gpio_get(2, y4, 1) -#define CONFIG_SOFT_I2C_GPIO_SDA exynos4_gpio_get(2, y4, 0) +#define CONFIG_SOFT_I2C_GPIO_SCL EXYNOS4_GPIO_Y41 +#define CONFIG_SOFT_I2C_GPIO_SDA EXYNOS4_GPIO_Y40 /* POWER */ #define CONFIG_POWER @@ -245,8 +245,8 @@ #define KEY_PWR_INTERRUPT_REG MAX8997_REG_INT1 #define KEY_PWR_INTERRUPT_MASK (1 0) -#define KEY_VOL_UP_GPIOexynos4_gpio_get(2, x2, 0) -#define KEY_VOL_DOWN_GPIO exynos4_gpio_get(2, x2, 1) +#define KEY_VOL_UP_GPIOEXYNOS4_GPIO_X20 +#define KEY_VOL_DOWN_GPIO EXYNOS4_GPIO_X21 #endif /* __ASSEMBLY__ */ /* LCD console */ diff --git a/include/configs/trats2.h b/include/configs/trats2.h index 53d449c..856c03b 100644 --- a/include/configs/trats2.h
[U-Boot] [PATCH v12 0/2] S5P: Exynos: Add GPIO numbering feature
Used a script to recheck/verify pin mapping and existing mapping appears to be fine, returning correct bank and pin values. Did ./MAKEALL -a arm and found all Exynos/S5P related boards compiled successfully. Couldn't test booting over all of them. Tested U-Boot bootup over SMDK5420, SMDK5250, Snow. Requesting maintaners to please test over affected SoCs/boards. Changes in V2: - Enabled CMD_GPIO as suggested by Simon Glass and supported same for EXYNOS5. Changes in V3: - New patch added to rename S5P GPIO definitions to S5P_GPIO. - GPIO Table added to calculate the base address of input gpio bank. Changes in V4: - To have consistent 0..n-1 GPIO numbering the banks are divided into different parts where ever they have holes in them. - Function and table to support gpio command moved to s5p-gpio driver. - Rebased on latest u-boot-samsung tree. Changes in V5: - Rebased on latest u-boot-samsung tree. - Removed Exynos5 specific code in gpio driver api to get bank. - Added #define HAVE_GENERIC_GPIO in config file to remove conditinal CPU check in gpio driver. Changes in V6: - Isolated config changes in a new patch. - Updated patches with corresponding changes for Exynos 5420. Changes in V7: - Added changes for other SoCs like Exynos 4412, 4210 etc. Changes in V8: - Changed Subject of patch 2/2 to reflect affected SoCs/boards. - Fixed arndale board compile time errors introduced due to patch-set v7. Changes in V9: - Fixed checkpatch errors. - Fixed naming error in exynos_gpio_data arrays which could be the possible reason behind data abort witnessed over Exynos4 boards. Changes in v10: - Made arch-exynos/gpio.h - arch/gpio.h. - Removed dead code. - Replaced exynos_gpio_get calls with corresponding pin number. - Edited pin numbmers in dts files. Changes in v11: - Created and fixed pinmux_config for Exynos 4412. - Removed dead code. Changes in v12: - Added change logs in individual patches. - Fixed few bugs and typos. - Added Acked-by: Przemyslaw Marczak. Akshay Saraswat (2): S5P: Exynos: Add GPIO pin numbering and rename definitions S5P: Exynos: Config: Enable GPIO CMD config arch/arm/cpu/armv7/exynos/pinmux.c | 561 + arch/arm/dts/exynos4210-origen.dts |4 +- arch/arm/dts/exynos4210-trats.dts |6 +- arch/arm/dts/exynos4210-universal_c210.dts |4 +- arch/arm/dts/exynos4412-trats2.dts |4 +- arch/arm/include/asm/arch-exynos/cpu.h | 17 +- arch/arm/include/asm/arch-exynos/gpio.h| 1761 +++- arch/arm/include/asm/arch-s5pc1xx/gpio.h | 948 --- board/samsung/arndale/arndale.c| 11 +- board/samsung/goni/goni.c | 32 +- board/samsung/smdk5250/exynos5-dt.c| 20 +- board/samsung/smdk5250/smdk5250.c | 19 +- board/samsung/smdk5420/smdk5420.c | 15 +- board/samsung/smdkc100/smdkc100.c |5 +- board/samsung/smdkv310/smdkv310.c | 19 +- board/samsung/trats/trats.c| 39 +- board/samsung/trats2/trats2.c | 74 +- board/samsung/universal_c210/universal.c | 51 +- drivers/gpio/s5p_gpio.c| 204 +++- include/configs/exynos5-dt.h |2 + include/configs/s5p_goni.h |4 +- include/configs/s5pc210_universal.h| 16 +- include/configs/smdkv310.h |1 + include/configs/trats.h|8 +- include/configs/trats2.h |4 +- 25 files changed, 2918 insertions(+), 911 deletions(-) -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] DA850EVM with USE_NAND config does not pad the AIS file
Hello Christian, Am 06.05.2014 13:30, schrieb Christian Riesch: Tom, Thank you very much for your investigations :-) --On April 26, 2014 13:34 -0400 Tom Taylor ttaylor.ta...@gmail.com wrote: I'm a U-Boot newbie so please feel free to correct how I'm reporting this issue.. I recently downloaded the 2014.04-rc3 snapshot to build U-Boot for my custom DA850-based board. The only change was to add a new target dav850evm_nand in boards.cfg with the added parameter USE_NAND. The resulting AIS file was programmed into EVM-compatible NAND using standard sfh_OMAP-L138 method. The board failed to boot, and stayed in a loop printing the SPL console message repeatedly. After some debugging with CCS 5.5 and an XDS100v2, I found that incorrect code was being loaded into the 0xc108000 RAM destination. The da850evm.h file defines CONFIG_SYS_NAND_U_BOOT_OFFS as 0x28000, which corresponds to an AIS offset of 0x8000 but the u-boot header did not appear there in the AIS file. A search revealed that the Makefile catenated u-boot immediately after the SPL without any padding. Further investigation revealed that the target Makefile needs CONFIG_SPL_MAX_SIZE to be defined as 0x8000 in order for the padding to be performed properly; however, this constant was apparently deleted during a series of changes in April, 2013 to accommodate separate code and BSS size limits for another target. In its place, CONFIG_SPL_MAX_FOOTPRINT was defined as 32768. Unfortunately, the da850evm Makefile does not refer to this constant. To solve the problem, I added the following 2 lines in my custom-modified da850evm.h: # define CONFIG_SPL_PAD_TO 0x8000 # define CONFIG_SPL_MAX_SIZE 0x8000 although the first line may not be strictly required. Yes, CONFIG_SPL_PAD_TO is currently not used for the 'make u-boot.ais' target in the Makefile. Instead, the Makefile uses CONFIG_SPL_MAX_SIZE for padding the SPL, which is probably wrong. Yes, CONFIG_SPL_PAD_TO is the correct define. On the other hand the question is is CONFIG_SPL_PAD_TO not always equal to CONFIG_SPL_MAX_SIZE ? This solved the problem and allowed the board to boot. Doesn't this mean that other similar targets may be broken? I think yes. I think the right fix would be to change the Makefile to use CONFIG_SPL_PAD_TO instead of CONFIG_SPL_MAX_SIZE for the u-boot.ais target. diff --git a/Makefile b/Makefile index ff38a43..869f442 100644 --- a/Makefile +++ b/Makefile @@ -890,7 +890,7 @@ MKIMAGEFLAGS_u-boot-spl.ais = -s -n $(if $(CONFIG_AIS_CONFIG_FILE), \ spl/u-boot-spl.ais: spl/u-boot-spl.bin FORCE $(call if_changed,mkimage) -OBJCOPYFLAGS_u-boot.ais = -I binary -O binary --pad-to=$(CONFIG_SPL_MAX_SIZE) +OBJCOPYFLAGS_u-boot.ais = -I binary -O binary --pad-to=$(CONFIG_SPL_PAD_TO) u-boot.ais: spl/u-boot-spl.ais u-boot.img FORCE $(call if_changed,pad_cat) And then check all ARM926EJS/Davinci configurations that use SPL: (extending Tom Rini's grep command from his email) $ git grep -l ARM926EJS include/configs/ | xargs grep -l DAVINCI | xargs grep -l _SPL_ include/configs/cam_enc_4xx.h include/configs/da830evm.h include/configs/da850evm.h include/configs/hawkboard.h include/configs/ipam390.h For the cam_enc_4xx CONFIG_SPL_PAD_TO is already defined, so it should work fine after fixing the Makefile. Heiko, any comments on this? Are you actually using the u-boot.ais target? I have no board to test, but I think it is used. da830evm and hawkboard did not use CONFIG_SPL_MAX_SIZE, so no need to fix them. da850evm: We should add CONFIG_SPL_PAD_TO as already suggested by you. ipam390.h: I think the #define CONFIG_SPL_MAX_SIZE 0x2 should be removed or replaced by #define CONFIG_SPL_PAD_TO 0x2. But actually the board has been added after the commits that replace grep -lr CONFIG_SPL_MAX_SIZE by CONFIG_SPL_MAX_FOOTPRINT, so why didn't that issue come up when adding the board to mainline? Heiko, any comments? Are you using make u-boot.ais here or something else? I am not sure, if we can just remove CONFIG_SPL_MAX_SIZE for this board, as it maybe has only 0x2 space for the SPL ? maybe: #if !defined(CONFIG_SPL_PAD_TO) define CONFIG_SPL_PAD_TO CONFIG_SPL_MAX_SIZE #endif is better? Heh, thats the case, see: ./include/config_fallbacks.h so, your Makefile patch should be Ok ... bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sf: params: Added support for Spansion S25FL512S_512K
On leave - Will take it on Monday.
On Tue, May 6, 2014 at 5:10 PM, Michal Simek mon...@monstr.eu wrote:
Hi Jagan,
On 04/25/2014 03:47 PM, Michal Simek wrote:
From: Siva Durga Prasad Paladugu siva.durga.palad...@xilinx.com
Added support for Spansion chip S25FL512S_512K.
Signed-off-by: Siva Durga Prasad Paladugu siva...@xilinx.com
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
drivers/mtd/spi/sf_params.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
index eb372b7..ac886fd 100644
--- a/drivers/mtd/spi/sf_params.c
+++ b/drivers/mtd/spi/sf_params.c
@@ -60,6 +60,7 @@ const struct spi_flash_params spi_flash_params_table[] = {
{S25FL256S_64K, 0x010219, 0x4d01,64 * 1024, 512, RD_FULL,
WR_QPP},
{S25FL512S_256K, 0x010220, 0x4d00, 256 * 1024, 256, RD_FULL,
WR_QPP},
{S25FL512S_64K, 0x010220, 0x4d01,64 * 1024, 1024, RD_FULL,
WR_QPP},
+ {S25FL512S_512K, 0x010220, 0x4f00, 256 * 1024, 256, RD_FULL,
WR_QPP},
#endif
#ifdef CONFIG_SPI_FLASH_STMICRO /* STMICRO */
{M25P10, 0x202011, 0x0, 32 * 1024, 4, 0,
0},
--
1.8.2.3
can you please add this patch to your spi custodian repo?
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
--
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/12] MX6: add boot device support for SPL
On Tue, May 6, 2014 at 12:55 AM, Stefano Babic sba...@denx.de wrote: Hi Tim, On 06/05/2014 08:36, Tapani Utriainen wrote: Tim, Stefano, that piece of code indeed originates from Freescale's 2009.08 u-boot. (Edward has changed jobs, so the CC:d address is of no use.) I supposed this. Tim, please add Freescale's Copyright, too. Thanks, Stefano Babic ok - will do. Thanks for the heads-up Tapani. Tim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] DA850EVM with USE_NAND config does not pad the AIS file
Hello Heiko, On 5/6/2014 10:46 AM, Heiko Schocher wrote: Hello Christian, Am 06.05.2014 13:30, schrieb Christian Riesch: Tom, Thank you very much for your investigations :-) --On April 26, 2014 13:34 -0400 Tom Taylor ttaylor.ta...@gmail.com wrote: I'm a U-Boot newbie so please feel free to correct how I'm reporting this issue.. I recently downloaded the 2014.04-rc3 snapshot to build U-Boot for my custom DA850-based board. The only change was to add a new target dav850evm_nand in boards.cfg with the added parameter USE_NAND. The resulting AIS file was programmed into EVM-compatible NAND using standard sfh_OMAP-L138 method. The board failed to boot, and stayed in a loop printing the SPL console message repeatedly. After some debugging with CCS 5.5 and an XDS100v2, I found that incorrect code was being loaded into the 0xc108000 RAM destination. The da850evm.h file defines CONFIG_SYS_NAND_U_BOOT_OFFS as 0x28000, which corresponds to an AIS offset of 0x8000 but the u-boot header did not appear there in the AIS file. A search revealed that the Makefile catenated u-boot immediately after the SPL without any padding. Further investigation revealed that the target Makefile needs CONFIG_SPL_MAX_SIZE to be defined as 0x8000 in order for the padding to be performed properly; however, this constant was apparently deleted during a series of changes in April, 2013 to accommodate separate code and BSS size limits for another target. In its place, CONFIG_SPL_MAX_FOOTPRINT was defined as 32768. Unfortunately, the da850evm Makefile does not refer to this constant. To solve the problem, I added the following 2 lines in my custom-modified da850evm.h: # define CONFIG_SPL_PAD_TO 0x8000 # define CONFIG_SPL_MAX_SIZE 0x8000 although the first line may not be strictly required. Yes, CONFIG_SPL_PAD_TO is currently not used for the 'make u-boot.ais' target in the Makefile. Instead, the Makefile uses CONFIG_SPL_MAX_SIZE for padding the SPL, which is probably wrong. Yes, CONFIG_SPL_PAD_TO is the correct define. On the other hand the question is is CONFIG_SPL_PAD_TO not always equal to CONFIG_SPL_MAX_SIZE ? This solved the problem and allowed the board to boot. Doesn't this mean that other similar targets may be broken? I think yes. I think the right fix would be to change the Makefile to use CONFIG_SPL_PAD_TO instead of CONFIG_SPL_MAX_SIZE for the u-boot.ais target. diff --git a/Makefile b/Makefile index ff38a43..869f442 100644 --- a/Makefile +++ b/Makefile @@ -890,7 +890,7 @@ MKIMAGEFLAGS_u-boot-spl.ais = -s -n $(if $(CONFIG_AIS_CONFIG_FILE), \ spl/u-boot-spl.ais: spl/u-boot-spl.bin FORCE $(call if_changed,mkimage) -OBJCOPYFLAGS_u-boot.ais = -I binary -O binary --pad-to=$(CONFIG_SPL_MAX_SIZE) +OBJCOPYFLAGS_u-boot.ais = -I binary -O binary --pad-to=$(CONFIG_SPL_PAD_TO) u-boot.ais: spl/u-boot-spl.ais u-boot.img FORCE $(call if_changed,pad_cat) And then check all ARM926EJS/Davinci configurations that use SPL: (extending Tom Rini's grep command from his email) $ git grep -l ARM926EJS include/configs/ | xargs grep -l DAVINCI | xargs grep -l _SPL_ include/configs/cam_enc_4xx.h include/configs/da830evm.h include/configs/da850evm.h include/configs/hawkboard.h include/configs/ipam390.h For the cam_enc_4xx CONFIG_SPL_PAD_TO is already defined, so it should work fine after fixing the Makefile. Heiko, any comments on this? Are you actually using the u-boot.ais target? I have no board to test, but I think it is used. da830evm and hawkboard did not use CONFIG_SPL_MAX_SIZE, so no need to fix them. da850evm: We should add CONFIG_SPL_PAD_TO as already suggested by you. ipam390.h: I think the #define CONFIG_SPL_MAX_SIZE 0x2 should be removed or replaced by #define CONFIG_SPL_PAD_TO 0x2. But actually the board has been added after the commits that replace grep -lr CONFIG_SPL_MAX_SIZE by CONFIG_SPL_MAX_FOOTPRINT, so why didn't that issue come up when adding the board to mainline? Heiko, any comments? Are you using make u-boot.ais here or something else? I am not sure, if we can just remove CONFIG_SPL_MAX_SIZE for this board, as it maybe has only 0x2 space for the SPL ? maybe: #if !defined(CONFIG_SPL_PAD_TO) define CONFIG_SPL_PAD_TO CONFIG_SPL_MAX_SIZE #endif is better? Heh, thats the case, see: ./include/config_fallbacks.h so, your Makefile patch should be Ok ... bye, Heiko There's currently only 0x8000 space allocated for the SPL. The first 0x2 byte block is allocated for the NAND-resident environment. From da850evm.h: #ifdef CONFIG_USE_NAND : #define CONFIG_ENV_OFFSET0x0 /* Block 0--not used by bootcode */ #define CONFIG_ENV_SIZE(128 10) Anyone customizing the build has to of course ensure that that the boot offset passed to nand_spl_load_image() is consistent . Again from da850evm.h: #define CONFIG_SYS_NAND_U_BOOT_OFFS0x28000 Because of include/config_fallbacks, it would seem like Christian's suggestion to change the
[U-Boot] [PATCH] ARM: tegra: Venice2 pinmux spreadsheet updates
From: Stephen Warren swar...@nvidia.com
The Venice2 pinmux spreadsheet was updated to fix a few issues. Import
those changes into the U-Boot pinmux initialization tables.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
board/nvidia/venice2/pinmux-config-venice2.h | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/board/nvidia/venice2/pinmux-config-venice2.h
b/board/nvidia/venice2/pinmux-config-venice2.h
index 05f3dab89dcd..bf8e3fd96581 100644
--- a/board/nvidia/venice2/pinmux-config-venice2.h
+++ b/board/nvidia/venice2/pinmux-config-venice2.h
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2013-2014, NVIDIA CORPORATION. All rights reserved.
+ * Copyright (c) 2014, NVIDIA CORPORATION. All rights reserved.
*
* SPDX-License-Identifier: GPL-2.0+
*/
@@ -30,6 +30,7 @@ static const struct tegra_gpio_config venice2_gpio_inits[] = {
GPIO_INIT(I1, IN),
GPIO_INIT(I2, OUT0),
GPIO_INIT(I4, OUT0),
+ GPIO_INIT(I5, OUT1),
GPIO_INIT(I6, IN),
GPIO_INIT(J0, IN),
GPIO_INIT(J7, IN),
@@ -47,7 +48,10 @@ static const struct tegra_gpio_config venice2_gpio_inits[] =
{
GPIO_INIT(O7, IN),
GPIO_INIT(P2, OUT0),
GPIO_INIT(Q0, IN),
+ GPIO_INIT(Q2, IN),
GPIO_INIT(Q3, IN),
+ GPIO_INIT(Q6, IN),
+ GPIO_INIT(Q7, IN),
GPIO_INIT(R0, OUT0),
GPIO_INIT(R1, IN),
GPIO_INIT(R4, IN),
@@ -125,7 +129,7 @@ static const struct pmux_pingrp_config venice2_pingrps[] = {
PINCFG(PI2,DEFAULT, NORMAL, NORMAL, OUTPUT,
DEFAULT, DEFAULT),
PINCFG(PI3,SPI4,NORMAL, NORMAL, OUTPUT,
DEFAULT, DEFAULT),
PINCFG(PI4,DEFAULT, NORMAL, NORMAL, OUTPUT,
DEFAULT, DEFAULT),
- PINCFG(PI5,RSVD2, UP, TRISTATE, OUTPUT,
DEFAULT, DEFAULT),
+ PINCFG(PI5,DEFAULT, NORMAL, NORMAL, OUTPUT,
DEFAULT, DEFAULT),
PINCFG(PI6,DEFAULT, NORMAL, NORMAL, INPUT,
DEFAULT, DEFAULT),
PINCFG(PI7,RSVD1, DOWN, TRISTATE, OUTPUT,
DEFAULT, DEFAULT),
PINCFG(PJ0,DEFAULT, UP, NORMAL, INPUT,
DEFAULT, DEFAULT),
@@ -166,12 +170,12 @@ static const struct pmux_pingrp_config venice2_pingrps[]
= {
PINCFG(DAP4_SCLK_PP7, I2S3,NORMAL, NORMAL, OUTPUT,
DEFAULT, DEFAULT),
PINCFG(KB_COL0_PQ0,DEFAULT, NORMAL, NORMAL, INPUT,
DEFAULT, DEFAULT),
PINCFG(KB_COL1_PQ1,RSVD2, DOWN, TRISTATE, OUTPUT,
DEFAULT, DEFAULT),
- PINCFG(KB_COL2_PQ2,RSVD2, DOWN, TRISTATE, OUTPUT,
DEFAULT, DEFAULT),
+ PINCFG(KB_COL2_PQ2,DEFAULT, UP, NORMAL, INPUT,
DEFAULT, DEFAULT),
PINCFG(KB_COL3_PQ3,DEFAULT, NORMAL, NORMAL, INPUT,
DEFAULT, DEFAULT),
PINCFG(KB_COL4_PQ4,SDMMC3, UP, NORMAL, INPUT,
DEFAULT, DEFAULT),
PINCFG(KB_COL5_PQ5,RSVD2, DOWN, TRISTATE, OUTPUT,
DEFAULT, DEFAULT),
- PINCFG(KB_COL6_PQ6,RSVD2, DOWN, TRISTATE, OUTPUT,
DEFAULT, DEFAULT),
- PINCFG(KB_COL7_PQ7,RSVD2, DOWN, TRISTATE, OUTPUT,
DEFAULT, DEFAULT),
+ PINCFG(KB_COL6_PQ6,DEFAULT, UP, NORMAL, INPUT,
DEFAULT, DEFAULT),
+ PINCFG(KB_COL7_PQ7,DEFAULT, UP, NORMAL, INPUT,
DEFAULT, DEFAULT),
PINCFG(KB_ROW0_PR0,DEFAULT, NORMAL, NORMAL, OUTPUT,
DEFAULT, DEFAULT),
PINCFG(KB_ROW1_PR1,DEFAULT, NORMAL, NORMAL, INPUT,
DEFAULT, DEFAULT),
PINCFG(KB_ROW2_PR2,RSVD2, DOWN, TRISTATE, OUTPUT,
DEFAULT, DEFAULT),
--
1.8.1.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v2 13/13] tegra: Convert tegra GPIO driver to use driver model
On 05/05/2014 05:00 PM, Simon Glass wrote: Hi Stephen, On 5 May 2014 16:07, Stephen Warren swar...@wwwdotorg.org mailto:swar...@wwwdotorg.org wrote: On 05/05/2014 03:30 PM, Simon Glass wrote: ... I think you have it backwards...the current implementation has a single level of hierarchy. Each driver handles one bank (or 'port' in the case of Tegra). What you are talking about is having a single driver handle multiple banks, thus requiring that the driver have a second level to deal with banks, over and above the device. We might end up with that, but I would prefer to move to it when we have evidence that it is a general need. Sigh. This is getting silly. All the APIs in SW need to just take a GPIO ID in the flat range 0..N (N==223 for Tegra20) and deal with it. Anything that expose banks anywhere, either as a parameter to public functions exported from the GPIO controller driver, or as the existence of separate drivers for separate banks, or as a command-line argument that the user sees, or ..., whether it be the U-Boot GPIO core or the Tegra GPIO driver itself that causes this, is just pointless. For exynos, the banks are not contiguous and there is quite a bit of fiddling to make this all work. You may have seen the series going in at the moment to number the GPIOs properly. I understand that Tegra is very straightforward though. Sure, HW that truly is designed as separate banks should be represented as such. However, the existence of such HW shouldn't force *other* HW to artificially expose banks of GPIOs when there's no need/desire to. Eh? We need to support named GPIOs in U-Boot. 155 is a meaningless number which drivers people back and forth to the datasheets, their calculators, a long table, etc. Even the Tegra device tree has moved away from numbers to GPIO names, I notice. The GPIO names are meaningless. I say this because all the Tegra schematics (and documentation that drives them) use the pin/pad name, which is almost always entirely different from the GPIO name. You have to map the pin name back to either the GPIO name or ID using a lookup table (such as the kernel's drivers/pinctrl/pinctrl-tegra20.c). Given the need for a lookup table, we should just use the simpler GPIO ID and not worry about GPIO names. There's no point screwing around with text names when we can just use simple numbers. In DT, GPIOs are specified by integer ID too. Admittedly we have macros that calculate those IDs from the bank/port/offset, but that was probably a mistake, since the bank/port/offset names aren't meaningful. U-Boot provides a friendly named interface for GPIOs. I see that as a requirement for driver model too. As someone who has spent a lot of time at the command line fiddling with hardware, I don't want to go backwards in the driver model conversion. Similarly, using numbers in the DT is very unfriendly and painful IMO. If we can agree on the friendly names, then let's talk about how to simplify things. To be honest, I disagree that meaningless names are friendly. Almost everything else deals with numbers. The values in DT are numbers. The debugfs files in Linux are numbers. The sysfs ABI in Linux is numbers. The current GPIO interface in U-Boot is numbers. The correlation with pinctrl pins is numbers. If the following happens, then I could live with a (part-time) name-based API: * The U-Boot commands accept either a name or a number. That would allow people to use what they want. * The API implemented by U-Boot GPIO drivers uses numbers exclusively. Note that when I say numbers above, all the numbering should be relative to a particular controller. So, I don't mean something like: gpio set 1056 ... where 1056 is 1000 (Tegra GPIO controller base) + 56 (Tegra GPIO ID). Instead, I would expect the command-line interface to be: gpio set tegra 56 gpio set tegra PH0 ... where tegra is the name of the GPIO controller instance, and 56/PH0 is the GPIO ID within that one GPIO controller. The controller name could be pca9555-0 (0th instance of a pca9555 device) or i2c-0-56 (I2C bus 0 device address 0x56) or whatever naming style you want. To support this, I would expect the GPIO driver API to contain just two APIs that know about the GPIO names: int name_to_gpio_id(const char *gpio_name); const char *gpio_id_to_name(int gpio_id); All the other GPIO driver APIs would take int gpio_id (controller-relative integer ID). ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] cm-t54: add cm-t54 board support
On Sun, Apr 27, 2014 at 01:17:28PM +0300, Dmitry Lifshitz wrote:
Add cm-t54 board directory, config file. Enable build.
[snip]
diff --git a/board/compulab/cm_t54/Makefile b/board/compulab/cm_t54/Makefile
new file mode 100644
index 000..bd8bc51
--- /dev/null
+++ b/board/compulab/cm_t54/Makefile
@@ -0,0 +1,10 @@
+#
+# Copyright (C) 2014 Compulab Ltd - http://compulab.co.il/
+#
+# Author: Dmitry Lifshitz lifsh...@compulab.co.il
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y += $(BOARD).o
Please don't use $(BOARD) here, just went and changed the other users of
this convention.
+/*
+ * Routine: board_init
+ * Description: hardware init.
+ */
+int board_init(void)
+{
+ gd-bd-bi_boot_params = (0x8000 + 0x100); /* boot param addr */
+
+ return 0;
+}
CONFIG_SYS_SDRAM_BASE + 0x100
+#define CONFIG_EXTRA_ENV_SETTINGS \
+ loadaddr=0x8200\0 \
+ fdtaddr=0x80F8\0 \
+ fdt_high=0x\0 \
+ rdaddr=0x8100\0 \
Can you use DEFAULT_LINUX_BOOT_ENV here (see u-boot-ti) ? I really
don't like disabling fdt relocation with it being below 128MB (I'd
prefer what we do with DEFAULT_LINUX_BOOT_ENV and bootm_size, please see
the various ML threads about that).
Thanks!
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] am335x: pepper: Add Gumstix Pepper AM335x-based machine
On Tue, Apr 29, 2014 at 11:05:35AM -0700, Ash Charles wrote: This adds the Gumstix Pepper[1] single-board computer based on the TI AM335x processor. Schematics are available [2]. [1] https://store.gumstix.com/index.php/products/344/ [2] https://pubs.gumstix.com/boards/PEPPER/ [snip] +/* Mach type */ +#define MACH_TYPE_PEPPER 4207/* Until the next sync */ +#define CONFIG_MACH_TYPE MACH_TYPE_PEPPER Shouldn't need this, you don't support any non-DT kernels do you, really? +#define CONFIG_EXTRA_ENV_SETTINGS \ + loadaddr=0x80F8\0 \ + dtbaddr=0x8020\0 \ Please look at DEFAULT_LINUX_BOOT_ENV and the related discussions. Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap4: duovero: Add Gumstix DuoVero machine.
On Tue, Apr 29, 2014 at 02:31:33PM -0700, Ash Charles wrote:
This adds the Gumstix DuoVero machine [1]. This is a OMAP4430-based
computer-on-module (COM aka SOM) that can be mounted on various
expansion boards with different peripherals.
[snip]
+ gd-bd-bi_arch_number = MACH_TYPE_OMAP4_DUOVERO;
You don't really support non-DT kernels do you?
+ gd-bd-bi_boot_params = (0x8000 + 0x100); /* boot param addr */
CONFIG_SYS_SDRAM_BASE + ...
diff --git a/include/configs/ti_omap4_common.h
b/include/configs/ti_omap4_common.h
index bcb5eab..4563cbb 100644
--- a/include/configs/ti_omap4_common.h
+++ b/include/configs/ti_omap4_common.h
@@ -111,9 +111,13 @@
importbootenv=echo Importing environment from mmc${mmcdev} ...; \
env import -t ${loadaddr} ${filesize}\0 \
loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0 \
+ loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0 \
mmcboot=echo Booting from mmc${mmcdev} ...; \
run mmcargs; \
bootz ${loadaddr} - ${fdtaddr}\0 \
+ uimageboot=echo Booting from mmc${mmcdev} ...; \
+ run mmcargs; \
+ bootm ${loadaddr}\0 \
First, please use 'load' not 'fatload' and second..
findfdt=\
if test $board_name = sdp4430; then \
setenv fdtfile omap4-sdp.dtb; fi; \
@@ -123,6 +127,8 @@
setenv fdtfile omap4-panda-a4.dtb; fi; \
if test $board_name = panda-es; then \
setenv fdtfile omap4-panda-es.dtb; fi; \
+ if test $board_name = duovero; then \
+ setenv fdtfile omap4-duovero.dtb; fi; \
if test $fdtfile = undefined; then \
echo WARNING: Could not determine device tree to use;
fi; \0 \
loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0 \
@@ -146,6 +152,9 @@
run loadfdt; \
run mmcboot; \
fi; \
+ if run loaduimage; then \
+ run uimageboot; \
+ fi; \
You really are using uImage and not zImage for this board, but not for
pepper?
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] [omap3][overo] Allow overo to boot with device tree
On Tue, Apr 29, 2014 at 04:15:28PM -0700, Ash Charles wrote: Update the board configuration for Gumstix Overo. In particular, add support for zImage and DTB files on boot. Signed-off-by: Ash Charles ashchar...@gmail.com [snip] #define CONFIG_EXTRA_ENV_SETTINGS \ loadaddr=0x8200\0 \ + dtbaddr=0x8160\0 \ + dtbfile=overo.dtb\0 \ Please see DEFAULT_LINUX_BOOT_ENV and the related discussions. If you have less than 128MB DDR we can sort something out, but if you have 256MB it's really advised to use 0x8800 for the DT (see Documentation/arm/Booting in the kernel). -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/12] imx: ventana: switch to SPL
On Mon, Apr 28, 2014 at 1:17 PM, Tim Harvey thar...@gateworks.com wrote:
Switch to an SPL image. The SPL for Ventana does the following:
- setup i2c and read the factory programmed EEPROM to obtain DRAM config
and model for board-specific calibration data
- configure DRAM per CPU/size/layout/devices/calibration
- load u-boot.img from NAND or MTD depending on boot device and jump to it
This allows for a single SPL+u-boot.img to replace the previous multiple board
configurations.
snip
+
+static void i2c_setup_iomux(void)
+{
+ if (is_cpu_type(MXC_CPU_MX6Q))
+ setup_i2c(0, CONFIG_SYS_I2C_SPEED, 0x7f, mx6q_i2c_pad_info0);
+ else
+ setup_i2c(0, CONFIG_SYS_I2C_SPEED, 0x7f,
mx6dl_i2c_pad_info0);
+}
+
snip
+
+/*
+ * called from C runtime startup code (arch/arm/lib/crt0.S:_main)
+ * - we have a stack and a place to store GD, both in SRAM
+ * - no variable global data is available
+ */
+void board_init_f(ulong dummy)
+{
+ struct ventana_board_info ventana_info;
+ int board_model;
+
+ /* iomux and setup of i2c */
+ i2c_setup_iomux();
+ timer_init();
+ board_model = read_eeprom(I2C_GSC, ventana_info);
+
+ /* provide some some default: 32bit 128MB */
+ if (GW_UNKNOWN == board_model) {
+ ventana_info.sdram_width = 2;
+ ventana_info.sdram_size = 3;
+ }
+ spl_dram_init(8 ventana_info.sdram_width,
+ 16 ventana_info.sdram_size,
+ board_model);
+
+ arch_cpu_init();
+
+ /* Clear the BSS. */
+ memset(__bss_start, 0, __bss_end - __bss_start);
+
+ /* Set global data pointer. */
+ gd = gdata;
+
+ board_early_init_f();
+
+ preloader_console_init();
+
+ board_init_r(NULL, 0);
+}
Stefano / York,
While preparing for a v3 patch series of my IMX6 SPL bootloader, I
find that commit dec1861be90c948ea9fb771927d3d26a994d2e20 [1] breaks
the above code because gd is now needed within setup_i2c.
I've always been a bit fuzzy on the order of the above calls so I dug
through the code and I think I understand things better. Please
correct any wrong assumptions I'm making below:
- assignment to gd should 'always' be first (before anything needs
it, so why not do it first)
- arch_cpu_init() should go next as this sets up very low level
CPU/SoC resources (in this case AIPS config and watchdog disable)
- board_early_init_f() should be next as that sets up any board-specific iomux
- any additional iomux necessary for SPL should go next (I take care
of i2c iomux and setup here)
- timer_init() next as you need a timer for UART and mxc i2c (for
delays and busy checks)
- preloader_console_init() next as we are now able to send something
over the UART (this gives me early debug for sdram config now too!)
- sdram setup goes next
- after sdram is setup, the bss can be cleared
- board_init_r - pass over to generic SPL code which will load/call
an image based on boot device
So, if the above is correct, I should rework the above function as follows:
void board_init_f(ulong dummy)
{
struct ventana_board_info ventana_info;
int board_model;
/* Set global data pointer. */
gd = gdata;
/* setup AIPS and disable watchdog */
arch_cpu_init();
/* iomux and setup of i2c */
board_early_init_f();
i2c_setup_iomux();
/* setup GP timer */
timer_init();
/* UART clocks enabled and gd valid - init serial console */
preloader_console_init();
/* read/validate EEPROM info to determine board model and SDRAM cfg */
board_model = read_eeprom(I2C_GSC, ventana_info);
/* provide some some default: 32bit 128MB */
if (GW_UNKNOWN == board_model) {
ventana_info.sdram_width = 2;
ventana_info.sdram_size = 3;
}
/* configure MMDC for SDRAM width/size and per-model calibration */
spl_dram_init(8 ventana_info.sdram_width,
16 ventana_info.sdram_size,
board_model);
/* Clear the BSS. */
memset(__bss_start, 0, __bss_end - __bss_start);
/* load/boot image from boot device */
board_init_r(NULL, 0);
}
Does this make sense?
Thanks,
Tim
[1] -
http://git.denx.de/?p=u-boot.git;a=commitdiff;h=dec1861be90c948ea9fb771927d3d26a994d2e20
+
+void reset_cpu(ulong addr)
+{
+}
diff --git a/boards.cfg b/boards.cfg
index c83aff3..9119e24 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -322,11 +322,7 @@ Active arm armv7 mx6 freescale
mx6qsabreauto
Active arm armv7 mx6 freescale mx6sabresd
mx6dlsabresd
mx6sabresd:IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6dl.cfg,MX6DL
Fabio
Re: [U-Boot] [RFC] Kconfig: MAINTAINERS file or not?
On Mon, Apr 28, 2014 at 06:58:55PM +0900, Masahiro Yamada wrote: Hi. Before I send Kconfig series v2, please let me cofirm our approach of maintainers info. When I posted the RFC series in March, I put maintainers info and board status into defconfig of each board. But this idea was rejected. Instead, MAINTAINERS file as in Linux Kernel was proposed. (And the patch series by Daniel is already on Patchwork.) http://patchwork.ozlabs.org/patch/340546/ But Wolfgang (and Albert) disagreed with it. So, what do we like, at the high level? We like being able to leverage tools and workflows from the linux kernel. What do we not like? Lots of conflicts when merging patches, making things harder for ourselves than they have to be. An issue with putting board maintainer into directly into a Kconfig file is that Kconfig is not awesome arbitrary string contents. Embedding maintainer into Kconfig doesn't buy us pre-existing tools and isn't any easier or harder to copy/paste out of than anything else. An issue with a single top-level MAINTAINERS file is that we'll get conflicts galore. What a MAINTAINERS file would give us is get_maintainers.pl from the kernel which can be helpful. Perhaps a compromise here is to throw lots of MAINTAINERS files around and whack get_maintainers.pl to loop over all 'MAINTAINERS' files rather than the single top level one? That way we can get human understandable information out easily (who owns board/ti/fooevm/ ? Check board/ti/fooevm/MAINTAINERS. New port? Better include the file in the patch set) and a small patch to existing tools should handle this multi file format. I think this is something that must be within the source tree and not a de-coupled database somewhere else, which is at least how I recall reading some of the other suggestions going. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Kconfig: MAINTAINERS file or not?
On 05/06/2014 12:33 PM, Tom Rini wrote: ... An issue with a single top-level MAINTAINERS file is that we'll get conflicts galore. What a MAINTAINERS file would give us is get_maintainers.pl from the kernel which can be helpful. The conflicts we'll get are likely to be quite trivial to resolve though. All changes to a particular entry should go through the subsystem tree that the entry applies to (e.g. only the USB tree should change a top-level USB entry, only an architecture or SoC tree should change an entry for drivers for that architecture/SoC, etc.) As such, it's pretty unlikely there will be many conflicts at all except a few trivial context changes, or some add/add, add/delete conflicts of adjacent blocks. I haven't see Linus complaining about issues merging MAINTAINERS at all, and he'd complain if it was a problem. Or, you could just say all MAINTAINERS changes go through u-boot.git directly. Then, there will be zero conflicts. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/12] imx: ventana: switch to SPL
On 05/06/2014 11:18 AM, Tim Harvey wrote:
On Mon, Apr 28, 2014 at 1:17 PM, Tim Harvey thar...@gateworks.com wrote:
Switch to an SPL image. The SPL for Ventana does the following:
- setup i2c and read the factory programmed EEPROM to obtain DRAM config
and model for board-specific calibration data
- configure DRAM per CPU/size/layout/devices/calibration
- load u-boot.img from NAND or MTD depending on boot device and jump to it
This allows for a single SPL+u-boot.img to replace the previous multiple
board
configurations.
snip
+
+static void i2c_setup_iomux(void)
+{
+ if (is_cpu_type(MXC_CPU_MX6Q))
+ setup_i2c(0, CONFIG_SYS_I2C_SPEED, 0x7f,
mx6q_i2c_pad_info0);
+ else
+ setup_i2c(0, CONFIG_SYS_I2C_SPEED, 0x7f,
mx6dl_i2c_pad_info0);
+}
+
snip
+
+/*
+ * called from C runtime startup code (arch/arm/lib/crt0.S:_main)
+ * - we have a stack and a place to store GD, both in SRAM
+ * - no variable global data is available
+ */
+void board_init_f(ulong dummy)
+{
+ struct ventana_board_info ventana_info;
+ int board_model;
+
+ /* iomux and setup of i2c */
+ i2c_setup_iomux();
+ timer_init();
+ board_model = read_eeprom(I2C_GSC, ventana_info);
+
+ /* provide some some default: 32bit 128MB */
+ if (GW_UNKNOWN == board_model) {
+ ventana_info.sdram_width = 2;
+ ventana_info.sdram_size = 3;
+ }
+ spl_dram_init(8 ventana_info.sdram_width,
+ 16 ventana_info.sdram_size,
+ board_model);
+
+ arch_cpu_init();
+
+ /* Clear the BSS. */
+ memset(__bss_start, 0, __bss_end - __bss_start);
+
+ /* Set global data pointer. */
+ gd = gdata;
+
+ board_early_init_f();
+
+ preloader_console_init();
+
+ board_init_r(NULL, 0);
+}
Stefano / York,
While preparing for a v3 patch series of my IMX6 SPL bootloader, I
find that commit dec1861be90c948ea9fb771927d3d26a994d2e20 [1] breaks
the above code because gd is now needed within setup_i2c.
I've always been a bit fuzzy on the order of the above calls so I dug
through the code and I think I understand things better. Please
correct any wrong assumptions I'm making below:
- assignment to gd should 'always' be first (before anything needs
it, so why not do it first)
- arch_cpu_init() should go next as this sets up very low level
CPU/SoC resources (in this case AIPS config and watchdog disable)
- board_early_init_f() should be next as that sets up any board-specific
iomux
- any additional iomux necessary for SPL should go next (I take care
of i2c iomux and setup here)
- timer_init() next as you need a timer for UART and mxc i2c (for
delays and busy checks)
- preloader_console_init() next as we are now able to send something
over the UART (this gives me early debug for sdram config now too!)
- sdram setup goes next
- after sdram is setup, the bss can be cleared
- board_init_r - pass over to generic SPL code which will load/call
an image based on boot device
So, if the above is correct, I should rework the above function as follows:
void board_init_f(ulong dummy)
{
struct ventana_board_info ventana_info;
int board_model;
/* Set global data pointer. */
gd = gdata;
/* setup AIPS and disable watchdog */
arch_cpu_init();
/* iomux and setup of i2c */
board_early_init_f();
i2c_setup_iomux();
/* setup GP timer */
timer_init();
/* UART clocks enabled and gd valid - init serial console */
preloader_console_init();
/* read/validate EEPROM info to determine board model and SDRAM cfg */
board_model = read_eeprom(I2C_GSC, ventana_info);
/* provide some some default: 32bit 128MB */
if (GW_UNKNOWN == board_model) {
ventana_info.sdram_width = 2;
ventana_info.sdram_size = 3;
}
/* configure MMDC for SDRAM width/size and per-model calibration */
spl_dram_init(8 ventana_info.sdram_width,
16 ventana_info.sdram_size,
board_model);
/* Clear the BSS. */
memset(__bss_start, 0, __bss_end - __bss_start);
/* load/boot image from boot device */
board_init_r(NULL, 0);
}
Does this make sense?
Tim,
I agree gd should be set first if the memory is available. My previous change to
this i2c driver was to make sure it works without DRAM. Since it uses a data
structure, it has no other place to go.
York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm, davinci: Use CONFIG_SPL_PAD_TO for padding the SPL in an ais image
The commits commit b7b5f1a16ca66dfdd817e7339f0e263a5b9f2758 Author: Albert ARIBAUD albert.u.b...@aribaud.net da850evm, da850_am18xxevm: convert to CONFIG_SPL_MAX_FOOTPRINT and commit e7497891e34efe5cb2b3a3dc7c6c096c012ede28 Author: Albert ARIBAUD albert.u.b...@aribaud.net cam_enc_4xx: convert to CONFIG_SPL_MAX_FOOTPRINT replaced CONFIG_SPL_MAX_SIZE by CONFIG_SPL_MAX_FOOTPRINT. However, CONFIG_SPL_MAX_SIZE is used in the Makefile for padding the SPL when preparing an u-boot.ais image. By removing CONFIG_SPL_MAX_SIZE said commits broke the ais image of the da850evm and cam_enc_4xx configurations. This patch converts the u-boot.ais target to use CONFIG_SPL_PAD_TO instead of CONFIG_SPL_MAX_SIZE for padding the SPL and adds a #define CONFIG_SPL_PAD_TO where it is required. Signed-off-by: Christian Riesch christian.rie...@omicron.at Reported-by: Tom Taylor ttaylor.ta...@gmail.com Cc: Sudhakar Rajashekhara sudhakar@ti.com Cc: Heiko Schocher h...@denx.de Cc: Albert ARIBAUD albert.u.b...@aribaud.net --- Makefile |2 +- include/configs/da850evm.h |1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index ff38a43..869f442 100644 --- a/Makefile +++ b/Makefile @@ -890,7 +890,7 @@ MKIMAGEFLAGS_u-boot-spl.ais = -s -n $(if $(CONFIG_AIS_CONFIG_FILE), \ spl/u-boot-spl.ais: spl/u-boot-spl.bin FORCE $(call if_changed,mkimage) -OBJCOPYFLAGS_u-boot.ais = -I binary -O binary --pad-to=$(CONFIG_SPL_MAX_SIZE) +OBJCOPYFLAGS_u-boot.ais = -I binary -O binary --pad-to=$(CONFIG_SPL_PAD_TO) u-boot.ais: spl/u-boot-spl.ais u-boot.img FORCE $(call if_changed,pad_cat) diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h index 509fe20..0ca0c8d 100644 --- a/include/configs/da850evm.h +++ b/include/configs/da850evm.h @@ -386,6 +386,7 @@ #define CONFIG_SPL_STACK 0x8001ff00 #define CONFIG_SPL_TEXT_BASE 0x8000 #define CONFIG_SPL_MAX_FOOTPRINT 32768 +#define CONFIG_SPL_PAD_TO 32768 #endif /* Load U-Boot Image From MMC */ -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] DA850EVM with USE_NAND config does not pad the AIS file
Hello Heiko, --On May 06, 2014 16:46 +0200 Heiko Schocher h...@denx.de wrote: Hello Christian, Am 06.05.2014 13:30, schrieb Christian Riesch: Tom, Thank you very much for your investigations :-) --On April 26, 2014 13:34 -0400 Tom Taylor ttaylor.ta...@gmail.com wrote: I'm a U-Boot newbie so please feel free to correct how I'm reporting this issue.. I recently downloaded the 2014.04-rc3 snapshot to build U-Boot for my custom DA850-based board. The only change was to add a new target dav850evm_nand in boards.cfg with the added parameter USE_NAND. The resulting AIS file was programmed into EVM-compatible NAND using standard sfh_OMAP-L138 method. The board failed to boot, and stayed in a loop printing the SPL console message repeatedly. After some debugging with CCS 5.5 and an XDS100v2, I found that incorrect code was being loaded into the 0xc108000 RAM destination. The da850evm.h file defines CONFIG_SYS_NAND_U_BOOT_OFFS as 0x28000, which corresponds to an AIS offset of 0x8000 but the u-boot header did not appear there in the AIS file. A search revealed that the Makefile catenated u-boot immediately after the SPL without any padding. Further investigation revealed that the target Makefile needs CONFIG_SPL_MAX_SIZE to be defined as 0x8000 in order for the padding to be performed properly; however, this constant was apparently deleted during a series of changes in April, 2013 to accommodate separate code and BSS size limits for another target. In its place, CONFIG_SPL_MAX_FOOTPRINT was defined as 32768. Unfortunately, the da850evm Makefile does not refer to this constant. To solve the problem, I added the following 2 lines in my custom-modified da850evm.h: # define CONFIG_SPL_PAD_TO 0x8000 # define CONFIG_SPL_MAX_SIZE 0x8000 although the first line may not be strictly required. Yes, CONFIG_SPL_PAD_TO is currently not used for the 'make u-boot.ais' target in the Makefile. Instead, the Makefile uses CONFIG_SPL_MAX_SIZE for padding the SPL, which is probably wrong. Yes, CONFIG_SPL_PAD_TO is the correct define. On the other hand the question is is CONFIG_SPL_PAD_TO not always equal to CONFIG_SPL_MAX_SIZE ? I guess yes. This solved the problem and allowed the board to boot. Doesn't this mean that other similar targets may be broken? I think yes. I think the right fix would be to change the Makefile to use CONFIG_SPL_PAD_TO instead of CONFIG_SPL_MAX_SIZE for the u-boot.ais target. diff --git a/Makefile b/Makefile index ff38a43..869f442 100644 --- a/Makefile +++ b/Makefile @@ -890,7 +890,7 @@ MKIMAGEFLAGS_u-boot-spl.ais = -s -n $(if $(CONFIG_AIS_CONFIG_FILE), \ spl/u-boot-spl.ais: spl/u-boot-spl.bin FORCE $(call if_changed,mkimage) -OBJCOPYFLAGS_u-boot.ais = -I binary -O binary --pad-to=$(CONFIG_SPL_MAX_SIZE) +OBJCOPYFLAGS_u-boot.ais = -I binary -O binary --pad-to=$(CONFIG_SPL_PAD_TO) u-boot.ais: spl/u-boot-spl.ais u-boot.img FORCE $(call if_changed,pad_cat) And then check all ARM926EJS/Davinci configurations that use SPL: (extending Tom Rini's grep command from his email) $ git grep -l ARM926EJS include/configs/ | xargs grep -l DAVINCI | xargs grep -l _SPL_ include/configs/cam_enc_4xx.h include/configs/da830evm.h include/configs/da850evm.h include/configs/hawkboard.h include/configs/ipam390.h For the cam_enc_4xx CONFIG_SPL_PAD_TO is already defined, so it should work fine after fixing the Makefile. Heiko, any comments on this? Are you actually using the u-boot.ais target? I have no board to test, but I think it is used. da830evm and hawkboard did not use CONFIG_SPL_MAX_SIZE, so no need to fix them. da850evm: We should add CONFIG_SPL_PAD_TO as already suggested by you. ipam390.h: I think the #define CONFIG_SPL_MAX_SIZE 0x2 should be removed or replaced by #define CONFIG_SPL_PAD_TO 0x2. But actually the board has been added after the commits that replace grep -lr CONFIG_SPL_MAX_SIZE by CONFIG_SPL_MAX_FOOTPRINT, so why didn't that issue come up when adding the board to mainline? Heiko, any comments? Are you using make u-boot.ais here or something else? I am not sure, if we can just remove CONFIG_SPL_MAX_SIZE for this board, as it maybe has only 0x2 space for the SPL ? I had another look at ipam390.h, currently there is #define CONFIG_SPL_MAX_SIZE 0x2 #define CONFIG_SPL_MAX_FOOTPRINT32768 So according to README, the linker checks if the SPL including BSS is smaller than 32kB, and if the SPL excluding BSS is smaller than 128 kB. So the check against CONFIG_SPL_MAX_SIZE is always fulfilled. Therefore it is save to replace CONFIG_SPL_MAX_SIZE with CONFIG_SPL_PAD_TO. maybe: # if !defined(CONFIG_SPL_PAD_TO) define CONFIG_SPL_PAD_TO CONFIG_SPL_MAX_SIZE # endif is better? Heh, thats the case, see: ./include/config_fallbacks.h so, your Makefile patch should be Ok ... Ok, so no change is required for ipam390. I'll send a patch. Christian bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235
Re: [U-Boot] [PATCH 12/12] imx: ventana: switch to SPL
Hello Tim,
On di, 2014-05-06 at 11:18 -0700, Tim Harvey wrote:
On Mon, Apr 28, 2014 at 1:17 PM, Tim Harvey thar...@gateworks.com wrote:
void board_init_f(ulong dummy)
{
struct ventana_board_info ventana_info;
int board_model;
/* Set global data pointer. */
gd = gdata;
/* setup AIPS and disable watchdog */
arch_cpu_init();
/* iomux and setup of i2c */
board_early_init_f();
i2c_setup_iomux();
/* setup GP timer */
timer_init();
/* UART clocks enabled and gd valid - init serial console */
preloader_console_init();
/* read/validate EEPROM info to determine board model and SDRAM cfg */
board_model = read_eeprom(I2C_GSC, ventana_info);
/* provide some some default: 32bit 128MB */
if (GW_UNKNOWN == board_model) {
ventana_info.sdram_width = 2;
ventana_info.sdram_size = 3;
}
/* configure MMDC for SDRAM width/size and per-model calibration */
spl_dram_init(8 ventana_info.sdram_width,
16 ventana_info.sdram_size,
board_model);
/* Clear the BSS. */
memset(__bss_start, 0, __bss_end - __bss_start);
/* load/boot image from boot device */
board_init_r(NULL, 0);
}
Does this make sense?
Since Crt0.S already created gd on the stack before calling
board_init_f, can't the assignment of gd not simply be removed?
Is there anything special about gdata?
Regards,
Jeroen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dwc_ahsata: return failure for MX6 if not IMX6Q
On 5/5/2014 10:22 PM, Tim Harvey wrote:
The IMX6QUAD/DUAL have SATA, but the IMX6SOLO/DL do not. Return an error
indicating no such port instead of attempting a memory access that results
in a data abort and reset. This dynamic detection is necessary for bootloaders
that support multiple variants of the IMX6 SoC.
Signed-off-by: Tim Harvey thar...@gateworks.com
---
drivers/block/dwc_ahsata.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/block/dwc_ahsata.c b/drivers/block/dwc_ahsata.c
index 3569214..638a585 100644
--- a/drivers/block/dwc_ahsata.c
+++ b/drivers/block/dwc_ahsata.c
@@ -17,6 +17,7 @@
#include asm/io.h
#include linux/bitops.h
#include asm/arch/clock.h
+#include asm/arch/sys_proto.h
#include dwc_ahsata.h
struct sata_port_regs {
@@ -558,6 +559,12 @@ int init_sata(int dev)
u32 linkmap;
struct ahci_probe_ent *probe_ent = NULL;
+#if defined(CONFIG_MX6)
+ if (!is_cpu_type(MXC_CPU_MX6Q)) {
!is_cpu_type(MXC_CPU_MX6D)
is needed too ?
Troy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Kconfig: MAINTAINERS file or not?
Dear Tom, In message 20140506183303.GY22182@bill-the-cat you wrote: Perhaps a compromise here is to throw lots of MAINTAINERS files around and whack get_maintainers.pl to loop over all 'MAINTAINERS' files rather than the single top level one? That way we can get human understandable information out easily (who owns board/ti/fooevm/ ? Check board/ti/fooevm/MAINTAINERS. New port? Better include the file in the patch set) and a small patch to existing tools should handle this multi file format. I think that's an excellent idea. I'm all for it. Thanks a lot! 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] [RFC PATCH v2 13/13] tegra: Convert tegra GPIO driver to use driver model
HI Stephen, On 6 May 2014 11:34, Stephen Warren swar...@wwwdotorg.org wrote: On 05/05/2014 05:00 PM, Simon Glass wrote: Hi Stephen, On 5 May 2014 16:07, Stephen Warren swar...@wwwdotorg.org mailto:swar...@wwwdotorg.org wrote: On 05/05/2014 03:30 PM, Simon Glass wrote: ... I think you have it backwards...the current implementation has a single level of hierarchy. Each driver handles one bank (or 'port' in the case of Tegra). What you are talking about is having a single driver handle multiple banks, thus requiring that the driver have a second level to deal with banks, over and above the device. We might end up with that, but I would prefer to move to it when we have evidence that it is a general need. Sigh. This is getting silly. All the APIs in SW need to just take a GPIO ID in the flat range 0..N (N==223 for Tegra20) and deal with it. Anything that expose banks anywhere, either as a parameter to public functions exported from the GPIO controller driver, or as the existence of separate drivers for separate banks, or as a command-line argument that the user sees, or ..., whether it be the U-Boot GPIO core or the Tegra GPIO driver itself that causes this, is just pointless. For exynos, the banks are not contiguous and there is quite a bit of fiddling to make this all work. You may have seen the series going in at the moment to number the GPIOs properly. I understand that Tegra is very straightforward though. Sure, HW that truly is designed as separate banks should be represented as such. However, the existence of such HW shouldn't force *other* HW to artificially expose banks of GPIOs when there's no need/desire to. OK, well that's mostly an implementation issue, will take a look. Eh? We need to support named GPIOs in U-Boot. 155 is a meaningless number which drivers people back and forth to the datasheets, their calculators, a long table, etc. Even the Tegra device tree has moved away from numbers to GPIO names, I notice. The GPIO names are meaningless. I say this because all the Tegra schematics (and documentation that drives them) use the pin/pad name, which is almost always entirely different from the GPIO name. You have to map the pin name back to either the GPIO name or ID using a lookup table (such as the kernel's drivers/pinctrl/pinctrl-tegra20.c). Given the need for a lookup table, we should just use the simpler GPIO ID and not worry about GPIO names. There's no point screwing around with text names when we can just use simple numbers. In DT, GPIOs are specified by integer ID too. Admittedly we have macros that calculate those IDs from the bank/port/offset, but that was probably a mistake, since the bank/port/offset names aren't meaningful. U-Boot provides a friendly named interface for GPIOs. I see that as a requirement for driver model too. As someone who has spent a lot of time at the command line fiddling with hardware, I don't want to go backwards in the driver model conversion. Similarly, using numbers in the DT is very unfriendly and painful IMO. If we can agree on the friendly names, then let's talk about how to simplify things. To be honest, I disagree that meaningless names are friendly. Almost everything else deals with numbers. The values in DT are numbers. The debugfs files in Linux are numbers. The sysfs ABI in Linux is numbers. The current GPIO interface in U-Boot is numbers. The correlation with pinctrl pins is numbers. If the following happens, then I could live with a (part-time) name-based API: * The U-Boot commands accept either a name or a number. That would allow people to use what they want. * The API implemented by U-Boot GPIO drivers uses numbers exclusively. Note that when I say numbers above, all the numbering should be relative to a particular controller. So, I don't mean something like: gpio set 1056 ... where 1056 is 1000 (Tegra GPIO controller base) + 56 (Tegra GPIO ID). Instead, I would expect the command-line interface to be: gpio set tegra 56 gpio set tegra PH0 ... where tegra is the name of the GPIO controller instance, and 56/PH0 is the GPIO ID within that one GPIO controller. The controller name could be pca9555-0 (0th instance of a pca9555 device) or i2c-0-56 (I2C bus 0 device address 0x56) or whatever naming style you want. To support this, I would expect the GPIO driver API to contain just two APIs that know about the GPIO names: int name_to_gpio_id(const char *gpio_name); const char *gpio_id_to_name(int gpio_id); All the other GPIO driver APIs would take int gpio_id (controller-relative integer ID). See gpio_lookup_name() which is where this lives. The GPIO uclass does sequentially number GPIOs, but be aware that on platforms with multiple GPIO
Re: [U-Boot] Problem building am335x_evm config
Try: make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- am335x_evm_defconfig make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- it works for me (please update your CROSS_COMPILE) Vasili, There was a change in 2014.04. After you run the *_defconfig you don't have to (Shouldn't) add am335x_evm to make. See above for correct procedure now. -Jonathan Cormier jcorm...@criticallink.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v2 13/13] tegra: Convert tegra GPIO driver to use driver model
On 05/06/2014 02:28 PM, Simon Glass wrote: ... The GPIO uclass does sequentially number GPIOs, but be aware that on platforms with multiple GPIO controllers (e.g. an I2C GPIO extender) you might hit a problem where the tegra GPIOs are not first, so might start at 8 or 16, for example. However I think that probably can be resolved when we come to it. That fact shouldn't be exposed to the user. If all the GPIO IDs are relative to a specific named GPIO device, then the user will never see the internal offset. Indeed, the GPIO driver for a particular GPIO HW module/chip wouldn't ever see the offset either. In fact, we shouldn't have/introduce a flat/global GPIO numbering space at all. The Linux community has learned that doesn't work very well, and is moving away from it in the more recent gpiod API for example. Everything should be identified as a tuple (GPIO controller handle, GPIO ID within that GPIO controller). ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v2 13/13] tegra: Convert tegra GPIO driver to use driver model
Hi Stephen, On 6 May 2014 14:37, Stephen Warren swar...@wwwdotorg.org wrote: On 05/06/2014 02:28 PM, Simon Glass wrote: ... The GPIO uclass does sequentially number GPIOs, but be aware that on platforms with multiple GPIO controllers (e.g. an I2C GPIO extender) you might hit a problem where the tegra GPIOs are not first, so might start at 8 or 16, for example. However I think that probably can be resolved when we come to it. That fact shouldn't be exposed to the user. If all the GPIO IDs are relative to a specific named GPIO device, then the user will never see the internal offset. Indeed, the GPIO driver for a particular GPIO HW module/chip wouldn't ever see the offset either. In fact, we shouldn't have/introduce a flat/global GPIO numbering space at all. The Linux community has learned that doesn't work very well, and is moving away from it in the more recent gpiod API for example. Everything should be identified as a tuple (GPIO controller handle, GPIO ID within that GPIO controller). Well that would be fairly easy to add my modifying the gpio command. Nothing we have talked about here precludes that, and driver model of course supports it. We should be able to make it backwards compatible too. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] fpga changes
On Tue, May 06, 2014 at 02:28:15PM +0200, Michal Simek wrote: Hi Tom, [cc: Albert] please pull these fpga changes to your tree. On Friday I have sent the next set of fpga changes which we have in our tree but I want to give more time to review them. And also I have based Xilinx ARM Zynq changes based on these patches that's why I would like to add these patches to your tree and then talk to Albert regarding zynq changes. Thanks, Michal The following changes since commit 52fded7b94d98c73a824e4a9d90596a33a1cbb8a: Merge branch 'next' of git://git.denx.de/u-boot-sh (2014-05-02 11:48:07 -0400) are available in the git repository at: git://www.denx.de/git/u-boot-microblaze.git fpga for you to fetch changes up to eeaf3aa5d3ac84015e0999ec437198682d1a776d: fpga: zynq: Use helper function zynq_validate_bitstream (2014-05-06 14:22:16 +0200) Michal Simek (7): fpga: spartan2: Avoid CamelCase fpga: spartan3: Avoid CamelCase fpga: virtex2: Avoid CamelCase fpga: xilinx: Avoid CamelCase for in Xilinx_desc fpga: xilinx: Fix the rest of CamelCases fpga: xilinx: Simplify load/dump/info function handling fpga: zynq: Remove sparse warnings Siva Durga Prasad Paladugu (2): fpga: zynq: Use helper functions for zynq dma fpga: zynq: Use helper function zynq_validate_bitstream board/armadeus/apf27/fpga.c | 6 +-- board/astro/mcf5373l/fpga.c | 6 +-- board/balloon3/balloon3.c| 4 +- board/esd/pmc440/fpga.c | 8 +-- board/gen860t/fpga.c | 6 +-- board/matrix_vision/mvsmr/fpga.c | 6 +-- board/spear/x600/fpga.c | 4 +- board/teejet/mt_ventoux/mt_ventoux.c | 4 +- board/xilinx/zynq/board.c| 14 +++--- drivers/fpga/spartan2.c | 46 + drivers/fpga/spartan3.c | 46 + drivers/fpga/virtex2.c | 40 --- drivers/fpga/xilinx.c| 179 +++--- drivers/fpga/zynqpl.c| 234 -- include/spartan2.h | 72 +-- include/spartan3.h | 84 +++ include/virtex2.h| 66 include/xilinx.h | 65 +--- include/zynqpl.h | 16 +++--- 19 files changed, 416 insertions(+), 490 deletions(-) This introduces: board/spear/x600/fpga.c:177:2: warning: initialization from incompatible pointer type [enabled by default] board/spear/x600/fpga.c:177:2: warning: (near initialization for ‘fpga[0].name’) [enabled by default] Please fix and re-submit, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Microblaze changes
On Tue, May 06, 2014 at 01:35:45PM +0200, Michal Simek wrote: Hi Tom, please pull this one microblaze patch which I have in my queue. Thanks, Michal The following changes since commit 52fded7b94d98c73a824e4a9d90596a33a1cbb8a: Merge branch 'next' of git://git.denx.de/u-boot-sh (2014-05-02 11:48:07 -0400) are available in the git repository at: git://www.denx.de/git/u-boot-microblaze.git master for you to fetch changes up to d1d37b5cab119096bb60c686eff7ea39cfebed25: microblaze: Wire up OF support for emaclite (2014-05-06 13:32:30 +0200) Stephan Linz (1): microblaze: Wire up OF support for emaclite include/configs/microblaze-generic.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Network zynq gem changes
On Tue, May 06, 2014 at 01:44:11PM +0200, Michal Simek wrote: Hi Ben and Tom, please pull these two patches to network tree or to mainline tree. Both changes are easy one. Thanks, Michal The following changes since commit 52fded7b94d98c73a824e4a9d90596a33a1cbb8a: Merge branch 'next' of git://git.denx.de/u-boot-sh (2014-05-02 11:48:07 -0400) are available in the git repository at: git://www.denx.de/git/u-boot-microblaze.git net for you to fetch changes up to 2fd2489b7aa36478433ae2a1f4de9f66e0a80322: net: zynq: Fix sparse warnings in gem (2014-05-06 13:41:55 +0200) Michal Simek (2): net: zynq: Use predefined macros instead of hardcoded value net: zynq: Fix sparse warnings in gem drivers/net/zynq_gem.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
On Mon, May 05, 2014 at 11:51:24AM +0200, Marek Vasut wrote: The following changes since commit a405764c1ec835a41ccda943b9156aee25e15d5e: drivers/i2c/fsl_i2c: modify i2c_read to handle multi-byte write (2014-04-29 07:10:58 +0200) are available in the git repository at: git://git.denx.de/u-boot-usb.git master for you to fetch changes up to af41d6b4cb1602abebaaa9c8774a9b0ece564796: common: fixed linker-list example (2014-05-05 10:24:13 +0200) Adrian Cox (2): usb: Add endian support macros to interrupt transfers in the EHCI driver. usb: Fix USB keyboard polling via control endpoint Lukasz Majewski (1): dfu:fix: Replace wrong return value with proper one Mateusz Zalega (9): mmc: mmc header fix part: header fix usb: dfu: fix boards wo USB cable detection dfu: mmc: raw data write fix dfu: mmc: change offset base handling ums: always initialize mmc before ums_disk_init() am335x: dfu: disable DFU in am335x_evm SPL build USB: gadget: added a saner gadget downloader registration API common: fixed linker-list example Nobuhiro Iwamatsu (1): usb: ehci: rmobile: Add support ehci host driver of rmobile SoCs Przemyslaw Marczak (2): usb:gadget:f_thor: code cleanup in function download_tail() usb:gadget:f_thor: fix write to filesystem by add dfu_flush() Rob Herring (2): usb: handle NULL table in usb_gadget_get_string usb: musb: fill in usb_gadget_unregister_driver Stephen Warren (7): usb: ci_udc: Support larger packets usb: ci_udc: set ep-req.actual after transfer usb: ci_udc: make PHY initialization conditional usb: ci_udc: support variants with hostpc register usb: ums: use only 1 buffer for CI_UDC usb: gadget: allow ci_udc to build with new gadget framework USB: gadget: save driver name before registering it andrey.konova...@linaro.org (1): exynos: usb: Fix data abort on boards w/o vbus-gpio node in the DT README | 7 - arch/arm/include/asm/arch-rmobile/ehci-rmobile.h | 147 + board/samsung/common/ums.c | 6 ++-- board/samsung/origen/origen.c| 7 - board/samsung/trats/trats.c | 4 +-- board/samsung/trats2/trats2.c| 4 +-- board/samsung/universal_c210/universal.c | 7 - common/cmd_dfu.c | 3 +- common/cmd_thordown.c| 3 +- common/cmd_usb_mass_storage.c| 10 -- common/usb_kbd.c | 36 +++--- drivers/dfu/dfu.c| 2 +- drivers/dfu/dfu_mmc.c| 109 ++ drivers/usb/gadget/Makefile | 1 + drivers/usb/gadget/ci_udc.c | 31 --- drivers/usb/gadget/ci_udc.h | 65 --- drivers/usb/gadget/f_dfu.c | 3 ++ drivers/usb/gadget/f_mass_storage.c | 11 --- drivers/usb/gadget/f_thor.c | 15 ++--- drivers/usb/gadget/g_dnl.c | 66 drivers/usb/gadget/storage_common.c | 4 +++ drivers/usb/gadget/usbstring.c | 3 ++ drivers/usb/host/Makefile| 1 + drivers/usb/host/ehci-exynos.c | 3 +- drivers/usb/host/ehci-hcd.c | 56 +++--- drivers/usb/host/ehci-rmobile.c | 130 ++ drivers/usb/host/xhci-exynos5.c | 3 +- drivers/usb/musb-new/musb_uboot.c| 5 ++- include/configs/am335x_evm.h | 10 +++--- include/configs/exynos4-dt.h | 1 - include/configs/trats.h | 4 +-- include/configs/trats2.h | 4 +-- include/dfu.h| 12 include/g_dnl.h | 24 +++ include/linker_lists.h | 2 +- include/mmc.h| 1 + include/part.h | 1 + include/thor.h | 8 - include/usb.h| 10 -- include/usb_mass_storage.h | 8 - 40 files changed, 597
Re: [U-Boot] [GIT PULL] Serial changes for zynq.
On Tue, May 06, 2014 at 02:18:40PM +0200, Michal Simek wrote: Hi Tom, [cc: Albert] please pull these two serial patches to your tree. If this should go through Albert's tree please let me know. Thanks, Michal The following changes since commit 52fded7b94d98c73a824e4a9d90596a33a1cbb8a: Merge branch 'next' of git://git.denx.de/u-boot-sh (2014-05-02 11:48:07 -0400) are available in the git repository at: git://www.denx.de/git/u-boot-microblaze.git serial for you to fetch changes up to 870e0bda43c9ea18a5f2fae5e48905c3b44ea18b: serial: zynq: Fix typo in suffix function name (2014-05-06 13:47:42 +0200) Michal Simek (2): serial: zynq: Remove sparse warnings serial: zynq: Fix typo in suffix function name drivers/serial/serial.c | 4 ++-- drivers/serial/serial_zynq.c | 18 +- 2 files changed, 11 insertions(+), 11 deletions(-) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] am335x: pepper: Add Gumstix Pepper AM335x-based machine
On Tue, May 6, 2014 at 11:02 AM, Tom Rini tr...@ti.com wrote: Shouldn't need this, you don't support any non-DT kernels do you, really? Embarrassingly, the default kernel is non-devicetree. Future updates to the BSP will use devicetree instead but some customers may still wish to use a non-devicetree kernel. Do you prefer a v2 with non-devicetree removed or can this stand as-is? +#define CONFIG_EXTRA_ENV_SETTINGS \ + loadaddr=0x80F8\0 \ + dtbaddr=0x8020\0 \ Please look at DEFAULT_LINUX_BOOT_ENV and the related discussions. Cool. Will send a v2 with this fixed. --Ash ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] am335x: pepper: Add Gumstix Pepper AM335x-based machine
On Tue, May 06, 2014 at 03:34:50PM -0700, Ash Charles wrote: On Tue, May 6, 2014 at 11:02 AM, Tom Rini tr...@ti.com wrote: Shouldn't need this, you don't support any non-DT kernels do you, really? Embarrassingly, the default kernel is non-devicetree. Future updates to the BSP will use devicetree instead but some customers may still wish to use a non-devicetree kernel. Do you prefer a v2 with non-devicetree removed or can this stand as-is? As long as it's really being used then OK, you can keep it. +#define CONFIG_EXTRA_ENV_SETTINGS \ + loadaddr=0x80F8\0 \ + dtbaddr=0x8020\0 \ Please look at DEFAULT_LINUX_BOOT_ENV and the related discussions. Cool. Will send a v2 with this fixed. Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/12] imx: ventana: switch to SPL
On Tue, May 6, 2014 at 12:11 PM, Jeroen Hofstee dasub...@myspectrum.nl wrote:
Hello Tim,
On di, 2014-05-06 at 11:18 -0700, Tim Harvey wrote:
On Mon, Apr 28, 2014 at 1:17 PM, Tim Harvey thar...@gateworks.com wrote:
void board_init_f(ulong dummy)
{
struct ventana_board_info ventana_info;
int board_model;
/* Set global data pointer. */
gd = gdata;
/* setup AIPS and disable watchdog */
arch_cpu_init();
/* iomux and setup of i2c */
board_early_init_f();
i2c_setup_iomux();
/* setup GP timer */
timer_init();
/* UART clocks enabled and gd valid - init serial console */
preloader_console_init();
/* read/validate EEPROM info to determine board model and SDRAM cfg
*/
board_model = read_eeprom(I2C_GSC, ventana_info);
/* provide some some default: 32bit 128MB */
if (GW_UNKNOWN == board_model) {
ventana_info.sdram_width = 2;
ventana_info.sdram_size = 3;
}
/* configure MMDC for SDRAM width/size and per-model calibration */
spl_dram_init(8 ventana_info.sdram_width,
16 ventana_info.sdram_size,
board_model);
/* Clear the BSS. */
memset(__bss_start, 0, __bss_end - __bss_start);
/* load/boot image from boot device */
board_init_r(NULL, 0);
}
Does this make sense?
Since Crt0.S already created gd on the stack before calling
board_init_f, can't the assignment of gd not simply be removed?
Is there anything special about gdata?
Regards,
Jeroen
Jeroen,
That does make sense, but what I find is that York's ocmmit
dec1861be90c948ea9fb771927d3d26a994d2e20 requires that gd be blanked
and its not. This causes bus_i2c_init to skip its initialization
because p-base is not zero.
York, does this make sense? Your patch creates a dependence on
gd-srdata being blank which isn't the case with the SRAM when booting
from the IMX6 boot rom.
Tim
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] [omap3][overo] Allow overo to boot with device tree
On Tue, May 6, 2014 at 11:14 AM, Tom Rini tr...@ti.com wrote: Please see DEFAULT_LINUX_BOOT_ENV and the related discussions. If you have less than 128MB DDR we can sort something out, but if you have 256MB it's really advised to use 0x8800 for the DT (see Documentation/arm/Booting in the kernel). Overo doesn't pull in the configuration from include/configs/ti_armv7_common.h where DEFAULT_LINUX_BOOT_ENV is defined. Might a v2 using the settings defined by DEFAULT_LINUX_BOOT_ENV in the overo config be acceptable? --Ash ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Trivial fix to .gitignore for spl/Makefile
Hi Ralph, On Thu, 1 May 2014 14:18:41 -0400 Ralph Siemsen ral...@netwinder.org wrote: Trivial fix to .gitignore for spl/Makefile According to the gitignore man page: An optional prefix ! which negates the pattern; any matching file excluded by a previous pattern will become included again. ^^ So the directory exclude /spl/* must come before the exception for spl/Makefile otherwise it has no effect. Signed-off-by: Ralph Siemsen ral...@netwinder.org I am Ccing Dan Murphy, the author of commit 86a8b3a207 just in case. I am not sure if this change is trivial or not. But anyway this patch worked for me on git v1.7.9.5 and v1.8.3.2. Tested-by: Masahiro Yamada yamad...@jp.panasonic.com [on git v1.7.9.5 / v1.8.3.2] Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] powerpc/85xx: add T4080 SoC support
T4080 SoC is a low-power version of T4160 SoC.
T4080 combines 4 dual-threaded Power Architecture e6500
cores with single cluster and two memory complexes.
Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
v3: refine comments.
v2: add more comments.
arch/powerpc/cpu/mpc85xx/Makefile | 2 ++
arch/powerpc/cpu/mpc85xx/cpu.c| 26 ++
arch/powerpc/cpu/mpc85xx/cpu_init.c | 9 -
arch/powerpc/cpu/mpc85xx/speed.c | 3 ++-
arch/powerpc/cpu/mpc85xx/t4240_serdes.c | 2 +-
arch/powerpc/cpu/mpc8xxx/cpu.c| 1 +
arch/powerpc/include/asm/config_mpc85xx.h | 16 +++-
arch/powerpc/include/asm/fsl_errata.h | 2 ++
arch/powerpc/include/asm/immap_85xx.h | 6 --
arch/powerpc/include/asm/processor.h | 1 +
drivers/net/fm/Makefile | 1 +
11 files changed, 59 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/Makefile
b/arch/powerpc/cpu/mpc85xx/Makefile
index 4094785..ad26b43 100644
--- a/arch/powerpc/cpu/mpc85xx/Makefile
+++ b/arch/powerpc/cpu/mpc85xx/Makefile
@@ -44,6 +44,7 @@ obj-$(CONFIG_PPC_P5020) += p5020_ids.o
obj-$(CONFIG_PPC_P5040) += p5040_ids.o
obj-$(CONFIG_PPC_T4240) += t4240_ids.o
obj-$(CONFIG_PPC_T4160) += t4240_ids.o
+obj-$(CONFIG_PPC_T4080) += t4240_ids.o
obj-$(CONFIG_PPC_B4420) += b4860_ids.o
obj-$(CONFIG_PPC_B4860) += b4860_ids.o
obj-$(CONFIG_PPC_T1040) += t1040_ids.o
@@ -88,6 +89,7 @@ obj-$(CONFIG_PPC_P5020) += p5020_serdes.o
obj-$(CONFIG_PPC_P5040) += p5040_serdes.o
obj-$(CONFIG_PPC_T4240) += t4240_serdes.o
obj-$(CONFIG_PPC_T4160) += t4240_serdes.o
+obj-$(CONFIG_PPC_T4080) += t4240_serdes.o
obj-$(CONFIG_PPC_B4420) += b4860_serdes.o
obj-$(CONFIG_PPC_B4860) += b4860_serdes.o
obj-$(CONFIG_BSC9132) += bsc9132_serdes.o
diff --git a/arch/powerpc/cpu/mpc85xx/cpu.c b/arch/powerpc/cpu/mpc85xx/cpu.c
index 12e8e10..27d7095 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu.c
@@ -77,6 +77,32 @@ int checkcpu (void)
major = SVR_MAJ(svr);
minor = SVR_MIN(svr);
+#if defined(CONFIG_SYS_FSL_QORIQ_CHASSIS2) defined(CONFIG_E6500)
+ if (SVR_SOC_VER(svr) == SVR_T4080) {
+ ccsr_rcpm_t *rcpm =
+ (void __iomem *)(CONFIG_SYS_FSL_CORENET_RCPM_ADDR);
+
+ setbits_be32(gur-devdisr2, FSL_CORENET_DEVDISR2_DTSEC1_6 ||
+FSL_CORENET_DEVDISR2_DTSEC1_9);
+ setbits_be32(gur-devdisr3, FSL_CORENET_DEVDISR3_PCIE3);
+ setbits_be32(gur-devdisr5, FSL_CORENET_DEVDISR5_DDR3);
+
+ /* There are 8 cores running when T4080 brings up,
+* disable core4~7 in the 2nd cluster.
+*/
+ for (i = 4; i 8; i++)
+ cpu_disable(i);
+
+ /* request core4~7 into PH20 state (prior to entering PCL10
+* state, all cores in cluster should be placed in PH20 state).
+*/
+ setbits_be32(rcpm-pcph20setr, 0xf0);
+
+ /* put the 2nd cluster into PCL10 state */
+ setbits_be32(rcpm-clpcl10setr, 1 1);
+ }
+#endif
+
if (cpu_numcores() 1) {
#ifndef CONFIG_MP
puts(Unicore software on multiprocessor system!!\n
diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index 36ef232..2edfe5b 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -462,10 +462,17 @@ __attribute__((weak, alias(__fsl_serdes__init))) void
fsl_serdes_init(void);
int enable_cluster_l2(void)
{
int i = 0;
- u32 cluster;
+ u32 cluster, svr = get_svr();
ccsr_gur_t *gur = (void __iomem *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
struct ccsr_cluster_l2 __iomem *l2cache;
+ /* only the L2 cache of the first cluster should be enabled on T4080,
+* but there is no EOC in the first cluster on T4080, so return here
+* to skip enabling L2 cache of the 2nd cluster.
+*/
+ if (SVR_SOC_VER(svr) == SVR_T4080)
+ return 0;
+
cluster = in_be32(gur-tp_cluster[i].lower);
if (cluster TP_CLUSTER_EOC)
return 0;
diff --git a/arch/powerpc/cpu/mpc85xx/speed.c b/arch/powerpc/cpu/mpc85xx/speed.c
index d516d4e..3236f6a 100644
--- a/arch/powerpc/cpu/mpc85xx/speed.c
+++ b/arch/powerpc/cpu/mpc85xx/speed.c
@@ -123,7 +123,8 @@ void get_sys_info(sys_info_t *sys_info)
* T4240/T4160 Rev1.0. eg. It's 12 in Rev1.0, however, for Rev2.0
* it uses 6.
*/
-#if defined(CONFIG_PPC_T4240) || defined(CONFIG_PPC_T4160)
+#if defined(CONFIG_PPC_T4240) || defined(CONFIG_PPC_T4160) || \
+ defined(CONFIG_PPC_T4080)
if (SVR_MAJ(get_svr()) = 2)
mem_pll_rat *= 2;
#endif
diff --git a/arch/powerpc/cpu/mpc85xx/t4240_serdes.c
b/arch/powerpc/cpu/mpc85xx/t4240_serdes.c
index ff55e3c..1f99a0a 100644
---
Re: [U-Boot] [RFC PATCH v2 04/13] Makefile: Support include files for .dts files
Hi Simon, Stephen, On Mon, 05 May 2014 10:54:52 -0600 Stephen Warren swar...@wwwdotorg.org wrote: On 05/05/2014 10:09 AM, Simon Glass wrote: Linux supports this, and if we are to have compatible device tree files, U-Boot should also. diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib # Modified for U-Boot dtc_cpp_flags = -Wp,-MD,$(depfile).pre.tmp -nostdinc\ -I$(srctree)/arch/$(ARCH)/dts \ +-I$(srctree)/include\ -undef -D__DTS__ I don't think we should add the top-level include/ directory to the DT include path. That is something I very specifically avoided in the kernel Makefiles. If we did allow this, then DTs could start including arbitrary U-Boot header files, rather than just header files intended to be used in DT bindings, and that would then make the DT files used in U-Boot not portable to the Linux kernel, or any standalone DT file repository which may appear. Instead, let's create a standalone root directory for the DT include files, and add that to the DT header path. We can add this DT-specific include path to the include patch for U-Boot C code if needed. Perhaps we can create a top-level dt/include/ or device-tree/include directory for this? I agree with Stephen. I hesitate to add the top-level include/ to the path. If we try to follow the Linux style, we can add the include path -I$(srctree)/arch/$(ARCH)/dts/include and create symbolic links to include/dt-bindings. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/t104xrdb: Toggle deep sleep management signals after resume
From: Tang Yuantian yuantian.t...@freescale.com
T104xrdb has several sleep management signals that are used for deep
sleep. They are enabled by OS to enter deep sleep and should be
disabled by u-boot when cores wake up.
Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
---
board/freescale/t104xrdb/t104xrdb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/board/freescale/t104xrdb/t104xrdb.c
b/board/freescale/t104xrdb/t104xrdb.c
index 24b8dba..c87519c 100644
--- a/board/freescale/t104xrdb/t104xrdb.c
+++ b/board/freescale/t104xrdb/t104xrdb.c
@@ -108,6 +108,8 @@ void ft_board_setup(void *blob, bd_t *bd)
#ifdef CONFIG_DEEP_SLEEP
void board_mem_sleep_setup(void)
{
+ /* does not provide HW signals for power management */
+ CPLD_WRITE(misc_ctl_status, (CPLD_READ(misc_ctl_status) ~0x40));
/* Disable MCKE isolation */
gpio_set_value(2, 0);
udelay(1);
--
1.8.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] fsl/pci: Add workaround for erratum A-005434
By default, all PEX inbound windows PEX_PEXIWARn[TRGT] are
mapped to 0xF, which is local memory. But for BSC9132, 0xF
is CCSR, 0x0 is local memory.
Signed-off-by: Minghuan Lian minghuan.l...@freescale.com
Signed-off-by: Chunhe Lan chunhe@freescale.com
---
arch/powerpc/cpu/mpc85xx/cmd_errata.c |3 +++
arch/powerpc/include/asm/config_mpc85xx.h |1 +
drivers/pci/fsl_pci_init.c|9 +++--
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
index 8b79c05..4bf5bc7 100644
--- a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
+++ b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
@@ -277,6 +277,9 @@ static int do_errata(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
if (has_erratum_a006261())
puts(Work-around for Erratum A006261 enabled\n);
#endif
+#ifdef CONFIG_SYS_FSL_ERRATUM_A005434
+ puts(Work-around for Erratum A-005434 enabled\n);
+#endif
return 0;
}
diff --git a/arch/powerpc/include/asm/config_mpc85xx.h
b/arch/powerpc/include/asm/config_mpc85xx.h
index df44451..94c769d 100644
--- a/arch/powerpc/include/asm/config_mpc85xx.h
+++ b/arch/powerpc/include/asm/config_mpc85xx.h
@@ -583,6 +583,7 @@
#define CONFIG_SYS_FSL_ESDHC_P1010_BROKEN_SDCLK
#define CONFIG_SYS_FSL_PCIE_COMPAT fsl,qoriq-pcie-v2.2
#define CONFIG_SYS_FSL_ERRATUM_A005125
+#define CONFIG_SYS_FSL_ERRATUM_A005434
#define CONFIG_SYS_FSL_ERRATUM_I2C_A004447
#define CONFIG_SYS_FSL_A004447_SVR_REV 0x11
#define CONFIG_ESDHC_HC_BLK_ADDR
diff --git a/drivers/pci/fsl_pci_init.c b/drivers/pci/fsl_pci_init.c
index 6317fb1..3a41b0e 100644
--- a/drivers/pci/fsl_pci_init.c
+++ b/drivers/pci/fsl_pci_init.c
@@ -49,8 +49,13 @@ static void set_inbound_window(volatile pit_t *pi,
u64 size)
{
u32 sz = (__ilog2_u64(size) - 1);
- u32 flag = PIWAR_EN | PIWAR_LOCAL |
- PIWAR_READ_SNOOP | PIWAR_WRITE_SNOOP;
+#ifdef CONFIG_SYS_FSL_ERRATUM_A005434
+ u32 flag = 0;
+#else
+ u32 flag = PIWAR_LOCAL;
+#endif
+
+ flag |= PIWAR_EN | PIWAR_READ_SNOOP | PIWAR_WRITE_SNOOP;
out_be32(pi-pitar, r-phys_start 12);
out_be32(pi-piwbar, r-bus_start 12);
--
1.7.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/85xx: Add T4160RDB board support
T4160RDB shares the same platform as T4240RDB. T4160 is a low power version of T4240, with the eight e6500 cores, two DDR3 controllers, and same peripheral bus interfaces. Signed-off-by: Chunhe Lan chunhe@freescale.com --- boards.cfg |1 + include/configs/T4240RDB.h |4 2 files changed, 5 insertions(+), 0 deletions(-) diff --git a/boards.cfg b/boards.cfg index 3ac45b2..a8ea91e 100644 --- a/boards.cfg +++ b/boards.cfg @@ -963,6 +963,7 @@ Active powerpc mpc85xx- freescale t4qds Active powerpc mpc85xx- freescale t4qds T4240QDS_SDCARD T4240QDS:PPC_T4240,RAMBOOT_PBL,SDCARD,SYS_TEXT_BASE=0xFFF4 - Active powerpc mpc85xx- freescale t4qds T4240QDS_SPIFLASH T4240QDS:PPC_T4240,RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF4 - Active powerpc mpc85xx- freescale t4qds T4240QDS_SRIO_PCIE_BOOT T4240QDS:PPC_T4240,SRIO_PCIE_BOOT_SLAVE,SYS_TEXT_BASE=0xFFF4 - +Active powerpc mpc85xx- freescale t4rdb T4160RDB T4240RDB:PPC_T4160 Chunhe Lan chunhe@freescale.com Active powerpc mpc85xx- freescale t4rdb T4240RDB T4240RDB:PPC_T4240 Chunhe Lan chunhe@freescale.com Active powerpc mpc85xx- gdsys p1022 controlcenterd_36BIT_SDCARD controlcenterd:36BIT,SDCARD Dirk Eibach eib...@gdsys.de Active powerpc mpc85xx- gdsys p1022 controlcenterd_36BIT_SDCARD_DEVELOP controlcenterd:36BIT,SDCARD,DEVELOP Dirk Eibach eib...@gdsys.de diff --git a/include/configs/T4240RDB.h b/include/configs/T4240RDB.h index 1bb083a..f14e710 100644 --- a/include/configs/T4240RDB.h +++ b/include/configs/T4240RDB.h @@ -678,7 +678,11 @@ unsigned long get_board_ddr_clk(void); * interleaving. It can be cacheline, page, bank, superbank. * See doc/README.fsl-ddr for details. */ +#ifdef CONFIG_PPC_T4240 #define CTRL_INTLV_PREFERED 3way_4KB +#else +#define CTRL_INTLV_PREFERED cacheline +#endif #defineCONFIG_EXTRA_ENV_SETTINGS \ hwconfig=fsl_ddr: \ -- 1.7.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv3 00/13] mmc: exynos: code cleanup and support DDR mode
Hi, All. If didn't have any other comment, could you apply this patch? I want to merge this patch at mainline. Best Regards, Jaehoon Chung On 04/29/2014 01:06 PM, Jaehoon Chung wrote: Dear, All. Did you have any comment? Best Regards, Jaehoon Chung On 04/11/2014 02:55 PM, Jaehoon Chung wrote: If card and host are supported DDR mode, then it can be used the DDR mode. This patch-set has dependency about beomho's patch-set. (Based-on u-boot-samsung repository) It's result for loading image. sdhci controller -5260488 bytes read in 259 ms (19.4 MiB/s) dwmmc controller without DDR mode - 5260488 bytes read in 202 ms (24.8 MiB/s) dwmmc controller with DDR mode - 5260488 bytes read in 118 ms (42.5 MiB/s) Download the 400M image with lthor. sdhci controller - 59.4sec (Avg 6.95 MB/s) dwmmc controller without DDR mode - 61.6sec (Avg 6.72MB/s) dwmmc controller with DDR mode - 60.4sec (Avg 6.85MB/s) Beomho Seo (3): arm: exynos: pinmux: add sdmmc4 gpio configratuion arm: exynos: clock: Remove exynos4x12_set_mmc_clk function board: trats2: Enable device tree on Trats2 Jaehoon Chung (10): ARM: exynos: board: change the mmc/sd init sequence ARM: exynos: clock: modify the set_mmc_clk for exynos4 mmc: exynos_dw_mmc: restore the property into host mmc: remove the unnecessary define and fix the wrong bit control mmc: support the DDR mode for eMMC mmc: dw_mmc: support the DDR mode ARM: dts: exnyos: enable dw-mmc controller mmc: exynos_dw_mmc: enable the DDR mode ARM: exynos4: enable the dwmmc configuration mmc: s5p_sdhci: add the s5p_sdhci_core_init function arch/arm/cpu/armv7/exynos/clock.c | 45 ++- arch/arm/cpu/armv7/exynos/pinmux.c | 18 ++- arch/arm/dts/exynos4.dtsi |8 ++ arch/arm/dts/exynos4412-trats2.dts | 12 ++ arch/arm/include/asm/arch-exynos/clk.h |5 + board/samsung/common/board.c | 13 +- drivers/mmc/dw_mmc.c | 12 +- drivers/mmc/exynos_dw_mmc.c| 209 drivers/mmc/mmc.c | 16 ++- drivers/mmc/s5p_sdhci.c| 42 +++ include/configs/exynos4-dt.h |3 + include/dwmmc.h|5 + include/mmc.h | 25 ++-- 13 files changed, 250 insertions(+), 163 deletions(-) ___ 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] [PATCH v7] nand/denali: Adding Denali NAND driver support
Hi Chin, Could you send v8? 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] dwc_ahsata: return failure for MX6 if not IMX6Q
On Tue, May 6, 2014 at 12:55 PM, Troy Kisky
troy.ki...@boundarydevices.com wrote:
On 5/5/2014 10:22 PM, Tim Harvey wrote:
The IMX6QUAD/DUAL have SATA, but the IMX6SOLO/DL do not. Return an error
indicating no such port instead of attempting a memory access that results
in a data abort and reset. This dynamic detection is necessary for
bootloaders
that support multiple variants of the IMX6 SoC.
Signed-off-by: Tim Harvey thar...@gateworks.com
---
drivers/block/dwc_ahsata.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/block/dwc_ahsata.c b/drivers/block/dwc_ahsata.c
index 3569214..638a585 100644
--- a/drivers/block/dwc_ahsata.c
+++ b/drivers/block/dwc_ahsata.c
@@ -17,6 +17,7 @@
#include asm/io.h
#include linux/bitops.h
#include asm/arch/clock.h
+#include asm/arch/sys_proto.h
#include dwc_ahsata.h
struct sata_port_regs {
@@ -558,6 +559,12 @@ int init_sata(int dev)
u32 linkmap;
struct ahci_probe_ent *probe_ent = NULL;
+#if defined(CONFIG_MX6)
+ if (!is_cpu_type(MXC_CPU_MX6Q)) {
!is_cpu_type(MXC_CPU_MX6D)
is needed too ?
Troy
Troy,
Indeed - thanks for the reminder!
Tim
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/9] Refactoring and Endian bug fixes of fdt_support
Hi Jerry Van Baren, Tom This is the third time I request the review of my series. This series was delegated to Jerry Van Baren and nothing's happened for almost 3 months. Is he too busy? Or not an active developer any more? Tom, could you review (and if it looks good, apply this series directly into u-boot/master?) Some FDT-related patches are delegated to Jerry Van Baren and some are to other custodians. For example, http://patchwork.ozlabs.org/patch/338543/ http://patchwork.ozlabs.org/patch/338542/ were delegated to York Sun and applied immediately. But my patchset has still been dismissed. I'm sad. Best Regards Masahiro Yamada On Thu, 24 Apr 2014 10:03:35 +0900 Masahiro Yamada yamad...@jp.panasonic.com wrote: Hi Jerry Van Baren, On Fri, 18 Apr 2014 17:40:56 +0900 Masahiro Yamada yamad...@jp.panasonic.com wrote: Masahiro Yamada (9): fdt_support: delete unnecessary DECLARE_GLOBAL_DATA_PTR fdt_support: refactor with fdt_find_or_add_subnode helper func fdt_support: delete force argument of fdt_initrd() fdt_support: delete force argument of fdt_chosen() fdt_support: refactor fdt_fixup_stdout() function fdt_support: add 'const' qualifier for unchanged argument fdt_support: fix an endian bug of fdt_fixup_memory_banks fdt_support: fix an endian bug of fdt_initrd() fdt_support: correct the return condition of fdt_initrd() I think this series is assigned to you. Could you review it? More than two months have passed since I posted v1. It was dismissed long time and finally it got not applicable. I rebased it and posted v2 but still no comments so far. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- パナソニック（株） システムLSIビジネスユニット 第二事業ディビジョン 開発グループ 第三開発チーム 山田 真弘 yamad...@jp.panasonic.com 〒617-8520 京都府長岡京市神足焼町1番地 外線 : 050-3783-5420 内線 : 7-664-2813, 社内ポスト: 664-772 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv3 00/13] mmc: exynos: code cleanup and support DDR mode
Dear Pantelis Antoniou, On 07/05/14 12:40, Jaehoon Chung wrote: Hi, All. If didn't have any other comment, could you apply this patch? I want to merge this patch at mainline. Best Regards, Jaehoon Chung If you are OK then, I want to pick up this patchset to samsung tree. This patchset has been including samsung related features. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Question] Linux Boot with u-boot 2014.04 on Zynq board
Hi Michal,
Sorry for late reply. (I'm back from my vacations.)
Before you build u-boot you have to copy ps7_init.c/h from your
hw design to the u-boot if you want to use SPL.
Oops, I forgot to mention this.
I did that.
ok. Then I expect you are able to see at least u-boot SPL messages.
Yes. I can see them.
This is what I am getting - u-boot.img has full u-boot.
U-Boot SPL 2014.01-00816-ge0c1813-dirty (Jan 22 2014 - 17:56:37)
mmc boot
reading download.bit
design filename = system.ncd;HW_TIMEOUT=FALSE;UserID=0x
part number = 7z020clg484
date = 2013/07/22
time = 17:18:11
bytes in bitstream = 4045564
zynq_load: Align buffer at 16c to 100(swap 1)
reading system.dtb
spl: error reading image system.dtb, err - -1
reading u-boot.img
reading u-boot.img
U-Boot 2014.01 (Mar 19 2014 - 08:12:51)
Memory: ECC disabled
DRAM: 1 GiB
MMC: zynq_sdhci: 0
SF: Detected N25Q128A with page size 256 Bytes, erase size 64 KiB, total 16
MiB
*** Warning - bad CRC, using default environment
In:serial
Out: serial
Err: serial
Net: Gem.e000b000
U-BOOT for zynq-zc702
Gem.e000b000 Waiting for PHY auto negotiation to complete done
BOOTP broadcast 1
BOOTP broadcast 2
Abort
Hit any key to stop autoboot: 0
U-Boot-PetaLinux
Thanks!
Now I understand how to boot u-boot and Linux.
Full u-boot image of zynq enables CONFIG_OF_SEPARATE, right?
I think u-boot.img does not include device tree.
In mainline yes but I am not using it. It is nice for playing
but it is fine just to disable it and you don't need to use dts at all.
Just disable it in zynq config file.
I am not convinced why unsupported CONFIG_OF_SEPARATE is enabled.
U-boot mainline and u-boot-xlnx diverged with this point.
Which way are you going in your future development?
U-Boot control with device tree? or without device tree?
My question is, how to pass an init ramdisk?
I am using cpio compiled in directly in the kernel.
In which file-name should I copy init ramdisk
into SD card?
Xilinx OSL versions are using initramdisk
which you can download here.
http://www.wiki.xilinx.com/Zynq+2014.1+Release
Yes. I am using this.
ok. Then what are you trying to do? Just use latest u-boot?
Yes.
I want to run U-boot and Linux on a Zynq board.
I also want to use new features in the U-Boot mainline such as Kbuild.
That is my motivation to try to run u-boot-2014.04 on a zynq board.
How should I load the init ramdisk from the SD card?
And this is the command which OSL version are using.
sdboot=if mmcinfo; then \
run uenvboot; \
echo Copying Linux from SD to RAM... \
fatload mmc 0 0x300 ${kernel_image} \
fatload mmc 0 0x2A0 ${devicetree_image} \
fatload mmc 0 0x200 ${ramdisk_image} \
bootm 0x300 0x200 0x2A0; \
fi\0 \
Yes. I know this works.
But in my understanding, SPL cannot use this command.
My question is how SPL can load the init ramdisk.
It looks like spl_load_image_fat_os() function loads
system.dtb and uImage.
But I could not find which code loads ramdisk.
Not supported yet?
yes, I think it is not supported.
I haven't had a time but Simon mentioned that they have
enabled ITS format in SPL and it should be straight forward
to do so. Then you can just use full ITS instead of DTB, kernel, ramdisk
in separate images.
This sounds reasonable!
I am looking forward to it.
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Latest u-boot release on BeagleBone Black for FreeBSD
On 05/04/2014 07:33 PM, Jeroen Hofstee wrote:
Hello Xuebing, (freebsd-arm added on cc),
On di, 2014-04-08 at 16:52 +0800, Xuebing Wang wrote:
Hi u-boot community,
I am trying to port u-boot (release u-boot-2014.04-rc3.tar.bz2) to
FreeBSD on BeagleBone Black.
In FreeBSD, there is a u-boot loader (named ubldr), which can call
u-boot API to get fdt (Flat Device Tree) data.
I have to comment out below 3 lines, in order to get correct fdt data in
FreeBSD ubldr from u-boot. Would you please advice what is the best way
to fix this?
In file common/env_common.c:
const uchar *env_get_addr(int index)
{
// if (gd-env_valid)
// return (uchar *)(gd-env_addr + index);
// else
return default_environment[index];
}
Assuming that you checked that your environment is valid you might be
facing the fact that the gd pointer is corrupted. gd is a pointer to the
global data and used for storing globals which are available before
and after relocation. On (32bit) ARM this value used to be stored in
register r8 but moved to r9 (llvm cannot reserve an arbitrary register,
but can reserve r9 for platform specific usage). If ubldr uses r9 you
end up with a invalid gd pointer when calling back into u-boot. ubldr
now reserves r8 and r9 so a recent version should work fine on an older
U-boot as well as current master.
Can you check the latest ubldr?
Hi Jeroen,
Thanks for your response.
1) Today, I tested ubldr in the snapshot build
FreeBSD-11.0-CURRENT-arm-armv6-BEAGLEBONE-20140428-r265054.img.bz2
without commenting out those 3 lines, I still can not get fdt ls in
ubldr command line.
After commenting out those 3 lines and rebuild u-boot, I can get fdt
ls in ubldr command line.
Note: All my previous test was based on
FreeBSD-11.0-CURRENT-arm-armv6-BEAGLEBONE-20140323-r263665.img.bz2
2) Would you please point to me which revision that reserves both r8 and r9?
Thanks.
Regards,
Jeroen
--
Thanks,
Xuebing Wang
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v12 0/2] S5P: Exynos: Add GPIO numbering feature
On 05/06/2014 04:36 PM, Akshay Saraswat wrote: Used a script to recheck/verify pin mapping and existing mapping appears to be fine, returning correct bank and pin values. Did ./MAKEALL -a arm and found all Exynos/S5P related boards compiled successfully. Couldn't test booting over all of them. Tested U-Boot bootup over SMDK5420, SMDK5250, Snow. Requesting maintaners to please test over affected SoCs/boards. Changes in V2: - Enabled CMD_GPIO as suggested by Simon Glass and supported same for EXYNOS5. Changes in V3: - New patch added to rename S5P GPIO definitions to S5P_GPIO. - GPIO Table added to calculate the base address of input gpio bank. Changes in V4: - To have consistent 0..n-1 GPIO numbering the banks are divided into different parts where ever they have holes in them. - Function and table to support gpio command moved to s5p-gpio driver. - Rebased on latest u-boot-samsung tree. Changes in V5: - Rebased on latest u-boot-samsung tree. - Removed Exynos5 specific code in gpio driver api to get bank. - Added #define HAVE_GENERIC_GPIO in config file to remove conditinal CPU check in gpio driver. Changes in V6: - Isolated config changes in a new patch. - Updated patches with corresponding changes for Exynos 5420. Changes in V7: - Added changes for other SoCs like Exynos 4412, 4210 etc. Changes in V8: - Changed Subject of patch 2/2 to reflect affected SoCs/boards. - Fixed arndale board compile time errors introduced due to patch-set v7. Changes in V9: - Fixed checkpatch errors. - Fixed naming error in exynos_gpio_data arrays which could be the possible reason behind data abort witnessed over Exynos4 boards. Changes in v10: - Made arch-exynos/gpio.h - arch/gpio.h. - Removed dead code. - Replaced exynos_gpio_get calls with corresponding pin number. - Edited pin numbmers in dts files. Changes in v11: - Created and fixed pinmux_config for Exynos 4412. - Removed dead code. Changes in v12: - Added change logs in individual patches. - Fixed few bugs and typos. - Added Acked-by: Przemyslaw Marczak. Akshay Saraswat (2): S5P: Exynos: Add GPIO pin numbering and rename definitions S5P: Exynos: Config: Enable GPIO CMD config arch/arm/cpu/armv7/exynos/pinmux.c | 561 + arch/arm/dts/exynos4210-origen.dts |4 +- arch/arm/dts/exynos4210-trats.dts |6 +- arch/arm/dts/exynos4210-universal_c210.dts |4 +- arch/arm/dts/exynos4412-trats2.dts |4 +- arch/arm/include/asm/arch-exynos/cpu.h | 17 +- arch/arm/include/asm/arch-exynos/gpio.h| 1761 +++- arch/arm/include/asm/arch-s5pc1xx/gpio.h | 948 --- board/samsung/arndale/arndale.c| 11 +- board/samsung/goni/goni.c | 32 +- board/samsung/smdk5250/exynos5-dt.c| 20 +- board/samsung/smdk5250/smdk5250.c | 19 +- board/samsung/smdk5420/smdk5420.c | 15 +- board/samsung/smdkc100/smdkc100.c |5 +- board/samsung/smdkv310/smdkv310.c | 19 +- board/samsung/trats/trats.c| 39 +- board/samsung/trats2/trats2.c | 74 +- board/samsung/universal_c210/universal.c | 51 +- drivers/gpio/s5p_gpio.c| 204 +++- include/configs/exynos5-dt.h |2 + include/configs/s5p_goni.h |4 +- include/configs/s5pc210_universal.h| 16 +- include/configs/smdkv310.h |1 + include/configs/trats.h|8 +- include/configs/trats2.h |4 +- 25 files changed, 2918 insertions(+), 911 deletions(-) Tested on Trats2. Tested-by: Piotr Wilczek p.wilc...@samsung.com Best regards, Piotr Wilczek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
