Re: [U-Boot] Regarding u-boot patch about accurate boot time measurement

[Abdullah Yıldız]

Hi,

On Tue, Feb 18, 2014 at 12:16 AM, Simon Glass  wrote:
> Hi,
>
> On 17 February 2014 05:07,
abdullah

 Yıldız  wrote:
>> Hi Albert,
>>
>> On Mon, Feb 17, 2014 at 1:58 PM, Albert ARIBAUD
>>  wrote:
>>> Hi Abdullah,
>>>
>>> On Mon, 17 Feb 2014 13:10:52 +0200, Abdullah Yıldız
>>>  wrote:
>>>
 Hi Simon,

 On Mon, Feb 17, 2014 at 1:03 AM, Simon Glass  wrote:
 > Hi Abdullah,
 >
 > On 16 February 2014 15:38, Abdullah Yıldız  
 > wrote:
 >> Dear Glass,
 >>
 >> I've fount this
 >> http://lists.denx.de/pipermail/u-boot/2011-May/092584.html while
 >> searching about boot time measurement methods in u-boot. However, I
 >> couldn't find a patch file regarding your post. Could you help me with
 >> this about where to find the patch?
 >
 > This was merged into U-Boot in early 2012, so you don't need a patch.
 > See bootstage.h for the API.
 >
 > Regards,
 > Simon
 >
 > --

 Adding CONFIG_BOOTSTAGE option and then make didn't work.
>>>
>>> Can you give more detail, e.g. what exactly is the commit you're
>>> trying to build, what is the command line, and what is the error
>>> message?
>>>
>>> Amicalement,
>>> --
>>> Albert.
>>>
>>> --
>>
>> I'm working on u-boot version 2014-01.
>>
>> Actually, there is no error message, u-boot runs without any timestamp.
>
> bootstage is a way of measuring boot time and progress - what sort of
> timestamp are you looking for?
>
> Regards,
> Simon
>
> --

bootstage is exactly what I'm looking for. Is it enough to define
#define CONFIG_BOOTSTAGE to build u-boot with timestamping?

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

Re: [U-Boot] [PATCH v8 0/38] Switch over to real Kbuild

[Masahiro Yamada]

Hello Simon,


> 
> I'm not sure whether to start a new thread or not, but here in one
> observations which might be useful.
> 
> With current master, a 'null' build (with nothing changed) takes about
> 5s for me.
> 
> time 
> CROSS_COMPILE=/opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.8-2013.08_linux/bin/arm
> -linux-gnueabihf- ARCH=arm make -j1
> real 0m4.978s
> user 0m1.144s
> sys 0m0.360s
> 
> 
> With the kbuild series, it takes a lot longer:
> 
> real 0m46.600s
> user 0m17.628s
> sys 0m8.664s

Thanks for your feedback.

Hmm, Kbuild is 9 times slower on your computer.
This is a big difference. (It was about 1.6 x slower on my box.)

I don't know where such a difference came from.

> There seem to be noticeable pauses between things happening. I'm not
> quite sure how to dig into it more. Is it possible that cc-option is
> no-longer caching the various compiler options?

I guess it's possible.

Is sandbox build slow as well?
Sandbox has no cc-option.
If cc-option is the cause of pauses, sandbox build
should be faster.

Anyway, evaluating cc-option multiple times isn't nice
and its optimization is on my TODO list.

Historically, U-Boot has included all
config.mk (arch/*/config.mk and board/*/config.mk)
every time descending into subdirectories.
That means cc-options are evaluated over and over again.
Caching cc-option is one of work arounds, but we should not
revive it.

What we should do is to include arch/*/config.mk and board/*/config.mk
only once at the top Makefile and export options.


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 v2 1/3] dts: re-write dts/Makefile more simply with Kbuild

[Masahiro Yamada]

Hello Simon,



> > Useful rules in scripts/Makefile.lib allows us to easily
> > generate a device tree blob and wrap it in assembly code.
> >
> > We do not need to parse a linker script to get output format and arch.
> >
> > This commit deletes ./u-boot.dtb since it is a copy of dts/dt.dtb
> 
> I'd rather have the former and delete the latter temporary file as
> part of the build. u-boot.dtb is currently a build output.


This is what I have said in the thread
Re: [PATCH] dts: re-write dts/Makefile more simply with Kbuild

We must keep dts/dt.dtb to suppress the re-generation of dts/dt.dtb.

Besides,  dts/dt.dtb is a prerequisite of dts/dt.dtb.S 
when CONFIG_OF_EMBED is enabled.

I believe keeping dts/dt.dtb is reasonable enough.

Better to keep both?


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] dts: re-write dts/Makefile more simply with Kbuild

[Masahiro Yamada]

Hello Simon,


> 
> >   - dts/dt.dtb
> 
> This is a temporary file, probably deleted during the build. 

No.
It is a temporary file, but it must not be deleted during the build.
Otherwise, dts/dt.dtb will be re-generated at every build
even when it shouldn't.

> I'm not
> even sure if it is created when you are building multiple files.
> Perhaps it use just used for CONFIG_OF_EMBED?

My patch is using dts/dt.dtb for both CONFIG_OF_EMBED and
CONFIG_OF_SEPARTE.

If you don't want to generate dts/dt.dtb at all,
most of  lines in dts/Makefile must be moved to the top Makefile,
which leads we get the top Makefile fatter and dirtier.


> >   - ./u-boot.dtb
> >
> > But, if you really need a DTB at the top directory,
> > I can revive u-boot.dtb at version 3.
> 
> For now I think there is a 'default' .dtb for each board config. After
> all U-Boot does not have a way to select between several of them at
> runtime. So it makes sense for this one to be made available as it
> currently is I think. Perhaps it could be a symlink to the real one?

Creating a symbolic link during the build is generally
troublesome and a bad idea, I think.


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 v2 2/3] dts: move device tree sources to arch/$(ARCH)/dts/

[Masahiro Yamada]

Hello Simon,


> >>
> >> On 4 February 2014 02:38, Masahiro Yamada  
> >> wrote:
> >> > Unlike Linux Kernel, U-Boot historically had *.dts files under
> >> > board/$(VENDOR)/dts/ and *.dtsi files under arch/$(ARCH)/dts/.
> >> >
> >> > I think arch/$(ARCH)/dts dicretory is a better location
> >> > to store both *.dts and *.dtsi files.
> >> >
> >> > For example, before this commit, board/xilinx/dts directory
> >> > had both MicroBlaze dts (microblaze-generic.dts) and
> >> > ARM dts (zynq-*.dts), which are totally unrelated.
> >> >
> >> > This commit moves *.dts to arch/$(ARCH)/dts/ directories,
> >> > allowing us to describe nicely mutiple DTBs generation in the next 
> >> > commit.
> >>
> >> What is the motivation for this? I worry that we might end up with a
> >> lot of files in one directory.
> >
> > We have only 35 .dtsi and .dts for ARM.
> > I think it will be OK at least until we have 500.
> >
> > Linux v3.13 has 500 .dtsi and .dts files in arch/arm/boot/dts/
> > and they are still adding device trees to that directory.
> >
> > I have no idea if they will keep going, or someone will scream and turn
> > around.
> >
> > Anyway, when Linux guys someday invents a nice idea to work arond
> > increasing device trees, we can import it to U-Boot.
> > It should be easy for us because we already have a similar build system.
> 
> Hmm, but would it be such a big problem to keep the general ARM and
> SOC stuff in arch/arm/dts and the board-specific stuff in board/ ?
> One of the problems with Linux is that their board-specific code is
> spread all over the place, and I'm not sure we want to emulate it?

Opposite.
Board-specific code mostly resides under
arch/arm/mach-* or arch/arm/plat-*.
And what else is arch/arm/configs and arch/arm/boot/dts. That's it.


We have board-specific part
 - entries in boards.cfg
 - include/configs/.h
 - board// or board/
 - arch//include/am/arch- includes sometimes
   board-specific headers  as well as SoC specific headers.
   (Because there is no other place to store board-specific header files)

Various stuff under include/, for exmple
  - include/xilinx.h:  vendor specific?
  - include/sandboxblockdev.h:  arch specific?

And we often missed to remove remainders of dead boards.

U-Boot has more troublesome directory structure.


> >> One benefit of the current approach is
> >> that .dts files are split up by vendor. Even if we put the SoC .dtsi
> >> files in arch/arm, perhaps there is a benefit in leaving the board
> >> .dts files in board/?
> >
> > I don't like the idea to split up by vendor.
> >
> > Now Xilinx has device trees both for ARM and Microblaze,
> > resulting in totally unrelated device trees in one directory.
> 
> Shouldn't the SoC part go in arch/arm and arch/microblaze? Then just
> the board-specific stuff can go in board/

What is SoC part? What is Board part?

> >
> > What if Freescale decided to adopt device tree?
> > They support various boards on ARM, PowerPC, M68K.
> >
> > Renesus is the same. They have ARM and SuperH boards.
> 
> I'm not convinced yet. I think maybe you have forgotten about the
> .dtsi files for SoCs. They are common, but no one is going to include
> a board .dts file (nor can they), so putting them in a common area
> does not seem like a win to me.

I do know that *.dtsi files are included from others, while
*.dts files are not included from anywhere.
And I understand your policy, *.dtsi to arch dir and *.dts to vendor dir.
(No that I care, we have two exceptions:
./board/avionic-design/dts/tegra20-tamonten.dtsi
./board/avionic-design/dts/tegra30-tamonten.dtsi)

If I have to mention a win,
we can save makefiles by not putting almost same ones in
vendor directories.


Anyway, we have 3 structures proposed so far.

[1] board/$(VENDOR)/dts/  (current structure)
[2] arch/$(ARCH)/dts/  (suggested by me)
[3] dts/  for all architectures (suggested by Scott)

In my option, [2] and [3] seem to be reasonable enough.

If we cannot reach an agreement,
shall we postpone 2/3 and 3/3 and apply only 1/3?


> > On the other hand, different vendors can produce similar boards.
> > For example avionic design, which develops Tegra boards,
> > are using nVidia's sources.
> >
> > When I saw  board/nvidia/common/common.mk
> > and board/avionic-design/*/Makefile, etc., I think we're screwed up
> > with  directory.
> 
> Well the probably as I see it is that board/nvidia has some SoC code
> that other boards want to use. The solution to that might be to move
> the code to arch/arm/cpu/armv7/tegra... instead?

Concerning the result, board/nvidia/common turned out to be
SoC-specific code, not Vendor-specific (board-specific) code.

But I guess the difference between SoC-specific code and board-specific
code was not clear when nVidia develpers posted that code first.

Maybe I am digressing, but it also happens to me quite often.
It is difficult for me to decide whether each code should
go to board/panasonic or arch/arm/cpu/armv7/uniphier.

I'd say, vendor (and board) direc

Re: [U-Boot] u-boot - timestamp

[TigerLiu]

Hi, Denk:
Thanks a lot!
I have tried it, and it seemed wonderful!
Its mechanism is:
Using host pc's time stamp to tag the kermit's every output msg line,
right?

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

[U-Boot] pre-compiled ARC gcc

[Masahiro Yamada]

Hello Alexey,

Can I download ARC gcc from somewhere?
I prefer a pre-built one.
I want to build all boards over all architectures.

Best Regards
Masahiro Yamada

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

Re: [U-Boot] RFC unified boot environment

[Stefano Babic]

Hi Dennis,

On 17/02/2014 18:56, Dennis Gilmore wrote:
> Hi All,
> 
> The attached patches build on the work for generic distro config, as well as
> Stephen Warrens implementation for tegra.
> 

First, thanks to make order on this issue.

> I have added a header to be included that will allow all boards to boot in the
> same way and I have ported over two boards to use it. One thought I have had
> is to move the environment into the same header as the generic config. 

I think this is currently the best solution.

> 
> I am also working on writing a README.distro file to document everything that
> needs to be set for everything to just work. Along with information on how to
> best choose memory locations. 


Ok, let's see. This seems quite board-depending, I do not know if we
find a common solution. But we can find an agreement about a generic set
of variables/scripts, that all boards can reuse.

Regards,
Stefano


-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] endian dependency fix

[Masahiro Yamada]

Hi Yoshinori,

You should read the patch submission rules
(http://www.denx.de/wiki/U-Boot/Patches)
before posting patches.

 - Use the imperative tense in your summary line

  I mean, "fix blah blah" rather than "blah blah fix"


 - If applicable, prefix the summary line with a word describing what
area of code is being affected followed by a colon.

  In this case,  "mmc: ..."

  Ditto in your MS7206SE series.


Best Regards
Masahiro Yamada

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

Re: [U-Boot] pre-compiled ARC gcc

[Alexey Brodkin]

Hello Masahiro-san,

On Tue, 2014-02-18 at 19:04 +0900, Masahiro Yamada wrote:
> Hello Alexey,
> 
> Can I download ARC gcc from somewhere?
> I prefer a pre-built one.
> I want to build all boards over all architectures.

Indeed there're pre-built versions of tools for ARC.
Please look here:
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/tag/arc-4.8-R2

There're separate tarballs for:
1. Elf32 and uClibc
2. For Debian/Ubuntu and RedHat/Fedora/CentOS
3. Little- and big-endian targets

You need only uClibc tools.

So for Debian/Ubuntu host you need following.
Little-endian toolchain:
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/download/arc-4.8-R2/arc_gnu_4.8-R2_prebuilt_uclibc_le_ubuntu_install.tar.gz

Big-endian toolchain:
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/download/arc-4.8-R2/arc_gnu_4.8-R2_prebuilt_uclibc_be_ubuntu_install.tar.gz


So for RedHat-based host you need following.
Little-endian toolchain: 
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/download/arc-4.8-R2/arc_gnu_4.8-R2_prebuilt_uclibc_le_rhel6_install.tar.gz

Big-endian toolchain:
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/download/arc-4.8-R2/arc_gnu_4.8-R2_prebuilt_uclibc_be_rhel6_install.tar.gz

Just extract corresponding tarball anywhere on your hos and add path to
"bin/" folder in your PATH env var.

Also you'll need to set ARCH env var to "arc".

Regards,
Alexey




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

[U-Boot] [PATCH] arc: fix relocation for big-endian target

[Alexey Brodkin]

In case of little-endian ARC700 instructions (which may include target
address) are encoded as middle-endian. That's why it's required to swap
bytes after read and ten right before write back.

But in case of big-endian ARC700 instructions are encoded as a plain
big-endian. Thus no need for byte swapping.

Signed-off-by: Alexey Brodkin 

Cc: Francois Bedard 
Cc: Tom Rini 
cc: Noam Camus 
---
 arch/arc/lib/relocate.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arc/lib/relocate.c b/arch/arc/lib/relocate.c
index 956aa14..2482bcd 100644
--- a/arch/arc/lib/relocate.c
+++ b/arch/arc/lib/relocate.c
@@ -41,19 +41,23 @@ int do_elf_reloc_fixups(void)
 */
memcpy(&val, offset_ptr_ram, sizeof(int));
 
+#ifdef __LITTLE_ENDIAN__
/* If location in ".text" section swap value */
if ((unsigned int)offset_ptr_rom <
(unsigned int)&__text_end)
val = (val << 16) | (val >> 16);
+#endif
 
/* Check that the target points into .text */
if (val >= CONFIG_SYS_TEXT_BASE && val <=
(unsigned int)&__bss_end) {
val += gd->reloc_off;
+#ifdef __LITTLE_ENDIAN__
/* If location in ".text" section swap value */
if ((unsigned int)offset_ptr_rom <
(unsigned int)&__text_end)
val = (val << 16) | (val >> 16);
+#endif
memcpy(offset_ptr_ram, &val, sizeof(int));
} else {
debug("   %p: rom reloc %x, ram %p, value %x, 
limit %x\n",
-- 
1.8.5.3

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

Re: [U-Boot] booting i.mx6

[Christian Gmeiner]

2014-02-18 8:35 GMT+01:00 JYOTI DUBEY :
> While launching the imx_usb script with a u-boot.imx, I've got the
> following message error :
> config file <./imx_usb.conf>
> main:Could not open device vid=0x15a2 pid=0x54 err=-3
>
> I gave many tries to correct it. Can some body help me to rectify the above
> error?
>

Do you see an freescale imx in recovery mode when doing an lsusb?

--
Christian Gmeiner, MSc

https://soundcloud.com/christian-gmeiner
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/7] usb: eth: introduce support for Moschip USB ethernet

[Marek Vasut]

Hello Wolfgang,

> Dear Marek,
> 
> In message <20140217.38911.ma...@denx.de> you wrote:
> > > > +#define PHY_CMD1_READ  BIT(6)
> > > > +#define PHY_CMD1_WRITE BIT(5)
> > > > +#define PHY_CMD1_PHYADDR   BIT(0)
> > > > +
> > > > +#define PHY_CMD2_PEND  BIT(7)
> > > > +#define PHY_CMD2_READY BIT(6)
> > > 
> > > ...
> > > 
> > > As mentioned in patch # 1, I object against the use of these
> > > obfuscating BIT() macros.  Please do not use these; use plain
> > > readable code, that leaves no ambiguities to the reader.
> > 
> > Just to chime in real quick, Linux uses these 'BIT()' macros, but I
> > personally have no hard feelings about them either way.
> 
> Yes, certain developers have been using this style before.  This does
> not make it any better.  Fact is, that I have no way to tell what the
> code means.  BIT(0) can be expected to have any of the following
> meanings: 0x01, 0x80, 0x8000, 0x8000, ... So I always have to look
> up the macro definition first, before I can unerstand it.  And then I
> have to compute in my head what the number actually means.
> 
> Compare: BIT(6) or 0x40 - what is easier to write, to read, and to
> understand?

(1 << 6) is easier for me to read honestly, because then I can quickly 
crosscheck it with the datasheet.

> You dump a register - either with the BDI, or with some printf().
> You get 0x27051956.  Is BIT(17) set?  Is bit 0x0002 set?
> Which of these questions is easier to answer (even when you are sure
> that this is on a system where bit no. 0 is the LSB)?

You have a point with the endianness here.

Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 02/10] ARM: AM43xx: clocks: Enable CPGMAC clock control

[Tom Rini]

From: Mugunthan V N 

Enable CPGMAC clock control for AM43xx to use ethernet in U-Boot

Signed-off-by: Mugunthan V N 
---
 arch/arm/cpu/armv7/am33xx/clock_am43xx.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/cpu/armv7/am33xx/clock_am43xx.c 
b/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
index 440cf8b..f0ef366 100644
--- a/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
+++ b/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
@@ -97,6 +97,7 @@ void enable_basic_clocks(void)
&cmper->gpio4clkctrl,
&cmper->gpio5clkctrl,
&cmper->i2c1clkctrl,
+   &cmper->cpgmac0clkctrl,
&cmper->emiffwclkctrl,
&cmper->emifclkctrl,
&cmper->otfaemifclkctrl,
-- 
1.7.9.5

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

[U-Boot] [PATCH 01/10] drivers: net: cpsw: add support to have phy address from cpsw platform data

[Tom Rini]

From: Mugunthan V N 

Some platforms like AM437x have different EVMs with different phy addresses,
so this patch adds support for passing phy address via cpsw plaform data.
Also renamed phy_id to phy_addr so better understanding of the code.

Reviewed-by: Felipe Balbi 
Signed-off-by: Mugunthan V N 
[trini: Update am335x_igep0033 pcm051_rev3 pcm051_rev1 cm_t335 boards]
Signed-off-by: Tom Rini 
---
 board/compulab/cm_t335/cm_t335.c  |2 +-
 board/isee/igep0033/board.c   |2 +-
 board/phytec/pcm051/board.c   |4 ++--
 board/siemens/dxr2/board.c|2 +-
 board/siemens/pxm2/board.c|4 ++--
 board/siemens/rut/board.c |4 ++--
 board/ti/am335x/board.c   |4 ++--
 board/ti/dra7xx/evm.c |4 ++--
 board/ti/ti814x/evm.c |4 ++--
 drivers/net/cpsw.c|4 ++--
 include/configs/am335x_evm.h  |1 -
 include/configs/am335x_igep0033.h |1 -
 include/configs/cm_t335.h |1 -
 include/configs/dra7xx_evm.h  |1 -
 include/configs/dxr2.h|1 -
 include/configs/pcm051.h  |1 -
 include/configs/pxm2.h|1 -
 include/configs/rut.h |1 -
 include/configs/ti814x_evm.h  |1 -
 include/cpsw.h|2 +-
 20 files changed, 18 insertions(+), 27 deletions(-)

diff --git a/board/compulab/cm_t335/cm_t335.c b/board/compulab/cm_t335/cm_t335.c
index 01019e8..9583149 100644
--- a/board/compulab/cm_t335/cm_t335.c
+++ b/board/compulab/cm_t335/cm_t335.c
@@ -47,7 +47,7 @@ static void cpsw_control(int enabled)
 static struct cpsw_slave_data cpsw_slave = {
.slave_reg_ofs  = 0x208,
.sliver_reg_ofs = 0xd80,
-   .phy_id = 0,
+   .phy_addr   = 0,
.phy_if = PHY_INTERFACE_MODE_RGMII,
 };
 
diff --git a/board/isee/igep0033/board.c b/board/isee/igep0033/board.c
index 089a835..9f8fcf2 100644
--- a/board/isee/igep0033/board.c
+++ b/board/isee/igep0033/board.c
@@ -116,7 +116,7 @@ static struct cpsw_slave_data cpsw_slaves[] = {
{
.slave_reg_ofs  = 0x208,
.sliver_reg_ofs = 0xd80,
-   .phy_id = 0,
+   .phy_addr   = 0,
.phy_if = PHY_INTERFACE_MODE_RMII,
},
 };
diff --git a/board/phytec/pcm051/board.c b/board/phytec/pcm051/board.c
index 7e5e07f..1071662 100644
--- a/board/phytec/pcm051/board.c
+++ b/board/phytec/pcm051/board.c
@@ -176,13 +176,13 @@ static struct cpsw_slave_data cpsw_slaves[] = {
{
.slave_reg_ofs  = 0x208,
.sliver_reg_ofs = 0xd80,
-   .phy_id = 0,
+   .phy_addr   = 0,
.phy_if = PHY_INTERFACE_MODE_RGMII,
},
{
.slave_reg_ofs  = 0x308,
.sliver_reg_ofs = 0xdc0,
-   .phy_id = 1,
+   .phy_addr   = 1,
.phy_if = PHY_INTERFACE_MODE_RGMII,
},
 };
diff --git a/board/siemens/dxr2/board.c b/board/siemens/dxr2/board.c
index 6c316fa..9b8f538 100644
--- a/board/siemens/dxr2/board.c
+++ b/board/siemens/dxr2/board.c
@@ -198,7 +198,7 @@ static struct cpsw_slave_data cpsw_slaves[] = {
{
.slave_reg_ofs  = 0x208,
.sliver_reg_ofs = 0xd80,
-   .phy_id = 0,
+   .phy_addr   = 0,
.phy_if = PHY_INTERFACE_MODE_MII,
},
 };
diff --git a/board/siemens/pxm2/board.c b/board/siemens/pxm2/board.c
index ef3d6cc..98083d5 100644
--- a/board/siemens/pxm2/board.c
+++ b/board/siemens/pxm2/board.c
@@ -181,13 +181,13 @@ static struct cpsw_slave_data cpsw_slaves[] = {
{
.slave_reg_ofs  = 0x208,
.sliver_reg_ofs = 0xd80,
-   .phy_id = 0,
+   .phy_addr   = 0,
.phy_if = PHY_INTERFACE_MODE_RMII,
},
{
.slave_reg_ofs  = 0x308,
.sliver_reg_ofs = 0xdc0,
-   .phy_id = 1,
+   .phy_addr   = 1,
.phy_if = PHY_INTERFACE_MODE_RMII,
},
 };
diff --git a/board/siemens/rut/board.c b/board/siemens/rut/board.c
index 25ab54d..e0ada3f 100644
--- a/board/siemens/rut/board.c
+++ b/board/siemens/rut/board.c
@@ -143,13 +143,13 @@ static struct cpsw_slave_data cpsw_slaves[] = {
{
.slave_reg_ofs  = 0x208,
.sliver_reg_ofs = 0xd80,
-   .phy_id = 1,
+   .phy_addr   = 1,
.phy_if = PHY_INTERFACE_MODE_RMII,
},
{
.slave_reg_ofs  = 0x308,
.sliver_reg_ofs = 0xdc0,
-   .phy_id = 0,
+   .phy_addr   = 0,
.phy_if = PHY_INTERFACE_MODE_RMII,
},
 };
diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index 5721768..862f9

[U-Boot] [PATCH 07/10] ARM: AM43xx: Add Ethernet boot support to SPL

[Tom Rini]

From: Mugunthan V N 

Add Ethernet Boot support to SPL

Acked-by: Tom Rini 
Signed-off-by: Mugunthan V N 
---
 board/ti/am43xx/board.c  |2 --
 include/configs/am43xx_evm.h |   10 --
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
index 7a28063..d744977 100644
--- a/board/ti/am43xx/board.c
+++ b/board/ti/am43xx/board.c
@@ -24,9 +24,7 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-#ifndef CONFIG_SPL_BUILD
 static struct ctrl_dev *cdev = (struct ctrl_dev *)CTRL_DEVICE_BASE;
-#endif
 
 /*
  * Read header information from EEPROM into global structure.
diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h
index 4476af5..dd70d39 100644
--- a/include/configs/am43xx_evm.h
+++ b/include/configs/am43xx_evm.h
@@ -175,6 +175,8 @@
"run mmcboot;" \
"run usbboot;"
 
+#endif
+
 /* CPSW Ethernet */
 #define CONFIG_CMD_NET
 #define CONFIG_CMD_DHCP
@@ -192,8 +194,12 @@
 #define CONFIG_NET_MULTI
 #define CONFIG_PHY_GIGE
 #define CONFIG_PHYLIB
+
+#define CONFIG_SPL_ENV_SUPPORT
+#define CONFIG_SPL_NET_VCI_STRING  "AM43xx U-Boot SPL"
+
+#define CONFIG_SPL_ETH_SUPPORT
+#define CONFIG_SPL_NET_SUPPORT
 #define CONFIG_SYS_RX_ETH_BUFFER   64
-#define CONFIG_PHY_ADDR16
 
-#endif
 #endif /* __CONFIG_AM43XX_EVM_H */
-- 
1.7.9.5

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

[U-Boot] [PATCH 04/10] ARM: AM335x: add support for reading cpsw 2nd mac address from efuse

[Tom Rini]

From: Mugunthan V N 

Adding support for reading cpsw 2nd mac address from efuse and pass it
to kernel via dtb which will be used in dual emac mode of cpsw.
Also adding mii command support to am335x common config.

Acked-by: Tom Rini 
Signed-off-by: Mugunthan V N 
---
 board/ti/am335x/board.c|   15 +++
 include/configs/ti_am335x_common.h |1 +
 2 files changed, 16 insertions(+)

diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index 862f966..7609a18 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -602,6 +602,21 @@ int board_eth_init(bd_t *bis)
}
 
 #ifdef CONFIG_DRIVER_TI_CPSW
+
+   mac_lo = readl(&cdev->macid1l);
+   mac_hi = readl(&cdev->macid1h);
+   mac_addr[0] = mac_hi & 0xFF;
+   mac_addr[1] = (mac_hi & 0xFF00) >> 8;
+   mac_addr[2] = (mac_hi & 0xFF) >> 16;
+   mac_addr[3] = (mac_hi & 0xFF00) >> 24;
+   mac_addr[4] = mac_lo & 0xFF;
+   mac_addr[5] = (mac_lo & 0xFF00) >> 8;
+
+   if (!getenv("eth1addr")) {
+   if (is_valid_ether_addr(mac_addr))
+   eth_setenv_enetaddr("eth1addr", mac_addr);
+   }
+
if (read_eeprom(&header) < 0)
puts("Could not get board ID.\n");
 
diff --git a/include/configs/ti_am335x_common.h 
b/include/configs/ti_am335x_common.h
index 91f97dd..b59c7fe 100644
--- a/include/configs/ti_am335x_common.h
+++ b/include/configs/ti_am335x_common.h
@@ -31,6 +31,7 @@
 /* Network defines. */
 #define CONFIG_CMD_NET /* 'bootp' and 'tftp' */
 #define CONFIG_CMD_DHCP
+#define CONFIG_CMD_MII
 #define CONFIG_BOOTP_DNS   /* Configurable parts of CMD_DHCP */
 #define CONFIG_BOOTP_DNS2
 #define CONFIG_BOOTP_SEND_HOSTNAME
-- 
1.7.9.5

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

[U-Boot] [PATCH 03/10] ARM: AM43xx: Add CPSW support to AM43xx EPOS and GP EVM

[Tom Rini]

From: Mugunthan V N 

Adding support for CPSW to AM43xx EPOS nad GP EVM which is connected
to RMII and RGMII phy respectively and enable cpsw in config.

Reviewed-by: Felipe Balbi 
Signed-off-by: Mugunthan V N 
---
 board/ti/am43xx/board.c  |  100 ++
 board/ti/am43xx/mux.c|   41 -
 include/configs/am43xx_evm.h |   20 +
 3 files changed, 160 insertions(+), 1 deletion(-)

diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
index 95fd137..0c9f0ef 100644
--- a/board/ti/am43xx/board.c
+++ b/board/ti/am43xx/board.c
@@ -19,9 +19,15 @@
 #include 
 #include 
 #include "board.h"
+#include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
+#ifndef CONFIG_SPL_BUILD
+static struct ctrl_dev *cdev = (struct ctrl_dev *)CTRL_DEVICE_BASE;
+#endif
+
 /*
  * Read header information from EEPROM into global structure.
  */
@@ -402,3 +408,97 @@ int board_late_init(void)
return 0;
 }
 #endif
+
+#ifdef CONFIG_DRIVER_TI_CPSW
+
+static void cpsw_control(int enabled)
+{
+   /* Additional controls can be added here */
+   return;
+}
+
+static struct cpsw_slave_data cpsw_slaves[] = {
+   {
+   .slave_reg_ofs  = 0x208,
+   .sliver_reg_ofs = 0xd80,
+   .phy_addr   = 16,
+   },
+   {
+   .slave_reg_ofs  = 0x308,
+   .sliver_reg_ofs = 0xdc0,
+   .phy_addr   = 1,
+   },
+};
+
+static struct cpsw_platform_data cpsw_data = {
+   .mdio_base  = CPSW_MDIO_BASE,
+   .cpsw_base  = CPSW_BASE,
+   .mdio_div   = 0xff,
+   .channels   = 8,
+   .cpdma_reg_ofs  = 0x800,
+   .slaves = 1,
+   .slave_data = cpsw_slaves,
+   .ale_reg_ofs= 0xd00,
+   .ale_entries= 1024,
+   .host_port_reg_ofs  = 0x108,
+   .hw_stats_reg_ofs   = 0x900,
+   .bd_ram_ofs = 0x2000,
+   .mac_control= (1 << 5),
+   .control= cpsw_control,
+   .host_port_num  = 0,
+   .version= CPSW_CTRL_VERSION_2,
+};
+
+int board_eth_init(bd_t *bis)
+{
+   int rv;
+   uint8_t mac_addr[6];
+   uint32_t mac_hi, mac_lo;
+
+   /* try reading mac address from efuse */
+   mac_lo = readl(&cdev->macid0l);
+   mac_hi = readl(&cdev->macid0h);
+   mac_addr[0] = mac_hi & 0xFF;
+   mac_addr[1] = (mac_hi & 0xFF00) >> 8;
+   mac_addr[2] = (mac_hi & 0xFF) >> 16;
+   mac_addr[3] = (mac_hi & 0xFF00) >> 24;
+   mac_addr[4] = mac_lo & 0xFF;
+   mac_addr[5] = (mac_lo & 0xFF00) >> 8;
+
+   if (!getenv("ethaddr")) {
+   puts(" not set. Validating first E-fuse MAC\n");
+   if (is_valid_ether_addr(mac_addr))
+   eth_setenv_enetaddr("ethaddr", mac_addr);
+   }
+
+   mac_lo = readl(&cdev->macid1l);
+   mac_hi = readl(&cdev->macid1h);
+   mac_addr[0] = mac_hi & 0xFF;
+   mac_addr[1] = (mac_hi & 0xFF00) >> 8;
+   mac_addr[2] = (mac_hi & 0xFF) >> 16;
+   mac_addr[3] = (mac_hi & 0xFF00) >> 24;
+   mac_addr[4] = mac_lo & 0xFF;
+   mac_addr[5] = (mac_lo & 0xFF00) >> 8;
+
+   if (!getenv("eth1addr")) {
+   if (is_valid_ether_addr(mac_addr))
+   eth_setenv_enetaddr("eth1addr", mac_addr);
+   }
+
+   if (board_is_eposevm()) {
+   writel(RMII_MODE_ENABLE | RMII_CHIPCKL_ENABLE, &cdev->miisel);
+   cpsw_slaves[0].phy_if = PHY_INTERFACE_MODE_RMII;
+   cpsw_slaves[0].phy_addr = 16;
+   } else {
+   writel(RGMII_MODE_ENABLE, &cdev->miisel);
+   cpsw_slaves[0].phy_if = PHY_INTERFACE_MODE_RGMII;
+   cpsw_slaves[0].phy_addr = 0;
+   }
+
+   rv = cpsw_register(&cpsw_data);
+   if (rv < 0)
+   printf("Error %d registering CPSW switch\n", rv);
+
+   return rv;
+}
+#endif
diff --git a/board/ti/am43xx/mux.c b/board/ti/am43xx/mux.c
index 51f7fd6..13774ad 100644
--- a/board/ti/am43xx/mux.c
+++ b/board/ti/am43xx/mux.c
@@ -11,6 +11,41 @@
 #include 
 #include "board.h"
 
+static struct module_pin_mux rmii1_pin_mux[] = {
+   {OFFSET(mii1_txen), MODE(1)},   /* RMII1_TXEN */
+   {OFFSET(mii1_txd1), MODE(1)},   /* RMII1_TD1 */
+   {OFFSET(mii1_txd0), MODE(1)},   /* RMII1_TD0 */
+   {OFFSET(mii1_rxd1), MODE(1) | RXACTIVE},/* RMII1_RD1 */
+   {OFFSET(mii1_rxd0), MODE(1) | RXACTIVE},/* RMII1_RD0 */
+   {OFFSET(mii1_rxdv), MODE(1) | RXACTIVE},/* RMII1_RXDV */
+   {OFFSET(mii1_crs), MODE(1) | RXACTIVE}, /* RMII1_CRS_DV */
+   {OFFSET(mii1_rxerr), MODE(1) | RXACTIVE},   /* RMII1_RXERR */
+   {OFFSET(rmii1_refclk), MODE(0) | RXACTIVE}, /* RMII1_refclk */
+   {-1},
+};
+
+static struct module_pin_mux rgmii1_pin_mux[] = 

[U-Boot] [PATCH 08/10] ARM: AM43xx: EMIF: configure self-refresh entry delay

[Tom Rini]

From: Dave Gerlach 

Per a suggestion from the hardware team, program the emif_pwr_mgmt_ctrl
and emif_pwr_mgmt_ctrl_shdw registers within the EMIF to hold the
desired delay in cycles that the EMIF waits without an access to enter
self-refresh, in this case 8192 cycles. With this, code desiring to
enter self refresh only has to toggle one bit to enable it.

Signed-off-by: Dave Gerlach 
---
 arch/arm/cpu/armv7/am33xx/ddr.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv7/am33xx/ddr.c b/arch/arm/cpu/armv7/am33xx/ddr.c
index d05e666..4173a10 100644
--- a/arch/arm/cpu/armv7/am33xx/ddr.c
+++ b/arch/arm/cpu/armv7/am33xx/ddr.c
@@ -80,8 +80,8 @@ static void configure_mr(int nr, u32 cs)
  */
 void config_sdram_emif4d5(const struct emif_regs *regs, int nr)
 {
-   writel(0x0, &emif_reg[nr]->emif_pwr_mgmt_ctrl);
-   writel(0x0, &emif_reg[nr]->emif_pwr_mgmt_ctrl_shdw);
+   writel(0xA0, &emif_reg[nr]->emif_pwr_mgmt_ctrl);
+   writel(0xA0, &emif_reg[nr]->emif_pwr_mgmt_ctrl_shdw);
writel(0x1, &emif_reg[nr]->emif_iodft_tlgc);
writel(regs->zq_config, &emif_reg[nr]->emif_zq_config);
 
-- 
1.7.9.5

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

[U-Boot] [PATCH 06/10] ARM: AM4372: Update EMIF registers for DDR3

[Tom Rini]

From: Lokesh Vutla 

Updating EMIF_PHY_CTRL and adding EMIF_READ_WRITE_EXECUTION_THRESHOLD
registers.
In EMIF_PHY_CTRL:
Updating [4:0]READ_LATENCY to 8, because at higher frequencies like
400MHz the read latency expected will be CL+3 as per tests from HW
folks.
Clearing [19]PHY_DIS_CALIB_RST bit as this is used onl for debug
purpose. With out this resume is not working(Still waiting for PHY team
to come back for better explanation).

Signed-off-by: Lokesh Vutla 
---
 board/ti/am43xx/board.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
index 0c9f0ef..7a28063 100644
--- a/board/ti/am43xx/board.c
+++ b/board/ti/am43xx/board.c
@@ -206,7 +206,7 @@ const struct emif_regs ddr3_emif_regs_400Mhz = {
.read_idle_ctrl = 0x0005,
.zq_config  = 0x50074BE4,
.temp_alert_config  = 0x0,
-   .emif_ddr_phy_ctlr_1= 0x0E084008,
+   .emif_ddr_phy_ctlr_1= 0x0E004008,
.emif_ddr_ext_phy_ctrl_1= 0x08020080,
.emif_ddr_ext_phy_ctrl_2= 0x00400040,
.emif_ddr_ext_phy_ctrl_3= 0x00400040,
-- 
1.7.9.5

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

[U-Boot] [PATCH 10/10] ARM: AM43xx: Change DDR3 Reset Value

[Tom Rini]

From: Dave Gerlach 

The bit DDR3_RST_DEF_VAL inside CTRL_DDR_IO represents the default value
of the ddr reset value for DDR3 before the EMIF takes over. We must have
this bit set high so that on exit from DeepSleep0 within the kernel the
reset line has the proper value.

Signed-off-by: Dave Gerlach 
---
 arch/arm/cpu/armv7/am33xx/emif4.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/am33xx/emif4.c 
b/arch/arm/cpu/armv7/am33xx/emif4.c
index d28fceb..3e39752 100644
--- a/arch/arm/cpu/armv7/am33xx/emif4.c
+++ b/arch/arm/cpu/armv7/am33xx/emif4.c
@@ -113,7 +113,7 @@ void config_ddr(unsigned int pll, const struct ctrl_ioregs 
*ioregs,
writel(readl(&cm_device->cm_dll_ctrl) & ~0x1, &cm_device->cm_dll_ctrl);
while ((readl(&cm_device->cm_dll_ctrl) && CM_DLL_READYST) == 0)
;
-   writel(0x0, &ddrctrl->ddrioctrl);
+   writel(0x8000, &ddrctrl->ddrioctrl);
 
config_io_ctrl(ioregs);
 
-- 
1.7.9.5

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

[U-Boot] [PATCH 09/10] ARM: AM43xx: Write sdram_config to secure_emif_sdram_config

[Tom Rini]

From: Dave Gerlach 

The register secure_emif_sdram_config in control module is copied to
the EMIF sdram_config register when it is coming out of DeepSleep0 in
order to ensure that the EMIF comes up for the correct type of DDR.
Without this, resume can hang from within the kernel.

Signed-off-by: Dave Gerlach 
---
 arch/arm/cpu/armv7/am33xx/ddr.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/cpu/armv7/am33xx/ddr.c b/arch/arm/cpu/armv7/am33xx/ddr.c
index 4173a10..9a625c4 100644
--- a/arch/arm/cpu/armv7/am33xx/ddr.c
+++ b/arch/arm/cpu/armv7/am33xx/ddr.c
@@ -96,6 +96,7 @@ void config_sdram_emif4d5(const struct emif_regs *regs, int 
nr)
 
writel(regs->ref_ctrl, &emif_reg[nr]->emif_sdram_ref_ctrl);
writel(regs->sdram_config, &emif_reg[nr]->emif_sdram_config);
+   writel(regs->sdram_config, &cstat->secure_emif_sdram_config);
 
if (emif_sdram_type() == EMIF_SDRAM_TYPE_LPDDR2) {
configure_mr(nr, 0);
-- 
1.7.9.5

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

[U-Boot] [PATCH 05/10] ARM: DRA7xx: add support for reading cpsw 2nd mac from efuse

[Tom Rini]

From: Mugunthan V N 

Adding support for reading cpsw 2nd mac address from efuse and pass it
to kernel via dtb which will be used in dual emac mode of cpsw.
Also correct the bit masking of mac id read from the efuse.

Acked-by: Tom Rini 
Signed-off-by: Mugunthan V N 
---
 board/ti/dra7xx/evm.c |   15 +++
 1 file changed, 15 insertions(+)

diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index 9d72d2e..fd29624 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -215,6 +215,21 @@ int board_eth_init(bd_t *bis)
if (is_valid_ether_addr(mac_addr))
eth_setenv_enetaddr("ethaddr", mac_addr);
}
+
+   mac_lo = readl((*ctrl)->control_core_mac_id_1_lo);
+   mac_hi = readl((*ctrl)->control_core_mac_id_1_hi);
+   mac_addr[0] = (mac_hi & 0xFF) >> 16;
+   mac_addr[1] = (mac_hi & 0xFF00) >> 8;
+   mac_addr[2] = mac_hi & 0xFF;
+   mac_addr[3] = (mac_lo & 0xFF) >> 16;
+   mac_addr[4] = (mac_lo & 0xFF00) >> 8;
+   mac_addr[5] = mac_lo & 0xFF;
+
+   if (!getenv("eth1addr")) {
+   if (is_valid_ether_addr(mac_addr))
+   eth_setenv_enetaddr("eth1addr", mac_addr);
+   }
+
ctrl_val = readl((*ctrl)->control_core_control_io1) & (~0x33);
ctrl_val |= 0x22;
writel(ctrl_val, (*ctrl)->control_core_control_io1);
-- 
1.7.9.5

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

Re: [U-Boot] u-boot - timestamp

[Wolfgang Denk]

Dear tiger...@via-alliance.com,

In message  you 
wrote:
>
> I have tried it, and it seemed wonderful!

fine.

> Its mechanism is:
> Using host pc's time stamp to tag the kermit's every output msg line,
> right?

Yes.  We use the conole output as progres meter and add a time tamp
whenever we receive a newline character.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
To understand a program you must become  both  the  machine  and  the
program.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [RFC] [PATCH] rewrite doc/README.arm-unaligned-accesses

[Albert ARIBAUD]

Signed-off-by: Albert ARIBAUD 
---
There has been a few back-and-forths (and sideways too) about how
unaligned accesses are considered in ARM U-Boot. This post is to (try
and) get us together in one place, get things straight about what is
currently done and why as far as alignment is concerned, and to get
doc/README.arm-unaligned-accesses is clear and consistent with it.

Please, in discussing this topic, always elaborate on your opinions
on whatever you are commenting. Avoid saying "this is wrong" or "you
should do XYZ instead" without also telling what exactly is wrong and
why, or what you compare XYZ to and what are the pros and cons of each;
your reasoning may seem obvious to you, but it probably is not to the
person whose post you are commenting, and won't be to the readers of
the resulting doc/README-arm-unaligned-accesses file if it is to
include your contribution.

I also suggest giving concrete examples, code excerpts, possibly even
generated assembly language if required to make a point; just make sure
that any generated code is actually generated (as opposed to manually
constructed) and how it was produced (including compiler options), so
that people can reproduce it.

And yes, this goes for me as well :) so don't hesitate to point out
parts of this text which require improvement... and why they do. :)

 doc/README.arm-unaligned-accesses | 379 +-
 1 file changed, 289 insertions(+), 90 deletions(-)

diff --git a/doc/README.arm-unaligned-accesses 
b/doc/README.arm-unaligned-accesses
index c37d135..5873689 100644
--- a/doc/README.arm-unaligned-accesses
+++ b/doc/README.arm-unaligned-accesses
@@ -1,55 +1,229 @@
-If you are reading this because of a data abort: the following MIGHT
-be relevant to your abort, if it was caused by an alignment violation.
-In order to determine this, use the PC from the abort dump along with
-an objdump -s -S of the u-boot ELF binary to locate the function where
-the abort happened; then compare this function with the examples below.
-If they match, then you've been hit with a compiler generated unaligned
-access, and you should rewrite your code or add -mno-unaligned-access
-to the command line of the offending file.
+Notes:
 
-Note that the PC shown in the abort message is relocated. In order to
-be able to match it to an address in the ELF binary dump, you will need
-to know the relocation offset. If your target defines CONFIG_CMD_BDI
-and if you can get to the prompt and enter commands before the abort
-happens, then command "bdinfo" will give you the offset. Otherwise you
-will need to try a build with DEBUG set, which will display the offset,
-or use a debugger and set a breakpoint at relocate_code() to see the
-offset (passed as an argument).
-
-*
-
-Since U-Boot runs on a variety of hardware, some only able to perform
-unaligned accesses with a strong penalty, some unable to perform them
-at all, the policy regarding unaligned accesses is to not perform any,
-unless absolutely necessary because of hardware or standards.
-
-Also, on hardware which permits it, the core is configured to throw
-data abort exceptions on unaligned accesses in order to catch these
-unallowed accesses as early as possible.
-
-Until version 4.7, the gcc default for performing unaligned accesses
-(-mno-unaligned-access) is to emulate unaligned accesses using aligned
-loads and stores plus shifts and masks. Emulated unaligned accesses
-will not be caught by hardware. These accesses may be costly and may
-be actually unnecessary. In order to catch these accesses and remove
-or optimize them, option -munaligned-access is explicitly set for all
-versions of gcc which support it.
-
-From gcc 4.7 onward starting at armv7 architectures, the default for
-performing unaligned accesses is to use unaligned native loads and
-stores (-munaligned-access), because the cost of unaligned accesses
-has dropped on armv7 and beyond. This should not affect U-Boot's
-policy of controlling unaligned accesses, however the compiler may
-generate uncontrolled unaligned accesses on its own in at least one
-known case: when declaring a local initialized char array, e.g.
+i) If you are reading this because of a data abort: section 10 is what
+you're looking for, but please read the whole document.
 
-function foo()
-{
-   char buffer[] = "initial value";
-/* or */
-   char buffer[] = { 'i', 'n', 'i', 't', 0 };
-   ...
-}
+ii) In order to make sure the following is self-sufficient, it goes
+through the basics of alignment and assumes only good, not expert,
+knowledge of the C language.
+
+1. C99 alignment requirements
+
+The C99 standard [1] (henceforth: 'C99') defines alignment requirements
+as a "requirement that objects of a particular type be located on
+storage boundaries with addresses that are particular multiples of a
+byte address".
+
+In C99, unaligned accesses (those which which do not respect alignment
+requirements of the object type being accessed) are deem

[U-Boot] Error Code "rm cannot remove directory 'asm/arch' : Is a directory"

[Ambuj Saxena]

Hello All,
 I am trying to learn u-boot in xp.
*http://d1.amobbs.com/bbs_upload782111/files_41/ourdev_649777NIY8KG.pdf
*

When I am trying to build u-boot I got an error.
When I call command "*make am3517_evm_config*" then  *Error* is "rm cannot
remove directory 'asm/arch' : Is a directory
make : ***[am3517_evm_config] Error 1

This time I don't know what to do. anyone can help me out

Any Kind of suggestion would be appreciated.


-- 


Best Regards,
Ambuj Saxena
+91-9033460719

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

Re: [U-Boot] Error Code "rm cannot remove directory 'asm/arch' : Is a directory"

[Albert ARIBAUD]

Hi Ambuj,

On Tue, 18 Feb 2014 16:51:12 +0530, Ambuj Saxena 
wrote:

> Hello All,
>  I am trying to learn u-boot in xp.
> *http://d1.amobbs.com/bbs_upload782111/files_41/ourdev_649777NIY8KG.pdf
> *

Why on Earth use XP? It's about the worst possible choice of MS OS for
trying to build U-Boot, if only because it's going to stop being
supported very soon (if not already?).

Plus, in general, U-Boot building requires GCC or LLVM, and generally
Unix- or Linux-originating tools, which are fiddly to get working
properly on an MS OS (disclaimer: I last tried this a decade ago and it
was a /nightmare/. I guess it got better over time, but still, it's
either MingW or Cygwin, right, and that probably still means a lot of
"playing around" to get things working).

> When I am trying to build u-boot I got an error.
> When I call command "*make am3517_evm_config*" then  *Error* is "rm cannot
> remove directory 'asm/arch' : Is a directory
> make : ***[am3517_evm_config] Error 1

Which version of U-Boot are you building, and with which version of GCC?

> This time I don't know what to do. anyone can help me out
> 
> Any Kind of suggestion would be appreciated.

Why not install some Linux-based OS? If you can't, why not at least run
some Linux-based OS as a VM? You'd save a lot of trouble IMO.

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

Re: [U-Boot] [PATCH v2 2/3] dts: move device tree sources to arch/$(ARCH)/dts/

[Tom Rini]

On Thu, Feb 06, 2014 at 02:50:50PM +0900, Masahiro Yamada wrote:
> Hello Simon,
> 
> 
> > Hi Masahiro,
> > 
> > On 4 February 2014 02:38, Masahiro Yamada  wrote:
> > > Unlike Linux Kernel, U-Boot historically had *.dts files under
> > > board/$(VENDOR)/dts/ and *.dtsi files under arch/$(ARCH)/dts/.
> > >
> > > I think arch/$(ARCH)/dts dicretory is a better location
> > > to store both *.dts and *.dtsi files.
> > >
> > > For example, before this commit, board/xilinx/dts directory
> > > had both MicroBlaze dts (microblaze-generic.dts) and
> > > ARM dts (zynq-*.dts), which are totally unrelated.
> > >
> > > This commit moves *.dts to arch/$(ARCH)/dts/ directories,
> > > allowing us to describe nicely mutiple DTBs generation in the next commit.
> > 
> > What is the motivation for this? I worry that we might end up with a
> > lot of files in one directory.
> 
> We have only 35 .dtsi and .dts for ARM.
> I think it will be OK at least until we have 500.
> 
> Linux v3.13 has 500 .dtsi and .dts files in arch/arm/boot/dts/
> and they are still adding device trees to that directory.

Last I saw the plan, still, is to remove them from the kernel "someday".
Hopefully when that happens we can also leverage what comes next.

> I have no idea if they will keep going, or someone will scream and turn
> around.
> 
> Anyway, when Linux guys someday invents a nice idea to work arond
> increasing device trees, we can import it to U-Boot.
> It should be easy for us because we already have a similar build system.

True.

> > One benefit of the current approach is
> > that .dts files are split up by vendor. Even if we put the SoC .dtsi
> > files in arch/arm, perhaps there is a benefit in leaving the board
> > .dts files in board/?
> 
> I don't like the idea to split up by vendor.
> 
> Now Xilinx has device trees both for ARM and Microblaze,
> resulting in totally unrelated device trees in one directory.

This, I think is backwards.  Xilinx has (and Freescale and others are or
will be joining them) a lot of things shared between them as IP blocks
get reused from non-ARM to ARM CPUs.  So there's a level of DT sharing
for these blocks between the CPUs.  The kernel is going to start having
this problem as vendors start dropping their arm IP blocks into ARMv8
SoCs, and those would be in arch/arm64/.  The question is, will people
care enough about the duplication, or just live with it.

-- 
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 v8 0/38] Switch over to real Kbuild

[Tom Rini]

On Sat, Feb 15, 2014 at 06:30:59PM -0700, Simon Glass wrote:
> Hi Masahiro,
> 
> On 6 February 2014 14:10, Tom Rini  wrote:
> > On Mon, Feb 03, 2014 at 12:46:30PM +0900, Masahiro Yamada wrote:
> >
> >> Hello Simon and Tom,
> >>
> >>
> >> This is my analysis of Kbuild performance.
> > [snip]
> >> Conclusion:
> >> The main reasons of the slow down with Kbuild are "fixdep" and "arg-check".
> >> Both of them are really important features for Kbuild and Kconfig.
> >> - "fixdep" is mandatory for our better life with Kconfig.
> >> - "arg-check" is for perfect dependency tracking.
> >>
> 
> Thanks for your detailed analysis of this. The slower build time is
> unfortunate but I think it is worth it. The fixdep thing is similar to
> the penalty from the autoconf series I did a while ago. Maybe the
> scripts can be sped up, I'm not sure.
> 
> >>
> >>
> >> > > What's your plan about this series?
> >> > > Are we ready to switch to Kbuild, or need more review?
> >> >
> >> > Lets get the performance problem Simon found figured out, but then
> >> > otherwise, yes, I think we're about ready to merge.
> >>
> >> Tom, are you satisfied with my analisys?
> >
> > I am, yes.  I guess if we're unhappy with the times, if we can improve
> > them we can push that back to the kernel and that's a good thing.
> 
> Well IMO the sooner this is merged the better so that the Makefiles
> become stable again.

Agreed.  Weather ate most of last week for me when I had hoped to clear
out some things and then grab this series.  Back at it all now..

-- 
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 5/5] NAND: DaVinci: allow forced disable of subpage writes

[Tom Rini]

On Wed, Feb 12, 2014 at 06:00:22PM -0600, Scott Wood wrote:
> 
> On Tue, 2014-01-28 at 23:19 +, Karicheri, Muralidharan wrote:
> > >-Original Message-
> > >From: Scott Wood [mailto:scottw...@freescale.com]
> > >Sent: Wednesday, January 22, 2014 3:48 PM
> > >To: Karicheri, Muralidharan
> > >Cc: u-boot@lists.denx.de; Rini, Tom; Andrianov, Vitaly
> > >Subject: Re: [U-Boot] [PATCH 5/5] NAND: DaVinci: allow forced disable of 
> > >subpage writes
> > >
> > >On Mon, 2014-01-20 at 17:10 -0500, Murali Karicheri wrote:
> > >> This patch introduces a configurable mechanism to disable subpage
> > >> writes in the DaVinci NAND driver.
> > >>
> > >> Signed-off-by: Vitaly Andrianov 
> > >> Signed-off-by: Murali Karicheri 
> > >> ---
> > >>  drivers/mtd/nand/davinci_nand.c |3 +++
> > >>  1 file changed, 3 insertions(+)
> > >>
> > >> diff --git a/drivers/mtd/nand/davinci_nand.c
> > >> b/drivers/mtd/nand/davinci_nand.c index 5b17d7b..75b03a7 100644
> > >> --- a/drivers/mtd/nand/davinci_nand.c
> > >> +++ b/drivers/mtd/nand/davinci_nand.c
> > >> @@ -609,6 +609,9 @@ void davinci_nand_init(struct nand_chip *nand)
> > >> #ifdef CONFIG_SYS_NAND_USE_FLASH_BBT
> > >>  nand->bbt_options |= NAND_BBT_USE_FLASH;
> > >>  #endif
> > >> +#ifdef CONFIG_SYS_NAND_NO_SUBPAGE_WRITE
> > >> +nand->options |= NAND_NO_SUBPAGE_WRITE;
> > >> +#endif
> > >>  #ifdef CONFIG_SYS_NAND_HW_ECC
> > >>  nand->ecc.mode = NAND_ECC_HW;
> > >>  nand->ecc.size = 512;
> > >
> > >Why does it need to be configurable?
> > >
> > 
> > Same driver used in multiple platforms, and on some platforms like the one
> > I work with doesn't support subpage writes and has to be disabled.
> 
> The option needs to be documented, and it should be either named in a
> davinci-specific manner, or the documentation should clearly list which
> drivers pay attention to it.

Agreed.

> It seems odd though, that the ability to support subpage writes is an
> independent thing rather than a consequence of some other variable such
> as controller version.

I suspect this is similar to the OMAP driver where we could support
subpages but it gets tricky coordinating with the HW ECC engine for BCH8
and higher.  Perhaps there are davinci targets with smaller ECC levels
where it works out OK but keystone is doing BCH8 or 16 and it's not
worth the savings.

-- 
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 2/3] dts: move device tree sources to arch/$(ARCH)/dts/

[Michal Simek]

On 02/18/2014 03:32 PM, Tom Rini wrote:
> On Thu, Feb 06, 2014 at 02:50:50PM +0900, Masahiro Yamada wrote:
>> Hello Simon,
>>
>>
>>> Hi Masahiro,
>>>
>>> On 4 February 2014 02:38, Masahiro Yamada  wrote:
 Unlike Linux Kernel, U-Boot historically had *.dts files under
 board/$(VENDOR)/dts/ and *.dtsi files under arch/$(ARCH)/dts/.

 I think arch/$(ARCH)/dts dicretory is a better location
 to store both *.dts and *.dtsi files.

 For example, before this commit, board/xilinx/dts directory
 had both MicroBlaze dts (microblaze-generic.dts) and
 ARM dts (zynq-*.dts), which are totally unrelated.

 This commit moves *.dts to arch/$(ARCH)/dts/ directories,
 allowing us to describe nicely mutiple DTBs generation in the next commit.
>>>
>>> What is the motivation for this? I worry that we might end up with a
>>> lot of files in one directory.
>>
>> We have only 35 .dtsi and .dts for ARM.
>> I think it will be OK at least until we have 500.
>>
>> Linux v3.13 has 500 .dtsi and .dts files in arch/arm/boot/dts/
>> and they are still adding device trees to that directory.
> 
> Last I saw the plan, still, is to remove them from the kernel "someday".
> Hopefully when that happens we can also leverage what comes next.
> 
>> I have no idea if they will keep going, or someone will scream and turn
>> around.
>>
>> Anyway, when Linux guys someday invents a nice idea to work arond
>> increasing device trees, we can import it to U-Boot.
>> It should be easy for us because we already have a similar build system.
> 
> True.
> 
>>> One benefit of the current approach is
>>> that .dts files are split up by vendor. Even if we put the SoC .dtsi
>>> files in arch/arm, perhaps there is a benefit in leaving the board
>>> .dts files in board/?
>>
>> I don't like the idea to split up by vendor.
>>
>> Now Xilinx has device trees both for ARM and Microblaze,
>> resulting in totally unrelated device trees in one directory.
>
> This, I think is backwards.  Xilinx has (and Freescale and others are or
> will be joining them) a lot of things shared between them as IP blocks
> get reused from non-ARM to ARM CPUs.  So there's a level of DT sharing
> for these blocks between the CPUs.  The kernel is going to start having
> this problem as vendors start dropping their arm IP blocks into ARMv8
> SoCs, and those would be in arch/arm64/.  The question is, will people
> care enough about the duplication, or just live with it.

We share all soft IP drivers between ARM and Microblaze and we will continue
in this style. The point is to have the same binding which we have.
We are using device-tree generator to get the latest binding which is
in sync with kernel. When we adopt u-boot configured by device-tree
(when variable handling in u-boot is fixed) we will use the same binding
in uboot too.

I personally don't care where DTS files will be placed because we will
generate them as we are doing now.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




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

Re: [U-Boot] RFC unified boot environment

[Dennis Gilmore]

On Tue, 18 Feb 2014 11:18:22 +0100
Stefano Babic  wrote:

> Hi Dennis,
> 
> On 17/02/2014 18:56, Dennis Gilmore wrote:
> > Hi All,
> > 
> > The attached patches build on the work for generic distro config,
> > as well as Stephen Warrens implementation for tegra.
> > 
> 
> First, thanks to make order on this issue.
> 
> > I have added a header to be included that will allow all boards to
> > boot in the same way and I have ported over two boards to use it.
> > One thought I have had is to move the environment into the same
> > header as the generic config. 
> 
> I think this is currently the best solution.
> 
> > 
> > I am also working on writing a README.distro file to document
> > everything that needs to be set for everything to just work. Along
> > with information on how to best choose memory locations. 
> 
> 
> Ok, let's see. This seems quite board-depending, I do not know if we
> find a common solution. But we can find an agreement about a generic
> set of variables/scripts, that all boards can reuse.

There will always be some board specific things like memory locations
etc. None of the boot logic is board specific. Some features are
hardware specific, i.e. PXE boot support is only configured if the
hardware supports it same for SATA. 

I'm putting what I have for the documentation so far at the end of this
email. I think that soc families should have a common settings file,
each board should have its on file and then we have a common set of
configurations on how to boot. 

Dennis


/*
 * (C) Copyright 2014 Red Hat Inc.
 *
 * SPDX-License-Identifier: GPL-2.0+
 */

Generic distro configuration



configuring
---
To configure a board to run the generic distro setup and enable generic distros
to easily support your board.


you will need to include a pair of headers to enable the boot environment and
configuration options needed. It is best to only include when not doing an
SPL build.

#ifndef CONFIG_SPL_BUILD
#include 
#include 
#endif

There is some memory addresses you will need to define in
CONFIG_EXTRA_ENV_SETTINGS
fdt_addr:
Optional, if specified a dtb to boot the system needs to be available at the
address.

fdt_addr_r:
Mandatory, This is the location where the sysboot/pxeboot with load the dtb to,
using the fdtdir/devicetreedir or fdt/devicetree options in the pxe/extlinux
config file. The location can be anywhere in ram it just needs to not overlap
with anything, allowing 1 megabyte seems to be a safe option.

ramdisk_addr_r:
Mandatory, This is the location where the sysboot/pxeboot with load the
initramfs to, using the initrd option in the pxe/extlinux config file, the
location of the initramfs does not matter, there needs to be enough room to be
able to store any image. Making the image the last item stored should allow for
any initramfs to fit and not overwrite anything else.

kernel_addr_r:
Mandatory, 

pxe_addr_r:
Mandatory, used by the PXE code to hold the pxelinux config file. The location
can be anywhere in ram it just needs to not overlap with anything, allowing 1 
megabyte seems to be a safe option.

scriptaddr:
Mandatory, 

suggested mapping:
16M 

make sure you also include BOOTCMDS_COMMON in CONFIG_EXTRA_ENV_SETTINGS

booting your system
---
in the most simplest form CONFIG_BOOTCOMMAND just needs one line

"for target in ${boot_targets}; do run bootcmd_${target}; done"

you can run any setup before going through the targets for example run a
command to set "fdtfile" variable for the dtb for your board.

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

Re: [U-Boot] [RFC] try to merge different i.MX environment

[Tom Rini]

On Sat, Feb 15, 2014 at 12:57:43PM +0100, Stefano Babic wrote:
> Hi Dennis,
> 
> On 14/02/2014 17:14, Dennis Gilmore wrote:
> > On Fri, 14 Feb 2014 16:06:55 +0100
> > Stefano Babic  wrote:
> > 
> >> Signed-off-by: Stefano Babic 
> >> CC: Fabio Estevam 
> >> CC: Otavio Salvador 
> >> CC: Marek Vasut 
> >> CC: Leo Sartre 
> >> CC: Jon Nettleton 
> >> CC: Eric Nelson 
> >> CC: b18...@freescale.com
> >>
> >> Hi everybody,
> >>
> >> the current built-in environment in most i.MX boards is very similar.
> >> Even if I always thought that the default environemt is something
> >> that the user want always customize, I see from all you submitters
> >> the not hidden desire to have such a common default environment for
> >> all boards. At least, for i.MX boards.
> >> Checking in the board configuration files, I see at least the
> >> following boards that hase "quite" the same built-in environment:
> >>
> > 
> > I'm working on building a common set environment based on the work by
> > Stephen Warren for tegra, that would provide for a very usable
> > experience.
> > 
> > Its the next step forward from the distro config options. Id rather us
> > get a solution that works across the board than something different per
> > soc family.
> 
> Fully agree. I will check again tegra-common-post.h. As far as I have
> understood, the built-in environment for Tegra sets a minimal set of
> rules and scripts that allow to load a full environment from another
> script stored on a media (mmc or usb). This is also a good statement,
> because the environment is not so fine defined and let easy customization.

Dan has adapted the tegra form to work with the TI boards that use
ti_armv7_common.h and similar so I think we should be able to get i.MX
also using something similar.

-- 
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] Pull request: u-boot-spi/master

[Jagannadha Sutradharudu Teki]

Hi Tom,

Please take this PR, few fixes and pending patches on qspi am43xx.

thanks!
--
Jagan.

The following changes since commit 22a240c32c1340183fce12867ae5f8736b92a638:

  serial/serial_arc - add driver for ARC UART (2014-02-07 12:55:07 -0500)

are available in the git repository at:

  git://git.denx.de/u-boot-spi.git master

for you to fetch changes up to 9ea09e20376abbca21760ed4ba87d6b5c4df465c:

  doc: SPI: Add qspi test details on AM43xx (2014-02-18 22:41:09 +0530)


Markus Niebel (3):
  spi: spi-mxc: add defines for clk inactive state for ECSPI
  spi: spi-mxc: implement clk control for ECSPI to fix SPI_MODE_3
  spi: mxc_spi: i.MX6 DL/S have only 4 eCSPI controller

Michal Simek (1):
  spi: xilinx: Move timeout calculation out of the loop

Sourav Poddar (5):
  am43xx: Add qspi support
  am437x_epos_evm: add SPL API, QSPI, and serial flash support
  spi: ti_qspi: Add AM43xx specifics changes
  spi: ti_qspi: Add delay before xfer for am43xx
  doc: SPI: Add qspi test details on AM43xx

 arch/arm/cpu/armv7/am33xx/clock_am43xx.c |  1 +
 arch/arm/include/asm/arch-am33xx/cpu.h   |  4 +-
 arch/arm/include/asm/arch-am33xx/omap.h  |  1 +
 arch/arm/include/asm/arch-mx5/imx-regs.h |  7 +--
 arch/arm/include/asm/arch-mx6/imx-regs.h |  9 ++--
 board/ti/am43xx/mux.c| 11 +
 doc/SPI/README.ti_qspi_am43x_test| 76 
 drivers/spi/mxc_spi.c|  9 +++-
 drivers/spi/ti_qspi.c| 33 --
 drivers/spi/xilinx_spi.c |  8 ++--
 include/configs/am43xx_evm.h | 20 +
 11 files changed, 163 insertions(+), 16 deletions(-)
 create mode 100644 doc/SPI/README.ti_qspi_am43x_test


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

Re: [U-Boot] Pull request: u-boot-nios/master

[Tom Rini]

On Tue, Feb 11, 2014 at 04:08:36PM +0800, Thomas Chou wrote:

> Hi Tom,
> 
> The following changes since commit 22a240c32c1340183fce12867ae5f8736b92a638:
> 
>   serial/serial_arc - add driver for ARC UART (2014-02-07 12:55:07 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-nios.git master
> 
> for you to fetch changes up to 2d61e1bed2205b5ebce6b732693c30d01590f9fc:
> 
>   serial: opencores_yanu: Avoid duplicate oc_serial_setbrg() implementation 
> (2014-02-11 15:49:19 +0800)
> 
> 
> Axel Lin (2):
>   serial: opencores_yanu: Fix build error
>   serial: opencores_yanu: Avoid duplicate oc_serial_setbrg() 
> implementation
> 
>  drivers/serial/opencores_yanu.c | 52 
> +
>  1 file changed, 11 insertions(+), 41 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] Pull request: u-boot-mmc 07022014

[Tom Rini]

On Fri, Feb 07, 2014 at 06:37:13PM +0200, Pantelis Antoniou wrote:

> Hi Tom,
> 
> The following changes since commit dbf3de2dd26cae37d16b00b348828c883b658cc5:
> 
>   include/usb/s3c_udc.h: Add  (2014-02-06 14:26:05 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-mmc.git master
> 
> for you to fetch changes up to b818d9ab8d96471c40ccbd4541a46dfa415eda73:
> 
>   dra7xx_evm: Add CONFIG_SUPPORT_EMMC_BOOT, document usage (2014-02-07 
> 18:17:49 +0200)
> 
> 
> Rajeshwari S Shinde (1):
>   MMC: DWMMC: Correct the CLKDIV register value
> 
> Siva Durga Prasad Paladugu (1):
>   mmc: Enabled quirk SDHCI_QUIRK_BROKEN_R1B
> 
> Stephen Warren (1):
>   mmc: set rca to 1 for MMC cards
> 
> Tom Rini (8):
>   SPL: Add CONFIG_SUPPORT_EMMC_BOOT support to CONFIG_SPL_FRAMEWORK
>   cmd_mmc.c: Change 'bootpart' code to match normal coding style
>   cmd_mmc.c: Rename 'bootpart' to 'bootpart-resize'
>   cmd_mmc.c: Add 'partconf' command to mmc
>   cmd_mmc.c: Add bootbus mmc sub-command
>   cmd_mmc.c: Drop open/close mmc sub-commands
>   omap5_uevm: Add CONFIG_SUPPORT_EMMC_BOOT, document usage
>   dra7xx_evm: Add CONFIG_SUPPORT_EMMC_BOOT, document usage
> 
>  arch/arm/cpu/armv7/omap-common/boot-common.c |  13 ++-
>  arch/arm/include/asm/arch-exynos/dwmmc.h |   4 
>  board/ti/dra7xx/README   |  25 +
>  board/ti/omap5_uevm/README   |  25 +
>  common/cmd_mmc.c | 108 
> ++
>  common/spl/spl_mmc.c |  24 
>  drivers/mmc/dw_mmc.c |   2 +-
>  drivers/mmc/exynos_dw_mmc.c  |  17 +--
>  drivers/mmc/mmc.c|  79 
> --
>  drivers/mmc/zynq_sdhci.c |   3 ++-
>  include/configs/dra7xx_evm.h |   2 ++
>  include/configs/omap5_uevm.h |   1 +
>  include/dwmmc.h  |   2 +-
>  include/mmc.h|   9 ++--
>  include/spl.h|   1 +
>  15 files changed, 198 insertions(+), 117 deletions(-)
>  create mode 100644 board/ti/dra7xx/README
>  create mode 100644 board/ti/omap5_uevm/README

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-arm/master

[Tom Rini]

On Thu, Feb 13, 2014 at 06:43:41PM +0100, Albert ARIBAUD wrote:

> Hi Tom,
> 
> The following changes since commit
> 0876703cf2ee107372b56037d4eeeb7604c56796:
> 
>   boards.cfg: Keep the entries sorted (2014-01-27 08:28:35 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-arm master
> 
> for you to fetch changes up to 9c134e189a95c976dab94d4f28444a5398627188:
> 
>   arm/km: introduce kmsugp1 target (2014-02-13 17:45:36 +0100)
> 
> 
> Albert ARIBAUD (3):
>   Merge branch 'u-boot-arm/next' into 'u-boot-arm/master'
>   Merge branch 'u-boot-ti/master' into 'u-boot-arm/master'
>   Merge branch 'u-boot-samsung/master' into 'u-boot-arm/master'
> 
> Enric Balletbò i Serra (7):
>   ARM: OMAP4: Rename to ti_omap4_common.h
>   ARM: OMAP5: Rename to ti_omap5_common.h
>   TI: armv7: Move ELM support to SoC configuration file.
>   TI: armv7: Do not define the number DRAM banks if is already
> defined. ARM: OMAP3: Rename OMAP3_PUBLIC_SRAM_* to NON_SECURE_SRAM_*
>   TI: OMAP3: Create common config files for TI OMAP3 platforms.
>   OMAP3: igep00x0: Convert to ti_omap3_common.h.
> 
> Gerlando Falauto (3):
>   arm/km: enable FDT for km_kirwkood
>   arm/km: define fdt_high env variable and allow backwards
> compatibility arm/km: introduce kmsugp1 target
> 
> Holger Brunck (5):
>   arm/km: drop unneeded define
>   arm/km: make local function startup_allowed static
>   arm/km/suv31: switch to 256MB RAM
>   arm/km: add CONFIG_KM_BOARD_EXTRA_ENV to default environment
>   arm/km: fix wrong error handling
> 
> Inha Song (3):
>   serial: s5p: set automatically clears after resetting Rx FIFO
>   exynos: clock: fixed that cfg is set to wrong value.
>   exynos: clock: use the clear and set bits macros.
> 
> Jassi Brar (2):
>   ARM: OMAP4/5: Remove dead code against
> CONFIG_SYS_CLOCKS_ENABLE_ALL ARM: OMAP4/5: Remove dead code against
> CONFIG_SYS_ENABLE_PADS_ALL
> 
> Jim Lin (1):
>   ARM: tegra: fix "bootp" issue for Tegra124 too
> 
> Jimmy Zhang (1):
>   ARM: tegra: don't exceed AVP limits when configuring PLLP
> 
> Linus Walleij (2):
>   ARM: versatile: pass correct machine type for Versatile AB
>   ARM: versatile: pass console setting to the kernel
> 
> Lokesh Vutla (1):
>   ARM: AM43xx: Enable DDR dynamic IO power down for DDR3
> 
> Masahiro Yamada (1):
>   relocate-rela: replace a magic number with sizeof(Elf64_Rela)
> 
> Michal Simek (2):
>   zynq: Use full tftpboot command instead of shortcut tftp
>   zynq: Fix elf header generation
> 
> Minkyu Kang (3):
>   exynos: pinmux: sort the list of peripherals
>   exynos: pinmux: remove unnecessary define
>   exynos: pinmux: remove unnecessary routine
> 
> Nishanth Menon (2):
>   DRA7: Add support for ES1.1 silicon ID code
>   DRA7: add ABB setup for MPU voltage domain
> 
> Piotr Wilczek (8):
>   arm:exynos: add cpu revision
>   arm:s5pc110: add cpu revision
>   board:samsung:common: set envs with board unified information
>   board:samsung:goni: add env variables describing platform
>   board:samsung:universal: add env variables describing platform
>   board:samsung:trats: add env variables describing platform
>   board:samsung:trats2: add env variables describing platform
>   board:samsung:trats/trats2: enable boot with appended and
> separated DTB
> 
> Przemyslaw Marczak (12):
>   s5p: gpio: change gpio coding method for s5p gpio.
>   trats2: Code cleanup.
>   samsung: common: Add file for common functions, draw_logo()
> cleanup. common: lcd.c: fix data abort exception when try to access bmp
> header lib: tizen: change Tizen logo with the new one.
>   video: exynos: fimd: add support for various display color modes
>   samsung: boards: update display configs with 16bpp mode.
>   samsung: misc: Add LCD download menu.
>   trats: add LCD download menu support
>   trats2: add LCD download menu support
>   universal: add LCD download menu support
>   config: trats: trats2: extend dfu_alt_info by env update settings
> 
> Satyanarayana, Sandhya (1):
>   ARM: AM335x: Enable DDR dynamic IO power down
> 
> Stephen Warren (16):
>   ARM: tegra: accept any SKU ID for most chips
>   ARM: tegra: set env vars to indicate Cardhu A04 support
>   ARM: tegra: clear $usb_need_init each boot
>   ARM: tegra: rename MASK_BITS_29_28 to MASK_BITS_31_28
>   ARM: tegra: rename OUT_CLK_SOURCE_*
>   ARM: tegra: use MASK_BITS_* macros everywhere
>   ARM: tegra: MASK_BITS_ no longer needs specific values
>   ARM: tegra: amend pmc.h for Tegra114+
>   mmc: tegra: support Tegra124
>   ARM: tegra: misc cleanups triggered by Tegra124 review
>   ARM: tegra: pass just partition ID to power_partition()
>   ARM: tegra: enable PLLX only once it's been fully configured
>   

[U-Boot] [PATCH] DRA7: fix ABB efuse offset for OPP_NOM

[Nishanth Menon]

commit 194dd74ad919e57026f385aaab7f89acf7ea79ef
(DRA7: add ABB setup for MPU voltage domain)

Made an offset typo error by using 0x4A003B24 as the efuse offset
for OPP_NOM. As per TI documentation, 0x4A003B24 is for OPP_OD, and
0x4A003B20 is for OPP_NOM. Fix the same.

Reported-by: Praveen Rao 
Signed-off-by: Nishanth Menon 
---

Unfortunately, this happened to slip past my results as the sample I
had used happened to have the same values for both registers.

Based on u-boot-arm
 5e77a74 ARM: bcm2835: fix mbox POWER_STATE_RESP_ON value
 arch/arm/cpu/armv7/omap5/prcm-regs.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/omap5/prcm-regs.c 
b/arch/arm/cpu/armv7/omap5/prcm-regs.c
index ff32807..7292161 100644
--- a/arch/arm/cpu/armv7/omap5/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c
@@ -432,7 +432,7 @@ struct omap_sys_ctrl_regs const dra7xx_ctrl = {
.control_srcomp_code_latch  = 0x4A002E84,
.control_ddr_control_ext_0  = 0x4A002E88,
.control_padconf_core_base  = 0x4A003400,
-   .control_std_fuse_opp_vdd_mpu_2 = 0x4A003B24,
+   .control_std_fuse_opp_vdd_mpu_2 = 0x4A003B20,
.control_port_emif1_sdram_config= 0x4AE0C110,
.control_port_emif1_lpddr2_nvm_config   = 0x4AE0C114,
.control_port_emif2_sdram_config= 0x4AE0C118,
-- 
1.7.9.5

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

Re: [U-Boot] Pull request: u-boot-arm/master

[Stephen Warren]

On 02/18/2014 10:50 AM, Tom Rini wrote:
> On Thu, Feb 13, 2014 at 06:43:41PM +0100, Albert ARIBAUD wrote:
> 
>> Hi Tom,
>>
>> The following changes since commit
>> 0876703cf2ee107372b56037d4eeeb7604c56796:
>>
>>   boards.cfg: Keep the entries sorted (2014-01-27 08:28:35 -0500)
>>
>> are available in the git repository at:
>>
>>   git://git.denx.de/u-boot-arm master
>>
>> for you to fetch changes up to 9c134e189a95c976dab94d4f28444a5398627188:
>>
>>   arm/km: introduce kmsugp1 target (2014-02-13 17:45:36 +0100)
...
> Applied to u-boot/master, thanks!

How often does u-boot/master get pushed, and is there any replication
delay once it does?

The most recent commit I see in u-boot/master was committed on Feb 7.
Since these emails are a trigger for me and others to go grab the latest
commits, it'd be nice if there was at most a very tiny delay between
receiving the email, and actually being able to pull the commits. Last
time I had this issue, I think I had to wait over 24 hours for the push
or replication delay, which was a bit annoying, since I needed to
remember to go back and check every so often.

If it's replication delay, perhaps the Linux Foundation's kernel.org
code could be stolen; that does (almost?) real-time replication from the
push-to servers to the public r/o-mirrors, triggered by the git push
action. That makes my life a lot easier, since I can "git push" then
immediately send the "applied" email.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 1/3] usb: tegra: fix USB2 powerdown for Tegra30 and later

[Stephen Warren]

On 02/16/2014 12:50 PM, Stefan Agner wrote:
> Clear the forced powerdown bit in the UTMIP_PLL_CFG2_0 register
> which brings USB2 in UTMI mode to work. This was clearly missing
> since the forced powerdown bit is set in reset by default for all
> USB ports.

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

Re: [U-Boot] Pull request: u-boot-arm/master

[Tom Rini]

On Tue, Feb 18, 2014 at 11:21:28AM -0700, Stephen Warren wrote:
> On 02/18/2014 10:50 AM, Tom Rini wrote:
> > On Thu, Feb 13, 2014 at 06:43:41PM +0100, Albert ARIBAUD wrote:
> > 
> >> Hi Tom,
> >>
> >> The following changes since commit
> >> 0876703cf2ee107372b56037d4eeeb7604c56796:
> >>
> >>   boards.cfg: Keep the entries sorted (2014-01-27 08:28:35 -0500)
> >>
> >> are available in the git repository at:
> >>
> >>   git://git.denx.de/u-boot-arm master
> >>
> >> for you to fetch changes up to 9c134e189a95c976dab94d4f28444a5398627188:
> >>
> >>   arm/km: introduce kmsugp1 target (2014-02-13 17:45:36 +0100)
> ...
> > Applied to u-boot/master, thanks!
> 
> How often does u-boot/master get pushed, and is there any replication
> delay once it does?

It gets pushed as often as I spam out accepted messages.  And yes,
there's a replication delay.  I believe it's every 6 hours, starting at
midnight +0200 ?  Wolfgang?

> The most recent commit I see in u-boot/master was committed on Feb 7.
> Since these emails are a trigger for me and others to go grab the latest
> commits, it'd be nice if there was at most a very tiny delay between
> receiving the email, and actually being able to pull the commits. Last
> time I had this issue, I think I had to wait over 24 hours for the push
> or replication delay, which was a bit annoying, since I needed to
> remember to go back and check every so often.

I think there was a human mistake back then.  But yes, would it be
possible to sync things out more automatically Wolfgang?  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v3 2/3] usb: tegra: fix PHY configuration

[Stephen Warren]

On 02/16/2014 12:50 PM, Stefan Agner wrote:
> On Tegra30 and later, the PTS (parallel transceiver select) and STS
> (serial transceiver select) are part of the HOSTPC1_DEVLC_0 register
> rather than PORTSC1_0 register. Since the reset configuration
> usually matches the intended configuration, this error did not show
> up on Tegra30 devices.
> 
> Also use the slightly different bit fields of first USB, (USBD) on
> Tegra20 and move those definitions to the Tegra20 specific header
> file.

Reviewed-by: Stephen Warren 

Hmm, the kernel has some potential bugs in this area as well:-( At
least, on Tegra20, phy-tegra-usb.c:set_pts() does the wrong thing on the
USB1 port. Luckily, the driver skips calling set_pts() on USB1, so this
isn't an actual issue.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Pull request: u-boot-arm/master

[Albert ARIBAUD]

Hi Tom,

On Tue, 18 Feb 2014 12:50:40 -0500, Tom Rini  wrote:

> On Thu, Feb 13, 2014 at 06:43:41PM +0100, Albert ARIBAUD wrote:
> 
> > Hi Tom,
> > 
> > The following changes since commit
> > 0876703cf2ee107372b56037d4eeeb7604c56796:
> > 
> >   boards.cfg: Keep the entries sorted (2014-01-27 08:28:35 -0500)
> > 
> > are available in the git repository at:
> > 
> >   git://git.denx.de/u-boot-arm master
> > 
> > for you to fetch changes up to 9c134e189a95c976dab94d4f28444a5398627188:
> > 
> >   arm/km: introduce kmsugp1 target (2014-02-13 17:45:36 +0100)
> > 
> > 
> > Albert ARIBAUD (3):
> >   Merge branch 'u-boot-arm/next' into 'u-boot-arm/master'
> >   Merge branch 'u-boot-ti/master' into 'u-boot-arm/master'
> >   Merge branch 'u-boot-samsung/master' into 'u-boot-arm/master'
> > 
> > Enric Balletbò i Serra (7):
> >   ARM: OMAP4: Rename to ti_omap4_common.h
> >   ARM: OMAP5: Rename to ti_omap5_common.h
> >   TI: armv7: Move ELM support to SoC configuration file.
> >   TI: armv7: Do not define the number DRAM banks if is already
> > defined. ARM: OMAP3: Rename OMAP3_PUBLIC_SRAM_* to NON_SECURE_SRAM_*
> >   TI: OMAP3: Create common config files for TI OMAP3 platforms.
> >   OMAP3: igep00x0: Convert to ti_omap3_common.h.
> > 
> > Gerlando Falauto (3):
> >   arm/km: enable FDT for km_kirwkood
> >   arm/km: define fdt_high env variable and allow backwards
> > compatibility arm/km: introduce kmsugp1 target
> > 
> > Holger Brunck (5):
> >   arm/km: drop unneeded define
> >   arm/km: make local function startup_allowed static
> >   arm/km/suv31: switch to 256MB RAM
> >   arm/km: add CONFIG_KM_BOARD_EXTRA_ENV to default environment
> >   arm/km: fix wrong error handling
> > 
> > Inha Song (3):
> >   serial: s5p: set automatically clears after resetting Rx FIFO
> >   exynos: clock: fixed that cfg is set to wrong value.
> >   exynos: clock: use the clear and set bits macros.
> > 
> > Jassi Brar (2):
> >   ARM: OMAP4/5: Remove dead code against
> > CONFIG_SYS_CLOCKS_ENABLE_ALL ARM: OMAP4/5: Remove dead code against
> > CONFIG_SYS_ENABLE_PADS_ALL
> > 
> > Jim Lin (1):
> >   ARM: tegra: fix "bootp" issue for Tegra124 too
> > 
> > Jimmy Zhang (1):
> >   ARM: tegra: don't exceed AVP limits when configuring PLLP
> > 
> > Linus Walleij (2):
> >   ARM: versatile: pass correct machine type for Versatile AB
> >   ARM: versatile: pass console setting to the kernel
> > 
> > Lokesh Vutla (1):
> >   ARM: AM43xx: Enable DDR dynamic IO power down for DDR3
> > 
> > Masahiro Yamada (1):
> >   relocate-rela: replace a magic number with sizeof(Elf64_Rela)
> > 
> > Michal Simek (2):
> >   zynq: Use full tftpboot command instead of shortcut tftp
> >   zynq: Fix elf header generation
> > 
> > Minkyu Kang (3):
> >   exynos: pinmux: sort the list of peripherals
> >   exynos: pinmux: remove unnecessary define
> >   exynos: pinmux: remove unnecessary routine
> > 
> > Nishanth Menon (2):
> >   DRA7: Add support for ES1.1 silicon ID code
> >   DRA7: add ABB setup for MPU voltage domain
> > 
> > Piotr Wilczek (8):
> >   arm:exynos: add cpu revision
> >   arm:s5pc110: add cpu revision
> >   board:samsung:common: set envs with board unified information
> >   board:samsung:goni: add env variables describing platform
> >   board:samsung:universal: add env variables describing platform
> >   board:samsung:trats: add env variables describing platform
> >   board:samsung:trats2: add env variables describing platform
> >   board:samsung:trats/trats2: enable boot with appended and
> > separated DTB
> > 
> > Przemyslaw Marczak (12):
> >   s5p: gpio: change gpio coding method for s5p gpio.
> >   trats2: Code cleanup.
> >   samsung: common: Add file for common functions, draw_logo()
> > cleanup. common: lcd.c: fix data abort exception when try to access bmp
> > header lib: tizen: change Tizen logo with the new one.
> >   video: exynos: fimd: add support for various display color modes
> >   samsung: boards: update display configs with 16bpp mode.
> >   samsung: misc: Add LCD download menu.
> >   trats: add LCD download menu support
> >   trats2: add LCD download menu support
> >   universal: add LCD download menu support
> >   config: trats: trats2: extend dfu_alt_info by env update settings
> > 
> > Satyanarayana, Sandhya (1):
> >   ARM: AM335x: Enable DDR dynamic IO power down
> > 
> > Stephen Warren (16):
> >   ARM: tegra: accept any SKU ID for most chips
> >   ARM: tegra: set env vars to indicate Cardhu A04 support
> >   ARM: tegra: clear $usb_need_init each boot
> >   ARM: tegra: rename MASK_BITS_29_28 to MASK_BITS_31_28
> >   ARM: tegra: rename OUT_CLK_SOURCE_*
> >   ARM: tegra: use MASK_BITS_* macros everywhere
> >   ARM: tegra: MASK_BITS_ no longer needs sp

Re: [U-Boot] [PATCH v3 3/3] usb: tegra: combine header file

[Stephen Warren]

On 02/16/2014 12:50 PM, Stefan Agner wrote:
> Combine the Tegra USB header file into one header file for all SoCs.
> Use ifdef to account for the difference, especially Tegra20 is quite
> different from newer SoCs. This avoids duplication especially
> between Tegra30 and newer devices.

Aside from a few minor comments below,
Reviewed-by: Stephen Warren 

I think this should be extended to Tegra124 too.

> diff --git a/arch/arm/include/asm/arch-tegra/usb.h 
> b/arch/arm/include/asm/arch-tegra/usb.h

>  #ifndef _TEGRA_USB_H_
>  #define _TEGRA_USB_H_
>  
> +
> +/* USB Controller (USBx_CONTROLLER_) regs */

Why two blank lines there?

> +struct usb_ctlr {
...
> + /* 0x200 */
> + uint reserved11[0x80];
> +
> +#else
> +
> + /* 0x130 */

I don't think there should be blank lines before/after the #else; there
aren't after the #if or before the #endif.

...
> +};
> +
> +
>  /* USB1_LEGACY_CTRL */

Why two blank lines there?

> +#if defined(CONFIG_TEGRA20) || defined(CONFIG_TEGRA30)
> +/* USB2_IF_ULPI_TIMING_CTRL_0 */
> +#define ULPI_OUTPUT_PINMUX_BYP   (1 << 10)
> +#define ULPI_CLKOUT_PINMUX_BYP   (1 << 11)
> +
> +/* USB2_IF_ULPI_TIMING_CTRL_1 */
> +#define ULPI_DATA_TRIMMER_LOAD   (1 << 0)
> +#define ULPI_DATA_TRIMMER_SEL(x) (((x) & 0x7) << 1)
> +#define ULPI_STPDIRNXT_TRIMMER_LOAD  (1 << 16)
> +#define ULPI_STPDIRNXT_TRIMMER_SEL(x)(((x) & 0x7) << 17)
> +#define ULPI_DIR_TRIMMER_LOAD(1 << 24)
> +#define ULPI_DIR_TRIMMER_SEL(x)  (((x) & 0x7) << 25)
> +#endif

Are those defines really Tegra20/30-only, or were they simply omitted
from the Tegra114 header because they aren't used by the driver?

Actually, if these aren't used, is it even worth including this text in
the header? Perhaps delete unused text in a separate patch before this
one, so that this patch simply moves text between files?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 3/3] usb: tegra: combine header file

[Stefan Agner]

Am 2014-02-18 20:27, schrieb Stephen Warren:
> On 02/16/2014 12:50 PM, Stefan Agner wrote:
>> +#if defined(CONFIG_TEGRA20) || defined(CONFIG_TEGRA30)
>> +/* USB2_IF_ULPI_TIMING_CTRL_0 */
>> +#define ULPI_OUTPUT_PINMUX_BYP  (1 << 10)
>> +#define ULPI_CLKOUT_PINMUX_BYP  (1 << 11)
>> +
>> +/* USB2_IF_ULPI_TIMING_CTRL_1 */
>> +#define ULPI_DATA_TRIMMER_LOAD  (1 << 0)
>> +#define ULPI_DATA_TRIMMER_SEL(x)(((x) & 0x7) << 1)
>> +#define ULPI_STPDIRNXT_TRIMMER_LOAD (1 << 16)
>> +#define ULPI_STPDIRNXT_TRIMMER_SEL(x)   (((x) & 0x7) << 17)
>> +#define ULPI_DIR_TRIMMER_LOAD   (1 << 24)
>> +#define ULPI_DIR_TRIMMER_SEL(x) (((x) & 0x7) << 25)
>> +#endif
> 
> Are those defines really Tegra20/30-only, or were they simply omitted
> from the Tegra114 header because they aren't used by the driver?
> 
> Actually, if these aren't used, is it even worth including this text in
> the header? Perhaps delete unused text in a separate patch before this
> one, so that this patch simply moves text between files?
I don't have access to a Tegra114 TRM right now, but I can it be that
the ULPI PHY is not in place there? If its not used in the driver, I
guess we can remove those defines completely...

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

Re: [U-Boot] [PATCH v3 3/3] usb: tegra: combine header file

[Stephen Warren]

On 02/18/2014 03:20 PM, Stefan Agner wrote:
> Am 2014-02-18 20:27, schrieb Stephen Warren:
>> On 02/16/2014 12:50 PM, Stefan Agner wrote:
>>> +#if defined(CONFIG_TEGRA20) || defined(CONFIG_TEGRA30)
>>> +/* USB2_IF_ULPI_TIMING_CTRL_0 */
>>> +#define ULPI_OUTPUT_PINMUX_BYP (1 << 10)
>>> +#define ULPI_CLKOUT_PINMUX_BYP (1 << 11)
>>> +
>>> +/* USB2_IF_ULPI_TIMING_CTRL_1 */
>>> +#define ULPI_DATA_TRIMMER_LOAD (1 << 0)
>>> +#define ULPI_DATA_TRIMMER_SEL(x)   (((x) & 0x7) << 1)
>>> +#define ULPI_STPDIRNXT_TRIMMER_LOAD(1 << 16)
>>> +#define ULPI_STPDIRNXT_TRIMMER_SEL(x)  (((x) & 0x7) << 17)
>>> +#define ULPI_DIR_TRIMMER_LOAD  (1 << 24)
>>> +#define ULPI_DIR_TRIMMER_SEL(x)(((x) & 0x7) << 25)
>>> +#endif
>>
>> Are those defines really Tegra20/30-only, or were they simply omitted
>> from the Tegra114 header because they aren't used by the driver?
>>
>> Actually, if these aren't used, is it even worth including this text in
>> the header? Perhaps delete unused text in a separate patch before this
>> one, so that this patch simply moves text between files?
>
> I don't have access to a Tegra114 TRM right now, but I can it be that
> the ULPI PHY is not in place there? If its not used in the driver, I
> guess we can remove those defines completely...

Looking further, all those values are used, but by a piece of code
that's #ifdef CONFIG_USB_ULPI, and that define is only enabled on a
couple of Tegra20 boards.

Looking at the TRMs, both the Tegra20/30 TRMs mention the register that
contains these fields (but doesn't document the register:-/), but
neither the Tegra114/124 TRMs mention the same registers, so perhaps
those values are Tegra20/30-only, so the ifdef you have is fine.

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

Re: [U-Boot] [PATCH v3 4/6] PPC: 85xx: Generalize DDR TLB mapping function

[Scott Wood]

On Tue, 2014-02-11 at 01:10 +0100, Alexander Graf wrote:
> - if (memsize)
> - print_size(memsize, " left unmapped\n");
> + if (size)
> + print_size(size, " left unmapped\n");
> +}

The print_size should move to the caller, with some way to pass back the
amout left unmapped.  Non-RAM callers would treat a non-zero unmapped
value as an error.

> +unsigned int
> +setup_ddr_tlbs_phys(phys_addr_t p_addr, unsigned int memsize_in_meg)
> +{
> + unsigned int ram_tlb_address = (unsigned int)CONFIG_SYS_DDR_SDRAM_BASE;
> + u64 memsize = (u64)memsize_in_meg << 20;
> +
> + memsize = min(memsize, CONFIG_MAX_MEM_MAPPED);
> + tlb_map_range(ram_tlb_address, p_addr, memsize, true);
>   return memsize_in_meg;
>  }

Here you seem to be hiding the message for RAM.

York, are you OK with just removing the message altogether, and having
tlb_map_range return a normal error code if it can't map everything
(with DDR size reduced in advance as above)?

> diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
> index cadaeef..5493c51 100644
> --- a/arch/powerpc/include/asm/mmu.h
> +++ b/arch/powerpc/include/asm/mmu.h
> @@ -509,6 +509,9 @@ extern void print_tlbcam(void);
>  extern unsigned int setup_ddr_tlbs(unsigned int memsize_in_meg);
>  extern void clear_ddr_tlbs(unsigned int memsize_in_meg);
>  
> +extern void tlb_map_range(ulong v_addr, phys_addr_t p_addr, uint64_t size,
> +   bool is_ram);

bool arguments tend to be hard to read at call sites -- flags (or enum)
with something like MAP_RAM/MAP_IO would be nicer (I'm not insisting,
though).

-Scott


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

Re: [U-Boot] [PATCH v3 6/6] PPC 85xx: Add qemu-ppce500 machine

[Scott Wood]

On Tue, 2014-02-11 at 01:10 +0100, Alexander Graf wrote:
> diff --git a/arch/powerpc/cpu/mpc85xx/start.S 
> b/arch/powerpc/cpu/mpc85xx/start.S
> index bb0025c..8982c78 100644
> --- a/arch/powerpc/cpu/mpc85xx/start.S
> +++ b/arch/powerpc/cpu/mpc85xx/start.S
> @@ -80,6 +80,11 @@ _start_e500:
>   li  r1,MSR_DE
>   mtmsr   r1
>  
> +#ifdef CONFIG_QEMU_E500
> + /* Save our ePAPR device tree pointer before we clobber it */
> + mr  r24, r3
> +#endif

FWIW, it should be harmless to do this unconditionally (though in that
case I'd insert "(if we have one)" in the comment.

>  #ifdef CONFIG_SYS_FSL_ERRATUM_A004510
>   mfspr   r3,SPRN_SVR
>   rlwinm  r3,r3,0,0xff
> @@ -514,6 +519,7 @@ nexti:mflrr1  /* R1 = our PC */
>   * As a general rule, TLB0 is used for short-term TLBs, and TLB1 is used for
>   * long-term TLBs, so we use TLB0 here.
>   */
> +#if !defined(CONFIG_DYNAMIC_CCSRBAR)
>  #if (CONFIG_SYS_CCSRBAR_DEFAULT != CONFIG_SYS_CCSRBAR_PHYS)

This shouldn't be necessary, if you have
CONFIG_SYS_CCSR_DO_NOT_RELOCATE.

> diff --git a/arch/powerpc/cpu/mpc85xx/tlb.c b/arch/powerpc/cpu/mpc85xx/tlb.c
> index 2011fb8..0e0b483 100644
> --- a/arch/powerpc/cpu/mpc85xx/tlb.c
> +++ b/arch/powerpc/cpu/mpc85xx/tlb.c
> @@ -36,6 +36,10 @@ void init_tlbs(void)
> tlb_table[i].mas7);
>   }
>  
> +#ifdef CONFIG_SYS_USE_DYNAMIC_TLBS
> + init_tlbs_dynamic();
> +#endif

You could avoid the ifdef by moving a stub implementation into the
header -- or possibly better, avoid the config symbol entirely by using
a weak symbol.

Better still, make init_tlbs() weak.  Then you don't need a config
symbol, a new function name, or a dummy tlb_table[] -- you just redefine
init_tlbs() in board code.

> diff --git a/board/freescale/qemu-ppce500/qemu-ppce500.c 
> b/board/freescale/qemu-ppce500/qemu-ppce500.c
> new file mode 100644
> index 000..fc546b9
> --- /dev/null
> +++ b/board/freescale/qemu-ppce500/qemu-ppce500.c
> @@ -0,0 +1,334 @@
> +/*
> + * Copyright 2007,2009-2014 Freescale Semiconductor, Inc.
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +static void *get_fdt(void)
> +{
> + return (void *)gd->fdt_blob;
> +}

Does this return virtual or physical?

> +
> +uint64_t get_phys_ccsrbar_addr_early(void)
> +{
> + u32 mas0, mas1, mas2, mas3, mas7;
> + ulong fdt = (ulong)get_fdt();
> + uint64_t r;
> +
> + /*
> +  * To be able to read the FDT we need to create a temporary TLB
> +  * map for it.
> +  */
> +
> + mas0 = MAS0_TLBSEL(1) | MAS0_ESEL(10);
> + mas1 = MAS1_VALID | MAS1_TID(0) | MAS1_TS | MAS1_TSIZE(BOOKE_PAGESZ_1M);
> + mas2 = FSL_BOOKE_MAS2(fdt, 0);
> + mas3 = FSL_BOOKE_MAS3(fdt, 0, MAS3_SW|MAS3_SR);
> + mas7 = FSL_BOOKE_MAS7(fdt);

Don't use the physical address as a virtual address.  Use a known-good
virtual address.  Using unknown physical addresses as virtual addresses
is generally a bad idea (it's different for stuff whose physical address
is hardcoded in U-Boot), but it's particularly bad here because you'll
create an overlapping TLB entry if the fdt happens to live within your
initial memory mapping.

OK, I see you use CONFIG_SYS_TMPVIRT for this elsewhere, but I guess
forgot to use it here (why is fdt mapping code duplicated?).

> +void pci_init_board(void)
> +{
> + struct pci_controller *pci_hoses;
> + void *fdt = get_fdt();
> + int pci_node;
> + int pci_num = 0;
> + int pci_count = 0;
> + const char *compat = "fsl,mpc8540-pci";
> + ulong map_addr;

May want to look for arbitrary PCI host controllers (device_type would
be simplest), in case the QEMU machine ever gets an upgrade to PCIe.

> +
> + puts("\n");
> +
> + /* Start MMIO and PIO range maps above RAM */
> + map_addr = CONFIG_MAX_MEM_MAPPED;

It'd be better to hardcode virtual addresses for this (as other boards
do), and limit the size you map to the smaller of the hardcoded size or
the device tree size.

> + /* Count and allocate PCI buses */
> + pci_node = fdt_node_offset_by_compatible(fdt, -1, compat);
> + while (pci_node != -FDT_ERR_NOTFOUND) {
> + pci_node = fdt_node_offset_by_compatible(fdt, pci_node, compat);
> + pci_count++;
> + }
> +
> + if (pci_count) {
> + pci_hoses = malloc(sizeof(struct pci_controller) * pci_count);
> + } else {
> + printf("PCI: disabled\n\n");
> + return;
> + }
> +
> + /* Spawn PCI buses based on device tree */
> + pci_node = fdt_node_offset_by_compatible(fdt, -1, compat);
> + while (pci_node != -FDT_ERR_NOTFOUND) {
> + struct fsl_pci_info pci_info = { };
> + const fdt32_t *reg;
> + int r;
> +
> + reg = fdt_getpro

Re: [U-Boot] [PATCH] endian dependency fix

[Nobuhiro Iwamatsu]

Hi, all.

Masahiro, thank you for the explanation.

Yoshinori, please resend patches after read patch submission rules.

Best regards,
  Nobuhiro

2014-02-18 19:19 GMT+09:00 Masahiro Yamada :
> Hi Yoshinori,
>
> You should read the patch submission rules
> (http://www.denx.de/wiki/U-Boot/Patches)
> before posting patches.
>
>  - Use the imperative tense in your summary line
>
>   I mean, "fix blah blah" rather than "blah blah fix"
>
>
>  - If applicable, prefix the summary line with a word describing what
> area of code is being affected followed by a colon.
>
>   In this case,  "mmc: ..."
>
>   Ditto in your MS7206SE series.
>
>
> Best Regards
> Masahiro Yamada
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot



-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v8 0/38] Switch over to real Kbuild

[Masahiro Yamada]

Hello Tom,

I notice Kbuild fails to build venice2 board
because commit 52ef43b0529  added an empty Makefile,
arch/arm/cpu/armv7/tegra124/Makefile.

What shall we do with this?

Do you need v10 or shall I fix it in a follow-up patch?


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 0/15] Follow-up for Kbuild series: more misc targets and short logs

[Masahiro Yamada]

Hello Simon,



> git am ~/Downloads/bundle-5618-masap.mbox
> Applying: kbuild: consolidate version and timestamp headers generation
> error: patch failed: Makefile:1128
> error: Makefile: patch does not apply
> error: patch failed: doc/DocBook/Makefile:131
> error: doc/DocBook/Makefile: patch does not apply
> error: scripts/kernel-doc: does not exist in index
> Patch failed at 0001 kbuild: consolidate version and timestamp headers
> generation
> The copy of the patch that failed is found in:
>/home/sjg/u/.git/rebase-apply/patch
> When you have resolved this problem, run "git am --continue".
> If you prefer to skip this patch, run "git am --skip" instead.
> To restore the original branch and stop patching, run "git am --abort".
> 
> 
> Could you please push it somewhere?

Done.

Please try this:

git clone git://github.com/masahir0y/u-boot-kbuild.git
cd u-boot-kbuild
git checkout kbuild_follow_v1


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 v2] cosmetic: FIT: fix a strange comment

[Simon Glass]

On 17 February 2014 22:39, Masahiro Yamada  wrote:
>
> There is a strange comment in fit_image_load().
> This function can be used for loading Kernel Image, FDT
> as well as ramdisk.
>
> Signed-off-by: Masahiro Yamada 
> Cc: Simon Glass 


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

Re: [U-Boot] Regarding u-boot patch about accurate boot time measurement

[Simon Glass]

Hi,

On 18 February 2014 00:30, Abdullah Yıldız  wrote:
> Hi,
>
> On Tue, Feb 18, 2014 at 12:16 AM, Simon Glass  wrote:
>> Hi,
>>
>> On 17 February 2014 05:07,
> abdullah
>
>  Yıldız  wrote:
>>> Hi Albert,
>>>
>>> On Mon, Feb 17, 2014 at 1:58 PM, Albert ARIBAUD
>>>  wrote:
 Hi Abdullah,

 On Mon, 17 Feb 2014 13:10:52 +0200, Abdullah Yıldız
  wrote:

> Hi Simon,
>
> On Mon, Feb 17, 2014 at 1:03 AM, Simon Glass  wrote:
> > Hi Abdullah,
> >
> > On 16 February 2014 15:38, Abdullah Yıldız 
> >  wrote:
> >> Dear Glass,
> >>
> >> I've fount this
> >> http://lists.denx.de/pipermail/u-boot/2011-May/092584.html while
> >> searching about boot time measurement methods in u-boot. However, I
> >> couldn't find a patch file regarding your post. Could you help me with
> >> this about where to find the patch?
> >
> > This was merged into U-Boot in early 2012, so you don't need a patch.
> > See bootstage.h for the API.
> >
> > Regards,
> > Simon
> >
> > --
>
> Adding CONFIG_BOOTSTAGE option and then make didn't work.

 Can you give more detail, e.g. what exactly is the commit you're
 trying to build, what is the command line, and what is the error
 message?

 Amicalement,
 --
 Albert.

 --
>>>
>>> I'm working on u-boot version 2014-01.
>>>
>>> Actually, there is no error message, u-boot runs without any timestamp.
>>
>> bootstage is a way of measuring boot time and progress - what sort of
>> timestamp are you looking for?
>>
>> Regards,
>> Simon
>>
>> --
>
> bootstage is exactly what I'm looking for. Is it enough to define
> #define CONFIG_BOOTSTAGE to build u-boot with timestamping?

Suggest #define CONFIG_BOOTSTAGE_REPORT also so you get an automatic
report before booting the kernel.

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

Re: [U-Boot] [PATCH v2 1/3] dts: re-write dts/Makefile more simply with Kbuild

[Simon Glass]

Hi Masahiro,

On 18 February 2014 01:27, Masahiro Yamada  wrote:
> Hello Simon,
>
>
>
>> > Useful rules in scripts/Makefile.lib allows us to easily
>> > generate a device tree blob and wrap it in assembly code.
>> >
>> > We do not need to parse a linker script to get output format and arch.
>> >
>> > This commit deletes ./u-boot.dtb since it is a copy of dts/dt.dtb
>>
>> I'd rather have the former and delete the latter temporary file as
>> part of the build. u-boot.dtb is currently a build output.
>
>
> This is what I have said in the thread
> Re: [PATCH] dts: re-write dts/Makefile more simply with Kbuild
>
> We must keep dts/dt.dtb to suppress the re-generation of dts/dt.dtb.

OK. From memory when I did this, it was just a temporary file which
was used to create dts/dt.o. Make deleted it at the end of the build,
I think. But I may remember wrong, and it doesn't matter anyway.

>
> Besides,  dts/dt.dtb is a prerequisite of dts/dt.dtb.S
> when CONFIG_OF_EMBED is enabled.
>
> I believe keeping dts/dt.dtb is reasonable enough.
>
> Better to keep both?

Yes I think so.

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

[U-Boot] introduction of www.xrefs.info

[John Smith]

hello,
I made http://www.xrefs.info available to open source community in
the hope of making open source developers more productive.
The site hosts many open source code projects' cross references based
on OpenGrok, which is a very fast cross reference tool, and easy to use.

To access, you can go to http://www.xrefs.info, select a project, pick
a version.
If you want to search the definition of a function,
simply type it in the definition box; If you want to do a full search,
type your text in the first box; If you want to search a file, simply
type file name in file path box. Hit search button, That's it!

The site covers following:
 - Linux kernel cross reference: from verion 0.01 - 3.13.3, plus nightly latest.
 - Linux boot loaders cross reference: u-boot, lilo, grub,
syslinux,plus nightly latest.
 - Linux user space core packages cross reference
 - Android cross reference, plus nightly latest.
 - Cloud computing other projects:
- xen hypervisor cross reference
- VirtualBox cross reference;
- OpenStack cross reference
- cloudStack cross reference.
- Puppet cross reference
- Salt cross reference
- Cloud Foundary cross reference
- OpenShift cross reference
- Chef cross reference
- Juju cross reference
 - Big data project Hadoop cross reference
 - BSD: FreeBSD cross reference, NetBSD cross reference, DragonflyBSD
cross reference
 - Database: MySQL cross reference, MariaDB cross reference, mongoDB
cross reference
 - Languages: OpenJDK cross reference, Perl cross reference, Python
cross reference, PHP cross reference.

If you have any questions, comments or suggestions for the site,
please let me know.

Thanks.
xrefs.i...@gmail.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/3] dts: move device tree sources to arch/$(ARCH)/dts/

[Simon Glass]

Hi Masahiro,

On 18 February 2014 01:43, Masahiro Yamada  wrote:
> Hello Simon,
>
>
>> >>
>> >> On 4 February 2014 02:38, Masahiro Yamada  
>> >> wrote:
>> >> > Unlike Linux Kernel, U-Boot historically had *.dts files under
>> >> > board/$(VENDOR)/dts/ and *.dtsi files under arch/$(ARCH)/dts/.
>> >> >
>> >> > I think arch/$(ARCH)/dts dicretory is a better location
>> >> > to store both *.dts and *.dtsi files.
>> >> >
>> >> > For example, before this commit, board/xilinx/dts directory
>> >> > had both MicroBlaze dts (microblaze-generic.dts) and
>> >> > ARM dts (zynq-*.dts), which are totally unrelated.
>> >> >
>> >> > This commit moves *.dts to arch/$(ARCH)/dts/ directories,
>> >> > allowing us to describe nicely mutiple DTBs generation in the next 
>> >> > commit.
>> >>
>> >> What is the motivation for this? I worry that we might end up with a
>> >> lot of files in one directory.
>> >
>> > We have only 35 .dtsi and .dts for ARM.
>> > I think it will be OK at least until we have 500.
>> >
>> > Linux v3.13 has 500 .dtsi and .dts files in arch/arm/boot/dts/
>> > and they are still adding device trees to that directory.
>> >
>> > I have no idea if they will keep going, or someone will scream and turn
>> > around.
>> >
>> > Anyway, when Linux guys someday invents a nice idea to work arond
>> > increasing device trees, we can import it to U-Boot.
>> > It should be easy for us because we already have a similar build system.
>>
>> Hmm, but would it be such a big problem to keep the general ARM and
>> SOC stuff in arch/arm/dts and the board-specific stuff in board/ ?
>> One of the problems with Linux is that their board-specific code is
>> spread all over the place, and I'm not sure we want to emulate it?
>
> Opposite.
> Board-specific code mostly resides under
> arch/arm/mach-* or arch/arm/plat-*.
> And what else is arch/arm/configs and arch/arm/boot/dts. That's it.
>
>
> We have board-specific part
>  - entries in boards.cfg
>  - include/configs/.h
>  - board// or board/
>  - arch//include/am/arch- includes sometimes
>board-specific headers  as well as SoC specific headers.
>(Because there is no other place to store board-specific header files)
>
> Various stuff under include/, for exmple
>   - include/xilinx.h:  vendor specific?
>   - include/sandboxblockdev.h:  arch specific?
>
> And we often missed to remove remainders of dead boards.
>
> U-Boot has more troublesome directory structure.

Well Linux got board-specific directories and systems only relatively
recently I suppose. U-Boot has the benefit of many years of legacy :-)

>
>
>> >> One benefit of the current approach is
>> >> that .dts files are split up by vendor. Even if we put the SoC .dtsi
>> >> files in arch/arm, perhaps there is a benefit in leaving the board
>> >> .dts files in board/?
>> >
>> > I don't like the idea to split up by vendor.
>> >
>> > Now Xilinx has device trees both for ARM and Microblaze,
>> > resulting in totally unrelated device trees in one directory.
>>
>> Shouldn't the SoC part go in arch/arm and arch/microblaze? Then just
>> the board-specific stuff can go in board/
>
> What is SoC part? What is Board part?

Well SoC is the chip from a vendor like Nvidia. Normally they would
provide a set of .dtsi files, say for example tegra20.dtsi,
tegra30.dtsi, etc. It makes sense to have a common SoC directory that
all boards can use.

Then a board that uses say a Tegra SoC on it can just include those
files and connect things up as required.

>
>> >
>> > What if Freescale decided to adopt device tree?
>> > They support various boards on ARM, PowerPC, M68K.
>> >
>> > Renesus is the same. They have ARM and SuperH boards.
>>
>> I'm not convinced yet. I think maybe you have forgotten about the
>> .dtsi files for SoCs. They are common, but no one is going to include
>> a board .dts file (nor can they), so putting them in a common area
>> does not seem like a win to me.
>
> I do know that *.dtsi files are included from others, while
> *.dts files are not included from anywhere.
> And I understand your policy, *.dtsi to arch dir and *.dts to vendor dir.
> (No that I care, we have two exceptions:
> ./board/avionic-design/dts/tegra20-tamonten.dtsi
> ./board/avionic-design/dts/tegra30-tamonten.dtsi)
>
> If I have to mention a win,
> we can save makefiles by not putting almost same ones in
> vendor directories.
>
>
> Anyway, we have 3 structures proposed so far.
>
> [1] board/$(VENDOR)/dts/  (current structure)
> [2] arch/$(ARCH)/dts/  (suggested by me)
> [3] dts/  for all architectures (suggested by Scott)
>
> In my option, [2] and [3] seem to be reasonable enough.
>
> If we cannot reach an agreement,
> shall we postpone 2/3 and 3/3 and apply only 1/3?
>

I don't want to hold up progress, but I am not sure that the Linux
approach is a great idea. I prefer this:

arch/$(ARCH)/dts   - SoC .dtsi files
board/$(VENDOR)/dts   - Board-specific .dts files (which include the above)

but as you say we don't have a lot of files so it is not a huge de

Re: [U-Boot] [PATCH v2 1/3] dts: re-write dts/Makefile more simply with Kbuild

[Masahiro Yamada]

Hello Simon,


On Tue, 18 Feb 2014 21:45:12 -0800
Simon Glass  wrote:

> Hi Masahiro,
> 
> On 18 February 2014 01:27, Masahiro Yamada  wrote:
> > Hello Simon,
> >
> >
> >
> >> > Useful rules in scripts/Makefile.lib allows us to easily
> >> > generate a device tree blob and wrap it in assembly code.
> >> >
> >> > We do not need to parse a linker script to get output format and arch.
> >> >
> >> > This commit deletes ./u-boot.dtb since it is a copy of dts/dt.dtb
> >>
> >> I'd rather have the former and delete the latter temporary file as
> >> part of the build. u-boot.dtb is currently a build output.
> >
> >
> > This is what I have said in the thread
> > Re: [PATCH] dts: re-write dts/Makefile more simply with Kbuild
> >
> > We must keep dts/dt.dtb to suppress the re-generation of dts/dt.dtb.
> 
> OK. From memory when I did this, it was just a temporary file which
> was used to create dts/dt.o. Make deleted it at the end of the build,
> I think. But I may remember wrong, and it doesn't matter anyway.

I think dts/dt.o was deleted at the end
only when CONFIG_OF_SEPARATE=y
by the following rule.

  $(obj)u-boot.dtb:   checkdtc $(obj)u-boot
  $(MAKE) $(build) dts binary
  mv $(obj)dts/dt.dtb $@

It moves, not copies dts/dt.dtb.


> >
> > Besides,  dts/dt.dtb is a prerequisite of dts/dt.dtb.S
> > when CONFIG_OF_EMBED is enabled.
> >
> > I believe keeping dts/dt.dtb is reasonable enough.
> >
> > Better to keep both?
> 
> Yes I think so.


OK.
I will revive ./u-boot.dtb and post a new version.

And I will send it as a single patch
dropping 2/3 and 3/3.
Do you think it's better?

Many kbuild-related patches are being stuck on patchwork
and my local branch is getting messed up.
I don't want to delay this patch any more.


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 v8 0/38] Switch over to real Kbuild

[Simon Glass]

Hi Masahiro,

On 18 February 2014 01:02, Masahiro Yamada  wrote:
> Hello Simon,
>
>
>>
>> I'm not sure whether to start a new thread or not, but here in one
>> observations which might be useful.
>>
>> With current master, a 'null' build (with nothing changed) takes about
>> 5s for me.
>>
>> time 
>> CROSS_COMPILE=/opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.8-2013.08_linux/bin/arm
>> -linux-gnueabihf- ARCH=arm make -j1
>> real 0m4.978s
>> user 0m1.144s
>> sys 0m0.360s
>>
>>
>> With the kbuild series, it takes a lot longer:
>>
>> real 0m46.600s
>> user 0m17.628s
>> sys 0m8.664s
>
> Thanks for your feedback.
>
> Hmm, Kbuild is 9 times slower on your computer.
> This is a big difference. (It was about 1.6 x slower on my box.)
>
> I don't know where such a difference came from.

Note this is a 32-core machine.

>
>> There seem to be noticeable pauses between things happening. I'm not
>> quite sure how to dig into it more. Is it possible that cc-option is
>> no-longer caching the various compiler options?
>
> I guess it's possible.
>
> Is sandbox build slow as well?
> Sandbox has no cc-option.
> If cc-option is the cause of pauses, sandbox build
> should be faster.

Yes actually sandbox is pretty fast.

>
> Anyway, evaluating cc-option multiple times isn't nice
> and its optimization is on my TODO list.
>
> Historically, U-Boot has included all
> config.mk (arch/*/config.mk and board/*/config.mk)
> every time descending into subdirectories.
> That means cc-options are evaluated over and over again.
> Caching cc-option is one of work arounds, but we should not
> revive it.
>
> What we should do is to include arch/*/config.mk and board/*/config.mk
> only once at the top Makefile and export options.

That sounds good to me. Thanks for looking at it.

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

Re: [U-Boot] [PATCH v2 1/3] dts: re-write dts/Makefile more simply with Kbuild

[Simon Glass]

Hi Masahiro,

On 18 February 2014 22:06, Masahiro Yamada  wrote:
> Hello Simon,
>
>
> On Tue, 18 Feb 2014 21:45:12 -0800
> Simon Glass  wrote:
>
>> Hi Masahiro,
>>
>> On 18 February 2014 01:27, Masahiro Yamada  wrote:
>> > Hello Simon,
>> >
>> >
>> >
>> >> > Useful rules in scripts/Makefile.lib allows us to easily
>> >> > generate a device tree blob and wrap it in assembly code.
>> >> >
>> >> > We do not need to parse a linker script to get output format and arch.
>> >> >
>> >> > This commit deletes ./u-boot.dtb since it is a copy of dts/dt.dtb
>> >>
>> >> I'd rather have the former and delete the latter temporary file as
>> >> part of the build. u-boot.dtb is currently a build output.
>> >
>> >
>> > This is what I have said in the thread
>> > Re: [PATCH] dts: re-write dts/Makefile more simply with Kbuild
>> >
>> > We must keep dts/dt.dtb to suppress the re-generation of dts/dt.dtb.
>>
>> OK. From memory when I did this, it was just a temporary file which
>> was used to create dts/dt.o. Make deleted it at the end of the build,
>> I think. But I may remember wrong, and it doesn't matter anyway.
>
> I think dts/dt.o was deleted at the end
> only when CONFIG_OF_SEPARATE=y
> by the following rule.
>
>   $(obj)u-boot.dtb:   checkdtc $(obj)u-boot
>   $(MAKE) $(build) dts binary
>   mv $(obj)dts/dt.dtb $@
>
> It moves, not copies dts/dt.dtb.
>
>
>> >
>> > Besides,  dts/dt.dtb is a prerequisite of dts/dt.dtb.S
>> > when CONFIG_OF_EMBED is enabled.
>> >
>> > I believe keeping dts/dt.dtb is reasonable enough.
>> >
>> > Better to keep both?
>>
>> Yes I think so.
>
>
> OK.
> I will revive ./u-boot.dtb and post a new version.
>
> And I will send it as a single patch
> dropping 2/3 and 3/3.
> Do you think it's better?
>
> Many kbuild-related patches are being stuck on patchwork
> and my local branch is getting messed up.
> I don't want to delay this patch any more.

Agreed, I look forward to all your series being merged, a bit step
forward for U-Boot.

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