Re: [U-Boot] [PATCH v2 02/15] zynq: kconfig: move board select menu and commonsettings
Hi Masahiro, On 08/06/2014 05:17 AM, Masahiro Yamada wrote: Becuase the board select menu in arch/arm/Kconfig is too big, move the Zynq board select menu to zynq/Kconfig. Consolidate also common settings (CONFIG_SYS_CPU=armv7 and CONFIG_SYS_SOC=zynq). Refactor board/xilinx/zynq/MAINTAINERS too. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Michal Simek michal.si...@xilinx.com --- Changes in v2: None arch/arm/Kconfig | 15 ++ arch/arm/cpu/armv7/zynq/Kconfig| 43 + board/xilinx/zynq/Kconfig | 95 -- board/xilinx/zynq/MAINTAINERS | 12 + configs/zynq_microzed_defconfig| 1 + configs/zynq_zc70x_defconfig | 1 + configs/zynq_zc770_xm010_defconfig | 1 + configs/zynq_zc770_xm012_defconfig | 1 + configs/zynq_zc770_xm013_defconfig | 1 + configs/zynq_zed_defconfig | 1 + include/configs/zynq-common.h | 1 - 11 files changed, 54 insertions(+), 118 deletions(-) create mode 100644 arch/arm/cpu/armv7/zynq/Kconfig delete mode 100644 board/xilinx/zynq/Kconfig One One thing I have noticed was that when I run [u-boot]$ make zynq_zc70x_defconfig ... there is incorrect CONFIG_DEFCONFIG_LIST setup [u-boot]$ head .config # # Automatically generated file; DO NOT EDIT. # U-Boot 2014.07 Configuration # CONFIG_DEFCONFIG_LIST=configs/sandbox_defconfig # # General setup # CONFIG_SPL=y BTW: I would keep that options sorted │ │ (X) Xilinx Zynq Platform │ │ │ │ ( ) NVIDIA Tegra | | The rest for zynq is fine. Tested-by: Michal Simek michal.si...@xilinx.com Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
Dear Alexander, In message 53dfdc99.2020...@ahsoftware.de you wrote: At least I've understood it such that nobody still has an objection=20 against the new feature for env import -t (-r). I object if it would be added without maintaining symmetry with env export. 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 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 02/15] zynq: kconfig: move board select menu and commonsettings
Hi Michal, On Wed, 6 Aug 2014 08:39:47 +0200 Michal Simek michal.si...@xilinx.com wrote: Hi Masahiro, On 08/06/2014 05:17 AM, Masahiro Yamada wrote: Becuase the board select menu in arch/arm/Kconfig is too big, move the Zynq board select menu to zynq/Kconfig. Consolidate also common settings (CONFIG_SYS_CPU=armv7 and CONFIG_SYS_SOC=zynq). Refactor board/xilinx/zynq/MAINTAINERS too. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Michal Simek michal.si...@xilinx.com --- Changes in v2: None arch/arm/Kconfig | 15 ++ arch/arm/cpu/armv7/zynq/Kconfig| 43 + board/xilinx/zynq/Kconfig | 95 -- board/xilinx/zynq/MAINTAINERS | 12 + configs/zynq_microzed_defconfig| 1 + configs/zynq_zc70x_defconfig | 1 + configs/zynq_zc770_xm010_defconfig | 1 + configs/zynq_zc770_xm012_defconfig | 1 + configs/zynq_zc770_xm013_defconfig | 1 + configs/zynq_zed_defconfig | 1 + include/configs/zynq-common.h | 1 - 11 files changed, 54 insertions(+), 118 deletions(-) create mode 100644 arch/arm/cpu/armv7/zynq/Kconfig delete mode 100644 board/xilinx/zynq/Kconfig One One thing I have noticed was that when I run [u-boot]$ make zynq_zc70x_defconfig ... there is incorrect CONFIG_DEFCONFIG_LIST setup [u-boot]$ head .config # # Automatically generated file; DO NOT EDIT. # U-Boot 2014.07 Configuration # CONFIG_DEFCONFIG_LIST=configs/sandbox_defconfig I assume you thought having sandbox_defconfig in ARM .config is weird. But I think this is correct. Unlike Linux, defconfig has a flat structure in U-Boot because ARCH=arm is not given from the command line. Sandbox is the default when no defconfig is specified although this is not related to this series at all. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] sunxi: Replace CONFIG_SUN[457]I ifdefs with SOC_IS_SUN[457]I() calls
On Sun, 2014-08-03 at 06:26 +0300, Siarhei Siamashka wrote: This is a purely mechanical conversion, replacing the ifdefs and preparing the code for the use of runtime Allwinner SoC type detection (within Allwinner A10/A13/A20 family). Similar 'board_is_xxx()' calls are used for TI hardware. I think this should be either soc_is_sunXi() giving the appearance of a function of SOC_IS_SUNxI giving the appearance of a variable. Other than that assuming the conversion is mechanical I think it is fine. Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] sunxi: Universal Allwinner A10/A13/A20 u-boot binary support
On Sun, 2014-08-03 at 06:26 +0300, Siarhei Siamashka wrote:
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e385eda..95887f6 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -650,6 +650,9 @@ config TARGET_SUN5I
config TARGET_SUN7I
bool Support sun7i
+config TARGET_SUN4I_SUN5I_SUN7I
+ bool Support sun4i/sun5i/sun7i
Is the intention to eventually support sun6i/sun8i etc here too? I think
we should try and avoid enumerating them in the names of everything
(Kconfig, filenames etc) and instead us TARGET_SUNXI_GENERIC or
TARGET_SUNXI_MULTI or something along those lines, or perhaps Kconfig
could present a bool for each of the subarches and enabling more than
one would enable multiple mode.
Not directly related to this series but probably arch/arm/Kconfig should
have TARGET_SUNXI and the 4i/5i/7i stuff ought to move down into
arch/arm/sunxi/Kconfig.
@@ -48,17 +48,62 @@ u32 spl_boot_mode(void)
}
#endif
+static void sunxi_soc_detect_init(void)
+{
+ /* Enable VER_REG (set the VER_R_EN bit) */
+ setbits_le32((u32 *)(SUNXI_SRAMC_BASE + 0x24), 1 15);
Please can you #define 0x24 and the various masks/shifts.
+}
+
+int soc_is_sun4i(void)
All of these should use a common helper which takes the ID as a
parameter or the SOC_IS_xxx macros could just use that helper directly
if the wrappers turn out not that useful.
A bit of cpp trickery could also lead to:
#define SUNXI_SOC_ID_SUN4I 0x1623
#define SUNXO_SOC_ID...
#define SUNXI_SOC_IS(X) soc_is(SUNXI_SOC_ID_#X)
Used as SUNXI_SOC_IS(SUN4I) etc. What do you think?
+
+ if (cons_index == 1 SOC_IS_SUN5I()) {
+ u32 val = readl(SUNXI_SID_BASE + 0x08);
+ if (((val 12) 0xf) == 3) {
Can we use some #defines for the masks and shifts please.
diff --git a/board/sunxi/dram_sunxi_ddr3_failsafe.c
b/board/sunxi/dram_sunxi_ddr3_failsafe.c
new file mode 100644
index 000..348e0b9
--- /dev/null
+++ b/board/sunxi/dram_sunxi_ddr3_failsafe.c
How about putting this stuff in dram.c (or a new dram_default.c if you
prefer) marked as __weak? IOW make it the default for everything which
doesn't add a more specific dram_foo.c.
@@ -0,0 +1,28 @@
+/* this file is generated, don't edit it yourself */
I've had my doubts about this comment in the past, but here in
particular I was under the impression that you had manually selected the
safest values.
+#define CONFIG_SYS_PROMPTsunxi#
TBH I think we should just move this to -common.h and nuke the sun[457]i
ones, they don't serve much purpose, the specific SOC is identified in
the boot banner already.
FYI I'm now AFK until the 18th.
Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCH] video: add cfb console driver for sunxi
Op 5 aug. 2014, om 23:37 heeft Michal Suchanek hramr...@gmail.com het volgende geschreven: On 5 August 2014 23:03, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Mon, Aug 04, 2014 at 05:05:00PM +0200, Luc Verhaegen wrote: On Mon, Aug 04, 2014 at 10:39:13AM +0200, Hans de Goede wrote: Hi Luc, First of all many thanks for your work on this. ATM I don't have time to do a full review, but I don't expect there to be too many suprises when I do find the time. Really my only concern is the handover of the reserved memory, etc. to the kernel. We need to get a plan in place for that *before* this can be merged. Note I don't want to raise any artificial barriers here, I would love to see this merged ASAP. But I don't want to paint us in a corner where u-boot having hdmi console support makes it harder to get kms support in the kernel going. I think we can both agree on that. So I really want to see some plan how this will work in place before merging. Note just a plan, I don't expect kernel patches ready to be merged for this, just a good idea / sketch of how all the bits will fit together. Memory is not the biggest worry. Some kernel code needs to claim clocks if the mode is to cleanly survive the start of the kernel. If not, there is no coming back until a proper display driver runs. If the simplefb driver claims these clocks, then the simplefb driver also must release these clocks, and this driver should then never be started again, so it should set the simplefb dt node status to disabled. I'm probably missing a bit of context, but one thing I still don't get is why you're taking into account the simplefb - KMS handover. It's a case that shouldn't exist. By essence, simplefb has never been meant for that. It's been meant to have a temporary solution until a full-fledged driver is merged in the kernel. Which is exactly the case we're into. It's a permanent temporary solution. Same as offb/vesafb/uefi and other unaccelerated drivers. It will be needed for platforms on which KMS is not (yet) fully supported or happens to break. Also how else do you express the fact that u-boot has left the display enabled other than generating the simplefb DT node? Note that the KMS driver will be probably unsuitable for early console while the simplefb driver can just write into the framebuffer set up by u-boot. Both simplefb and the potention sunxifb will be using the same kernel infrastructure and start printing at the same time, so your argument about simplefb being able to print 'earlier' is nonsense. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] pxe: Allow use of environment variables in append string
Use cli_simple_process_macros, so that environment
variables (e.g. ${console}) can be used in append strings.
Signed-off-by: Hans de Goede hdego...@redhat.com
--
Changes in v2:
-Use cli_simple_process_macros instead of run_cmd(setenv bootargs ...), so
that only $() / ${} get processed and not ;
---
common/cmd_pxe.c | 29 +
1 file changed, 13 insertions(+), 16 deletions(-)
diff --git a/common/cmd_pxe.c b/common/cmd_pxe.c
index ba48692..bd7aa65 100644
--- a/common/cmd_pxe.c
+++ b/common/cmd_pxe.c
@@ -14,6 +14,7 @@
#include fs.h
#include menu.h
+#include cli.h
#define MAX_TFTP_PATH_LEN 127
@@ -577,8 +578,12 @@ static int label_localboot(struct pxe_label *label)
if (!localcmd)
return -ENOENT;
- if (label-append)
- setenv(bootargs, label-append);
+ if (label-append) {
+ char bootargs[CONFIG_SYS_CBSIZE];
+
+ cli_simple_process_macros(label-append, bootargs);
+ setenv(bootargs, bootargs);
+ }
debug(running: %s\n, localcmd);
@@ -606,7 +611,6 @@ static int label_boot(cmd_tbl_t *cmdtp, struct pxe_label
*label)
char initrd_str[22];
char mac_str[29] = ;
char ip_str[68] = ;
- char *bootargs;
int bootm_argc = 3;
int len = 0;
@@ -651,7 +655,6 @@ static int label_boot(cmd_tbl_t *cmdtp, struct pxe_label
*label)
sprintf(ip_str, ip=%s:%s:%s:%s,
getenv(ipaddr), getenv(serverip),
getenv(gatewayip), getenv(netmask));
- len += strlen(ip_str);
}
#ifdef CONFIG_CMD_NET
@@ -661,27 +664,21 @@ static int label_boot(cmd_tbl_t *cmdtp, struct pxe_label
*label)
err = format_mac_pxe(mac_str + 8, sizeof(mac_str) - 8);
if (err 0)
mac_str[0] = '\0';
- len += strlen(mac_str);
}
#endif
- if (label-append)
- len += strlen(label-append);
+ if ((label-ipappend 0x3) || label-append) {
+ char bootargs[CONFIG_SYS_CBSIZE] = ;
+ char finalbootargs[CONFIG_SYS_CBSIZE];
- if (len) {
- bootargs = malloc(len + 1);
- if (!bootargs)
- return 1;
- bootargs[0] = '\0';
if (label-append)
strcpy(bootargs, label-append);
strcat(bootargs, ip_str);
strcat(bootargs, mac_str);
- setenv(bootargs, bootargs);
- printf(append: %s\n, bootargs);
-
- free(bootargs);
+ cli_simple_process_macros(bootargs, finalbootargs);
+ setenv(bootargs, finalbootargs);
+ printf(append: %s\n, finalbootargs);
}
bootm_argv[1] = getenv(kernel_addr_r);
--
2.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: HYP/non-sec: Add MIDR check to detect unsupported CPUs
On Mon, 2014-08-04 at 16:14 +0100, Marc Zyngier wrote: My personal feeling is that booting in secure mode is always the wrong thing to do. FWIW I agree. If you want to go down the road of a single bootloader that is able to run on several SOCs, then do it the proper way: parse the device tree and have separate constraints for your SoC. But please don't blacklist random cores just because it fits your environment. I think there is a CPU feature register which indicates whether support for HYP mode is present, isn't there? In which case a tolerable fix for now (going all the way DT is a big yakk to shave...) would be to use that to decide between booting in NS.HYP vs NS.SVC (nb: not NS.HYP vs S.SVC). I don't recall if the GIC has a feature bit for the security extensions, but if not then inferring it from the CPUs support wouldn't be the worst thing in the world under the circumstances. Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] cli: Export cli_simple_process_macros for use outside of cli_simple
Signed-off-by: Hans de Goede hdego...@redhat.com
---
common/cli_simple.c | 4 ++--
include/cli.h | 8
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/common/cli_simple.c b/common/cli_simple.c
index 353ceeb..6c65cc6 100644
--- a/common/cli_simple.c
+++ b/common/cli_simple.c
@@ -57,7 +57,7 @@ int cli_simple_parse_line(char *line, char *argv[])
return nargs;
}
-static void process_macros(const char *input, char *output)
+void cli_simple_process_macros(const char *input, char *output)
{
char c, prev;
const char *varname_start = NULL;
@@ -236,7 +236,7 @@ int cli_simple_run_command(const char *cmd, int flag)
debug_parser(token: \%s\\n, token);
/* find macros in this token and replace them */
- process_macros(token, finaltoken);
+ cli_simple_process_macros(token, finaltoken);
/* Extract arguments */
argc = cli_simple_parse_line(finaltoken, argv);
diff --git a/include/cli.h b/include/cli.h
index 6994262..6da7a4a 100644
--- a/include/cli.h
+++ b/include/cli.h
@@ -31,6 +31,14 @@ void cli_simple_loop(void);
int cli_simple_run_command(const char *cmd, int flag);
/**
+ * cli_simple_process_macros() - Expand $() and ${} format env. variables
+ *
+ * @param inputInput string possible containing $() / ${} vars
+ * @param output Output string with $() / ${} vars expanded
+ */
+void cli_simple_process_macros(const char *input, char *output);
+
+/**
* cli_simple_run_command_list() - Execute a list of command
*
* The commands should be separated by ; or \n and will be executed
--
2.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/2] pxe: Allow use of environment variables in append
Hi,
Here is v2 of my patch-set to expand $() / ${} in extlinux.conf append strings.
Changes in v2:
-Add cli: Export cli_simple_process_macros for use outside patch
-Use cli_simple_process_macros instead of run_cmd(setenv bootargs ...), so
that only $() / ${} get processed and not ;
Regards,
Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 02/15] zynq: kconfig: move board select menu and commonsettings
On 08/06/2014 08:49 AM, Masahiro Yamada wrote: Hi Michal, On Wed, 6 Aug 2014 08:39:47 +0200 Michal Simek michal.si...@xilinx.com wrote: Hi Masahiro, On 08/06/2014 05:17 AM, Masahiro Yamada wrote: Becuase the board select menu in arch/arm/Kconfig is too big, move the Zynq board select menu to zynq/Kconfig. Consolidate also common settings (CONFIG_SYS_CPU=armv7 and CONFIG_SYS_SOC=zynq). Refactor board/xilinx/zynq/MAINTAINERS too. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Michal Simek michal.si...@xilinx.com --- Changes in v2: None arch/arm/Kconfig | 15 ++ arch/arm/cpu/armv7/zynq/Kconfig| 43 + board/xilinx/zynq/Kconfig | 95 -- board/xilinx/zynq/MAINTAINERS | 12 + configs/zynq_microzed_defconfig| 1 + configs/zynq_zc70x_defconfig | 1 + configs/zynq_zc770_xm010_defconfig | 1 + configs/zynq_zc770_xm012_defconfig | 1 + configs/zynq_zc770_xm013_defconfig | 1 + configs/zynq_zed_defconfig | 1 + include/configs/zynq-common.h | 1 - 11 files changed, 54 insertions(+), 118 deletions(-) create mode 100644 arch/arm/cpu/armv7/zynq/Kconfig delete mode 100644 board/xilinx/zynq/Kconfig One One thing I have noticed was that when I run [u-boot]$ make zynq_zc70x_defconfig ... there is incorrect CONFIG_DEFCONFIG_LIST setup [u-boot]$ head .config # # Automatically generated file; DO NOT EDIT. # U-Boot 2014.07 Configuration # CONFIG_DEFCONFIG_LIST=configs/sandbox_defconfig I assume you thought having sandbox_defconfig in ARM .config is weird. Not exactly this. My expectation was that when I use zynq_zc70x_defconfig that it will be listed there instead of sandbox one. Or just CONFIG_DEFCONFIG_LIST not there. But I think this is correct. Unlike Linux, defconfig has a flat structure in U-Boot because ARCH=arm is not given from the command line. Even if ARCH=arm is passed behavior is the same [u-boot]$ make ARCH=arm zynq_zc70x_defconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/zconf.lex.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf # # configuration written to .config # # # configuration written to spl/.config # [u-boot]$ head .config # # Automatically generated file; DO NOT EDIT. # U-Boot 2014.07 Configuration # CONFIG_DEFCONFIG_LIST=configs/sandbox_defconfig # # General setup # CONFIG_SPL=y Is DEFCONFIG_LIST used anywhere? I just want to know what is this for. Sandbox is the default when no defconfig is specified although this is not related to this series at all. yes it is not related that's why I have given you Tested-by for that patch. Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 09/18] arm: mx6: ddr: do not write into reserved bit
On Mon, Aug 4, 2014 at 5:49 AM, Nikita Kiryanov nik...@compulab.co.il wrote: Hi Tim, On 04/08/14 08:43, Tim Harvey wrote: On Sun, Aug 3, 2014 at 12:34 AM, Nikita Kiryanov nik...@compulab.co.il wrote: Bit 16 in mapsr register is in a reserved field. Don't write to it. Cc: Stefano Babic sba...@denx.de Cc: Tim Harvey thar...@gateworks.com Signed-off-by: Nikita Kiryanov nik...@compulab.co.il --- arch/arm/cpu/armv7/mx6/ddr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/cpu/armv7/mx6/ddr.c b/arch/arm/cpu/armv7/mx6/ddr.c index af91314..70ce38f 100644 --- a/arch/arm/cpu/armv7/mx6/ddr.c +++ b/arch/arm/cpu/armv7/mx6/ddr.c @@ -466,7 +466,7 @@ void mx6_dram_cfg(const struct mx6_ddr_sysinfo *sysinfo, 1 6 | /* BOTH_CS_PD */ (tcksrx 0x7) 3 | (tcksre 0x7); - mmdc0-mapsr = 0x00011006; /* ADOPT power down enabled */ + mmdc0-mapsr = 0x1006; /* ADOPT power down enabled */ /* Step 11: Configure ZQ calibration: one-time and periodic 1ms */ val = 0xa1390003; -- 1.9.1 Nikita, This makes sense per the reference manual, but does not agree with the i.Mx6DQSDL DDR3 Script Aid spreadsheet (https://community.freescale.com/docs/DOC-94917). I'm curious if you found any other explanation of this or anything else that makes you feel the spreadsheet is in error (vs the RM's). Nothing specific, I just don't like to use undocumented features. It's probably benign, but still... I've asked our Freescale FAE to clarify. Looking forward to that... Regards, Nikita Kiryanov Nikita, Freescale confirmed its an error in their spreadsheet (https://community.freescale.com/docs/DOC-94917#comment-12921), so: Acked-by: Tim Harvey thar...@gateworks.com Tim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 09/18] arm: mx6: ddr: do not write into reserved bit
Hi Tim, hi Nikita, On 06/08/2014 10:18, Tim Harvey wrote: I've asked our Freescale FAE to clarify. Looking forward to that... Regards, Nikita Kiryanov Nikita, Freescale confirmed its an error in their spreadsheet (https://community.freescale.com/docs/DOC-94917#comment-12921), so: Acked-by: Tim Harvey thar...@gateworks.com Thanks both to have clarified this issue, patch is ready to be merged. 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 02/15] zynq: kconfig: move board select menu and commonsettings
Hi Michal, On Wed, 6 Aug 2014 09:57:46 +0200 Michal Simek michal.si...@xilinx.com wrote: On 08/06/2014 08:49 AM, Masahiro Yamada wrote: Hi Michal, On Wed, 6 Aug 2014 08:39:47 +0200 Michal Simek michal.si...@xilinx.com wrote: Hi Masahiro, On 08/06/2014 05:17 AM, Masahiro Yamada wrote: Becuase the board select menu in arch/arm/Kconfig is too big, move the Zynq board select menu to zynq/Kconfig. Consolidate also common settings (CONFIG_SYS_CPU=armv7 and CONFIG_SYS_SOC=zynq). Refactor board/xilinx/zynq/MAINTAINERS too. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Michal Simek michal.si...@xilinx.com --- Changes in v2: None arch/arm/Kconfig | 15 ++ arch/arm/cpu/armv7/zynq/Kconfig| 43 + board/xilinx/zynq/Kconfig | 95 -- board/xilinx/zynq/MAINTAINERS | 12 + configs/zynq_microzed_defconfig| 1 + configs/zynq_zc70x_defconfig | 1 + configs/zynq_zc770_xm010_defconfig | 1 + configs/zynq_zc770_xm012_defconfig | 1 + configs/zynq_zc770_xm013_defconfig | 1 + configs/zynq_zed_defconfig | 1 + include/configs/zynq-common.h | 1 - 11 files changed, 54 insertions(+), 118 deletions(-) create mode 100644 arch/arm/cpu/armv7/zynq/Kconfig delete mode 100644 board/xilinx/zynq/Kconfig One One thing I have noticed was that when I run [u-boot]$ make zynq_zc70x_defconfig ... there is incorrect CONFIG_DEFCONFIG_LIST setup [u-boot]$ head .config # # Automatically generated file; DO NOT EDIT. # U-Boot 2014.07 Configuration # CONFIG_DEFCONFIG_LIST=configs/sandbox_defconfig I assume you thought having sandbox_defconfig in ARM .config is weird. Not exactly this. My expectation was that when I use zynq_zc70x_defconfig that it will be listed there instead of sandbox one. Or just CONFIG_DEFCONFIG_LIST not there. But I think this is correct. Unlike Linux, defconfig has a flat structure in U-Boot because ARCH=arm is not given from the command line. Even if ARCH=arm is passed behavior is the same Yes. Giving ARCH is meaningless in U-Boot. Is DEFCONFIG_LIST used anywhere? I just want to know what is this for. I set the default value just in case. The only difference I noticed is make savedefconfig. If .config does not exist, make savedefconfig uses DEFCONFIG_LIST as its default. With config DEFCONFIG_LIST, $ rm -f .config* $ make savedefconfig scripts/kconfig/conf --savedefconfig=defconfig Kconfig # # using defaults found in configs/sandbox_defconfig # But if we comment out DEFCONFIG_LIST, $ rm -f .config* $ make savedefconfig scripts/kconfig/conf --savedefconfig=defconfig Kconfig Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] arm: vf610: add NFC clock support
Add NFC (NAND Flash Controller) clock support and enable them
at board initialization time.
Signed-off-by: Stefan Agner ste...@agner.ch
---
arch/arm/include/asm/arch-vf610/crm_regs.h | 14 ++
arch/arm/include/asm/arch-vf610/imx-regs.h | 1 +
2 files changed, 15 insertions(+)
diff --git a/arch/arm/include/asm/arch-vf610/crm_regs.h
b/arch/arm/include/asm/arch-vf610/crm_regs.h
index 5256624..724682c 100644
--- a/arch/arm/include/asm/arch-vf610/crm_regs.h
+++ b/arch/arm/include/asm/arch-vf610/crm_regs.h
@@ -156,14 +156,27 @@ struct anadig_reg {
#define CCM_CSCMR1_ESDHC1_CLK_SEL_OFFSET 18
#define CCM_CSCMR1_ESDHC1_CLK_SEL_MASK (0x3 18)
#define CCM_CSCMR1_ESDHC1_CLK_SEL(v) (((v) 0x3) 18)
+#define CCM_CSCMR1_NFC_CLK_SEL_OFFSET 12
+#define CCM_CSCMR1_NFC_CLK_SEL_MASK(0x3 12)
+#define CCM_CSCMR1_NFC_CLK_SEL(v) (((v) 0x3) 12)
#define CCM_CSCDR1_RMII_CLK_EN (1 24)
+#define CCM_CSCDR2_NFC_EN (1 9)
+#define CCM_CSCDR2_NFC_FRAC_DIV_EN (1 13)
+#define CCM_CSCDR2_NFC_CLK_INV (1 14)
+#define CCM_CSCDR2_NFC_FRAC_DIV_OFFSET 4
+#define CCM_CSCDR2_NFC_FRAC_DIV_MASK (0xf 4)
+#define CCM_CSCDR2_NFC_FRAC_DIV(v) (((v) 0xf) 4)
+
#define CCM_CSCDR2_ESDHC1_EN (1 29)
#define CCM_CSCDR2_ESDHC1_CLK_DIV_OFFSET 20
#define CCM_CSCDR2_ESDHC1_CLK_DIV_MASK (0xf 20)
#define CCM_CSCDR2_ESDHC1_CLK_DIV(v) (((v) 0xf) 20)
+#define CCM_CSCDR3_NFC_PRE_DIV_OFFSET 13
+#define CCM_CSCDR3_NFC_PRE_DIV_MASK(0x7 13)
+#define CCM_CSCDR3_NFC_PRE_DIV(v) (((v) 0x7) 13)
#define CCM_CSCDR3_QSPI0_EN(1 4)
#define CCM_CSCDR3_QSPI0_DIV(v)((v) 3)
#define CCM_CSCDR3_QSPI0_X2_DIV(v) ((v) 2)
@@ -195,6 +208,7 @@ struct anadig_reg {
#define CCM_CCGR7_SDHC1_CTRL_MASK (0x3 4)
#define CCM_CCGR9_FEC0_CTRL_MASK 0x3
#define CCM_CCGR9_FEC1_CTRL_MASK (0x3 2)
+#define CCM_CCGR10_NFC_CTRL_MASK 0x3
#define ANADIG_PLL5_CTRL_BYPASS (1 16)
#define ANADIG_PLL5_CTRL_ENABLE (1 13)
diff --git a/arch/arm/include/asm/arch-vf610/imx-regs.h
b/arch/arm/include/asm/arch-vf610/imx-regs.h
index bd6f680..bb00217 100644
--- a/arch/arm/include/asm/arch-vf610/imx-regs.h
+++ b/arch/arm/include/asm/arch-vf610/imx-regs.h
@@ -86,6 +86,7 @@
#define ESDHC1_BASE_ADDR (AIPS1_BASE_ADDR + 0x00032000)
#define ENET_BASE_ADDR (AIPS1_BASE_ADDR + 0x0005)
#define ENET1_BASE_ADDR(AIPS1_BASE_ADDR + 0x00051000)
+#define NFC_BASE_ADDR (AIPS1_BASE_ADDR + 0x0006)
#define QSPI0_AMBA_BASE0x2000
--
2.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/4] 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 Stefan Agner (4): arm: vf610: add NFC pin mux arm: vf610: add NFC clock support mtd: nand: add Freescale NFC driver arm: vf610: add NAND support for vf610twr arch/arm/include/asm/arch-vf610/crm_regs.h| 14 + arch/arm/include/asm/arch-vf610/imx-regs.h| 1 + arch/arm/include/asm/arch-vf610/iomux-vf610.h | 34 ++ arch/arm/include/asm/imx-common/iomux-v3.h| 4 + board/freescale/vf610twr/vf610twr.c | 47 +- configs/vf610twr_defconfig| 2 +- configs/vf610twr_nand_defconfig | 3 + drivers/mtd/nand/Makefile | 1 + drivers/mtd/nand/fsl_nfc.c| 676 ++ include/configs/vf610twr.h| 43 ++ 10 files changed, 821 insertions(+), 4 deletions(-) create mode 100644 configs/vf610twr_nand_defconfig create mode 100644 drivers/mtd/nand/fsl_nfc.c -- 2.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] arm: vf610: add NFC pin mux
Add pin mux for NAND Flash Controller (NFC). NAND can be connected
using 8 or 16 data lines, this patch adds pin mux entries for all
16 data lines.
Signed-off-by: Stefan Agner ste...@agner.ch
---
arch/arm/include/asm/arch-vf610/iomux-vf610.h | 34 +++
arch/arm/include/asm/imx-common/iomux-v3.h| 4
2 files changed, 38 insertions(+)
diff --git a/arch/arm/include/asm/arch-vf610/iomux-vf610.h
b/arch/arm/include/asm/arch-vf610/iomux-vf610.h
index a965641..7464da8 100644
--- a/arch/arm/include/asm/arch-vf610/iomux-vf610.h
+++ b/arch/arm/include/asm/arch-vf610/iomux-vf610.h
@@ -19,6 +19,13 @@
#define VF610_DDR_PAD_CTRL PAD_CTL_DSE_25ohm
#define VF610_I2C_PAD_CTRL (PAD_CTL_PUS_47K_UP | PAD_CTL_DSE_50ohm | \
PAD_CTL_SPEED_HIGH | PAD_CTL_OBE_IBE_ENABLE)
+#define VF610_NFC_IO_PAD_CTRL (PAD_CTL_SPEED_MED | PAD_CTL_SRE | \
+ PAD_CTL_DSE_50ohm | PAD_CTL_PUS_47K_UP | \
+ PAD_CTL_OBE_IBE_ENABLE)
+#define VF610_NFC_CN_PAD_CTRL (PAD_CTL_SPEED_MED | PAD_CTL_SRE | \
+ PAD_CTL_DSE_25ohm | PAD_CTL_OBE_ENABLE)
+#define VF610_NFC_RB_PAD_CTRL (PAD_CTL_SPEED_MED | PAD_CTL_SRE | \
+ PAD_CTL_PUS_22K_UP | PAD_CTL_IBE_ENABLE)
#define VF610_QSPI_PAD_CTRL(PAD_CTL_SPEED_HIGH | PAD_CTL_DSE_150ohm | \
PAD_CTL_PUS_22K_UP | PAD_CTL_OBE_IBE_ENABLE)
@@ -56,6 +63,15 @@ enum {
VF610_PAD_PTA29__ESDHC1_DAT3= IOMUX_PAD(0x004c, 0x004c, 5,
__NA_, 0, VF610_SDHC_PAD_CTRL),
VF610_PAD_PTB14__I2C0_SCL = IOMUX_PAD(0x0090, 0x0090, 2,
0x033c, 1, VF610_I2C_PAD_CTRL),
VF610_PAD_PTB15__I2C0_SDA = IOMUX_PAD(0x0094, 0x0094, 2,
0x0340, 1, VF610_I2C_PAD_CTRL),
+ VF610_PAD_PTD31__NF_IO15= IOMUX_PAD(0x00fc, 0x00fc, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+ VF610_PAD_PTD30__NF_IO14= IOMUX_PAD(0x0100, 0x0100, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+ VF610_PAD_PTD29__NF_IO13= IOMUX_PAD(0x0104, 0x0104, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+ VF610_PAD_PTD28__NF_IO12= IOMUX_PAD(0x0108, 0x0108, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+ VF610_PAD_PTD27__NF_IO11= IOMUX_PAD(0x010c, 0x010c, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+ VF610_PAD_PTD26__NF_IO10= IOMUX_PAD(0x0110, 0x0110, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+ VF610_PAD_PTD25__NF_IO9 = IOMUX_PAD(0x0114, 0x0114, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+ VF610_PAD_PTD24__NF_IO8 = IOMUX_PAD(0x0118, 0x0118, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+ VF610_PAD_PTD23__NF_IO7 = IOMUX_PAD(0x011c, 0x011c, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
VF610_PAD_PTD0__QSPI0_A_QSCK= IOMUX_PAD(0x013c, 0x013c, 1,
__NA_, 0, VF610_QSPI_PAD_CTRL),
VF610_PAD_PTD1__QSPI0_A_CS0 = IOMUX_PAD(0x0140, 0x0140, 1,
__NA_, 0, VF610_QSPI_PAD_CTRL),
VF610_PAD_PTD2__QSPI0_A_DATA3 = IOMUX_PAD(0x0144, 0x0144, 1,
__NA_, 0, VF610_QSPI_PAD_CTRL),
@@ -68,6 +84,24 @@ enum {
VF610_PAD_PTD10__QSPI0_B_DATA2 = IOMUX_PAD(0x0164, 0x0164, 1,
__NA_, 0, VF610_QSPI_PAD_CTRL),
VF610_PAD_PTD11__QSPI0_B_DATA1 = IOMUX_PAD(0x0168, 0x0168, 1,
__NA_, 0, VF610_QSPI_PAD_CTRL),
VF610_PAD_PTD12__QSPI0_B_DATA0 = IOMUX_PAD(0x016c, 0x016c, 1,
__NA_, 0, VF610_QSPI_PAD_CTRL),
+ VF610_PAD_PTD22__NF_IO6 = IOMUX_PAD(0x0120, 0x0120, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+ VF610_PAD_PTD21__NF_IO5 = IOMUX_PAD(0x0124, 0x0124, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+ VF610_PAD_PTD20__NF_IO4 = IOMUX_PAD(0x0128, 0x0128, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+ VF610_PAD_PTD19__NF_IO3 = IOMUX_PAD(0x012c, 0x012c, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+ VF610_PAD_PTD18__NF_IO2 = IOMUX_PAD(0x0130, 0x0130, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+ VF610_PAD_PTD17__NF_IO1 = IOMUX_PAD(0x0134, 0x0134, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+ VF610_PAD_PTD16__NF_IO0 = IOMUX_PAD(0x0138, 0x0138, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+ VF610_PAD_PTB24__NF_WE_B= IOMUX_PAD(0x0178, 0x0178, 5,
__NA_, 0, VF610_NFC_CN_PAD_CTRL),
+ VF610_PAD_PTB25__NF_CE0_B = IOMUX_PAD(0x017c, 0x017c, 5,
__NA_, 0, VF610_NFC_CN_PAD_CTRL),
+
+ VF610_PAD_PTB27__NF_RE_B= IOMUX_PAD(0x0184, 0x0184, 6,
__NA_, 0, VF610_NFC_CN_PAD_CTRL),
+
+ VF610_PAD_PTC26__NF_RB_B= IOMUX_PAD(0x018C, 0x018C, 5,
__NA_, 0, VF610_NFC_RB_PAD_CTRL),
+
+ VF610_PAD_PTC27__NF_ALE = IOMUX_PAD(0x0190, 0x0190, 6,
__NA_, 0, VF610_NFC_CN_PAD_CTRL),
+
+ VF610_PAD_PTC28__NF_CLE =
[U-Boot] [PATCH 3/4] mtd: nand: add Freescale NFC driver
This adds initial support for Freescale NFC (NAND Flash Controller). The IP is used in ARM based Vybrid SoCs as well as on some PowerPC devices. This driver is only tested on Vybrid. Signed-off-by: Stefan Agner ste...@agner.ch --- drivers/mtd/nand/Makefile | 1 + drivers/mtd/nand/fsl_nfc.c | 676 + 2 files changed, 677 insertions(+) create mode 100644 drivers/mtd/nand/fsl_nfc.c diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index bf1312a..85cb0dd 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_FSL_NFC) += fsl_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/fsl_nfc.c b/drivers/mtd/nand/fsl_nfc.c new file mode 100644 index 000..df2c8be --- /dev/null +++ b/drivers/mtd/nand/fsl_nfc.c @@ -0,0 +1,676 @@ +/* + * 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 +#include asm/processor.h + +#defineDRV_NAMEfsl_nfc + +/* 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 4/4] arm: vf610: add NAND support for vf610twr
This adds NAND Flash Controller (NFC) support for the Vybrid tower
system (TWR-VF65GS10). 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 | 43 +
4 files changed, 91 insertions(+), 4 deletions(-)
create mode 100644 configs/vf610twr_nand_defconfig
diff --git a/board/freescale/vf610twr/vf610twr.c
b/board/freescale/vf610twr/vf610twr.c
index 54a9f2c..63ebbf8 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_FSL_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_FSL_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..543f241 100644
--- a/include/configs/vf610twr.h
+++ b/include/configs/vf610twr.h
@@ -14,6
Re: [U-Boot] [PATCH v2 02/15] zynq: kconfig: move board select menu and commonsettings
On 08/06/2014 10:31 AM, Masahiro Yamada wrote: Hi Michal, On Wed, 6 Aug 2014 09:57:46 +0200 Michal Simek michal.si...@xilinx.com wrote: On 08/06/2014 08:49 AM, Masahiro Yamada wrote: Hi Michal, On Wed, 6 Aug 2014 08:39:47 +0200 Michal Simek michal.si...@xilinx.com wrote: Hi Masahiro, On 08/06/2014 05:17 AM, Masahiro Yamada wrote: Becuase the board select menu in arch/arm/Kconfig is too big, move the Zynq board select menu to zynq/Kconfig. Consolidate also common settings (CONFIG_SYS_CPU=armv7 and CONFIG_SYS_SOC=zynq). Refactor board/xilinx/zynq/MAINTAINERS too. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Michal Simek michal.si...@xilinx.com --- Changes in v2: None arch/arm/Kconfig | 15 ++ arch/arm/cpu/armv7/zynq/Kconfig| 43 + board/xilinx/zynq/Kconfig | 95 -- board/xilinx/zynq/MAINTAINERS | 12 + configs/zynq_microzed_defconfig| 1 + configs/zynq_zc70x_defconfig | 1 + configs/zynq_zc770_xm010_defconfig | 1 + configs/zynq_zc770_xm012_defconfig | 1 + configs/zynq_zc770_xm013_defconfig | 1 + configs/zynq_zed_defconfig | 1 + include/configs/zynq-common.h | 1 - 11 files changed, 54 insertions(+), 118 deletions(-) create mode 100644 arch/arm/cpu/armv7/zynq/Kconfig delete mode 100644 board/xilinx/zynq/Kconfig One One thing I have noticed was that when I run [u-boot]$ make zynq_zc70x_defconfig ... there is incorrect CONFIG_DEFCONFIG_LIST setup [u-boot]$ head .config # # Automatically generated file; DO NOT EDIT. # U-Boot 2014.07 Configuration # CONFIG_DEFCONFIG_LIST=configs/sandbox_defconfig I assume you thought having sandbox_defconfig in ARM .config is weird. Not exactly this. My expectation was that when I use zynq_zc70x_defconfig that it will be listed there instead of sandbox one. Or just CONFIG_DEFCONFIG_LIST not there. But I think this is correct. Unlike Linux, defconfig has a flat structure in U-Boot because ARCH=arm is not given from the command line. Even if ARCH=arm is passed behavior is the same Yes. Giving ARCH is meaningless in U-Boot. Is DEFCONFIG_LIST used anywhere? I just want to know what is this for. I set the default value just in case. The only difference I noticed is make savedefconfig. If .config does not exist, make savedefconfig uses DEFCONFIG_LIST as its default. With config DEFCONFIG_LIST, $ rm -f .config* $ make savedefconfig scripts/kconfig/conf --savedefconfig=defconfig Kconfig # # using defaults found in configs/sandbox_defconfig # But if we comment out DEFCONFIG_LIST, $ rm -f .config* $ make savedefconfig scripts/kconfig/conf --savedefconfig=defconfig Kconfig Based on steps below - defconfigs are both empty. Linux kernel is taking .config from /boot/config-`uname -r`. Maybe I do something wrong and Kconfig handles it differently but currently I can't see a reason to have this option there. Thanks, Michal [u-boot]$ make mrproper [u-boot]$ make savedefconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/zconf.lex.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf --savedefconfig=defconfig Kconfig # # using defaults found in configs/sandbox_defconfig # [u-boot]$ cat defconfig [u-boot]$ vim Kconfig [u-boot]$ git diff diff --git a/Kconfig b/Kconfig index 9e77a6e28b46..1a3864557df4 100644 --- a/Kconfig +++ b/Kconfig @@ -12,12 +12,6 @@ config KCONFIG_OBJDIR string option env=KCONFIG_OBJDIR -config DEFCONFIG_LIST - string - depends on !SPL_BUILD - option defconfig_list - default configs/sandbox_defconfig - menu General setup config SPL_BUILD [u-boot]$ make mrproper CLEAN scripts/basic CLEAN scripts/kconfig [u-boot]$ make savedefconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/zconf.lex.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf --savedefconfig=defconfig Kconfig [u-boot]$ cat defconfig [u-boot]$ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] ARM: mx6: Enable Thumb build for SPL
On Sun, Aug 3, 2014 at 4:47 PM, Marek Vasut ma...@denx.de wrote: Building the SPL in Thumb mode saves roughly 30% in size of the resulting SPL binary. As the size of SPL it limited on the MX6, this helps a lot. Signed-off-by: Marek Vasut ma...@denx.de --- include/configs/imx6_spl.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/imx6_spl.h b/include/configs/imx6_spl.h index 6fdc438..970460d 100644 --- a/include/configs/imx6_spl.h +++ b/include/configs/imx6_spl.h @@ -24,6 +24,7 @@ *and some padding thus 'our' max size is really 0x00908000 - 0x00918000 *or 64KB */ +#define CONFIG_SYS_THUMB_BUILD #define CONFIG_SPL_LDSCRIPT arch/arm/cpu/armv7/omap-common/u-boot-spl.lds #define CONFIG_SPL_TEXT_BASE 0x00908000 #define CONFIG_SPL_MAX_SIZE(64 * 1024) -- 2.0.1 Marek, Thanks for pointing this out - this indeed is a great space savings where it matters. Acked-by: Tim Harvey thar...@gateworks.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] ARM: atmel: use pcr to enable or disable peripheral clock
When use pcr (peripheral control register), then we won't need
to care about the peripheral ID.
Signed-off-by: Bo Shen voice.s...@atmel.com
---
arch/arm/cpu/armv7/at91/clock.c | 24
arch/arm/include/asm/arch-at91/at91_pmc.h | 4
arch/arm/include/asm/arch-at91/clk.h | 1 +
3 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/arch/arm/cpu/armv7/at91/clock.c b/arch/arm/cpu/armv7/at91/clock.c
index 1588e0c..36ed4a6 100644
--- a/arch/arm/cpu/armv7/at91/clock.c
+++ b/arch/arm/cpu/armv7/at91/clock.c
@@ -114,9 +114,25 @@ int at91_clock_init(unsigned long main_clock)
void at91_periph_clk_enable(int id)
{
struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
+ u32 regval;
- if (id 31)
- writel(1 (id - 32), pmc-pcer1);
- else
- writel(1 id, pmc-pcer);
+ if (id AT91_PMC_PCR_PID_MASK)
+ return;
+
+ regval = AT91_PMC_PCR_EN | AT91_PMC_PCR_CMD_WRITE | id;
+
+ writel(regval, pmc-pcr);
+}
+
+void at91_periph_clk_disable(int id)
+{
+ struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
+ u32 regval;
+
+ if (id AT91_PMC_PCR_PID_MASK)
+ return;
+
+ regval = AT91_PMC_PCR_CMD_WRITE | id;
+
+ writel(regval, pmc-pcr);
}
diff --git a/arch/arm/include/asm/arch-at91/at91_pmc.h
b/arch/arm/include/asm/arch-at91/at91_pmc.h
index 04f6239..bef5793 100644
--- a/arch/arm/include/asm/arch-at91/at91_pmc.h
+++ b/arch/arm/include/asm/arch-at91/at91_pmc.h
@@ -147,6 +147,10 @@ typedef struct at91_pmc {
#define AT91_PMC_IXR_PCKRDY3 0x0800
#define AT91_PMC_IXR_MOSCSELS 0x0001
+#define AT91_PMC_PCR_PID_MASK (0x3f)
+#define AT91_PMC_PCR_CMD_WRITE (0x1 12)
+#define AT91_PMC_PCR_EN(0x1 28)
+
#defineAT91_PMC_PCK(1 0) /*
Processor Clock */
#defineAT91RM9200_PMC_UDP (1 1) /* USB
Devcice Port Clock [AT91RM9200 only] */
#defineAT91RM9200_PMC_MCKUDP (1 2) /* USB
Device Port Master Clock Automatic Disable on Suspend [AT91RM9200 only] */
diff --git a/arch/arm/include/asm/arch-at91/clk.h
b/arch/arm/include/asm/arch-at91/clk.h
index ce9e28f..4076a78 100644
--- a/arch/arm/include/asm/arch-at91/clk.h
+++ b/arch/arm/include/asm/arch-at91/clk.h
@@ -80,4 +80,5 @@ static inline unsigned long get_mci_clk_rate(void)
int at91_clock_init(unsigned long main_clock);
void at91_periph_clk_enable(int id);
+void at91_periph_clk_disable(int id);
#endif /* __ASM_ARM_ARCH_CLK_H__ */
--
1.8.5.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/4] ARM: atmel: use pcr to control clock
When the SoC has pcr (peripheral control register), then switch to use it to enable or disable clock. Bo Shen (4): ARM: atmel: use pcr to enable or disable peripheral clock ARM: atmel: add pcr related definition USB: ohci-at91: use pcr to enable or disable clock USB: ehci-atmel: use pcr to enable or disable clock arch/arm/cpu/armv7/at91/clock.c | 24 arch/arm/include/asm/arch-at91/at91_pmc.h | 6 +- arch/arm/include/asm/arch-at91/clk.h | 1 + arch/arm/include/asm/arch-at91/sama5d3.h | 1 + drivers/usb/host/ehci-atmel.c | 8 drivers/usb/host/ohci-at91.c | 8 6 files changed, 39 insertions(+), 9 deletions(-) -- 1.8.5.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] USB: ohci-at91: use pcr to enable or disable clock
If the SoC has pcr, we use pcr (peripheral control register) to enable or disable clock. Signed-off-by: Bo Shen voice.s...@atmel.com --- drivers/usb/host/ohci-at91.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c index c24505e..820e2e5 100644 --- a/drivers/usb/host/ohci-at91.c +++ b/drivers/usb/host/ohci-at91.c @@ -38,8 +38,8 @@ int usb_cpu_init(void) #endif /* Enable USB host clock. */ -#ifdef CONFIG_SAMA5D3 - writel(1 (ATMEL_ID_UHP - 32), pmc-pcer1); +#ifdef CPU_HAS_PCR + at91_periph_clk_enable(ATMEL_ID_UHP); #else writel(1 ATMEL_ID_UHP, pmc-pcer); #endif @@ -58,8 +58,8 @@ int usb_cpu_stop(void) at91_pmc_t *pmc = (at91_pmc_t *)ATMEL_BASE_PMC; /* Disable USB host clock. */ -#ifdef CONFIG_SAMA5D3 - writel(1 (ATMEL_ID_UHP - 32), pmc-pcdr1); +#ifdef CPU_HAS_PCR + at91_periph_clk_disable(ATMEL_ID_UHP); #else writel(1 ATMEL_ID_UHP, pmc-pcdr); #endif -- 1.8.5.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] ARM: atmel: add pcr related definition
Using CPU_HAS_PCR micro to present the SoC has pcr
(peripheral control register).
Signed-off-by: Bo Shen voice.s...@atmel.com
---
arch/arm/include/asm/arch-at91/at91_pmc.h | 2 +-
arch/arm/include/asm/arch-at91/sama5d3.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/arch-at91/at91_pmc.h
b/arch/arm/include/asm/arch-at91/at91_pmc.h
index bef5793..27331ff 100644
--- a/arch/arm/include/asm/arch-at91/at91_pmc.h
+++ b/arch/arm/include/asm/arch-at91/at91_pmc.h
@@ -54,7 +54,7 @@ typedef struct at91_pmc {
u32 reserved5[21];
u32 wpmr; /* 0xE4 Write Protect Mode Register (CAP0) */
u32 wpsr; /* 0xE8 Write Protect Status Register (CAP0) */
-#ifdef CONFIG_SAMA5D3
+#ifdef CPU_HAS_PCR
u32 reserved6[8];
u32 pcer1; /* 0x100 Periperial Clock Enable Register 1 */
u32 pcdr1; /* 0x104 Periperial Clock Disable Register 1 */
diff --git a/arch/arm/include/asm/arch-at91/sama5d3.h
b/arch/arm/include/asm/arch-at91/sama5d3.h
index 6d936f4..f7bc4ad 100644
--- a/arch/arm/include/asm/arch-at91/sama5d3.h
+++ b/arch/arm/include/asm/arch-at91/sama5d3.h
@@ -188,6 +188,7 @@
#define ATMEL_PIO_PORTS5
#define CPU_HAS_PIO3
#define PIO_SCDR_DIV 0x3fff
+#define CPU_HAS_PCR
/*
* PMECC table in ROM
--
1.8.5.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] USB: ehci-atmel: use pcr to enable or disable clock
If the SoC has pcr, we use pcr (peripheral control register) to enable or disable clock. Signed-off-by: Bo Shen voice.s...@atmel.com --- drivers/usb/host/ehci-atmel.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb/host/ehci-atmel.c index 9ffe501..9a8f004 100644 --- a/drivers/usb/host/ehci-atmel.c +++ b/drivers/usb/host/ehci-atmel.c @@ -40,7 +40,11 @@ int ehci_hcd_init(int index, enum usb_init_type init, } /* Enable USB Host clock */ +#ifdef CPU_HAS_PCR + at91_periph_clk_enable(ATMEL_ID_UHPHS); +#else writel(1 ATMEL_ID_UHPHS, pmc-pcer); +#endif *hccr = (struct ehci_hccr *)ATMEL_BASE_EHCI; *hcor = (struct ehci_hcor *)((uint32_t)*hccr + @@ -55,7 +59,11 @@ int ehci_hcd_stop(int index) ulong start_time, tmp_time; /* Disable USB Host Clock */ +#ifdef CPU_HAS_PCR + at91_periph_clk_disable(ATMEL_ID_UHPHS); +#else writel(1 ATMEL_ID_UHPHS, pmc-pcdr); +#endif start_time = get_timer(0); /* Disable UTMI PLL */ -- 1.8.5.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 02/15] zynq: kconfig: move board select menu and commonsettings
Hi Michal, On Wed, 6 Aug 2014 11:10:14 +0200 Michal Simek michal.si...@xilinx.com wrote: Based on steps below - defconfigs are both empty. Linux kernel is taking .config from /boot/config-`uname -r`. Yes, but the .config of U-Boot is not installed anywhere in the host PC. I guess that is why DEFCONFIG_LIST seems meaningless... I have to admit I am still searching for the usage of this option. Maybe I do something wrong and Kconfig handles it differently but currently I can't see a reason to have this option there. I don't think you did anything wrong. [u-boot]$ make mrproper [u-boot]$ make savedefconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/zconf.lex.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf --savedefconfig=defconfig Kconfig # # using defaults found in configs/sandbox_defconfig # [u-boot]$ cat defconfig In this case, savedefconfig was done based on configs/sandbox_defconfig which is empty for now, but which will have more options in the future. [u-boot]$ vim Kconfig [u-boot]$ git diff diff --git a/Kconfig b/Kconfig index 9e77a6e28b46..1a3864557df4 100644 --- a/Kconfig +++ b/Kconfig @@ -12,12 +12,6 @@ config KCONFIG_OBJDIR string option env=KCONFIG_OBJDIR -config DEFCONFIG_LIST - string - depends on !SPL_BUILD - option defconfig_list - default configs/sandbox_defconfig - menu General setup config SPL_BUILD [u-boot]$ make mrproper CLEAN scripts/basic CLEAN scripts/kconfig [u-boot]$ make savedefconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/zconf.lex.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf --savedefconfig=defconfig Kconfig [u-boot]$ cat defconfig [u-boot]$ Whereas, this case, savedefconfig failed, that is why the file is empty. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: HYP/non-sec: Add MIDR check to detect unsupported CPUs
On Wed, Aug 06, 2014 at 08:38:13AM +0100, Ian Campbell wrote: On Mon, 2014-08-04 at 16:14 +0100, Marc Zyngier wrote: My personal feeling is that booting in secure mode is always the wrong thing to do. FWIW I agree. If you want to go down the road of a single bootloader that is able to run on several SOCs, then do it the proper way: parse the device tree and have separate constraints for your SoC. But please don't blacklist random cores just because it fits your environment. I think there is a CPU feature register which indicates whether support for HYP mode is present, isn't there? ID_PFR1[15:12] should tell you if the CPU has the virtualization extensions. In which case a tolerable fix for now (going all the way DT is a big yakk to shave...) would be to use that to decide between booting in NS.HYP vs NS.SVC (nb: not NS.HYP vs S.SVC). That sounds ideal. I don't recall if the GIC has a feature bit for the security extensions, but if not then inferring it from the CPUs support wouldn't be the worst thing in the world under the circumstances. GICD_TYPER[10] (SecurityExtn) should tell you if the GIC has the security extensions. I don't know whether you'll encounter a platform where the CPU and GIC are mismatched w.r.t. security extensions. Mark. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
Am 06.08.2014 08:43, schrieb Wolfgang Denk: Dear Alexander, In message 53dfdc99.2020...@ahsoftware.de you wrote: At least I've understood it such that nobody still has an objection=20 against the new feature for env import -t (-r). I object if it would be added without maintaining symmetry with env export. As explained I don't know how to add symmetry. It's impossible to export text concurrently in both formats. And I will not write a patch (I don't need), if I have to assume I'm wasting my time because it will never reach any possible user. So without consensus about what such a symmetry feature for env export should be and how it will look like I will not spend the (little) time to write a patch, nor the much large time to discuss the patch afterwards. Regards, Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/15] kirkwood: kconfig: refactor Kconfig and defconfig
-Original Message- From: Masahiro Yamada [mailto:yamad...@jp.panasonic.com] Sent: 06 August 2014 08:48 To: u-boot@lists.denx.de Cc: Tom Rini; Simon Glass; Masahiro Yamada; Prafulla Wadaskar; Luka Perkov Subject: [PATCH v2 06/15] kirkwood: kconfig: refactor Kconfig and defconfig Becuase the board select menu in arch/arm/Kconfig is too big, move the KirkWood board select menu to kirkwood/Kconfig. Consolidate also common settings (CONFIG_SYS_CPU=arm926ejs and CONFIG_SYS_SOC=kirkwood). Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Prafulla Wadaskar prafu...@marvell.com Cc: Luka Perkov l...@openwrt.org --- Changes in v2: - Fix some board names pointed out by Luka Perkov. arch/arm/Kconfig| 75 ++--- -- arch/arm/cpu/arm926ejs/kirkwood/Kconfig | 89 + board/LaCie/net2big_v2/Kconfig | 8 --- board/LaCie/netspace_v2/Kconfig | 8 --- board/LaCie/wireless_space/Kconfig | 8 --- board/Marvell/dreamplug/Kconfig | 8 --- board/Marvell/guruplug/Kconfig | 8 --- board/Marvell/mv88f6281gtw_ge/Kconfig | 8 --- board/Marvell/openrd/Kconfig| 8 --- board/Marvell/rd6281a/Kconfig | 8 --- board/Marvell/sheevaplug/Kconfig| 8 --- board/Seagate/dockstar/Kconfig | 8 --- board/Seagate/goflexhome/Kconfig| 8 --- board/buffalo/lsxl/Kconfig | 8 --- board/cloudengines/pogo_e02/Kconfig | 8 --- board/d-link/dns325/Kconfig | 8 --- board/iomega/iconnect/Kconfig | 8 --- board/karo/tk71/Kconfig | 8 --- board/keymile/km_arm/Kconfig| 8 --- board/raidsonic/ib62x0/Kconfig | 8 --- configs/d2net_v2_defconfig | 1 + configs/dns325_defconfig| 1 + configs/dockstar_defconfig | 1 + configs/dreamplug_defconfig | 1 + configs/goflexhome_defconfig| 1 + configs/guruplug_defconfig | 1 + configs/ib62x0_defconfig| 1 + configs/iconnect_defconfig | 1 + configs/inetspace_v2_defconfig | 1 + configs/km_kirkwood_128m16_defconfig| 1 + configs/km_kirkwood_defconfig | 1 + configs/km_kirkwood_pci_defconfig | 1 + configs/kmcoge5un_defconfig | 1 + configs/kmnusa_defconfig| 1 + configs/kmsugp1_defconfig | 1 + configs/kmsuv31_defconfig | 1 + configs/lschlv2_defconfig | 1 + configs/lsxhl_defconfig | 1 + configs/mgcoge3un_defconfig | 1 + configs/mv88f6281gtw_ge_defconfig | 1 + configs/net2big_v2_defconfig| 1 + configs/netspace_lite_v2_defconfig | 1 + configs/netspace_max_v2_defconfig | 1 + configs/netspace_mini_v2_defconfig | 1 + configs/netspace_v2_defconfig | 1 + configs/openrd_base_defconfig | 1 + configs/openrd_client_defconfig | 1 + configs/openrd_ultimate_defconfig | 1 + configs/pogo_e02_defconfig | 1 + configs/portl2_defconfig| 1 + configs/rd6281a_defconfig | 1 + configs/sheevaplug_defconfig| 1 + configs/tk71_defconfig | 1 + configs/wireless_space_defconfig| 1 + include/configs/dns325.h| 1 - include/configs/dockstar.h | 1 - include/configs/dreamplug.h | 1 - include/configs/goflexhome.h| 1 - include/configs/guruplug.h | 1 - include/configs/ib62x0.h| 1 - include/configs/iconnect.h | 1 - include/configs/km/km_arm.h | 1 - include/configs/lacie_kw.h | 1 - include/configs/lsxl.h | 1 - include/configs/mv88f6281gtw_ge.h | 1 - include/configs/openrd.h| 1 - include/configs/pogo_e02.h | 1 - include/configs/rd6281a.h | 1 - include/configs/sheevaplug.h| 1 - include/configs/tk71.h | 1 - include/configs/wireless_space.h| 1 - 71 files changed, 127 insertions(+), 232 deletions(-) Acked-by: Prafulla Wadasdkar prafu...@marvell.com Will be pulled latter... Regards... Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/15] kirkwood: kconfig: refactor Kconfig and defconfig
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot- boun...@lists.denx.de] On Behalf Of Prafulla Wadaskar Sent: 06 August 2014 15:35 To: Masahiro Yamada; u-boot@lists.denx.de Cc: Tom Rini; Luka Perkov Subject: Re: [U-Boot] [PATCH v2 06/15] kirkwood: kconfig: refactor Kconfig and defconfig -Original Message- From: Masahiro Yamada [mailto:yamad...@jp.panasonic.com] Sent: 06 August 2014 08:48 To: u-boot@lists.denx.de Cc: Tom Rini; Simon Glass; Masahiro Yamada; Prafulla Wadaskar; Luka Perkov Subject: [PATCH v2 06/15] kirkwood: kconfig: refactor Kconfig and defconfig Becuase the board select menu in arch/arm/Kconfig is too big, move the KirkWood board select menu to kirkwood/Kconfig. Consolidate also common settings (CONFIG_SYS_CPU=arm926ejs and CONFIG_SYS_SOC=kirkwood). Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Prafulla Wadaskar prafu...@marvell.com Cc: Luka Perkov l...@openwrt.org --- Changes in v2: - Fix some board names pointed out by Luka Perkov. arch/arm/Kconfig| 75 ++- -- -- arch/arm/cpu/arm926ejs/kirkwood/Kconfig | 89 + board/LaCie/net2big_v2/Kconfig | 8 --- board/LaCie/netspace_v2/Kconfig | 8 --- board/LaCie/wireless_space/Kconfig | 8 --- board/Marvell/dreamplug/Kconfig | 8 --- board/Marvell/guruplug/Kconfig | 8 --- board/Marvell/mv88f6281gtw_ge/Kconfig | 8 --- board/Marvell/openrd/Kconfig| 8 --- board/Marvell/rd6281a/Kconfig | 8 --- board/Marvell/sheevaplug/Kconfig| 8 --- board/Seagate/dockstar/Kconfig | 8 --- board/Seagate/goflexhome/Kconfig| 8 --- board/buffalo/lsxl/Kconfig | 8 --- board/cloudengines/pogo_e02/Kconfig | 8 --- board/d-link/dns325/Kconfig | 8 --- board/iomega/iconnect/Kconfig | 8 --- board/karo/tk71/Kconfig | 8 --- board/keymile/km_arm/Kconfig| 8 --- board/raidsonic/ib62x0/Kconfig | 8 --- configs/d2net_v2_defconfig | 1 + configs/dns325_defconfig| 1 + configs/dockstar_defconfig | 1 + configs/dreamplug_defconfig | 1 + configs/goflexhome_defconfig| 1 + configs/guruplug_defconfig | 1 + configs/ib62x0_defconfig| 1 + configs/iconnect_defconfig | 1 + configs/inetspace_v2_defconfig | 1 + configs/km_kirkwood_128m16_defconfig| 1 + configs/km_kirkwood_defconfig | 1 + configs/km_kirkwood_pci_defconfig | 1 + configs/kmcoge5un_defconfig | 1 + configs/kmnusa_defconfig| 1 + configs/kmsugp1_defconfig | 1 + configs/kmsuv31_defconfig | 1 + configs/lschlv2_defconfig | 1 + configs/lsxhl_defconfig | 1 + configs/mgcoge3un_defconfig | 1 + configs/mv88f6281gtw_ge_defconfig | 1 + configs/net2big_v2_defconfig| 1 + configs/netspace_lite_v2_defconfig | 1 + configs/netspace_max_v2_defconfig | 1 + configs/netspace_mini_v2_defconfig | 1 + configs/netspace_v2_defconfig | 1 + configs/openrd_base_defconfig | 1 + configs/openrd_client_defconfig | 1 + configs/openrd_ultimate_defconfig | 1 + configs/pogo_e02_defconfig | 1 + configs/portl2_defconfig| 1 + configs/rd6281a_defconfig | 1 + configs/sheevaplug_defconfig| 1 + configs/tk71_defconfig | 1 + configs/wireless_space_defconfig| 1 + include/configs/dns325.h| 1 - include/configs/dockstar.h | 1 - include/configs/dreamplug.h | 1 - include/configs/goflexhome.h| 1 - include/configs/guruplug.h | 1 - include/configs/ib62x0.h| 1 - include/configs/iconnect.h | 1 - include/configs/km/km_arm.h | 1 - include/configs/lacie_kw.h | 1 - include/configs/lsxl.h | 1 - include/configs/mv88f6281gtw_ge.h | 1 - include/configs/openrd.h| 1 - include/configs/pogo_e02.h | 1 - include/configs/rd6281a.h | 1 - include/configs/sheevaplug.h| 1 - include/configs/tk71.h | 1 - include/configs/wireless_space.h| 1 - 71 files changed, 127 insertions(+), 232 deletions(- ) Acked-by: Prafulla Wadasdkar prafu...@marvell.com Will be pulled latter... Sorry ... Just consider ack, I think this entire patch series will be pulled by u-boot ARM custodian. (if I am not
Re: [U-Boot] [PATCH] ARM: HYP/non-sec: Add MIDR check to detect unsupported CPUs
On 06/08/14 10:49, Mark Rutland wrote: On Wed, Aug 06, 2014 at 08:38:13AM +0100, Ian Campbell wrote: On Mon, 2014-08-04 at 16:14 +0100, Marc Zyngier wrote: My personal feeling is that booting in secure mode is always the wrong thing to do. FWIW I agree. If you want to go down the road of a single bootloader that is able to run on several SOCs, then do it the proper way: parse the device tree and have separate constraints for your SoC. But please don't blacklist random cores just because it fits your environment. I think there is a CPU feature register which indicates whether support for HYP mode is present, isn't there? ID_PFR1[15:12] should tell you if the CPU has the virtualization extensions. In which case a tolerable fix for now (going all the way DT is a big yakk to shave...) would be to use that to decide between booting in NS.HYP vs NS.SVC (nb: not NS.HYP vs S.SVC). That sounds ideal. I don't recall if the GIC has a feature bit for the security extensions, but if not then inferring it from the CPUs support wouldn't be the worst thing in the world under the circumstances. GICD_TYPER[10] (SecurityExtn) should tell you if the GIC has the security extensions. I don't know whether you'll encounter a platform where the CPU and GIC are mismatched w.r.t. security extensions. I know at least of one for which this is the case... which makes switching the interrupts from Group0 to Group1 a fun adventure. M. -- Jazz is not dead. It just smells funny... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mmc: set correct block size value in bfin sdh driver
From: Sonic Zhang sonic.zh...@analog.com
Wait data transfer till the data end bit other than the data block end
bit is set.
Signed-off-by: Sonic Zhang sonic.zh...@analog.com
---
drivers/mmc/bfin_sdh.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/bfin_sdh.c b/drivers/mmc/bfin_sdh.c
index bcd6a3e..9bdfbbc 100644
--- a/drivers/mmc/bfin_sdh.c
+++ b/drivers/mmc/bfin_sdh.c
@@ -138,9 +138,9 @@ static int sdh_setup_data(struct mmc *mmc, struct mmc_data
*data)
if (data-flags MMC_DATA_WRITE)
return UNUSABLE_ERR;
#ifndef RSI_BLKSZ
- data_ctl |= ((ffs(data_size) - 1) 4);
+ data_ctl |= ((ffs(data-blocksize) - 1) 4);
#else
- bfin_write_SDH_BLK_SIZE(data_size);
+ bfin_write_SDH_BLK_SIZE(data-blocksize);
#endif
data_ctl |= DTX_DIR;
bfin_write_SDH_DATA_CTL(data_ctl);
@@ -189,7 +189,8 @@ static int bfin_sdh_request(struct mmc *mmc, struct mmc_cmd
*cmd,
do {
udelay(1);
status = bfin_read_SDH_STATUS();
- } while (!(status (DAT_BLK_END | DAT_END | DAT_TIME_OUT |
DAT_CRC_FAIL | RX_OVERRUN)));
+ } while (!(status (DAT_END | DAT_TIME_OUT | DAT_CRC_FAIL |
+RX_OVERRUN)));
if (status DAT_TIME_OUT) {
bfin_write_SDH_STATUS_CLR(DAT_TIMEOUT_STAT);
--
1.8.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/25] Add Marvell Armada XP MV78460 SoC support
-Original Message- From: Stefan Roese [mailto:s...@denx.de] Sent: 05 August 2014 12:40 To: u-boot@lists.denx.de Cc: Prafulla Wadaskar; tr...@ti.com Subject: [PATCH v2 0/25] Add Marvell Armada XP MV78460 SoC support This patch series adds support for the Marvell Armada XP SoC's. Specifically the MV78460. Basic support for the db-78460-bp evaluation board is added. Supporting the following interfaces: - UART - SPI (including SPI NOR flash) - I2C - Ethernet (neta) While doing this port, I tried to consolidate common Marvell code into the arch/arm/mvebu-common directory. This directory should be used to collect more common code for the MVEBU SoC's (Dove, Kirkwood, Armada 370, Armada 380, Armada XP). I started with Kirkwood and some of its interfaces. Dove is definitely a candidate to move some of its code into thise directory as well. Because of the renaming of some functions from kirkwood to mvebu (to make them better usable on other MVEBU SoCs), this patch series not only touches the ARM SoC specific files (in arch/arm/...). But also some device drivers (e.g. SPI, I2C). Separating these driver specific patches into different patches that are not depending on this ARM patch series seems hard if not impossible. Thats why I would really like to get this patch series to get applied completely be one custodian. Not sure if this could / should go through Tom directly? Only if all the subsystem custodians have given their Acked-by ... of course. Hi Stefan, Yes, it will be difficult, so please consider my ack for Kirkwood part to inline with new SoC support. Regards... Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
Am 06.08.2014 12:02, schrieb Alexander Holler: Am 06.08.2014 08:43, schrieb Wolfgang Denk: Dear Alexander, In message 53dfdc99.2020...@ahsoftware.de you wrote: At least I've understood it such that nobody still has an objection=20 against the new feature for env import -t (-r). I object if it would be added without maintaining symmetry with env export. As explained I don't know how to add symmetry. It's impossible to export text concurrently in both formats. And I will not write a patch (I don't need), if I have to assume I'm wasting my time because it will never reach any possible user. So without consensus about what such a symmetry feature for env export should be and how it will look like I will not spend the (little) time to write a patch, nor the much large time to discuss the patch afterwards. Maybe it helps to explain my motivation to write the patch in the subject: I've run into the problem once, when I had to use a Windows box to write an uEnv.txt, and it happens extremly seldom that I'm using Windows. But then I've seen several other people running into the same problem (which is extremly hard to identify as CR is usually invisible). So I though I'm nice and write a patch to help other people (because I can write such a patch and I don't need to spend much time to do so) and everyone will be happy about. So to conclude I don't need the -r for env import myself and it just ended up with around a dozen mails where I had to defend and explain the patch. That isn't what motivates to spend time writing maintainer friendly patches and to submit them. Regards, Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
Alexander Holler hol...@ahsoftware.de writes: Am 06.08.2014 08:43, schrieb Wolfgang Denk: Dear Alexander, In message 53dfdc99.2020...@ahsoftware.de you wrote: At least I've understood it such that nobody still has an objection=20 against the new feature for env import -t (-r). I object if it would be added without maintaining symmetry with env export. As explained I don't know how to add symmetry. It's impossible to export text concurrently in both formats. What is the problem with ignoring \r on input and not writing it on output? -- Måns Rullgård m...@mansr.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/18] spl: improve spi configuration
On 05/08/14 17:11, Marek Vasut wrote: On Tuesday, August 05, 2014 at 03:28:04 PM, Nikita Kiryanov wrote: On 03/08/14 16:44, Marek Vasut wrote: On Sunday, August 03, 2014 at 09:34:31 AM, Nikita Kiryanov wrote: Currently we can define CONFIG_SPL_SPI_any parameter except SPI MODE. Define CONFIG_SPL_SPI_MODE option, and provide a default value for backwards compatibility. Default values are also provided for the rest of the spi_flash_probe parameters (like we do in cmd_sf), to help with config file brevity. Cc: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com Cc: Tom Rini tr...@ti.com Signed-off-by: Nikita Kiryanov nik...@compulab.co.il You might actually be even more bold and check if you cannot fall back to the CONFIG_DEFAULT_SPI_MODE etc. What do you think ? Not a fan of the idea. It will: - Complicate the #ifdefs - Complicate the relationship between CONFIG_DEFAULT_SPI_* and CONFIG_SPL_SPI_* #defines - Not get much use: most boards do not #define CONFIG_DEFAULT_SPI_* values in the config files, and of the ones that do, only two (dra7xx_evm and cm_fx6) use SPI in SPL. On the other hand, it's now only a matter of time until we get CONFIG_TPL_SPI_* m which gives us _another_ set of defines. So the question is -- what is your proposition to keep the amount of new ad-hoc defines low and cater for this case? OK I think I may have misunderstood your suggestion. You wanted to replace CONFIG_SPL_SPI_* #defines with CONFIG_DEFAULT_SPI_* #defines, not use both, right? Based on cursory grepping, this seems possible, though I think CONFIG_SF_DEFAULT_* is a better candidate. I'll prepare a patch.. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers: rtc: remove dead drivers
Hi Simon, On 06/08/2014 04:34, Simon Glass wrote: I agree with Tom. RTC_MX27 was tested and submitted with the armadeus apf27 board, but then another RTC was chosen on this target. The RTC_MX27 remains ready to be used. It is easy to enable this driver on some other targets - if these kind of drivers are not explicitely broken, I think we should let live in mainline. Would it be possible to add a board to use these, just so it is not dead code? Even a fake board? We can add it to the apf27 board (without adding a fake board) because the driver was tested only on this board. Best regards, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCH] video: add cfb console driver for sunxi
Hi, On 08/06/2014 09:24 AM, Koen Kooi wrote: Op 5 aug. 2014, om 23:37 heeft Michal Suchanek hramr...@gmail.com het volgende geschreven: On 5 August 2014 23:03, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Mon, Aug 04, 2014 at 05:05:00PM +0200, Luc Verhaegen wrote: On Mon, Aug 04, 2014 at 10:39:13AM +0200, Hans de Goede wrote: Hi Luc, First of all many thanks for your work on this. ATM I don't have time to do a full review, but I don't expect there to be too many suprises when I do find the time. Really my only concern is the handover of the reserved memory, etc. to the kernel. We need to get a plan in place for that *before* this can be merged. Note I don't want to raise any artificial barriers here, I would love to see this merged ASAP. But I don't want to paint us in a corner where u-boot having hdmi console support makes it harder to get kms support in the kernel going. I think we can both agree on that. So I really want to see some plan how this will work in place before merging. Note just a plan, I don't expect kernel patches ready to be merged for this, just a good idea / sketch of how all the bits will fit together. Memory is not the biggest worry. Some kernel code needs to claim clocks if the mode is to cleanly survive the start of the kernel. If not, there is no coming back until a proper display driver runs. If the simplefb driver claims these clocks, then the simplefb driver also must release these clocks, and this driver should then never be started again, so it should set the simplefb dt node status to disabled. I'm probably missing a bit of context, but one thing I still don't get is why you're taking into account the simplefb - KMS handover. It's a case that shouldn't exist. By essence, simplefb has never been meant for that. It's been meant to have a temporary solution until a full-fledged driver is merged in the kernel. Which is exactly the case we're into. It's a permanent temporary solution. Same as offb/vesafb/uefi and other unaccelerated drivers. It will be needed for platforms on which KMS is not (yet) fully supported or happens to break. Also how else do you express the fact that u-boot has left the display enabled other than generating the simplefb DT node? Note that the KMS driver will be probably unsuitable for early console while the simplefb driver can just write into the framebuffer set up by u-boot. Both simplefb and the potention sunxifb will be using the same kernel infrastructure and start printing at the same time, so your argument about simplefb being able to print 'earlier' is nonsense. Distros typically build kms drivers as modules, since there can be many different gpus on a single platform (even for arm now that we have multi arm v7 support). So I think that having simplefb build in, and then having the kms driver taking over when it loads make sense, and this is also more or less how it works on x86. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
Am 06.08.2014 12:44, schrieb Måns Rullgård: Alexander Holler hol...@ahsoftware.de writes: Am 06.08.2014 08:43, schrieb Wolfgang Denk: Dear Alexander, In message 53dfdc99.2020...@ahsoftware.de you wrote: At least I've understood it such that nobody still has an objection=20 against the new feature for env import -t (-r). I object if it would be added without maintaining symmetry with env export. As explained I don't know how to add symmetry. It's impossible to export text concurrently in both formats. What is the problem with ignoring \r on input and not writing it on output? None. Please read the mails before. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 02/15] zynq: kconfig: move board select menu and commonsettings
Hi Masahiro, On 08/06/2014 11:48 AM, Masahiro Yamada wrote: Hi Michal, On Wed, 6 Aug 2014 11:10:14 +0200 Michal Simek michal.si...@xilinx.com wrote: Based on steps below - defconfigs are both empty. Linux kernel is taking .config from /boot/config-`uname -r`. Yes, but the .config of U-Boot is not installed anywhere in the host PC. I guess that is why DEFCONFIG_LIST seems meaningless... I have to admit I am still searching for the usage of this option. ok. great.. Maybe I do something wrong and Kconfig handles it differently but currently I can't see a reason to have this option there. I don't think you did anything wrong. [u-boot]$ make mrproper [u-boot]$ make savedefconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/zconf.lex.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf --savedefconfig=defconfig Kconfig # # using defaults found in configs/sandbox_defconfig # [u-boot]$ cat defconfig In this case, savedefconfig was done based on configs/sandbox_defconfig which is empty for now, but which will have more options in the future. No problem with that. The question and my concern is that every .config will contain this line and this is just one usage which is questionable. IMHO if there is no .config savedefconfig should failed to let user to know that something is wrong. But that's just my opinion. [u-boot]$ vim Kconfig [u-boot]$ git diff diff --git a/Kconfig b/Kconfig index 9e77a6e28b46..1a3864557df4 100644 --- a/Kconfig +++ b/Kconfig @@ -12,12 +12,6 @@ config KCONFIG_OBJDIR string option env=KCONFIG_OBJDIR -config DEFCONFIG_LIST - string - depends on !SPL_BUILD - option defconfig_list - default configs/sandbox_defconfig - menu General setup config SPL_BUILD [u-boot]$ make mrproper CLEAN scripts/basic CLEAN scripts/kconfig [u-boot]$ make savedefconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/zconf.lex.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf --savedefconfig=defconfig Kconfig [u-boot]$ cat defconfig [u-boot]$ Whereas, this case, savedefconfig failed, that is why the file is empty. It doesn't look at it is failing - just don't use that default one. [u-boot]$ make mrproper CLEAN scripts/basic CLEAN scripts/kconfig [u-boot]$ git diff diff --git a/Kconfig b/Kconfig index 9e77a6e28b46..1a3864557df4 100644 --- a/Kconfig +++ b/Kconfig @@ -12,12 +12,6 @@ config KCONFIG_OBJDIR string option env=KCONFIG_OBJDIR -config DEFCONFIG_LIST - string - depends on !SPL_BUILD - option defconfig_list - default configs/sandbox_defconfig - menu General setup config SPL_BUILD [u-boot]$ make savedefconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/zconf.lex.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf --savedefconfig=defconfig Kconfig [u-boot]$ echo $? 0 [u-boot]$ Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 02/15] zynq: kconfig: move board select menu and commonsettings
Hi Masahiro, On 08/06/2014 11:48 AM, Masahiro Yamada wrote: Hi Michal, On Wed, 6 Aug 2014 11:10:14 +0200 Michal Simek michal.si...@xilinx.com wrote: Based on steps below - defconfigs are both empty. Linux kernel is taking .config from /boot/config-`uname -r`. Yes, but the .config of U-Boot is not installed anywhere in the host PC. I guess that is why DEFCONFIG_LIST seems meaningless... I have to admit I am still searching for the usage of this option. ok. great.. Maybe I do something wrong and Kconfig handles it differently but currently I can't see a reason to have this option there. I don't think you did anything wrong. [u-boot]$ make mrproper [u-boot]$ make savedefconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/zconf.lex.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf --savedefconfig=defconfig Kconfig # # using defaults found in configs/sandbox_defconfig # [u-boot]$ cat defconfig In this case, savedefconfig was done based on configs/sandbox_defconfig which is empty for now, but which will have more options in the future. No problem with that. The question and my concern is that every .config will contain this line and this is just one usage which is questionable. IMHO if there is no .config savedefconfig should failed to let user to know that something is wrong. But that's just my opinion. [u-boot]$ vim Kconfig [u-boot]$ git diff diff --git a/Kconfig b/Kconfig index 9e77a6e28b46..1a3864557df4 100644 --- a/Kconfig +++ b/Kconfig @@ -12,12 +12,6 @@ config KCONFIG_OBJDIR string option env=KCONFIG_OBJDIR -config DEFCONFIG_LIST - string - depends on !SPL_BUILD - option defconfig_list - default configs/sandbox_defconfig - menu General setup config SPL_BUILD [u-boot]$ make mrproper CLEAN scripts/basic CLEAN scripts/kconfig [u-boot]$ make savedefconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/zconf.lex.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf --savedefconfig=defconfig Kconfig [u-boot]$ cat defconfig [u-boot]$ Whereas, this case, savedefconfig failed, that is why the file is empty. It doesn't look at it is failing - just don't use that default one. [u-boot]$ make mrproper CLEAN scripts/basic CLEAN scripts/kconfig [u-boot]$ git diff diff --git a/Kconfig b/Kconfig index 9e77a6e28b46..1a3864557df4 100644 --- a/Kconfig +++ b/Kconfig @@ -12,12 +12,6 @@ config KCONFIG_OBJDIR string option env=KCONFIG_OBJDIR -config DEFCONFIG_LIST - string - depends on !SPL_BUILD - option defconfig_list - default configs/sandbox_defconfig - menu General setup config SPL_BUILD [u-boot]$ make savedefconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/zconf.lex.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf --savedefconfig=defconfig Kconfig [u-boot]$ echo $? 0 [u-boot]$ Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/18] spl: improve spi configuration
On Wednesday, August 06, 2014 at 12:53:19 PM, Nikita Kiryanov wrote: On 05/08/14 17:11, Marek Vasut wrote: On Tuesday, August 05, 2014 at 03:28:04 PM, Nikita Kiryanov wrote: On 03/08/14 16:44, Marek Vasut wrote: On Sunday, August 03, 2014 at 09:34:31 AM, Nikita Kiryanov wrote: Currently we can define CONFIG_SPL_SPI_any parameter except SPI MODE. Define CONFIG_SPL_SPI_MODE option, and provide a default value for backwards compatibility. Default values are also provided for the rest of the spi_flash_probe parameters (like we do in cmd_sf), to help with config file brevity. Cc: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com Cc: Tom Rini tr...@ti.com Signed-off-by: Nikita Kiryanov nik...@compulab.co.il You might actually be even more bold and check if you cannot fall back to the CONFIG_DEFAULT_SPI_MODE etc. What do you think ? Not a fan of the idea. It will: - Complicate the #ifdefs - Complicate the relationship between CONFIG_DEFAULT_SPI_* and CONFIG_SPL_SPI_* #defines - Not get much use: most boards do not #define CONFIG_DEFAULT_SPI_* values in the config files, and of the ones that do, only two (dra7xx_evm and cm_fx6) use SPI in SPL. On the other hand, it's now only a matter of time until we get CONFIG_TPL_SPI_* m which gives us _another_ set of defines. So the question is -- what is your proposition to keep the amount of new ad-hoc defines low and cater for this case? OK I think I may have misunderstood your suggestion. You wanted to replace CONFIG_SPL_SPI_* #defines with CONFIG_DEFAULT_SPI_* #defines, not use both, right? Based on cursory grepping, this seems possible, though I think CONFIG_SF_DEFAULT_* is a better candidate. I'll prepare a patch.. Yep, 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] video: add cfb console driver for sunxi
On Tue, Aug 05, 2014 at 01:56:36PM +0200, Hans de Goede wrote:
Hi,
On 08/02/2014 06:14 PM, Luc Verhaegen wrote:
This adds a fixed mode hdmi driver (lcd to be added in future) for the
sunxi platform. Current config is such that 8MB is shaved off at the top
of the RAM. Simplefb support is available for kernels that know how to
use it.
I've been trying to follow all the discussion in this thread, and here
is what I think we should do:
1) There has been some discussion about using this console-driver
in u-boot without generating the simplefb dt node. This means yet another
variation in how all the bits fit together, so I don't think we should do
this. Note I realize that the original patch did not have a specific
config option for this, but it was mentioned later in the thread.
TL;DR: Enabling the console driver will always generate the simplefb dt
node.
When we do not claim clocks, we luckily cleanly disable hw, in our case.
2) I think we can worry about what to do with the reserved memory\when not
using simplefb
(or when switching from simplefb to kms) later. For now lets focus on the
issue with the clocks.
Yes, this was the plan all along.
3) To me the issue with clocks seems simple, we should modify the
devicetree binding for simplefb to support a clocks property, and modify
the simplefb kernel code to get + prep_and_enable any clocks specified
in the dt node.
For me, an important part of this discussion was seemingly flawed way in
which clocks are defined. I was of course not going to completely
overturn the thinking here, but i had expected that people would've at
least agreed that something was obviously awry, as there are several
obvious indicators there.
This means parsing enough of the dt to find the clocks to be able to
specify phandles to them in the added node. I don't know how hard it will
be to do this in u-boot, but IMHO it is simply the right thing to do, so
this is how it should be done.
No, you do not need to add nodes. This was never the case. ahb_gates
is never used like that.
It is either used as ahb_gates bit from the dt, or ahb_bitname
from kernel code which directly references clocks, with the
ahb_bitnames listed as part of ahb_gates in the clock-output-names
property. This lack of symmetry is one very clear sign.
The fact that only the kernel knows how to map the clock-output-names
list, which is only defined in the dts, to bits only defined in the clk
driver code in the kernel, that's another very clear sign.
If others agree that specifying the clocks in the simplefb dt node is
the right way to ensure that the clocks don't get enabled I'm willing
at taking a shot on coding this.
I have been on it since last friday, when i started seeing the issues
here, but haven't done much code til now, and am only uncovering many
more inconsistencies.
For instance, in the linux kernel,
Documentation/devicetree/bindings/clock/clock-bindings.txt only adds to
the confusion.
Now trying to find a working solution from the kernel side, as i already
manually inserted 6 u32s: {phandle, bit, phandle, bit, phandle, bit}.
Wait and see how that pans out, but i know that this will not provide a
proper or lasting solution, as the pairs of cells needed now will at one
point need to be mixed with directly referenced clocks (pll3/pll7, which
are currently not defined in dts yet).
Luc Verhaegen.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
Am 06.08.2014 13:18, schrieb Alexander Holler: Am 06.08.2014 12:44, schrieb Måns Rullgård: Alexander Holler hol...@ahsoftware.de writes: Am 06.08.2014 08:43, schrieb Wolfgang Denk: Dear Alexander, In message 53dfdc99.2020...@ahsoftware.de you wrote: At least I've understood it such that nobody still has an objection=20 against the new feature for env import -t (-r). I object if it would be added without maintaining symmetry with env export. As explained I don't know how to add symmetry. It's impossible to export text concurrently in both formats. What is the problem with ignoring \r on input and not writing it on output? None. Please read the mails before. And just in case it has become difficult to follow this thread because the subject should have changed to something else, I think what Wolfgang Denk wants is an option to extent env export to export the environment to text files with CRLF. I've made a suggestion here: http://lists.denx.de/pipermail/u-boot/2014-August/185272.html But as there was no response until now (I'm not impatient, I'm just mentioning it again because I think you've missed about what Wolfgang Denk started to discuss). it's just an assumption from me, I don't have any clue what he means with symmetry in regard to that -r. And without any consensus I will not spend the time to write the few lines of source to implement that (I don't need it). As written before, I don't even care much if -r for env export -t ends up in mainline U-Boot. So there is no problem, Wolfgang Denk and I are just discussing if and how to extend env export. That is at least how I do now understand this thread about the simple patch I've posted some years ago. Regards, Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] Re: [PATCH] video: add cfb console driver for sunxi
On Tue, Aug 05, 2014 at 11:37:11PM +0200, Michal Suchanek wrote: I'm probably missing a bit of context, but one thing I still don't get is why you're taking into account the simplefb - KMS handover. It's a case that shouldn't exist. By essence, simplefb has never been meant for that. It's been meant to have a temporary solution until a full-fledged driver is merged in the kernel. Which is exactly the case we're into. It's a permanent temporary solution. Same as offb/vesafb/uefi and other unaccelerated drivers. It will be needed for platforms on which KMS is not (yet) fully supported or happens to break. Yeah, I get that part, but there's no handover in this case. Also how else do you express the fact that u-boot has left the display enabled other than generating the simplefb DT node? Just like timers, UARTs, i2c, ethernet, and any other controller that might be used by the OS: the OS should deal with it. We don't use a simplefb-equivalent for the PMIC, or for the GMAC, I don't see why we should use one here to deal with that issue. What resources are you afraid to waste here? clocks are reclaimed automatically, memory is not, but simplefb won't help, see our discussion on the othre thread about this patch. Note that the KMS driver will be probably unsuitable for early console while the simplefb driver can just write into the framebuffer set up by u-boot. They both step in at the same time. simplefb is not a solution for that either. -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-blackfin
On Mon, Aug 04, 2014 at 09:56:45AM +0800, Sonic Zhang wrote: Hi Tom, Please pull the following patches for Blackfin from u-boot-blackfin into your tree. Thanks Sonic Zhang The following changes since commit e1b362f4425209d836f230a872ef2bf04b45de27: boards.cfg : Add maintainers entries for SOCFPGA (2014-07-29 11:51:03 -0400) are available in the git repository at: git://git.denx.de/u-boot-blackfin.git master for you to fetch changes up to 97cd2735b279068037013426977c44f45a8d5151: support blackfin board initialization in generic board_f (2014-08-01 18:21:45 +0800) Aaron Wu (1): bfin: add register define required by core B on dual core BF609 processor Scott Jiang (1): blackfin: spi clock is in sysclk1 domain instead of sysclk0 Sonic Zhang (2): blackfin: convert blackfin board_f and board_r to use generic board init functions support blackfin board initialization in generic board_f arch/blackfin/config.mk | 3 + arch/blackfin/cpu/cpu.c | 333 +++-- arch/blackfin/cpu/start.S| 14 +- arch/blackfin/cpu/u-boot.lds | 4 +- arch/blackfin/include/asm/clock.h| 2 +- arch/blackfin/include/asm/mach-bf609/BF609_def.h | 2 + arch/blackfin/include/asm/u-boot.h | 3 + arch/blackfin/lib/Makefile | 7 +- arch/blackfin/lib/board.c| 443 --- arch/blackfin/lib/sections.c | 11 + common/board_f.c | 35 +- include/configs/bfin_adi_common.h| 4 + include/watchdog.h | 2 +- 13 files changed, 366 insertions(+), 497 deletions(-) delete mode 100644 arch/blackfin/lib/board.c create mode 100644 arch/blackfin/lib/sections.c With this applied, MAKEALL -a blackfin fails for a number of boards. In addition, this also breaks m68k as they haven't switched over to generic board yet and need: diff --git a/include/watchdog.h b/include/watchdog.h index 174c894..9273fa1 100644 --- a/include/watchdog.h +++ b/include/watchdog.h @@ -21,7 +21,8 @@ int init_func_watchdog_reset(void); #endif -#if defined(CONFIG_WATCHDOG) || defined(CONFIG_HW_WATCHDOG) +#if defined(CONFIG_SYS_GENERIC_BOARD) \ + (defined(CONFIG_WATCHDOG) || defined(CONFIG_HW_WATCHDOG)) #define INIT_FUNC_WATCHDOG_INITinit_func_watchdog_init, #define INIT_FUNC_WATCHDOG_RESET init_func_watchdog_reset, #else So, NAK. -- 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 v5 05/11] exynos: dts: Adjust device tree files for U-Boot
And these, as you said I think, are HW description things that should be included in the master DT file upstream, right? Well we only need them because we are added 'reg' properties to the subnodes. There would certainly be no harm in including them upstream. The only bad thing I'm doing is the 'Replicate the ordering' bit. That should just go away once the GPIO numbering doesn't matter anymore (which requires that we use the device tree binding in GPIOs - this is the next step!). HI Simon, I'm trying to understand what you are saying here. Specifically, is this your solution to the GPIO renumbering problem that I've droning on and on about? jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] uboot imx-usb-loader
Hello I am trying to send a u-boot i built from denx sources to my SabreLite board, but when i use imx-usb-loader, it doesn't work because of an unknown load adress. Does someone know how to fix this? Regards Alexandre Delove ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 02/13] buildman: Add some notes about moving from MAKEALL
Hi York, On 5 August 2014 20:53, York Sun york...@freescale.com wrote: On 8/5/14 7:15 PM, Simon Glass s...@chromium.org wrote: But in this case why not just leave off the 'freescale'? This is just an example. What if I chose -a arm and -v freescale. ARM has 300+ targets, but only 20+ are for Freescale. I could save time by building a lot less platforms. The point here is the OR logic. I suppose you could use mx6 or similar, but I take your point. So what could we do here? Perhaps add a --vendor flag to limit to a particular vendor? Would that be enough? With the ability to build targets for more than one arch, I will be tempted to use syntax like this buildman (powerpc freescale) (arm freescale) aarch64 buildman mpc85xx mpc83xx mpc86xx (arm freescale) aarch64 buildman powerpc (arm freescale) aarch64 I can see myself using these commands if they can be supported. Gosh that sounds like a lot of complexity. Can you explain what you would want these commands to do? Beside, buildman still needs boards.cfg. It takes long to generate this file. So does MAKEALL, right? Yes. MAKEALL also generates the boards.cfg. Not too long, but if my other tools clean the working directory for each commit, this accumulates to long time. Can you expand on at a little please? I'm not sure what this refers to. Again it is our internal tools of choice. We use Gerrit and Jenkins. Each commit triggers a build on Jenkins. Right now I use MAKEALL to build the concerned targets. Before each build, the working directory is checkout out to that particular commit and cleaned. So if each build needs to generate the boards.cfg, a lot of time will be consumed if I have many commits in the queue. I don't think it works like that. Once you have a boards.cfg you don't need to regenerate it. Granted if a patch adds a new board there will be confusion. I use git clean -xfqd after checkout every commit to make sure I have a clean working directory. Each commit can potentially add/remove a board. Then again, you will have the same problem with MAKEALL so it is more a Kconfig/process question than a buildman one. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-mpc85xx.git master
On Fri, Aug 01, 2014 at 02:23:14PM -0700, York Sun wrote: Tom, The following changes since commit fb5368789a45ca5ee4396cbbf563a8f16ab24f9c: board/freescale: use generic board architecture for t2080qds and t2080rdb (2014-07-23 12:40:30 -0700) are available in the git repository at: git://git.denx.de/u-boot-mpc85xx.git master for you to fetch changes up to e3917b21c05776b41663bdfcc7666aca11a381a0: kmp204x: prepare to use CPU watchdog (2014-08-01 14:18:59 -0700) Boschung, Rainer (9): mpc85xx: fix interrupt init to not affect watchdog powerpc: macros for e500mc timer regs added mpc85xx: watchdog initialisation added powerpc: mpc85xx watchdog init added to init_func kmp204x: CPU watchdog enabled kmp204x/qrio: prepare support for the CPU watchdog reset reason kmp204x: set CPU watchdog reset reason flag kmp204x/qrio: support for setting the CPU reset request mode kmp204x: prepare to use CPU watchdog arch/powerpc/cpu/mpc85xx/cpu.c|8 arch/powerpc/cpu/mpc85xx/interrupts.c |2 +- arch/powerpc/include/asm/processor.h |5 + arch/powerpc/lib/board.c |3 +++ board/keymile/kmp204x/kmp204x.c | 15 +++ board/keymile/kmp204x/kmp204x.h |7 +++ board/keymile/kmp204x/qrio.c | 32 include/configs/km/kmp204x-common.h |8 include/watchdog.h|4 9 files changed, 83 insertions(+), 1 deletion(-) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-mmc 1/08/2014
On Fri, Aug 01, 2014 at 08:21:23PM +0300, Pantelis Antoniou wrote: Hi Tom, The following changes since commit 25b4adbba018633b943a99322bfb2fb819c0bafb: include: remove CONFIG_SPL/CONFIG_TPL definition in config headers (2014-07-30 14:42:03 -0400) are available in the git repository at: git://git.denx.de/u-boot-mmc.git master for you to fetch changes up to 6e7b7df4df435742fcfde5f384760ae1bda2e39c: env_mmc: support env partition setup in runtime (2014-08-01 20:12:15 +0300) Bo Shen (3): MMC: atmel_mci: refactor setting the mode register MMC: atmel_mci: add configuration register definition MMC: atmel_mci: enable high speed mode support Chin Liang See (1): mmc/dw_mmc: Fix clock divider calculation error for bypass mode Dmitry Lifshitz (2): env_mmc: add mmc_get_env_addr() prototype env_mmc: support env partition setup in runtime DrEagle (1): ARM: kirkwood: add mvsdio driver Lubomir Rintel (1): bcm2835_sdhci: Add SDHCI_QUIRK_NO_HISPD_BIT flag Marek Vasut (2): arm: s3c: Unify the S3C24xx SDI structure mmc: s3c: Add SD driver arch/arm/cpu/arm926ejs/kirkwood/cpu.c | 9 +++ arch/arm/include/asm/arch-kirkwood/kirkwood.h | 1 + arch/arm/include/asm/arch-s3c24x0/s3c2410.h | 4 +- arch/arm/include/asm/arch-s3c24x0/s3c2440.h | 4 +- arch/arm/include/asm/arch-s3c24x0/s3c24x0.h | 19 +++-- common/env_mmc.c | 35 ++--- drivers/mmc/Makefile | 2 + drivers/mmc/bcm2835_sdhci.c | 2 +- drivers/mmc/dw_mmc.c | 5 +- drivers/mmc/gen_atmel_mci.c | 63 +++ drivers/mmc/mvebu_mmc.c | 361 ++ drivers/mmc/s3c_sdi.c | 321 include/atmel_mci.h | 18 - include/configs/openrd.h | 8 ++ include/configs/sheevaplug.h | 11 +++ include/environment.h | 9 +++ include/mvebu_mmc.h | 278 ++ 17 files changed, 1109 insertions(+), 41 deletions(-) create mode 100644 drivers/mmc/mvebu_mmc.c create mode 100644 drivers/mmc/s3c_sdi.c create mode 100644 include/mvebu_mmc.h Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-dm.git
On Mon, Aug 04, 2014 at 05:28:21AM -0600, Simon Glass wrote: Hi Tom, These are the two remaining malloc() changes for arm. If Albert would prefer to pull these that is fine with me too. The following changes since commit 25b4adbba018633b943a99322bfb2fb819c0bafb: include: remove CONFIG_SPL/CONFIG_TPL definition in config headers (2014-07-30 14:42:03 -0400) are available in the git repository at: ssh://gu...@git.denx.de/u-boot-dm for you to fetch changes up to 76a1e584e10d14f1981f65376636ecff80bdc19b: arm: Support pre-relocation malloc() (2014-08-04 05:24:35 -0600) Simon Glass (2): arm: Set up global data before board_init_f() arm: Support pre-relocation malloc() README| 3 +++ arch/arm/include/asm/config.h | 2 ++ arch/arm/lib/crt0.S | 12 3 files changed, 17 insertions(+) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] git-mailrc: add a kconfig alias
On Thu, Jul 31, 2014 at 05:30:03PM -0600, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com It's easier to Cc Masahiro on Kconfig-related changes with a git-mailrc alias. Signed-off-by: Stephen Warren swar...@nvidia.com Acked-by: Masahiro Yamada yamad...@jp.panasonic.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] doc: delete README.ARM-SoC
On Tue, Aug 05, 2014 at 03:25:32PM +0900, Masahiro Yamada wrote: This document is too old and useless. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-spi/master
On Wed, Aug 06, 2014 at 12:22:15AM +0530, Jagannadha Sutradharudu Teki wrote: Hi Tom, Please pull this PR. thanks! Jagan. The following changes since commit 25b4adbba018633b943a99322bfb2fb819c0bafb: include: remove CONFIG_SPL/CONFIG_TPL definition in config headers (2014-07-30 14:42:03 -0400) are available in the git repository at: git://git.denx.de/u-boot-spi.git master for you to fetch changes up to f659b57361c4a351ef2a5fc23b9197428e2e67f0: spi, spi_mxc: do not hang in spi_xchg_single (2014-08-06 00:18:01 +0530) Heiko Schocher (1): spi, spi_mxc: do not hang in spi_xchg_single Marek Vasut (1): sf: sf_ops: Stop leaking memory Simon Glass (3): cros_ec: Fix two bugs in the SPI implementation exynos: spi: Fix calculation of SPI transaction start time spi: Support half-duplex mode in FDT decode README | 4 doc/device-tree-bindings/spi/spi-bus.txt | 2 ++ drivers/misc/cros_ec_spi.c | 4 ++-- drivers/mtd/spi/sf_ops.c | 1 + drivers/spi/exynos_spi.c | 9 + drivers/spi/mxc_spi.c| 17 +++-- drivers/spi/spi.c| 2 ++ 7 files changed, 31 insertions(+), 8 deletions(-) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] doc: README.SPL: adjust for Kbuild and Kconfig
On Tue, Aug 05, 2014 at 03:25:06PM +0900, Masahiro Yamada wrote: Reflect the latest build system to doc/README.SPL. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] The _config target is not present anymore, mention _defconfig instead
On Mon, Aug 04, 2014 at 09:26:05AM +0200, Holger Freyther wrote: The _config part is gone for sure, the _defconfig target could at least work. I have not verified this for all targets though. Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Change Andy Fleming's email address
On Fri, Jul 25, 2014 at 05:39:08PM -0500, Andy Fleming wrote: Messages to aflem...@freescale.com now bounce, and should be directed to my personal address at aflem...@gmail.com Signed-off-by: Andy Fleming aflem...@gmail.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [ANN] U-Boot v2014.07-rc1 released
Hey all, I've pushed v2017.10-rc1 out to the repository and tarballs should exist soon. The merge window is now, really, closed. I was hoping to do this Monday but it took a little longer dealing with some pull requests than I had hoped. Before looking over the diffstat and logs, the big thing is Kconfig support. A giganticly huge THANK YOU to Masahiro Yamada for all the hard work to get us this far. Aside from the usual platforms / SoC additions and fixes/cleanups, we're making more progress on device model work. Looking over my patchwork TODO list, I see I've let it get a bit large, so I'm going to focus on clearing it out, both master and TI related stuff. As always, if anything is broken please speak up. Thanks all! -- 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 v4 02/13] buildman: Add some notes about moving from MAKEALL
On Wed, Aug 06, 2014 at 08:20:47AM -0600, Simon Glass wrote: Hi York, On 5 August 2014 20:53, York Sun york...@freescale.com wrote: On 8/5/14 7:15 PM, Simon Glass s...@chromium.org wrote: But in this case why not just leave off the 'freescale'? This is just an example. What if I chose -a arm and -v freescale. ARM has 300+ targets, but only 20+ are for Freescale. I could save time by building a lot less platforms. The point here is the OR logic. I suppose you could use mx6 or similar, but I take your point. So what could we do here? Perhaps add a --vendor flag to limit to a particular vendor? Would that be enough? With the ability to build targets for more than one arch, I will be tempted to use syntax like this buildman (powerpc freescale) (arm freescale) aarch64 Spaces outside of parens are implicit ORs here, so all powerpc+freescale, all arm+freescale and all aarch64. In the fullness of time the last one might become all freescale+aarch64. Bonus points if we can easily write 'buildman ... ((powerpc|arm|aarch64) freescale)' Thinking out loud, the problem is today we have | for OR but we don't have an AND symbol. I can do: $ buildman 'arm|powerpc|aarch64' Today and get what I want. But I can't: $ buildman '(powerpcfreescale)|(armfreescale)' -- 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 v5 05/11] exynos: dts: Adjust device tree files for U-Boot
Hi Jon, On 6 August 2014 07:56, Jon Loeliger loeli...@gmail.com wrote: And these, as you said I think, are HW description things that should be included in the master DT file upstream, right? Well we only need them because we are added 'reg' properties to the subnodes. There would certainly be no harm in including them upstream. The only bad thing I'm doing is the 'Replicate the ordering' bit. That should just go away once the GPIO numbering doesn't matter anymore (which requires that we use the device tree binding in GPIOs - this is the next step!). HI Simon, I'm trying to understand what you are saying here. Specifically, is this your solution to the GPIO renumbering problem that I've droning on and on about? No this is unrelated. The existing exynos4 code defines the GPIOs in a particular order, and the DT has them in a different order (and there are not aliases to change it). So it's really just a work-around until we can get away from having GPIO defines in exynos. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT] Pull request: u-boot-dfu
On 07/23/2014 12:15 PM, Marek Vasut wrote: On Wednesday, July 16, 2014 at 09:18:56 AM, Lukasz Majewski wrote: Dear Marek, The following changes since commit 5ba95541b700d2edecb4d97d4b905f51ed8551b3: usb: phy: omap_usb_phy: implement usb_phy_power() for AM437x (2014-07-09 22:11:51 +0200) are available in the git repository at: ssh://gu-...@git.denx.de/u-boot-dfu/master for you to fetch changes up to 24b109300c6e6a35792bc804846d7753baba7a69: dfu: fix readback buffer overflow test (2014-07-16 08:47:01 +0200) Fixed up one merge conflict and applied, thanks! These changes don't seem to have made it into u-boot/master yet. I assume they will for the v2014.10 release? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] pxe: clear Bootfile before returning
On 07/23/2014 03:56 PM, Joe Hershberger wrote: On Wed, Jul 23, 2014 at 4:41 PM, Stephen Warren swar...@wwwdotorg.org mailto:swar...@wwwdotorg.org wrote: On 07/23/2014 03:37 PM, Joe Hershberger wrote: On Tue, Jul 22, 2014 at 7:06 PM, Stephen Warren swar...@wwwdotorg.org mailto:swar...@wwwdotorg.org mailto:swar...@wwwdotorg.org mailto:swar...@wwwdotorg.org wrote: From: Stephen Warren swar...@nvidia.com mailto:swar...@nvidia.com mailto:swar...@nvidia.com mailto:swar...@nvidia.com When pxe boot downloads the initrd/kernel/DTB, netboot_common() saves the downloaded filename to global variable BootFile. If the boot operation is aborted, this global state is not cleared. If dhcp is executed later without any arguments, BootFile is not cleared, and when the DHCP response is received, BootpCopyNetParams() writes the value into environment variable bootfile. ... Acked-by: Joe Hershberger joe.hershber...@ni.com mailto:joe.hershber...@ni.com mailto:joe.hershber...@ni.com mailto:joe.hershber...@ni.com Thanks. I'm not sure if you ack'd this simply so you'd remember you'd reviewed it, or because you expect someone else to apply the change? If the latter, I should forward the patch to them so they know about it:-) Partly for me to remember and partly because recently Tom has been picking these few net things up directly. Tom, are you planning on picking up this patch? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: BOOTP retry timeout improvements
On 07/25/2014 05:30 PM, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com Currently, the BOOTP code sends out its initial request as soon as the Ethernet driver indicates link up. If this packet is lost or not replied to for some reason, the code waits for a 1s timeout before retrying. For some reason, such early packets are often lost on my system, so this causes an annoying delay. To optimize this, modify the BOOTP code to have very short timeouts for the first packet transmitted, but gradually increase the timeout each time a timeout occurs. This way, if the first packet is lost, the second packet is transmitted quite quickly and hence the overall delay is low. However, if there's still no response, we don't keep spewing out packets at an insane speed. It's arguably more correct to try and find out why the first packet is lost. However, it seems to disappear inside my Ethenet chip; the TX chip indicates no error during TX (not that it has much in the way of reporting...), yet wireshark on the RX side doesn't see any packet. FWIW, I'm using an ASIX USB Ethernet adapter. Perhaps link up is reported too early or based on the wrong condition in HW, and we should add some fixed extra delay into the driver. However, this would slow down every link up event even if it ends up not being needed in some cases. Having BOOTP retry quickly applies the fix/WAR to every possible Ethernet device, and is quite simple to implement, so seems a better solution. Joe, Tom, Does this patch look OK? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd
On 07/30/2014 04:37 PM, Stephen Warren wrote: From: Dennis Gilmore den...@ausil.us This generic $bootcmd, and associated support macros, automatically searches a defined set of storage devices (or network protocols) for an extlinux configuration file or U-Boot boot script in various standardized locations. Distros that install such a boot config file/script in those standard locations will get easy-to-set-up booting on HW that enables this generic $bootcmd. Simon, are you OK with these patches following the discussion? Dennis, I assume you're OK with the new version of this patch? I assume that your acks would go a long way towards Tom applying this series. Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] lib: lmb: fix overflow in __lmb_alloc_base w/ large RAM
On 07/31/2014 01:40 PM, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com If a 32-bit system has 2GB of RAM, and the base address of that RAM is 2GB, then start+size will overflow a 32-bit value (to a value of 0). __lmb_alloc_base is affected by this; it calculates the minimum of (start+size of RAM) and max_addr. However, when start+size is 0, it is always less than max_addr, which causes the value of max_addr not to be taken into account when restricting the allocation's location. Fix this by calculating start+size separately, and if that calculation underflows, using -1 (interpreted as the max unsigned value) as the value instead, and then taking the min of that and max_addr. Now that start+size doesn't overflow, it's typically large, and max_addr dominates the min() call, and is taken into account. The user-visible symptom of this bug is that CONFIG_BOOTMAP_SZ is ignored on Tegra124 systems with 2GB of RAM, which in turn causes the DT to be relocated at the very end of RAM, which the ARM Linux kernel doesn't map during early boot, and which causes boot failures. With this fix, CONFIG_BOOTMAP_SZ correctly restricts the relocated DT to a much lower address, and everything works. TomR, Does this patch look OK to you? I imagine that TomW is holding off applying ARM: tegra: Use mem size from MC rather than ODMDATA since it depends on this patch, which isn't applied yet. Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ARM: tegra: add Colibri T30 board support
On 08/05/2014 03:27 PM, Stefan Agner wrote: This adds board support for the Toradex Colibri T30 module. Working functions: - SD card boot - eMMC environment and boot - USB host/USB client (on the dual role port) - Network (via ASIX USB) Acked-by: Stephen Warren swar...@nvidia.com Note that this patch is going to conflict with: http://patchwork.ozlabs.org/patch/376287/ tegra: kconfig: move board select menu and common settings ... since that moves all the Tegra Kconfig board options into sub-menus. At some point, this or that patch will need to be rebased on the other, or merged with each-other. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] config: introduce a generic $bootcmd
Hi Stephen, On 6 August 2014 10:01, Stephen Warren swar...@wwwdotorg.org wrote: On 07/30/2014 04:37 PM, Stephen Warren wrote: From: Dennis Gilmore den...@ausil.us This generic $bootcmd, and associated support macros, automatically searches a defined set of storage devices (or network protocols) for an extlinux configuration file or U-Boot boot script in various standardized locations. Distros that install such a boot config file/script in those standard locations will get easy-to-set-up booting on HW that enables this generic $bootcmd. Simon, are you OK with these patches following the discussion? Dennis, I assume you're OK with the new version of this patch? I looked it through fairly closely as you cleared up my doubts (i.e. we can move the implementation from scripts to a command later if we want without anyone outside U-Boot knowing/caring). I'll take another look. I assume that your acks would go a long way towards Tom applying this series. Thanks. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/t1040qds: Remove Video - HDMI support
On 04/18/2014 02:32 AM, Wang Dongsheng-B40534 wrote: -Original Message- From: Jain Priyanka-B32167 Sent: Friday, April 18, 2014 4:26 PM To: Wang Dongsheng-B40534; Sun York-R58495 Cc: Wood Scott-B07421; u-boot@lists.denx.de; Wang Dongsheng-B40534 Subject: RE: [PATCH] powerpc/t1040qds: Remove Video - HDMI support Hello Dongsheng, We do have requirement to support this that's why code development was done. Also , what is the dependency of deep-sleep on this. Please elaborate And if something is broken, we should fix it. Instead of removing the feature. If we have, why kernel doesn't support DIU on T1040QDS? That I must remove it reason. Guys, Do we have an agreement if this feature should be kept or removed? York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/mpc85xx: Enabling CPC conditionally based on hwconfig options
On 07/01/2014 11:14 PM, Shaveta Leekha wrote: If hwconfig does not contains en_cpc then by default all cpcs are enabled If this config is defined then only those individual cpcs which are defined in the subargument of en_cpc will be enabled e.g en_cpc:cpc1,cpc2; (this will enable cpc1 and cpc2) or en_cpc:cpc2; (this enables just cpc2) What's the user's case for enabling selected CPC? York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: BOOTP retry timeout improvements
On Wed, Aug 06, 2014 at 09:58:12AM -0600, Stephen Warren wrote: On 07/25/2014 05:30 PM, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com Currently, the BOOTP code sends out its initial request as soon as the Ethernet driver indicates link up. If this packet is lost or not replied to for some reason, the code waits for a 1s timeout before retrying. For some reason, such early packets are often lost on my system, so this causes an annoying delay. To optimize this, modify the BOOTP code to have very short timeouts for the first packet transmitted, but gradually increase the timeout each time a timeout occurs. This way, if the first packet is lost, the second packet is transmitted quite quickly and hence the overall delay is low. However, if there's still no response, we don't keep spewing out packets at an insane speed. It's arguably more correct to try and find out why the first packet is lost. However, it seems to disappear inside my Ethenet chip; the TX chip indicates no error during TX (not that it has much in the way of reporting...), yet wireshark on the RX side doesn't see any packet. FWIW, I'm using an ASIX USB Ethernet adapter. Perhaps link up is reported too early or based on the wrong condition in HW, and we should add some fixed extra delay into the driver. However, this would slow down every link up event even if it ends up not being needed in some cases. Having BOOTP retry quickly applies the fix/WAR to every possible Ethernet device, and is quite simple to implement, so seems a better solution. Joe, Tom, Does this patch look OK? I was a bit worried about this impacting boards that don't have a problem today but a quick test shows they're still getting the first reply, so I'm OK with it. I'll be grabbing things soon. -- 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 09/10] arm: ls102xa: Add basic support for LS1021AQDS board
On 07/03/2014 12:24 AM, Alison Wang wrote:
diff --git a/lib/lmb.c b/lib/lmb.c
index 081e418..0903222 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -295,7 +295,7 @@ phys_addr_t __lmb_alloc_base(struct lmb *lmb, phys_size_t
size, ulong align, phy
if (max_addr == LMB_ALLOC_ANYWHERE)
base = lmb_align_down(lmbbase + lmbsize - size, align);
else if (lmbbase max_addr) {
- base = min(lmbbase + lmbsize, max_addr);
+ base = min(lmbbase + lmbsize - 1, max_addr);
base = lmb_align_down(base - size, align);
} else
continue;
Alison,
You didn't mention the change to lmb.c. It looks like a bug fix.
York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8 02/13] kconfig: add board Kconfig and defconfig files
On 07/29/2014 10:08 PM, Masahiro Yamada wrote:
This commit adds:
- arch/${ARCH}/Kconfig
provide a menu to select target boards
- board/${VENDOR}/${BOARD}/Kconfig or board/${BOARD}/Kconfig
set CONFIG macros to the appropriate values for each board
- configs/${TARGET_BOARD}_defconfig
default setting of each board
(This commit was automatically generated by a conversion script
based on boards.cfg)
Dear Masahiro,
Do you have any plan to sort the entries in each Kconfig, eg arch/arm/Kconfig?
York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] QorIQ P1020 NAND Flash 2k-Page-Size Problem
On Tue, 2014-08-05 at 16:48 -0300, Allan Fislor wrote: Hi all, I have a custom Freescale QorIQ P1020 board, with a serial NOR Flash (eSPI bus) and a NAND Flash (eLBC/FCM bus). Im booting from the NOR flash. The old NAND (512 bytes page size) was working perfectly, so I swapped for another with 2k bytes page size. I changed in the config file: CONFIG_SYS_NAND_OR_PRELIM: added OR_FCM_PGS option CONFIG_SYS_NAND_BLOCK_SIZE: set to (128 * 1024) But this new NAND flash does not work. If I enter the command nand erase.chip, all sectors appears with bad block. Are the timings correct for your new NAND chip? What do you see if you dump the raw NAND contents? Have you seen this behavior with more than one instance of the new flash chip type? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/10] arm: ls102xa: Add etsec support for LS102xA
On 07/03/2014 12:24 AM, Alison Wang wrote:
Missing commit message here.
Signed-off-by: Alison Wang alison.w...@freescale.com
---
Change log:
v2: Add private mdio read and write support.
drivers/net/fsl_mdio.c | 24 +++-
drivers/net/tsec.c | 7 +++
include/fsl_mdio.h | 3 +++
include/tsec.h | 7 ++-
4 files changed, 35 insertions(+), 6 deletions(-)
diff --git a/drivers/net/fsl_mdio.c b/drivers/net/fsl_mdio.c
index 8d09f5d..3081228 100644
--- a/drivers/net/fsl_mdio.c
+++ b/drivers/net/fsl_mdio.c
@@ -12,6 +12,15 @@
#include asm/io.h
#include asm/errno.h
+void tsec_mdio_sync(void)
+{
+#if defined(CONFIG_PPC)
+ asm(sync);
+#elif defined(CONFIG_ARM)
+ asm(dsb);
+#endif
+}
+
void tsec_local_mdio_write(struct tsec_mii_mng __iomem *phyregs, int
port_addr,
int dev_addr, int regnum, int value)
{
@@ -19,7 +28,7 @@ void tsec_local_mdio_write(struct tsec_mii_mng __iomem
*phyregs, int port_addr,
out_be32(phyregs-miimadd, (port_addr 8) | (regnum 0x1f));
out_be32(phyregs-miimcon, value);
- asm(sync);
+ tsec_mdio_sync();
Don't reinvent the wheel. You can use mb() where you use tsec_mdio_sync();
York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 05/10] arm: ls102xa: Add esdhc support for LS102xA
On 07/03/2014 12:24 AM, Alison Wang wrote: Missing commit message here. You should explain why we need this change. It will help us search the log later. Signed-off-by: Alison Wang alison.w...@freescale.com --- York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/9] arm: ls102xa: Add Freescale LS102xA SoC and LS1021AQDS/TWR board support
On 07/03/2014 12:24 AM, Alison Wang wrote: This series contain the support for Freescale LS102xA SoC and LS1021AQDS/TWR board. Alison, Please respin your patches. It has been a while since you submitted them. For your convenience, I have rebased your patches to v2014.10-rc1 and converted to the latest Kconfig. They can be compiled but I didn't verify on boards. Please verify and address the review comments. http://git.denx.de/?p=u-boot/u-boot-fsl-qoriq.git;a=shortlog;h=refs/heads/test Please submit your new patches based on u-boot-fsl-qoriq/master. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/4] usb/gadget: fastboot: add support for flash command
On 14-07-30 06:39 PM, Marek Vasut wrote: On Thursday, June 26, 2014 at 10:13:23 PM, Steve Rae wrote: - implement 'fastboot flash' for eMMC devices Signed-off-by: Steve Rae s...@broadcom.com Reviewed-by: Marek Vasut ma...@denx.de Thanks, Steve 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 4/4] usb/gadget: fastboot: minor cleanup
On 14-07-30 06:40 PM, Marek Vasut wrote:
On Thursday, June 26, 2014 at 10:13:24 PM, Steve Rae wrote:
- update static function
- additional debugging statements
Signed-off-by: Steve Rae s...@broadcom.com
---
Changes in v3: None
Changes in v2:
- new in v2
drivers/usb/gadget/f_fastboot.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/f_fastboot.c
b/drivers/usb/gadget/f_fastboot.c index 89c2d3e..3e6e47f 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -293,7 +293,7 @@ static int fastboot_add(struct usb_configuration *c)
}
DECLARE_GADGET_BIND_CALLBACK(usb_dnl_fastboot, fastboot_add);
-int fastboot_tx_write(const char *buffer, unsigned int buffer_size)
+static int fastboot_tx_write(const char *buffer, unsigned int buffer_size)
{
struct usb_request *in_req = fastboot_func-in_req;
int ret;
@@ -338,6 +338,7 @@ static void cb_getvar(struct usb_ep *ep, struct
usb_request *req) strcpy(response, OKAY);
strsep(cmd, :);
if (!cmd) {
+ printf(%s: missing var\n, __func__);
I'd spell it out completely -- variable -- but I'm not sure if you might need to
maintain some kind of compatibility with the fastboot responses here or not.
nope -- done in v4
Thanks, Steve
[...]
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 2/4] usb/gadget: fastboot: add eMMC support for flash command
On 14-07-30 06:37 PM, Marek Vasut wrote:
On Thursday, June 26, 2014 at 10:13:22 PM, Steve Rae wrote:
[...]
+
+#include common.h
+#include fb_mmc.h
+#include part.h
+#include sparse_format.h
+
+/* The 64 defined bytes plus \0 */
+#define RESPONSE_LEN (64 + 1)
+
+static char *response_str;
I'd suggest to pass this response_str around instead of making it global.
That would involve adding it to fastboot_resp(), which is called 11
times in this code, from 3 different functions (so would need to add
this to two of the functions...). And as these evolve, there will likely
be more nested functions, which would all require passing it around
I think that this static global pointer is a cleaner implementation.
+static void fastboot_resp(const char *s)
+{
+ strncpy(response_str, s, RESPONSE_LEN);
+ response_str[RESPONSE_LEN - 1] = '\0';
This could be shrunk to a single snprintf(response_str, RESPONSE_LENGTH, s); I
think, but I'm not sure if the overhead won't grow.
snprintf() is used very sparingling in U-Boot, and with the cautionary
statements in README (line 852) and the fact that CONFIG_SYS_VSNPRINTF
is not defined for armv7 builds, I am not going to use it
+}
+
+static int is_sparse_image(void *buf)
+{
+ sparse_header_t *s_header = (sparse_header_t *)buf;
+
+ if ((le32_to_cpu(s_header-magic) == SPARSE_HEADER_MAGIC)
+ (le16_to_cpu(s_header-major_version) == 1))
+ return 1;
+
+ return 0;
+}
+
+static void write_sparse_image(block_dev_desc_t *dev_desc,
+ disk_partition_t *info, const char *part_name,
+ void *buffer, unsigned int download_bytes)
+{
+ lbaint_t blk;
+ lbaint_t blkcnt;
+ lbaint_t blks;
+ sparse_header_t *s_header = (sparse_header_t *)buffer;
+ chunk_header_t *c_header;
+ void *buf;
+ uint32_t blk_sz;
+ uint32_t remaining_chunks;
+ uint32_t bytes_written = 0;
+
+ blk_sz = le32_to_cpu(s_header-blk_sz);
+
+ /* verify s_header-blk_sz is exact multiple of info-blksz */
+ if (blk_sz != (blk_sz ~(info-blksz - 1))) {
+ printf(%s: Sparse image block size issue [%u]\n,
+ __func__, blk_sz);
+ fastboot_resp(FAILsparse image block size issue);
Can't you just make the fastboot_resp() function a variadic one AND move the
printf() into the fastboot_resp() function? You could then even get consistent
output on both the device and in the response if you snprintf() into the
response_str first and then printf() the response_str .
Generally, the printf() statements which are sent to the console, and
the fastboot_resp() statements which are sent to the host running the
fastboot application are not the same
+ return;
+ }
[...]
+static void write_raw_image(block_dev_desc_t *dev_desc, disk_partition_t
*info, +const char *part_name, void *buffer,
+ unsigned int download_bytes)
+{
+ lbaint_t blkcnt;
+ lbaint_t blks;
+
+ /* determine number of blocks to write */
+ blkcnt = ((download_bytes + (info-blksz - 1)) ~(info-blksz - 1));
+ blkcnt = blkcnt / info-blksz;
+
+ if (blkcnt info-size) {
+ printf(%s: too large for partition: '%s'\n, __func__,
+ part_name);
+ fastboot_resp(FAILtoo large for partition);
+ return;
+ }
+
+ printf(Flashing Raw Image\n);
Use puts() here and everywhere where printf() is not taking any args please.
done in v4 - Thanks!
+ blks = dev_desc-block_write(dev_desc-dev, info-start, blkcnt,
+buffer);
+ if (blks != blkcnt) {
+ printf(%s: failed writing to device %d\n, __func__,
+ dev_desc-dev);
+ fastboot_resp(FAILfailed writing to device);
+ return;
+ }
+
+ printf( wrote LBAFU bytes to '%s'\n, blkcnt * info-blksz,
+ part_name);
+ fastboot_resp(OKAY);
+}
[...]
Thanks, Steve
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 0/5] Implement fastboot flash for eMMC
This series implements the fastboot flash command for eMMC devices. It supports both raw and sparse images. NOTES: - the support for the fastboot flash command is enabled with CONFIG_FASTBOOT_FLASH - the support for eMMC is enabled with CONFIG_FASTBOOT_FLASH_MMC_DEV - (future) the support for NAND would be enabled with CONFIG_FASTBOOT_FLASH_NAND(???) This has been tested on ARMv7. While we are struggling with the sparse_format copyright and licensing issues, can we accept the first three patches? Thanks, Steve Changes in v4: - rearranged this patchset so that sparse_format.h can be dropped (if we cannot resolve the copyright/licensing issues) - update mmc_get_dev(...) to get_dev(mmc,) - update printf() to puts() where applicable - update debug string as per feedback - rearranged sparse format support in this patchset, in order to isolate... Changes in v3: - remove most references to 'mmc', which leaves only one mmc specific function: mmc_get_dev() Changes in v2: - split large function into three - improved handling of response messages - additional partition size checking when writing sparse image - update README.android-fastboot file - new in v2 Steve Rae (5): usb/gadget: fastboot: add eMMC support for flash command usb/gadget: fastboot: add support for flash command usb/gadget: fastboot: minor cleanup usb/gadget: fastboot: add sparse image definitions usb/gadget: fastboot: implement sparse format README | 10 +++ common/Makefile | 5 ++ common/cmd_fastboot.c | 7 +- common/fb_mmc.c | 191 doc/README.android-fastboot | 5 +- drivers/usb/gadget/f_fastboot.c | 44 - include/fb_mmc.h| 8 ++ include/sparse_format.h | 58 8 files changed, 319 insertions(+), 9 deletions(-) create mode 100644 common/fb_mmc.c create mode 100644 include/fb_mmc.h create mode 100644 include/sparse_format.h -- 1.8.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 1/5] usb/gadget: fastboot: add eMMC support for flash command
- add support for 'fastboot flash' command for eMMC devices
Signed-off-by: Steve Rae s...@broadcom.com
---
Changes in v4:
- rearranged this patchset so that sparse_format.h can be dropped (if we
cannot
resolve the copyright/licensing issues)
- update mmc_get_dev(...) to get_dev(mmc,)
- update printf() to puts() where applicable
Changes in v3:
- remove most references to 'mmc',
which leaves only one mmc specific function: mmc_get_dev()
Changes in v2:
- split large function into three
- improved handling of response messages
- additional partition size checking when writing sparse image
common/Makefile | 5
common/fb_mmc.c | 82
include/fb_mmc.h | 8 ++
3 files changed, 95 insertions(+)
create mode 100644 common/fb_mmc.c
create mode 100644 include/fb_mmc.h
diff --git a/common/Makefile b/common/Makefile
index de5cce8..daebe39 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -266,4 +266,9 @@ obj-$(CONFIG_IO_TRACE) += iotrace.o
obj-y += memsize.o
obj-y += stdio.o
+# This option is not just y/n - it can have a numeric value
+ifdef CONFIG_FASTBOOT_FLASH_MMC_DEV
+obj-y += fb_mmc.o
+endif
+
CFLAGS_env_embedded.o := -Wa,--no-warn -DENV_CRC=$(shell tools/envcrc
2/dev/null)
diff --git a/common/fb_mmc.c b/common/fb_mmc.c
new file mode 100644
index 000..f42a115
--- /dev/null
+++ b/common/fb_mmc.c
@@ -0,0 +1,82 @@
+/*
+ * Copyright 2014 Broadcom Corporation.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include fb_mmc.h
+#include part.h
+
+/* The 64 defined bytes plus \0 */
+#define RESPONSE_LEN (64 + 1)
+
+static char *response_str;
+
+static void fastboot_resp(const char *s)
+{
+ strncpy(response_str, s, RESPONSE_LEN);
+ response_str[RESPONSE_LEN - 1] = '\0';
+}
+
+static void write_raw_image(block_dev_desc_t *dev_desc, disk_partition_t *info,
+ const char *part_name, void *buffer,
+ unsigned int download_bytes)
+{
+ lbaint_t blkcnt;
+ lbaint_t blks;
+
+ /* determine number of blocks to write */
+ blkcnt = ((download_bytes + (info-blksz - 1)) ~(info-blksz - 1));
+ blkcnt = blkcnt / info-blksz;
+
+ if (blkcnt info-size) {
+ printf(%s: too large for partition: '%s'\n, __func__,
+ part_name);
+ fastboot_resp(FAILtoo large for partition);
+ return;
+ }
+
+ puts(Flashing Raw Image\n);
+
+ blks = dev_desc-block_write(dev_desc-dev, info-start, blkcnt,
+buffer);
+ if (blks != blkcnt) {
+ printf(%s: failed writing to device %d\n, __func__,
+ dev_desc-dev);
+ fastboot_resp(FAILfailed writing to device);
+ return;
+ }
+
+ printf( wrote LBAFU bytes to '%s'\n, blkcnt * info-blksz,
+ part_name);
+ fastboot_resp(OKAY);
+}
+
+void fb_mmc_flash_write(const char *cmd, void *download_buffer,
+ unsigned int download_bytes, char *response)
+{
+ int ret;
+ block_dev_desc_t *dev_desc;
+ disk_partition_t info;
+
+ /* initialize the response buffer */
+ response_str = response;
+
+ dev_desc = get_dev(mmc, CONFIG_FASTBOOT_FLASH_MMC_DEV);
+ if (!dev_desc || dev_desc-type == DEV_TYPE_UNKNOWN) {
+ printf(%s: invalid mmc device\n, __func__);
+ fastboot_resp(FAILinvalid mmc device);
+ return;
+ }
+
+ ret = get_partition_info_efi_by_name(dev_desc, cmd, info);
+ if (ret) {
+ printf(%s: cannot find partition: '%s'\n, __func__, cmd);
+ fastboot_resp(FAILcannot find partition);
+ return;
+ }
+
+ write_raw_image(dev_desc, info, cmd, download_buffer,
+ download_bytes);
+}
diff --git a/include/fb_mmc.h b/include/fb_mmc.h
new file mode 100644
index 000..1ad1d13
--- /dev/null
+++ b/include/fb_mmc.h
@@ -0,0 +1,8 @@
+/*
+ * Copyright 2014 Broadcom Corporation.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+void fb_mmc_flash_write(const char *cmd, void *download_buffer,
+ unsigned int download_bytes, char *response);
--
1.8.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 3/5] usb/gadget: fastboot: minor cleanup
- update static function
- additional debugging statements
- update fastboot command information
- add missing include file
- update spelling
Signed-off-by: Steve Rae s...@broadcom.com
---
Changes in v4:
- update debug string as per feedback
Changes in v3: None
Changes in v2:
- new in v2
common/cmd_fastboot.c | 7 ---
drivers/usb/gadget/f_fastboot.c | 13 +
2 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/common/cmd_fastboot.c b/common/cmd_fastboot.c
index 83fa7bd..909616d 100644
--- a/common/cmd_fastboot.c
+++ b/common/cmd_fastboot.c
@@ -30,7 +30,8 @@ static int do_fastboot(cmd_tbl_t *cmdtp, int flag, int argc,
char *const argv[])
}
U_BOOT_CMD(
- fastboot, 1, 1, do_fastboot,
- fastboot - enter USB Fastboot protocol,
-
+ fastboot, 1, 0, do_fastboot,
+ use USB Fastboot protocol,
+ \n
+ - run as a fastboot usb device
);
diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
index e2659fa..3b588a9 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -10,6 +10,7 @@
*
* SPDX-License-Identifier:GPL-2.0+
*/
+#include config.h
#include common.h
#include errno.h
#include malloc.h
@@ -41,7 +42,7 @@
struct f_fastboot {
struct usb_function usb_function;
- /* IN/OUT EP's and correspoinding requests */
+ /* IN/OUT EP's and corresponding requests */
struct usb_ep *in_ep, *out_ep;
struct usb_request *in_req, *out_req;
};
@@ -293,7 +294,7 @@ static int fastboot_add(struct usb_configuration *c)
}
DECLARE_GADGET_BIND_CALLBACK(usb_dnl_fastboot, fastboot_add);
-int fastboot_tx_write(const char *buffer, unsigned int buffer_size)
+static int fastboot_tx_write(const char *buffer, unsigned int buffer_size)
{
struct usb_request *in_req = fastboot_func-in_req;
int ret;
@@ -341,6 +342,7 @@ static void cb_getvar(struct usb_ep *ep, struct usb_request
*req)
strsep(cmd, :);
if (!cmd) {
+ printf(%s: missing variable\n, __func__);
fastboot_tx_write_str(FAILmissing var);
return;
}
@@ -361,6 +363,7 @@ static void cb_getvar(struct usb_ep *ep, struct usb_request
*req)
else
strcpy(response, FAILValue not set);
} else {
+ printf(%s: unknown variable: %s\n, __func__, cmd);
strcpy(response, FAILVariable not implemented);
}
fastboot_tx_write_str(response);
@@ -534,10 +537,12 @@ static void rx_handler_command(struct usb_ep *ep, struct
usb_request *req)
}
}
- if (!func_cb)
+ if (!func_cb) {
+ printf(%s: unknown command: %s\n, __func__, cmdbuf);
fastboot_tx_write_str(FAILunknown command);
- else
+ } else {
func_cb(ep, req);
+ }
if (req-status == 0) {
*cmdbuf = '\0';
--
1.8.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 2/5] usb/gadget: fastboot: add support for flash command
- implement 'fastboot flash' for eMMC devices
Signed-off-by: Steve Rae s...@broadcom.com
Reviewed-by: Marek Vasut ma...@denx.de
---
Changes in v4: None
Changes in v3: None
Changes in v2:
- update README.android-fastboot file
README | 10 ++
doc/README.android-fastboot | 5 +++--
drivers/usb/gadget/f_fastboot.c | 31 +++
3 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/README b/README
index 1d71359..ed26884 100644
--- a/README
+++ b/README
@@ -1623,6 +1623,16 @@ The following options need to be configured:
downloads. This buffer should be as large as possible for a
platform. Define this to the size available RAM for fastboot.
+ CONFIG_FASTBOOT_FLASH
+ The fastboot protocol includes a flash command for writing
+ the downloaded image to a non-volatile storage device. Define
+ this to enable the fastboot flash command.
+
+ CONFIG_FASTBOOT_FLASH_MMC_DEV
+ The fastboot flash command requires addition information
+ regarding the non-volatile storage device. Define this to
+ the eMMC device that fastboot should use to store the image.
+
- Journaling Flash filesystem support:
CONFIG_JFFS2_NAND, CONFIG_JFFS2_NAND_OFF,
CONFIG_JFFS2_NAND_SIZE,
CONFIG_JFFS2_NAND_DEV
diff --git a/doc/README.android-fastboot b/doc/README.android-fastboot
index f1d128c..430e29c 100644
--- a/doc/README.android-fastboot
+++ b/doc/README.android-fastboot
@@ -6,8 +6,9 @@ Overview
The protocol that is used over USB is described in
README.android-fastboot-protocol in same directory.
-The current implementation does not yet support the flash and erase
-commands.
+The current implementation does not yet support the erase command or the
+oem format command, and there is minimal support for the flash command;
+it only supports eMMC devices.
Client installation
===
diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
index 7a1acb9..e2659fa 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -19,6 +19,9 @@
#include linux/compiler.h
#include version.h
#include g_dnl.h
+#ifdef CONFIG_FASTBOOT_FLASH_MMC_DEV
+#include fb_mmc.h
+#endif
#define FASTBOOT_VERSION 0.4
@@ -469,6 +472,28 @@ static void cb_boot(struct usb_ep *ep, struct usb_request
*req)
fastboot_tx_write_str(OKAY);
}
+#ifdef CONFIG_FASTBOOT_FLASH
+static void cb_flash(struct usb_ep *ep, struct usb_request *req)
+{
+ char *cmd = req-buf;
+ char response[RESPONSE_LEN];
+
+ strsep(cmd, :);
+ if (!cmd) {
+ printf(%s: missing partition name\n, __func__);
+ fastboot_tx_write_str(FAILmissing partition name);
+ return;
+ }
+
+ strcpy(response, FAILno flash device defined);
+#ifdef CONFIG_FASTBOOT_FLASH_MMC_DEV
+ fb_mmc_flash_write(cmd, (void *)CONFIG_USB_FASTBOOT_BUF_ADDR,
+ download_bytes, response);
+#endif
+ fastboot_tx_write_str(response);
+}
+#endif
+
struct cmd_dispatch_info {
char *cmd;
void (*cb)(struct usb_ep *ep, struct usb_request *req);
@@ -488,6 +513,12 @@ static const struct cmd_dispatch_info cmd_dispatch_info[]
= {
.cmd = boot,
.cb = cb_boot,
},
+#ifdef CONFIG_FASTBOOT_FLASH
+ {
+ .cmd = flash,
+ .cb = cb_flash,
+ },
+#endif
};
static void rx_handler_command(struct usb_ep *ep, struct usb_request *req)
--
1.8.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 4/5] usb/gadget: fastboot: add sparse image definitions
- to prepare for the support of fastboot sparse images
Signed-off-by: Steve Rae s...@broadcom.com
---
This file is ASIS from:
https://raw.githubusercontent.com/AOSB/android_system_core/master/libsparse/sparse_format.h
(commit 28fa5bc347390480fe190294c6c385b6a9f0d68b)
except for the __UBOOT__ conditional include.
Changes in v4: None
Changes in v3: None
Changes in v2: None
include/sparse_format.h | 58 +
1 file changed, 58 insertions(+)
create mode 100644 include/sparse_format.h
diff --git a/include/sparse_format.h b/include/sparse_format.h
new file mode 100644
index 000..21fbd05
--- /dev/null
+++ b/include/sparse_format.h
@@ -0,0 +1,58 @@
+/*
+ * Copyright (C) 2010 The Android Open Source Project
+ *
+ * Licensed under the Apache License, Version 2.0 (the License);
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#ifndef _LIBSPARSE_SPARSE_FORMAT_H_
+#define _LIBSPARSE_SPARSE_FORMAT_H_
+#define __UBOOT__
+#ifndef __UBOOT__
+#include sparse_defs.h
+#endif
+
+typedef struct sparse_header {
+ __le32 magic; /* 0xed26ff3a */
+ __le16 major_version; /* (0x1) - reject images with higher major
versions */
+ __le16 minor_version; /* (0x0) - allow images with higer minor
versions */
+ __le16 file_hdr_sz;/* 28 bytes for first revision of the file
format */
+ __le16 chunk_hdr_sz; /* 12 bytes for first revision of the file
format */
+ __le32 blk_sz; /* block size in bytes, must be a multiple of 4
(4096) */
+ __le32 total_blks; /* total blocks in the non-sparse output image
*/
+ __le32 total_chunks; /* total chunks in the sparse input image */
+ __le32 image_checksum; /* CRC32 checksum of the original data,
counting don't care */
+ /* as 0. Standard 802.3 polynomial, use a
Public Domain */
+ /* table implementation */
+} sparse_header_t;
+
+#define SPARSE_HEADER_MAGIC0xed26ff3a
+
+#define CHUNK_TYPE_RAW 0xCAC1
+#define CHUNK_TYPE_FILL0xCAC2
+#define CHUNK_TYPE_DONT_CARE 0xCAC3
+#define CHUNK_TYPE_CRC320xCAC4
+
+typedef struct chunk_header {
+ __le16 chunk_type; /* 0xCAC1 - raw; 0xCAC2 - fill; 0xCAC3 -
don't care */
+ __le16 reserved1;
+ __le32 chunk_sz; /* in blocks in output image */
+ __le32 total_sz; /* in bytes of chunk input file including chunk
header and data */
+} chunk_header_t;
+
+/* Following a Raw or Fill or CRC32 chunk is data.
+ * For a Raw chunk, it's the data in chunk_sz * blk_sz.
+ * For a Fill chunk, it's 4 bytes of the fill data.
+ * For a CRC32 chunk, it's 4 bytes of CRC32
+ */
+
+#endif
--
1.8.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 5/5] usb/gadget: fastboot: implement sparse format
- add capability to fastboot flash with sparse format images
Signed-off-by: Steve Rae s...@broadcom.com
---
I suspect that the sparse image handling (ie. the while (remaining_chunks)
loop)
has been implemented elsewhere -- I need help finding the original code to
determine
any licensing issues
Thanks, Steve
Changes in v4:
- rearranged sparse format support in this patchset, in order to isolate...
Changes in v3: None
Changes in v2: None
common/fb_mmc.c | 115 ++--
1 file changed, 112 insertions(+), 3 deletions(-)
diff --git a/common/fb_mmc.c b/common/fb_mmc.c
index f42a115..306c102 100644
--- a/common/fb_mmc.c
+++ b/common/fb_mmc.c
@@ -1,5 +1,6 @@
/*
- * Copyright 2014 Broadcom Corporation.
+ * Copyright TODO
+ * Portions Copyright 2014 Broadcom Corporation.
*
* SPDX-License-Identifier:GPL-2.0+
*/
@@ -7,6 +8,7 @@
#include common.h
#include fb_mmc.h
#include part.h
+#include sparse_format.h
/* The 64 defined bytes plus \0 */
#define RESPONSE_LEN (64 + 1)
@@ -19,6 +21,108 @@ static void fastboot_resp(const char *s)
response_str[RESPONSE_LEN - 1] = '\0';
}
+static int is_sparse_image(void *buf)
+{
+ sparse_header_t *s_header = (sparse_header_t *)buf;
+
+ if ((le32_to_cpu(s_header-magic) == SPARSE_HEADER_MAGIC)
+ (le16_to_cpu(s_header-major_version) == 1))
+ return 1;
+
+ return 0;
+}
+
+static void write_sparse_image(block_dev_desc_t *dev_desc,
+ disk_partition_t *info, const char *part_name,
+ void *buffer, unsigned int download_bytes)
+{
+ lbaint_t blk;
+ lbaint_t blkcnt;
+ lbaint_t blks;
+ sparse_header_t *s_header = (sparse_header_t *)buffer;
+ chunk_header_t *c_header;
+ void *buf;
+ uint32_t blk_sz;
+ uint32_t remaining_chunks;
+ uint32_t bytes_written = 0;
+
+ blk_sz = le32_to_cpu(s_header-blk_sz);
+
+ /* verify s_header-blk_sz is exact multiple of info-blksz */
+ if (blk_sz != (blk_sz ~(info-blksz - 1))) {
+ printf(%s: Sparse image block size issue [%u]\n,
+ __func__, blk_sz);
+ fastboot_resp(FAILsparse image block size issue);
+ return;
+ }
+
+ if ((le32_to_cpu(s_header-total_blks) * blk_sz)
+ (info-size * info-blksz)) {
+ printf(%s: Sparse image is too large for the partition\n,
+ __func__);
+ fastboot_resp(FAILsparse image is too large);
+ return;
+ }
+
+ puts(Flashing Sparse Image\n);
+
+ remaining_chunks = le32_to_cpu(s_header-total_chunks);
+ c_header = (chunk_header_t *)(buffer +
+ le16_to_cpu(s_header-file_hdr_sz));
+ blk = info-start;
+ while (remaining_chunks) {
+ blkcnt =
+ (le32_to_cpu(c_header-chunk_sz) * blk_sz) / info-blksz;
+
+ switch (le16_to_cpu(c_header-chunk_type)) {
+ case CHUNK_TYPE_RAW:
+ buf = (void *)c_header +
+ le16_to_cpu(s_header-chunk_hdr_sz);
+
+ if (blk + blkcnt info-start + info-size) {
+ printf(
+ %s: Request would exceed partition
size!\n,
+ __func__);
+ fastboot_resp(
+ FAILRequest would exceed partition size!);
+ return;
+ }
+
+ blks = dev_desc-block_write(dev_desc-dev, blk, blkcnt,
+ buf);
+ if (blks != blkcnt) {
+ printf(%s: Write failed LBAFU \n,
+ __func__, blks);
+ fastboot_resp(FAILwrite failure);
+ return;
+ }
+
+ bytes_written += blkcnt * info-blksz;
+ break;
+
+ case CHUNK_TYPE_FILL:
+ case CHUNK_TYPE_DONT_CARE:
+ case CHUNK_TYPE_CRC32:
+ /* do nothing */
+ break;
+
+ default:
+ /* error */
+ printf(%s: Unknown chunk type\n, __func__);
+ fastboot_resp(FAILunknown chunk type in sparse image);
+ return;
+ }
+
+ blk += blkcnt;
+ c_header = (chunk_header_t *)((void *)c_header +
+ le32_to_cpu(c_header-total_sz));
+ remaining_chunks--;
+ }
+
+ printf( wrote %u bytes to '%s'\n, bytes_written, part_name);
+ fastboot_resp(OKAY);
+}
+
static void write_raw_image(block_dev_desc_t *dev_desc, disk_partition_t *info,
const
Re: [U-Boot] [PATCH v3 2/4] usb/gadget: fastboot: add eMMC support for flash command
On Thursday, August 07, 2014 at 01:48:06 AM, Steve Rae wrote:
On 14-07-30 06:37 PM, Marek Vasut wrote:
On Thursday, June 26, 2014 at 10:13:22 PM, Steve Rae wrote:
[...]
+
+#include common.h
+#include fb_mmc.h
+#include part.h
+#include sparse_format.h
+
+/* The 64 defined bytes plus \0 */
+#define RESPONSE_LEN (64 + 1)
+
+static char *response_str;
I'd suggest to pass this response_str around instead of making it
global.
That would involve adding it to fastboot_resp(), which is called 11
times in this code, from 3 different functions (so would need to add
this to two of the functions...). And as these evolve, there will likely
be more nested functions, which would all require passing it around
I think that this static global pointer is a cleaner implementation.
Eventually, the amount of these static variables in the code will grow and it
will become increasingly difficult to weed them out. I believe it would be even
better to pass around some kind of a structure with private data of the
fastboot, which would cater for all possible variables which might come in the
future. What do you think ?
+static void fastboot_resp(const char *s)
+{
+ strncpy(response_str, s, RESPONSE_LEN);
+ response_str[RESPONSE_LEN - 1] = '\0';
This could be shrunk to a single snprintf(response_str, RESPONSE_LENGTH,
s); I think, but I'm not sure if the overhead won't grow.
snprintf() is used very sparingling in U-Boot
This is not a reason to avoid it.
, and with the cautionary statements in README (line 852)
Which statements? Can you please point them out? I fail to see them, sorry.
and the fact that CONFIG_SYS_VSNPRINTF is not defined for armv7 builds, I am
not going to use it
Is it a problem to define it? Also, even without CONFIG_SYS_VSNPRINTF , the
functions are still available, see the README:
857 If this option is not given then these functions will
858 silently discard their buffer size argument - this means
859 you are not getting any overflow checking in this case.
I have yet to see some hard-evidence against using safe printing functions here.
+}
+
+static int is_sparse_image(void *buf)
+{
+ sparse_header_t *s_header = (sparse_header_t *)buf;
+
+ if ((le32_to_cpu(s_header-magic) == SPARSE_HEADER_MAGIC)
+ (le16_to_cpu(s_header-major_version) == 1))
+ return 1;
+
+ return 0;
+}
+
+static void write_sparse_image(block_dev_desc_t *dev_desc,
+ disk_partition_t *info, const char *part_name,
+ void *buffer, unsigned int download_bytes)
+{
+ lbaint_t blk;
+ lbaint_t blkcnt;
+ lbaint_t blks;
+ sparse_header_t *s_header = (sparse_header_t *)buffer;
+ chunk_header_t *c_header;
+ void *buf;
+ uint32_t blk_sz;
+ uint32_t remaining_chunks;
+ uint32_t bytes_written = 0;
+
+ blk_sz = le32_to_cpu(s_header-blk_sz);
+
+ /* verify s_header-blk_sz is exact multiple of info-blksz */
+ if (blk_sz != (blk_sz ~(info-blksz - 1))) {
+ printf(%s: Sparse image block size issue [%u]\n,
+ __func__, blk_sz);
+ fastboot_resp(FAILsparse image block size issue);
Can't you just make the fastboot_resp() function a variadic one AND move
the printf() into the fastboot_resp() function? You could then even get
consistent output on both the device and in the response if you
snprintf() into the response_str first and then printf() the
response_str .
Generally, the printf() statements which are sent to the console, and
the fastboot_resp() statements which are sent to the host running the
fastboot application are not the same
OK, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 4/5] usb/gadget: fastboot: add sparse image definitions
On Thursday, August 07, 2014 at 01:55:12 AM, Steve Rae wrote: - to prepare for the support of fastboot sparse images Signed-off-by: Steve Rae s...@broadcom.com --- Are we discussing the licensing issues here still ? Tom ? 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 0/5] Implement fastboot flash for eMMC
On Thursday, August 07, 2014 at 01:55:08 AM, Steve Rae wrote: This series implements the fastboot flash command for eMMC devices. It supports both raw and sparse images. NOTES: - the support for the fastboot flash command is enabled with CONFIG_FASTBOOT_FLASH - the support for eMMC is enabled with CONFIG_FASTBOOT_FLASH_MMC_DEV - (future) the support for NAND would be enabled with CONFIG_FASTBOOT_FLASH_NAND(???) This has been tested on ARMv7. I'll just wait for Tom's comments on 4/5 and 5/5 and will see then. The 1-3/5 look OK. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/6] arm: rmobile: koelsch: Update QoS initialization to version 0.334
This update QoS version 0.334 for ES2 of R8A7791.
Signed-off-by: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com
---
board/renesas/koelsch/qos.c | 41 +
1 file changed, 21 insertions(+), 20 deletions(-)
diff --git a/board/renesas/koelsch/qos.c b/board/renesas/koelsch/qos.c
index 55a0420..ecf3eed 100644
--- a/board/renesas/koelsch/qos.c
+++ b/board/renesas/koelsch/qos.c
@@ -13,7 +13,7 @@
#include asm/io.h
#include asm/arch/rmobile.h
-/* QoS version 0.240 for ES1 and version 0.310 for ES2 */
+/* QoS version 0.240 for ES1 and version 0.334 for ES2 */
enum {
DBSC3_00, DBSC3_01, DBSC3_02, DBSC3_03, DBSC3_04,
@@ -116,10 +116,16 @@ void qos_init(void)
/* S3C -QoS */
s3c = (struct rcar_s3c *)S3C_BASE;
if (IS_R8A7791_ES2()) {
- writel(0x00FF1B0D, s3c-s3cadsplcr);
- writel(0x1F0D0B0A, s3c-s3crorr);
- writel(0x1F0D0B09, s3c-s3cworr);
- writel(0x00200808, s3c-s3carcr11);
+ /* Linear All mode */
+ /* writel(0x, s3c-s3cadsplcr); */
+ /* Linear Linear 0x7000 to 0x7800 mode */
+ writel(0x00BF1B0C, s3c-s3cadsplcr);
+ /* Split Linear 0x6800 t 0x7000 mode */
+ /* writel(0x00DF1B0C, s3c-s3cadsplcr); */
+ /* Ssplit All mode */
+ /* writel(0x00FF1B0C, s3c-s3cadsplcr); */
+ writel(0x1F0B0908, s3c-s3crorr);
+ writel(0x1F0C0A08, s3c-s3cworr);
} else {
writel(0x00FF1B1D, s3c-s3cadsplcr);
writel(0x1F0D0C0C, s3c-s3crorr);
@@ -149,10 +155,7 @@ void qos_init(void)
writel(0x2032, s3c_qos-s3cqos8);
s3c_qos = (struct rcar_s3c_qos *)S3C_QOS_MXI_BASE;
- if (IS_R8A7791_ES2())
- writel(0x80928092, s3c_qos-s3cqos0);
- else
- writel(0x00820082, s3c_qos-s3cqos0);
+ writel(0x00820082, s3c_qos-s3cqos0);
writel(0x20960020, s3c_qos-s3cqos1);
writel(0x20302030, s3c_qos-s3cqos2);
writel(0x20AA20DC, s3c_qos-s3cqos3);
@@ -185,7 +188,7 @@ void qos_init(void)
writel(0x0001, qos_addr-dbrqctr);
writel(0x2078, qos_addr-dbthres0);
writel(0x204B, qos_addr-dbthres1);
- writel(0x1FE7, qos_addr-dbthres2);
+ writel(0x201E, qos_addr-dbthres2);
writel(0x0001, qos_addr-dblgqon);
}
@@ -193,13 +196,13 @@ void qos_init(void)
for (i = DBSC3_00; i DBSC3_NR; i++) {
qos_addr = (struct rcar_dbsc3_qos *)dbsc3_0_w_qos_addr[i];
writel(0x0002, qos_addr-dblgcnt);
- writel(0x20EB, qos_addr-dbtmval0);
- writel(0x206E, qos_addr-dbtmval1);
+ writel(0x2096, qos_addr-dbtmval0);
+ writel(0x2064, qos_addr-dbtmval1);
writel(0x2050, qos_addr-dbtmval2);
writel(0x203A, qos_addr-dbtmval3);
writel(0x0001, qos_addr-dbrqctr);
writel(0x2078, qos_addr-dbthres0);
- writel(0x205A, qos_addr-dbthres1);
+ writel(0x204B, qos_addr-dbthres1);
writel(0x203C, qos_addr-dbthres2);
writel(0x0001, qos_addr-dblgqon);
}
@@ -215,7 +218,7 @@ void qos_init(void)
writel(0x0001, qos_addr-dbrqctr);
writel(0x2078, qos_addr-dbthres0);
writel(0x204B, qos_addr-dbthres1);
- writel(0x1FE7, qos_addr-dbthres2);
+ writel(0x201E, qos_addr-dbthres2);
writel(0x0001, qos_addr-dblgqon);
}
@@ -223,13 +226,13 @@ void qos_init(void)
for (i = DBSC3_00; i DBSC3_NR; i++) {
qos_addr = (struct rcar_dbsc3_qos *)dbsc3_1_w_qos_addr[i];
writel(0x0002, qos_addr-dblgcnt);
- writel(0x20EB, qos_addr-dbtmval0);
- writel(0x206E, qos_addr-dbtmval1);
+ writel(0x2096, qos_addr-dbtmval0);
+ writel(0x2064, qos_addr-dbtmval1);
writel(0x2050, qos_addr-dbtmval2);
writel(0x203A, qos_addr-dbtmval3);
writel(0x0001, qos_addr-dbrqctr);
writel(0x2078, qos_addr-dbthres0);
- writel(0x205A, qos_addr-dbthres1);
+ writel(0x204B, qos_addr-dbthres1);
writel(0x203C, qos_addr-dbthres2);
writel(0x0001, qos_addr-dblgqon);
}
@@ -245,14 +248,12 @@ void qos_init(void)
mxi = (struct rcar_mxi *)MXI_BASE;
writel(0x0013, mxi-mxrtcr);
writel(0x0013, mxi-mxwtcr);
- writel(0x00780080, mxi-mxsaar0);
- writel(0x02000800, mxi-mxsaar1);
/* QoS Control (MXI) */
mxi_qos = (struct rcar_mxi_qos *)MXI_QOS_BASE;
[U-Boot] [PATCH 2/6] arm: rmobile: alt: Update QoS initialization to version 0.11
Signed-off-by: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com
---
board/renesas/alt/qos.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/board/renesas/alt/qos.c b/board/renesas/alt/qos.c
index ea51f3f..d788aa0 100644
--- a/board/renesas/alt/qos.c
+++ b/board/renesas/alt/qos.c
@@ -13,7 +13,7 @@
#include asm/io.h
#include asm/arch/rmobile.h
-/* QoS version 0.10 */
+/* QoS version 0.11 */
enum {
DBSC3_00, DBSC3_01, DBSC3_02, DBSC3_03, DBSC3_04,
@@ -156,8 +156,8 @@ void qos_init(void)
}
/* CCI-400 -QoS */
- writel(0x20001000, CCI_400_MAXOT_1);
- writel(0x20001000, CCI_400_MAXOT_2);
+ writel(0x2800, CCI_400_MAXOT_1);
+ writel(0x2800, CCI_400_MAXOT_2);
writel(0x000C, CCI_400_QOSCNTL_1);
writel(0x000C, CCI_400_QOSCNTL_2);
--
2.0.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/6] arm: rmobile: lager: Update Qos setting to version 0.955
This updates QoS version 0.955 for ES1 of lager board.
Signed-off-by: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com
---
board/renesas/lager/qos.c | 107 ++
1 file changed, 61 insertions(+), 46 deletions(-)
diff --git a/board/renesas/lager/qos.c b/board/renesas/lager/qos.c
index 3742757..930fe8d 100644
--- a/board/renesas/lager/qos.c
+++ b/board/renesas/lager/qos.c
@@ -12,55 +12,55 @@
#include asm/io.h
#include asm/arch/rmobile.h
-/* QoS version 0.955 */
+/* QoS version 0.955 for ES1
enum {
- DBSC3_R00, DBSC3_R01, DBSC3_R02, DBSC3_R03, DBSC3_R04,
- DBSC3_R05, DBSC3_R06, DBSC3_R07, DBSC3_R08, DBSC3_R09,
- DBSC3_R10, DBSC3_R11, DBSC3_R12, DBSC3_R13, DBSC3_R14,
- DBSC3_R15,
- DBSC3_W00, DBSC3_W01, DBSC3_W02, DBSC3_W03, DBSC3_W04,
- DBSC3_W05, DBSC3_W06, DBSC3_W07, DBSC3_W08, DBSC3_W09,
- DBSC3_W10, DBSC3_W11, DBSC3_W12, DBSC3_W13, DBSC3_W14,
- DBSC3_W15,
+ DBSC3_00, DBSC3_01, DBSC3_02, DBSC3_03, DBSC3_04,
+ DBSC3_05, DBSC3_06, DBSC3_07, DBSC3_08, DBSC3_09,
+ DBSC3_10, DBSC3_11, DBSC3_12, DBSC3_13, DBSC3_14,
+ DBSC3_15,
DBSC3_NR,
};
-static const u32 dbsc3_qos_addr[DBSC3_NR] = {
- [DBSC3_R00] = DBSC3_0_QOS_R0_BASE,
- [DBSC3_R01] = DBSC3_0_QOS_R1_BASE,
- [DBSC3_R02] = DBSC3_0_QOS_R2_BASE,
- [DBSC3_R03] = DBSC3_0_QOS_R3_BASE,
- [DBSC3_R04] = DBSC3_0_QOS_R4_BASE,
- [DBSC3_R05] = DBSC3_0_QOS_R5_BASE,
- [DBSC3_R06] = DBSC3_0_QOS_R6_BASE,
- [DBSC3_R07] = DBSC3_0_QOS_R7_BASE,
- [DBSC3_R08] = DBSC3_0_QOS_R8_BASE,
- [DBSC3_R09] = DBSC3_0_QOS_R9_BASE,
- [DBSC3_R10] = DBSC3_0_QOS_R10_BASE,
- [DBSC3_R11] = DBSC3_0_QOS_R11_BASE,
- [DBSC3_R12] = DBSC3_0_QOS_R12_BASE,
- [DBSC3_R13] = DBSC3_0_QOS_R13_BASE,
- [DBSC3_R14] = DBSC3_0_QOS_R14_BASE,
- [DBSC3_R15] = DBSC3_0_QOS_R15_BASE,
- [DBSC3_W00] = DBSC3_0_QOS_W0_BASE,
- [DBSC3_W01] = DBSC3_0_QOS_W1_BASE,
- [DBSC3_W02] = DBSC3_0_QOS_W2_BASE,
- [DBSC3_W03] = DBSC3_0_QOS_W3_BASE,
- [DBSC3_W04] = DBSC3_0_QOS_W4_BASE,
- [DBSC3_W05] = DBSC3_0_QOS_W5_BASE,
- [DBSC3_W06] = DBSC3_0_QOS_W6_BASE,
- [DBSC3_W07] = DBSC3_0_QOS_W7_BASE,
- [DBSC3_W08] = DBSC3_0_QOS_W8_BASE,
- [DBSC3_W09] = DBSC3_0_QOS_W9_BASE,
- [DBSC3_W10] = DBSC3_0_QOS_W10_BASE,
- [DBSC3_W11] = DBSC3_0_QOS_W11_BASE,
- [DBSC3_W12] = DBSC3_0_QOS_W12_BASE,
- [DBSC3_W13] = DBSC3_0_QOS_W13_BASE,
- [DBSC3_W14] = DBSC3_0_QOS_W14_BASE,
- [DBSC3_W15] = DBSC3_0_QOS_W15_BASE,
+static u32 dbsc3_0_r_qos_addr[DBSC3_NR] = {
+ [DBSC3_00] = DBSC3_0_QOS_R0_BASE,
+ [DBSC3_01] = DBSC3_0_QOS_R1_BASE,
+ [DBSC3_02] = DBSC3_0_QOS_R2_BASE,
+ [DBSC3_03] = DBSC3_0_QOS_R3_BASE,
+ [DBSC3_04] = DBSC3_0_QOS_R4_BASE,
+ [DBSC3_05] = DBSC3_0_QOS_R5_BASE,
+ [DBSC3_06] = DBSC3_0_QOS_R6_BASE,
+ [DBSC3_07] = DBSC3_0_QOS_R7_BASE,
+ [DBSC3_08] = DBSC3_0_QOS_R8_BASE,
+ [DBSC3_09] = DBSC3_0_QOS_R9_BASE,
+ [DBSC3_10] = DBSC3_0_QOS_R10_BASE,
+ [DBSC3_11] = DBSC3_0_QOS_R11_BASE,
+ [DBSC3_12] = DBSC3_0_QOS_R12_BASE,
+ [DBSC3_13] = DBSC3_0_QOS_R13_BASE,
+ [DBSC3_14] = DBSC3_0_QOS_R14_BASE,
+ [DBSC3_15] = DBSC3_0_QOS_R15_BASE,
};
+static u32 dbsc3_0_w_qos_addr[DBSC3_NR] = {
+ [DBSC3_00] = DBSC3_0_QOS_W0_BASE,
+ [DBSC3_01] = DBSC3_0_QOS_W1_BASE,
+ [DBSC3_02] = DBSC3_0_QOS_W2_BASE,
+ [DBSC3_03] = DBSC3_0_QOS_W3_BASE,
+ [DBSC3_04] = DBSC3_0_QOS_W4_BASE,
+ [DBSC3_05] = DBSC3_0_QOS_W5_BASE,
+ [DBSC3_06] = DBSC3_0_QOS_W6_BASE,
+ [DBSC3_07] = DBSC3_0_QOS_W7_BASE,
+ [DBSC3_08] = DBSC3_0_QOS_W8_BASE,
+ [DBSC3_09] = DBSC3_0_QOS_W9_BASE,
+ [DBSC3_10] = DBSC3_0_QOS_W10_BASE,
+ [DBSC3_11] = DBSC3_0_QOS_W11_BASE,
+ [DBSC3_12] = DBSC3_0_QOS_W12_BASE,
+ [DBSC3_13] = DBSC3_0_QOS_W13_BASE,
+ [DBSC3_14] = DBSC3_0_QOS_W14_BASE,
+ [DBSC3_15] = DBSC3_0_QOS_W15_BASE,
+};
+
+/* QoS version 0.955 for ES1 */
void qos_init(void)
{
int i;
@@ -115,7 +115,6 @@ void qos_init(void)
writel(0x20142032, s3c_qos-s3cqos8);
s3c_qos = (struct rcar_s3c_qos *)S3C_QOS_AXI_BASE;
-
writel(0x00810089, s3c_qos-s3cqos0);
writel(0x20410001, s3c_qos-s3cqos1);
writel(0x200A2023, s3c_qos-s3cqos2);
@@ -129,9 +128,24 @@ void qos_init(void)
writel(0x00200808, s3c-s3carcr11);
/* DBSC -QoS */
- /* DBSC0 - Read/Write */
- for (i = DBSC3_R00; i DBSC3_NR; i++) {
- qos_addr = (struct rcar_dbsc3_qos *)dbsc3_qos_addr[i];
+ /* DBSC0 - Read */
+ for (i = DBSC3_00; i DBSC3_NR; i++) {
+ qos_addr = (struct rcar_dbsc3_qos *)dbsc3_0_r_qos_addr[i];
+ writel(0x0203, qos_addr-dblgcnt);
+ writel(0x2064, qos_addr-dbtmval0);
+ writel(0x2048,
[U-Boot] [PATCH 4/6] arm: rmobile: lager: Add Qos setting for ES2
This adds support version 0.963 for ES2 of lager board.
Signed-off-by: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com
---
board/renesas/lager/qos.c | 1253 -
1 file changed, 1251 insertions(+), 2 deletions(-)
diff --git a/board/renesas/lager/qos.c b/board/renesas/lager/qos.c
index 930fe8d..ce7f8ba 100644
--- a/board/renesas/lager/qos.c
+++ b/board/renesas/lager/qos.c
@@ -12,7 +12,7 @@
#include asm/io.h
#include asm/arch/rmobile.h
-/* QoS version 0.955 for ES1
+/* QoS version 0.955 for ES1 and version 0.963 for ES2 */
enum {
DBSC3_00, DBSC3_01, DBSC3_02, DBSC3_03, DBSC3_04,
@@ -61,7 +61,7 @@ static u32 dbsc3_0_w_qos_addr[DBSC3_NR] = {
};
/* QoS version 0.955 for ES1 */
-void qos_init(void)
+static void qos_init_es1(void)
{
int i;
struct rcar_s3c *s3c;
@@ -1132,3 +1132,1252 @@ void qos_init(void)
writel(0x0001, axi_qos-qosthres2);
writel(0x, axi_qos-qosqon);
}
+
+/* QoS version 0.963 for ES2 */
+static void qos_init_es2(void)
+{
+ int i;
+ struct rcar_s3c *s3c;
+ struct rcar_s3c_qos *s3c_qos;
+ struct rcar_dbsc3_qos *qos_addr;
+ struct rcar_mxi *mxi;
+ struct rcar_mxi_qos *mxi_qos;
+ struct rcar_axi_qos *axi_qos;
+
+ /* DBSC DBADJ2 */
+ writel(0x20042004, DBSC3_0_DBADJ2);
+
+ /* S3C -QoS */
+ s3c = (struct rcar_s3c *)S3C_BASE;
+ writel(0x8000, s3c-s3cadsplcr);
+ writel(0x1F060504, s3c-s3crorr);
+ writel(0x1F060503, s3c-s3cworr);
+
+ /* QoS Control Registers */
+ s3c_qos = (struct rcar_s3c_qos *)S3C_QOS_CCI0_BASE;
+ writel(0x00890089, s3c_qos-s3cqos0);
+ writel(0x20960010, s3c_qos-s3cqos1);
+ writel(0x20302030, s3c_qos-s3cqos2);
+ writel(0x20AA2200, s3c_qos-s3cqos3);
+ writel(0x2032, s3c_qos-s3cqos4);
+ writel(0x20960010, s3c_qos-s3cqos5);
+ writel(0x20302030, s3c_qos-s3cqos6);
+ writel(0x20AA2200, s3c_qos-s3cqos7);
+ writel(0x2032, s3c_qos-s3cqos8);
+
+ s3c_qos = (struct rcar_s3c_qos *)S3C_QOS_CCI1_BASE;
+ writel(0x00890089, s3c_qos-s3cqos0);
+ writel(0x20960010, s3c_qos-s3cqos1);
+ writel(0x20302030, s3c_qos-s3cqos2);
+ writel(0x20AA2200, s3c_qos-s3cqos3);
+ writel(0x2032, s3c_qos-s3cqos4);
+ writel(0x20960010, s3c_qos-s3cqos5);
+ writel(0x20302030, s3c_qos-s3cqos6);
+ writel(0x20AA2200, s3c_qos-s3cqos7);
+ writel(0x2032, s3c_qos-s3cqos8);
+
+ s3c_qos = (struct rcar_s3c_qos *)S3C_QOS_MXI_BASE;
+ writel(0x80928092, s3c_qos-s3cqos0);
+ writel(0x20960020, s3c_qos-s3cqos1);
+ writel(0x20302030, s3c_qos-s3cqos2);
+ writel(0x20AA20DC, s3c_qos-s3cqos3);
+ writel(0x2032, s3c_qos-s3cqos4);
+ writel(0x20960020, s3c_qos-s3cqos5);
+ writel(0x20302030, s3c_qos-s3cqos6);
+ writel(0x20AA20DC, s3c_qos-s3cqos7);
+ writel(0x2032, s3c_qos-s3cqos8);
+
+ s3c_qos = (struct rcar_s3c_qos *)S3C_QOS_AXI_BASE;
+ writel(0x00820082, s3c_qos-s3cqos0);
+ writel(0x20960020, s3c_qos-s3cqos1);
+ writel(0x20302030, s3c_qos-s3cqos2);
+ writel(0x20AA20FA, s3c_qos-s3cqos3);
+ writel(0x2032, s3c_qos-s3cqos4);
+ writel(0x20960020, s3c_qos-s3cqos5);
+ writel(0x20302030, s3c_qos-s3cqos6);
+ writel(0x20AA20FA, s3c_qos-s3cqos7);
+ writel(0x2032, s3c_qos-s3cqos8);
+
+ writel(0x00200808, s3c-s3carcr11);
+
+ /* DBSC -QoS */
+ /* DBSC0 - Read */
+ for (i = DBSC3_00; i DBSC3_NR; i++) {
+ qos_addr = (struct rcar_dbsc3_qos *)dbsc3_0_r_qos_addr[i];
+ writel(0x0002, qos_addr-dblgcnt);
+ writel(0x2096, qos_addr-dbtmval0);
+ writel(0x2064, qos_addr-dbtmval1);
+ writel(0x2032, qos_addr-dbtmval2);
+ writel(0x1FB0, qos_addr-dbtmval3);
+ writel(0x0001, qos_addr-dbrqctr);
+ writel(0x2078, qos_addr-dbthres0);
+ writel(0x204B, qos_addr-dbthres1);
+ writel(0x201E, qos_addr-dbthres2);
+ writel(0x0001, qos_addr-dblgqon);
+ }
+
+ /* DBSC0 - Write */
+ for (i = DBSC3_00; i DBSC3_NR; i++) {
+ qos_addr = (struct rcar_dbsc3_qos *)dbsc3_0_w_qos_addr[i];
+ writel(0x0002, qos_addr-dblgcnt);
+ writel(0x2096, qos_addr-dbtmval0);
+ writel(0x2064, qos_addr-dbtmval1);
+ writel(0x2050, qos_addr-dbtmval2);
+ writel(0x203A, qos_addr-dbtmval3);
+ writel(0x0001, qos_addr-dbrqctr);
+ writel(0x2078, qos_addr-dbthres0);
+ writel(0x204B, qos_addr-dbthres1);
+ writel(0x203C, qos_addr-dbthres2);
+ writel(0x0001, qos_addr-dblgqon);
+ }
+
+ /* MXI -QoS */
+ /* Transaction Control
[U-Boot] [PATCH 5/6] arm: rmobile: lager: Fix CPU frequency setting
Setting to change the CPU frequency is only used version2.
Signed-off-by: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com
---
board/renesas/lager/lager.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/board/renesas/lager/lager.c b/board/renesas/lager/lager.c
index a5a0474..5302839 100644
--- a/board/renesas/lager/lager.c
+++ b/board/renesas/lager/lager.c
@@ -29,15 +29,17 @@ void s_init(void)
{
struct rcar_rwdt *rwdt = (struct rcar_rwdt *)RWDT_BASE;
struct rcar_swdt *swdt = (struct rcar_swdt *)SWDT_BASE;
- u32 stc;
/* Watchdog init */
writel(0xA5A5A500, rwdt-rwtcsra);
writel(0xA5A5A500, swdt-swtcsra);
/* CPU frequency setting. Set to 1.4GHz */
- stc = ((1500 / CLK2MHZ(CONFIG_SYS_CLK_FREQ)) - 1) PLL0_STC_BIT;
- clrsetbits_le32(PLL0CR, PLL0_STC_MASK, stc);
+ if (rmobile_get_cpu_rev_integer() = R8A7790_CUT_ES2X) {
+ u32 stc = ((1400 / CLK2MHZ(CONFIG_SYS_CLK_FREQ)) - 1)
+PLL0_STC_BIT;
+ clrsetbits_le32(PLL0CR, PLL0_STC_MASK, stc);
+ }
/* QoS(Quality-of-Service) Init */
qos_init();
--
2.0.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/6] arm: rmobile: Remove unnecessary initialization for l2ctlr
This removes duplicate initialization of l2ctlr. Signed-off-by: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com --- arch/arm/cpu/armv7/rmobile/lowlevel_init_ca15.S | 5 - 1 file changed, 5 deletions(-) diff --git a/arch/arm/cpu/armv7/rmobile/lowlevel_init_ca15.S b/arch/arm/cpu/armv7/rmobile/lowlevel_init_ca15.S index 287f8d7..dbb96ed 100644 --- a/arch/arm/cpu/armv7/rmobile/lowlevel_init_ca15.S +++ b/arch/arm/cpu/armv7/rmobile/lowlevel_init_ca15.S @@ -42,11 +42,6 @@ do_lowlevel_init: mcreq p15, 0, r0, c1, c0, 1 /* and set l2 latency */ - mrceq p15, 1, r0, c9, c0, 2 /* l2ctlr */ - orreq r0, r0, #0x0800 - orreq r0, r0, #0x0003 - mcreq p15, 1, r0, c9, c0, 2 - mrc p15, 0, r0, c0, c0, 5 /* r0 = MPIDR */ and r0, r0, #0xf00 lsr r0, r0, #8 -- 2.0.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/4] usb/gadget: fastboot: add eMMC support for flash command
On 14-08-06 05:13 PM, Marek Vasut wrote:
On Thursday, August 07, 2014 at 01:48:06 AM, Steve Rae wrote:
On 14-07-30 06:37 PM, Marek Vasut wrote:
On Thursday, June 26, 2014 at 10:13:22 PM, Steve Rae wrote:
[...]
+
+#include common.h
+#include fb_mmc.h
+#include part.h
+#include sparse_format.h
+
+/* The 64 defined bytes plus \0 */
+#define RESPONSE_LEN (64 + 1)
+
+static char *response_str;
I'd suggest to pass this response_str around instead of making it
global.
That would involve adding it to fastboot_resp(), which is called 11
times in this code, from 3 different functions (so would need to add
this to two of the functions...). And as these evolve, there will likely
be more nested functions, which would all require passing it around
I think that this static global pointer is a cleaner implementation.
Eventually, the amount of these static variables in the code will grow and it
will become increasingly difficult to weed them out. I believe it would be even
better to pass around some kind of a structure with private data of the
fastboot, which would cater for all possible variables which might come in the
future. What do you think ?
Yes -- if there is private data that the fastboot implementation
requires, then a data structure is the way to go. However, I still think
that this fastboot response string would even be an exception to that
private data
+static void fastboot_resp(const char *s)
+{
+ strncpy(response_str, s, RESPONSE_LEN);
+ response_str[RESPONSE_LEN - 1] = '\0';
This could be shrunk to a single snprintf(response_str, RESPONSE_LENGTH,
s); I think, but I'm not sure if the overhead won't grow.
snprintf() is used very sparingling in U-Boot
This is not a reason to avoid it.
true
, and with the cautionary statements in README (line 852)
Which statements? Can you please point them out? I fail to see them, sorry.
I was referring to what you mention below...
852 - Safe printf() functions
853 Define CONFIG_SYS_VSNPRINTF to compile in safe versions of
854 the printf() functions. These are defined in
855 include/vsprintf.h and include snprintf(), vsnprintf() and
856 so on. Code size increase is approximately 300-500 bytes.
857 If this option is not given then these functions will
858 silently discard their buffer size argument - this means
859 you are not getting any overflow checking in this case.
and the fact that CONFIG_SYS_VSNPRINTF is not defined for armv7 builds, I am
not going to use it
Is it a problem to define it? Also, even without CONFIG_SYS_VSNPRINTF , the
functions are still available, see the README:
857 If this option is not given then these functions will
858 silently discard their buffer size argument - this means
859 you are not getting any overflow checking in this case.
I have yet to see some hard-evidence against using safe printing functions here.
I don't want to be the first to defined it for all of armv7
And I really don't want to define it only only my boards running so that
they can run 'fastboot'
What do you suggest?
+}
+
+static int is_sparse_image(void *buf)
+{
+ sparse_header_t *s_header = (sparse_header_t *)buf;
+
+ if ((le32_to_cpu(s_header-magic) == SPARSE_HEADER_MAGIC)
+ (le16_to_cpu(s_header-major_version) == 1))
+ return 1;
+
+ return 0;
+}
+
+static void write_sparse_image(block_dev_desc_t *dev_desc,
+ disk_partition_t *info, const char *part_name,
+ void *buffer, unsigned int download_bytes)
+{
+ lbaint_t blk;
+ lbaint_t blkcnt;
+ lbaint_t blks;
+ sparse_header_t *s_header = (sparse_header_t *)buffer;
+ chunk_header_t *c_header;
+ void *buf;
+ uint32_t blk_sz;
+ uint32_t remaining_chunks;
+ uint32_t bytes_written = 0;
+
+ blk_sz = le32_to_cpu(s_header-blk_sz);
+
+ /* verify s_header-blk_sz is exact multiple of info-blksz */
+ if (blk_sz != (blk_sz ~(info-blksz - 1))) {
+ printf(%s: Sparse image block size issue [%u]\n,
+ __func__, blk_sz);
+ fastboot_resp(FAILsparse image block size issue);
Can't you just make the fastboot_resp() function a variadic one AND move
the printf() into the fastboot_resp() function? You could then even get
consistent output on both the device and in the response if you
snprintf() into the response_str first and then printf() the
response_str .
Generally, the printf() statements which are sent to the console, and
the fastboot_resp() statements which are sent to the host running the
fastboot application are not the same
OK, thanks!
Thanks, Steve
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/5] Implement fastboot flash for eMMC
On 14-08-06 05:16 PM, Marek Vasut wrote: On Thursday, August 07, 2014 at 01:55:08 AM, Steve Rae wrote: This series implements the fastboot flash command for eMMC devices. It supports both raw and sparse images. NOTES: - the support for the fastboot flash command is enabled with CONFIG_FASTBOOT_FLASH - the support for eMMC is enabled with CONFIG_FASTBOOT_FLASH_MMC_DEV - (future) the support for NAND would be enabled with CONFIG_FASTBOOT_FLASH_NAND(???) This has been tested on ARMv7. I'll just wait for Tom's comments on 4/5 and 5/5 and will see then. The 1-3/5 look OK. Best regards, Marek Vasut THANKS! Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 4/5] usb/gadget: fastboot: add sparse image definitions
On 14-08-06 05:14 PM, Marek Vasut wrote: On Thursday, August 07, 2014 at 01:55:12 AM, Steve Rae wrote: - to prepare for the support of fastboot sparse images Signed-off-by: Steve Rae s...@broadcom.com --- Are we discussing the licensing issues here still ? Tom ? Best regards, Marek Vasut I hope so -- and I'm hoping that someone can help resolve this Thanks in advance, Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 4/5] usb/gadget: fastboot: add sparse image definitions
On Thursday, August 07, 2014 at 02:31:17 AM, Steve Rae wrote: On 14-08-06 05:14 PM, Marek Vasut wrote: On Thursday, August 07, 2014 at 01:55:12 AM, Steve Rae wrote: - to prepare for the support of fastboot sparse images Signed-off-by: Steve Rae s...@broadcom.com --- Are we discussing the licensing issues here still ? Tom ? Best regards, Marek Vasut I hope so -- and I'm hoping that someone can help resolve this Thanks in advance, Steve Someone should ask the legal dept ... Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
