Re: [U-Boot] Pull request for ARM zynq

[Michal Simek]

Hi Albert and Tom,

can you please look at my pull request?

Thanks,
Michal

2012/9/13 Michal Simek :
> Hi Albert, CC: Joe and Tom
>
>
> a month ago I have sent 4 Xilinx ARM zynq patches to mailing list (v2)
> (reminder yesterday)
> and I haven't got any reaction from anybody. The first patches were
> commented
> by Joe and problems fixed in the next version.
> There is one network driver which should require ACK from Joe
> and others from ARM maintainer.
> I would like to get these patches to mainline.
>
> Albert and Tom: Can you please look at these patches and tell me what you
> thing?
> The best will be if you can pull them to your trees.
>
> Here are links to patchwork
> http://patchwork.ozlabs.org/patch/177907/
> http://patchwork.ozlabs.org/patch/177908/
> http://patchwork.ozlabs.org/patch/177909/
> http://patchwork.ozlabs.org/patch/177910/
>
> Thanks,
> Michal
>
>
>
> The following changes since commit a6f0c4faa4c65a7b7048b12c9d180d7e1aad1721:
>   Wolfgang Denk (1):
> Merge branch 'master' of git://git.denx.de/u-boot-avr32
>
> are available in the git repository at:
>
>   git://www.denx.de/git/u-boot-microblaze.git master-zynq
>
> Michal Simek (4):
>   serial: Add Zynq serial driver
>   net: Add driver for Zynq Gem IP
>   arm: Support new Xilinx Zynq platform
>   xilinx: Add new Zynq board
>
>  arch/arm/cpu/armv7/zynq/Makefile|   52 
>  arch/arm/cpu/armv7/zynq/lowlevel_init.S |   27 ++
>  arch/arm/cpu/armv7/zynq/timer.c |  151 ++
>  board/xilinx/zynq/Makefile  |   54 
>  board/xilinx/zynq/board.c   |   64 +
>  boards.cfg  |1 +
>  drivers/net/Makefile|1 +
>  drivers/net/zynq_gem.c  |  453
> +++
>  drivers/serial/Makefile |1 +
>  drivers/serial/serial_zynq.c|  200 ++
>  include/configs/zynq.h  |  110 
>  include/netdev.h|2 +-
>  12 files changed, 1115 insertions(+), 1 deletions(-)
>  create mode 100644 arch/arm/cpu/armv7/zynq/Makefile
>  create mode 100644 arch/arm/cpu/armv7/zynq/lowlevel_init.S
>  create mode 100644 arch/arm/cpu/armv7/zynq/timer.c
>  create mode 100644 board/xilinx/zynq/Makefile
>  create mode 100644 board/xilinx/zynq/board.c
>  create mode 100644 drivers/net/zynq_gem.c
>  create mode 100644 drivers/serial/serial_zynq.c
>  create mode 100644 include/configs/zynq.h
>
>
> --
> Michal Simek, Ing. (M.Eng)
> w: www.monstr.eu p: +42-0-721842854
> Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
> Microblaze U-BOOT custodian



-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/2] Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files

[Thierry Reding]

On Mon, Feb 11, 2013 at 12:21:59PM -0700, Tom Warren wrote:
> Thierry/Lucas,
> 
> On Mon, Feb 11, 2013 at 12:11 PM, Thierry Reding
>  wrote:
> > On Mon, Feb 11, 2013 at 10:56:33AM -0700, Tom Warren wrote:
> >> Lucas,
> >>
> >> On Mon, Feb 11, 2013 at 10:28 AM, Lucas Stach  wrote:
> >> > Hi Tom,
> >> >
> >> > Am Montag, den 11.02.2013, 10:17 -0700 schrieb Tom Warren:
> >> >> Linux dts files were used for those boards that didn't already
> >> >> have sdhci info populated. Tamonten has their own dtsi file with
> >> >> common sdhci nodes (sourced from Linux).
> >> >>
> >> >> Signed-off-by: Tom Warren 
> >> >> ---
> >> >> v2:
> >> >> - cleanup comments in dts files/match w/kernel files
> >> >> - add sdhci aliases in all dts files
> >> >> - use tegra20-tamonten.dtsi from the kernel for AD boards
> >> >>
> >> >>  arch/arm/dts/tegra20-tamonten.dtsi   |  489 
> >> >> ++
> >> >
> >> > I'm not sure if pushing the whole file in this patch is the right thing
> >> > to do.
> >>
> >> I didn't want to edit it since we seem to be moving towards using the
> >> Linux DTS files in toto in U-Boot (as per Stephen & Simon). Does it do
> >> any harm to have the whole thing here? Saves some work later. Thierry
> >> - what do you think?
> >
> > Given that it isn't used anywhere I don't think we really need it right
> > now. We can always add it later when we can make better use of it.
> 
> It actually is used (for SDMMC/sdhci) now, Thierry. That's why it's in
> this patchset.

Right, I hadn't looked at that patch yet.

> I had originally put the sdhci node for Avionic Design
> boards in their respective .dts files, but Stephen pointed out that
> the kernel had a tegra20-tamonten.dtsi file with common info, which
> included the sdhci node, and asked that I use it, instead, so we echo
> the kernel layout. So I pulled that file into my MMC DT patchset, and
> used it in all AD board builds (medcom/tec/plutux) - it's pulled in
> via an override of CONFIG_ARCH_DEVICE_TREE in the config files.
> 
> So the options seem to be:
> 
> a) Don't use the tamonton dtsi file, and put the sdhci nodes in the AD
> dts files, just like all other boards (this was my V1 approach).
> Vetoed by Stephen.
> b) Use tegra20-tamonten.dtsi as is, identical to the kernel file. If
> necessary, I can move it's inclusion to a separate patch, independent
> of the MMC DT patchset, as suggested by Lucas.
> c) Use tegra20-tamonten.dtsi, but just with the sdhci node (is this
> what you're suggesting, Thierry?). I'd still pull it in via a
> CONFIG_ARCH_DEVICE_TREE #define in the AD config files.
> 
> Let me know ASAP - I'd like to get V3 upstreamed soon so I can move on
> to work on the T30/T114 MMC patches.

I think option b) sounds fine given that we want to move to the same DTS
as the kernel eventually anyway. So for the Tamonten (and AD board)
pieces, consider this:

Acked-by: Thierry Reding 

I can't give you a Tested-by because I have a bunch of other things to
take care of and I probably won't get to testing this for a few days.

Thierry


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

Re: [U-Boot] [PATCH v2] build: imx: Fix 'u-boot.imx' build without full OBJTREE reference

[Marek Vasut]

Dear Otavio Salvador,

> When calling 'make u-boot.imx' the build were failing as it were
> expecting the full path for the file; this regression has been
> included by commit 71a988a (imximage.cfg: run files through C
> preprocessor).
> 
> The direct references for u-boot.imx were replaced by $(obj) as
> config.mk handles the proper setting of it making it set to $(OBJTREE)
> when required.
> 
> The build has been test using:
> 
>  - ./MAKEALL -s mx5 -s mx6
>  - make u-boot.imx
>  - make O=/tmp/build

BUILD_DIR=/tmp/xyz MAKEALL please.

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

Re: [U-Boot] [PATCH 0/5] Add support for using an UBI volume for environment

[Scott Wood]

On 02/08/2013 02:07:21 PM, Joe Hershberger wrote:

NAND is not good at handling absolute addresses to sectors for storing
particular data.  The current implementation of the NAND env support
works around this in several ways such as storing a pointer to the
sector in the OOB of the first sector (interferes with some CRC) or
supporting a range of sectors (which unless it is huge is not
guaranteed to be safe).  None of these options address wear-leveling
concerns or bad block handling.

Accessing the u-boot env from UBI eliminates these concerns.  However,
it does require some of the basic settings for finding the UBI env to
be in the default u-boot env.


The downside is this moves us further away from having an environment  
available before relocation (e.g. loaded by SPL), which is important  
not just for serial config but also hwconfig, which can affect how RAM  
is set up among other things.


Maybe the "OOB of first sector" approach could be changed to be more  
like how bad block tables are allocated, with a special marker in the  
env block's own OOB that we scan for.


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

Re: [U-Boot] [PATCH v3 00/10] Add Marvell Dove and SolidRun CuBox

[Prafulla Wadaskar]

> -Original Message-
> From: Luka Perkov [mailto:l...@openwrt.org]
> Sent: 11 February 2013 02:08
> To: Sebastian Hesselbarth
> Cc: Prafulla Wadaskar; u-boot@lists.denx.de; Rabeeh Khoury; Albert
> Aribaud; Andy Fleming; Joe Hershberger; Daniel Stodden
> Subject: Re: [PATCH v3 00/10] Add Marvell Dove and SolidRun CuBox
> 
> On Mon, Feb 11, 2013 at 10:43:00AM +0100, Sebastian Hesselbarth wrote:
> > u-boot has kwboot for kirkwood since ages, but the general
> functionality
> > to boot through UART boot mode also applies to above SoCs. I took
> > kwbimage to reflect that kwboot should be used for booting this
> image.
> > IMHO introducing new abbreviated image names like dvbimage will just
> > distract people from using the correct tool to boot it. kwboot will
> not
> > be renamed, will it?
> 
> I don't mind if we rename kwboot to lets say mvebu-boot. That name
> would
> fit for kirkwood, dove and armada SoCs in the future...

That's good idea.
I vote for renaming kwboot as "mvboot", that will inline with predefined file 
naming strategy.

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

[U-Boot] u-Boot oxnas-810 usb support...

[Frank v.d. Jagt]

Hello all,

 

I'm trying to setup usb support in u-Boot for eTrayz (an oxnas-810 device)
so it will be able to boot from usb see
http://forum.xtreamer.net/forum/386-etrayz-mods-general-discussion

Device is currently running u-Boot 1.1.2 (no usb) from flash.

I'm looking for u-Boot configuration for this device and have asked xTreamer
but sofar no cooperation there.

Also found this tree
(https://github.com/WarheadsSE/OX820-uboot-2011.09/tree/master
 ) on
github. Would that work for the oxnas-810 board in eTrayz ?

Any help would be greatly appreciated.

 

Thank you,

Frank Hunter

 

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

[U-Boot] Fwd: pull request for u-boot-tegra/master into ARM/master

[Tom Warren]

Dropped the list from the PR. Sorry 'bout that.


-- Forwarded message --
From: Tom Warren 
Date: Mon, Feb 11, 2013 at 11:05 AM
Subject: pull request for u-boot-tegra/master into ARM/master
To: Albert ARIBAUD 
Cc: Tom Warren , Stephen Warren
, Simon Glass , Wolfgang Denk
, Allen Martin , Lucas Stach



Albert,

Please pull u-boot-tegra/master into ARM/master. Thanks!

./MAKEALL -a arm completed over the weekend w/o any new errors, and
checkpatch is clean.

The following changes since commit 8978f860a64eecfa088c1088bc0c2002ec316362:
  Tom Rini (1):
am33xx: Drop gpio0_7_pin_mux from phytec pcm051

are available in the git repository at:

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

Allen Martin (8):
  tegra: fdt: add back missing host1x node
  tegra20: fdt: add SPI SFLASH node
  tegra: spi: add fdt support to tegra SPI SFLASH driver
  tegra30: add SBC1 to periph id mapping table
  tegra30: fdt: add SPI SLINK nodes
  tegra: add addresses of SPI SLINK controllers
  tegra: add SPI SLINK driver
  tegra: cardhu: config: enable SPI

Lucas Stach (1):
  arm: fix CONFIG_DELAY_ENVIRONMENT to act like it claims in the README

Stephen Warren (2):
  tegra: rename FUNCMUX_UART2_UARTB
  tegra: don't hard-code LCD into default TEGRA_DEVICE_SETTINGS

Tom Warren (9):
  Tegra: T20: Remove unused 'SLOW' SoC ID and PLLX table entry
  Tegra: Move common clock code to arch/arm/cpu/tegra-common/clock.c
  Tegra114: Add arch-tegra114 include files
  Tegra114: Add AVP (arm720t) files
  Tegra114: Add CPU (armv7) files
  Tegra114: Add common CPU (shared) files
  Tegra114: Dalmore: Add DT files
  Tegra114: Add generic Tegra114 build support
  Tegra114: Add/enable Dalmore build (T114 reference board)

 arch/arm/cpu/arm720t/tegra-common/cpu.c   |   78 ++--
 arch/arm/cpu/arm720t/tegra-common/cpu.h   |8 +-
 arch/arm/cpu/arm720t/tegra114/Makefile|   42 ++
 arch/arm/cpu/arm720t/tegra114/config.mk   |   19 +
 arch/arm/cpu/arm720t/tegra114/cpu.c   |  297 +
 arch/arm/cpu/armv7/tegra114/Makefile  |   40 ++
 arch/arm/cpu/armv7/tegra114/config.mk |   19 +
 arch/arm/cpu/tegra-common/Makefile|2 +-
 arch/arm/cpu/tegra-common/ap.c|9 +-
 arch/arm/cpu/tegra-common/board.c |   25 +-
 arch/arm/cpu/tegra-common/clock.c |  560 
 arch/arm/cpu/tegra114-common/Makefile |   41 ++
 arch/arm/cpu/tegra114-common/clock.c  |  655 +++
 arch/arm/cpu/tegra114-common/funcmux.c|   63 ++
 arch/arm/cpu/tegra114-common/pinmux.c |  506 +++
 arch/arm/cpu/tegra20-common/clock.c   |  605 +-
 arch/arm/cpu/tegra20-common/funcmux.c |2 +-
 arch/arm/cpu/tegra30-common/clock.c   |  712 -
 arch/arm/dts/tegra114.dtsi|5 +
 arch/arm/dts/tegra20.dtsi |   12 +
 arch/arm/dts/tegra30.dtsi |   72 ++
 arch/arm/include/asm/arch-tegra/clk_rst.h |   58 ++-
 arch/arm/include/asm/arch-tegra/clock.h   |   59 ++-
 arch/arm/include/asm/arch-tegra/gp_padctrl.h  |1 +
 arch/arm/include/asm/arch-tegra/pmc.h |8 +
 arch/arm/include/asm/arch-tegra/tegra.h   |9 +-
 arch/arm/include/asm/arch-tegra/tegra_slink.h |   84 +++
 arch/arm/include/asm/arch-tegra114/clock-tables.h |  402 
 arch/arm/include/asm/arch-tegra114/clock.h|   28 +
 arch/arm/include/asm/arch-tegra114/flow.h |   35 +
 arch/arm/include/asm/arch-tegra114/funcmux.h  |   31 +
 arch/arm/include/asm/arch-tegra114/gp_padctrl.h   |   59 ++
 arch/arm/include/asm/arch-tegra114/gpio.h |   30 +
 arch/arm/include/asm/arch-tegra114/hardware.h |   22 +
 arch/arm/include/asm/arch-tegra114/pinmux.h   |  618 ++
 arch/arm/include/asm/arch-tegra114/pmu.h  |   23 +
 arch/arm/include/asm/arch-tegra114/spl.h  |   22 +
 arch/arm/include/asm/arch-tegra114/tegra.h|   33 +
 arch/arm/include/asm/arch-tegra20/clock-tables.h  |4 +
 arch/arm/include/asm/arch-tegra20/clock.h |4 +
 arch/arm/include/asm/arch-tegra20/funcmux.h   |2 +-
 arch/arm/include/asm/arch-tegra20/tegra.h |2 +
 arch/arm/include/asm/arch-tegra30/clock.h |4 +
 arch/arm/include/asm/arch-tegra30/tegra.h |2 +
 arch/arm/lib/board.c  |2 +-
 board/compulab/dts/tegra20-trimslice.dts  |5 +
 board/nvidia/common/board.c   |5 +-
 board/nvidia/dalmore/Makefile |   36 +
 board/nvidia/dalmore/dalmore.c|   32 +
 board/nvidia/dalmore/pinmux-config-dalmore.h  |  249 +++
 board/nvidia/dts/tegra114-dalmore.dts 

Re: [U-Boot] Patches for this merge window

[Tom Rini]

[take 2 for me, gmail defaults to reply not reply-all]

On Sun, Feb 10, 2013 at 11:48 PM, Simon Glass  wrote:

> Hi Tom,
>
> I see quite a lot of non-x86 patches in my todo list - does that mean
> that I should pick them up if I am happy with them, or just assign
> them back to you once I've taken a look?

For stuff you've posted, yes, you can either toss it back to me, toss
it into a branch in u-boot-x86.git or toss it into a patchwork bundle
and hand 'em back to me.

> I'm keen to get the sandbox fs and memory stuff in fairly early if
> possible, since I fear breakages and the longer people have to test
> the better. No one has screamed about map_sysmem() but I'm not sure if
> anyone noticed. So I could pull these in, build and send a pull if
> that suits? Perhaps one series at a time Also if Mike is having a
> break should I pull in the SPI ones assigned to me?

In general I've tried to skim patches at least, and will give things
one more read over when it comes back at me to pull in (however that
is).  For trivial SPI stuff (more IDs, etc) yes. For the changes to
writing and output and so forth, keep those in a
separate request if nothing else.

> There is also buildman, and I'm not sure what to do about that. It
> would be nice to have some feedback if people have tried it - I have
> had a few private emails only. I think it's a great help, but it still
> has some rough edges.

I still need to try that myself, sorry.  Has anything changed from the
last series you posted?

> Anyway, please let me know your expectations with the above. Re x86, I
> am going to start applying things this week once the board removable
> patch is sorted out.
>
> Generic board is also a big change, but since it is sort-of parallel
> to existing code and only turned on on a board-by-board basis the risk
> is lower - it just need some weeks of review time IMO.

Sounds good, thanks!

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

Re: [U-Boot] [PATCH] Add README for the "Falcon" mode

[Otavio Salvador]

On Mon, Nov 12, 2012 at 8:59 AM, Stefano Babic  wrote:
> Simple howto to add support to a board
> for booting the kernel from SPL ("Falcon" mode).
>
> Signed-off-by: Stefano Babic 

Could this be updated and resend? This is an interesting feature which
lacks documentation currently.

Regards,

-- 
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854  http://projetos.ossystems.com.br
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Tom Rini]

On Fri, Feb 08, 2013 at 10:41:41PM -0500, Jerry Van Baren wrote:

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

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v5 01/23] ppc: Add initial memory barrier macros

[Scott Wood]

On 02/08/2013 09:11:57 AM, Simon Glass wrote:

These are available on other architectures, so add them on ppc.

Signed-off-by: Simon Glass 
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/powerpc/include/asm/io.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/powerpc/include/asm/io.h  
b/arch/powerpc/include/asm/io.h

index 1f12c29..1bf12f5 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -317,4 +317,12 @@ static inline phys_addr_t virt_to_phys(void *  
vaddr)

 #endif
 }

+/*
+ * TODO: The kernel offers some more advanced versions of barriers,  
it might

+ * have some advantages to use them instead of the simple one here.
+ */
+#define dmb()  __asm__ __volatile__ ("" : : : "memory")
+#define __iormb()  dmb()
+#define __iowmb()  dmb()


What is the definition of these?  Given that we already have an  
architecture-independent barrier(), I assume this is meant to be an  
actual hardware barrier rather than a compiler barrier, so this is not  
a correct implementation.


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

Re: [U-Boot] [PATCH 1/2] Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files

[Scott Wood]

On 02/05/2013 10:56:59 PM, Simon Glass wrote:

Hi,

On Tue, Feb 5, 2013 at 12:49 PM, Stephen Warren  
 wrote:
> Right now, I believe your/Simon's policy on DT is to only include  
in the

> U-Boot .dts files what's actually needed for U-Boot. I've asked that
> this be done on a per-node basis rather than per-property basis in  
order

> to reduce diffs. If you want to change that, and include nodes that
> U-Boot doesn't need, that'd be great and assist unification, but  
then

> I'd recommend simply importing the current kernel .dts files as-is
> without any changes, rather than adding things piece-meal.

I have to say that within reason I like the idea of bring in the DT
from the kernel as is, limited perhaps to the nodes that U-Boot
actually uses.

A separate repo for the DT files seems like something that should
happen, but I have seen little progress on that front. Still, when it
happens, it would be nice it we could drop U-Boot's files and just use
the kernel's. That will be a lot easier if we head in that direction
now.


I think any device tree that makes assumptions about what U-Boot will  
be fixing up, or even what addresses U-Boot will configure devices at,  
belongs in the U-Boot tree.  Keeping such trees in Linux has been  
awkward so far, especially when a change gets made to such an  
assumption, or when U-Boot isn't the only supported firmware.


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

Re: [U-Boot] [U-boot]-gdwarf option

[Scott Wood]

On 02/07/2013 02:01:05 AM, tiger...@viatech.com.cn wrote:

Hi, experts:
I have a JTAG debugger.
Its manual suggested user should add "-gdwarf-2" option in the arm gcc
compiler.
Because it could produce debugging information.

But I searched the whole uboot source package, could not find
"-gdwarf-2" option in config.mk or other files.

Why?


I think it's already the default with most toolchains.  Do you see any  
difference in the output when supplying that flag?


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

Re: [U-Boot] [PATCH] kirkwood_nand: allow usage of NAND_ECC_SOFT_BCH

[Scott Wood]

On 02/10/2013 09:39:08 PM, Prafulla Wadaskar wrote:



> -Original Message-
> From: Holger Brunck [mailto:holger.bru...@keymile.com]
> Sent: 16 January 2013 14:04
> To: u-boot@lists.denx.de
> Cc: Gerlando Falauto; Holger Brunck; Valentin Longchamp; Prafulla
> Wadaskar
> Subject: [PATCH] kirkwood_nand: allow usage of NAND_ECC_SOFT_BCH
>
> From: Gerlando Falauto 
>
> If CONFIG_NAND_ECC_BCH is set use 4-bit error correction code  
instead

> of
> the 1-bit error correction code on the NAND device.
>
> Signed-off-by: Gerlando Falauto 
> Signed-off-by: Holger Brunck 
> cc: Valentin Longchamp 
> cc: Prafulla Wadaskar 
> ---
>  drivers/mtd/nand/kirkwood_nand.c |4 
>  1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mtd/nand/kirkwood_nand.c
> b/drivers/mtd/nand/kirkwood_nand.c
> index bdab5aa..0a99a10 100644
> --- a/drivers/mtd/nand/kirkwood_nand.c
> +++ b/drivers/mtd/nand/kirkwood_nand.c
> @@ -74,7 +74,11 @@ void kw_nand_select_chip(struct mtd_info *mtd,  
int

> chip)
>  int board_nand_init(struct nand_chip *nand)
>  {
>nand->options = NAND_COPYBACK | NAND_CACHEPRG | NAND_NO_PADDING;
> +#if defined(CONFIG_NAND_ECC_BCH)
> +  nand->ecc.mode = NAND_ECC_SOFT_BCH;
> +#else
>nand->ecc.mode = NAND_ECC_SOFT;
> +#endif
>nand->cmd_ctrl = kw_nand_hwcontrol;
>nand->chip_delay = 40;
>nand->select_chip = kw_nand_select_chip;

Acked-by: Prafulla Wadaskar 
Will pull this latter.


Acked-by: Scott Wood 

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

Re: [U-Boot] [PATCH v2 1/2] Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files

[Tom Warren]

Thierry/Lucas,

On Mon, Feb 11, 2013 at 12:11 PM, Thierry Reding
 wrote:
> On Mon, Feb 11, 2013 at 10:56:33AM -0700, Tom Warren wrote:
>> Lucas,
>>
>> On Mon, Feb 11, 2013 at 10:28 AM, Lucas Stach  wrote:
>> > Hi Tom,
>> >
>> > Am Montag, den 11.02.2013, 10:17 -0700 schrieb Tom Warren:
>> >> Linux dts files were used for those boards that didn't already
>> >> have sdhci info populated. Tamonten has their own dtsi file with
>> >> common sdhci nodes (sourced from Linux).
>> >>
>> >> Signed-off-by: Tom Warren 
>> >> ---
>> >> v2:
>> >> - cleanup comments in dts files/match w/kernel files
>> >> - add sdhci aliases in all dts files
>> >> - use tegra20-tamonten.dtsi from the kernel for AD boards
>> >>
>> >>  arch/arm/dts/tegra20-tamonten.dtsi   |  489 
>> >> ++
>> >
>> > I'm not sure if pushing the whole file in this patch is the right thing
>> > to do.
>>
>> I didn't want to edit it since we seem to be moving towards using the
>> Linux DTS files in toto in U-Boot (as per Stephen & Simon). Does it do
>> any harm to have the whole thing here? Saves some work later. Thierry
>> - what do you think?
>
> Given that it isn't used anywhere I don't think we really need it right
> now. We can always add it later when we can make better use of it.

It actually is used (for SDMMC/sdhci) now, Thierry. That's why it's in
this patchset. I had originally put the sdhci node for Avionic Design
boards in their respective .dts files, but Stephen pointed out that
the kernel had a tegra20-tamonten.dtsi file with common info, which
included the sdhci node, and asked that I use it, instead, so we echo
the kernel layout. So I pulled that file into my MMC DT patchset, and
used it in all AD board builds (medcom/tec/plutux) - it's pulled in
via an override of CONFIG_ARCH_DEVICE_TREE in the config files.

So the options seem to be:

a) Don't use the tamonton dtsi file, and put the sdhci nodes in the AD
dts files, just like all other boards (this was my V1 approach).
Vetoed by Stephen.
b) Use tegra20-tamonten.dtsi as is, identical to the kernel file. If
necessary, I can move it's inclusion to a separate patch, independent
of the MMC DT patchset, as suggested by Lucas.
c) Use tegra20-tamonten.dtsi, but just with the sdhci node (is this
what you're suggesting, Thierry?). I'd still pull it in via a
CONFIG_ARCH_DEVICE_TREE #define in the AD config files.

Let me know ASAP - I'd like to get V3 upstreamed soon so I can move on
to work on the T30/T114 MMC patches.

Tom

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

Re: [U-Boot] [PATCH v2 1/2] Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files

[Thierry Reding]

On Mon, Feb 11, 2013 at 10:56:33AM -0700, Tom Warren wrote:
> Lucas,
> 
> On Mon, Feb 11, 2013 at 10:28 AM, Lucas Stach  wrote:
> > Hi Tom,
> >
> > Am Montag, den 11.02.2013, 10:17 -0700 schrieb Tom Warren:
> >> Linux dts files were used for those boards that didn't already
> >> have sdhci info populated. Tamonten has their own dtsi file with
> >> common sdhci nodes (sourced from Linux).
> >>
> >> Signed-off-by: Tom Warren 
> >> ---
> >> v2:
> >> - cleanup comments in dts files/match w/kernel files
> >> - add sdhci aliases in all dts files
> >> - use tegra20-tamonten.dtsi from the kernel for AD boards
> >>
> >>  arch/arm/dts/tegra20-tamonten.dtsi   |  489 
> >> ++
> >
> > I'm not sure if pushing the whole file in this patch is the right thing
> > to do.
> 
> I didn't want to edit it since we seem to be moving towards using the
> Linux DTS files in toto in U-Boot (as per Stephen & Simon). Does it do
> any harm to have the whole thing here? Saves some work later. Thierry
> - what do you think?

Given that it isn't used anywhere I don't think we really need it right
now. We can always add it later when we can make better use of it.

Thierry


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

Re: [U-Boot] [PATCH v2 1/2] Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files

[Lucas Stach]

Am Montag, den 11.02.2013, 10:56 -0700 schrieb Tom Warren:
> Lucas,
> 
> On Mon, Feb 11, 2013 at 10:28 AM, Lucas Stach  wrote:
> > Hi Tom,
> >
> > Am Montag, den 11.02.2013, 10:17 -0700 schrieb Tom Warren:
> >> Linux dts files were used for those boards that didn't already
> >> have sdhci info populated. Tamonten has their own dtsi file with
> >> common sdhci nodes (sourced from Linux).
> >>
> >> Signed-off-by: Tom Warren 
> >> ---
> >> v2:
> >> - cleanup comments in dts files/match w/kernel files
> >> - add sdhci aliases in all dts files
> >> - use tegra20-tamonten.dtsi from the kernel for AD boards
> >>
> >>  arch/arm/dts/tegra20-tamonten.dtsi   |  489 
> >> ++
> >
> > I'm not sure if pushing the whole file in this patch is the right thing
> > to do.
> 
> I didn't want to edit it since we seem to be moving towards using the
> Linux DTS files in toto in U-Boot (as per Stephen & Simon). Does it do
> any harm to have the whole thing here? Saves some work later. Thierry
> - what do you think?
> 
I'm not objecting against pulling in the kernel dtsi in general, as I
think most of the things in there like pinmux will become handy in a
bit. I would just like to see this huge chunk in a separate patch and
this one would then just add the aliases.

Regards,
Lucas

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

Re: [U-Boot] [PATCH v2 2/2] Tegra: MMC: Add DT support to MMC driver for all T20 boards

[Tom Warren]

Lucas,

On Mon, Feb 11, 2013 at 10:33 AM, Lucas Stach  wrote:
> Am Montag, den 11.02.2013, 10:17 -0700 schrieb Tom Warren:
>> tegra_mmc_init() now parses the DT info for bus width, WP/CD GPIOs, etc.
>> Tested on Seaboard, fully functional.
>>
>> Tamonten boards (medcom-wide, plutux, and tec) use a different/new
>> dtsi file w/common settings.
>>
>> Signed-off-by: Tom Warren 
>> ---
>> v2:
>> - all boards now call tegra_mmc_init once, w/no params
>> - count MMC controllers, not aliases
>> - AD boards (medcom/plutux/tec) use common tegra20-tamonten.dtsi
>>
>>  arch/arm/include/asm/arch-tegra/mmc.h |2 +-
>>  arch/arm/include/asm/arch-tegra/tegra_mmc.h   |   13 +-
>>  board/avionic-design/common/tamonten.c|4 +-
>>  board/compal/paz00/paz00.c|   11 +-
>>  board/compulab/trimslice/trimslice.c  |9 +-
>>  board/nvidia/harmony/harmony.c|   11 +-
>>  board/nvidia/seaboard/seaboard.c  |   11 +-
>>  board/nvidia/whistler/whistler.c  |7 +-
>>  board/toradex/colibri_t20_iris/colibri_t20_iris.c |2 +-
>>  drivers/mmc/tegra_mmc.c   |  259 
>> +
>>  include/configs/medcom-wide.h |2 +
>>  include/configs/plutux.h  |2 +
>>  include/configs/tec.h |2 +
>>  include/fdtdec.h  |1 +
>>  lib/fdtdec.c  |1 +
>>  15 files changed, 197 insertions(+), 140 deletions(-)
>>
> [...]
>> diff --git a/board/nvidia/harmony/harmony.c b/board/nvidia/harmony/harmony.c
>> index 93430ed..fba06c2 100644
>> --- a/board/nvidia/harmony/harmony.c
>> +++ b/board/nvidia/harmony/harmony.c
>> @@ -58,18 +58,13 @@ static void pin_mux_mmc(void)
>>  /* this is a weak define that we are overriding */
>>  int board_mmc_init(bd_t *bd)
>>  {
>> - debug("board_mmc_init called\n");
>> + debug("%s called\n", __func__);
>>
>>   /* Enable muxes, etc. for SDMMC controllers */
>>   pin_mux_mmc();
>>
>> - debug("board_mmc_init: init SD slot J26\n");
>> - /* init dev 0, SD slot J26, with 8-bit bus */
>> - tegra_mmc_init(0, 8, GPIO_PI6, GPIO_PH2);
>> -
>> - debug("board_mmc_init: init SD slot J5\n");
>> - /* init dev 2, SD slot J5, with 4-bit bus */
>> - tegra_mmc_init(2, 4, GPIO_PT3, GPIO_PI5);
>> + debug("%s: init MMC devs\n", __func__);
>> + tegra_mmc_init();
>>
> tegra_mmc_init should not be called from every individual board file,
> but from the common nvidia tegra board file. Only the pinmux should stay
> in the individual board code, same thing as was done to all the other
> functions like NAND and USB.

True. I was originally just adapting the current config-file driven
MMC to DT step-by-step, but you're right - it should be called just
once for all boards in the common board file. I'll change it in V3.

Thanks,

Tom
>>   return 0;
>>  }
> [...]
>
> Regards,
> Lucas
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/2] Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files

[Tom Warren]

Lucas,

On Mon, Feb 11, 2013 at 10:28 AM, Lucas Stach  wrote:
> Hi Tom,
>
> Am Montag, den 11.02.2013, 10:17 -0700 schrieb Tom Warren:
>> Linux dts files were used for those boards that didn't already
>> have sdhci info populated. Tamonten has their own dtsi file with
>> common sdhci nodes (sourced from Linux).
>>
>> Signed-off-by: Tom Warren 
>> ---
>> v2:
>> - cleanup comments in dts files/match w/kernel files
>> - add sdhci aliases in all dts files
>> - use tegra20-tamonten.dtsi from the kernel for AD boards
>>
>>  arch/arm/dts/tegra20-tamonten.dtsi   |  489 
>> ++
>
> I'm not sure if pushing the whole file in this patch is the right thing
> to do.

I didn't want to edit it since we seem to be moving towards using the
Linux DTS files in toto in U-Boot (as per Stephen & Simon). Does it do
any harm to have the whole thing here? Saves some work later. Thierry
- what do you think?

>
>>  arch/arm/dts/tegra20.dtsi|   16 +-
>>  board/avionic-design/dts/tegra20-medcom-wide.dts |1 +
>>  board/avionic-design/dts/tegra20-plutux.dts  |1 +
>>  board/avionic-design/dts/tegra20-tec.dts |1 +
>>  board/compal/dts/tegra20-paz00.dts   |   19 +-
>>  board/compulab/dts/tegra20-trimslice.dts |   14 +
>>  board/nvidia/dts/tegra20-harmony.dts |   18 +
>>  board/nvidia/dts/tegra20-seaboard.dts|   12 +-
>>  board/nvidia/dts/tegra20-ventana.dts |   15 +
>>  board/nvidia/dts/tegra20-whistler.dts|   13 +
>>  board/toradex/dts/tegra20-colibri_t20_iris.dts   |6 +
>>  12 files changed, 595 insertions(+), 10 deletions(-)
>>  create mode 100644 arch/arm/dts/tegra20-tamonten.dtsi
>>
> [...]
>> diff --git a/board/toradex/dts/tegra20-colibri_t20_iris.dts 
>> b/board/toradex/dts/tegra20-colibri_t20_iris.dts
>> index c29b43a..0dd4c43 100644
>> --- a/board/toradex/dts/tegra20-colibri_t20_iris.dts
>> +++ b/board/toradex/dts/tegra20-colibri_t20_iris.dts
>> @@ -10,6 +10,7 @@
>>   usb0 = "/usb@c5008000";
>>   usb1 = "/usb@c500";
>>   usb2 = "/usb@c5004000";
>> + sdhci0 = "/sdhci@c8000600";
>>   };
>>
>>   usb@c500 {
>> @@ -35,4 +36,9 @@
>>   compatible = "nand-flash";
>>   };
>>   };
>> +
>> + sdhci@c8000600 {
>> + status = "okay";
>> + bus-width = <4>;
> You are missing the CD GPIO here. It's PC7.
Thanks, I'll add it.

Tom
>
>> + };
>>  };
>
> Regards,
> Lucas
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/2] Tegra: MMC: Add DT support to MMC driver for all T20 boards

[Lucas Stach]

Am Montag, den 11.02.2013, 10:17 -0700 schrieb Tom Warren:
> tegra_mmc_init() now parses the DT info for bus width, WP/CD GPIOs, etc.
> Tested on Seaboard, fully functional.
> 
> Tamonten boards (medcom-wide, plutux, and tec) use a different/new
> dtsi file w/common settings.
> 
> Signed-off-by: Tom Warren 
> ---
> v2:
> - all boards now call tegra_mmc_init once, w/no params
> - count MMC controllers, not aliases
> - AD boards (medcom/plutux/tec) use common tegra20-tamonten.dtsi
> 
>  arch/arm/include/asm/arch-tegra/mmc.h |2 +-
>  arch/arm/include/asm/arch-tegra/tegra_mmc.h   |   13 +-
>  board/avionic-design/common/tamonten.c|4 +-
>  board/compal/paz00/paz00.c|   11 +-
>  board/compulab/trimslice/trimslice.c  |9 +-
>  board/nvidia/harmony/harmony.c|   11 +-
>  board/nvidia/seaboard/seaboard.c  |   11 +-
>  board/nvidia/whistler/whistler.c  |7 +-
>  board/toradex/colibri_t20_iris/colibri_t20_iris.c |2 +-
>  drivers/mmc/tegra_mmc.c   |  259 
> +
>  include/configs/medcom-wide.h |2 +
>  include/configs/plutux.h  |2 +
>  include/configs/tec.h |2 +
>  include/fdtdec.h  |1 +
>  lib/fdtdec.c  |1 +
>  15 files changed, 197 insertions(+), 140 deletions(-)
> 
[...]
> diff --git a/board/nvidia/harmony/harmony.c b/board/nvidia/harmony/harmony.c
> index 93430ed..fba06c2 100644
> --- a/board/nvidia/harmony/harmony.c
> +++ b/board/nvidia/harmony/harmony.c
> @@ -58,18 +58,13 @@ static void pin_mux_mmc(void)
>  /* this is a weak define that we are overriding */
>  int board_mmc_init(bd_t *bd)
>  {
> - debug("board_mmc_init called\n");
> + debug("%s called\n", __func__);
>  
>   /* Enable muxes, etc. for SDMMC controllers */
>   pin_mux_mmc();
>  
> - debug("board_mmc_init: init SD slot J26\n");
> - /* init dev 0, SD slot J26, with 8-bit bus */
> - tegra_mmc_init(0, 8, GPIO_PI6, GPIO_PH2);
> -
> - debug("board_mmc_init: init SD slot J5\n");
> - /* init dev 2, SD slot J5, with 4-bit bus */
> - tegra_mmc_init(2, 4, GPIO_PT3, GPIO_PI5);
> + debug("%s: init MMC devs\n", __func__);
> + tegra_mmc_init();
>  
tegra_mmc_init should not be called from every individual board file,
but from the common nvidia tegra board file. Only the pinmux should stay
in the individual board code, same thing as was done to all the other
functions like NAND and USB.
>   return 0;
>  }
[...]

Regards,
Lucas

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

Re: [U-Boot] [PATCH v2 1/2] Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files

[Lucas Stach]

Hi Tom,

Am Montag, den 11.02.2013, 10:17 -0700 schrieb Tom Warren:
> Linux dts files were used for those boards that didn't already
> have sdhci info populated. Tamonten has their own dtsi file with
> common sdhci nodes (sourced from Linux).
> 
> Signed-off-by: Tom Warren 
> ---
> v2:
> - cleanup comments in dts files/match w/kernel files
> - add sdhci aliases in all dts files
> - use tegra20-tamonten.dtsi from the kernel for AD boards
> 
>  arch/arm/dts/tegra20-tamonten.dtsi   |  489 
> ++

I'm not sure if pushing the whole file in this patch is the right thing
to do.

>  arch/arm/dts/tegra20.dtsi|   16 +-
>  board/avionic-design/dts/tegra20-medcom-wide.dts |1 +
>  board/avionic-design/dts/tegra20-plutux.dts  |1 +
>  board/avionic-design/dts/tegra20-tec.dts |1 +
>  board/compal/dts/tegra20-paz00.dts   |   19 +-
>  board/compulab/dts/tegra20-trimslice.dts |   14 +
>  board/nvidia/dts/tegra20-harmony.dts |   18 +
>  board/nvidia/dts/tegra20-seaboard.dts|   12 +-
>  board/nvidia/dts/tegra20-ventana.dts |   15 +
>  board/nvidia/dts/tegra20-whistler.dts|   13 +
>  board/toradex/dts/tegra20-colibri_t20_iris.dts   |6 +
>  12 files changed, 595 insertions(+), 10 deletions(-)
>  create mode 100644 arch/arm/dts/tegra20-tamonten.dtsi
> 
[...]
> diff --git a/board/toradex/dts/tegra20-colibri_t20_iris.dts 
> b/board/toradex/dts/tegra20-colibri_t20_iris.dts
> index c29b43a..0dd4c43 100644
> --- a/board/toradex/dts/tegra20-colibri_t20_iris.dts
> +++ b/board/toradex/dts/tegra20-colibri_t20_iris.dts
> @@ -10,6 +10,7 @@
>   usb0 = "/usb@c5008000";
>   usb1 = "/usb@c500";
>   usb2 = "/usb@c5004000";
> + sdhci0 = "/sdhci@c8000600";
>   };
>  
>   usb@c500 {
> @@ -35,4 +36,9 @@
>   compatible = "nand-flash";
>   };
>   };
> +
> + sdhci@c8000600 {
> + status = "okay";
> + bus-width = <4>;
You are missing the CD GPIO here. It's PC7.

> + };
>  };

Regards,
Lucas


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

[U-Boot] [PATCH v2 2/2] Tegra: MMC: Add DT support to MMC driver for all T20 boards

[Tom Warren]

tegra_mmc_init() now parses the DT info for bus width, WP/CD GPIOs, etc.
Tested on Seaboard, fully functional.

Tamonten boards (medcom-wide, plutux, and tec) use a different/new
dtsi file w/common settings.

Signed-off-by: Tom Warren 
---
v2:
- all boards now call tegra_mmc_init once, w/no params
- count MMC controllers, not aliases
- AD boards (medcom/plutux/tec) use common tegra20-tamonten.dtsi

 arch/arm/include/asm/arch-tegra/mmc.h |2 +-
 arch/arm/include/asm/arch-tegra/tegra_mmc.h   |   13 +-
 board/avionic-design/common/tamonten.c|4 +-
 board/compal/paz00/paz00.c|   11 +-
 board/compulab/trimslice/trimslice.c  |9 +-
 board/nvidia/harmony/harmony.c|   11 +-
 board/nvidia/seaboard/seaboard.c  |   11 +-
 board/nvidia/whistler/whistler.c  |7 +-
 board/toradex/colibri_t20_iris/colibri_t20_iris.c |2 +-
 drivers/mmc/tegra_mmc.c   |  259 +
 include/configs/medcom-wide.h |2 +
 include/configs/plutux.h  |2 +
 include/configs/tec.h |2 +
 include/fdtdec.h  |1 +
 lib/fdtdec.c  |1 +
 15 files changed, 197 insertions(+), 140 deletions(-)

diff --git a/arch/arm/include/asm/arch-tegra/mmc.h 
b/arch/arm/include/asm/arch-tegra/mmc.h
index 5c95047..71ad407 100644
--- a/arch/arm/include/asm/arch-tegra/mmc.h
+++ b/arch/arm/include/asm/arch-tegra/mmc.h
@@ -22,6 +22,6 @@
 #ifndef _TEGRA_MMC_H_
 #define _TEGRA_MMC_H_
 
-int tegra_mmc_init(int dev_index, int bus_width, int pwr_gpio, int cd_gpio);
+void tegra_mmc_init(void);
 
 #endif /* _TEGRA_MMC_H_ */
diff --git a/arch/arm/include/asm/arch-tegra/tegra_mmc.h 
b/arch/arm/include/asm/arch-tegra/tegra_mmc.h
index dd746ca..bd18f5f 100644
--- a/arch/arm/include/asm/arch-tegra/tegra_mmc.h
+++ b/arch/arm/include/asm/arch-tegra/tegra_mmc.h
@@ -27,6 +27,8 @@
 #define TEGRA_SDMMC3_BASE  0xC8000400
 #define TEGRA_SDMMC4_BASE  0xC8000600
 
+#define MAX_HOSTS  4   /* Max number of 'hosts'/controllers */
+
 #ifndef __ASSEMBLY__
 struct tegra_mmc {
unsigned intsysad;  /* _SYSTEM_ADDRESS_0 */
@@ -119,12 +121,15 @@ struct tegra_mmc {
 
 struct mmc_host {
struct tegra_mmc *reg;
+   int id; /* device id/number, 0-3 */
+   int enabled;/* 1 to enable, 0 to disable */
+   int width;  /* Bus Width, 1, 4 or 8 */
+   enum periph_id mmc_id;  /* Peripheral ID: PERIPH_ID_... */
+   struct fdt_gpio_state cd_gpio;  /* Change Detect GPIO */
+   struct fdt_gpio_state pwr_gpio; /* Power GPIO */
+   struct fdt_gpio_state wp_gpio;  /* Write Protect GPIO */
unsigned int version;   /* SDHCI spec. version */
unsigned int clock; /* Current clock (MHz) */
-   unsigned int base;  /* Base address, SDMMC1/2/3/4 */
-   enum periph_id mmc_id;  /* Peripheral ID: PERIPH_ID_... */
-   int pwr_gpio;   /* Power GPIO */
-   int cd_gpio;/* Change Detect GPIO */
 };
 
 #endif /* __ASSEMBLY__ */
diff --git a/board/avionic-design/common/tamonten.c 
b/board/avionic-design/common/tamonten.c
index e6a932e..a7dd598 100644
--- a/board/avionic-design/common/tamonten.c
+++ b/board/avionic-design/common/tamonten.c
@@ -69,8 +69,8 @@ int board_mmc_init(bd_t *bd)
/* Enable muxes, etc. for SDMMC controllers */
pin_mux_mmc();
 
-   /* init dev 0, SD slot, with 4-bit bus */
-   tegra_mmc_init(0, 4, GPIO_PI6, GPIO_PH2);
+   /* init mmc devs */
+   tegra_mmc_init();
 
return 0;
 }
diff --git a/board/compal/paz00/paz00.c b/board/compal/paz00/paz00.c
index 1447f47..5bd72bb 100644
--- a/board/compal/paz00/paz00.c
+++ b/board/compal/paz00/paz00.c
@@ -55,18 +55,13 @@ static void pin_mux_mmc(void)
 /* this is a weak define that we are overriding */
 int board_mmc_init(bd_t *bd)
 {
-   debug("board_mmc_init called\n");
+   debug("%s called\n", __func__);
 
/* Enable muxes, etc. for SDMMC controllers */
pin_mux_mmc();
 
-   debug("board_mmc_init: init eMMC\n");
-   /* init dev 0, eMMC chip, with 8-bit bus */
-   tegra_mmc_init(0, 8, -1, -1);
-
-   debug("board_mmc_init: init SD slot\n");
-   /* init dev 3, SD slot, with 4-bit bus */
-   tegra_mmc_init(3, 4, GPIO_PV1, GPIO_PV5);
+   debug("%s: init MMC\n", __func__);
+   tegra_mmc_init();
 
return 0;
 }
diff --git a/board/compulab/trimslice/trimslice.c 
b/board/compulab/trimslice/trimslice.c
index 8f4dd09..020283c 100644
--- a/board/compulab/trimslice/trimslice.c
+++ b/board/compulab/trimslice/trimslice.c
@@ -64,16 +64,13 @@ static void pin_mux_mmc(void)
 /* this is a weak define that we are overriding */
 int board_mmc_init(bd_t *bd)
 {
-   debug("board_mmc_init

[U-Boot] [PATCH v2 1/2] Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files

[Tom Warren]

Linux dts files were used for those boards that didn't already
have sdhci info populated. Tamonten has their own dtsi file with
common sdhci nodes (sourced from Linux).

Signed-off-by: Tom Warren 
---
v2:
- cleanup comments in dts files/match w/kernel files
- add sdhci aliases in all dts files
- use tegra20-tamonten.dtsi from the kernel for AD boards

 arch/arm/dts/tegra20-tamonten.dtsi   |  489 ++
 arch/arm/dts/tegra20.dtsi|   16 +-
 board/avionic-design/dts/tegra20-medcom-wide.dts |1 +
 board/avionic-design/dts/tegra20-plutux.dts  |1 +
 board/avionic-design/dts/tegra20-tec.dts |1 +
 board/compal/dts/tegra20-paz00.dts   |   19 +-
 board/compulab/dts/tegra20-trimslice.dts |   14 +
 board/nvidia/dts/tegra20-harmony.dts |   18 +
 board/nvidia/dts/tegra20-seaboard.dts|   12 +-
 board/nvidia/dts/tegra20-ventana.dts |   15 +
 board/nvidia/dts/tegra20-whistler.dts|   13 +
 board/toradex/dts/tegra20-colibri_t20_iris.dts   |6 +
 12 files changed, 595 insertions(+), 10 deletions(-)
 create mode 100644 arch/arm/dts/tegra20-tamonten.dtsi

diff --git a/arch/arm/dts/tegra20-tamonten.dtsi 
b/arch/arm/dts/tegra20-tamonten.dtsi
new file mode 100644
index 000..4766aba
--- /dev/null
+++ b/arch/arm/dts/tegra20-tamonten.dtsi
@@ -0,0 +1,489 @@
+/include/ "tegra20.dtsi"
+
+/ {
+   model = "Avionic Design Tamonten SOM";
+   compatible = "ad,tamonten", "nvidia,tegra20";
+
+   memory {
+   reg = <0x 0x2000>;
+   };
+
+   host1x {
+   hdmi {
+   vdd-supply = <&hdmi_vdd_reg>;
+   pll-supply = <&hdmi_pll_reg>;
+
+   nvidia,ddc-i2c-bus = <&hdmi_ddc>;
+   nvidia,hpd-gpio = <&gpio 111 0>; /* PN7 */
+   };
+   };
+
+   pinmux {
+   pinctrl-names = "default";
+   pinctrl-0 = <&state_default>;
+
+   state_default: pinmux {
+   ata {
+   nvidia,pins = "ata";
+   nvidia,function = "ide";
+   };
+   atb {
+   nvidia,pins = "atb", "gma", "gme";
+   nvidia,function = "sdio4";
+   };
+   atc {
+   nvidia,pins = "atc";
+   nvidia,function = "nand";
+   };
+   atd {
+   nvidia,pins = "atd", "ate", "gmb", "gmd", "gpu",
+   "spia", "spib", "spic";
+   nvidia,function = "gmi";
+   };
+   cdev1 {
+   nvidia,pins = "cdev1";
+   nvidia,function = "plla_out";
+   };
+   cdev2 {
+   nvidia,pins = "cdev2";
+   nvidia,function = "pllp_out4";
+   };
+   crtp {
+   nvidia,pins = "crtp";
+   nvidia,function = "crt";
+   };
+   csus {
+   nvidia,pins = "csus";
+   nvidia,function = "vi_sensor_clk";
+   };
+   dap1 {
+   nvidia,pins = "dap1";
+   nvidia,function = "dap1";
+   };
+   dap2 {
+   nvidia,pins = "dap2";
+   nvidia,function = "dap2";
+   };
+   dap3 {
+   nvidia,pins = "dap3";
+   nvidia,function = "dap3";
+   };
+   dap4 {
+   nvidia,pins = "dap4";
+   nvidia,function = "dap4";
+   };
+   dta {
+   nvidia,pins = "dta", "dtd";
+   nvidia,function = "sdio2";
+   };
+   dtb {
+   nvidia,pins = "dtb", "dtc", "dte";
+   nvidia,function = "rsvd1";
+   };
+   dtf {
+   nvidia,pins = "dtf";
+   nvidia,function = "i2c3";
+   };
+   gmc {
+   nvidia,pins = "gmc";
+   nvidia,function = "uartd";
+   };
+   gpu7 {
+   nvidia,pins = "

[U-Boot] [PATCH v2 0/2] Tegra: MMC: Add DT support for MMC to T20 boards

[Tom Warren]

This patchset adds device-tree support to the Tegra MMC driver.
All device config is done via properties in the DT files instead
of hard-coded config options/function arguments.

I've tested this on my Seaboard and everything works fine,
including card detect. For the other T20 boards, I've used
the Linux kernel DTS files for the sdhci nodes where there
wasn't one already, or expanded the info that was already
there. Everything builds fine, but I haven't tested anything
but Seaboard.

v2: Changes as per Stephen's & Simon's review

Tom Warren (2):
  Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files
  Tegra: MMC: Add DT support to MMC driver for all T20 boards

 arch/arm/dts/tegra20-tamonten.dtsi|  489 +
 arch/arm/dts/tegra20.dtsi |   16 +-
 arch/arm/include/asm/arch-tegra/mmc.h |2 +-
 arch/arm/include/asm/arch-tegra/tegra_mmc.h   |   13 +-
 board/avionic-design/common/tamonten.c|4 +-
 board/avionic-design/dts/tegra20-medcom-wide.dts  |1 +
 board/avionic-design/dts/tegra20-plutux.dts   |1 +
 board/avionic-design/dts/tegra20-tec.dts  |1 +
 board/compal/dts/tegra20-paz00.dts|   19 +-
 board/compal/paz00/paz00.c|   11 +-
 board/compulab/dts/tegra20-trimslice.dts  |   14 +
 board/compulab/trimslice/trimslice.c  |9 +-
 board/nvidia/dts/tegra20-harmony.dts  |   18 +
 board/nvidia/dts/tegra20-seaboard.dts |   12 +-
 board/nvidia/dts/tegra20-ventana.dts  |   15 +
 board/nvidia/dts/tegra20-whistler.dts |   13 +
 board/nvidia/harmony/harmony.c|   11 +-
 board/nvidia/seaboard/seaboard.c  |   11 +-
 board/nvidia/whistler/whistler.c  |7 +-
 board/toradex/colibri_t20_iris/colibri_t20_iris.c |2 +-
 board/toradex/dts/tegra20-colibri_t20_iris.dts|6 +
 drivers/mmc/tegra_mmc.c   |  259 +++
 include/configs/medcom-wide.h |2 +
 include/configs/plutux.h  |2 +
 include/configs/tec.h |2 +
 include/fdtdec.h  |1 +
 lib/fdtdec.c  |1 +
 27 files changed, 792 insertions(+), 150 deletions(-)
 create mode 100644 arch/arm/dts/tegra20-tamonten.dtsi

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

[U-Boot] [PATCH] Allow OMAP2 boards to setup GPMC chipselects.

[Mark Jackson]

Expose the enable_gpmc_cs_config() function so OMAP2 boards can register
GPMC chipselects.

Signed-off-by: Mark Jackson 
---
 arch/arm/include/asm/arch-am33xx/sys_proto.h |2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h 
b/arch/arm/include/asm/arch-am33xx/sys_proto.h
index 588d8de..97ab60d 100644
--- a/arch/arm/include/asm/arch-am33xx/sys_proto.h
+++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h
@@ -35,5 +35,7 @@ void ddr_pll_config(unsigned int ddrpll_M);
  void sdelay(unsigned long);
 void gpmc_init(void);
+void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs *cs, u32 
base,
+   u32 size);
 void omap_nand_switch_ecc(int);
 #endif
-- 
1.7.9.5


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

[U-Boot] patches review

[Angelo Dureghello]

Dear All,

i never had an answer on these 2 patches, related to the introduction
of AMCORE board:

http://patchwork.ozlabs.org/patch/215904/
http://patchwork.ozlabs.org/patch/214686/

Many thanks
Regards,

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

Re: [U-Boot] [PATCH v2 6/7] MIPS: u-boot.lds: add relocation specific sections

[Gabor Juhos]

2013.02.11. 15:32 keltezéssel, Daniel Schwierzeck írta:
> From: Gabor Juhos 
> 
> This section contain the table needed for dynamic
> relocation. Also provide symbols for the relocation
> code to access the table.
> 
> Discard all sections which are not needed in the final
> ELF binary and U-Boot image. Section .dynsym cannot be
> discarded or GNU ld crashes otherwise. This section
> will be stripped by GNU objcpy in a later patch.
> 
> Signed-off-by: Gabor Juhos 
> Signed-off-by: Daniel Schwierzeck 
> ---
> Changes since v1:
> - add back the .deadcode section (see code comment for explanation)

Thanks!

-Gabor

For the record: the qemu_mips{,el,64,64el} and the qi_lb60 images (compiled from
the updated mips/reloc branch) are working under qemu:

U-Boot 2013.01-00178-gc27fe73 (Feb 11 2013 - 15:46:40)

Board: Qemu -M mips CPU: 24Kf proc_id=0x19300
DRAM:  128 MiB
## Unknown flash on Bank 1 - Size = 0x = 0 MB
Flash: 0 Bytes
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Net:   NE2000
Hit any key to stop autoboot:  0
qemu-mips #

---

U-Boot 2013.01-00178-gc27fe73 (Feb 11 2013 - 15:47:29)

Board: Qemu -M mips CPU: 24Kf proc_id=0x19300
DRAM:  128 MiB
## Unknown flash on Bank 1 - Size = 0x = 0 MB
Flash: 0 Bytes
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Net:   NE2000
Hit any key to stop autoboot:  0
qemu-mipsel #

---

U-Boot 2013.01-00178-gc27fe73 (Feb 11 2013 - 15:48:16)

Board: Qemu -M mips CPU: 20Kc proc_id=0x182a0
DRAM:  128 MiB
## Unknown flash on Bank 1 - Size = 0x = 0 MB
Flash: 0 Bytes
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Net:   NE2000
Hit any key to stop autoboot:  0
qemu-mips64 #

---

U-Boot 2013.01-00178-gc27fe73 (Feb 11 2013 - 15:48:55)

Board: Qemu -M mips CPU: 20Kc proc_id=0x182a0
DRAM:  128 MiB
## Unknown flash on Bank 1 - Size = 0x = 0 MB
Flash: 0 Bytes
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Net:   NE2000
Hit any key to stop autoboot:  0
qemu-mips64el #

---

U-Boot 2013.01-00178-gc27fe73 (Feb 11 2013 - 15:49:34)

Board: Qi LB60 (Ingenic XBurst Jz4740 SoC, Speed 336 MHz)
DRAM:  32 MiB
NAND:  No NAND device found!!!
0 MiB
No Valid Environment Area found
No Valid Redundant Environment Area found
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0

no devices available
Wrong Image Format for bootm command
ERROR: can't get kernel image!
NanoNote#

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

[U-Boot] [PATCH v2 6/7] MIPS: u-boot.lds: add relocation specific sections

[Daniel Schwierzeck]

From: Gabor Juhos 

This section contain the table needed for dynamic
relocation. Also provide symbols for the relocation
code to access the table.

Discard all sections which are not needed in the final
ELF binary and U-Boot image. Section .dynsym cannot be
discarded or GNU ld crashes otherwise. This section
will be stripped by GNU objcpy in a later patch.

Signed-off-by: Gabor Juhos 
Signed-off-by: Daniel Schwierzeck 
---
Changes since v1:
- add back the .deadcode section (see code comment for explanation)

 arch/mips/cpu/u-boot.lds | 42 +-
 1 file changed, 41 insertions(+), 1 deletion(-)

diff --git a/arch/mips/cpu/u-boot.lds b/arch/mips/cpu/u-boot.lds
index 4cd983a..10513ab 100644
--- a/arch/mips/cpu/u-boot.lds
+++ b/arch/mips/cpu/u-boot.lds
@@ -70,7 +70,35 @@ SECTIONS
. = ALIGN(4);
__image_copy_end = .;

-   .bss : {
+   .rel.dyn : {
+   __rel_dyn_start = .;
+   *(.rel.dyn)
+   __rel_dyn_end = .;
+   }
+
+   .deadcode : {
+   /*
+* Workaround for a binutils feature (or bug?).
+*
+* The GNU ld from binutils puts the dynamic relocation
+* entries into the .rel.dyn section. Sometimes it
+* allocates more dynamic relocation entries than it needs
+* and the unused slots are set to R_MIPS_NONE entries.
+*
+* However the size of the .rel.dyn section in the ELF
+* section header does not cover the unused entries, so
+* objcopy removes those during stripping.
+*
+* Create a small section here to avoid that.
+*/
+   LONG(0x);
+   }
+
+   .dynsym : {
+   *(.dynsym)
+   }
+
+   .bss __rel_dyn_start (OVERLAY) : {
__bss_start = .;
*(.sbss.*)
*(.bss.*)
@@ -78,4 +106,16 @@ SECTIONS
. = ALIGN(4);
__bss_end = .;
}
+
+   /DISCARD/ : {
+   *(.dynbss)
+   *(.dynstr)
+   *(.dynamic)
+   *(.interp)
+   *(.hash)
+   *(.gnu.*)
+   *(.plt)
+   *(.got.plt)
+   *(.rel.plt)
+   }
 }
--
1.8.1.1

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

[U-Boot] [PATCH v2] build: imx: Fix 'u-boot.imx' build without full OBJTREE reference

[Otavio Salvador]

When calling 'make u-boot.imx' the build were failing as it were
expecting the full path for the file; this regression has been
included by commit 71a988a (imximage.cfg: run files through C
preprocessor).

The direct references for u-boot.imx were replaced by $(obj) as
config.mk handles the proper setting of it making it set to $(OBJTREE)
when required.

The build has been test using:

 - ./MAKEALL -s mx5 -s mx6
 - make u-boot.imx
 - make O=/tmp/build

Signed-off-by: Otavio Salvador 
---
Changes in v2:
- Improve commit log
- Fix out of tree build

 Makefile | 4 ++--
 arch/arm/cpu/arm926ejs/config.mk | 2 +-
 arch/arm/cpu/armv7/config.mk | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/Makefile b/Makefile
index f4a9b33..a8c7b7b 100644
--- a/Makefile
+++ b/Makefile
@@ -467,8 +467,8 @@ $(obj)u-boot.img:   $(obj)u-boot.bin
sed -e 's/"[ ]*$$/ for $(BOARD) board"/') \
-d $< $@
 
-$(OBJTREE)/u-boot.imx : $(obj)u-boot.bin $(SUBDIR_TOOLS) depend
-   $(MAKE) -C $(SRCTREE)/arch/arm/imx-common $@
+$(obj)u-boot.imx: $(obj)u-boot.bin depend
+   $(MAKE) -C $(SRCTREE)/arch/arm/imx-common $(OBJTREE)/u-boot.imx
 
 $(obj)u-boot.kwb:   $(obj)u-boot.bin
$(obj)tools/mkimage -n $(CONFIG_SYS_KWD_CONFIG) -T kwbimage \
diff --git a/arch/arm/cpu/arm926ejs/config.mk b/arch/arm/cpu/arm926ejs/config.mk
index 47f24f5..6a3a1bb 100644
--- a/arch/arm/cpu/arm926ejs/config.mk
+++ b/arch/arm/cpu/arm926ejs/config.mk
@@ -34,6 +34,6 @@ PLATFORM_RELFLAGS += $(PF_RELFLAGS_SLB_AT)
 
 ifneq ($(CONFIG_IMX_CONFIG),)
 
-ALL-y  += $(OBJTREE)/u-boot.imx
+ALL-y  += $(obj)u-boot.imx
 
 endif
diff --git a/arch/arm/cpu/armv7/config.mk b/arch/arm/cpu/armv7/config.mk
index 350e946..9c3e2f3 100644
--- a/arch/arm/cpu/armv7/config.mk
+++ b/arch/arm/cpu/armv7/config.mk
@@ -40,5 +40,5 @@ PF_NO_UNALIGNED := $(call cc-option, -mno-unaligned-access,)
 PLATFORM_NO_UNALIGNED := $(PF_NO_UNALIGNED)
 
 ifneq ($(CONFIG_IMX_CONFIG),)
-ALL-y  += $(OBJTREE)/u-boot.imx
+ALL-y  += $(obj)u-boot.imx
 endif
-- 
1.8.1

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

Re: [U-Boot] [PATCH v1 6/7] MIPS: u-boot.lds: add relocation specific sections

[Daniel Schwierzeck]

2013/2/11 Gabor Juhos :
>> that's weird. Actually I checked after each patch if the *_end symbols
>> match the U-Boot binary size. Now I checked again with different
>> toolchains (gcc-4.[5,6,7], binutils-2.[21.53,22] and I have again that
>> binutils issue.
>>
>> But all toolchains have one in common (tested with qemu_mips):
>> __rel_dyn_end - __rel_dyn_start = 0x1770
>> size from readelf = 0x15f8
>>
>> Another problem is that your .deadcode workaround does not work
>> anymore for me. It does not matter how I arrange or drop the unneeded
>> sections, the size of .rel.dyn remains at 0x1770. I'll try to find
>> another solution.
>
> Erm, the presence of the .deadcode section does not change the size of the
> .rel.dyn section.
>
> The ELF headers shows that there is a gap between the .rel.dyn and the 
> .deadcode
> section:
>
>   [ 6] .rel.dyn  REL bfc30804 030864 0015f8 08   A  8   0 
>  4
>   [ 7] .deadcode PROGBITSbfc31f74 031fd4 04 00  WA  0   0 
>  1
>
> However objcopy will copy the .deadcode section into the final binary because 
> it
> is placed after the .rel.dyn section, and the gap will be filled with 0xff 
> bytes.
>
> As a result, the size of u-boot.bin will equal to (__rel_dyn_end - __start + 
> 4),
> and this ensures that it will contain the full .rel.dyn section.
>

ok.
I guess I misunderstood the intention of your workaround. My goal was
to minimize the increase of image size caused by PIE.

I'll send a v2 of patch 6/7 with the .deadcode section.

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

Re: [U-Boot] [PATCH v1 6/7] MIPS: u-boot.lds: add relocation specific sections

[Gabor Juhos]

> that's weird. Actually I checked after each patch if the *_end symbols
> match the U-Boot binary size. Now I checked again with different
> toolchains (gcc-4.[5,6,7], binutils-2.[21.53,22] and I have again that
> binutils issue.
> 
> But all toolchains have one in common (tested with qemu_mips):
> __rel_dyn_end - __rel_dyn_start = 0x1770
> size from readelf = 0x15f8
> 
> Another problem is that your .deadcode workaround does not work
> anymore for me. It does not matter how I arrange or drop the unneeded
> sections, the size of .rel.dyn remains at 0x1770. I'll try to find
> another solution.

Erm, the presence of the .deadcode section does not change the size of the
.rel.dyn section.

The ELF headers shows that there is a gap between the .rel.dyn and the .deadcode
section:

  [ 6] .rel.dyn  REL bfc30804 030864 0015f8 08   A  8   0  4
  [ 7] .deadcode PROGBITSbfc31f74 031fd4 04 00  WA  0   0  1

However objcopy will copy the .deadcode section into the final binary because it
is placed after the .rel.dyn section, and the gap will be filled with 0xff 
bytes.

As a result, the size of u-boot.bin will equal to (__rel_dyn_end - __start + 4),
and this ensures that it will contain the full .rel.dyn section.

$ ls -l u-boot.bin
-rw-r--r-- 1 juhosg root 204664 Feb 11 14:46 u-boot.bin

This is with the attached patch applied on top of the mips/reloc branch.

-Gabor

>From 07bbc17f35a78bbace7d91477643497f8b51cc0c Mon Sep 17 00:00:00 2001
From: Gabor Juhos 
Date: Mon, 11 Feb 2013 15:06:17 +0100
Subject: [PATCH] MIPS: u-boot.lds: add back the .deadcode section

---
 arch/mips/cpu/u-boot.lds |   18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/mips/cpu/u-boot.lds b/arch/mips/cpu/u-boot.lds
index cea9533..10513ab 100644
--- a/arch/mips/cpu/u-boot.lds
+++ b/arch/mips/cpu/u-boot.lds
@@ -76,6 +76,24 @@ SECTIONS
 		__rel_dyn_end = .;
 	}
 
+	.deadcode : {
+		/*
+		 * Workaround for a binutils feature (or bug?).
+		 *
+		 * The GNU ld from binutils puts the dynamic relocation
+		 * entries into the .rel.dyn section. Sometimes it
+		 * allocates more dynamic relocation entries than it needs
+		 * and the unused slots are set to R_MIPS_NONE entries.
+		 *
+		 * However the size of the .rel.dyn section in the ELF
+		 * section header does not cover the unused entries, so
+		 * objcopy removes those during stripping.
+		 *
+		 * Create a small section here to avoid that.
+		 */
+		LONG(0x);
+	}
+
 	.dynsym : {
 		*(.dynsym)
 	}
-- 
1.7.10

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

Re: [U-Boot] [PATCH] mmc:sdhci:fix: Change default interrupts enabled at SDHCI initialization

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/11/2013 03:50 AM, Lukasz Majewski wrote:
> Dear All,
> 
> Any feedback about this patch?
> 
> It has been on the list for quite long time.

This is one of the patches that I really want Andy to chime in on.

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

iQIcBAEBAgAGBQJRGPj/AAoJENk4IS6UOR1WTmsP/3Qa4YAmLosshxWbjZNxqc3F
a9MfL8XLzPF9qs1qp1p4VmeviVEHTmEXLgZP61+gdvxhayRKAPV5xuEd4LstWO5d
rKHVvN1pwm+rQPNWfuIkptySXsGfe+JBZUoiQ934psRxDy+2Ji6DExG+Vl3ThfCD
bmWd5kfktHCMNwgYFCuU7v8RbR/dbUIiSGtIw0t6LKI8b+csE9QCF8LVjhSDFKb5
dpFvxKjjDu1NWXMz0mrGvccLb7q8WNrZOGjhV3RSaTWB7UCUI2aJ9i+Fz3e7w4lZ
OA+cI/IwgqJA8R3+iikITw3qseLVEz35WqyYhdrdW9HZV1h3Eqn/UO8Z+/9YsCh0
dhlDtDd7lFBvgB35WzFtLE13RpiHbowWvux06qfohXfzC2M42O+EvYeqvKnkKKtD
bzZWLhUhe+e7JA5JJudyOtz/4Lk3j9Xt1hjZamFyiIlqtoOWHQihyhp0w7BfasUt
3HZrbud+KIM/Odv045Mvhi//V8Fsu/RziNGw9OAbO4nsNkCXh/qU9zQ1qUjbFzQx
DC/RpSMxEpFc7pAfiTpSwUTSpNNkFDbBKaIA7jOXdC8xpW2UmvSjARlpGWKOKj1z
3OMoR/CYpFaG0gvlkl16RsebmZf7mEKECLdOO4SUrw5W8PwFeRwDhoZx1Qqvg5sh
ZgFdVkDk2nu85cUcsmJq
=xiNx
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v1 6/7] MIPS: u-boot.lds: add relocation specific sections

[Daniel Schwierzeck]

2013/2/11 Gabor Juhos :
> 2013.02.09. 21:33 keltezéssel, daniel.schwierz...@gmail.com írta:
>> From: Gabor Juhos 
>>
>> This section contain the table needed for dynamic
>> relocation. Also provide symbols for the relocation
>> code to access the table.
>>
>> Discard all sections which are not needed in the final
>> ELF binary and U-Boot image. Section .dynsym cannot be
>> discarded or GNU ld crashes otherwise. This section
>> will be stripped by GNU objcpy in a later patch.
>>
>> Signed-off-by: Gabor Juhos 
>> Signed-off-by: Daniel Schwierzeck 
>> ---
>>  arch/mips/cpu/u-boot.lds | 24 +++-
>>  1 file changed, 23 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/mips/cpu/u-boot.lds b/arch/mips/cpu/u-boot.lds
>> index 4cd983a..cea9533 100644
>> --- a/arch/mips/cpu/u-boot.lds
>> +++ b/arch/mips/cpu/u-boot.lds
>> @@ -70,7 +70,17 @@ SECTIONS
>>   . = ALIGN(4);
>>   __image_copy_end = .;
>>
>> - .bss : {
>> + .rel.dyn : {
>> + __rel_dyn_start = .;
>> + *(.rel.dyn)
>> + __rel_dyn_end = .;
>> + }
>> +
>> + .dynsym : {
>> + *(.dynsym)
>> + }
>
> This is not enough to avoid the binutils issue I have mentioned in the 
> original
> patch. The issue is present after applying this series.
>
> The following example comes from the qemu_mips target compiled with the ELDK 
> 5.3
> toolchain:
>
>> $ mips-linux-objdump --disassemble u-boot | grep bfc005[67]
>> bfc00560:   nop
>> bfc00564:   bfc31f74cache   0x3,8052(s8)<--- __rel_dyn_end
>
> The offset of __rel_dyn_end:
> 0x0bfc31f74 - 0xbfc0 = 0x31f74 = 204660
>
>> bfc00568:   bfc30804cache   0x3,2052(s8)
>> bfc0056c:   bfc30804cache   0x3,2052(s8)
>> bfc00570:   bfc2fa70cache   0x2,-1424(s8)
>> bfc00574:   01df0x1df
>> bfc00578 :
>> bfc00578:   8d0bfffclw  t3,-4(t0)
>> bfc0057c:   8d0cfff8lw  t4,-8(t0)
>
>> $ ls -l u-boot.bin
>> -rw-r--r-- 1 juhosg root 204284 Feb 11 11:29 u-boot.bin
>
> 204660 - 204284 = 376 bytes are missing from the final u-boot.bin.
>
> -Gabor
>

that's weird. Actually I checked after each patch if the *_end symbols
match the U-Boot binary size. Now I checked again with different
toolchains (gcc-4.[5,6,7], binutils-2.[21.53,22] and I have again that
binutils issue.

But all toolchains have one in common (tested with qemu_mips):
__rel_dyn_end - __rel_dyn_start = 0x1770
size from readelf = 0x15f8

Another problem is that your .deadcode workaround does not work
anymore for me. It does not matter how I arrange or drop the unneeded
sections, the size of .rel.dyn remains at 0x1770. I'll try to find
another solution.
-- 
Best regards,
Daniel
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 10/10] mx23_olinuxino: Add ethernet support

[Otavio Salvador]

This adds support to the LAN9512 chip included in the board and extend
the environment to easy netboot use.

Signed-off-by: Otavio Salvador 
---
Changes in v2:
- Remove extra newline

 include/configs/mx23_olinuxino.h | 39 ---
 1 file changed, 36 insertions(+), 3 deletions(-)

diff --git a/include/configs/mx23_olinuxino.h b/include/configs/mx23_olinuxino.h
index e081c49..dfba0fc 100644
--- a/include/configs/mx23_olinuxino.h
+++ b/include/configs/mx23_olinuxino.h
@@ -55,11 +55,13 @@
 #defineCONFIG_DOS_PARTITION
 
 #defineCONFIG_CMD_CACHE
+#defineCONFIG_CMD_DHCP
 #defineCONFIG_CMD_EXT2
 #defineCONFIG_CMD_FAT
 #defineCONFIG_CMD_GPIO
 #defineCONFIG_CMD_LED
 #defineCONFIG_CMD_MMC
+#defineCONFIG_CMD_NET
 #defineCONFIG_CMD_USB
 
 /*
@@ -150,6 +152,12 @@
 #defineCONFIG_USB_STORAGE
 #endif
 
+/* Ethernet */
+#ifdef CONFIG_CMD_NET
+#defineCONFIG_USB_HOST_ETHER
+#defineCONFIG_USB_ETHER_SMSC95XX
+#endif
+
 /*
  * Boot Linux
  */
@@ -191,6 +199,7 @@
"fdt_file=imx23-olinuxino.dtb\0" \
"fdt_addr=0x4100\0" \
"boot_fdt=try\0" \
+   "ip_dyn=yes\0" \
"mmcdev=0\0" \
"mmcpart=2\0" \
"mmcroot=/dev/mmcblk0p3 rw rootwait\0" \
@@ -216,6 +225,31 @@
"fi; " \
"else " \
"bootm; " \
+   "fi;\0" \
+   "netargs=setenv bootargs console=${console_mainline},${baudrate} " \
+   "root=/dev/nfs " \
+   "ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \
+   "netboot=echo Booting from net ...; " \
+   "usb start; " \
+   "run netargs; " \
+   "if test ${ip_dyn} = yes; then " \
+   "setenv get_cmd dhcp; " \
+   "else " \
+   "setenv get_cmd tftp; " \
+   "fi; " \
+   "${get_cmd} ${uimage}; " \
+   "if test ${boot_fdt} = yes; then " \
+   "if ${get_cmd} ${fdt_addr} ${fdt_file}; then " \
+   "bootm ${loadaddr} - ${fdt_addr}; " \
+   "else " \
+   "if test ${boot_fdt} = try; then " \
+   "bootm; " \
+   "else " \
+   "echo WARN: Cannot load the DT; " \
+   "fi;" \
+   "fi; " \
+   "else " \
+   "bootm; " \
"fi;\0"
 
 #define CONFIG_BOOTCOMMAND \
@@ -225,10 +259,9 @@
"else " \
"if run loaduimage; then " \
"run mmcboot; " \
-   "else " \
-   "echo ERR: Fail to boot from MMC; " \
+   "else run netboot; " \
"fi; " \
"fi; " \
-   "else exit; fi"
+   "else run netboot; fi"
 
 #endif /* __MX23_OLINUXINO_CONFIG_H__ */
-- 
1.8.1

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

[U-Boot] [PATCH v2 09/10] mx23_olinuxino: Enable USB support

[Otavio Salvador]

This enabled USB support for the mx23_olinuxino board.

Signed-off-by: Otavio Salvador 
---
Changes in v2:
- Add changes for allow use of the USB hub

 board/olimex/mx23_olinuxino/mx23_olinuxino.c |  6 ++
 board/olimex/mx23_olinuxino/spl_boot.c   |  4 
 include/configs/mx23_olinuxino.h | 10 ++
 3 files changed, 20 insertions(+)

diff --git a/board/olimex/mx23_olinuxino/mx23_olinuxino.c 
b/board/olimex/mx23_olinuxino/mx23_olinuxino.c
index 2501417..9ed7718 100644
--- a/board/olimex/mx23_olinuxino/mx23_olinuxino.c
+++ b/board/olimex/mx23_olinuxino/mx23_olinuxino.c
@@ -23,6 +23,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -45,6 +46,11 @@ int board_early_init_f(void)
/* SSP0 clock at 96MHz */
mxs_set_sspclk(MXC_SSPCLK0, 96000, 0);
 
+#ifdef CONFIG_CMD_USB
+   /* Enable LAN9512 */
+   gpio_direction_output(MX23_PAD_GPMI_ALE__GPIO_0_17, 1);
+#endif
+
return 0;
 }
 
diff --git a/board/olimex/mx23_olinuxino/spl_boot.c 
b/board/olimex/mx23_olinuxino/spl_boot.c
index 3bbf5ad..a96c293 100644
--- a/board/olimex/mx23_olinuxino/spl_boot.c
+++ b/board/olimex/mx23_olinuxino/spl_boot.c
@@ -95,6 +95,10 @@ const iomux_cfg_t iomux_setup[] = {
MX23_PAD_SSP1_DATA2__SSP1_DATA2 | MUX_CONFIG_SSP,
MX23_PAD_SSP1_DATA3__SSP1_DATA3 | MUX_CONFIG_SSP,
MX23_PAD_SSP1_SCK__SSP1_SCK | MUX_CONFIG_SSP,
+
+   /* Ethernet */
+   MX23_PAD_GPMI_ALE__GPIO_0_17 |
+   (MXS_PAD_3V3 | MXS_PAD_12MA | MXS_PAD_NOPULL),
 };
 
 void board_init_ll(void)
diff --git a/include/configs/mx23_olinuxino.h b/include/configs/mx23_olinuxino.h
index d019944..e081c49 100644
--- a/include/configs/mx23_olinuxino.h
+++ b/include/configs/mx23_olinuxino.h
@@ -60,6 +60,7 @@
 #defineCONFIG_CMD_GPIO
 #defineCONFIG_CMD_LED
 #defineCONFIG_CMD_MMC
+#defineCONFIG_CMD_USB
 
 /*
  * Memory configurations
@@ -140,6 +141,15 @@
  */
 #define CONFIG_APBH_DMA
 
+/* USB */
+#ifdef CONFIG_CMD_USB
+#defineCONFIG_USB_EHCI
+#defineCONFIG_USB_EHCI_MXS
+#defineCONFIG_EHCI_MXS_PORT 0
+#defineCONFIG_EHCI_IS_TDI
+#defineCONFIG_USB_STORAGE
+#endif
+
 /*
  * Boot Linux
  */
-- 
1.8.1

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

[U-Boot] [PATCH v2 08/10] mx23evk: Enable USB support

[Otavio Salvador]

This enabled USB support for the mx23evk board.

Signed-off-by: Otavio Salvador 
---
Changes in v2: None

 include/configs/mx23evk.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/include/configs/mx23evk.h b/include/configs/mx23evk.h
index c44a8b8..8db6283 100644
--- a/include/configs/mx23evk.h
+++ b/include/configs/mx23evk.h
@@ -60,6 +60,7 @@
 #define CONFIG_CMD_FAT
 #define CONFIG_CMD_GPIO
 #define CONFIG_CMD_MMC
+#define CONFIG_CMD_USB
 #define CONFIG_CMD_BOOTZ
 
 /* Memory configurations */
@@ -125,6 +126,15 @@
 #define CONFIG_MXS_MMC
 #endif
 
+/* USB */
+#ifdef CONFIG_CMD_USB
+#defineCONFIG_USB_EHCI
+#defineCONFIG_USB_EHCI_MXS
+#defineCONFIG_EHCI_MXS_PORT 0
+#defineCONFIG_EHCI_IS_TDI
+#defineCONFIG_USB_STORAGE
+#endif
+
 /* Boot Linux */
 #define CONFIG_CMDLINE_TAG
 #define CONFIG_SETUP_MEMORY_TAGS
-- 
1.8.1

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

[U-Boot] [PATCH v2 07/10] usb: mxs: Disable USB Port 1 for i.MX23

[Otavio Salvador]

The i.MX23 just one USB port so disable the second controller probe
when building for i.MX23.

Signed-off-by: Otavio Salvador 
---
Changes in v2:
- Avoid wrong clock setting in MX23

 drivers/usb/host/ehci-mxs.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/usb/host/ehci-mxs.c b/drivers/usb/host/ehci-mxs.c
index 5062af5..b7bf856 100644
--- a/drivers/usb/host/ehci-mxs.c
+++ b/drivers/usb/host/ehci-mxs.c
@@ -50,10 +50,12 @@ int mxs_ehci_get_port(struct ehci_mxs *mxs_usb, int port)
usb_base = MXS_USBCTRL0_BASE;
phy_base = MXS_USBPHY0_BASE;
break;
+#ifdef CONFIG_MX28
case 1:
usb_base = MXS_USBCTRL1_BASE;
phy_base = MXS_USBPHY1_BASE;
break;
+#endif
default:
printf("CONFIG_EHCI_MXS_PORT (port = %d)\n", port);
return -1;
@@ -67,7 +69,9 @@ int mxs_ehci_get_port(struct ehci_mxs *mxs_usb, int port)
 /* This DIGCTL register ungates clock to USB */
 #defineHW_DIGCTL_CTRL  0x8001c000
 #defineHW_DIGCTL_CTRL_USB0_CLKGATE (1 << 2)
+#ifdef CONFIG_MX28
 #defineHW_DIGCTL_CTRL_USB1_CLKGATE (1 << 16)
+#endif
 
 int ehci_hcd_init(int index, struct ehci_hccr **hccr, struct ehci_hcor **hcor)
 {
@@ -95,8 +99,12 @@ int ehci_hcd_init(int index, struct ehci_hccr **hccr, struct 
ehci_hcor **hcor)
writel(CLKCTRL_PLL1CTRL0_EN_USB_CLKS | CLKCTRL_PLL1CTRL0_POWER,
&clkctrl_regs->hw_clkctrl_pll1ctrl0_set);
 
+#if defined(CONFIG_MX23)
+   writel(HW_DIGCTL_CTRL_USB0_CLKGATE, &digctl_ctrl->reg_clr);
+#elif defined(CONFIG_MX28)
writel(HW_DIGCTL_CTRL_USB0_CLKGATE | HW_DIGCTL_CTRL_USB1_CLKGATE,
&digctl_ctrl->reg_clr);
+#endif
 
/* Start USB PHY */
writel(0, &ehci_mxs.phy_regs->hw_usbphy_pwd);
@@ -153,8 +161,12 @@ int ehci_hcd_stop(int index)
&clkctrl_regs->hw_clkctrl_pll1ctrl0_clr);
 
/* Gate off the USB clock */
+#if defined(CONFIG_MX23)
+   writel(HW_DIGCTL_CTRL_USB0_CLKGATE, &digctl_ctrl->reg_set);
+#elif defined(CONFIG_MX28)
writel(HW_DIGCTL_CTRL_USB0_CLKGATE | HW_DIGCTL_CTRL_USB1_CLKGATE,
&digctl_ctrl->reg_set);
+#endif
 
return 0;
 }
-- 
1.8.1

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

[U-Boot] [PATCH v2 06/10] mx23_olinuxino: Add support for status LED

[Otavio Salvador]

This allow user to know if the bootloader is running, even without a
serial console.

Signed-off-by: Otavio Salvador 
---
Changes in v2:
- Use MUX pin name - Requested by Marek

 board/olimex/mx23_olinuxino/mx23_olinuxino.c |  7 +++
 board/olimex/mx23_olinuxino/spl_boot.c   |  4 
 include/configs/mx23_olinuxino.h | 14 ++
 3 files changed, 25 insertions(+)

diff --git a/board/olimex/mx23_olinuxino/mx23_olinuxino.c 
b/board/olimex/mx23_olinuxino/mx23_olinuxino.c
index 6a6053b..2501417 100644
--- a/board/olimex/mx23_olinuxino/mx23_olinuxino.c
+++ b/board/olimex/mx23_olinuxino/mx23_olinuxino.c
@@ -28,6 +28,9 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_STATUS_LED
+#include 
+#endif
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -67,5 +70,9 @@ int board_init(void)
/* Adress of boot parameters */
gd->bd->bi_boot_params = PHYS_SDRAM_1 + 0x100;
 
+#if defined(CONFIG_STATUS_LED) && defined(STATUS_LED_BOOT)
+   status_led_set(STATUS_LED_BOOT, STATUS_LED_STATE);
+#endif
+
return 0;
 }
diff --git a/board/olimex/mx23_olinuxino/spl_boot.c 
b/board/olimex/mx23_olinuxino/spl_boot.c
index 7def8bc..3bbf5ad 100644
--- a/board/olimex/mx23_olinuxino/spl_boot.c
+++ b/board/olimex/mx23_olinuxino/spl_boot.c
@@ -84,6 +84,10 @@ const iomux_cfg_t iomux_setup[] = {
MX23_PAD_EMI_RASN__EMI_RASN | MUX_CONFIG_EMI,
MX23_PAD_EMI_WEN__EMI_WEN | MUX_CONFIG_EMI,
 
+   /* Green LED */
+   MX23_PAD_SSP1_DETECT__GPIO_2_1 |
+   (MXS_PAD_3V3 | MXS_PAD_4MA | MXS_PAD_NOPULL),
+
/* MMC 0 */
MX23_PAD_SSP1_CMD__SSP1_CMD | MUX_CONFIG_SSP,
MX23_PAD_SSP1_DATA0__SSP1_DATA0 | MUX_CONFIG_SSP,
diff --git a/include/configs/mx23_olinuxino.h b/include/configs/mx23_olinuxino.h
index 7983c5d..d019944 100644
--- a/include/configs/mx23_olinuxino.h
+++ b/include/configs/mx23_olinuxino.h
@@ -19,6 +19,8 @@
 #ifndef __MX23_OLINUXINO_CONFIG_H__
 #define __MX23_OLINUXINO_CONFIG_H__
 
+#include 
+
 /*
  * SoC configurations
  */
@@ -56,6 +58,7 @@
 #defineCONFIG_CMD_EXT2
 #defineCONFIG_CMD_FAT
 #defineCONFIG_CMD_GPIO
+#defineCONFIG_CMD_LED
 #defineCONFIG_CMD_MMC
 
 /*
@@ -112,6 +115,17 @@
 #defineCONFIG_BAUDRATE 115200  /* Default baud rate */
 
 /*
+ * Status LED
+ */
+#defineCONFIG_STATUS_LED
+#defineCONFIG_GPIO_LED
+#defineCONFIG_BOARD_SPECIFIC_LED
+#defineSTATUS_LED_BOOT 0
+#defineSTATUS_LED_BIT  MX23_PAD_SSP1_DETECT__GPIO_2_1
+#defineSTATUS_LED_STATESTATUS_LED_ON
+#defineSTATUS_LED_PERIOD   (CONFIG_SYS_HZ / 2)
+
+/*
  * MMC Driver
  */
 #ifdef CONFIG_CMD_MMC
-- 
1.8.1

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

[U-Boot] [PATCH v2 05/10] mxs: Fix iomux.h to not break build during assembly stage

[Otavio Salvador]

This fixes the build failure when included in mx23_olinuxino.h board
config; the addition of "asm/types.h" is due "u32" being otherwise
undefined.

Signed-off-by: Otavio Salvador 
---
Changes in v2: None

 arch/arm/include/asm/arch-mxs/iomux.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/include/asm/arch-mxs/iomux.h 
b/arch/arm/include/asm/arch-mxs/iomux.h
index 7abdf58..4288715 100644
--- a/arch/arm/include/asm/arch-mxs/iomux.h
+++ b/arch/arm/include/asm/arch-mxs/iomux.h
@@ -21,6 +21,10 @@
 #ifndef __MACH_MXS_IOMUX_H__
 #define __MACH_MXS_IOMUX_H__
 
+#ifndef __ASSEMBLY__
+
+#include 
+
 /*
  * IOMUX/PAD Bit field definitions
  *
@@ -165,4 +169,5 @@ int mxs_iomux_setup_pad(iomux_cfg_t pad);
  */
 int mxs_iomux_setup_multiple_pads(const iomux_cfg_t *pad_list, unsigned count);
 
+#endif /* __ASSEMBLY__ */
 #endif /* __MACH_MXS_IOMUX_H__*/
-- 
1.8.1

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

[U-Boot] [PATCH v2 04/10] led: Use STATUS_LED_ON and STATUS_LED_OFF when calling __led_set

[Otavio Salvador]

This fixes the gpio_led driver which needs to compare againt a
STATUS_LED_ON to enable a led.

Signed-off-by: Otavio Salvador 
---
Changes in v2: None

 common/cmd_led.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/common/cmd_led.c b/common/cmd_led.c
index 7f5ab43..84f79fa 100644
--- a/common/cmd_led.c
+++ b/common/cmd_led.c
@@ -110,13 +110,15 @@ int do_led (cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
if (led_commands[i].on)
led_commands[i].on();
else
-   __led_set(led_commands[i].mask, 1);
+   __led_set(led_commands[i].mask,
+ STATUS_LED_ON);
break;
case LED_OFF:
if (led_commands[i].off)
led_commands[i].off();
else
-   __led_set(led_commands[i].mask, 0);
+   __led_set(led_commands[i].mask,
+ STATUS_LED_OFF);
break;
case LED_TOGGLE:
if (led_commands[i].toggle)
-- 
1.8.1

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

[U-Boot] [PATCH v2 03/10] mx23evk: Adjust DRAM control register to use full 128MB of RAM

[Otavio Salvador]

Adjust HW_DRAM_CTL14 to enable the chip selects to allow usage of full
128MB of RAM.

Signed-off-by: Otavio Salvador 
---
Changes in v2: None

 board/freescale/mx23evk/spl_boot.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/board/freescale/mx23evk/spl_boot.c 
b/board/freescale/mx23evk/spl_boot.c
index 6007433..b6f4e7e 100644
--- a/board/freescale/mx23evk/spl_boot.c
+++ b/board/freescale/mx23evk/spl_boot.c
@@ -98,6 +98,16 @@ const iomux_cfg_t iomux_setup[] = {
(MXS_PAD_4MA | MXS_PAD_3V3 | MXS_PAD_NOPULL),
 };
 
+#define HW_DRAM_CTL14  (0x38 >> 2)
+#define CS_MAP 0x3
+#define INTAREF0x2
+#define HW_DRAM_CTL14_CONFIG   (INTAREF << 8 | CS_MAP)
+
+void mxs_adjust_memory_params(uint32_t *dram_vals)
+{
+   dram_vals[HW_DRAM_CTL14] = HW_DRAM_CTL14_CONFIG;
+}
+
 void board_init_ll(void)
 {
mxs_common_spl_init(iomux_setup, ARRAY_SIZE(iomux_setup));
-- 
1.8.1

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

[U-Boot] [PATCH v2 02/10] mx23: Document the tRAS lockout setting in memory initialization

[Otavio Salvador]

Add a comment about the tRAS lockout setting of HW_DRAM_CTL08 to
enable the 'Fast Auto Pre-Charge' found in the memory chip. The
setting is applied after memory initialization and it is worth
document it.

Signed-off-by: Otavio Salvador 
---
Changes in v2:
- Extend code comment to explicit say it needs to be there.

 arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c 
b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
index f8392f6..1952eac 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
@@ -119,6 +119,7 @@ static void initialize_dram_values(void)
writel(dram_vals[i], MXS_DRAM_BASE + (4 * i));
 
 #ifdef CONFIG_MX23
+   /* Enable tRAS lockout in HW_DRAM_CTL08 ; it must be after all */
writel((1 << 24), MXS_DRAM_BASE + (4 * 8));
 #endif
 }
-- 
1.8.1

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

[U-Boot] [PATCH v2 0/10] mx23/mxs pending patches

[Otavio Salvador]

This patchset includes the pending patches we have in our tree. It
fixes issues for mx23evk and mx23_olinuxino boards.

The DRAM control register change has been kept specific to mx23evk as
it breaks mx23_olinuxino (as it than reads only 16MB)

Changes in v2:
- Extend code comment to explicit say it needs to be there.
- Use MUX pin name - Requested by Marek
- Avoid wrong clock setting in MX23
- Add changes for allow use of the USB hub
- Remove extra newline

Otavio Salvador (10):
  mxs: Rename CONFIG_SPL_MX28_PSWITCH_WAIT to
CONFIG_SPL_MXS_PSWITCH_WAIT
  mx23: Document the tRAS lockout setting in memory initialization
  mx23evk: Adjust DRAM control register to use full 128MB of RAM
  led: Use STATUS_LED_ON and STATUS_LED_OFF when calling __led_set
  mxs: Fix iomux.h to not break build during assembly stage
  mx23_olinuxino: Add support for status LED
  usb: mxs: Disable USB Port 1 for i.MX23
  mx23evk: Enable USB support
  mx23_olinuxino: Enable USB support
  mx23_olinuxino: Add ethernet support

 arch/arm/cpu/arm926ejs/mxs/mxs_init.h|  2 +-
 arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c|  1 +
 arch/arm/cpu/arm926ejs/mxs/spl_power_init.c  |  2 +-
 arch/arm/include/asm/arch-mxs/iomux.h|  5 +++
 board/freescale/mx23evk/spl_boot.c   | 10 +
 board/olimex/mx23_olinuxino/mx23_olinuxino.c | 13 ++
 board/olimex/mx23_olinuxino/spl_boot.c   |  8 
 common/cmd_led.c |  6 ++-
 drivers/usb/host/ehci-mxs.c  | 12 ++
 include/configs/mx23_olinuxino.h | 63 ++--
 include/configs/mx23evk.h| 10 +
 11 files changed, 125 insertions(+), 7 deletions(-)

-- 
1.8.1

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

[U-Boot] [PATCH v2 01/10] mxs: Rename CONFIG_SPL_MX28_PSWITCH_WAIT to CONFIG_SPL_MXS_PSWITCH_WAIT

[Otavio Salvador]

The power switch option is compatible with i.MX23 and i.MX28 so the
configration option needs to reflect it. We choose
'CONFIG_SPL_MXS_PSWITCH_WAIT' for the option name.

Signed-off-by: Otavio Salvador 
Acked-by: Marek Vasut 
---
Changes in v2: None

 arch/arm/cpu/arm926ejs/mxs/mxs_init.h   | 2 +-
 arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/mxs/mxs_init.h 
b/arch/arm/cpu/arm926ejs/mxs/mxs_init.h
index 2ddc5bc..084def5 100644
--- a/arch/arm/cpu/arm926ejs/mxs/mxs_init.h
+++ b/arch/arm/cpu/arm926ejs/mxs/mxs_init.h
@@ -30,7 +30,7 @@ void early_delay(int delay);
 
 void mxs_power_init(void);
 
-#ifdef CONFIG_SPL_MX28_PSWITCH_WAIT
+#ifdef CONFIG_SPL_MXS_PSWITCH_WAIT
 void mxs_power_wait_pswitch(void);
 #else
 static inline void mxs_power_wait_pswitch(void) { }
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c 
b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
index e9d6302..287c698 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
@@ -921,7 +921,7 @@ void mxs_power_init(void)
early_delay(1000);
 }
 
-#ifdef CONFIG_SPL_MX28_PSWITCH_WAIT
+#ifdef CONFIG_SPL_MXS_PSWITCH_WAIT
 void mxs_power_wait_pswitch(void)
 {
struct mxs_power_regs *power_regs =
-- 
1.8.1

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

Re: [U-Boot] [PATCH 5/5] env: Add redundant env support to UBI env

[Stefan Roese]

On 02/08/2013 09:07 PM, Joe Hershberger wrote:
> Allow the user to specify two UBI volumes to use for the environment
> 
> Signed-off-by: Joe Hershberger 

Some minor comments below.

> ---
>  README|   6 +++
>  common/env_ubi.c  | 115 
> ++
>  include/environment.h |   3 ++
>  tools/env/fw_env.c|   3 ++
>  4 files changed, 127 insertions(+)
> 
> diff --git a/README b/README
> index c46ca3a..baf828a 100644
> --- a/README
> +++ b/README
> @@ -3457,6 +3457,12 @@ but it can not erase, write this NOR flash by SRIO or 
> PCIE interface.
> Define this to the name of the volume that you want to store the
> environment in.
>  
> + - CONFIG_ENV_UBI_VOLUME_REDUND:
> +
> +   Define this to the name of another volume to store a second copy of
> +   the environment in.  This will enable redundant environments in UBI.
> +   It is assumed that both volumes are in the same MTD partition.
> +
>  - CONFIG_SYS_SPI_INIT_OFFSET
>  
>   Defines offset to the initial SPI buffer area in DPRAM. The
> diff --git a/common/env_ubi.c b/common/env_ubi.c
> index 9a47fd2..48f0bcb 100644
> --- a/common/env_ubi.c
> +++ b/common/env_ubi.c
> @@ -47,6 +47,58 @@ int env_init(void)
>  }
>  
>  #ifdef CONFIG_CMD_SAVEENV
> +#ifdef CONFIG_SYS_REDUNDAND_ENVIRONMENT
> +static unsigned char env_flags;
> +
> +int saveenv(void)
> +{
> + ALLOC_CACHE_ALIGN_BUFFER(env_t, env_new, 1);
> + ssize_t len;
> + char *res;
> +
> + res = (char *)&env_new->data;
> + len = hexport_r(&env_htab, '\0', 0, &res, ENV_SIZE, 0, NULL);
> + if (len < 0) {
> + error("Cannot export environment: errno = %d\n", errno);
> + return 1;
> + }
> +
> + if (ubi_part(CONFIG_ENV_UBI_PART, NULL)) {
> + printf("\n** Cannot find mtd partition \"%s\"\n",
> + CONFIG_ENV_UBI_PART);
> + return 1;
> + }
> +
> + env_new->crc = crc32(0, env_new->data, ENV_SIZE);
> + env_new->flags = ++env_flags; /* increase the serial */
> +
> + if (gd->env_valid == 1) {
> + puts("Writing to redundant UBI... ");
> + if (ubi_volume_write(CONFIG_ENV_UBI_VOLUME_REDUND,
> + (void *)env_new, CONFIG_ENV_SIZE)) {
> + printf("\n** Unable to write env to %s:%s **\n",
> + CONFIG_ENV_UBI_PART,
> + CONFIG_ENV_UBI_VOLUME_REDUND);
> + return 1;
> + }
> + } else {
> + puts("Writing to UBI... ");
> + if (ubi_volume_write(CONFIG_ENV_UBI_VOLUME,
> + (void *)env_new, CONFIG_ENV_SIZE)) {
> + printf("\n** Unable to write env to %s:%s **\n",
> + CONFIG_ENV_UBI_PART,
> + CONFIG_ENV_UBI_VOLUME);
> + return 1;
> + }
> + }
> +
> + puts("done\n");
> +
> + gd->env_valid = gd->env_valid == 2 ? 1 : 2;
> +
> + return 0;
> +}
> +#else /* ! CONFIG_SYS_REDUNDAND_ENVIRONMENT */
>  int saveenv(void)
>  {
>   ALLOC_CACHE_ALIGN_BUFFER(env_t, env_new, 1);
> @@ -78,8 +130,70 @@ int saveenv(void)
>   puts("done\n");
>   return 0;
>  }
> +#endif /* CONFIG_SYS_REDUNDAND_ENVIRONMENT */
>  #endif /* CONFIG_CMD_SAVEENV */
>  
> +#ifdef CONFIG_SYS_REDUNDAND_ENVIRONMENT
> +void env_relocate_spec(void)
> +{
> + ALLOC_CACHE_ALIGN_BUFFER(char, env1_buf, CONFIG_ENV_SIZE);
> + ALLOC_CACHE_ALIGN_BUFFER(char, env2_buf, CONFIG_ENV_SIZE);
> + int crc1_ok = 0, crc2_ok = 0;
> + env_t *ep, *tmp_env1, *tmp_env2;
> +
> + tmp_env1 = (env_t *)env1_buf;
> + tmp_env2 = (env_t *)env2_buf;
> +
> + if (ubi_part(CONFIG_ENV_UBI_PART, NULL)) {
> + printf("\n** Cannot find mtd partition \"%s\"\n",
> + CONFIG_ENV_UBI_PART);
> + set_default_env(NULL);
> + return;
> + }
> +
> + if (ubi_volume_read(CONFIG_ENV_UBI_VOLUME, (void *)tmp_env1,
> + CONFIG_ENV_SIZE))
> + printf("\n** Unable to read env from %s:%s **\n",
> + CONFIG_ENV_UBI_PART, CONFIG_ENV_UBI_VOLUME);

Parentheses for multi-line statements.

> +
> + if (ubi_volume_read(CONFIG_ENV_UBI_VOLUME_REDUND, (void *)tmp_env2,
> + CONFIG_ENV_SIZE))
> + printf("\n** Unable to read redundant env from %s:%s **\n",
> + CONFIG_ENV_UBI_PART, CONFIG_ENV_UBI_VOLUME_REDUND);

Here too.

> +
> + crc1_ok = crc32(0, tmp_env1->data, ENV_SIZE) == tmp_env1->crc;
> + crc2_ok = crc32(0, tmp_env2->data, ENV_SIZE) == tmp_env2->crc;
> +
> + if (!crc1_ok && !crc2_ok) {
> + set_default_env("!bad CRC");
> + return;
> + } else if (crc1_ok && !crc2_ok) {
> + gd->env_valid = 1;
> + } else if (!crc1_ok && crc2_ok) {
> + gd->env_valid = 2;
> + } else {
> + /* both ok - ch

Re: [U-Boot] [PATCH 4/5] env: Add support for UBI environment

[Stefan Roese]

On 02/08/2013 09:07 PM, Joe Hershberger wrote:
> UBI is a better place for the environment on NAND devices because it
> handles wear-leveling and bad blocks.
> 
> Gluebi is needed in Linux to access the env as an MTD partition.
> 
> Signed-off-by: Joe Hershberger 

Looks good:

Acked-by: Stefan Roese 

Thanks,
Stefan

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

Re: [U-Boot] [PATCH 3/5] mtd: Make mtdparts work with pre-reloc env

[Stefan Roese]

On 02/08/2013 09:07 PM, Joe Hershberger wrote:
> The env in UBI needs to look up the mtd partition as part of relocation,
> which happens before relocation.  Make the mtdparts code capable of
> working on the default env to start with.
> 
> The code tries to set values in the env as well, but again, the env
> isn't there yet, so add a check to setenv to not allow sets before the
> env is relocated.
> 
> Signed-off-by: Joe Hershberger 

Looks good:

Acked-by: Stefan Roese 

Thanks,
Stefan

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

Re: [U-Boot] [PATCH 2/5] ubi: ubifs: Turn off verbose prints

[Stefan Roese]

On 02/08/2013 09:07 PM, Joe Hershberger wrote:
> The prints are out of control.  SILENCE!
> 
> Signed-off-by: Joe Hershberger 
> ---
>  common/cmd_ubi.c  |  3 +++
>  drivers/mtd/mtdpart.c | 14 --
>  drivers/mtd/ubi/ubi.h |  3 ++-
>  fs/ubifs/ubifs.h  |  2 +-
>  4 files changed, 14 insertions(+), 8 deletions(-)
> 
> diff --git a/common/cmd_ubi.c b/common/cmd_ubi.c
> index 01335dd..02b6b81 100644
> --- a/common/cmd_ubi.c
> +++ b/common/cmd_ubi.c
> @@ -23,6 +23,9 @@
>  #include 
>  #include 
>  
> +#undef ubi_msg
> +#define ubi_msg(fmt, ...) printk(KERN_NOTICE "UBI: " fmt "\n", ##__VA_ARGS__)
> +
>  #define DEV_TYPE_NONE0
>  #define DEV_TYPE_NAND1
>  #define DEV_TYPE_ONENAND 2
> diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
> index 96dcda2..2c60293 100644
> --- a/drivers/mtd/mtdpart.c
> +++ b/drivers/mtd/mtdpart.c
> @@ -347,16 +347,18 @@ static struct mtd_part *add_one_partition(struct 
> mtd_info *master,
>   if (mtd_mod_by_eb(cur_offset, master) != 0) {
>   /* Round up to next erasesize */
>   slave->offset = (mtd_div_by_eb(cur_offset, master) + 1) 
> * master->erasesize;
> - printk(KERN_NOTICE "Moving partition %d: "
> -"0x%012llx -> 0x%012llx\n", partno,
> -(unsigned long long)cur_offset, (unsigned long 
> long)slave->offset);
> + debug("Moving partition %d: 0x%012llx -> 0x%012llx\n",
> + partno, (unsigned long long)cur_offset,
> + (unsigned long long)slave->offset);
>   }
>   }
>   if (slave->mtd.size == MTDPART_SIZ_FULL)
>   slave->mtd.size = master->size - slave->offset;
>  
> - printk(KERN_NOTICE "0x%012llx-0x%012llx : \"%s\"\n", (unsigned long 
> long)slave->offset,
> - (unsigned long long)(slave->offset + slave->mtd.size), 
> slave->mtd.name);
> + debug("0x%012llx-0x%012llx : \"%s\"\n",
> + (unsigned long long)slave->offset,
> + (unsigned long long)(slave->offset + slave->mtd.size),
> + slave->mtd.name);
>  
>   /* let's do some sanity checks */
>   if (slave->offset >= master->size) {
> @@ -463,7 +465,7 @@ int add_mtd_partitions(struct mtd_info *master,
>   if (mtd_partitions.next == NULL)
>   INIT_LIST_HEAD(&mtd_partitions);
>  
> - printk(KERN_NOTICE "Creating %d MTD partitions on \"%s\":\n", nbparts, 
> master->name);
> + debug("Creating %d MTD partitions on \"%s\":\n", nbparts, master->name);

Not so sure about this one. Other users might find this message quite
useful. Does this output really interfere with your UBI env handling?

>   for (i = 0; i < nbparts; i++) {
>   slave = add_one_partition(master, parts + i, i, cur_offset);
> diff --git a/drivers/mtd/ubi/ubi.h b/drivers/mtd/ubi/ubi.h
> index 14c3a5f..f4ed7d8 100644
> --- a/drivers/mtd/ubi/ubi.h
> +++ b/drivers/mtd/ubi/ubi.h
> @@ -59,7 +59,8 @@
>  #define UBI_NAME_STR "ubi"
>  
>  /* Normal UBI messages */
> -#define ubi_msg(fmt, ...) printk(KERN_NOTICE "UBI: " fmt "\n", ##__VA_ARGS__)
> +#define ubi_msg(fmt, ...) /*printk(KERN_NOTICE "UBI: " fmt "\n", \
> + ##__VA_ARGS__)*/

Hmmm

>  /* UBI warning messages */
>  #define ubi_warn(fmt, ...) printk(KERN_WARNING "UBI warning: %s: " fmt "\n", 
> \
> __func__, ##__VA_ARGS__)
> diff --git a/fs/ubifs/ubifs.h b/fs/ubifs/ubifs.h
> index 0af471a..4ab1cbd 100644
> --- a/fs/ubifs/ubifs.h
> +++ b/fs/ubifs/ubifs.h
> @@ -464,7 +464,7 @@ static inline ino_t parent_ino(struct dentry *dentry)
>  
>  /* Normal UBIFS messages */
>  #define ubifs_msg(fmt, ...) \
> - printk(KERN_NOTICE "UBIFS: " fmt "\n", ##__VA_ARGS__)
> + /*printk(KERN_NOTICE "UBIFS: " fmt "\n", ##__VA_ARGS__)*/

... Not sure again about this silencing. And these "removed" printk's
are really ugly.

Could you please give an example of UBI usage (message logs from "ubi
create ..., ubi part ..., ubi read ...") without this patch (or complete
patchset) and with it? So that we see the real difference?

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

Re: [U-Boot] [PATCH v1 6/7] MIPS: u-boot.lds: add relocation specific sections

[Gabor Juhos]

2013.02.09. 21:33 keltezéssel, daniel.schwierz...@gmail.com írta:
> From: Gabor Juhos 
> 
> This section contain the table needed for dynamic
> relocation. Also provide symbols for the relocation
> code to access the table.
> 
> Discard all sections which are not needed in the final
> ELF binary and U-Boot image. Section .dynsym cannot be
> discarded or GNU ld crashes otherwise. This section
> will be stripped by GNU objcpy in a later patch.
> 
> Signed-off-by: Gabor Juhos 
> Signed-off-by: Daniel Schwierzeck 
> ---
>  arch/mips/cpu/u-boot.lds | 24 +++-
>  1 file changed, 23 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/mips/cpu/u-boot.lds b/arch/mips/cpu/u-boot.lds
> index 4cd983a..cea9533 100644
> --- a/arch/mips/cpu/u-boot.lds
> +++ b/arch/mips/cpu/u-boot.lds
> @@ -70,7 +70,17 @@ SECTIONS
>   . = ALIGN(4);
>   __image_copy_end = .;
>  
> - .bss : {
> + .rel.dyn : {
> + __rel_dyn_start = .;
> + *(.rel.dyn)
> + __rel_dyn_end = .;
> + }
> +
> + .dynsym : {
> + *(.dynsym)
> + }

This is not enough to avoid the binutils issue I have mentioned in the original
patch. The issue is present after applying this series.

The following example comes from the qemu_mips target compiled with the ELDK 5.3
toolchain:

> $ mips-linux-objdump --disassemble u-boot | grep bfc005[67]
> bfc00560:   nop
> bfc00564:   bfc31f74cache   0x3,8052(s8)<--- __rel_dyn_end

The offset of __rel_dyn_end:
0x0bfc31f74 - 0xbfc0 = 0x31f74 = 204660

> bfc00568:   bfc30804cache   0x3,2052(s8)
> bfc0056c:   bfc30804cache   0x3,2052(s8)
> bfc00570:   bfc2fa70cache   0x2,-1424(s8)
> bfc00574:   01df0x1df
> bfc00578 :
> bfc00578:   8d0bfffclw  t3,-4(t0)
> bfc0057c:   8d0cfff8lw  t4,-8(t0)

> $ ls -l u-boot.bin
> -rw-r--r-- 1 juhosg root 204284 Feb 11 11:29 u-boot.bin

204660 - 204284 = 376 bytes are missing from the final u-boot.bin.

-Gabor

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

Re: [U-Boot] [PATCH 1/5] ubi: Expose a few simple functions from the cmd_ubi

[Stefan Roese]

On 02/08/2013 09:07 PM, Joe Hershberger wrote:
> Part, Read, and Write functionality that will be used by env_ubi.
> 
> Signed-off-by: Joe Hershberger 

Some minor nitpicking comments below.

> ---
>  common/cmd_ubi.c| 146 
> 
>  include/ubi_uboot.h |   3 ++
>  2 files changed, 83 insertions(+), 66 deletions(-)
> 
> diff --git a/common/cmd_ubi.c b/common/cmd_ubi.c
> index 35b1d31..01335dd 100644
> --- a/common/cmd_ubi.c
> +++ b/common/cmd_ubi.c
> @@ -263,7 +263,7 @@ out_err:
>   return err;
>  }
>  
> -static int ubi_volume_write(char *volume, void *buf, size_t size)
> +int ubi_volume_write(char *volume, void *buf, size_t size)
>  {
>   int err = 1;
>   int rsvd_bytes = 0;
> @@ -308,12 +308,10 @@ static int ubi_volume_write(char *volume, void *buf, 
> size_t size)
>   ubi_gluebi_updated(vol);
>   }
>  
> - printf("%d bytes written to volume %s\n", size, volume);
> -
>   return 0;
>  }
>  
> -static int ubi_volume_read(char *volume, char *buf, size_t size)
> +int ubi_volume_read(char *volume, char *buf, size_t size)
>  {
>   int err, lnum, off, len, tbuf_size;
>   void *tbuf;
> @@ -325,8 +323,6 @@ static int ubi_volume_read(char *volume, char *buf, 
> size_t size)
>   if (vol == NULL)
>   return ENODEV;
>  
> - printf("Read %d bytes from volume %s to %p\n", size, volume, buf);
> -
>   if (vol->updating) {
>   printf("updating");
>   return EBUSY;
> @@ -431,26 +427,82 @@ static int ubi_dev_scan(struct mtd_info *info, char 
> *ubidev,
>   return 0;
>  }
>  
> -static int do_ubi(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[])
> +int ubi_part(char *part_name, const char *vid_header_offset)
>  {
> - size_t size = 0;
> - ulong addr = 0;
>   int err = 0;
> -
> - if (argc < 2)
> - return CMD_RET_USAGE;
> + char mtd_dev[16];
> + struct mtd_device *dev;
> + struct part_info *part;
> + u8 pnum;
>  
>   if (mtdparts_init() != 0) {
>   printf("Error initializing mtdparts!\n");
>   return 1;
>   }
>  
> +#ifdef CONFIG_CMD_UBIFS
> + /*
> +  * Automatically unmount UBIFS partition when user
> +  * changes the UBI device. Otherwise the following
> +  * UBIFS commands will crash.
> +  */
> + if (ubifs_is_mounted())
> + cmd_ubifs_umount();
> +#endif
> +
> + /* todo: get dev number for NAND... */
> + ubi_dev.nr = 0;
> +
> + /*
> +  * Call ubi_exit() before re-initializing the UBI subsystem
> +  */
> + if (ubi_initialized) {
> + ubi_exit();
> + del_mtd_partitions(ubi_dev.mtd_info);
> + }
> +
> + /*
> +  * Search the mtd device number where this partition
> +  * is located
> +  */
> + if (find_dev_and_part(part_name, &dev, &pnum, &part)) {
> + printf("Partition %s not found!\n", part_name);
> + return 1;
> + }
> + sprintf(mtd_dev, "%s%d", MTD_DEV_TYPE(dev->id->type), dev->id->num);
> + ubi_dev.mtd_info = get_mtd_device_nm(mtd_dev);
> + if (IS_ERR(ubi_dev.mtd_info)) {
> + printf("Partition %s not found on device %s!\n", part_name,
> + mtd_dev);
> + return 1;
> + }
> +
> + ubi_dev.selected = 1;
> +
> + strcpy(ubi_dev.part_name, part_name);
> + err = ubi_dev_scan(ubi_dev.mtd_info, ubi_dev.part_name,
> + vid_header_offset);
> + if (err) {
> + printf("UBI init error %d\n", err);
> + ubi_dev.selected = 0;
> + return err;
> + }
> +
> + ubi = ubi_devices[0];
> +
> + return 0;
> +}
> +
> +static int do_ubi(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> +{
> + size_t size = 0;
> + ulong addr = 0;
> +
> + if (argc < 2)
> + return CMD_RET_USAGE;
> +
>   if (strcmp(argv[1], "part") == 0) {
> - char mtd_dev[16];
> - struct mtd_device *dev;
> - struct part_info *part;
>   const char *vid_header_offset = NULL;
> - u8 pnum;
>  
>   /* Print current partition */
>   if (argc == 2) {
> @@ -467,58 +519,10 @@ static int do_ubi(cmd_tbl_t * cmdtp, int flag, int 
> argc, char * const argv[])
>   if (argc < 3)
>   return CMD_RET_USAGE;
>  
> -#ifdef CONFIG_CMD_UBIFS
> - /*
> -  * Automatically unmount UBIFS partition when user
> -  * changes the UBI device. Otherwise the following
> -  * UBIFS commands will crash.
> -  */
> - if (ubifs_is_mounted())
> - cmd_ubifs_umount();
> -#endif
> -
> - /* todo: get dev number for NAND... */
> - ubi_dev.nr = 0;
> -
> - /*
> -  * Call ubi_exit() before re-initializing the UBI subsystem
> -  */
> -  

Re: [U-Boot] [PATCH 0/5] Add support for using an UBI volume for environment

[Stefan Roese]

Hi Joe,

On 02/08/2013 09:07 PM, Joe Hershberger wrote:
> NAND is not good at handling absolute addresses to sectors for storing
> particular data.  The current implementation of the NAND env support
> works around this in several ways such as storing a pointer to the
> sector in the OOB of the first sector (interferes with some CRC) or
> supporting a range of sectors (which unless it is huge is not
> guaranteed to be safe).  None of these options address wear-leveling
> concerns or bad block handling.
> 
> Accessing the u-boot env from UBI eliminates these concerns.  However,
> it does require some of the basic settings for finding the UBI env to
> be in the default u-boot env.

Great. I'll review the patches in a bit and will send some comments.

Thanks,
Stefan

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

Re: [U-Boot] [PATCH] Allow u-boot to be silent without forcing Linux to be

[Stefan Roese]

Hi Joe,

On 02/08/2013 09:17 PM, Joe Hershberger wrote:
> That's a bit presumptuous of you, u-boot!
> 
> Signed-off-by: Joe Hershberger 
> ---
>  common/cmd_bootm.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
> index 7ae5d5b..435c980 100644
> --- a/common/cmd_bootm.c
> +++ b/common/cmd_bootm.c
> @@ -83,7 +83,7 @@ extern flash_info_t flash_info[]; /* info for FLASH chips */
>  static int do_imls(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
> argv[]);
>  #endif
>  
> -#ifdef CONFIG_SILENT_CONSOLE
> +#if defined(CONFIG_SILENT_CONSOLE) && !defined(CONFIG_SILENT_U_BOOT_ONLY)

Could you please add a short description of this new define to the README?

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

Re: [U-Boot] [PATCH v3 00/10] Add Marvell Dove and SolidRun CuBox

[Luka Perkov]

On Mon, Feb 11, 2013 at 10:43:00AM +0100, Sebastian Hesselbarth wrote:
> u-boot has kwboot for kirkwood since ages, but the general functionality
> to boot through UART boot mode also applies to above SoCs. I took
> kwbimage to reflect that kwboot should be used for booting this image.
> IMHO introducing new abbreviated image names like dvbimage will just
> distract people from using the correct tool to boot it. kwboot will not
> be renamed, will it?

I don't mind if we rename kwboot to lets say mvebu-boot. That name would
fit for kirkwood, dove and armada SoCs in the future...

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

Re: [U-Boot] [PATCH v3 00/10] Add Marvell Dove and SolidRun CuBox

[Sebastian Hesselbarth]

On 02/11/2013 04:39 AM, Prafulla Wadaskar wrote:

-Original Message-
From: Sebastian Hesselbarth [mailto:sebastian.hesselba...@gmail.com]
Sent: 17 January 2013 00:55
To: Sebastian Hesselbarth
Cc: u-boot@lists.denx.de; Rabeeh Khoury; Albert Aribaud; Prafulla
Wadaskar; Andy Fleming; Joe Hershberger; Daniel Stodden; Luka Perkov
Subject: [PATCH v3 00/10] Add Marvell Dove and SolidRun CuBox

This patch set add support for the Marvell Dove 88AP510 SoC and
the SolidRun CuBox board based on that SoC. The patch set is divided
into the four following sections:


Dear Sabastian
First of all I express my thanks for initiating this Soc Support in the u-boot.
Secondly I express my apology since I could not review then immediately.
Please find my comments for entire patch series


Prafulla,

thanks for the detailled review! I will quickly give some comments about
some of your review questions and will do a full re-review later.

* About the orion/dove/kirkwood naming convention in linux kernel (that
this patch set picks up):

When I started hacking on linux and marvell SoCs in particular there
was support for orion5x, mv78xx0, kirkwood, and dove. As those SoCs
share a bunch of internal peripherals (you might know better) the
drivers shared between those SoCs were prepended with "orion_" that
should reflect the family of SoCs with that peripherals. I personally
find the naming collision with orion5x "unlucky" but that is the way
it is.

Then there came some effort to also mainline Armada 370/XP series that
of course also share "orion" drivers. The final name for all SoCs
(including "orion") was mvebu as it is the only common naming scheme
that fit (mvebu stands for some business unit within Marvell).

Plans for using just "marvell" or "mv" were rejected because there are
also pxa SoCs from marvell sitting in the kernel tree. They likely share
some of the internal peripherals but that is not reflected within kernel
tree, as there are two different hacking communities I guess.

New drivers that fit all SoCs (namely pinctrl and gpio, because linux
API changes required new drivers from scratch) get mvebu_, drivers that
still fit in "orion" get orion_, new soc specific ones get either
dove_, kirkwood_, armada_370_, or whatever the code name of that SoC is.
Old driver names remain untouched even if they are reused on Armada
370/XP.

Whenever I used orion_ in this patch set this refers to orion as in SoC
family, not orion5x that you might have been irritated with.

* About the kwboot/kwbimage patches:
u-boot has kwboot for kirkwood since ages, but the general functionality
to boot through UART boot mode also applies to above SoCs. I took
kwbimage to reflect that kwboot should be used for booting this image.
IMHO introducing new abbreviated image names like dvbimage will just
distract people from using the correct tool to boot it. kwboot will not
be renamed, will it?

* About the ordering of patches/patch sets:

(1) Patches 1-5:


I have suggestions to break down your patches as mentioned below


Add support for the Dove SoC and related drivers. Where possible
drivers from Marvell Kirkwood are reused (mvsata, mvgbe), or
forked to allow more generic usage (SPI, GPIO). The SDHCI driver
is different and a new driver is added for it. The forked drivers
can also be reused on Kirkwood but that would have required patching
existing boards.

(2) Patches 6-8:
Allow mvgbe to use the phylib API, add support for 88E1310 PHY and
allow Dove to use the driver.

(3) Patch 9
Add the SolidRun CuBox as the first board based on Marvell Dove SoC.

(4) Patch 10
Add support for different UART boot mode found on Dove.

Changelog:
v1->v2:
- respect review comments by Luka Perkov
- fix commenting styles and typos
- add MAINTAINERS entry
- also update kwboot.1 manpage

v2->v3:
- integrate kwboot patch from Daniel Stodden
- rebase on release v2013.01

Sebastian Hesselbarth (10):
   ARM: dove: add support for Marvell Dove SoC
   GPIO: add gpio driver for Orion SoCs
   MMC: sdhci: Add support for dove sdhci
   SPI: Add Orion SPI driver
   block: mvsata: add dove include
   NET: phy: add 88E1310 PHY initialization
   NET: mvgbe: add phylib support
   NET: mvgbe: add support for Dove
   Boards: Add support for SolidRun CuBox
   tools: Add support for Dove to kwboot

  MAINTAINERS |4 +
  arch/arm/cpu/armv7/dove/Makefile|   49 +
  arch/arm/cpu/armv7/dove/cpu.c   |  266
++
  arch/arm/cpu/armv7/dove/dram.c  |  118 
  arch/arm/cpu/armv7/dove/lowlevel_init.S |   83 
  arch/arm/cpu/armv7/dove/mpp.c   |  318
+++
  arch/arm/cpu/armv7/dove/timer.c |  176 +
  arch/arm/cpu/armv7/dove/usb.c   |  101 ++
  arch/arm/include/asm/arch-dove/config.h |  153 +++
  arch/arm/include/asm/arch-dove/cpu.h|  204 
  arch/arm/include/asm/arch-dove/dove.h   |   93 +

Re: [U-Boot] [PATCH] mmc:sdhci:fix: Change default interrupts enabled at SDHCI initialization

[Lukasz Majewski]

Dear All,

Any feedback about this patch?

It has been on the list for quite long time.


> Dear All,
> 
> Any feedback about this patch?
> 
> > This patch changes sdhci_init()'s behavior to NOT enable all
> > interrupt sources by default. Moreover interrupt signaling has been
> > disabled.
> > 
> > This patch do not enable interrupts which aren't served in u-boot
> > (they are defined at sdhci.h but NOT used elsewhere):
> > - SDHCI_INT_CARD_INSERT, SDHCI_INT_CARD_REMOVE, SDHCI_BUS_POWER,
> >   SDHCI_INT_CARD_REMOVE, SDHCI_INT_CARD_INT
> > 
> > Special care shall be put on SDHCI_INT_CARD_INT, which indicates
> > interrupt generated by SD card.
> > According to "SD Host Controller Simplified Spec. ver 3.00" when
> > bit 8 (Card Interrupt Status Enable) at "Normal Interrupt Status
> > Enable Register" (offset 0x34) is set, the card interrupt detection
> > is started. Then eMMC card may cause the SD controller to set this
> > bit and then this interrupt is passed to booted OS and might cause
> > kernel crash.
> > 
> > 
> > To sum up:
> > - Only enable interrupts, which are served at u-boot
> > - This cleanup as a side effect fixes SDHCI's CARD INTERRUPT problem
> > at Linux kernel (versions 3.6+, sdhci controller)
> > - Keep masked bits at "Normal Interrupt Signal Enable
> > Register" (0x38h)
> > 
> > Signed-off-by: Lukasz Majewski 
> > Signed-off-by: Kyungmin Park 
> > Cc: Lei Wen 
> > Cc: Andy Fleming 
> > ---
> >  drivers/mmc/sdhci.c |8 +---
> >  1 files changed, 5 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
> > index 0fd1337..76c14fb 100644
> > --- a/drivers/mmc/sdhci.c
> > +++ b/drivers/mmc/sdhci.c
> > @@ -412,9 +412,11 @@ int sdhci_init(struct mmc *mmc)
> > status = sdhci_readl(host,
> > SDHCI_PRESENT_STATE); }
> >  
> > -   /* Eable all state */
> > -   sdhci_writel(host, SDHCI_INT_ALL_MASK, SDHCI_INT_ENABLE);
> > -   sdhci_writel(host, SDHCI_INT_ALL_MASK,
> > SDHCI_SIGNAL_ENABLE);
> > +   /* Enable only interrupts served by the SD controller */
> > +   sdhci_writel(host, SDHCI_INT_DATA_MASK | SDHCI_INT_CMD_MASK
> > +, SDHCI_INT_ENABLE);
> > +   /* Mask all sdhci interrupt sources */
> > +   sdhci_writel(host, 0x0, SDHCI_SIGNAL_ENABLE);
> >  
> > return 0;
> >  }
> 
> 
> 



-- 
Best regards,

Lukasz Majewski

Samsung R&D Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] u-boot target coreboot: error: impossible constraint in 'asm'

[Altunbas Sabri (DC-IA/EAH2)]

Hi,

I get following error if I compile without optimization (-Os ). I want to 
compile without optimization because I can debug better with my jtag debugger.



gcc  -g-ffunction-sections -fvisibility=hidden -D__KERNEL__ 
-DCONFIG_SYS_TEXT_BASE=0x01008000 -I/home/tux/aaa/myprj/u-boot-2013.01/include 
-fno-builtin -ffreestanding -nostdinc -isystem 
/usr/lib/gcc/i486-linux-gnu/4.7/include -pipe  -fno-strict-aliasing 
-Wstrict-prototypes -mregparm=3 -fomit-frame-pointer -ffreestanding 
-fno-toplevel-reorder -fno-stack-protector -mpreferred-stack-boundary=2 
-fno-dwarf2-cfi-asm -DREALMODE_BASE=0x7c0 -DCONFIG_X86 -D__I386__ -march=i386  
-Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral 
-Wno-format-security -fstack-usage -o cpu.o cpu.c -c
cpu.c: In function 'x86_cpu_init_f':
cpu.c:130:2: warning: asm operand 0 probably doesn't match constraints [enabled 
by default]
cpu.c:130:2: warning: asm operand 1 probably doesn't match constraints [enabled 
by default]
cpu.c:130:2: error: impossible constraint in 'asm'
make[1]: *** [cpu.o] Error 1
make[1]: Leaving directory `/home/tux/aaa/myprj/u-boot-2013.01/arch/x86/cpu'
make: *** [arch/x86/cpu/libx86.o] Error 2


Thanx in advance for some hints

Mit freundlichen Grüßen / Best regards 

Sabri Altunbas 

Entwicklung Basisfirmware DC-IA/EAH2
Bosch Rexroth. The Drive & Control Company

Tel. +49 (0) 6062/78-526
Fax +49 (0) 6062/78-771
sabri.altun...@boschrexroth.de
www.boschrexroth.com

Bosch Rexroth AG
Berliner Straße
64711 Erbach
GERMANY

Firmensitz: Stuttgart, Registrierung: Amtsgericht Stuttgart HRB 23192
Vorstand: Dr. Karl Tragl (Vorsitzender), Dr. Georg Hanen; Dr. Bertram Hoffmann; 
Dr. Stefan Spindler
Vorsitzender des Aufsichtsrats: Dr. Siegfried Dais

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

Re: [U-Boot] [PATCH 4/4] x86: Remove 16-bit reset code

[Graeme Russ]

Hi Simon,

On Sat, Feb 9, 2013 at 3:42 AM, Simon Glass  wrote:
> This code is not needed now, since we boot U-Boot from Coreboot on x86.
>
> Signed-off-by: Simon Glass 
> ---
>  Makefile   |   4 --
>  README |   4 --
>  arch/x86/cpu/Makefile  |   1 -
>  arch/x86/cpu/resetvec.S|  38 
>  arch/x86/cpu/start16.S | 146 
> -
>  include/configs/coreboot.h |   1 -
>  6 files changed, 194 deletions(-)
>  delete mode 100644 arch/x86/cpu/resetvec.S
>  delete mode 100644 arch/x86/cpu/start16.S

As mentioned in reply to the previous patch, I would like to see this code stay

> diff --git a/Makefile b/Makefile
> index 51bd918..1924d4b 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -230,10 +230,6 @@ endif
>  # U-Boot objectsorder is important (i.e. start must be first)
>
>  OBJS  = $(CPUDIR)/start.o
> -ifeq ($(CPU),x86)
> -RESET_OBJS-$(CONFIG_X86_NO_RESET_VECTOR) += $(CPUDIR)/start16.o
> -RESET_OBJS-$(CONFIG_X86_NO_RESET_VECTOR) += $(CPUDIR)/resetvec.o
> -endif

Hmm, odd - the logic here seems to be inverted - the reset vector code
appears to be included if CONFIG_X86_NO_RESET_VECTOR is defined...

Oh, and as discussed before, this can actually be moved out of the
main Makefile and into arch/x86/cpu/Makefile. Hmm, that's odd, it
looks like it already is:

START-y = start.o
RESET_OBJS-$(CONFIG_X86_NO_RESET_VECTOR) += resetvec.o start16.o
COBJS   = interrupts.o cpu.o timer.o

SRCS:= $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS:= $(addprefix $(obj),$(SOBJS) $(COBJS))
START   := $(addprefix $(obj),$(START-y) $(RESET_OBJS-))

But again, the logic seems to be inverted...

> diff --git a/README b/README
> index 103036f..061898c 100644
> --- a/README
> +++ b/README
> @@ -3816,10 +3816,6 @@ Low Level (hardware related) configuration options:
> be used if available. These functions may be faster under some
> conditions but may increase the binary size.
>
> -- CONFIG_X86_NO_RESET_VECTOR
> -   If defined, the x86 reset vector code is excluded. You will 
> need
> -   to do this when U-Boot is running from Coreboot.
> -

Maybe we could just change this to CONFIG_X86_RESET_VECTOR and make
exclusion of the 16-bit reset vector and protected mode switch the
default case

Regards,

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

Re: [U-Boot] [PATCH 2/4] x86: Remove sc520 cpu

[Graeme Russ]

Hi Simon,

On Sat, Feb 9, 2013 at 3:42 AM, Simon Glass  wrote:
> This x86 CPU variant is no longer required as the boards that use it have
> been removed.
>
> Signed-off-by: Simon Glass 
> ---
>  arch/x86/cpu/sc520/Makefile |  58 
>  arch/x86/cpu/sc520/asm-offsets.c|  45 ---
>  arch/x86/cpu/sc520/sc520.c  |  66 -
>  arch/x86/cpu/sc520/sc520_car.S  |  94 ---
>  arch/x86/cpu/sc520/sc520_pci.c  | 142 --
>  arch/x86/cpu/sc520/sc520_reset.c|  40 ---
>  arch/x86/cpu/sc520/sc520_sdram.c| 479 
> 
>  arch/x86/cpu/sc520/sc520_ssi.c  |  93 ---
>  arch/x86/cpu/sc520/sc520_timer.c|  89 --
>  arch/x86/include/asm/arch-sc520/pci.h   |  79 --
>  arch/x86/include/asm/arch-sc520/sc520.h | 372 -
>  arch/x86/include/asm/arch-sc520/ssi.h   |  34 ---
>  12 files changed, 1591 deletions(-)
>  delete mode 100644 arch/x86/cpu/sc520/Makefile
>  delete mode 100644 arch/x86/cpu/sc520/asm-offsets.c
>  delete mode 100644 arch/x86/cpu/sc520/sc520.c
>  delete mode 100644 arch/x86/cpu/sc520/sc520_car.S
>  delete mode 100644 arch/x86/cpu/sc520/sc520_pci.c
>  delete mode 100644 arch/x86/cpu/sc520/sc520_reset.c
>  delete mode 100644 arch/x86/cpu/sc520/sc520_sdram.c
>  delete mode 100644 arch/x86/cpu/sc520/sc520_ssi.c
>  delete mode 100644 arch/x86/cpu/sc520/sc520_timer.c
>  delete mode 100644 arch/x86/include/asm/arch-sc520/pci.h
>  delete mode 100644 arch/x86/include/asm/arch-sc520/sc520.h
>  delete mode 100644 arch/x86/include/asm/arch-sc520/ssi.h

Acked-by: Graeme Russ 

Regards,

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

Re: [U-Boot] [PATCH 3/4] x86: Remove all real mode code

[Graeme Russ]

Hi Simon,

On Sat, Feb 9, 2013 at 3:42 AM, Simon Glass  wrote:
> This code is pretty old and we want to support only 32-bit systems now.
>
> Signed-off-by: Simon Glass 
> ---
>  README  |   5 -
>  arch/x86/config.mk  |   1 -
>  arch/x86/cpu/u-boot.lds |  25 --
>  arch/x86/include/asm/realmode.h |  36 ---
>  arch/x86/lib/Makefile   |  10 -
>  arch/x86/lib/bios.S | 569 
> 
>  arch/x86/lib/bios.h |   3 -
>  arch/x86/lib/bios_pci.S | 447 ---
>  arch/x86/lib/bios_setup.c   | 179 -
>  arch/x86/lib/realmode.c |  93 ---
>  arch/x86/lib/realmode_switch.S  | 232 
>  arch/x86/lib/video.c|   6 -
>  arch/x86/lib/video_bios.c   | 196 --
>  arch/x86/lib/zimage.c   |  23 --
>  14 files changed, 1825 deletions(-)
>  delete mode 100644 arch/x86/include/asm/realmode.h
>  delete mode 100644 arch/x86/lib/bios.S
>  delete mode 100644 arch/x86/lib/bios_pci.S
>  delete mode 100644 arch/x86/lib/bios_setup.c
>  delete mode 100644 arch/x86/lib/realmode.c
>  delete mode 100644 arch/x86/lib/realmode_switch.S
>  delete mode 100644 arch/x86/lib/video_bios.c
>
> diff --git a/README b/README
> index 2352e38..103036f 100644
> --- a/README
> +++ b/README
> @@ -3820,11 +3820,6 @@ Low Level (hardware related) configuration options:
> If defined, the x86 reset vector code is excluded. You will 
> need
> to do this when U-Boot is running from Coreboot.
>
> -- CONFIG_X86_NO_REAL_MODE
> -   If defined, x86 real mode code is omitted. This assumes a
> -   32-bit environment where such code is not needed. You will
> -   need to do this when U-Boot is running from Coreboot.
> -
>
>  Freescale QE/FMAN Firmware Support:
>  ---
> diff --git a/arch/x86/config.mk b/arch/x86/config.mk
> index 23cacff..8356577 100644
> --- a/arch/x86/config.mk
> +++ b/arch/x86/config.mk
> @@ -34,7 +34,6 @@ PF_CPPFLAGS_X86   := $(call cc-option, -ffreestanding) \
>  $(call cc-option, -mpreferred-stack-boundary=2)
>  PLATFORM_CPPFLAGS += $(PF_CPPFLAGS_X86)
>  PLATFORM_CPPFLAGS += -fno-dwarf2-cfi-asm
> -PLATFORM_CPPFLAGS += -DREALMODE_BASE=0x7c0
>
>  PLATFORM_RELFLAGS += -ffunction-sections -fvisibility=hidden
>
> diff --git a/arch/x86/cpu/u-boot.lds b/arch/x86/cpu/u-boot.lds
> index 0c6f0e3..8f5e444 100644
> --- a/arch/x86/cpu/u-boot.lds
> +++ b/arch/x86/cpu/u-boot.lds
> @@ -73,29 +73,4 @@ SECTIONS
> /DISCARD/ : { *(.plt*) }
> /DISCARD/ : { *(.interp*) }
> /DISCARD/ : { *(.gnu*) }
> -
> -   /* 16bit realmode trampoline code */
> -   .realmode REALMODE_BASE : AT ( LOADADDR(.rel.dyn) + SIZEOF(.rel.dyn) 
> ) { KEEP(*(.realmode)) }
> -
> -   __realmode_start = LOADADDR(.realmode);
> -   __realmode_size = SIZEOF(.realmode);
> -
> -   /* 16bit BIOS emulation code (just enough to boot Linux) */
> -   .bios 0 : AT ( LOADADDR(.realmode) + SIZEOF(.realmode) ) { 
> KEEP(*(.bios)) }
> -
> -   __bios_start = LOADADDR(.bios);
> -   __bios_size = SIZEOF(.bios);
> -
> -#ifndef CONFIG_X86_NO_RESET_VECTOR
> -
> -   /*
> -* The following expressions place the 16-bit Real-Mode code and
> -* Reset Vector at the end of the Flash ROM
> -*/
> -   . = START_16;
> -   .start16 : AT (CONFIG_SYS_TEXT_BASE + (CONFIG_SYS_MONITOR_LEN - 
> RESET_SEG_SIZE + START_16)) { KEEP(*(.start16)); }
> -
> -   . = RESET_VEC_LOC;
> -   .resetvec : AT (CONFIG_SYS_TEXT_BASE + (CONFIG_SYS_MONITOR_LEN - 
> RESET_SEG_SIZE + RESET_VEC_LOC)) { KEEP(*(.resetvec)); }
> -#endif

Can we please keep the reset vector and real-to-protected mode code. I
know coreboot does not need it (and hence it is dead code) but it
keeps alive the thought that U-Boot can actually boot an x86 from
power-up

Apart from that, I'll be glad to see the back of this legacy crap :)

Regards,

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

Re: [U-Boot] [PATCH 1/4] x86: Remove eNET boards

[Graeme Russ]

Hi Simon,

On Sat, Feb 9, 2013 at 3:42 AM, Simon Glass  wrote:
> These are no longer used and should be removed.
>
> Signed-off-by: Simon Glass 
> ---
>  board/eNET/Makefile   |  52 
>  board/eNET/eNET.c | 284 -
>  board/eNET/eNET_pci.c | 128 --
>  board/eNET/eNET_start.S   |  30 ---
>  board/eNET/eNET_start16.S |  87 ---
>  board/eNET/hardware.h |  36 ---
>  boards.cfg|   2 -
>  include/configs/eNET.h| 619 
> --
>  8 files changed, 1238 deletions(-)
>  delete mode 100644 board/eNET/Makefile
>  delete mode 100644 board/eNET/eNET.c
>  delete mode 100644 board/eNET/eNET_pci.c
>  delete mode 100644 board/eNET/eNET_start.S
>  delete mode 100644 board/eNET/eNET_start16.S
>  delete mode 100644 board/eNET/hardware.h
>  delete mode 100644 include/configs/eNET.h

Acked-by: Graeme Russ 

Regards,

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

[U-Boot] [PATCH v4] env: Allow accessing non-mtd devices

[Lubomir Rintel]

In certain cases, memory device is present as flat file or block device (via
mmc or mtdblock layer). Do not attempt MTD operations against it.

Signed-off-by: Lubomir Rintel 
---
Changes for v2:
   - Coding Style cleanup
   - Clarified an error message
Changes for v3:
   - Used MTD_ABSENT macro to represent non-MTD devices
   - Cleaned up places when zero was used instead of MTD_ABSENT
Changes for v4:
   - Further clarification to failed fstat() error message
   - Improved flash_read() error handling to include file names

 tools/env/fw_env.c  |   34 +++---
 tools/env/fw_env.config |3 +++
 2 files changed, 26 insertions(+), 11 deletions(-)

diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
index 0c68e24..bf30234 100644
--- a/tools/env/fw_env.c
+++ b/tools/env/fw_env.c
@@ -836,9 +836,9 @@ static int flash_write_buf (int dev, int fd, void *buf, 
size_t count,
 
erase.start = blockstart;
ioctl (fd, MEMUNLOCK, &erase);
-
-   /* Dataflash does not need an explicit erase cycle */
-   if (mtd_type != MTD_DATAFLASH)
+   /* These do not need an explicit erase cycle */
+   if (mtd_type != MTD_ABSENT &&
+   mtd_type != MTD_DATAFLASH)
if (ioctl (fd, MEMERASE, &erase) != 0) {
fprintf (stderr, "MTD erase error on %s: %s\n",
 DEVNAME (dev),
@@ -949,21 +949,33 @@ static int flash_write (int fd_current, int fd_target, 
int dev_target)
 static int flash_read (int fd)
 {
struct mtd_info_user mtdinfo;
+   struct stat st;
int rc;
 
-   rc = ioctl (fd, MEMGETINFO, &mtdinfo);
+   rc = fstat(fd, &st);
if (rc < 0) {
-   fprintf(stderr, "Cannot get MTD information for %s\n",
+   fprintf(stderr, "Cannot stat the file %s\n",
DEVNAME(dev_current));
return -1;
}
 
-   if (mtdinfo.type != MTD_NORFLASH &&
-   mtdinfo.type != MTD_NANDFLASH &&
-   mtdinfo.type != MTD_DATAFLASH) {
-   fprintf (stderr, "Unsupported flash type %u on %s\n",
-mtdinfo.type, DEVNAME(dev_current));
-   return -1;
+   if (S_ISCHR(st.st_mode)) {
+   rc = ioctl(fd, MEMGETINFO, &mtdinfo);
+   if (rc < 0) {
+   fprintf(stderr, "Cannot get MTD information for %s\n",
+   DEVNAME(dev_current));
+   return -1;
+   }
+   if (mtdinfo.type != MTD_NORFLASH &&
+   mtdinfo.type != MTD_NANDFLASH &&
+   mtdinfo.type != MTD_DATAFLASH) {
+   fprintf (stderr, "Unsupported flash type %u on %s\n",
+mtdinfo.type, DEVNAME(dev_current));
+   return -1;
+   }
+   } else {
+   memset(&mtdinfo, 0, sizeof(mtdinfo));
+   mtdinfo.type = MTD_ABSENT;
}
 
DEVTYPE(dev_current) = mtdinfo.type;
diff --git a/tools/env/fw_env.config b/tools/env/fw_env.config
index 8e21d5a..c086512 100644
--- a/tools/env/fw_env.config
+++ b/tools/env/fw_env.config
@@ -17,3 +17,6 @@
 
 # NAND example
 #/dev/mtd0 0x4000  0x4000  0x2 
2
+
+# Block device example
+#/dev/mmcblk0  0xc 0x2
-- 
1.7.1

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