Re: [U-Boot] [PATCH 1/2] sunxi: Replace CONFIG_SUN[457]I ifdefs with SOC_IS_SUN[457]I() calls

[Ian Campbell]

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

[Ian Campbell]

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_PROMPT"sunxi# "

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

[Koen Kooi]

Op 5 aug. 2014, om 23:37 heeft Michal Suchanek  het 
volgende geschreven:

> On 5 August 2014 23:03, Maxime Ripard  
> 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

[Hans de Goede]

Use cli_simple_process_macros, so that environment
variables (e.g. ${console}) can be used in append strings.

Signed-off-by: Hans de Goede 

--
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 
 
 #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

[Ian Campbell]

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

[Hans de Goede]

Signed-off-by: Hans de Goede 
---
 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

[Hans de Goede]

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

[Michal Simek]

On 08/06/2014 08:49 AM, Masahiro Yamada wrote:
> Hi Michal,
> 
> 
> On Wed, 6 Aug 2014 08:39:47 +0200
> Michal Simek  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 
>>> Cc: Michal Simek 
>>> ---
>>>
>>> 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

[Tim Harvey]

On Mon, Aug 4, 2014 at 5:49 AM, Nikita Kiryanov  wrote:
> Hi Tim,
>
>
> On 04/08/14 08:43, Tim Harvey wrote:
>>
>> On Sun, Aug 3, 2014 at 12:34 AM, Nikita Kiryanov 
>> wrote:
>>>
>>> Bit 16 in mapsr register is in a reserved field. Don't write to it.
>>>
>>> Cc: Stefano Babic 
>>> Cc: Tim Harvey 
>>> Signed-off-by: Nikita Kiryanov 
>>> ---
>>>   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 

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

[Stefano Babic]

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 

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

[Masahiro Yamada]

Hi Michal,



On Wed, 6 Aug 2014 09:57:46 +0200
Michal Simek  wrote:

> On 08/06/2014 08:49 AM, Masahiro Yamada wrote:
> > Hi Michal,
> > 
> > 
> > On Wed, 6 Aug 2014 08:39:47 +0200
> > Michal Simek  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 
> >>> Cc: Michal Simek 
> >>> ---
> >>>
> >>> 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

[Stefan Agner]

Add NFC (NAND Flash Controller) clock support and enable them
at board initialization time.

Signed-off-by: Stefan Agner 
---
 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

[Stefan Agner]

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

[Stefan Agner]

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 
---
 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 = IOMUX_PAD(0x0194, 0x0194, 

[U-Boot] [PATCH 3/4] mtd: nand: add Freescale NFC driver

[Stefan Agner]

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 
---
 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 
+ *  Bill Pringlemeir 
+ *  Shaohui Xie 
+ *  Jason Jin 
+ *
+ * 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 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#defineDRV_NAME"fsl_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  (1<<0)
+
+/* 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  0x7FC0
+#define CONFIG_ECC_SRAM_ADDR_SHIFT 22
+#define CONFIG_ECC_SRAM_REQ_BIT(1<<21)
+#define CONFIG_DMA_REQ_BIT (1<<20)
+#define CONFIG_ECC_MODE_

[U-Boot] [PATCH 4/4] arm: vf610: add NAND support for vf610twr

[Stefan Agner]

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 
---
 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,

Re: [U-Boot] [PATCH v2 02/15] zynq: kconfig: move board select menu and commonsettings

[Michal Simek]

On 08/06/2014 10:31 AM, Masahiro Yamada wrote:
> Hi Michal,
> 
> 
> 
> On Wed, 6 Aug 2014 09:57:46 +0200
> Michal Simek  wrote:
> 
>> On 08/06/2014 08:49 AM, Masahiro Yamada wrote:
>>> Hi Michal,
>>>
>>>
>>> On Wed, 6 Aug 2014 08:39:47 +0200
>>> Michal Simek  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 
> Cc: Michal Simek 
> ---
>
> 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

[Tim Harvey]

On Sun, Aug 3, 2014 at 4:47 PM, Marek Vasut  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 
> ---
>  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 
___
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

[Bo Shen]

When use pcr (peripheral control register), then we won't need
to care about the peripheral ID.

Signed-off-by: Bo Shen 
---

 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

[Bo Shen]

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

[Bo Shen]

If the SoC has pcr, we use pcr (peripheral control register)
to enable or disable clock.

Signed-off-by: Bo Shen 
---

 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

[Bo Shen]

Using CPU_HAS_PCR micro to present the SoC has pcr
(peripheral control register).

Signed-off-by: Bo Shen 
---

 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

[Bo Shen]

If the SoC has pcr, we use pcr (peripheral control register)
to enable or disable clock.

Signed-off-by: Bo Shen 
---

 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

[Masahiro Yamada]

Hi Michal,


On Wed, 6 Aug 2014 11:10:14 +0200
Michal Simek  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

[Mark Rutland]

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

[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.


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

[Prafulla Wadaskar]

> -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
> 
> Cc: Prafulla Wadaskar 
> Cc: Luka Perkov 
> ---
> 
> 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 

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

[Prafulla Wadaskar]

> -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
> > 
> > Cc: Prafulla Wadaskar 
> > Cc: Luka Perkov 
> > ---
> >
> > 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 
> 
> W

Re: [U-Boot] [PATCH] ARM: HYP/non-sec: Add MIDR check to detect unsupported CPUs

[Marc Zyngier]

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

[Sonic Zhang]

From: Sonic Zhang 

Wait data transfer till the data end bit other than the data block end
bit is set.

Signed-off-by: Sonic Zhang 
---

 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

[Prafulla Wadaskar]

> -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

[Alexander Holler]

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  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

[Måns Rullgård]

Alexander Holler  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

[Nikita Kiryanov]

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_.
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 
Cc: Tom Rini 
Signed-off-by: Nikita Kiryanov 


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

[Stefano Babic]

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

[Hans de Goede]

Hi,

On 08/06/2014 09:24 AM, Koen Kooi wrote:
> 
> Op 5 aug. 2014, om 23:37 heeft Michal Suchanek  het 
> volgende geschreven:
> 
>> On 5 August 2014 23:03, Maxime Ripard  
>> 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

[Alexander Holler]

Am 06.08.2014 12:44, schrieb Måns Rullgård:

Alexander Holler  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

[Michal Simek]

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  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

[Michal Simek]

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  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

[Marek Vasut]

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_  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 
>  Cc: Tom Rini 
>  Signed-off-by: Nikita Kiryanov 
> >>> 
> >>> 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

[Luc Verhaegen]

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

[Alexander Holler]

Am 06.08.2014 13:18, schrieb Alexander Holler:

Am 06.08.2014 12:44, schrieb Måns Rullgård:

Alexander Holler  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

[Maxime Ripard]

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

[Tom Rini]

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

[Jon Loeliger]

>>
>> 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

[Alexandre Delove]

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

[Simon Glass]

Hi York,

On 5 August 2014 20:53, York Sun  wrote:
>
>
> On 8/5/14 7:15 PM, "Simon Glass"  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

[Tom Rini]

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

[Tom Rini]

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

[Tom Rini]

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

[Tom Rini]

On Thu, Jul 31, 2014 at 05:30:03PM -0600, Stephen Warren wrote:

> From: Stephen Warren 
> 
> It's easier to Cc Masahiro on Kconfig-related changes with a git-mailrc
> alias.
> 
> Signed-off-by: Stephen Warren 
> Acked-by: Masahiro Yamada 

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

[Tom Rini]

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 

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

[Tom Rini]

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

[Tom Rini]

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 

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

[Tom Rini]

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

[Tom Rini]

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 

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

[Tom Rini]

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

[Tom Rini]

On Wed, Aug 06, 2014 at 08:20:47AM -0600, Simon Glass wrote:
> Hi York,
> 
> On 5 August 2014 20:53, York Sun  wrote:
> >
> >
> > On 8/5/14 7:15 PM, "Simon Glass"  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 '(powerpc&freescale)|(arm&freescale)'

-- 
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

[Simon Glass]

Hi Jon,

On 6 August 2014 07:56, Jon Loeliger  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

[Stephen Warren]

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

[Stephen Warren]

On 07/23/2014 03:56 PM, Joe Hershberger wrote:


On Wed, Jul 23, 2014 at 4:41 PM, Stephen Warren 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
mailto:swar...@wwwdotorg.org>
 > > >> wrote:
 > >>
 > >> From: Stephen Warren 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 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

[Stephen Warren]

On 07/25/2014 05:30 PM, Stephen Warren wrote:

From: Stephen Warren 

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

[Stephen Warren]

On 07/30/2014 04:37 PM, Stephen Warren wrote:

From: Dennis Gilmore 

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

[Stephen Warren]

On 07/31/2014 01:40 PM, Stephen Warren wrote:

From: Stephen Warren 

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

[Stephen Warren]

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 

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

[Simon Glass]

Hi Stephen,

On 6 August 2014 10:01, Stephen Warren  wrote:
> On 07/30/2014 04:37 PM, Stephen Warren wrote:
>>
>> From: Dennis Gilmore 
>>
>> 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

[York Sun]

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 12/18] arm: mx6: add support for Compulab cm-fx6 CoM

[Nikita Kiryanov]

On 04/08/14 16:36, Nikita Kiryanov wrote:



On 04/08/14 07:45, Tim Harvey wrote:

On Sun, Aug 3, 2014 at 12:34 AM, Nikita Kiryanov
 wrote:

Add initial support for Compulab CM-FX6 CoM.
Support includes MMC, SPI flash, and SPL with dynamic DRAM detection.




+
+static void spl_mx6s_dram_init(enum ddr_config dram_config, int reset)
+{
+   struct mx6_mmdc_calibration calib;
+   struct mx6_ddr_sysinfo sysinfo;
+   struct mx6_ddr3_cfg ddr3_cfg;
+
+   if (reset)
+   ((struct mmdc_p_regs *)MX6_MMDC_P0_MDCTL)->mdmisc = 2;
+
+   calib.p0_mpwldectrl0= 0x005B0061;
+   calib.p0_mpwldectrl1= 0x004F0055;
+   calib.p0_mpdgctrl0  = 0x0314030C;
+   calib.p0_mpdgctrl1  = 0x025C0268;
+   calib.p0_mprddlctl  = 0x42464646;
+   calib.p0_mpwrdlctl  = 0x36322C34;
+   ddr3_cfg.mem_speed  = 800;
+   ddr3_cfg.density= 4;
+   ddr3_cfg.rowaddr= 14;
+   ddr3_cfg.coladdr= 10;
+   ddr3_cfg.pagesz = 2;
+   ddr3_cfg.trcd   = 1800;
+   ddr3_cfg.trcmin = 5200;
+   ddr3_cfg.trasmin= 3600;
+   ddr3_cfg.SRT= 0;
+   sysinfo.cs1_mirror  = 1;
+   sysinfo.cs_density  = 16;
+   sysinfo.bi_on   = 1;
+   sysinfo.rtt_nom = 1;
+   sysinfo.rtt_wr  = 0;
+   sysinfo.ralat   = 5;
+   sysinfo.walat   = 1;
+   sysinfo.mif3_mode   = 3;
+   sysinfo.rst_to_cke  = 0x23;
+   sysinfo.sde_to_rst  = 0x10;
+   switch (dram_config) {
+   case DDR_16BIT_256MB:
+   sysinfo.dsize = 0;
+   sysinfo.ncs = 1;
+   break;
+   case DDR_32BIT_512MB:
+   sysinfo.dsize = 1;
+   sysinfo.ncs = 1;
+   break;
+   case DDR_32BIT_1GB:
+   sysinfo.dsize = 1;
+   sysinfo.ncs = 2;
+   break;
+   default:
+   puts("Tried to setup invalid DDR configuration\n");
+   hang();
+   }
+
+   mx6_dram_cfg(&sysinfo, &calib, &ddr3_cfg);
+   udelay(100);
+}


Nikita,

I'm curious why you add an extra udelay(100) here? There is an
mdelay(1) before the return of mx6_dram_cfg() to wait for auto-ZQ
calibration to complete (I never found a way to determine when it was
complete via registers).


Yes you're right. This udelay can probably be removed (unless I catch
the board misbehaving during multiple resets).


Caught the DRAM config failing during multiple resets when udelay(100)
is removed, so I guess they stay..





Regards,

Tim


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] powerpc/mpc85xx: Enabling CPC conditionally based on hwconfig options

[York Sun]

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

[Tom Rini]

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 
> >
> >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

[York Sun]

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

[York Sun]

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

[Scott Wood]

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] net: BOOTP retry timeout improvements

[Joe Hershberger]

On Fri, Jul 25, 2014 at 6:30 PM, Stephen Warren 
wrote:
>
> From: Stephen Warren 
>
> 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.
>
> Signed-off-by: Stephen Warren 
> ---

Acked-by: Joe Hershberger 
___
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

[York Sun]

On 07/03/2014 12:24 AM, Alison Wang wrote:

Missing commit message here.

> Signed-off-by: Alison Wang 
> ---
> 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 
>  #include 
>  
> +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

[York Sun]

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 
> ---

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

[York Sun]

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

[Steve Rae]

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 


Reviewed-by: Marek Vasut 

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

[Steve Rae]

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 
---

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

[Steve Rae]

On 14-07-30 06:37 PM, Marek Vasut wrote:

On Thursday, June 26, 2014 at 10:13:22 PM, Steve Rae wrote:
[...]

+
+#include 
+#include 
+#include 
+#include 
+
+/* 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

[Steve Rae]

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

[Steve Rae]

- add support for 'fastboot flash' command for eMMC devices

Signed-off-by: Steve Rae 
---

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 
+#include 
+#include 
+
+/* 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

[Steve Rae]

- update static function
- additional debugging statements
- update "fastboot command" information
- add missing include file
- update spelling

Signed-off-by: Steve Rae 
---

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 
 #include 
 #include 
 #include 
@@ -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

[Steve Rae]

- implement 'fastboot flash' for eMMC devices

Signed-off-by: Steve Rae 
Reviewed-by: Marek Vasut 
---

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 
 #include 
 #include 
+#ifdef CONFIG_FASTBOOT_FLASH_MMC_DEV
+#include 
+#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

[Steve Rae]

- to prepare for the support of fastboot sparse images

Signed-off-by: Steve Rae 
---
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

[Steve Rae]

- add capability to "fastboot flash" with sparse format images

Signed-off-by: Steve Rae 
---
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 
 #include 
 #include 
+#include 
 
 /* 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,
  

Re: [U-Boot] [PATCH v3 2/4] usb/gadget: fastboot: add eMMC support for flash command

[Marek Vasut]

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 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +/* 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

[Marek Vasut]

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 
> ---

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

[Marek Vasut]

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

[Nobuhiro Iwamatsu]

This update QoS version 0.334 for ES2 of R8A7791.

Signed-off-by: Nobuhiro Iwamatsu 
---
 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 
 #include 
 
-/* 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) */

[U-Boot] [PATCH 2/6] arm: rmobile: alt: Update QoS initialization to version 0.11

[Nobuhiro Iwamatsu]

Signed-off-by: Nobuhiro Iwamatsu 
---
 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 
 #include 
 
-/* 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

[Nobuhiro Iwamatsu]

This updates QoS version 0.955 for ES1 of lager board.

Signed-off-by: Nobuhiro Iwamatsu 
---
 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 
 #include 
 
-/* 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, &qos_addr->dbtmval1);
+   writel(0x2

[U-Boot] [PATCH 4/6] arm: rmobile: lager: Add Qos setting for ES2

[Nobuhiro Iwamatsu]

This adds support version 0.963 for ES2 of lager board.

Signed-off-by: Nobuhiro Iwamatsu 
---
 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 
 #include 
 
-/* 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);

[U-Boot] [PATCH 5/6] arm: rmobile: lager: Fix CPU frequency setting

[Nobuhiro Iwamatsu]

Setting to change the CPU frequency is only used version2.

Signed-off-by: Nobuhiro Iwamatsu 
---
 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

[Nobuhiro Iwamatsu]

This removes duplicate initialization of l2ctlr.

Signed-off-by: Nobuhiro Iwamatsu 
---
 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

[Steve Rae]

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 
+#include 
+#include 
+#include 
+
+/* 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

[Steve Rae]

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

[Steve Rae]

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 
---


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

[Marek Vasut]

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 
> >> ---
> > 
> > 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

Re: [U-Boot] [PATCH] powerpc/t1040qds: Remove Video - HDMI support

[dongsheng.w...@freescale.com]

Hi York,

Sorry, I'm wrong. Please drop the "powerpc/t1040qds: Remove Video - HDMI 
support" patch.

Cause of we need to keep u-boot support to QDS-DIU feature.

Regards,
Dongsheng

> -Original Message-
> From: Wang Dongsheng-B40534
> Sent: Thursday, August 07, 2014 10:22 AM
> To: Sun York-R58495; Jain Priyanka-B32167
> Cc: Wood Scott-B07421; u-boot@lists.denx.de
> Subject: RE: [PATCH] powerpc/t1040qds: Remove Video - HDMI support
> 
> Hi York,
> 
> Sorry for late response. We don't need to remove this patch. Please keep this
> patch.
> 
> Regards,
> Dongsheng
> 
> > -Original Message-
> > From: Sun York-R58495
> > Sent: Thursday, August 07, 2014 1:17 AM
> > To: Wang Dongsheng-B40534; Jain Priyanka-B32167
> > Cc: Wood Scott-B07421; u-boot@lists.denx.de
> > Subject: Re: [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