Re: [U-Boot] USB on mx53

[Stefano Babic]

On 16/07/2012 08:26, Andreas Salvisberg wrote:
> Dear Mr. Babic
> 
>  

Hi,

please use the U-Boot ML for U-Boot related questions. You will find
much more help than asking to a single person and your questions can
interest many other people.

> 
> I try to run a USB Host on a i.MX53 Board. Unfortunately USB does not
> work. I got the following error message: „EHCI timed out on TD -
> token=0x80008c80“.
> 
>  
> 
> On a discussion on GMANE I found a post of you, that you run USB on a
> mx53_loco.
> 
> Can you tell me on which source base you are working?

I tested when patches were submitted on a MX53QSB. I have tried now, and
USB seems working.


U-Boot 2011.12-00518-gf56cab3 (Mar 23 2012 - 13:03:38)

CPU:   Freescale i.MX53 rev2.1 at 800 MHz
Reset cause: POR
Board: MX53 LOCO
DRAM:  1 GiB
WARNING: Caches not enabled
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
In:serial
Out:   serial
Err:   serial
Net:   FEC
Hit any key to stop autoboot:  0
MX53LOCO U-Boot > usb start
(Re)start USB...
USB:   Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... 2 USB Device(s) found
   scanning bus for storage devices... 1 Storage Device(s) found
   scanning bus for ethernet devices... 0 Ethernet Device(s) found

However, with last TOT I get errors:

ERROR: v7_dcache_inval_range - stop address is not aligned - 0xaf56b960

and of course it is not working. Some "git bisect" is needed here...

> 
> Do you use the UBoot sources from Freescale?

Absolutely not, only mainline U-Boot.

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

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

Re: [U-Boot] DaVinci PHYs

[Heiko Schocher]

Hello Marek,

added Tom Rini to cc, as he is the ti maintainer ...

On 15.07.2012 15:42, Marek Vasut wrote:

Hi guys,

is there any hope the ad-hoc implementation of davinci emac PHYs will ever be
flipped to phylib ?


I currently have no such job in sight ...

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

Re: [U-Boot] [PATCH V2 3/8] ehci-hcd.c, musb_core, usb.h: Add USB_DMA_MINALIGN define for cache alignment

[Ilya Yanok]

Dear Marek,

ok, I finally managed to fix it. Will post the patches in a few seconds.

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

[U-Boot] [PATCH] ehci-hcd: program asynclistaddr before every transfer

[Ilya Yanok]

Move or_asynclistaddr programming to ehci_submit_async()
function to make sure queue head is properly programmed
before every transfer. This solves the problem with changing
qh address.

Also remove unneeded qh_list->qh_link reprogramming at the
end of transfer.

Signed-off-by: Ilya Yanok 
---
 drivers/usb/host/ehci-hcd.c |8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 04300be..3be2a77 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -348,6 +348,9 @@ ehci_submit_async(struct usb_device *dev, unsigned long 
pipe, void *buffer,
flush_dcache_range((uint32_t)&qh, (uint32_t)&qh + sizeof(struct QH));
flush_dcache_range((uint32_t)qtd, (uint32_t)qtd + sizeof(qtd));
 
+   /* Set async. queue head pointer. */
+   ehci_writel(&hcor->or_asynclistaddr, (uint32_t)&qh_list);
+
usbsts = ehci_readl(&hcor->or_usbsts);
ehci_writel(&hcor->or_usbsts, (usbsts & 0x3f));
 
@@ -403,8 +406,6 @@ ehci_submit_async(struct usb_device *dev, unsigned long 
pipe, void *buffer,
goto fail;
}
 
-   qh_list.qh_link = cpu_to_hc32((uint32_t)&qh_list | QH_LINK_TYPE_QH);
-
token = hc32_to_cpu(qh.qh_overlay.qt_token);
if (!(token & 0x80)) {
debug("TOKEN=%#x\n", token);
@@ -741,9 +742,6 @@ int usb_lowlevel_init(void)
qh_list.qh_overlay.qt_altnext = cpu_to_hc32(QT_NEXT_TERMINATE);
qh_list.qh_overlay.qt_token = cpu_to_hc32(0x40);
 
-   /* Set async. queue head pointer. */
-   ehci_writel(&hcor->or_asynclistaddr, (uint32_t)&qh_list);
-
reg = ehci_readl(&hccr->cr_hcsparams);
descriptor.hub.bNbrPorts = HCS_N_PORTS(reg);
printf("Register %x NbrPorts %d\n", reg, descriptor.hub.bNbrPorts);
-- 
1.7.9.5

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

[U-Boot] [PATCH V2a 3/8] ehci-hcd.c, musb_core, usb.h: Add USB_DMA_MINALIGN define for cache alignment

[Ilya Yanok]

From: Tom Rini 

The USB spec says that 32 bytes is the minimum required alignment.
However on some platforms we have a larger minimum requirement for cache
coherency.  In those cases, use that value rather than the USB spec
minimum.  We add a cpp check to  to define USB_DMA_MINALIGN and
make use of it in ehci-hcd.c and musb_core.h.  We cannot use MAX() here
as we are not allowed to have tests inside of align(...).

Signed-off-by: Tom Rini 
[marek.vasut]: introduce some crazy macro voodoo
Signed-off-by: Marek Vasut 
[ilya.yanok]: moved external buffer fixes to separate patch,
we use {ALLOC,DEFINE}_ALIGN_BUFFER macros with alignment of USB_DMA_MINALIGN
for qh_list, qh and qtd structures to make sure they are proper aligned
for both controller and cache operations.
Signed-off-by: Ilya Yanok 
---
Changes from V2:
 - qh struct made non-static

 drivers/usb/host/ehci-hcd.c  |   61 ++
 drivers/usb/musb/musb_core.h |2 +-
 include/usb.h|   10 +++
 3 files changed, 43 insertions(+), 30 deletions(-)

diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 3be2a77..2b46662 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -34,7 +34,10 @@ struct ehci_hccr *hccr;  /* R/O registers, not need for 
volatile */
 volatile struct ehci_hcor *hcor;
 
 static uint16_t portreset;
-static struct QH qh_list __attribute__((aligned(32)));
+DEFINE_ALIGN_BUFFER(struct QH, qh_list, 1, USB_DMA_MINALIGN);
+
+#define ALIGN_END_ADDR(type, ptr, size)\
+   ((uint32_t)(ptr) + roundup((size) * sizeof(type), USB_DMA_MINALIGN))
 
 static struct descriptor {
struct usb_hub_descriptor hub;
@@ -207,8 +210,8 @@ static int
 ehci_submit_async(struct usb_device *dev, unsigned long pipe, void *buffer,
   int length, struct devrequest *req)
 {
-   static struct QH qh __attribute__((aligned(32)));
-   static struct qTD qtd[3] __attribute__((aligned (32)));
+   ALLOC_ALIGN_BUFFER(struct QH, qh, 1, USB_DMA_MINALIGN);
+   ALLOC_ALIGN_BUFFER(struct qTD, qtd, 3, USB_DMA_MINALIGN);
int qtd_counter = 0;
 
volatile struct qTD *vtd;
@@ -229,8 +232,8 @@ ehci_submit_async(struct usb_device *dev, unsigned long 
pipe, void *buffer,
  le16_to_cpu(req->value), le16_to_cpu(req->value),
  le16_to_cpu(req->index));
 
-   memset(&qh, 0, sizeof(struct QH));
-   memset(qtd, 0, sizeof(qtd));
+   memset(qh, 0, sizeof(struct QH));
+   memset(qtd, 0, 3 * sizeof(*qtd));
 
toggle = usb_gettoggle(dev, usb_pipeendpoint(pipe), usb_pipeout(pipe));
 
@@ -244,7 +247,7 @@ ehci_submit_async(struct usb_device *dev, unsigned long 
pipe, void *buffer,
 *   qh_overlay.qt_next .. 13-10 H
 * - qh_overlay.qt_altnext
 */
-   qh.qh_link = cpu_to_hc32((uint32_t)&qh_list | QH_LINK_TYPE_QH);
+   qh->qh_link = cpu_to_hc32((uint32_t)qh_list | QH_LINK_TYPE_QH);
c = (usb_pipespeed(pipe) != USB_SPEED_HIGH &&
 usb_pipeendpoint(pipe) == 0) ? 1 : 0;
endpt = (8 << 28) |
@@ -255,14 +258,14 @@ ehci_submit_async(struct usb_device *dev, unsigned long 
pipe, void *buffer,
(usb_pipespeed(pipe) << 12) |
(usb_pipeendpoint(pipe) << 8) |
(0 << 7) | (usb_pipedevice(pipe) << 0);
-   qh.qh_endpt1 = cpu_to_hc32(endpt);
+   qh->qh_endpt1 = cpu_to_hc32(endpt);
endpt = (1 << 30) |
(dev->portnr << 23) |
(dev->parent->devnum << 16) | (0 << 8) | (0 << 0);
-   qh.qh_endpt2 = cpu_to_hc32(endpt);
-   qh.qh_overlay.qt_next = cpu_to_hc32(QT_NEXT_TERMINATE);
+   qh->qh_endpt2 = cpu_to_hc32(endpt);
+   qh->qh_overlay.qt_next = cpu_to_hc32(QT_NEXT_TERMINATE);
 
-   tdp = &qh.qh_overlay.qt_next;
+   tdp = &qh->qh_overlay.qt_next;
 
if (req != NULL) {
/*
@@ -340,16 +343,16 @@ ehci_submit_async(struct usb_device *dev, unsigned long 
pipe, void *buffer,
tdp = &qtd[qtd_counter++].qt_next;
}
 
-   qh_list.qh_link = cpu_to_hc32((uint32_t)&qh | QH_LINK_TYPE_QH);
+   qh_list->qh_link = cpu_to_hc32((uint32_t)qh | QH_LINK_TYPE_QH);
 
/* Flush dcache */
-   flush_dcache_range((uint32_t)&qh_list,
-   (uint32_t)&qh_list + sizeof(struct QH));
-   flush_dcache_range((uint32_t)&qh, (uint32_t)&qh + sizeof(struct QH));
-   flush_dcache_range((uint32_t)qtd, (uint32_t)qtd + sizeof(qtd));
+   flush_dcache_range((uint32_t)qh_list,
+   ALIGN_END_ADDR(struct QH, qh_list, 1));
+   flush_dcache_range((uint32_t)qh, ALIGN_END_ADDR(struct QH, qh, 1));
+   flush_dcache_range((uint32_t)qtd, ALIGN_END_ADDR(struct qTD, qtd, 3));
 
/* Set async. queue head pointer. */
-   ehci_writel(&hcor->or_asynclistaddr, (uint32_t)&qh_list);
+   ehci_writel(&hcor->or_asynclistaddr, (uint32_t)qh_list);
 
usbsts = ehci_readl(&hcor->

[U-Boot] Uboot and initramfs

[Wojtek]

Hi,

I'm struggling with the topic for long two days and I want to ask for help.

I have a DNS-320 system with u-boot. I compiled kernel and it works 
well, but I need initramfs. I prepared contents on this system (ARM) (no 
need to cross-compile), then did:


find . -print0 | cpio --null -ov --format=newc | gzip -9 > initramfs
mkimage -A arm -O linux -T ramdisk -C gzip -n "Some name" -d initramfs 
initramfs.kwb


flash_eraseall /dev/mtd2
nandwrite -p /dev/mtd2 ./initramfs.kwb

reboot

Marvell_DNS320>> nand read.e 0xa0 0x10 0x20

NAND read: device 0 offset 0x10, size 0x20 load addr   =a0

 2097152 bytes read: OK
Marvell_DNS320>> nand read.e 0xf0 0x60 0x50

NAND read: device 0 offset 0x60, size 0x50 load addr   =f0

 5242880 bytes read: OK
Marvell_DNS320>> bootm 0xa0 0xf0
## Booting image at 00a0 ...
   Image Name:   Linux-3.4.4
   Created:  2012-07-08  11:45:53 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:2039456 Bytes =  1.9 MB
   Load Address: 8000
   Entry Point:  8000
   Verifying Checksum ... OK
OK
## Loading Ramdisk Image at 0f0 ...
   Image Name:   Initramfs 3.4.4
   Created:  2012-07-15  16:08:35 UTC
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:4816677 Bytes =  4.6 MB
   Load Address: 
   Entry Point:  
   Verifying Checksum ... OK

Starting kernel ...

And here it hangs.


If I skip passing initramfs system boots properly.
What is wrong?

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

Re: [U-Boot] [PATCH v2 0/4] mmc: Support designWare Controller

[Minkyu Kang]

Dear Andy,

On 9 July 2012 11:45, Jaehoon Chung  wrote:
> Hi Andy,
>
> Could you merge these series?
> If you don't mind, could we merge this at u-boot-samsung?
> To use the exynos5, must enable the DesignWare Controller for eMMC.
>
> Best Regards,
> Jaehoon Chung
>
> On 07/03/2012 04:57 PM, Jaehoon Chung wrote:
>
>> Include mmc:dw-mmc:support DesignWare MMC controller at this patchset.
>> dw-mmc.c is generic interface.(like sdhci.c)
>> For using dw-mmc controller, need to add the some samsung specific code.
>> Exynos specific code should be presented into exynos_dw_mmc.c
>>

If you are OK.
I'll merge this patchset to u-boot-samsung.

Thanks.
Minkyu Kang.
-- 
from. prom.
www.promsoft.net
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] mxc_i2c: remove setting speed at each start

[Stefano Babic]

On 13/07/2012 12:38, Marek Vasut wrote:
> Dear Dirk Behme,
> 
> [...]
> 
>>> Ok, everything was already clear, and I can also add my:
>>>
>>> Acked-by: Stefano Babic 
>>
>> Same for this one: Is this applied anywhere? It doesn't seem to be part
>> of v2012.07-rc1?
>>
>> Best regards
> 
> Stefano, once you're out of mont blanc, can you apply this please?

It is applied into u-boot-i2c, it will be merged directly into mainline
ny next Heiko's pull request.

Best regards,
Stefano


-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

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

[U-Boot] [PATCH] kirkwood: add support for Iomega iConnect board

[Luka Perkov]

Add support for new board iConnect from Iomega.

More information about the device can be found here:

http://go.iomega.com/en/products/network-storage-desktop/wireless-data-station/network-hard-drive-iconnect/?partner=4735

Signed-off-by: Luka Perkov 
Tested-by: Wojciech Dubowik 
Tested-by: Tim Fletcher 
---

 MAINTAINERS|1 +
 board/iomega/iconnect/Makefile |   43 ++
 board/iomega/iconnect/iconnect.c   |  107 +++
 board/iomega/iconnect/iconnect.h   |   39 +
 board/iomega/iconnect/kwbimage.cfg |  165 
 boards.cfg |1 +
 include/configs/iconnect.h |  131 
 7 files changed, 487 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index fd0c65c..9e9d8d7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -787,6 +787,7 @@ Linus Walleij 
 Luka Perkov 
 
ib62x0  ARM926EJS
+   iconnectARM926EJS
 
 Dave Peverley 
 
diff --git a/board/iomega/iconnect/Makefile b/board/iomega/iconnect/Makefile
new file mode 100644
index 000..f77fcfb
--- /dev/null
+++ b/board/iomega/iconnect/Makefile
@@ -0,0 +1,43 @@
+#
+# (C) Copyright 2009
+# Marvell Semiconductor 
+# Written-by: Prafulla Wadaskar 
+#
+# 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, see .
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS  := iconnect.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/iomega/iconnect/iconnect.c b/board/iomega/iconnect/iconnect.c
new file mode 100644
index 000..6ee3b84
--- /dev/null
+++ b/board/iomega/iconnect/iconnect.c
@@ -0,0 +1,107 @@
+/*
+ * Copyright (C) 2009-2012
+ * Wojciech Dubowik 
+ * Luka Perkov 
+ *
+ * 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, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "iconnect.h"
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int board_early_init_f(void)
+{
+   /*
+* default gpio configuration
+* There are maximum 64 gpios controlled through 2 sets of registers
+* the below configuration configures mainly initial LED status
+*/
+   kw_config_gpio(ICONNECT_OE_VAL_LOW,
+   ICONNECT_OE_VAL_HIGH,
+   ICONNECT_OE_LOW, ICONNECT_OE_HIGH);
+
+   /* Multi-Purpose Pins Functionality configuration */
+   u32 kwmpp_config[] = {
+   MPP0_NF_IO2,
+   MPP1_NF_IO3,
+   MPP2_NF_IO4,
+   MPP3_NF_IO5,
+   MPP4_NF_IO6,
+   MPP5_NF_IO7,
+   MPP6_SYSRST_OUTn,
+   MPP7_GPO,
+   MPP8_TW_SDA,
+   MPP9_TW_SCK,
+   MPP10_UART0_TXD,
+   MPP11_UART0_RXD,
+   MPP12_GPO,
+   MPP13_SD_CMD,
+   MPP14_SD_D0,
+   MPP15_SD_D1,
+   MPP16_SD_D2,
+   MPP17_SD_D3,
+   MPP18_NF_IO0,
+   MPP19_NF_IO1,
+   MPP20_GE1_0,
+   MPP21_GE1_1,
+   MPP22_GE1_2,
+   MPP23_GE1_3,
+   MPP24_GE1_4,
+   MPP25_GE1_5,
+   MPP26_GE1_6,
+   MPP27_GE1_7,
+

Re: [U-Boot] [PATCH v2 1/2] imx: Use a clear identification of an unidentified CPU type

[Stefano Babic]

On 30/06/2012 17:07, Otavio Salvador wrote:
> In case an unidentified CPU type is detected it now returns
> i.MX??, in a const char.
> 
> Signed-off-by: Otavio Salvador 
> Cc: Marek Vasut 
> Cc: Stefano Babic 
> Cc: Fabio Estevam 
> 
> ---

Applied to u-boot-imx, next branch, thanks.

Best regards,
Stefano Babic


-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

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

Re: [U-Boot] [PATCH v3 2/2] mxs: generalize code for print_cpuinfo()

[Stefano Babic]

On 30/06/2012 17:07, Otavio Salvador wrote:
> The information now is gathered from HW_DIGCTL_CHIPID register and
> includes the revision of the chip on the output.
> 
> Signed-off-by: Otavio Salvador 
> Cc: Marek Vasut 
> Cc: Stefano Babic 
> Cc: Fabio Estevam 
> 
> ---


Hi Otavio,

could you take a look and rebase it ? It does not apply anymore - thanks.

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

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

Re: [U-Boot] [PATCH V2 3/8] ehci-hcd.c, musb_core, usb.h: Add USB_DMA_MINALIGN define for cache alignment

[Marek Vasut]

Dear Ilya Yanok,

> Dear Marek,
> 
> ok, I finally managed to fix it. Will post the patches in a few seconds.

So the link I sent you was true afterall ? :)

What was the problem? I'll pick the patches for -next though, unless we're 100% 
definitelly sure they won't break anything else.

> 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 v2 0/4] Board support and feature for LaCie devices

[Simon Guinot]

On Wed, Jun 06, 2012 at 01:16:49AM +0200, Simon Guinot wrote:
> Changes for v2:
>  - Move board support and feature into a separate patch set.
>  - Move mach-types update into a separate patch.
> 
> Simon Guinot (4):
>   lacie_kw: add support for EFI partitions
>   ARM: add netspace_mini_v2 to mach-types.h
>   ARM: add support for Network Space v2 Lite and Mini
>   ARM: add support for d2 Network v2
> 
>  arch/arm/include/asm/mach-types.h |   13 +++
>  board/LaCie/common/common.c   |   36 ++-
>  board/LaCie/common/common.h   |1 +
>  board/LaCie/netspace_v2/kwbimage-ns2l.cfg |  162 
> +
>  board/LaCie/netspace_v2/netspace_v2.c |4 +
>  boards.cfg|3 +
>  include/configs/lacie_kw.h|   42 ++--
>  7 files changed, 252 insertions(+), 9 deletions(-)
>  create mode 100644 board/LaCie/netspace_v2/kwbimage-ns2l.cfg

Hi Prafulla,

What is the next step for this patches ?
Do you want me for some changes ?

Regards,

Simon

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


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

Re: [U-Boot] [PATCH v3 2/2] mxs: generalize code for print_cpuinfo()

[Otavio Salvador]

On Mon, Jul 16, 2012 at 8:04 AM, Stefano Babic  wrote:
> On 30/06/2012 17:07, Otavio Salvador wrote:
>> The information now is gathered from HW_DIGCTL_CHIPID register and
>> includes the revision of the chip on the output.
>
> could you take a look and rebase it ? It does not apply anymore - thanks.

Sure; I splitted it to apply i.MX28 part for now and leave i.MX233
info for the another patchset. Will send it.

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

Re: [U-Boot] DaVinci PHYs

[Tom Rini]

On 07/16/2012 12:33 AM, Heiko Schocher wrote:
> Hello Marek,
> 
> added Tom Rini to cc, as he is the ti maintainer ...
> 
> On 15.07.2012 15:42, Marek Vasut wrote:
>> Hi guys,
>>
>> is there any hope the ad-hoc implementation of davinci emac PHYs will
>> ever be
>> flipped to phylib ?
> 
> I currently have no such job in sight ...

The last time someone wanted to add a new phy to the driver I asked them
to investigate and switch over to phylib.  That's about as far as it's
gotten.

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

Re: [U-Boot] [PATCH 3/3 V2] MX28: SPI: Add DMA transfer support

[Stefano Babic]

On 09/07/2012 12:48, Marek Vasut wrote:
> The DMA transfers happen only if the transfered data are larger
> than 512 bytes. Otherwise PIO is used. This is a small speed
> optimization.
> 
> The DMA transfer doesn't work if unaligned transfer is requested
> due to the limitation of the DMA controller. This has to be fixed
> by introducing generic bounce buffer. Therefore the DMA feature
> is now disabled by default.
> 
> Signed-off-by: Marek Vasut 
> Cc: Fabio Estevam 
> Cc: Otavio Salvador 
> Cc: Stefano Babic 
> Cc: Wolfgang Denk 
> ---

Applied to u-boot-imx, next branch, thanks.

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

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

Re: [U-Boot] [PATCH 1/3 V2] MX28: SPI: Refactor spi_xfer a bit

[Stefano Babic]

On 09/07/2012 12:48, Marek Vasut wrote:
> This makes it easier to adapt for addition of DMA support.
> 
> Signed-off-by: Marek Vasut 
> Cc: Fabio Estevam 
> Cc: Otavio Salvador 
> Cc: Stefano Babic 
> Cc: Wolfgang Denk 
> ---

Applied to u-boot-imx, next branch, thanks.

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

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

Re: [U-Boot] [PATCH 2/3 RESEND] MX28: SPI: Pull out the PIO transfer function

[Stefano Babic]

On 09/07/2012 12:48, Marek Vasut wrote:
> Pull out all the PIO transfer logic into separate function,
> so DMA can be added.
> 
> Signed-off-by: Marek Vasut 
> Cc: Fabio Estevam 
> Cc: Otavio Salvador 
> Cc: Stefano Babic 
> Cc: Wolfgang Denk 
> ---

Applied to u-boot-imx, next branch, thanks.

Best regards,
Stefano Babic



-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

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

Re: [U-Boot] [PATCH 12/20] arm/km: add support for external switchconfiguration

[Detlev Zundel]

Hi,

>> How about amending the U-Boot design principles with 
>
> Go for it - it's a wiki.

Thinking about it, I turned it not into a rule, but into a Lemma from
the 10 rules:

  Lemmas from the golden rules
  
  1. Generic Code is Good Code
  
  New code shall be as generic as possible and added to the U-Boot
  abstraction hierarchy as high as possible. As few code as possible shall
  be added in board directories as people usually do not expect re-usable
  code there. Thus peripheral drivers should be put below "drivers" even
  if they start out supporting only one specific configuration. Note that
  it is not a requirement for such a first instance to be generic as
  genericity generally cannot be extrapolated from a single data point.
  
Feel free to amend / modify that.

Cheers
  Detlev

[1] http://www.denx.de/wiki/rdiff/U-Boot/DesignPrinciples?rev1=1.14&rev2=1.13

PS: Ok, actually I didn't want to ruin the magic 10 ;)

-- 
Question: If you were redesigning UNIX, what would you do differently?
Ken Thompson: I'd spell creat with an e.
--
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] [PATCH u-boot-arm/next 1/2] OMAP3: igep00x0: Add config option to choose flash storage memory

[Tom Rini]

On 07/16/2012 12:43 AM, Enric Balletbò i Serra wrote:

[snip]
> I would like to investigateif we can do this using runtime detection
> instead of a separate config option. Give me some days. The runtime
> detection can be done reading the sysboot configuration for example. I
> think it's possible, do you think would be possible ?

Until we have the device model and the ability to see at run-time if we
have say NAND or OneNAND (or neither!) we can't because we have to
build-time define where the environment will be found.

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

Re: [U-Boot] [PATCH u-boot-arm/next 2/2] OMAP3: igep00x0: add SPL support for IGEP-based boards

[Tom Rini]

On 07/13/2012 12:41 PM, Javier Martinez Canillas wrote:

> This patch adds SPL support for IGEP-based boards.
> 
> Tested on an IGEPv2 Rev.C board with Micron NAND Flash memory.
[snip]
> +#define CONFIG_SPL_MAX_SIZE  (45 * 1024)

This should be 54 * 1024.  Thanks!

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

Re: [U-Boot] DaVinci PHYs

[Marek Vasut]

Dear Tom Rini,

> On 07/16/2012 12:33 AM, Heiko Schocher wrote:
> > Hello Marek,
> > 
> > added Tom Rini to cc, as he is the ti maintainer ...
> > 
> > On 15.07.2012 15:42, Marek Vasut wrote:
> >> Hi guys,
> >> 
> >> is there any hope the ad-hoc implementation of davinci emac PHYs will
> >> ever be
> >> flipped to phylib ?
> > 
> > I currently have no such job in sight ...
> 
> The last time someone wanted to add a new phy to the driver I asked them
> to investigate and switch over to phylib.  That's about as far as it's
> gotten.

Damn. btw. I'll be moving the OMAP GPIO driver into drivers/gpio/ ... I have a 
patch for that already.

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

[U-Boot] [PATCH] Add support for eco5-pk ARM board

[Raphael Assenat]

This patch adds support for the 8D Technologies ECO5-PK board which is
based on the TI AM3505 ARM SOC.

Signed-off-by: Raphael Assenat 

diff --git a/board/8dtech/eco5pk/Makefile b/board/8dtech/eco5pk/Makefile
new file mode 100644
index 000..befe60a
--- /dev/null
+++ b/board/8dtech/eco5pk/Makefile
@@ -0,0 +1,43 @@
+#
+# (C) Copyright 2000, 2001, 2002
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# Adapted from ti/evm/Makefile
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS  := eco5pk.o
+
+SRCS   := $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
+
+$(LIB):$(obj).depend $(OBJS)
+   $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
diff --git a/board/8dtech/eco5pk/eco5pk.c b/board/8dtech/eco5pk/eco5pk.c
new file mode 100644
index 000..ddc5274
--- /dev/null
+++ b/board/8dtech/eco5pk/eco5pk.c
@@ -0,0 +1,61 @@
+/*
+ * eco5pk.c - board file for 8D Technology's AM3517 based eco5pk board
+ *
+ * Based on am3517evm.c
+ *
+ * Copyright (C) 2011-2012 8D Technologies inc.
+ * Copyright (C) 2009 Texas Instruments Incorporated
+ *
+ * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "eco5pk.h"
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/*
+ * Routine: board_init
+ * Description: Early hardware init.
+ */
+int board_init(void)
+{
+   gpmc_init(); /* in SRAM or SDRAM, finish GPMC */
+   gd->bd->bi_boot_params = (OMAP34XX_SDRC_CS0 + 0x100);
+   
+   gpio_request(30, "RESOUT");
+   gpio_direction_output(30,1);
+   return 0;
+}
+
+/*
+ * Routine: set_muxconf_regs
+ * Description: Setting up the configuration Mux registers specific to the
+ * hardware. Many pins need to be moved from protect to primary
+ * mode.
+ */
+void set_muxconf_regs(void)
+{
+   MUX_ECO5_PK();
+}
diff --git a/board/8dtech/eco5pk/eco5pk.h b/board/8dtech/eco5pk/eco5pk.h
new file mode 100644
index 000..0e60ef8
--- /dev/null
+++ b/board/8dtech/eco5pk/eco5pk.h
@@ -0,0 +1,402 @@
+/*
+ * eco5.h - Header file for the 8D Technologies ECO5 board.
+ *
+ * Based on  am3517evm.h
+ * Based on ti/evm/evm.h
+ *
+ * Copyright (C) 2011 8D Technologies inc.
+ * Copyright (C) 2009 Texas Instruments Incorporated
+ *
+ * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#ifndef _ECO5PK_H__
+#define _ECO5PK_H__
+
+const omap3_sysinfo sysinfo = {
+   DDR_DISCRETE,
+   "ECO5 Board",
+   "NAND",
+};
+
+/*
+ * IEN  - Input Enable
+ * IDIS - Input Disable
+ * PTD  - Pull type Down
+ * PTU  - Pull type Up
+ * DIS  - Pull type selection is inactive
+ * EN   - Pull type selection is active
+ * M0   - M

[U-Boot] [PATCH v3] i.MX28: extend print_cpuinfo() to use chip information

[Otavio Salvador]

The information now is gathered from HW_DIGCTL_CHIPID register and
includes the chip modem and revision on the output.

Signed-off-by: Otavio Salvador 
---
Changes in v2:
- use ?? for unidentified revision and cpu type
- use numeric revisions

Changes in v3:
- drop mx23 data as it will be posted in a later patch
- fix info order (first rev, then clock)

 arch/arm/cpu/arm926ejs/mx28/mx28.c   |   38 --
 arch/arm/include/asm/arch-mx28/regs-digctl.h |4 +++
 2 files changed, 40 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/mx28/mx28.c 
b/arch/arm/cpu/arm926ejs/mx28/mx28.c
index ff25772..cf7a50f 100644
--- a/arch/arm/cpu/arm926ejs/mx28/mx28.c
+++ b/arch/arm/cpu/arm926ejs/mx28/mx28.c
@@ -188,13 +188,47 @@ int arch_cpu_init(void)
 }
 
 #if defined(CONFIG_DISPLAY_CPUINFO)
+static const char *get_cpu_type(void)
+{
+   struct mx28_digctl_regs *digctl_regs =
+   (struct mx28_digctl_regs *)MXS_DIGCTL_BASE;
+
+   switch (readl(&digctl_regs->hw_digctl_chipid) & HW_DIGCTL_CHIPID_MASK) {
+   case HW_DIGCTL_CHIPID_MX28:
+   return "28";
+   default:
+   return "??";
+   }
+}
+
+static const char *get_cpu_rev(void)
+{
+   struct mx28_digctl_regs *digctl_regs =
+   (struct mx28_digctl_regs *)MXS_DIGCTL_BASE;
+   uint8_t rev = readl(&digctl_regs->hw_digctl_chipid) & 0x00FF;
+
+   switch (readl(&digctl_regs->hw_digctl_chipid) & HW_DIGCTL_CHIPID_MASK) {
+   case HW_DIGCTL_CHIPID_MX28:
+   switch (rev) {
+   case 0x1:
+   return "1.2";
+   default:
+   return "??";
+   }
+   default:
+   return "??";
+   }
+}
+
 int print_cpuinfo(void)
 {
struct mx28_spl_data *data = (struct mx28_spl_data *)
((CONFIG_SYS_TEXT_BASE - sizeof(struct mx28_spl_data)) & ~0xf);
 
-   printf("Freescale i.MX28 family at %d MHz\n",
-   mxc_get_clock(MXC_ARM_CLK) / 100);
+   printf("CPU:   Freescale i.MX%s rev%s at %d MHz\n",
+   get_cpu_type(),
+   get_cpu_rev(),
+   mxc_get_clock(MXC_ARM_CLK) / 100);
printf("BOOT:  %s\n", mx28_boot_modes[data->boot_mode_idx].mode);
return 0;
 }
diff --git a/arch/arm/include/asm/arch-mx28/regs-digctl.h 
b/arch/arm/include/asm/arch-mx28/regs-digctl.h
index 9a63594..247da6e 100644
--- a/arch/arm/include/asm/arch-mx28/regs-digctl.h
+++ b/arch/arm/include/asm/arch-mx28/regs-digctl.h
@@ -152,4 +152,8 @@ struct mx28_digctl_regs {
 };
 #endif
 
+/* Product code identification */
+#define HW_DIGCTL_CHIPID_MASK  (0x << 16)
+#define HW_DIGCTL_CHIPID_MX28  (0x2800 << 16)
+
 #endif /* __MX28_REGS_DIGCTL_H__ */
-- 
1.7.10.4

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

Re: [U-Boot] DaVinci PHYs

[Tom Rini]

On 07/16/2012 11:58 AM, Marek Vasut wrote:
> Dear Tom Rini,
> 
>> On 07/16/2012 12:33 AM, Heiko Schocher wrote:
>>> Hello Marek,
>>>
>>> added Tom Rini to cc, as he is the ti maintainer ...
>>>
>>> On 15.07.2012 15:42, Marek Vasut wrote:
 Hi guys,

 is there any hope the ad-hoc implementation of davinci emac PHYs will
 ever be
 flipped to phylib ?
>>>
>>> I currently have no such job in sight ...
>>
>> The last time someone wanted to add a new phy to the driver I asked them
>> to investigate and switch over to phylib.  That's about as far as it's
>> gotten.
> 
> Damn. btw. I'll be moving the OMAP GPIO driver into drivers/gpio/ ... I have 
> a 
> patch for that already.

It should not be a hard move to make, it's just not anywhere near the
top of my priority list.  Since it's on am3517 I can test it without too
much trouble, if someone else does the semi-mechanical stuff :)

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

Re: [U-Boot] [PATCH] fsl: board EEPROM has the CRC in the wrong location

[Wolfgang Denk]

Dear Scott,

In message <5000ab43.6090...@freescale.com> you wrote:
>
> > You are interpreting something which can be random data.
> > 
> >> if (e.version == 0)
> >>crc_offset = 0x72;
> >>
> >> So here we're reading the 'version' field before we validate the data,
> >> because we need to check the version to know where the CRC is.
> > 
> > Argh.  More crap ...
> 
> And how would you do it?  You have to look at *something* first, and
> whatever that is could be a coincidence if you think people are going to
> stuff arbitrary data into the EEPROM.

If you cannot avoid using binary data structures you must make sure
the design allows extensions which do not break the design.  This was
attempted here (CRC at fixed position 0xFC), which is supposed to be
"at the end" - unless the EEPROM size changes one day.

Accessing _any_ data fields in the binary structure must always be
done only _after_ the CRC has been verified.  It makes zero sense to
try to interpret a version field without knowing if it is valid at
all.

Such code shows undefined behaviour.  You may argument that the
likelyhood of a false match is small, but this doesn't matter: it's
still undefined behaviour.


With all the previous explanations already given (only very fewsystems
affected) it is best to remove all this crap, and provide a manual
recovery tool (to be run under close supervision of the user).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"The two most common things in the universe are hydrogen  and  stupi-
dity."
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3] i.MX28: extend print_cpuinfo() to use chip information

[Marek Vasut]

Dear Otavio Salvador,

> The information now is gathered from HW_DIGCTL_CHIPID register and
> includes the chip modem and revision on the output.
> 
> Signed-off-by: Otavio Salvador 

This one is OK with me, queue for next maybe?

Acked-by: Marek Vasut 

> ---
> Changes in v2:
> - use ?? for unidentified revision and cpu type
> - use numeric revisions
> 
> Changes in v3:
> - drop mx23 data as it will be posted in a later patch
> - fix info order (first rev, then clock)
> 
>  arch/arm/cpu/arm926ejs/mx28/mx28.c   |   38
> -- arch/arm/include/asm/arch-mx28/regs-digctl.h | 
>   4 +++
>  2 files changed, 40 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/cpu/arm926ejs/mx28/mx28.c
> b/arch/arm/cpu/arm926ejs/mx28/mx28.c index ff25772..cf7a50f 100644
> --- a/arch/arm/cpu/arm926ejs/mx28/mx28.c
> +++ b/arch/arm/cpu/arm926ejs/mx28/mx28.c
> @@ -188,13 +188,47 @@ int arch_cpu_init(void)
>  }
> 
>  #if defined(CONFIG_DISPLAY_CPUINFO)
> +static const char *get_cpu_type(void)
> +{
> + struct mx28_digctl_regs *digctl_regs =
> + (struct mx28_digctl_regs *)MXS_DIGCTL_BASE;
> +
> + switch (readl(&digctl_regs->hw_digctl_chipid) & HW_DIGCTL_CHIPID_MASK) {
> + case HW_DIGCTL_CHIPID_MX28:
> + return "28";
> + default:
> + return "??";
> + }
> +}
> +
> +static const char *get_cpu_rev(void)
> +{
> + struct mx28_digctl_regs *digctl_regs =
> + (struct mx28_digctl_regs *)MXS_DIGCTL_BASE;
> + uint8_t rev = readl(&digctl_regs->hw_digctl_chipid) & 0x00FF;
> +
> + switch (readl(&digctl_regs->hw_digctl_chipid) & HW_DIGCTL_CHIPID_MASK) {
> + case HW_DIGCTL_CHIPID_MX28:
> + switch (rev) {
> + case 0x1:
> + return "1.2";
> + default:
> + return "??";
> + }
> + default:
> + return "??";
> + }
> +}
> +
>  int print_cpuinfo(void)
>  {
>   struct mx28_spl_data *data = (struct mx28_spl_data *)
>   ((CONFIG_SYS_TEXT_BASE - sizeof(struct mx28_spl_data)) & ~0xf);
> 
> - printf("Freescale i.MX28 family at %d MHz\n",
> - mxc_get_clock(MXC_ARM_CLK) / 100);
> + printf("CPU:   Freescale i.MX%s rev%s at %d MHz\n",
> + get_cpu_type(),
> + get_cpu_rev(),
> + mxc_get_clock(MXC_ARM_CLK) / 100);
>   printf("BOOT:  %s\n", mx28_boot_modes[data->boot_mode_idx].mode);
>   return 0;
>  }
> diff --git a/arch/arm/include/asm/arch-mx28/regs-digctl.h
> b/arch/arm/include/asm/arch-mx28/regs-digctl.h index 9a63594..247da6e
> 100644
> --- a/arch/arm/include/asm/arch-mx28/regs-digctl.h
> +++ b/arch/arm/include/asm/arch-mx28/regs-digctl.h
> @@ -152,4 +152,8 @@ struct mx28_digctl_regs {
>  };
>  #endif
> 
> +/* Product code identification */
> +#define HW_DIGCTL_CHIPID_MASK(0x << 16)
> +#define HW_DIGCTL_CHIPID_MX28(0x2800 << 16)
> +
>  #endif /* __MX28_REGS_DIGCTL_H__ */

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

Re: [U-Boot] DaVinci PHYs

[Marek Vasut]

Dear Tom Rini,

> On 07/16/2012 11:58 AM, Marek Vasut wrote:
> > Dear Tom Rini,
> > 
> >> On 07/16/2012 12:33 AM, Heiko Schocher wrote:
> >>> Hello Marek,
> >>> 
> >>> added Tom Rini to cc, as he is the ti maintainer ...
> >>> 
> >>> On 15.07.2012 15:42, Marek Vasut wrote:
>  Hi guys,
>  
>  is there any hope the ad-hoc implementation of davinci emac PHYs will
>  ever be
>  flipped to phylib ?
> >>> 
> >>> I currently have no such job in sight ...
> >> 
> >> The last time someone wanted to add a new phy to the driver I asked them
> >> to investigate and switch over to phylib.  That's about as far as it's
> >> gotten.
> > 
> > Damn. btw. I'll be moving the OMAP GPIO driver into drivers/gpio/ ... I
> > have a patch for that already.
> 
> It should not be a hard move to make, it's just not anywhere near the
> top of my priority list.  Since it's on am3517 I can test it without too
> much trouble, if someone else does the semi-mechanical stuff :)

I'll roll out the set after .07 is out. Not before, it's all too heated now too.

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

[U-Boot] [RFC PATCH 0/2] i.MX28 SoC pending patches

[Otavio Salvador]

Those patches are waiting in my tree for some time and are part of my
work i.MX233 support. Am trying to send small parts that are ready for
merging and that do not depends on i.MX233 SoC to work.

Otavio Salvador (2):
  i.MX28: Check if we are using a valid VBUS when initializing power
  i.MX28: use a clear name for DDR2 initialization

 arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c   |   12 ++--
 arch/arm/cpu/arm926ejs/mx28/spl_power_init.c |   21 ++---
 2 files changed, 20 insertions(+), 13 deletions(-)

-- 
1.7.10.4

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

[U-Boot] [RFC PATCH 1/2] i.MX28: Check if we are using a valid VBUS when initializing power

[Otavio Salvador]

Signed-off-by: Otavio Salvador 
---
 arch/arm/cpu/arm926ejs/mx28/spl_power_init.c |   21 ++---
 1 file changed, 14 insertions(+), 7 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..c8a35af 100644
--- a/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
+++ b/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
@@ -564,6 +564,15 @@ void mx28_batt_boot(void)
0x8 << POWER_5VCTRL_CHARGE_4P2_ILIMIT_OFFSET);
 }
 
+static int mx28_valid_vbus(void)
+{
+   struct mx28_power_regs *power_regs =
+   (struct mx28_power_regs *)MXS_POWER_BASE;
+
+   /* iMX23 uses POWER_STS_VBUSVALID_STATUS at same offset */
+   return readl(&power_regs->hw_power_sts) & POWER_STS_VBUSVALID0_STATUS;
+}
+
 void mx28_handle_5v_conflict(void)
 {
struct mx28_power_regs *power_regs =
@@ -581,7 +590,7 @@ void mx28_handle_5v_conflict(void)
break;
}
 
-   if (tmp & POWER_STS_VDD5V_GT_VDDIO) {
+   if (mx28_valid_vbus() && (tmp & POWER_STS_VDD5V_GT_VDDIO)) {
mx28_boot_valid_5v();
break;
} else {
@@ -601,17 +610,15 @@ void mx28_5v_boot(void)
struct mx28_power_regs *power_regs =
(struct mx28_power_regs *)MXS_POWER_BASE;
 
-   /*
-* NOTE: In original IMX-Bootlets, this also checks for VBUSVALID,
-* but their implementation always returns 1 so we omit it here.
-*/
-   if (readl(&power_regs->hw_power_sts) & POWER_STS_VDD5V_GT_VDDIO) {
+   if (mx28_valid_vbus() &&
+   (readl(&power_regs->hw_power_sts) & POWER_STS_VDD5V_GT_VDDIO)) {
mx28_boot_valid_5v();
return;
}
 
early_delay(1000);
-   if (readl(&power_regs->hw_power_sts) & POWER_STS_VDD5V_GT_VDDIO) {
+   if (mx28_valid_vbus() &&
+   (readl(&power_regs->hw_power_sts) & POWER_STS_VDD5V_GT_VDDIO)) {
mx28_boot_valid_5v();
return;
}
-- 
1.7.10.4

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

[U-Boot] [RFC PATCH 2/2] i.MX28: use a clear name for DDR2 initialization

[Otavio Salvador]

The mx28 prefix has been added to the initialization data and function
so it is clear by which SoC it is used as i.MX233 will have a specific
one.

Signed-off-by: Otavio Salvador 
---
 arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c 
b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
index e17a4d7..7317a97 100644
--- a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
+++ b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
@@ -31,7 +31,7 @@
 
 #include "mx28_init.h"
 
-uint32_t dram_vals[] = {
+uint32_t mx28_dram_vals[] = {
0x, 0x, 0x, 0x,
0x, 0x, 0x, 0x,
0x, 0x, 0x, 0x,
@@ -88,14 +88,14 @@ void __mx28_adjust_memory_params(uint32_t *dram_vals)
 void mx28_adjust_memory_params(uint32_t *dram_vals)
__attribute__((weak, alias("__mx28_adjust_memory_params")));
 
-void init_m28_200mhz_ddr2(void)
+void init_mx28_200mhz_ddr2(void)
 {
int i;
 
-   mx28_adjust_memory_params(dram_vals);
+   mx28_adjust_memory_params(mx28_dram_vals);
 
-   for (i = 0; i < ARRAY_SIZE(dram_vals); i++)
-   writel(dram_vals[i], MXS_DRAM_BASE + (4 * i));
+   for (i = 0; i < ARRAY_SIZE(mx28_dram_vals); i++)
+   writel(mx28_dram_vals[i], MXS_DRAM_BASE + (4 * i));
 }
 
 void mx28_mem_init_clock(void)
@@ -230,7 +230,7 @@ void mx28_mem_init(void)
/* Clear START bit from DRAM_CTL16 */
clrbits_le32(MXS_DRAM_BASE + 0x40, 1);
 
-   init_m28_200mhz_ddr2();
+   init_mx28_200mhz_ddr2();
 
/* Clear SREFRESH bit from DRAM_CTL17 */
clrbits_le32(MXS_DRAM_BASE + 0x44, 1);
-- 
1.7.10.4

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

Re: [U-Boot] [PATCH v3] i.MX28: extend print_cpuinfo() to use chip information

[Otavio Salvador]

On Mon, Jul 16, 2012 at 5:19 PM, Marek Vasut  wrote:
>> The information now is gathered from HW_DIGCTL_CHIPID register and
>> includes the chip modem and revision on the output.
>>
>> Signed-off-by: Otavio Salvador 
>
> This one is OK with me, queue for next maybe?

Fine with me. This is not urgent but a nice to have one.

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

Re: [U-Boot] [RFC PATCH 1/2] i.MX28: Check if we are using a valid VBUS when initializing power

[Marek Vasut]

Dear Otavio Salvador,

[...]
> 
> - if (tmp & POWER_STS_VDD5V_GT_VDDIO) {
> + if (mx28_valid_vbus() && (tmp & POWER_STS_VDD5V_GT_VDDIO)) {


So if the board isn't supplied by USB VBUS, this will fail now?

[...]

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

Re: [U-Boot] [RFC PATCH 2/2] i.MX28: use a clear name for DDR2 initialization

[Marek Vasut]

Dear Otavio Salvador,

> The mx28 prefix has been added to the initialization data and function
> so it is clear by which SoC it is used as i.MX233 will have a specific
> one.
> 
> Signed-off-by: Otavio Salvador 

Acked-by: Marek Vasut 

[...]

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

[U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12

[Detlev Zundel]

Hi,

as promised, here are my expanded notes from the BoF meeting at LSM2012
last week.  It was a pleasure to get some core developers into one room
at the same time and discuss controversial topics without the health of
any one attendant being in jeopardy at any time, so thanks again to
everybody for making this meeting as successful as it was!

[Note that this text expresses my understanding of the topics and thus
may sometimes be slightly imprecise or bluntly wrong, so feel free to
correct me where due :) ]


* Tips on how to use JTAG to debug custom hardware that does
  not boot

Some experiences on how to recover bricked hardware with the help of
JTAG debuggers were exchanged.  Some recurring problems one should be
aware of in this area are:

 - Breakpoints on unintialized RAM
 - How to cope with relocation (e.g. reload symbols in gdb with an
   offset to the ELF symbol table as described in the Wiki)
 - Different system architectures, with different responsibilities to
   setup RAM
 - What is BootROM doing before U-Boot is running?  Analyze the system
   at hand with respect to its expected boot sequence before hooking
   into it with a debugger.

General rules seem to be hard to find for details as the early phases of
booting vary greatly over the range of supported hardware in U-Boot.


* U-Boot History visualized

The history of the U-Boot repository was shown visualized with the help
of the gource tool:

http://code.google.com/p/gource/

Unfortunately the movie shown was 2.4GiB in size and found to be
unsuitable for putting up on our webspace.  We will look into producing
a smaller version to publish.

It is visually clear from the short movie, that the U-Boot community and
the amount of interaction has grown substantially over time.  The sheer
amount of source files also grew in relation to that ;)

* Patman

As Simon Glass, the author of the 'patman' tool, was physically present,
he agreed to give a short introduction to this tool recently added to
the U-Boot repository:

http://git.denx.de/?p=u-boot.git;a=tree;f=tools/patman

In short, this tool allows to elegantly manage entire patch series over
multiple iterations and easily send them to the mailing list.
Controlled through meta-data included (but stripped from submission) in
the git commit messages, it helps formally verifying patch series with
checkpatch, tracking inter-submission changes and addressing the
relevant mail recipients.

It was agreed that the help to be gained from the tool was substantial
and that it should get more exhibition in the documentation and among
contributors.


* Conflict resolution: setting up a moderator procedure for
  unhappy submitters

A recent occurence on the mailing list where contributers were sent
through multiple rounds of patch submissions for non-obvious reasons was
used as a ground for discussing non-technical aspects of patch
submissions.  It was especially discussed that the privilege of being a
custodian in U-Boot also brings obligations that should be defined more
clearly.  Essentially we would like to see somewhat "enforceable" rights
for the "motor" of the project, i.e. for patch submitters.

For this we should extend our documentation to clearly cover
responsibility of custodiands.  Require making constructive (testable)
suggestions on how to get patch accepted when nak-ing patches for
example.  This can also be enforced by patch submitters by waiting for
clear and precise suggestions for re-work.

It was also found to be a good idea to document people willing to act as
"moderators" for unhappy contributers, i.e. who can look into problems
and try to moderate.  (I would volunteer to be such a moderator).

Currently the lack of any reaction whatsoever was identified to be a
very discouraging sign for contributors. One thing we could do is to
declare a "soft" time-limit (two weeks) that patches need to be looked
at.  After this time-limit, one could declare "backup-custodians" to
push patches to or merge patches into some "-staging" branch.  (What to
do with that branch then?) For this to work, custodians would need to
announce "off-times" which currently is not general consensus.


* Patchwork pros / cons

While talking about the patch submission process it became clear that
the handling through patchwork still has some unsolved problems, the
most obvious being the large backlog of patches in the archieve.

It was agreed that automatic marking of changes as accepted when changes
hit mainline would be a good thing.  There is some info on our wiki
available, although it is not clear who uses them:

http://www.denx.de/wiki/view/U-Boot/Patches#pwclient and
http://www.mail-archive.com/patchwork@lists.ozlabs.org/msg00057.html

A tool to automatically mark patches as superceded on newer versions
was also suggested to be very valuable.  

Unanswered questions:

- What can patman do automatically?
- Can gerrit help the workflow?

During the discussion it showed that many people believe that patches
ou

[U-Boot] [PATCH v2] i.MX28: Check if we are using a valid VBUS for power initialization

[Otavio Salvador]

Signed-off-by: Otavio Salvador 
---
Changes in v2:
- add comments
- fix when we have vbus OR vdd5v
- improve patch short description

 arch/arm/cpu/arm926ejs/mx28/spl_power_init.c |   26 +++---
 1 file changed, 19 insertions(+), 7 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..fdf810c 100644
--- a/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
+++ b/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
@@ -564,6 +564,15 @@ void mx28_batt_boot(void)
0x8 << POWER_5VCTRL_CHARGE_4P2_ILIMIT_OFFSET);
 }
 
+static int mx28_valid_vbus(void)
+{
+   struct mx28_power_regs *power_regs =
+   (struct mx28_power_regs *)MXS_POWER_BASE;
+
+   /* iMX23 uses POWER_STS_VBUSVALID_STATUS at same offset */
+   return readl(&power_regs->hw_power_sts) & POWER_STS_VBUSVALID0_STATUS;
+}
+
 void mx28_handle_5v_conflict(void)
 {
struct mx28_power_regs *power_regs =
@@ -577,14 +586,19 @@ void mx28_handle_5v_conflict(void)
tmp = readl(&power_regs->hw_power_sts);
 
if (tmp & POWER_STS_VDDIO_BO) {
+   /*
+* VDDIO has a brownout, then the VDD5V_GT_VDDIO becomes
+* unreliable
+*/
mx28_powerdown();
break;
}
 
-   if (tmp & POWER_STS_VDD5V_GT_VDDIO) {
+   if (mx28_valid_vbus() || (tmp & POWER_STS_VDD5V_GT_VDDIO)) {
mx28_boot_valid_5v();
break;
} else {
+   /* Neither 5v sees 5v so we power down */
mx28_powerdown();
break;
}
@@ -601,17 +615,15 @@ void mx28_5v_boot(void)
struct mx28_power_regs *power_regs =
(struct mx28_power_regs *)MXS_POWER_BASE;
 
-   /*
-* NOTE: In original IMX-Bootlets, this also checks for VBUSVALID,
-* but their implementation always returns 1 so we omit it here.
-*/
-   if (readl(&power_regs->hw_power_sts) & POWER_STS_VDD5V_GT_VDDIO) {
+   if (mx28_valid_vbus() &&
+   (readl(&power_regs->hw_power_sts) & POWER_STS_VDD5V_GT_VDDIO)) {
mx28_boot_valid_5v();
return;
}
 
early_delay(1000);
-   if (readl(&power_regs->hw_power_sts) & POWER_STS_VDD5V_GT_VDDIO) {
+   if (mx28_valid_vbus() &&
+   (readl(&power_regs->hw_power_sts) & POWER_STS_VDD5V_GT_VDDIO)) {
mx28_boot_valid_5v();
return;
}
-- 
1.7.10.4

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

Re: [U-Boot] [RFC PATCH 1/2] i.MX28: Check if we are using a valid VBUS when initializing power

[Otavio Salvador]

On Mon, Jul 16, 2012 at 5:42 PM, Marek Vasut  wrote:
> Dear Otavio Salvador,
>
> [...]
>>
>> - if (tmp & POWER_STS_VDD5V_GT_VDDIO) {
>> + if (mx28_valid_vbus() && (tmp & POWER_STS_VDD5V_GT_VDDIO)) {
>
>
> So if the board isn't supplied by USB VBUS, this will fail now?

I sent a v2 of it, but with a minor change in short description.

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

Re: [U-Boot] [PATCH v2] i.MX28: Check if we are using a valid VBUS for power initialization

[Marek Vasut]

Dear Otavio Salvador,

> Signed-off-by: Otavio Salvador 
> ---
> Changes in v2:
> - add comments
> - fix when we have vbus OR vdd5v
> - improve patch short description
> 
>  arch/arm/cpu/arm926ejs/mx28/spl_power_init.c |   26
> +++--- 1 file changed, 19 insertions(+), 7
> 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..fdf810c
> 100644
> --- a/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
> +++ b/arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
> @@ -564,6 +564,15 @@ void mx28_batt_boot(void)
>   0x8 << POWER_5VCTRL_CHARGE_4P2_ILIMIT_OFFSET);
>  }
> 
> +static int mx28_valid_vbus(void)
> +{
> + struct mx28_power_regs *power_regs =
> + (struct mx28_power_regs *)MXS_POWER_BASE;
> +
> + /* iMX23 uses POWER_STS_VBUSVALID_STATUS at same offset */
> + return readl(&power_regs->hw_power_sts) & POWER_STS_VBUSVALID0_STATUS;
> +}
> +
>  void mx28_handle_5v_conflict(void)
>  {
>   struct mx28_power_regs *power_regs =
> @@ -577,14 +586,19 @@ void mx28_handle_5v_conflict(void)
>   tmp = readl(&power_regs->hw_power_sts);
> 
>   if (tmp & POWER_STS_VDDIO_BO) {
> + /*
> +  * VDDIO has a brownout, then the VDD5V_GT_VDDIO becomes
> +  * unreliable
> +  */
>   mx28_powerdown();
>   break;
>   }
> 
> - if (tmp & POWER_STS_VDD5V_GT_VDDIO) {
> + if (mx28_valid_vbus() || (tmp & POWER_STS_VDD5V_GT_VDDIO)) {
>   mx28_boot_valid_5v();
>   break;
>   } else {
> + /* Neither 5v sees 5v so we power down */
>   mx28_powerdown();
>   break;
>   }
> @@ -601,17 +615,15 @@ void mx28_5v_boot(void)
>   struct mx28_power_regs *power_regs =
>   (struct mx28_power_regs *)MXS_POWER_BASE;
> 
> - /*
> -  * NOTE: In original IMX-Bootlets, this also checks for VBUSVALID,
> -  * but their implementation always returns 1 so we omit it here.
> -  */
> - if (readl(&power_regs->hw_power_sts) & POWER_STS_VDD5V_GT_VDDIO) {
> + if (mx28_valid_vbus() &&
> + (readl(&power_regs->hw_power_sts) & POWER_STS_VDD5V_GT_VDDIO)) {
>   mx28_boot_valid_5v();
>   return;
>   }
> 
>   early_delay(1000);
> - if (readl(&power_regs->hw_power_sts) & POWER_STS_VDD5V_GT_VDDIO) {
> + if (mx28_valid_vbus() &&

This is still likely to break any device that doesn't source it's 5V power 
supply from USB

> + (readl(&power_regs->hw_power_sts) & POWER_STS_VDD5V_GT_VDDIO)) {
>   mx28_boot_valid_5v();
>   return;
>   }

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 v2] i.MX28: Check if we are using a valid VBUS for power initialization

[Otavio Salvador]

On Mon, Jul 16, 2012 at 6:46 PM, Marek Vasut  wrote:
...
>>   early_delay(1000);
>> - if (readl(&power_regs->hw_power_sts) & POWER_STS_VDD5V_GT_VDDIO) {
>> + if (mx28_valid_vbus() &&
>
> This is still likely to break any device that doesn't source it's 5V power
> supply from USB

I might be missing something here but the conflict function handles
this case and if any is available it boots.

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

Re: [U-Boot] i.MX dcache issues

[Marek Vasut]

Dear Dirk Behme,

> On 15.07.2012 00:08, Benoît Thébaudeau wrote:
> > On Sat, Jul 14, 2012 at 11:28:03PM +0200, Benoît Thébaudeau wrote:
> >> Shouldn't the MMC/eSDHC drivers flush/invalidate the dcache ranges
> >> that they use
> >> for DMA operations? Not doing so would explain why stack-allocated
> >> buffers are
> >> more affected than buffers in unused RAM areas.
> > 
> > That will help:
> > http://git.denx.de/?p=u-boot/u-boot-mmc.git;a=commitdiff;h=e576bd90f94080
> > 6b989ffd666552081f17f032c8
> 
> Are you sure that this patch does really help?
> 
> If I remember correctly (will re-check) we have this patch locally
> applied. But even with this patch, we have issues so that we enabled
> CONFIG_SYS_DCACHE_OFF, i.e. disabled the dcache.

Try using the bounce buffer as I do on mx28.

> The issues we observed *without* CONFIG_SYS_DCACHE_OFF: The SD card
> was detected as 1-bit only (mmcinfo), while with dcache off it was
> used as 4-bit. Debugging this showed that wrong configuration data was
> read [1]. Having a fat partition on the card, mmc part/fatls etc
> failed, too, with cache enabled.

Ad caches -- FEC should be fixed on these platforms, USB might work, MMC should 
work if you use the bounce buffer. FAT should be fixed, so should be ext2

> Best regards
> 
> Dirk
> 
> [1]
> 
> http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mmc/mmc.c;h=aebe578ff6f2e
> 0228baa3e5d010f6808ea269760;hb=HEAD#l856
> 
> mmc->scr[0]/scr[1] contained random data
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

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] fsl: board EEPROM has the CRC in the wrong location

[Scott Wood]

On 07/16/2012 02:57 PM, Wolfgang Denk wrote:
> Dear Scott,
> 
> In message <5000ab43.6090...@freescale.com> you wrote:
>>
>>> You are interpreting something which can be random data.
>>>
 if (e.version == 0)
crc_offset = 0x72;

 So here we're reading the 'version' field before we validate the data,
 because we need to check the version to know where the CRC is.
>>>
>>> Argh.  More crap ...
>>
>> And how would you do it?  You have to look at *something* first, and
>> whatever that is could be a coincidence if you think people are going to
>> stuff arbitrary data into the EEPROM.
> 
> If you cannot avoid using binary data structures you must make sure
> the design allows extensions which do not break the design.

That's what the version field is for.  Would it be nice if, from the
beginning, there were a size and CRC field up front?  Sure.  But that's
not what happened, and this is not a data format that we (the team that
Timur and I are on) control.  It's specified by the part of Freescale
that programs EEPROMs on the boards before sending them to customers,
and they're not going to change just because we tell them you think it's
"crap".  And we are not going to break compatibility with existing
EEPROM contents.  Sorry.

> This was
> attempted here (CRC at fixed position 0xFC), which is supposed to be
> "at the end" - unless the EEPROM size changes one day.
> 
> Accessing _any_ data fields in the binary structure must always be
> done only _after_ the CRC has been verified.  It makes zero sense to
> try to interpret a version field without knowing if it is valid at
> all.

And you don't know where the CRC is if you don't know what sort of data
structure it is.  If the version field gets corrupted, and the result is
interpreted as a valid version, then you rely on that version's CRC to
reject the EEPROM contents.

To use your logic, it makes zero sense to interpret a value as a CRC
without first knowing that it's supposed to be one.  Do you reject as
"crap" every single system of format autodetection in the world, even
when a good magic number is used (I'm not claiming that these version
numbers are good magic numbers)?

> Such code shows undefined behaviour.  You may argument that the
> likelyhood of a false match is small, but this doesn't matter: 

In the real world, yes, it does.  It also matters that you need bad data
to start with (a failed CRC in the proper location) to even begin
rolling the dice on whether there's a spurious "good" CRC in the old
location.

The U-Boot source code is managed by a version control system that is
constantly gambling on not getting a chance collision.  Such a collision
is so extremely rare that it will likely never happen to any git user
until humans go extinct, but it's theoretically possible.  The odds here
are larger than that, but still very small, and it's a chance that's
much more rarely taken to begin with.  The odds of there being a problem
if we do what you want us to do are greater.

> it's still undefined behaviour.
> 
> 
> With all the previous explanations already given (only very fewsystems
> affected) it is best to remove all this crap, and provide a manual
> recovery tool

I wonder if "only very few systems affected" was thrown in to prevent a
counterargument that it is best to remove the code for the old U-Boot
environment data structure, replace it with something that is
size-extensible (not to mention the assumption that
CONFIG_SYS_RENDUNDAND_ENVIRONMENT (sic) hasn't changed on upgrade), and
provide a manual recovery tool. :-)

They are systems that we care about, regardless of whether they are
"very few" as a percentage of all boards that U-Boot supports.

> (to be run under close supervision of the user).

Often it's the users that need supervision. :-P

-Scott

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

[U-Boot] [PATCH v7 04/15] tegra20: tec: add tegra20-common-post.h

[Allen Martin]

Add tegra20-common-post.h to be consistent with other tegra20 boards.

Signed-off-by: Allen Martin 
Acked-by: Thierry Reding 
Acked-by: Stephen Warren 
Tested-by: Thierry Reding 
---
 include/configs/tec.h |2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/tec.h b/include/configs/tec.h
index 39400d9..9b3f88d 100644
--- a/include/configs/tec.h
+++ b/include/configs/tec.h
@@ -79,4 +79,6 @@
"ext2load mmc 0 0x1700 /boot/uImage;"   \
"bootm"
 
+#include "tegra20-common-post.h"
+
 #endif /* __CONFIG_H */
-- 
1.7.9.5

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

[U-Boot] [PATCH v7 06/15] mkconfig: add support for SPL CPU

[Allen Martin]

Add support for specifying a different CPU for main u-boot and SPL
u-boot builds.  This is done by adding an optional SPL CPU after the
main CPU in boards.cfg as follows:

 normal_cpu:spl_cpu

This this case CPU will be set to "normal_cpu" during the main u-boot
build and "spl_cpu" during the SPL build.

Signed-off-by: Allen Martin 
Acked-by: Stephen Warren 
Tested-by: Thierry Reding 
---
 boards.cfg |5 +
 doc/README.SPL |   12 
 mkconfig   |   24 
 3 files changed, 33 insertions(+), 8 deletions(-)

diff --git a/boards.cfg b/boards.cfg
index 70507ad..35f9737 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -11,6 +11,11 @@
 #  Lines starting with '#' are comments.
 #  Blank lines are ignored.
 #
+#  The CPU field takes the form:
+#  cpu[:spl_cpu]
+#  If spl_cpu is specified the make variable CPU will be set to this
+#  during the SPL build.
+#
 #  The options field takes the form:
 #  [:comma separated config options]
 #  Each config option has the form (value defaults to "1"):
diff --git a/doc/README.SPL b/doc/README.SPL
index 0276953..e4a5ac3 100644
--- a/doc/README.SPL
+++ b/doc/README.SPL
@@ -66,3 +66,15 @@ CONFIG_SPL_DMA_SUPPORT (drivers/dma/libdma.o)
 CONFIG_SPL_POST_MEM_SUPPORT (post/drivers/memory.o)
 CONFIG_SPL_NAND_LOAD (drivers/mtd/nand/nand_spl_load.o)
 CONFIG_SPL_SPI_LOAD (drivers/mtd/spi/spi_spl_load.o)
+
+
+Normally CPU is assumed to be the same between the SPL and normal
+u-boot build.  However it is possible to specify a different CPU for
+the SPL build for cases where the SPL is expected to run on a
+different CPU model from the main u-boot.  This is done by specifying
+an SPL CPU in boards.cfg as follows:
+
+   normal_cpu:spl_cpu
+
+This this case CPU will be set to "normal_cpu" during the main u-boot
+build and "spl_cpu" during the SPL build.
diff --git a/mkconfig b/mkconfig
index 801f921..07031c6 100755
--- a/mkconfig
+++ b/mkconfig
@@ -59,7 +59,8 @@ CONFIG_NAME="${1%_config}"
 [ "${BOARD_NAME}" ] || BOARD_NAME="${1%_config}"
 
 arch="$2"
-cpu="$3"
+cpu=`echo $3 | awk 'BEGIN {FS = ":"} ; {print $1}'`
+spl_cpu=`echo $3 | awk 'BEGIN {FS = ":"} ; {print $2}'`
 if [ "$4" = "-" ] ; then
board=${BOARD_NAME}
 else
@@ -130,13 +131,20 @@ fi
 #
 # Create include file for Make
 #
-echo "ARCH   = ${arch}"  >  config.mk
-echo "CPU= ${cpu}"   >> config.mk
-echo "BOARD  = ${board}" >> config.mk
-
-[ "${vendor}" ] && echo "VENDOR = ${vendor}" >> config.mk
-
-[ "${soc}"] && echo "SOC= ${soc}">> config.mk
+( echo "ARCH   = ${arch}"
+if [ ! -z "$spl_cpu" ] ; then
+   echo 'ifeq ($(CONFIG_SPL_BUILD),y)'
+   echo "CPU= ${spl_cpu}"
+   echo "else"
+   echo "CPU= ${cpu}"
+   echo "endif"
+else
+   echo "CPU= ${cpu}"
+fi
+echo "BOARD  = ${board}"
+
+[ "${vendor}" ] && echo "VENDOR = ${vendor}"
+[ "${soc}"] && echo "SOC= ${soc}" ) > config.mk
 
 # Assign board directory to BOARDIR variable
 if [ -z "${vendor}" ] ; then
-- 
1.7.9.5

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

[U-Boot] [PATCH v7 00/15] split tegra20 arm7 code into separate SPL

[Allen Martin]

This patch series fixes a long standing problem with the tegra20
u-boot build.  Tegra20 contains an ARM7TDMI boot processor and a
Cortex A9 main processor.  Prior to this patch series this was
accomplished by #ifdefing out any armv7 code from the early boot
sequence and creating a single binary that runs on both both the
ARM7TDMI and A9.  This was very fragile as changes to compiler options
or any additions or rearranging of the early boot code could add
additional armv7 specific code causing it to fail on the ARM7TDMI.

This patch series pulls all the armv4t code out into a separate SPL
that does nothing more than initialize the A9 and transfer control to
it.  The resultint SPL and armv7 u-boot are concatenated together into
a single image.

This patch series is also available from:
git://github.com/arm000/u-boot.git
branch: tegra-spl-v7

Changes:
v7:
 - rebased to u-boot-tegra/next
 - added Acks and Tested-Bys
v6:
 - changed combined SPL/u-boot target names to u-boot-dtb-tegra.bin
 and u-boot-nodtb-tegra.bin
 - fixed regression introduced in v5 that caused git bisect to fail to
 build at one of the patches
 - fix USE_PRIVATE_LIBGCC for SPL build and enable it
 - fix libtegra20-common.so link so it works if building with out of
 tree OBJDIR
v5:
 - added missing mkdir rules in all tegra20 board Makefiles that
 include common code and changed them to be unconditional
 - make new u-boot-dtb-t2.bin rule default for tegra20 and copy
 resulting binary over u-boot.bin
v4:
 - rebased to u-boot-tegra/next
 - reordered entire patch series to preserve git bisect, verified
 build and boot at each patch
 - merged patches that add SPL config defines and removes duplicate
 code from u-boot init, these have to go in atomically to preserve
 building at each patch
 - fixed compiler warnings introduced
 - fixed blank line at end of file on cpu.c
 - renamed u-boot.t2 to u-boot-t2.bin
 - cleaned up config.mk generation in mkconfig to make it more
 readable
 - added some text to clarify using arm720t code for arm7tdmi
 - rearranged SPL memory map to make resulting SPL + u-boot image much
 smaller 
 - removed separate PAD_TO define in favor of just using
 CONFIG_SYS_TEXT_BASE 
 - moved warmboot_save_sdram_params() from dram_init() to board_init()
v3:
 - git bisect still does not work across this series, I'm saving that
 for the next revision, but I had enough changes that I wanted to get
 this out for review
 - expanded the tegra2 -> tegra20 rename to include
 functions/variables/
 defines
 - rebased to u-boot-tegra/next
 - removed some extra -march=armv4t flags, kept armv4t flags on
 warmboot_avp since it's special
 - removed bashisms from mkconfig
 - renamed CONFIG_MACH_TEGRA_GENERIC to CONFIG_TEGRA
 - moved SPL overrides to tegra2-common-post.h
 - changed SPL base address to 0x108000, u-boot goes to 0x208000
 - moved warboot_save_sdram_params fix to separate patch
 - remove USE_PRIVATE_LIBGCC from non SPL build
 - expanded SPL support to all tegra20 boards, not just seaboard
v2:
 - renamed tegra2 to tegra20 to match kernel and devicetree naming
 policy
 - pulled all SPL related config overrides to a separate file to clean
 up ifdefs from seabard.h
 - rebased to TOT u-boot/master and fixed a bug related to init
 sequence changes between this patch series and new EMC code
 - made u-boot.t2 target work even if CONFIG_OF is disabled
 - added back USE_PRIVATE_LIBGCC

Allen Martin (15):
  tegra20: rename tegra2 -> tegra20
  tegra20: move tegra20 SoC code to arch/arm/cpu/tegra20-common
  tegra20: rename CONFIG_MACH_TEGRA_GENERIC
  tegra20: tec: add tegra20-common-post.h
  tegra20: make board mkdir commands unconditional
  mkconfig: add support for SPL CPU
  ARM: Fix arm720t SPL build
  tegra20: remove timer_init from SPL build
  ARM: add tegra20 support to arm720t
  tegra20: add u-boot-*-tegra.bin targets
  tegra20: move SDRAM param save to later in boot
  tegra20: enable SPL for tegra20 boards
  arm: enable libgcc build for SPL
  spl: fix SPL build of private libgcc
  tegra20: Remove armv4t build flags

 MAINTAINERS|   18 +--
 Makefile   |   26 
 arch/arm/cpu/arm720t/cpu.c |2 +
 arch/arm/cpu/arm720t/interrupts.c  |5 +
 arch/arm/cpu/arm720t/start.S   |   19 ++-
 .../arm/cpu/arm720t/tegra20}/Makefile  |   27 ++--
 .../arch-tegra2 => cpu/arm720t/tegra20}/board.h|   11 +-
 .../{armv7/tegra2 => arm720t/tegra20}/config.mk|   12 --
 .../{armv7/tegra2/ap20.c => arm720t/tegra20/cpu.c} |  148 ++--
 .../ap20.h => cpu/arm720t/tegra20/cpu.h}   |   15 +-
 arch/arm/cpu/arm720t/tegra20/spl.c |  132 +
 arch/arm/cpu/armv7/start.S |2 -
 arch/arm/cpu/armv7/{tegra2 => tegra20}/Makefile|   15 +-
 .../cpu/armv7/{tegra2 => tegra20}/cmd_enterrcm.c   |4 +-
 arch/arm/cpu/armv7/{tegra2 => tegra20}/c

[U-Boot] [PATCH v7 13/15] arm: enable libgcc build for SPL

[Allen Martin]

Enable the building of private libgcc for SPL

Signed-off-by: Allen Martin 
Acked-by: Stephen Warren 
Tested-by: Thierry Reding 
---
 arch/arm/lib/Makefile |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 39a9550..bd3b77f 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -26,7 +26,6 @@ include $(TOPDIR)/config.mk
 LIB= $(obj)lib$(ARCH).o
 LIBGCC = $(obj)libgcc.o
 
-ifndef CONFIG_SPL_BUILD
 GLSOBJS+= _ashldi3.o
 GLSOBJS+= _ashrdi3.o
 GLSOBJS+= _divsi3.o
@@ -37,6 +36,7 @@ GLSOBJS   += _umodsi3.o
 
 GLCOBJS+= div0.o
 
+ifndef CONFIG_SPL_BUILD
 COBJS-y+= board.o
 COBJS-y+= bootm.o
 COBJS-$(CONFIG_SYS_L2_PL310) += cache-pl310.o
-- 
1.7.9.5

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

[U-Boot] [PATCH v7 15/15] tegra20: Remove armv4t build flags

[Allen Martin]

These flags were necessary when building tegra20 as a single binary
that supported ARM7TDMI and Cortex A9.  Now that the ARM7TDMI support
is split into a separate SPL, this is no longer necessary.

Signed-off-by: Allen Martin 
Acked-by: Stephen Warren 
Tested-by: Thierry Reding 
---
 arch/arm/cpu/armv7/tegra20/config.mk |   12 
 arch/arm/cpu/tegra20-common/Makefile |2 --
 2 files changed, 14 deletions(-)

diff --git a/arch/arm/cpu/armv7/tegra20/config.mk 
b/arch/arm/cpu/armv7/tegra20/config.mk
index 714daaf..6432e75 100644
--- a/arch/arm/cpu/armv7/tegra20/config.mk
+++ b/arch/arm/cpu/armv7/tegra20/config.mk
@@ -23,16 +23,4 @@
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 # MA 02111-1307 USA
 #
-
-# Tegra has an ARMv4T CPU which runs board_init_f(), so we must build these
-# files with compatible flags
-ifdef CONFIG_TEGRA20
-CFLAGS_arch/arm/lib/board.o += -march=armv4t
-CFLAGS_arch/arm/lib/memset.o += -march=armv4t
-CFLAGS_lib/string.o += -march=armv4t
-CFLAGS_common/cmd_nvedit.o += -march=armv4t
-endif
-
-USE_PRIVATE_LIBGCC = yes
-
 CONFIG_ARCH_DEVICE_TREE := tegra20
diff --git a/arch/arm/cpu/tegra20-common/Makefile 
b/arch/arm/cpu/tegra20-common/Makefile
index 60be2a6..43c96c6 100644
--- a/arch/arm/cpu/tegra20-common/Makefile
+++ b/arch/arm/cpu/tegra20-common/Makefile
@@ -27,8 +27,6 @@ include $(TOPDIR)/config.mk
 
 # The AVP is ARMv4T architecture so we must use special compiler
 # flags for any startup files it might use.
-CFLAGS_arch/arm/cpu/tegra20-common/ap20.o += -march=armv4t
-CFLAGS_arch/arm/cpu/tegra20-common/clock.o += -march=armv4t
 CFLAGS_arch/arm/cpu/tegra20-common/warmboot_avp.o += -march=armv4t
 
 LIB= $(obj)lib$(SOC)-common.o
-- 
1.7.9.5

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

[U-Boot] [PATCH v7 11/15] tegra20: move SDRAM param save to later in boot

[Allen Martin]

Move warmboot_save_sdram_params() to later in the boot sequence.  This
code relies on devicetree to get the address of the memory controller
and with upcoming changes for SPL boot it gets called early in the
boot process when devicetree is not initialized yet.

Signed-off-by: Allen Martin 
Acked-by: Stephen Warren 
Tested-by: Thierry Reding 
---
 arch/arm/cpu/tegra20-common/ap20.c |5 -
 board/nvidia/common/board.c|3 +++
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/arch/arm/cpu/tegra20-common/ap20.c 
b/arch/arm/cpu/tegra20-common/ap20.c
index 8b6afbc..6ff71e0 100644
--- a/arch/arm/cpu/tegra20-common/ap20.c
+++ b/arch/arm/cpu/tegra20-common/ap20.c
@@ -345,11 +345,6 @@ void init_pmc_scratch(void)
/* ODMDATA is for kernel use to determine RAM size, LP config, etc. */
odmdata = get_odmdata();
writel(odmdata, &pmc->pmc_scratch20);
-
-#ifdef CONFIG_TEGRA20_LP0
-   /* save Sdram params to PMC 2, 4, and 24 for WB0 */
-   warmboot_save_sdram_params();
-#endif
 }
 
 void tegra20_start(void)
diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c
index 6753f95..7ab2040 100644
--- a/board/nvidia/common/board.c
+++ b/board/nvidia/common/board.c
@@ -133,6 +133,9 @@ int board_init(void)
 #endif
 
 #ifdef CONFIG_TEGRA20_LP0
+   /* save Sdram params to PMC 2, 4, and 24 for WB0 */
+   warmboot_save_sdram_params();
+
/* prepare the WB code to LP0 location */
warmboot_prepare_code(TEGRA_LP0_ADDR, TEGRA_LP0_SIZE);
 #endif
-- 
1.7.9.5

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

[U-Boot] [PATCH v7 07/15] ARM: Fix arm720t SPL build

[Allen Martin]

Take a few SPL fixes from armv7 and apply them to arm720t:
-Use dummy exception handlers for SPL build
-Initialize relocation register r9 to 0 for the case of no relocation
-ifdef out interrupt handler code

Signed-off-by: Allen Martin 
Acked-by: Stephen Warren 
Tested-by: Thierry Reding 
---
 arch/arm/cpu/arm720t/start.S |   13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/cpu/arm720t/start.S b/arch/arm/cpu/arm720t/start.S
index 540e3c2..df66946 100644
--- a/arch/arm/cpu/arm720t/start.S
+++ b/arch/arm/cpu/arm720t/start.S
@@ -51,6 +51,15 @@ _start: breset
ldr pc, _irq
ldr pc, _fiq
 
+#ifdef CONFIG_SPL_BUILD
+_undefined_instruction: .word _undefined_instruction
+_software_interrupt:   .word _software_interrupt
+_prefetch_abort:   .word _prefetch_abort
+_data_abort:   .word _data_abort
+_not_used: .word _not_used
+_irq:  .word _irq
+_fiq:  .word _fiq
+#else
 _undefined_instruction: .word undefined_instruction
 _software_interrupt:   .word software_interrupt
 _prefetch_abort:   .word prefetch_abort
@@ -58,6 +67,7 @@ _data_abort:  .word data_abort
 _not_used: .word not_used
 _irq:  .word irq
 _fiq:  .word fiq
+#endif /* CONFIG_SPL_BUILD */
 
.balignl 16,0xdeadbeef
 
@@ -167,6 +177,7 @@ stack_setup:
 
adr r0, _start
cmp r0, r6
+   moveq   r9, #0  /* no relocation. relocation offset(r9) = 0 */
beq clear_bss   /* skip relocation */
mov r1, r6  /* r1 <- scratch for copy_loop */
ldr r3, _bss_start_ofs
@@ -425,6 +436,7 @@ lock_loop:
mov pc, lr
 
 
+#ifndef CONFIG_SPL_BUILD
 /*
  *
  *
@@ -587,6 +599,7 @@ fiq:
bl  do_fiq
 
 #endif
+#endif /* CONFIG_SPL_BUILD */
 
 #if defined(CONFIG_NETARM)
.align  5
-- 
1.7.9.5

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

[U-Boot] [PATCH v7 14/15] spl: fix SPL build of private libgcc

[Allen Martin]

This fixes the SPL build to link with the SPL version of libgcc if
USE_PRIVATE_LIBGCC is set to "yes".  Previously it was linking with
the libgcc from the normal u-boot build because it gets set in
PLATFORM_LIBS and passed down the to the SPL build.

Signed-off-by: Allen Martin 
Acked-by: Stephen Warren 
Tested-by: Thierry Reding 
---
 spl/Makefile |6 ++
 1 file changed, 6 insertions(+)

diff --git a/spl/Makefile b/spl/Makefile
index d04d2f2..c82e9de 100644
--- a/spl/Makefile
+++ b/spl/Makefile
@@ -66,6 +66,12 @@ ifeq ($(SOC),tegra20)
 LIBS-y += arch/$(ARCH)/cpu/$(SOC)-common/lib$(SOC)-common.o
 endif
 
+# Add GCC lib
+ifeq ("$(USE_PRIVATE_LIBGCC)", "yes")
+PLATFORM_LIBGCC = $(SPLTREE)/arch/$(ARCH)/lib/libgcc.o
+PLATFORM_LIBS := $(filter-out %/libgcc.o, $(filter-out -lgcc, 
$(PLATFORM_LIBS))) $(PLATFORM_LIBGCC)
+endif
+
 START := $(addprefix $(SPLTREE)/,$(START))
 LIBS := $(addprefix $(SPLTREE)/,$(sort $(LIBS-y)))
 
-- 
1.7.9.5

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

[U-Boot] [PATCH v7 02/15] tegra20: move tegra20 SoC code to arch/arm/cpu/tegra20-common

[Allen Martin]

In preparation for splitting out the armv4t code from tegra20, move
the tegra20 SoC code to arch/arm/cpu/tegra20-common.  This code will
be compiled armv4t for the arm7tdmi and armv7 for the cortex A9.

Signed-off-by: Allen Martin 
Acked-by: Stephen Warren 
Tested-by: Thierry Reding 
---
 Makefile   |3 ++
 arch/arm/cpu/armv7/tegra20/Makefile|   15 ++
 .../cpu/{armv7/tegra20 => tegra20-common}/Makefile |   31 +---
 .../cpu/{armv7/tegra20 => tegra20-common}/ap20.c   |0
 .../cpu/{armv7/tegra20 => tegra20-common}/board.c  |0
 .../cpu/{armv7/tegra20 => tegra20-common}/clock.c  |0
 .../cpu/{armv7/tegra20 => tegra20-common}/crypto.c |0
 .../cpu/{armv7/tegra20 => tegra20-common}/crypto.h |0
 .../cpu/{armv7/tegra20 => tegra20-common}/emc.c|0
 .../{armv7/tegra20 => tegra20-common}/funcmux.c|0
 .../tegra20 => tegra20-common}/lowlevel_init.S |0
 .../cpu/{armv7/tegra20 => tegra20-common}/pinmux.c |0
 .../cpu/{armv7/tegra20 => tegra20-common}/pmu.c|0
 .../{armv7/tegra20 => tegra20-common}/sys_info.c   |0
 .../cpu/{armv7/tegra20 => tegra20-common}/timer.c  |0
 .../{armv7/tegra20 => tegra20-common}/warmboot.c   |0
 .../tegra20 => tegra20-common}/warmboot_avp.c  |0
 .../tegra20 => tegra20-common}/warmboot_avp.h  |0
 spl/Makefile   |4 +++
 19 files changed, 23 insertions(+), 30 deletions(-)
 copy arch/arm/cpu/{armv7/tegra20 => tegra20-common}/Makefile (66%)
 rename arch/arm/cpu/{armv7/tegra20 => tegra20-common}/ap20.c (100%)
 rename arch/arm/cpu/{armv7/tegra20 => tegra20-common}/board.c (100%)
 rename arch/arm/cpu/{armv7/tegra20 => tegra20-common}/clock.c (100%)
 rename arch/arm/cpu/{armv7/tegra20 => tegra20-common}/crypto.c (100%)
 rename arch/arm/cpu/{armv7/tegra20 => tegra20-common}/crypto.h (100%)
 rename arch/arm/cpu/{armv7/tegra20 => tegra20-common}/emc.c (100%)
 rename arch/arm/cpu/{armv7/tegra20 => tegra20-common}/funcmux.c (100%)
 rename arch/arm/cpu/{armv7/tegra20 => tegra20-common}/lowlevel_init.S (100%)
 rename arch/arm/cpu/{armv7/tegra20 => tegra20-common}/pinmux.c (100%)
 rename arch/arm/cpu/{armv7/tegra20 => tegra20-common}/pmu.c (100%)
 rename arch/arm/cpu/{armv7/tegra20 => tegra20-common}/sys_info.c (100%)
 rename arch/arm/cpu/{armv7/tegra20 => tegra20-common}/timer.c (100%)
 rename arch/arm/cpu/{armv7/tegra20 => tegra20-common}/warmboot.c (100%)
 rename arch/arm/cpu/{armv7/tegra20 => tegra20-common}/warmboot_avp.c (100%)
 rename arch/arm/cpu/{armv7/tegra20 => tegra20-common}/warmboot_avp.h (100%)

diff --git a/Makefile b/Makefile
index 85e36ec..0ff6b3c 100644
--- a/Makefile
+++ b/Makefile
@@ -322,6 +322,9 @@ endif
 ifeq ($(SOC),exynos)
 LIBS += $(CPUDIR)/s5p-common/libs5p-common.o
 endif
+ifeq ($(SOC),tegra20)
+LIBS += arch/$(ARCH)/cpu/$(SOC)-common/lib$(SOC)-common.o
+endif
 
 LIBS := $(addprefix $(obj),$(sort $(LIBS)))
 .PHONY : $(LIBS)
diff --git a/arch/arm/cpu/armv7/tegra20/Makefile 
b/arch/arm/cpu/armv7/tegra20/Makefile
index da62646..5f4035d 100644
--- a/arch/arm/cpu/armv7/tegra20/Makefile
+++ b/arch/arm/cpu/armv7/tegra20/Makefile
@@ -23,27 +23,16 @@
 # MA 02111-1307 USA
 #
 
-# The AVP is ARMv4T architecture so we must use special compiler
-# flags for any startup files it might use.
-CFLAGS_arch/arm/cpu/armv7/tegra20/ap20.o += -march=armv4t
-CFLAGS_arch/arm/cpu/armv7/tegra20/clock.o += -march=armv4t
-CFLAGS_arch/arm/cpu/armv7/tegra20/warmboot_avp.o += -march=armv4t
-
 include $(TOPDIR)/config.mk
 
 LIB=  $(obj)lib$(SOC).o
 
-SOBJS  := lowlevel_init.o
-COBJS-y:= ap20.o board.o clock.o funcmux.o pinmux.o sys_info.o timer.o
-COBJS-$(CONFIG_TEGRA_CLOCK_SCALING) += emc.o
-COBJS-$(CONFIG_TEGRA_PMU) += pmu.o
 COBJS-$(CONFIG_USB_EHCI_TEGRA) += usb.o
-COBJS-$(CONFIG_TEGRA20_LP0) += crypto.o warmboot.o warmboot_avp.o
 COBJS-$(CONFIG_CMD_ENTERRCM) += cmd_enterrcm.o
 
 COBJS  := $(COBJS-y)
-SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
-OBJS   := $(addprefix $(obj),$(COBJS) $(SOBJS))
+SRCS   := $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
 
 all:$(obj).depend $(LIB)
 
diff --git a/arch/arm/cpu/armv7/tegra20/Makefile 
b/arch/arm/cpu/tegra20-common/Makefile
similarity index 66%
copy from arch/arm/cpu/armv7/tegra20/Makefile
copy to arch/arm/cpu/tegra20-common/Makefile
index da62646..60be2a6 100644
--- a/arch/arm/cpu/armv7/tegra20/Makefile
+++ b/arch/arm/cpu/tegra20-common/Makefile
@@ -1,7 +1,7 @@
 #
 # (C) Copyright 2010,2011 Nvidia Corporation.
 #
-# (C) Copyright 2000-2003
+# (C) Copyright 2000-2008
 # Wolfgang Denk, DENX Software Engineering, w...@denx.de.
 #
 # See file CREDITS for list of people who contributed to this
@@ -14,7 +14,7 @@
 #
 # 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
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURP

[U-Boot] [PATCH v7 08/15] tegra20: remove timer_init from SPL build

[Allen Martin]

Don't use timer_init from tegra board.c.  This comes out of arm720t
for the SPL build.

Signed-off-by: Allen Martin 
Acked-by: Stephen Warren 
Tested-by: Thierry Reding 
---
 board/nvidia/common/board.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c
index d1a7f3a..6753f95 100644
--- a/board/nvidia/common/board.c
+++ b/board/nvidia/common/board.c
@@ -49,6 +49,7 @@ const struct tegra20_sysinfo sysinfo = {
CONFIG_TEGRA20_BOARD_STRING
 };
 
+#ifndef CONFIG_SPL_BUILD
 /*
  * Routine: timer_init
  * Description: init the timestamp and lastinc value
@@ -57,6 +58,7 @@ int timer_init(void)
 {
return 0;
 }
+#endif
 
 void __pin_mux_usb(void)
 {
-- 
1.7.9.5

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

[U-Boot] [PATCH v7 05/15] tegra20: make board mkdir commands unconditional

[Allen Martin]

Change the mkdir commands for the object directories to be
unconditional.  This fixes an issue when building for SPL where
SRCTREE and OBJTREE are the same, but $(obj) is under SPLTREE.

Signed-off-by: Allen Martin 
Acked-by: Stephen Warren 
Tested-by: Thierry Reding 
---
 board/avionic-design/medcom/Makefile |2 --
 board/avionic-design/plutux/Makefile |2 --
 board/avionic-design/tec/Makefile|2 --
 board/compal/paz00/Makefile  |2 --
 board/compulab/trimslice/Makefile|2 --
 5 files changed, 10 deletions(-)

diff --git a/board/avionic-design/medcom/Makefile 
b/board/avionic-design/medcom/Makefile
index d96d043..864bc0e 100644
--- a/board/avionic-design/medcom/Makefile
+++ b/board/avionic-design/medcom/Makefile
@@ -25,9 +25,7 @@
 
 include $(TOPDIR)/config.mk
 
-ifneq ($(OBJTREE),$(SRCTREE))
 $(shell mkdir -p $(obj)../common $(obj)../../nvidia/common)
-endif
 
 LIB= $(obj)lib$(BOARD).o
 
diff --git a/board/avionic-design/plutux/Makefile 
b/board/avionic-design/plutux/Makefile
index d96d043..864bc0e 100644
--- a/board/avionic-design/plutux/Makefile
+++ b/board/avionic-design/plutux/Makefile
@@ -25,9 +25,7 @@
 
 include $(TOPDIR)/config.mk
 
-ifneq ($(OBJTREE),$(SRCTREE))
 $(shell mkdir -p $(obj)../common $(obj)../../nvidia/common)
-endif
 
 LIB= $(obj)lib$(BOARD).o
 
diff --git a/board/avionic-design/tec/Makefile 
b/board/avionic-design/tec/Makefile
index d96d043..864bc0e 100644
--- a/board/avionic-design/tec/Makefile
+++ b/board/avionic-design/tec/Makefile
@@ -25,9 +25,7 @@
 
 include $(TOPDIR)/config.mk
 
-ifneq ($(OBJTREE),$(SRCTREE))
 $(shell mkdir -p $(obj)../common $(obj)../../nvidia/common)
-endif
 
 LIB= $(obj)lib$(BOARD).o
 
diff --git a/board/compal/paz00/Makefile b/board/compal/paz00/Makefile
index 488e381..7f7287e 100644
--- a/board/compal/paz00/Makefile
+++ b/board/compal/paz00/Makefile
@@ -16,9 +16,7 @@
 
 include $(TOPDIR)/config.mk
 
-ifneq ($(OBJTREE),$(SRCTREE))
 $(shell mkdir -p $(obj)../../nvidia/common)
-endif
 
 LIB= $(obj)lib$(BOARD).o
 
diff --git a/board/compulab/trimslice/Makefile 
b/board/compulab/trimslice/Makefile
index bf624f4..ff07879 100644
--- a/board/compulab/trimslice/Makefile
+++ b/board/compulab/trimslice/Makefile
@@ -24,9 +24,7 @@
 
 include $(TOPDIR)/config.mk
 
-ifneq ($(OBJTREE),$(SRCTREE))
 $(shell mkdir -p $(obj)../../nvidia/common)
-endif
 
 LIB= $(obj)lib$(BOARD).o
 
-- 
1.7.9.5

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

[U-Boot] [PATCH v7 10/15] tegra20: add u-boot-*-tegra.bin targets

[Allen Martin]

Add target for tegra20 u-boot image.  This is a concatenation of tegra
spl and normal u-boot binaries.  For non-devicetree builds this is
named "u-boot-nodtb-tegra.bin" for devicetree builds is named
"u-boot-dtb-tegra.bin".

Signed-off-by: Allen Martin 
Acked-by: Stephen Warren 
Tested-by: Thierry Reding 
---
 Makefile |   14 ++
 1 file changed, 14 insertions(+)

diff --git a/Makefile b/Makefile
index 0ff6b3c..9612930 100644
--- a/Makefile
+++ b/Makefile
@@ -475,6 +475,20 @@ $(obj)u-boot.spr:  $(obj)u-boot.img 
$(obj)spl/u-boot-spl.bin
conv=notrunc 2>/dev/null
cat $(obj)spl/u-boot-spl-pad.img $(obj)u-boot.img > $@
 
+ifeq ($(SOC),tegra20)
+ifeq ($(CONFIG_OF_SEPARATE),y)
+$(obj)u-boot-dtb-tegra.bin:$(obj)spl/u-boot-spl.bin $(obj)u-boot.bin 
$(obj)u-boot.dtb
+   $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(CONFIG_SYS_TEXT_BASE) -O 
binary $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin
+   cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin 
$(obj)u-boot.dtb > $@
+   rm $(obj)spl/u-boot-spl-pad.bin
+else
+$(obj)u-boot-nodtb-tegra.bin:  $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
+   $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(CONFIG_SYS_TEXT_BASE) -O 
binary $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin
+   cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin > $@
+   rm $(obj)spl/u-boot-spl-pad.bin
+endif
+endif
+
 ifeq ($(CONFIG_SANDBOX),y)
 GEN_UBOOT = \
cd $(LNDIR) && $(CC) $(SYMS) -T $(obj)u-boot.lds \
-- 
1.7.9.5

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

[U-Boot] [PATCH v7 09/15] ARM: add tegra20 support to arm720t

[Allen Martin]

Add support for tegra20 arm7 boot processor.  This processor is used
to power on the Cortex A9 and transfer control to it.  In tegra this
processor is an ARM7TDMI not an ARM720T, but since we don't use cache
it was easier to just reuse the ARM720T code as the processors are
otherwise identical except for cache and MMU.

Signed-off-by: Allen Martin 
Acked-by: Stephen Warren 
Tested-by: Thierry Reding 
---
 arch/arm/cpu/arm720t/cpu.c   |2 +
 arch/arm/cpu/arm720t/interrupts.c|5 +
 arch/arm/cpu/arm720t/start.S |6 +-
 arch/arm/cpu/arm720t/tegra20/Makefile|   48 +
 arch/arm/cpu/arm720t/tegra20/board.h |   25 +++
 arch/arm/cpu/arm720t/tegra20/config.mk   |   26 +++
 arch/arm/cpu/arm720t/tegra20/cpu.c   |  258 ++
 arch/arm/cpu/arm720t/tegra20/cpu.h   |  100 ++
 arch/arm/cpu/arm720t/tegra20/spl.c   |  132 +
 arch/arm/include/asm/arch-tegra20/hardware.h |   29 +++
 10 files changed, 630 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/cpu/arm720t/tegra20/Makefile
 create mode 100644 arch/arm/cpu/arm720t/tegra20/board.h
 create mode 100644 arch/arm/cpu/arm720t/tegra20/config.mk
 create mode 100644 arch/arm/cpu/arm720t/tegra20/cpu.c
 create mode 100644 arch/arm/cpu/arm720t/tegra20/cpu.h
 create mode 100644 arch/arm/cpu/arm720t/tegra20/spl.c
 create mode 100644 arch/arm/include/asm/arch-tegra20/hardware.h

diff --git a/arch/arm/cpu/arm720t/cpu.c b/arch/arm/cpu/arm720t/cpu.c
index 974f288..b6eee7e 100644
--- a/arch/arm/cpu/arm720t/cpu.c
+++ b/arch/arm/cpu/arm720t/cpu.c
@@ -51,6 +51,8 @@ int cleanup_before_linux (void)
/* Nothing more needed */
 #elif defined(CONFIG_INTEGRATOR) && defined(CONFIG_ARCH_INTEGRATOR)
/* No cleanup before linux for IntegratorAP/CM720T as yet */
+#elif defined (CONFIG_TEGRA)
+   /* No cleanup before linux for tegra as yet */
 #else
 #error No cleanup_before_linux() defined for this CPU type
 #endif
diff --git a/arch/arm/cpu/arm720t/interrupts.c 
b/arch/arm/cpu/arm720t/interrupts.c
index 464dd30..c2f898f 100644
--- a/arch/arm/cpu/arm720t/interrupts.c
+++ b/arch/arm/cpu/arm720t/interrupts.c
@@ -180,6 +180,9 @@ int timer_init (void)
PUT32(T0TC, 0);
PUT32(T0TCR, 1);/* enable timer0 */
 
+#elif defined(CONFIG_TEGRA)
+   /* No timer routines for tegra as yet */
+   lastdec = 0;
 #else
 #error No timer_init() defined for this CPU type
 #endif
@@ -282,6 +285,8 @@ void __udelay (unsigned long usec)
 
 #elif defined(CONFIG_INTEGRATOR) && defined(CONFIG_ARCH_INTEGRATOR)
/* No timer routines for IntegratorAP/CM720T as yet */
+#elif defined(CONFIG_TEGRA)
+   /* No timer routines for tegra as yet */
 #else
 #error Timer routines not defined for this CPU type
 #endif
diff --git a/arch/arm/cpu/arm720t/start.S b/arch/arm/cpu/arm720t/start.S
index df66946..3371d3d 100644
--- a/arch/arm/cpu/arm720t/start.S
+++ b/arch/arm/cpu/arm720t/start.S
@@ -407,6 +407,8 @@ lock_loop:
ldr r0, VPBDIV_ADR
mov r1, #0x01   /* VPB clock is same as process clock */
str r1, [r0]
+#elif defined(CONFIG_TEGRA)
+   /* No cpu_init_crit for tegra as yet */
 #else
 #error No cpu_init_crit() defined for current CPU type
 #endif
@@ -422,7 +424,7 @@ lock_loop:
str r1, [r0]
 #endif
 
-#ifndef CONFIG_LPC2292
+#if !defined(CONFIG_LPC2292) && !defined(CONFIG_TEGRA)
mov ip, lr
/*
 * before relocating, we have to setup RAM timing
@@ -631,6 +633,8 @@ reset_cpu:
 .globl reset_cpu
 reset_cpu:
mov pc, r0
+#elif defined(CONFIG_TEGRA)
+   /* No specific reset actions for tegra as yet */
 #else
 #error No reset_cpu() defined for current CPU type
 #endif
diff --git a/arch/arm/cpu/arm720t/tegra20/Makefile 
b/arch/arm/cpu/arm720t/tegra20/Makefile
new file mode 100644
index 000..6e48475
--- /dev/null
+++ b/arch/arm/cpu/arm720t/tegra20/Makefile
@@ -0,0 +1,48 @@
+#
+# (C) Copyright 2010,2011 Nvidia Corporation.
+#
+# (C) Copyright 2000-2008
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(SOC).o
+
+

[U-Boot] [PATCH v7 03/15] tegra20: rename CONFIG_MACH_TEGRA_GENERIC

[Allen Martin]

Rename CONFIG_MACH_TEGRA_GENERIC to the less confusing CONFIG_TEGRA.
The meaning of the config options is now:

CONFIG_TEGRA - Any tegra chip
CONFIG_TEGRA20 - A tegra20 family chip
CONFIG_TEGRA30 - A tegra30 family chip (not added yet)

Signed-off-by: Allen Martin 
Acked-by: Stephen Warren 
Tested-by: Thierry Reding 
---
 include/configs/tegra20-common.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/tegra20-common.h b/include/configs/tegra20-common.h
index 91cf28c..769728b 100644
--- a/include/configs/tegra20-common.h
+++ b/include/configs/tegra20-common.h
@@ -38,7 +38,7 @@
  */
 #define CONFIG_ARMCORTEXA9 /* This is an ARM V7 CPU core */
 #define CONFIG_TEGRA20 /* in a NVidia Tegra20 core */
-#define CONFIG_MACH_TEGRA_GENERIC  /* which is a Tegra generic machine */
+#define CONFIG_TEGRA   /* which is a Tegra generic machine */
 #define CONFIG_SYS_L2CACHE_OFF /* No L2 cache */
 
 #define CONFIG_SYS_CACHELINE_SIZE  32
-- 
1.7.9.5

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

[U-Boot] [PATCH v7 12/15] tegra20: enable SPL for tegra20 boards

[Allen Martin]

Add SPL options to tegra20 config files and enable SPL build for
tegra20 boards.  Also remove redundant code from u-boot that is not
contained in SPL.

Signed-off-by: Allen Martin 
Acked-by: Stephen Warren 
Tested-by: Thierry Reding 
---
 Makefile  |9 ++
 arch/arm/cpu/armv7/start.S|2 -
 arch/arm/cpu/tegra20-common/ap20.c|  258 +
 arch/arm/cpu/tegra20-common/board.c   |   23 +--
 boards.cfg|   18 +--
 include/configs/tegra20-common-post.h |   65 +
 include/configs/tegra20-common.h  |   22 ++-
 7 files changed, 104 insertions(+), 293 deletions(-)

diff --git a/Makefile b/Makefile
index 9612930..ea85ed3 100644
--- a/Makefile
+++ b/Makefile
@@ -384,6 +384,15 @@ ONENAND_BIN ?= $(obj)onenand_ipl/onenand-ipl-2k.bin
 ALL-$(CONFIG_SPL) += $(obj)spl/u-boot-spl.bin
 ALL-$(CONFIG_OF_SEPARATE) += $(obj)u-boot.dtb $(obj)u-boot-dtb.bin
 
+# enable combined SPL/u-boot/dtb rules for tegra
+ifeq ($(SOC),tegra20)
+ifeq ($(CONFIG_OF_SEPARATE),y)
+ALL-y += $(obj)u-boot-dtb-tegra.bin
+else
+ALL-y += $(obj)u-boot-nodtb-tegra.bin
+endif
+endif
+
 all:   $(ALL-y) $(SUBDIR_EXAMPLES)
 
 $(obj)u-boot.dtb:  $(obj)u-boot
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index 6cfdfd2..5487ee0 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -133,7 +133,6 @@ reset:
orr r0, r0, #0xd3
msr cpsr,r0
 
-#if !defined(CONFIG_TEGRA20)
 /*
  * Setup vector:
  * (OMAP4 spl TEXT_BASE is not 32 byte aligned.
@@ -149,7 +148,6 @@ reset:
ldr r0, =_start
mcr p15, 0, r0, c12, c0, 0  @Set VBAR
 #endif
-#endif /* !Tegra20 */
 
/* the mask ROM code should have PLL and others stable */
 #ifndef CONFIG_SKIP_LOWLEVEL_INIT
diff --git a/arch/arm/cpu/tegra20-common/ap20.c 
b/arch/arm/cpu/tegra20-common/ap20.c
index 6ff71e0..2d4705a 100644
--- a/arch/arm/cpu/tegra20-common/ap20.c
+++ b/arch/arm/cpu/tegra20-common/ap20.c
@@ -20,16 +20,11 @@
 * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 * MA 02111-1307 USA
 */
-
 #include 
-#include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -68,235 +63,7 @@ int tegra_get_chip_type(void)
return TEGRA_SOC_UNKNOWN;
 }
 
-/* Returns 1 if the current CPU executing is a Cortex-A9, else 0 */
-static int ap20_cpu_is_cortexa9(void)
-{
-   u32 id = readb(NV_PA_PG_UP_BASE + PG_UP_TAG_0);
-   return id == (PG_UP_TAG_0_PID_CPU & 0xff);
-}
-
-void init_pllx(void)
-{
-   struct clk_rst_ctlr *clkrst =
-   (struct clk_rst_ctlr *)NV_PA_CLK_RST_BASE;
-   struct clk_pll_simple *pll =
-   &clkrst->crc_pll_simple[CLOCK_ID_XCPU - CLOCK_ID_FIRST_SIMPLE];
-   u32 reg;
-
-   /* If PLLX is already enabled, just return */
-   if (readl(&pll->pll_base) & PLL_ENABLE_MASK)
-   return;
-
-   /* Set PLLX_MISC */
-   writel(1 << PLL_CPCON_SHIFT, &pll->pll_misc);
-
-   /* Use 12MHz clock here */
-   reg = PLL_BYPASS_MASK | (12 << PLL_DIVM_SHIFT);
-   reg |= 1000 << PLL_DIVN_SHIFT;
-   writel(reg, &pll->pll_base);
-
-   reg |= PLL_ENABLE_MASK;
-   writel(reg, &pll->pll_base);
-
-   reg &= ~PLL_BYPASS_MASK;
-   writel(reg, &pll->pll_base);
-}
-
-static void enable_cpu_clock(int enable)
-{
-   struct clk_rst_ctlr *clkrst = (struct clk_rst_ctlr *)NV_PA_CLK_RST_BASE;
-   u32 clk;
-
-   /*
-* NOTE:
-* Regardless of whether the request is to enable or disable the CPU
-* clock, every processor in the CPU complex except the master (CPU 0)
-* will have it's clock stopped because the AVP only talks to the
-* master. The AVP does not know (nor does it need to know) that there
-* are multiple processors in the CPU complex.
-*/
-
-   if (enable) {
-   /* Initialize PLLX */
-   init_pllx();
-
-   /* Wait until all clocks are stable */
-   udelay(PLL_STABILIZATION_DELAY);
-
-   writel(CCLK_BURST_POLICY, &clkrst->crc_cclk_brst_pol);
-   writel(SUPER_CCLK_DIVIDER, &clkrst->crc_super_cclk_div);
-   }
-
-   /*
-* Read the register containing the individual CPU clock enables and
-* always stop the clock to CPU 1.
-*/
-   clk = readl(&clkrst->crc_clk_cpu_cmplx);
-   clk |= 1 << CPU1_CLK_STP_SHIFT;
-
-   /* Stop/Unstop the CPU clock */
-   clk &= ~CPU0_CLK_STP_MASK;
-   clk |= !enable << CPU0_CLK_STP_SHIFT;
-   writel(clk, &clkrst->crc_clk_cpu_cmplx);
-
-   clock_enable(PERIPH_ID_CPU);
-}
-
-static int is_cpu_powered(void)
-{
-   struct pmc_ctlr *pmc = (struct pmc_ctlr *)TEGRA20_PMC_BASE;
-
-   return (readl(&pmc->pmc_pwrgate_status) & CPU_PWRED) ? 1 : 0;
-}
-
-static void remove_cpu_io_clamps(void)
-{
-   struct pmc_ctlr *pmc = (struct pmc_ctl

Re: [U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12

[Graeme Russ]

Hi Detlev,

On Tue, Jul 17, 2012 at 7:30 AM, Detlev Zundel  wrote:

>
> * Conflict resolution: setting up a moderator procedure for
>   unhappy submitters
>
> A recent occurence on the mailing list where contributers were sent
> through multiple rounds of patch submissions for non-obvious reasons was
> used as a ground for discussing non-technical aspects of patch
> submissions.  It was especially discussed that the privilege of being a
> custodian in U-Boot also brings obligations that should be defined more
> clearly.  Essentially we would like to see somewhat "enforceable" rights
> for the "motor" of the project, i.e. for patch submitters.
>
> For this we should extend our documentation to clearly cover
> responsibility of custodiands.  Require making constructive (testable)
> suggestions on how to get patch accepted when nak-ing patches for
> example.  This can also be enforced by patch submitters by waiting for
> clear and precise suggestions for re-work.
>
> It was also found to be a good idea to document people willing to act as
> "moderators" for unhappy contributers, i.e. who can look into problems
> and try to moderate.  (I would volunteer to be such a moderator).

For some first time submitters, it can be a very daunting (and discouraging)
process to get patches accepted - Especially if they are submitting a large
and complex patch-set to introduce a new board or arch.

I have in the past acted as a mentor for first-time submitters. This
involved taking the submission offline for a couple of revisions. This
gives the submitter some room for error and an opportunity to have the
submission process explained in direct relation to their patches without
the often blunt and confusing feedback that arises on the list. Of course
this has it's own set of problems as it can result in strange revision
numbers when the patches come back to the list.

I'm more than happy to continue doing this on the understanding that it
can lead to some 'jitter' in the submission process.

> Currently the lack of any reaction whatsoever was identified to be a
> very discouraging sign for contributors. One thing we could do is to
> declare a "soft" time-limit (two weeks) that patches need to be looked
> at.  After this time-limit, one could declare "backup-custodians" to
> push patches to or merge patches into some "-staging" branch.  (What to
> do with that branch then?) For this to work, custodians would need to
> announce "off-times" which currently is not general consensus.

I like this idea in principle. In order to work, I think there needs to be
two or three 'top-tier' custodians who will arbitrarily assign 'stale'
patches to another custodian. And maybe one top-top-tier custodian (Hi
Wolfgang ;)) in case the patch goes very stale.

I think a couple of ideas could be employed:
 - If a custodian is backlogged (or otherwise unable to immediately review
   the patch) they should issue a quick reply with an estimated date that
   they will be able to review the patch. At least then the submitter is
   not left in the dark
 - If a custodian simply does not have time to review a patch, they should
   request for another custodian to take ownership. If no other custodian
   responds, the top-tier custodians can take action.
 - If a patch is submitted outside the merge window, or the patch requires
   major rework such that the custodian does not think the patch will be
   included in the current merge, a clear message needs to be provided to
   the submitter (The recent ZFS patches are a good example)
 - If the patch is a 'miscellaneous' patch (i.e. no clear custodian) then
   whichever custodian 'claims' it should send a message back to the list
   stating so - That custodian is then responsible for communicating with
   the submitter regarding the status of the patch (via the list or offline
   if required - see my mentoring comments above)

Whatever we do, each patch needs to have clear indications of:
 - Which custodian is responsible for it
 - When it will get reviewed
 - What the review state is (approved, awaiting changes, rejected etc)
 - When it will get merged (current release or next release)

> * Patchwork pros / cons
>
> While talking about the patch submission process it became clear that
> the handling through patchwork still has some unsolved problems, the
> most obvious being the large backlog of patches in the archieve.

I haven't had a chance to do my usual patchwork housekeeping for a while.
When annoying thing about patchwork is that old revisions do not get
automatically marked as superseded.

> It was agreed that automatic marking of changes as accepted when changes
> hit mainline would be a good thing.  There is some info on our wiki
> available, although it is not clear who uses them:
>
> http://www.denx.de/wiki/view/U-Boot/Patches#pwclient and
> http://www.mail-archive.com/patchwork@lists.ozlabs.org/msg00057.html
>
> A tool to automatically mark patches as superceded on newer versions
> was also su

Re: [U-Boot] [PATCH u-boot-arm/next 2/2] OMAP3: igep00x0: add SPL support for IGEP-based boards

[Javier Martinez Canillas]

On Mon, Jul 16, 2012 at 8:01 PM, Tom Rini  wrote:
> On 07/13/2012 12:41 PM, Javier Martinez Canillas wrote:
>
>> This patch adds SPL support for IGEP-based boards.
>>
>> Tested on an IGEPv2 Rev.C board with Micron NAND Flash memory.
> [snip]
>> +#define CONFIG_SPL_MAX_SIZE  (45 * 1024)
>
> This should be 54 * 1024.  Thanks!
>
> --
> Tom

Hi Tom,

Ok thanks a lot for your feedback. I'll fix it and send a v2 of the patch.

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

Re: [U-Boot] [PATCH u-boot-arm/next 1/2] OMAP3: igep00x0: Add config option to choose flash storage memory

[Javier Martinez Canillas]

On Mon, Jul 16, 2012 at 7:58 PM, Tom Rini  wrote:
> On 07/16/2012 12:43 AM, Enric Balletbò i Serra wrote:
>
> [snip]
>> I would like to investigateif we can do this using runtime detection
>> instead of a separate config option. Give me some days. The runtime
>> detection can be done reading the sysboot configuration for example. I
>> think it's possible, do you think would be possible ?
>
> Until we have the device model and the ability to see at run-time if we
> have say NAND or OneNAND (or neither!) we can't because we have to
> build-time define where the environment will be found.
>
> --
> Tom

Hi Enric,

Runtime detection is possible reading the sysboot as you said (in fact
this is how we do it in the kernel) but as Tom said I didn't find a
common way to do this. I guess you can manually detect the NAND type
and configure the GPMC registers on the board code but I didn't see
other OMAP boards doing this. Instead I found other examples of boards
using compile options to choose between memory types.

Of course I will be more than glad if you have a better approach to
solve this :-)

Thanks a lot and best regards,
Javier
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH u-boot-arm/next 1/2] OMAP3: igep00x0: Add config option to choose flash storage memory

[Tom Rini]

On 07/16/2012 04:41 PM, Javier Martinez Canillas wrote:

[snip]
> Runtime detection is possible reading the sysboot as you said (in fact
> this is how we do it in the kernel) but as Tom said I didn't find a
> common way to do this. I guess you can manually detect the NAND type
> and configure the GPMC registers on the board code but I didn't see
> other OMAP boards doing this. Instead I found other examples of boards
> using compile options to choose between memory types.
> 
> Of course I will be more than glad if you have a better approach to
> solve this :-)

The biggest problem is that today we don't have a way to read/write
environment to a dynamically detected backing store.  I had an idea on
how to do this, but given the device model will also allow for this,
easier, that's the way to go.

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

[U-Boot] [PATCH u-boot-arm/next v2 1/1] OMAP3: igep00x0: add SPL support for IGEP-based boards

[Javier Martinez Canillas]

This patch adds SPL support for IGEP-based boards.

Tested on an IGEPv2 Rev.C board with Micron NAND Flash memory.

Signed-off-by: Javier Martinez Canillas 
---

Changes since v1:
- CONFIG_SPL_MAX_SIZE should be 54 * 1024 instead of 45 * 1024 as
  suggested by Tom Rini

 board/isee/igep0020/config.mk  |   33 
 board/isee/igep0020/igep0020.c |   34 -
 board/isee/igep0030/config.mk  |   33 
 board/isee/igep0030/igep0030.c |   34 -
 include/configs/igep00x0.h |   65 
 5 files changed, 131 insertions(+), 68 deletions(-)
 delete mode 100644 board/isee/igep0020/config.mk
 delete mode 100644 board/isee/igep0030/config.mk

diff --git a/board/isee/igep0020/config.mk b/board/isee/igep0020/config.mk
deleted file mode 100644
index 7964621..000
--- a/board/isee/igep0020/config.mk
+++ /dev/null
@@ -1,33 +0,0 @@
-#
-# (C) Copyright 2009
-# ISEE 2007 SL, 
-#
-# IGEP0020 uses OMAP3 (ARM-CortexA8) cpu
-# see http://www.ti.com/ for more information on Texas Instruments
-#
-# 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
-#
-# Physical Address:
-# 8000' (bank0)
-# A000/ (bank1)
-# Linux-Kernel is expected to be at 8000'8000, entry 8000'8000
-# (mem base + reserved)
-
-# For use with external or internal boots.
-CONFIG_SYS_TEXT_BASE = 0x80008000
diff --git a/board/isee/igep0020/igep0020.c b/board/isee/igep0020/igep0020.c
index 971e31b..40436d6 100644
--- a/board/isee/igep0020/igep0020.c
+++ b/board/isee/igep0020/igep0020.c
@@ -58,6 +58,38 @@ int board_init(void)
return 0;
 }
 
+#ifdef CONFIG_SPL_BUILD
+/*
+ * Routine: omap_rev_string
+ * Description: For SPL builds output board rev
+ */
+void omap_rev_string(void)
+{
+}
+
+/*
+ * Routine: get_board_mem_timings
+ * Description: If we use SPL then there is no x-loader nor config header
+ * so we have to setup the DDR timings ourself on both banks.
+ */
+void get_board_mem_timings(u32 *mcfg, u32 *ctrla, u32 *ctrlb, u32 *rfr_ctrl,
+   u32 *mr)
+{
+   *mr = MICRON_V_MR_165;
+#ifdef CONFIG_BOOT_NAND
+   *mcfg = MICRON_V_MCFG_165(512 << 20);
+   *ctrla = MICRON_V_ACTIMA_165;
+   *ctrlb = MICRON_V_ACTIMB_165;
+   *rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_165MHz;
+#else
+   *mcfg = NUMONYX_V_MCFG_165(512 << 20);
+   *ctrla = NUMONYX_V_ACTIMA_165;
+   *ctrlb = NUMONYX_V_ACTIMB_165;
+   *rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_165MHz;
+#endif
+}
+#endif
+
 /*
  * Routine: setup_net_chip
  * Description: Setting up the configuration GPMC registers specific to the
@@ -91,7 +123,7 @@ static void setup_net_chip(void)
 }
 #endif
 
-#ifdef CONFIG_GENERIC_MMC
+#if defined(CONFIG_GENERIC_MMC) && !defined(CONFIG_SPL_BUILD)
 int board_mmc_init(bd_t *bis)
 {
omap_mmc_init(0, 0, 0);
diff --git a/board/isee/igep0030/config.mk b/board/isee/igep0030/config.mk
deleted file mode 100644
index 059a878..000
--- a/board/isee/igep0030/config.mk
+++ /dev/null
@@ -1,33 +0,0 @@
-#
-# (C) Copyright 2009
-# ISEE 2007 SL, 
-#
-# IGEP0030 uses OMAP3 (ARM-CortexA8) cpu
-# see http://www.ti.com/ for more information on Texas Instruments
-#
-# 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
-#
-# Physical Address:
-# 8000' (bank0)
-# A000/ (bank1)
-# Linux-Kernel is expected to be at 8000'8000, entry 8000'8000
-# (mem base + reserved)
-
-# For use with external or internal boots.
-CONFIG_SYS_TEXT_BASE = 0x80008000
diff --git a/board/isee/igep0030/igep0030.c b/board/ise

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

[Thomas Chou]

On 04/24/2012 09:38 AM, thomas wrote:

The following changes since commit 61ddce07f8b96c5df7d00466b4da9edaecb0eff1:

   sandbox: Use the new run_command() (2012-04-23 22:53:54 +0200)

are available in the git repository at:
   git://git.denx.de/u-boot-nios.git master

Thomas Chou (1):
   nios2: move gd and bd into BSS

  arch/nios2/lib/board.c  |   12 +---
  include/configs/nios2-generic.h |   12 
  2 files changed, 9 insertions(+), 15 deletions(-)


Dear Wolfgang,

Please handle this pull request. It was missed. I have rebased it 
against rc1. Thanks.


Best regards,
Thomas


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

Re: [U-Boot] [PATCH] video: support exynos fimd driver for various exynos series

[Minkyu Kang]

Dear Donghwa,

On 2 July 2012 11:22, Donghwa Lee  wrote:
> This patch supports exynos fimd driver for various exynos series different 
> from
> existing it supports only exynos4 chip.
>
> Signed-off-by: Donghwa Lee 
> Signed-off-by: Kyungmin Park 
> ---
>  arch/arm/include/asm/arch-exynos/fb.h |   15 +-
>  drivers/video/exynos_fimd.c   |   85 
> -
>  2 files changed, 66 insertions(+), 34 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-exynos/fb.h 
> b/arch/arm/include/asm/arch-exynos/fb.h
> index b10b0da..b56ab55 100644
> --- a/arch/arm/include/asm/arch-exynos/fb.h
> +++ b/arch/arm/include/asm/arch-exynos/fb.h
> @@ -23,7 +23,7 @@
>  #define __ASM_ARM_ARCH_FB_H_
>
>  #ifndef __ASSEMBLY__
> -struct exynos4_fb {
> +struct exynos_fb {
> unsigned int vidcon0;
> unsigned int vidcon1;
> unsigned int vidcon2;
> @@ -154,6 +154,9 @@ struct exynos4_fb {
>  };
>  #endif
>
> +/* LCD IF register offset */
> +#define EXYNOS_LCD_IF_BASE_OFFSET  (0x2)

for exynos4? or exynos5?

> +
>  /*
>   *  Register offsets
>  */
> @@ -253,6 +256,10 @@ struct exynos4_fb {
>  /* VIDTCON2 */
>  #define EXYNOS_VIDTCON2_LINEVAL(x) (((x) & 0x7ff) << 11)
>  #define EXYNOS_VIDTCON2_HOZVAL(x)  (((x) & 0x7ff) << 0)
> +#define EXYNOS_VIDTCON2_LINEVAL_E(x)   x) & 0x800) \
> +   >> 11) << 23)
> +#define EXYNOS_VIDTCON2_HOZVAL_E(x)x) & 0x800) \
> +   >> 11) << 22)
>
>  /* Window 0~4 Control - WINCONx */
>  #define EXYNOS_WINCON_DATAPATH_DMA (0 << 22)
> @@ -330,6 +337,8 @@ struct exynos4_fb {
>  #define EXYNOS_VIDOSD_TOP_Y(x) (((x) & 0x7ff) << 0)
>  #define EXYNOS_VIDOSD_RIGHT_X(x)   (((x) & 0x7ff) << 11)
>  #define EXYNOS_VIDOSD_BOTTOM_Y(x)  (((x) & 0x7ff) << 0)
> +#define EXYNOS_VIDOSD_RIGHT_X_E(x) (((x) & 0x1) << 23)
> +#define EXYNOS_VIDOSD_BOTTOM_Y_E(x)(((x) & 0x1) << 22)
>
>  /* VIDOSD0C, VIDOSDxD */
>  #define EXYNOS_VIDOSD_SIZE(x)  (((x) & 0xff) << 
> 0)
> @@ -354,6 +363,10 @@ struct exynos4_fb {
>  /* Buffer Size */
>  #define EXYNOS_VIDADDR_OFFSIZE(x)  (((x) & 0x1fff) << 13)
>  #define EXYNOS_VIDADDR_PAGEWIDTH(x)(((x) & 0x1fff) << 0)
> +#define EXYNOS_VIDADDR_OFFSIZE_E(x)x) & 0x2000) \
> +   >> 13) << 27)
> +#define EXYNOS_VIDADDR_PAGEWIDTH_E(x)  x) & 0x2000) \
> +   >> 13) << 26)
>
>  /* WIN Color Map */
>  #define EXYNOS_WINMAP_COLOR(x) ((x) & 0xff)
> diff --git a/drivers/video/exynos_fimd.c b/drivers/video/exynos_fimd.c
> index f07568a..f8eac9d 100644
> --- a/drivers/video/exynos_fimd.c
> +++ b/drivers/video/exynos_fimd.c
> @@ -41,8 +41,8 @@ void exynos_fimd_lcd_init_mem(u_long screen_base, u_long 
> fb_size,
>
>  static void exynos_fimd_set_dualrgb(unsigned int enabled)
>  {
> -   struct exynos4_fb *fimd_ctrl =
> -   (struct exynos4_fb *)samsung_get_base_fimd();
> +   struct exynos_fb *fimd_ctrl =
> +   (struct exynos_fb *)samsung_get_base_fimd();
> unsigned int cfg = 0;
>
> if (enabled) {
> @@ -60,8 +60,8 @@ static void exynos_fimd_set_dualrgb(unsigned int enabled)
>  static void exynos_fimd_set_par(unsigned int win_id)
>  {
> unsigned int cfg = 0;
> -   struct exynos4_fb *fimd_ctrl =
> -   (struct exynos4_fb *)samsung_get_base_fimd();
> +   struct exynos_fb *fimd_ctrl =
> +   (struct exynos_fb *)samsung_get_base_fimd();
>
> /* set window control */
> cfg = readl((unsigned int)&fimd_ctrl->wincon0 +
> @@ -93,7 +93,10 @@ static void exynos_fimd_set_par(unsigned int win_id)
> EXYNOS_VIDOSD(win_id));
>
> cfg = EXYNOS_VIDOSD_RIGHT_X(pvid->vl_col - 1) |
> -   EXYNOS_VIDOSD_BOTTOM_Y(pvid->vl_row - 1);
> +   EXYNOS_VIDOSD_BOTTOM_Y(pvid->vl_row - 1) |
> +   EXYNOS_VIDOSD_RIGHT_X_E(1) |
> +   EXYNOS_VIDOSD_BOTTOM_Y_E(0);
> +
> writel(cfg, (unsigned int)&fimd_ctrl->vidosd0b +
> EXYNOS_VIDOSD(win_id));
>
> @@ -106,8 +109,8 @@ static void exynos_fimd_set_par(unsigned int win_id)
>  static void exynos_fimd_set_buffer_address(unsigned int win_id)
>  {
> unsigned long start_addr, end_addr;
> -   struct exynos4_fb *fimd_ctrl =
> -   (struct exynos4_fb *)samsung_get_base_fimd();
> +   struct exynos_fb *fimd_ctrl =
> +   (struct exynos_fb *)samsung_get_base_fimd();
>
> start_addr = (unsigned long)lcd_base_addr;
> end_addr = start_addr + ((pvid

[U-Boot] [PATCH v4 0/7] arm: rmobile: kzm9g: enable booting Linux kernel

[Tetsuyuki Kobayshi]

From: Tetsuyuki Kobayashi 

Hi, Iwamatsu-san

This is v4 patch set for kzm9g.
I modified bus controller setting for CS4. 
And enabled reset command.


Tetsuyuki Kobayashi (7):
  arm: rmobile: kzm9g: Modify sdram area
  arm: rmobile: kzm9g: Adjust low level hardware setting
  arm: rmobile: kzm9g: change prompt to board specific
  arm: rmobile: kzm9g: Add dummy member to struct sh73a0_rwdt
  MAINTAINERS: Add Tetsuyuki Kobayshi for kzm9g
  arm: rmobile: kzm9g: Modify bus controller setting for CS4
  arm: rmobile: kzm9g: enable reset command

 MAINTAINERS|1 +
 arch/arm/include/asm/arch-rmobile/sh73a0.h |   10 +-
 board/kmc/kzm9g/kzm9g.c|9 +++--
 include/configs/kzm9g.h|7 ---
 4 files changed, 21 insertions(+), 6 deletions(-)

-- 
1.7.9.5

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

[U-Boot] [PATCH v4 1/7] arm: rmobile: kzm9g: Modify sdram area

[Tetsuyuki Kobayshi]

From: Tetsuyuki Kobayashi 

Reserve first 16MB for RT-CPU (as same as kernel config).

Signed-off-by: Tetsuyuki Kobayashi 
Signed-off-by: Nobuhiro Iwamatsu 
---
Changes for v2:
 - No change. Just rebased.
Changes for v3:
 - No change.
Changes for v4:
 - No change.

 include/configs/kzm9g.h |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/configs/kzm9g.h b/include/configs/kzm9g.h
index 7567d46..bcf2cd8 100644
--- a/include/configs/kzm9g.h
+++ b/include/configs/kzm9g.h
@@ -97,8 +97,9 @@
 #define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_INIT_RAM_ADDR + \
 CONFIG_SYS_INIT_RAM_SIZE - \
 GENERATED_GBL_DATA_SIZE)
-#define CONFIG_SYS_SDRAM_BASE  KZM_SDRAM_BASE
-#define CONFIG_SYS_SDRAM_SIZE  PHYS_SDRAM_SIZE
+#define CONFIG_SDRAM_OFFSET_FOR_RT (16 * 1024 * 1024)
+#define CONFIG_SYS_SDRAM_BASE  (KZM_SDRAM_BASE + CONFIG_SDRAM_OFFSET_FOR_RT)
+#define CONFIG_SYS_SDRAM_SIZE  (PHYS_SDRAM_SIZE - CONFIG_SDRAM_OFFSET_FOR_RT)
 #define CONFIG_SYS_LOAD_ADDR   (CONFIG_SYS_SDRAM_BASE + 32 * 1024 * 1024)
 
 #define CONFIG_SYS_MONITOR_BASE(KZM_FLASH_BASE)
-- 
1.7.9.5

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

[U-Boot] [PATCH v4 2/7] arm: rmobile: kzm9g: Adjust low level hardware setting

[Tetsuyuki Kobayshi]

From: Tetsuyuki Kobayashi 

Adjust low level hardware setting in s_init.

Signed-off-by: Tetsuyuki Kobayashi 
Signed-off-by: Nobuhiro Iwamatsu 
---
Changes for v2:
 - No change. Just rebased.
Changes for v3:
 - No change.
Changes for v4:
 - No change.

 arch/arm/include/asm/arch-rmobile/sh73a0.h |4 +++-
 board/kmc/kzm9g/kzm9g.c|2 ++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch-rmobile/sh73a0.h 
b/arch/arm/include/asm/arch-rmobile/sh73a0.h
index 605dd44..ad59be7 100644
--- a/arch/arm/include/asm/arch-rmobile/sh73a0.h
+++ b/arch/arm/include/asm/arch-rmobile/sh73a0.h
@@ -229,7 +229,9 @@ struct sh73a0_sbsc_cpg {
volatile u32 smstpcr3;
volatile u32 smstpcr4;
volatile u32 smstpcr5;
-   volatile u32 dummy11[10]; /* 0x148 .. 0x16c */
+   volatile u32 dummy11[2]; /* 0x148 .. 0x14c */
+   volatile u32 cpgxxcs4;
+   volatile u32 dummy12[7]; /* 0x154 .. 0x16c */
volatile u32 dvfscr2;
volatile u32 dvfscr3;
volatile u32 dvfscr4;
diff --git a/board/kmc/kzm9g/kzm9g.c b/board/kmc/kzm9g/kzm9g.c
index 8d7c61a..3716483 100644
--- a/board/kmc/kzm9g/kzm9g.c
+++ b/board/kmc/kzm9g/kzm9g.c
@@ -163,6 +163,7 @@ void s_init(void)
#define LIFEC_SEC_SRC_BIT   (1 << 15)
writel(readl(LIFEC_SEC_SRC) & ~LIFEC_SEC_SRC_BIT, LIFEC_SEC_SRC);
 
+   clrbits_le32(&cpg->smstpcr3, (1 << 15));
clrbits_le32(&cpg_srcr->srcr3, (1 << 15));
clrbits_le32(&cpg->smstpcr2, (1 << 18));
clrbits_le32(&cpg_srcr->srcr2, (1 << 18));
@@ -266,6 +267,7 @@ void s_init(void)
 
writel(0x0b0b, &cpg->frqcrd);
cmp_loop(&cpg->frqcrd, 0x8000, 0x0);
+   writel(0xfffc, &cpg->cpgxxcs4);
 }
 
 int board_early_init_f(void)
-- 
1.7.9.5

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

[U-Boot] [PATCH v4 4/7] arm: rmobile: kzm9g: Add dummy member to struct sh73a0_rwdt

[Tetsuyuki Kobayshi]

From: Tetsuyuki Kobayashi 

Add dummy member to struct sh73a0_rwdt in sh73a0.h.
Without this, initializing watch dog timer goes wrong.

Signed-off-by: Tetsuyuki Kobayashi 
---
Changes for v2:
 - New
Changes for v3:
 - No change
Changes for v4:
 - No change

 arch/arm/include/asm/arch-rmobile/sh73a0.h |2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/include/asm/arch-rmobile/sh73a0.h 
b/arch/arm/include/asm/arch-rmobile/sh73a0.h
index ad59be7..74d1c48 100644
--- a/arch/arm/include/asm/arch-rmobile/sh73a0.h
+++ b/arch/arm/include/asm/arch-rmobile/sh73a0.h
@@ -60,7 +60,9 @@
 /* RWDT */
 struct sh73a0_rwdt {
volatile u16 rwtcnt0;   /* 0x00 */
+   volatile u16 dummy0;/* 0x02 */
volatile u16 rwtcsra0;  /* 0x04 */
+   volatile u16 dummy1;/* 0x06 */
volatile u16 rwtcsrb0;  /* 0x08 */
 };
 
-- 
1.7.9.5

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

[U-Boot] [PATCH v4 3/7] arm: rmobile: kzm9g: change prompt to board specific

[Tetsuyuki Kobayshi]

From: Tetsuyuki Kobayashi 

Change U-Boot prompt to board specific one.

Signed-off-by: Tetsuyuki Kobayashi 
Signed-off-by: Nobuhiro Iwamatsu 
---
Changes for v2:
 - No change. Just rebased.
Changes for v3:
 - No change.
Changes for v4:
 - No change.

 include/configs/kzm9g.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/kzm9g.h b/include/configs/kzm9g.h
index bcf2cd8..bd157d9 100644
--- a/include/configs/kzm9g.h
+++ b/include/configs/kzm9g.h
@@ -70,7 +70,7 @@
 
 /* prompt */
 #define CONFIG_SYS_LONGHELP
-#define CONFIG_SYS_PROMPT  "> "
+#define CONFIG_SYS_PROMPT  "KZM-A9-GT# "
 #define CONFIG_SYS_CBSIZE  256
 #define CONFIG_SYS_PBSIZE  256
 #define CONFIG_SYS_MAXARGS 16
-- 
1.7.9.5

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

[U-Boot] [PATCH v4 6/7] arm: rmobile: kzm9g: Modify bus controller setting for CS4

[Tetsuyuki Kobayshi]

From: Tetsuyuki Kobayashi 

Problem:
Linux kernel hangs up when it write a file to NFS mounted directory.
Solution:
Modify bus controller setting for CS4, which connected smsc9221 ethernet
controller.

Detail:
Modify CS4BCR bit[29:28] (IWW[1:0]) from 00 to 01.
Modify CS4BCR bit[20:19] (IWRRD[1:0]) from 00 to 01.
Modify CS4BCR bit[17:16] (IWRRS[1:0]) from 00 to 01.
Modify CS4WCR bit[27:26] (WSW[1:0]) from 10 to 11
Modify CS4WCR bit[25:24] (WHW[1:0]) from 01 to 10
Modify CS4WCR bit[18:16] (WW[2:0]) from 101 to 111
Modify CS4WCR bit[13:11] (SW[2:0]) from 010 to 011
Modify CS4WCR bit[10:7] (WR[3:0]) from 1000 to 1011

Signed-off-by: Tetsuyuki Kobayashi 
---
Changes for v3:
 - New
Changes for v4:
 - Modify values for CS4BCR and CS4WCR.

 board/kmc/kzm9g/kzm9g.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/board/kmc/kzm9g/kzm9g.c b/board/kmc/kzm9g/kzm9g.c
index 3716483..ed530fd 100644
--- a/board/kmc/kzm9g/kzm9g.c
+++ b/board/kmc/kzm9g/kzm9g.c
@@ -31,9 +31,10 @@
 DECLARE_GLOBAL_DATA_PTR;
 
 #define CS0BCR_D (0x06C00400)
-#define CS4BCR_D (0x06C00400)
+#define CS4BCR_D (0x16c90400)
 #define CS0WCR_D (0x55062C42)
-#define CS4WCR_D (0x19051443)
+#define CS4WCR_D (0x1e071dc3)
+
 #define CMNCR_BROMMD0   (1 << 21)
 #define CMNCR_BROMMD1   (1 << 22)
 #define CMNCR_BROMMD   (CMNCR_BROMMD0|CMNCR_BROMMD1)
-- 
1.7.9.5

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

[U-Boot] [PATCH v4 7/7] arm: rmobile: kzm9g: enable reset command

[Tetsuyuki Kobayshi]

From: Tetsuyuki Kobayashi 

Do soft power on reset in U-Boot reset command.

Signed-off-by: Tetsuyuki Kobayashi 
---
Changes for v4:
 - New

 arch/arm/include/asm/arch-rmobile/sh73a0.h |4 
 board/kmc/kzm9g/kzm9g.c|2 ++
 2 files changed, 6 insertions(+)

diff --git a/arch/arm/include/asm/arch-rmobile/sh73a0.h 
b/arch/arm/include/asm/arch-rmobile/sh73a0.h
index 74d1c48..6a6c237 100644
--- a/arch/arm/include/asm/arch-rmobile/sh73a0.h
+++ b/arch/arm/include/asm/arch-rmobile/sh73a0.h
@@ -41,6 +41,10 @@
 #define SRESCR (CPG_BASE + 0x1018)
 #define PCLKCR (CPG_BASE + 0x1020)
 
+/* SYSC */
+#define SYSC_BASE   (0xE618)
+#define RESCNT2(SYSC_BASE + 0x8020)
+
 /* BSC */
 #define BSC_BASE (0xFEC1)
 
diff --git a/board/kmc/kzm9g/kzm9g.c b/board/kmc/kzm9g/kzm9g.c
index ed530fd..66bac69 100644
--- a/board/kmc/kzm9g/kzm9g.c
+++ b/board/kmc/kzm9g/kzm9g.c
@@ -372,4 +372,6 @@ int board_eth_init(bd_t *bis)
 
 void reset_cpu(ulong addr)
 {
+   /* Soft Power On Reset */
+   writel((1 << 31), RESCNT2);
 }
-- 
1.7.9.5

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

[U-Boot] [PATCH v4 5/7] MAINTAINERS: Add Tetsuyuki Kobayshi for kzm9g

[Tetsuyuki Kobayshi]

From: Tetsuyuki Kobayashi 


Signed-off-by: Tetsuyuki Kobayashi 
---
Changes for v2:
 - New
Changes for v3:
 - No change
Changes for v4:
 - No change

 MAINTAINERS |1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 45446f4..55a6c1b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -947,6 +947,7 @@ Vladimir Zapolskiy 
devkit3250  lpc32xx
 
 Nobuhiro Iwamatsu 
+Tetsuyuki Kobayashi 
 
kzm9g   SH73A0 (RMOBILE SoC)
 
-- 
1.7.9.5

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