date:20140731

This patch series enable the features supported by the MCI
which not enabled before.

For example: high speed mode
without this patch:
  U-Boot fatload mmc 0 0x2000 uimage
  reading uimage
  3973216 bytes read in 392 ms (9.7 MiB/s)

with this patch
  U-Boot fatload mmc 0 0x2000 uimage
  reading uimage
  3973216 bytes read in 275 ms (13.8 MiB/s)

It near 50% performance improvement.


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

 drivers/mmc/gen_atmel_mci.c | 63 ++---
 include/atmel_mci.h | 18 -
 2 files changed, 65 insertions(+), 16 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 1/3] MMC: atmel_mci: refactor setting the mode register

The mode register is different between MCI IP version.
So, according to MCI IP version to set the mode register.

Signed-off-by: Bo Shen voice.s...@atmel.com
---
 drivers/mmc/gen_atmel_mci.c | 56 +
 include/atmel_mci.h |  4 
 2 files changed, 46 insertions(+), 14 deletions(-)

diff --git a/drivers/mmc/gen_atmel_mci.c b/drivers/mmc/gen_atmel_mci.c
index a57a9b1..8778a4d 100644
--- a/drivers/mmc/gen_atmel_mci.c
+++ b/drivers/mmc/gen_atmel_mci.c
@@ -58,30 +58,58 @@ static void mci_set_mode(struct mmc *mmc, u32 hz, u32 
blklen)
atmel_mci_t *mci = mmc-priv;
u32 bus_hz = get_mci_clk_rate();
u32 clkdiv = 255;
+   unsigned int version = atmel_mci_get_version(mci);
+   u32 clkodd = 0;
+   u32 mr;
 
debug(mci: bus_hz is %u, setting clock %u Hz, block size %u\n,
bus_hz, hz, blklen);
if (hz  0) {
-   /* find lowest clkdiv yielding a rate = than requested */
-   for (clkdiv=0; clkdiv255; clkdiv++) {
-   if ((bus_hz / (clkdiv+1) / 2) = hz)
-   break;
+   if (version = 0x500) {
+   clkdiv = DIV_ROUND_UP(bus_hz, hz) - 2;
+   if (clkdiv  511)
+   clkdiv = 511;
+
+   clkodd = clkdiv  1;
+   clkdiv = 1;
+
+   printf(mci: setting clock %u Hz, block size %u\n,
+  bus_hz / (clkdiv * 2 + clkodd + 2), blklen);
+   } else {
+   /* find clkdiv yielding a rate = than requested */
+   for (clkdiv = 0; clkdiv  255; clkdiv++) {
+   if ((bus_hz / (clkdiv + 1) / 2) = hz)
+   break;
+   }
+   printf(mci: setting clock %u Hz, block size %u\n,
+  (bus_hz / (clkdiv + 1)) / 2, blklen);
+
}
}
-   printf(mci: setting clock %u Hz, block size %u\n,
-   (bus_hz / (clkdiv+1)) / 2, blklen);
 
blklen = 0xfffc;
-   /* On some platforms RDPROOF and WRPROOF are ignored */
-   writel((MMCI_BF(CLKDIV, clkdiv)
-| MMCI_BF(BLKLEN, blklen)
-| MMCI_BIT(RDPROOF)
-| MMCI_BIT(WRPROOF)), mci-mr);
+
+   mr = MMCI_BF(CLKDIV, clkdiv);
+
+   /* MCI IP version = 0x200 has R/WPROOF */
+   if (version = 0x200)
+   mr |= MMCI_BIT(RDPROOF) | MMCI_BIT(WRPROOF);
+
/*
-* On some new platforms BLKLEN in mci-mr is ignored.
-* Should use the BLKLEN in the block register.
+* MCI IP version = 0x500 use bit 16 as clkodd.
+* MCI IP version  0x500 use upper 16 bits for blklen.
 */
-   writel(MMCI_BF(BLKLEN, blklen), mci-blkr);
+   if (version = 0x500)
+   mr |= MMCI_BF(CLKODD, clkodd);
+   else
+   mr |= MMCI_BF(BLKLEN, blklen);
+
+   writel(mr, mci-mr);
+
+   /* MCI IP version = 0x200 has blkr */
+   if (version = 0x200)
+   writel(MMCI_BF(BLKLEN, blklen), mci-blkr);
+
initialized = 1;
 }
 
diff --git a/include/atmel_mci.h b/include/atmel_mci.h
index 090574d..3d2870f 100644
--- a/include/atmel_mci.h
+++ b/include/atmel_mci.h
@@ -67,6 +67,10 @@ typedef struct atmel_mci {
 #define MMCI_PDCPADV_SIZE  1
 #define MMCI_PDCMODE_OFFSET15
 #define MMCI_PDCMODE_SIZE  1
+/* MCI IP version = 0x500, MR bit 16 used for CLKODD */
+#define MMCI_CLKODD_OFFSET 16
+#define MMCI_CLKODD_SIZE   1
+/* MCI IP version  0x200, MR higher 16bits for BLKLEN */
 #define MMCI_BLKLEN_OFFSET 16
 #define MMCI_BLKLEN_SIZE   16
 
-- 
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/3] MMC: atmel_mci: add configuration register definition

Add configuration register definition, this register only
exists on MCI IP version = 0x300.

Signed-off-by: Bo Shen voice.s...@atmel.com
---
 include/atmel_mci.h | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/include/atmel_mci.h b/include/atmel_mci.h
index 3d2870f..de24148 100644
--- a/include/atmel_mci.h
+++ b/include/atmel_mci.h
@@ -36,7 +36,9 @@ typedef struct atmel_mci {
u32 ier;/* 0x44 */
u32 idr;/* 0x48 */
u32 imr;/* 0x4c */
-   u32 reserved[43];
+   u32 dma;/* 0x50 */
+   u32 cfg;/* 0x54 */
+   u32 reserved[41];
u32 version;
 } atmel_mci_t;
 
@@ -189,6 +191,16 @@ typedef struct atmel_mci {
 #define MMCI_TRTYP_MULTI_BLOCK 1
 #define MMCI_TRTYP_STREAM  2
 
+/* Bitfields in CFG */
+#define MMCI_FIFOMODE_OFFSET   0
+#define MMCI_FIFOMODE_SIZE 1
+#define MMCI_FERRCTRL_OFFSET   4
+#define MMCI_FERRCTRL_SIZE 1
+#define MMCI_HSMODE_OFFSET 8
+#define MMCI_HSMODE_SIZE   1
+#define MMCI_LSYNC_OFFSET  12
+#define MMCI_LSYNC_SIZE1
+
 /* Bit manipulation macros */
 #define MMCI_BIT(name) \
(1  MMCI_##name##_OFFSET)
-- 
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/3] MMC: atmel_mci: enable high speed mode support

If the MCI IP version = 0x300, it supports hight speed mode
option, this patch enable it.

Signed-off-by: Bo Shen voice.s...@atmel.com
---
 drivers/mmc/gen_atmel_mci.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/gen_atmel_mci.c b/drivers/mmc/gen_atmel_mci.c
index 8778a4d..45bcffb 100644
--- a/drivers/mmc/gen_atmel_mci.c
+++ b/drivers/mmc/gen_atmel_mci.c
@@ -110,6 +110,9 @@ static void mci_set_mode(struct mmc *mmc, u32 hz, u32 
blklen)
if (version = 0x200)
writel(MMCI_BF(BLKLEN, blklen), mci-blkr);
 
+   if (mmc-card_caps  mmc-cfg-host_caps  MMC_MODE_HS)
+   writel(MMCI_BIT(HSMODE), mci-cfg);
+
initialized = 1;
 }
 
@@ -404,8 +407,10 @@ int atmel_mci_init(void *regs)
/* need to be able to pass these in on a board by board basis */
cfg-voltages = MMC_VDD_32_33 | MMC_VDD_33_34;
version = atmel_mci_get_version(mci);
-   if ((version  0xf00) = 0x300)
+   if ((version  0xf00) = 0x300) {
cfg-host_caps = MMC_MODE_8BIT;
+   cfg-host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;
+   }
 
cfg-host_caps |= MMC_MODE_4BIT;
 
-- 
1.8.5.2

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

Re: [U-Boot] Quick guide to Kconfig

2014-07-31 Thread Frank Ihle

Hi Masahiro,

thanks! it's running nicely. I see you're running the GUI with lxdialog, and 
it's nice to see that more and more build systems come together to one base, 
which makes it much easier for further developing. 

I've just started using it on our project too, but the integration is a pretty 
tenacious job, as you might know. I would much appreciate it, if you could 
share any information like tutorials or documentation for a better adaptation 
of the lxdialog, if that's alright. Because, if we are using U-Boots 
menuconfig, then we'd like to add extra rows with information on our own.

Kind Regards 

Frank

 Masahiro Yamada yamad...@jp.panasonic.com 31.07.14 8.39 Uhr 
Hi Frank,


On Thu, 31 Jul 2014 08:29:07 +0200
Frank Ihle frank.i...@hs-offenburg.de wrote:

 Hi everyone,
 
 can you please give me a hint how to run the menuconfig?
  
 I just downloaded the latest U-Boot from 
 ftp://ftp.denx.de/pub/u-boot/u-boot-latest.tar.bz2 (Version: 2014.07). When 
 entering the /u-boot-2014.07/ directory and hitting make menuconfig then, 
 it just tells me that there's no rule to make menuconfig - and so I can't 
 run the configuration tool. Am I in the wrong directory or is it the wrong 
 version?



Kconfig is not included in u-boot-latest.tar.bz2 (Version: 2014.07);
Kconfig was merged into the mainline just ten hours ago!

If you want to try the newest source tree,
please do git-clone.

git clone git://git.denx.de/u-boot.git



Best Regards
Masahiro Yamada



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

Re: [U-Boot] Please pull u-boot-sunxi.git/master

2014-07-31 Thread Ian Campbell

On Thu, 2014-07-31 at 13:30 +0900, Masahiro Yamada wrote:
 Hi Tom, Albert, Hans,
 
 
 I am afraid we are going to be in trouble
 with this pre-Kconfig based PR
 because it includes various new boards.

Yeah, I was wondering how this would work!

 (We can fix the merge conflict,
 but it is not trivial.)
 
 
 How this is going to work?
 
 Perhaps should we discard unmerged PRs and
 get all the subsystem repos
 synchronized with u-boot/master ?
 
 
 Or shall we break these boards once
 and fix them in a follow-up patch ?

Can you point us to the conversion script please?

(I say us/we here but I'm actually about to get on a plain and be AFK
for several days, so I guess I mean Hans ;-))

With that script we could rebase onto the current branch base running
the script at every step (including a new artificial step right before
the top of the branch to pickup all the other boards) and commit --amend
any new defconfigs which are produced.

Then rebase the result of that onto the current master, ignoring
conflicts in boards.cfg (i.e. just deleting it each time).

The result should be a rebased tree where all the changes to boards.cfg
are instead replicated in the appropriate defconfig.

Does that sound workable?

Ian.

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

Re: [U-Boot] Please pull u-boot-sunxi.git/master

Hi,

On 07/31/2014 09:54 AM, Ian Campbell wrote:
 On Thu, 2014-07-31 at 13:30 +0900, Masahiro Yamada wrote:
 Hi Tom, Albert, Hans,


 I am afraid we are going to be in trouble
 with this pre-Kconfig based PR
 because it includes various new boards.
 
 Yeah, I was wondering how this would work!
 
 (We can fix the merge conflict,
 but it is not trivial.)


 How this is going to work?

 Perhaps should we discard unmerged PRs and
 get all the subsystem repos
 synchronized with u-boot/master ?


 Or shall we break these boards once
 and fix them in a follow-up patch ?
 
 Can you point us to the conversion script please?
 
 (I say us/we here but I'm actually about to get on a plain and be AFK
 for several days, so I guess I mean Hans ;-))
 
 With that script we could rebase onto the current branch base running
 the script at every step (including a new artificial step right before
 the top of the branch to pickup all the other boards) and commit --amend
 any new defconfigs which are produced.
 
 Then rebase the result of that onto the current master, ignoring
 conflicts in boards.cfg (i.e. just deleting it each time).
 
 The result should be a rebased tree where all the changes to boards.cfg
 are instead replicated in the appropriate defconfig.
 
 Does that sound workable?

That sounds workable to me. I can try to get that done this weekend,
and then send a new PR rebased on current master.

Regards,

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

Re: [U-Boot] Please pull u-boot-sunxi.git/master

2014-07-31 Thread Masahiro Yamada

Hi Ian, Hans,


On Thu, 31 Jul 2014 08:54:09 +0100
Ian Campbell i...@hellion.org.uk wrote:

 On Thu, 2014-07-31 at 13:30 +0900, Masahiro Yamada wrote:
  Hi Tom, Albert, Hans,
  
  
  I am afraid we are going to be in trouble
  with this pre-Kconfig based PR
  because it includes various new boards.
 
 Yeah, I was wondering how this would work!
 
  (We can fix the merge conflict,
  but it is not trivial.)
  
  
  How this is going to work?
  
  Perhaps should we discard unmerged PRs and
  get all the subsystem repos
  synchronized with u-boot/master ?
  
  
  Or shall we break these boards once
  and fix them in a follow-up patch ?
 
 Can you point us to the conversion script please?


Sure.

These are the conversion tools I used in my series:

http://patchwork.ozlabs.org/patch/374412/
   for generating *_defconfig and Kconfig

http://patchwork.ozlabs.org/patch/374406/
   for generating MAINTAINERS


I assume you have boards.cfg on your local branch.

If you run 'tools/genkconfig' and 'tools/gen_maintainers.py',
*_defconfig, Kconfig, and MAINTAINERS will be generated
for all the boards listed in the boards.cfg file.

And then commit --amend the diffs of *_defconfig, Kconfig, MAINTAINERS.



 (I say us/we here but I'm actually about to get on a plain and be AFK
 for several days, so I guess I mean Hans ;-))
 
 With that script we could rebase onto the current branch base running
 the script at every step (including a new artificial step right before
 the top of the branch to pickup all the other boards) and commit --amend
 any new defconfigs which are produced.
 
 Then rebase the result of that onto the current master, ignoring
 conflicts in boards.cfg (i.e. just deleting it each time).
 
 The result should be a rebased tree where all the changes to boards.cfg
 are instead replicated in the appropriate defconfig.
 
 Does that sound workable?


Yes. Sounds good!
Thanks!

In you are in trouble, please feel free to ask questions.
I am happy to help you.


Best Regards
Masahiro Yamada

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

Re: [U-Boot] Can not boot Linux with new FIT image on ARMv8

2014-07-31 Thread Simon Glass

Hi,


On 31 July 2014 02:24, Duxiaoqiang duxiaoqi...@huawei.com wrote:

 Hi Simon



  This problem has confused me several days, I will appreciated if you
 can give me susggestions.

 You could try 'setenv verify n' to turn off verification. That will make
 sure that the problem is actually related to verified boot. Does the image
 boot OK without verified boot?

 Added by Jason##
 I tried setenv verify n, but boot the image is not OK. So the problem
 should not related verified boot.

 It says:

 Loading Device Tree to 9fe0, end 9fe04a91 ...
  fdt_rsv_mem_addr = c32b2540

 Is that a valid address? What addresses are the kernel, FDT and ramdisk
 loaded to when you use the legacy image?

 I think the address is normal, I run on foundation platform, the physical
 memory space is up to 4G.
 I used to load legacy image as bellow:
 Kernel Image load/entry: 0x9000
 Fdt blod address:0xa000
 Ramdisk : 0xa100
 Uboot code section: 0x8800

 The address space for now new FIT image
 Kernel Image load/entry: 0x8900
 Fdt blob: It is relocated by uboot, speculate from debug information, it
 is 0x9fe0
 RAM disk: It is set to 0xaa00 at FIT file, but relocated by uboot.
 Speculate from debug information, the address is 0xe7c83000
 Uboot code section:0x8800
 FIT image to be load:0xc304


Well then I'm not sure what is going on, but it is probably worth debugging
into the kernel and asking on the kernel mailing list.

Perhaps with a debugger attached you might figure out where it goes into
the weeds?

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

Re: [U-Boot] Driver Model and DTS Parsing

2014-07-31 Thread Simon Glass

Hi Stephen,

On 30 July 2014 20:57, Stephen Warren swar...@wwwdotorg.org wrote:

 On 07/30/2014 10:09 AM, Simon Glass wrote:

 Hi Stephen,

 On 30 July 2014 16:47, Stephen Warren swar...@wwwdotorg.org wrote:

 On 07/30/2014 09:26 AM, Simon Glass wrote:


 Hi Stephen,

 On 12 June 2014 23:31, Stephen Warren swar...@wwwdotorg.org wrote:


 On 06/11/2014 10:55 PM, Simon Glass wrote:
 ...


 Tegra doesn't have much in the device tree for GPIOs - it seems to be
 all hard-coded in the software. So I ended up with the code you saw
 which just iterates over a known number of banks, creating a device
 for each.



 That still sounds wrong. Tegra HW has a single GPIO controller that
 exposes a bunch of GPIOs. It isn't logically divided into banks or any
 other construct that is multi-level  Although the naming of the
 individual GPIOs does call something a bank, that's just a name of a
 register, not separate HW blocks. It's just going to be confusing to
 users if the U-Boot representation doesn't match what the HW actually
 has.



 I'm getting back to this as I just re-issued the series.

 I don't see the mismatch you are referring to here. U-Boot people are
 used to seeing GPIOs as named banks, and the Tegra TRM uses bank names
 also.



 The mismaatch is that in HW, there is a single GPIO controller that has a
 large number of GPIOs, not a number of GPIO controllers that each has a
 smaller number of GPIOs.

 U-Boot's commands/APIs/... should model this directly; a single
 controller
 object that has a large number of GPIOs within it.

 As such, an example user-visible GPIO command needs to be roughly
 something
 like:

 # using integer IDs
 gpio set tegra 128
   ^^^^ (controller instance name) (GPIO ID)
 or:

 # using names within the controller
 gpio set tegra PQ0
   ^^^^ (controller instance name) (GPIO name)

 (note that there must be separate controller ID and GPIO ID parameters in
 the commands in order to e.g. differentiate between 2 instances of the
 same
 I2C GPIO expander chip; something like pca9555@a0@i2c0, pca9555@i2c1@a4)

 not:

 gpio set tegraP 10
   ^^ ^^ (hypothetical bank name) (GPIO ID within bank)

 or:

 gpio set P10
   ^^ GPIO name without any controller ID


 This will require enhancing the gpio command further, right?


 Sure, but that's going to be needed irrespective of this discussion, right?


No, the current series does not include this. It would be a separate
enhancement, probably proceeded by a wide-ranging discussion about the
U-Boot command line and how it will deal with multiple devices, etc (i.e.
not just for GPIOs).




  There's zero extra indirection caused by SW correctly describing the HW
 as a single bank. I have absolutely no idea what you mean my extra
 indirection here; any time there is a driver for a GPIO, you call a
 function to set a GPIO. That doesn't change based on whether there are
 32 or 1 GPIO controller drivers.  The only difference is how many
 drivers you have to search through to find the right one. For Tegra at
 least, I'm arguing for 1 driver to match the 1 HW module.



 OK let me explain a bit more.

 At the moment, the GPIO uclass supports a single GPIO bank, defined as
 something that has a name, like A, or B.



 The GPIO bank name should just be Tegra. The Tegra TRM specifies a
 single
 GPIO controller, in the address map etc., and there should be a single
 U-Boot object that represents it.  Really the phrase bank in U-Boot
 needs
 to be replaced with controller.


 But that would change the meaning - at present a GPIO device in U-Boot
 is a GPIO bank.


 So just define the Tegra GPIO controller as having a single bank. The fact
 that U-Boot and Tegra both chose the word bank to mean different things
 doesn't mean that the U-Boot term has to be forced to apply to Tegra where
 the documentation talks about a bank.

 I don't think bank is a good description or level of abstraction anyway;
 U-Boot should use the term controller, chip, or module (which would
 apply to an entire HW module or GPIO expander chip), since bank is
 usually an internal implementation detail rather than something the user
 cares about. Put another way: all banks in a controller/chip/module/...
 would typically use the same operation/op/callback functions, just with
 different GPIO IDs or per-GPIO data, whereas different
 controllers/chips/modules/... would use different operation/op/callback
 functions. It therefore makes much more sense to abstract at the level of
 controller/chip/module/... rather than bank level, which is an internal
 implementation detail.


Are you saying that 'bank' should be renamed 'chip' and then you would be
happy? Or are you still talking about a separate level of data structure?



  Within that bank there can be

 several individual GPIO lines. This is what the Tegra TRM refers to as
 A0, A1, B0, B1, etc.



 While the TRM does use the phrase bank, I believe this is just a
 collision
 with the term

Re: [U-Boot] [PATCH v2 7/8] Makefile: default to cc for host compiler

2014-07-31 Thread Masahiro Yamada

Hi Jeroen,


On Wed, 30 Jul 2014 21:54:55 +0200
Jeroen Hofstee jer...@myspectrum.nl wrote:

 Since the host compiler might not be gcc but e.g. clang
 default to cc to invoke it.
 
 cc: Masahiro Yamada yamad...@jp.panasonic.com
 cc: Tom Rini tr...@ti.com
 Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl
 ---
  Makefile | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/Makefile b/Makefile
 index 80eb239..c19f7d9 100644
 --- a/Makefile
 +++ b/Makefile
 @@ -204,7 +204,7 @@ CONFIG_SHELL := $(shell if [ -x $$BASH ]; then echo 
 $$BASH; \
 else if [ -x /bin/bash ]; then echo /bin/bash; \
 else echo sh; fi ; fi)
  
 -HOSTCC   = gcc
 +HOSTCC   = cc
  HOSTCXX  = g++
  HOSTCFLAGS   = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer
  HOSTCXXFLAGS = -O2



For consistency,

HOSTCXX = c++

?


Kconfig has a C++ host program.
(scripts/kconfig/qconf.cc)



Could you please consider posting this patch to
linux-kbuild ML  because this may be,
I think, acceptable in Linux too.

On systems where both gcc and clang are installed,
we can select gcc or clang
by using update-alternatives (or alternative)
command.





Best Regards
Masahiro Yamada

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

[U-Boot] [U-boot] the first 0x20 bytes in u-boot.bin

2014-07-31 Thread TigerLiu

Hi, Albert:

I am studying 2014.07 release u-boot package.

I found u-boot.bin's first bytes were not code in start.S .

Taken for compling smdkv310 as an example:

The compiled u-boot.bin's first 0x20 bytes were:

18 F0 9F E5 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5

18 F0 9F E5 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5

..

 

So, Is it equal to ldr pc, [pc,#0x18] ?

 

Best wishes,

___
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

2014-07-31 Thread Ian Campbell

On Wed, 2014-07-30 at 16:37 -0600, Stephen Warren wrote:
 From: Dennis Gilmore den...@ausil.us
 
 This generic $bootcmd, and associated support macros, automatically
 searches a defined set of storage devices (or network protocols) for an
 extlinux configuration file or U-Boot boot script in various standardized
 locations. Distros that install such a boot config file/script in those
 standard locations will get easy-to-set-up booting on HW that enables
 this generic $bootcmd.

From a distro PoV this is awesome, thanks!

Are you planning to convert any more platforms during this merge window?
Hans  I would really like to see sunxi switch this time around, before
it gets more widely used (since v2014.10 will support loads more
platforms).

I'm AFK after today but Hans has offered to try and whip something up
ASAP.

Cheers,
Ian.

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

[U-Boot] [PATCH 3/3] cm-t54: convert to generic board

Use generic board setup functions by defining
CONFIG_SYS_GENERIC_BOARD.

Signed-off-by: Dmitry Lifshitz lifsh...@compulab.co.il
---
 include/configs/cm_t54.h |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/include/configs/cm_t54.h b/include/configs/cm_t54.h
index db04095..df93a59 100644
--- a/include/configs/cm_t54.h
+++ b/include/configs/cm_t54.h
@@ -19,6 +19,9 @@
 #undef CONFIG_MISC_INIT_R
 #undef CONFIG_SPL_OS_BOOT
 
+/* Enable Generic board */
+#define CONFIG_SYS_GENERIC_BOARD
+
 /* Device Tree defines */
 #define CONFIG_OF_LIBFDT
 #define CONFIG_OF_BOARD_SETUP
-- 
1.7.5.4

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

[U-Boot] [PATCH 0/3] cm-t54: misc board fixes, convert to generic board

Fix MAC address data read (from EEPROM) issue and boot mode check.
Convert to generic board.

Dmitry Lifshitz (3):
  cm-t54: fix EEPROM read return value check
  cm-t54: fix eMMC boot mode check
  cm-t54: convert to generic board

 board/compulab/cm_t54/cm_t54.c |6 +++---
 include/configs/cm_t54.h   |3 +++
 2 files changed, 6 insertions(+), 3 deletions(-)

-- 
1.7.5.4

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

[U-Boot] [PATCH 1/3] cm-t54: fix EEPROM read return value check

Fix cl_eeprom_read_mac_addr() return value check.
Fix long line codding style issue in board_init().

Signed-off-by: Dmitry Lifshitz lifsh...@compulab.co.il
---
 board/compulab/cm_t54/cm_t54.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/board/compulab/cm_t54/cm_t54.c b/board/compulab/cm_t54/cm_t54.c
index fadfddc..306491b 100644
--- a/board/compulab/cm_t54/cm_t54.c
+++ b/board/compulab/cm_t54/cm_t54.c
@@ -43,7 +43,7 @@ const struct omap_sysinfo sysinfo = {
  */
 int board_init(void)
 {
-   gd-bd-bi_boot_params = (CONFIG_SYS_SDRAM_BASE + 0x100); /* boot param 
addr */
+   gd-bd-bi_boot_params = (CONFIG_SYS_SDRAM_BASE + 0x100);
 
return 0;
 }
@@ -169,7 +169,7 @@ static int handle_mac_address(void)
return 0;
 
ret = cl_eeprom_read_mac_addr(enetaddr);
-   if (!ret || !is_valid_ether_addr(enetaddr))
+   if (ret || !is_valid_ether_addr(enetaddr))
generate_mac_addr(enetaddr);
 
if (!is_valid_ether_addr(enetaddr))
-- 
1.7.5.4

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

[U-Boot] [PATCH 2/3] cm-t54: fix eMMC boot mode check

Boot from eMMC boot partition corresponds to BOOT_DEVICE_MMC2
omap_bootmode, while BOOT_DEVICE_MMC2_2 corresponds to the user
data partition boot.

Fix mmc_get_env_part() boot mode check to use a correct value.

Signed-off-by: Dmitry Lifshitz lifsh...@compulab.co.il
---
 board/compulab/cm_t54/cm_t54.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/board/compulab/cm_t54/cm_t54.c b/board/compulab/cm_t54/cm_t54.c
index 306491b..944b723 100644
--- a/board/compulab/cm_t54/cm_t54.c
+++ b/board/compulab/cm_t54/cm_t54.c
@@ -89,7 +89,7 @@ uint mmc_get_env_part(struct mmc *mmc)
 * If booted from eMMC boot partition then force eMMC
 * FIRST boot partition to be env storage
 */
-   if (bootmode == BOOT_DEVICE_MMC2_2)
+   if (bootmode == BOOT_DEVICE_MMC2)
bootpart = 1;
 
return bootpart;
-- 
1.7.5.4

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

Re: [U-Boot] [PATCH v8 07/13] tools: add genboardscfg.py

2014-07-31 Thread Tom Rini

On Thu, Jul 31, 2014 at 11:22:05AM +0900, Masahiro Yamada wrote:
 Hi Tom,
 
 
 On Wed, 30 Jul 2014 10:07:19 -0400
 Tom Rini tr...@ti.com wrote:
 
  On Wed, Jul 30, 2014 at 02:08:19PM +0900, Masahiro Yamada wrote:
  
   Now the primary data for each board is in Kconfig, defconfig and
   MAINTAINERS.
   
   It is true boards.cfg is needed for MAKEALL and buildman and might be
   useful to brouse all the supported boards in a single database.
   But it would be painful to maintain the boards.cfg in sync.
   
   So, this is the solution.
   Add a tool to generate the equivalent boards.cfg file based on
   the latest Kconfig, defconfig and MAINTAINERS.
   
   We can keep all the functions of MAKEALL and buildman with it.
   
   The best thing would be to change MAKEALL and buildman for not
   depending on boards.cfg in the future, but it would take some time.
  [snip]
   +def get_make_cmd():
   +Get the command name of GNU Make.
   +try:
   +make_cmd = subprocess.check_output([SHOW_GNU_MAKE])
   +except subprocess.CalledProcessError:
   +print  sys.stderr, 'GNU Make not found'
   +sys.exit(1)
   +return make_cmd.rstrip()
  
  So subprocess.check_output comes from Python 2.7 and Ubuntu 10.04 ships
  with 2.6.  This isn't a deal-breaker as I'm working on updating the two
  calls here now (and we'll set aside mailmapper, that's not going to be
  commonly used I think).
 
 
 
 BTW, Ubuntu 10.04 is now being supported only for Server.

Yeah.  IT counts build servers as Server not Desktop so I've got access
to some beefy build resources that're on that (and staying there for
some time to come). :)

-- 
Tom


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

Re: [U-Boot] [U-boot] the first 0x20 bytes in u-boot.bin

2014-07-31 Thread Jon Loeliger

On Thu, Jul 31, 2014 at 5:24 AM,  tiger...@via-alliance.com wrote:
 Hi, Albert:

 I am studying 2014.07 release u-boot package.

 I found u-boot.bin's first bytes were not code in start.S .

 Taken for compling smdkv310 as an example:

 The compiled u-boot.bin's first 0x20 bytes were:

 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5

 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5

 ..



 So, Is it equal to ldr pc, [pc,#0x18] ?

Hard to say.  Perhaps.

You should study the linker script (*.lds) for this board.
It is likely that the code you are seeing is the reset vector.

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

Re: [U-Boot] [U-boot] the first 0x20 bytes in u-boot.bin

2014-07-31 Thread Christian Riesch

Hi,

On Thu, Jul 31, 2014 at 12:24 PM,  tiger...@via-alliance.com wrote:
 Hi, Albert:

 I am studying 2014.07 release u-boot package.

 I found u-boot.bin's first bytes were not code in start.S .

For ARM processors, it's in arch/arm/lib/vectors.S.

Regards,
Christian


 Taken for compling smdkv310 as an example:

 The compiled u-boot.bin's first 0x20 bytes were:

 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5

 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5

 ..



 So, Is it equal to ldr pc, [pc,#0x18] ?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] kconfig: Fix compiler warning in menu.c

This fixes the following compiler warning:

In file included from scripts/kconfig/zconf.tab.c:2537:0:
scripts/kconfig/menu.c: In function ‘get_symbol_str’:
scripts/kconfig/menu.c:590:18: warning: ‘jump’ may be used uninitialized in 
this function [-Wmaybe-uninitialized]
 jump-offset = strlen(r-s);
  ^
In file included from scripts/kconfig/zconf.tab.c:2537:0:
scripts/kconfig/menu.c:551:19: note: ‘jump’ was declared here
  struct jump_key *jump;

Signed-off-by: Hans de Goede hdego...@redhat.com
---
 scripts/kconfig/menu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c
index a26cc5d..584e0fc 100644
--- a/scripts/kconfig/menu.c
+++ b/scripts/kconfig/menu.c
@@ -548,7 +548,7 @@ static void get_prompt_str(struct gstr *r, struct property 
*prop,
 {
int i, j;
struct menu *submenu[8], *menu, *location = NULL;
-   struct jump_key *jump;
+   struct jump_key *jump = NULL;
 
str_printf(r, _(Prompt: %s\n), _(prop-text));
menu = prop-menu-parent;
-- 
2.0.3

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

[U-Boot] Setting Uboot environment variables from within Linux

2014-07-31 Thread Rossco

Hi,

I have an issue when attempting to access my uboot variables from within my
linux distribution.

My set-up is as follows...

Cyclone V SoC with ARM Cortex A9 processor running 3.11 kernel (git revision
a946a64), uboot version 2013.01.01 - only modification being to configure
for QSPI boot and to add some extra environment variables.

I am running a QSPI boot configuration, my QSPI has three partitions...
1. Raw partition containing Pre-loader, device-tree and uboot
2. Kernel1 - containing initial kernel
3. Kernel2 - for future updated kernel

I have a NAND device offering UBI filesystem.

I created the fw_printenv and exported to my development board, created sym
link to create fw_setenv. Also copied across the fw_env.config which looks
like this (I have not modified this)...

# NOR example
# MTD device name Device offset Env. size Flash sector size
/dev/mtd1 0x 0x4000 0x4000
/dev/mtd2 0x 0x4000 0x4000

# MTD SPI-dataflash example
# MTD device name Device offset Env. size Flash sector size
#/dev/mtd5 0x4200 0x4200
#/dev/mtd6 0x4200 0x4200

# NAND example
#/dev/mtd0 0x4000 0x4000 0x2

cat /proc/mtd look like...
dev:size erasesize name
mtd0: 4000 0004 denali-nand
mtd1: 0080 0001 Flash 0 Raw Data
mtd2: 0190 0001 Kernel Partition 1
mtd3: 0190 0001 Kernel Partition 2

When I attempt to run fw_printenv I get the following error message..
Warning: Bad CRC, using default environment

I'm assuming that my config file is wrong but I'm not sure how to change it.
Do I need to manually workout where the environment variables are being
stored? Should I have a separate environment variables image? If so how do I
get that image?

Any guidance greatly appreciated :-)

Thanks

Rossco

--
View this message in context:
http://u-boot.10912.n7.nabble.com/Setting-Uboot-environment-variables-from-within-Linux-tp185482.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Please pull u-boot-sunxi.git/master

Hi,

On 07/31/2014 10:23 AM, Masahiro Yamada wrote:
 Hi Ian, Hans,
 
 
 On Thu, 31 Jul 2014 08:54:09 +0100
 Ian Campbell i...@hellion.org.uk wrote:
 
 On Thu, 2014-07-31 at 13:30 +0900, Masahiro Yamada wrote:
 Hi Tom, Albert, Hans,


 I am afraid we are going to be in trouble
 with this pre-Kconfig based PR
 because it includes various new boards.

 Yeah, I was wondering how this would work!

 (We can fix the merge conflict,
 but it is not trivial.)


 How this is going to work?

 Perhaps should we discard unmerged PRs and
 get all the subsystem repos
 synchronized with u-boot/master ?


 Or shall we break these boards once
 and fix them in a follow-up patch ?

 Can you point us to the conversion script please?
 
 
 Sure.
 
 These are the conversion tools I used in my series:
 
 http://patchwork.ozlabs.org/patch/374412/
for generating *_defconfig and Kconfig
 
 http://patchwork.ozlabs.org/patch/374406/
for generating MAINTAINERS
 
 
 I assume you have boards.cfg on your local branch.
 
 If you run 'tools/genkconfig' and 'tools/gen_maintainers.py',
 *_defconfig, Kconfig, and MAINTAINERS will be generated
 for all the boards listed in the boards.cfg file.
 
 And then commit --amend the diffs of *_defconfig, Kconfig, MAINTAINERS.

Thanks,

I've rebased the u-boot-sunxi master  next branches (which are in
sync arm) on top of u-boot/master, using the above method.

I've also run some quick tests (and a MAKEALL) and everything still
seems to work fine, one new pull-req coming up.

Regards,

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

[U-Boot] Please pull u-boot-sunxi.git/master

Hi Albert

Note:

1) This superseeds my previous pull-req as that conflicted with the Kconfig 
changes
which have landed in u-boot/master, this pull-req replaces all the boards.cfg 
changes
from the previous series with defconfig changes / additions;

2) Since this new pull-req is intended to resolve conflicts with u-boot/master 
it
is based on u-boot/master rather then on u-boot-arm/master.

Please pull from u-boot-sunxi.git/master for a set of patches adding
AHCI, EHCI, PSCI support + support for 14 new boards.

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:

  http://git.denx.de/u-boot-sunxi.git master

for you to fetch changes up to 3340eab26d89176dd0bf543e6d2590665c577423:

  sun7i: Add bananapi board (2014-07-31 15:37:24 +0200)


Hans de Goede (8):
  sun4i: add USB EHCI settings
  sun5i: add USB EHCI settings
  sunxi: Enable EHCI on various sunxi boards
  sunxi: Add CONFIG_MACPWR option
  sun4i: Add support for a number of new sun4i boards
  sun5i: Add support for a number of new sun5i boards
  sun7i: Add support for a number of new sun7i boards
  sun7i: Add bananapi board

Ian Campbell (2):
  ahci: provide sunxi SATA driver using AHCI platform framework
  cubieboard2: Enable AXP209 power controller

Marc Zyngier (2):
  sunxi: HYP/non-sec: add sun7i PSCI backend
  sunxi: HYP/non-sec: configure CNTFRQ on all CPUs

Roman Byshko (5):
  sunxi: add defines to control USB Host clocks/resets
  sunxi: add USB EHCI driver
  sunxi: add general USB settings
  sun7i: add USB EHCI settings
  sun7i: cubietruck: enable USB EHCI

 arch/arm/cpu/armv7/sunxi/Makefile |   3 +
 arch/arm/cpu/armv7/sunxi/board.c  |   5 +
 arch/arm/cpu/armv7/sunxi/clock_sun4i.c|   4 +
 arch/arm/cpu/armv7/sunxi/psci.S   | 162 +
 arch/arm/include/asm/arch-sunxi/clock_sun4i.h |  15 +-
 board/sunxi/MAINTAINERS   |  19 ++-
 board/sunxi/Makefile  |  16 ++
 board/sunxi/ahci.c|  84 +++
 board/sunxi/dram_a10_olinuxino_l.c|  31 
 board/sunxi/dram_a10s_olinuxino_m.c   |  31 
 board/sunxi/dram_a13_olinuxino.c  |  31 
 board/sunxi/dram_bananapi.c   |  31 
 board/sunxi/dram_linksprite_pcduino3.c|  31 
 board/sunxi/dram_sun4i_360_1024_iow16.c   |  31 
 board/sunxi/dram_sun4i_360_1024_iow8.c|  31 
 board/sunxi/dram_sun4i_360_512.c  |  31 
 board/sunxi/dram_sun4i_384_1024_iow8.c|  31 
 board/sunxi/dram_sun7i_384_1024_iow16.c   |  31 
 board/sunxi/dram_sun7i_384_512_busw16_iow16.c |  31 
 configs/A10-OLinuXino-Lime_defconfig  |   4 +
 configs/A10s-OLinuXino-M_defconfig|   4 +
 configs/A13-OLinuXinoM_defconfig  |   2 +-
 configs/A13-OLinuXino_defconfig   |   4 +
 configs/A20-OLinuXino_MICRO_defconfig |   4 +
 configs/Auxtek-T004_defconfig |   4 +
 configs/Bananapi_defconfig|   4 +
 configs/Cubieboard2_FEL_defconfig |   2 +-
 configs/Cubieboard2_defconfig |   2 +-
 configs/Cubieboard_defconfig  |   2 +-
 configs/Cubietruck_FEL_defconfig  |   2 +-
 configs/Cubietruck_defconfig  |   2 +-
 configs/Linksprite_pcDuino3_defconfig |   4 +
 configs/Mele_A1000G_defconfig |   4 +
 configs/Mele_A1000_defconfig  |   4 +
 configs/Mini-X-1Gb_defconfig  |   4 +
 configs/Mini-X_defconfig  |   4 +
 configs/ba10_tv_box_defconfig |   4 +
 configs/i12-tvbox_defconfig   |   4 +
 configs/qt840a_defconfig  |   4 +
 configs/r7-tv-dongle_defconfig|   2 +-
 drivers/block/ahci.c  |  16 ++
 drivers/usb/host/Makefile |   1 +
 drivers/usb/host/ehci-sunxi.c | 201 ++
 include/ahci.h|   4 +
 include/configs/sun4i.h   |  12 ++
 include/configs/sun5i.h   |   5 +
 include/configs/sun7i.h   |  19 +++
 include/configs/sunxi-common.h|  18 +++
 48 files changed, 982 insertions(+), 13 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/sunxi/psci.S
 create mode 100644 board/sunxi/ahci.c
 create mode 100644 board/sunxi/dram_a10_olinuxino_l.c
 create mode 100644 board/sunxi/dram_a10s_olinuxino_m.c
 create mode 100644 board/sunxi/dram_a13_olinuxino.c
 create mode 100644 board/sunxi/dram_bananapi.c
 create mode 100644

Re: [U-Boot] Quick guide to Kconfig