Re: ELDK for Armv8.2

[Jerry Van Baren]

On Tue, Apr 5, 2022 at 8:52 AM Jerry Van Baren  wrote:

> Hi Ron,
>
> On Mon, Apr 4, 2022 at 7:12 PM Ron Eggler 
> wrote:
>
>> I'm working on a BSP that features the Reesas RZ/G2L & RZ/V2L CPUs which
>> have a Cortex-A55 core onthe  Arm8.2 architecture. I don't see it listed
>> under https://www.denx.de/wiki/view/ELDK-5/WebHome#Section_1.4. and was
>> wondering if there's a way to use ELDK for this Aarch64 architecture at
>> all?
>
>
Oh, and if you are only looking for an ARM cross compiler,
Debian/Ubuntu/variants have an apt package for that which includes all the
libraries and binutils etc.
(RedHat flavors probably do too)

$ apt-cache show gcc-aarch64-linux-gnu
Package: gcc-aarch64-linux-gnu
Architecture: amd64
Version: 4:9.3.0-1ubuntu2
Multi-Arch: foreign
Priority: optional
Section: devel
Source: gcc-defaults (1.185.1ubuntu2)
Origin: Ubuntu
Maintainer: Ubuntu Developers 
Original-Maintainer: Debian GCC Maintainers 
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 25
Depends: cpp-aarch64-linux-gnu (= 4:9.3.0-1ubuntu2),
gcc-9-aarch64-linux-gnu (>= 9.3.0-3~)
Recommends: libc6-dev-arm64-cross | libc-dev-arm64-cross
Suggests: make, manpages-dev, autoconf, automake, libtool, flex, bison,
gdb-aarch64-linux-gnu, gcc-doc
Filename:
pool/main/g/gcc-defaults/gcc-aarch64-linux-gnu_9.3.0-1ubuntu2_amd64.deb
Size: 1420
MD5sum: 73d8756bb50f915099c9d4abbf50ea6e
SHA1: bd4bf15585b764d788383dc1220e93222382bf8a
SHA256: aab6daa6ffcce913e148a0c07719dc918cb1bdc1e27fbb05fb3d3b85c518a0de
Description-en: GNU C compiler for the arm64 architecture
 This is the GNU C compiler, a fairly portable optimizing compiler for C.
 .
 This is a dependency package providing the default GNU C cross-compiler
 for the arm64 architecture.
Description-md5: 69df476a1d2ab9184e2d806ac537e77d

Re: ELDK for Armv8.2

[Jerry Van Baren]

Hi Ron,

On Mon, Apr 4, 2022 at 7:12 PM Ron Eggler  wrote:

> I'm working on a BSP that features the Reesas RZ/G2L & RZ/V2L CPUs which
> have a Cortex-A55 core onthe  Arm8.2 architecture. I don't see it listed
> under https://www.denx.de/wiki/view/ELDK-5/WebHome#Section_1.4. and was
> wondering if there's a way to use ELDK for this Aarch64 architecture at
> all?
>

I would recommend you use Buildroot  to build a
cross compiler and pretty much everything else you need to boot and run
linux (or your custom code) on your CPU. It takes a bit to configure it and
a while to build from scratch, but it works very well. Buildroot makes
building a cross compiler extremely simple. Building a whole (linux based)
system is complicated only because there are many, many choices to make -
the actual building is trivial.

gvb

Re: [PATCH] power: zynqmp: Add power domain driver for ZynqMP

[Jerry Van Baren]

Trivial English correction.

On Wed, Jan 19, 2022 at 6:04 AM Michal Simek 
wrote:

> Driver should be enabled by CONFIG_POWER_DOMAIN=y and
> CONFIG_ZYNQMP_POWER_DOMAIN=y. Power domain driver doesn't have own DT node
> but it uses zynqmp firmware DT node that's why there is a need to bind
> driver when firmware node is found.
>
> Driver itself is simple. It is sending pmufw config object overlay for
> enabling access to device which is done in ...domain_request().
> In ...domain_on() capabilities are passed and node is requested.
> This should be bare minimum of required to get power domain driver working.
>
> Signed-off-by: Michal Simek 
> ---
>
[snip]

> +static int zynqmp_firmware_bind(struct udevice *dev)
> +{
> +   int ret;
> +   struct udevice *child;
> +
> +   if (IS_ENABLED(CONFIG_ZYNQMP_POWER_DOMAIN)) {
> +   ret = device_bind_driver_to_node(dev,
> "zynqmp_power_domain",
> +"zynqmp_power_domain",
> +dev_ofnode(dev), &child);
> +   if (ret)
> +   printf("zynqmp power domain driver is not
> binded\n");
>
s/binded/bound/

> +   }
> +
> +   return dm_scan_fdt_dev(dev);
> +}
> +
>

[snip]

gvb

Re: Problem building u-boot

[Jerry Van Baren]

Hi Olivier,

On Wed, Feb 5, 2020 at 11:01 AM Olivier BERTON <
olivier.ber...@etu.univ-nantes.fr> wrote:

> Hi,
>
> I'm a student working on ZedBoard FPGA, and I have to install a custom
> Linux on the ZedBoard.
> I have to build u-boot, so I'm following this Wiki :
> https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841973/Build+U-Boot
> In the third command I have to enter "Make", and I get this error :
>
> cc1: error: bad value (‘generic-armv7-a’) for ‘-mtune=’ switch
> cc1: note: valid arguments to ‘-mtune=’ switch are: nocona core2 nehalem
> corei7 westmere sandybridge corei7-avx ivybridge core-avx-i haswell
> core-avx2 broadwell skylake skylake-avx512 bonnell atom silvermont slm knl
> intel x86-64 eden-x2 nano nano-1000 nano-2000 nano-3000 nano-x2 eden-x4
> nano-x4 k8 k8-sse3 opteron opteron-sse3 athlon64 athlon64-sse3 athlon-fx
> amdfam10 barcelona bdver1 bdver2 bdver3 bdver4 znver1 btver1 btver2
> generic
> Kbuild:43: recipe for target 'lib/asm-offsets.s' failed
> make[1]: *** [lib/asm-offsets.s] Error 1
> Makefile:1579: recipe for target 'prepare0' failed
> make: *** [prepare0] Error 2
>

You are using your default x86 compiler toolchain for the compiler. This
doesn't work because the ZedBoard is an ARM processor.

You need to install the ARM cross compiler toolchain and set CROSS_COMPILE
appropriately. For Ubuntu/apt based systems...
$ apt-get install crossbuild-essential-armhf
$ export CROSS_COMPILE=gcc-7-arm-linux-gnueabihf-

(The above may be inaccurate in its details because I did not actually
execute the commands on my computer.)

gvb

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

[Jerry Van Baren]

On 08/12/2013 12:35 PM, Simon Glass wrote:

Hi Jerry,

On Sat, Aug 10, 2013 at 7:21 AM, Jerry Van Baren mailto:gvb.ub...@gmail.com>> wrote:


[snip]


I also discovered the u-boot libfdt/fdt_wip.c has fdt_find_regions()
from Simon that isn't in the upstream dtc version.  I slipped up on
that one, I'll be looking into reconciling u-boot-fdt with the
upstream dtc.


I did start the work of upstreaming this, and an fdtgrep too to go with
it - you will see I think two versions of the patches on the
device-tree-discuss mailing list. At the time it was felt that it should
not go into the next release as it was not a small change. That release
(1.4) has gone out now so it is probably time to try again with that. I
have a few comments back and some adjustments to make.


Ahh, yes, I have been watching unfolding saga of fdtgrep, forgot this 
was connected.


Thanks,
gvb

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

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

[Jerry Van Baren]

Note: This is the license header change from Roger Meier (thanks), acked 
by Wolfgang.  While this will diverge our source a bit from the dtc 
upstream, I'm willing to live with that for now and indefinitely if 
necessary.


I would like to start a dialog with David Gibson and Jon Loeliger to see 
if they are interested in adopting the compact license IDs. 
Unfortunately, I've been buried at work and am going on vacation, so 
that will have to wait a bit.


I also discovered the u-boot libfdt/fdt_wip.c has fdt_find_regions() 
from Simon that isn't in the upstream dtc version.  I slipped up on that 
one, I'll be looking into reconciling u-boot-fdt with the upstream dtc.

=
commit 3e06cd1f97792b4bc3882de1ac99f031fb0eaa80
Author: Simon Glass 
Date:   Thu Jun 13 15:10:08 2013 -0700

libfdt: Add fdt_find_regions()

Add a function to find regions in device tree given a list of nodes to
include and properties to exclude.

See the header file for full documentation.

Signed-off-by: Simon Glass 
=

Best regards,
gvb


The following changes since commit a78dac79ede7fbb4c9e816abc879655540c3f076:

  nds32: fix the missing COBJS-y change (2013-08-09 01:51:24 +0800)

are available in the git repository at:

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

for you to fetch changes up to 35084760a9f492f29434020b64f1db339bf99a23:

  libfdt: SPDX-License-Identifier: GPL-2.0+ BSD-2-Clause (2013-08-10 
09:04:25 -0400)



Roger Meier (1):
  libfdt: SPDX-License-Identifier: GPL-2.0+ BSD-2-Clause

 Licenses/README  |   13 ++--
 Licenses/bsd-2-clause.txt|   25 ++
 lib/libfdt/fdt.c |   47 
+-
 lib/libfdt/fdt_empty_tree.c  |   47 
+-
 lib/libfdt/fdt_ro.c  |   47 
+-
 lib/libfdt/fdt_rw.c  |   47 
+-
 lib/libfdt/fdt_strerror.c|   47 
+-
 lib/libfdt/fdt_sw.c  |   47 
+-
 lib/libfdt/fdt_wip.c |   47 
+-
 lib/libfdt/libfdt_internal.h |   47 
+-

 10 files changed, 40 insertions(+), 374 deletions(-)
 create mode 100644 Licenses/bsd-2-clause.txt
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] fdt: remove unaligned access in fdt_fixup_ethernet()

[Jerry Van Baren]

Hi Stephen,

Sorry for not applying this in a timely manner.  Thanks, Tom, for 
covering for me.


gvb

On 06/07/2013 02:19 PM, Tom Rini wrote:

On Mon, May 27, 2013 at 06:01:19PM -, Stephen Warren wrote:


Some ARM compilers may emit code that makes unaligned accesses when
faced with constructs such as:

char mac[16] = "ethaddr";

Replace this with a strcpy() call instead to avoid this. strcpy() is
used here, rather than replacing all usage of the mac variable with the
string itself, since the loop itself sprintf()s to the variable each
iteration, so strcpy() is doing basically the same thing.

Reported-by: Florian Meier
Signed-off-by: Stephen Warren 


Applied to u-boot/master, thanks!


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

Re: [U-Boot] [PATCH] fdt: allow bootdelay to be specified via device tree

[Jerry Van Baren]

On 06/03/2013 11:05 AM, Stephen Warren wrote:

On 06/02/2013 06:44 AM, Gerald Van Baren wrote:

Hi Stephen,

On 06/02/2013 01:24 AM, Stephen Warren wrote:

On 05/14/2013 12:02 PM, Stephen Warren wrote:

From: Stephen Warren 

This can be useful to force bootcmd to execute as soon as U-Boot has
started.

My use-case is: An SoC-specific tool pushes U-Boot into RAM, along with
an image to be written to device boot flash, with the DT config property
"bootcmd" set to contain a command to write that image to flash. In this
scenario, we don't want to allow any stale bootdelay value taken from
the current flash content to affect how long it takes before the
flashing process starts.


Jerry, does this patch look OK, or do you have comments on it? Thanks.


I'm good with the patch.

Acked-by: Gerald Van Baren 


Oh, I'm not sure who you're expecting to apply this then; I assume since
it was a DT-related feature it'd be applied to your DT tree. Are you
expecting Tom Rini to apply it to the main U-Boot repo?


Ahh, one of those fuzzy gray areas... the patch is to main.c, I mostly 
focus on files in the libfdt subdirectory.  I can apply it via the FDT repo.


Tom Rini, do you have any preference?

The merge window closed May 11 and the original patch was emailed on May 
14... is it a candidate to go into the July 15 release?  It is a simple 
patch arguably fixing a bug, but it did miss the window.


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

Re: [U-Boot] [PATCH] fdt_support: Use CONFIG_NR_DRAM_BANKS if defined

[Jerry Van Baren]

On 05/17/2013 02:05 PM, Tom Rini wrote:

On Fri, May 17, 2013 at 09:59:23AM -0700, Doug Anderson wrote:

Tom,

On Fri, May 17, 2013 at 9:52 AM, Tom Rini  wrote:

Saw your reply but don't completely understand it.  I think we'd still
like U-Boot to populate the memory property if possible and it sounds
like your patch would prevent that.  One reason is that we'd like to
be able to handle different memory configurations (one of which is
3.5G) with a single binary and have U-Boot just tell the kernel how
much space there is.


So, I've been assuming that these are different platforms that you
already append different device trees on, so that you use the same
binary still and just different DTs.  Is that not the case here?


Current thought is that we'll even share a device tree between the two
boards since differences between the two are very minimal.  Sorta like
how you can buy a Galaxy Nexus with 8G or 16G.  They're the same
device (as far as I know) just with a different eMMC part stuffed on.


OK.  I'll pick up this patch then, thanks!


FWIIW...

Acked-by: Gerald Van Baren 

Thanks,
gvb


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

[U-Boot] Pull request: u-boot-fdt

[Jerry Van Baren]

Dear Tom,

The following changes since commit 2988eac70ead3720f9ec85a239cd06b2f7246683:

  Merge branch 'patman' of git://git.denx.de/u-boot-x86 (2013-05-10 
08:16:34 -0400)


are available in the git repository at:

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

for you to fetch changes up to bbd0f7e3ba66d288a2f146f1c7797801e04598ae:

  Move FDT_RAMDISK_OVERHEAD from fdt.h to libfdt_env.h (2013-05-10 
19:04:50 -0400)


Per my email and consensus, I have *not* included Simon's patch
  libfdt: Add fdt_next_subnode() to permit easy subnode iteration
which Tom has or will apply as part of Simon's full sandbox patchset.

Thanks,
gvb


François Revol (1):
  Fix typo

Gerald Van Baren (1):
  Move FDT_RAMDISK_OVERHEAD from fdt.h to libfdt_env.h

Justin Sobota (1):
  Added license header to dtc/libfdt/fdt.h and libfdt_env.h

Simon Glass (1):
  Export fdt_stringlist_contains()

 include/fdt.h|   53 
--

 include/libfdt.h |   16 ++-
 include/libfdt_env.h |3 +++
 lib/libfdt/fdt_ro.c  |5 ++---
 4 files changed, 71 insertions(+), 6 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 06/19] libfdt: Add fdt_next_subnode() to permit easy subnode iteration

[Jerry Van Baren]

Hi Simon,

On 05/07/2013 12:11 PM, Simon Glass wrote:

Iterating through subnodes with libfdt is a little painful to write as we
need something like this:


[snip]


Signed-off-by: Simon Glass 
(Cherry-picked from dtc commit 4e76ec79)


Acked-by: Gerald Van Baren 

Unless I hear otherwise, I'll drop this patch from my u-boot-fdt repo 
and let you (Tom?) apply it with the "sandbox" patch series since that 
is where it came from and where it logically belongs.



---
Changes in v4:
- Bring in upstream version of fdt_first/next_subnode()

Changes in v3: None
Changes in v2: None

  include/libfdt.h | 22 ++
  lib/libfdt/fdt.c | 28 
  2 files changed, 50 insertions(+)


Thanks,
gvb

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

Re: [U-Boot] [PATCH v3 12/17] Revert "fdt- Tell the FDT library where the device tree is"

[Jerry Van Baren]

On 04/20/2013 02:42 PM, Simon Glass wrote:

This reverts commit 3b73459ea3421e9f8c6c8c62e1d3fe458ca5bc56.

In practice it doesn't seem like a good idea to make the the working
FDT point to the control FDT. Now that we can access the control FDT
using the 'fdt' command, there is no need for this feature. Remove it.

Signed-off-by: Simon Glass 


Acked-by: Gerald Van Baren 


---
Changes in v3: None
Changes in v2:
- Revert the whole change including the set_working_fdt_addr() part

  common/main.c | 8 
  1 file changed, 8 deletions(-)


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

Re: [U-Boot] [PATCH v3 11/17] fdt: Skip checking FDT if the pointer is NULL

[Jerry Van Baren]

On 04/20/2013 02:42 PM, Simon Glass wrote:

If we have no FDT, don't attempt to read from it. This allows sandbox to
run without an FDT if required.

Signed-off-by: Simon Glass 


Acked-by: Gerald Van Baren 


---
Changes in v3: None
Changes in v2:
- Fix checkpatch checks about parenthesis alignment

  lib/fdtdec.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)


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

Re: [U-Boot] [PATCH v3 10/17] sandbox: fdt: Support fdt command for sandbox

[Jerry Van Baren]

On 04/20/2013 02:42 PM, Simon Glass wrote:

By using map_sysmem() we can get the fdt command to work correctly with
sandbox.

Signed-off-by: Simon Glass 


Acked-by: Gerald Van Baren 


---
Changes in v3: None
Changes in v2:
- Rebase to use updated fdt_valid() function

  common/cmd_fdt.c | 10 +++---
  1 file changed, 7 insertions(+), 3 deletions(-)


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

Re: [U-Boot] [PATCH v3 09/17] fdt: Allow fdt command to check and update control FDT

[Jerry Van Baren]

On 04/20/2013 02:42 PM, Simon Glass wrote:

There is an existing fdt command to deal with the working FDT. Enhance this
to support the control FDT also (CONFIG_OF_CONTROL).

Signed-off-by: Simon Glass 


Acked-by: Gerald Van Baren 


---
Changes in v3:
- Remove #ifdefs which are not needed now that we have generic global_data

Changes in v2:
- Correct bug in setting control FDT
- Fix checkpatch checks about parenthesis alignment

  common/cmd_fdt.c | 47 ++-
  1 file changed, 34 insertions(+), 13 deletions(-)


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

Re: [U-Boot] [PATCH v3 07/17] fdt: Add a parameter to fdt_valid()

[Jerry Van Baren]

On 04/20/2013 02:42 PM, Simon Glass wrote:

At present this only checks working_fdt, but we want to check other FDTs
also. So add the FDT to check as a parameter to fdt_valid().

Signed-off-by: Simon Glass 


Acked-by: Gerald Van Baren 


---
Changes in v3: None
Changes in v2:
- fdt_valid() sets the FDT pointer to NULL on error, to simplify callers
- Allow the control FDT to be set even if there is currently no control FDT

  common/cmd_fdt.c | 38 --
  1 file changed, 20 insertions(+), 18 deletions(-)


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

Re: [U-Boot] [PATCH] fdt: Ensure that libfdt_env.h comes from U-Boot

[Jerry Van Baren]

Hi Simon,

On 04/12/2013 04:24 PM, Simon Glass wrote:

Hi Tom / Jerry,


[snip]


Another way to fix this is to use -nostdinc and -idirafter to ensure that
system includes are included after U-Boot ones. Unfortunately this means
that U-Boot's errno.h gets included instead of the system one. This in
turn requires a hack to errno.h to redirect things, so all in all the
solution in this patch is probably cleaner.


[snip]


Can this be considered for the release please?


This appears to be a reasonable request to fix an outstanding bug.  I 
don't have time today or tomorrow, but I'll pull in your patch and move 
it forward, Tom willing.



Regards,
Simon


Thanks,
gvb


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

[U-Boot] [Pull] u-boot-fdt/master

[Jerry Van Baren]

Dear Tom,

Please pull u-boot-fdt.

Thanks,
gvb

The following changes since commit d62ef5619c9249772247d6af3b8e65207ae0c871:

  sf: stmicro: Add support for N25Q256A (2013-02-06 10:10:00 -0500)

are available in the git repository at:

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

for you to fetch changes up to 58864ddc7276ca7403ddbb716da5853638f37519:

  Clean up libfdt.h includes (2013-02-08 22:32:38 -0500)


Allen Martin (1):
  fdt: fix dts preprocessor options

Gerald Van Baren (1):
  Clean up libfdt.h includes

Kim Phillips (5):
  treewide: include libfdt_env.h before fdt.h
  libfdt_env.h: add fdt type definitions
  libfdt: update fdt.h from upstream dtc
  libfdt: update from upstream dtc commit 142419e
  common/fdt_support.c: sparse fixes

 arch/arm/lib/bootm.c |1 -
 arch/nios2/cpu/fdt.c |1 -
 arch/powerpc/cpu/mpc5xxx/cpu.c   |1 -
 arch/powerpc/cpu/mpc8260/cpu.c   |1 -
 arch/powerpc/cpu/mpc85xx/fdt.c   |2 +-
 arch/powerpc/cpu/mpc8xx/cpu.c|1 -
 arch/powerpc/cpu/ppc4xx/fdt.c|1 -
 arch/powerpc/lib/bootm.c |2 -
 arch/x86/include/asm/arch-coreboot/sysinfo.h |2 +-
 board/cm5200/cm5200.c|1 -
 common/cmd_bootm.c   |1 -
 common/cmd_fdt.c |1 -
 common/fdt_support.c |   87
++
 common/image.c   |1 -
 dts/Makefile |2 +-
 include/fdt.h|   42 ++---
 include/fdt_support.h|4 +-
 include/image.h  |1 -
 include/libfdt.h |   32 +-
 include/libfdt_env.h |5 ++
 lib/libfdt/fdt.c |2 +-
 lib/libfdt/fdt_ro.c  |2 +-
 lib/libfdt/fdt_rw.c  |4 +-
 lib/libfdt/fdt_sw.c  |4 +-
 lib/libfdt/fdt_wip.c |2 +-
 tools/fdt_host.h |1 -
 tools/imls/imls.c|1 -
 27 files changed, 101 insertions(+), 104 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] Clean up libfdt.h includes

[Jerry Van Baren]

The libfdt.h file is the definition file for libfdt.  It is unnecessary
to include other fdt header files (the necessary ones are pulled in
by libfdt.h).

Signed-off-by: Gerald Van Baren 
---

This comes from discussion on the Device Tree email list that 
is *the* user interface definition.

FWIIW, I proposed removing the redundant #includes in the libfdt source
too, but it hasn't been accepted by David Gibson yet.  He is open to the
concept but I have not pushed it forward to the point where he says
"yes" or "no".  I have the patch, but am holding it for when dtc/libfdt
accepts it (or not).

Best regards,
gvb

 arch/nios2/cpu/fdt.c |1 -
 arch/powerpc/cpu/mpc5xxx/cpu.c   |1 -
 arch/powerpc/cpu/mpc8260/cpu.c   |1 -
 arch/powerpc/cpu/mpc8xx/cpu.c|1 -
 arch/powerpc/cpu/ppc4xx/fdt.c|1 -
 arch/powerpc/lib/bootm.c |1 -
 arch/x86/include/asm/arch-coreboot/sysinfo.h |3 +--
 board/cm5200/cm5200.c|1 -
 include/fdt_support.h|3 +--
 9 files changed, 2 insertions(+), 11 deletions(-)

diff --git a/arch/nios2/cpu/fdt.c b/arch/nios2/cpu/fdt.c
index b1ed9e1..f238665 100644
--- a/arch/nios2/cpu/fdt.c
+++ b/arch/nios2/cpu/fdt.c
@@ -30,7 +30,6 @@

 #if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP)
 #include 
-#include 
 #include 

 DECLARE_GLOBAL_DATA_PTR;
diff --git a/arch/powerpc/cpu/mpc5xxx/cpu.c b/arch/powerpc/cpu/mpc5xxx/cpu.c
index 0c1eebd..dc021e3 100644
--- a/arch/powerpc/cpu/mpc5xxx/cpu.c
+++ b/arch/powerpc/cpu/mpc5xxx/cpu.c
@@ -36,7 +36,6 @@

 #if defined(CONFIG_OF_LIBFDT)
 #include 
-#include 
 #include 
 #endif

diff --git a/arch/powerpc/cpu/mpc8260/cpu.c b/arch/powerpc/cpu/mpc8260/cpu.c
index 220c1e2..f8bc5a9 100644
--- a/arch/powerpc/cpu/mpc8260/cpu.c
+++ b/arch/powerpc/cpu/mpc8260/cpu.c
@@ -50,7 +50,6 @@

 #if defined(CONFIG_OF_LIBFDT)
 #include 
-#include 
 #include 
 #endif

diff --git a/arch/powerpc/cpu/mpc8xx/cpu.c b/arch/powerpc/cpu/mpc8xx/cpu.c
index b3fcfe5..b6b733d 100644
--- a/arch/powerpc/cpu/mpc8xx/cpu.c
+++ b/arch/powerpc/cpu/mpc8xx/cpu.c
@@ -45,7 +45,6 @@

 #if defined(CONFIG_OF_LIBFDT)
 #include 
-#include 
 #include 
 #endif

diff --git a/arch/powerpc/cpu/ppc4xx/fdt.c b/arch/powerpc/cpu/ppc4xx/fdt.c
index 5ddb880..a94e82c 100644
--- a/arch/powerpc/cpu/ppc4xx/fdt.c
+++ b/arch/powerpc/cpu/ppc4xx/fdt.c
@@ -29,7 +29,6 @@

 #if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP)
 #include 
-#include 
 #include 
 #include 

diff --git a/arch/powerpc/lib/bootm.c b/arch/powerpc/lib/bootm.c
index 33d013f..0119a7b 100644
--- a/arch/powerpc/lib/bootm.c
+++ b/arch/powerpc/lib/bootm.c
@@ -38,7 +38,6 @@
 #if defined(CONFIG_OF_LIBFDT)
 #include 
 #include 
-
 #endif

 #ifdef CONFIG_SYS_INIT_RAM_LOCK
diff --git a/arch/x86/include/asm/arch-coreboot/sysinfo.h
b/arch/x86/include/asm/arch-coreboot/sysinfo.h
index bd88eb5..78d3a9d 100644
--- a/arch/x86/include/asm/arch-coreboot/sysinfo.h
+++ b/arch/x86/include/asm/arch-coreboot/sysinfo.h
@@ -32,8 +32,7 @@

 #include 
 #include 
-#include 
-#include 
+#include 
 #include 

 /* Allow a maximum of 16 memory range definitions. */
diff --git a/board/cm5200/cm5200.c b/board/cm5200/cm5200.c
index b25887b..c0ea1c6 100644
--- a/board/cm5200/cm5200.c
+++ b/board/cm5200/cm5200.c
@@ -44,7 +44,6 @@

 #ifdef CONFIG_OF_LIBFDT
 #include 
-#include 
 #include 
 #endif /* CONFIG_OF_LIBFDT */

diff --git a/include/fdt_support.h b/include/fdt_support.h
index 568bcbf..235 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -26,8 +26,7 @@

 #ifdef CONFIG_OF_LIBFDT

-#include 
-#include 
+#include 

 u32 fdt_getprop_u32_default(const void *fdt, const char *path,
const char *prop, const u32 dflt);
-- 
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/5] treewide: include libfdt_env.h before fdt.h

[Jerry Van Baren]

Hi Kim,

On 01/16/2013 06:59 PM, Kim Phillips wrote:
> and, if including libfdt.h which includes libfdt_env.h in
> the correct order, don't include fdt.h before libfdt.h.
> 
> this is needed to get the fdt type definitions set from
> the project environment before fdt.h uses them.
> 
> Signed-off-by: Kim Phillips 
> Cc: Jerry Van Baren 

Thanks, that was very helpful.  I applied the series to my personal
tree, will push when the dust settles.

I created a patch that uses just libfdt.h as the interface #include,
will publish when the dust settles on the dtc (device tree) list discussion.

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

Re: [U-Boot] [PATCH 1/5] treewide: include libfdt_env.h before fdt.h

[Jerry Van Baren]

Hi Scott, Kim, David,

On 01/17/2013 12:54 PM, Kim Phillips wrote:

On Wed, 16 Jan 2013 18:36:03 -0600
Scott Wood  wrote:


On 01/16/2013 05:59:04 PM, Kim Phillips wrote:

and, if including libfdt.h which includes libfdt_env.h in
the correct order, don't include fdt.h before libfdt.h.

this is needed to get the fdt type definitions set from
the project environment before fdt.h uses them.

Signed-off-by: Kim Phillips 
Cc: Jerry Van Baren 


Maybe fdt.h should include libfdt_env.h?

Or just always use libfdt.h as the public header.


Was just following along the same lines as the dtc commits 38ad79d3
"dtc/tests: don't include fdt.h prior to libfdt.h" and 20b866a7
"dtc/fdtdump: include libfdt_env.h prior to fdt.h", acked by David
G.  I don't know why some only include fdt.h.

devicetree-discuss/David: is there a prescribed way to go here?
Change all fdt.h includers to just always include libfdt.h instead
of libfdt_env.h prior to fdt.h?


I started applying Kim's "sparse" patches to the u-boot source and ran 
into this issue pretty hard.


In u-boot, there is an added complexity that the "tools" (host-based 
u-boot support tools) support flattened device trees, but explicitly 
include the u-boot version of libfdt declarations so they don't fall out 
of sync if the host has a non-compatible libfdt version.  Having them 
out of sync would be a *horrible* situation to sort out - everything 
would build OK but nothing would work right, probably with no useful 
diagnostic information.  This originated in 2008, so life may be better 
nowadays.  Or maybe not.


I would be in favor of explicitly including all the *fdt* headers in the 
sources.  Alternately, Scott's suggestion of just including libfdt.h as 
the public header seems good, but I'm pretty sure it will mess me up 
with the explicit #including in the host-based "tools" build, leaving us 
with nasty work-arounds or a risk of hard to identify incompatible host 
vs. u-boot fdt versions.


Who Includes Who

fdt.h - no includes

fdt_support.h - (u-boot only file)
  29 #include 

libfdt.h
  54 #include 
  55 #include 

libfdt_env.h
 - u-boot version is minimal, uses pre-existing macros for byte swapping
 - dtc version implements byte swapping, includes:
   4 #include 
   5 #include 
   6 #include 

libfdt_env.h is where Kim typedef'ed fdt16_t, fdt32_t, fdt64_t

I suspect the original intent was to have  be the file that 
people #included.  For whatever reason, most includes are (picking on 
fdt_ro.c arbitrarily):

  51 #include "libfdt_env.h"
  53 #include 
  54 #include 
Since libfdt.h #includes fdt.h and libfdt_env.h, lines 51 and 53 (above) 
are redundant.  It sorts out OK in dtc because libfdt_env.h includes 
stdint.h and defines fdt*_t, but it messes me up in u-boot where 
(currently) libfdt_env.h does *not* include stdint.h... and then things 
get really wonky in the u-boot "tools" directory due to the need to use 
the u-boot version of the *fdt*.h headers, not random stuff installed on 
the computer.


HTH,
gvb

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

[U-Boot] [Pull] u-boot-fdt/master

[Jerry Van Baren]

Dear Tom,

Please pull u-boot-fdt to fix the global_data compilation issue
introduced in "[PATCH 14/14] fdt: Set kernaddr if fdt indicates a kernel
is present" (identified by Dennis Lan).

Thanks,
gvb

The following changes since commit d41b3cc16fd97da23900f79e8fefdeedeebde8f6:

  Merge branch 'master' of git://git.denx.de/u-boot-mips (2012-11-27
20:34:51 -0700)

are available in the git repository at:


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

for you to fetch changes up to f39612d360c02ce97e7ca7a872693f348f7ec8fd:

  fdt: Correct global_data condition in main (2012-11-28 19:26:49 -0500)


Simon Glass (1):
  fdt: Correct global_data condition in main

 common/main.c |2 --
 1 file changed, 2 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] fdt: Correct global_data condition in main

[Jerry Van Baren]

Hi Simon,

On 11/28/2012 12:54 PM, Simon Glass wrote:
> We need an extra condition here in case we want to use fdt without the
> silent console/cmdline editing/post options. It is easier to just remove
> the #ifdef.
> 
> Signed-off-by: Simon Glass 
> ---
> Changes in v2:
> - Remove the #ifdef as it is getting out of hand
> 
>  common/main.c |2 --
>  1 files changed, 0 insertions(+), 2 deletions(-)
> 
> diff --git a/common/main.c b/common/main.c
> index 8052d42..5362781 100644
> --- a/common/main.c
> +++ b/common/main.c
> @@ -53,9 +53,7 @@
>  #include 
>  #include 
>  
> -#if defined(CONFIG_SILENT_CONSOLE) || defined(CONFIG_POST) || 
> defined(CONFIG_CMDLINE_EDITING)
>  DECLARE_GLOBAL_DATA_PTR;
> -#endif
>  
>  /*
>   * Board-specific Platform code can reimplement show_boot_progress () if 
> needed
> 

Applied to u-boot-fdt, pull request coming.

Thanks,
gvb

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

[U-Boot] Pull request: u-boot-fdt

[Jerry Van Baren]

Dear Tom,

Please pull u-boot-fdt.  These are the patches submitted by Simon Glass
and his compatriots prior to the v2013.01 merge window closing and are
thus eligible for inclusion in the v2013.01 release.

Thanks,
gvb

The following changes since commit 59852d03867108217fe88e3bfc3e1e9cedfe63c5:

  Merge branch 'master' of git://www.denx.de/git/u-boot-microblaze
(2012-11-09 08:47:25 -0700)

are available in the git repository at:

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

for you to fetch changes up to 008784765ab7f37fb355d5f7fb180661b94c42ab:

  fdt: Remove fdtdec_find_alias_node() function (2012-11-12 23:15:25 -0500)


Abhilash Kesavan (2):
  fdt: Add function to get config int from device tree
  fdt: Add function for decoding multiple gpios globally available

Che-Liang Chiou (2):
  fdt: Add fdtdec_get_uint64 to decode a 64-bit value from a property
  fdt: Load boot command from device tree

Doug Anderson (1):
  fdt: Allow device tree to specify secure booting

Gabe Black (3):
  fdt: Add function to read boolean property
  fdt: Tell the FDT library where the device tree is
  fdt: Add option to default to most compatible conf in a fit image

Gerald Van Baren (1):
  fdt: Export fdtdec_lookup() and fix the name

Sean Paul (1):
  fdt: Add polarity-aware gpio functions to fdtdec

Simon Glass (4):
  fdt: Add function to get a config string from device tree
  fdt: Add fdtdec_decode_region() to decode memory region
  fdt: Set kernaddr if fdt indicates a kernel is present
  fdt: Remove fdtdec_find_alias_node() function

 README |   11 +
 common/cmd_bootm.c |   11 +
 common/image.c |  127

 common/main.c  |  102 -
 include/fdtdec.h   |  112 +
 include/image.h|1 +
 lib/fdtdec.c   |  125
---
 7 files changed, 461 insertions(+), 28 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Custodian branch base commits

[Jerry Van Baren]

On 10/30/2012 06:20 PM, Stephen Warren wrote:
> On 10/30/2012 04:06 PM, Wolfgang Denk wrote:
>> Dear Stephen Warren,
>>
>> In message <5090423c.5070...@wwwdotorg.org> you wrote:
>>>
>>> git checkout master
>>> git reset --hard u-boot/master
>> ...
 Why don't you do just
git branch -D master
git checkout -b master u-boot/master
 instead?
>>>
>>> That would work identically. The exact git commands to do this really
>>> aren't the point of this conversation.
>>
>> Maybe not for you.  But I was trying to understand what you are doing,
>> and I find your approach difficult to read.  A "git reset --hard" is
>> nothign I ever do in the normal course of actions.
>>
 BTW - why are you doing this on the "master" branch?  Any other branch
 name appears more appropriate to me for such work?
>>>
>>> Well, the U-Boot wiki tells all custodians to use a branch named master,
>>> and all the custodian repos I've needed to look at follow this convention.
>>
>> You are supposed to _never_ reset or rebase the master branch.
> 
> I assume that statement is conditionalized by "within the U-Boot
> process" and "in the main u-boot.git repository"; it's not necessarily
> required to be true just due to use of git.
> 
> Well, even in recent history, that hasn't been actual practice. The wiki
> even explicitly tells you to rebase:
> 
> http://www.denx.de/wiki/U-Boot/CustodianGitTrees
> 
> Who owns updating that?

It's a wiki, *nobody* owns it. :-O

> I could take a stab, but since I'm pretty new to U-Boot development,
> not a custodian, and pushing for changes, I'm probably not the best
> person to re-write it, and least not without a 
> code-review/patch-based process.

I wrote the advice in 2007, relatively early days in our (u-boot's and
my) git usage.
  
It is definitely worth updating to recommend better techniques.

Best regards,
gvb

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

Re: [U-Boot] [PATCH 0/14] fdt: Add various device tree utilities and features

[Jerry Van Baren]

Dear Simon,

Sorry for being so late on this (the patches were submitted before the
merge window closed).  I've applied the patches to the "next" branch in
the u-boot-fdt repo.
  

I'm assuming these are still valid (Simon) and eligible to be applied to
the v2013.01 u-boot release (Tom).  If so, I'll submit a pull request.

On 10/25/2012 10:30 PM, Simon Glass wrote:
> This series contains a number of features related to CONFIG_OF_CONTROL,
> such as:
> 
> - reading fdt values
> - reading configuration from the fdt
> - allowing the fdt to specify a boot command

[snip]

>  README |   11 +
>  common/cmd_bootm.c |   11 +
>  common/image.c |  127 
> 
>  common/main.c  |  102 +-
>  include/fdtdec.h   |  121 +
>  include/image.h|1 +
>  lib/fdtdec.c   |  107 +---
>  7 files changed, 472 insertions(+), 8 deletions(-)

Again, my apologies,
gvb

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

Re: [U-Boot] [PATCH 1/2] libfdt: Add support for appending the values to a existing property

[Jerry Van Baren]

On 11/08/2012 08:41 PM, Kim Phillips wrote:
> On Sat, 15 Sep 2012 10:36:28 -0400
> Jerry Van Baren  wrote:
> 
>> On 08/27/2012 08:38 PM, Kim Phillips wrote:
>>> From: Minghuan Lian 
>>>
>>> Some properties may contain multiple values, these values may need
>>> to be added to the property respectively. this patch provides this
>>> functionality. The main purpose of fdt_append_prop() is to append
>>> the values to a existing property, or create a new property if it
>>> dose not exist.
>>>
>>> Signed-off-by: Minghuan Lian 
>>> Signed-off-by: David Gibson 
>>
>> Queued up 2 of 2 patches to the u-boot-fdt "next" branch.  I'll issue a
>> pull request when the merge window opens.
> 
> the merge window closed five days ago, and these didn't make it in.
> What's the deal?
> 
> Kim

It's in there:
<http://git.denx.de/?p=u-boot.git;a=commit;h=36ad18a6db0eec546b83e6500ceb7593be53a1ed>

I sent a pull request Mon, Oct 22, 2012 and Tom applied it on Oct 23:
-
David Gibson (1):
  libfdt: Add helpers for 64-bit integer properties

Gerald Van Baren (2):
  libfdt: Add helper function to create a trivial, empty tree
  Merge branch 'next'

Joe Hershberger (5):
  fdt: Check error codes returned from fdtlib when loading ITB
  fdt: Limit printed hex in fdt print and list commands
  fdt: Add get commands to fdt
  fdt: Identify scripts in ITBs as printable strings
  fdt: Check for a token to skip auto-hash validation

Minghuan Lian (1):
  libfdt: Add support for appending the values to a existing property
-

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

Re: [U-Boot] [U-Boot, 2/6] fdt: Limit printed hex in fdt print and list commands

[Jerry Van Baren]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Tom, Joe,

On 10/25/2012 04:59 PM, Tom Rini wrote:
> On Fri, Aug 17, 2012 at 10:34:36AM -, Joe Hershberger wrote:
> 
>> Prevent printing the entire image in a itb. It is most likely 
>> unhelpful to have the hex of the entire image scroll for minutes 
>> on your slow serial console.
>> 
>> Signed-off-by: Joe Hershberger 
> 
> This causes: $ uboot-build.sh sandboxTesting sandbox on 
> -4-gf0a29d4 Thu Oct 25 13:59:03 MST 2012 Configuring for 
> sandbox board... textdata bss dec hex filename 
> 1402456332   28472  175049   2abc9 sandbox/u-boot cmd_fdt.c:
> In function 'print_data': cmd_fdt.c:679:32: warning: cast from
> pointer to integer of different size [-Wpointer-to-int-cast] 
> cmd_fdt.c:691:32: warning: cast from pointer to integer of 
> different size [-Wpointer-to-int-cast]

Sorry, I should have caught that and the 3/6 warning. :-(

I'm tied up with a flight test through Friday (Nov 2) which has been
consuming all my available time.  Joe, can you look at fixing the
warnings?

Thanks,
gvb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQEcBAEBAgAGBQJQjdPPAAoJEGOcKeGailWqeSMH/itjpDTCi/dNf3wdDHImpTev
r9A7Ygk01eLhPWlLX5sV9+GziO1x1s8Z9mRbpdIBz4NeA5vaB79wS3D2/S06dxh8
DeSlk3U8eo4tNiI9OysDDp5IyxNXEmje4KkOD8snLIeYKV3/1RDPQYzsLrzlGVJ6
dFjPGNHmjLWzMi4kOSR34b6SIl1xPCUtBUgMfMTN6R8S5JLuJKSn/WUUcXtHpras
yKYfvs1ULkmMg4aEbKzCWFa/a/JJK+XlxU4XQX2Xd7HSISg0eIoOJSV5khTCG8gR
SVCkbF89+XO749a9xL3jyTEz1xMPqFO3KugbnyZGtsOm87VWyuZ/qzR4KdC2rJA=
=ox6g
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [fdt] Pull request

[Jerry Van Baren]

Dear Tom,

The following changes since commit bcf28c23f2195a91e0713337934f630a9c7bc5a9:

  ARM : Remove unused CONFIG_DRIVER_SMC9, CONFIG_DRIVER_LAN91C96
(2012-10-22 08:33:52 -0700)

are available in the git repository at:

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

for you to fetch changes up to cae4a8a2a81ca6cd16d5de1b55d47e315cbff05a:

  Merge branch 'next' (2012-10-22 20:42:09 -0400)



David Gibson (1):
  libfdt: Add helpers for 64-bit integer properties

Gerald Van Baren (2):
  libfdt: Add helper function to create a trivial, empty tree
  Merge branch 'next'

Joe Hershberger (5):
  fdt: Check error codes returned from fdtlib when loading ITB
  fdt: Limit printed hex in fdt print and list commands
  fdt: Add get commands to fdt
  fdt: Identify scripts in ITBs as printable strings
  fdt: Check for a token to skip auto-hash validation

Minghuan Lian (1):
  libfdt: Add support for appending the values to a existing property

 common/cmd_fdt.c|  186 ++---
 common/image.c  |   46 
 include/image.h |4 +
 include/libfdt.h|  275
---
 lib/libfdt/Makefile |2 +-
 lib/libfdt/fdt_empty_tree.c |   84 +
 lib/libfdt/fdt_rw.c |   27 +
 7 files changed, 592 insertions(+), 32 deletions(-)
 create mode 100644 lib/libfdt/fdt_empty_tree.c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 00/32] Initial sparse fix series

[Jerry Van Baren]

Hi David, Jon,

Kim Phillips created a series of patches to change variable declarations
that are big endian to be __be32/__be64.  Since the device tree is
defined to be big endian, he created a patch to mark the appropriate
libfdt entities as __be*.

On 10/16/2012 08:28 PM, Kim Phillips wrote:
> This 32-patch series only begins to address making u-boot source more
> 'sparseable,' or sparse-clean, ultimately to catch type, address space,
> and endianness mismatches and generally improve code quality. E.g., in this
> initial dose whose main purpose is to reduce the output volume to workable
> levels, a couple of endianness bugs are found and fixed in
> of_bus_default_translate() and fdt_get_base_address().  See [PATCH 14/32]
> common/fdt_support.c: sparse fixes.

Upside: This is very good for identifying endian errors early.
Downside: It could break/complicate non-linux uses of libfdt.

What are your thoughts on this quest?

[snip]

> Note that there are two libfdt dependencies:

[snipped #1, u-boot-fdt dependency, NBD]

> 2. potential upstream dtc change dependencies, due to having to attribute base
> device tree header types to __be32 in include/libfdt.  See patch 19/32
> "include/fdt.h: sparse fixes".  It is unknown whether such changes would
> be welcome to dtc (but there's a way to find out :).

[snip]

> Build-tested in both endians :).  Please help test.
> 
> Thanks,
> 
> Kim

Below is the actual patch for reference (it was in a separate email).
The impact in terms of changed lines is pretty small.  I'm not sure how
this impacts non-linux / non-gcc systems since the sparse checker comes
from a linux background and uses gcc extensions.

Possibly this could be handled a definition:

#ifndef _LINUX_TYPES_H
typedef uint32_t __be32
typedef uint64_t __be64
#endif

>  include/fdt.h | 33 +
>  include/fdt_support.h |  2 ++
>  include/libfdt.h  |  4 ++--
>  lib/libfdt/fdt.c  |  2 +-
>  lib/libfdt/fdt_ro.c   |  2 +-
>  lib/libfdt/fdt_rw.c   |  4 ++--
>  lib/libfdt/fdt_sw.c   |  4 ++--
>  lib/libfdt/fdt_wip.c  |  2 +-
>  8 files changed, 28 insertions(+), 25 deletions(-)
> 
> diff --git a/include/fdt.h b/include/fdt.h
> index c51212e..1b7f044 100644
> --- a/include/fdt.h
> +++ b/include/fdt.h
> @@ -2,40 +2,41 @@
>  #define _FDT_H
>  
>  #ifndef __ASSEMBLY__
> +#include 
>  
>  struct fdt_header {
> - uint32_t magic;  /* magic word FDT_MAGIC */
> - uint32_t totalsize;  /* total size of DT block */
> - uint32_t off_dt_struct;  /* offset to structure */
> - uint32_t off_dt_strings; /* offset to strings */
> - uint32_t off_mem_rsvmap; /* offset to memory reserve map */
> - uint32_t version;/* format version */
> - uint32_t last_comp_version;  /* last compatible version */
> + __be32 magic;/* magic word FDT_MAGIC */
> + __be32 totalsize;/* total size of DT block */
> + __be32 off_dt_struct;/* offset to structure */
> + __be32 off_dt_strings;   /* offset to strings */
> + __be32 off_mem_rsvmap;   /* offset to memory reserve map */
> + __be32 version;  /* format version */
> + __be32 last_comp_version;/* last compatible version */
>  
>   /* version 2 fields below */
> - uint32_t boot_cpuid_phys;/* Which physical CPU id we're
> + __be32 boot_cpuid_phys;  /* Which physical CPU id we're
>   booting on */
>   /* version 3 fields below */
> - uint32_t size_dt_strings;/* size of the strings block */
> + __be32 size_dt_strings;  /* size of the strings block */
>  
>   /* version 17 fields below */
> - uint32_t size_dt_struct; /* size of the structure block */
> + __be32 size_dt_struct;   /* size of the structure block */
>  };
>  
>  struct fdt_reserve_entry {
> - uint64_t address;
> - uint64_t size;
> + __be64 address;
> + __be64 size;
>  };
>  
>  struct fdt_node_header {
> - uint32_t tag;
> + __be32 tag;
>   char name[0];
>  };
>  
>  struct fdt_property {
> - uint32_t tag;
> - uint32_t len;
> - uint32_t nameoff;
> + __be32 tag;
> + __be32 len;
> + __be32 nameoff;
>   char data[0];
>  };
>  
> diff --git a/include/fdt_support.h b/include/fdt_support.h
> index 2e18d82..399b73f 100644
> --- a/include/fdt_support.h
> +++ b/include/fdt_support.h
> @@ -81,7 +81,9 @@ int fdt_pci_dma_ranges(void *blob, int phb_off, struct 
> pci_controller *hose);
>  #ifdef CONFIG_OF_BOARD_SETUP
>  void ft_board_setup(void *blob, bd_t *bd);
>  void ft_cpu_setup(void *blob, bd_t *bd);
> +void ft_fixup_num_cores(void *blob);
>  void ft_pci_setup(void *blob, bd_t *bd);
> +void ft_srio_setup(void *blob);
>  #endif
>  
>  void set_working_fdt_addr(void *addr);
> diff --git a/include/libfdt.h b/include/libfdt.h
> index 4589c5f..ab98d23 100644
> --- a/include/libf

Re: [U-Boot] [PATCH - resend due to bounce] libfdt: Add fdt functionality for more intuitive

[Jerry Van Baren]

Hi Peter,

On 05/07/2012 09:52 AM, Peter Feuerer wrote:
> libfdt: Add fdt functionality for more intuitive fdt handling
> 
> New functions:
> fdt_read - retrieve the value of a property by full path
> fdt_write - create or change a property with full path and create subnodes if 
> needed
> fdt_create_path - create subnode path with parents
> 
> Signed-off-by: Peter Feuerer 
> CC: David Gibson 
> CC: Gerald Van Baren 

As David pointed out, this needs to go through the upstream libfdt (dtc)
library so that we stay in sync.



Thanks,
gvb

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

Re: [U-Boot] mips port

[Jerry Van Baren]

On 10/06/2012 09:11 PM, Dmytro Milinevskyy wrote:
> Hi,
> I'm new to uboot mips port and first decided to try it with qemu.

Welcome.  :-)

> I've encountered some problems with UART, but I guess that's more qemu
> issue(lsr reg is not updated when the line is available).
> 
> Another issue I faced was code execution after the relocation is done. The
> address of board_init_r is not computed correctly(it was relative to boot
> ROM address space/bfc0).
> Is it specific to qemu(I don't see the reference here though) or is it a
> generic mips port issue? Attached patch allows me to proceed with the boot
> in qemu.
> 
> And last - why do we need relocation at all with u-boot? Performance
> constraints?

Generally, yes.  Flash is very often slower than RAM (often 8 bits width
vs. 32 bits or more, generally doesn't support bursting, the processor
cache may not work with it, etc.).

A side benefit of running out of RAM is that it makes it much easier to
write to flash... you don't have to worry about writing to the chip you
are executing out of (when you erase/write flash, the chip returns a
"programming in progress" status until it is done - that will crash your
program if you are running out of that chip).

> Thanks,
> -- dmytro

Best regards,
gvb

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

Re: [U-Boot] [PATCH 1/6] fdt: Check error codes returned from fdtlib when loading ITB

[Jerry Van Baren]

Hi Joe, Tom,

On 10/04/2012 01:38 PM, Joe Hershberger wrote:
> Hi Jerry,
> 
> On Fri, Aug 17, 2012 at 3:34 PM, Joe Hershberger  
> wrote:
>> Before this patch, error codes returned from fdtlib were ignored and
>> continued access would cause a crash. Now just check if the image is
>> truncated and error if so.
>>
>> Signed-off-by: Joe Hershberger 
>> ---
> 
> What's the progress on this series?  I know Mike didn't like the last
> patch (6 of 6), but the first 5 should be good to go.  I'd like them
> to be in the 2012.10 release.
> 
> Are you able to apply them through your branch?  Or maybe ack and go
> through Tom?

The first 5 of the series look good to me.  #1 and #5 touch image.c
which is on the fringe of my FDT mandate.

Tom, do you want to pick the changes up?  Unless you object, I'll apply
them to the fdt subrepo and submit a pull request when the window opens.

> Thanks,
> -Joe

Thanks,
gvb

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

Re: [U-Boot] [PATCH 1/2] libfdt: Add support for appending the values to a existing property

[Jerry Van Baren]

On 09/15/2012 11:00 AM, Tabi Timur-B04825 wrote:
> On Sat, Sep 15, 2012 at 9:36 AM, Jerry Van Baren  wrote:
> 
>> Queued up 2 of 2 patches to the u-boot-fdt "next" branch.  I'll issue a
>> pull request when the merge window opens.
> 
> I thought libfdt patches were suppose to go to dtc.git?

That is where they came from.  Since the u-boot libfdt is a subset of
the whole dtc.git repository (just the libfdt part), I've been cherry
picking only the libfdt/* patches (with the help of others).

I see David has another patch for the libfdt library that I probably
should pick up so that we stay in sync (18 lines of code by counting
semicolons).

commit be6026838e45b67800ac803f4ad8cca3cde57d6d
Author: David Gibson 
Date:   Fri Jun 1 14:12:38 2012 +1000

libfdt: Add helper function to create a trivial, empty tree

The libfdt read/write functions are now usable enough that it's become a
moderately common pattern to use them to build and manipulate a device
tree from scratch.  For example, we do so ourself in our rw_tree1
testcase,
and qemu is starting to use this model when building device trees
for some
targets such as e500.

However, the read/write functions require some sort of valid tree to
begin
with, so this necessitates either having a trivial canned dtb to
begin with
or, more commonly, creating an empty tree using the serial-write
functions
first.

This patch adds a helper function which uses the serial-write
functions to
create a trivial, empty but complete and valid tree in a supplied
buffer,
ready for manipulation with the read/write functions.

Signed-off-by: David Gibson 


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

Re: [U-Boot] [PATCH 1/2] libfdt: Add support for appending the values to a existing property

[Jerry Van Baren]

On 08/27/2012 08:38 PM, Kim Phillips wrote:
> From: Minghuan Lian 
> 
> Some properties may contain multiple values, these values may need
> to be added to the property respectively. this patch provides this
> functionality. The main purpose of fdt_append_prop() is to append
> the values to a existing property, or create a new property if it
> dose not exist.
> 
> Signed-off-by: Minghuan Lian 
> Signed-off-by: David Gibson 

Queued up 2 of 2 patches to the u-boot-fdt "next" branch.  I'll issue a
pull request when the merge window opens.

Thanks,
gvb

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

[U-Boot] Pull request: u-boot-fdt

[Jerry Van Baren]

Dear Tom,

Please pull u-boot-fdt.  This contains the FDT null address bug fix from
Marek.

Thanks,
gvb

P.S. Tom - Resent because I sent to the list from the wrong email account.

The following changes since commit a6f0c4faa4c65a7b7048b12c9d180d7e1aad1721:

  Merge branch 'master' of git://git.denx.de/u-boot-avr32 (2012-09-04
09:17:27 +0200)

are available in the git repository at:


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

for you to fetch changes up to e02c9458748a59e5d80649deb5e40f96ed992bb5:

  fdt: Check if the FDT address is configured (2012-09-15 09:16:08 -0400)


Marek Vasut (1):
  fdt: Check if the FDT address is configured

 common/cmd_fdt.c |   13 -
 1 file changed, 12 insertions(+), 1 deletion(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] fdt: Check if the FDT address is configured

[Jerry Van Baren]

On 09/05/2012 02:34 AM, Marek Vasut wrote:
> In case the "fdt addr" command wasn't ran yet and any other "fdt"
> subcommand was issued, the system crashed due to NULL pointer being
> used.
> 
> This is caused by "fdt addr" command setting up a pointer to the
> FDT memory location. Prior issuing "fdt addr", the pointer is NULL
> so calling any other subcommands crashed the u-boot.
> 
> Signed-off-by: Marek Vasut 
> Cc: Simon Glass 

Applied and sent a pull request to Tom Rini.

Thanks,
gvb

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

Re: [U-Boot] [PATCH] fdt: Check if the FDT address is configured

[Jerry Van Baren]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/13/2012 01:37 PM, Tom Rini wrote:
> On Thu, Sep 13, 2012 at 10:30:29AM +0200, Marek Vasut wrote:
>> Dear Jerry Van Baren,
>> 
>>> Hi Marek,
>>> 
>>> I'll queue this up this weekend.
>>> 
>>> The merge window for v2012.10 closed September 18.  Unless
>>> there is an overriding urgency, the patch will go into the
>>> following release.
>> 
>> It's a fix, I'd say queue it for current release. Only fixes go
>> into current release after MW closed.
> 
> I second what Marek says, this is a bugfix, so lets get it into
> the release.  Thanks!

OK, will do.

Thanks,
gvb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQEcBAEBAgAGBQJQUlsqAAoJEGOcKeGailWqg5QH/1MaQYApeanym3uyMEC4Mjm8
Yc+Tjozb6l3UbnptMLdsH5WT+BexrcyVn8YsgkSCELtTByKPDZIHIQH7KFfttCd5
ZzU/roLZbE0fJmlzaTcSI9fL4+I4ZhgSGhRneQH6zsejOhWuxM0Jv7k43cTk3g0K
75ItdSHc9g7QB1zd0r6HMw7cEKOni4nbzv/ZimHvFgJDo1pUCr1Myee6o7DucqcO
3fMEx8HDH7VW3HFepJb1yN3LI1FIeNc3BBD5rbaVOyTmg5qnbmNa9kEiOGXxmuDA
tAoOo8IraN63XULYXCEpgIrxJ6pb8c7ULdkHyPw2YfEDvgGixDW8HbAa0aqfm9A=
=mvwF
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] fdt: Check if the FDT address is configured

[Jerry Van Baren]

Hi Marek,

I'll queue this up this weekend.

The merge window for v2012.10 closed September 18.  Unless there is an
overriding urgency, the patch will go into the following release.

On 09/05/2012 02:34 AM, Marek Vasut wrote:
> In case the "fdt addr" command wasn't ran yet and any other "fdt"
> subcommand was issued, the system crashed due to NULL pointer being
> used.
> 
> This is caused by "fdt addr" command setting up a pointer to the
> FDT memory location. Prior issuing "fdt addr", the pointer is NULL
> so calling any other subcommands crashed the u-boot.
> 
> Signed-off-by: Marek Vasut 
> Cc: Simon Glass 
> ---
>  common/cmd_fdt.c |   13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> Note: Damn, I'm falling asleep already :-( I hope the text above at
>   least makes sense though.
> 
> diff --git a/common/cmd_fdt.c b/common/cmd_fdt.c
> index 9a5c53e..e2225c4 100644
> --- a/common/cmd_fdt.c
> +++ b/common/cmd_fdt.c
> @@ -114,10 +114,21 @@ int do_fdt (cmd_tbl_t * cmdtp, int flag, int argc, char 
> * const argv[])
>   }
>   }
>  
> + return CMD_RET_SUCCESS;
> + }
> +
> + if (!working_fdt) {
> + puts(
> + "No FDT memory address configured. Please configure\n"
> + "the FDT address via \"fdt addr \" command.\n"
> + "Aborting!\n");
> + return CMD_RET_FAILURE;
> + }
> +
>   /*
>* Move the working_fdt
>*/
> - } else if (strncmp(argv[1], "mo", 2) == 0) {
> + if (strncmp(argv[1], "mo", 2) == 0) {
>   struct fdt_header *newaddr;
>   int  len;
>   int  err;
> 

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

Re: [U-Boot] [PATCH 1/2] libfdt: Add support for appending the values to a existing property

[Jerry Van Baren]

Hi Kim, Minghuan,

On 09/12/2012 08:08 PM, Kim Phillips wrote:
> On Mon, 27 Aug 2012 19:38:59 -0500
> Kim Phillips  wrote:
> 
>> From: Minghuan Lian 
>>
>> Some properties may contain multiple values, these values may need
>> to be added to the property respectively. this patch provides this
>> functionality. The main purpose of fdt_append_prop() is to append
>> the values to a existing property, or create a new property if it
>> dose not exist.
>>
>> Signed-off-by: Minghuan Lian 
>> Signed-off-by: David Gibson 
>> ---
> 
> Jerry, can you take a look at applying these?

Yes, I'll queue them up this weekend.

I'll also queue Marek Vasut  patch "[U-Boot] [PATCH] fdt:
Check if the FDT address is configured"

The merge window for v2012.10 closed September 18.  Unless there is an
overriding urgency, the patches will go into the following release.

> Thanks,
> Kim

Best regards,
gvb

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

Re: [U-Boot] Strange / Unreadable console output

[Jerry Van Baren]

On 08/13/2012 07:17 AM, Markus Hubig wrote:
> On Sat, Aug 11, 2012 at 08:15:43AM -0400, Jerry Van Baren wrote:
>> On 07/27/2012 05:16 AM, Markus Hubig wrote:
>>> one minor Problem I often read about in this list is some crappy / 
>>> unreadable
>>> console output at beginning of the U-Boot start procedure. Now I have the 
>>> same
>>> "visual" Problem.
>>>
>>> | H�NAND:  128 MiB
>>> | *** Warning - bad CRC, using default environment
>>> | 
>>> | In:serial
>>> | Out:   serial
>>> | Err:   serial
>>> | Net:   macb0
>>> | macb0: Starting autonegotiation...
>>> | macb0: Autonegotiation timed out (status=0x7849)
>>> | macb0: link down (status: 0x7849)
>>> | Hit any key to stop autoboot:  0 
>>> | ...
>>>
>>> Sometimes I get a good readable output, which looks like so:
>>>
>>> | U-Boot 2012.04.01-3-gab465ef-dirty (Jul 23 2012 - 14:44:29)
>>> | 
>>> | U-Boot code: 23F0 -> 23F30464  BSS: -> 23F72128
>>> | CPU: AT91SAM9G20
>>> | Crystal frequency:   18.432 MHz
>>> | CPU clock:  396.288 MHz
>>> | Master clock :  132.096 MHz
>>> | RAM Configuration:
>>> | Bank #0: 2000 64 MiB
>>> | WARNING: Caches not enabled
>>> | NAND:  128 MiB
>>> | ...

[snip]

>> 2) The line before the garbled output becomes readable is "WARNING:
>> Caches not enabled".  Does (your) at91bootstrap enable caches?  If so,
>> does it disable them before jumping to u-boot?  When the output is
>> garbled, does it say "WARNING: Caches not enabled" or is that line
>> missing???
> 
> Hmm the only reverence I found related to caches in the at91bootstrap
> code I use (https://bitbucket.org/imko/at91bootstrap) is in crt0_gnu.S.
> 
> There are some lines disabling the cache but only if I enable Thump
> support, which I don't ... but I'll try this.

Good test, although it likely will change the system timing.  The really
worst case is that the problem is still lurking, but changing the boot
timing hides it. :-/

>> A classic way for UARTs to be garbled is to inadvertently cache their
>> registers.  This shows up on start up because typically caching is "all
>> or nothing" until the MMU is fully configured (MMU configuration is
>> complex).
> 
> OK. But is enabling the caches in context of u-boot/bootstrap generally
> a good thing to do?

Enabling caches is a very good thing to do for speed, especially if you
are copying a flash image to RAM, but you pay a price in complexity.
Enabling code cache is generally safe (the only time you get into
problems is self-modifying code - probably why "thump" support disables
the cache).  Enabling data caches is good for memory operations, but
will bite you if you inadvertently cache hardware registers.

A fairly common technique is to enable data caches during heavy memory
read/write operations (copies, checksum/hash verifications, etc.) and
then disable it.

>> When your program reads the "TxReady" flag, in this scenario it gets a
>> cached value of the status register that a always says "ready" even
>> though the hardware isn't ready at all.  The result is all bytes get
>> immediately crammed into the Tx register, overwriting the previous byte
>> and garbling it.
>>
>> If you get lucky and the UART status register isn't cached (or is cached
>> "not ready" but the Tx routine has a timeout so it writes the byte to
>> the Tx register anyway), the UART works properly and the output isn't
>> garbled.
> 
> OK good to know, I'm running a bit out of time at the moment course of
> my thesis, but I'll definitely will have a look at this in detail when
> I'm finished.

Making sure cache is disabled when exiting the bootstrap loader to
u-boot should be reasonably easy to do (make sure you flush the data
cache before disabling it).  That and a few reboots should give you a
good indication if that is indeed your problem.

> Cheers, Markus

Good luck on the thesis,
gvb

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

Re: [U-Boot] Is there file size limiation of tftp

[Jerry Van Baren]

On 08/11/2012 09:21 PM, J.Hwan Kim wrote:
> Hi, everyone
> 
> Is there any limit of file size for tftpboot?
> I have a problem downloading the file of which file size is 65MB.
> The procedure stops in the middle of downloading.
> 
> Thanks in advnace.
> 
> Best Regards,
> J.Hwan Kim
> 
> -
> 
> # tftp 0xc000 192.168.100.10:system.img
> smc911x: detected LAN9221 controller
> smc911x: phy initialized
> smc911x: MAC c3ea1460M (00405c260a5b)
> TFTP from server 192.168.100.10; our IP address is 192.168.100.50
> Filename 'system.img'.
> Load address: 0xc000

Probably what Mike said.  Note that 64MB is 0x4000 and your load
address is 0xC000... add the two together and you get 0x1__
which is a very suspicious number.

Having said that, there are two places where TFTP implementations have
problems.  The block number is a 16 bit unsigned integer.

The easier (and less often problematic) one is where the block number
goes from 0x7FFF to 0x8000.  If an implementation erroneously treats the
block number as a *signed* integer, it will screw that up.

The second size limit stumbling block is when the block number hits
0x, what is the next block number?  Some implementations just give
up and limit the maximum file size to 64K-1 blocks[1].  If your block
size is the default 512, that makes the maximum file size 32MB.  If your
block size is 4K, it will make the maximum file size 256MB.

RFC1350[2] is silent on the issue, probably because the authors never
considered using TFTP with files bigger than 32MB.  TFTP does use block
number 0 in a special way to ACK the write request and says "block
numbers are consecutive and begin with one."  The simpler and more
intuitive interpretation of 0x + 1 is to wrap to 0x.  The less
intuitive one that honors 0 being special is to wrap to 0x0001.

U-Boot wraps to 0, see net/tftp.c function update_block_number().  Your
TFTP server needs to do the same.

Best regards,
gvb

Ref:
[1] 
[2] 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Strange / Unreadable console output

[Jerry Van Baren]

Hi Markus,

On 07/27/2012 05:16 AM, Markus Hubig wrote:
> Hi @all,
> 
> one minor Problem I often read about in this list is some crappy / unreadable
> console output at beginning of the U-Boot start procedure. Now I have the same
> "visual" Problem.
> 
> | H�NAND:  128 MiB
> | *** Warning - bad CRC, using default environment
> | 
> | In:serial
> | Out:   serial
> | Err:   serial
> | Net:   macb0
> | macb0: Starting autonegotiation...
> | macb0: Autonegotiation timed out (status=0x7849)
> | macb0: link down (status: 0x7849)
> | Hit any key to stop autoboot:  0 
> | ...
> 
> Sometimes I get a good readable output, which looks like so:
> 
> | U-Boot 2012.04.01-3-gab465ef-dirty (Jul 23 2012 - 14:44:29)
> | 
> | U-Boot code: 23F0 -> 23F30464  BSS: -> 23F72128
> | CPU: AT91SAM9G20
> | Crystal frequency:   18.432 MHz
> | CPU clock:  396.288 MHz
> | Master clock :  132.096 MHz
> | RAM Configuration:
> | Bank #0: 2000 64 MiB
> | WARNING: Caches not enabled
> | NAND:  128 MiB
> | ...
> 
> Has anyone an idea how to fix this?

No. :-)

>  Or what's the cause of it?

The UART is being mishandled, either directly or indirectly, e.g. due to
caching issues or maybe the UART block isn't configured properly.

> Is it even related to u-boot or is it something at91bootstrap is
> doing wrong?

Yes. :-)

Questions / observations:
1) When the output is garbled, is it always associated with the line
"*** Warning - bad CRC, using default environment" and not garbled if
the environment is OK?  That would indicate it is a configuration issue
with the default environment.  It could also indicate a caching problem
(see next), where your environment is obscured by an enabled cache.

2) The line before the garbled output becomes readable is "WARNING:
Caches not enabled".  Does (your) at91bootstrap enable caches?  If so,
does it disable them before jumping to u-boot?  When the output is
garbled, does it say "WARNING: Caches not enabled" or is that line
missing???

A classic way for UARTs to be garbled is to inadvertently cache their
registers.  This shows up on start up because typically caching is "all
or nothing" until the MMU is fully configured (MMU configuration is
complex).

When your program reads the "TxReady" flag, in this scenario it gets a
cached value of the status register that a always says "ready" even
though the hardware isn't ready at all.  The result is all bytes get
immediately crammed into the Tx register, overwriting the previous byte
and garbling it.

If you get lucky and the UART status register isn't cached (or is cached
"not ready" but the Tx routine has a timeout so it writes the byte to
the Tx register anyway), the UART works properly and the output isn't
garbled.

> Cheers, Markus

Good luck, and let us know what you learn,
gvb

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

Re: [U-Boot] [PATCH] AVR32 removal due to lack of custodian.

[Jerry Van Baren]

Hi Wolfgang,

On 02/25/2012 05:13 PM, Wolfgang Denk wrote:

AVR32 appaers to be unmaintained, and nobody appears to care about
that.  Let's get rid fof it.

Signed-off-by: Wolfgang Denk
---
  doc/feature-removal-schedule.txt |7 ++
  1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/doc/feature-removal-schedule.txt b/doc/feature-removal-schedule.txt
index e04ba2d..f0b828e 100644
--- a/doc/feature-removal-schedule.txt
+++ b/doc/feature-removal-schedule.txt
@@ -7,6 +7,20 @@ file.

  ---

+What:  ARV32 Support


FWIIW, typo: s/ARV/AVR/


+When:  v2012.06
+Why:   Lack of a custodian and of interest, and lack of time and/or sponsors.
+Who:   Wolfgang Denk
+
+---
+
  What: Users of the legacy miiphy_* code
  When: undetermined



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

Re: [U-Boot] fdt patches for Tegra

[Jerry Van Baren]

On 01/19/2012 06:40 PM, Tom Warren wrote:
> Folks,
> 
> Simon and Stephen have been talking offline about Simon's fdt
> patches, to wit:
> 
> U-Boot-v3-1-2-fdt-Add-fdtdec_find_aliases-to-deal-with-alias-nodes.patch
> U-Boot-v3-2-2-fdt-Add-tests-for-fdtdec.patch
> U-Boot-v4-01-20-fdt-Tidy-up-a-few-fdtdec-problems.patch
> U-Boot-v4-02-20-fdt-Add-functions-to-access-phandles-arrays-and-bools.patch
> 
> We'd like to add these to the Tegra repo (u-boot-tegra), since it's
> the forerunner for DT stuff in U-Boot. Stephen has Acked them, but
> he'd like to see them reviewed by the device tree maintainer.
> 
> Jerry - can you take a look and give these an Acked-by if the look
> good to you? I believe Simon CC'd you on most, if not all of them. Or
> if there are other opinions on how and where these should go in,
> please let me know.

They look good to me, I acked them.  Inclusion via the Tegra repo sounds
like a good plan to me.

> Thanks,
> Tom

Thanks,
gvb

P.S. to the direct recipients, sorry for the double send, I forgot to
use my u-boot subscription source email address.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 1/2] fdt: Add fdtdec_find_aliases() to deal with alias nodes

[Jerry Van Baren]

On 01/17/2012 01:20 PM, Simon Glass wrote:
> Stephen Warren pointed out that we should use nodes whether or not they
> have an alias in the /aliases section. The aliases section specifies the
> order so far as it can, but is not essential. Operating without alisses

Nitpick: aliases

> is useful when the enumerated order of nodes does not matter (admittedly
> rare in U-Boot).
> 
> This is considerably more complex, and it is important to keep this
> complexity out of driver code. This patch creates a function
> fdtdec_find_aliases() which returns an ordered list of node offsets
> for a particular compatible ID, taking account of alias nodes.
> 
> Signed-off-by: Simon Glass

Acked-by: Gerald Van Baren 

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

Re: [U-Boot] [PATCH v3 2/2] fdt: Add tests for fdtdec

[Jerry Van Baren]

On 01/17/2012 01:20 PM, Simon Glass wrote:
> The fdtdec_find_aliases_for_id() function is complicated enough that
> it really should have some tests. This does not necessarily need to be
> committed to U-Boot, but it might be useful.
> 
> (note there are a few minor inconsistencies with this patch which will be
> cleaned up when the USB series is applied)
> 
> Signed-off-by: Simon Glass

Acked-by: Gerald Van Baren 

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

Re: [U-Boot] [PATCH v4 01/20] fdt: Tidy up a few fdtdec problems

[Jerry Van Baren]

On 01/11/2012 11:32 PM, Simon Glass wrote:
> This fixes five trivial issues in fdtdec.c:
> 1. fdtdec_get_is_enabled() doesn't really need a default value
> 2. The fdt must be word-aligned, since otherwise it will fail on ARM
> 3. The compat_names[] array is missing its first element. This is needed
> only because the first fdt_compat_id is defined to be invalid.
> 4. Added a header prototype for fdtdec_next_compatible()
> 5. Change fdtdec_next_alias() to only increment its 'upto' parameter
> on success, to make the display error messages in the caller easier.
> 
> Signed-off-by: Simon Glass

Acked-by: Gerald Van Baren 

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

Re: [U-Boot] [PATCH v4 02/20] fdt: Add functions to access phandles, arrays and bools

[Jerry Van Baren]

On 01/11/2012 11:32 PM, Simon Glass wrote:
> Add a function to look up a property which is a phandle in a node, and
> another to read a fixed-length integer array from an fdt property.
> Also add a function to read boolean properties, although there is no
> actual boolean type in U-Boot.
> 
> Signed-off-by: Simon Glass

Acked-by: Gerald Van Baren 

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

Re: [U-Boot] fdt patches for Tegra

[Jerry Van Baren]

On 01/19/2012 06:40 PM, Tom Warren wrote:

Folks,

Simon and Stephen have been talking offline about Simon's fdt patches, to wit:

U-Boot-v3-1-2-fdt-Add-fdtdec_find_aliases-to-deal-with-alias-nodes.patch
U-Boot-v3-2-2-fdt-Add-tests-for-fdtdec.patch
U-Boot-v4-01-20-fdt-Tidy-up-a-few-fdtdec-problems.patch
U-Boot-v4-02-20-fdt-Add-functions-to-access-phandles-arrays-and-bools.patch

We'd like to add these to the Tegra repo (u-boot-tegra), since it's
the forerunner for DT stuff in U-Boot. Stephen has Acked them, but
he'd like to see them reviewed by the device tree maintainer.

Jerry - can you take a look and give these an Acked-by if the look
good to you? I believe Simon CC'd you on most, if not all of them. Or
if there are other opinions on how and where these should go in,
please let me know.


Yes, I've seen he's been spamm^W working hard. ;-)  They've been putting 
in lot of effort, but interesting.  I'll review and ack the patchsets.



Thanks,
Tom


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

Re: [U-Boot] [PATCH] arm, fdt: update ethernet mac address before booting Linux

[Jerry Van Baren]

Hi Heiko,

On 12/14/2011 04:39 AM, Heiko Schocher wrote:

Hello Albert, Gerald,

Heiko Schocher wrote:

Signed-off-by: Heiko Schocher
Cc: Albert ARIBAUD
Cc: Gerald van Baren
---
  arch/arm/lib/bootm.c |2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 802e833..afa0093 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -206,6 +206,8 @@ static int bootm_linux_fdt(int machid, bootm_headers_t 
*images)

fixup_memory_node(*of_flat_tree);

+   fdt_fixup_ethernet(*of_flat_tree);
+
fdt_initrd(*of_flat_tree, *initrd_start, *initrd_end, 1);

announce_and_cleanup();


Some comments on this patch? Can it go in, in the current release?


I would defer to Albert, it is in his domain (ARM).


bye,
Heiko


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

Re: [U-Boot] [PATCH 02/14] fdt: Add functions to access phandles, arrays and bools

[Jerry Van Baren]

On 12/01/2011 11:58 PM, Simon Glass wrote:

Hi Jerry,

On Thu, Dec 1, 2011 at 7:33 PM, Jerry Van Baren  wrote:


[snip]


FDT helper functions have been accumulating in common/fdt_support.c rather
than a separate file.  Simon, what is the history of lib/fdtdec.c?  Is it a
shared file from the linux kernel?  If it is u-boot specific, it would
probably be better to add the functions to fdt_support.c.


There are sort-of two FDT strands within U-Boot. The main one is
support for putting together an FDT to pass to the kernel (cmd_fdt,
fdt_support), and the other is for U-Boot's own use (run-time
configuration of U-Boot, fdtdec). They both use libfdt.

I regard fdt_support as part of the former, and fdtdec (decode-only
helper functions) as part of the latter. At present when you turn on
CONFIG_OF_LIBFDT you get everything, but we could provide finer
granularity for platforms which only want to decode an FDT for
run-time config and don't want to mess with it. Since fdt_decode is
about 6KB of code that might be useful.


Ahh, I see.  I have not been closely tracking the u-boot config (fdtdec) 
improvements, so I did not recognize it as being part of that effort. 
That makes sense.


Thanks,
gvb

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

Re: [U-Boot] [PATCH 02/14] fdt: Add functions to access phandles, arrays and bools

[Jerry Van Baren]

On 11/28/2011 01:41 PM, Stephen Warren wrote:

On 11/23/2011 08:54 PM, Simon Glass wrote:

Add a function to lookup a property which is a phandle in a node, and
another to read a fixed-length integer array from an fdt property.
Also add a function to read boolean properties.

Signed-off-by: Simon Glass


Looking at the U-Boot custodians web page, you need to send the core DT
changes (well, probably anything DT related) to Jerry Van Baren.


Yeah, I saw the patch go by.  I did not recognize the file it patched 
and looked at the history:


commit b5220bc6ed6e6a197adf4926958dca1df4b420b0
Author: Simon Glass 
Date:   Mon Oct 24 19:15:32 2011 +

fdt: add decode helper library

This library provides useful functions to drivers which want to use
the fdt to control their operation. Functions are provided to:
:
:

and the copyright is "Copyright (c) 2011 The Chromium OS Authors."

FDT helper functions have been accumulating in common/fdt_support.c 
rather than a separate file.  Simon, what is the history of 
lib/fdtdec.c?  Is it a shared file from the linux kernel?  If it is 
u-boot specific, it would probably be better to add the functions to 
fdt_support.c.


In the same vein, I also have not looked at the functions provided by 
fdtdec.c to see if there is any overlap with existing fdt_support.c 
functions (a quick look says not).


Best regards,
gvb

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

Re: [U-Boot] [u-boot]automatic reset of variables to defaults

[Jerry Van Baren]

On 11/17/2011 10:46 AM, Dennis Borgmann wrote:
> Hello u-boot users list,
>
> I am experiencing a problem concerning variables being set and later
> getting lost.

This sounds like your environment variables in flash got erased or 
corrupted.  The question is why.

Where is your u-boot env being saved?  Normal flash?  I2C-attached 
flash?  Other?  (I2C flash is inherently less robust than we like due to 
weaknesses in the protocol.)

I am assuming normal flash...
* Do you have flash write protection enabled (prevents inadvertent flash 
scribbling, especially a problem if your linux or programs are not stable).

* Do you understand your flash memory layout (can you draw a diagram of 
it)?  Is something like a flash file system inadvertently overlayed on 
top of the u-boot env?  If you have a flash file system inadvertently 
configured to use the same memory space as your u-boot env, it will 
"randomly" overwrite it based on file activity.

* Do you use linux utilities to read/write your u-boot env?

When the failure occurs, what does the memory dump of the actual u-boot 
flash storage area look like?  Quite often the overwrite pattern leaves 
valuable clues as to who did it.

* If it is all 0xFF, someone just erased it.

* If some bits are set to zero that should be ones, someone probably did 
an inadvertent write to the memory (writing a '0' to a '1' bit turns it 
to a '0', writing a '0' or '1' to a '0' bit doesn't change it).

* Does it look like file data?

[snip]

> Annoyingly, I cannot surely reproduce this error. I tried rebooting it
> over 3 days in 2-minute-steps and the error won't occur. In addition, I
> tried giving random input to the console of u-boot for 3 days (again in
> 2-minute-steps) and still the error won't come up.

We've all been there and feel your pain. :-(

> Two questions:
>
> 1. What else might be the cause of this?

Someone (likely software, possibly hardware) is corrupting or erasing 
your u-boot env storage in flash.

> 2. How could I prevent u-boot from resetting to its default value?

Fix whoever is doing the scribbling.  There is no other way.

> I'd be happy for any kind of help.
>
> Best regards,
> Dennis

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

Re: [U-Boot] [PATCH] [fdt] Fix constness of the fdt void pointer in fdt_getprop_u32_default

[Jerry Van Baren]

On 11/08/2011 04:09 AM, Gabe Black wrote:
> The function fdt_getprop_u32_default doesn't modify the fdt, so it can use a
> const void * for its fdt argument.
>
> Signed-off-by: Gabe Black

Applied and requested a bugfix pull.

Thanks,
gvb


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

Re: [U-Boot] [PATCH] Add some missing endian conversions in fdt_support.c

[Jerry Van Baren]

On 11/08/2011 04:05 AM, Gabe Black wrote:
> Some functions in fdt_support.c use fdt_getprop to read 32 bit values out of
> the device tree, but then use them directly without doing any endian
> conversion. Because they check for a value that doesn't actually appear in
> practice, the functions continued to work even though they're incorrect.
> This change adds the missing conversions.
>
> Signed-off-by: Gabe Black
> ---
>   common/fdt_support.c |4 ++--
>   1 files changed, 2 insertions(+), 2 deletions(-)

Applied and requested a bugfix pull.

Thanks,
gvb

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

[U-Boot] Pull request: u-boot-fdt

[Jerry Van Baren]

Dear Wolfgang,

Please pull the bugfixes from the following changes since commit 
5721385b187b3154c7768e6c182501022f4e2e45:

   Merge branch 'master' of git://git.denx.de/u-boot-mpc83xx (2011-11-08 
07:44:52 +0100)

are available in the git repository at:

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

Gabe Black (2):
   Add some missing endian conversions in fdt_support.c
   Fix constness of the fdt void pointer in fdt_getprop_u32_default

  common/fdt_support.c  |8 
  include/fdt_support.h |4 ++--
  2 files changed, 6 insertions(+), 6 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] fdt: check for fdt errors in fdt_create_phandle

[Jerry Van Baren]

On 09/20/2011 07:24 PM, Timur Tabi wrote:
> fdt_create_phandle() was ignoring errors from fdt_set_phandle().  If an
> error occurs, print an error message and return 0, which is an invalid
> phandle.  We also need to change the return type for fdt_create_phandle()
> to indicate that it cannot return an error code.
>
> Signed-off-by: Timur Tabi
> ---
>   common/fdt_support.c  |   11 +--
>   include/fdt_support.h |2 +-
>   2 files changed, 10 insertions(+), 3 deletions(-)

Added to u-boot-fdt, sent a pull request to wd.

Thanks,
gvb

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

Re: [U-Boot] [PATCH 1/2 v6] fdt: Add a do_fixup_by_path_string() function

[Jerry Van Baren]

On 08/30/2011 10:36 PM, Chunhe Lan wrote:
> The do_fixup_by_path_string() will set the specified node's property to the
> value contained in "status". It would just be an inline wrapper for
> do_fixup_by_path() that calls strlen on the argument.
>
> Signed-off-by: Chunhe Lan

Added to u-boot-fdt, sent a pull request to wd.

Thanks,
gvb

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

[U-Boot] Pull request: u-boot-fdt

[Jerry Van Baren]

The following changes since commit d8fffa057c9430fd0c5104ab6ff7db4cdb03db51:

   Merge branch 'master' of git://git.denx.de/u-boot-mips (2011-10-12 
22:47:15 +0200)

are available in the git repository at:

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

Chunhe Lan (1):
   fdt: Add a do_fixup_by_path_string() function

Timur Tabi (3):
   fdt: check for fdt errors in fdt_create_phandle
   fdt: update fdt_alloc_phandle to use fdt_get_phandle
   powerpc/85xx: use fdt_create_phandle() to create the Fman 
firmware phandles

  arch/powerpc/cpu/mpc85xx/fdt.c |5 ++---
  common/fdt_support.c   |   18 +++---
  include/fdt_support.h  |9 -
  3 files changed, 21 insertions(+), 11 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] fdt: Add new fdt_set_node_status & fdt_set_status_by_alias helpers

[Jerry Van Baren]

Hi Kumar, Shengzhou,

On 10/14/2011 03:10 PM, Kumar Gala wrote:
> From: Shengzhou Liu
>
> Add common function fdt_set_node_status() to assist in various locations
> that we set a nodes status.  This function utilizes the status values
> that are part of the EPAPR spec (on power.org).
>
> fdt_set_status_by_alias() is based on fdt_set_node_status() but uses an
> alias string to identify the node to update.
>
> We also add some shortcut functions to help the common cases of setting
> "okay" and "disabled":
>
>   fdt_status_okay()
>   fdt_status_disabled()
>   fdt_status_okay_by_alias()
>   fdt_status_disabled_by_alias()
>
> Finally, we fixup the corenet_ds ethernet code which previously had
> a function by the same name that can be replaced with the new helpers.
>
> Signed-off-by: Shengzhou Liu
> Signed-off-by: Kumar Gala
> ---
>   board/freescale/corenet_ds/eth_hydra.c |   26 ++
>   board/freescale/corenet_ds/eth_p4080.c |   36 +--
>   common/fdt_support.c   |   60 
> +++-
>   include/fdt_support.h  |   28 +++
>   4 files changed, 101 insertions(+), 49 deletions(-)

While this touches fdt_support.[ch] which is nominally "mine", it is 
coupled with the Freescale support.  I could make you break it into two, 
but then I would have to do more work and you (and wd) would have to 
make sure they went into u-boot in the right order.  That sounds ugly, 
so I would prefer Kumar apply it to his subrepo to feed into u-boot.

Acked-by: Gerald Van Baren 

Best regards,
gvb

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

Re: [U-Boot] [RFC PATCH 0/4] Run-time configuration of U-Boot via a flat device tree (fdt)

[Jerry Van Baren]

Hi Simon,

On 09/01/2011 04:49 PM, Simon Glass wrote:
> At present in U-Boot configuration is mostly done using CONFIG options in the
> board file. This patch set aims to make it possible for a single U-Boot
> binary to support multiple boards, with the exact configuration of each board
> controlled by a flat device tree (fdt). This is the approach recently taken
> by the ARM Linux kernel and has been used by PowerPC for some time.

Very exciting.  I've thought about doing this for years, but never had 
the ambition (or time).

[snip]

> and add some defines to your board (only ARM is currently supported):
>
>   #define CONFIG_OF_CONTROL   (to enable run-time config control via fdt)
>   #define CONFIG_OF_EMBED or CONFIG_OF_SEPARATE
>   (either build the fdt blob into U-Boot, or create a separate u-boot.dtb)
>   #define CONFIG_DEFAULT_DEVICE_TREE  ""
>   (to specify the name of the device tree file is
>board///.dts)
>
> This patch set does not include any drivers which actually use the fdt. I have
> some concerns about spreading fdt code around the U-Boot code base so am
> thinking of having a support file which makes this easier. I can provide a
> UART driver modified to use fdt if there is interest.

Please.  A concrete reference is very useful, especially for discussion.

> It is important to understand that the fdt only selects options available in
> the platform / drivers. It cannot add new drivers (yet). So you must still
> have the CONFIG option to enable the driver. For example, you need to define
> CONFIG_SYS_NS16550 to bring in the NS16550 driver, but can use the fdt to
> specific the UART clock, peripheral address, etc. In very broad terms, the
> CONFIG options in general control *what* driver files are pulled in, and the
> fdt controls *how* those files work.

Sounds reasonable and practical.  One of the things u-boot struggles 
with is staying small (but it is nice to be able to make it all 
inclusive and big if you have the flash).

> While only ARM is supported in this patch series, it should be easy enough to
> add support for other architectures.

Exercise left for the students.  :-)

[snip]

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

Re: [U-Boot] Porting U-Boot to HP TouchPad

[Jerry Van Baren]

On 08/22/2011 01:11 AM, Graeme Russ wrote:
> Hello All,
>
> Well it looks like I'm getting my hands on the now defunct HP
> Touchpad

Lucky!

> Any ideas how I could port U-Boot (and ultimately Linux) to it?

There is a fair amount of talk about installing various flavors of linux 
(including Android) on the touchpad, e.g.



> Regards,
> Graeme

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

Re: [U-Boot] [PATCH 1/2 v3] fdt: Add a do_fixup_by_path_string() function

[Jerry Van Baren]

Hi Chunhe Lan,

On 08/17/2011 02:24 AM, Chunhe Lan wrote:

[snip]

> +
> +static inline void do_fixup_by_path_string(void *fdt, const char *path,
> +const char *prop, const char *status)
> +{
> + do_fixup_by_path(fdt, path, prop, status, strlen(status) + 1, 1);
> +}
> +

After all the good advice from Scott et al., the patch turns into a 
pretty trivial one-liner.  I am questioning the advantage of calling
   do_fixup_by_path_string(fdt, path, prop, status);
vs. simply calling
   do_fixup_by_path(fdt, path, prop, status, strlen(status) + 1, 1);

The do_fixup_by_path_string() saves two parameters
   "strlen(status) + 1, 1"
at the cost of Yet Another Function.  Is it worth it?

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

Re: [U-Boot] Need answers of basic questions regarding u-boot

[Jerry Van Baren]

On 08/07/2011 02:55 PM, Rakesh Modi wrote:
> Hi,
> I am new to linux and u-boot. Please answer my following questions.
> 1) what is u-boot? why it require?

It initializes and configures the hardware (processor, RAM, 
peripherals), it loads linux (or other OS) from storage (flash, hard 
drive, ethernet, other) into RAM and then passes control to linux.

While it isn't required, it is very convenient to have it.  The other 
features of u-boot are that u-boot can be used to load new linux images 
into your storage device.  The general principle is that u-boot is not 
often replaced on a board, but the linux image is updated and upgraded 
regularly.

> 2) why we can not load linux kernel directly without use of u-boot?

You can, but you need to do the hardware initialization and 
configuration in the linux start up code.  You will also have to create 
a method to and mechanism for linux to upgrade itself, preferably in a 
"failure resistant" way so that you don't "brick" your board 
inadvertently by having a failure when upgrading linux.

U-boot has solved these problems already for you.

> 3) How does any processor sequence starts when power is on?

That is described in the processor hardware reference manual.  It is 
different for each processor, but in general the processor starts 
fetching and executing code from a known location - sometimes from a 
fixed memory address, sometimes it fetches a pointer from a fixed memory 
address and starts executing from the address pointed to.

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

Re: [U-Boot] [PATCH 2/2] fdt: Add new fdt_create_phandle helper

[Jerry Van Baren]

On 08/01/2011 02:23 AM, Kumar Gala wrote:
> Add a helper function that will return a phandle value for the given
> node.  If the node doesn't have a phandle already one will be created.
>
> Signed-off-by: Kumar Gala

Acked-by: Gerald Van Baren 

> ---
>   common/fdt_support.c  |   20 
>   include/fdt_support.h |1 +
>   2 files changed, 21 insertions(+), 0 deletions(-)

[snip]

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

Re: [U-Boot] [PATCH 1/2] fdt: Rename fdt_create_phandle to fdt_set_phandle

[Jerry Van Baren]

On 08/01/2011 02:23 AM, Kumar Gala wrote:
> The old fdt_create_phandle didn't actually create a phandle it just
> set one.  We'll introduce a new helper that actually does creation.
>
> Signed-off-by: Kumar Gala

Acked-by: Gerald Van Baren 

> ---
>   arch/powerpc/cpu/mpc85xx/portals.c |2 +-
>   common/fdt_support.c   |6 +++---
>   include/fdt_support.h  |2 +-
>   3 files changed, 5 insertions(+), 5 deletions(-)

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

[U-Boot] [GIT pull] Please pull u-boot-fdt

[Jerry Van Baren]

Dear Wolfgang...

The following changes since commit 68d4230c3ccce96a72c5b99e48399bf1796fe3c6:
   Ramneek Mehresh (1):
 powerpc/85xx: Add default usb mode and phy type to hwconfig

are available in the git repository at:

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

David A. Long (1):
   Add uboot "fdt_high" enviroment variable

David Gibson (2):
   Support ePAPR compliant phandle properties
   libfdt: Implement property iteration functions

Gerald Van Baren (1):
   fdt: introduce fdt_create_phandle()

Timur Tabi (2):
   fdt: introduce fdt_verify_alias_address() and fdt_get_base_address()
   fdt: add prototype for fdt_increase_size()

  README   |9 +++
  common/fdt_support.c |  107 +
  common/image.c   |   60 +---
  include/fdt_support.h|6 ++
  include/libfdt.h |  103 +++
  lib/libfdt/fdt.c |9 +++
  lib/libfdt/fdt_ro.c  |  156 
++---
  lib/libfdt/libfdt_internal.h |1 +
  8 files changed, 398 insertions(+), 53 deletions(-)

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

Re: [U-Boot] [uboot PATCH v2] Add uboot "fdt_high" enviroment variable

[Jerry Van Baren]

On 07/09/2011 04:40 PM, David A. Long wrote:
> From: David A. Long
>
> Add a new "fdt_high" enviroment variable. This can be used to control (or 
> prevent) the
> relocation of the flattened device tree on boot. It can be used to prevent 
> relocation
> of the fdt into highmem.  The variable behaves similarly to the existing 
> "initrd_high"
> variable.
>
> Signed-off-by: David A. Long

While I agree in principle with Scott's point that it would be good to 
understand and fix/improve the ARM bootm_linux_fdt() function, I have 
bought into Dave's argument that this is a useful environment variable 
and is symmetric with "initrd_high".

Consequently, I've added this patch to the u-boot-fdt repo.  If anyone 
has strong objects, now is the time to object strongly. ;-)

Thanks,
gvb

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

Re: [U-Boot] Please update libfdt for U-Boot

[Jerry Van Baren]

On 06/29/2011 03:41 PM, Jerry Van Baren wrote:
> Hi Timur,
>
> On 06/29/2011 03:40 PM, Tabi Timur-B04825 wrote:
>> Jerry,
>>
>> Now that the merge window is open, could you please update libfdt?
>> The version in U-Boot hasn't been updated in over a year, and there
>> are new features that I need to have.  Specifically, this commit:
>> http://git.jdl.com/gitweb/?p=dtc.git;a=commit;h=d75b33af676d0beac8398651a7f09037555a550b

I've imported two patches from the upstream libfdt (aka. dtc) repository:
David Gibsonlibfdt: Implement property iteration functions
David GibsonSupport ePAPR compliant phandle properties

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

Re: [U-Boot] [PATCH 1/2] fdt: introduce fdt_create_phandle()

[Jerry Van Baren]

On 05/10/2011 04:14 PM, Timur Tabi wrote:
> The ePAPR specification says that phandle properties should be called
> "phandle", and not "linux,phandle".  To facilitate the migration from
> "linux,phandle" to "phandle", introduce function fdt_create_phandle(), which
> creates a phandle in a given node.  For now, we create both the "phandle" and
> "linux,phandle" properties.  A later version of this function will remove
> support for "linux,phandle".
>
> Signed-off-by: Timur Tabi
> ---
>   common/fdt_support.c  |   40 
>   include/fdt_support.h |1 +
>   2 files changed, 41 insertions(+), 0 deletions(-)

Applied to u-boot-fdt.

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

Re: [U-Boot] [PATCH 1/2] fdt: add prototype for fdt_increase_size()

[Jerry Van Baren]

On 05/03/2011 02:35 PM, Timur Tabi wrote:
> Add a prototype for fdt_increase_size() so that anyone can call it.
>
> Signed-off-by: Timur Tabi
> ---
>   include/fdt_support.h |1 +
>   1 files changed, 1 insertions(+), 0 deletions(-)

Applied to u-boot-fdt.

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

Re: [U-Boot] [PATCH 1/2] [v2] fdt: introduce fdt_verify_alias_address() and fdt_get_base_address()

[Jerry Van Baren]

On 05/03/2011 02:24 PM, Timur Tabi wrote:
> Introduce two functions, fdt_verify_alias_address() and 
> fdt_get_base_address(),
> which can be used to verify the physical address of a device in a device tree.
>
> fdt_get_base_address() returns the base address of an SOC or PCI node.
>
> fdt_verify_alias_address() prints a message if the address of a node specified
> by an alias does not match the given physical address.
>
> Signed-off-by: Timur Tabi

Applied to u-boot-fdt.

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

Re: [U-Boot] [PATCH] powerpc: Fix device tree padding associated with ramdisk

[Jerry Van Baren]

Hi Kumar, Wolfgang

On 07/06/2011 09:16 PM, Kumar Gala wrote:
> When booting with a ramdisk we bump the amount of memory reserved for
> the device tree by FDT_RAMDISK_OVERHEAD.  However we did not increase
> the actual size in the device tree blob to match.
>
> Its possible on boundary cases that we dont have enough memory according
> to the device tree blob and get errors like:
>
> WARNING: could not set linux,initrd-end FDT_ERR_NOSPACE
>
> We can easily fix this by setting the device tree size at the same time
> we bump the amount of memory reserved for the device tree.
>
> Signed-off-by: Kumar Gala
> ---
>   arch/powerpc/lib/bootm.c |4 +++-
>   1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/lib/bootm.c b/arch/powerpc/lib/bootm.c
> index e01787d..4e0cb8f 100644
> --- a/arch/powerpc/lib/bootm.c
> +++ b/arch/powerpc/lib/bootm.c
> @@ -288,8 +288,10 @@ static int boot_body_linux(bootm_headers_t *images)
>   return ret;
>   of_size = ret;
>
> - if (*initrd_start&&  *initrd_end)
> + if (*initrd_start&&  *initrd_end) {
>   of_size += FDT_RAMDISK_OVERHEAD;
> + fdt_set_totalsize(*of_flat_tree, of_size);
> + }
>   /* Create a new LMB reservation */
>   lmb_reserve(lmb, (ulong)*of_flat_tree, of_size);

This looks good to me.  Since it is in bootm.c and not in libfdt, I'll 
let Wolfgang pick it up unless I hear otherwise.

Acked-by: Gerald Van Baren 

Thanks,
gvb

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

Re: [U-Boot] [uboot PATCH v2] Add uboot "fdt_high" enviroment variable

[Jerry Van Baren]

Hi Dave,

This looks reasonable, with one minor nit...

On 07/09/2011 04:40 PM, David A. Long wrote:
> From: David A. Long
>
> Add a new "fdt_high" enviroment variable. This can be used to control (or 
> prevent) the
> relocation of the flattened device tree on boot. It can be used to prevent 
> relocation
> of the fdt into highmem.  The variable behaves similarly to the existing 
> "initrd_high"
> variable.
>
> Signed-off-by: David A. Long
> ---
>   README |9 
>   common/image.c |   60 
> ++--
>   2 files changed, 58 insertions(+), 11 deletions(-)
>
> diff --git a/README b/README
> index 8bb9c8d..5b95246 100644
> --- a/README
> +++ b/README
> @@ -3281,6 +3281,15 @@ List of environment variables (most likely not 
> complete):

[snip]

> diff --git a/common/image.c b/common/image.c
> index e542a57..7853de0 100644
> --- a/common/image.c
> +++ b/common/image.c
> @@ -1234,8 +1234,10 @@ int boot_relocate_fdt (struct lmb *lmb, char 
> **of_flat_tree, ulong *of_size)
>   {
>   void*fdt_blob = *of_flat_tree;
>   void*of_start = 0;
> + char*fdt_high;
>   ulong   of_len = 0;
>   int err;
> + int disable_relocation=0;

Need spaces around the "="

I will add the spaces before applying the patch unless you send an 
updated patch.

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

Re: [U-Boot] Please update libfdt for U-Boot

[Jerry Van Baren]

Hi Tabi,

On 06/29/2011 03:40 PM, Tabi Timur-B04825 wrote:
> Jerry,
>
> Now that the merge window is open, could you please update libfdt?
> The version in U-Boot hasn't been updated in over a year, and there
> are new features that I need to have.  Specifically, this commit:
> http://git.jdl.com/gitweb/?p=dtc.git;a=commit;h=d75b33af676d0beac8398651a7f09037555a550b

Will do, thanks for the reminder.

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

Re: [U-Boot] [PATCH] common/cmd_fdt.c: fix wrong data displayed in fdt print

[Jerry Van Baren]

On 06/01/2011 04:45 PM, Wolfgang Denk wrote:
> Dear Haojian Zhuang,
>
> In message<1306137210-31942-1-git-send-email-haojian.zhu...@marvell.com>  you 
> wrote:

[snip]

> Applied, thanks.
>
> Gerald, I hope this is OK with you?

Yes.

> Best regards,
> Wolfgang Denk

Thanks,
gvb

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

Re: [U-Boot] [STATUS] Getting ready for -rc1

[Jerry Van Baren]

Hi Andreas, Wolfgang,

On 05/17/2011 11:04 AM, Andreas Pretzsch wrote:
> Am Montag, den 16.05.2011, 22:24 +0200 schrieb Wolfgang Denk:
>> Hi everybody,
>>
>> I would like to get our -rc1 within the next 2 days or so.
>>
>> Please drop me (and the respective custodian) a note if you have any
>> patches that are supposed to go in.
>
> I'd like to request the inclusion of my patchset adding a command to
> manually trigger an update from a FIT-image, see
>http://lists.denx.de/pipermail/u-boot/2011-April/090911.html
>http://lists.denx.de/pipermail/u-boot/2011-April/090912.html
>http://lists.denx.de/pipermail/u-boot/2011-April/090913.html
> resp.
>http://patchwork.ozlabs.org/bundle/apr-cn-eng/fitupd/
>http://patchwork.ozlabs.org/patch/92055/
>http://patchwork.ozlabs.org/patch/92056/
>
> I suppose Mr. Jerry Van Baren as the FDT custodian is the primary
> contact, therefore I added him to CC. But maybe you could decide also.


This is a new command that uses the FDT utilities.  As such, I believe 
it is in Wolfgang's area.

[snip]

> Thanks in advance,
>Andreas

Best regards,
gvb

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

Re: [U-Boot] Pull request: u-boot-fdt

[Jerry Van baren]

On 4/20/2011 4:54 PM, Wolfgang Denk wrote:
> Dear Gerald Van Baren,

[snip]

>> I only have a one-liner bugfix by Kyle Moffett in the pull.  Grant's
>> changes "[PATCH 0/6] ARM device tree support improvements" look good in
>> principle, but I had a compilation error using the PPC target we need to
>> work that out.
>
> Please let me know when this situation changes.  I want to see that
> stuff in mainline as quickly as possible.  Thanks.

Will do, I'll prioritize it.

[snip]

> Best regards,
> Wolfgang Denk

Thanks,
gvb

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

Re: [U-Boot] Daughter card detection

[Jerry Van Baren]

Hi Kapil,

On 04/11/2011 12:06 AM, Dev, Kapil wrote:
> Hi I am trying to detect a daughter card chip. From data sheet I was
> able to find the address for that chip. But when I use i2c probe
> command from uboot shell, it is showing me only 4 addresses. And
> these 4 addresses does not contain the address of any chip on the
> daughter card.
> So my query is :
>
> 1.  how can I detect the daughter card chips using i2c.

The i2c probe command should work if your daughter card is working properly.

> 2.  why i2c probe command is not showing the chip addresses for
> daughter card as mentioned on the data sheet. But that is giving the
> correct address of EEPROM.

What is the target chip that is not responding?  You have given us no 
useful information.

I would connect a logic analyzer (preferred) or scope to the SDA and SCL 
lines on the I2C chip on your daughter card and verify the signals are 
making it to the chip and are valid signals.  It is tough with a scope, 
but with a logic analyzer you should be able to decode the signals and 
see the target chip's response or lack thereof.

> Here I want to mention that the card is working fine but not able to
> identify the chips on the daughter card mounted on davinci evm
> board.

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

Re: [U-Boot] Please pull u-boot-mpc85xx.git

[Jerry Van Baren]

On 04/04/2011 03:42 PM, Wolfgang Denk wrote:
> Dear Kumar Gala,
>
> In message<16cf6cad-477c-4e04-93e0-1dadcf05c...@kernel.crashing.org>  you 
> wrote:

[snip]

> Timur: does this fix any real problem?
>
>>> powerpc/85xx: introduce 'fdt verify' command
>>
>> I'm wondering if its better to just set the dtb props instead of verifying.
>
> Unfortunately Timur's posting broke the mail thread because he failed
> to add keep reference headers in his patch postings.  I'm not happy
> with this implementation either.
>
> In any case this needs the ACK from the responsible custodian (FDT =>
> gvb).

I don't see any problem with the patch other than a minor typo  On the 
last line, s/patch/match./

>> +/*
>> + * Verify the addresses for all of the PCI controllers
>> + *
>> + * PCI is complicated because there is no correlation between the numbering
>> + * of the controllers by U-Boot and the numbering the device tree.  So we 
>> need
>> + * to search all of the aliases until we find a patch
>> + */

It appears to provide a valuable service.

Acked-by: Gerald Van Baren 

> Best regards,
>
> Wolfgang Denk
>

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

Re: [U-Boot] [PATCH 2/6] Default to bootm_size() when CONFIG_SYS_BOOTMAPSZ is not defined

[Jerry Van Baren]

Hi Grant,

On 03/28/2011 03:58 PM, Grant Likely wrote:
> From: Grant Likely
>
> This patch adds a function getenv_bootm_mapsize() for obtaining the
> size of the early mapped region accessible by the kernel during early
> boot.  It defaults to CONFIG_SYS_BOOTMAPSZ, or if not defined,
> defaults to getenv_bootm_size(), which in turn defaults to the size of
> RAM.
>
> getenv_bootm_mapsize() can also be overridden with a "bootm_mapsize"
> environmental variable.
>
> Signed-off-by: Grant Likely
> ---
>   README   |   16 ++--
>   arch/powerpc/lib/bootm.c |2 +-
>   common/image.c   |   22 +++---
>   include/image.h  |1 +
>   4 files changed, 35 insertions(+), 6 deletions(-)

[snip]

> @@ -1207,7 +1223,7 @@ int boot_relocate_fdt (struct lmb *lmb, char 
> **of_flat_tree, ulong *of_size)
>   /* Pad the FDT by a specified amount */
>   of_len = *of_size + CONFIG_SYS_FDT_PAD;
>   of_start = (void *)(unsigned long)lmb_alloc_base(lmb, of_len, 0x1000,
> - CONFIG_SYS_BOOTMAPSZ + getenv_bootm_low());
> + getenv_bootm_mapsize() + getenv_bootm_low());
_^^

>
>   if (of_start == 0) {
>   puts("device tree - allocation error\n");
> @@ -1581,7 +1597,7 @@ int boot_get_cmdline (struct lmb *lmb, ulong 
> *cmd_start, ulong *cmd_end)
>   char *s;
>
>   cmdline = (char *)(ulong)lmb_alloc_base(lmb, CONFIG_SYS_BARGSIZE, 0xf,
> -  CONFIG_SYS_BOOTMAPSZ + getenv_bootm_low());
> + getenv_bootm_mapsize() + getenv_bootm_base());
_^^

getenv_bootm_base() doesn't exist in my tree, should it have been 
getenv_bootm_low()?

>   if (cmdline == NULL)
>   return -1;
> @@ -1617,7 +1633,7 @@ int boot_get_cmdline (struct lmb *lmb, ulong 
> *cmd_start, ulong *cmd_end)
>   int boot_get_kbd (struct lmb *lmb, bd_t **kbd)
>   {
>   *kbd = (bd_t *)(ulong)lmb_alloc_base(lmb, sizeof(bd_t), 0xf,
> -  CONFIG_SYS_BOOTMAPSZ + getenv_bootm_low());
> + getenv_bootm_mapsize() + getenv_bootm_low());
_^^

I don't have access to my 8360 board at the moment to execute test the 
code. :-/

[snip]

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

Re: [U-Boot] [PATCHv2] fdt_support: Fix buffer overflow in fdt_fixup_memory_banks

[Jerry Van Baren]

On 02/23/2011 11:18 AM, Kyle Moffett wrote:
> When fdt_fixup_memory_banks is called with 2-cell address and size
> fields in the device-tree (IE: 64-bit address and size), then it will
> overflow its on-stack "tmp" buffer.
>
> This fixes the buffer size and adds a comment explaining how many bytes
> need to be allocated per record.
>
> Signed-off-by: Kyle Moffett
> Cc: Jerry Van Baren
> ---
> Changelog:
> v2: Resubmitted separately from the other HWW-1U-1A changes.

Applied to u-boot-fdt, thanks.

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

Re: [U-Boot] [PATCH 1/6] Stop passing around bootmem_base value.

[Jerry Van Baren]

Hi Grant,

On 03/28/2011 03:58 PM, Grant Likely wrote:
> From: Grant Likely
>
> For the calls to boot_relocate_fdt(), boot_get_cmdline(), and
> boot_get_kbd(), the value of bootmem_base is always obtained by
> calling getenv_bootm_low().  Since the value always comes from the
> same source, the calling signature for those functions can be
> simplified by making them call getenv_bootm_low() directly.
>
> Signed-off-by: Grant Likely

[snip]

> diff --git a/include/image.h b/include/image.h
> index 005e0d2..aa1d7df 100644
> --- a/include/image.h
> +++ b/include/image.h

[snip]

> @@ -345,11 +344,10 @@ int boot_ramdisk_high (struct lmb *lmb, ulong rd_data, 
> ulong rd_len,
> ulong *initrd_start, ulong *initrd_end);
>   #endif /* CONFIG_SYS_BOOT_RAMDISK_HIGH */
>   #ifdef CONFIG_SYS_BOOT_GET_CMDLINE
> -int boot_get_cmdline (struct lmb *lmb, ulong *cmd_start, ulong *cmd_end,
> - ulong bootmap_base);
> +int boot_get_cmdline (struct lmb *lmb, ulong *cmd_start, ulong *cmd_end)
___^

D'oh, you lost a semicolon.  Compiles for ARM, not so well for PowerPC. 
  Took me a bit of staring and head scratching to see the missing piece 
(the hardest thing to see is the thing that isn't there).

I'm having a problem with patch 2 of 6 as well, getenv_bootm_base() not 
found for PowerPC, apparently the code isn't used in ARM.

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

Re: [U-Boot] [STATUS] Custodian changes, using Patchwork

[Jerry Van baren]

Hi Wolfgang,

On 11/12/2010 5:22 AM, Wolfgang Denk wrote:
> Hi all,
>
> here is some news about organizational changes:

[snip]

>For now, I would like to ask all CUSTODIANS to register as users at
>patchwork.ozlabs.org, so we can arrange that the appropriate
>privileges will be granted to you.

I'm registered as "gvb".

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

Re: [U-Boot] [PATCH v2 1/2] fdt_support: support adding EDID property to FDT display nodes

[Jerry Van baren]

On 10/12/2010 3:06 PM, Wolfgang Denk wrote:
> Dear Anatolij Gustschin,
>
> In message<1282123520-25823-1-git-send-email-ag...@denx.de>  you wrote:

[snip]

>> Signed-off-by: Anatolij Gustschin
>> Acked-by: Detlev Zundel
>> Cc: Gerald Van Baren
>> ---
>> v2:
>>   - improve commit message as suggested by Detlev
>>   - add Acked-by line
>>
>>   common/fdt_support.c  |   29 +
>>   include/fdt_support.h |1 +
>>   2 files changed, 30 insertions(+), 0 deletions(-)
>
> Applied.
>
>
> Jerry, hope it's OK with you that I pulled this directly.

Yes, thanks.

> Best regards,
> Wolfgang Denk

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

Re: [U-Boot] [PATCH] fdt: Fix bug in size calculation in fdt_resize() with initrd use

[Jerry Van Baren]

On 08/03/2010 10:22 AM, Stefan Roese wrote:
> From: Feng Wang
>
> Original bug description from Feng (fdt_resize() bug caused "WARNING:
> could not set linux, initrd-start FDT_ERR_NOSPACE."):
>
> What I got is an error: "WARNING: could not set linux,initrd-start
> FDT_ERR_NOSPACE." after loading Device Tree blob. This in turn caused
> linux to miss init part.
>
> After some digging, I found out the reason for this error, it is caused
> by fdt_resize().
>
> FDT blob got resized after filling in all board specific information of
> PowerPC. (in boot_body_linux()). It reduced blob size with only extra
> space for two fdt_reserve_entry, one for fdt itself, and one for initrd.
> Then it's aligned to a 0x1000 page boundary. However, later in
> fdt_initrd(), it could add two more properties, initrd-start AND
> initrd-end, each one needs at least two fdt_reserve_entry sizes done by
> _fdt_add_property() (name and value). Thus, the two fdt_reserve_entry
> extra space is not sufficient.
>
> So for some specific fdt size which is just under the page boundary
> after resizing, this will cause an error of FDT_ERR_NOSPACE in
> fdt_initrd() when setting those two properties, and failed to pass
> initrd information to linux.
>
> My fix is in fdt_resize(), leave at least 4 fdt_reserve_entry for
> initrd. So instead of 2*sizeof(struct fdt_reserve_entry) for
> actual_totalsize, use 5*sizeof(struc fdt_reserve_entry).
>
> Stefan: I got this same error on katmai, when trying to boot with
> initrd (run flash_self). This patch fixes this issue.
>
> Signed-off-by: Feng Wang
> Tested-by: Stefan Roese
> Cc: Jerry Van Baren

Acked-by: Gerald Van Baren 

Stefan or Wolfgang, can you apply this?

Thanks,
gvb

> ---
>   common/fdt_support.c |7 ---
>   1 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/common/fdt_support.c b/common/fdt_support.c
> index 718b635..6f198de 100644
> --- a/common/fdt_support.c
> +++ b/common/fdt_support.c
> @@ -498,11 +498,12 @@ int fdt_resize(void *blob)
>
>   /*
>* Calculate the actual size of the fdt
> -  * plus the size needed for two fdt_add_mem_rsv, one
> -  * for the fdt itself and one for a possible initrd
> +  * plus the size needed for 5 fdt_add_mem_rsv, one
> +  * for the fdt itself and 4 for a possible initrd
> +  * ((initrd-start + initrd-end) * 2 (name&  value))
>*/
>   actualsize = fdt_off_dt_strings(blob) +
> - fdt_size_dt_strings(blob) + 2*sizeof(struct fdt_reserve_entry);
> + fdt_size_dt_strings(blob) + 5 * sizeof(struct 
> fdt_reserve_entry);
>
>   /* Make it so the fdt ends on a page boundary */
>   actualsize = ALIGN(actualsize + ((uint)blob&  0xfff), 0x1000);

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

Re: [U-Boot] [PATCH 1/5] Add basic errno support.

[Jerry Van Baren]

On 07/17/2010 05:17 PM, Mike Frysinger wrote:
> On Saturday, July 17, 2010 15:45:44 Wolfgang Denk wrote:
>> --- /dev/null
>> +++ b/lib/errno.c
>> @@ -0,0 +1 @@
>> +int errno = 0;
>
> drop the "= 0" so that errno ends up in the bss ?
> -mike

Is this going to be a problem during early startup (pre-relocation) vs. 
normal running?  Pre-relocation, we only have a temporary stack and RAM 
is not set up initially.

I have not looked at when RAM gets initialized vs. when env. variables 
get used.  It is probably OK.  Wolfgang?

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

Re: [U-Boot] [PATCH] common: add a grepenv command

[Jerry Van Baren]

On 07/16/2010 04:41 PM, Scott Wood wrote:
> On Thu, 15 Jul 2010 22:15:22 -0500
> Kim Phillips  wrote:
>
>> u-boot environments, esp. when boards are shared across multiple users,
>> can get pretty large and time consuming to visually parse.
>> The grepenv command this patch adds can be used in lieu of printenv
>> to facilitate searching.  grepenv works like printenv but limits its output
>> only to environment strings (variable name and value pairs) that match the
>> user specified substring.
>
> Since it doesn't actually handle regular expressions, I'd call it
> something like findenv.  Or fgrepenv. :-)
>
> -Scott

Me too on "findenv".  I don't like fgrepenv since it has the same 
problem as "grepenv".  It actually is a gssp (global substring print) :-P.

gvb

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

Re: [U-Boot] [PATCH v3] fdt: Add function to alloc phandle values

[Jerry Van Baren]

On 07/10/2010 09:25 AM, Kumar Gala wrote:
> If we are creating reference (handles) to nodes in a device tree we need
> to first create a new phandle in node and this needs a new phandle
> value.  So we search through the whole dtb to find the max phandle value
> and return the next greater value for a new phandle allocation.
>
> Signed-off-by: Kumar Gala
> ---
> * Try this whitespace cleanup again
>
>   common/fdt_support.c  |   18 ++
>   include/fdt_support.h |1 +
>   2 files changed, 19 insertions(+), 0 deletions(-)

Acked-by: Gerald Van Baren 

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

Re: [U-Boot] [PATCH] always relocate fdt into an lmb-allocated memory block

[Jerry Van Baren]

Hi Timur,

On 05/24/2010 04:10 PM, Timur Tabi wrote:
> The device tree (fdt) must always exist in within the bootmap (usually the
> first 16MB of RAM).  If it doesn't, then boot_relocate_fdt() will allocate an
> LMB region in the bootmap and copy the fdt into that region.  It will also
> increase the size of the fdt.
>
> If the fdt is already in the bootmap, then previously the memory was just
> reserved.  There was no contingency if the reservation failed, however.
>
> By always allocating an lmb region and copying/resizing the fdt into that
> region, the code is simplified and the memory region is always allocated
> properly.
>
> Also change the types of some variables to avoid some typecasts.
>
> Signed-off-by: Timur Tabi
^
Need a space in your SOB line?

> ---
>   common/image.c |   83 
> +++-
>   1 files changed, 28 insertions(+), 55 deletions(-)

I assume this is a "live" patch, and replaces the patch with the subject 
"libfdt: make fdt_increase_size() available to  everyone".  It looks like 
a good improvement to me and nobody threw any stones at it, so...

Acked-by: Gerald Van Baren 

[snip]

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

Re: [U-Boot] [PATCH 1/2] fdt: Add fdt_translate_address to convert reg node to cpu phys addr

[Jerry Van Baren]

Hi Kumar,

On 07/17/2010 11:49 AM, Kumar Gala wrote:
>
> On Jul 4, 2010, at 1:18 PM, Kumar Gala wrote:
>
>> This code is extracted out of the Linux Kernel code from
>> arch/powerpc/kernel/prom_parse.c.
>>
>> We maintain some of the same structure to support multiple bus types even
>> though we only have one in the current code.  In the future we might want
>> to translate across a PCI bus and thus it will be easier to add that
>> functionality back in.
>>
>> Signed-off-by: Kumar Gala
>> ---
>> common/fdt_support.c  |  264 
>> +
>> include/fdt_support.h |1 +
>> 2 files changed, 265 insertions(+), 0 deletions(-)
>
> Jerry,
>
> Any comments?
>
> - k


Looks OK to me.

Acked-by: Gerald Van Baren 

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

Re: [U-Boot] [PATCH 2/2] fdt: Add fdt_node_offset_by_compat_reg helper

[Jerry Van Baren]

Hi Kumar,

On 07/17/2010 11:49 AM, Kumar Gala wrote:
>
> On Jul 4, 2010, at 1:18 PM, Kumar Gala wrote:
>
>> Given a compatiable string and physical address try and find a node that

compatible

>> matches.  This is useful when we want to find a specific device node to
>> update (for example if we have multiple PCI nodes we can use the
>> physical address to distinquish them when trying to update the device

distinguish  (s/q/g/)

>> tree).
>>
>> Signed-off-by: Kumar Gala
 ^
Probably should have a space in your signed-off-by line just in case a 
SOB line parser is picky.

>> ---
>> common/fdt_support.c  |   27 +++
>> include/fdt_support.h |2 ++
>> 2 files changed, 29 insertions(+), 0 deletions(-)
>
> Jerry,
>
> Any comments?
>
> - k

Looks OK to me other than two typos in the comment.

Acked-by: Gerald Van Baren 

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

Re: [U-Boot] Linux kernel hang with FDT changes

[Jerry Van Baren]

Hi Ronny,

Just adding to Stefan's comments...

On Mon, 2010-06-14 at 13:27 +0200, Stefan Roese wrote:
> Hi Ronny,
> 
> On Monday 14 June 2010 12:00:38 Ronny D wrote:
> > I am using customized ppc440 based board.
> 
> BTW: Do you plan to send the U-Boot changes to the mailing list and some time?
>   
> > We have created a .dtb file, u-boot should not update the file because of
> > that we have added following macro in config file 
> > #define CONFIG_OF_LIBFDT 1
> > #undef CONFIG_OF_BOARD_SETUP  

Is there a reason you *don't* want the board setup to run?
  
> > With the above change kernel code gets hang with following log:

Without the fixup, linux hangs.

[snip]

> > When we debug the u-boot code by added the following flag
> > #define CONFIG_OF_BOARD_SETUP   1
> > Kernel works fine.
> >  
> > Is there any dependency of CONFIG_OF_BOARD_SETUP flag for .dtb file?

With the fixup, it works.

In all cases I'm aware of, the fixup is a *good* thing.  Check the
source to see what is being fixed up.  The evidence is pretty clear that
you want the fixup. 

> With CONFIG_OF_BOARD_SETUP defined, the function ft_board_setup() will be 
> called to modify the dtb before passing it to the Linux kernel. I suggest you 
> check the code to see, what exactly gets changed/patched by this routine.

...and it is a good thing to run unless you have specific reasons not to
run it.  If you really don't want to run the fixup, it is indicating you
have a problem with your DTB (DTS) that you will have to figure out.  As
Stefan points out, the answer lies in the fixup code vs. your DTB.

> Cheers,
> Stefan

Best regards,
gvb


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

Re: [U-Boot] [PATCH] libfdt: introduce function fdt_get_max_phandle

[Jerry Van Baren]

Wolfgang Denk wrote:
> Dear Timur Tabi,
> 
> In message <1274308618-2974-1-git-send-email-ti...@freescale.com> you wrote:
>> Introduce function fdt_get_max_phandle(), which returns the largest value
>> of all phandles in a device tree.  This is useful for allocating a new 
>> phandle
>> property, since all phandles must be unique.
>>
>> Signed-off-by: Timur Tabi 
>> ---
>>  include/libfdt.h|   20 
>>  lib/libfdt/fdt_ro.c |   17 +
>>  2 files changed, 37 insertions(+), 0 deletions(-)
> 
> Please submit as part of a patch / patch series that acrtually uses
> this feature.  As is, it's just dead code that has no users.

I'm happy with this in principle, and will  formally when the 
community is OK with the code change.  It looks like a positive 
improvement to me, reducing complexity and addressing Timur/Freescale's 
needs.  Anyway, I envision  the patch and having FSL include it 
in whatever MPC8xxx patchset that actually needs the changes.

Thanks and best regards,
gvb

[snip improvement suggestion]
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] libfdt: make fdt_increase_size() available to everyone

[Jerry Van Baren]

Timur Tabi wrote:
> The function fdt_increase_size() increases the size of the device tree by the
> given amount.  This is useful for any code that wants to add a node or large
> property, to avoid the possibility of running out of space.  It's much smarter
> to have U-Boot increase the size of device tree when it knows it's going to
> add data, instead of hoping that the DTS was compiled with the right -p value.
> 
> Signed-off-by: Timur Tabi 

Acked-by: Gerald Van Baren 

> ---
> 
>  common/fdt_support.c  |   20 ++--
>  include/fdt_support.h |1 +
>  2 files changed, 11 insertions(+), 10 deletions(-)
> 
> diff --git a/common/fdt_support.c b/common/fdt_support.c
> index b6f252a..01d635b 100644
> --- a/common/fdt_support.c
> +++ b/common/fdt_support.c
> @@ -645,6 +645,16 @@ int fdt_resize(void *blob)
>   return actualsize;
>  }
>  
> +int fdt_increase_size(void *fdt, int add_len)
> +{
> + int newlen;
> +
> + newlen = fdt_totalsize(fdt) + add_len;
> +
> + /* Open in place with a new len */
> + return fdt_open_into(fdt, fdt, newlen);
> +}
> +
>  #ifdef CONFIG_PCI
>  #define CONFIG_SYS_PCI_NR_INBOUND_WIN 4
>  
> @@ -792,16 +802,6 @@ int fdt_del_subnodes(const void *blob, int parent_offset)
>   return 0;
>  }
>  
> -int fdt_increase_size(void *fdt, int add_len)
> -{
> - int newlen;
> -
> - newlen = fdt_totalsize(fdt) + add_len;
> -
> - /* Open in place with a new len */
> - return fdt_open_into(fdt, fdt, newlen);
> -}
> -
>  int fdt_del_partitions(void *blob, int parent_offset)
>  {
>   const void *prop;
> diff --git a/include/fdt_support.h b/include/fdt_support.h
> index 9a453af..d70627d 100644
> --- a/include/fdt_support.h
> +++ b/include/fdt_support.h
> @@ -78,6 +78,7 @@ void ft_pci_setup(void *blob, bd_t *bd);
>  
>  void set_working_fdt_addr(void *addr);
>  int fdt_resize(void *blob);
> +int fdt_increase_size(void *fdt, int add_len);
>  
>  int fdt_fixup_nor_flash_size(void *blob, int cs, u32 size);
>  

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

Re: [U-Boot] libfdt: make fdt_increase_size() available to everyone

[Jerry Van Baren]

Timur Tabi wrote:
> On Sat, May 15, 2010 at 9:11 PM, Gerald Van Baren  wrote:
> 
>> The code has one pre-existing weakness that bothers me: if there is
>> something following the FDT blob, it will get overwritten by the
>> increased blob.  One way around this would be to malloc() a new memory
>> space and move and expand the blob to the new space.  The first time
>> this was done, the original blob should not be free()ed since it wasn't
>> malloc()ed, but the second and subsequent times it should be free()ed.
> 
> But then how does the caller know where the new blob is?  When I call
> fdt_increase_size(), I pass it the address of a blob that I'm
> modifying.  After the function returns, my value of 'fdt' is no longer
> valid.

Oops, yes, that is a pretty fatal flaw.

>> I've added this to your patch, but have *NOT* execution tested it.  Does
>> this addition (a) make sense and (b) work?
> 
> I was expecting the caller of fdt_increase_size() to know that the
> space after the fdt is available.

OK.  I'll  the original patch.  The best way to incorporate 
the patch would be for Kumar (I assume) to pick up the libfdt change 
with the Freescale change that needs it so that the changes are 
inherently coordinated.

gvb

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

Re: [U-Boot] [PATCH] fdt_support: add entry for sec3.1 and remove tls_ssl_stream descriptor type capability for sec3.3

[Jerry Van Baren]

Hi Kim, Haiying,

Kim Phillips wrote:
> Add sec3.1 h/w geometry for fdt node fixups.
> 
> Also, technically, whilst SEC v3.3 h/w honours the tls_ssl_stream descriptor
> type, it lacks the ARC4 algorithm execution unit required to be able
> to execute anything meaningful with it.  Change the node to agree with
> the documentation that declares that the sec3.3 really doesn't have such
> a descriptor type.
> 
> Reported-by: Haiying Wang 
> Signed-off-by: Kim Phillips 
> ---
>  common/fdt_support.c |3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/common/fdt_support.c b/common/fdt_support.c
> index b6f252a..a8ac617 100644
> --- a/common/fdt_support.c
> +++ b/common/fdt_support.c
> @@ -534,7 +534,8 @@ void fdt_fixup_crypto_node(void *blob, int sec_rev)
>   { 0x0202, 1, 24, 0x04c, 0x0122003f }, /* SEC 2.2 */
>   { 0x0204, 4, 24, 0x07e, 0x012b0ebf }, /* SEC 2.4 */
>   { 0x0300, 4, 24, 0x9fe, 0x03ab0ebf }, /* SEC 3.0 */
> - { 0x0303, 4, 24, 0x97c, 0x03ab0abf }, /* SEC 3.3 */
> + { 0x0301, 4, 24, 0xbfe, 0x03ab0ebf }, /* SEC 3.1 */
> + { 0x0303, 4, 24, 0x97c, 0x03a30abf }, /* SEC 3.3 */
>   };
>   char compat_strlist[ARRAY_SIZE(sec_rev_prop_list) *
>   sizeof("fsl,secX.Y")];


Hmmm, we have two pieces of Freescale processor-specific fixups in 
fdt_support.c:

#ifdef CONFIG_HAS_FSL_DR_USB
void fdt_fixup_dr_usb(void *blob, bd_t *bd)
:
:
#endif /* CONFIG_HAS_FSL_DR_USB */

#if defined(CONFIG_MPC83xx) || defined(CONFIG_MPC85xx)
/*
  * update crypto node properties to a specified revision of the SEC
  * called with sec_rev == 0 if not on an mpc8xxxE processor
  */
void fdt_fixup_crypto_node(void *blob, int sec_rev)
:
:
#endif /* defined(CONFIG_MPC83xx) || defined(CONFIG_MPC85xx) */

While I'm OK with the change and am willing to ack since it appears to 
be a small and necessary improvement to existing code, it would be 
better to move the Freescale specific fixups into a Freescale CPU 
subdirectory, probably cpu/mpc8xxx/fdt.c.

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

Re: [U-Boot] [STATUS] Heads-up: Reorganize directory structure

[Jerry Van baren]

Dear Wolfgang,

On 4/13/2010 5:23 AM, Wolfgang Denk wrote:
> Hello Custodians,
>
> please note that I have applied Peter Tyser's "Reorganize directory
> structure" patch series. This results in a massive change of the
> directory structure.
>
> Please make sure to sync your repsitories ASAP.
>
> Thanks.
> Best regards,
> Wolfgang Denk

The "libfdt" u-boot-fdt has been updated.  There was nothing pending, so 
this was trivial.

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

Re: [U-Boot] Any good __LOW COST__ MIPS SBC suggestion please

[Jerry Van Baren]

Hi Balaji,

Please don't top quote.

Balaji Ravindran wrote:
> Hi Florian and Jerry,
> 
> Thanks for the inputs, i was actually going through the choices, and yea 
> as suggested Lemote seems to be a nice choice for me, and was wanting to 
> see distributors in the US / US shipping options.,

Based on your .in email domain, I did not expect that to be a problem. :-/

> also i had a look at the Linksys routers that you guys mentioned, but 
> one question, aren't the commercial products different from those of 
> development versions?, 

There are no development versions.  That is why they are cheap. ;-)

> I mean, when i opened up my WRT 610N, i could see  that, the main
> section of my router board is sealed in a steel casing(guess heat
> dissipater), though i can get the specs online,

The metal enclosure would be a EMI shield.  This is typically needed 
over the RF sections, sometimes needed over the processor sections.  It 
may or may not cover interesting things (processor, JTAG connector, etc).

> but does it have JTAG ports for debugging support? usually in production 
> versions, the odm's doesn't provide JTAG right? well, i couldn't see one 
> though.

The JTAG port is typically pads with no connector installed.  The 
designer/developers need it for development and the manufacturer 
typically needs it for loading new boards or debugging bad boards.

Developers get boards with connectors installed (special builds or 
add-on).  Manufacturers will use a fixture with "pogo pins" to stab the 
pads directly.  You get the opportunity for showing creativity, 
ingenuity, and soldering prowess.

> Just curious, will we be able to get development boards of Linksys WRT 
> SKUs? 

No.  Linksys is in the business of selling lots of turnkey boxes, not 
development stations.  Their attitude varies between tolerance and 
unhappiness with respect to hackers repurposing their boxes.

If you are looking for development boards, the "off-the-shelf" 
repurposing that Florian and I have mentioned do not fit your desires. 
You will need to restart your search with actual eval/dev boards and 
probably pay more money.  The advantage is that you will probably get 
better help and more information from the (re)seller.  The disadvantage 
is that you will pay more and probably learn less.

> Thanks
> 
> Balaji R

Best regards,
gvb

P.S. Florian: Thanks for the added info, that was very helpful.

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