[U-Boot] [U-Boot, PATCH v3 1/2] arm: BeagleBone Black: enable fastboot support
Enable Android Fastboot support on am335x_evm board Signed-off-by: Dileep Katta dileep.ka...@linaro.org --- Changes in v2: -None Changes in v3: -None include/configs/am335x_evm.h | 10 ++ 1 file changed, 10 insertions(+) diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index 35ae0e6..3999405 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -291,6 +291,11 @@ #define CONFIG_AM335X_USB0_MODEMUSB_PERIPHERAL #define CONFIG_AM335X_USB1 #define CONFIG_AM335X_USB1_MODE MUSB_HOST +/* Fastboot */ +#define CONFIG_CMD_FASTBOOT +#define CONFIG_ANDROID_BOOT_IMAGE +#define CONFIG_USB_FASTBOOT_BUF_ADDR CONFIG_SYS_LOAD_ADDR +#define CONFIG_USB_FASTBOOT_BUF_SIZE 0x0700 #ifdef CONFIG_MUSB_HOST #define CONFIG_CMD_USB @@ -303,8 +308,13 @@ #define CONFIG_USBNET_HOST_ADDRde:ad:be:af:00:00 /* USB TI's IDs */ +#ifdef CONFIG_CMD_FASTBOOT +#define CONFIG_G_DNL_VENDOR_NUM 0x0451 +#define CONFIG_G_DNL_PRODUCT_NUM 0xd022 /* TI fastboot PID */ +#else #define CONFIG_G_DNL_VENDOR_NUM 0x0403 #define CONFIG_G_DNL_PRODUCT_NUM 0xBD00 +#endif #define CONFIG_G_DNL_MANUFACTURER Texas Instruments #endif /* CONFIG_MUSB_GADGET */ -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-Boot, PATCH v3 2/2] fastboot: Flash command support
Flash command internally uses DFU, and Fastboot command initialization is
modified to add DFU and partition initialization
Added oem format functionality for GPT table creation
partitioning code is added as disk/part_fastboot.c for better usability
Fastboot flash command code is enabled and being tested on BeagleBone Black.
OMAP3 Beagle configuration is modified to fix the build errors, but this
configuration needs to be updated as per the flash functionality.
Signed-off-by: Dileep Katta dileep.ka...@linaro.org
---
Changes in v2:
- Fixed coding style issues
Changes in v3:
- Removed unnecessary code and flags as per review comments
common/cmd_fastboot.c | 5 +
common/cmd_mmc.c| 2 +-
common/cmd_nvedit.c | 2 +-
disk/Makefile | 1 +
disk/part_fastboot.c| 379
doc/README.android-fastboot | 26 +++
drivers/usb/gadget/f_fastboot.c | 178 ++-
include/configs/am335x_evm.h| 23 ++-
include/configs/omap3_beagle.h | 12 ++
include/usb/fastboot.h | 182 +++
10 files changed, 796 insertions(+), 14 deletions(-)
create mode 100644 disk/part_fastboot.c
create mode 100644 include/usb/fastboot.h
diff --git a/common/cmd_fastboot.c b/common/cmd_fastboot.c
index 83fa7bd..6d0d0a4 100644
--- a/common/cmd_fastboot.c
+++ b/common/cmd_fastboot.c
@@ -10,11 +10,15 @@
#include common.h
#include command.h
#include g_dnl.h
+#include dfu.h
+#include usb/fastboot.h
static int do_fastboot(cmd_tbl_t *cmdtp, int flag, int argc, char *const
argv[])
{
int ret;
+ board_partition_init();
+ dfu_init_env_entities(mmc, CONFIG_FB_MMCDEV);
ret = g_dnl_register(usb_dnl_fastboot);
if (ret)
return ret;
@@ -26,6 +30,7 @@ static int do_fastboot(cmd_tbl_t *cmdtp, int flag, int argc,
char *const argv[])
}
g_dnl_unregister();
+ dfu_free_entities();
return CMD_RET_SUCCESS;
}
diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
index 1e40983..dd7170d 100644
--- a/common/cmd_mmc.c
+++ b/common/cmd_mmc.c
@@ -612,7 +612,7 @@ static cmd_tbl_t cmd_mmc[] = {
U_BOOT_CMD_MKENT(setdsr, 2, 0, do_mmc_setdsr, , ),
};
-static int do_mmcops(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+int do_mmcops(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
cmd_tbl_t *cp;
diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index 855808c..a100109 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -686,7 +686,7 @@ ulong getenv_ulong(const char *name, int base, ulong
default_val)
#ifndef CONFIG_SPL_BUILD
#if defined(CONFIG_CMD_SAVEENV) !defined(CONFIG_ENV_IS_NOWHERE)
-static int do_env_save(cmd_tbl_t *cmdtp, int flag, int argc,
+int do_env_save(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
{
printf(Saving Environment to %s...\n, env_name_spec);
diff --git a/disk/Makefile b/disk/Makefile
index 6970cec..4b7a9ef 100644
--- a/disk/Makefile
+++ b/disk/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_DOS_PARTITION) += part_dos.o
obj-$(CONFIG_ISO_PARTITION) += part_iso.o
obj-$(CONFIG_AMIGA_PARTITION) += part_amiga.o
obj-$(CONFIG_EFI_PARTITION) += part_efi.o
+obj-$(CONFIG_CMD_FASTBOOT)+= part_fastboot.o
diff --git a/disk/part_fastboot.c b/disk/part_fastboot.c
new file mode 100644
index 000..4fa9f85
--- /dev/null
+++ b/disk/part_fastboot.c
@@ -0,0 +1,379 @@
+/*
+ * Copyright (C) 2013 Texas Instruments
+ *
+ * Author : Pankaj Bharadiya pankaj.bharad...@ti.com
+ *
+ * Tom Rix tom@windriver.com and Sitara 2011 u-boot by
+ * Mohammed Afzal M A af...@ti.com
+ *
+ * Copyright (C) 2008 The Android Open Source Project
+ * All rights reserved.
+ *
+ * Copyright 2014 Linaro, Ltd.
+ * Dileep Katta dileep.ka...@linaro.org
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include command.h
+#include usb/fastboot.h
+#include linux/usb/ch9.h
+#include linux/usb/gadget.h
+#include environment.h
+#include mmc.h
+#include dfu.h
+
+#define EFI_VERSION 0x0001
+#define EFI_ENTRIES 128
+#define EFI_NAMELEN 36
+
+struct partition_emmc {
+ const char *name;
+ unsigned size_kb;
+};
+
+/* eMMC partition layout (All sizes are in kB)
+ * Modify the below partition table to change the GPT configuration.
+ * The entry for each partition can be modified as per the requirement.
+ */
+static struct partition_emmc partitions[] = {
+ { -, 128 }, /* Master Boot Record and GUID Partition Table */
+ { spl, 128 }, /* First stage bootloader */
+ { bootloader, 512 }, /* Second stage bootloader */
+ { misc, 128 },/* Rserved for internal purpose */
+ { -, 128 }, /* Reserved */
+ { recovery, 8*1024 }, /* Recovery partition */
+ { boot, 8*1024 }, /* Partition contains kernel + ramdisk images */
+ {
Re: [U-Boot] [PATCH 2/2 v2] fastboot: Flash command support
On 12 August 2014 01:22, Steve Rae s...@broadcom.com wrote:
On 14-08-10 06:59 PM, Dileep Katta wrote:
Flash command internally uses DFU, and Fastboot command initialization is
modified to add DFU and partition initialization
Added oem format functionality for GPT table creation
partitioning code is added as disk/part_fastboot.c for better usability
Fastboot flash command code is enabled and being tested on BeagleBone
Black.
OMAP3 Beagle configuration is modified to fix the build errors, but this
configuration needs to be updated as per the flash functionality.
Signed-off-by: Dileep Katta dileep.ka...@linaro.org
---
Changes for v2:
- Fixed coding style issues
common/cmd_fastboot.c | 5 +
common/cmd_mmc.c| 2 +-
common/cmd_nvedit.c | 2 +-
disk/Makefile | 1 +
disk/part_fastboot.c| 379 ++
++
doc/README.android-fastboot | 26 +++
drivers/usb/gadget/f_fastboot.c | 178 ++-
include/configs/am335x_evm.h| 23 ++-
include/configs/omap3_beagle.h | 12 ++
include/usb/fastboot.h | 182 +++
10 files changed, 796 insertions(+), 14 deletions(-)
create mode 100644 disk/part_fastboot.c
create mode 100644 include/usb/fastboot.h
diff --git a/common/cmd_fastboot.c b/common/cmd_fastboot.c
index 83fa7bd..6d0d0a4 100644
--- a/common/cmd_fastboot.c
+++ b/common/cmd_fastboot.c
@@ -10,11 +10,15 @@
#include common.h
#include command.h
#include g_dnl.h
+#include dfu.h
+#include usb/fastboot.h
static int do_fastboot(cmd_tbl_t *cmdtp, int flag, int argc, char
*const argv[])
{
int ret;
+ board_partition_init();
+ dfu_init_env_entities(mmc, CONFIG_FB_MMCDEV);
ret = g_dnl_register(usb_dnl_fastboot);
if (ret)
return ret;
@@ -26,6 +30,7 @@ static int do_fastboot(cmd_tbl_t *cmdtp, int flag, int
argc, char *const argv[])
}
g_dnl_unregister();
+ dfu_free_entities();
return CMD_RET_SUCCESS;
}
diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
index 1e40983..dd7170d 100644
--- a/common/cmd_mmc.c
+++ b/common/cmd_mmc.c
@@ -612,7 +612,7 @@ static cmd_tbl_t cmd_mmc[] = {
U_BOOT_CMD_MKENT(setdsr, 2, 0, do_mmc_setdsr, , ),
};
-static int do_mmcops(cmd_tbl_t *cmdtp, int flag, int argc, char * const
argv[])
+int do_mmcops(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
cmd_tbl_t *cp;
diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index 855808c..a100109 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -686,7 +686,7 @@ ulong getenv_ulong(const char *name, int base, ulong
default_val)
#ifndef CONFIG_SPL_BUILD
#if defined(CONFIG_CMD_SAVEENV) !defined(CONFIG_ENV_IS_NOWHERE)
-static int do_env_save(cmd_tbl_t *cmdtp, int flag, int argc,
+int do_env_save(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
{
printf(Saving Environment to %s...\n, env_name_spec);
diff --git a/disk/Makefile b/disk/Makefile
index 6970cec..4b7a9ef 100644
--- a/disk/Makefile
+++ b/disk/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_DOS_PARTITION) += part_dos.o
obj-$(CONFIG_ISO_PARTITION) += part_iso.o
obj-$(CONFIG_AMIGA_PARTITION) += part_amiga.o
obj-$(CONFIG_EFI_PARTITION) += part_efi.o
+obj-$(CONFIG_CMD_FASTBOOT)+= part_fastboot.o
diff --git a/disk/part_fastboot.c b/disk/part_fastboot.c
new file mode 100644
index 000..4fa9f85
--- /dev/null
+++ b/disk/part_fastboot.c
@@ -0,0 +1,379 @@
+/*
+ * Copyright (C) 2013 Texas Instruments
+ *
+ * Author : Pankaj Bharadiya pankaj.bharad...@ti.com
+ *
+ * Tom Rix tom@windriver.com and Sitara 2011 u-boot by
+ * Mohammed Afzal M A af...@ti.com
+ *
+ * Copyright (C) 2008 The Android Open Source Project
+ * All rights reserved.
+ *
+ * Copyright 2014 Linaro, Ltd.
+ * Dileep Katta dileep.ka...@linaro.org
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include command.h
+#include usb/fastboot.h
+#include linux/usb/ch9.h
+#include linux/usb/gadget.h
+#include environment.h
+#include mmc.h
+#include dfu.h
+
+#define EFI_VERSION 0x0001
+#define EFI_ENTRIES 128
+#define EFI_NAMELEN 36
+
+struct partition_emmc {
+ const char *name;
+ unsigned size_kb;
+};
+
+/* eMMC partition layout (All sizes are in kB)
+ * Modify the below partition table to change the GPT configuration.
+ * The entry for each partition can be modified as per the requirement.
+ */
+static struct partition_emmc partitions[] = {
+ { -, 128 }, /* Master Boot Record and GUID Partition Table */
+ { spl, 128 }, /* First stage bootloader */
+ { bootloader, 512 }, /* Second stage bootloader */
+ { misc, 128 },/* Rserved for internal purpose */
+ { -, 128 },
[U-Boot] [Uboot 2012.10] AMCC's Riviera (PowerPC) linking .bss section at 0x10?
Hi,
I know uboot 2012 is quite old but I’m quite confused here.
I’m trying to move the code for n4310 board (which similar to riviera) from
uboot 2009 to uboot 2012.10. The linker script for uboot-ocm for n4310 was
copied from riviera’s one. In riviera ocm linker script, I noticed that
.bss is intended to placed at 0x10 which cause my code hang when it try to
access some uninitialized global variables in .bss section before
initializing RAM as uboot can only access the last 4KB of 32-bit address
(0x f000 - 0x ) before RAM has been initialized.
In uboot 2009 ocm linker script, .bss section was placed right after .data
section (both in this 4KB) (you can see the diff at the end of this mail)
Now, I can fix this problem by moving .bss section in this linker script up
before some assignment which will move location counter to 0x10, and place
.bss right after .data section .Then,my code can run without any problems
but I still want to know does uboot intend to move .bss section to 0x10?
Could anyone please explain this for me or show me where I can find this
information (I have searched through mailing list for a while but couldn’t
find any clues).
Thank you very much.
Best regards,
Here is the diff for this section in uboot-ocm.lds
git diff uboot/board/amcc/riviera/u-boot-ocm.lds
uboot_2012.10/board/amcc/riviera/u-boot-ocm.lds
_edata = .;
PROVIDE (edata = .);
@@ -118,7 +85,6 @@ SECTIONS
.u_boot_cmd : { *(.u_boot_cmd) }
__u_boot_cmd_end = .;
-
. = .;
__start___ex_table = .;
__ex_table : { *(__ex_table) }
@@ -131,15 +97,52 @@ SECTIONS
. = ALIGN(256);
__init_end = .;
+#ifdef CONFIG_440+ .bootpg RESET_VECTOR_ADDRESS - 0xffc :+ {+
arch/powerpc/cpu/ppc4xx/start.o(.bootpg)++/*+ * PPC440
board need a board specific object with the+ * TLB definitions.
This needs to get included right after+ * start.o, since the first
shadow TLB only covers 4k+ * of address space.+ */+#ifdef
CONFIG_INIT_TLB+CONFIG_INIT_TLB (.bootpg)+#else+
CONFIG_BOARDDIR/init.o (.bootpg)+#endif+ } :text =
0x+#endif++ .resetvec RESET_VECTOR_ADDRESS :+ {+
KEEP(*(.resetvec))+ } :text = 0x++ . = RESET_VECTOR_ADDRESS +
0x4;+
++ /*+ * Make sure that the bss segment isn't linked at 0x0,
otherwise its+ * address won't be updated during relocation fixups.
Note that+ * this is a temporary fix. Code to dynamically the fixup
the bss+ * location will be added in the future. When the bss
relocation+ * fixup code is present this workaround should be
removed.+ */+#if (RESET_VECTOR_ADDRESS == 0xfffc)+ . |=
0x10;+#endif+
__bss_start = .;- .bss :+ .bss (NOLOAD) :
{- *(.sbss) *(.scommon)- *(.dynbss)- *(.bss)+ *(.bss*)+ *(.sbss*)
*(COMMON)- . = ALIGN(4);- }- _end = . ;+ } :bss++ . =
ALIGN(4);+ __bss_end__ = . ;
PROVIDE (end = .);
}
/**
- @Name: Phạm Hữu Đăng Nhật
- @StudentID: 51002279
- @Class: MT10KTTN
- Ho Chi Minh University of Technology
- @Mobile: 0164.968.2716
*/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 09/10] kconfig: move CONFIG_OF_* to Kconfig
Hi, On 09/09/2014 12:44 PM, Akshay Saraswat wrote: Hi Masahiro, Hi Samsung developers, Simon Glass, 2014-09-09 1:10 GMT+09:00 Masahiro YAMADA : Hi Stephen, 2014-09-09 0:58 GMT+09:00 Stephen Warren : On 09/08/2014 09:57 AM, Masahiro YAMADA wrote: Hi Stephen, 2014-09-09 0:04 GMT+09:00 Stephen Warren : I don't believe this is the correct approach; CONFIG_OF_CONTROL isn't a user-configurable option, and hence shouldn't show up in *_defconfig. select OF_CONTROL in a Kconfig file probably makes sense though. I think it depends on the board (SoC). In my understanding, Zynq boards should work with/without Device Tree control. (Moreover, Zynq boards work with/without SPL) At least as for Zynq, CONFIG_OF_CONTROL ( and CONFIG_SPL too) is a user-configurable option. (Michal, please correct me if I am wrong.) I am not familiar with Tegra SoCs, but do Tegra boards always Device Tree? ( and only work with SPL ?) If so, config TEGRA select SPL select OF_CONTROL looks better? That looks correct for Tegra. OK. I will send v2. CONFIG_OF_CONTROL in tegra defconfigs will go away. (BTW, I forgot to mention a famous board; beaglebone black. am335_boneblack_defconfig disables CONFIG_OF_CONTROL, whereas am335_boneblack_vboot_defconfig enables it. ) Before posting v2 of this series, please let me ask the same question on Exynos and Sandbox Do Exynos boards always need Device Tree to run U-Boot? (that is, CONFIG_OF_CONTROL must be selected.) Yes, all Exynos5 boards need Device Tree to run U-Boot. In case of Snow and Pit, we use U-Boot's DTB to extract corresponding Kernel DTB. Also, we do check (#ifdef) CONFIG_OF_CONTROL to enable some features and IPs. I am not sure about Exynos4 but I can see CONFIG_OF_LIBFDT in their config files. I knew Exynos4/5 are supported the Device-tree, but older Samsung SoCs isn't supported it. Best Regards, Jaehoon Chung or Do they work with/without Device Tree? (that is, users can enable/disable via make menuconfig or friends.) What about Sandbox? Best Regards Masahiro Yamada Regards, Akshay Saraswat ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] am335x_evm: Add boot script support to am335x_evm
This patch adds boot script support to am335x_evm
Signed-off-by: Guillaume GARDET guillaume.gar...@free.fr
Cc: Tom Rini tr...@ti.com
---
include/configs/am335x_evm.h | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index df1a6fc..aef0ad3 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -115,6 +115,9 @@
nfsroot=${serverip}:${rootpath},${nfsopts} rw \
ip=dhcp\0 \
bootenv=uEnv.txt\0 \
+ loadbootscript=load mmc ${mmcdev} ${loadaddr} boot.scr\0 \
+ bootscript=echo Running bootscript from mmc${mmcdev} ...; \
+ source ${loadaddr}\0 \
loadbootenv=load mmc ${mmcdev} ${loadaddr} ${bootenv}\0 \
importbootenv=echo Importing environment from mmc ...; \
env import -t -r $loadaddr $filesize\0 \
@@ -142,17 +145,21 @@
mmcboot=mmc dev ${mmcdev}; \
if mmc rescan; then \
echo SD/MMC found on device ${mmcdev}; \
- if run loadbootenv; then \
- echo Loaded environment from ${bootenv}; \
- run importbootenv; \
- fi; \
- if test -n $uenvcmd; then \
- echo Running uenvcmd ...; \
- run uenvcmd; \
- fi; \
- if run loadimage; then \
- run mmcloados; \
- fi; \
+ if run loadbootscript; then \
+ run bootscript; \
+ else \
+ if run loadbootenv; then \
+ echo Loaded environment from
${bootenv}; \
+ run importbootenv; \
+ fi; \
+ if test -n $uenvcmd; then \
+ echo Running uenvcmd ...; \
+ run uenvcmd; \
+ fi; \
+ if run loadimage; then \
+ run mmcloados; \
+ fi; \
+ fi ; \
fi;\0 \
spiboot=echo Booting from spi ...; \
run spiargs; \
--
1.8.4.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] odroid: set MPLL clock to 880MHz
Hi Jaehoon, Hi, On 09/11/2014 02:03 PM, Minkyu Kang wrote: On 05/09/14 19:50, Przemyslaw Marczak wrote: Hello Minkyu, On 09/05/2014 08:55 AM, Minkyu Kang wrote: On 24/07/14 19:42, Przemyslaw Marczak wrote: This patch changes MPLL from 800MHz to 880MHz on Odroid. Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com --- board/samsung/odroid/odroid.c | 60 +-- 1 file changed, 30 insertions(+), 30 deletions(-) applied to u-boot-samsung. Thanks, Minkyu Kang. Thank you for applying the Odroid patch set. I would like to note, that this one patch was intended for MR. Daniel just for his tests. This patch breaks dw mmc performance: e.g. eMMC uImage(fat) read performance: - before this commit: 47.6 MiB/s - after this commit: 13.0 MiB/s So this requires some more changes in clocks and also in dw mmc driver. MPLL is used to the eMMC's source clock. If MPLL is changed to 880MHz, then eMMC's clock should not be set to correct value. It has to test before changed MPLL clock. otherwise, we need to use other source clock. Yes, correct. But for now this patch introduces considerable performance regression. Moreover, as Przemek had written it down to Minkyu, this patch was supposed solely for Daniel's private usage and shouldn't be applied to u-boot main line. Hence I'd like to ask for removing this patch from the pull request sent to Albert. Best Regards, Jaehoon Chung And it can break some kernel clocks divider dependencies. It is not tested. So please revert this patch. Best Regards, reverted.. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- 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 5/8] config: Move arndale to use common exynos5250 file
Dear Simon Glass, On 23/07/14 21:11, Simon Glass wrote: Most of the arndale features are common with other exynos5250 boards. To permit easier addition of driver model support, use the common file. Signed-off-by: Simon Glass s...@chromium.org --- include/configs/arndale.h | 212 +++--- 1 file changed, 14 insertions(+), 198 deletions(-) diff --git a/include/configs/arndale.h b/include/configs/arndale.h index 370db82..1f0bec9 100644 --- a/include/configs/arndale.h +++ b/include/configs/arndale.h @@ -9,219 +9,55 @@ #ifndef __CONFIG_ARNDALE_H #define __CONFIG_ARNDALE_H -/* High Level Configuration Options */ -#define CONFIG_SAMSUNG /* in a SAMSUNG core */ -#define CONFIG_S5P /* S5P Family */ -#define CONFIG_EXYNOS5 /* which is in a Exynos5 Family */ -#define CONFIG_EXYNOS5250 - -#include asm/arch/cpu.h/* get chip and board defs */ - -#define CONFIG_SYS_GENERIC_BOARD -#define CONFIG_ARCH_CPU_INIT -#define CONFIG_DISPLAY_CPUINFO -#define CONFIG_DISPLAY_BOARDINFO - -#define CONFIG_OF_CONTROL -#define CONFIG_OF_SEPARATE - -/* Allow tracing to be enabled */ -#define CONFIG_TRACE -#define CONFIG_CMD_TRACE -#define CONFIG_TRACE_BUFFER_SIZE (16 20) -#define CONFIG_TRACE_EARLY_SIZE (8 20) -#define CONFIG_TRACE_EARLY -#define CONFIG_TRACE_EARLY_ADDR 0x5000 - -/* Keep L2 Cache Disabled */ -#define CONFIG_SYS_DCACHE_OFF - -#define CONFIG_SYS_SDRAM_BASE0x4000 -#define CONFIG_SYS_TEXT_BASE 0x43E0 - -/* input clock of PLL: SMDK5250 has 24MHz input clock */ -#define CONFIG_SYS_CLK_FREQ 2400 - -#define CONFIG_SETUP_MEMORY_TAGS -#define CONFIG_CMDLINE_TAG -#define CONFIG_INITRD_TAG -#define CONFIG_CMDLINE_EDITING - -/* Power Down Modes */ -#define S5P_CHECK_SLEEP 0x0BAD -#define S5P_CHECK_DIDLE 0xBAD0 -#define S5P_CHECK_LPA0xABAD - -/* Offset for inform registers */ -#define INFORM0_OFFSET 0x800 -#define INFORM1_OFFSET 0x804 - -/* Size of malloc() pool */ -#define CONFIG_SYS_MALLOC_LEN(CONFIG_ENV_SIZE + (4 20)) - -/* select serial console configuration */ -#define CONFIG_BAUDRATE 115200 -#define EXYNOS5_DEFAULT_UART_OFFSET 0x01 -#define CONFIG_SILENT_CONSOLE - -/* Console configuration */ -#define CONFIG_CONSOLE_MUX -#define CONFIG_SYS_CONSOLE_IS_IN_ENV -#define EXYNOS_DEVICE_SETTINGS \ - stdin=serial\0 \ - stdout=serial\0 \ - stderr=serial\0 - -#define CONFIG_EXTRA_ENV_SETTINGS \ - EXYNOS_DEVICE_SETTINGS +#include exynos5250-common.h + +#undef CONFIG_BOARD_COMMON +#undef CONFIG_ARCH_EARLY_INIT_R /* SD/MMC configuration */ -#define CONFIG_GENERIC_MMC -#define CONFIG_MMC -#define CONFIG_SDHCI -#define CONFIG_S5P_SDHCI -#define CONFIG_DWMMC -#define CONFIG_EXYNOS_DWMMC #define CONFIG_SUPPORT_EMMC_BOOT -#define CONFIG_BOUNCE_BUFFER - - -#define CONFIG_BOARD_EARLY_INIT_F -#define CONFIG_SKIP_LOWLEVEL_INIT - -/* PWM */ -#define CONFIG_PWM /* allow to overwrite serial and ethaddr */ #define CONFIG_ENV_OVERWRITE -/* Command definition*/ -#include config_cmd_default.h - -#define CONFIG_CMD_PING -#define CONFIG_CMD_ELF -#define CONFIG_CMD_MMC #define CONFIG_CMD_EXT2 -#define CONFIG_CMD_FAT -#define CONFIG_CMD_NET -#define CONFIG_CMD_HASH - -#define CONFIG_BOOTDELAY 3 -#define CONFIG_ZERO_BOOTDELAY_CHECK /* USB */ -#define CONFIG_CMD_USB +#undef CONFIG_USB_XHCI +#undef CONFIG_USB_XHCI_EXYNOS #define CONFIG_USB_EHCI #define CONFIG_USB_EHCI_EXYNOS -#define CONFIG_USB_STORAGE +#undef CONFIG_SYS_USB_XHCI_MAX_ROOT_PORTS #define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 3 #define CONFIG_USB_HOST_ETHER #define CONFIG_USB_ETHER_ASIX /* MMC SPL */ #define CONFIG_EXYNOS_SPL -#define CONFIG_SPL -#define COPY_BL2_FNPTR_ADDR 0x02020030 - -#define CONFIG_SPL_LIBCOMMON_SUPPORT - -/* specific .lds file */ -#define CONFIG_SPL_LDSCRIPT board/samsung/common/exynos-uboot-spl.lds -#define CONFIG_SPL_TEXT_BASE 0x02023400 -#define CONFIG_SPL_MAX_FOOTPRINT (14 * 1024) - -#define CONFIG_BOOTCOMMAND mmc read 40007000 451 2000; bootm 40007000 /* Miscellaneous configurable options */ -#define CONFIG_SYS_LONGHELP /* undef to save memory */ -#define CONFIG_SYS_HUSH_PARSER /* use hush command parser */ +#undef CONFIG_SYS_PROMPT #define CONFIG_SYS_PROMPTARNDALE # -#define CONFIG_SYS_CBSIZE256 /* Console I/O Buffer Size */ -#define CONFIG_SYS_PBSIZE384 /* Print Buffer Size */ -#define CONFIG_SYS_MAXARGS 16 /* max number of command args */ +#undef CONFIG_DEFAULT_CONSOLE #define
Re: [U-Boot] [PATCH 3/8] exynos: Move common smdk5420 things to common file
Dear Simon Glass,
On 23/07/14 21:11, Simon Glass wrote:
A few things are common but are not in the common file. Fix this and
rename the file to fit with the other exynos*-common files.
Signed-off-by: Simon Glass s...@chromium.org
---
include/configs/{exynos5420.h = exynos5420-common.h} | 11 ++-
include/configs/peach-pit.h | 7 +--
include/configs/smdk5420.h| 7 +--
3 files changed, 8 insertions(+), 17 deletions(-)
rename include/configs/{exynos5420.h = exynos5420-common.h} (88%)
diff --git a/include/configs/exynos5420.h
b/include/configs/exynos5420-common.h
similarity index 88%
rename from include/configs/exynos5420.h
rename to include/configs/exynos5420-common.h
index d2a9556..685f9c1 100644
--- a/include/configs/exynos5420.h
+++ b/include/configs/exynos5420-common.h
@@ -9,7 +9,9 @@
#ifndef __CONFIG_EXYNOS5420_H
#define __CONFIG_EXYNOS5420_H
-#define CONFIG_EXYNOS5420/* which is in a Exynos5 Family */
+#define CONFIG_EXYNOS5420
+
+#include configs/exynos5-common.h
#define MACH_TYPE_SMDK5420 8002
#define CONFIG_MACH_TYPE MACH_TYPE_SMDK5420
@@ -31,10 +33,6 @@
#define CONFIG_MAX_I2C_NUM 11
-/* Enable FIT support and comparison */
-#define CONFIG_FIT
-#define CONFIG_FIT_BEST_MATCH
-
#define CONFIG_BOARD_REV_GPIO_COUNT 2
#define CONFIG_BOOTCOMMAND mmc read 20007000 451 2000; bootm 20007000
@@ -49,4 +47,7 @@
#define CONFIG_NR_DRAM_BANKS 7
#define SDRAM_BANK_SIZE (512UL 20UL) /* 512 MB */
+/* select serial console configuration */
+#define CONFIG_SERIAL3 /* use SERIAL 3 */
I think it's a board specific feature.
+
#endif /* __CONFIG_EXYNOS5420_H */
diff --git a/include/configs/peach-pit.h b/include/configs/peach-pit.h
index 59192e1..407f10f 100644
--- a/include/configs/peach-pit.h
+++ b/include/configs/peach-pit.h
@@ -9,16 +9,11 @@
#ifndef __CONFIG_PEACH_PIT_H
#define __CONFIG_PEACH_PIT_H
-#include configs/exynos5-common.h
-
-#include configs/exynos5420.h
+#include configs/exynos5420-common.h
#undef CONFIG_DEFAULT_DEVICE_TREE
#define CONFIG_DEFAULT_DEVICE_TREE exynos5420-peach-pit
-/* select serial console configuration */
-#define CONFIG_SERIAL3 /* use SERIAL 3 */
-
#define CONFIG_SYS_PROMPTPeach #
#define CONFIG_IDENT_STRING for Peach
diff --git a/include/configs/smdk5420.h b/include/configs/smdk5420.h
index 43c9808..83abc13 100644
--- a/include/configs/smdk5420.h
+++ b/include/configs/smdk5420.h
@@ -9,18 +9,13 @@
#ifndef __CONFIG_SMDK5420_H
#define __CONFIG_SMDK5420_H
-#include configs/exynos5-common.h
-
-#include configs/exynos5420.h
+#include configs/exynos5420-common.h
#define CONFIG_SMDK5420 /* which is in a SMDK5420 */
#undef CONFIG_DEFAULT_DEVICE_TREE
#define CONFIG_DEFAULT_DEVICE_TREE exynos5420-smdk5420
-/* select serial console configuration */
-#define CONFIG_SERIAL3 /* use SERIAL 3 */
-
#define CONFIG_SYS_PROMPTSMDK5420 #
#define CONFIG_IDENT_STRING for SMDK5420
Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
Dear Michal, In message 54112b64.5010...@monstr.eu you wrote: I am not sure if you need to have separate repo to work like this. I am keeping zynq patches in my microblaze repo and sending pull request to Albert (or Tom now) and there is no problem with that. Well, technically of course this works, but it is far from perfect. It works only for those who actually know about this. But anybody looking at the U-Boot site for any zynq related stuff will have hard times to find it. I think it is much better to make this knowledge public information - and one easy way to do this is to have a separate repository for it, which is listed on the custodians page, so everybody looking for it will find all relevant information. In socfpga case I think there are guys from Altera who maintain it. Well, they maintain the stuff at rocketboards.org ; there are efforts on the way to mainline stuff, but the process is not exactly satisfactory. I highly appreciate that Marek volunteers to put efforts in this. As far as I am concerned, I support both Marek's and Masahiro's requests. @ Marek and Masahiro: if we reach an agreement to create such repos, please send me your SSH public keys that shall be used for these. Also, what should the names be - u-boot-socfpga ? And u-boot-uniphier ? [But is there not a chance that Pana- sonic might have other SoCs that might be mainlines? So maybe we should use u-boot-panasonic instead?] 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 Laughter and tears are meant to turn the wheels of the same machinery of sensibility; one is wind-power, and the other water-power. - Oliver Wendell Holmes, Sr. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
Hi! In socfpga case I think there are guys from Altera who maintain it. Well, they maintain the stuff at rocketboards.org ; there are efforts on the way to mainline stuff, but the process is not exactly satisfactory. I highly appreciate that Marek volunteers to put efforts in this. As far as I am concerned, I support both Marek's and Masahiro's requests. Repository for socfpga work is a good idea, thanks. One person I have in my email lists is Charles Manning -- he did preloader work before, I put him into cc list. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, PATCH v3 2/2] fastboot: Flash command support
Dear Dileep Katta,
In message 1410417650-16522-2-git-send-email-dileep.ka...@linaro.org you
wrote:
Flash command internally uses DFU, and Fastboot command initialization is
modified to add DFU and partition initialization
Added oem format functionality for GPT table creation
partitioning code is added as disk/part_fastboot.c for better usability
Fastboot flash command code is enabled and being tested on BeagleBone Black.
OMAP3 Beagle configuration is modified to fix the build errors, but this
configuration needs to be updated as per the flash functionality.
Please fix the line length in the commit message.
Also, checkpatch says:
WARNING: do not add new typedefs
#1073: FILE: include/usb/fastboot.h:98:
+typedef struct fastboot_ptentry fastboot_ptentry;
+int handle_flash(char *part_name, char *response, char *transfer_buffer)
+{
+ int status = 0;
+ printf(download_bytes: 0x%x\n, download_bytes);
+ if (download_bytes) {
+ struct fastboot_ptentry *ptn;
+
+ /* Next is the partition name */
+ ptn = fastboot_flash_find_ptn(part_name);
+
+ if (ptn == 0) {
+ printf(Partition:[%s] does not exist\n, part_name);
+ sprintf(response, FAILpartition does not exist);
+ } else if ((download_bytes ptn-length)
+ !(ptn-flags FASTBOOT_PTENTRY_FLAGS_WRITE_ENV)) {
+ printf(Image too large for the partition\n);
+ sprintf(response, FAILimage too large for partition);
+ } else if (ptn-flags FASTBOOT_PTENTRY_FLAGS_WRITE_ENV) {
+ /* Check if this is not really a flash write,
+ * but instead a saveenv
+ */
+ unsigned int i = 0;
+ /* Env file is expected with a NULL delimeter between
+ * env variables So replace New line Feeds(0x0a) with
+ * NULL (0x00)
+ */
Incorrect multiline comment style. Please fix globally.
Also this sequence of comment - declaration - comment is highly
confusing. What is the first comment (Check if..) actually related
to?
+ for (i = 0; i download_bytes; i++) {
+ if (transfer_buffer[i] == 0x0a)
+ transfer_buffer[i] = 0x00;
+ }
+ memset(env_ptr-data, 0, ENV_SIZE);
+ memcpy(env_ptr-data, transfer_buffer, download_bytes);
+ do_env_save(NULL, 0, 1, NULL);
+ printf(saveenv to '%s' DONE!\n, ptn-name);
I think it is a bad idea to split formatting / reformatting
envrionment data alll over the place. This should be done only once,
in the environment handling code. Also, I do not like you using
do_env_save() here - this should remain a static function. Why do't
you simply use saveenv() here?
Finally, the saveenv to '%s' DONE!\n is IMO too verbose. No news is
Good News - we usually do not report abot the success of operations,
as this is what we expect. We should only print error messages when
such occur - which points out another problem of that code: there is
no error checking nor handling there...
+static void end_ptbl(struct ptable *ptbl)
+{
+ struct efi_header *hdr = ptbl-header;
+ u32 n;
+
+ n = crc32(0, 0, 0);
What exactly is this good for?
+ n = crc32(n, (void *)ptbl-entry, sizeof(ptbl-entry));
+ hdr-entries_crc32 = n;
+
+ n = crc32(0, 0, 0);
What exactly is this good for?
+ n = crc32(0, (void *)ptbl-header, sizeof(ptbl-header));
+ hdr-crc32 = n;
+}
+ for (n = 0; n (128/4); n++) {
+ /* read partition */
+ source[0] = '\0';
+ dest[0] = '\0';
+ length[0] = '\0';
You overwrite source, dest, and length by the sprintf()s just a few
lines below. So why are you doing this here?
+ mmc_read[2] = source;
+ mmc_read[3] = dest;
+ mmc_read[4] = length;
+
+ sprintf(source, %p, entry);
+ sprintf(dest, 0x%x, 0x1+n);
+ sprintf(length, 0x%x, 1);
+int board_mmc_fbtptn_init(void)
+{
+ char *mmc_init[2] = {mmc, rescan,};
+ char dev[2];
+ char *mmc_dev[3] = {mmc, dev, NULL};
+
+ mmc_dev[2] = dev;
Why do you initialize mmc_dev[2] with another value just a line
above? Why don't you use the correct value right from the beginning?
+ if (do_mmcops(NULL, 0, 3, mmc_dev)) {
+ printf(MMC DEV: %d selection FAILED!\n, CONFIG_FB_MMCDEV);
+ return -1;
+ }
+
+ if (do_mmcops(NULL, 0, 2, mmc_init)) {
+ printf(FAIL:Init of MMC card\n);
+ return 1;
+ }
What exactly are your return codes? Here you return -1 in case of
error, there +1 -
Re: [U-Boot] [PATCH v2] README.imximage: Fix the maximum DCD size
Hi Fabio, On 09/09/2014 17:37, Fabio Estevam wrote: In commit 021e79c85371 (tools: imximage: Fix the maximum DCD size for mx53/mx6) we have fixed the maximum DCD size for mx53/mx6. Do the same on the README document for consistency. Reported-by: Jonas Karlsson jonas.d.karls...@gmail.com Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/8] add clang support for some ARM boards
Hi Jeroen, On Wed, 10 Sep 2014 20:08:50 +0200, Jeroen Hofstee jer...@myspectrum.nl wrote: Changes since v2: - As Albert pointed out the clang instructions don't work with Debian based binary packages. While I was aware of that it is for a different reason then I thought, it is not that ARM is not enabled as a backend but older versions are a bit more picky on the target argument and don't tolerate a trailing dash to it as used for CROSS_COMPILE etc. The README is updated accordingly. As a side note clang3.5-svn as shipped in Ubuntu is not the 3.5 release but an snapshot of some svn commit and hence explain why the recompiled 3.5 can behave different then the ubuntu clang-3.5. Since it misses some patches, the clang3.5-svn can build less boards then 3.4 or an actual 3.5 release. - While add it, include Masahiro suggestion to also use c++ instead of g++. - Drop dependencies from the cover-letter as they are merged. - only patch 7/8 and 8/8 are reposted. 1..6 are the same as v2. Thanks, tested building rpi_b, it works now. The, tested on versatileqemu out of curiosity and got the following results: 1. clang warns about Unused static functions in common/console.c, namely console_printdevs and console_doenv (1). Why gcc does not flag this? We have -Wall set which is supposed to imply -Wunused-functions. There is also an unused variable warning in disk/part.c28 (block_drvr). I haven't looked at why clang warns about it and not gcc, but it could raise the same question as the functions above. 2. clang errors on arch/arm/lib/cache.c:28 for this: asm(0: mrc p15, 0, r15, c7, c10, 3\n\t bne 0b\n : : : memory); and that is a clang mistake, as for ARM926EJS r15 is a valid (albeit quite special semantically) Rd for Test and Clean DCache, see page 2-24. Jeroen, do you feel like raising point 2 to the clang/LLVM folks? (1) and BTW it's not like the functions are used in some configuration other than versatileqemu; they're completely unused. Other than that, the patch series seems to be good. I'll apply it soonish. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] usb: eth: add ASIX AX88179 DRIVER
Am 10.09.2014 17:00, schrieb Marek Vasut:
On Wednesday, September 10, 2014 at 12:00:29 PM, René Griessl wrote:
Am 09.09.2014 16:34, schrieb Marek Vasut:
On Wednesday, September 03, 2014 at 04:31:20 PM, Rene Griessl wrote:
changes in v2:
-added usb_ether.h to change list
-added 2nd patch to enable driver for arndale board
Signed-off-by: Rene Griessl rgrie...@cit-ec.uni-bielefeld.de
I see that in Linux, there is asix_common.c stuff. Can this driver share
any parts with drivers/net/ax88* ?
The asix_common.c includes asix.h. There you see that the common driver
supports following devices:
AX88172
AX88772
AX88178
but it is not supporting AX88179 and AX88178a, they have a separate
driver called ax88179_178a.c
These two have a different style in accessing MAC registers and PHY
I didn't look deep enough. The 88179 driver is a completely separate driver, not
sharing any code what-so-ever with the other ASIX driver, yes ?
The USB read and write cmd functions are similar and the probe function
is the same. So they are
sharing 6% of code.
What do you have in mind? Do you want to build one driver supporting all
devices?
[...]
+ buf[0], buf[1], buf[2], buf[3], buf[4], buf[5]);
+ }
+ else {
+ }
Uh, this check needs some rework, right ? Also, you want to lint your
patches with ./scripts/checkpatch.pl tool before resubmitting.
was OK for ./scripts/checkpatch.pl
but I can change that
This is rather surprising, but you're right. Please fix this up, the else can be
dropped and the trailing } can be indented just under the if () clause.
OK
+ return ret;
+}
+
+
+static int asix_read_mac(struct eth_device *eth)
+{
+ struct ueth_data *dev = (struct ueth_data *)eth-priv;
+ ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buf, ETH_ALEN);
+
+ if (dev-pusb_dev-descriptor.idProduct == 0x1790) {
+ asix_read_cmd(dev, AX_ACCESS_MAC, 0x10, 6, 6, buf);
+ debug(asix_read_mac() returning 0x%02x%02x%02x%02x%02x%02x\n,
+ buf[0], buf[1], buf[2], buf[3], buf[4], buf[5]);
+ memcpy(eth-enetaddr, buf, ETH_ALEN);
+ }
Same here.
+ return 0;
+}
+
+
+
+static int asix_basic_reset(struct ueth_data *dev)
+{
+ ALLOC_CACHE_ALIGN_BUFFER(u8, buf, 6);
Why does the buffer need to be aligned here ? It's just a buffer that is
not used for DMA, no ?
+ u16 *tmp16;
Is it because you were getting unaligned accesses , since when the buffer
itself was not aligned and you did cast it to u16, the CPU triggered
unaligned access ?
Thats right, if I do not align I get unaligned accesses during USB
communication.
Is there a smarter solution for that?
Oh I see. The smart solution would be to add bounce buffer into the USB stack,
but unless you want to dive into this, this solution would be OK here.
OK, then I will leave it this way.
--
Dipl.-Ing. René Griessl
Universität Bielefeld
AG Kognitronik Sensorik
Exzellenzcluster Cognitive Interaction Technology (CITEC)
Inspiration 1 (Zehlendorfer Damm 199)
33615 Bielefeld
Telefon : +49 521-106-67362
Fax : +49 521-106-12348
eMail : rgrie...@cit-ec.uni-bielefeld.de
Internet: http://www.ks.cit-ec.uni-bielefeld.de/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v3] Add i.MX6 CPU temperature sensor support
Hi Nitin,
On 02/09/2014 00:48, nitin.g...@freescale.com wrote:
From: Nitin Garg nitin.g...@freescale.com
i.MX6 SoC has onChip temperature sensor. Add support
for this sensor.
Signed-off-by: Nitin Garg nitin.g...@freescale.com
---
arch/arm/cpu/armv7/mx6/soc.c | 138 +++-
arch/arm/imx-common/cpu.c|7 +-
arch/arm/include/asm/arch-mx6/crm_regs.h | 543
+-
arch/arm/include/asm/arch-mx6/imx-regs.h |9 +-
4 files changed, 693 insertions(+), 4 deletions(-)
I tend to consider this as a driver instead of a couple of functions to
read/check temperature. Hiding this code inside cpu code does not get an
overview about which API is used. If another SOC (not necessarily
Freescale) will add such kind of functionality, we will have probably a
different API.
I would prefer, without reinventing the wheel, to follow the kernel
approach and move this code into a driver, let's say into
drivers/thermal. Feel free to add this directory to u-boot tree. A name
as imx-thermal as in kernel looks to me appropriate for your code.
diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
index ac84a1f..b0c1306 100644
--- a/arch/arm/cpu/armv7/mx6/soc.c
+++ b/arch/arm/cpu/armv7/mx6/soc.c
@@ -2,7 +2,7 @@
* (C) Copyright 2007
* Sascha Hauer, Pengutronix
*
- * (C) Copyright 2009 Freescale Semiconductor, Inc.
+ * (C) Copyright 2009-2014 Freescale Semiconductor, Inc.
*
* SPDX-License-Identifier: GPL-2.0+
*/
@@ -35,6 +35,16 @@ struct scu_regs {
u32 fpga_rev;
};
+#define TEMPERATURE_MIN -40
+#define TEMPERATURE_HOT 80
+#define TEMPERATURE_MAX 125
+#define FACTOR1 15976
+#define FACTOR2 4297157
+#define MEASURE_FREQ 327
+
+#define REG_VALUE_TO_CEL(ratio, raw) \
+ ((raw_n40c - raw) * 100 / ratio - 40)
+
u32 get_nr_cpus(void)
{
struct scu_regs *scu = (struct scu_regs *)SCU_BASE_ADDR;
@@ -218,6 +228,132 @@ static void imx_set_wdog_powerdown(bool enable)
writew(enable, wdog2-wmcr);
}
+#ifdef CONFIG_IMX6_TEMP_SENSOR
TEMP is rather a misleading name. It can be confused with temporary.
Maybe CONFIG_IMX_THERMAL or CONFIG_IMX_THERMAL_SENSOR ?
+static int read_cpu_temperature(u32 *fuse)
+{
+ int temperature;
+ unsigned int ccm_ccgr2;
+ unsigned int reg, tmp;
+ unsigned int raw_25c, raw_n40c, ratio;
+ struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
+ struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
+ struct ocotp_regs *ocotp = (struct ocotp_regs *)OCOTP_BASE_ADDR;
+ struct fuse_bank *bank = ocotp-bank[1];
+ struct fuse_bank1_regs *fuse_bank1 =
+ (struct fuse_bank1_regs *)bank-fuse_regs;
+
+ /* need to make sure pll3 is enabled for thermal sensor */
The code to enable a clock should go into armv7/mx6/clock.c.
+ if ((readl(anatop-usb1_pll_480_ctrl)
+ BM_ANADIG_USB1_PLL_480_CTRL_LOCK) == 0) {
+ /* enable pll's power */
+ writel(BM_ANADIG_USB1_PLL_480_CTRL_POWER,
+anatop-usb1_pll_480_ctrl_set);
+ writel(0x80, anatop-ana_misc2_clr);
+ /* wait for pll lock */
+ while ((readl(anatop-usb1_pll_480_ctrl)
+ BM_ANADIG_USB1_PLL_480_CTRL_LOCK) == 0)
+ ;
+ /* disable bypass */
+ writel(BM_ANADIG_USB1_PLL_480_CTRL_BYPASS,
+anatop-usb1_pll_480_ctrl_clr);
+ /* enable pll output */
+ writel(BM_ANADIG_USB1_PLL_480_CTRL_ENABLE,
+anatop-usb1_pll_480_ctrl_set);
+ }
+
+ ccm_ccgr2 = readl(mxc_ccm-CCGR2);
+ /* enable OCOTP_CTRL clock in CCGR2 */
+ writel(ccm_ccgr2 | MXC_CCM_CCGR2_OCOTP_CTRL_MASK, mxc_ccm-CCGR2);
You are readding the same code we have already merged. We have a ocotp
driver in u-boot, and this uses enable_ocotp_clk() to enable and disable
the clock. Please use also the functions provide by the ocotp driver. I
suggest you add a Kconfig rule to make this driver dependend on ocotp.
+ *fuse = readl(fuse_bank1-ana1);
+
+ /* restore CCGR2 */
+ writel(ccm_ccgr2, mxc_ccm-CCGR2);
+
+ if (*fuse == 0 || *fuse == 0x || (*fuse 0xfff0) == 0)
+ return TEMPERATURE_MIN;
+
Does it mean invalid values ? According to manual, the register is split
into three different regions (Room, Hot_count, Hot_temp) and I am
wondering we can simply compare the whole register. If your check means
that you are reading invalid or not expected values, an error should be
reported instead of falling back to the minimal temperature.
+ /*
+ * fuse data layout:
+ * [31:20] sensor value @ 25C
+ * [19:8] sensor value of hot
+ * [7:0] hot temperature value
+ */
+
Re: [U-Boot] [PATCH v2 2/2] imx: mx6slevk: Change to use generic board
On 09/09/2014 08:51, Ye.Li wrote: Enable CONFIG_SYS_GENERIC_BOARD for imx6slevk to use generic board. Signed-off-by: Ye.Li b37...@freescale.com --- Applied to u-boot-imx, thanks ! 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/2] imx: mx6q/dlarm2: Change to use generic board
On 09/09/2014 08:51, Ye.Li wrote: Enable the CONFIG_SYS_GENERIC_BOARD for imx6q/dl arm2 board to use generic board. Signed-off-by: Ye.Li b37...@freescale.com --- Applied to u-boot-imx, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/4] mtd: nand: add Freescale vf610_nfc driver
Hi Stefan,
patch is landed on my desk as part of i.MX. I will have some minor
points. Is thi
On 18/08/2014 18:26, Stefan Agner wrote:
This adds initial support for Freescale NFC (NAND Flash Controller)
found in ARM Vybrid SoC's, Power Architecture MPC5125 and others.
The driver is called vf610_nfc since this is the first supported
and tested hardware platform supported by the driver.
Signed-off-by: Stefan Agner ste...@agner.ch
---
[snip]
+struct vf610_nfc {
+ struct mtd_info *mtd;
+ struct nand_chip chip;
+/* struct device *dev;*/
Do not add dead code. Check this globally.
+ void __iomem *regs;
+ uint column;
+ intspareonly;
+ intpage;
+ /* Status and ID are in alternate locations. */
+ intalt_buf;
+#define ALT_BUF_ID 1
+#define ALT_BUF_STAT 2
+ struct clk*clk;
+};
+
+#define mtd_to_nfc(_mtd) (struct vf610_nfc *)((struct nand_chip
*)_mtd-priv)-priv;
+
+static u8 bbt_pattern[] = {'B', 'b', 't', '0' };
+static u8 mirror_pattern[] = {'1', 't', 'b', 'B' };
+
+static struct nand_bbt_descr bbt_main_descr = {
+ .options = NAND_BBT_LASTBLOCK | NAND_BBT_CREATE | NAND_BBT_WRITE |
+NAND_BBT_2BIT | NAND_BBT_VERSION,
+ .offs = 11,
+ .len = 4,
+ .veroffs = 15,
+ .maxblocks = 4,
+ .pattern = bbt_pattern,
+};
+
+static struct nand_bbt_descr bbt_mirror_descr = {
+ .options = NAND_BBT_LASTBLOCK | NAND_BBT_CREATE | NAND_BBT_WRITE |
+NAND_BBT_2BIT | NAND_BBT_VERSION,
+ .offs = 11,
+ .len = 4,
+ .veroffs = 15,
+ .maxblocks = 4,
+ .pattern = mirror_pattern,
+};
+
+static struct nand_ecclayout vf610_nfc_ecc45 = {
+ .eccbytes = 45,
+ .eccpos = {19, 20, 21, 22, 23,
+24, 25, 26, 27, 28, 29, 30, 31,
+32, 33, 34, 35, 36, 37, 38, 39,
+40, 41, 42, 43, 44, 45, 46, 47,
+48, 49, 50, 51, 52, 53, 54, 55,
+56, 57, 58, 59, 60, 61, 62, 63},
+ .oobfree = {
+ {.offset = 8,
+ .length = 11} }
+};
+
+static inline u32 vf610_nfc_read(struct mtd_info *mtd, uint reg)
+{
+ struct vf610_nfc *nfc = mtd_to_nfc(mtd);
+
+ return readl(nfc-regs + reg);
+}
+
+static inline void vf610_nfc_write(struct mtd_info *mtd, uint reg, u32 val)
+{
+ struct vf610_nfc *nfc = mtd_to_nfc(mtd);
+
+ writel(val, nfc-regs + reg);
+}
+
+static inline void vf610_nfc_set(struct mtd_info *mtd, uint reg, u32 bits)
+{
+ vf610_nfc_write(mtd, reg, vf610_nfc_read(mtd, reg) | bits);
+}
+
+static inline void vf610_nfc_clear(struct mtd_info *mtd, uint reg, u32 bits)
+{
+ vf610_nfc_write(mtd, reg, vf610_nfc_read(mtd, reg) ~bits);
+}
+
+static inline void vf610_nfc_set_field(struct mtd_info *mtd, u32 reg,
+u32 mask, u32 shift, u32 val)
+{
+ vf610_nfc_write(mtd, reg,
+ (vf610_nfc_read(mtd, reg) (~mask)) | val shift);
+}
+
+/* Clear flags for upcoming command */
+static inline void vf610_nfc_clear_status(void __iomem *regbase)
+{
+ void __iomem *reg = regbase + NFC_IRQ_STATUS;
+ u32 tmp = __raw_readl(reg);
+ tmp |= CMD_DONE_CLEAR_BIT | IDLE_CLEAR_BIT;
+ __raw_writel(tmp, reg);
+}
+
+/* Wait for complete operation */
+static inline void vf610_nfc_done(struct mtd_info *mtd)
+{
+ struct vf610_nfc *nfc = mtd_to_nfc(mtd);
+ uint start;
+
+ /*
+ * Barrier is needed after this write. This write need
+ * to be done before reading the next register the first
+ * time.
+ * vf610_nfc_set implicates such a barrier by using writel
+ * to write to the register.
+ */
+ vf610_nfc_set(mtd, NFC_FLASH_CMD2, START_BIT);
+
+ start = get_timer(0);
+
+ while (!(vf610_nfc_read(mtd, NFC_IRQ_STATUS) IDLE_IRQ_BIT)) {
+ if (get_timer(start) NFC_TIMEOUT) {
+ printf(Timeout while waiting for !BUSY.\n);
+ return;
+ }
+ }
+ vf610_nfc_clear_status(nfc-regs);
+}
+
+static u8 vf610_nfc_get_id(struct mtd_info *mtd, int col)
+{
+ u32 flash_id;
+
+ if (col 4) {
+ flash_id = vf610_nfc_read(mtd, NFC_FLASH_STATUS1);
+ return (flash_id (3-col)*8) 0xff;
+ } else {
+ flash_id = vf610_nfc_read(mtd, NFC_FLASH_STATUS2);
+ return flash_id 24;
+ }
+}
+
+static u8 vf610_nfc_get_status(struct mtd_info *mtd)
+{
+ return vf610_nfc_read(mtd, NFC_FLASH_STATUS2) STATUS_BYTE1_MASK;
+}
+
+/* Single command */
+static void vf610_nfc_send_command(void __iomem *regbase, u32 cmd_byte1,
+u32 cmd_code)
+{
+ void __iomem *reg = regbase + NFC_FLASH_CMD2;
+ u32 tmp;
+ vf610_nfc_clear_status(regbase);
+
+ tmp = __raw_readl(reg);
+ tmp =
Re: [U-Boot] [PATCH v3 3/4] mtd: nand: add Freescale vf610_nfc driver
On 21/08/2014 23:15, Bill Pringlemeir wrote:
On 14 Aug 2014, ste...@agner.ch wrote:
This adds initial support for Freescale NFC (NAND Flash
Controller) found in ARM Vybrid SoC's, Power Architecture MPC5125
and others. However, this driver is only tested on Vybrid.
On Wed, 2014-08-13 at 22:32, Scott Wood wrote:
raw_writel() is itself something that should only be used for
hand-optimized sections. For non-performance-critical code you
should use normal writel() so that you don't need to worry about
manually adding I/O barriers.
Am 2014-08-14 23:12, schrieb Bill Pringlemeir:
[regarding memcpy() in the driver]
Maybe a comment is fine? It seems the Vybrid is safe for
different access sizes, but it is possible that some other CPU
might not be able to access this memory via 32/16/8 bit accesses
and 'memcpy()' may not be appropriate. It seems that 'natural'
size of the NFC controller itself is 32bits and the CPU interface
does lane masking. Ie, boot mode documentation talks about
remapping 'sram_physical_addr[13:3] =
{cpu_addr[11:3],cpu_addr[13:12]}' saying that bits 2,1 are not used
(hopefully one based numbers). This is just my guess...
On 18 Aug 2014, ste...@agner.ch wrote:
What assumptions do you make how memcpy accesses memory? This latest
patch now uses the optimized versions from the kernel... Maybe they
even try to access 64-bit width (the NIC interconnect supports
64-bit access)
[snip]
Am 2014-08-18 18:38, schrieb Bill Pringlemeir:
My only point is that the SRAM buffers use the same interface as the
main Nand controller register banks. So using 'readl/writel' for the
register, but not the SRAM buffers seems inconsistent.
So to address this inconsistency, I was thinking that we should at
least have a comment?
On 19 Aug 2014, ste...@agner.ch wrote:
IMHO, we just treat this as if its memory and I guess this is fine for
a buffer. memcpy knows how to copy data, and takes care if the
architecture needs aligned access when reading 32-bit width, or
similar requirements. We do not know whether memcpy really uses 32-bit
accesses, hence this comment might even be wrong. In a short test, I
could also access the buffer in byte/word length (tested using
md.b/md.w).
Also, I assume this just works for a different architecture too. If
not, the one using this driver the first time on a different
architecture would see this pretty quickly I guess :-)
[snip]
In our case, a barrier just after the memcpy would be sufficient.
I would suggest you make a 'vf610_nfc_memcpy()' [or even from/to
variants if you are pendantic] which can be a wrapper function of just
'memcpy'. Just the like the readl/writel wrappers this will collect the
BUS accesses into one place. So they are documented for people porting
the code. Trying to accommodate some future insane hardware hookup seems
futile beyond this?
Otherwise, I will add an 'Ack' or 'Reviewed-By' from me if you like. I
am sorry, I don't know what if anything is appropriate.
Both are appropraite. IMHO you are an author and you checked the code
after Stefan's porting: ACK should be the best choice,.
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
[U-Boot] [PATCH V2] sf: Add support for flag status register on Micron chips
From: Mingkai Hu mingkai...@freescale.com
Enter 3 Byte address mode at first, because it may change to 4 Byte
address mode in kernel driver and not reset to 3 Byte address mode
after reboot.
Add clear flag status register operation that some Micron SPI flash
chips required after reading the flag status register to check some
operations completion.
Signed-off-by: Mingkai.Hu mingkai...@freescale.com
---
V1:
Based on git://git.denx.de/u-boot.git.
Tested on board T2080QDS and T2080RDB.
V2:
Add the operation of enter 3 Byte address mode in probe.
drivers/mtd/spi/sf_internal.h | 17
drivers/mtd/spi/sf_ops.c | 64 +--
drivers/mtd/spi/sf_probe.c| 5
3 files changed, 78 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
index 19d4914..49e5a2c 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -36,6 +36,11 @@
#define CMD_WRITE_ENABLE 0x06
#define CMD_READ_CONFIG0x35
#define CMD_FLAG_STATUS0x70
+#define CMD_CLEAR_FLAG_STATUS 0x50
+
+/* Used for Macronix and Winbond flashes */
+#defineCMD_ENTER_4B_ADDR 0xB7
+#defineCMD_EXIT_4B_ADDR0xE9
/* Read commands */
#define CMD_READ_ARRAY_SLOW0x03
@@ -59,6 +64,8 @@
#define STATUS_QEB_WINSPAN (1 1)
#define STATUS_QEB_MXIC(1 6)
#define STATUS_PEC (1 7)
+#define STATUS_PROT(1 1)
+#define STATUS_ERASE (1 5)
#ifdef CONFIG_SYS_SPI_ST_ENABLE_WP_PIN
#define STATUS_SRWD(1 7) /* SR write protect */
@@ -124,6 +131,12 @@ static inline int spi_flash_cmd_write_disable(struct
spi_flash *flash)
return spi_flash_cmd(flash-spi, CMD_WRITE_DISABLE, NULL, 0);
}
+/* Clear flag status register */
+static inline int spi_flash_cmd_clear_flag_status(struct spi_flash *flash)
+{
+ return spi_flash_cmd(flash-spi, CMD_CLEAR_FLAG_STATUS, NULL, 0);
+}
+
/*
* Send the read status command to the device and wait for the wip
* (write-in-progress) bit to clear itself.
@@ -160,4 +173,8 @@ int spi_flash_read_common(struct spi_flash *flash, const u8
*cmd,
int spi_flash_cmd_read_ops(struct spi_flash *flash, u32 offset,
size_t len, void *data);
+#if defined(CONFIG_SPI_FLASH_STMICRO)
+int spi_flash_cmd_4B_addr_switch(struct spi_flash *flash, int enable);
+#endif
+
#endif /* _SF_INTERNAL_H_ */
diff --git a/drivers/mtd/spi/sf_ops.c b/drivers/mtd/spi/sf_ops.c
index 85cf22d..8a532b8 100644
--- a/drivers/mtd/spi/sf_ops.c
+++ b/drivers/mtd/spi/sf_ops.c
@@ -93,6 +93,30 @@ int spi_flash_cmd_write_config(struct spi_flash *flash, u8
wc)
}
#endif
+#if defined(CONFIG_SPI_FLASH_STMICRO)
+int spi_flash_cmd_4B_addr_switch(struct spi_flash *flash, int enable)
+{
+ int ret;
+ u8 cmd;
+
+ cmd = enable ? CMD_ENTER_4B_ADDR : CMD_EXIT_4B_ADDR;
+
+ ret = spi_claim_bus(flash-spi);
+ if (ret) {
+ debug(SF: unable to claim SPI bus\n);
+ return ret;
+ }
+
+ ret = spi_flash_cmd_write_enable(flash);
+ if (ret 0) {
+ debug(SF: enabling write failed\n);
+ return ret;
+ }
+
+ return spi_flash_cmd(flash-spi, cmd, NULL, 0);
+}
+#endif
+
#ifdef CONFIG_SPI_FLASH_BAR
static int spi_flash_cmd_bankaddr_write(struct spi_flash *flash, u8 bank_sel)
{
@@ -160,6 +184,7 @@ int spi_flash_cmd_wait_ready(struct spi_flash *flash,
unsigned long timeout)
unsigned long timebase;
unsigned long flags = SPI_XFER_BEGIN;
int ret;
+ int out_of_time = 1;
u8 status;
u8 check_status = 0x0;
u8 poll_bit = STATUS_WIP;
@@ -186,22 +211,45 @@ int spi_flash_cmd_wait_ready(struct spi_flash *flash,
unsigned long timeout)
WATCHDOG_RESET();
ret = spi_xfer(spi, 8, NULL, status, 0);
- if (ret)
+ if (ret) {
+ spi_xfer(spi, 0, NULL, NULL, SPI_XFER_END);
return -1;
+ }
- if ((status poll_bit) == check_status)
+ if ((status poll_bit) == check_status) {
+ out_of_time = 0;
break;
+ }
} while (get_timer(timebase) timeout);
spi_xfer(spi, 0, NULL, NULL, SPI_XFER_END);
- if ((status poll_bit) == check_status)
- return 0;
+ if (out_of_time) {
+ /* Timed out */
+ debug(SF: time out!\n);
+ if (cmd == CMD_FLAG_STATUS) {
+ if (spi_flash_cmd_clear_flag_status(flash) 0)
+ debug(SF: clear flag status failed\n);
+ }
+ ret = -1;
+ }
+#ifdef CONFIG_SPI_FLASH_STMICRO
+ else if (cmd ==
[U-Boot] [PATCH V2] sf: Add support for flag status register on Micron chips
From: Mingkai Hu mingkai...@freescale.com
Enter 3 Byte address mode at first, because it may change to 4 Byte
address mode in kernel driver and not reset to 3 Byte address mode
after reboot.
Add clear flag status register operation that some Micron SPI flash
chips required after reading the flag status register to check some
operations completion.
Signed-off-by: Mingkai.Hu mingkai...@freescale.com
---
V1:
Based on git://git.denx.de/u-boot.git.
Tested on board T2080QDS and T2080RDB.
V2:
Add the operation of enter 3 Byte address mode in probe.
drivers/mtd/spi/sf_internal.h | 17
drivers/mtd/spi/sf_ops.c | 64 +--
drivers/mtd/spi/sf_probe.c| 5
3 files changed, 78 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
index 19d4914..49e5a2c 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -36,6 +36,11 @@
#define CMD_WRITE_ENABLE 0x06
#define CMD_READ_CONFIG0x35
#define CMD_FLAG_STATUS0x70
+#define CMD_CLEAR_FLAG_STATUS 0x50
+
+/* Used for Macronix and Winbond flashes */
+#defineCMD_ENTER_4B_ADDR 0xB7
+#defineCMD_EXIT_4B_ADDR0xE9
/* Read commands */
#define CMD_READ_ARRAY_SLOW0x03
@@ -59,6 +64,8 @@
#define STATUS_QEB_WINSPAN (1 1)
#define STATUS_QEB_MXIC(1 6)
#define STATUS_PEC (1 7)
+#define STATUS_PROT(1 1)
+#define STATUS_ERASE (1 5)
#ifdef CONFIG_SYS_SPI_ST_ENABLE_WP_PIN
#define STATUS_SRWD(1 7) /* SR write protect */
@@ -124,6 +131,12 @@ static inline int spi_flash_cmd_write_disable(struct
spi_flash *flash)
return spi_flash_cmd(flash-spi, CMD_WRITE_DISABLE, NULL, 0);
}
+/* Clear flag status register */
+static inline int spi_flash_cmd_clear_flag_status(struct spi_flash *flash)
+{
+ return spi_flash_cmd(flash-spi, CMD_CLEAR_FLAG_STATUS, NULL, 0);
+}
+
/*
* Send the read status command to the device and wait for the wip
* (write-in-progress) bit to clear itself.
@@ -160,4 +173,8 @@ int spi_flash_read_common(struct spi_flash *flash, const u8
*cmd,
int spi_flash_cmd_read_ops(struct spi_flash *flash, u32 offset,
size_t len, void *data);
+#if defined(CONFIG_SPI_FLASH_STMICRO)
+int spi_flash_cmd_4B_addr_switch(struct spi_flash *flash, int enable);
+#endif
+
#endif /* _SF_INTERNAL_H_ */
diff --git a/drivers/mtd/spi/sf_ops.c b/drivers/mtd/spi/sf_ops.c
index 85cf22d..8a532b8 100644
--- a/drivers/mtd/spi/sf_ops.c
+++ b/drivers/mtd/spi/sf_ops.c
@@ -93,6 +93,30 @@ int spi_flash_cmd_write_config(struct spi_flash *flash, u8
wc)
}
#endif
+#if defined(CONFIG_SPI_FLASH_STMICRO)
+int spi_flash_cmd_4B_addr_switch(struct spi_flash *flash, int enable)
+{
+ int ret;
+ u8 cmd;
+
+ cmd = enable ? CMD_ENTER_4B_ADDR : CMD_EXIT_4B_ADDR;
+
+ ret = spi_claim_bus(flash-spi);
+ if (ret) {
+ debug(SF: unable to claim SPI bus\n);
+ return ret;
+ }
+
+ ret = spi_flash_cmd_write_enable(flash);
+ if (ret 0) {
+ debug(SF: enabling write failed\n);
+ return ret;
+ }
+
+ return spi_flash_cmd(flash-spi, cmd, NULL, 0);
+}
+#endif
+
#ifdef CONFIG_SPI_FLASH_BAR
static int spi_flash_cmd_bankaddr_write(struct spi_flash *flash, u8 bank_sel)
{
@@ -160,6 +184,7 @@ int spi_flash_cmd_wait_ready(struct spi_flash *flash,
unsigned long timeout)
unsigned long timebase;
unsigned long flags = SPI_XFER_BEGIN;
int ret;
+ int out_of_time = 1;
u8 status;
u8 check_status = 0x0;
u8 poll_bit = STATUS_WIP;
@@ -186,22 +211,45 @@ int spi_flash_cmd_wait_ready(struct spi_flash *flash,
unsigned long timeout)
WATCHDOG_RESET();
ret = spi_xfer(spi, 8, NULL, status, 0);
- if (ret)
+ if (ret) {
+ spi_xfer(spi, 0, NULL, NULL, SPI_XFER_END);
return -1;
+ }
- if ((status poll_bit) == check_status)
+ if ((status poll_bit) == check_status) {
+ out_of_time = 0;
break;
+ }
} while (get_timer(timebase) timeout);
spi_xfer(spi, 0, NULL, NULL, SPI_XFER_END);
- if ((status poll_bit) == check_status)
- return 0;
+ if (out_of_time) {
+ /* Timed out */
+ debug(SF: time out!\n);
+ if (cmd == CMD_FLAG_STATUS) {
+ if (spi_flash_cmd_clear_flag_status(flash) 0)
+ debug(SF: clear flag status failed\n);
+ }
+ ret = -1;
+ }
+#ifdef CONFIG_SPI_FLASH_STMICRO
+ else if (cmd ==
[U-Boot] [PATCH] imx: nitrogen6x: Make use of both uSD and SD slots to load script or kernel on Sabrelite board
Sabrelite board has two solts: 0 is SD3 (bottom) slot and 1 is uSD4 (top) slot.
This patch makes use of both slots instead of only one.
Signed-off-by: Guillaume GARDET guillaume.gar...@free.fr
Cc: Stefano Babic sba...@denx.de
Cc: Eric Nelson eric.nel...@boundarydevices.com
---
include/configs/nitrogen6x.h | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h
index d4b0ac9..2a1eb3b 100644
--- a/include/configs/nitrogen6x.h
+++ b/include/configs/nitrogen6x.h
@@ -186,7 +186,7 @@
fdt_addr=0x1800\0 \
boot_fdt=try\0 \
ip_dyn=yes\0 \
- mmcdev=0\0 \
+ mmcdevs=0 1\0 \
mmcpart=1\0 \
mmcroot=/dev/mmcblk0p2 rootwait rw\0 \
mmcargs=setenv bootargs console=${console},${baudrate} \
@@ -238,16 +238,19 @@
fi;\0
#define CONFIG_BOOTCOMMAND \
- mmc dev ${mmcdev}; if mmc rescan; then \
- if run loadbootscript; then \
- run bootscript; \
- else \
- if run loaduimage; then \
- run mmcboot; \
- else run netboot; \
- fi; \
- fi; \
- else run netboot; fi
+ for mmcdev in ${mmcdevs}; do \
+ mmc dev ${mmcdev}; \
+ if mmc rescan; then \
+ if run loadbootscript; then \
+ run bootscript; \
+ else \
+ if run loaduimage; then \
+ run mmcboot; \
+ fi; \
+ fi; \
+ fi; \
+ done; \
+ run netboot;
#else
#define CONFIG_EXTRA_ENV_SETTINGS \
console=ttymxc1\0 \
--
1.8.4.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/8] add clang support for some ARM boards
Hello Albert,
On do, 2014-09-11 at 10:32 +0200, Albert ARIBAUD wrote:
On Wed, 10 Sep 2014 20:08:50 +0200, Jeroen Hofstee
jer...@myspectrum.nl wrote:
Changes since v2:
- As Albert pointed out the clang instructions don't work with
Debian based binary packages. While I was aware of that it is
for a different reason then I thought, it is not that ARM is not
enabled as a backend but older versions are a bit more picky on
the target argument and don't tolerate a trailing dash to it as
used for CROSS_COMPILE etc. The README is updated accordingly.
As a side note clang3.5-svn as shipped in Ubuntu is not the 3.5
release but an snapshot of some svn commit and hence explain why
the recompiled 3.5 can behave different then the ubuntu clang-3.5.
Since it misses some patches, the clang3.5-svn can build less
boards then 3.4 or an actual 3.5 release.
- While add it, include Masahiro suggestion to also use c++ instead
of g++.
- Drop dependencies from the cover-letter as they are merged.
- only patch 7/8 and 8/8 are reposted. 1..6 are the same as v2.
Thanks, tested building rpi_b, it works now.
The, tested on versatileqemu out of curiosity and got the following
results:
1.
clang warns about Unused static functions in common/console.c, namely
console_printdevs and console_doenv (1). Why gcc does not flag this?
We have -Wall set which is supposed to imply -Wunused-functions.
It is a gcc feature, see [1]: Warn whenever a static function is
declared but not defined or a _non-inline static function_ is unused.
This warning is enabled by -Wall.
There is also an unused variable warning in disk/part.c28
(block_drvr). I haven't looked at why clang warns about it and not gcc,
but it could raise the same question as the functions above.
Also a gcc feature, see [2]. The constant is indeed not used.
2.
clang errors on arch/arm/lib/cache.c:28 for this:
asm(0: mrc p15, 0, r15, c7, c10, 3\n\t bne 0b\n : : : memory);
and that is a clang mistake, as for ARM926EJS r15 is a valid (albeit
quite special semantically) Rd for Test and Clean DCache, see page 2-24.
This is the integrated-as complaining (the README tells you to disable
it for the moment). The clang folks push UAL hard, up to a point we need
to think about minimum gcc version etc. To avoid that, I just left out
such changes and just use gas instead, at least for the time being.
Below are some changes to compile versatileqemu with llvm integrated-as
and gcc/gas. No idea if it actually boots though.
Jeroen, do you feel like raising point 2 to the clang/LLVM folks?
It is removed on purpose as far as I understood. I don't think they
regards it as a bug, see obfuscated patch below.
Other than that, the patch series seems to be good. I'll apply it
soonish.
Thanks,
Jeroen
[1] https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13029
s/~/-/g
~~~
From dbc16575725693378ad5dac84d6fb945545c3b63 Mon Sep 17 00:00:00 2001
From: Jeroen Hofstee jer...@myspectrum.nl
Date: Thu, 11 Sep 2014 12:46:35 +0200
Subject: [PATCH] versatileqemu ual build
~~~
arch/arm/cpu/arm926ejs/cache.c | 2 +~
arch/arm/cpu/arm926ejs/start.S | 2 +~
arch/arm/lib/cache.c | 2 +~
include/configs/versatile.h| 2 ++
4 files changed, 5 insertions(+), 3 deletions(~)
diff ~~git a/arch/arm/cpu/arm926ejs/cache.c
b/arch/arm/cpu/arm926ejs/cache.c
index e86c2ed..b1aae13 100644
~~~ a/arch/arm/cpu/arm926ejs/cache.c
+++ b/arch/arm/cpu/arm926ejs/cache.c
@@ ~22,7 +22,7 @@ void flush_dcache_all(void)
{
asm volatile(
0:
~ mrc p15, 0, r15, c7, c14, 3\n
+ mrc p15, 0, apsr_nzcv, c7, c14, 3\n
bne 0b\n
mcr p15, 0, %0, c7, c10, 4\n
: : r(0) : memory
diff ~~git a/arch/arm/cpu/arm926ejs/start.S
b/arch/arm/cpu/arm926ejs/start.S
index 8eb2494..b9d2ae2 100644
~~~ a/arch/arm/cpu/arm926ejs/start.S
+++ b/arch/arm/cpu/arm926ejs/start.S
@@ ~78,7 +78,7 @@ cpu_init_crit:
*/
mov r0, #0
flush_dcache:
~ mrc p15, 0, r15, c7, c10, 3
+ mrc p15, 0, apsr_nzcv, c7, c10, 3
bne flush_dcache
mcr p15, 0, r0, c8, c7, 0 /* invalidate TLB */
diff ~~git a/arch/arm/lib/cache.c b/arch/arm/lib/cache.c
index 4e597a4..d12ea2b 100644
~~~ a/arch/arm/lib/cache.c
+++ b/arch/arm/lib/cache.c
@@ ~25,7 +25,7 @@ __weak void flush_cache(unsigned long start, unsigned
long size)
#ifdef CONFIG_ARM926EJS
/* test and clean, page 2~23 of arm926ejs manual */
~ asm(0: mrc p15, 0, r15, c7, c10, 3\n\t bne 0b\n : : : memory);
+ asm(0: mrc p15, 0, apsr_nzcv, c7, c10, 3\n\t bne 0b\n : : :
memory);
/* disable write buffer as well (page 2~22) */
asm(mcr p15, 0, %0, c7, c10, 4 : : r (0));
#endif /* CONFIG_ARM926EJS */
diff ~~git a/include/configs/versatile.h b/include/configs/versatile.h
index 29c32fe..52d2af3 100644
~~~ a/include/configs/versatile.h
+++ b/include/configs/versatile.h
Re: [U-Boot] arm kirkwood pending patches
Sure... will be pulled soon, once I am back in office. Regards... Prafulla . . . -Original Message- From: Luka Perkov [mailto:l...@openwrt.org] Sent: 11 September 2014 04:29 To: u-boot@lists.denx.de Cc: Prafulla Wadaskar Subject: arm kirkwood pending patches Hi, I have noticed that there are 3 pending kirkwood patches that I've sent a while back. It seems that there has been no action since then. Patches have been ACKed... Can we get some progress on these: http://patchwork.ozlabs.org/patch/366225/ http://patchwork.ozlabs.org/patch/366226/ http://patchwork.ozlabs.org/patch/366227/ Thanks. Regards, Luka ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] usb: dfu: add fullspeed support for DFU
Hi Heiko,
DFU now can use also fullspeed.
Signed-off-by: Heiko Schocher h...@denx.de
Cc: Tom Rini tr...@ti.com
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Marek Vasut ma...@denx.de
Cc: Liu Bin b-...@ti.com
Cc: Lukas Stockmann lukas.stockm...@siemens.com
---
- changes for v2:
- get rid of config option CONFIG_DFU_FULLSPEED as Bin Liu
suggested.
---
drivers/usb/gadget/f_dfu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/gadget/f_dfu.c b/drivers/usb/gadget/f_dfu.c
index 1145aab..dfa9f3b 100644
--- a/drivers/usb/gadget/f_dfu.c
+++ b/drivers/usb/gadget/f_dfu.c
@@ -238,6 +238,7 @@ static inline void to_dfu_mode(struct f_dfu
*f_dfu) {
f_dfu-usb_function.strings = dfu_strings;
f_dfu-usb_function.hs_descriptors = f_dfu-function;
+ f_dfu-usb_function.descriptors = f_dfu-function;
f_dfu-dfu_state = DFU_STATE_dfuIDLE;
}
@@ -245,6 +246,7 @@ static inline void to_runtime_mode(struct f_dfu
*f_dfu) {
f_dfu-usb_function.strings = NULL;
f_dfu-usb_function.hs_descriptors = dfu_runtime_descs;
+ f_dfu-usb_function.descriptors = dfu_runtime_descs;
}
static int handle_upload(struct usb_request *req, u16 len)
@@ -809,6 +811,7 @@ static int dfu_bind_config(struct
usb_configuration *c) return -ENOMEM;
f_dfu-usb_function.name = dfu;
f_dfu-usb_function.hs_descriptors = dfu_runtime_descs;
+ f_dfu-usb_function.descriptors = dfu_runtime_descs;
f_dfu-usb_function.bind = dfu_bind;
f_dfu-usb_function.unbind = dfu_unbind;
f_dfu-usb_function.set_alt = dfu_set_alt;
Test HW: Exynos 4412 - Trats2
This patch seems to not introduce any regressions, so
Tested-by: Lukasz Majewski l.majew...@samsung.com
--
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
[U-Boot] [PATCH v4 1/2] mtd: nand: add Freescale vf610_nfc driver
This adds initial support for Freescale NFC (NAND Flash Controller) found in ARM Vybrid SoC's, Power Architecture MPC5125 and others. The driver is called vf610_nfc since this is the first supported and tested hardware platform supported by the driver. Signed-off-by: Stefan Agner ste...@agner.ch --- drivers/mtd/nand/Makefile| 1 + drivers/mtd/nand/vf610_nfc.c | 721 +++ 2 files changed, 722 insertions(+) create mode 100644 drivers/mtd/nand/vf610_nfc.c diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index bf1312a..eef86d1 100644 --- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -51,6 +51,7 @@ obj-$(CONFIG_NAND_KB9202) += kb9202_nand.o obj-$(CONFIG_NAND_KIRKWOOD) += kirkwood_nand.o obj-$(CONFIG_NAND_KMETER1) += kmeter1_nand.o obj-$(CONFIG_NAND_MPC5121_NFC) += mpc5121_nfc.o +obj-$(CONFIG_NAND_VF610_NFC) += vf610_nfc.o obj-$(CONFIG_NAND_MXC) += mxc_nand.o obj-$(CONFIG_NAND_MXS) += mxs_nand.o obj-$(CONFIG_NAND_NDFC) += ndfc.o diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c new file mode 100644 index 000..f0eba9a --- /dev/null +++ b/drivers/mtd/nand/vf610_nfc.c @@ -0,0 +1,721 @@ +/* + * Copyright 2009-2014 Freescale Semiconductor, Inc. and others + * + * Description: MPC5125, VF610, MCF54418 and Kinetis K70 Nand driver. + * Ported to U-Boot by Stefan Agner + * Based on RFC driver posted on Kernel Mailing list by Bill Pringlemeir + * Jason ported to M54418TWR and MVFA5. + * Authors: Stefan Agner stefan.ag...@toradex.com + * Bill Pringlemeir bpringlem...@nbsps.com + * Shaohui Xie b21...@freescale.com + * Jason Jin jason@freescale.com + * + * Based on original driver mpc5121_nfc.c. + * + * This is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * Limitations: + * - Untested on MPC5125 and M54418. + * - DMA not used. + * - 2K pages or less. + * - Only 2K page w. 64+OOB and hardware ECC. + */ + +#include common.h +#include malloc.h + +#include linux/mtd/mtd.h +#include linux/mtd/nand.h +#include linux/mtd/partitions.h + +#include nand.h +#include errno.h +#include asm/io.h + +/* Register Offsets */ +#define NFC_FLASH_CMD1 0x3F00 +#define NFC_FLASH_CMD2 0x3F04 +#define NFC_COL_ADDR 0x3F08 +#define NFC_ROW_ADDR 0x3F0c +#define NFC_ROW_ADDR_INC 0x3F14 +#define NFC_FLASH_STATUS1 0x3F18 +#define NFC_FLASH_STATUS2 0x3F1c +#define NFC_CACHE_SWAP 0x3F28 +#define NFC_SECTOR_SIZE0x3F2c +#define NFC_FLASH_CONFIG 0x3F30 +#define NFC_IRQ_STATUS 0x3F38 + +/* Addresses for NFC MAIN RAM BUFFER areas */ +#define NFC_MAIN_AREA(n) ((n) * 0x1000) + +#define PAGE_2K0x0800 +#define OOB_64 0x0040 + +/* + * NFC_CMD2[CODE] values. See section: + * - 31.4.7 Flash Command Code Description, Vybrid manual + * - 23.8.6 Flash Command Sequencer, MPC5125 manual + * + * Briefly these are bitmasks of controller cycles. + */ +#define READ_PAGE_CMD_CODE 0x7EE0 +#define PROGRAM_PAGE_CMD_CODE 0x7FC0 +#define ERASE_CMD_CODE 0x4EC0 +#define READ_ID_CMD_CODE 0x4804 +#define RESET_CMD_CODE 0x4040 +#define STATUS_READ_CMD_CODE 0x4068 + +/* NFC ECC mode define */ +#define ECC_BYPASS 0 +#define ECC_45_BYTE6 + +/*** Register Mask and bit definitions */ + +/* NFC_FLASH_CMD1 Field */ +#define CMD_BYTE2_MASK 0xFF00 +#define CMD_BYTE2_SHIFT24 + +/* NFC_FLASH_CM2 Field */ +#define CMD_BYTE1_MASK 0xFF00 +#define CMD_BYTE1_SHIFT24 +#define CMD_CODE_MASK 0x0000 +#define CMD_CODE_SHIFT 8 +#define BUFNO_MASK 0x0006 +#define BUFNO_SHIFT1 +#define START_BIT (10) + +/* NFC_COL_ADDR Field */ +#define COL_ADDR_MASK 0x +#define COL_ADDR_SHIFT 0 + +/* NFC_ROW_ADDR Field */ +#define ROW_ADDR_MASK 0x00FF +#define ROW_ADDR_SHIFT 0 +#define ROW_ADDR_CHIP_SEL_RB_MASK 0xF000 +#define ROW_ADDR_CHIP_SEL_RB_SHIFT 28 +#define ROW_ADDR_CHIP_SEL_MASK 0x0F00 +#define ROW_ADDR_CHIP_SEL_SHIFT24 + +/* NFC_FLASH_STATUS2 Field */ +#define STATUS_BYTE1_MASK 0x00FF + +/* NFC_FLASH_CONFIG Field */ +#define CONFIG_ECC_SRAM_ADDR_MASK
[U-Boot] [PATCH v4 0/2] arm: vf610: add NAND flash support
This patch set adds NAND Flash Controller (NFC) support for Freescale Vybrid ARM SoCs (vf610). The driver is based on Bill Pringlemeirs prelineary patch sent in January 2014 to the MTD mailing list: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/226623.html Changes in v4 - Drop preparation patches 1 and 2 since they are already merged upstream - Add memcpy accessor function vf610_nfc_memcpy - Remove disabled code Changes in v3 - Further optimizations in vf610_nfc_send_command(s) to avoid performance hit by additional barriers introduced through using writel/readl - Removed unnecessary barrier and added comment - Use void __iomem * as memory base data type - Set page to -1 on read error to allow reread of pages by the higher layers - Minor style fixes Changes in v2: - Renamed the driver from fsl_nfc to vf610_nfc - Use writel/readl in register access functions - Optimized some register accesses by read/write value only once in code - Use CONFIG_SYS_NAND_SELF_INIT and fix board_nand_init implementation - Removed uncommented code/fixed comments - Add CONFIG_USE_ARCH_MEMCPY for improved NAND performance - Use hweight32 for improved count_written_bits performance - Implement page_read/page_write rather than reuse MTD stacks version Stefan Agner (2): mtd: nand: add Freescale vf610_nfc driver arm: vf610: add NAND support for vf610twr board/freescale/vf610twr/vf610twr.c | 47 ++- configs/vf610twr_defconfig | 2 +- configs/vf610twr_nand_defconfig | 3 + drivers/mtd/nand/Makefile | 1 + drivers/mtd/nand/vf610_nfc.c| 721 include/configs/vf610twr.h | 46 ++- 6 files changed, 815 insertions(+), 5 deletions(-) create mode 100644 configs/vf610twr_nand_defconfig create mode 100644 drivers/mtd/nand/vf610_nfc.c -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 2/2] arm: vf610: add NAND support for vf610twr
This adds NAND support for the Vybrid tower system (TWR-VF65GS10)
provided by the vf610_nfc driver. Full 16-Bit bus width is
supported. Also an aditional config vf610twr_nand is introduced
which gets the environment from NAND. However, booting U-Boot from
NAND is not yet possible due to missing boot configuration block
(BCB).
Signed-off-by: Stefan Agner ste...@agner.ch
---
board/freescale/vf610twr/vf610twr.c | 47 ++---
configs/vf610twr_defconfig | 2 +-
configs/vf610twr_nand_defconfig | 3 +++
include/configs/vf610twr.h | 46 +++-
4 files changed, 93 insertions(+), 5 deletions(-)
create mode 100644 configs/vf610twr_nand_defconfig
diff --git a/board/freescale/vf610twr/vf610twr.c
b/board/freescale/vf610twr/vf610twr.c
index 54a9f2c..4d09796 100644
--- a/board/freescale/vf610twr/vf610twr.c
+++ b/board/freescale/vf610twr/vf610twr.c
@@ -278,6 +278,39 @@ static void setup_iomux_i2c(void)
imx_iomux_v3_setup_multiple_pads(i2c0_pads, ARRAY_SIZE(i2c0_pads));
}
+#ifdef CONFIG_NAND_VF610_NFC
+static void setup_iomux_nfc(void)
+{
+ static const iomux_v3_cfg_t nfc_pads[] = {
+ VF610_PAD_PTD31__NF_IO15,
+ VF610_PAD_PTD30__NF_IO14,
+ VF610_PAD_PTD29__NF_IO13,
+ VF610_PAD_PTD28__NF_IO12,
+ VF610_PAD_PTD27__NF_IO11,
+ VF610_PAD_PTD26__NF_IO10,
+ VF610_PAD_PTD25__NF_IO9,
+ VF610_PAD_PTD24__NF_IO8,
+ VF610_PAD_PTD23__NF_IO7,
+ VF610_PAD_PTD22__NF_IO6,
+ VF610_PAD_PTD21__NF_IO5,
+ VF610_PAD_PTD20__NF_IO4,
+ VF610_PAD_PTD19__NF_IO3,
+ VF610_PAD_PTD18__NF_IO2,
+ VF610_PAD_PTD17__NF_IO1,
+ VF610_PAD_PTD16__NF_IO0,
+ VF610_PAD_PTB24__NF_WE_B,
+ VF610_PAD_PTB25__NF_CE0_B,
+ VF610_PAD_PTB27__NF_RE_B,
+ VF610_PAD_PTC26__NF_RB_B,
+ VF610_PAD_PTC27__NF_ALE,
+ VF610_PAD_PTC28__NF_CLE
+ };
+
+ imx_iomux_v3_setup_multiple_pads(nfc_pads, ARRAY_SIZE(nfc_pads));
+}
+#endif
+
+
static void setup_iomux_qspi(void)
{
static const iomux_v3_cfg_t qspi0_pads[] = {
@@ -354,6 +387,8 @@ static void clock_init(void)
CCM_CCGR7_SDHC1_CTRL_MASK);
clrsetbits_le32(ccm-ccgr9, CCM_REG_CTRL_MASK,
CCM_CCGR9_FEC0_CTRL_MASK | CCM_CCGR9_FEC1_CTRL_MASK);
+ clrsetbits_le32(ccm-ccgr10, CCM_REG_CTRL_MASK,
+ CCM_CCGR10_NFC_CTRL_MASK);
clrsetbits_le32(anadig-pll2_ctrl, ANADIG_PLL2_CTRL_POWERDOWN,
ANADIG_PLL2_CTRL_ENABLE | ANADIG_PLL2_CTRL_DIV_SELECT);
@@ -373,14 +408,17 @@ static void clock_init(void)
CCM_CACRR_IPG_CLK_DIV(1) | CCM_CACRR_BUS_CLK_DIV(2) |
CCM_CACRR_ARM_CLK_DIV(0));
clrsetbits_le32(ccm-cscmr1, CCM_REG_CTRL_MASK,
- CCM_CSCMR1_ESDHC1_CLK_SEL(3) | CCM_CSCMR1_QSPI0_CLK_SEL(3));
+ CCM_CSCMR1_ESDHC1_CLK_SEL(3) | CCM_CSCMR1_QSPI0_CLK_SEL(3) |
+ CCM_CSCMR1_NFC_CLK_SEL(0));
clrsetbits_le32(ccm-cscdr1, CCM_REG_CTRL_MASK,
CCM_CSCDR1_RMII_CLK_EN);
clrsetbits_le32(ccm-cscdr2, CCM_REG_CTRL_MASK,
- CCM_CSCDR2_ESDHC1_EN | CCM_CSCDR2_ESDHC1_CLK_DIV(0));
+ CCM_CSCDR2_ESDHC1_EN | CCM_CSCDR2_ESDHC1_CLK_DIV(0) |
+ CCM_CSCDR2_NFC_EN);
clrsetbits_le32(ccm-cscdr3, CCM_REG_CTRL_MASK,
CCM_CSCDR3_QSPI0_EN | CCM_CSCDR3_QSPI0_DIV(1) |
- CCM_CSCDR3_QSPI0_X2_DIV(1) | CCM_CSCDR3_QSPI0_X4_DIV(3));
+ CCM_CSCDR3_QSPI0_X2_DIV(1) | CCM_CSCDR3_QSPI0_X4_DIV(3) |
+ CCM_CSCDR3_NFC_PRE_DIV(5));
clrsetbits_le32(ccm-cscmr2, CCM_REG_CTRL_MASK,
CCM_CSCMR2_RMII_CLK_SEL(0));
}
@@ -411,6 +449,9 @@ int board_early_init_f(void)
setup_iomux_enet();
setup_iomux_i2c();
setup_iomux_qspi();
+#ifdef CONFIG_NAND_VF610_NFC
+ setup_iomux_nfc();
+#endif
return 0;
}
diff --git a/configs/vf610twr_defconfig b/configs/vf610twr_defconfig
index 10e6432..7de374a 100644
--- a/configs/vf610twr_defconfig
+++ b/configs/vf610twr_defconfig
@@ -1,3 +1,3 @@
-CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=board/freescale/vf610twr/imximage.cfg
+CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=board/freescale/vf610twr/imximage.cfg,ENV_IS_IN_MMC
CONFIG_ARM=y
CONFIG_TARGET_VF610TWR=y
diff --git a/configs/vf610twr_nand_defconfig b/configs/vf610twr_nand_defconfig
new file mode 100644
index 000..e78db26
--- /dev/null
+++ b/configs/vf610twr_nand_defconfig
@@ -0,0 +1,3 @@
+CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=board/freescale/vf610twr/imximage.cfg,ENV_IS_IN_NAND
+CONFIG_ARM=y
+CONFIG_TARGET_VF610TWR=y
diff --git a/include/configs/vf610twr.h b/include/configs/vf610twr.h
index 0342550..6fd0b17 100644
--- a/include/configs/vf610twr.h
+++
[U-Boot] [PATCH] usb: dfu: thor: gadget: Remove dead code
This code is not used anymore in the current DFU implementation and
can be safely removed.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
drivers/usb/gadget/f_dfu.c | 8
drivers/usb/gadget/f_thor.c | 10 --
2 files changed, 18 deletions(-)
diff --git a/drivers/usb/gadget/f_dfu.c b/drivers/usb/gadget/f_dfu.c
index 3e4f029..d040606 100644
--- a/drivers/usb/gadget/f_dfu.c
+++ b/drivers/usb/gadget/f_dfu.c
@@ -81,14 +81,6 @@ static struct usb_descriptor_header *dfu_runtime_descs[] = {
NULL,
};
-static const struct usb_qualifier_descriptor dev_qualifier = {
- .bLength = sizeof dev_qualifier,
- .bDescriptorType = USB_DT_DEVICE_QUALIFIER,
- .bcdUSB = __constant_cpu_to_le16(0x0200),
- .bDeviceClass = USB_CLASS_VENDOR_SPEC,
- .bNumConfigurations = 1,
-};
-
static const char dfu_name[] = Device Firmware Upgrade;
/*
diff --git a/drivers/usb/gadget/f_thor.c b/drivers/usb/gadget/f_thor.c
index c85b0fb..78519fa 100644
--- a/drivers/usb/gadget/f_thor.c
+++ b/drivers/usb/gadget/f_thor.c
@@ -458,16 +458,6 @@ static struct usb_endpoint_descriptor hs_int_desc = {
.bInterval = 0x9,
};
-static struct usb_qualifier_descriptor dev_qualifier = {
- .bLength = sizeof(dev_qualifier),
- .bDescriptorType = USB_DT_DEVICE_QUALIFIER,
-
- .bcdUSB = __constant_cpu_to_le16(0x0200),
- .bDeviceClass = USB_CLASS_VENDOR_SPEC,
-
- .bNumConfigurations = 2,
-};
-
/*
* This attribute vendor descriptor is necessary for correct operation with
* Windows version of THOR download program
--
2.0.0.rc2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/8] add clang support for some ARM boards
Hi Jeroen, On Thu, 11 Sep 2014 13:17:20 +0200, Jeroen Hofstee jer...@myspectrum.nl wrote: Hello Albert, On do, 2014-09-11 at 10:32 +0200, Albert ARIBAUD wrote: On Wed, 10 Sep 2014 20:08:50 +0200, Jeroen Hofstee jer...@myspectrum.nl wrote: Changes since v2: - As Albert pointed out the clang instructions don't work with Debian based binary packages. While I was aware of that it is for a different reason then I thought, it is not that ARM is not enabled as a backend but older versions are a bit more picky on the target argument and don't tolerate a trailing dash to it as used for CROSS_COMPILE etc. The README is updated accordingly. As a side note clang3.5-svn as shipped in Ubuntu is not the 3.5 release but an snapshot of some svn commit and hence explain why the recompiled 3.5 can behave different then the ubuntu clang-3.5. Since it misses some patches, the clang3.5-svn can build less boards then 3.4 or an actual 3.5 release. - While add it, include Masahiro suggestion to also use c++ instead of g++. - Drop dependencies from the cover-letter as they are merged. - only patch 7/8 and 8/8 are reposted. 1..6 are the same as v2. Thanks, tested building rpi_b, it works now. The, tested on versatileqemu out of curiosity and got the following results: 1. clang warns about Unused static functions in common/console.c, namely console_printdevs and console_doenv (1). Why gcc does not flag this? We have -Wall set which is supposed to imply -Wunused-functions. It is a gcc feature, see [1]: Warn whenever a static function is declared but not defined or a _non-inline static function_ is unused. This warning is enabled by -Wall. Ok, I'll assume there is some logic in there, but then, clang does not follow that logic -- so which one is the 'good' one? Or maybe that's the same as the second issue, where... There is also an unused variable warning in disk/part.c28 (block_drvr). I haven't looked at why clang warns about it and not gcc, but it could raise the same question as the functions above. Also a gcc feature, see [2]. The constant is indeed not used. ... apparently, it's a case of trying to balance false positives and missed true issue, and each team has its own view of where to set the limit. :/ (anyway -- here clearly, clang is right in warning us and gcc is wrong in not doing it) 2. clang errors on arch/arm/lib/cache.c:28 for this: asm(0: mrc p15, 0, r15, c7, c10, 3\n\t bne 0b\n : : : memory); and that is a clang mistake, as for ARM926EJS r15 is a valid (albeit quite special semantically) Rd for Test and Clean DCache, see page 2-24. This is the integrated-as complaining (the README tells you to disable it for the moment). The clang folks push UAL hard, up to a point we need to think about minimum gcc version etc. To avoid that, I just left out such changes and just use gas instead, at least for the time being. Below are some changes to compile versatileqemu with llvm integrated-as and gcc/gas. No idea if it actually boots though. Jeroen, do you feel like raising point 2 to the clang/LLVM folks? It is removed on purpose as far as I understood. I don't think they regards it as a bug, see obfuscated patch below. Other than that, the patch series seems to be good. I'll apply it soonish. Thanks, Jeroen ~ mrc p15, 0, r15, c7, c14, 3\n + mrc p15, 0, apsr_nzcv, c7, c14, 3\n Is this is a hack to set the Rd field of the mrc instruction to a value equal to what r15 would have given, but fooling clang by using an unrelated and, in this context, meaningless, symbol instead of r15? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/8] add clang support for some ARM boards
Hi Jeroen, On Wed, 10 Sep 2014 20:08:50 +0200, Jeroen Hofstee jer...@myspectrum.nl wrote: Changes since v2: - As Albert pointed out the clang instructions don't work with Debian based binary packages. While I was aware of that it is for a different reason then I thought, it is not that ARM is not enabled as a backend but older versions are a bit more picky on the target argument and don't tolerate a trailing dash to it as used for CROSS_COMPILE etc. The README is updated accordingly. As a side note clang3.5-svn as shipped in Ubuntu is not the 3.5 release but an snapshot of some svn commit and hence explain why the recompiled 3.5 can behave different then the ubuntu clang-3.5. Since it misses some patches, the clang3.5-svn can build less boards then 3.4 or an actual 3.5 release. - While add it, include Masahiro suggestion to also use c++ instead of g++. - Drop dependencies from the cover-letter as they are merged. - only patch 7/8 and 8/8 are reposted. 1..6 are the same as v2. Series (patches 1-6 of v2, 7 and 8 of v3) applied to u-boot-arm/master, thanks! (still 2 warnings and 5 errors at the top of u-boot-arm/master, but this series does not make things any worse) Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/8] add clang support for some ARM boards
Hi Jeroen, Correction on the asm stuff: On Thu, 11 Sep 2014 13:17:20 +0200, Jeroen Hofstee jer...@myspectrum.nl wrote: clang errors on arch/arm/lib/cache.c:28 for this: asm(0: mrc p15, 0, r15, c7, c10, 3\n\t bne 0b\n : : : memory); and that is a clang mistake, as for ARM926EJS r15 is a valid (albeit quite special semantically) Rd for Test and Clean DCache, see page 2-24. This is the integrated-as complaining (the README tells you to disable it for the moment). The clang folks push UAL hard, up to a point we need to think about minimum gcc version etc. To avoid that, I just left out such changes and just use gas instead, at least for the time being. Below are some changes to compile versatileqemu with llvm integrated-as and gcc/gas. No idea if it actually boots though. Actually, I had the -no-integrated-as then and have just re-tested now, making sure I have it and get the error above. For some reason, despite the -no-integrated-as option, the internal assembler is invoked. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arch/arm: Add individual TLB size support.
Hi li.xi...@freescale.com, On Wed, 10 Sep 2014 03:10:27 +, li.xi...@freescale.com li.xi...@freescale.com wrote: Hi Albert, Subject: Re: [PATCH] arch/arm: Add individual TLB size support. Hi Xiubo, On Mon, 7 Jul 2014 13:19:11 +0800, Xiubo Li li.xi...@freescale.com wrote: This adds CONFIG_TLB_SIZE for individual board, whose TLB size maybe larger than PGTABLE_SIZE. Signed-off-by: Xiubo Li li.xi...@freescale.com --- arch/arm/lib/board.c | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c index dc34190..b7327ce 100644 --- a/arch/arm/lib/board.c +++ b/arch/arm/lib/board.c @@ -353,7 +353,11 @@ void board_init_f(ulong bootflag) #if !(defined(CONFIG_SYS_ICACHE_OFF) defined(CONFIG_SYS_DCACHE_OFF)) /* reserve TLB table */ +#ifdef CONFIG_TLB_SIZE + gd-arch.tlb_size = CONFIG_TLB_SIZE; +#else gd-arch.tlb_size = PGTABLE_SIZE; +#endif addr -= gd-arch.tlb_size; /* round down to next 64 kB limit */ There is no code in current mainline which defines CONFIG_TLB_SIZE; that makes the patch a dead code addition. Yes, this will be used by our LS1 SoC first, and it is still doing The upstream. Then please sumbit this patch as part of the LS1 SoC support series, where the code it creates will actually be used. Besides, what's the point of this as opposed to, e.g., just defining the right PGTABLE_SIZE, or renaming PGTABLE_SIZE as CONFIG_TLB_SIZE? We'll add the LPAE support in uboot and need more space for tlb. I still don't get it. Is gd-arch.tlb_size the size of a page table or of a translation lookahead buffer? Thanks very much, BRs Xiubo Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] fix issue with mmc partition management
On Tue, Sep 02, 2014 at 06:31:21PM -0500, Peter A. Bigot wrote: This series aims at addressing an issue discovered with SPL mode when the MMC device being used lacks an environment partition. http://www.mail-archive.com/meta-ti@yoctoproject.org/msg04320.html includes details on the original failure with this diagnosis: This is a bug in handling mmc_switch_part: what's happening is that the code reconfigures the mmc device to look at the partition on which the environment is to be found, but fails to restore it to reflect the state of the whole device. I.e., the mmc capacity and lba are zero in my case (I have no partition 2 on the uSD card), but mmc_switch_part() returns -ENODEV on the attempt to switch back in fini_mmc_for_env() without also resetting the capacity to what the rest of the system expects. 1/2 has been superseded and there's some questions about 2/2. I'm going to take 2/2 as it fixes a real problem. But Stephen brings up some good questions that do need to be answered. The first thing is that SPL today assumes that it only has one MMC device registered with the subsystem, not 2. This may be reworkable (and maybe not have a big size change) but it's a bit late in this release cycle for that. So what this means is that on some hardware like say Beaglebone Black we either have an SD card (which lacks physical partitions) or we have an eMMC which means the 2 boot partitions and the user partition. The next part of the problem is that we have some cases where we say environment is on eMMC, in one of the boot partitions and we say SPL needs to look at the environment. This situation works fine when we boot from eMMC. Things fail when we use this same binary to boot from SD card. We don't have env and somewhere along the line what fails is that we tried to switch physical partition, noticed a failure, tried to correct said failure but instead end up with our internal representation of the SD/MMC device being invalid. Peter's patch 2/2 corrects this so that when we hit a failure it goes and re-sets that representation. But the next question is wait, why did it get set _wrong_ to start with?. I'm not sure actually. The fini_mmc_for_env call isn't making us be restored to what the physical partition was before, if that's what it was intended to do, it's making sure that we're still on the env partition. Which I'm not sure why it needs to do since we've already read a copy into memory at this point. -- 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 v2 00/40] ARM: tegra: Add PCIe support
Hi Thierry, On Tue, 26 Aug 2014 17:33:48 +0200, Thierry Reding thierry.red...@gmail.com wrote: From: Thierry Reding tred...@nvidia.com Note: this series was split over several custodians (including myself). It might thus get applied piecewise... Shouldn't it rather be assigned a single custodian -with others giving their Ack) and be applied as a whole? And yes, I'm ok with getting all the pieces. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
On Thu, Sep 11, 2014 at 2:46 AM, Wolfgang Denk w...@denx.de wrote: Dear Michal, In message 54112b64.5010...@monstr.eu you wrote: I am not sure if you need to have separate repo to work like this. I am keeping zynq patches in my microblaze repo and sending pull request to Albert (or Tom now) and there is no problem with that. Well, technically of course this works, but it is far from perfect. It works only for those who actually know about this. But anybody looking at the U-Boot site for any zynq related stuff will have hard times to find it. rocketboards.org is our portal. Linux and u-boot currently have repos there. This will be our central place for uboot and Linux. PERIOD! I think it is much better to make this knowledge public information - and one easy way to do this is to have a separate repository for it, which is listed on the custodians page, so everybody looking for it will find all relevant information. In socfpga case I think there are guys from Altera who maintain it. Well, they maintain the stuff at rocketboards.org ; there are efforts on the way to mainline stuff, but the process is not exactly satisfactory. I highly appreciate that Marek volunteers to put efforts in this. Thanks Marek for your volunteer, but we would like to maintain our git repo at rocketboards.org. Dinh As far as I am concerned, I support both Marek's and Masahiro's requests. @ Marek and Masahiro: if we reach an agreement to create such repos, please send me your SSH public keys that shall be used for these. Also, what should the names be - u-boot-socfpga ? And u-boot-uniphier ? [But is there not a chance that Pana- sonic might have other SoCs that might be mainlines? So maybe we should use u-boot-panasonic instead?] 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 Laughter and tears are meant to turn the wheels of the same machinery of sensibility; one is wind-power, and the other water-power. - Oliver Wendell Holmes, Sr. ___ 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 v2 00/40] ARM: tegra: Add PCIe support
On 09/11/2014 10:00 AM, Albert ARIBAUD wrote: Hi Thierry, On Tue, 26 Aug 2014 17:33:48 +0200, Thierry Reding thierry.red...@gmail.com wrote: From: Thierry Reding tred...@nvidia.com Note: this series was split over several custodians (including myself). It might thus get applied piecewise... Shouldn't it rather be assigned a single custodian -with others giving their Ack) and be applied as a whole? And yes, I'm ok with getting all the pieces. Yes, applying it all in one place would probably make sense. IIRC, Simon Glass already applied some of the DT patches early in the series? I CC'd him to check, BTW, Thierry is on vacation at the moment, so I don't expect he'll respond. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
On Wed, Sep 10, 2014 at 6:33 PM, Marek Vasut ma...@denx.de wrote: Hello, I'd be interested in maintaining u-boot-socfpga repository. So far, we don't have a repo for this platform and there is a large flurry of patches flying around without any kind of central point for them. I'd like to get your formal consent for starting this and if you agree, I'd start sending PR to Albert once the repo is in place. I maintain a linux git repo at git://git.rocketboards.org/linux-socfpga-next.git. It would be trivial for us to maintain a u-boot repo at the same location. a large flurry of patches flying around? Funny, that I have not been CCed on any of these patches. Chin-Liang, have you been? Dinh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
On Thursday, September 11, 2014 at 09:46:18 AM, Wolfgang Denk wrote: Dear Michal, In message 54112b64.5010...@monstr.eu you wrote: I am not sure if you need to have separate repo to work like this. I am keeping zynq patches in my microblaze repo and sending pull request to Albert (or Tom now) and there is no problem with that. Well, technically of course this works, but it is far from perfect. It works only for those who actually know about this. But anybody looking at the U-Boot site for any zynq related stuff will have hard times to find it. +1 , having separate u-boot-zynq would be a good idea. It doesn't cost much and greatly improves the organisation. I think it is much better to make this knowledge public information - and one easy way to do this is to have a separate repository for it, which is listed on the custodians page, so everybody looking for it will find all relevant information. In socfpga case I think there are guys from Altera who maintain it. Well, they maintain the stuff at rocketboards.org ; there are efforts on the way to mainline stuff, but the process is not exactly satisfactory. I highly appreciate that Marek volunteers to put efforts in this. As far as I am concerned, I support both Marek's and Masahiro's requests. @ Marek and Masahiro: if we reach an agreement to create such repos, please send me your SSH public keys that shall be used for these. Also, what should the names be - u-boot-socfpga ? U-Boot-socfpga works OK I'd say -- it would cover all of Cyclone and Arria and Stratix socfpga families. Also, my SSH key should already be in position for u-boot-usb and u-boot-pxa ;-) Thank you! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: dfu: thor: gadget: Remove dead code
On Thursday, September 11, 2014 at 03:26:10 PM, Lukasz Majewski wrote: This code is not used anymore in the current DFU implementation and can be safely removed. Signed-off-by: Lukasz Majewski l.majew...@samsung.com How come the compiler didn't spew that this is unused ? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
On Thursday, September 11, 2014 at 06:56:04 AM, Michal Simek wrote: Hi, On 09/11/2014 05:09 AM, Masahiro Yamada wrote: On Thu, 11 Sep 2014 01:33:20 +0200 Marek Vasut ma...@denx.de wrote: Hello, I'd be interested in maintaining u-boot-socfpga repository. So far, we don't have a repo for this platform and there is a large flurry of patches flying around without any kind of central point for them. I'd like to get your formal consent for starting this and if you agree, I'd start sending PR to Albert once the repo is in place. Me too. I'd like to own u-boot-uniphier to collect Panasonic-SoC-specific changes. That would be faster and would not disturb Albert. I am not sure if you need to have separate repo to work like this. I am keeping zynq patches in my microblaze repo and sending pull request to Albert (or Tom now) and there is no problem with that. WD already answered that part, so I'll skip this. Alberts know that and it is working quite well. It is enough to talk to him and that's it. In socfpga case I think there are guys from Altera who maintain it. That's not quite the case, that's why I stepped up. Again, WD explained the rocketboards situation, but we need to improve on the mainline push and this repository should help I hope. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
On Thursday, September 11, 2014 at 09:55:55 AM, Pavel Machek wrote: Hi! In socfpga case I think there are guys from Altera who maintain it. Well, they maintain the stuff at rocketboards.org ; there are efforts on the way to mainline stuff, but the process is not exactly satisfactory. I highly appreciate that Marek volunteers to put efforts in this. As far as I am concerned, I support both Marek's and Masahiro's requests. Repository for socfpga work is a good idea, thanks. One person I have in my email lists is Charles Manning -- he did preloader work before, I put him into cc list. Good idea, thanks! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] e1000: add i211 and unprogrammed i210/i211 support
On Wednesday, September 10, 2014 at 11:18:20 PM, Marcel Ziswiler wrote:
On Mon, 2014-09-08 at 04:07 +0200, Marek Vasut wrote:
Does the network really work with an i21x with unprogrammed iNVM ?
Yes, it actually does work quite nicely.
That's interesting. I never got it working with unprogrammed iNVM, I always had
to program it first.
However I currently still have to patch it additionally as follows:
diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index ce19173..5f9c606 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -1128,7 +1128,7 @@ e1000_swfw_sync_acquire(struct e1000_hw *hw,
uint16_t mask)
if (!timeout) {
DEBUGOUT(Driver can't access resource, SW_FW_SYNC
timeout.\n);
- return -E1000_ERR_SWFW_SYNC;
+// return -E1000_ERR_SWFW_SYNC;
}
swfw_sync |= swmask;
@@ -4378,7 +4378,7 @@ e1000_get_phy_cfg_done(struct e1000_hw *hw)
if (!timeout) {
DEBUGOUT(MNG configuration cycle has not
completed.\n);
- return -E1000_ERR_RESET;
+// return -E1000_ERR_RESET;
}
break;
}
Without doing the above it fails as follows (enabled E1000_DEBUG):
[...]
This is both with programmed (iNVM only, haven't tried external serial
PROM possible on i210) as well as unprogrammed i210 as well as i211
chips on our Apalis T30 modules.
Have you ever seen any such issue?
No, but this looks like the card cannot acquire a semaphore. You might want to
check if there are maybe some pecularities in semaphore handling on this i210
hardware. I remember intel did change the semaphore handling between various
intel ethernet cards.
Wondering whether this is a Tegra PCIe related issue.
I doubt so.
May I ask about your specific platform you tried this on?
The MX6 SabreLite and the MX6 SabreSDP . Both MX6Quad.
Could you send some output of a working session with
E1000_DEBUG enabled? I plan to try it on a Boundary Devices Nitrogen6X
as well as our Apalis iMX6 module as well.
I don't have the setup assembled now and the i210 is not available to me now,
but you should be getting the same result with the N6X. Right now, I only have
the MX6 SabreLite and an another intel NIC available, sorry.
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
On Thursday, September 11, 2014 at 06:14:55 PM, Dinh Nguyen wrote: On Thu, Sep 11, 2014 at 2:46 AM, Wolfgang Denk w...@denx.de wrote: Dear Michal, In message 54112b64.5010...@monstr.eu you wrote: I am not sure if you need to have separate repo to work like this. I am keeping zynq patches in my microblaze repo and sending pull request to Albert (or Tom now) and there is no problem with that. Well, technically of course this works, but it is far from perfect. It works only for those who actually know about this. But anybody looking at the U-Boot site for any zynq related stuff will have hard times to find it. rocketboards.org is our portal. Linux and u-boot currently have repos there. I'm OK with this. This will be our central place for uboot and Linux. PERIOD! I am OK with this as well. But I want to use mainline U-Boot on my board, which I cannot seem to find on the rocketboards website. I only see an ancient 2013.01.01 and I don't see anyone feeding the rocketboards patches into mainline either. Charles and Pavel have been a great help so far in sending U-Boot patches for SoCFPGA into mainline, but so far we lack coordination there. Thus, I decided to take that up and collect all their effort so they're not lost. That said, I'd be glad if someone from Altera would step up and work on the mainline support for SoCFPGA properly, pick the patches and maintain the repository. I think it is much better to make this knowledge public information - and one easy way to do this is to have a separate repository for it, which is listed on the custodians page, so everybody looking for it will find all relevant information. In socfpga case I think there are guys from Altera who maintain it. Well, they maintain the stuff at rocketboards.org ; there are efforts on the way to mainline stuff, but the process is not exactly satisfactory. I highly appreciate that Marek volunteers to put efforts in this. Thanks Marek for your volunteer, but we would like to maintain our git repo at rocketboards.org. I am not asking you to stop working on your repository, please do not misunderstand my intention. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7] ARM: sunxi: Fix build break when CONFIG_USB_EHCI is not defined
Hi Chen, On 09/11/2014 07:07 PM, Chen-Yu Tsai wrote: Hi Ian, Hans, On Mon, Sep 8, 2014 at 9:28 PM, Chen-Yu Tsai w...@csie.org wrote: BOOT_TARGET_DEVICES includes USB unconditionally. This breaks when CONFIG_CMD_USB is not defined. Use a secondary macro to conditionally include it when CONFIG_EHCI is enabled, as we do for CONFIG_AHCI. The other patches are for the next release, but maybe this fix could go into 2014.10? I agree that this is a benign bug fix, but since we don't have any boards not setting CONFIG_EHCI atm I don't really see the value for getting it into 2014.10. Regards, Hans Thanks ChenYu Signed-off-by: Chen-Yu Tsai w...@csie.org --- include/configs/sunxi-common.h | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 1d947d7..a31656e 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -233,10 +233,16 @@ #define BOOT_TARGET_DEVICES_SCSI(func) #endif +#ifdef CONFIG_USB_EHCI +#define BOOT_TARGET_DEVICES_USB(func) func(USB, usb, 0) +#else +#define BOOT_TARGET_DEVICES_USB(func) +#endif + #define BOOT_TARGET_DEVICES(func) \ func(MMC, mmc, 0) \ BOOT_TARGET_DEVICES_SCSI(func) \ - func(USB, usb, 0) \ + BOOT_TARGET_DEVICES_USB(func) \ func(PXE, pxe, na) \ func(DHCP, dhcp, na) -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
On Thu, Sep 11, 2014 at 11:14:55AM -0500, Dinh Nguyen wrote: On Thu, Sep 11, 2014 at 2:46 AM, Wolfgang Denk w...@denx.de wrote: Dear Michal, In message 54112b64.5010...@monstr.eu you wrote: I am not sure if you need to have separate repo to work like this. I am keeping zynq patches in my microblaze repo and sending pull request to Albert (or Tom now) and there is no problem with that. Well, technically of course this works, but it is far from perfect. It works only for those who actually know about this. But anybody looking at the U-Boot site for any zynq related stuff will have hard times to find it. rocketboards.org is our portal. Linux and u-boot currently have repos there. This will be our central place for uboot and Linux. PERIOD! Alright. The sunxi community has recently made some great strides in getting things merged from their tree into mainline (And again, yy, thanks for the hard work there guys!). What is the plan to get things up-lifted and merged to mainline for this SoC? -- 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] u-boot-socfpga repository
On Thursday, September 11, 2014 at 06:01:31 PM, Dinh Nguyen wrote: On Wed, Sep 10, 2014 at 6:33 PM, Marek Vasut ma...@denx.de wrote: Hello, I'd be interested in maintaining u-boot-socfpga repository. So far, we don't have a repo for this platform and there is a large flurry of patches flying around without any kind of central point for them. I'd like to get your formal consent for starting this and if you agree, I'd start sending PR to Albert once the repo is in place. I maintain a linux git repo at git://git.rocketboards.org/linux-socfpga-next.git. It would be trivial for us to maintain a u-boot repo at the same location. The preferred way in the mainline U-Boot development is to have all the repositories in the same place, that is, git.denx.de git server. a large flurry of patches flying around? Funny, that I have not been CCed on any of these patches. Chin-Liang, have you been? I think. Mr. See was on CC for all the patches Pavel sent at least. I'll keep you on CC as well. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] mmc: restore capacity when switching to partition 0
On Tue, Sep 02, 2014 at 06:31:23PM -0500, Peter A. Bigot wrote: The capacity and lba for an MMC device with part_num 0 reflects the whole device. When mmc_switch_part() successfully switches to a partition, the capacity is changed to that partition. As partition 0 does not physically exist, attempts to switch back to the whole device will indicate an error, but the capacity setting for the whole device must still be restored to match the partition. Signed-off-by: Peter A. Bigot p...@pabigot.com Tested-by: Tom Rini tr...@ti.com -- 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 v2 1/2] usb: eth: add ASIX AX88179 DRIVER
On Thursday, September 11, 2014 at 10:33:57 AM, René Griessl wrote: [...] I didn't look deep enough. The 88179 driver is a completely separate driver, not sharing any code what-so-ever with the other ASIX driver, yes ? The USB read and write cmd functions are similar and the probe function is the same. So they are sharing 6% of code. What do you have in mind? Do you want to build one driver supporting all devices? Yes, but if that's not easily doable, just like you point out, then I am fine with two drivers. Thank you! [..] Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/2] mtd: nand: add Freescale vf610_nfc driver
On 11 Sep 2014, ste...@agner.ch wrote: This adds initial support for Freescale NFC (NAND Flash Controller) found in ARM Vybrid SoC's, Power Architecture MPC5125 and others. The driver is called vf610_nfc since this is the first supported and tested hardware platform supported by the driver. Signed-off-by: Stefan Agner ste...@agner.ch Acked-by: Bill Pringlemeir bpringlem...@nbsps.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7] ARM: sunxi: Fix build break when CONFIG_USB_EHCI is not defined
On Thu, 2014-09-11 at 19:19 +0200, Hans de Goede wrote: Hi Chen, On 09/11/2014 07:07 PM, Chen-Yu Tsai wrote: Hi Ian, Hans, On Mon, Sep 8, 2014 at 9:28 PM, Chen-Yu Tsai w...@csie.org wrote: BOOT_TARGET_DEVICES includes USB unconditionally. This breaks when CONFIG_CMD_USB is not defined. Use a secondary macro to conditionally include it when CONFIG_EHCI is enabled, as we do for CONFIG_AHCI. The other patches are for the next release, but maybe this fix could go into 2014.10? I agree that this is a benign bug fix, but since we don't have any boards not setting CONFIG_EHCI atm I don't really see the value for getting it into 2014.10. FWIW I was planning on putting the whole series in #next until the next merge window as soon as I find a some spare moments to look through it (sorry, might take me a few more days, I'm travelling at the w/e). Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: dfu: thor: gadget: Remove dead code
Hello Marek, On 11-09-14 17:47, Marek Vasut wrote: On Thursday, September 11, 2014 at 03:26:10 PM, Lukasz Majewski wrote: This code is not used anymore in the current DFU implementation and can be safely removed. Signed-off-by: Lukasz Majewski l.majew...@samsung.com How come the compiler didn't spew that this is unused ? gcc feature, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13029. Regards, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/40] ARM: tegra: Add PCIe support
Hi, On 11 September 2014 10:17, Stephen Warren swar...@wwwdotorg.org wrote: On 09/11/2014 10:00 AM, Albert ARIBAUD wrote: Hi Thierry, On Tue, 26 Aug 2014 17:33:48 +0200, Thierry Reding thierry.red...@gmail.com wrote: From: Thierry Reding tred...@nvidia.com Note: this series was split over several custodians (including myself). It might thus get applied piecewise... Shouldn't it rather be assigned a single custodian -with others giving their Ack) and be applied as a whole? And yes, I'm ok with getting all the pieces. Yes, applying it all in one place would probably make sense. IIRC, Simon Glass already applied some of the DT patches early in the series? I CC'd him to check, Yes I applied the fdt patches to u-boot-fdt/next. I can do a pull request to ARM if that helps, or you can just grab them. BTW, Thierry is on vacation at the moment, so I don't expect he'll respond. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/8] add clang support for some ARM boards
Hello Albert, On 11-09-14 17:43, Albert ARIBAUD wrote: Hi Jeroen, Correction on the asm stuff: On Thu, 11 Sep 2014 13:17:20 +0200, Jeroen Hofstee jer...@myspectrum.nl wrote: clang errors on arch/arm/lib/cache.c:28 for this: asm(0: mrc p15, 0, r15, c7, c10, 3\n\t bne 0b\n : : : memory); and that is a clang mistake, as for ARM926EJS r15 is a valid (albeit quite special semantically) Rd for Test and Clean DCache, see page 2-24. This is the integrated-as complaining (the README tells you to disable it for the moment). The clang folks push UAL hard, up to a point we need to think about minimum gcc version etc. To avoid that, I just left out such changes and just use gas instead, at least for the time being. Below are some changes to compile versatileqemu with llvm integrated-as and gcc/gas. No idea if it actually boots though. Actually, I had the -no-integrated-as then and have just re-tested now, making sure I have it and get the error above. For some reason, despite the -no-integrated-as option, the internal assembler is invoked. You don't happen to be testing with the clang 3.5 minus a half / non release (svn 201651) right? As I mentioned before, it will do you more harm then good. I cannot reproduce this with an 3.4 nor 3.5 release. Regards, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: dfu: thor: gadget: Remove dead code
On Thursday, September 11, 2014 at 09:17:57 PM, Jeroen Hofstee wrote: Hello Marek, On 11-09-14 17:47, Marek Vasut wrote: On Thursday, September 11, 2014 at 03:26:10 PM, Lukasz Majewski wrote: This code is not used anymore in the current DFU implementation and can be safely removed. Signed-off-by: Lukasz Majewski l.majew...@samsung.com How come the compiler didn't spew that this is unused ? gcc feature, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13029. I see, thanks for pointing this out! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/8] add clang support for some ARM boards
Hello Albert,
On 11-09-14 15:31, Albert ARIBAUD wrote:
Thanks, tested building rpi_b, it works now.
The, tested on versatileqemu out of curiosity and got the following
results:
1.
clang warns about Unused static functions in common/console.c, namely
console_printdevs and console_doenv (1). Why gcc does not flag this?
We have -Wall set which is supposed to imply -Wunused-functions.
It is a gcc feature, see [1]: Warn whenever a static function is
declared but not defined or a _non-inline static function_ is unused.
This warning is enabled by -Wall.
Ok, I'll assume there is some logic in there, but then, clang does not
follow that logic -- so which one is the 'good' one? Or maybe that's
the same as the second issue, where...
well I don't know the details, but the compiler should not emit a
warning if the static inline came from a header file, perhaps that
is motivation behind it. Anyway I have a branch with 60 patches
or so fixing warnings, don't bother too much about them for the
time being.
2.
clang errors on arch/arm/lib/cache.c:28 for this:
asm(0: mrc p15, 0, r15, c7, c10, 3\n\t bne 0b\n : : : memory);
and that is a clang mistake, as for ARM926EJS r15 is a valid (albeit
quite special semantically) Rd for Test and Clean DCache, see page 2-24.
This is the integrated-as complaining (the README tells you to disable
it for the moment). The clang folks push UAL hard, up to a point we need
to think about minimum gcc version etc. To avoid that, I just left out
such changes and just use gas instead, at least for the time being.
Below are some changes to compile versatileqemu with llvm integrated-as
and gcc/gas. No idea if it actually boots though.
[..]
~ mrc p15, 0, r15, c7, c14, 3\n
+ mrc p15, 0, apsr_nzcv, c7, c14, 3\n
Is this is a hack to set the Rd field of the mrc instruction to a value
equal to what r15 would have given, but fooling clang by using an
unrelated and, in this context, meaningless, symbol instead of r15?
Nope, it is UAL syntax, binutils agrees:
arm-linux-gnueabi-objdump -S u-boot
flush_dcache:
mrc p15, 0, r15, c7, c10, 3
10320: ee17ff7amrc 15, 0, APSR_nzcv, cr7, cr10, {3}
Clang is just pushing it a bit harder. I have a branch for that too,
but as said, I will let it bit-rot for a while, since that would require
about minimal gcc versions and other boring stuff.
Regards,
Jeroen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] driver/ddr/fsl: Fix DDR4 driver
When accumulated ECC is enabled, the DQ_MAP for ECC[4:7] needs to be set
to 0, i.e. 0-0, 1-1, etc., required by controller logic, even these pins
are not actually connected.
Also fix a bug when reading from DDR register to use proper accessor for
correct endianess.
Signed-off-by: York Sun york...@freescale.com
---
drivers/ddr/fsl/ctrl_regs.c|9 +++--
drivers/ddr/fsl/fsl_ddr_gen4.c |3 +--
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/ddr/fsl/ctrl_regs.c b/drivers/ddr/fsl/ctrl_regs.c
index d9cac22..f3635ed 100644
--- a/drivers/ddr/fsl/ctrl_regs.c
+++ b/drivers/ddr/fsl/ctrl_regs.c
@@ -1886,9 +1886,12 @@ static void set_timing_cfg_9(fsl_ddr_cfg_regs_t *ddr)
debug(FSLDDR: timing_cfg_9 = 0x%08x\n, ddr-timing_cfg_9);
}
+/* This function needs to be called after set_ddr_sdram_cfg() is called */
static void set_ddr_dq_mapping(fsl_ddr_cfg_regs_t *ddr,
const dimm_params_t *dimm_params)
{
+ unsigned int acc_ecc_en = (ddr-ddr_sdram_cfg 2) 0x1;
+
ddr-dq_map_0 = ((dimm_params-dq_mapping[0] 0x3F) 26) |
((dimm_params-dq_mapping[1] 0x3F) 20) |
((dimm_params-dq_mapping[2] 0x3F) 14) |
@@ -1907,9 +1910,11 @@ static void set_ddr_dq_mapping(fsl_ddr_cfg_regs_t *ddr,
((dimm_params-dq_mapping[15] 0x3F) 8) |
((dimm_params-dq_mapping[16] 0x3F) 2);
+ /* dq_map for ECC[4:7] is set to 0 if accumulated ECC is enabled */
ddr-dq_map_3 = ((dimm_params-dq_mapping[17] 0x3F) 26) |
((dimm_params-dq_mapping[8] 0x3F) 20) |
- ((dimm_params-dq_mapping[9] 0x3F) 14) |
+ (acc_ecc_en ? 0 :
+(dimm_params-dq_mapping[9] 0x3F) 14) |
dimm_params-dq_mapping_ors;
debug(FSLDDR: dq_map_0 = 0x%08x\n, ddr-dq_map_0);
@@ -2276,7 +2281,7 @@ compute_fsl_memctl_config_regs(const memctl_options_t
*popts,
if (ip_rev 0x40400)
unq_mrs_en = 1;
- if (ip_rev 0x40700)
+ if ((ip_rev 0x40700) (popts-cswl_override != 0))
ddr-debug[18] = popts-cswl_override;
set_ddr_sdram_cfg_2(ddr, popts, unq_mrs_en);
diff --git a/drivers/ddr/fsl/fsl_ddr_gen4.c b/drivers/ddr/fsl/fsl_ddr_gen4.c
index bfc76b3..e024db9 100644
--- a/drivers/ddr/fsl/fsl_ddr_gen4.c
+++ b/drivers/ddr/fsl/fsl_ddr_gen4.c
@@ -216,7 +216,7 @@ step2:
* For example, 2GB on 666MT/s 64-bit bus takes about 402ms
* Let's wait for 800ms
*/
- bus_width = 3 - ((ddr-sdram_cfg SDRAM_CFG_DBW_MASK)
+ bus_width = 3 - ((ddr_in32(ddr-sdram_cfg) SDRAM_CFG_DBW_MASK)
SDRAM_CFG_DBW_SHIFT);
timeout = ((total_gb_size_per_controller (6 - bus_width)) * 100 /
(get_ddr_freq(0) 20)) 2;
@@ -233,5 +233,4 @@ step2:
if (timeout = 0)
printf(Waiting for D_INIT timeout. Memory may not work.\n);
-
}
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] board/ls1021aqds_d4: Add DDR4 support
LS1021AQDS has a variant with DDR4 slot. This patch adds a new target for
this variant and enables DDR4 support. RAW timing parameters are not added
for DDR4. The board timing parameters are only tuned for single-rank 1600
and 1800MT/s with Micron DIMM 9ASF51272AZ-2G1A1 due to availability.
Signed-off-by: York Sun york...@freescale.com
---
arch/arm/Kconfig |3 +++
arch/arm/include/asm/arch-ls102xa/config.h |5 +
board/freescale/ls1021aqds/Kconfig |2 +-
board/freescale/ls1021aqds/ddr.c |9 -
board/freescale/ls1021aqds/ddr.h | 10 ++
...s_nor_defconfig = ls1021aqds_d4_nor_defconfig} |1 +
include/configs/ls1021aqds.h |4 +++-
7 files changed, 31 insertions(+), 3 deletions(-)
copy configs/{ls1021aqds_nor_defconfig = ls1021aqds_d4_nor_defconfig} (50%)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 11143a8..49c4b5a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -473,6 +473,9 @@ config TARGET_LS2085A_SIMU
config TARGET_LS1021AQDS
bool Support ls1021aqds_nor
+config TARGET_LS1021AQDS_D4
+ bool Support ls1021aqds_nor with DDR4
+
config TARGET_LS1021ATWR
bool Support ls1021atwr_nor
diff --git a/arch/arm/include/asm/arch-ls102xa/config.h
b/arch/arm/include/asm/arch-ls102xa/config.h
index ed78c33..a500b5b 100644
--- a/arch/arm/include/asm/arch-ls102xa/config.h
+++ b/arch/arm/include/asm/arch-ls102xa/config.h
@@ -50,7 +50,11 @@
#ifdef CONFIG_DDR_SPD
#define CONFIG_SYS_FSL_DDR_BE
#define CONFIG_VERY_BIG_RAM
+#ifdef CONFIG_SYS_FSL_DDR4
+#define CONFIG_SYS_FSL_DDRC_GEN4
+#else
#define CONFIG_SYS_FSL_DDRC_ARM_GEN3
+#endif
#define CONFIG_SYS_FSL_DDR
#define CONFIG_SYS_LS1_DDR_BLOCK1_SIZE ((phys_size_t)2 30)
#define CONFIG_MAX_MEM_MAPPED CONFIG_SYS_LS1_DDR_BLOCK1_SIZE
@@ -71,6 +75,7 @@
#define CONFIG_MAX_CPUS2
#define CONFIG_SYS_FSL_IFC_BANK_COUNT 8
#define CONFIG_NUM_DDR_CONTROLLERS 1
+#define CONFIG_SYS_FSL_DDR_VER FSL_DDR_VER_5_0
#else
#error SoC not defined
#endif
diff --git a/board/freescale/ls1021aqds/Kconfig
b/board/freescale/ls1021aqds/Kconfig
index c28bd2b..1f60d95 100644
--- a/board/freescale/ls1021aqds/Kconfig
+++ b/board/freescale/ls1021aqds/Kconfig
@@ -1,4 +1,4 @@
-if TARGET_LS1021AQDS
+if TARGET_LS1021AQDS || TARGET_LS1021AQDS_D4
config SYS_CPU
string
diff --git a/board/freescale/ls1021aqds/ddr.c b/board/freescale/ls1021aqds/ddr.c
index 679c654..5898e33 100644
--- a/board/freescale/ls1021aqds/ddr.c
+++ b/board/freescale/ls1021aqds/ddr.c
@@ -79,7 +79,6 @@ found:
*/
popts-wrlvl_override = 1;
popts-wrlvl_sample = 0xf;
- popts-cswl_override = DDR_CSWL_CS0;
/*
* Rtt and Rtt_WR override
@@ -89,9 +88,17 @@ found:
/* Enable ZQ calibration */
popts-zq_en = 1;
+#ifdef CONFIG_SYS_FSL_DDR4
+ popts-ddr_cdr1 = DDR_CDR1_DHC_EN | DDR_CDR1_ODT(DDR_CDR_ODT_80ohm);
+ popts-ddr_cdr2 = DDR_CDR2_ODT(DDR_CDR_ODT_80ohm) |
+ DDR_CDR2_VREF_OVRD(70); /* Vref = 70% */
+#else
+ popts-cswl_override = DDR_CSWL_CS0;
+
/* DHC_EN =1, ODT = 75 Ohm */
popts-ddr_cdr1 = DDR_CDR1_DHC_EN | DDR_CDR1_ODT(DDR_CDR_ODT_75ohm);
popts-ddr_cdr2 = DDR_CDR2_ODT(DDR_CDR_ODT_75ohm);
+#endif
}
#ifdef CONFIG_SYS_DDR_RAW_TIMING
diff --git a/board/freescale/ls1021aqds/ddr.h b/board/freescale/ls1021aqds/ddr.h
index 16d87cb..f819c99 100644
--- a/board/freescale/ls1021aqds/ddr.h
+++ b/board/freescale/ls1021aqds/ddr.h
@@ -30,6 +30,13 @@ static const struct board_specific_parameters udimm0[] = {
* num| hi| rank| clk| wrlvl | wrlvl | wrlvl | cpo |wrdata|2T
* ranks| mhz| GB |adjst| start | ctl2| ctl3 | |delay |
*/
+#ifdef CONFIG_SYS_FSL_DDR4
+ {2, 1666, 0, 4, 7, 0x0808090B, 0x0C0D0E0A,},
+ {2, 1900, 0, 4, 6, 0x08080A0C, 0x0D0E0F0A,},
+ {1, 1666, 0, 4, 8, 0x090A0B0B, 0x0C0D0E0C,},
+ {1, 1900, 0, 4, 9, 0x0A0B0C0B, 0x0D0E0F0D,},
+ {1, 2200, 0, 4,10, 0x0B0C0D0C, 0x0E0F110E,},
+#elif defined(CONFIG_SYS_FSL_DDR3)
{1, 833, 1, 6, 8, 0x06060607, 0x08080807, 0x1f,2, 0},
{1, 1350, 1, 6, 8, 0x0708080A, 0x0A0B0C09, 0x1f,2, 0},
{1, 833, 2, 6, 8, 0x06060607, 0x08080807, 0x1f,2, 0},
@@ -39,6 +46,9 @@ static const struct board_specific_parameters udimm0[] = {
{2, 1350, 0, 6, 8, 0x0708080A, 0x0A0B0C09, 0x1f,2, 0},
{2, 1666, 4, 4, 0xa, 0x0B08090C, 0x0B0E0D0A, 0x1f,2, 0},
{2, 1666, 0, 4, 0xa, 0x0B08090C, 0x0B0E0D0A, 0x1f,2, 0},
+#else
+#error DDR type not defined
+#endif
{}
};
diff --git a/configs/ls1021aqds_nor_defconfig
b/configs/ls1021aqds_d4_nor_defconfig
similarity index 50%
copy from
Re: [U-Boot] [PATCH 2/2] board/ls1021aqds_d4: Add DDR4 support
On Thu, Sep 11, 2014 at 5:32 PM, York Sun york...@freescale.com wrote:
LS1021AQDS has a variant with DDR4 slot. This patch adds a new target for
this variant and enables DDR4 support. RAW timing parameters are not added
for DDR4. The board timing parameters are only tuned for single-rank 1600
and 1800MT/s with Micron DIMM 9ASF51272AZ-2G1A1 due to availability.
Signed-off-by: York Sun york...@freescale.com
---
arch/arm/Kconfig |3 +++
arch/arm/include/asm/arch-ls102xa/config.h |5 +
board/freescale/ls1021aqds/Kconfig |2 +-
board/freescale/ls1021aqds/ddr.c |9 -
board/freescale/ls1021aqds/ddr.h | 10 ++
...s_nor_defconfig = ls1021aqds_d4_nor_defconfig} |1 +
include/configs/ls1021aqds.h |4 +++-
7 files changed, 31 insertions(+), 3 deletions(-)
copy configs/{ls1021aqds_nor_defconfig = ls1021aqds_d4_nor_defconfig} (50%)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 11143a8..49c4b5a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -473,6 +473,9 @@ config TARGET_LS2085A_SIMU
config TARGET_LS1021AQDS
bool Support ls1021aqds_nor
+config TARGET_LS1021AQDS_D4
+ bool Support ls1021aqds_nor with DDR4
Use _DDR4 for the target, easier to understand when reading later.
config TARGET_LS1021ATWR
bool Support ls1021atwr_nor
diff --git a/arch/arm/include/asm/arch-ls102xa/config.h
b/arch/arm/include/asm/arch-ls102xa/config.h
index ed78c33..a500b5b 100644
--- a/arch/arm/include/asm/arch-ls102xa/config.h
+++ b/arch/arm/include/asm/arch-ls102xa/config.h
@@ -50,7 +50,11 @@
#ifdef CONFIG_DDR_SPD
#define CONFIG_SYS_FSL_DDR_BE
#define CONFIG_VERY_BIG_RAM
+#ifdef CONFIG_SYS_FSL_DDR4
+#define CONFIG_SYS_FSL_DDRC_GEN4
+#else
#define CONFIG_SYS_FSL_DDRC_ARM_GEN3
+#endif
#define CONFIG_SYS_FSL_DDR
#define CONFIG_SYS_LS1_DDR_BLOCK1_SIZE ((phys_size_t)2 30)
#define CONFIG_MAX_MEM_MAPPED CONFIG_SYS_LS1_DDR_BLOCK1_SIZE
@@ -71,6 +75,7 @@
#define CONFIG_MAX_CPUS2
#define CONFIG_SYS_FSL_IFC_BANK_COUNT 8
#define CONFIG_NUM_DDR_CONTROLLERS 1
+#define CONFIG_SYS_FSL_DDR_VER FSL_DDR_VER_5_0
#else
#error SoC not defined
#endif
diff --git a/board/freescale/ls1021aqds/Kconfig
b/board/freescale/ls1021aqds/Kconfig
index c28bd2b..1f60d95 100644
--- a/board/freescale/ls1021aqds/Kconfig
+++ b/board/freescale/ls1021aqds/Kconfig
@@ -1,4 +1,4 @@
-if TARGET_LS1021AQDS
+if TARGET_LS1021AQDS || TARGET_LS1021AQDS_D4
Same here.
config SYS_CPU
string
diff --git a/board/freescale/ls1021aqds/ddr.c
b/board/freescale/ls1021aqds/ddr.c
index 679c654..5898e33 100644
--- a/board/freescale/ls1021aqds/ddr.c
+++ b/board/freescale/ls1021aqds/ddr.c
@@ -79,7 +79,6 @@ found:
*/
popts-wrlvl_override = 1;
popts-wrlvl_sample = 0xf;
- popts-cswl_override = DDR_CSWL_CS0;
/*
* Rtt and Rtt_WR override
@@ -89,9 +88,17 @@ found:
/* Enable ZQ calibration */
popts-zq_en = 1;
+#ifdef CONFIG_SYS_FSL_DDR4
+ popts-ddr_cdr1 = DDR_CDR1_DHC_EN | DDR_CDR1_ODT(DDR_CDR_ODT_80ohm);
+ popts-ddr_cdr2 = DDR_CDR2_ODT(DDR_CDR_ODT_80ohm) |
+ DDR_CDR2_VREF_OVRD(70); /* Vref = 70% */
+#else
+ popts-cswl_override = DDR_CSWL_CS0;
+
/* DHC_EN =1, ODT = 75 Ohm */
popts-ddr_cdr1 = DDR_CDR1_DHC_EN | DDR_CDR1_ODT(DDR_CDR_ODT_75ohm);
popts-ddr_cdr2 = DDR_CDR2_ODT(DDR_CDR_ODT_75ohm);
+#endif
}
#ifdef CONFIG_SYS_DDR_RAW_TIMING
diff --git a/board/freescale/ls1021aqds/ddr.h
b/board/freescale/ls1021aqds/ddr.h
index 16d87cb..f819c99 100644
--- a/board/freescale/ls1021aqds/ddr.h
+++ b/board/freescale/ls1021aqds/ddr.h
@@ -30,6 +30,13 @@ static const struct board_specific_parameters udimm0[] = {
* num| hi| rank| clk| wrlvl | wrlvl | wrlvl | cpo
|wrdata|2T
* ranks| mhz| GB |adjst| start | ctl2| ctl3 | |delay |
*/
+#ifdef CONFIG_SYS_FSL_DDR4
+ {2, 1666, 0, 4, 7, 0x0808090B, 0x0C0D0E0A,},
+ {2, 1900, 0, 4, 6, 0x08080A0C, 0x0D0E0F0A,},
+ {1, 1666, 0, 4, 8, 0x090A0B0B, 0x0C0D0E0C,},
+ {1, 1900, 0, 4, 9, 0x0A0B0C0B, 0x0D0E0F0D,},
+ {1, 2200, 0, 4,10, 0x0B0C0D0C, 0x0E0F110E,},
+#elif defined(CONFIG_SYS_FSL_DDR3)
{1, 833, 1, 6, 8, 0x06060607, 0x08080807, 0x1f,2, 0},
{1, 1350, 1, 6, 8, 0x0708080A, 0x0A0B0C09, 0x1f,2, 0},
{1, 833, 2, 6, 8, 0x06060607, 0x08080807, 0x1f,2, 0},
@@ -39,6 +46,9 @@ static const struct board_specific_parameters udimm0[] = {
{2, 1350, 0, 6, 8, 0x0708080A, 0x0A0B0C09, 0x1f,2, 0},
{2, 1666, 4, 4, 0xa, 0x0B08090C, 0x0B0E0D0A, 0x1f,2,
Re: [U-Boot] [PATCH 2/2] board/ls1021aqds_d4: Add DDR4 support
On 09/11/2014 03:26 PM, Otavio Salvador wrote:
On Thu, Sep 11, 2014 at 5:32 PM, York Sun york...@freescale.com wrote:
LS1021AQDS has a variant with DDR4 slot. This patch adds a new target for
this variant and enables DDR4 support. RAW timing parameters are not added
for DDR4. The board timing parameters are only tuned for single-rank 1600
and 1800MT/s with Micron DIMM 9ASF51272AZ-2G1A1 due to availability.
Signed-off-by: York Sun york...@freescale.com
---
arch/arm/Kconfig |3 +++
arch/arm/include/asm/arch-ls102xa/config.h |5 +
board/freescale/ls1021aqds/Kconfig |2 +-
board/freescale/ls1021aqds/ddr.c |9 -
board/freescale/ls1021aqds/ddr.h | 10 ++
...s_nor_defconfig = ls1021aqds_d4_nor_defconfig} |1 +
include/configs/ls1021aqds.h |4 +++-
7 files changed, 31 insertions(+), 3 deletions(-)
copy configs/{ls1021aqds_nor_defconfig = ls1021aqds_d4_nor_defconfig} (50%)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 11143a8..49c4b5a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -473,6 +473,9 @@ config TARGET_LS2085A_SIMU
config TARGET_LS1021AQDS
bool Support ls1021aqds_nor
+config TARGET_LS1021AQDS_D4
+ bool Support ls1021aqds_nor with DDR4
Use _DDR4 for the target, easier to understand when reading later.
I accept this suggestion but will wait for the final name of the board. I used
_D4 following T1040QDS_D4 because that board was named so.
York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
On 09/11/2014 11:51 AM, Marek Vasut wrote: On Thursday, September 11, 2014 at 06:14:55 PM, Dinh Nguyen wrote: On Thu, Sep 11, 2014 at 2:46 AM, Wolfgang Denk w...@denx.de wrote: Dear Michal, In message 54112b64.5010...@monstr.eu you wrote: I am not sure if you need to have separate repo to work like this. I am keeping zynq patches in my microblaze repo and sending pull request to Albert (or Tom now) and there is no problem with that. Well, technically of course this works, but it is far from perfect. It works only for those who actually know about this. But anybody looking at the U-Boot site for any zynq related stuff will have hard times to find it. rocketboards.org is our portal. Linux and u-boot currently have repos there. I'm OK with this. This will be our central place for uboot and Linux. PERIOD! I am OK with this as well. But I want to use mainline U-Boot on my board, which I cannot seem to find on the rocketboards website. I only see an ancient 2013.01.01 and I don't see anyone feeding the rocketboards patches into mainline either. Charles and Pavel have been a great help so far in sending U-Boot patches for SoCFPGA into mainline, but so far we lack coordination there. Thus, I decided to take that up and collect all their effort so they're not lost. That said, I'd be glad if someone from Altera would step up and work on the mainline support for SoCFPGA properly, pick the patches and maintain the repository. Honestly, I have not seen any patches for SOCFPGA come my way. I don't think I would ignore them if they did. Please CC me and Vince on any future uboot support for SOCFPGA. We will make sure they are collected and posted to u-boot-socfpga-next.git. Like everything, there's only so many hours in a day. I am fully aware of our lack of uboot mainline support. It's very high on our list, but that darn Linux thing sometimes get in the way. We have added an additional resource internally, Vince Bridgers, to help us mainline u-boot support. I think it is much better to make this knowledge public information - and one easy way to do this is to have a separate repository for it, which is listed on the custodians page, so everybody looking for it will find all relevant information. In socfpga case I think there are guys from Altera who maintain it. Well, they maintain the stuff at rocketboards.org ; there are efforts on the way to mainline stuff, but the process is not exactly satisfactory. I highly appreciate that Marek volunteers to put efforts in this. Thanks Marek for your volunteer, but we would like to maintain our git repo at rocketboards.org. I am not asking you to stop working on your repository, please do not misunderstand my intention. Not at all. Dinh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-socfpga repository
On 09/11/2014 12:14 PM, Tom Rini wrote: On Thu, Sep 11, 2014 at 11:14:55AM -0500, Dinh Nguyen wrote: On Thu, Sep 11, 2014 at 2:46 AM, Wolfgang Denk w...@denx.de wrote: Dear Michal, In message 54112b64.5010...@monstr.eu you wrote: I am not sure if you need to have separate repo to work like this. I am keeping zynq patches in my microblaze repo and sending pull request to Albert (or Tom now) and there is no problem with that. Well, technically of course this works, but it is far from perfect. It works only for those who actually know about this. But anybody looking at the U-Boot site for any zynq related stuff will have hard times to find it. rocketboards.org is our portal. Linux and u-boot currently have repos there. This will be our central place for uboot and Linux. PERIOD! Alright. The sunxi community has recently made some great strides in getting things merged from their tree into mainline (And again, yy, thanks for the hard work there guys!). What is the plan to get things up-lifted and merged to mainline for this SoC? Understood...You have just lit a fire in our arses! We have added a resource internally, Vince Bridgers, to help us upstream more u-boot support. Also, now that Linux support for SOCFPGA is decent, I will focus more on u-boot. Thanks, Dinh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] fallback to other boot command (UBootBootCountLimit )
Hi, is this functionality removed from master? http://www.denx.de/wiki/view/DULG/UBootBootCountLimit If yes, would it be ok to re-introduce the feature with a patch submission? What we need is a way to try a different boot command (specifically tftp) if linux fails to boot. best Arvid ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] fallback to other boot command (UBootBootCountLimit )
On Thu, Sep 11, 2014 at 2:21 PM, Arvid E. Picciani a...@exys.org wrote: Hi, is this functionality removed from master? http://www.denx.de/wiki/view/DULG/UBootBootCountLimit Have you added '#define CONFIG_BOOTCOUNT_LIMIT' into your board file? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: dfu: thor: gadget: Remove dead code
Hello Lukasz, Am 11.09.2014 15:26, schrieb Lukasz Majewski: This code is not used anymore in the current DFU implementation and can be safely removed. Signed-off-by: Lukasz Majewskil.majew...@samsung.com --- drivers/usb/gadget/f_dfu.c | 8 drivers/usb/gadget/f_thor.c | 10 -- 2 files changed, 18 deletions(-) Thanks! Acked-by: Heiko Schocher h...@denx.de 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] u-boot-socfpga repository
Dear Dinh, In message 54122de5.1080...@opensource.altera.com you wrote: Understood...You have just lit a fire in our arses! We have added a resource internally, Vince Bridgers, to help us upstream more u-boot support. Also, now that Linux support for SOCFPGA is decent, I will focus more on u-boot. That's great to hear, thank. So I suggest we create u-boot-socfpga now, as this will be needed in any case when any significant amount of patches is coming in for mainline. For now, we assing Marek as custodian - he has volunteered, and he already has a reputation in the community. As soon as Vince starts actively working here on the mailing list, we can switch this role to him. What do you think? 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 C makes it easy for you to shoot yourself in the foot. C++ makes that harder, but when you do, it blows away your whole leg. -- Bjarne Stroustrup ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] nand/denali: Adding Denali NAND driver support
On Tue, 2014-09-02 at 21:15 -0500, Scott Wood wrote: On Sat, 2014-08-30 at 07:45 -0400, Tom Rini wrote: On Thu, Aug 28, 2014 at 11:13:40AM +0900, Masahiro Yamada wrote: Hi Scott, On Tue, 19 Aug 2014 04:47:40 -0500 Chin Liang See cl...@altera.com wrote: To add the Denali NAND driver support into U-Boot. This driver is leveraged from Linux. Signed-off-by: Chin Liang See cl...@altera.com Cc: Scott Wood scottw...@freescale.com Cc: Masahiro Yamada yamad...@jp.panasonic.com --- Changes for v9 - Updated the commit messageb - Removed macro kern_xx - Removed debug macro - Changed CONFIG_NAND_DENALI_64BIT to CONFIG_SYS_NAND_DENALI_64BIT Any comments? If nothing, please apply this patch. I don't see anything obviously wrong here, but since Scott has reviewed previous versions I want to give him a little more time to ack. I'm OK pulling this into master with Scott's ack or lets say Wednesday next week and we'll ask Chin Liang to address any late feedback. Thanks all! I still don't see a reference to the SHA of the corresponding Linux driver. I will add it in commit message. Its fdbad98dff8007f2b8bee6698b5d25ebba0471c9 #define MODE5_WORKAROUND 0 still exists even though it's never used. Sorry as forget to update the header file. Done I still see (void *) casts in memcpy -- v8 comments said removed but not all instances were removed. Done It still introduces CONFIG_SYS_NAND_DENALI_64BIT without documenting it. I already added into comments of the code. Let me add it into commit message. Thanks Chin Liang -scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v10] nand/denali: Adding Denali NAND driver support
To add the Denali NAND driver support into U-Boot. This driver is leveraged from Linux with commit ID fdbad98dff8007f2b8bee6698b5d25ebba0471c9. For Denali controller 64 variance, you need to declare macro CONFIG_SYS_NAND_DENALI_64BIT. Signed-off-by: Chin Liang See cl...@altera.com Cc: Scott Wood scottw...@freescale.com Cc: Masahiro Yamada yamad...@jp.panasonic.com --- Changes for v10 - Updated the commit message to include Linux driver commit ID, usage of macro CONFIG_SYS_NAND_DENALI_64BIT - Removed casting for memcpy function - Removed NAND_CMD_LOCK_TIGHT support as no longer in latest NAND driver Changes for v9 - Updated the commit message - Removed macro kern_xx - Removed debug macro - Changed CONFIG_NAND_DENALI_64BIT to CONFIG_SYS_NAND_DENALI_64BIT Changes for v8 - Applied Masahiro's patch as below - Replaced denali-foo with denali.foo - Fixed denali_write_oob() handler - Made denali_read_oob() 10x faster Changes for v7 - Adding Masahiro's code to support 64bit version controller - Removed unused stub functions - Enhanced the ECC calculation Changes for v6 - Remove chip_delay as its unused - Remove ECC bit assignment in nand_para functions Changes for v5 - Rename denali_nand to denali only - Rename the macro for ctrl and data address Changes for v4 - Added cache flush to handle dcache enabled - Used standard return where 0 for pass - Removed unnecessary casting - Used standard readl and writel Changes for v3 - Fixed coding style Changes for v2 - Enable this driver support for SOCFPGA --- drivers/mtd/nand/Makefile |1 + drivers/mtd/nand/denali.c | 1205 + drivers/mtd/nand/denali.h | 467 ++ 3 files changed, 1673 insertions(+) create mode 100644 drivers/mtd/nand/denali.c create mode 100644 drivers/mtd/nand/denali.h diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index bf1312a..f298f84 100644 --- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -42,6 +42,7 @@ obj-$(CONFIG_NAND_ECC_BCH) += nand_bch.o obj-$(CONFIG_NAND_ATMEL) += atmel_nand.o obj-$(CONFIG_DRIVER_NAND_BFIN) += bfin_nand.o obj-$(CONFIG_NAND_DAVINCI) += davinci_nand.o +obj-$(CONFIG_NAND_DENALI) += denali.o obj-$(CONFIG_NAND_FSL_ELBC) += fsl_elbc_nand.o obj-$(CONFIG_NAND_FSL_IFC) += fsl_ifc_nand.o obj-$(CONFIG_NAND_FSL_UPM) += fsl_upm.o diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c new file mode 100644 index 000..ba3de1a --- /dev/null +++ b/drivers/mtd/nand/denali.c @@ -0,0 +1,1205 @@ +/* + * Copyright (C) 2014 Panasonic Corporation + * Copyright (C) 2013-2014, Altera Corporation www.altera.com + * Copyright (C) 2009-2010, Intel Corporation and its suppliers. + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include common.h +#include malloc.h +#include nand.h +#include asm/errno.h +#include asm/io.h + +#include denali.h + +#define NAND_DEFAULT_TIMINGS -1 + +static int onfi_timing_mode = NAND_DEFAULT_TIMINGS; + +/* We define a macro here that combines all interrupts this driver uses into + * a single constant value, for convenience. */ +#define DENALI_IRQ_ALL (INTR_STATUS__DMA_CMD_COMP | \ + INTR_STATUS__ECC_TRANSACTION_DONE | \ + INTR_STATUS__ECC_ERR | \ + INTR_STATUS__PROGRAM_FAIL | \ + INTR_STATUS__LOAD_COMP | \ + INTR_STATUS__PROGRAM_COMP | \ + INTR_STATUS__TIME_OUT | \ + INTR_STATUS__ERASE_FAIL | \ + INTR_STATUS__RST_COMP | \ + INTR_STATUS__ERASE_COMP | \ + INTR_STATUS__ECC_UNCOR_ERR | \ + INTR_STATUS__INT_ACT | \ + INTR_STATUS__LOCKED_BLK) + +/* indicates whether or not the internal value for the flash bank is + * valid or not */ +#define CHIP_SELECT_INVALID-1 + +#define SUPPORT_8BITECC1 + +/* + * this macro allows us to convert from an MTD structure to our own + * device context (denali) structure. + */ +#define mtd_to_denali(m) (((struct nand_chip *)mtd-priv)-priv) + +/* These constants are defined by the driver to enable common driver + * configuration options. */ +#define SPARE_ACCESS 0x41 +#define MAIN_ACCESS0x42 +#define MAIN_SPARE_ACCESS 0x43 + +#define DENALI_UNLOCK_START0x10 +#define DENALI_UNLOCK_END 0x11 +#define DENALI_LOCK0x21 +#define DENALI_LOCK_TIGHT 0x31 +#define DENALI_BUFFER_LOAD 0x60 +#define DENALI_BUFFER_WRITE0x62 + +#define DENALI_READ0 +#define DENALI_WRITE 0x100 + +/* types of device accesses. We can issue commands and get status */ +#define COMMAND_CYCLE 0 +#define ADDR_CYCLE 1 +#define STATUS_CYCLE 2 + +/* this is a helper macro that allows us to + * format the bank into the proper bits for the controller */ +#define BANK(x) ((x) 24) + +/* Interrupts are cleared by writing a 1 to the appropriate status bit */ +static
Re: [U-Boot] [PATCH 1/2] arm: Make reset position-independent
Hi Benoît, On Wed, 3 Sep 2014 23:32:33 +0200, Benoît Thébaudeau benoit.thebaudeau@gmail.com wrote: Some boards, like mx31pdk and tx25, require the beginning of the SPL code to be position-independent. For these two boards, this is because they use the i.MX external NAND boot, which starts by executing the first NAND Flash page from the NFC page buffer. The SPL then needs to copy itself to its actual link address in order to free the NFC page buffer and use it to load the non-SPL image from Flash before running it. This means that the SPL runtime address differs from its link address between the reset and the initial copy performed by board_init_f(), so this part of the SPL binary must be position-independent. This requirement was broken by commit 41623c9 'arm: move exception handling out of start.S files', which used an absolute address to branch to the reset routine. This new commit restores the original behavior, which just performed a relative branch. This fixes the boot of mx31pdk and tx25. Signed-off-by: Benoît Thébaudeau benoit.thebaudeau@gmail.com Reported-by: Helmut Raiger helmut.rai...@hale.at Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Magnus Lilja lilja.mag...@gmail.com Cc: John Rigby jcri...@gmail.com --- arch/arm/lib/vectors.S |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/arm/lib/vectors.S b/arch/arm/lib/vectors.S index 493f337..843b18f 100644 --- a/arch/arm/lib/vectors.S +++ b/arch/arm/lib/vectors.S @@ -50,7 +50,7 @@ #endif _start: - ldr pc, _reset + b reset ldr pc, _undefined_instruction ldr pc, _software_interrupt ldr pc, _prefetch_abort @@ -77,7 +77,6 @@ _start: .globl _irq .globl _fiq -_reset: .word reset _undefined_instruction: .word undefined_instruction _software_interrupt: .word software_interrupt _prefetch_abort: .word prefetch_abort Applied (as a bug fix) to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] arm: Fix _start for CONFIG_SYS_DV_NOR_BOOT_CFG
Hi Benoît, On Wed, 3 Sep 2014 23:32:34 +0200, Benoît Thébaudeau benoit.thebaudeau@gmail.com wrote: The boards using CONFIG_SYS_DV_NOR_BOOT_CFG (i.e. calimain, da850evm_direct_nor and enbw_cmc) had the _start symbol defined after the CONFIG_SYS_DV_NOR_BOOT_CFG word rather than before it in arch/arm/lib/vectors.S. Because of that, if by lack of luck 'gd-mon_len = (ulong)__bss_end - (ulong)_start' (see setup_mon_len()) was a multiple of 4 kiB (see reserve_uboot()), then the last BSS word overlapped the first word of the following reserved RAM area (or went beyond the top of RAM without such an area) after relocation because __image_copy_start did not match _start (see relocate_code()). This was broken by commit 41623c9 'arm: move exception handling out of start.S files', which defined _start twice (before and after the CONFIG_SYS_DV_NOR_BOOT_CFG word), then by commit 0a26e1d 'arm: fix a double-definition error of _start symbol', which kept the definition of the _start symbol after the CONFIG_SYS_DV_NOR_BOOT_CFG word. This new commit fixes this issue by restoring the original behavior, i.e. by defining the _start symbol before the CONFIG_SYS_DV_NOR_BOOT_CFG word. Signed-off-by: Benoît Thébaudeau benoit.thebaudeau@gmail.com Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Manfred Rudigier manfred.rudig...@omicron.at Cc: Christian Riesch christian.rie...@omicron.at Cc: Sudhakar Rajashekhara sudhakar@ti.com Cc: Heiko Schocher h...@denx.de --- arch/arm/lib/vectors.S |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/lib/vectors.S b/arch/arm/lib/vectors.S index 843b18f..0cb87ce 100644 --- a/arch/arm/lib/vectors.S +++ b/arch/arm/lib/vectors.S @@ -45,11 +45,12 @@ * */ +_start: + #ifdef CONFIG_SYS_DV_NOR_BOOT_CFG .word CONFIG_SYS_DV_NOR_BOOT_CFG #endif -_start: b reset ldr pc, _undefined_instruction ldr pc, _software_interrupt Applied (as a bug fix) to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2] generic board for socfpga
On Tue, 2014-09-09 at 13:25 +0200, ZY - pavel wrote: Socfpga u-boot works fine with CONFIG_SYS_GENERIC_BOARD, so enable that option as documentation suggests. Signed-off-by: Pavel Machek pa...@denx.de Acked-by: Chin Liang See cl...@altera.com --- Sorry, I let this last too long before I reviewed it and now it does not apply cleanly at all. Can you have a look? Here you go. diff --git a/include/configs/socfpga_cyclone5.h b/include/configs/socfpga_cyclone5.h index 5d145cd..d3d1e48 100644 --- a/include/configs/socfpga_cyclone5.h +++ b/include/configs/socfpga_cyclone5.h @@ -11,6 +11,8 @@ #include ../../board/altera/socfpga/iocsr_config.h #include ../../board/altera/socfpga/pll_config.h +#define CONFIG_SYS_GENERIC_BOARD + /* * High level configuration */ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
