Re: [U-Boot] [PATCH] Davinci: Utility for MMC boot

[Wolfgang Denk]

Dear "Lad, Prabhakar",

In message <4665bc9cc4253445b213a010e6dc7b35cdd...@dbde01.ent.ti.com> you wrote:
> 
> > > This is a Linux command line tool specific to TI's Davinci platforms, f> 
> > > or
> > > flashing UBL (User Boot Loader), u-boot and u-boot Environment in the M> 
> > > MC/SD
> > > card. This MMC/SD card can be used for booting Davinci platforms that s> 
> > > upports
> > > MMC/SD boot option.
> > 
> > Do we also build UBL as part of the U-Boot source tree?
> > 
>   No, we do not build UBL as part of U-Boot.

Why not?

I assume by adding this tool to the U-Boot tree you want to provide a
single, self-contained build system for the boot loader on such
boards.  But this doesn;t work if we are not also building the UBL
image.

> > If not, then why is this tool supposed to be part of the U-Boot tree?
> > 
> > How does this work with a SPL?
> > 
>   This command has options to flash u-boot images to MMC/SD card. When SPL
>   is supported, this command can be used to flash the single SPL image to
>   MMC/SD card.

How exactly does this work?  You do not document this use case.

> > > +e. Using the 'uflash' utility, place the UBL and u-uoot binaries on th> 
> > > e MMC
> > > +   card. Copy the u-boot.bin to tools/uflash directory
> > 
> > Why is this copy operation needed?
> > 
>   This copy is not needed as long as the path to u-boot.bin is specified
>   Correctly in command line.
>
> > And where is the UBL binary coming from?
> > 
>   UBL binary is optional. We can flash only u-boot.bin.

I did not understand this from your documentation.  Can you please add
this information?

> > This looks like U-Boot environment settings?  Why are these in the
> > tools/uflash/ directory?  I would expect these are board specific?
> > For example, what in case a board uses a different baud rate?
> > 
> > Is this really supposed to be board independent?  It doesn't look
> > so...
> > 
>  I agree with this. Can you think of any other scenario?

I have no idea what you are trying to do here.  The envrionment
settings are inherently part of U-Boot, and I don't understand why you
are adding another set of settings here.

> > > + if (!strcmp(platform, "DM3XX")) {
> > > + if (!uboot_load_address)
> > > + uboot_load_address = DM3XX_UBOOT_LOAD_ADDRESS;
> > > + if (!uboot_entry_point)
> > > + uboot_entry_point = DM3XX_UBOOT_LOAD_ADDRESS;
> > > + }
> > > +
> > > + if (!strcmp(platform, "OMAPL138")) {
> > > + if (!uboot_load_address)
> > > + uboot_load_address = DA850_UBOOT_LOAD_ADDRESS;
> > > + if (!uboot_entry_point)
> > > + uboot_entry_point = DA850_UBOOT_LOAD_ADDRESS;
> > > + }
> > 
> > So this is actually all hardwired for a few very specific board
> > configurations, right?
> > 
>   Yes.

Sorry, but this doesn't make sense then.  It doesn't scale.  It should
be possible to use such a tool with any such board - and without
changing the code of the tool.  Instead of gard-coding all this
information, you should make the tool data driven, so that it's
sufficient to provide respective configuration data - actually I think
all this information is already present in the existing header files,
especially the board configuration file. So why not just reuse this
information?

> > You don't even print a warning or error message in case of read
> > errors?  Ouch...
> > 
>   Ok , I'll fix it in V2 version.

Please check error checking / handling for all system calls and calls
to library functions.

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 have often regretted my speech, never my silence.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: rmobile: kzm9g: Adjust hardware setting in lowlevel_init.S

[Tetsuyuki Kobayashi]

Hi Albert

(2012/06/27 6:22), Albert ARIBAUD wrote:


On Tue, 26 Jun 2012 11:30:16 +0900, Tetsuyuki Kobayashi
  wrote:


This patch depends on
  Nobuhiro Iwamatsu's arm: rmobile: Add supoprt for KMC KZM-A9-GT board
  Tetsuyuki Kobayashi's arm: rmobile: kzm9g: Modify sdram area


Seems like a series to me -- you should post it as such, with patches
numbered 1/N, 2/N etc. Should be easy as you probably already have them
as a series of commits above master; git format-patch should generate
the mails alright.


OK. I am studying git format-patch and git send-email.

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

Re: [U-Boot] [PATCH 1/3] microblaze: remove wrong define CONFIG_SYS_FLASH_PROTECTION

[Michal Simek]

On 06/27/2012 12:28 AM, Stephan Linz wrote:

CONFIG_SYS_FLASH_PROTECTION will defined twice. The second one
is outside the flash configuration context and we can remove
it safely.

Signed-off-by: Stephan Linz
---
  include/configs/microblaze-generic.h |2 --
  1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/include/configs/microblaze-generic.h 
b/include/configs/microblaze-generic.h
index 295d123..5f16820 100644
--- a/include/configs/microblaze-generic.h
+++ b/include/configs/microblaze-generic.h
@@ -200,8 +200,6 @@
  # define CONFIG_ENV_IS_NOWHERE1
  # define CONFIG_ENV_SIZE  0x1000
  # define CONFIG_ENV_ADDR  (CONFIG_SYS_MONITOR_BASE - CONFIG_ENV_SIZE)
-/* hardware flash protection */
-# define CONFIG_SYS_FLASH_PROTECTION
  #endif /* !FLASH */

  /* system ace */



Applied all three patches to microblaze custodian repo with minor cleanup.

Thanks,
Michal


--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Atmel : usb : add EHCI driver for Atmel SoC

[Andreas Bießmann]

Dear all,

On 25.06.12 15:07, Marek Vasut wrote:
> Dear Bo Shen,
> 
>> Hi Marek,
>>
>> On 6/25/2012 10:57, Marek Vasut wrote:
>>> Dear Bo Shen,
>>>
 Hi Marek,

 On 6/21/2012 18:17, Marek Vasut wrote:
> Dear Bo Shen,
>
>> Some Atmel SoC support USB EHCI, add the EHCI driver to support it.
>>
>> To enable the USB EHCI, add the following configuration options into
>> board relative configuration file and remove USB OHCI options.
>>
>> #define CONFIG_USB_EHCI
>> #define CONFIG_USB_EHCI_ATMEL
>> #define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 2
>>
>> Signed-off-by: Bo Shen
>> ---
>>
>> [...]
>>
> btw do you have some user for this code?

 The at91sam9m10g45ek now uses OHCI, if needed, it can use EHCI. New
 coming boards will use EHCI.
>>>
>>> When do you see such board appearing please?
>>
>>The at91sam9m10g45ek board has existed in mainline. As to AT91
>> maintainer has no response, so I just send the EHCI driver separately.
> 
> I think there're some issues with the at91 maintainer. Ccing Andreas, maybe 
> he 
> can actually start picking up the atmel patches?
> 

Sorry for being late, I read the list not really daily these days.

AFAIR Reinhard gave up somewhere end of last year, in fact we currently
have no at91 maintainer.
I'm willing to step into at least for a while. My main aim is to get the
latest Atmel patches into mainline for 2012.07, if Albert is willing to
pull them (well less than 20 days left, and some of the patches where
slightly after close of MW for 2012.07).

As far as I can see these patches are left:

Bo Shen (new board):
http://patchwork.ozlabs.org/patch/160581/
http://patchwork.ozlabs.org/patch/167290/

Alexandre Belloni (change address for dataflash; first submission in
February!):
http://patchwork.ozlabs.org/patch/154242/

Jens Scharsig (fixes):
http://patchwork.ozlabs.org/patch/147550/
http://patchwork.ozlabs.org/patch/147534/

Vladimir Zapolskiy (new board):
http://patchwork.ozlabs.org/patch/135526/

Wolfgang and Albert, how do you think about?

best regards

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

[U-Boot] ARM CONFIG_OF_CONTROL status

[Michal Simek]

Hi,

can you please update me about current state of CONFIG_OF_CONTROL for ARM?
Are there any other archs/boards which will use this option?
Or any other git repo out of mainline u-boot?

Has someone tried to look for devices based on compatible property?
I see that in usb driver it is based on aliases which is not the best solution.

Thanks,
Michal

--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH][v3] powerpc/CoreNet: add tool to support pbl image build.

[Xie Shaohui-B21989]

Hello, Andy,

Do you have any comment for this patch, if no could you help apply it?


Best Regards, 
Shaohui Xie 


>-Original Message-
>From: Xie Shaohui-B21989
>Sent: Tuesday, June 12, 2012 4:11 PM
>To: u-boot@lists.denx.de
>Cc: Xie Shaohui-B21989
>Subject: [PATCH][v3] powerpc/CoreNet: add tool to support pbl image build.
>
>Provides a tool to build boot Image for PBL(Pre boot loader) which is used
>on Freescale CoreNet SoCs, PBL can be used to load some instructions
>and/or data for pre-initialization. The default output image is u-boot.pbl,
>for more details please refer to doc/README.pblimage.
>
>Signed-off-by: Shaohui Xie 
>---
>changes for v3:
>1. dump config.mk, aligned to comment of Wolfgang Denk; 2. split one
>configuration file to two, one is for RCW, one is for PBI commands, add
>second entry in mkimage for second configuration file, aligned to comment
>of Wood Scott; 3. refined the README.pblimage;
>
> Makefile   |6 +
> board/freescale/corenet_ds/pbi.cfg |   51 ++
> board/freescale/corenet_ds/rcw.cfg |   32 
> common/image.c |1 +
> doc/README.pblimage|  114 +
> include/configs/corenet_ds.h   |2 +
> include/image.h|1 +
> tools/Makefile |2 +
> tools/mkimage.c|   15 ++
> tools/mkimage.h|3 +
> tools/pblimage.c   |  328
>
> tools/pblimage.h   |   36 
> 12 files changed, 591 insertions(+), 0 deletions(-)  create mode 100644
>board/freescale/corenet_ds/pbi.cfg
> create mode 100644 board/freescale/corenet_ds/rcw.cfg
> create mode 100644 doc/README.pblimage
> create mode 100644 tools/pblimage.c
> create mode 100644 tools/pblimage.h
>


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

Re: [U-Boot] [PATCH] arm: enable unaligned access on ARMv7

[Tetsuyuki Kobayashi]

Hi Rob and all,

>>>
>>> Am Dienstag, den 05.06.2012, 12:42 -0600 schrieb Stephen Warren:
 On 06/05/2012 11:47 AM, Lucas Stach wrote:
> Recent toolchains default to using the hardware feature for
> unaligned access on ARM v7, rather than doing the software
> fallback. According to ARM this is safe as all v7 implementations
> have to support this feature.
> (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0471c/BABJFFAE.html)
>
> To avoid CPU hangs when doing unaligned memory access, we have to
> turn off alignment checking in our CPU initialisation code.
> (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0491c/CIHCGCFD.html)

 Does this behavior change trickle down to Linux/... too, or would
 an OS completely re-initialize this state, and hence not be
 affected?

>>>
>>> Linux in particular does reinitialize this state and I expect any
>>> reasonable OS to do so.
>>
>> Then what is the point of enabling it on U-Boot? Does it fix some issue
>> whereby some mis-aligned piece of data cannot be properly aligned?
>>
> 
> This is a new optimization feature in gcc 4.7 (and backported to some
> 4.6 versions like the ubuntu 12.04 arm cross compiler (4.6.3)):
> 
> http://lists.linaro.org/pipermail/linaro-dev/2012-June/012360.html
> 
> http://seabright.co.nz/2012/06/11/kernel-not-booting-with-linaro-gcc/
> 
> If you don't want to enable unaligned accesses, then
> "-mno-unaligned-access" needs to be added.
> 

I verified it. Option "-mno-unaligned-access" works good.


include/mtd/cfi_flash.h

/* CFI standard query structure */
struct cfi_qry {
u8  qry[3];
u16 p_id;  <-- unaligned!
...
} __attribute__((packed));


$ ${CROSS_COMPILE}gcc --version
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.6.2 20110921 
(release) [ARM/embedded-4_6-branch revision 182083]
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

=
Compiled without --mno-unaligned-access
$ ${CROSS_COMPILE}objdump -d -S u-boot 

info->vendor = le16_to_cpu(qry.p_id);
cc88:   e3003a1cmovwr3, #2588   ; 0xa1c
cc8c:   e1dd11bbldrhr1, [sp, #27]  <-- this is unaligned 
access
cc90:   ...
cc94:   e18410b3strhr1, [r4, r3]


=
Compiled with --mno-unaligned-access
$ ${CROSS_COMPILE}objdump -d -S u-boot 


info->vendor = le16_to_cpu(qry.p_id);
cce8:   e5dd101cldrbr1, [sp, #28]  <--
ccec:   e5dd301bldrbr3, [sp, #27]  <-- separated 2 byte 
accesses
ccf0:   ...
ccf4:   e1831401orr r1, r3, r1, lsl #8
ccf8:   e3003a1cmovwr3, #2588   ; 0xa1c
ccfc:   e18410b3strhr1, [r4, r3]

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

[U-Boot] Is it possible to boot the U-boot from the another U-boot from the flash area

[Ishwar Saunshi]

Hi All,

I am really curiuos to see if U-boot can boot another version or another
Uboot burnt in flash ?
Its like having 2 images of U-boot which can boot each other if it is
possible can any one of you hint me how I can achive this. I tried to
relocate the Uboot and burned on to the flash in 2 different loacation
however when I try to do "go " it ends up in TLB
error in early stage of flash execution.


Thanks for the Help.
Ish
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] fs/ext2/ext2fs.c: fix warning

[Andreas Bießmann]

This patch fixes following warning:
---8<---
ext2fs.c: In function 'ext2fs_read_file':
ext2fs.c:458:19: warning: 'blocknxt' may be used uninitialized in this function 
[-Wuninitialized]
--->8---

The warning was introduced in 436da3cd233e7166b5ce9293dbd28092cf37bcc9.

Signed-off-by: Andreas Bießmann 
cc: Jason Cooper 
cc: Eric Nelson 
cc: Thierry Reding 
---
 fs/ext2/ext2fs.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ext2/ext2fs.c b/fs/ext2/ext2fs.c
index f1fce48..40b6e6f 100644
--- a/fs/ext2/ext2fs.c
+++ b/fs/ext2/ext2fs.c
@@ -440,7 +440,7 @@ int ext2fs_read_file
/* grab middle blocks in one go */
if (i != pos / blocksize && i != blockcnt - 1 && blockcnt > 3) {
int oldblk = blknr;
-   int blocknxt;
+   int blocknxt = blknr;
while (i < blockcnt - 1) {
blocknxt = ext2fs_read_block(node, i + 1);
if (blocknxt == (oldblk + 1)) {
-- 
1.7.10

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

Re: [U-Boot] [PATCH] fs/ext2/ext2fs.c: fix warning

[Thierry Reding]

On Wed, Jun 27, 2012 at 01:47:51PM +0200, Andreas Bießmann wrote:
> This patch fixes following warning:
> ---8<---
> ext2fs.c: In function 'ext2fs_read_file':
> ext2fs.c:458:19: warning: 'blocknxt' may be used uninitialized in this 
> function [-Wuninitialized]
> --->8---
> 
> The warning was introduced in 436da3cd233e7166b5ce9293dbd28092cf37bcc9.
> 
> Signed-off-by: Andreas Bießmann 
> cc: Jason Cooper 
> cc: Eric Nelson 
> cc: Thierry Reding 
> ---
>  fs/ext2/ext2fs.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/ext2/ext2fs.c b/fs/ext2/ext2fs.c
> index f1fce48..40b6e6f 100644
> --- a/fs/ext2/ext2fs.c
> +++ b/fs/ext2/ext2fs.c
> @@ -440,7 +440,7 @@ int ext2fs_read_file
>   /* grab middle blocks in one go */
>   if (i != pos / blocksize && i != blockcnt - 1 && blockcnt > 3) {
>   int oldblk = blknr;
> - int blocknxt;
> + int blocknxt = blknr;
>   while (i < blockcnt - 1) {
>   blocknxt = ext2fs_read_block(node, i + 1);
>   if (blocknxt == (oldblk + 1)) {

This doesn't look quite right. The warning should go away as well if you
change the "i != blockcnt - 1" to "i < blockcnt - 1" in the condition
above. I think that'd be more appropriate, but perhaps Jason is better
qualified to comment.

Thierry


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

[U-Boot] [PATCH 2/2 V2] Kirkwood: Add support for Ka-Ro TK71

[Marek Vasut]

Signed-off-by: Marek Vasut 
Cc: Prafulla Wadaskar 
Cc: Wolfgang Denk 
---
 board/karo/tk71/Makefile |   45 +++
 board/karo/tk71/kwbimage.cfg |  174 ++
 board/karo/tk71/tk71.c   |  174 ++
 boards.cfg   |1 +
 include/configs/tk71.h   |  130 +++
 5 files changed, 524 insertions(+)
 create mode 100644 board/karo/tk71/Makefile
 create mode 100644 board/karo/tk71/kwbimage.cfg
 create mode 100644 board/karo/tk71/tk71.c
 create mode 100644 include/configs/tk71.h

V2: Enable hush parser

diff --git a/board/karo/tk71/Makefile b/board/karo/tk71/Makefile
new file mode 100644
index 000..934e391
--- /dev/null
+++ b/board/karo/tk71/Makefile
@@ -0,0 +1,45 @@
+#
+# Copyright (C) 2012 Marek Vasut 
+# on behalf of DENX Software Engineering GmbH
+#
+#
+# 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., 51 Franklin Street, Fifth Floor, Boston,
+# MA 02110-1301 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS  := tk71.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+   $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/karo/tk71/kwbimage.cfg b/board/karo/tk71/kwbimage.cfg
new file mode 100644
index 000..0166826
--- /dev/null
+++ b/board/karo/tk71/kwbimage.cfg
@@ -0,0 +1,174 @@
+#
+# (C) Copyright 2009
+# Marvell Semiconductor 
+# Written-by: Prafulla Wadaskar 
+#
+# adopted to TK71 by
+# Nils Faerber 
+#
+# 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., 51 Franklin Street, Fifth Floor, Boston,
+# MA 02110-1301 USA
+#
+# Refer docs/README.kwimage for more details about how-to configure
+# and create kirkwood boot image
+#
+
+# Boot Media configurations
+BOOT_FROM  nand
+NAND_ECC_MODE  default
+NAND_PAGE_SIZE 0x0800
+
+# SOC registers configuration using bootrom header extension
+# Maximum KWBIMAGE_MAX_CONFIG configurations allowed
+
+# Configure RGMII-0 interface pad voltage to 1.8V
+DATA 0xFFD100e0 0x1b1b1b9b
+
+#Dram initalization for SINGLE x16 CL=5 @ 400MHz
+DATA 0xFFD01400 0x43000c30 # DDR Configuration register
+# bit13-0:  0xc30 (3120 DDR2 clks refresh rate)
+# bit23-14: zero
+# bit24: 1= enable exit self refresh mode on DDR access
+# bit25: 1 required
+# bit29-26: zero
+# bit31-30: 01
+
+DATA 0xFFD01404 0x36543000 # DDR Controller Control Low
+# bit 4:0=addr/cmd in smame cycle
+# bit 5:0=clk is driven during self refresh, we don't care for APX
+# bit 6:0=use recommended falling edge of clk for addr/cmd
+# bit14:0=input buffer always powered up
+# bit18:1=cpu lock transaction enabled
+# bit23-20: 5=recommended value for CL=5 and STARTBURST_DEL disabled bit31=0
+# bit27-24: 7= CL+2, STARTBURST sample stages, for freqs 400MHz, unbuffered 
DIMM
+# bit30-28: 3 required
+# bit31:0=no additional STARTBURST delay
+
+DATA 0xFFD01408 0x1101355b # DDR Timing (Low) (active cycles value +1)
+# bit3-0:   TRAS lsbs
+# bit7-4:   TRCD
+# bit11- 8: TRP
+# bit15-12: TWR
+# bit19-16: TWTR
+# bit20:TRAS msb
+# bit23-21: 0x0
+# bit27-24: TRRD
+# bit31-28: TRTP
+
+DATA 0xFFD0140C 0x0034 #  DDR Timing (High)
+# bit6-0:   TRFC
+# bit8-7:   TR2R
+# bit10-9:  TR2W
+# bit12-11: TW2W
+# bit31-13: z

Re: [U-Boot] [PATCH] i.MX28: bug fixes in PMU configuration code

[Marek Vasut]

Dear Stathis Voukelatos,

> Fixed some typos in the i.MX28 PMU code that sets up the VDDD
> and VDDIO power rails. In addition the VDDD and VDDIO brownout
> offset values should be divided by a step size before being
> programmed to the corresponding registers.
> 
> Signed-off-by: Stathis Voukelatos 
> Cc: Stefano Babic 
> Cc: Marek Vasut 

Will test it ASAP. I should be getting new board by next week, so I'll test-
drive it on that one too.

Thanks for finding those!

> ---
>  arch/arm/cpu/arm926ejs/mx28/spl_power_init.c |   12 ++--
>  1 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
> b/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c index 4b09b0c..cc71af8
> 100644
> --- a/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
> +++ b/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
> @@ -716,7 +716,7 @@ int mx28_get_vddio_power_source_off(void)
> tmp = readl(&power_regs->hw_power_vddioctrl);
> if (tmp & POWER_VDDIOCTRL_DISABLE_FET) {
> if ((tmp & POWER_VDDIOCTRL_LINREG_OFFSET_MASK) ==
> -   POWER_VDDDCTRL_LINREG_OFFSET_0STEPS) {
> +   POWER_VDDIOCTRL_LINREG_OFFSET_0STEPS) {
> return 1;
> }
> }
> @@ -724,7 +724,7 @@ int mx28_get_vddio_power_source_off(void)
> if (!(readl(&power_regs->hw_power_5vctrl) &
> POWER_5VCTRL_ENABLE_DCDC)) {
> if ((tmp & POWER_VDDIOCTRL_LINREG_OFFSET_MASK) ==
> -   POWER_VDDDCTRL_LINREG_OFFSET_0STEPS) {
> +   POWER_VDDIOCTRL_LINREG_OFFSET_0STEPS) {
> return 1;
> }
> }
> @@ -772,7 +772,7 @@ void mx28_power_set_vddio(uint32_t new_target, uint32_t
> new_brownout) uint32_t cur_target, diff, bo_int = 0;
> uint32_t powered_by_linreg = 0;
> 
> -   new_brownout = new_target - new_brownout;
> +   new_brownout = (new_target - new_brownout + 25) / 50;
> 
> cur_target = readl(&power_regs->hw_power_vddioctrl);
> cur_target &= POWER_VDDIOCTRL_TRG_MASK;
> @@ -858,8 +858,8 @@ void mx28_power_set_vddio(uint32_t new_target, uint32_t
> new_brownout) }
> 
> clrsetbits_le32(&power_regs->hw_power_vddioctrl,
> -   POWER_VDDDCTRL_BO_OFFSET_MASK,
> -   new_brownout << POWER_VDDDCTRL_BO_OFFSET_OFFSET);
> +   POWER_VDDIOCTRL_BO_OFFSET_MASK,
> +   new_brownout << POWER_VDDIOCTRL_BO_OFFSET_OFFSET);
>  }
> 
>  void mx28_power_set_vddd(uint32_t new_target, uint32_t new_brownout)
> @@ -869,7 +869,7 @@ void mx28_power_set_vddd(uint32_t new_target, uint32_t
> new_brownout) uint32_t cur_target, diff, bo_int = 0;
> uint32_t powered_by_linreg = 0;
> 
> -   new_brownout = new_target - new_brownout;
> +   new_brownout = (new_target - new_brownout + 12) / 25;
> 
> cur_target = readl(&power_regs->hw_power_vdddctrl);
> cur_target &= POWER_VDDDCTRL_TRG_MASK;

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

[U-Boot] [PATCH] i.MX28: bug fixes in PMU configuration code

[Stathis Voukelatos]

Fixed some typos in the i.MX28 PMU code that sets up the VDDD
and VDDIO power rails. In addition the VDDD and VDDIO brownout 
offset values should be divided by a step size before being 
programmed to the corresponding registers.

Signed-off-by: Stathis Voukelatos 
Cc: Stefano Babic 
Cc: Marek Vasut 
---
 arch/arm/cpu/arm926ejs/mx28/spl_power_init.c |   12 ++--
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c 
b/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
index 4b09b0c..cc71af8 100644
--- a/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
+++ b/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
@@ -716,7 +716,7 @@ int mx28_get_vddio_power_source_off(void)
tmp = readl(&power_regs->hw_power_vddioctrl);
if (tmp & POWER_VDDIOCTRL_DISABLE_FET) {
if ((tmp & POWER_VDDIOCTRL_LINREG_OFFSET_MASK) ==
-   POWER_VDDDCTRL_LINREG_OFFSET_0STEPS) {
+   POWER_VDDIOCTRL_LINREG_OFFSET_0STEPS) {
return 1;
}
}
@@ -724,7 +724,7 @@ int mx28_get_vddio_power_source_off(void)
if (!(readl(&power_regs->hw_power_5vctrl) &
POWER_5VCTRL_ENABLE_DCDC)) {
if ((tmp & POWER_VDDIOCTRL_LINREG_OFFSET_MASK) ==
-   POWER_VDDDCTRL_LINREG_OFFSET_0STEPS) {
+   POWER_VDDIOCTRL_LINREG_OFFSET_0STEPS) {
return 1;
}
}
@@ -772,7 +772,7 @@ void mx28_power_set_vddio(uint32_t new_target, uint32_t 
new_brownout)
uint32_t cur_target, diff, bo_int = 0;
uint32_t powered_by_linreg = 0;
 
-   new_brownout = new_target - new_brownout;
+   new_brownout = (new_target - new_brownout + 25) / 50;
 
cur_target = readl(&power_regs->hw_power_vddioctrl);
cur_target &= POWER_VDDIOCTRL_TRG_MASK;
@@ -858,8 +858,8 @@ void mx28_power_set_vddio(uint32_t new_target, uint32_t 
new_brownout)
}
 
clrsetbits_le32(&power_regs->hw_power_vddioctrl,
-   POWER_VDDDCTRL_BO_OFFSET_MASK,
-   new_brownout << POWER_VDDDCTRL_BO_OFFSET_OFFSET);
+   POWER_VDDIOCTRL_BO_OFFSET_MASK,
+   new_brownout << POWER_VDDIOCTRL_BO_OFFSET_OFFSET);
 }
 
 void mx28_power_set_vddd(uint32_t new_target, uint32_t new_brownout)
@@ -869,7 +869,7 @@ void mx28_power_set_vddd(uint32_t new_target, uint32_t 
new_brownout)
uint32_t cur_target, diff, bo_int = 0;
uint32_t powered_by_linreg = 0;
 
-   new_brownout = new_target - new_brownout;
+   new_brownout = (new_target - new_brownout + 12) / 25;
 
cur_target = readl(&power_regs->hw_power_vdddctrl);
cur_target &= POWER_VDDDCTRL_TRG_MASK;
-- 
1.7.2.5

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

[U-Boot] [PATCH] [nand]: Hack to support 4k page in fsl_elbc_nand

[Rafael Beims]

Freescale FCM controller has a 2K size limitation of buffer RAM. In order
to support the Nand flash chip with pagesize larger than 2K bytes,
we read/write 2k data repeatedly by issuing FIR_OP_RB/FIR_OP_WB and save
them to a large buffer.
Because of this, the in flash layout of the oob is different from the
default for 4096kiB page sizes. Therefore, we need to migrate the
factory bad block markers from the original position to the new layout.

Signed-off-by: Shengzhou Liu 
Signed-off-by: Liu Shuo 
Signed-off-by: Rafael Beims 
---
 drivers/mtd/nand/fsl_elbc_nand.c |  445 +++---
 1 files changed, 417 insertions(+), 28 deletions(-)

diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 9076ad4..7393266 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -76,15 +76,17 @@ struct fsl_elbc_ctrl {

/* device info */
fsl_lbc_t *regs;
-   u8 __iomem *addr;/* Address of assigned FCM buffer*/
-   unsigned int page;   /* Last page written to / read from  */
-   unsigned int read_bytes; /* Number of bytes read during command   */
-   unsigned int column; /* Saved column from SEQIN   */
-   unsigned int index;  /* Pointer to next byte to 'read'*/
-   unsigned int status; /* status read from LTESR after last op  */
-   unsigned int mdr;/* UPM/FCM Data Register value   */
-   unsigned int use_mdr;/* Non zero if the MDR is to be set  */
-   unsigned int oob;/* Non zero if operating on OOB data */
+   u8 __iomem *addr;   /* Address of assigned FCM buffer   */
+   unsigned int page;  /* Last page written to / read from */
+   unsigned int read_bytes;/* Number of bytes read during command  */
+   unsigned int column;/* Saved column from SEQIN  */
+   unsigned int index; /* Pointer to next byte to 'read'   */
+   unsigned int status;/* status read from LTESR after last op */
+   unsigned int mdr;   /* UPM/FCM Data Register value  */
+   unsigned int use_mdr;   /* Non zero if the MDR is to be set */
+   unsigned int oob;   /* Non zero if operating on OOB data*/
+   char *buffer;   /* Just used when pagesize is greater   */
+   /* than FCM RAM 2K limitation   */
 };

 /* These map to the positions used by the FCM hardware ECC generator */
@@ -131,6 +133,15 @@ static struct nand_bbt_descr largepage_memorybased = {
.pattern = scan_ff_pattern,
 };

+static u8 migrated_pattern[] = { 0xde, 0xad, 0xde, 0xad };
+static struct nand_bbt_descr largepage_migrated = {
+   .options = 0,
+   .offs = 1,
+   .len = 4,
+   .maxblocks = 3,
+   .pattern = migrated_pattern,
+};
+
 /*
  * ELBC may use HW ECC, so that OOB offsets, that NAND core uses for bbt,
  * interfere with ECC positions, that's why we implement our own descriptors.
@@ -159,6 +170,35 @@ static struct nand_bbt_descr bbt_mirror_descr = {
.pattern = mirror_pattern,
 };

+static void io_to_buffer(struct mtd_info *mtd, int subpage, int oob)
+{
+   struct nand_chip *chip = mtd->priv;
+   struct fsl_elbc_mtd *priv = chip->priv;
+   struct fsl_elbc_ctrl *ctrl = priv->ctrl;
+   void *src, *dst;
+   int len = oob ? 64 : 2048;
+
+   /* for emulating 4096+ bytes NAND using 2048-byte FCM RAM */
+   dst = ctrl->buffer + (oob ? mtd->writesize : 0) + subpage * len;
+   src = ctrl->addr + (oob ? 2048 : 0);
+   memcpy_fromio(dst, src, len);
+}
+
+static void buffer_to_io(struct mtd_info *mtd, int subpage, int oob)
+{
+   struct nand_chip *chip = mtd->priv;
+   struct fsl_elbc_mtd *priv = chip->priv;
+   struct fsl_elbc_ctrl *ctrl = priv->ctrl;
+   void *src, *dst;
+   int len = oob ? 64 : 2048;
+
+   src = ctrl->buffer + (oob ? mtd->writesize : 0) + subpage * len;
+   dst = ctrl->addr + (oob ? 2048 : 0);
+   memcpy_toio(dst, src, len);
+   /* See the in_8() in fsl_elbc_write_buf() */
+   in_8(ctrl->addr);
+}
+
 /*=*/

 /*
@@ -194,7 +234,7 @@ static void set_addr(struct mtd_info *mtd, int
column, int page_addr, int oob)

/* for OOB data point to the second half of the buffer */
if (oob)
-   ctrl->index += priv->page_size ? 2048 : 512;
+   ctrl->index += mtd->writesize;

vdbg("set_addr: bank=%d, ctrl->addr=0x%p (0x%p), "
 "index %x, pes %d ps %d\n",
@@ -256,13 +296,14 @@ static int fsl_elbc_run_command(struct mtd_info *mtd)
return ctrl->status == LTESR_CC ? 0 : -EIO;
 }

-static void fsl_elbc_do_read(struct nand_chip *chip, int oob)
+static void fsl_elbc_do_read(struct mtd_info *mtd, int oob)
 {
+   struct nand_chip *chip = mtd->priv;
struct fsl_elb

Re: [U-Boot] [PATCH] mx28evk: Fix boot by adjusting HW_DRAM_CTL29 register

[Fabio Estevam]

Hi Stefano,

On Tue, Jun 19, 2012 at 6:12 PM, Marek Vasut  wrote:
> Dear Fabio Estevam,
>
>> commit acc4959fc1 (Revert "i.MX28: Enable additional DRAM address bits")
>> broke mx28evk boot.
>>
>> Fix it by properly adjusting the HW_DRAM_CTL29 register value.
>>
>> Suggested-by: Marek Vasut 
>> Signed-off-by: Fabio Estevam 
>> ---
>>  board/freescale/mx28evk/iomux.c |   14 ++
>>  1 files changed, 14 insertions(+), 0 deletions(-)
>>
>> diff --git a/board/freescale/mx28evk/iomux.c
>
> Uh, why isn't this file called splboot.c?
>
> But
> Acked-by: Marek Vasut 

Could this one be applied?

mx28evk does not boot without this patch.

Thanks,

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

[U-Boot] [PATCH 0/1] fsl_elbc support for 4k devices and factory badblock migration

[Rafael Beims]

This is my implementation of the factory badblock migration process for
the fsl_elbc driver using the hack to support nand devices with page
sizes bigger than 2048k.
The migrated pattern is in "test mode". I really don't know what is the
convention for something like this, and would like to hear suggestions
of what this pattern should be.
I would really appreciate any feedback related to the patch.


Rafael Beims (1):
  [nand]: Hack to support 4k page in fsl_elbc_nand

 drivers/mtd/nand/fsl_elbc_nand.c |  445 +++---
 1 files changed, 417 insertions(+), 28 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Atmel : usb : add EHCI driver for Atmel SoC

[Wolfgang Denk]

Dear Andreas,

In message <4feacd7e.8000...@gmail.com> you wrote:
> 
> AFAIR Reinhard gave up somewhere end of last year, in fact we currently
> have no at91 maintainer.
> I'm willing to step into at least for a while. My main aim is to get the
> latest Atmel patches into mainline for 2012.07, if Albert is willing to
> pull them (well less than 20 days left, and some of the patches where
> slightly after close of MW for 2012.07).
...
> Wolfgang and Albert, how do you think about?

I am really glad you are volunteering - you close a pretty painful
gap.  Thanks a lot for your work in advance, it is highly appreciated.


Your SSH key has been installed for both u-boot-atmel and u-boot-at91
so you should be able to start working.

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 fractal is by definition a set for which the Hausdorff Besicovitch
dimension strictly exceeds the topological dimension."
- Mandelbrot, _The Fractal Geometry of Nature_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: AT91: add at91sam9x5ek board support

[Andreas Bießmann]

On 22.05.2012 12:06, Bo Shen wrote:
> Add at91sam9x5ek board support.
>   support AT91SAM9G15, G25, G35, X25, X35 SoC
> 
> Signed-off-by: Bo Shen 

In general:
---8<---
total: 14 errors, 11 warnings, 1148 lines checked

NOTE: Ignored message types: COMPLEX_MACRO CONSIDER_KSTRTO MINMAX
MULTISTATEMENT_MACRO_USE_DO_WHILE

/tmp/[PATCH] arm: AT91: add at91sam9x5ek board support.eml has style
problems, please review.
--->8---

please fix these.

> ---
>  MAINTAINERS|3 +
>  arch/arm/cpu/arm926ejs/at91/Makefile   |1 +
>  arch/arm/cpu/arm926ejs/at91/at91sam9x5_devices.c   |  223 ++
>  arch/arm/cpu/arm926ejs/at91/clock.c|7 +-
>  arch/arm/include/asm/arch-at91/at91sam9_matrix.h   |2 +
>  arch/arm/include/asm/arch-at91/at91sam9x5.h|  172 +++
>  arch/arm/include/asm/arch-at91/at91sam9x5_matrix.h |   91 ++
>  arch/arm/include/asm/arch-at91/hardware.h  |2 +
>  board/atmel/at91sam9x5ek/Makefile  |   48 +++
>  board/atmel/at91sam9x5ek/at91sam9x5ek.c|  323 
> 
>  board/atmel/at91sam9x5ek/config.mk |1 +
>  boards.cfg |1 +
>  drivers/net/macb.c |4 +-
>  include/configs/at91sam9x5ek.h |  216 +
>  14 files changed, 1090 insertions(+), 4 deletions(-)
>  create mode 100644 arch/arm/cpu/arm926ejs/at91/at91sam9x5_devices.c
>  create mode 100644 arch/arm/include/asm/arch-at91/at91sam9x5.h
>  create mode 100644 arch/arm/include/asm/arch-at91/at91sam9x5_matrix.h
>  create mode 100644 board/atmel/at91sam9x5ek/Makefile
>  create mode 100644 board/atmel/at91sam9x5ek/at91sam9x5ek.c
>  create mode 100644 board/atmel/at91sam9x5ek/config.mk
>  create mode 100644 include/configs/at91sam9x5ek.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e2441d8..cd8b8b5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -658,6 +658,9 @@ Sedji Gaouaou
>   at91sam9g10ek   ARM926EJS (AT91SAM9G10 SoC)
>   at91sam9m10g45ekARM926EJS (AT91SAM9G45 SoC)
>  
> +Bo Shen 
> + at91sam9x5ekARM926EJS (AT91SAM9X5 SoC)
> +
>  Simon Guinot 
>  
>   inetspace_v2ARM926EJS (Kirkwood SoC)
> diff --git a/arch/arm/cpu/arm926ejs/at91/Makefile 
> b/arch/arm/cpu/arm926ejs/at91/Makefile
> index f333753..346e58f 100644
> --- a/arch/arm/cpu/arm926ejs/at91/Makefile
> +++ b/arch/arm/cpu/arm926ejs/at91/Makefile
> @@ -35,6 +35,7 @@ COBJS-$(CONFIG_AT91SAM9263) += at91sam9263_devices.o
>  COBJS-$(CONFIG_AT91SAM9RL)   += at91sam9rl_devices.o
>  COBJS-$(CONFIG_AT91SAM9M10G45)   += at91sam9m10g45_devices.o
>  COBJS-$(CONFIG_AT91SAM9G45)  += at91sam9m10g45_devices.o
> +COBJS-$(CONFIG_AT91SAM9X5)   += at91sam9x5_devices.o
>  COBJS-$(CONFIG_AT91_EFLASH)  += eflash.o
>  COBJS-$(CONFIG_AT91_LED) += led.o
>  COBJS-y += clock.o
> diff --git a/arch/arm/cpu/arm926ejs/at91/at91sam9x5_devices.c 
> b/arch/arm/cpu/arm926ejs/at91/at91sam9x5_devices.c
> new file mode 100644
> index 000..e4262a5
> --- /dev/null
> +++ b/arch/arm/cpu/arm926ejs/at91/at91sam9x5_devices.c
> @@ -0,0 +1,223 @@
> +/*
> + * Copyright (C) 2012 Atmel Corporation
> + *
> + * 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 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define AT91_CIDR_VERSION(0x1f << 0) /* Version of the Device */

this should go into a header.

> +
> +unsigned int get_chip_id(void)
> +{
> + return readl(ATMEL_BASE_DBGU + 0x40) & ~AT91_CIDR_VERSION;

can we get some explanation of these magic numbers please (0x40 here and
0x44 later), maybe add these offsets to the header?

> +
> +}
> +unsigned int get_extension_chip_id(void)
> +{
> + return readl(ATMEL_BASE_DBGU + 0x44);
> +}
> +
> +unsigned int has_emac1()
> +{
> + return cpu_is_at91sam9x25();
> +}
> +unsigned int has_emac0()
> +{
> + return !(cpu_is_at91sam9g15());
> +}
> +unsigned int has_lcdc()
> +{
> + return cpu_is_at91sam9g15() || cpu_is_at91sam9g35()
> + || cpu_is_at91sam9x35();
> +}
> +
> +char *get_cpu_name()
> +{
> + unsigned int extension_i

Re: [U-Boot] Is it possible to boot the U-boot from the another U-boot from the flash area

[Wolfgang Denk]

Dear Ishwar Saunshi,

In message  
you wrote:
> 
> I am really curiuos to see if U-boot can boot another version or another
> Uboot burnt in flash ?
> Its like having 2 images of U-boot which can boot each other if it is
> possible can any one of you hint me how I can achive this. I tried to
> relocate the Uboot and burned on to the flash in 2 different loacation
> however when I try to do "go " it ends up in TLB
> error in early stage of flash execution.

In general, this is not possible.  This topic is covered in the FAQ
here:
http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM


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
"Out of register space (ugh)"
- vi
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mx28: Fix elftosb source link in README.mx28_common

[Detlev Zundel]

Hi Marek,

> Dear Anatolij Gustschin,
>
>> The documented link to elftosb package tarball is not accessible,
>> change to another working link.
>> 
>> Signed-off-by: Anatolij Gustschin 
>> Cc: Otavio Salvador 
>> Cc: Marek Vasut 
>> Cc: Fabio Estevam 
>> ---
>>  doc/README.mx28_common |4 ++--
>>  1 files changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/doc/README.mx28_common b/doc/README.mx28_common
>> index 448d221..fab0e32 100644
>> --- a/doc/README.mx28_common
>> +++ b/doc/README.mx28_common
>> @@ -29,14 +29,14 @@ is the "mxsboot" tool found in U-Boot source tree.
>> 
>>  Firstly, obtain the elftosb archive from the following location:
>> 
>> -http://foss.doredevelopment.dk/mirrors/imx/elftosb-10.12.01.tar.gz
>> +
> http://repository.timesys.com/buildsources/e/elftosb/elftosb-10.12.01/elf
>> tosb-10.12.01.tar.gz
>> 
>>  We use a $VER variable here to denote the current version. At the time of
>>  writing of this document, that is "10.12.01". To obtain the file from
>> command line, use:
>> 
>>  $ VER="10.12.01"
>> -$ wget http://foss.doredevelopment.dk/mirrors/imx/elftosb-${VER}.tar.gz
>> +$ wget
>> http://repository.timesys.com/buildsources/e/elftosb/elftosb-${VER}/elftos
>> b-${VER}.tar.gz
>> 
>>  Extract the file:
>
> That's sad, maybe we should mirror this package and be done with it? 
> Wolfgang/Detlev?

Somewhat late, but still the file can now also be found here:

ftp://ftp.denx.de/pub/tools/elftosb-10.12.01.tar.gz

Cheers
  Detlev

-- 
Music scenes ain't real life / They won't get rid of the bomb
Won't eliminate rape / Or bring down the banks / any kind of change
Takes more time and work / than changing channels on a TV set
-- Jello Biafra
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ARM CONFIG_OF_CONTROL status

[Simon Glass]

Hi,

On Wed, Jun 27, 2012 at 2:29 AM, Michal Simek  wrote:

> Hi,
>
> can you please update me about current state of CONFIG_OF_CONTROL for ARM?
> Are there any other archs/boards which will use this option?
>
Or any other git repo out of mainline u-boot?
>

Exynos is in progress - development is happening in the Chromium tree and
being upstreamed in chunks (although no fdt patches have been sent yet).


>
> Has someone tried to look for devices based on compatible property?
> I see that in usb driver it is based on aliases which is not the best
> solution.
>

U-Boot doesn't yet have a device model which would allow this in the
general case. For now, drivers look for their own compatible nodes. This
works well enough until we have a device model.

There are other limitations also - for example USB supports only a single
controller type working at one time (a restriction we may need to look at
to support USB2 and USB3 together). So even if two USB drivers decided that
they both found compatible nodes, only one of them could operate. So for
now aliases provide just an ordering, nothing else.

Regards,
Simon


>
> Thanks,
> Michal
>
> --
> Michal Simek, Ing. (M.Eng)
> w: www.monstr.eu p: +42-0-721842854
> Maintainer of Linux kernel 2.6 Microblaze Linux -
> http://www.monstr.eu/fdt/
> Microblaze U-BOOT custodian
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mx28: Fix elftosb source link in README.mx28_common

[Anatolij Gustschin]

Hi Detlev,

On Wed, 27 Jun 2012 15:54:40 +0200
Detlev Zundel  wrote:
...
> > That's sad, maybe we should mirror this package and be done with it? 
> > Wolfgang/Detlev?
> 
> Somewhat late, but still the file can now also be found here:
> 
> ftp://ftp.denx.de/pub/tools/elftosb-10.12.01.tar.gz

Thanks! I'll resend updated patch soon.

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

Re: [U-Boot] [Patch v2 2/2] AT91: at91sam9m10g45ek : Enable EHCI instead OHCI

[Andreas Bießmann]

On 26.06.2012 04:21, Bo Shen wrote:
> Enable EHCI support instead OHCI
> 
> Signed-off-by: Bo Shen 

I have no style objections.
Marek, would you take this and apply it in your usb tree (to have the
providing code and user side by side) or should I take it?

Acked-by: Andreas Bießmann 

> ---
>  include/configs/at91sam9m10g45ek.h |   20 +++-
>  1 file changed, 3 insertions(+), 17 deletions(-)


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

Re: [U-Boot] [Patch v2 2/2] AT91: at91sam9m10g45ek : Enable EHCI instead OHCI

[Marek Vasut]

Dear Andreas Bießmann,

> On 26.06.2012 04:21, Bo Shen wrote:
> > Enable EHCI support instead OHCI
> > 
> > Signed-off-by: Bo Shen 
> 
> I have no style objections.
> Marek, would you take this and apply it in your usb tree (to have the
> providing code and user side by side) or should I take it?
> 
> Acked-by: Andreas Bießmann 

Take it

> > ---
> > 
> >  include/configs/at91sam9m10g45ek.h |   20 +++-
> >  1 file changed, 3 insertions(+), 17 deletions(-)

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

[U-Boot] [PATCH v2] mx28: Fix elftosb source link in README.mx28_common

[Anatolij Gustschin]

The documented link to elftosb package tarball is not accessible,
change to another working link.

Signed-off-by: Anatolij Gustschin 
Cc: Otavio Salvador 
Cc: Marek Vasut 
Cc: Fabio Estevam 
Acked-by: Otavio Salvador 
---
v2:
 - change package src url from timesys to DENX ftp
 
 doc/README.mx28_common |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/README.mx28_common b/doc/README.mx28_common
index 448d221..bdd11e7 100644
--- a/doc/README.mx28_common
+++ b/doc/README.mx28_common
@@ -29,14 +29,14 @@ is the "mxsboot" tool found in U-Boot source tree.
 
 Firstly, obtain the elftosb archive from the following location:
 
-   http://foss.doredevelopment.dk/mirrors/imx/elftosb-10.12.01.tar.gz
+   ftp://ftp.denx.de/pub/tools/elftosb-10.12.01.tar.gz
 
 We use a $VER variable here to denote the current version. At the time of
 writing of this document, that is "10.12.01". To obtain the file from command
 line, use:
 
$ VER="10.12.01"
-   $ wget http://foss.doredevelopment.dk/mirrors/imx/elftosb-${VER}.tar.gz
+   $ wget ftp://ftp.denx.de/pub/tools/elftosb-${VER}.tar.gz
 
 Extract the file:
 
-- 
1.7.1

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

[U-Boot] MPC8641HPVN saveenv, newstart u-boot stops

[Thies Peter Thiesen]

MPC8641HPVN  saveenv, newstart u-boot stops

Hi All,

ich used the board freescale HPCN8641D board with nwest u-boot.
only after saveenv and following power off and on, u-boot stops directly 
without serial output.

Because analyse ich have seen:
The command "saveenv" writes environment variable directy the code-area from 
u-boot(flash).

I thing, the hard coded offset to flash "environment variable " after the .text 
area in the flash
is to be small actually.

I give some informations:
Power PC MPC8641D
Flash area u-boot:
version_string: 0xeff4  __bss_end__ 0xeff7a360   size = 0x7a360 


In command saveenv...env_flash.c
Routine saveenv
if (flash_sect_erase((long)flash_addr, end_addr))
used following addresses:
 flash_addr = 0xeff6 end_addr = 0xeff6

static env_t *flash_addr = (env_t *)CONFIG_ENV_ADDR;


File MPC8641HPCN.h
#ifndef CONFIG_SYS_RAMBOOT
#define CONFIG_ENV_IS_IN_FLASH  1
#define CONFIG_ENV_ADDR (CONFIG_SYS_MONITOR_BASE + 0x6)
#define CONFIG_ENV_SECT_SIZE0x1 /* 64K(one sector) for 
env */
#else
#define CONFIG_ENV_IS_NOWHERE   1   /* Store ENV in memory only */
#define CONFIG_ENV_ADDR (CONFIG_SYS_MONITOR_BASE - 0x1000)
#endif

#define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_TEXT_BASE/* start of 
monitor */
#define CONFIG_SYS_TEXT_BASE0xeff0

I thing the constand with 0x6 is to small (u-boot size is bigger)

For my test I have changed 0x6 into 0x7 
#define CONFIG_ENV_ADDR (CONFIG_SYS_MONITOR_BASE + 0x7)

Can someone evaluate this analysis?


Thanks for the Help.
 Thiesen

-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ARM CONFIG_OF_CONTROL status

[Michal Simek]

Hi Simon,

On 06/27/2012 03:58 PM, Simon Glass wrote:

Hi,

On Wed, Jun 27, 2012 at 2:29 AM, Michal Simek mailto:mon...@monstr.eu>> wrote:

Hi,

can you please update me about current state of CONFIG_OF_CONTROL for ARM?
Are there any other archs/boards which will use this option?

Or any other git repo out of mainline u-boot?


Exynos is in progress - development is happening in the Chromium tree and being 
upstreamed in chunks (although no fdt patches have been sent yet).


ok.




Has someone tried to look for devices based on compatible property?
I see that in usb driver it is based on aliases which is not the best 
solution.


U-Boot doesn't yet have a device model which would allow this in the general 
case. For now, drivers look for their own compatible nodes. This works well 
enough until we have a device model.

There are other limitations also - for example USB supports only a single 
controller type working at one time (a restriction we may need to look at to 
support USB2 and USB3 together). So even if two USB drivers decided that they 
both found compatible nodes, only one of them could operate. So for now aliases 
provide just an ordering, nothing else.



I have looked at the code and did some tests on Microblaze.

Firstly I have tried to change emaclite ethernet initialization and I ended 
with this code fragment which could be
broadly used by other drivers.

int offset = 0;
do {
offset = fdt_node_offset_by_compatible(gd->fdt_blob, offset, 
"xlnx,xps-ethernetlite-1.00.a" );
u32 rxpp = fdtdec_get_int(gd->fdt_blob, offset, 
"xlnx,rx-ping-pong", 0);
u32 txpp = fdtdec_get_int(gd->fdt_blob, offset, 
"xlnx,tx-ping-pong", 0);
u32 reg = fdtdec_get_int(gd->fdt_blob, offset, "reg", 0);
if (reg)
ret |= xilinx_emaclite_initialize(bis, reg, txpp, rxpp);
} while (offset != -1);

What do you think? This code is in platform file.

Also I have tested code around aliases which parse DTS aliases list for console 
initialization
and I have also get it work for !CONSOLE_SERIAL_MULTI case.

What was the reason to use compat_names table in fdtdec.c file?

Thanks,
Michal


--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] mx28: Fix elftosb source link in README.mx28_common

[Detlev Zundel]

Hi Anatolij,

> The documented link to elftosb package tarball is not accessible,
> change to another working link.
>
> Signed-off-by: Anatolij Gustschin 
> Cc: Otavio Salvador 
> Cc: Marek Vasut 
> Cc: Fabio Estevam 
> Acked-by: Otavio Salvador 

Acked-by: Detlev Zundel 

Thanks Anatolij!
  Detlev

-- 
Man is a fool, and woman, for tolerating him, is a damned fool
   -- Mark Twain
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] sha256_crypt for uboot

[Richard Retanubun]

Hello,

I am working on a project to allow uboot to authenticate users by using the 
same sha256_crypt function that Linux user-space use for libcrypt
[ref] http://www.akkadia.org/drepper/SHA-crypt.txt

We chose sha256 because uboot already have support for doing sha256 hashes, I 
am wondering about a few things:
1. Has this been attempted before?

2. If I want to make a test command for a proof of concept using crypt(), how 
do I modify the Makefile to allow a
   command to statically link to libcrypt? hacking it into the Makefile's 
$(PLATFORM_LIBS)?

3. Once I am done porting sha256_crypt to use it using the facilities uboot 
has, is there any hope of getting this mainlined when I am done?
   If there is a policy to not unnecessarily add crypto algorithm, then I'll 
just keep it all in one file to reduce risk of merge conflict.
   If there is interest to mainline this, then I'll stage the supporting 
functions that uboot does not have yet (mempcpy, stpcpy, etc) into
   separate files.

Thank you for everyone's time
--
Richard Retanubun
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] davinci, c6x: Always use C version of reset code

[Tom Rini]

We can safely use the same reset code written in C for both Davinci and
C6X platforms.  In addition the C version of the code is marginally
smaller on Davinci.

Tested-by: Matt Porter 
Signed-off-by: Tom Rini 
---
 arch/arm/cpu/arm926ejs/davinci/Makefile  |9 +---
 arch/arm/cpu/arm926ejs/davinci/reset.S   |   81 --
 arch/arm/cpu/arm926ejs/davinci/reset.c   |   32 
 arch/arm/cpu/arm926ejs/davinci/reset_c.c |   32 
 4 files changed, 33 insertions(+), 121 deletions(-)
 delete mode 100644 arch/arm/cpu/arm926ejs/davinci/reset.S
 create mode 100644 arch/arm/cpu/arm926ejs/davinci/reset.c
 delete mode 100644 arch/arm/cpu/arm926ejs/davinci/reset_c.c

diff --git a/arch/arm/cpu/arm926ejs/davinci/Makefile 
b/arch/arm/cpu/arm926ejs/davinci/Makefile
index 54f096d..c91928e 100644
--- a/arch/arm/cpu/arm926ejs/davinci/Makefile
+++ b/arch/arm/cpu/arm926ejs/davinci/Makefile
@@ -27,7 +27,7 @@ include $(TOPDIR)/config.mk
 
 LIB= $(obj)lib$(SOC).o
 
-COBJS-y+= cpu.o misc.o timer.o psc.o pinmux.o
+COBJS-y+= cpu.o misc.o timer.o psc.o pinmux.o 
reset.o
 COBJS-$(CONFIG_DA850_LOWLEVEL) += da850_lowlevel.o
 COBJS-$(CONFIG_SOC_DM355)  += dm355.o
 COBJS-$(CONFIG_SOC_DM365)  += dm365.o
@@ -42,13 +42,6 @@ COBJS-$(CONFIG_SOC_DM365)+= dm365_lowlevel.o
 COBJS-$(CONFIG_SOC_DA8XX)  += da850_lowlevel.o
 endif
 
-
-ifeq ($(CPU),c674x)
-COBJS-y+= reset_c.o
-else
-SOBJS  = reset.o
-endif
-
 ifndef CONFIG_SKIP_LOWLEVEL_INIT
 SOBJS  += lowlevel_init.o
 endif
diff --git a/arch/arm/cpu/arm926ejs/davinci/reset.S 
b/arch/arm/cpu/arm926ejs/davinci/reset.S
deleted file mode 100644
index ba0a7c3..000
--- a/arch/arm/cpu/arm926ejs/davinci/reset.S
+++ /dev/null
@@ -1,81 +0,0 @@
-/*
- * Processor reset using WDT for TI TMS320DM644x SoC.
- *
- * Copyright (C) 2007 Sergey Kubushyn 
- *
- * -
- *
- * 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
- */
-
-.globl reset_cpu
-reset_cpu:
-   ldr r0, WDT_TGCR
-   mov r1, $0x08
-   str r1, [r0]
-   ldr r1, [r0]
-   orr r1, r1, $0x03
-   str r1, [r0]
-   mov r1, $0
-   ldr r0, WDT_TIM12
-   str r1, [r0]
-   ldr r0, WDT_TIM34
-   str r1, [r0]
-   ldr r0, WDT_PRD12
-   str r1, [r0]
-   ldr r0, WDT_PRD34
-   str r1, [r0]
-   ldr r0, WDT_TCR
-   ldr r1, [r0]
-   orr r1, r1, $0x40
-   str r1, [r0]
-   ldr r0, WDT_WDTCR
-   ldr r1, [r0]
-   orr r1, r1, $0x4000
-   str r1, [r0]
-   ldr r1, WDTCR_VAL1
-   str r1, [r0]
-   ldr r1, WDTCR_VAL2
-   str r1, [r0]
-   /* Write an invalid value to the WDKEY field to trigger
-* an immediate watchdog reset */
-   mov r1, $0x4000
-   str r1, [r0]
-   nop
-   nop
-   nop
-   nop
-reset_cpu_loop:
-   b   reset_cpu_loop
-
-WDT_TGCR:
-   .word   0x01c21c24
-WDT_TIM12:
-   .word   0x01c21c10
-WDT_TIM34:
-   .word   0x01c21c14
-WDT_PRD12:
-   .word   0x01c21c18
-WDT_PRD34:
-   .word   0x01c21c1c
-WDT_TCR:
-   .word   0x01c21c20
-WDT_WDTCR:
-   .word   0x01c21c28
-WDTCR_VAL1:
-   .word   0xa5c64000
-WDTCR_VAL2:
-   .word   0xda7e4000
diff --git a/arch/arm/cpu/arm926ejs/davinci/reset.c 
b/arch/arm/cpu/arm926ejs/davinci/reset.c
new file mode 100644
index 000..44ae364
--- /dev/null
+++ b/arch/arm/cpu/arm926ejs/davinci/reset.c
@@ -0,0 +1,32 @@
+/*
+ *  Processor reset using WDT.
+ *
+ * Copyright (C) 2012 Dmitry Bondar 
+ * Copyright (C) 2007 Sergey Kubushyn 
+ *
+ * This file is released under the terms of GPL v2 and any later version.
+ * See the file COPYING in the root directory of the source tree for details.
+*/
+
+#include 
+#include 
+#include 
+
+void reset_cpu(unsigned long a)
+{
+   struct davinci_timer *const wdttimer =
+   (struct davinci_timer *)DAVINCI_TIMER1_BASE;
+   writel(0x08, &wdttimer->tgcr);
+   writel(readl(&wdttimer->tgcr) | 0x03, &wdttimer->tgcr);
+   writel(0, &wdttimer->tim12);
+   writel(0, &wdttimer->tim34);
+   writel(0, &wdttimer->prd12);
+   writel(0, &wdttimer-

Re: [U-Boot] [PATCH] davinci, c6x: Always use C version of reset code

[Tom Rini]

On Wed, Jun 27, 2012 at 08:27:05AM -0700, Tom Rini wrote:

> We can safely use the same reset code written in C for both Davinci and
> C6X platforms.  In addition the C version of the code is marginally
> smaller on Davinci.
> 
> Tested-by: Matt Porter 
> Signed-off-by: Tom Rini 

In the next go-round of the c6x patches please just fold this (and the
tested-by) into the patch you add that creates the C version of the
reset code.  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 1/1] USB: EHCI: Initialize multiple USB controllers at once

[Stephen Warren]

On 06/27/2012 12:55 AM, Wolfgang Denk wrote:
> Dear Jim Lin,
> 
> sending the very same message eight (8!) times doesnot make it a bit
> more convincing - on contrary.
> 
> In message <4b9c9637d5087840a465bdcb251780e9e2d6eda...@hkmail02.nvidia.com> 
> you wrote:
>>
>>> U-Boot is not multi-tasking, so you can always access only a single
>>> USB device at a time ayway.  And it is a decoumented design principle
>>> that U-Boot must not initialize any devices it does not use itself.
>>>
>>> So why?
>> Because of this complaint and request for devices under different controllers
>> to be working at same time.
> 
> You make another claim here, but don't explain how this is supposed to
> work or whay the exact use case would be where this was needed.
> U-Boot will not be able to access multiple devices at the same time,
> so why would it be necessary to enable these?  It should be sufficient
> to enable the controller that is responsible for the single device
> that is currently being used.
> 
>> "One particularly annoying consequence of this is when you use the Seaboard
>> configuration on Springbank.
>> Seaboard selects Tegra's USB3 as "usb 0" device, which is the one you can 
>> use,
>> in order not to conflict with the flashing USB port USB1.
>> However, Springbank only exposes USB1 since USB3 is used internally for the
>> USB keyboard/mouse. As such, you cannot use the USB port on Springbank under
>> U-Boot at the moment.
>> "
> 
> I have to admit that I cannot make any sense from this statement.  The
> only thing I understand is that you are trying to use a configuration
> for one hardware (Seaboard) on another, incompatible hardware
> (Springbank).
> 
> The simple answer to this problem is: don't do that, then.

Seaboard and Springbank are essentially the same board, and hence are
almost 100% SW compatible, so there's no problem running a Seaboard
build of U-Boot/kernel/... on Springbank.

The primary issue here is that many boards have multiple USB ports.
Users could plug e.g. a USB->Ethernet device into any of the ports.
Requiring the user to know which port is which ID so they can issue the
correct "usb start " command is painful; no other SW stack limits
itself to a single port and so most people don't have a clue which ports
are numbered what; they just want USB to work.

The specific issue on Springbank is that there are multiple USB ports
that are useful at the essentially the same time. One of the USB ports
hosts a built-in USB keyboard (inside a sealed clamshell/netbook case),
which we would like to use for the U-boot console. Another USB port is
external, and people will plug in a USB->Ethernet dongle or USB storage
device there. so, if I need to "usb start 0" to get the keyboard, and
"usb start 1" to get USB Ethernet, then as soon as I "usb start 1" to
get the Ethernet, I've just lost the console, and am unable to interact
with U-Boot any more...
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 1/3] AM335x : Add USB support for AM335x in u-boot

[Tom Rini]

On Tue, Jun 26, 2012 at 03:08:01PM +0530, Harman Sohanpal wrote:

> From: Gene Zarkhin 
> 
> Adds USB support in uboot for AM335x.
> By default the USB 1 module is enabled.
> The support for USB 0 can be enabled by changing the
> USB base address and the phy control register address
> in the header file am335x.h.
> USB 1 has a full size connector so acts in host mode and
> USB 0 has a mini connector so used in device mode.
> By default, the support is added for host mode hence USB 1
> has been enabled by default.
> 
> Signed-off-by: Gene Zarkhin 
> Signed-off-by: Harman Sohanpal 

What I was saying was that we want to make am335x.h do:
#define AM335X_USB0_BASE 0x47401000
#define AM335X_USB1_BASE 0x47401800

Then:
#ifdef CONFIG_AM335X_USB0
#define AM335X_USB_OTG_BASE AM335X_USB0_BASE
#elif defined(CONFIG_AM335X_USB1)
#define AM335X_USB_OTG_BASE AM335X_USB1_BASE
#endif
#define AM335X_USB_OTG_CORE_BASE (AM335X_USB_OTG_BASE + 0x400)

So that in boards.cfg we could add an entry for am335x_evm_usb1 and set
CONFIG_AM335X_USB1 dynamically.  Then in am335x_evm.h set either
MUSB_HCD or MUSB_UDC based on if CONFIG_AM335X_USB0 or
CONFIG_AM335X_USB1 is set (and have boards.cfg set CONFIG_AM335X_USB0
for 'am335x_evm).

Then you can test device mode on the evm :)  And how did you test device
mode on the beaglebone?  I couldn't since I don't have the rest set of
adapters here.

Also:

> +++ b/drivers/usb/musb/am335x.h
[snip]
> +/* Control Module Registers */
> +#define CM_REGISTERS CTRL_BASE
> +#define USB_CTRL0_REG_OFFSET (0x628)
> +#define USB_CTRL1_REG_OFFSET (0x680)

Please get all indentation out to a consistent level

> +#define PRCM_IDLEST 0x3
> +#define DPLL_CLKDCOLDO_GATE_CTRL0x300

And always use tabs :)

-- 
Tom


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

Re: [U-Boot] [PATCH 1/2] bcm: Add GPIO driver for BCM2835 SoC

[Vikram Narayanan]

Hello Stephen,

On 6/27/2012 7:09 AM, Stephen Warren wrote:

On 06/24/2012 11:21 AM, Vikram Narayanan wrote:

First off, it's great to see some patches for the chip. Thanks. Sorry
for being so nit-picky below; it's a tendency of mine...


Thanks for the detailed review. I'd make a v2 for this.
And I might probably include you in the signed-off-by line.
Hope you don't mind that.

Do you have a hosted repo somewhere for this rpi_b stuff?
If so, please post it here or we shall have one, which has all the 
patches queued in for the mainline. What do you say? Share your opinions 
about this.



BTW, I don't think this patch compiles; gpio_set_value() references
variable "pin", which doesn't exist.


Sorry about that, Late night submission!

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

Re: [U-Boot] [PATCH] arm: bugfix: save_boot_params_default accesses uninitalized stack when -O0

[Tom Rini]

On Mon, Jun 25, 2012 at 09:42:29PM +0900, Tetsuyuki Kobayashi wrote:

> save_boot_params_default() in cpu.c accesses uninitialized stack area
> when it compiled with -O0 (not optimized).
> 
> Signed-off-by: Tetsuyuki Kobayashi 
> ---
>  arch/arm/cpu/armv7/cpu.c |3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm/cpu/armv7/cpu.c b/arch/arm/cpu/armv7/cpu.c
> index c6fa8ef..6104cb2 100644
> --- a/arch/arm/cpu/armv7/cpu.c
> +++ b/arch/arm/cpu/armv7/cpu.c
> @@ -37,8 +37,11 @@
>  #include 
>  #include 
>  
> +__attribute__((naked)) /* don't save anything to stack even if compiled with 
> -O0 */
>  void save_boot_params_default(u32 r0, u32 r1, u32 r2, u32 r3)
>  {
> + /* stack is not yet initialized */
> + asm("bx lr");
>  }

Please add  and use __naked instead.  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 5/6] mtd/spi: add sst25l driver

[Tom Rini]

On Tue, Jun 26, 2012 at 02:33:13PM +0400, Mikhail Kshevetskiy wrote:

> current SST driver does not support well this types of flash, so use
> linux-3.3 code as a base.
> 
> Signed-off-by: Mikhail Kshevetskiy 

The correct form here is to say:
Backport from Linux commit 
If this is from the 3.3 release please say that clearly.  Thanks!

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

Re: [U-Boot] [PATCH 1/2] bcm: Add GPIO driver for BCM2835 SoC

[Stephen Warren]

On 06/27/2012 11:32 AM, Vikram Narayanan wrote:
> Hello Stephen,
> 
> On 6/27/2012 7:09 AM, Stephen Warren wrote:
>> On 06/24/2012 11:21 AM, Vikram Narayanan wrote:
>>
>> First off, it's great to see some patches for the chip. Thanks. Sorry
>> for being so nit-picky below; it's a tendency of mine...
> 
> Thanks for the detailed review. I'd make a v2 for this.
> And I might probably include you in the signed-off-by line.
> Hope you don't mind that.

No, you shouldn't add any tags to the patch that refer to other people,
except perhaps a Reported-By, without their explicitly giving those tags.

Also, Signed-off-by wouldn't make sense here since I'm not vouching for
the code or passing it along. Once V2 is posted, I may give an ack or
review tag.

> Do you have a hosted repo somewhere for this rpi_b stuff?
> If so, please post it here or we shall have one, which has all the
> patches queued in for the mainline. What do you say? Share your opinions
> about this.

I do have a repo. It's at:
https://github.com/swarren/u-boot

However, that's my personal work-space. The RPi patches should
eventually make it into the official U-Boot repositories through the
standard review process. They are:

ARM repo:
git://git.denx.de/u-boot-arm.git

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

Re: [U-Boot] [PATCH] arm: bugfix: Move vector table before jumping relocated code

[Tom Rini]

On Mon, Jun 25, 2012 at 09:40:57PM +0900, Tetsuyuki Kobayashi wrote:

> Interrupts and exceptions doesn't work in relocated code.
> It badly use IRQ_STACK_START_IN in rom area as interrupt stack.
> It is because the vecotr table is not moved to ram area.
> This patch moves vector table before jumping relocated code.
> 
> Signed-off-by: Tetsuyuki Kobayashi 
> ---
>  arch/arm/cpu/armv7/start.S |   12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
> index 52f7f6e..5098f7b 100644
> --- a/arch/arm/cpu/armv7/start.S
> +++ b/arch/arm/cpu/armv7/start.S
> @@ -277,6 +277,18 @@ jump_2_ram:
>   mcr p15, 0, r0, c7, c10, 4  @ DSB
>   mcr p15, 0, r0, c7, c5, 4   @ ISB
>  #endif
> +/*
> + * Move vector table
> + */
> +#if !defined(CONFIG_TEGRA2)
> +#if !(defined(CONFIG_OMAP44XX) && defined(CONFIG_SPL_BUILD))
> + /* Set vector address in CP15 VBAR register */
> + ldr r0, =_start
> + add r0, r0, r9
> + mcr p15, 0, r0, c12, c0, 0  @Set VBAR
> +#endif
> +#endif /* !Tegra2 */
> + 
>   ldr r0, _board_init_r_ofs
>   adr r1, _start
>   add lr, r0, r1

I think this code should get boot tested on a few platforms to make sure
it's OK.  As such, I've tried on am335x and omap3 and they're still
fine.

Tested-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH v2 0/3] Bug fixes for LaCie devices

[Simon Guinot]

On Thu, Jun 14, 2012 at 08:18:33AM -0700, Prafulla Wadaskar wrote:
> 
> 
> > -Original Message-
> > From: Simon Guinot [mailto:si...@sequanux.org]
> > Sent: 14 June 2012 20:41
> > To: Simon Guinot
> > Cc: Prafulla Wadaskar; u-boot@lists.denx.de
> > Subject: Re: [U-Boot] [PATCH v2 0/3] Bug fixes for LaCie devices
> > 
> > On Wed, Jun 06, 2012 at 01:15:57AM +0200, Simon Guinot wrote:
> > > This patch series provides bug fixes for LaCie devices (mostly for
> > > Internet Space v2 and 2Big Network v2).
> > >
> > > Changes for v2:
> > >  - Move bug fixes into a separate patch set.
> > >
> > > Simon Guinot (3):
> > >   lacie_kw: fix SDRAM banks number for net2big_v2
> > >   lacie_kw: fix CONFIG_SYS_KWD_CONFIG for inetspace_v2
> > >   ARM: don't probe PHY address for LaCie boards
> > >
> > >  board/LaCie/common/common.c   |   23 +++---
> > -
> > >  board/LaCie/common/common.h   |2 +-
> > >  board/LaCie/edminiv2/edminiv2.c   |2 +-
> > >  board/LaCie/net2big_v2/net2big_v2.c   |2 +-
> > >  board/LaCie/netspace_v2/netspace_v2.c |2 +-
> > >  include/configs/lacie_kw.h|6 +-
> > >  6 files changed, 12 insertions(+), 25 deletions(-)
> > 
> > Hi Prafulla,
> > 
> > Please could you pick this patches ?
> > 
> 
> Sure, I will do it. Hopefully by tomorrow

Please could you pick my two patch series ?

Thanks.

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] [PATCH 1/3] tegra: add GMC/GMD funcmux entry for SFLASH

[Tom Warren]

Stephen,

> -Original Message-
> From: Stephen Warren [mailto:swar...@wwwdotorg.org]
> Sent: Tuesday, June 12, 2012 11:34 AM
> To: Tom Warren
> Cc: u-boot@lists.denx.de; Stephen Warren
> Subject: [PATCH 1/3] tegra: add GMC/GMD funcmux entry for SFLASH

This series (3 patches) has been applied to u-boot-tegra/master. Thanks!

Tom
> 
> From: Stephen Warren 
> 
> This is used on TrimSlice.
> 
> Signed-off-by: Stephen Warren 
> ---
>  arch/arm/cpu/armv7/tegra2/funcmux.c|   10 ++
>  arch/arm/include/asm/arch-tegra2/funcmux.h |3 +++
>  2 files changed, 13 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv7/tegra2/funcmux.c
> b/arch/arm/cpu/armv7/tegra2/funcmux.c
> index 455d010..4a31a4c 100644
> --- a/arch/arm/cpu/armv7/tegra2/funcmux.c
> +++ b/arch/arm/cpu/armv7/tegra2/funcmux.c
> @@ -224,6 +224,16 @@ int funcmux_select(enum periph_id id, int config)
>   }
>   break;
> 
> + case PERIPH_ID_SPI1:
> + if (config == FUNCMUX_SPI1_GMC_GMD) {
> + pinmux_set_func(PINGRP_GMC, PMUX_FUNC_SFLASH);
> + pinmux_set_func(PINGRP_GMD, PMUX_FUNC_SFLASH);
> +
> + pinmux_tristate_disable(PINGRP_GMC);
> + pinmux_tristate_disable(PINGRP_GMD);
> + }
> + break;
> +
>   default:
>   debug("%s: invalid periph_id %d", __func__, id);
>   return -1;
> diff --git a/arch/arm/include/asm/arch-tegra2/funcmux.h
> b/arch/arm/include/asm/arch-tegra2/funcmux.h
> index 3cbc7d2..dcd512f 100644
> --- a/arch/arm/include/asm/arch-tegra2/funcmux.h
> +++ b/arch/arm/include/asm/arch-tegra2/funcmux.h
> @@ -54,6 +54,9 @@ enum {
> 
>   /* USB configs */
>   FUNCMUX_USB2_ULPI = 0,
> +
> + /* Serial Flash configs */
> + FUNCMUX_SPI1_GMC_GMD = 0,
>  };
> 
>  /**
> --
> 1.7.0.4
-- 
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v5 1/1] tegra: usb: Fix device enumeration problem of USB1

[Tom Warren]

Jim,

> -Original Message-
> From: Jim Lin
> Sent: Sunday, June 24, 2012 11:41 PM
> To: 'u-boot@lists.denx.de'
> Cc: Tom Warren; Marek Vasut; 'Stephen Warren'
> Subject: [PATCH v5 1/1] tegra: usb: Fix device enumeration problem of USB1
 
This patch has been applied to u-boot-tegra/master. Thanks!

Tom
> 
> A known hardware issue of USB1 port where bit 1 (connect status
> change) of PORTSC register will be set after issuing Port Reset (like "usb
> reset" in u-boot command line).
> This will be treated as an error and stops later device enumeration.
> 
> Therefore we clear that bit after Port Reset in order to proceed later
> device enumeration.
> 
> Signed-off-by: Jim Lin 
> ---
> To reproduce this issue, you can modify board .dts file to set as the
> following to build u-boot binary.
> "
>  usb0 = "/usb@c500";
>  usb1 = "/usb@c5008000";
> "
> Install device on USB1 port (address at 0xc500).
> And run "usb reset" in u-boot console to enumerate device.
> 
> Before adding this patch, we could see problem every time.
> After adding, tried 10 times of "usb reset", "usb tree", "usb stop"
> , without seeing issue.
> 
> Changes in v5:
> - Define USB address mask value in header file
> 
> Changes in v4:
> - Add comment to describe replacing weak function ehci_powerup_fixup of
> ehci-hcd.c
> - Remove using variable my_reg
> 
> Changes in v3:
> - Move patch for USB1 controller into ehci_powerup_fixup of ehci-tegra.c
> - Update copyright year to 2012
> 
> Changes in v2:
> - Change config name
> - Add a callback function at the end of ehci_submit_root() function
> 
>  arch/arm/include/asm/arch-tegra2/tegra2.h |1 +
>  drivers/usb/host/ehci-tegra.c |   18 +-
>  2 files changed, 18 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/include/asm/arch-tegra2/tegra2.h
> b/arch/arm/include/asm/arch-tegra2/tegra2.h
> index d4ada10..710334b 100644
> --- a/arch/arm/include/asm/arch-tegra2/tegra2.h
> +++ b/arch/arm/include/asm/arch-tegra2/tegra2.h
> @@ -45,6 +45,7 @@
>  #define NV_PA_CSITE_BASE 0x7004
>  #define TEGRA_USB1_BASE  0xC500
>  #define TEGRA_USB3_BASE  0xC5008000
> +#define TEGRA_USB_ADDR_MASK  0xC000
> 
>  #define TEGRA2_SDRC_CS0  NV_PA_SDRAM_BASE
>  #define LOW_LEVEL_SRAM_STACK 0x4000FFFC
> diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
> index a7e105b..4646b29 100644
> --- a/drivers/usb/host/ehci-tegra.c
> +++ b/drivers/usb/host/ehci-tegra.c
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2009 NVIDIA Corporation
> + * Copyright (c) 2009-2012 NVIDIA Corporation
>   *
>   * See file CREDITS for list of people who contributed to this
>   * project.
> @@ -29,6 +29,22 @@
>  #include 
>  #include 
> 
> +/*
> + * A known hardware issue where Connect Status Change bit of PORTSC
> +register
> + * of USB1 controller will be set after Port Reset.
> + * We have to clear it in order for later device enumeration to proceed.
> + * This ehci_powerup_fixup overrides the weak function
> +ehci_powerup_fixup
> + * in "ehci-hcd.c".
> + */
> +void ehci_powerup_fixup(uint32_t *status_reg, uint32_t *reg) {
> + mdelay(50);
> + if (((u32) status_reg & TEGRA_USB_ADDR_MASK) != TEGRA_USB1_BASE)
> + return;
> + /* For EHCI_PS_CSC to be cleared in ehci_hcd.c */
> + if (ehci_readl(status_reg) & EHCI_PS_CSC)
> + *reg |= EHCI_PS_CSC;
> +}
> 
>  /*
>   * Create the appropriate control structures to manage
> --
> 1.7.3
--  
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] BOOT: Fix unused variable issue when enabling bootz support

[Tom Warren]

Stephen,

> -Original Message-
> From: Stephen Warren [mailto:swar...@wwwdotorg.org]
> Sent: Wednesday, June 13, 2012 12:55 PM
> To: Tom Warren
> Cc: u-boot@lists.denx.de; Stephen Warren; Marek Vasut; Wolfgang Denk
> Subject: [PATCH 1/3] BOOT: Fix unused variable issue when enabling bootz
> support

This series (3 patches) has been applied to u-boot-tegra/master. Thanks!

Tom

> 
> From: Stephen Warren 
> 
> cmd_bootm.c: In function 'do_bootz':
> cmd_bootm.c:1590:9: warning: variable 'iflag' set but not used [-Wunused-
> but-set-variable]
> 
> Cc: Marek Vasut 
> Cc: Wolfgang Denk 
> Signed-off-by: Stephen Warren 
> ---
> I think this is best taken through the Tegra tree, since it's needed to
> avoid introducing warnings when enabling CONFIG_CMD_BOOTZ, which the next
> patch enables, and we don't want MAKEALL -s tegra2 to suddenly start giving
> warnings.
> ---
>  common/cmd_bootm.c |3 +--
>  1 files changed, 1 insertions(+), 2 deletions(-)
> 
> diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c index 5685232..45e726a
> 100644
> --- a/common/cmd_bootm.c
> +++ b/common/cmd_bootm.c
> @@ -1587,7 +1587,6 @@ static int bootz_start(cmd_tbl_t *cmdtp, int flag, int
> argc,
> 
>  static int do_bootz(cmd_tbl_t *cmdtp, int flag, int argc, char * const
> argv[])  {
> - ulong   iflag;
>   bootm_headers_t images;
> 
>   if (bootz_start(cmdtp, flag, argc, argv, &images)) @@ -1598,7 +1597,7
> @@ static int do_bootz(cmd_tbl_t *cmdtp, int flag, int argc, char * const
> argv[])
>* overwrite all exception vector code, so we cannot easily
>* recover from any failures any more...
>*/
> - iflag = disable_interrupts();
> + disable_interrupts();
> 
>  #if defined(CONFIG_CMD_USB)
>   /*
> --
> 1.7.0.4
-- 
nvpublic

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

Re: [U-Boot] [PATCH v2] mx28: Fix elftosb source link in README.mx28_common

[Marek Vasut]

Hi Anatolij,

> Hi Anatolij,
> 
> > The documented link to elftosb package tarball is not accessible,
> > change to another working link.
> > 
> > Signed-off-by: Anatolij Gustschin 
> > Cc: Otavio Salvador 
> > Cc: Marek Vasut 
> > Cc: Fabio Estevam 
> > Acked-by: Otavio Salvador 
> 
> Acked-by: Detlev Zundel 

Acked-by: Marek Vasut 
 
> Thanks Anatolij!
>   Detlev

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

Re: [U-Boot] [PATCH v3 1/4] Add support new arch: c6x

[bond]

> On Mon, Jun 25, 2012 at 10:02:38PM +0400, Dmitry Bondar wrote:
>
>> C6X (C6000) is Texas Instruments architecture of fixed and
>> floating-point DSPs.
>> This patch add basic support.
>> Many of code in arch/c6x/include/asm come from c6x-linux project
>> (http://linux-c6x.org)
>>
>> Signed-off-by: Dmitry Bondar 
>> Cc: Tom Rini 
>
> Please cite the exact commit from upstream where this comes from (I
> imagine you could even use kernel.org proper, but I didn't check all
> files just a few) and say for example:
> Backport from linux commit 27406e978f596a646b87941cba5247eb0ccc8916
>
Must I say it in each file, or in commit message?

If in commit, how about  something like this:
"
Many of code in arch/c6x/include/asm and arch/c6x/lib come from linux kernel,
c6x headers (arch/c6x/include/asm) in linux kernel mainline from commit
a7f626c1948ab6178d2338831c5ffea7385e9f7f
c6x libs (arch/c6x/lib) in linux kernel mainline from
09831ca73443bd819ad7993db5409b19c899ba33
"

>> +#ifndef __ASM_GBL_DATA_H
>
> Tabs instead of spaces.  I don't know why checkpatch didn't complain but
> please give all of the files a quick check for things like 
> and '#define' and '#ifndef.
>
> I spot-checked a few of the library files and they seem to match the
> kernel which is important so I'll set aside disliking ';' as a comment
> char.
>
> [snip]
>> diff --git a/common/cmd_bdinfo.c b/common/cmd_bdinfo.c
>> index 42f08fd..faf534b 100644
>> --- a/common/cmd_bdinfo.c
>> +++ b/common/cmd_bdinfo.c
>> @@ -513,6 +513,11 @@ int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc,
>> char * const argv[])
>>
>>  return 0;
>>  }
>> +#elif defined(CONFIG_C6X)
>> +int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc, char * const
>> argv[])
>> +{
>> +return 0;
>> +}
>
> You should be able to define a minimal set of prints here, see the
> OpenRISC example above it.
>
>> diff --git a/common/image.c b/common/image.c
>> index 91954ac..0fff687 100644
>> --- a/common/image.c
>> +++ b/common/image.c
>> @@ -456,8 +456,12 @@ phys_size_t getenv_bootm_size(void)
>>  #if defined(CONFIG_ARM)
>>  return gd->bd->bi_dram[0].size - tmp;
>>  #else
>> +#if defined(CONFIG_C6X)
>> +return gd->bd->bi_dram[0].size - tmp;
>
> Here and possibly another place or two in the file, just change the
> check from defined(CONFIG_ARM) to defined(CONFIG_ARM) ||
> defined(CONFIG_C6X).
>
> Thanks!
>
> --
> Tom
>


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

Re: [U-Boot] [PATCH v3 1/4] Add support new arch: c6x

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/27/2012 01:36 PM, b...@inmys.ru wrote:
>> On Mon, Jun 25, 2012 at 10:02:38PM +0400, Dmitry Bondar wrote:
>> 
>>> C6X (C6000) is Texas Instruments architecture of fixed and 
>>> floating-point DSPs. This patch add basic support. Many of code
>>> in arch/c6x/include/asm come from c6x-linux project 
>>> (http://linux-c6x.org)
>>> 
>>> Signed-off-by: Dmitry Bondar  Cc: Tom Rini
>>> 
>> 
>> Please cite the exact commit from upstream where this comes from
>> (I imagine you could even use kernel.org proper, but I didn't
>> check all files just a few) and say for example: Backport from
>> linux commit 27406e978f596a646b87941cba5247eb0ccc8916
>> 
> Must I say it in each file, or in commit message?

Just the commit message.

> If in commit, how about  something like this: " Many of code in
> arch/c6x/include/asm and arch/c6x/lib come from linux kernel, c6x
> headers (arch/c6x/include/asm) in linux kernel mainline from
> commit a7f626c1948ab6178d2338831c5ffea7385e9f7f c6x libs
> (arch/c6x/lib) in linux kernel mainline from 
> 09831ca73443bd819ad7993db5409b19c899ba33 "

Yes, or just make sure that both parts are still in sync with the
kernel at whichever of those commits is later.  That'll make any
future re-syncs easier on you :)

- -- 
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJP63NeAAoJENk4IS6UOR1WmjUP/3b/SAQxeJXzupGW0PhKH5TZ
ptwHPxkzTDcSXGNYmL42XdD4NLTM0rgNxQxZoPobKVVSAynlxv58Bzb9e4Umf/BH
HWs4L/TvnAWlAu45BU3wjzPYqF+lo7aDyiw4jDsX0zb+WxArPY90kM1NTCiUvK9U
BexzFTrqL0Rfw0vAAIfGSw46qyIRaZp2AM2q97J0Q7j4satiA8AJ7Ly6XcWu43/s
4L5FBF0lDeLLmsMnFXvJOj0O2KWxvyaQx7ola1YkXSSFPdSXY9M2gbkbz+spSe81
Pgw43XJ7OXlrASDsvov7U9V/LHLuqXS/Lo8jVMFTp5hLfXD830mA5dBCipsPJF/1
mIxXy3qIgdxNwtOMeebhfknpIhW6TQV1T5F5RyTFmsB5g1N+5lBTQveMCE1qMqmK
Lki6ftPGhsJpPTxNvev/gx3acBQ6O+/X/zWujlj6YUcx1QCZYZq4bXP4a+4MB07N
bmuSNwl3PlH03lO9SDUZVBc6h+eLJ2jU1rMba+ojQmcGOUUeq42Cs+W1Lr5dfQEE
rcg/y4HxUIbYxkR4P0jJwE0SGsEy25/8X8859rGnQw25Pvxg0xFXmtisDb2WYDzd
SU9y31JsLybpa6HeO8F5ex3aRb7+KYhLrOSxoGCGKmgeuJ0ndcQP3dRigrw3jVs6
Tq7hNvK/kgUBVT6pXimQ
=4ngS
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 1/4] Add support new arch: c6x

[Wolfgang Denk]

Dear b...@inmys.ru,

In message <9cc1576e223fd1ac2b8a3329ad55bca8.squirrel@78.108.93.81> you wrote:
>
> > Please cite the exact commit from upstream where this comes from (I
> > imagine you could even use kernel.org proper, but I didn't check all
> > files just a few) and say for example:
> > Backport from linux commit 27406e978f596a646b87941cba5247eb0ccc8916
> >
> Must I say it in each file, or in commit message?

How about reading the documentation?  It answers such questions, with
examples and all that.

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
"There is nothing  so  deadly  as  not  to  hold  up  to  people  the
opportunity to do great and wonderful things, if we wish to stimulate
them in an active way."
- Dr. Harold Urey, Nobel Laureate in chemistry
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 3/6] mcx: Disable DCACHE since USB EHCI is enabled

[Marek Vasut]

Dear Ilya Yanok,

> Hi,
> 
> 21.06.2012 02:14, Tom Rini wrote:
> > USB EHCI and DCACHE are not compatible, so disable DCACHE support at
> > build-time as run-time disable is insufficient for USB use.
> 
> Sorry for missing this discussion. I think compile-time disabling of the
> cache is too brutal.
> ehci-hcd cache handling is broken anyway: doing unaligned
> flushes/invalidates is a bug, and we know for sure that upper layers
> don't care about alignment (and I bet ehci-hcd does this even for its
> internal buffers). So what's the point in all this cache handling in
> ehci-hcd? It's not going to work anyway and just produces problems. So I
> suggest to just disable all this stuff until generic code will be fixed.
> Alternatively we can do bounce-buffering inside driver.

We should rather introduce generic bounce buffer. But the upper layers are 
getting fixed recently so we should be getting there.

> 
> Regards, Ilya.

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

Re: [U-Boot] [PATCH 2/4] cache_v7: Check for dcache enablement in dcache flush functions

[Aneesh V]

Hi Sricharan,

On 06/21/2012 02:25 AM, Sricharan R wrote:

Hi,
[snip..]

On 06/15/2012 07:48 AM, R, Sricharan wrote:

Hi,


On Fri, Jun 15, 2012 at 12:31 AM, Tom Rini   wrote:

If we are built with D-CACHE enabled but have run 'dcache off' and

then

attempt to flush unaligned regions we spam the console with

problems

that aren't true (as the cache was off).


Today we do cache maintenance operations after the dcache is

turned off.

One example is before jumping to kernel, we try to invalidate

the caches,

in cache turned off state. So with this patch those maintenance

calls will

do nothing, which is not correct.


Ah yes,  But, shouldn't we be doing these same operations as part of
turning the cache off?


The problem is that while turning of dcaches, we flush it, and

turn

   cache and MMU off.  But these operations are not happening
   automatically in a single call. So there is a chance of  valid
   entries present in cache even after it is OFF.


I think this is what we need to fix. Otherwise, Tom's change looks good
to me. How about an invalidate in dcache_disable() or something like
that?


   Correct. So if the cleaning up sequence is fine, then ok.
   So there should be no need to check if caches are OFF inside
   the maintenance functions. Kernel does not looks like doing such checks.
   The real issue looks like we should have had assembly level functions
   to do the cleanup routines for flush-invalidate-turn OFF caches/MMU
atomically.


Sorry for the late reply. Yes, kernel doesn't do such checks. But
kernel's implementation is different from u-boot implementation. In
kernel the invalidate routine flushes unaligned lines in the end which,
after a lot of discussions[1], we decided to avoid in u-boot. Instead
we printed noisy error messages to alert the user. Now these messages
will appear even if we are calling the maintenance functions after the
disable and that's what Tom is trying to avoid.

br,
Aneeesh

[1] http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/105113
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] cache_v7: Check for dcache enablement in dcache flush functions

[Aneesh V]

Sricharan,

On 06/21/2012 08:23 AM, R, Sricharan wrote:

Hi Aneesh,

On Thu, Jun 21, 2012 at 2:55 PM, Sricharan R  wrote:

Hi,
[snip..]

On 06/15/2012 07:48 AM, R, Sricharan wrote:

Hi,


On Fri, Jun 15, 2012 at 12:31 AM, Tom Riniwrote:

If we are built with D-CACHE enabled but have run 'dcache off' and

then

attempt to flush unaligned regions we spam the console with

problems

that aren't true (as the cache was off).


Today we do cache maintenance operations after the dcache is

turned off.

One example is before jumping to kernel, we try to invalidate

the caches,

in cache turned off state. So with this patch those maintenance

calls will

do nothing, which is not correct.


Ah yes,  But, shouldn't we be doing these same operations as part of
turning the cache off?


The problem is that while turning of dcaches, we flush it, and

turn

   cache and MMU off.  But these operations are not happening
   automatically in a single call. So there is a chance of  valid
   entries present in cache even after it is OFF.


I think this is what we need to fix. Otherwise, Tom's change looks good
to me. How about an invalidate in dcache_disable() or something like
that?


  Correct. So if the cleaning up sequence is fine, then ok.
  So there should be no need to check if caches are OFF inside
  the maintenance functions. Kernel does not looks like doing such checks.
  The real issue looks like we should have had assembly level functions
  to do the cleanup routines for flush-invalidate-turn OFF caches/MM
atomically.

   Actually, with something like speculation in the behind, only way of
ensuring that
we do not have any valid entries is to do a invalidate all, after
turn of caches/mmu.
So this means that we will have a maintenance after turning off.


Good point. But we need that invalidate just one last time after the
disable, right? How about making the cache_status a variable rather
than reading the C bit. And then disable_cache() shall be like this:

1. Flush all
2. Disable C bit
3. Invalidate all
4. cache_status = disabled

Maybe, not the best solution. But I can't think of anything better.
Please note that after this point there won't be any valid entries in
the cache per ARMv7 Architecture reference manual(section B2.2.2):

"If the cache is disabled, it is guaranteed that no new allocation of 
memory locations into the cache will occur."


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

Re: [U-Boot] [PATCH v4 3/6] mcx: Disable DCACHE since USB EHCI is enabled

[Ilya Yanok]

Hi,

21.06.2012 02:14, Tom Rini wrote:

USB EHCI and DCACHE are not compatible, so disable DCACHE support at
build-time as run-time disable is insufficient for USB use.


Sorry for missing this discussion. I think compile-time disabling of the 
cache is too brutal.
ehci-hcd cache handling is broken anyway: doing unaligned 
flushes/invalidates is a bug, and we know for sure that upper layers 
don't care about alignment (and I bet ehci-hcd does this even for its 
internal buffers). So what's the point in all this cache handling in 
ehci-hcd? It's not going to work anyway and just produces problems. So I 
suggest to just disable all this stuff until generic code will be fixed. 
Alternatively we can do bounce-buffering inside driver.


Regards, Ilya.

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

Re: [U-Boot] ARM CONFIG_OF_CONTROL status

[Simon Glass]

Hi Michal,

On Wed, Jun 27, 2012 at 7:35 AM, Michal Simek  wrote:

> Hi Simon,
>
>
> On 06/27/2012 03:58 PM, Simon Glass wrote:
>
>> Hi,
>>
>>
>> On Wed, Jun 27, 2012 at 2:29 AM, Michal Simek > mon...@monstr.eu>> wrote:
>>
>>Hi,
>>
>>can you please update me about current state of CONFIG_OF_CONTROL for
>> ARM?
>>Are there any other archs/boards which will use this option?
>>
>>Or any other git repo out of mainline u-boot?
>>
>>
>> Exynos is in progress - development is happening in the Chromium tree and
>> being upstreamed in chunks (although no fdt patches have been sent yet).
>>
>
> ok.
>
>
>
>>
>>Has someone tried to look for devices based on compatible property?
>>I see that in usb driver it is based on aliases which is not the best
>> solution.
>>
>>
>> U-Boot doesn't yet have a device model which would allow this in the
>> general case. For now, drivers look for their own compatible nodes. This
>> works well enough until we have a device model.
>>
>> There are other limitations also - for example USB supports only a single
>> controller type working at one time (a restriction we may need to look at
>> to support USB2 and USB3 together). So even if two USB drivers decided that
>> they both found compatible nodes, only one of them could operate. So for
>> now aliases provide just an ordering, nothing else.
>>
>
>
> I have looked at the code and did some tests on Microblaze.
>
> Firstly I have tried to change emaclite ethernet initialization and I
> ended with this code fragment which could be
> broadly used by other drivers.
>
>int offset = 0;
>do {
>offset = fdt_node_offset_by_compatible(**gd->fdt_blob,
> offset, "xlnx,xps-ethernetlite-1.00.a" );
>

You could check if offset < 0 here, or !fdtdec_get_is_enabled(gd->fdt_blob,
offset)


>u32 rxpp = fdtdec_get_int(gd->fdt_blob, offset,
> "xlnx,rx-ping-pong", 0);
>u32 txpp = fdtdec_get_int(gd->fdt_blob, offset,
> "xlnx,tx-ping-pong", 0);
>u32 reg = fdtdec_get_int(gd->fdt_blob, offset, "reg", 0);
>

Maybe fdtdec_get_addr()


>if (reg)
>ret |= xilinx_emaclite_initialize(**bis, reg,
> txpp, rxpp);
>} while (offset != -1);
>
> What do you think? This code is in platform file.
>

Seems reasonable to me.

>
> Also I have tested code around aliases which parse DTS aliases list for
> console initialization
> and I have also get it work for !CONSOLE_SERIAL_MULTI case.
>

Great - I did send a patch to the list for fdt serial, but haven't really
got back to it.

>
> What was the reason to use compat_names table in fdtdec.c file?


Just so there is a simple register of everything that uses fdt in U-Boot -
the enum is used by driver code. If we end up with a lot of support then we
might reconsider one day

Regards,
Simon

>
>
> Thanks,
> Michal
>
>
> --
> Michal Simek, Ing. (M.Eng)
> w: www.monstr.eu p: +42-0-721842854
> Maintainer of Linux kernel 2.6 Microblaze Linux -
> http://www.monstr.eu/fdt/
> Microblaze U-BOOT custodian
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: bugfix: save_boot_params_default accesses uninitalized stack when -O0

[Tetsuyuki Kobayashi]

Hi Tom, thank you for reviewing.

(2012/06/28 2:40), Tom Rini wrote:

On Mon, Jun 25, 2012 at 09:42:29PM +0900, Tetsuyuki Kobayashi wrote:


save_boot_params_default() in cpu.c accesses uninitialized stack area
when it compiled with -O0 (not optimized).

Signed-off-by: Tetsuyuki Kobayashi
---
  arch/arm/cpu/armv7/cpu.c |3 +++
  1 file changed, 3 insertions(+)

diff --git a/arch/arm/cpu/armv7/cpu.c b/arch/arm/cpu/armv7/cpu.c
index c6fa8ef..6104cb2 100644
--- a/arch/arm/cpu/armv7/cpu.c
+++ b/arch/arm/cpu/armv7/cpu.c
@@ -37,8 +37,11 @@
  #include
  #include

+__attribute__((naked)) /* don't save anything to stack even if compiled with 
-O0 */
  void save_boot_params_default(u32 r0, u32 r1, u32 r2, u32 r3)
  {
+   /* stack is not yet initialized */
+   asm("bx lr");
  }


Please add  and use __naked instead.  Thanks!


OK. I will post V2 patch.

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

Re: [U-Boot] [PATCH] arm: bugfix: Move vector table before jumping relocated code

[Tetsuyuki Kobayashi]

Hi Tom and all,

(2012/06/28 3:23), Tom Rini wrote:

On Mon, Jun 25, 2012 at 09:40:57PM +0900, Tetsuyuki Kobayashi wrote:


Interrupts and exceptions doesn't work in relocated code.
It badly use IRQ_STACK_START_IN in rom area as interrupt stack.
It is because the vecotr table is not moved to ram area.
This patch moves vector table before jumping relocated code.

Signed-off-by: Tetsuyuki Kobayashi
---
  arch/arm/cpu/armv7/start.S |   12 
  1 file changed, 12 insertions(+)

diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index 52f7f6e..5098f7b 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -277,6 +277,18 @@ jump_2_ram:
mcr p15, 0, r0, c7, c10, 4  @ DSB
mcr p15, 0, r0, c7, c5, 4   @ ISB
  #endif
+/*
+ * Move vector table
+ */
+#if !defined(CONFIG_TEGRA2)
+#if !(defined(CONFIG_OMAP44XX)&&  defined(CONFIG_SPL_BUILD))
+   /* Set vector address in CP15 VBAR register */
+   ldr r0, =_start
+   add r0, r0, r9
+   mcr p15, 0, r0, c12, c0, 0  @Set VBAR
+#endif
+#endif /* !Tegra2 */
+   
ldr r0, _board_init_r_ofs
adr r1, _start
add lr, r0, r1


I think this code should get boot tested on a few platforms to make sure
it's OK.  As such, I've tried on am335x and omap3 and they're still
fine.

Tested-by: Tom Rini


Tom, thank you for testing.

Easy way to test this patch.
Jump any bad address using go command on U-boot prompt.

Good restult:

> go 0x0badc0de
## Starting application at 0x0BADC0DE ...
undefined instruction
pc : [<0badc0e0>]  lr : [<5ff91354>]
sp : 5feefb98  ip : 001c fp : 5feefbdd
r10: 0002  r9 : 5feefbdd r8 : 5feeff68
r7 : 5feeff14  r6 : 0badc0de r5 : 5feefed4  r4 : 0002
r3 : 0badc0de  r2 : 5feefed4 r1 : 5feefed4  r0 : 0001
Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

resetting ...


Bad result:
> go 0x0badc0de

(.. hang up without any crash dump.)



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

Re: [U-Boot] [PATCH 1/2] bcm: Add GPIO driver for BCM2835 SoC

[Vikram Narayanan]

On 6/27/2012 11:36 PM, Stephen Warren wrote:

On 06/27/2012 11:32 AM, Vikram Narayanan wrote:

Hello Stephen,

On 6/27/2012 7:09 AM, Stephen Warren wrote:

On 06/24/2012 11:21 AM, Vikram Narayanan wrote:

First off, it's great to see some patches for the chip. Thanks. Sorry
for being so nit-picky below; it's a tendency of mine...


Thanks for the detailed review. I'd make a v2 for this.
And I might probably include you in the signed-off-by line.
Hope you don't mind that.


No, you shouldn't add any tags to the patch that refer to other people,
except perhaps a Reported-By, without their explicitly giving those tags.

Also, Signed-off-by wouldn't make sense here since I'm not vouching for
the code or passing it along. Once V2 is posted, I may give an ack or
review tag.


I'm aware of it. :)
Just for the level of details you said to change in the code I said so.
Don't mind that.


Do you have a hosted repo somewhere for this rpi_b stuff?
If so, please post it here or we shall have one, which has all the
patches queued in for the mainline. What do you say? Share your opinions
about this.


I do have a repo. It's at:
https://github.com/swarren/u-boot

However, that's my personal work-space. The RPi patches should
eventually make it into the official U-Boot repositories through the
standard review process. They are:

ARM repo:
git://git.denx.de/u-boot-arm.git

Main repo:
git://git.denx.de/u-boot.git


I'm aware of this too. I'm referring to a public hosting of these RPi 
patches somewhere, so that it could easily be submitted to the mainline 
in _one_ shot. Since your initial SoC support patches aren't added to 
the u-boot-arm, I planned to have everything queued up for submission 
into the mainline *via* the mailing list. Hope you got my point.

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

Re: [U-Boot] [PATCH 2/4] cache_v7: Check for dcache enablement in dcache flush functions

[R, Sricharan]

Aneesh,
[snip..]
 If we are built with D-CACHE enabled but have run 'dcache off' and

 then

 attempt to flush unaligned regions we spam the console with

 problems

 that aren't true (as the cache was off).

>>>    Today we do cache maintenance operations after the dcache is

 turned off.
>>>
>>>    One example is before jumping to kernel, we try to invalidate

 the caches,
>>>
>>>    in cache turned off state. So with this patch those maintenance

 calls will
>>>
>>>    do nothing, which is not correct.
>>
>>
>> Ah yes,  But, shouldn't we be doing these same operations as part of
>> turning the cache off?
>>
>    The problem is that while turning of dcaches, we flush it, and

 turn
>
>   cache and MMU off.  But these operations are not happening
>   automatically in a single call. So there is a chance of  valid
>   entries present in cache even after it is OFF.


 I think this is what we need to fix. Otherwise, Tom's change looks good
 to me. How about an invalidate in dcache_disable() or something like
 that?

>>>  Correct. So if the cleaning up sequence is fine, then ok.
>>>  So there should be no need to check if caches are OFF inside
>>>  the maintenance functions. Kernel does not looks like doing such checks.
>>>  The real issue looks like we should have had assembly level functions
>>>  to do the cleanup routines for flush-invalidate-turn OFF caches/MM
>>> atomically.
>>
>>   Actually, with something like speculation in the behind, only way of
>> ensuring that
>>    we do not have any valid entries is to do a invalidate all, after
>> turn of caches/mmu.
>>    So this means that we will have a maintenance after turning off.
>
>
> Good point. But we need that invalidate just one last time after the
> disable, right? How about making the cache_status a variable rather
> than reading the C bit. And then disable_cache() shall be like this:
>
> 1. Flush all
> 2. Disable C bit
> 3. Invalidate all
> 4. cache_status = disabled
>
> Maybe, not the best solution. But I can't think of anything better.
> Please note that after this point there won't be any valid entries in
> the cache per ARMv7 Architecture reference manual(section B2.2.2):
>
> "If the cache is disabled, it is guaranteed that no new allocation of memory
> locations into the cache will occur."

  I agree on this sequence. But the only thing is, is it good to turn off
  the caches runtime, because one driver cant do aligned access ?
 Will this then not become a custom, say any other driver which
 sees problem with cache, will then simply go ahead disable and proceed.
  Is that right ?.
 yes, having enabled caches we are missing things like UNCACHED allocations,
 IO etc, but that is going to make boot loaders more heavy, may be.

  In the end, I am not sure which is the right decision to take here :)

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

Re: [U-Boot] ARM CONFIG_OF_CONTROL status

[Michal Simek]

Hi Simon,

On 06/28/2012 03:10 AM, Simon Glass wrote:

Hi Michal,

On Wed, Jun 27, 2012 at 7:35 AM, Michal Simek mailto:mon...@monstr.eu>> wrote:

Hi Simon,


On 06/27/2012 03:58 PM, Simon Glass wrote:

Hi,


On Wed, Jun 27, 2012 at 2:29 AM, Michal Simek mailto:mon...@monstr.eu> >> 
wrote:

Hi,

can you please update me about current state of CONFIG_OF_CONTROL 
for ARM?
Are there any other archs/boards which will use this option?

Or any other git repo out of mainline u-boot?


Exynos is in progress - development is happening in the Chromium tree 
and being upstreamed in chunks (although no fdt patches have been sent yet).


ok.




Has someone tried to look for devices based on compatible property?
I see that in usb driver it is based on aliases which is not the 
best solution.


U-Boot doesn't yet have a device model which would allow this in the 
general case. For now, drivers look for their own compatible nodes. This works 
well enough until we have a device model.

There are other limitations also - for example USB supports only a 
single controller type working at one time (a restriction we may need to look 
at to support USB2 and USB3 together). So even if two USB drivers decided that 
they both found compatible nodes, only one of them could operate. So for now 
aliases provide just an ordering, nothing else.



I have looked at the code and did some tests on Microblaze.

Firstly I have tried to change emaclite ethernet initialization and I ended 
with this code fragment which could be
broadly used by other drivers.

int offset = 0;
do {
offset = fdt_node_offset_by_compatible(__gd->fdt_blob, offset, 
"xlnx,xps-ethernetlite-1.00.a" );


You could check if offset < 0 here, or !fdtdec_get_is_enabled(gd->fdt_blob, 
offset)

u32 rxpp = fdtdec_get_int(gd->fdt_blob, offset, 
"xlnx,rx-ping-pong", 0);
u32 txpp = fdtdec_get_int(gd->fdt_blob, offset, 
"xlnx,tx-ping-pong", 0);
u32 reg = fdtdec_get_int(gd->fdt_blob, offset, "reg", 0);


Maybe fdtdec_get_addr()


yeah right.

do {
offset = fdt_node_offset_by_compatible(gd->fdt_blob, offset, 
"xlnx,xps-ethernetlite-1.00.a" );
u32 rxpp = fdtdec_get_int(gd->fdt_blob, offset, 
"xlnx,rx-ping-pong", 0);
u32 txpp = fdtdec_get_int(gd->fdt_blob, offset, 
"xlnx,tx-ping-pong", 0);
u32 reg = fdtdec_get_addr(gd->fdt_blob, offset, "reg");
if (reg != FDT_ADDR_T_NONE)
ret |= xilinx_emaclite_initialize(bis, reg, txpp, rxpp);
} while (offset != -1);





if (reg)
ret |= xilinx_emaclite_initialize(__bis, reg, txpp, 
rxpp);
} while (offset != -1);

What do you think? This code is in platform file.


Seems reasonable to me.


ok.




Also I have tested code around aliases which parse DTS aliases list for 
console initialization
and I have also get it work for !CONSOLE_SERIAL_MULTI case.


Great - I did send a patch to the list for fdt serial, but haven't really got 
back to it.



Can you give me link to it or just subject?





What was the reason to use compat_names table in fdtdec.c file?


Just so there is a simple register of everything that uses fdt in U-Boot - the 
enum is used by driver code. If we end up with a lot of support then we might 
reconsider one day


Is it requirement that all new drivers should extend this table?
Because from my point of view is just this not necessary to do.
Based on function above this is enough for drivers to be probed.

Thanks,
Michal

--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ARM CONFIG_OF_CONTROL status

[Simon Glass]

Hi Michal,

On Wed, Jun 27, 2012 at 10:50 PM, Michal Simek  wrote:

> Hi Simon,
>
>
> On 06/28/2012 03:10 AM, Simon Glass wrote:
>
>> Hi Michal,
>>
>>
>> On Wed, Jun 27, 2012 at 7:35 AM, Michal Simek > mon...@monstr.eu>> wrote:
>>
>>Hi Simon,
>>
>>
>>On 06/27/2012 03:58 PM, Simon Glass wrote:
>>
>>Hi,
>>
>>
>>On Wed, Jun 27, 2012 at 2:29 AM, Michal Simek 
>> > mon...@monstr.eu> >>
>> wrote:
>>
>>Hi,
>>
>>can you please update me about current state of
>> CONFIG_OF_CONTROL for ARM?
>>Are there any other archs/boards which will use this option?
>>
>>Or any other git repo out of mainline u-boot?
>>
>>
>>Exynos is in progress - development is happening in the Chromium
>> tree and being upstreamed in chunks (although no fdt patches have been sent
>> yet).
>>
>>
>>ok.
>>
>>
>>
>>
>>Has someone tried to look for devices based on compatible
>> property?
>>I see that in usb driver it is based on aliases which is not
>> the best solution.
>>
>>
>>U-Boot doesn't yet have a device model which would allow this in
>> the general case. For now, drivers look for their own compatible nodes.
>> This works well enough until we have a device model.
>>
>>There are other limitations also - for example USB supports only a
>> single controller type working at one time (a restriction we may need to
>> look at to support USB2 and USB3 together). So even if two USB drivers
>> decided that they both found compatible nodes, only one of them could
>> operate. So for now aliases provide just an ordering, nothing else.
>>
>>
>>
>>I have looked at the code and did some tests on Microblaze.
>>
>>Firstly I have tried to change emaclite ethernet initialization and I
>> ended with this code fragment which could be
>>broadly used by other drivers.
>>
>>int offset = 0;
>>do {
>>offset = fdt_node_offset_by_compatible(**__gd->fdt_blob,
>> offset, "xlnx,xps-ethernetlite-1.00.a" );
>>
>>
>>
>> You could check if offset < 0 here, or !fdtdec_get_is_enabled(gd->**fdt_blob,
>> offset)
>>
>>u32 rxpp = fdtdec_get_int(gd->fdt_blob, offset,
>> "xlnx,rx-ping-pong", 0);
>>u32 txpp = fdtdec_get_int(gd->fdt_blob, offset,
>> "xlnx,tx-ping-pong", 0);
>>u32 reg = fdtdec_get_int(gd->fdt_blob, offset, "reg",
>> 0);
>>
>>
>> Maybe fdtdec_get_addr()
>>
>
> yeah right.
>
>
>do {
>offset = fdt_node_offset_by_compatible(**gd->fdt_blob,
> offset, "xlnx,xps-ethernetlite-1.00.a" );
>u32 rxpp = fdtdec_get_int(gd->fdt_blob, offset,
> "xlnx,rx-ping-pong", 0);
>u32 txpp = fdtdec_get_int(gd->fdt_blob, offset,
> "xlnx,tx-ping-pong", 0);
>u32 reg = fdtdec_get_addr(gd->fdt_blob, offset, "reg");
>if (reg != FDT_ADDR_T_NONE)
>
>ret |= xilinx_emaclite_initialize(**bis, reg,
> txpp, rxpp);
>} while (offset != -1);
>
>
>
>
>>if (reg)
>>ret |= xilinx_emaclite_initialize(__**bis,
>> reg, txpp, rxpp);
>>
>>} while (offset != -1);
>>
>>What do you think? This code is in platform file.
>>
>>
>> Seems reasonable to me.
>>
>
> ok.
>
>
>
>>
>>Also I have tested code around aliases which parse DTS aliases list
>> for console initialization
>>and I have also get it work for !CONSOLE_SERIAL_MULTI case.
>>
>>
>> Great - I did send a patch to the list for fdt serial, but haven't really
>> got back to it.
>>
>
>
> Can you give me link to it or just subject?


WIP: fdt: Add serial port controlled by device tree

These are the related commits in the Chromium tree. I will get to
upstreaming these at some point.

 1fe36bf gen: serial: Disable FDT serial console if requested
c80331f gen: Adjust fdt console to be silent if no alias present
2006b07 gen: fdt: Add serial port controlled by device tree
711f29d fixup: gen: fdt: Fix compile-time errors
0c8fc5d lost: gen: x86: Allow NS16550 driver to support IO and memory
mapped reg
da92af5 gen: Fix a compiler warning in serial_fdt.c
ab1d572 gen: fdt: silence console in response to device tree 'silent' option
376c215 lost: gen: fdt: Add serial port controlled by device tree


>
>
>
>>
>>What was the reason to use compat_names table in fdtdec.c file?
>>
>>
>> Just so there is a simple register of everything that uses fdt in U-Boot
>> - the enum is used by driver code. If we end up with a lot of support then
>> we might reconsider one day
>>
>
> Is it requirement that all new drivers should extend this table?
> Because from my point of view is just this not necessary to do.
> Based on function above this is enough for drivers to be probed.


Fair enough. If you don't want to I don't see why it should be a hard
requirement.

Regards,
Simon


>
>
> Thanks,
> Michal
>
> --
> Michal Simek, I

[U-Boot] [PATCH] tools/mkenvimage.c: fix basename(3) usage

[Andreas Bießmann]

Use the POSIX variant of basename due to BSD systems (e.g. OS X) do not provide
GNU version of basename(3). It is save to use the POSIX variant here cause we do
never use argv[0] later on which may be modified by the basename(3) POSIX
variant.
On systems providing GNU variant the GNU variant should be used since string.h
is included before libgen.h. Therefore let the _GNU_SOURCE as is.

This patch fixes following warning (on OS X):
---8<---
mkenvimage.c: In function ‘main’:
mkenvimage.c:105: warning: implicit declaration of function ‘basename’
mkenvimage.c:105: warning: assignment makes pointer from integer without a cast
--->8---

Signed-off-by: Andreas Bießmann 
cc: Keith Mok 
---
This was sent by Keith Mok before. Read
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/126003

 tools/mkenvimage.c | 1 +
 1 Datei geändert, 1 Zeile hinzugefügt(+)

diff --git a/tools/mkenvimage.c b/tools/mkenvimage.c
index bfc4eb6..5521268 100644
--- a/tools/mkenvimage.c
+++ b/tools/mkenvimage.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
1.7.11

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

[U-Boot] NAND DMA timed out with i.mx boot source code.

[alex]

Hi:
  I have one board which hardware copied from mx28evk board, and compiled the 
source code cloned from u-boot mainline git. The rom in mx28 print 0x80508008, 
that is "NAND DMA timed out".  I compile the source from u-boot-testing, and 
it's no any wrong print, and the start is OK. I don't know why result in this 
issue.

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

[U-Boot] U-boot support for versatile express cortex a-15

[Kumar Sourav]

Does u-boot support the arm board versatile express cortex
A-15(V2P-CA15x2)?If not is there anyway to port it to this board?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] U-boot support for versatile express cortex a-15

[Kumar Sourav]

Does u-boot support the arm board versatile express cortex
A-15(V2P-CA15x2)?If not is there anyway to port it to this board?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ARM CONFIG_OF_CONTROL status

[Michal Simek]

On 06/28/2012 07:57 AM, Simon Glass wrote:

Hi Michal,

On Wed, Jun 27, 2012 at 10:50 PM, Michal Simek mailto:mon...@monstr.eu>> wrote:

Hi Simon,


On 06/28/2012 03:10 AM, Simon Glass wrote:

Hi Michal,


On Wed, Jun 27, 2012 at 7:35 AM, Michal Simek mailto:mon...@monstr.eu> >> 
wrote:

Hi Simon,


On 06/27/2012 03:58 PM, Simon Glass wrote:

Hi,


On Wed, Jun 27, 2012 at 2:29 AM, Michal Simek mailto:mon...@monstr.eu> 
>  
fdt_blob, 
offset, "xlnx,xps-ethernetlite-1.00.a" );



You could check if offset < 0 here, or 
!fdtdec_get_is_enabled(gd->__fdt_blob, offset)

u32 rxpp = fdtdec_get_int(gd->fdt_blob, offset, 
"xlnx,rx-ping-pong", 0);
u32 txpp = fdtdec_get_int(gd->fdt_blob, offset, 
"xlnx,tx-ping-pong", 0);
u32 reg = fdtdec_get_int(gd->fdt_blob, offset, 
"reg", 0);


Maybe fdtdec_get_addr()


yeah right.


do {
offset = fdt_node_offset_by_compatible(__gd->fdt_blob, offset, 
"xlnx,xps-ethernetlite-1.00.a" );
u32 rxpp = fdtdec_get_int(gd->fdt_blob, offset, 
"xlnx,rx-ping-pong", 0);
u32 txpp = fdtdec_get_int(gd->fdt_blob, offset, 
"xlnx,tx-ping-pong", 0);
u32 reg = fdtdec_get_addr(gd->fdt_blob, offset, "reg");
if (reg != FDT_ADDR_T_NONE)

ret |= xilinx_emaclite_initialize(__bis, reg, txpp, 
rxpp);
} while (offset != -1);




if (reg)
ret |= xilinx_emaclite_initialize(bis, 
reg, txpp, rxpp);

} while (offset != -1);

What do you think? This code is in platform file.


Seems reasonable to me.


ok.




Also I have tested code around aliases which parse DTS aliases list 
for console initialization
and I have also get it work for !CONSOLE_SERIAL_MULTI case.


Great - I did send a patch to the list for fdt serial, but haven't 
really got back to it.



Can you give me link to it or just subject?


WIP: fdt: Add serial port controlled by device tree

These are the related commits in the Chromium tree. I will get to upstreaming 
these at some point.

  1fe36bf gen: serial: Disable FDT serial console if requested
c80331f gen: Adjust fdt console to be silent if no alias present
2006b07 gen: fdt: Add serial port controlled by device tree
711f29d fixup: gen: fdt: Fix compile-time errors
0c8fc5d lost: gen: x86: Allow NS16550 driver to support IO and memory mapped reg
da92af5 gen: Fix a compiler warning in serial_fdt.c
ab1d572 gen: fdt: silence console in response to device tree 'silent' option
376c215 lost: gen: fdt: Add serial port controlled by device tree



Can you also send me link to Chromium tree?

I am going to send RFC for emaclite driver and cleanup Microblaze port.

Thanks,
Michal


--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT cust

[U-Boot] [PATCH] sh: ap_sh4a_4a: Fix wrong register initialization value

[Nobuhiro Iwamatsu]

The value of ET0_ERXD6 and GPSR1_INIT was wrong.
This fixes them.

Signed-off-by: Nobuhiro Iwamatsu 
---
 board/alphaproject/ap_sh4a_4a/ap_sh4a_4a.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/board/alphaproject/ap_sh4a_4a/ap_sh4a_4a.c 
b/board/alphaproject/ap_sh4a_4a/ap_sh4a_4a.c
index 77cadea..ff37df1 100644
--- a/board/alphaproject/ap_sh4a_4a/ap_sh4a_4a.c
+++ b/board/alphaproject/ap_sh4a_4a/ap_sh4a_4a.c
@@ -90,7 +90,7 @@ int checkboard(void)
 /* IPSR11 */
 #define ET0_ERXD4  (0x4 <<  4)
 #define ET0_ERXD5  (0x4 <<  7)
-#define ET0_ERXD6  (0x4 <<  4)
+#define ET0_ERXD6  (0x3 << 10)
 #define ET0_TX_EN  (0x2 << 19)
 #define ET0_TX_ER  (0x2 << 21)
 #define ET0_TX_CLK_A (0x4 << 23)
@@ -99,7 +99,7 @@ int checkboard(void)
(ET0_ERXD4 | ET0_ERXD5 | ET0_ERXD6 | ET0_TX_EN | ET0_TX_ER | \
ET0_TX_CLK_A | ET0_RX_CLK_A)
 
-#define GPSR1_INIT (0xFFBF7FFF)
+#define GPSR1_INIT (0x7FFF)
 #define GPSR2_INIT (0x4005FEFF)
 #define GPSR3_INIT (0x2EFF)
 #define GPSR4_INIT (0xC700)
-- 
1.7.10

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