Re: [U-Boot] [Patch V6 0/4] Add basic NVIDIA Tegra2 SoC support

[Mike Rapoport]

On 02/02/11 02:09, Tom Warren wrote:
> I haven't seen any new feedback on this version (V6) of the patchset
> since it was posted.
> 
> Wolfgang, Mike, Peter, et al - are you happy with the current patch?

I'm Ok with the current patch.

> If so, when can I expect it to be pushed?
> 
> Thanks,
> 
> Tom
> 
> On Thu, Jan 27, 2011 at 1:58 PM, Tom Warren  wrote:
>> This series of patches adds preliminary/baseline support for NVIDIA's
>> Tegra2 SoC.  Basic CPU (AVP), RAM and UART init are covered so that the
>> system (Harmony or Seaboard) can boot to the U-Boot serial cmd prompt.
>>
>> Further support (for Cortex-A9 CPU(s), USB, SD/MMC, etc.) to follow.
>>
>> Changes for V2:
>>- Coding style cleanup
>>- Remove mach-types.h change; wait for ARM kernel sync-up
>>- Move serial driver changes to separate patch
>>- Use board/nvidia/ instead of /board/tegra
>>- Remove TRUE/FALSE defines
>>- Use standard NS16550 register/bit defines in UART init
>>- Change nv-common.h config file to tegra2-common.h
>>
>> Changes for V3:
>>- Use I/O accessors for Tegra2 HW MMIO register access
>>- Allow conditional compile of UARTA/UARTD code to save space
>>
>> Changes for V4:
>>- Use address of HW structs (&pmc, etc.) in readl/writel
>>- Remove empty lines, fix mixed case hex #s & comments in header(s)
>>- Move board/nvidia/common/board.c UART code & header to
>>arch/arm/cpu/armv7/tegra2/
>>- Declare internal functions as static in UART code
>>
>> Changes for V5:
>>- Move arch/arm/cpu/armv7/uart.c & board.h to drivers/serial and
>>rename to serial_tegra2.c
>>- Remove use of uart_num & UART_A/D in serial_tegra2, simplify code
>>
>> Changes for V6:
>>- Fix uart.c add & delete in previous patchset
>>- Move pinmux & clock init code to common board file as per review
>>- Use #if defined() where possible in config files/UART code
>>- Drop all typedef and volatile struct declarations in header files
>>
>> Tom Warren (4):
>>  arm: Tegra2: Add basic NVIDIA Tegra2 SoC support
>>  serial: Add Tegra2 serial port support
>>  arm: Tegra2: Add support for NVIDIA Harmony board
>>  arm: Tegra2: Add support for NVIDIA Seaboard board
>>
>>  MAINTAINERS  |5 +
>>  arch/arm/cpu/armv7/tegra2/Makefile   |   48 +++
>>  arch/arm/cpu/armv7/tegra2/board.c|   88 
>>  arch/arm/cpu/armv7/tegra2/config.mk  |   28 
>>  arch/arm/cpu/armv7/tegra2/lowlevel_init.S|   65 +
>>  arch/arm/cpu/armv7/tegra2/sys_info.c |   35 +
>>  arch/arm/cpu/armv7/tegra2/timer.c|  122 
>>  arch/arm/include/asm/arch-tegra2/clk_rst.h   |  165 ++
>>  arch/arm/include/asm/arch-tegra2/pinmux.h|   55 
>>  arch/arm/include/asm/arch-tegra2/pmc.h   |  124 +
>>  arch/arm/include/asm/arch-tegra2/sys_proto.h |   35 +
>>  arch/arm/include/asm/arch-tegra2/tegra2.h|   49 +++
>>  arch/arm/include/asm/arch-tegra2/uart.h  |   47 ++
>>  board/nvidia/common/board.c  |  193 
>> ++
>>  board/nvidia/harmony/Makefile|   50 +++
>>  board/nvidia/seaboard/Makefile   |   50 +++
>>  boards.cfg   |2 +
>>  common/serial.c  |3 +-
>>  drivers/serial/Makefile  |1 +
>>  drivers/serial/serial_tegra2.c   |   77 ++
>>  drivers/serial/serial_tegra2.h   |   29 
>>  include/configs/harmony.h|   49 +++
>>  include/configs/seaboard.h   |   43 ++
>>  include/configs/tegra2-common.h  |  160 +
>>  include/serial.h |3 +-
>>  25 files changed, 1524 insertions(+), 2 deletions(-)
>>  create mode 100644 arch/arm/cpu/armv7/tegra2/Makefile
>>  create mode 100644 arch/arm/cpu/armv7/tegra2/board.c
>>  create mode 100644 arch/arm/cpu/armv7/tegra2/config.mk
>>  create mode 100644 arch/arm/cpu/armv7/tegra2/lowlevel_init.S
>>  create mode 100644 arch/arm/cpu/armv7/tegra2/sys_info.c
>>  create mode 100644 arch/arm/cpu/armv7/tegra2/timer.c
>>  create mode 100644 arch/arm/include/asm/arch-tegra2/clk_rst.h
>>  create mode 100644 arch/arm/include/asm/arch-tegra2/pinmux.h
>>  create mode 100644 arch/arm/include/asm/arch-tegra2/pmc.h
>>  create mode 100644 arch/arm/include/asm/arch-tegra2/sys_proto.h
>>  create mode 100644 arch/arm/include/asm/arch-tegra2/tegra2.h
>>  create mode 100644 arch/arm/include/asm/arch-tegra2/uart.h
>>  create mode 100644 board/nvidia/common/board.c
>>  create mode 100644 board/nvidia/harmony/Makefile
>>  create mode 100644 board/nvidia/seaboard/Makefile
>>  create mode 100644 drivers/serial/serial_tegra2.c
>>  create mode 100644 drivers

[U-Boot] at91sam9263_nandflash build issues

[Marek Vasut]

The problem is clear from this IRC log, where "vickylinuxer" described his 
grief 
(so I included the log, the board really doesn't build). I also did a quick and 
dirty patch (follows the log, it might give you an idea where it breaks, but 
it's a mess -- not all is relevant and it probably breaks it even more).

Cheers

// LOG -

05:01 < vickylinuxer> guys i am making u-boot for at91sam9263 with ubifs 
support...which u-boot version i can prefer...
05:02 < vickylinuxer> because u-boot-12-2010 gave so many compilation 
problems...
05:06 < Marex> vickylinuxer: look ... what's the problem ? what board did you 
config it for ?
05:06 < Marex> vickylinuxer: give me the exact xyz for xyz_config
05:10 < vickylinuxer> at91sam9263_nandflash
05:11 < vickylinuxer> atmel board
05:11 < Marex> compiling, checking ... please wait
05:12 < Marex> I see
05:12 < Marex> vickylinuxer: it'll take a bit to fix it all ... wanna tinker 
with 
it and assist in fixing ?
05:38 < vickylinuxer> yes marex  i want to update from  ver 2010.09 to 
2010.12..but 09 is working good...
05:39 < vickylinuxer> but when compiling uboot-12 i m getting sdram error and 
so 
on...
05:51 < Marex> vickylinuxer: ok well ... there seems to be more breakage than I 
expected
05:57 < Marex> vickylinuxer: try this http://pastebin.com/2Rq92nNg

// DIFF -

diff --git a/config.mk b/config.mk
index 5147c35..fe1d40c 100644
--- a/config.mk
+++ b/config.mk
@@ -261,7 +261,7 @@ $(obj)%.s:  %.c
 
 # If the list of objects to link is empty, just create an empty built-in.o
 cmd_link_o_target = $(if $(strip $1),\
- $(LD) $(LDFLAGS) -r -o $@ $1,\
+ $(LD) -r -o $@ $1,\
  rm -f $@; $(AR) rcs $@ )
 
 #
diff --git a/drivers/serial/atmel_usart.c b/drivers/serial/atmel_usart.c
index bfa1f3a..1cc8bc0 100644
--- a/drivers/serial/atmel_usart.c
+++ b/drivers/serial/atmel_usart.c
@@ -23,6 +23,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #if defined(CONFIG_USART0)
diff --git a/drivers/spi/atmel_dataflash_spi.c 
b/drivers/spi/atmel_dataflash_spi.c
index 4a5c4aa..d5215c0 100644
--- a/drivers/spi/atmel_dataflash_spi.c
+++ b/drivers/spi/atmel_dataflash_spi.c
@@ -158,12 +158,12 @@ unsigned int AT91F_SpiWrite(AT91PS_DataflashDesc pDesc)
}
 
/* arm simple, non interrupt dependent timer */
-   reset_timer_masked();
+   reset_timer();
timeout = 0;
 
writel(AT91_SPI_TXTEN + AT91_SPI_RXTEN, AT91_BASE_SPI + AT91_SPI_PTCR);
while (!(readl(AT91_BASE_SPI + AT91_SPI_SR) & AT91_SPI_RXBUFF) &&
-   ((timeout = get_timer_masked()) < CONFIG_SYS_SPI_WRITE_TOUT));
+   ((timeout = get_timer(0)) < CONFIG_SYS_SPI_WRITE_TOUT));
writel(AT91_SPI_TXTDIS + AT91_SPI_RXTDIS, AT91_BASE_SPI + 
AT91_SPI_PTCR);
pDesc->state = IDLE;
 
diff --git a/include/configs/at91sam9263ek.h b/include/configs/at91sam9263ek.h
index f6cb406..3db8bd0 100644
--- a/include/configs/at91sam9263ek.h
+++ b/include/configs/at91sam9263ek.h
@@ -27,6 +27,9 @@
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
+#define CONFIG_AT91_LEGACY
+#defineCONFIG_AT91FAMILY
+
 /* ARM asynchronous clock */
 #define CONFIG_SYS_AT91_MAIN_CLOCK 16367660/* 16.367 MHz crystal */
 #define CONFIG_SYS_HZ  1000
@@ -341,6 +344,10 @@
  */
 #define CONFIG_SYS_MALLOC_LEN  ROUND(3 * CONFIG_ENV_SIZE + 128*1024, 
0x1000)
 
+#define CONFIG_SYS_SDRAM_BASE  PHYS_SDRAM
+#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_SDRAM_BASE + 0x1000 - \
+   GENERATED_GBL_DATA_SIZE)
+
 #define CONFIG_STACKSIZE   (32*1024)   /* regular stack */
 
 #ifdef CONFIG_USE_IRQ
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] change email address in MAINTAINERS

[Nobuhiro Iwamatsu]

Applied, thanks.

On Wed, Feb 02, 2011 at 10:05:39AM +0900, Yoshihiro Shimoda wrote:
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  This patch depends on "sh: add support for sh7757lcr board".
> 
>  MAINTAINERS |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7313542..c26c9a7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1017,7 +1017,7 @@ Mark Jonas 
> 
>   mpr2SH7720
> 
> -Yoshihiro Shimoda 
> +Yoshihiro Shimoda 
> 
>   MS7720SESH7720
>   R0P77570030RL   SH7757
> -- 
> 1.7.1
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] spi subystem maintainer?

[Kumar Gala]

On Feb 1, 2011, at 1:29 PM, Wolfgang Denk wrote:

> Dear Kumar Gala,
> 
> In message <9a3702c1-3ed1-4f24-a0bc-ca7daea46...@kernel.crashing.org> you 
> wrote:
>> Do we have one?
> 
> Not yet.  Are you volunteering?

Nope, too much to do as it stands.

Wanted to see if anyone had input on how to deal with the SPI controller on 
some of our newer parts.  It expects command & data xfer's to happen together.  
However our current code does not call spi_xfer() that way.

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

Re: [U-Boot] u-boot compilation lowlevel_init.S:619: error: #error "Unknown DDR configuration!!!"

[sughosh ganu]

hi,

On Tue, Feb 1, 2011 at 9:00 PM, Vaishali  wrote:

> Getting this error with the u-boot compilation
> http://pastebin.com/h3x90vHK
> u-boot  is a git clone of the
> git://gitorious.org/hawkboard/u-boot.git
> plz help any idea what needs to be done to fix this .
>

Mainline u-boot has hawkboard support. Why don't you try building and using
that. Check out the doc/README.hawkboard for the procedure to build and
flash.

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

Re: [U-Boot] [PATCH] sh: add support the CONFIG_SYS_LDSCRIPT

[Nobuhiro Iwamatsu]

Applied, thanks.

On Thu, Jan 27, 2011 at 10:06:14AM +0900, Yoshihiro Shimoda wrote:
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  arch/sh/config.mk |4 
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/sh/config.mk b/arch/sh/config.mk
> index 415c949..b408a44 100644
> --- a/arch/sh/config.mk
> +++ b/arch/sh/config.mk
> @@ -31,4 +31,8 @@ endif
>  PLATFORM_CPPFLAGS += -DCONFIG_SH -D__SH__
>  PLATFORM_LDFLAGS += -e $(CONFIG_SYS_TEXT_BASE) --defsym 
> reloc_dst=$(CONFIG_SYS_TEXT_BASE)
> 
> +ifdef CONFIG_SYS_LDSCRIPT
> +LDSCRIPT := $(subst ",,$(CONFIG_SYS_LDSCRIPT))
> +else
>  LDSCRIPT := $(SRCTREE)/$(CPUDIR)/u-boot.lds
> +endif
> -- 
> 1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] u-boot compilation lowlevel_init.S:619: error: #error "Unknown DDR configuration!!!"

[sughosh ganu]

hi,
On Tue, Feb 1, 2011 at 9:00 PM, Vaishali  wrote:

> Getting this error with the u-boot compilation
> http://pastebin.com/h3x90vHK
> u-boot  is a git clone of the
> git://gitorious.org/hawkboard/u-boot.git
> plz help any idea what needs to be done to fix this .
> Thanks .
>

Mainline u-boot has hawkboard support. Why don't you try building and using
that. Check out the doc/README.hawkboard for the procedure to build and
flash.

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

Re: [U-Boot] [PATCH 1/2] mp2usb: remove board support

[Albert ARIBAUD]

Hi Eric,

Le 25/01/2011 23:31, Eric Bénard a écrit :
> this board was cancelled long time ago so remove it as it won't
> be maintained anymore
>
> Signed-off-by: Eric Bénard
> ---
>   board/mp2usb/Makefile|   50 -
>   board/mp2usb/config.mk   |3 -
>   board/mp2usb/flash.c |  552 
> --
>   board/mp2usb/mp2usb.c|   98 
>   include/configs/mp2usb.h |  242 
>   5 files changed, 0 insertions(+), 945 deletions(-)
>   delete mode 100644 board/mp2usb/Makefile
>   delete mode 100644 board/mp2usb/config.mk
>   delete mode 100644 board/mp2usb/flash.c
>   delete mode 100644 board/mp2usb/mp2usb.c
>   delete mode 100644 include/configs/mp2usb.h

This patch does not remove the mp2usb from boards.cfg. Can you please 
fix that?

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

Re: [U-Boot] Trouble running hello_world

[Albert ARIBAUD]

Le 02/02/2011 01:54, Alfred Morgan a écrit :
> Hello clueful people, I am new to U-Boot.
>
> I am having trouble executing anything using U-Boot.  I have read the U-Boot 
> README and Manual.  I have also tried to following the steps on 
> plugcomputer.org's wiki.  I was feeling like I was beginning to get a clue 
> but then I couldn't get anything to work.  I figured a good place to start is 
> trying to execute the u-boot hello_world standalone program but I couldn't 
> even get that to work.
>
> I am connected to the serial port via the GuruPlug JTAG board to my GuruPlug 
> Server Plus and here is my output from the serial console:
> U-Boot 2009.11-rc1-00602-g28a9c08-dirty (Feb 09 2010 - 18:15:21)
> Marvell-Plug2L

This is an old U-Boot. Can you use a newer one?

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

Re: [U-Boot] [PATCH 5/6] powerpc/85xx: do not initialize QE if QE's firmware is in nand flash

[Kumar Gala]

On Jan 31, 2011, at 3:37 PM, Wolfgang Denk wrote:

> Dear Haiying Wang,
> 
> In message <1296507737.2049.518.camel@haiying-laptop> you wrote:
>> On Mon, 2011-01-31 at 21:08 +0100, Wolfgang Denk wrote:
>>> Dear haiying.w...@freescale.com,
>>> 
>>> In message <1296499317-26616-6-git-send-email-haiying.w...@freescale.com> 
>>> you wrote:
 From: Haiying Wang 
 
 For some board which doesn't have NOR flash and the QE's firmware(ucode) is
 saved in its NAND flash, we don't want call qe_init in cpu_init_r, but will
 call it later after nand is initialized.
>>> 
>>> Is there a pressing reason to do this so early for other boards?  Can
>>> not all boards initialize this later?
>>> 
>> My understanding is that QE is a cpu feature, so it is called early in
>> cpu_init_r. As Kumar recommended before, I can move qe_init from
>> cpu_init_r to misc_init_r for every 85xx boards with qe support. Is it
>> acceptable to you?
> 
> Yes, if this way we can avoid to do the same thing at different
> points in the initialization sequence.

Doing this in misc_init_r() isn't right either.

We've had this argument before, can we just add a cpu_init_late_r() that is 
post env_relocate() ?

Why should we duplicate cpu generic code in board code?

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

Re: [U-Boot] [PATCH 6/6] p1021mds: add QE and UEC support

[Kumar Gala]

On Feb 1, 2011, at 1:46 PM, Haiying Wang wrote:

> On Tue, 2011-02-01 at 13:15 -0600, Kumar Gala wrote:
>> On Feb 1, 2011, at 11:01 AM, Haiying Wang wrote:
>> 
>>> On Tue, 2011-02-01 at 10:50 -0600, Scott Wood wrote:
>> 
> If it is a one time setting, there should be no problem to put it into
> board code. But these pin settings need to be done before any usage of
> phy read/write (accessing MDIO/MDC), and need to be released after the
> usage of phy, thus the devices connected to eLBC like NAND flash/BCSR
> can be accessed. If we use board code to set/release the pin, we don't
> know when the phy access and nand flash access will happen.
 
 Is this actually a board issue or an SoC issue?
 
>>> It is not a board issue. It is a SoC *feature*. Too many pins are muxed
>>> on P1021. For this case, LBCTL of eLBC is muxed with QE's CE_PB[20]
>>> which is used for MDIO signal. 
>>> 
>>> Haiying
>>> 
>> 
>> But its a board decision on how they want to utilize those pins and for what 
>> feature.
> 
> Yes, you can say that. If the board doesn't have QE UCC ETH support at
> all, we won't have to add such code in QE driver. But if there is QE UCC
> ETH on board, we have no choice to decide which pins to use. We
> definitely need to use CE_PB[20] for MDIO signal, there is no other GPIO
> pins to use for QE's MDIO.  
> 
> Haiying

If that case and controlled by some CONFIG_QE_* define than we clearly can make 
the choice in non-board specific code.

- k

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

Re: [U-Boot] PCIE supported networking cards?

[Kumar Gala]

You may want to look at the following patch that adds support for 0x10d3:

http://patchwork.ozlabs.org/patch/79788/

- k

On Feb 1, 2011, at 3:32 PM, Aaron Williams wrote:

> This is an Intel EXPI9301 PRO/1000 OEM card, vendor ID 0x8086, device ID 
> 0x10d3. I added it to the list but I don't know what the MAC type is.  I'll 
> look into the Linux driver and see if I can see what it is.
> 
> -Aaron
> 
> On Tuesday, February 01, 2011 11:19:24 am Scott Wood wrote:
>> On Tue, 1 Feb 2011 13:15:01 -0600
>> 
>> Kumar Gala  wrote:
>>> We utilize e1000 PCIe cards all the time
>> 
>> Aren't there some versions that work, and some that don't?
>> 
>> -Scott
>> 
>>> - k
>>> 
>>> On Feb 1, 2011, at 1:10 PM, Aaron Williams wrote:
 Are there any PCIE networking cards that are supported? So far I've
 tried an Intel card and a Realtek RTL8168 card, but neither is
 supported. It looks like the E1000 driver only supports PCI and PCIX
 based cards (Linux uses the e1000e card for PCIe cards).
 
 -Aaron
 ___
 U-Boot mailing list
 U-Boot@lists.denx.de
 http://lists.denx.de/mailman/listinfo/u-boot
>>> 
>>> ___
>>> U-Boot mailing list
>>> U-Boot@lists.denx.de
>>> http://lists.denx.de/mailman/listinfo/u-boot

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

[U-Boot] [PATCH v3] Add support for Bluewater Systems Snapper 9260 and 9G20 modules

[Ryan Mallon]

Add support for Bluewater Systems AT91 based Snapper 9260 and 9G20
single board computer modules. Includes NAND flash and Ethernet
support.

Signed-off-by: Ryan Mallon 
---
Patches apply against the rework101229 branch of 
git://git.denx.de/u-boot-atmel.git.

Builds and runs. Tested Ethernet and NAND booting.

Changes for v3:
 - Replaced SZ_ macros with shifts
 - Remove defined values from CONFIG_ defines
 - Moved boards.cfg entry to correct place
 - Added MAINTAINERS entry

Changes for v2:
 - Updated for recent at91 changes
 - Use CONFIG_AT91FAMILY in soft_i2c driver
 - Fixed missing snapper9260.h config file
 - Add config to boards.cfg not Makefile
 - Removed config.mk (now in snapper9260.h)

 MAINTAINERS   |5 +
 board/bluewater/snapper9260/Makefile  |   53 
 board/bluewater/snapper9260/snapper9260.c |  169 +
 boards.cfg|2 +
 include/configs/snapper9260.h |  191 +
 5 files changed, 420 insertions(+), 0 deletions(-)
 create mode 100644 board/bluewater/snapper9260/Makefile
 create mode 100644 board/bluewater/snapper9260/snapper9260.c
 create mode 100644 include/configs/snapper9260.h

diff --git a/MAINTAINERS b/MAINTAINERS
index a5f0493..f8c1996 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -298,6 +298,11 @@ Dan Malek 
stxssa  MPC85xx
stxxtc  MPC8xx
 
+Ryan Mallon 
+
+   snapper9260 ARM926EJS (AT91SAM9260 SoC)
+   snapper9g20 ARM926EJS (AT91SAM9G20 SoC)
+
 Eran Man 
 
EVB64260_750CX  MPC750CX
diff --git a/board/bluewater/snapper9260/Makefile 
b/board/bluewater/snapper9260/Makefile
new file mode 100644
index 000..4fccdaa
--- /dev/null
+++ b/board/bluewater/snapper9260/Makefile
@@ -0,0 +1,53 @@
+#
+# (C) Copyright 2003-2008
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# (C) Copyright 2011 Bluewater Systems
+# Ryan Mallon 
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS-y+= snapper9260.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS-y))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+   $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+clean:
+   rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+   rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/bluewater/snapper9260/snapper9260.c 
b/board/bluewater/snapper9260/snapper9260.c
new file mode 100644
index 000..6bb2ee0
--- /dev/null
+++ b/board/bluewater/snapper9260/snapper9260.c
@@ -0,0 +1,169 @@
+/*
+ * Bluewater Systems Snapper 9260/9G20 modules
+ *
+ * (C) Copyright 2011 Bluewater Systems
+ *   Author: Andre Renaud 
+ *   Author: Ryan Mallon 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* IO Expander pins */
+#define IO_EXP_ETH_RESET   (0 << 1)
+#define IO_EXP_ETH_POWER   (1 << 1)
+
+static void macb_hw_init(void)
+{
+   struct at91_pmc *pmc   = (struct at91_pmc  *)ATMEL_BASE_PMC;
+   struct at91_port *pioa = (struct at91_p

Re: [U-Boot] [PATCH] Fix to make U-Boot work with more USB sticks

[Simon Glass]

Hi Aaron,

OK good. Yes I notice ext2 is slow also, but the dcache is still off so I
assumed that was it.

I have had no hub problems, but have only tried two types. I do recall a LUN
patch floating around. I was going to try with an uSD card to see if it is
needed there.

Regards,
Simon

On Tue, Feb 1, 2011 at 4:03 PM, Aaron Williams <
aaron.willi...@caviumnetworks.com> wrote:

> I too am interested in this. I am running EHCI and have had problems with a
> number of USB storage devices, one of which (the SanDisk Cruzer) causes a
> crash due to it reporting the maximum LUN as 1.  I'm also seeing some
> interesting performance issues with ext2 being extremely slow compared to
> FAT.
>
> Additionally, I have been trying various USB hubs with EHCI and have found
> that a large percentage fail to work.  Hopefully I'll look into it more
> soon
> when I get ahold of our USB analyzer again.
>
> -Aaron
>
> On Tuesday, February 01, 2011 11:34:00 am Remy Bohmer wrote:
> > Hi,
> >
> > 2011/2/1 Simon Glass :
> > > Hi Remy,
> > > Still waiting on some boards to try, unfortunately. I expect it will
> > > happen in the next 2 weeks though (ARM9 and OMAP4 platforms). Once I
> get
> > > to the bottom of it I will split the patches as requested. I have not
> > > seen reports from other users of U-Boot. Also working on USB host
> > > Ethernet.
> > > Regards,
> > > Simon
> >
> > FWIW: I tested it on Atmel at91 and it does not seem to break OHCI, it
> > does not seem to fix some troubles USB sticks I have here either...
> >
> > Kind regards,
> >
> > Remy
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v3] sh: add support for sh7757lcr board

[Yoshihiro Shimoda]

The R0P7757LC0030RL board has SH7757, 256MB DDR3-SDRAM, SPI ROM,
Ethernet, and more.

This patch supports the following functions:
 - 256MB DDR3-SDRAM
 - SPI ROM
 - Ethernet

Signed-off-by: Yoshihiro Shimoda 
---
 about v3:
  - change my email address in Makefile and u-boot.lds

 MAINTAINERS |1 +
 arch/sh/include/asm/cpu_sh4.h   |2 +
 arch/sh/include/asm/cpu_sh7757.h|  218 
 board/renesas/sh7757lcr/Makefile|   43 +++
 board/renesas/sh7757lcr/lowlevel_init.S |  558 +++
 board/renesas/sh7757lcr/sh7757lcr.c |  454 +
 board/renesas/sh7757lcr/spi-boot.c  |  109 ++
 board/renesas/sh7757lcr/u-boot.lds  |  101 ++
 boards.cfg  |1 +
 doc/README.sh7757lcr|   64 
 include/configs/sh7757lcr.h |  146 
 11 files changed, 1697 insertions(+), 0 deletions(-)
 create mode 100644 arch/sh/include/asm/cpu_sh7757.h
 create mode 100644 board/renesas/sh7757lcr/Makefile
 create mode 100644 board/renesas/sh7757lcr/lowlevel_init.S
 create mode 100644 board/renesas/sh7757lcr/sh7757lcr.c
 create mode 100644 board/renesas/sh7757lcr/spi-boot.c
 create mode 100644 board/renesas/sh7757lcr/u-boot.lds
 create mode 100644 doc/README.sh7757lcr
 create mode 100644 include/configs/sh7757lcr.h

diff --git a/MAINTAINERS b/MAINTAINERS
index d7cd09c..7313542 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1020,6 +1020,7 @@ Mark Jonas 
 Yoshihiro Shimoda 

MS7720SESH7720
+   R0P77570030RL   SH7757
R0P77850011RL   SH7785

 #
diff --git a/arch/sh/include/asm/cpu_sh4.h b/arch/sh/include/asm/cpu_sh4.h
index fdcebd6..9b29d3a 100644
--- a/arch/sh/include/asm/cpu_sh4.h
+++ b/arch/sh/include/asm/cpu_sh4.h
@@ -44,6 +44,8 @@
 # include 
 #elif defined (CONFIG_CPU_SH7723)
 # include 
+#elif defined (CONFIG_CPU_SH7757)
+# include 
 #elif defined (CONFIG_CPU_SH7763)
 # include 
 #elif defined (CONFIG_CPU_SH7780)
diff --git a/arch/sh/include/asm/cpu_sh7757.h b/arch/sh/include/asm/cpu_sh7757.h
new file mode 100644
index 000..17a6537
--- /dev/null
+++ b/arch/sh/include/asm/cpu_sh7757.h
@@ -0,0 +1,218 @@
+/*
+ * Copyright (C) 2011  Renesas Solutions Corp.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ */
+
+#ifndef _ASM_CPU_SH7757_H_
+#define _ASM_CPU_SH7757_H_
+
+#define CCR0xFF1C
+#define WTCNT  0xFFCC
+#define CCR_CACHE_INIT 0x090b
+#define CACHE_OC_NUM_WAYS  1
+
+#ifndef __ASSEMBLY__   /* put C only stuff in this section */
+/* MMU */
+struct mmu_regs {
+   unsigned intreserved[4];
+   unsigned intmmucr;
+};
+#define MMU_BASE   ((struct mmu_regs *)0xff00)
+
+/* Watchdog */
+#define WTCSR0 0xffcc0002
+#define WRSTCSR_R  0xffcc0003
+#define WRSTCSR_W  0xffcc0002
+#define WTCSR_PREFIX   0xa500
+#define WRSTCSR_PREFIX 0x6900
+#define WRSTCSR_WOVF_PREFIX0x9600
+
+/* SCIF */
+#define SCIF0_BASE 0xfe4b  /* The real name is SCIF2 */
+#define SCIF1_BASE 0xfe4c  /* The real name is SCIF3 */
+#define SCIF2_BASE 0xfe4d  /* The real name is SCIF4 */
+
+/* SerMux */
+#define SMR0   0xfe47
+
+/* TMU0 */
+#define TSTR   0xFE430004
+#define TOCR   0xFE43
+#define TSTR0  0xFE430004
+#define TCOR0  0xFE430008
+#define TCNT0  0xFE43000C
+#define TCR0   0xFE430010
+#define TCOR1  0xFE430014
+#define TCNT1  0xFE430018
+#define TCR1   0xFE43001C
+#define TCOR2  0xFE430020
+#define TCNT2  0xFE430024
+#define TCR2   0xFE430028
+#define TCPR2  0xFE43002C
+
+/* ETHER, GETHER MAC address */
+struct ether_mac_regs {
+   unsigned intreserved[114];
+   unsigned intmahr;
+   unsigned intreserved2;
+   unsigned intmalr;
+};
+#define GETHER0_MAC_BASE   ((struct ether_mac_regs *)0xfee0400)
+#define GETHER1_MAC_BASE   ((struct ether_mac_regs *)0xfee0c00)
+#define ETHER0_MAC_BASE((struct ether_mac_regs *)0xfef)
+#define ETHER1_MAC_BASE((struct ether_mac_regs *)0xfef0800)
+
+/

[U-Boot] change email address in MAINTAINERS

[Yoshihiro Shimoda]

Signed-off-by: Yoshihiro Shimoda 
---
 This patch depends on "sh: add support for sh7757lcr board".

 MAINTAINERS |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7313542..c26c9a7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1017,7 +1017,7 @@ Mark Jonas 

mpr2SH7720

-Yoshihiro Shimoda 
+Yoshihiro Shimoda 

MS7720SESH7720
R0P77570030RL   SH7757
-- 
1.7.1

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

[U-Boot] Trouble running hello_world

[Alfred Morgan]

Hello clueful people, I am new to U-Boot.

I am having trouble executing anything using U-Boot.  I have read the U-Boot 
README and Manual.  I have also tried to following the steps on 
plugcomputer.org's wiki.  I was feeling like I was beginning to get a clue but 
then I couldn't get anything to work.  I figured a good place to start is 
trying to execute the u-boot hello_world standalone program but I couldn't even 
get that to work.

I am connected to the serial port via the GuruPlug JTAG board to my GuruPlug 
Server Plus and here is my output from the serial console:
U-Boot 2009.11-rc1-00602-g28a9c08-dirty (Feb 09 2010 - 18:15:21)
Marvell-Plug2L

SoC:   Kirkwood 88F6281_A0
DRAM:  512 MB
NAND:  512 MiB
In:serial
Out:   serial
Err:   serial
Net:   egiga0, egiga1
88E1121 Initialized on egiga0
88E1121 Initialized on egiga1
Hit any key to stop autoboot:  0 
Marvell>> loads 
## Ready for S-Record download ...

## First Load Addr = 0x0C10
## Last  Load Addr = 0x0C100249
## Total Size  = 0x024A = 586 Bytes
## Start Addr  = 0x0C10
Marvell>> go 0xC10
## Starting application at 0x0C10 ...

And that is it.  The plug sits there with no further output to the serial 
console.  I've also tried "tftp 0x640 hello_world.bin" and "go 0x644" 
(like the manual says to start 4 bytes from start in section 5.12.1) but still, 
same boring results.  I've also tried 0xC14 with the loads method just in 
case, but still nothing.

Am I loosing serial console output when I issue the go command?  Am I doing 
something wrong here?

-alfred

hello_world.srec:
S01368656C6C6F5F776F726C642E7372656376
S3150C1070402DE90050A0E10100A0E10160A0E1D3
S3150C10001060EB0610A0E37C009FE530EBBF
S3150C10002025EB0040A0E30010A0E16C009FE55A
S3150C1000302BEB68009FE529EB64009FE5A0
S3150C1000400510A0E126EB07EA042196E754
S3150C10005054309FE552E30410A0E14C009FE5DC
S3150C1000600320A0011EEB014084E2050054E1C0
S3150C100070F5DA38009FE519EB12EBD4
S3150C10008050E3FC0A0DEB24009FE577
S3150C10009013EBA0E37080BDE8C001100C4B
S3150C1000A0E001100CFE01100C0B02100C1602100CB9
S3150C1000B01D02100C2E02100C4702100C50C098E5A5
S3150C1000C000F09CE550C098E504F09CE550C098E50E
S3150C1000D008F09CE550C098E50CF09CE550C098E5EE
S3150C1000E010F09CE550C098E514F09CE550C098E5CE
S3150C1000F018F09CE550C098E51CF09CE550C098E5AE
S3150C10010020F09CE550C098E524F09CE550C098E58D
S3150C10011028F09CE550C098E52CF09CE550C098E56D
S3150C10012030F09CE550C098E534F09CE550C098E54D
S3150C10013038F09CE550C098E53CF09CE550C098E52D
S3150C10014040F09CE550C098E544F09CE550C098E50D
S3150C10015048F09CE550C098E54CF09CE550C098E5ED
S3150C10016050F09CE550C098E554F09CE550C098E5CD
S3150C10017058F09CE550C098E55CF09CE550C098E5AD
S3150C10018060F09CE550C098E564F09CE550C098E58D
S3150C10019068F09CE51EFF2FE118309FE501EA80
S3150C1001A00020A0E30120C3E40C209FE5020053E1DC
S3150C1001B0FA3A1EFF2FE14A82100C4C82100CEC
S3150C1001C04578616D706C6520657870656374732005
S3150C1001D04142492076657273696F6E2025640A0058
S3150C1001E041637475616C20552D426F6F74204142BA
S3150C1001F0492076657273696F6E2025640A0048650E
S3150C1002006C6C6F20576F726C640A00617267632096
S3150C1002103D2025640A003C4E554C4C3E00617267DD
S3150C100220765B25645D203D20222573220A004869E1
S3150C1002307420616E79206B657920746F20657869EE
S30F0C10024074202E2E2E2A0A0040
S7050C10DE

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

Re: [U-Boot] [Patch V6 0/4] Add basic NVIDIA Tegra2 SoC support

[Tom Warren]

I haven't seen any new feedback on this version (V6) of the patchset
since it was posted.

Wolfgang, Mike, Peter, et al - are you happy with the current patch?
If so, when can I expect it to be pushed?

Thanks,

Tom

On Thu, Jan 27, 2011 at 1:58 PM, Tom Warren  wrote:
> This series of patches adds preliminary/baseline support for NVIDIA's
> Tegra2 SoC.  Basic CPU (AVP), RAM and UART init are covered so that the
> system (Harmony or Seaboard) can boot to the U-Boot serial cmd prompt.
>
> Further support (for Cortex-A9 CPU(s), USB, SD/MMC, etc.) to follow.
>
> Changes for V2:
>        - Coding style cleanup
>        - Remove mach-types.h change; wait for ARM kernel sync-up
>        - Move serial driver changes to separate patch
>        - Use board/nvidia/ instead of /board/tegra
>        - Remove TRUE/FALSE defines
>        - Use standard NS16550 register/bit defines in UART init
>        - Change nv-common.h config file to tegra2-common.h
>
> Changes for V3:
>        - Use I/O accessors for Tegra2 HW MMIO register access
>        - Allow conditional compile of UARTA/UARTD code to save space
>
> Changes for V4:
>        - Use address of HW structs (&pmc, etc.) in readl/writel
>        - Remove empty lines, fix mixed case hex #s & comments in header(s)
>        - Move board/nvidia/common/board.c UART code & header to
>                arch/arm/cpu/armv7/tegra2/
>        - Declare internal functions as static in UART code
>
> Changes for V5:
>        - Move arch/arm/cpu/armv7/uart.c & board.h to drivers/serial and
>                rename to serial_tegra2.c
>        - Remove use of uart_num & UART_A/D in serial_tegra2, simplify code
>
> Changes for V6:
>        - Fix uart.c add & delete in previous patchset
>        - Move pinmux & clock init code to common board file as per review
>        - Use #if defined() where possible in config files/UART code
>        - Drop all typedef and volatile struct declarations in header files
>
> Tom Warren (4):
>  arm: Tegra2: Add basic NVIDIA Tegra2 SoC support
>  serial: Add Tegra2 serial port support
>  arm: Tegra2: Add support for NVIDIA Harmony board
>  arm: Tegra2: Add support for NVIDIA Seaboard board
>
>  MAINTAINERS                                  |    5 +
>  arch/arm/cpu/armv7/tegra2/Makefile           |   48 +++
>  arch/arm/cpu/armv7/tegra2/board.c            |   88 
>  arch/arm/cpu/armv7/tegra2/config.mk          |   28 
>  arch/arm/cpu/armv7/tegra2/lowlevel_init.S    |   65 +
>  arch/arm/cpu/armv7/tegra2/sys_info.c         |   35 +
>  arch/arm/cpu/armv7/tegra2/timer.c            |  122 
>  arch/arm/include/asm/arch-tegra2/clk_rst.h   |  165 ++
>  arch/arm/include/asm/arch-tegra2/pinmux.h    |   55 
>  arch/arm/include/asm/arch-tegra2/pmc.h       |  124 +
>  arch/arm/include/asm/arch-tegra2/sys_proto.h |   35 +
>  arch/arm/include/asm/arch-tegra2/tegra2.h    |   49 +++
>  arch/arm/include/asm/arch-tegra2/uart.h      |   47 ++
>  board/nvidia/common/board.c                  |  193 
> ++
>  board/nvidia/harmony/Makefile                |   50 +++
>  board/nvidia/seaboard/Makefile               |   50 +++
>  boards.cfg                                   |    2 +
>  common/serial.c                              |    3 +-
>  drivers/serial/Makefile                      |    1 +
>  drivers/serial/serial_tegra2.c               |   77 ++
>  drivers/serial/serial_tegra2.h               |   29 
>  include/configs/harmony.h                    |   49 +++
>  include/configs/seaboard.h                   |   43 ++
>  include/configs/tegra2-common.h              |  160 +
>  include/serial.h                             |    3 +-
>  25 files changed, 1524 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm/cpu/armv7/tegra2/Makefile
>  create mode 100644 arch/arm/cpu/armv7/tegra2/board.c
>  create mode 100644 arch/arm/cpu/armv7/tegra2/config.mk
>  create mode 100644 arch/arm/cpu/armv7/tegra2/lowlevel_init.S
>  create mode 100644 arch/arm/cpu/armv7/tegra2/sys_info.c
>  create mode 100644 arch/arm/cpu/armv7/tegra2/timer.c
>  create mode 100644 arch/arm/include/asm/arch-tegra2/clk_rst.h
>  create mode 100644 arch/arm/include/asm/arch-tegra2/pinmux.h
>  create mode 100644 arch/arm/include/asm/arch-tegra2/pmc.h
>  create mode 100644 arch/arm/include/asm/arch-tegra2/sys_proto.h
>  create mode 100644 arch/arm/include/asm/arch-tegra2/tegra2.h
>  create mode 100644 arch/arm/include/asm/arch-tegra2/uart.h
>  create mode 100644 board/nvidia/common/board.c
>  create mode 100644 board/nvidia/harmony/Makefile
>  create mode 100644 board/nvidia/seaboard/Makefile
>  create mode 100644 drivers/serial/serial_tegra2.c
>  create mode 100644 drivers/serial/serial_tegra2.h
>  create mode 100644 include/configs/harmony.h
>  create mode 100644 include/configs/seaboard.h
>  create mode 100644 include/configs/tegra2-common.h
>
> 

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

[Albert ARIBAUD]

Hi Wolfgang,

Please pull from u-boot-arm/master to go into rc1 of upcoming release.

The following changes since commit 6f918bd46482f889f4d94623b09daf659a1974bd:

   Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx (2011-01-31 
23:20:32 +0100)

are available in the git repository at:

   git://www.denx.de/git/u-boot-arm.git master

Alexander Holler (1):
   ARM: Avoid compiler optimization for readb, writeb and friends.

Anatolij Gustschin (2):
   SPI: mxc_spi: fix swapping bug and add missing swapping in 
unaligned rx case
   SPI: mxc_spi: add SPI clock calculation and setup to the driver

Heiko Schocher (2):
   arm1136: timer: Replace bss variable by gd
   arm926ejs: timer: Replace bss variable by gdr

Jens Scharsig (1):
   remove (double) LED initialization in arm920t start.s

Liu Hui-R64343 (10):
   MX51EVK: UART does not print out the early information
   MX5: Add initial support for MX53 processor
   fec_mxc: add support for MX53 processor
   serial_mxc: add support for MX53 processor
   mxc_gpio: add support for MX53 processor
   mxc_i2c: add support for MX53 processor
   fsl_pmic: add I2C interface support
   MX5:MX53: add initial support for MX53EVK board
   imximage: Add MX53 boot image support
   ARM: */start.S: code cleanup

Marek Vasut (4):
   BLOCK: Add freescale IMX51 PATA driver
   MC13892: Add SWx buck switchers definitions
   MX51EVK: Use SWx macros in PMIC init
   iMX5: EfikaMX: Preliminary board support

Mike Rapoport (1):
   OMAP3: add CM-T35 board

Minkyu Kang (4):
   armv7: s5pc1xx: don't use function pointer for clock functions
   S5P: serial: Use the inline function instead of static value
   armv7: add support for S5PC210 SoC
   armv7: add support for s5pc210 universal board

Po-Yu Chuang (1):
   arm: a320evb: fixes for relocation support

Sandeep Paulraj (12):
   Davinci MMCSD Support
   DaVinci DM355: Adding MMC/SD support for DM355 EVM
   DaVinci DM365: Adding MMC/SD support for DM365 EVM
   DM365: Fix Build Error
   DaVinci EMAC: Fix davinci_eth_gigabit_enable
   DaVinci EMAC: Add name to Ethernet device
   DaVinci DM6467: Added ET1011C (LSI) PHY support
   ARM: Update mach types
   DaVinci DM6467: Enhance board Support
   DaVinci DM6467: Fix Build Error
   DaVinci Sonata: Fix Build Error
   DaVinci: Remove incorrect CONFIG option

Stefano Babic (13):
   mxc_nand: add support for i.MX35 processor
   Add support for MX35 processor
   serial_mxc: add support for Freescale's i.MX35 processor
   mxc_i2c: Add support for the i.MX35 processor
   I2C: mxc_i2c: get rid of __REG access
   I2C: mxc_i2c: address failure with mx35 processor
   Add basic support for Freescale's mc9sdz60
   SPI: mxc_spi: add support for i.MX35 processor
   SPI: mxc_spi: replace fixed offsets with structures
   Add support for Freescale's mx35pdk board.
   MX5: Reuse the gd->tbl value for timestamp and add gd->lastinc 
for lastinc bss
   MXC: removed warnings from IMX51 ATA driver
   ARM: fix broken build of ARM

  MAINTAINERS|   17 +-
  arch/arm/config.mk |2 +-
  arch/arm/cpu/arm1136/mx31/timer.c  |   19 +-
  arch/arm/cpu/arm1136/mx35/Makefile |   63 +
  arch/arm/cpu/arm1136/mx35/asm-offsets.c|   43 +
  arch/arm/cpu/arm1136/mx35/generic.c|  463 
  arch/arm/cpu/arm1136/mx35/iomux.c  |  116 +
  arch/arm/cpu/arm1136/mx35/timer.c  |  120 +
  arch/arm/cpu/arm1136/omap24xx/timer.c  |   19 +-
  arch/arm/cpu/arm1136/start.S   |2 -
  arch/arm/cpu/arm1176/start.S   |2 -
  arch/arm/cpu/arm720t/start.S   |2 -
  arch/arm/cpu/arm920t/start.S   |5 -
  arch/arm/cpu/arm925t/start.S   |2 -
  arch/arm/cpu/arm926ejs/davinci/Makefile|2 +-
  arch/arm/cpu/arm926ejs/davinci/cpu.c   |   14 +-
  arch/arm/cpu/arm926ejs/davinci/et1011c.c   |   55 +
  arch/arm/cpu/arm926ejs/kirkwood/timer.c|6 +-
  arch/arm/cpu/arm926ejs/mb86r0x/timer.c |6 +-
  arch/arm/cpu/arm926ejs/mx25/timer.c|6 +-
  arch/arm/cpu/arm926ejs/mx27/timer.c|6 +-
  arch/arm/cpu/arm926ejs/omap/timer.c|6 +-
  arch/arm/cpu/arm926ejs/orion5x/timer.c |6 +-
  arch/arm/cpu/arm926ejs/spear/timer.c   |6 +-
  arch/arm/cpu/arm926ejs/start.S |2 -
  arch/arm/cpu/arm926ejs/versatile/timer.c   |6 +-
  arch/arm/cpu/arm946es/start.S  |2 -
  arch/arm/cpu/arm_intcm/start.S |2 -
  arch/arm/cpu/armv7/mx5/iomux.c |   30 +-
  arc

Re: [U-Boot] [PATCH] Fix to make U-Boot work with more USB sticks

[Aaron Williams]

I too am interested in this. I am running EHCI and have had problems with a 
number of USB storage devices, one of which (the SanDisk Cruzer) causes a 
crash due to it reporting the maximum LUN as 1.  I'm also seeing some 
interesting performance issues with ext2 being extremely slow compared to FAT.

Additionally, I have been trying various USB hubs with EHCI and have found 
that a large percentage fail to work.  Hopefully I'll look into it more soon 
when I get ahold of our USB analyzer again.

-Aaron

On Tuesday, February 01, 2011 11:34:00 am Remy Bohmer wrote:
> Hi,
> 
> 2011/2/1 Simon Glass :
> > Hi Remy,
> > Still waiting on some boards to try, unfortunately. I expect it will
> > happen in the next 2 weeks though (ARM9 and OMAP4 platforms). Once I get
> > to the bottom of it I will split the patches as requested. I have not
> > seen reports from other users of U-Boot. Also working on USB host
> > Ethernet.
> > Regards,
> > Simon
> 
> FWIW: I tested it on Atmel at91 and it does not seem to break OHCI, it
> does not seem to fix some troubles USB sticks I have here either...
> 
> Kind regards,
> 
> Remy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [GIT PULL] Pull request: u-boot-imx

[Albert ARIBAUD]

Hi Stefano,

Le 01/02/2011 19:13, Stefano Babic a écrit :
> Hi Albert,
>
> here my pull request for u-boot-imx. Since my last pull-request, I
> rebased my tree to substitute:
>
>   imximage: Add MX53 boot image support
>
> I fixed the wrong mode,too, and I cherry-picked from u-boot-arm:
>
>ARM: fix broken build of ARM
>
> that you have already merged, to avoid leaving u-boot-imx broken. I hope
> this is not a problem for you.

Pulled into u-boot-arm/master, thanks -- had to force update, though.

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

Re: [U-Boot] PCIE supported networking cards?

[Aaron Williams]

This is an Intel EXPI9301 PRO/1000 OEM card, vendor ID 0x8086, device ID 
0x10d3. I added it to the list but I don't know what the MAC type is.  I'll 
look into the Linux driver and see if I can see what it is.

-Aaron

On Tuesday, February 01, 2011 11:19:24 am Scott Wood wrote:
> On Tue, 1 Feb 2011 13:15:01 -0600
> 
> Kumar Gala  wrote:
> > We utilize e1000 PCIe cards all the time
> 
> Aren't there some versions that work, and some that don't?
> 
> -Scott
> 
> > - k
> > 
> > On Feb 1, 2011, at 1:10 PM, Aaron Williams wrote:
> > > Are there any PCIE networking cards that are supported? So far I've
> > > tried an Intel card and a Realtek RTL8168 card, but neither is
> > > supported. It looks like the E1000 driver only supports PCI and PCIX
> > > based cards (Linux uses the e1000e card for PCIe cards).
> > > 
> > > -Aaron
> > > ___
> > > U-Boot mailing list
> > > U-Boot@lists.denx.de
> > > http://lists.denx.de/mailman/listinfo/u-boot
> > 
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL

[Scott Wood]

On Tue, 1 Feb 2011 21:20:50 +0100
Wolfgang Denk  wrote:

> Dear Scott Wood,
> 
> In message <20110201135136.0817f...@udp111988uds.am.freescale.net> you wrote:
> >
> > > > Prior to the introduction of LDFLAGS_u-boot, was LDFLAGS not what was
> > > > used?  So before, anything that board/cpu code adds directly to LDFLAGS
> > > > (maybe they're supposed to use PLATFORM_LDFLAGS, but not all do) was
> > > > used in the final link.  After 8aba9dc, only things in
> > > > PLATFORM_LDFLAGS plus -Bstatic and -T are used in the final link.
> > > 
> > > And this is correct for all boards?
> > 
> > By "this" do you mean the switch to PLATFORM_LDFLAGS in 8aba9dc, or the
> > switch back to LDFLAGS?  It's not obvious to me that the dropping of
> 
> I don;t understand why you contine to talk about "switch to
> PLATFORM_LDFLAGS in 8aba9dc".  There was no such switch - at least I
> cannot see it.
> 
> I see only a switch in your patch.  This is why I'm asking.

Before 8aba9dc, the flags for the final link were produced by taking
the existing LDFLAGS, and adding:
-Bstatic -T  $(PLATFORM_LDFLAGS) -Ttext .

This included anything that cpu/board code added to LDFLAGS -- some
architectures added --gc-sections, x86 added --cref, etc.  Since the above
flags are added to LDFLAGS, rather than replacing them, these flags got used
in the final link.

Commit 8aba9dc introduces LDFLAGS_u-boot, so that LDFLAGS is no longer the
source for the flags for the final link.  It generates LDFLAGS_u-boot using
PLATFORM_LDFLAGS, not LDFLAGS.  It converts most of the board/cpu updates to
LDFLAGS into LDFLAGS_u-boot, but it missed --cref.

I don't see any other LDFLAGS changes in board/cpu code, so the distinction
between using LDFLAGS and PLATFORM_LDFLAGS should have no other impact on
current boards.  However, the patch appears to be intended to support
platform linker flags that need to be used during partial link, which
would involve board/cpu additions to LDFLAGS.  This change would break that
only if those options need to be used for partial link *only*, and cannot be
used in the final link.  In such a case I'd suggest using something like
LDFLAGS_PARTIAL to make this explicit.  But I'd be surprised if that
were actually the case.

If you're looking to cut down on the number of variables, it's not clear to
me what PLATFORM_LDFLAGS is supposed to mean distinct from adding to
LDFLAGS.

-Scott

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

Re: [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL

[Wolfgang Denk]

Dear Scott Wood,

In message <20110201135136.0817f...@udp111988uds.am.freescale.net> you wrote:
>
> > > Prior to the introduction of LDFLAGS_u-boot, was LDFLAGS not what was
> > > used?  So before, anything that board/cpu code adds directly to LDFLAGS
> > > (maybe they're supposed to use PLATFORM_LDFLAGS, but not all do) was
> > > used in the final link.  After 8aba9dc, only things in
> > > PLATFORM_LDFLAGS plus -Bstatic and -T are used in the final link.
> > 
> > And this is correct for all boards?
> 
> By "this" do you mean the switch to PLATFORM_LDFLAGS in 8aba9dc, or the
> switch back to LDFLAGS?  It's not obvious to me that the dropping of

I don;t understand why you contine to talk about "switch to
PLATFORM_LDFLAGS in 8aba9dc".  There was no such switch - at least I
cannot see it.

I see only a switch in your patch.  This is why I'm asking.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
HANDLE WITH EXTREME CARE:  This Product Contains  Minute Electrically
Charged  Particles  Moving  at  Velocities  in Excess of Five Hundred
Million Miles Per Hour.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] at91sam9261ek: make operational again

[Reinhard Meyer]

Dear all,
>> /home/toolchain/bin/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld
>>   -pie -r -o libat91.o  lowlevel_init.o clock.o cpu.o reset.o timer.o
>> /home/toolchain/bin/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld:
>>  -r and -shared may not be used together
>>
>> I have tried this patch but this a problem releated to linking option. Do 
>> you have this problem?
>>
>> Michael
>
> Read up recent posts on the list: this was detected and is fixed in the
> master branch of the u-boot-arm repository.
I'll rebase u-boot-atmel on u-boot-arm/master then. Please rebase at91 related 
patches on
u-boot-atmel/rework then (my time permitting, that branch will exist somewhere 
tomorrow)

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

Re: [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL

[Scott Wood]

On Tue, 1 Feb 2011 20:32:29 +0100
Wolfgang Denk  wrote:

> Dear Scott Wood,
> 
> In message <20110201102446.23b4a...@udp111988uds.am.freescale.net> you wrote:
> >
> > Prior to the introduction of LDFLAGS_u-boot, was LDFLAGS not what was
> > used?  So before, anything that board/cpu code adds directly to LDFLAGS
> > (maybe they're supposed to use PLATFORM_LDFLAGS, but not all do) was
> > used in the final link.  After 8aba9dc, only things in
> > PLATFORM_LDFLAGS plus -Bstatic and -T are used in the final link.
> 
> And this is correct for all boards?

By "this" do you mean the switch to PLATFORM_LDFLAGS in 8aba9dc, or the
switch back to LDFLAGS?  It's not obvious to me that the dropping of
board/cpu modifications to LDFLAGS except during partial link was an
intentional change, or a correct one for all boards.

The only case I see where it makes any difference at all is arch/i386,
which does LDFLAGS += --cref.  From the description of --cref in the
linker manual, it probably actually belongs in LDFLAGS_FINAL, though
I'm not sure if it's harmless to include it in partial link or not.
Currently, with 8aba9dc, it's included *only* in partial link.

It's also not clear to me what this option has to do with i386... it
looks like an arch-neutral debugging feature that doesn't affect the
actual u-boot image at all (the output goes into the map file).

-Scott

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

Re: [U-Boot] [PATCH 6/6] p1021mds: add QE and UEC support

[Haiying Wang]

On Tue, 2011-02-01 at 13:15 -0600, Kumar Gala wrote:
> On Feb 1, 2011, at 11:01 AM, Haiying Wang wrote:
> 
> > On Tue, 2011-02-01 at 10:50 -0600, Scott Wood wrote:
>  
> >>> If it is a one time setting, there should be no problem to put it into
> >>> board code. But these pin settings need to be done before any usage of
> >>> phy read/write (accessing MDIO/MDC), and need to be released after the
> >>> usage of phy, thus the devices connected to eLBC like NAND flash/BCSR
> >>> can be accessed. If we use board code to set/release the pin, we don't
> >>> know when the phy access and nand flash access will happen.
> >> 
> >> Is this actually a board issue or an SoC issue?
> >> 
> > It is not a board issue. It is a SoC *feature*. Too many pins are muxed
> > on P1021. For this case, LBCTL of eLBC is muxed with QE's CE_PB[20]
> > which is used for MDIO signal. 
> > 
> > Haiying
> > 
> 
> But its a board decision on how they want to utilize those pins and for what 
> feature.

Yes, you can say that. If the board doesn't have QE UCC ETH support at
all, we won't have to add such code in QE driver. But if there is QE UCC
ETH on board, we have no choice to decide which pins to use. We
definitely need to use CE_PB[20] for MDIO signal, there is no other GPIO
pins to use for QE's MDIO.  

Haiying



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

Re: [U-Boot] [PATCH] Fix to make U-Boot work with more USB sticks

[Remy Bohmer]

Hi,

2011/2/1 Simon Glass :
> Hi Remy,
> Still waiting on some boards to try, unfortunately. I expect it will happen
> in the next 2 weeks though (ARM9 and OMAP4 platforms). Once I get to the
> bottom of it I will split the patches as requested. I have not seen reports
> from other users of U-Boot. Also working on USB host Ethernet.
> Regards,
> Simon

FWIW: I tested it on Atmel at91 and it does not seem to break OHCI, it
does not seem to fix some troubles USB sticks I have here either...

Kind regards,

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

Re: [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL

[Wolfgang Denk]

Dear Scott Wood,

In message <20110201102446.23b4a...@udp111988uds.am.freescale.net> you wrote:
>
> Prior to the introduction of LDFLAGS_u-boot, was LDFLAGS not what was
> used?  So before, anything that board/cpu code adds directly to LDFLAGS
> (maybe they're supposed to use PLATFORM_LDFLAGS, but not all do) was
> used in the final link.  After 8aba9dc, only things in
> PLATFORM_LDFLAGS plus -Bstatic and -T are used in the final link.

And this is correct for all boards?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
I don't mind criticism. You know me. I've  never  been  one  to  take
offence  at  criticism. No one could say I'm the sort to take offence
at criticism -- Not twice, anyway. Not without blowing bubbles.
  - Terry Pratchett, _Witches Abroad_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] at91sam9261ek: make operational again

[Remy Bohmer]

Hi,

2011/2/1 Michael Trimarchi :
> Hi
>
> On 02/01/2011 01:16 PM, Albert ARIBAUD wrote:
>> Le 01/02/2011 11:45, Michael Trimarchi a écrit :
>>
>>> Hi
>>>
>>> /home/toolchain/bin/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld
>>>   -pie -r -o libat91.o  lowlevel_init.o clock.o cpu.o reset.o timer.o
>>> /home/toolchain/bin/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld:
>>>  -r and -shared may not be used together
>>>
>>> I have tried this patch but this a problem releated to linking option. Do 
>>> you have this problem?
>>>
>>> Michael
>>
>> Read up recent posts on the list: this was detected and is fixed in the
>> master branch of the u-boot-arm repository.

I mentioned this as well directly after posting this patch for the first time.
But anyway, if you look at 'cdc-at91' branch of u-boot-usb you can see
all the other patches that are required to make it compile properly.
Including the timer fix for the at91 family.

>>
>> Amicalement,
> I see, but I see but I have other little problem. I have fixed the 
> compilation, but I have a segmentation fault.
>
> Starting program: 
> /opt/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld
>  -pie -Bstatic -T u-boot.lds -Ttext 0x23e0 arch/arm/cpu/arm926ejs/start.o 
> --start-group api/libapi.o arch/arm/cpu/arm926ejs/at91/libat91.o 
> arch/arm/cpu/arm926ejs/libarm926ejs.o arch/arm/lib/libarm.o 
> common/libcommon.o disk/libdisk.o drivers/bios_emulator/libatibiosemu.o 
> drivers/block/libblock.o drivers/dma/libdma.o drivers/fpga/libfpga.o 
> drivers/gpio/libgpio.o drivers/hwmon/libhwmon.o drivers/i2c/libi2c.o 
> drivers/input/libinput.o drivers/misc/libmisc.o drivers/mmc/libmmc.o 
> drivers/mtd/libmtd.o drivers/mtd/nand/libnand.o 
> drivers/mtd/onenand/libonenand.o drivers/mtd/spi/libspi_flash.o 
> drivers/mtd/ubi/libubi.o drivers/net/libnet.o drivers/net/phy/libphy.o 
> drivers/pci/libpci.o drivers/pcmcia/libpcmcia.o drivers/power/libpower.o 
> drivers/rtc/librtc.o drivers/serial/libserial.o drivers/spi/libspi.o 
> drivers/twserial/libtws.o drivers/usb/gadget/libusb_gadget.o
> drivers/usb/host/libusb_host.o drivers/usb/musb/libusb_musb.o 
> drivers/usb/phy/libusb_phy.o drivers/video/libvideo.o 
> drivers/watchdog/libwatchdog.o fs/cramfs/libcramfs.o fs/ext2/libext2fs.o 
> fs/fat/libfat.o fs/fdos/libfdos.o fs/jffs2/libjffs2.o 
> fs/reiserfs/libreiserfs.o fs/ubifs/libubifs.o fs/yaffs2/libyaffs2.o 
> lib/libfdt/libfdt.o lib/libgeneric.o lib/lzma/liblzma.o lib/lzo/liblzo.o 
> net/libnet.o post/libpost.o board/atmel/at91sam9261ek/libat91sam9261ek.o 
> --end-group /home/michael/u-boot/arch/arm/lib/eabi_compat.o -L 
> /opt/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/../lib/gcc/arm-none-linux-gnueabi/4.1.2
>  -lgcc -Map u-boot.map -o u-boot
> /opt/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld:
>  u-boot: warning: allocated section `.bss' not in segment
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x08081ebd in elf32_arm_finish_dynamic_sections ()
> (gdb) bt
> #0  0x08081ebd in elf32_arm_finish_dynamic_sections ()
> #1  0x0809cc2b in bfd_elf_final_link ()
> #2  0x0807b525 in elf32_arm_bfd_final_link ()
> #3  0x0805bfce in ldwrite ()
> #4  0x0805a0be in main ()
>
> Michael

I see you use a rather old compiler.
I tested with a GCC 4.3.4 (CodeSourcery 2009q1) compiler which works
okay. I also noticed that the current make structure of U-boot is more
picky on linker usage, and even unresolved externals result in
crashing linkers. This has nothing to do with this patch though.

Kind regards,

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

Re: [U-Boot] spi subystem maintainer?

[Wolfgang Denk]

Dear Kumar Gala,

In message <9a3702c1-3ed1-4f24-a0bc-ca7daea46...@kernel.crashing.org> you wrote:
> Do we have one?

Not yet.  Are you volunteering?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Any sufficiently advanced technology is indistinguishable from magic.
   - Arthur C. Clarke
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] PCIE supported networking cards?

[Scott Wood]

On Tue, 1 Feb 2011 13:15:01 -0600
Kumar Gala  wrote:

> We utilize e1000 PCIe cards all the time

Aren't there some versions that work, and some that don't?

-Scott


> 
> - k
> 
> On Feb 1, 2011, at 1:10 PM, Aaron Williams wrote:
> 
> > Are there any PCIE networking cards that are supported? So far I've
> > tried an Intel card and a Realtek RTL8168 card, but neither is
> > supported. It looks like the E1000 driver only supports PCI and PCIX
> > based cards (Linux uses the e1000e card for PCIe cards).
> > 
> > -Aaron
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 


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

Re: [U-Boot] [PATCH 6/6] p1021mds: add QE and UEC support

[Kumar Gala]

On Feb 1, 2011, at 11:01 AM, Haiying Wang wrote:

> On Tue, 2011-02-01 at 10:50 -0600, Scott Wood wrote:
 
>>> If it is a one time setting, there should be no problem to put it into
>>> board code. But these pin settings need to be done before any usage of
>>> phy read/write (accessing MDIO/MDC), and need to be released after the
>>> usage of phy, thus the devices connected to eLBC like NAND flash/BCSR
>>> can be accessed. If we use board code to set/release the pin, we don't
>>> know when the phy access and nand flash access will happen.
>> 
>> Is this actually a board issue or an SoC issue?
>> 
> It is not a board issue. It is a SoC *feature*. Too many pins are muxed
> on P1021. For this case, LBCTL of eLBC is muxed with QE's CE_PB[20]
> which is used for MDIO signal. 
> 
> Haiying
> 

But its a board decision on how they want to utilize those pins and for what 
feature.

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

Re: [U-Boot] PCIE supported networking cards?

[Kumar Gala]

We utilize e1000 PCIe cards all the time

- k

On Feb 1, 2011, at 1:10 PM, Aaron Williams wrote:

> Are there any PCIE networking cards that are supported? So far I've
> tried an Intel card and a Realtek RTL8168 card, but neither is
> supported. It looks like the E1000 driver only supports PCI and PCIX
> based cards (Linux uses the e1000e card for PCIe cards).
> 
> -Aaron
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

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

Re: [U-Boot] [PATCH 2/2] at91sam9261ek: make operational again

[Michael Trimarchi]

Hi

On 02/01/2011 01:16 PM, Albert ARIBAUD wrote:
> Le 01/02/2011 11:45, Michael Trimarchi a écrit :
>
>> Hi
>>
>> /home/toolchain/bin/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld
>>   -pie -r -o libat91.o  lowlevel_init.o clock.o cpu.o reset.o timer.o
>> /home/toolchain/bin/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld:
>>  -r and -shared may not be used together
>>
>> I have tried this patch but this a problem releated to linking option. Do 
>> you have this problem?
>>
>> Michael
>
> Read up recent posts on the list: this was detected and is fixed in the 
> master branch of the u-boot-arm repository.
>
> Amicalement,
I see, but I see but I have other little problem. I have fixed the compilation, 
but I have a segmentation fault.

Starting program: 
/opt/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld
 -pie -Bstatic -T u-boot.lds -Ttext 0x23e0 arch/arm/cpu/arm926ejs/start.o 
--start-group api/libapi.o arch/arm/cpu/arm926ejs/at91/libat91.o 
arch/arm/cpu/arm926ejs/libarm926ejs.o arch/arm/lib/libarm.o common/libcommon.o 
disk/libdisk.o drivers/bios_emulator/libatibiosemu.o drivers/block/libblock.o 
drivers/dma/libdma.o drivers/fpga/libfpga.o drivers/gpio/libgpio.o 
drivers/hwmon/libhwmon.o drivers/i2c/libi2c.o drivers/input/libinput.o 
drivers/misc/libmisc.o drivers/mmc/libmmc.o drivers/mtd/libmtd.o 
drivers/mtd/nand/libnand.o drivers/mtd/onenand/libonenand.o 
drivers/mtd/spi/libspi_flash.o drivers/mtd/ubi/libubi.o drivers/net/libnet.o 
drivers/net/phy/libphy.o drivers/pci/libpci.o drivers/pcmcia/libpcmcia.o 
drivers/power/libpower.o drivers/rtc/librtc.o drivers/serial/libserial.o 
drivers/spi/libspi.o drivers/twserial/libtws.o 
drivers/usb/gadget/libusb_gadget.o
drivers/usb/host/libusb_host.o drivers/usb/musb/libusb_musb.o 
drivers/usb/phy/libusb_phy.o drivers/video/libvideo.o 
drivers/watchdog/libwatchdog.o fs/cramfs/libcramfs.o fs/ext2/libext2fs.o 
fs/fat/libfat.o fs/fdos/libfdos.o fs/jffs2/libjffs2.o fs/reiserfs/libreiserfs.o 
fs/ubifs/libubifs.o fs/yaffs2/libyaffs2.o lib/libfdt/libfdt.o lib/libgeneric.o 
lib/lzma/liblzma.o lib/lzo/liblzo.o net/libnet.o post/libpost.o 
board/atmel/at91sam9261ek/libat91sam9261ek.o --end-group 
/home/michael/u-boot/arch/arm/lib/eabi_compat.o -L 
/opt/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/../lib/gcc/arm-none-linux-gnueabi/4.1.2
 -lgcc -Map u-boot.map -o u-boot
/opt/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld:
 u-boot: warning: allocated section `.bss' not in segment

Program received signal SIGSEGV, Segmentation fault.
0x08081ebd in elf32_arm_finish_dynamic_sections ()
(gdb) bt
#0  0x08081ebd in elf32_arm_finish_dynamic_sections ()
#1  0x0809cc2b in bfd_elf_final_link ()
#2  0x0807b525 in elf32_arm_bfd_final_link ()
#3  0x0805bfce in ldwrite ()
#4  0x0805a0be in main ()

Michael

diff --git a/arch/arm/cpu/arm926ejs/at91/timer.c b/arch/arm/cpu/arm926ejs/at91/timer.c
index 82b8d7e..b140893 100644
--- a/arch/arm/cpu/arm926ejs/at91/timer.c
+++ b/arch/arm/cpu/arm926ejs/at91/timer.c
@@ -122,11 +122,21 @@ void __udelay(unsigned long usec)
  *
  * The time is used in CONFIG_SYS_HZ units!
  */
-void reset_timer(void)
+void reset_timer_masked(void)
 {
 	gd->timer_reset_value = get_ticks();
 }
 
+void reset_timer(void)
+{
+	reset_timer_masked();
+}
+
+ulong get_timer_masked(void)
+{
+return tick_to_time(get_ticks() - gd->timer_reset_value);
+}
+
 ulong get_timer(ulong base)
 {
 	return tick_to_time(get_ticks() - gd->timer_reset_value) - base;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] PCIE supported networking cards?

[Aaron Williams]

Are there any PCIE networking cards that are supported? So far I've
tried an Intel card and a Realtek RTL8168 card, but neither is
supported. It looks like the E1000 driver only supports PCI and PCIX
based cards (Linux uses the e1000e card for PCIe cards).

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

[U-Boot] [GIT PULL] Pull request: u-boot-imx

[Stefano Babic]

Hi Albert,

here my pull request for u-boot-imx. Since my last pull-request, I
rebased my tree to substitute:

imximage: Add MX53 boot image support

I fixed the wrong mode,too, and I cherry-picked from u-boot-arm:

  ARM: fix broken build of ARM

that you have already merged, to avoid leaving u-boot-imx broken. I hope
this is not a problem for you.


The following changes since commit 6f918bd46482f889f4d94623b09daf659a1974bd:

  Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx (2011-01-31
23:20:32 +0100)

are available in the git repository at:

  git://www.denx.de/git/u-boot-imx.git master

Anatolij Gustschin (2):
  SPI: mxc_spi: fix swapping bug and add missing swapping in
unaligned rx case
  SPI: mxc_spi: add SPI clock calculation and setup to the driver

Liu Hui-R64343 (9):
  MX51EVK: UART does not print out the early information
  MX5: Add initial support for MX53 processor
  fec_mxc: add support for MX53 processor
  serial_mxc: add support for MX53 processor
  mxc_gpio: add support for MX53 processor
  mxc_i2c: add support for MX53 processor
  fsl_pmic: add I2C interface support
  MX5:MX53: add initial support for MX53EVK board
  imximage: Add MX53 boot image support

Marek Vasut (4):
  BLOCK: Add freescale IMX51 PATA driver
  MC13892: Add SWx buck switchers definitions
  MX51EVK: Use SWx macros in PMIC init
  iMX5: EfikaMX: Preliminary board support

Stefano Babic (13):
  mxc_nand: add support for i.MX35 processor
  Add support for MX35 processor
  serial_mxc: add support for Freescale's i.MX35 processor
  mxc_i2c: Add support for the i.MX35 processor
  I2C: mxc_i2c: get rid of __REG access
  I2C: mxc_i2c: address failure with mx35 processor
  Add basic support for Freescale's mc9sdz60
  SPI: mxc_spi: add support for i.MX35 processor
  SPI: mxc_spi: replace fixed offsets with structures
  Add support for Freescale's mx35pdk board.
  MX5: Reuse the gd->tbl value for timestamp and add gd->lastinc for
lastinc bss
  MXC: removed warnings from IMX51 ATA driver
  ARM: fix broken build of ARM

 MAINTAINERS |8 +-
 arch/arm/config.mk  |2 +-
 arch/arm/cpu/arm1136/mx35/Makefile  |   63 +++
 arch/arm/cpu/arm1136/mx35/asm-offsets.c |   43 ++
 arch/arm/cpu/arm1136/mx35/generic.c |  463 ++
 arch/arm/cpu/arm1136/mx35/iomux.c   |  116 +
 arch/arm/cpu/arm1136/mx35/timer.c   |  120 +
 arch/arm/cpu/armv7/mx5/iomux.c  |   30 +-
 arch/arm/cpu/armv7/mx5/lowlevel_init.S  |   91 +++--
 arch/arm/cpu/armv7/mx5/soc.c|   22 +-
 arch/arm/cpu/armv7/mx5/timer.c  |6 +-
 arch/arm/include/asm/arch-mx31/mx31-regs.h  |   11 +
 arch/arm/include/asm/arch-mx35/clock.h  |   45 ++
 arch/arm/include/asm/arch-mx35/crm_regs.h   |  270 +++
 arch/arm/include/asm/arch-mx35/imx-regs.h   |  303 
 arch/arm/include/asm/arch-mx35/iomux.h  |  295 
 arch/arm/include/asm/arch-mx35/mx35_pins.h  |  355 ++
 arch/arm/include/asm/arch-mx35/sys_proto.h  |   31 ++
 arch/arm/include/asm/arch-mx5/asm-offsets.h |5 +
 arch/arm/include/asm/arch-mx5/imx-regs.h|   94 ++--
 arch/arm/include/asm/arch-mx5/iomux.h   |  102 
 arch/arm/include/asm/arch-mx5/mx5x_pins.h   |  469 ++-
 board/efikamx/Makefile  |   52 ++
 board/efikamx/config.mk |   25 +
 board/efikamx/efikamx.c |  689
+++
 board/efikamx/imximage.cfg  |  122 +
 board/freescale/mx35pdk/Makefile|   49 ++
 board/freescale/mx35pdk/lowlevel_init.S |  363 ++
 board/freescale/mx35pdk/mx35pdk.c   |  297 
 board/freescale/mx35pdk/mx35pdk.h   |  101 
 board/freescale/mx51evk/mx51evk.c   |   17 +-
 board/freescale/mx53evk/Makefile|   48 ++
 board/freescale/mx53evk/config.mk   |   24 +
 board/freescale/mx53evk/imximage.cfg|  112 +
 board/freescale/mx53evk/mx53evk.c   |  397 +++
 boards.cfg  |3 +
 doc/README.imximage |   12 +-
 doc/README.mx35pdk  |  188 
 drivers/block/Makefile  |1 +
 drivers/block/mxc_ata.c |  146 ++
 drivers/gpio/mxc_gpio.c |9 +-
 drivers/i2c/mxc_i2c.c   |  172 +--
 drivers/misc/Makefile   |5 +-
 drivers/misc/fsl_pmic.c |   45 ++-
 drivers/misc/mc9sdz60.c |   51 ++
 drivers/mtd/nand/mxc_nand.c |6 +-
 drivers/net/fec_mxc.c   |2 +-
 drivers/net/fec_mxc.h   |4 +-
 drivers/serial/serial_mxc.c  

Re: [U-Boot] [PATCH V2 09/11] SPI: mxc_spi: add SPI clock calculation and setup to the driver

[Stefano Babic]

On 01/20/2011 09:46 AM, Stefano Babic wrote:
> From: Anatolij Gustschin 
> 
> The MXC SPI driver didn't calculate the SPI clock up to
> now and just used highest possible divider 512 for DATA
> RATE in the control register. This results in very low
> transfer rates.
> 
> The patch adds code to calculate and setup the SPI clock
> frequency for transfers.
> 
> Signed-off-by: Anatolij Gustschin 
> Signed-off-by: Stefano Babic 

Applied to u-boot-imx, thanks

Best regards,
Stefano Babic

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

Re: [U-Boot] [PATCH V3 08/11] SPI: mxc_spi: fix swapping bug and add missing swapping in unaligned rx case

[Stefano Babic]

On 01/20/2011 06:53 PM, Stefano Babic wrote:
> From: Anatolij Gustschin 
> 
> We need to shift only one time in each cycle in the swapping loop
> for unaligned tx case. Currently two byte shift operations are
> performed in each loop cycle causing zero gaps in the transmited
> data, so not all data scheduled for transmition is actually
> transmited.
> 
> The proper swapping in unaligned rx case is missing, so add it
> as we need to put the received data into the rx buffer in the
> correct byte order.
> 
> Signed-off-by: Anatolij Gustschin 
> Tested-by: Stefano Babic 

Applied to u-boot-imx, thanks

Best regards,
Stefano Babic

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

Re: [U-Boot] [PATCH V3 11/11] Add support for Freescale's mx35pdk board.

[Stefano Babic]

On 01/20/2011 06:53 PM, Stefano Babic wrote:
> The patch adds suupport for the Freescale's mx35pdk board
> (known as well as mx35_3stack).
> 
> The board boots from the NOR flash. Following devices
> are supported:
>  - two ethernet devices (FEC and SMC911x on debug board)
>  - I2C
>  - PMIC (MC13892) via I2C interface
>  - UART
>  - NOR flash (64MB)
>  - NAND flash (2GB)
>  - basic access to mc9sdz60 registers via I2C interface
> 
> Signed-off-by: Stefano Babic 

Applied to u-boot-imx, thanks

Best regards,
Stefano Babic

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

Re: [U-Boot] [PATCH V4 11/11] Add support for Freescale's mx35pdk board.

[Stefano Babic]

On 01/20/2011 07:05 PM, Stefano Babic wrote:
> The patch adds suupport for the Freescale's mx35pdk board
> (known as well as mx35_3stack).
> 
> The board boots from the NOR flash. Following devices
> are supported:
>  - two ethernet devices (FEC and SMC911x on debug board)
>  - I2C
>  - PMIC (MC13892) via I2C interface
>  - UART
>  - NOR flash (64MB)
>  - NAND flash (2GB)
>  - basic access to mc9sdz60 registers via I2C interface
> 
> Signed-off-by: Stefano Babic 

Applied to u-boot-imx, thanks

Best regards,
Stefano Babic

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

Re: [U-Boot] [PATCH V3 01/11] Add support for MX35 processor

[Stefano Babic]

On 01/20/2011 06:49 PM, Stefano Babic wrote:
> The patch adds basic support for the Freescale's i.MX35
> (arm1136 based) processor.
> 
> The patch adds also a prototype for the initialization
> of the FEC(ethernet controller) to netdev.h to avoid
> warnings.
> 
> Signed-off-by: Stefano Babic 

Applied to u-boot-imx, thanks

Best regards,
Stefano Babic

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

Re: [U-Boot] [PATCH 3/3 v4] iMX5: EfikaMX: Preliminary board support

[Stefano Babic]

On 01/19/2011 03:40 PM, Marek Vasut wrote:
> Supported:
> MMC
> IDE
> PMIC
> SPI flash
> LEDs
> 
> I can boot the kernel supplied by freescale/genesi with this from MMC card
> and/or PATA disk.
> 
> Signed-off-by: Marek Vasut 
> ---

Applied to u-boot-imx, thanks

Best regards,
Stefano Babic

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

Re: [U-Boot] [PATCH 2/3 v2] MX51EVK: Use SWx macros in PMIC init

[Stefano Babic]

On 01/19/2011 03:40 PM, Marek Vasut wrote:
> Signed-off-by: Marek Vasut 
> ---
> v2: Remove stray newline and useless parens
> 
>  board/freescale/mx51evk/mx51evk.c |6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)

Applied to u-boot-imx, thanks

Best regards,
Stefano Babic

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

Re: [U-Boot] [PATCH 1/3 RESEND] MC13892: Add SWx buck switchers definitions

[Stefano Babic]

On 01/19/2011 03:40 PM, Marek Vasut wrote:
> Define voltages configurable on SWx buck switchers.
> 
> Signed-off-by: Marek Vasut 
> Acked-by: Stefano Babic 
> ---
>  include/mc13892.h |   39 +++
>  1 files changed, 39 insertions(+), 0 deletions(-)
> 

Applied to u-boot-imx, thanks

Best regards,
Stefano Babic

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

Re: [U-Boot] [PATCH v5 1/1] imximage: Add MX53 boot image support

[Stefano Babic]

On 01/19/2011 08:40 PM, Jason Liu wrote:
> This patch add the MX53 boot image support.
> 
> This patch has been tested on Freescale MX53EVK board
> and MX51EVK board.
> 
> Signed-off-by: Jason Liu 
> 
> ---

Applied to u-boot-imx, thanks

Regards,
Stefano Babic

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

Re: [U-Boot] [PATCH] MXC: removed warnings from IMX51 ATA driver

[Marek Vasut]

On Tuesday 01 February 2011 18:30:02 Stefano Babic wrote:
> Drop warnings due to unused variables.
> 
> Signed-off-by: Stefano Babic 
> CC: Marek Vasut 
> ---
>  drivers/block/mxc_ata.c |3 ---
>  1 files changed, 0 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/block/mxc_ata.c b/drivers/block/mxc_ata.c
> index 842a633..f22f4f4 100644
> --- a/drivers/block/mxc_ata.c
> +++ b/drivers/block/mxc_ata.c
> @@ -87,11 +87,8 @@ struct mxc_data_hdd_regs {
> 
>  /* PIO timing table */
>  #define  NR_PIO_SPECS5
> -static uint16_t pio_t0[NR_PIO_SPECS] = { 600, 383, 240, 180, 120 };
>  static uint16_t pio_t1[NR_PIO_SPECS] = { 70,  50,  30,  30,  25 };
>  static uint16_t pio_t2_8[NR_PIO_SPECS]   = { 290, 290, 290, 80,  70 };
> -static uint16_t pio_t2_16[NR_PIO_SPECS]  = { 165, 125, 100, 80,  70 };
> -static uint16_t pio_t2i[NR_PIO_SPECS]= { 40,  0,   0,   0,   0 };
>  static uint16_t pio_t4[NR_PIO_SPECS] = { 30,  20,  15,  10,  10 };
>  static uint16_t pio_t9[NR_PIO_SPECS] = { 20,  15,  10,  10,  10 };
>  static uint16_t pio_tA[NR_PIO_SPECS] = { 50,  50,  50,  50,  50 };

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

[U-Boot] [PATCH] MXC: removed warnings from IMX51 ATA driver

[Stefano Babic]

Drop warnings due to unused variables.

Signed-off-by: Stefano Babic 
CC: Marek Vasut 
---
 drivers/block/mxc_ata.c |3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/drivers/block/mxc_ata.c b/drivers/block/mxc_ata.c
index 842a633..f22f4f4 100644
--- a/drivers/block/mxc_ata.c
+++ b/drivers/block/mxc_ata.c
@@ -87,11 +87,8 @@ struct mxc_data_hdd_regs {
 
 /* PIO timing table */
 #defineNR_PIO_SPECS5
-static uint16_t pio_t0[NR_PIO_SPECS]   = { 600, 383, 240, 180, 120 };
 static uint16_t pio_t1[NR_PIO_SPECS]   = { 70,  50,  30,  30,  25 };
 static uint16_t pio_t2_8[NR_PIO_SPECS] = { 290, 290, 290, 80,  70 };
-static uint16_t pio_t2_16[NR_PIO_SPECS]= { 165, 125, 100, 80,  70 };
-static uint16_t pio_t2i[NR_PIO_SPECS]  = { 40,  0,   0,   0,   0 };
 static uint16_t pio_t4[NR_PIO_SPECS]   = { 30,  20,  15,  10,  10 };
 static uint16_t pio_t9[NR_PIO_SPECS]   = { 20,  15,  10,  10,  10 };
 static uint16_t pio_tA[NR_PIO_SPECS]   = { 50,  50,  50,  50,  50 };
-- 
1.7.1

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

Re: [U-Boot] [PATCH 6/6] p1021mds: add QE and UEC support

[Haiying Wang]

On Tue, 2011-02-01 at 10:50 -0600, Scott Wood wrote:
> > > 
> > If it is a one time setting, there should be no problem to put it into
> > board code. But these pin settings need to be done before any usage of
> > phy read/write (accessing MDIO/MDC), and need to be released after the
> > usage of phy, thus the devices connected to eLBC like NAND flash/BCSR
> > can be accessed. If we use board code to set/release the pin, we don't
> > know when the phy access and nand flash access will happen.
> 
> Is this actually a board issue or an SoC issue?
> 
It is not a board issue. It is a SoC *feature*. Too many pins are muxed
on P1021. For this case, LBCTL of eLBC is muxed with QE's CE_PB[20]
which is used for MDIO signal. 

Haiying


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

Re: [U-Boot] [PATCH] BLOCK: Fixup iMX51 ATA driver

[Marek Vasut]

On Tuesday 01 February 2011 08:11:51 Stefano Babic wrote:
> On 11/29/2010 03:18 PM, Marek Vasut wrote:
> > Signed-off-by: Marek Vasut 
> 
> Hi Marek,
> 
> in my regression tests to check if all IMX boards are compiled clean I
> found the following warnings (efikamx):
> 
> mxc_ata.c:90: warning: 'pio_t0' defined but not used
> mxc_ata.c:93: warning: 'pio_t2_16' defined but not used
> mxc_ata.c:94: warning: 'pio_t2i' defined but not used
> 
> As I have already merged your patch into u-boot-imx (and Albert has
> already merged it in u-boot-arm), I will post a patch on top of it to
> remove them. Anyway, have you expected that these three variables are
> not used at all ? Could I remove them ?

Yes, you can remove them. They are unused in the original freescale driver too, 
stupid sed-mistake.

Thanks for the good catch :)

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

Re: [U-Boot] [PATCH 6/6] p1021mds: add QE and UEC support

[Scott Wood]

On Mon, 31 Jan 2011 22:14:45 -0500
Haiying Wang  wrote:

> On Mon, 2011-01-31 at 15:28 -0600, Kumar Gala wrote:
> > On Jan 31, 2011, at 2:50 PM, Haiying Wang wrote:
> > 
> > > On Mon, 2011-01-31 at 21:11 +0100, Wolfgang Denk wrote:
> > >>> 
> > >>> +#ifdef CONFIG_P1021
> > >>> +   ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
> > >>> +
> > >>> +   /* QE9 and QE12 need to be set for enabling QE MII managment 
> > >>> signals */
> > >>> +   setbits_be32(&gur->pmuxcr, MPC85xx_PMUXCR_QE9);
> > >>> +   setbits_be32(&gur->pmuxcr, MPC85xx_PMUXCR_QE12);
> > >>> +#endif
> > >> ...
> > >> 
> > >> Can we please avoid having board specific code in common files?
> > > I wish I could, but only P1021 has such pin mux problems.
> > > 
> > >> If this is really necessary, it shoud be a feature-specific #define,
> > >> not a board specific one.
> > > I don't know whether this *feature* will show up on other SoC. But if
> > > you insist, I can use CONFIG_QE_PIN_MUX.
> > > 
> > > Thanks.
> > > 
> > > Haiying
> > 
> > I think pin muxing is a board level decision so it seems like board code is 
> > the right place for it.
> > 
> If it is a one time setting, there should be no problem to put it into
> board code. But these pin settings need to be done before any usage of
> phy read/write (accessing MDIO/MDC), and need to be released after the
> usage of phy, thus the devices connected to eLBC like NAND flash/BCSR
> can be accessed. If we use board code to set/release the pin, we don't
> know when the phy access and nand flash access will happen.

Is this actually a board issue or an SoC issue?

-Scott

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

[U-Boot] !!! Trouble with u-boot and leon3 !!!!

[Fabio Giovagnini]

Hi All,
We have built u-boot (from git as suggested by U-Boot SPARC / LEON Port v
1.0.0 April 2009.
The building is successfull.
I configured for execution in ram (CONFIG_SYS_TEXT_BASE = 0x4000) and
the system runs.
But nothing I see on the serial console connected to minicom.
When I do Crtl+C the system stop at an address inside such function:
arch/sparc/cpu/leon3/cpu_init.c - void cpu_init_f(void)
I found that it fails:
/* Find AMBA APB IRQMP Controller */
if (ambapp_apb_first(VENDOR_GAISLER, GAISLER_IRQMP, &apbdev) != 1) {
/* no IRQ controller, something is wrong
 * ==> jump to start (or hang)
 */
while (1) ;
}

so the while (1) occurs.

I discovered that:
ambapp_apb_first(VENDOR_GAISLER, GAISLER_IRQMP, &apbdev)

Any suggetions?


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

Re: [U-Boot] nand commands missing wtchdog reset

[Scott Wood]

On Tue, 1 Feb 2011 10:43:56 +0100
Jaap de Jong  wrote:

> thanks for your reply.
> You are right, the format was totally wrong; I apologize!
> Concerning the patch itself: I agree: low-level hangups should trigger 
> the watchdog although in this specific case the hangups will not occur 
> due to a timeout construction surrounding it.

And if the timeout mechanism fails, that'd be a really good time for
the watchdog to kick in. :-)

> Unfortunately I'm not able to investigate this any further
> To get this fix done: hopefully some u-boot-guru will do the dirty work...

It's just a couple lines, I'll write up a patch.

-Scott

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

Re: [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL

[Scott Wood]

On Tue, 1 Feb 2011 08:34:01 +0100
Wolfgang Denk  wrote:

> Dear Scott Wood,
> 
> In message <20110131135548.50d65...@udp111988uds.am.freescale.net> you wrote:
> > As I understand it, it has only been limited to PLATFORM_LDFLAGS since
> > the LDFLAGS_u-boot commit.  Was that change intentional, and widely
> > tested?
> 
> Can you please be more specific?  I don't see where "the
> LDFLAGS_u-boot commit" (you mean 8aba9dc ?) would change any related
> code.  The relevant hunk looks like this:
> 
> @@ -204,9 +204,11 @@ endif
>  
>  AFLAGS := $(AFLAGS_DEBUG) -D__ASSEMBLY__ $(CPPFLAGS)
>  
> -LDFLAGS += -Bstatic -T $(obj)u-boot.lds $(PLATFORM_LDFLAGS)
> +LDFLAGS += $(PLATFORM_LDFLAGS)
> +
> +LDFLAGS_u-boot += -Bstatic -T $(obj)u-boot.lds $(PLATFORM_LDFLAGS)
>  ifneq ($(CONFIG_SYS_TEXT_BASE),)
> -LDFLAGS += -Ttext $(CONFIG_SYS_TEXT_BASE)
> +LDFLAGS_u-boot += -Ttext $(CONFIG_SYS_TEXT_BASE)
>  endif

Prior to the introduction of LDFLAGS_u-boot, was LDFLAGS not what was
used?  So before, anything that board/cpu code adds directly to LDFLAGS
(maybe they're supposed to use PLATFORM_LDFLAGS, but not all do) was
used in the final link.  After 8aba9dc, only things in
PLATFORM_LDFLAGS plus -Bstatic and -T are used in the final link.

-Scott

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

Re: [U-Boot] [PATCH] powerpc/85xx: Remove config.mk for nand linker script

[Scott Wood]

On Mon, 31 Jan 2011 22:02:03 -0600
Kumar Gala  wrote:

> 
> On Jan 31, 2011, at 4:52 PM, Scott Wood wrote:
> 
> > On Mon, 31 Jan 2011 16:37:44 -0600
> > Kumar Gala  wrote:
> > 
> >> * fix where we define this, it should !CONFIG_NAND_SPL, read the old 
> >> config.mk incorrectly.
> > 
> > I don't think that will make a difference -- CONFIG_NAND_SPL is never
> > set when symbols are extracted into autoconf.mk, and
> > CONFIG_SYS_LDSCRIPT is not used when building the SPL.
> 
> it seems to work out ok.

My point is it will work either way, the ifdef just confuses things,
since that's not actually the mechanism by which a different linker
script is used for SPL (nor would it work if you relied on the
ifdef for that).

-Scott

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

[U-Boot] spi subystem maintainer?

[Kumar Gala]

Do we have one?

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

Re: [U-Boot] u-boot compilation lowlevel_init.S:619: error: #error "Unknown DDR configuration!!!"

[Wolfgang Denk]

Dear Vaishali,

In message  you 
wrote:
> Getting this error with the u-boot compilation http://pastebin.com/h3x90vHK
> u-boot is a git clone of the git://gitorious.org/hawkboard/u-boot.git
> plz help any idea what needs to be done to fix this .

Sorry - please contact the people responsible for that repository.

We have no idea if or how this corresponds to the mainline code we are
discussing here.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Madness takes its toll. Please have exact change.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] u-boot compilation lowlevel_init.S:619: error: #error "Unknown DDR configuration!!!"

[Vaishali]

Getting this error with the u-boot compilation http://pastebin.com/h3x90vHK
u-boot is a git clone of the git://gitorious.org/hawkboard/u-boot.git
plz help any idea what needs to be done to fix this .
Thanks .
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL

[Haiying Wang]

On Tue, 2011-02-01 at 08:34 +0100, Wolfgang Denk wrote:

> Can you please be more specific?  I don't see where "the
> LDFLAGS_u-boot commit" (you mean 8aba9dc ?) would change any related
> code.  The relevant hunk looks like this:
> 
> @@ -204,9 +204,11 @@ endif
>  
>  AFLAGS := $(AFLAGS_DEBUG) -D__ASSEMBLY__ $(CPPFLAGS)
>  
> -LDFLAGS += -Bstatic -T $(obj)u-boot.lds $(PLATFORM_LDFLAGS)
> +LDFLAGS += $(PLATFORM_LDFLAGS)
> +
> +LDFLAGS_u-boot += -Bstatic -T $(obj)u-boot.lds $(PLATFORM_LDFLAGS)
>  ifneq ($(CONFIG_SYS_TEXT_BASE),)
> -LDFLAGS += -Ttext $(CONFIG_SYS_TEXT_BASE)
> +LDFLAGS_u-boot += -Ttext $(CONFIG_SYS_TEXT_BASE)
>  endif
>  
>  # Location of a usable BFD library, where we define "usable" as
> 
> and this does not make any changes of PLATFORM_LDFLAGS into LDFLAGS
> or vice versa.
> 
But PLATFORM_LDFLAGS has been changed in $(CPUDIR)/config.mk.

You can see in commit 8aba9dc:

--- a/arch/powerpc/config.mk
+++ b/arch/powerpc/config.mk
@@ -24,10 +24,10 @@
 CROSS_COMPILE ?= ppc_8xx-
 
 STANDALONE_LOAD_ADDR = 0x4
-
+LDFLAGS_u-boot = --gc-sections
 PLATFORM_RELFLAGS += -mrelocatable -ffunction-sections -fdata-sections
 PLATFORM_CPPFLAGS += -DCONFIG_PPC -D__powerpc__
-PLATFORM_LDFLAGS  += -n --gc-sections
+PLATFORM_LDFLAGS  += -n

Here, --gc-sections is set only for LDFLAGS_u-boot, the PLATFORM_LDFLAGS
does have --gc-sections, So in toplevel config.mk:

+LDFLAGS += $(PLATFORM_LDFLAGS)

And later in this config.mk, 

@@ -259,7 +261,7 @@ $(obj)%.s:  %.c
 
 # If the list of objects to link is empty, just create an empty built-in.o
 cmd_link_o_target = $(if $(strip $1),\
- $(LD) -r -o $@ $1 ,\
+ $(LD) $(LDFLAGS) -r -o $@ $1,\
  rm -f $@; $(AR) rcs $@ )


LDFLAGS is added in cmd_link_o_target which made changes to build
nand_spl.

Haiying




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

Re: [U-Boot] [PATCH 2/2 v2] powerpc/8xxx: Refactor fsl_ddr_get_spd into common code from board

[Kumar Gala]

On Feb 1, 2011, at 4:08 AM, Timur Tabi wrote:

> On Mon, Jan 31, 2011 at 11:28 PM, Kumar Gala  
> wrote:
>> +#if defined(SPD_EEPROM_ADDRESS) || \
>> +defined(SPD_EEPROM_ADDRESS1) || defined(SPD_EEPROM_ADDRESS2) || \
>> +defined(SPD_EEPROM_ADDRESS3) || defined(SPD_EEPROM_ADDRESS4)
>> +#if (CONFIG_NUM_DDR_CONTROLLERS == 1) && (CONFIG_DIMM_SLOTS_PER_CTLR == 1)
>> +u8 spd_i2c_addr[CONFIG_NUM_DDR_CONTROLLERS][CONFIG_DIMM_SLOTS_PER_CTLR] = {
>> +   [0][0] = SPD_EEPROM_ADDRESS,
>> +};
>> +#endif
>> +#if (CONFIG_NUM_DDR_CONTROLLERS == 2) && (CONFIG_DIMM_SLOTS_PER_CTLR == 1)
>> +u8 spd_i2c_addr[CONFIG_NUM_DDR_CONTROLLERS][CONFIG_DIMM_SLOTS_PER_CTLR] = {
>> +   [0][0] = SPD_EEPROM_ADDRESS1,   /* controller 1 */
>> +   [1][0] = SPD_EEPROM_ADDRESS2,   /* controller 2 */
>> +};
>> +#endif
>> +#if (CONFIG_NUM_DDR_CONTROLLERS == 2) && (CONFIG_DIMM_SLOTS_PER_CTLR == 2)
>> +u8 spd_i2c_addr[CONFIG_NUM_DDR_CONTROLLERS][CONFIG_DIMM_SLOTS_PER_CTLR] = {
>> +   [0][0] = SPD_EEPROM_ADDRESS1,   /* controller 1 */
>> +   [0][1] = SPD_EEPROM_ADDRESS2,   /* controller 1 */
>> +   [1][0] = SPD_EEPROM_ADDRESS3,   /* controller 2 */
>> +   [1][1] = SPD_EEPROM_ADDRESS4,   /* controller 2 */
>> +};
>> +#endif
> 
> Wouldn't it be easier if we just temporarily defined values for
> SPD_EEPROM_ADDRESSx?  Like this:
> 
> #ifndef SPD_EEPROM_ADDRESS2
> #define SPD_EEPROM_ADDRESS2 0
> #endif
> ...
> 
> u8 spd_i2c_addr[2][2] = {

This is problematic because because if you notice SPD_EEPROM_ADDRESS2 is used 
for both controller 2 / dimm 1 & controller 1 / dimm 2.

>> +static void __get_spd(generic_spd_eeprom_t *spd, u8 i2c_address)
>> +{
>> +   int ret = i2c_read(i2c_address, 0, 1, (uchar *)spd,
>> +   sizeof(generic_spd_eeprom_t));
>> +
>> +   if (ret) {
>> +   debug("DDR: failed to read SPD from address %u\n", 
>> i2c_address);
> 
> This should probably be a printf() instead.

will change

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

Re: [U-Boot] MPC8xx malloc failing

[Wolfgang Denk]

Dear saugat mitra,

In message  you 
wrote:
> 
> I have moved onto 2009.11, though more new versions are available but still ..

Stefano wrote:

| > make yourself a favour and upgrade to last U-Boot version...

Can you please explain why you stick again with code that is > 1 year
old?


> I am using a MPC8XX based board( as earlier), but now the code is crashing
> in env_relocate() function. On applying debug prints I found that the
> code was failing
> in malloc with a Bus Fault with the following dump -

It would have been easier if you had just decoded the backtrace:

> Call backtrace:
> 00FC9988 00FDCD34 00FCCD60 00FC93B8
> machine check

Which routines are these addresses from?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
In C we had to code our own bugs, in C++ we can inherit them.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] BSS footprint of FAT very high - SPL issues

[Wolfgang Denk]

Dear "Bedia, Vaibhav",

In message  you 
wrote:
>
> In that case how can network boot be supported in U-Boot? Is the expectation 
> that the SPL image which gets downloaded to internal RAM inits SDRAM, 
> relocates to it and then download any other image like a larger U-Boot or the 
> OS image?

Can you please restrict your line length to some 70 or so characters?

At the moment, U-Boot it self assumes that it somehow got started as a
whole - either executing from reset (like when booting from NOR flash
or similar bootable memory regions), or by being loaded by some
secondary loader.  So far, we support NAND and OneNAND in such a mode.
Especially with NAND the restrictions may be severe - quite often the
SPL code has to fit in as little as 4 KiB, sometimes even in 2 KiB.

If you want SPL support for network booting, this needs to be added.
I am not sure if this really makes sense, though. Many devices today
have ROM code capable of reading boot images from USB or SDCard etc.,
so these are the "naturally supported" boot modes for such systems.
I haven't seen network boot in such a configuration yet.

If you add it, I guess the next steps will be support for WLAN booting
and IPv6.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Why can you only have two doors on a chicken coop? If it had four  it
would be a chicken sedan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] MPC8xx malloc failing

[saugat mitra]

Hi

I have moved onto 2009.11, though more new versions are available but still ..
I am using a MPC8XX based board( as earlier), but now the code is crashing
in env_relocate() function. On applying debug prints I found that the
code was failing
in malloc with a Bus Fault with the following dump -

Bus Fault @ 0x00fc9988, fixup 0x
Machine check in kernel mode.
Caused by (from msr): regs 00f42e20 Unknown values in msr
NIP: 00FC9988 XER: 20002D10 LR: 00FC9988 REGS: 00f42e20 TRAP: 0200 DAR: 7D8C6218
MSR: 1002 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00

GPR00: 00FC9988 00F42F10 00F42F90  00FEC4AC 00F42B10  
GPR08: 0020 02202800 B060C000 0020 82C00428 090700D8 00FFE400 FDFC7000
GPR16: 00019040 000448D1 045744A8 02420830 01A400E2 0001 0074832A 
GPR24: 00F42F90 00F42F78 4008 0072 00FF81E4 B0610008 00FFE424 7D8C6214
Call backtrace:
00FC9988 00FDCD34 00FCCD60 00FC93B8
machine check
### ERROR ### Please RESET the board ###


Help Required.
Thanks
Saugat.

On Mon, Jan 24, 2011 at 6:16 PM, Stefano Babic  wrote:
> On 01/24/2011 01:12 PM, saugat mitra wrote:
>> Hi
>>
>
> Hi,
>
>> I am trying to boot a MPC8XXX based board using uboot version 1.1.3.
>> I am able to get the serial console up. But when I try to ping it
>> gives me a time out error.
>> On trying "mii info" and enabling debug messages I see that all the
>> mii read messages are
>> returning 0x. Could any one please suggest me steps to debug.
>
> make yourself a favour and upgrade to last U-Boot version. Your version
> is so ancient that is impossible to find which is the fix for you. And
> on current release, ethernet works well on mpc8xx (tested on a TQ
> tqm860L board).
>
> Best regards,
> Stefano Babic
>
> --
> =
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
> =
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] BSS footprint of FAT very high - SPL issues

[Bedia, Vaibhav]

On Tuesday, February 01, 2011 4:19 PM, Albert ARIBAUD wrote:
[...]
> That would be way outside of how U-Boot is supposed to work: the
> assumption is that the SPL and U-Boot itself are present on-board
> anyway -- the rationale being that the board should be able to get
> to the U-Boot prompt with only the console attached.  

Ok. Thanks for the clarification.

In that case how can network boot be supported in U-Boot? Is the expectation 
that the SPL image which gets downloaded to internal RAM inits SDRAM, relocates 
to it and then download any other image like a larger U-Boot or the OS image?

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

[U-Boot] Flashing ubinize image under U-Boot

[Robert Hodaszi]

  Hi,

I would like to support UBI under U-Boot. I could successfully flash a 
raw UBIFS image with the "ubi write" command, and also a UBI (ubinize) 
image with the nand write command. So it's working well. But in the 
second case, I will loose all existing information (e.g. the erase 
counters). Under Linux, there's the "ubiformat" application, which can 
flash this image, while preserves the existing informations.

Does the U-Boot support flashing UBI (ubinize) images on the same way 
(preserving partition informations)? Or if not, then is there any plan 
to extend the "ubi write" to support the ubinize images?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3 v4] iMX5: EfikaMX: Preliminary board support

[Albert ARIBAUD]

Le 01/02/2011 08:57, Wolfgang Denk a écrit :
> Dear Albert ARIBAUD,
>
> In message<4d47ad9a.3060...@free.fr>  you wrote:
>>
>> Wolfgang, do we:
>>
>> - wait for Prafulla's pull, or
>>
>> - just take Stefano's and move ahead with this release, and Prafulla
>> stacks the current changes onto his 'next' branch until the MW opens
>> again, or
>>
>> - something else yet?
>
> Let's please thake what we have so far and get some -rc1 out ASAP.
>
> When Prafulla's pull request comes, we can still decide if we pull
> this into mainline (I tend to do so if it's really a few days) or
> push into next.

All right.

Stefano, please provide a new pull request (with fixed modes); I'll take 
it then send out my own pull request.

> Best regards,
>
> Wolfgang Denk

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

Re: [U-Boot] SPI flash protection

[Albert ARIBAUD]

Le 01/02/2011 10:09, Simon Guinot a écrit :

>> In this case, a *software* protection mechanism like for NOR flash
>> would be a better choice.
>
> Or no protection at all. After all, there is no such mechanism
> implemented for u-boot and Linux...

Actually yes, there is, for NOR at least: in U-boot, sectors of NOR 
containing U-Boot and the environment are marked protected and thus 
trying to erase them will fail if you don't unprotect them first.

As for Linux, you can define this when declaring the NOR device in the 
machine specific code.

> Best regards,
>
> Simon

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

Re: [U-Boot] [PATCH 1/6] mtd: add writebufsize field to mtd_info struct

[Holger Brunck]

Hi Stefan,

Stefan Roese wrote:
> 
>> as I told in another mail, the min I/O size adaption patch leads to
>> incompatibilites for the UBIFS and therefore the similar patch in linux
>> kernel was reverted. But anyway the first five patches in the patch serie
>> are already part of the mtd layer of the linux kernel.
>>
>> So the patches 1-5 of this series can also be committed to u-boot. Whats
>> your opinion?
> 
> I have no problems with applying patches 1-5. But they have been
> submitted after the merge window was closed, so they will not make it
> into the next release.
> 
> I'm volunteering to push those patches into "next" (once its available)
> via one of my git repositories (UBI/UBIFS or CFI) if nobody else objects.
> 

Ok, thanks.

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

Re: [U-Boot] [PATCH 2/2] at91sam9261ek: make operational again

[Albert ARIBAUD]

Le 01/02/2011 11:45, Michael Trimarchi a écrit :

> Hi
>
> /home/toolchain/bin/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld
>   -pie -r -o libat91.o  lowlevel_init.o clock.o cpu.o reset.o timer.o
> /home/toolchain/bin/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld:
>  -r and -shared may not be used together
>
> I have tried this patch but this a problem releated to linking option. Do you 
> have this problem?
>
> Michael

Read up recent posts on the list: this was detected and is fixed in the 
master branch of the u-boot-arm repository.

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

Re: [U-Boot] [PATCH 2/2] at91sam9261ek: make operational again

[Michael Trimarchi]

Dear Remy

On 01/27/2011 11:46 PM, Remy Bohmer wrote:
> Since U-boot v2010.12 the at91sam9261ek board is broken.
> This is solved and tested on this board.
>
> Note: It requires that the 1st stage bootloader (like Atmel at91-bootstrap)
> to load U-boot at a different address compared to previous releases of
> U-boot due to conflicts in the BSS area during relocation.
> (0x23f0 -> -0x23e0)
>
> Derived from a patch of: Alexander Stein 
> 
>
> Signed-off-by: Remy Bohmer 
Hi

/home/toolchain/bin/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld
  -pie -r -o libat91.o  lowlevel_init.o clock.o cpu.o reset.o timer.o
/home/toolchain/bin/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld:
 -r and -shared may not be used together

I have tried this patch but this a problem releated to linking option. Do you 
have this problem?

Michael

> ---
>  board/atmel/at91sam9261ek/Makefile|   10 +-
>  board/atmel/at91sam9261ek/at91sam9261ek.c |7 ---
>  board/atmel/at91sam9261ek/config.mk   |1 -
>  include/configs/at91sam9261ek.h   |   25 +
>  4 files changed, 30 insertions(+), 13 deletions(-)
>  delete mode 100644 board/atmel/at91sam9261ek/config.mk
>
> diff --git a/board/atmel/at91sam9261ek/Makefile 
> b/board/atmel/at91sam9261ek/Makefile
> index 9d20ba0..1da810f 100644
> --- a/board/atmel/at91sam9261ek/Makefile
> +++ b/board/atmel/at91sam9261ek/Makefile
> @@ -29,16 +29,16 @@ include $(TOPDIR)/config.mk
>  
>  LIB  = $(obj)lib$(BOARD).o
>  
> -COBJS-y += at91sam9261ek.o
> +COBJS-y += $(BOARD).o
>  COBJS-y += led.o
>  COBJS-$(CONFIG_HAS_DATAFLASH) += partition.o
>  
> -SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
> -OBJS := $(addprefix $(obj),$(COBJS-y))
> -SOBJS:= $(addprefix $(obj),$(SOBJS))
> +SRCS := $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
> +OBJS := $(addprefix $(obj),$(COBJS-y) $(SOBJS-y))
> +SOBJS:= $(addprefix $(obj),$(SOBJS-y))
>  
>  $(LIB):  $(obj).depend $(OBJS) $(SOBJS)
> - $(call cmd_link_o_target, $(OBJS) $(SOBJS))
> + $(call cmd_link_o_target, $(OBJS))
>  
>  clean:
>   rm -f $(SOBJS) $(OBJS)
> diff --git a/board/atmel/at91sam9261ek/at91sam9261ek.c 
> b/board/atmel/at91sam9261ek/at91sam9261ek.c
> index de5cfae..25c181e 100644
> --- a/board/atmel/at91sam9261ek/at91sam9261ek.c
> +++ b/board/atmel/at91sam9261ek/at91sam9261ek.c
> @@ -246,7 +246,7 @@ int board_init(void)
>   gd->bd->bi_arch_number = MACH_TYPE_AT91SAM9261EK;
>  #endif
>   /* adress of boot parameters */
> - gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
> + gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;
>  
>   at91_serial_hw_init();
>  #ifdef CONFIG_CMD_NAND
> @@ -273,8 +273,9 @@ int board_eth_init(bd_t *bis)
>  
>  int dram_init(void)
>  {
> - gd->bd->bi_dram[0].start = PHYS_SDRAM;
> - gd->bd->bi_dram[0].size = PHYS_SDRAM_SIZE;
> + /* dram_init must store complete ramsize in gd->ram_size */
> + gd->ram_size = get_ram_size((volatile long *)CONFIG_SYS_SDRAM_BASE,
> + CONFIG_SYS_SDRAM_SIZE);
>   return 0;
>  }
>  
> diff --git a/board/atmel/at91sam9261ek/config.mk 
> b/board/atmel/at91sam9261ek/config.mk
> deleted file mode 100644
> index e554a45..000
> --- a/board/atmel/at91sam9261ek/config.mk
> +++ /dev/null
> @@ -1 +0,0 @@
> -CONFIG_SYS_TEXT_BASE = 0x23f0
> diff --git a/include/configs/at91sam9261ek.h b/include/configs/at91sam9261ek.h
> index 401478b..0cffd94 100644
> --- a/include/configs/at91sam9261ek.h
> +++ b/include/configs/at91sam9261ek.h
> @@ -27,6 +27,8 @@
>  #ifndef __CONFIG_H
>  #define __CONFIG_H
>  
> +#include 
> +
>  #define CONFIG_AT91_LEGACY
>  
>  /* ARM asynchronous clock */
> @@ -39,6 +41,7 @@
>  #else
>  #define CONFIG_AT91SAM9261   1   /* It's an Atmel AT91SAM9261 SoC*/
>  #endif
> +#define CONFIG_AT91FAMILY
>  #define CONFIG_ARCH_CPU_INIT
>  #undef CONFIG_USE_IRQ/* we don't need IRQ/FIQ stuff  
> */
>  
> @@ -105,11 +108,21 @@
>  #define CONFIG_CMD_DHCP  1
>  #define CONFIG_CMD_NAND  1
>  #define CONFIG_CMD_USB   1
> +#define CONFIG_CMD_CACHE 1
>  
>  /* SDRAM */
>  #define CONFIG_NR_DRAM_BANKS 1
> -#define PHYS_SDRAM   0x2000
> -#define PHYS_SDRAM_SIZE  0x0400  /* 64 megs */
> +#define CONFIG_SYS_SDRAM_BASE0x2000
> +#define CONFIG_SYS_SDRAM_SIZESZ_64M  /* 64 megs */
> +
> +/*
> + * AT91-bootstrap expects that U-boot needs to be loaded at 0x23f0
> + * but since U-boot is now being relocated to the end of RAM which is
> + * almost in the same area, there will be an overlap in the BSS segment
> + * resulting in a lockup during boot. So, we need to tell the
> + * AT91-bootstrap code to load it at a lower address, namely 0x23e0
> + */
> +#define CONFIG_SYS_TEXT_BASE 0x23e0
>  
>  /* DataFlash */
>  #define CONFIG_ATMEL_DAT

Re: [U-Boot] BSS footprint of FAT very high - SPL issues

[Albert ARIBAUD]

Le 01/02/2011 09:26, Aneesh V a écrit :

> I would prefer to have rest of the BSS in internal RAM itself.

In this case, you should define a dedicated output section in your 
linker file (say, ".ram"), which would locate in DRAM and collect input 
sections named similarly (".ram" as well would work) and then use 
attributes in the buffer declarations to put them in .ram sections.

That way, you'd clearly have .text, .data, .bss mapped to IRAM, and .ram 
  mapped to DRAM in a manner that readers of your code can understand.

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

Re: [U-Boot] BSS footprint of FAT very high - SPL issues

[Albert ARIBAUD]

Le 01/02/2011 11:18, Bedia, Vaibhav a écrit :
> On Tuesday, February 01, 2011 3:35 PM, Wolfgang Denk wrote:
>> Dear "Bedia, Vaibhav",
>>
>> In message
>>   you
>> wrote:
>>>
 Luckily we don't need networking related code in SPL.
>>>
>>> It might be required later on :)
>>
>> It makes no sense. Load and start U-Boot if you need more fancy
>> features. If you need even more complex ones (say, TCP/IP and Java
>> support) then boot and OS.
>>
>
> I was thinking of a scenario where we have SPL being loaded over
> ethernet and the SPL stage then trying to load the 2nd stage using
> TFTP.

That would be way outside of how U-Boot is supposed to work: the 
assumption is that the SPL and U-Boot itself are present on-board anyway 
-- the rationale being that the board should be able to get to the 
U-Boot prompt with only the console attached.

> Regards,
> Vaibhav

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

Re: [U-Boot] [U-BOOT PROBLEM] RAM loading RAMdisk addresses

[Wolfgang Denk]

Dear "GRACE, ERWAN (ERWAN)** CTR **",

please make sure to keep the mailing list on Cc:

Also, please restrict your line length to some 70 characters or so.

In message 

 you wrote:
> 
> Thank you for your answer. I'd like to precise that the 2 RAMdisks
> weren't built from exactly the same set of files. There's a small
> difference between these RAMdisks as one of them was generated
> after replacing only one filewith another file which is supposed to
> be exactly the same as the first one. So, at the end of the day,
> these RAMdisks should have the same size but that isn't the case. I

No, they should not.  They should probably have the same content on a
file system level, but when erasing a file and replacing it by another
one (or even an identical copy) you will have other file system blocks
used, other inode and free block lists, etc.  In other words, the
binary images of the file systems will be different.  They will most
probably also compress to different sizes, then.

> precise that I'm not the person who generated these RAMdisks,
> that's why I try to understand why there's such a difference betw
> een them. Moreover, in the messages displayed on the screen when the

They are different images, with different sizes.

> board is booting, we can see that the addresses shown in the line
> "Loading RAMdisk to ..., end ... OK" are different. I'd like to
> know where these addressesare defined (in a configuration file? In

They are computed based on the ramdisk sizes (plus some rounding).
Given different ramdisk sizes you end up with different load
addresses.  There is no magic anywhere here.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Emotions are alien to me.  I'm a scientist.
-- Spock, "This Side of Paradise", stardate 3417.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] BSS footprint of FAT very high - SPL issues

[Bedia, Vaibhav]

On Tuesday, February 01, 2011 3:35 PM, Wolfgang Denk wrote:
> Dear "Bedia, Vaibhav",
> 
> In message
>  you
> wrote:  
>> 
>>> Luckily we don't need networking related code in SPL.
>> 
>> It might be required later on :)
> 
> It makes no sense. Load and start U-Boot if you need more fancy
> features. If you need even more complex ones (say, TCP/IP and Java
> support) then boot and OS. 
> 

I was thinking of a scenario where we have SPL being loaded over ethernet and 
the SPL stage then trying to load the 2nd stage using TFTP.

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

Re: [U-Boot] [PATCH 2/2 v2] powerpc/8xxx: Refactor fsl_ddr_get_spd into common code from board

[Timur Tabi]

On Mon, Jan 31, 2011 at 11:28 PM, Kumar Gala  wrote:
> +#if defined(SPD_EEPROM_ADDRESS) || \
> +    defined(SPD_EEPROM_ADDRESS1) || defined(SPD_EEPROM_ADDRESS2) || \
> +    defined(SPD_EEPROM_ADDRESS3) || defined(SPD_EEPROM_ADDRESS4)
> +#if (CONFIG_NUM_DDR_CONTROLLERS == 1) && (CONFIG_DIMM_SLOTS_PER_CTLR == 1)
> +u8 spd_i2c_addr[CONFIG_NUM_DDR_CONTROLLERS][CONFIG_DIMM_SLOTS_PER_CTLR] = {
> +       [0][0] = SPD_EEPROM_ADDRESS,
> +};
> +#endif
> +#if (CONFIG_NUM_DDR_CONTROLLERS == 2) && (CONFIG_DIMM_SLOTS_PER_CTLR == 1)
> +u8 spd_i2c_addr[CONFIG_NUM_DDR_CONTROLLERS][CONFIG_DIMM_SLOTS_PER_CTLR] = {
> +       [0][0] = SPD_EEPROM_ADDRESS1,   /* controller 1 */
> +       [1][0] = SPD_EEPROM_ADDRESS2,   /* controller 2 */
> +};
> +#endif
> +#if (CONFIG_NUM_DDR_CONTROLLERS == 2) && (CONFIG_DIMM_SLOTS_PER_CTLR == 2)
> +u8 spd_i2c_addr[CONFIG_NUM_DDR_CONTROLLERS][CONFIG_DIMM_SLOTS_PER_CTLR] = {
> +       [0][0] = SPD_EEPROM_ADDRESS1,   /* controller 1 */
> +       [0][1] = SPD_EEPROM_ADDRESS2,   /* controller 1 */
> +       [1][0] = SPD_EEPROM_ADDRESS3,   /* controller 2 */
> +       [1][1] = SPD_EEPROM_ADDRESS4,   /* controller 2 */
> +};
> +#endif

Wouldn't it be easier if we just temporarily defined values for
SPD_EEPROM_ADDRESSx?  Like this:

#ifndef SPD_EEPROM_ADDRESS2
#define SPD_EEPROM_ADDRESS2 0
#endif
...

u8 spd_i2c_addr[2][2] = {


> +static void __get_spd(generic_spd_eeprom_t *spd, u8 i2c_address)
> +{
> +       int ret = i2c_read(i2c_address, 0, 1, (uchar *)spd,
> +                               sizeof(generic_spd_eeprom_t));
> +
> +       if (ret) {
> +               debug("DDR: failed to read SPD from address %u\n", 
> i2c_address);

This should probably be a printf() instead.

-- 
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] BSS footprint of FAT very high - SPL issues

[Wolfgang Denk]

Dear "Bedia, Vaibhav",

In message  you 
wrote:
>
> > Luckily we don't need networking related code in SPL.
> 
> It might be required later on :)

It makes no sense. Load and start U-Boot if you need more fancy
features. If you need even more complex ones (say, TCP/IP and Java
support) then boot and OS.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
A witty saying proves nothing, but saying  something  pointless  gets
people's attention.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] BSS footprint of FAT very high - SPL issues

[Wolfgang Denk]

Dear Aneesh V,

In message <4d47c1c9.1020...@ti.com> you wrote:
> 
> > Why would that be necessary?  Just put the BSS segment in SDRAM, and
> > everything is fine, isn't it?
> 
> SDRAM is initialized by the SPL. So, bss can not be initialized and
> used until SDRAM initialization is complete. I would prefer to have

Yes, this is normal.

> rest of the bss in internal RAM so that it's available as soon as we
> enter C code.

Well, you probably have to decide if you want an easy solution with
the restictions of the internal RAM size, or a somewhat more complex
solution with much more powerful resources.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"It's like deja vu all over again."  - Yogi Berra
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] nand commands missing wtchdog reset

[Jaap de Jong]

thanks for your reply.
You are right, the format was totally wrong; I apologize!
Concerning the patch itself: I agree: low-level hangups should trigger 
the watchdog although in this specific case the hangups will not occur 
due to a timeout construction surrounding it.
Unfortunately I'm not able to investigate this any further
To get this fix done: hopefully some u-boot-guru will do the dirty work...

Jaap

On 01/31/2011 08:25 PM, Scott Wood wrote:
> On Mon, 31 Jan 2011 13:16:59 -0600
> Scott Wood  wrote:
>
>> On Mon, 31 Jan 2011 09:05:55 +0100
>> Jaap de Jong  wrote:
>>
>>> Hi all,
>>> On my board (at91sam9263ek) I have enabled the watchdog.
>>> It will reset the processor after about 16 seconds.
>>> It looks like it is working but if I'm writing a large file into nand it
>>> seems that the watchdog is not reset and finally my processor resets.
>>> I've patched it, but I'm not sure if it is the right way to do it this
>>> way...
>> So far we've been putting the watchdog resets in higher-level
>> functions.  It looks like the block-skipping versions have them, but
>> the non-block-skipping versions don't (and the former will call the
>> latter if it doesn't see any bad blocks).
>>
>> So I think this should go in nand_read() and nand_write().  If things
>> hang up inside the low-level wait that should trigger the watchdog.
> Oh, and all patches require a sign-off, and the text above the patch
> should be what is intended to go in the git changelog, with any
> additional comments/greetings/etc below a "---" line.
>
> See http://www.denx.de/wiki/U-Boot/Patches
> and also the Developer's Certificate of Origin in
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;h=689e2371095cc5dfea9927120009341f369159aa;hb=HEAD
>
> -Scott
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/6] mtd: add writebufsize field to mtd_info struct

[Stefan Roese]

Hi Holger & Detlev,

On Tuesday 01 February 2011 09:26:56 Holger Brunck wrote:
> > do you have any comment on this series?  I delegated the patches to you
> > in patchwork already :)  No seriously, the patches look sane and are in
> > accordance to what is done in Linux

I'm back from vacation now and slowly picking up...
 
> >> This field will be used to indicate the write buffer size
> >> of the MTD device. UBI will set it's minimal I/O unit size
> >> (min_io_size) to the indicated write buffer size. By this
> >> change we intend to fix failed recovery of UBIFS partitions
> >> we currently observe on NOR flash when mounting the partition
> >> after unclean unmount.
> >> 
> >> Currently the min_io_size is set to mtd->writesize (which is 1
> >> byte for NOR flash). But flash programming is often done from
> >> prepared write buffer containing multiple bytes and is performed
> >> in one programming operation which could be interrupted by a power
> >> cut or a system reset causing corrupted (partially written) areas
> >> in a flash sector. Knowing the size of potentially corrupted areas
> >> UBIFS scanning and recovery algorithms are able to perform
> >> successful recovery.
> >> 
> >> Signed-off-by: Holger Brunck 
> 
> as I told in another mail, the min I/O size adaption patch leads to
> incompatibilites for the UBIFS and therefore the similar patch in linux
> kernel was reverted. But anyway the first five patches in the patch serie
> are already part of the mtd layer of the linux kernel.
> 
> So the patches 1-5 of this series can also be committed to u-boot. Whats
> your opinion?

I have no problems with applying patches 1-5. But they have been submitted 
after the merge window was closed, so they will not make it into the next 
release.

I'm volunteering to push those patches into "next" (once its available) via 
one of my git repositories (UBI/UBIFS or CFI) if nobody else objects.

Cheers,
Stefan

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

Re: [U-Boot] SPI flash protection

[Simon Guinot]

Hi Reinhard,

On Mon, Jan 31, 2011 at 08:17:36AM +0100, Reinhard Meyer wrote:
> Dear Albert ARIBAUD, Simon Guinot,
> >
> Here is the protect area map for a MX25L4005A 4Mb flash:
> 
> bit  2 1 0 | protect level
>    |___
>  0 0 0 | none
>  0 0 1 | block 7
>  0 1 0 | block 6-7
>  0 1 1 | block 4-7
>  1 * * | all
> >>Block size is 64KB. The compiled U-Boot image is about 220KB and
> >>environment is 4KB. So, 4 blocks are required for U-Boot.
> 
> I don't know your particular hardware, but is not u-boot (or the
> initial bootloader if there is any) fetched from the *beginning*
> of the flash?
> 
> If so, you would have to *hardware* protect the *entire* flash.

Yes you are right. Moreover the protected blocks (for a same register
value) _could_ be different on an another Macronix device.
For example, larger flash use 4 bits instead of 3 for block protection.

> 
> In this case, a *software* protection mechanism like for NOR flash
> would be a better choice.

Or no protection at all. After all, there is no such mechanism
implemented for u-boot and Linux...

Best regards,

Simon


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] BSS footprint of FAT very high - SPL issues

[Bedia, Vaibhav]

On Tuesday, February 01, 2011 1:48 PM, Aneesh V wrote:
> Dear Wolfgang,
> 
> On Tuesday 01 February 2011 01:25 PM, Wolfgang Denk wrote:
>> Dear Aneesh V,
>> 
>> In message<4d4798e2.3050...@ti.com>  you wrote:
>>> 
>>> I had been working on creating an MMC SPL for OMAP4. OMAP boards
>>> typically support booting from the FAT partition of a removable
>>> SD/MMC card. So, we need to have FAT support in the SPL. But I am
>>> having some difficulties in adding FAT support to SPL.
>>> 
>>> BSS footprint of fat.c is very high. It has three buffers each of
>>> size 64KB. To workaround this problem I have done something like
>>> below(The way x-loader works around this problem today).
>>> CONFIG_SYS_SPL_FAT_BUFFER_BASE is in SDRAM.Is this ok?
>> 
>> Why would that be necessary?  Just put the BSS segment in SDRAM,
>> and everything is fine, isn't it?
> 
> SDRAM is initialized by the SPL. So, bss can not be initialized and
> used until SDRAM initialization is complete. I would prefer to have
> rest of the bss in internal RAM so that it's available as soon as
> we enter C code.   
> 

This approach looks very messy to me. I would rather revisit the init sequence 
to see if things can be fixed there.

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

Re: [U-Boot] BSS footprint of FAT very high - SPL issues

[Bedia, Vaibhav]

On Tuesday, February 01, 2011 1:57 PM, V, Aneesh wrote:
> Hi Vaibhav,
> 
[...]
>> 
>> I guess you will hit a similar issue with the networking related
>> code is used (I am not sure if SPL uses it). That also requires a
>> decent size of bss.  
> 
> Luckily we don't need networking related code in SPL.

It might be required later on :)

> 
>> 
>> Is having a config option to specify the location of bss (like
>> CONFIG_SYS_BSS_ADDR) better/acceptable? 
> 
> I would prefer to have rest of the BSS in internal RAM itself.

Instead of adding workarounds for each driver I think putting BSS in SDRAM as 
pointed out by Wolfgang is better.

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

[U-Boot] [PING] Re: [PATCH V3] update VCMA9 port

[David Müller (ELSOFT AG)]

Hello

Any news?

http://lists.denx.de/pipermail/u-boot/2011-January/085072.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PING] Re: [PATCH V3] update SMDK2410 port

[David Müller (ELSOFT AG)]

Hello

Any news?

http://lists.denx.de/pipermail/u-boot/2011-January/085070.html

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

[U-Boot] [PING] Re: [PATCH] add print_cpuinfo to s3c24x0

[David Müller (ELSOFT AG)]

Hello

Any news?

http://lists.denx.de/pipermail/u-boot/2010-December/083032.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] BSS footprint of FAT very high - SPL issues

[Aneesh V]

Hi Albert,

On Tuesday 01 February 2011 12:41 PM, Albert ARIBAUD wrote:
> Le 01/02/2011 08:04, Albert ARIBAUD a écrit :
>
>> I'd like to make sure I understand the issue. Do these three BSS
>> variables occupy space in the U-Boot binary? If they do, then *that*
>> must be fixed rather than allocating a fixed address for them. In ARM
>> achitectures, the linker file makes sure the BSS is at the end of the
>> image and is not loadable, so the ELF to bin conversion just skips them.
>> Maybe the linker file you're using here does not do this?
>
> Answering myself: after reading Vaibhav's answer, I should amend my
> question aboce. Seems like the issue is the SPL has a BSS in IRAM, or in
> whatever memory it lands in. In that case, there's indeed no fix except
> putting the buffers in DRAM.

Yes, that's right. SPL has code, data and bss in internal RAM.

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

Re: [U-Boot] [PATCH 1/6] mtd: add writebufsize field to mtd_info struct

[Holger Brunck]

Hi Detlev,

Detlev Zundel wrote:
> Hi Stefan,
> 
> do you have any comment on this series?  I delegated the patches to you
> in patchwork already :)  No seriously, the patches look sane and are in
> accordance to what is done in Linux
> 
>> This field will be used to indicate the write buffer size
>> of the MTD device. UBI will set it's minimal I/O unit size
>> (min_io_size) to the indicated write buffer size. By this
>> change we intend to fix failed recovery of UBIFS partitions
>> we currently observe on NOR flash when mounting the partition
>> after unclean unmount.
>>
>> Currently the min_io_size is set to mtd->writesize (which is 1
>> byte for NOR flash). But flash programming is often done from
>> prepared write buffer containing multiple bytes and is performed
>> in one programming operation which could be interrupted by a power
>> cut or a system reset causing corrupted (partially written) areas
>> in a flash sector. Knowing the size of potentially corrupted areas
>> UBIFS scanning and recovery algorithms are able to perform
>> successful recovery.
>>
>> Signed-off-by: Holger Brunck 
> 

as I told in another mail, the min I/O size adaption patch leads to
incompatibilites for the UBIFS and therefore the similar patch in linux kernel
was reverted. But anyway the first five patches in the patch serie are already
part of the mtd layer of the linux kernel.

So the patches 1-5 of this series can also be committed to u-boot. Whats your
opinion?

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

Re: [U-Boot] BSS footprint of FAT very high - SPL issues

[Aneesh V]

Hi Vaibhav,

On Tuesday 01 February 2011 12:22 PM, Bedia, Vaibhav wrote:
> Hi Aneesh,
>
> On Tuesday, February 01, 2011 10:54 AM, Aneesh V wrote:
>> Dear Wolfgang,
>>
>> I had been working on creating an MMC SPL for OMAP4. OMAP boards
>> typically support booting from the FAT partition of a removable
>> SD/MMC card. So, we need to have FAT support in the SPL. But I am
>> having some difficulties in adding FAT support to SPL.
>>
>> BSS footprint of fat.c is very high. It has three buffers each of
>> size 64KB. To workaround this problem I have done something like
>> below(The way x-loader works around this problem today).
>> CONFIG_SYS_SPL_FAT_BUFFER_BASE is in SDRAM.Is this ok?
>>
> [...]
>
> I guess you will hit a similar issue with the networking related code is used 
> (I am not sure if SPL uses it). That also requires a decent size of bss.

Luckily we don't need networking related code in SPL.

>
> Is having a config option to specify the location of bss (like 
> CONFIG_SYS_BSS_ADDR) better/acceptable?

I would prefer to have rest of the BSS in internal RAM itself.

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

Re: [U-Boot] BSS footprint of FAT very high - SPL issues

[Aneesh V]

Dear Wolfgang,

On Tuesday 01 February 2011 01:25 PM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<4d4798e2.3050...@ti.com>  you wrote:
>>
>> I had been working on creating an MMC SPL for OMAP4. OMAP boards
>> typically support booting from the FAT partition of a removable SD/MMC
>> card. So, we need to have FAT support in the SPL. But I am having some
>> difficulties in adding FAT support to SPL.
>>
>> BSS footprint of fat.c is very high. It has three buffers each of size
>> 64KB. To workaround this problem I have done something like below(The
>> way x-loader works around this problem today).
>> CONFIG_SYS_SPL_FAT_BUFFER_BASE is in SDRAM.Is this ok?
>
> Why would that be necessary?  Just put the BSS segment in SDRAM, and
> everything is fine, isn't it?

SDRAM is initialized by the SPL. So, bss can not be initialized and
used until SDRAM initialization is complete. I would prefer to have
rest of the bss in internal RAM so that it's available as soon as we
enter C code.

>
>> Also, I was wondering why we need 3 such scratch buffers in this
>> implementation. I do not understand this code. But I was wondering if we
>> could work with just one 64K buffer?
>
> I have no idea.   I am not familiar with that code either.

Probably I will give it a try once I solve some other issues I am
facing in getting FAT to work.

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

Re: [U-Boot] calling pci_init before relocation?

[Heiko Schocher]

Hello Michael,

Michael Schwingen wrote:
> On 01/31/2011 09:45 AM, Heiko Schocher wrote:
>>
>> I think, on arm plattforms we should move the pci_init as it is
>> done on powerpc plattforms, to board_init_r. It seems to me, that
>> this is a leftover from introducing relocation to arm. I also just
>> could think of using a "PCI console" before relocation... and if
>> I looked right, this is not used on any arm plattform ...
> Fine. I'll include that change with the other changes needed to get PCI
> up again on IXP425.

Ok, thanks!

bye,
Heiko
-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] BSS footprint of FAT very high - SPL issues

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <4d47b20b.5040...@free.fr> you wrote:
> 
> > variables occupy space in the U-Boot binary? If they do, then *that*
> > must be fixed rather than allocating a fixed address for them. In ARM
> > achitectures, the linker file makes sure the BSS is at the end of the
> > image and is not loadable, so the ELF to bin conversion just skips them.
> > Maybe the linker file you're using here does not do this?
>
> Answering myself: after reading Vaibhav's answer, I should amend my
> question aboce. Seems like the issue is the SPL has a BSS in IRAM, or in
> whatever memory it lands in. In that case, there's indeed no fix except
> putting the buffers in DRAM.

well, there _is_ an obvious fix: put the BSS inS DRAM where we have
sufficient room for it.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The idea of male and female are universal constants.
-- Kirk, "Metamorphosis", stardate 3219.8
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] calling pci_init before relocation?

[Michael Schwingen]

On 01/31/2011 09:45 AM, Heiko Schocher wrote:
>
> I think, on arm plattforms we should move the pci_init as it is
> done on powerpc plattforms, to board_init_r. It seems to me, that
> this is a leftover from introducing relocation to arm. I also just
> could think of using a "PCI console" before relocation... and if
> I looked right, this is not used on any arm plattform ...
Fine. I'll include that change with the other changes needed to get PCI 
up again on IXP425.

cu
Michael

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