Re: [U-Boot] U-Boot software debug tools ?
Dear =?big5?B?QmlsbCBDaGFuKLjir3G6+l9BU1Ip?=, In message <6f31f8706a8b0e4e96cb192603902509688...@ar-ex-03.pega.corp.PEGATRON> you wrote: > > As we are moving into source codes and start reading start.S, we > eagerly want to know what software tools do you use in implementing and > debugging Stage1 assembly codes? The standard debug tool here is the Abatron BDI3000 in combination with GDB (eventually combined with the GUI of your choice). 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 COBOL is for morons. -- E.W. Dijkstra ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] net/eth.c: make eth_get_dev_by_name(NULL) safe
On 07/06/2011 09:38 PM, Mike Frysinger wrote: > On Wednesday, July 06, 2011 03:15:08 Helmut Raiger wrote: >> On 07/05/2011 05:44 AM, Mike Frysinger wrote: >>> On Monday, July 04, 2011 06:29:51 helmut.rai...@hale.at wrote: eth_get_dev_by_name() is not safe to use for devname being NULL as it uses strcmp. This patch makes it return NULL if devname NULL is passed. >>> i'm not sure about this. passing NULL is wrong, and the caller should >>> catch that shouldnt it ? >> So what is your suggestion how to deal with it? > in what situation is eth_get_dev_by_name(NULL) being called ? my suggestion > would be to fix that call point since it's doing something wrong. > -mike I couldn't find a situation where this might be the case. But as Luca Ceresoli pointed out in his e-mail, somewhere up the thread, that he tested for devname being NULL in his miiphy_read and write routines, I checked eth_get_dev_by_name() and found that it is vulnerable to passing a NULL pointer, hence the fix. Is there something missing for the patch to be acknowledged? It's hanging there quite a while now? Helmut -- Scanned by MailScanner. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot software debug tools ?
BDI JTAG -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Bill Chan(袪益綸_ASR) Sent: 2011年7月7日 12:28 To: u-boot@lists.denx.de Subject: [U-Boot] U-Boot software debug tools ? Dear Sir from U-Boot, This is Bill from Taiwan, we are currently working on a board that runs Freescale iMX53 CPU and using U-Boot as our bootloader. As we are moving into source codes and start reading start.S, we eagerly want to know what software tools do you use in implementing and debugging Stage1 assembly codes? Far as our experiences, we used to go with ADS1.2 to check r0~r15 status line by line; May you kindly let us know if there is a recommend to do so in Linux or Windows, thank you very much! Regards Bill Chan ASRock Inc. Tel: +886-2-2896-5588 ext.11737 Email: bill_c...@asroack.com.tw ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] powerpc/p2040rdb: Add p2040rdb board support
P2040RDB Specification: --- Memory subsystem: * 4Gbyte unbuffered DDR3 SDRAM SO-DIMM(64bit bus) * 128 Mbyte NOR flash single-chip memory * 256 Kbit M24256 I2C EEPROM * 16 Mbyte SPI memory * SD connector to interface with the SD memory card Ethernet: * dTSEC1: connected to the Vitesse SGMII PHY (VSC8221) * dTSEC2: connected to the Vitesse SGMII PHY (VSC8221) * dTSEC3: connected to the Vitesse SGMII PHY (VSC8221) * dTSEC4: connected to the Vitesse RGMII PHY (VSC8641) * dTSEC5: connected to the Vitesse RGMII PHY (VSC8641) PCIe: * Lanes E, F, G and H of Bank1 are connected to one x4 PCIe SLOT1 * Lanes C and Land D of Bank2 are connected to one x4 PCIe SLOT2 SATA: Lanes C and Land D of Bank2 are connected to two SATA connectors USB 2.0: connected via a internal UTMI PHY to two TYPE-A interfaces I2C: * I2C1: Real time clock, Temperature sensor, Memory module * I2C2: Vcore Regulator, 256Kbit I2C Bus EEPROM, PCIe slot1/2 UART: supports two UARTs up to 115200 bps for console Signed-off-by: Mingkai Hu --- v2: - Fix some warning of checkpatch.pl, such as "line over 80 characters". board/freescale/p2040rdb/Makefile | 56 board/freescale/p2040rdb/cpld.c | 171 ++ board/freescale/p2040rdb/cpld.h | 53 +++ board/freescale/p2040rdb/ddr.c | 115 +++ board/freescale/p2040rdb/law.c | 37 ++ board/freescale/p2040rdb/p2040rdb.c | 205 board/freescale/p2040rdb/pci.c | 39 +++ board/freescale/p2040rdb/tlb.c | 119 +++ boards.cfg |3 + doc/README.p2040rdb | 123 +++ include/configs/P2040RDB.h | 624 +++ 11 files changed, 1545 insertions(+), 0 deletions(-) create mode 100644 board/freescale/p2040rdb/Makefile create mode 100644 board/freescale/p2040rdb/cpld.c create mode 100644 board/freescale/p2040rdb/cpld.h create mode 100644 board/freescale/p2040rdb/ddr.c create mode 100644 board/freescale/p2040rdb/law.c create mode 100644 board/freescale/p2040rdb/p2040rdb.c create mode 100644 board/freescale/p2040rdb/pci.c create mode 100644 board/freescale/p2040rdb/tlb.c create mode 100644 doc/README.p2040rdb create mode 100644 include/configs/P2040RDB.h diff --git a/board/freescale/p2040rdb/Makefile b/board/freescale/p2040rdb/Makefile new file mode 100644 index 000..65f348f --- /dev/null +++ b/board/freescale/p2040rdb/Makefile @@ -0,0 +1,56 @@ +# +# Copyright 2011 Freescale Semiconductor, Inc. +# (C) Copyright 2001-2006 +# 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$(BOARD).o + +COBJS-y+= $(BOARD).o +COBJS-y += cpld.o +COBJS-y+= ddr.o +COBJS-y+= law.o +COBJS-y+= tlb.o +COBJS-$(CONFIG_PCI) += pci.o + +SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS-y)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(call cmd_link_o_target, $(OBJS)) + +clean: + rm -f $(OBJS) $(SOBJS) + +distclean: clean + rm -f $(LIB) core *.bak .depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/freescale/p2040rdb/cpld.c b/board/freescale/p2040rdb/cpld.c new file mode 100644 index 000..8e1f46e --- /dev/null +++ b/board/freescale/p2040rdb/cpld.c @@ -0,0 +1,171 @@ +/** + * Copyright 2011 Freescale Semiconductor + * Author: Mingkai Hu + * + * 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 file provides support for the board-specific CPLD used on some Freescale + * reference boards. + * + * The following macros need to be defined: + * + * CPLD_BASE - The virtual address of the base of the CPLD register map + * + */ + +#include +#include +#include
[U-Boot] N/A
You have $85,000USD in cash credit by the International Monetary Funds(IMF) via western union. Details required: Full Name,Address,Tel,Occupation ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-Boot software debug tools ?
Dear Sir from U-Boot, This is Bill from Taiwan, we are currently working on a board that runs Freescale iMX53 CPU and using U-Boot as our bootloader. As we are moving into source codes and start reading start.S, we eagerly want to know what software tools do you use in implementing and debugging Stage1 assembly codes? Far as our experiences, we used to go with ADS1.2 to check r0~r15 status line by line; May you kindly let us know if there is a recommend to do so in Linux or Windows, thank you very much! Regards Bill Chan ASRock Inc. Tel: +886-2-2896-5588 ext.11737 Email: bill_c...@asroack.com.tw ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/6] Add Highbank platform
Wolfgang, On 07/04/2011 05:28 AM, Wolfgang Denk wrote: > Dear Rob Herring, > > In message <1309275583-11763-1-git-send-email-robherri...@gmail.com> you > wrote: >> From: Rob Herring >> >> This series enables non-PCI AHCI controllers and adds support for Calxeda >> Highbank platform which uses the AHCI changes. >> >> Changes from v3: >> - Added Highbank to MAINTAINERS >> - Added back patch to fix CONFIG_SKIP_LOWLEVEL_INIT (mistakenly dropped >> from v2) >> >> Wolfgang, Albert, >> >> Can you apply these to your trees for v2011.09? All review comments have been >> addressed. > > I have to admit that I dislike the way you are working. > > If I'm not wrong, there have been several versions of your patches > around, but you repost again and again without any indication that > these are reposts, nor what exactly has been changed between versions. > For example, I see three different posts here: > > 06/11 Rob Herring[U-Boot] [PATCH 8/8] ARM: Add Calxeda Highbank > platform > http://article.gmane.org/gmane.comp.boot-loaders.u-boot/101435 > 06/21 Rob Herring[U-Boot] [PATCH 1/5] ARM: Add Calxeda Highbank > platform > http://article.gmane.org/gmane.comp.boot-loaders.u-boot/101867 > 06/28 Rob Herring[U-Boot] [PATCH 2/6] ARM: Add Calxeda Highbank > platform > http://article.gmane.org/gmane.comp.boot-loaders.u-boot/102124 > > None of these adheres to the requirements as documented here: > http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions > > Please be aware that NOT documentaing what you changed means that all > (potential) reviewers of your code have to spend additional time > figuring out what you might have changed, and checking back in the > history if you really implemented all earlier review comments. > Speaking for me, I must state that being notoriously short of time I > am not willing to waste additional time on such postings, so I tend > to ignore them. > > In short: please stick to the rules if you want your patches to go > into mainline. > Sorry about this. I will follow this more closely going forward. Much of the significant change was to the series itself and less so the content itself. I added Highbank support based on you wanting to see a platform use the AHCI changes. Then I dropped the SDHCI changes as another "common" implementation appeared on the list and it will take some time to sort out. The history for "ARM: Add Calxeda Highbank platform" is: v2: - Move SATA and MMC board init to separate patches - Fix DRAM size setup v3: - Add maintainer I can repost it if you like with the history, but I'd like to get any review comments from you first. Up until my last post, the following patches have had no comments and no changes. They were only reposted as part of the whole series: ARM: add missing CONFIG_SKIP_LOWLEVEL_INIT for armv7 arm: add __ilog2 function scsi/ahci: ata id little endian fix I have posted v2 of "arm: add __ilog2 function" and v3 of "scsi/ahci: add support for non-PCI controllers" as a replies to the prior versions. http://article.gmane.org/gmane.comp.boot-loaders.u-boot/102679 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/102775 Regards, Rob ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] scsi/ahci: add support for non-PCI controllers
From: Rob Herring
Add support for AHCI controllers that are not PCI based.
Signed-off-by: Rob Herring
Cc: Wolfgang Denk
---
changes in v2:
- fix checkpatch.pl warnings/errors
- fix label indentation
- simplify "sizeof(hd_driveid_t *) * AHCI_MAX_PORTS" to "sizeof(ataid)"
- Add function prototypes for ahci_init and scsi_scan
changes in v3:
- Introduce CONFIG_SCSI_AHCI_PLAT and replace CONFIG_PCI with it in
ahci.c
- Make no SCSI_DEV_ID and SCSI_VEND_ID only okay if CONFIG_SCSI_AHCI_PLAT
is defined.
- fix checkpatch.pl warnings/errors (again...)
common/cmd_scsi.c|5 ++-
drivers/block/ahci.c | 70 -
include/ahci.h |4 +++
include/scsi.h |1 +
4 files changed, 70 insertions(+), 10 deletions(-)
diff --git a/common/cmd_scsi.c b/common/cmd_scsi.c
index be4fe74..352781b 100644
--- a/common/cmd_scsi.c
+++ b/common/cmd_scsi.c
@@ -46,7 +46,7 @@
#define SCSI_VEND_ID 0x10b9
#define SCSI_DEV_ID 0x5288
-#else
+#elif !defined(CONFIG_SCSI_AHCI_PLAT)
#error no scsi device defined
#endif
@@ -174,7 +174,7 @@ removable:
scsi_curr_dev = -1;
}
-
+#ifdef CONFIG_PCI
void scsi_init(void)
{
int busdevfunc;
@@ -192,6 +192,7 @@ void scsi_init(void)
scsi_low_level_init(busdevfunc);
scsi_scan(1);
}
+#endif
block_dev_desc_t * scsi_get_dev(int dev)
{
diff --git a/drivers/block/ahci.c b/drivers/block/ahci.c
index d431c5a..64f52bb 100644
--- a/drivers/block/ahci.c
+++ b/drivers/block/ahci.c
@@ -78,13 +78,15 @@ static int waiting_for_cmd_completed(volatile u8 *offset,
static int ahci_host_init(struct ahci_probe_ent *probe_ent)
{
+#ifndef CONFIG_SCSI_AHCI_PLAT
pci_dev_t pdev = probe_ent->dev;
+ u16 tmp16;
+ unsigned short vendor;
+#endif
volatile u8 *mmio = (volatile u8 *)probe_ent->mmio_base;
u32 tmp, cap_save;
- u16 tmp16;
int i, j;
volatile u8 *port_mmio;
- unsigned short vendor;
cap_save = readl(mmio + HOST_CAP);
cap_save &= ((1 << 28) | (1 << 17));
@@ -110,6 +112,7 @@ static int ahci_host_init(struct ahci_probe_ent *probe_ent)
writel(cap_save, mmio + HOST_CAP);
writel_with_flush(0xf, mmio + HOST_PORTS_IMPL);
+#ifndef CONFIG_SCSI_AHCI_PLAT
pci_read_config_word(pdev, PCI_VENDOR_ID, &vendor);
if (vendor == PCI_VENDOR_ID_INTEL) {
@@ -118,7 +121,7 @@ static int ahci_host_init(struct ahci_probe_ent *probe_ent)
tmp16 |= 0xf;
pci_write_config_word(pdev, 0x92, tmp16);
}
-
+#endif
probe_ent->cap = readl(mmio + HOST_CAP);
probe_ent->port_map = readl(mmio + HOST_PORTS_IMPL);
probe_ent->n_ports = (probe_ent->cap & 0x1f) + 1;
@@ -183,22 +186,24 @@ static int ahci_host_init(struct ahci_probe_ent
*probe_ent)
writel(tmp | HOST_IRQ_EN, mmio + HOST_CTL);
tmp = readl(mmio + HOST_CTL);
debug("HOST_CTL 0x%x\n", tmp);
-
+#ifndef CONFIG_SCSI_AHCI_PLAT
pci_read_config_word(pdev, PCI_COMMAND, &tmp16);
tmp |= PCI_COMMAND_MASTER;
pci_write_config_word(pdev, PCI_COMMAND, tmp16);
-
+#endif
return 0;
}
static void ahci_print_info(struct ahci_probe_ent *probe_ent)
{
+#ifndef CONFIG_SCSI_AHCI_PLAT
pci_dev_t pdev = probe_ent->dev;
+ u16 cc;
+#endif
volatile u8 *mmio = (volatile u8 *)probe_ent->mmio_base;
u32 vers, cap, impl, speed;
const char *speed_s;
- u16 cc;
const char *scc_s;
vers = readl(mmio + HOST_VERSION);
@@ -213,6 +218,9 @@ static void ahci_print_info(struct ahci_probe_ent
*probe_ent)
else
speed_s = "?";
+#ifdef CONFIG_SCSI_AHCI_PLAT
+ scc_s = "SATA";
+#else
pci_read_config_word(pdev, 0x0a, &cc);
if (cc == 0x0101)
scc_s = "IDE";
@@ -222,7 +230,7 @@ static void ahci_print_info(struct ahci_probe_ent
*probe_ent)
scc_s = "RAID";
else
scc_s = "unknown";
-
+#endif
printf("AHCI %02x%02x.%02x%02x "
"%u slots %u ports %s Gbps 0x%x impl %s mode\n",
(vers >> 24) & 0xff,
@@ -249,6 +257,7 @@ static void ahci_print_info(struct ahci_probe_ent
*probe_ent)
cap & (1 << 13) ? "part " : "");
}
+#ifndef CONFIG_SCSI_AHCI_PLAT
static int ahci_init_one(pci_dev_t pdev)
{
u16 vendor;
@@ -291,7 +300,7 @@ static int ahci_init_one(pci_dev_t pdev)
err_out:
return rc;
}
-
+#endif
#define MAX_DATA_BYTE_COUNT (4*1024*1024)
@@ -667,7 +676,9 @@ void scsi_low_level_init(int busdevfunc)
int i;
u32 linkmap;
+#ifndef CONFIG_SCSI_AHCI_PLAT
ahci_init_one(busdevfunc);
+#endif
linkmap = probe_ent->link_port_map;
@@ -682,6 +693,49 @@ void scsi_low_level_init(int busdevfunc)
}
}
+#ifdef CONFIG_SCSI_AHCI_PLAT
+int ahci_init(u32 base)
+{
+ int i, rc = 0;
+ u32 linkmap;
+
+ memset(ataid, 0, sizeof(
[U-Boot] [PATCH] powerpc: Fix device tree padding associated with ramdisk
When booting with a ramdisk we bump the amount of memory reserved for
the device tree by FDT_RAMDISK_OVERHEAD. However we did not increase
the actual size in the device tree blob to match.
Its possible on boundary cases that we dont have enough memory according
to the device tree blob and get errors like:
WARNING: could not set linux,initrd-end FDT_ERR_NOSPACE
We can easily fix this by setting the device tree size at the same time
we bump the amount of memory reserved for the device tree.
Signed-off-by: Kumar Gala
---
arch/powerpc/lib/bootm.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/lib/bootm.c b/arch/powerpc/lib/bootm.c
index e01787d..4e0cb8f 100644
--- a/arch/powerpc/lib/bootm.c
+++ b/arch/powerpc/lib/bootm.c
@@ -288,8 +288,10 @@ static int boot_body_linux(bootm_headers_t *images)
return ret;
of_size = ret;
- if (*initrd_start && *initrd_end)
+ if (*initrd_start && *initrd_end) {
of_size += FDT_RAMDISK_OVERHEAD;
+ fdt_set_totalsize(*of_flat_tree, of_size);
+ }
/* Create a new LMB reservation */
lmb_reserve(lmb, (ulong)*of_flat_tree, of_size);
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch] MPC83XX: Fix PCI express clock setup
On Wed, 25 May 2011 15:51:07 -0400 Bill Cook wrote: > On a 8308 based board it was found that the PEX_GLK_RATIO register > (programmed in arch/powerpc/cpu/mpc83xx/pcie.c) was getting set to 0, This > was tracked to the fact that the pci express clock frequency was not being > assigned to the pciexp1_clk entry in the global data structure in file > arch/powerpc/cpu/mpc83xx/speed.c. Fix this and a similiar issue in > 'do_clocks' command. > > Signed-off-by: Bill Cook > --- applied to u-boot-mpc83xx. Thanks, Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] MPC83xx: Add MergerBox support.
On Thu, 14 Apr 2011 15:11:43 +0200 Andre Schwarz wrote: > This patch adds support for Matrix Vision MergerBox. > It is a Freescale MPC8377 based 3D image preocessing > platform utilizing Altera Cyclone IV FPGA and Silicon > Motion SM107 embedded graphics connected via PCI. > See doc/README.mergerbox for details. > > MAKEALL -c mpc83xx shows no errors/warnings introduced by this patchset. > > Files have been checked using checkpatch. > > Andre Schwarz (4): > MergerBox: Add board config file. > MergerBox: add documentation. > MergerBox: add maintainer and boards.cfg entries. > MergerBox: add board specific files in vendor dir. 4 out of 4 patches squashed, and applied to u-boot-mpc83xx. Thanks, Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MPC83xx: add config options for memory setup.
On Mon, 18 Apr 2011 08:10:12 +0800 York Sun wrote: > On Thu, 2011-04-14 at 14:54 +0200, Andre Schwarz wrote: > > CPO value and driver strength settings are board specifc. > > Also allow SPD data fetch from any accessible I2C EEPROM. > > > > Signed-off-by: Andre Schwarz > > --- > Looks good to me. > > Acked-by: York Sun applied to u-boot-mpc83xx. Thanks, Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MPC83xx: add define for global half-strength enable (HSE)
On Thu, 14 Apr 2011 14:53:37 +0200 Andre Schwarz wrote: > > Signed-off-by: Andre Schwarz > --- applied to u-boot-mpc83xx. Thanks, Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] MPC837x: set i2c1_clk
On Thu, 14 Apr 2011 14:57:40 +0200 Andre Schwarz wrote: > Running on mpc837x without CONFIG_FSL_ESDHC leads to > i2c1_clk not being set at all. It is bound to clock > of encryption module. fix this. > > > Signed-off-by: Andre Schwarz > --- applied to u-boot-mpc83xx. Thanks, Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fsl_dma: fix support for 83xx DMA engine
On Wed, 15 Jun 2011 14:08:29 -0700 "Ira W. Snyder" wrote: > On Tue, Mar 01, 2011 at 02:40:55PM -0800, Ira W. Snyder wrote: > > Commit 359ec4931944adb885882deb9b781e4095eabc94 broke support for the > > Freescale DMA engine on the 83xx parts. This is due to using registers > > which do not exist on 83xx. Remove the attribute register accesses from > > the 83xx build. > > > > Hi everyone, > > This never made it into mainline. I think it is a pretty obvious build > error on 83xx platforms. Can someone pick it up? applied to u-boot-mpc83xx. Thanks, Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [GIT PULL] mpc83xx: new MergerBox board + minor fixes
Wolfgang Denk, Please pull new MergerBox board + minor fixes for 83xx for u-boot v2011.09: The following changes since commit 79642098a8345e2506ab0ff02e8c7ac4da405d0c: Add support for Network Space v2 and parents (2011-07-04 10:55:28 +0200) are available in the git repository at: git://git.denx.de/u-boot-mpc83xx.git master Andre Schwarz (4): MPC837x: set i2c1_clk MPC83xx: add define for global half-strength enable (HSE) MPC83xx: add config options for memory setup. mpc83xx: Add support for MergerBox board Bill Cook (1): MPC83XX: Fix PCI express clock setup Ira W. Snyder (1): fsl_dma: fix support for 83xx DMA engine Timur Tabi (1): powerpc/83xx: remove empty board_early_init_f() MAINTAINERS |1 + arch/powerpc/cpu/mpc83xx/spd_sdram.c | 19 +- arch/powerpc/cpu/mpc83xx/speed.c |8 +- board/freescale/mpc8323erdb/mpc8323erdb.c |5 - board/freescale/mpc8360erdk/mpc8360erdk.c |5 - board/matrix_vision/mergerbox/Makefile| 51 +++ board/matrix_vision/mergerbox/fpga.c | 175 board/matrix_vision/mergerbox/fpga.h | 30 ++ board/matrix_vision/mergerbox/mergerbox.c | 241 +++ board/matrix_vision/mergerbox/mergerbox.h | 67 +++ board/matrix_vision/mergerbox/pci.c | 134 +++ board/matrix_vision/mergerbox/sm107.c | 126 ++ boards.cfg|1 + doc/README.mergerbox | 59 +++ drivers/dma/fsl_dma.c |2 + include/configs/MERGERBOX.h | 619 + include/configs/MPC8323ERDB.h |2 - include/configs/MPC8360ERDK.h |1 - include/mpc83xx.h |1 + 19 files changed, 1531 insertions(+), 16 deletions(-) create mode 100644 board/matrix_vision/mergerbox/Makefile create mode 100644 board/matrix_vision/mergerbox/fpga.c create mode 100644 board/matrix_vision/mergerbox/fpga.h create mode 100644 board/matrix_vision/mergerbox/mergerbox.c create mode 100644 board/matrix_vision/mergerbox/mergerbox.h create mode 100644 board/matrix_vision/mergerbox/pci.c create mode 100644 board/matrix_vision/mergerbox/sm107.c create mode 100644 doc/README.mergerbox create mode 100644 include/configs/MERGERBOX.h Thanks, Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] powerpc/83xx: remove empty board_early_init_f()
On Thu, 28 Apr 2011 15:01:29 -0500 Timur Tabi wrote: > Remove an empty board_early_init_f() from the MPC8323ERD and MPC360ERDK > boards. > > Signed-off-by: Timur Tabi > --- applied to u-boot-mpc83xx. Thanks, Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] (no subject)
Hi there We're pleased to inform that your organisation has been invited to participate in the exclusive monthly Art of England Magazine September 2011 edition, and beyond. Now seven years old, the Art of England Magazine offers you an excellent monthly targeted distribution throughout the UK and abroad, providing a highly successful reach to the art and luxury market sectors (full distribution details available at link below). Participants range from art galleries, dealers, auctioneers and associated professions, through to those who wish to contact this financially capable demographic for their products and services, reaping the appropriate business development from this high net worth audience. The editorial content too, as you might imagine, is 'top drawer' and commensurate with the subject matter (example edition available via link below). Regarding your potential participation, we're pleased to tell you that the Special Introductory Rate for booking for the coming September 2011 Edition is now open and we would like to offer you the extended reduced 'welcome' rate of just £950.00 total for a full A4 page advertisement (usual premium position list price £1350.00), a double page spread at £1650.00, or a half page at £500.00. This will enable you to try out the response from this financially capable fine art audience at limited risk to yourselves (usual rate card and media kit links also below). We look forward to hearing your thoughts when you have a moment! Kind regards Deni Parkes for ART OF ENGLAND MAGAZINE T: +44 (0)203 286 8737 ddi F: +44 (0)207 183 4752 or via accounts team +44 (0) 207 607 0717 W: www.artofengland.uk.com Downloads: Rate Card - http://sksassociates.co.uk/AofE/ART_OF_ENGLAND_MAGAZINE_RateCard.pdf Media Kit - http://sksassociates.co.uk/AofE/ART_OF_ENGLAND_MAGAZINE_MediaPack.pdf Distribution - http://artofengland.uk.com/advertise Example edition - http://www.pmbmedia.co.uk/ezine/aoedec10/fullpage.html Contracted exclusively by: SKS/Enhanced Media & Communications Ltd 1 Farnham Road, Guildford, Surrey GU2 4RG UK "Bringing the top drawer to you!" ** You were subscribed to this offer list through one of our extensive, but discerning luxury partner networks. ** If you feel you have received this email in error, simply REPLY and SEND with the subject line intact. Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch 1/1] Spi Flash: Allow auto-booting of images from spi flash load
On Wednesday, July 06, 2011 17:51:58 Andre Renaud wrote: > This allows intelligent booting of FIT (& the legacy style) images from > SPI flash. Basically it means that you don't have to guess at the image > length, so data reads are more optimal (& hopefully faster). this looks like largely a copy & paste job from one of the many existing boot funcs. considering the only unique thing here is the spi flash read, seems like it'd make sense to add a new func to common/cmd_bootm.c like bootm_load_image(). it'd take a read callback as well as a pointer to data. as it stands, this patch breaks configs that enable the spi flash command but disable the bootm command. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [Patch 1/1] Spi Flash: Allow auto-booting of images from spi flash load
This allows intelligent booting of FIT (& the legacy style) images from
SPI flash. Basically it means that you don't have to guess at the image
length, so data reads are more optimal (& hopefully faster).
Signed-off-by: Andre Renaud
---
Index: common/cmd_sf.c
===
--- common/cmd_sf.c (revision 31)
+++ common/cmd_sf.c (working copy)
@@ -109,6 +109,96 @@
return 0;
}
+static int do_spi_flash_boot(cmd_tbl_t *cmdtp, int argc, char * const argv[])
+{
+ char *ep;
+ size_t cnt;
+ image_header_t *hdr;
+#if defined(CONFIG_FIT)
+ const void *fit_hdr = NULL;
+#endif
+ unsigned long addr;
+ unsigned long offset;
+ char *endp;
+ int ret;
+
+ if (argc < 3)
+ return -1;
+
+ addr = simple_strtoul(argv[1], &endp, 16);
+ if (*argv[1] == 0 || *endp != 0)
+ return -1;
+ offset = simple_strtoul(argv[2], &endp, 16);
+ if (*argv[2] == 0 || *endp != 0)
+ return -1;
+
+ printf("\nLoading from offset 0x%lx\n", offset);
+
+ ret = spi_flash_read(flash, offset, 1024, (u_char *)addr);
+ if (ret) {
+ printf("SPI flash boot failed\n");
+ return 1;
+ }
+
+ switch (genimg_get_format((void *)addr)) {
+ case IMAGE_FORMAT_LEGACY:
+ hdr = (image_header_t *)addr;
+
+ image_print_contents(hdr);
+
+ cnt = image_get_image_size(hdr);
+ break;
+#if defined(CONFIG_FIT)
+ case IMAGE_FORMAT_FIT:
+ fit_hdr = (const void *)addr;
+ puts("Fit image detected...\n");
+
+ cnt = fit_get_size(fit_hdr);
+ break;
+#endif
+ default:
+ puts("** Unknown image type\n");
+ return 1;
+ }
+
+ ret = spi_flash_read(flash, offset, cnt, (u_char *)addr);
+ if (ret) {
+ printf("SPI flash boot failed\n");
+ return 1;
+ }
+
+#if defined(CONFIG_FIT)
+ /* This cannot be done earlier,
+* we need complete FIT image in RAM first */
+ if (genimg_get_format((void *)addr) == IMAGE_FORMAT_FIT) {
+ if (!fit_check_format(fit_hdr)) {
+ puts("** Bad FIT image format\n");
+ return 1;
+ }
+ fit_print_contents(fit_hdr);
+ }
+#endif
+
+ /* Loading ok, update default load address */
+
+ load_addr = addr;
+
+ /* Check if we should attempt an auto-start */
+ if (((ep = getenv("autostart")) != NULL) && (strcmp(ep, "yes") == 0)) {
+ char *local_args[2];
+
+ local_args[0] = "bootm";
+ local_args[1] = NULL;
+
+ printf("Automatic boot of image at addr 0x%08lx ...\n", addr);
+
+ do_bootm(cmdtp, 0, 1, local_args);
+ return 1;
+ }
+ return 0;
+}
+
+
static int do_spi_flash_read_write(int argc, char * const argv[])
{
unsigned long addr;
@@ -207,6 +297,8 @@
ret = do_spi_flash_read_write(argc, argv);
else if (strcmp(cmd, "erase") == 0)
ret = do_spi_flash_erase(argc, argv);
+ else if (strcmp(cmd, "boot") == 0)
+ ret = do_spi_flash_boot(cmdtp, argc, argv);
else
ret = -1;
@@ -229,4 +321,7 @@
" at `addr' to flash at `offset'\n"
"sf erase offset [+]len - erase `len' bytes from `offset'\n"
" `+len' round up `len' to block size"
+ "sf boot addr offset- read a boot image starting at\n"
+ " `offset' to memory at `addr' and\n"
+ " execute it\n"
);
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] Added extra documentation about how the relocation address to RAM is picked for ARM.
Dear Christopher Harvey,
In message <20110706205857.gb2...@harvey-pc.matrox.com> you wrote:
>
> > Also delete "for ARM", and s/arm//. This is not ARM specific.
>
> I don't understand, I found the following snippet in
> arch/arm/lib/board.c
>
>--addr defined and set here--
>
> gd->relocaddr = addr;
> gd->start_addr_sp = addr_sp;
> gd->reloc_off = addr - _TEXT_BASE;
> debug ("relocation Offset is: %08lx\n", gd->reloc_off);
> memcpy (id, (void *)gd, sizeof (gd_t));
>
> relocate_code (addr_sp, id, addr);
> /* NOTREACHED - relocate_code() does not return */
>
> Running grep -R gd->relocaddr *,
> I found similar assignments for various architectures.
Yes, that's what I said: this is not ARM specific, it is supposed to
be common code used by all architectures (except for the sad fact that
there are several non-conforming implementations). But if we document
it, we should document the nominal state. [If in doubt, use the
powerpc implementation as reference.]
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"It is better to have tried and failed than to have failed to try,
but the result's the same." - Mike Dennison
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [POST] retrieving the results in Linux ?
Dear Valentin Longchamp, In message <4e146e9f.4000...@keymile.com> you wrote: > > In the POST documentation, it is clearly stated: > > > 2) The results of tests shall be saved so that it will be possible to > >retrieve them from Linux. > > I have two questions here: > > - I don't find where the result actually is saved. Was this implemented > already > ? Was the logbuffer intented for this (call to logbuff_log in post_log) ? Yes. The idea is to share the log buffer between U-Boot and Linux (hence it's allocation at the very end of the RAM). Of course you need support for this feature in Linux, too. IIRC this has not yet made it's way into mainline. > - If I was wrong for the first question (the results actually are saved), > where > can I find some information about how to retrieve these results ? The plan is to share the log buffer, in both directions: Linux can read the POST results, and U-Boot can read the last Linux messages after a crash / reboot. Actually, after a reboot you can read the last messages from the _previously_ running kernel in Linux, too (assuming there are no wraparounds, of course). 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 One difference between a man and a machine is that a machine is quiet when well oiled. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] Added extra documentation about how the relocation address to RAM is picked for ARM.
On Mon, Jul 04, 2011 at 09:43:24PM +0200, Wolfgang Denk wrote:
> Dear Christopher Harvey,
>
> In message <20110704174348.gc3...@harvey-pc.matrox.com> you wrote:
> > Signed-off-by: Christopher Harvey
> > ---
> > doc/README.arm-relocation |9 -
> > 1 files changed, 8 insertions(+), 1 deletions(-)
>
> Please let's stop with ARM specific documatation of things that are
> considered generic.
>
> > +The code that picks the location in RAM for ARM can be found in the
> > +arch/arm/lib/board.c file under the board_init_f function.
>
> under the function? Who dropped that code? :-) s/under/in/
>
> Also delete "for ARM", and s/arm//. This is not ARM specific.
>
I don't understand, I found the following snippet in
arch/arm/lib/board.c
--addr defined and set here--
gd->relocaddr = addr;
gd->start_addr_sp = addr_sp;
gd->reloc_off = addr - _TEXT_BASE;
debug ("relocation Offset is: %08lx\n", gd->reloc_off);
memcpy (id, (void *)gd, sizeof (gd_t));
relocate_code (addr_sp, id, addr);
/* NOTREACHED - relocate_code() does not return */
Running grep -R gd->relocaddr *,
I found similar assignments for various architectures.
...
[snip]
...
>
> Best regards,
>
> Wolfgang Denk
>
Thanks for the clarification,
-Chris
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] arm: add CONFIG_MACH_TYPE option and documentation
On 07/06/11 21:53, Albert ARIBAUD wrote:
> Hi Igor,
>
> Le 04/07/2011 11:00, Igor Grinberg a écrit :
>> CONFIG_MACH_TYPE can be used to set the machine type number in the
>> common arm code instead of setting it in the board code.
>>
>> Signed-off-by: Igor Grinberg
>> ---
>> README | 12
>> arch/arm/lib/board.c |5 +
>> 2 files changed, 17 insertions(+), 0 deletions(-)
>>
>> diff --git a/README b/README
>> index 446966d..a9ccb0a 100644
>> --- a/README
>> +++ b/README
>> @@ -442,6 +442,18 @@ The following options need to be configured:
>> crash. This is needed for buggy hardware (uc101) where
>> no pull down resistor is connected to the signal IDE5V_DD7.
>>
>> +CONFIG_MACH_TYPE[relevant for ARM only]
>> +
>> +This option can be used to specify the machine type number
>> +as it appears in the ARM machine registry
>> +(see http://www.arm.linux.org.uk/developer/machines/).
>> +If this option is not defined, then your board code
>> +will have to set this up like:
>> +gd->bd->bi_arch_number =;
>> +Note: This option is not suitable if you have multiple
>> +boards supported in a single configuration file and the
>> +machine type is runtime discoverable.
>> +
>> - vxWorks boot parameters:
>>
>> bootvx constructs a valid bootline using the following
>> diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
>> index 169dfeb..ee77d05 100644
>> --- a/arch/arm/lib/board.c
>> +++ b/arch/arm/lib/board.c
>> @@ -451,6 +451,11 @@ void board_init_r (gd_t *id, ulong dest_addr)
>>
>> monitor_flash_len = _end_ofs;
>> debug ("monitor flash len: %08lX\n", monitor_flash_len);
>> +
>> +#ifdef CONFIG_MACH_TYPE
>> +bd->bi_arch_number = CONFIG_MACH_TYPE; /* board id for Linux */
>> +#endif
>> +
>> board_init();/* Setup chipselects */
>>
>> #ifdef CONFIG_SERIAL_MULTI
>
> I don't really see the added value of having this configuration option. It is
> used in only one place for one line of code, which is a sign to me that it
> does not bring any substantial benefits.
Well, this is something that came up when I tried to get rid of machine_is_*
macros (patch 3/3), so we could change/cut/simplify the overgrown mach-types.h
if we want/need to...
I think there is an added value, may be it is hard to see it right now.
If we have this option and it is documented, then any new board can use it
instead of thinking (although it is simple) where and how to dereference
the bi_arch_number.
Also, it can come in handy, in the configuration system (I think it is called
Kbuild?),
so the value can be chosen from the list or something.
The history of how this option was born is here:
http://www.mail-archive.com/u-boot@lists.denx.de/msg52349.html
and in this thread:
http://www.mail-archive.com/u-boot@lists.denx.de/msg52396.html
--
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] net/eth.c: make eth_get_dev_by_name(NULL) safe
On Wednesday, July 06, 2011 03:15:08 Helmut Raiger wrote: > On 07/05/2011 05:44 AM, Mike Frysinger wrote: > > On Monday, July 04, 2011 06:29:51 helmut.rai...@hale.at wrote: > >> eth_get_dev_by_name() is not safe to use for devname being NULL > >> as it uses strcmp. This patch makes it return NULL if devname NULL > >> is passed. > > > > i'm not sure about this. passing NULL is wrong, and the caller should > > catch that shouldnt it ? > > So what is your suggestion how to deal with it? in what situation is eth_get_dev_by_name(NULL) being called ? my suggestion would be to fix that call point since it's doing something wrong. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Adds saving of Kernel boot args to NAND flash
Hi Simon, Le 05/07/2011 15:20, Simon Schwarz a écrit : > This is an RFC on how this can be done. Then please tag the subject with [RFC] next time! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] arm: add CONFIG_MACH_TYPE option and documentation
Hi Igor,
Le 04/07/2011 11:00, Igor Grinberg a écrit :
> CONFIG_MACH_TYPE can be used to set the machine type number in the
> common arm code instead of setting it in the board code.
>
> Signed-off-by: Igor Grinberg
> ---
> README | 12
> arch/arm/lib/board.c |5 +
> 2 files changed, 17 insertions(+), 0 deletions(-)
>
> diff --git a/README b/README
> index 446966d..a9ccb0a 100644
> --- a/README
> +++ b/README
> @@ -442,6 +442,18 @@ The following options need to be configured:
> crash. This is needed for buggy hardware (uc101) where
> no pull down resistor is connected to the signal IDE5V_DD7.
>
> + CONFIG_MACH_TYPE[relevant for ARM only]
> +
> + This option can be used to specify the machine type number
> + as it appears in the ARM machine registry
> + (see http://www.arm.linux.org.uk/developer/machines/).
> + If this option is not defined, then your board code
> + will have to set this up like:
> + gd->bd->bi_arch_number =;
> + Note: This option is not suitable if you have multiple
> + boards supported in a single configuration file and the
> + machine type is runtime discoverable.
> +
> - vxWorks boot parameters:
>
> bootvx constructs a valid bootline using the following
> diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
> index 169dfeb..ee77d05 100644
> --- a/arch/arm/lib/board.c
> +++ b/arch/arm/lib/board.c
> @@ -451,6 +451,11 @@ void board_init_r (gd_t *id, ulong dest_addr)
>
> monitor_flash_len = _end_ofs;
> debug ("monitor flash len: %08lX\n", monitor_flash_len);
> +
> +#ifdef CONFIG_MACH_TYPE
> + bd->bi_arch_number = CONFIG_MACH_TYPE; /* board id for Linux */
> +#endif
> +
> board_init(); /* Setup chipselects */
>
> #ifdef CONFIG_SERIAL_MULTI
I don't really see the added value of having this configuration option.
It is used in only one place for one line of code, which is a sign to me
that it does not bring any substantial benefits.
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Adds saving of Kernel boot args to NAND flash
On Wed, 6 Jul 2011 09:42:52 +0200 Simon Schwarz wrote: > Hi, > > thanks for your feedback! > > I will address the style problems - didn't run checkpatch for the RFC > - sorry my fault. > > > Why are you writing to NAND as part of bootm? > > > > If you just want access to the results of the FDT/ATAG preparation that > > bootm does, consider using the bootm subcommands to prepare them, then > > normal U-Boot commands to write to NAND. > > Hm thats a point. I see this as a feature as it saves new settings > without the need of special commands But that's not what bootm is for. If you're doing something new, it should be in a new command -- or in a script of existing commands. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mxc_nand: fix a problem writing more than 32MB
From: Helmut Raiger When writing 0x4000 to the unlockend_blkaddr register, large writes to a 2k page NAND sometimes fail. The current kernel driver writes 0x to this register for V2 of the nand controller. However on an i.MX31 this also fixes writes larger than 32MB. The datasheet is very unspecific, but (0x4000=16384)*2000 roughly fits the limits we're encountering with NAND writes. This problem might be NAND chip specific. Signed-off-by: Helmut Raiger --- drivers/mtd/nand/mxc_nand.c | 13 - 1 files changed, 12 insertions(+), 1 deletions(-) diff --git a/drivers/mtd/nand/mxc_nand.c b/drivers/mtd/nand/mxc_nand.c index 78e07cc..35e89a0 100644 --- a/drivers/mtd/nand/mxc_nand.c +++ b/drivers/mtd/nand/mxc_nand.c @@ -1371,7 +1371,18 @@ int board_nand_init(struct nand_chip *this) /* Blocks to be unlocked */ writew(0x0, &host->regs->nfc_unlockstart_blkaddr); - writew(0x4000, &host->regs->nfc_unlockend_blkaddr); + /* Originally (Freescale LTIB 2.6.21) 0x4000 was written to the +* unlockend_blkaddr, but the magic 0x4000 does not always work +* when writing more than some 32 megabytes (on 2k page nands) +* However 0x doesn't seem to have this kind +* of limitation (tried it back and forth several times). +* The linux kernel driver sets this to 0x for the v2 controller +* only, but probably this was not tested there for v1. +* The very same limitation seems to apply to this kernel driver. +* This might be NAND chip specific and the i.MX31 datasheet is +* extremely vague about the semantics of this register. +*/ + writew(0x, &host->regs->nfc_unlockend_blkaddr); /* Unlock Block Command for given address range */ writew(0x4, &host->regs->nfc_wrprot); -- 1.7.4.4 -- Scanned by MailScanner. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: Update maintainer of board scb9328
On 07/06/2011 05:46 PM, Torsten Koschorrek wrote: > understood. I CCed you for the MAINTAINERS patch. I hope this was correct. Ok. I will put this into u-boot-imx together with your patch for the scb9328, if there will be no more comments. > Thanks, and sorry for the noise regarding some basic rules for sending > patches! You're welcome, do not worry ;-) Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: Update maintainer of board scb9328
Stefano Babic wrote: > On 07/04/2011 11:34 AM, Torsten Koschorrek wrote: >> Torsten Koschorrek wrote: >>> Signed-off-by: Torsten Koschorrek >>> --- >>> MAINTAINERS |2 +- >>> 1 files changed, 1 insertions(+), 1 deletions(-) >>> >>> diff --git a/MAINTAINERS b/MAINTAINERS >>> index c462ae2..fe578ef 100644 >>> --- a/MAINTAINERS >>> +++ b/MAINTAINERS >>> @@ -684,7 +684,7 @@ Matthias Kaehlcke >>> edb9315 ARM920T (EP9315) >>> edb9315aARM920T (EP9315) >>> -Konstantin Kletschke >>> +Torsten Koschorrek >>> scb9328 ARM920T >>> Nishant Kamat >> >> What about this patch? I don't see it in master yet... > > Hi Torsten, > > sorry for delay. Please send your patches in CC also to the maintainer > for part you want to change. > understood. I CCed you for the MAINTAINERS patch. I hope this was correct. > You must maintain the order of the list. If you check, except some > errors, the list is sorted by the alphabetical name of the developers. > Please fix it. > done, see v2 of the patch. > Best regards, > Stefano Babic > Thanks, and sorry for the noise regarding some basic rules for sending patches! Torsten ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] ARM: Update maintainer of board scb9328
Signed-off-by: Torsten Koschorrek --- Changes for v2: - order of list - cpu description i.MXL added MAINTAINERS |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 2bba7b4..990d508 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -688,9 +688,6 @@ Matthias Kaehlcke edb9315 ARM920T (EP9315) edb9315aARM920T (EP9315) -Konstantin Kletschke - scb9328 ARM920T - Nishant Kamat omap1610h2 ARM926EJS @@ -705,6 +702,9 @@ Chander Kashyap SMDKV310ARM ARMV7 (S5PC210 SoC) +Torsten Koschorrek + scb9328 ARM920T (i.MXL) + Frederik Kriewitz devkit8000 ARM ARMV7 (OMAP3530 SoC) -- 1.7.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARMv7: Add missing boards to MAKEALL
From: Dirk Behme Add all missing boards with CPU==armv7 from boards.cfg to MAKEALL. Signed-off-by: Dirk Behme --- MAKEALL | 12 1 file changed, 12 insertions(+) Index: u-boot.git/MAKEALL === --- u-boot.git.orig/MAKEALL +++ u-boot.git/MAKEALL @@ -423,11 +423,18 @@ LIST_ARMV7=" \ am3517_crane\ am3517_evm \ ca9x4_ct_vxp\ + cm_t35 \ devkit8000 \ dig297 \ + efikamx \ + harmony \ igep0020\ igep0030\ mx51evk \ + mx53ard \ + mx53evk \ + mx53loco\ + mx53smd \ omap3_beagle\ omap3_overo \ omap3_evm \ @@ -437,8 +444,13 @@ LIST_ARMV7=" \ omap3_zoom2 \ omap4_panda \ omap4_sdp4430 \ + s5pc210_universal \ s5p_goni\ + seaboard\ smdkc100\ + smdkv310\ + u8500_href \ + vision2 \ " # ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [POST] retrieving the results in Linux ?
Hello, In the POST documentation, it is clearly stated: > 2) The results of tests shall be saved so that it will be possible to >retrieve them from Linux. I have two questions here: - I don't find where the result actually is saved. Was this implemented already ? Was the logbuffer intented for this (call to logbuff_log in post_log) ? - If I was wrong for the first question (the results actually are saved), where can I find some information about how to retrieve these results ? -- Valentin Longchamp Embedded Software Engineer Hardware and Chip Integration __ KEYMILE AG Schwarzenburgstr. 73 CH-3097 Liebefeld Phone +41 31 377 1318 Fax +41 31 377 1212 valentin.longch...@keymile.com www.keymile.com __ KEYMILE: A Specialist as a Partner ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Samsung] [PATCH 1/2] ARMV7: Add support for Samsung ORIGEN board
Hi Simon, On Wed, Jul 6, 2011 at 7:32 AM, Simon Glass wrote: > Hi Chander, > > On Mon, Jun 27, 2011 at 1:37 AM, Chander Kashyap > wrote: >> >> Origen board is based upon S5PV310 SoC which is similiar to >> S5PC210 SoC. >> >> Signed-off-by: Chander Kashyap >> --- >> MAINTAINERS | 1 + >> board/samsung/origen/Makefile | 46 >> board/samsung/origen/lowlevel_init.S | 468 >> ++ >> board/samsung/origen/mem_setup.S | 392 >> board/samsung/origen/origen.c | 103 >> boards.cfg | 1 + >> include/configs/origen.h | 167 >> 7 files changed, 1178 insertions(+), 0 deletions(-) >> create mode 100644 board/samsung/origen/Makefile >> create mode 100644 board/samsung/origen/lowlevel_init.S >> create mode 100644 board/samsung/origen/mem_setup.S >> create mode 100644 board/samsung/origen/origen.c >> create mode 100644 include/configs/origen.h >> > There is a lot of assembler in this patch. I wonder if it would make sense > to use C for more of this? The size of the SPL is restricted so that was the reason that assembly was used. > Regards, > Simon > Cheers Angus -- Angus Ainslie Team Lead, Samsung Landing Team ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] davinci, dm365, usb: timeoutvalue
Dear Heiko Schocher,
In message <4e144710.7020...@denx.de> you wrote:
> Hello Thomas,
>
> I just debugging some usb issues on an dm365 based board. I noticed
> that if no usb device is connected to the board, the "usb start"
> command does have a long timeout (also have access to an dm365evm
> board, same behaviour). Found the reason for this big timeout here:
>
> ./drivers/usb/musb/musb_hcd.c usb_lowlevel_init():
> timeout = musb_cfg.timeout;
> while (timeout--)
> if (readb(&musbr->devctl) & MUSB_DEVCTL_HM)
> break;
Argh...
> #define DAVINCI_USB_TIMEOUT 0x3FF
>
> Why is this DAVINCI_USB_TIMEOUT value so high? This could be shorter,
> or are there some reasons for such a long timeout?
Actually this means that the actual amount of time spent in this loop
is not defined, and depends on the actual speed of the CPU, RAM, etc.
The timeout value should be changed into a time value (instead of
cycle count), and the poll loop should be changed accordingly, for
example like this:
#define DAVINCI_USB_TIMEOUT 250 /* 250 milliseconds */
...
while (timeout--) {
if (readb(&musbr->devctl) & MUSB_DEVCTL_HM)
break;
udelay (1000);
}
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
"Today's robots are very primitive, capable of understanding only a
few simple instructions such as 'go left', 'go right', and 'build
car'." - John Sladek
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] ARMV7: Add support for Samsung ORIGEN board
Hi Chander, On Mon, Jun 27, 2011 at 1:37 AM, Chander Kashyap wrote: > Origen board is based upon S5PV310 SoC which is similiar to > S5PC210 SoC. > > Signed-off-by: Chander Kashyap > --- > MAINTAINERS |1 + > board/samsung/origen/Makefile| 46 > board/samsung/origen/lowlevel_init.S | 468 > ++ > board/samsung/origen/mem_setup.S | 392 > board/samsung/origen/origen.c| 103 > boards.cfg |1 + > include/configs/origen.h | 167 > 7 files changed, 1178 insertions(+), 0 deletions(-) > create mode 100644 board/samsung/origen/Makefile > create mode 100644 board/samsung/origen/lowlevel_init.S > create mode 100644 board/samsung/origen/mem_setup.S > create mode 100644 board/samsung/origen/origen.c > create mode 100644 include/configs/origen.h > > There is a lot of assembler in this patch. I wonder if it would make sense to use C for more of this? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Adds saving of Kernel boot args to NAND flash
> If you just want access to the results of the FDT/ATAG preparation that > bootm does, consider using the bootm subcommands to prepare them, then > normal U-Boot commands to write to NAND. Me again. I rethought and the problem with bootm is that the subfunctions (bootm_linux_fdt/do_bootm_linux) are directly boot the kernel. That means either I copy almost the whole function and delete the kernel_entry-call. Or I move the tag/fdt creation out of bootm-command and create a extra function. The first way I consider bad because of code duplication - therefore I would take the second path. Any Objections? Regards Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] davinci, dm365, usb: timeoutvalue
Hello Thomas,
I just debugging some usb issues on an dm365 based board. I noticed
that if no usb device is connected to the board, the "usb start"
command does have a long timeout (also have access to an dm365evm
board, same behaviour). Found the reason for this big timeout here:
./drivers/usb/musb/musb_hcd.c usb_lowlevel_init():
timeout = musb_cfg.timeout;
while (timeout--)
if (readb(&musbr->devctl) & MUSB_DEVCTL_HM)
break;
with ./drivers/usb/musb/davinci.:
/* MUSB platform configuration */
struct musb_config musb_cfg = {
.regs = (struct musb_regs *)MENTOR_USB0_BASE,
.timeout= DAVINCI_USB_TIMEOUT,
.musb_speed = 0,
};
and ./drivers/usb/musb/davinci.h:
#define DAVINCI_USB_TIMEOUT 0x3FF
Why is this DAVINCI_USB_TIMEOUT value so high? This could be shorter,
or are there some reasons for such a long timeout?
Thanks!
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4 v3] musb: Add Phy programming for usingexternal Vbus
On 2011-07-05 16:16, Gupta, Ajay Kumar wrote: >> (On our custom board, we have added an external vbus supply to be able >> to draw> 100 mA.) > So it seems you are using PHY inside TPS659x but external Vbus for which > I think you need to, > 1. Explicitly set "OTG_CTRL.D5 = 0" so that PHY doesn't drive 5V. > 2. Do not set musb_cfg.extvbus Great, thanks for clarifying (and agreed on all points). It seems the best I can do is turn off DRVVBUS as soon as the chip has entered host mode (and turned thus it on). Thanks, Orjan -- Orjan Friberg FlatFrog Laboratories AB ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] smdk2416 board support
Hi, Sorry for the shameless advertising, but I thought that perhaps someone would be interested to know that I've started working on this, and I was able to convince ppl here to offer a small bounty on getting this work done, and done properly. So I've posted a project on freelancer.com (http://www.freelancer.com/projects/C-Programming/Port-boot-custom-code-mainline.html). Kind Regards, Thiago A. Correa ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] gpio command: return value on write, additional actions
Dear Detlev Zundel, In message you wrote: > > > I'd say clear/set/toggle are changeable, don't see any legit > > return-value-usage here. For 100% backward compatibility, one could > > leave them as they are and use 0|1 as new actions with return 0, as > > proposed. Hm... I think it would be beneficial to bee able to get information about the current settings. For "clear" and "set" the result is known, but for "toggle" it would be helpful if we returned the current port state. Eventually we should add a "test" command (or "read" ?) that returns the current setting? > > So these variants: > > gpio clear|0 => set to output, write 0, return success > > gpio set|1 => set to output, write 1, return success > > gpio toggle => (set to output), toggle output, return success > > gpio input => set to input, return pin value > > gpio value => return current pin/latch/whatever value > > I'd propose to fix the commands to be sensible now. Actually I believe > that they should not be in heavy use "in the wild" and so we should take > the opportunity and declare the current behaviour as buggy and fix it. > Rather now than later ;) Agreed. > Actually I would expect the "output" commands to return true when they > were able to do what was requestes from them, i.e. drive the requested > value to the output. I guess this cannot be done in the general case, > but for a "weak output" that can be read back, this would be the most > sensible thing to do. For consistency I would prefer to have all commands return the same type of information, i. e. either an error status (like we do with all other commands - any result values would then have to be passed as environment settings), or we return the current port state (also for the "output" commands - see my comments for "toggle"). 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 Hokey religions and ancient weapons are no substitute for a good blaster at your side. - Han Solo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/6] imx: Add auto generation of asm-offsets.h for imx25
Offsets to registers may be needed in asm code. This patch adds automated
generation of these offsets form C structures.
Signed-off-by: Matthias Weisser
---
Changes in v2:
- Added a change in Makefile which was in wrong patch of the patch set
arch/arm/cpu/arm926ejs/mx25/Makefile |2 +
arch/arm/cpu/arm926ejs/mx25/asm-offsets.c | 60 +
arch/arm/include/asm/arch-mx25/imx-regs.h | 39 +++
3 files changed, 101 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/cpu/arm926ejs/mx25/asm-offsets.c
diff --git a/arch/arm/cpu/arm926ejs/mx25/Makefile
b/arch/arm/cpu/arm926ejs/mx25/Makefile
index 3c2a65e..9219c06 100644
--- a/arch/arm/cpu/arm926ejs/mx25/Makefile
+++ b/arch/arm/cpu/arm926ejs/mx25/Makefile
@@ -34,6 +34,8 @@ all: $(obj).depend $(LIB)
$(LIB):$(OBJS)
$(call cmd_link_o_target, $(OBJS))
+$(OBJS) : $(TOPDIR)/include/asm/arch/asm-offsets.h
+
#
# defines $(obj).depend target
diff --git a/arch/arm/cpu/arm926ejs/mx25/asm-offsets.c
b/arch/arm/cpu/arm926ejs/mx25/asm-offsets.c
new file mode 100644
index 000..ba8dfd4
--- /dev/null
+++ b/arch/arm/cpu/arm926ejs/mx25/asm-offsets.c
@@ -0,0 +1,60 @@
+/*
+ * Adapted from Linux v2.6.36 kernel: arch/powerpc/kernel/asm-offsets.c
+ *
+ * This program is used to generate definitions needed by
+ * assembly language modules.
+ *
+ * We use the technique used in the OSF Mach kernel code:
+ * generate asm statements containing #defines,
+ * compile this file to assembler, and then extract the
+ * #defines from the assembly-language output.
+ *
+ * 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.
+ */
+
+#include
+#include
+
+#include
+
+int main(void)
+{
+ /* Clock Control Module */
+ DEFINE(CCM_CCTL, offsetof(struct ccm_regs, cctl));
+ DEFINE(CCM_CGCR0, offsetof(struct ccm_regs, cgr0));
+ DEFINE(CCM_CGCR1, offsetof(struct ccm_regs, cgr1));
+ DEFINE(CCM_CGCR2, offsetof(struct ccm_regs, cgr2));
+ DEFINE(CCM_PCDR2, offsetof(struct ccm_regs, pcdr[2]));
+ DEFINE(CCM_MCR, offsetof(struct ccm_regs, mcr));
+
+ /* Enhanced SDRAM Controller */
+ DEFINE(ESDRAMC_ESDCTL0, offsetof(struct esdramc_regs, ctl0));
+ DEFINE(ESDRAMC_ESDCFG0, offsetof(struct esdramc_regs, cfg0));
+ DEFINE(ESDRAMC_ESDMISC, offsetof(struct esdramc_regs, misc));
+
+ /* Multi-Layer AHB Crossbar Switch */
+ DEFINE(MAX_MPR0, offsetof(struct max_regs, mpr0));
+ DEFINE(MAX_SGPCR0, offsetof(struct max_regs, sgpcr0));
+ DEFINE(MAX_MPR1, offsetof(struct max_regs, mpr1));
+ DEFINE(MAX_SGPCR1, offsetof(struct max_regs, sgpcr1));
+ DEFINE(MAX_MPR2, offsetof(struct max_regs, mpr2));
+ DEFINE(MAX_SGPCR2, offsetof(struct max_regs, sgpcr2));
+ DEFINE(MAX_MPR3, offsetof(struct max_regs, mpr3));
+ DEFINE(MAX_SGPCR3, offsetof(struct max_regs, sgpcr3));
+ DEFINE(MAX_MPR4, offsetof(struct max_regs, mpr4));
+ DEFINE(MAX_SGPCR4, offsetof(struct max_regs, sgpcr4));
+ DEFINE(MAX_MGPCR0, offsetof(struct max_regs, mgpcr0));
+ DEFINE(MAX_MGPCR1, offsetof(struct max_regs, mgpcr1));
+ DEFINE(MAX_MGPCR2, offsetof(struct max_regs, mgpcr2));
+ DEFINE(MAX_MGPCR3, offsetof(struct max_regs, mgpcr3));
+ DEFINE(MAX_MGPCR4, offsetof(struct max_regs, mgpcr4));
+
+ /* AHB <-> IP-Bus Interface */
+ DEFINE(AIPS_MPR_0_7, offsetof(struct aips_regs, mpr_0_7));
+ DEFINE(AIPS_MPR_8_15, offsetof(struct aips_regs, mpr_8_15));
+
+ return 0;
+}
diff --git a/arch/arm/include/asm/arch-mx25/imx-regs.h
b/arch/arm/include/asm/arch-mx25/imx-regs.h
index 55ad115..62ee4d5 100644
--- a/arch/arm/include/asm/arch-mx25/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx25/imx-regs.h
@@ -141,6 +141,45 @@ struct fuse_bank0_regs {
u32 mac_addr[6];
};
+/* Multi-Layer AHB Crossbar Switch (MAX) registers */
+struct max_regs {
+ u32 mpr0;
+ u32 pad00[3];
+ u32 sgpcr0;
+ u32 pad01[59];
+ u32 mpr1;
+ u32 pad02[3];
+ u32 sgpcr1;
+ u32 pad03[59];
+ u32 mpr2;
+ u32 pad04[3];
+ u32 sgpcr2;
+ u32 pad05[59];
+ u32 mpr3;
+ u32 pad06[3];
+ u32 sgpcr3;
+ u32 pad07[59];
+ u32 mpr4;
+ u32 pad08[3];
+ u32 sgpcr4;
+ u32 pad09[251];
+ u32 mgpcr0;
+ u32 pad10[63];
+ u32 mgpcr1;
+ u32 pad11[63];
+ u32 mgpcr2;
+ u32 pad12[63];
+ u32 mgpcr3;
+ u32 pad13[63];
+ u32 mgpcr4;
+};
+
+/* AHB <-> IP-Bus Interface (AIPS) */
+struct aips_regs {
+ u32 mpr_0_7;
+ u32 mpr_8_15;
+};
+
#endif
/* AIPS 1 */
--
1.7.0.4
___
U-Boot maili
[U-Boot] [PATCH v2 5/6] imx: Make imx25 compatible to mxc_gpio driver and fix in tx25
Adding support for mxc_gpio driver for imx25 and fix names of registers in tx25
board.
Signed-off-by: Matthias Weisser
---
Changes in v2:
- New in patch set due to review of v1
arch/arm/include/asm/arch-mx25/imx-regs.h | 10 --
board/karo/tx25/tx25.c| 26 +-
include/mxc_gpio.h|5 +
3 files changed, 26 insertions(+), 15 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx25/imx-regs.h
b/arch/arm/include/asm/arch-mx25/imx-regs.h
index 62ee4d5..2ccb445 100644
--- a/arch/arm/include/asm/arch-mx25/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx25/imx-regs.h
@@ -86,8 +86,8 @@ struct esdramc_regs {
/* GPIO registers */
struct gpio_regs {
- u32 dr; /* data */
- u32 dir;/* direction */
+ u32 gpio_dr;/* data */
+ u32 gpio_dir; /* direction */
u32 psr;/* pad satus */
u32 icr1; /* interrupt config 1 */
u32 icr2; /* interrupt config 2 */
@@ -357,4 +357,10 @@ struct aips_regs {
#define WSR_UNLOCK10x
#define WSR_UNLOCK20x
+/* Names used in GPIO driver */
+#define GPIO1_BASE_ADDRIMX_GPIO1_BASE
+#define GPIO2_BASE_ADDRIMX_GPIO2_BASE
+#define GPIO3_BASE_ADDRIMX_GPIO3_BASE
+#define GPIO4_BASE_ADDRIMX_GPIO4_BASE
+
#endif /* _IMX_REGS_H */
diff --git a/board/karo/tx25/tx25.c b/board/karo/tx25/tx25.c
index 269858c..4088374 100644
--- a/board/karo/tx25/tx25.c
+++ b/board/karo/tx25/tx25.c
@@ -70,18 +70,18 @@ void tx25_fec_init(void)
writel(0x0, &padctl->pad_d11);
/* drop PHY power and assert reset (low) */
- val = readl(&gpio4->dr) & ~((1 << 7) | (1 << 9));
- writel(val, &gpio4->dr);
- val = readl(&gpio4->dir) | (1 << 7) | (1 << 9);
- writel(val, &gpio4->dir);
+ val = readl(&gpio4->gpio_dr) & ~((1 << 7) | (1 << 9));
+ writel(val, &gpio4->gpio_dr);
+ val = readl(&gpio4->gpio_dir) | (1 << 7) | (1 << 9);
+ writel(val, &gpio4->gpio_dir);
mdelay(5);
debug("resetting phy\n");
/* turn on PHY power leaving reset asserted */
- val = readl(&gpio4->dr) | 1 << 9;
- writel(val, &gpio4->dr);
+ val = readl(&gpio4->gpio_dr) | 1 << 9;
+ writel(val, &gpio4->gpio_dr);
mdelay(10);
@@ -111,19 +111,19 @@ void tx25_fec_init(void)
/*
* set each to 1 and make each an output
*/
- val = readl(&gpio3->dr) | (1 << 10) | (1 << 11) | (1 << 12);
- writel(val, &gpio3->dr);
- val = readl(&gpio3->dir) | (1 << 10) | (1 << 11) | (1 << 12);
- writel(val, &gpio3->dir);
+ val = readl(&gpio3->gpio_dr) | (1 << 10) | (1 << 11) | (1 << 12);
+ writel(val, &gpio3->gpio_dr);
+ val = readl(&gpio3->gpio_dir) | (1 << 10) | (1 << 11) | (1 << 12);
+ writel(val, &gpio3->gpio_dir);
mdelay(22); /* this value came from RedBoot */
/*
* deassert PHY reset
*/
- val = readl(&gpio4->dr) | 1 << 7;
- writel(val, &gpio4->dr);
- writel(val, &gpio4->dr);
+ val = readl(&gpio4->gpio_dr) | 1 << 7;
+ writel(val, &gpio4->gpio_dr);
+ writel(val, &gpio4->gpio_dr);
mdelay(5);
diff --git a/include/mxc_gpio.h b/include/mxc_gpio.h
index 002ba61..f673dce 100644
--- a/include/mxc_gpio.h
+++ b/include/mxc_gpio.h
@@ -24,6 +24,11 @@
#ifndef __MXC_GPIO_H
#define __MXC_GPIO_H
+/* Converts a GPIO port number and the internal bit position
+ * to the GPIO number
+ */
+#define MXC_GPIO_PORT_TO_NUM(port, bit) (((port - 1) << 5) + (bit & 0x1f))
+
enum mxc_gpio_direction {
MXC_GPIO_DIRECTION_IN,
MXC_GPIO_DIRECTION_OUT,
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 6/6] imx: Add support for zmx25 board
zmx25 is a board based on imx25 SoC, 64 Megs of LPDDR, 32 Megs of NOR flash, an optional NAND flash. Signed-off-by: Matthias Weisser --- Changes in v2: - Using mxc_gpio now - Factored out asm macros MAINTAINERS|1 + arch/arm/include/asm/arch-mx25/macro.h | 64 ++ board/syteco/zmx25/Makefile| 51 board/syteco/zmx25/lowlevel_init.S | 110 + board/syteco/zmx25/zmx25.c | 203 boards.cfg |1 + include/configs/zmx25.h| 180 7 files changed, 610 insertions(+), 0 deletions(-) create mode 100644 arch/arm/include/asm/arch-mx25/macro.h create mode 100644 board/syteco/zmx25/Makefile create mode 100644 board/syteco/zmx25/lowlevel_init.S create mode 100644 board/syteco/zmx25/zmx25.c create mode 100644 include/configs/zmx25.h diff --git a/MAINTAINERS b/MAINTAINERS index 2bba7b4..5b633af 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -892,6 +892,7 @@ Lei Wen Matthias Weisser jadecpu ARM926EJS (MB86R01 SoC) + zmx25 ARM926EJS (imx25 SoC) Richard Woodruff diff --git a/arch/arm/include/asm/arch-mx25/macro.h b/arch/arm/include/asm/arch-mx25/macro.h new file mode 100644 index 000..276c71c --- /dev/null +++ b/arch/arm/include/asm/arch-mx25/macro.h @@ -0,0 +1,64 @@ +/* + * (C) Copyright 2011 + * Matthias Weisser + * + * (C) Copyright 2009 DENX Software Engineering + * Author: John Rigby + * + * Common asm macros for imx25 + * + * 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 + */ + +#ifndef __ASM_ARM_ARCH_MACRO_H__ +#define __ASM_ARM_ARCH_MACRO_H__ +#ifdef __ASSEMBLY__ + +#include +#include + +.macro init_aips + write32 IMX_AIPS1_BASE + AIPS_MPR_0_7, 0x + write32 IMX_AIPS1_BASE + AIPS_MPR_8_15, 0x + write32 IMX_AIPS2_BASE + AIPS_MPR_0_7, 0x + write32 IMX_AIPS2_BASE + AIPS_MPR_8_15, 0x +.endm + +.macro init_max + write32 IMX_MAX_BASE + MAX_MPR0, 0x43210 + write32 IMX_MAX_BASE + MAX_MPR1, 0x43210 + write32 IMX_MAX_BASE + MAX_MPR2, 0x43210 + write32 IMX_MAX_BASE + MAX_MPR3, 0x43210 + write32 IMX_MAX_BASE + MAX_MPR4, 0x43210 + + write32 IMX_MAX_BASE + MAX_SGPCR0, 0x10 + write32 IMX_MAX_BASE + MAX_SGPCR1, 0x10 + write32 IMX_MAX_BASE + MAX_SGPCR2, 0x10 + write32 IMX_MAX_BASE + MAX_SGPCR3, 0x10 + write32 IMX_MAX_BASE + MAX_SGPCR4, 0x10 + + write32 IMX_MAX_BASE + MAX_MGPCR0, 0x0 + write32 IMX_MAX_BASE + MAX_MGPCR1, 0x0 + write32 IMX_MAX_BASE + MAX_MGPCR2, 0x0 + write32 IMX_MAX_BASE + MAX_MGPCR3, 0x0 + write32 IMX_MAX_BASE + MAX_MGPCR4, 0x0 +.endm + +#endif /* __ASSEMBLY__ */ +#endif /* __ASM_ARM_ARCH_MACRO_H__ */ diff --git a/board/syteco/zmx25/Makefile b/board/syteco/zmx25/Makefile new file mode 100644 index 000..5a0e5b3 --- /dev/null +++ b/board/syteco/zmx25/Makefile @@ -0,0 +1,51 @@ +# +# (c) 2010 Graf-Syteco, Matthias Weisser +# +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).o + +COBJS-y+= zmx25.o +SOBJS := lowlevel_init.o + +SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS-y)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(call cmd_link_o_target, $(OBJS) $(SOBJS)) + +clean: + rm
[U-Boot] [PATCH v2 3/6] imx: Add support for USB EHCI on imx25
Adding support for USB host on imx25 using the internal PHY. Changing the name
of base address define for imx31 to get some unification.
Signed-off-by: Matthias Weisser
---
Changes in v2:
- Partially unified for imx25 and imx31
arch/arm/include/asm/arch-mx31/imx-regs.h |2 +-
drivers/usb/host/ehci-mxc.c | 33 ++---
2 files changed, 26 insertions(+), 9 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx31/imx-regs.h
b/arch/arm/include/asm/arch-mx31/imx-regs.h
index 306f966..3c8d607 100644
--- a/arch/arm/include/asm/arch-mx31/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx31/imx-regs.h
@@ -746,7 +746,7 @@ enum iomux_pins {
#define IRAM_SIZE (16 * 1024)
#define MX31_AIPS1_BASE_ADDR 0x43f0
-#define MX31_OTG_BASE_ADDR (MX31_AIPS1_BASE_ADDR + 0x88000)
+#define IMX_USB_BASE (MX31_AIPS1_BASE_ADDR + 0x88000)
/* USB portsc */
/* values for portsc field */
diff --git a/drivers/usb/host/ehci-mxc.c b/drivers/usb/host/ehci-mxc.c
index 6af35ab..a0cfbb7 100644
--- a/drivers/usb/host/ehci-mxc.c
+++ b/drivers/usb/host/ehci-mxc.c
@@ -29,6 +29,14 @@
#define USBCTRL_OTGBASE_OFFSET 0x600
+#ifdef CONFIG_MX25
+#define MX25_USB_CTRL_IP_PUE_DOWN_BIT (1<<6)
+#define MX25_USB_CTRL_HSTD_BIT (1<<5)
+#define MX25_USB_CTRL_USBTE_BIT(1<<4)
+#define MX25_USB_CTRL_OCPOL_OTG_BIT(1<<3)
+#endif
+
+#ifdef CONFIG_MX31
#define MX31_OTG_SIC_SHIFT 29
#define MX31_OTG_SIC_MASK (0x3 << MX31_OTG_SIC_SHIFT)
#define MX31_OTG_PM_BIT(1 << 24)
@@ -42,12 +50,19 @@
#define MX31_H1_SIC_MASK (0x3 << MX31_H1_SIC_SHIFT)
#define MX31_H1_PM_BIT (1 << 8)
#define MX31_H1_DT_BIT (1 << 4)
+#endif
static int mxc_set_usbcontrol(int port, unsigned int flags)
{
unsigned int v;
+
+#ifdef CONFIG_MX25
+ v = MX25_USB_CTRL_IP_PUE_DOWN_BIT | MX25_USB_CTRL_HSTD_BIT |
+ MX25_USB_CTRL_USBTE_BIT | MX25_USB_CTRL_OCPOL_OTG_BIT;
+#endif
+
#ifdef CONFIG_MX31
- v = readl(MX31_OTG_BASE_ADDR + USBCTRL_OTGBASE_OFFSET);
+ v = readl(IMX_USB_BASE + USBCTRL_OTGBASE_OFFSET);
switch (port) {
case 0: /* OTG port */
@@ -85,36 +100,38 @@ static int mxc_set_usbcontrol(int port, unsigned int flags)
default:
return -EINVAL;
}
-
- writel(v, MX31_OTG_BASE_ADDR +
-USBCTRL_OTGBASE_OFFSET);
#endif
- return 0;
+
+ writel(v, IMX_USB_BASE + USBCTRL_OTGBASE_OFFSET);
+ return 0;
}
int ehci_hcd_init(void)
{
- u32 tmp;
struct usb_ehci *ehci;
+#ifdef CONFIG_MX31
+ u32 tmp;
struct clock_control_regs *sc_regs =
(struct clock_control_regs *)CCM_BASE;
tmp = __raw_readl(&sc_regs->ccmr);
__raw_writel(__raw_readl(&sc_regs->ccmr) | (1 << 9), &sc_regs->ccmr) ;
+#endif
udelay(80);
/* Take USB2 */
- ehci = (struct usb_ehci *)(MX31_OTG_BASE_ADDR +
+ ehci = (struct usb_ehci *)(IMX_USB_BASE +
(0x200 * CONFIG_MXC_USB_PORT));
hccr = (struct ehci_hccr *)((uint32_t)&ehci->caplength);
hcor = (struct ehci_hcor *)((uint32_t) hccr +
HC_LENGTH(ehci_readl(&hccr->cr_capbase)));
setbits_le32(&ehci->usbmode, CM_HOST);
+#ifdef CONFIG_MX31
setbits_le32(&ehci->control, USB_EN);
__raw_writel(CONFIG_MXC_USB_PORTSC, &ehci->portsc);
-
+#endif
mxc_set_usbcontrol(CONFIG_MXC_USB_PORT, CONFIG_MXC_USB_FLAGS);
udelay(1);
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/6] imx: Use correct imx25 reset.c
imx25 used the wrong reset.c from imx27 Signed-off-by: Matthias Weisser --- Changes in v2: - Removed unrelated change arch/arm/cpu/arm926ejs/mx25/Makefile |6 ++ 1 files changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/mx25/Makefile b/arch/arm/cpu/arm926ejs/mx25/Makefile index 38d7f03..3c2a65e 100644 --- a/arch/arm/cpu/arm926ejs/mx25/Makefile +++ b/arch/arm/cpu/arm926ejs/mx25/Makefile @@ -24,12 +24,10 @@ include $(TOPDIR)/config.mk LIB= $(obj)lib$(SOC).o -COBJS = generic.o timer.o -MX27OBJS = reset.o +COBJS = generic.o timer.o reset.o SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) -SRCS += $(addprefix $(SRCTREE)/arch/arm/cpu/arm926ejs/mx27/,$(MX27OBJS:.o=.c)) -OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS) $(MX27OBJS)) +OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS)) all: $(obj).depend $(LIB) -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/6] imx: Add get_tbclk() function for imx25
Need this function for autoboot keyd
Signed-off-by: Matthias Weisser
---
arch/arm/cpu/arm926ejs/mx25/timer.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx25/timer.c
b/arch/arm/cpu/arm926ejs/mx25/timer.c
index 14f0c2d..7c8a71b 100644
--- a/arch/arm/cpu/arm926ejs/mx25/timer.c
+++ b/arch/arm/cpu/arm926ejs/mx25/timer.c
@@ -187,3 +187,15 @@ void __udelay (unsigned long usec)
while (get_ticks() < tmp) /* loop till event */
/*NOP*/;
}
+
+/*
+ * This function is derived from PowerPC code (timebase clock frequency).
+ * On ARM it returns the number of timer ticks per second.
+ */
+ulong get_tbclk(void)
+{
+ ulong tbclk;
+
+ tbclk = CONFIG_MX25_CLK32;
+ return tbclk;
+}
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/6] Add support for zmx25 board
zmx25 is a board based on imx25 SoC, 64 Megs of LPDDR, 32 Megs of NOR flash and an optional NAND flash. Some additons to imx25 SoC are made to fully support the hardware on the board. Changes in v2: - Using mxc_gpio now - Partially unified usb for imx25 and imx31 - Factored out asm macros Matthias Weisser (6): imx: Add get_tbclk() function for imx25 imx: Use correct imx25 reset.c imx: Add support for USB EHCI on imx25 imx: Add auto generation of asm-offsets.h for imx25 imx: Make imx25 compatible to mxc_gpio driver and fix in tx25 imx: Add support for zmx25 board MAINTAINERS |1 + arch/arm/cpu/arm926ejs/mx25/Makefile |8 +- arch/arm/cpu/arm926ejs/mx25/asm-offsets.c | 60 + arch/arm/cpu/arm926ejs/mx25/timer.c | 12 ++ arch/arm/include/asm/arch-mx25/imx-regs.h | 49 +++- arch/arm/include/asm/arch-mx25/macro.h| 64 + arch/arm/include/asm/arch-mx31/imx-regs.h |2 +- board/karo/tx25/tx25.c| 26 ++-- board/syteco/zmx25/Makefile | 51 +++ board/syteco/zmx25/lowlevel_init.S| 110 board/syteco/zmx25/zmx25.c| 203 + boards.cfg|1 + drivers/usb/host/ehci-mxc.c | 33 - include/configs/zmx25.h | 180 + include/mxc_gpio.h|5 + 15 files changed, 777 insertions(+), 28 deletions(-) create mode 100644 arch/arm/cpu/arm926ejs/mx25/asm-offsets.c create mode 100644 arch/arm/include/asm/arch-mx25/macro.h create mode 100644 board/syteco/zmx25/Makefile create mode 100644 board/syteco/zmx25/lowlevel_init.S create mode 100644 board/syteco/zmx25/zmx25.c create mode 100644 include/configs/zmx25.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i2c:gpio:s5p: I2C GPIO Software implementation
Hello Lukasz,
Lukasz Majewski wrote:
> On Wed, 06 Jul 2011 07:56:20 +0200
> Heiko Schocher wrote:
>
>> Hello Mike,
>>
>> Mike Frysinger wrote:
>>> On Tuesday, July 05, 2011 08:23:41 Lukasz Majewski wrote:
This commit adds I2C software support for Samsung's S5PC110
family of processors.
The generic drivers/i2c/soft_i2c framework is used, with
routines provided by this commit.
>>> if you simply implemented the generic gpio layer (asm/gpio.h), the
>>> soft_i2c.c code already handles gluing to GPIO pins. then you
>>> wouldnt need a sep driver at all. you can see the bf561-ezkit
>>> already using this code. -mike
>> Yes, that was my thought too. No seperate i2c driver should be needed
>> here.
>>
>> bye,
>> Heiko
>
> Thanks Mike and Heiko for reply.
>
> However I've got some extra question.
>
> In the bf651-ezkit.h file I can see the I2C definition:
>
> #define CONFIG_SOFT_I2C
> #define CONFIG_SOFT_I2C_GPIO_SCL GPIO_PF0
> #define CONFIG_SOFT_I2C_GPIO_SDA GPIO_PF1
>
> My concern is about the situation when SoC needs more than one Software
> I2C run via GPIO?
>
> Please consider following scenario:
> One sensor is connected to pins 1(SCL) and 3(SDA) and another to 4(SCL)
> and 5(SDA) in a GPIO port.
>
> As fair as I've understood the software_i2c framework, it is supposed to
> run only one instance of GPIO I2C.
>
> Is there any way to "instantiate" more than one I2C GPIO interface via
> software_i2c?
It should be possible (not tested), but not very nice:
First, you have to define CONFIG_I2C_MULTI_BUS and CONFIG_SYS_MAX_I2C_BUS
Then your CONFIG_SOFT_I2C_GPIO_SDA and CONFIG_SOFT_I2C_GPIO_SCL
should look something like this:
#define CONFIG_SOFT_I2C_GPIO_SDA get_sda_pin
with
int get_sda_pin(void)
{
int busnr = i2c_get_bus_num();
switch (busnr) {
case 0:
return 3;
break;
case 1:
return 5;
break;
[...]
}
}
Cleaner would be to get the i2c multibus branch to mainline, see:
http://git.denx.de/?p=u-boot/u-boot-i2c.git;a=shortlog;h=refs/heads/multibus_v2
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] i2c:gpio:s5p: I2C GPIO Software implementation
On Wed, 06 Jul 2011 07:56:20 +0200 Heiko Schocher wrote: > Hello Mike, > > Mike Frysinger wrote: > > On Tuesday, July 05, 2011 08:23:41 Lukasz Majewski wrote: > >> This commit adds I2C software support for Samsung's S5PC110 > >> family of processors. > >> The generic drivers/i2c/soft_i2c framework is used, with > >> routines provided by this commit. > > > > if you simply implemented the generic gpio layer (asm/gpio.h), the > > soft_i2c.c code already handles gluing to GPIO pins. then you > > wouldnt need a sep driver at all. you can see the bf561-ezkit > > already using this code. -mike > > Yes, that was my thought too. No seperate i2c driver should be needed > here. > > bye, > Heiko Thanks Mike and Heiko for reply. However I've got some extra question. In the bf651-ezkit.h file I can see the I2C definition: #define CONFIG_SOFT_I2C #define CONFIG_SOFT_I2C_GPIO_SCL GPIO_PF0 #define CONFIG_SOFT_I2C_GPIO_SDA GPIO_PF1 My concern is about the situation when SoC needs more than one Software I2C run via GPIO? Please consider following scenario: One sensor is connected to pins 1(SCL) and 3(SDA) and another to 4(SCL) and 5(SDA) in a GPIO port. As fair as I've understood the software_i2c framework, it is supposed to run only one instance of GPIO I2C. Is there any way to "instantiate" more than one I2C GPIO interface via software_i2c? -- Best regards, Lukasz Majewski Samsung Poland R&D Center Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] gpio command: return value on write, additional actions
Hi Andreas, > I'd say clear/set/toggle are changeable, don't see any legit > return-value-usage here. For 100% backward compatibility, one could > leave them as they are and use 0|1 as new actions with return 0, as > proposed. > > So these variants: > gpio clear|0 => set to output, write 0, return success > gpio set|1 => set to output, write 1, return success > gpio toggle => (set to output), toggle output, return success > gpio input => set to input, return pin value > gpio value => return current pin/latch/whatever value I'd propose to fix the commands to be sensible now. Actually I believe that they should not be in heavy use "in the wild" and so we should take the opportunity and declare the current behaviour as buggy and fix it. Rather now than later ;) Actually I would expect the "output" commands to return true when they were able to do what was requestes from them, i.e. drive the requested value to the output. I guess this cannot be done in the general case, but for a "weak output" that can be read back, this would be the most sensible thing to do. Cheers Detlev -- Helena ist verhältnismäßig leicht zu besetzen. Eine Frau, zarteste Jugend mit sinnlicher Reife verbindend; äußerst intelligent, indes von durchaus weiblicher Denkart; phlegmatisch, aber sensibel; unübertrefflich schön und dabei von sehr persönlichem Charme - mehr wird da nicht verlangt. -- Peter Hacks -- 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] [RFC PATCH 1/4] Adapt config.mk for usage in spl/Makefile
Hi Daniel, On Tuesday 05 July 2011 09:56 PM, Daniel Schwierzeck wrote: > [ane...@ti.com: > 1. Changed the definition of OBJTREE and the way 'obj' is defined. > 2. Defined a flag to identify regular U-Boot build > 3. Taking care of autoconf.mk etc for SPL due to changed OBJTREE > ] > > [daniel.schwierz...@googlemail.com: > 1. reverted changes on implicite make rules > 2. readded definition of -DCONFIG_UBOOT_SPL_BUILD in CPPFLAGS > ] > > Signed-off-by: Aneesh V > Signed-off-by: Daniel Schwierzeck > --- > config.mk | 28 > 1 files changed, 28 insertions(+), 0 deletions(-) > > diff --git a/config.mk b/config.mk > index 2eb7fa2..a16e761 100644 > --- a/config.mk > +++ b/config.mk > @@ -116,8 +116,14 @@ RANLIB = $(CROSS_COMPILE)RANLIB > # > > # Load generated board configuration > +ifdef CONFIG_UBOOT_SPL_BUILD > +# OBJTREE points to /spl/obj inside the original OBJTREE for SPL > +sinclude $(OBJTREE)/../../include/autoconf.mk > +sinclude $(OBJTREE)/../../include/config.mk > +else > sinclude $(OBJTREE)/include/autoconf.mk > sinclude $(OBJTREE)/include/config.mk > +endif > > # Some architecture config.mk files need to know what CPUDIR is set to, > # so calculate CPUDIR before including ARCH/SOC/CPU config.mk files. > @@ -164,13 +170,30 @@ ifneq ($(CONFIG_SYS_TEXT_BASE),) > CPPFLAGS += -DCONFIG_SYS_TEXT_BASE=$(CONFIG_SYS_TEXT_BASE) > endif > > +ifneq ($(CONFIG_SPL_TEXT_BASE),) Is 'ifdef' more readable? > +CPPFLAGS += -DCONFIG_SPL_TEXT_BASE=$(CONFIG_SPL_TEXT_BASE) > +endif > + > +# Allow compiling of C and ASM code parts in different way. > +# Serves also as a replacement for CONFIG_PRELOADER. > +ifneq ($(CONFIG_UBOOT_SPL_BUILD),) > +CPPFLAGS += -DCONFIG_UBOOT_SPL_BUILD > +endif I think we need to consolidate the CONFIG flags. There are quite a few in use already. CONFIG_PRELOADER CONFIG_ONENAND_IPL CONFIG_NAND_SPL I wonder if CONFIG_ONENAND_IPL and CONFIG_NAND_SPL are used today to distinguish the respective boots specifically or whether they could be replaced by CONFIG_PRELOADER. BTW, why do you want to replace CONFIG_PRELOADER with a new flag? > + > +CONFIG_NORMAL_UBOOT = $(if $(CONFIG_UBOOT_SPL_BUILD),,y) > + > ifneq ($(RESET_VECTOR_ADDRESS),) > CPPFLAGS += -DRESET_VECTOR_ADDRESS=$(RESET_VECTOR_ADDRESS) > endif > [snip..] > +LDFLAGS_u-boot-spl += -T $(obj)u-boot-spl.lds $(LDFLAGS_FINAL) > +ifneq ($(CONFIG_SPL_TEXT_BASE),) > +LDFLAGS_u-boot-spl += -Ttext $(CONFIG_SPL_TEXT_BASE) > +endif > + Do we need this here or can this be in spl/Makefile ? best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Armada100: MFP macro naming correction
> -Original Message- > From: Ajay Bhargav [mailto:ajay.bhar...@einfochips.com] > Sent: Wednesday, July 06, 2011 12:09 PM > To: Prafulla Wadaskar > Cc: u-boot@lists.denx.de; Ajay Bhargav > Subject: [PATCH 1/2] Armada100: MFP macro naming correction > > MFP macros for UART3 updated. > > Signed-off-by: Ajay Bhargav > --- > arch/arm/include/asm/arch-armada100/mfp.h |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/include/asm/arch-armada100/mfp.h > b/arch/arm/include/asm/arch-armada100/mfp.h > index 73783a7..d6e0494 100644 > --- a/arch/arm/include/asm/arch-armada100/mfp.h > +++ b/arch/arm/include/asm/arch-armada100/mfp.h > @@ -57,8 +57,8 @@ > #define MFP89_UART2_TXD (MFP_REG(0x0164) | MFP_AF2 | > MFP_DRIVE_MEDIUM) > > /* UART3 */ > -#define MFPO8_UART3_RXD (MFP_REG(0x06c) | MFP_AF2 | > MFP_DRIVE_MEDIUM) > -#define MFPO9_UART3_TXD (MFP_REG(0x070) | MFP_AF2 | > MFP_DRIVE_MEDIUM) > +#define MFPO8_UART3_TXD (MFP_REG(0x06c) | MFP_AF2 | > MFP_DRIVE_MEDIUM) > +#define MFPO9_UART3_RXD (MFP_REG(0x070) | MFP_AF2 | > MFP_DRIVE_MEDIUM) > > /* I2c */ > #define MFP105_CI2C_SDA (MFP_REG(0x1a4) | MFP_AF1 | > MFP_DRIVE_MEDIUM) > -- Acked-By: Prafulla Wadaskar Regards.. Prafulla . . > 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Armada100: Add Board Support for Marvell GuruPlug-Display
> -Original Message- > From: Ajay Bhargav [mailto:ajay.bhar...@einfochips.com] > Sent: Wednesday, July 06, 2011 12:09 PM > To: Prafulla Wadaskar > Cc: u-boot@lists.denx.de; Ajay Bhargav > Subject: [PATCH 2/2] Armada100: Add Board Support for Marvell GuruPlug- > Display > > This patch adds basic board support with DRAM and UART functionality > > v2 - Updated MAINTAINERS file as suggested by Prafulla. > > Signed-off-by: Ajay Bhargav > Acked-by: Tanmay Upadhyay > --- > MAINTAINERS |4 ++ > MAKEALL |1 + > board/Marvell/gplugd/Makefile | 57 +++ > board/Marvell/gplugd/gplugd.c | 62 + > boards.cfg|1 + > include/configs/gplugd.h | 87 > + > 6 files changed, 212 insertions(+), 0 deletions(-) > create mode 100644 board/Marvell/gplugd/Makefile > create mode 100644 board/Marvell/gplugd/gplugd.c > create mode 100644 include/configs/gplugd.h Acked-By: Prafulla Wadaskar Regards.. Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Adds saving of Kernel boot args to NAND flash
Hi, thanks for your feedback! I will address the style problems - didn't run checkpatch for the RFC - sorry my fault. > Why are you writing to NAND as part of bootm? > > If you just want access to the results of the FDT/ATAG preparation that > bootm does, consider using the bootm subcommands to prepare them, then > normal U-Boot commands to write to NAND. Hm thats a point. I see this as a feature as it saves new settings without the need of special commands - you start the same configuration either with u-boot or the SPL. But you are right - an extra command would also be nice. I will add this. Regards Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mxc_nand: fixed some typos (cosmetic)
From: Helmut Raiger
Signed-off-by: Helmut Raiger
---
drivers/mtd/nand/mxc_nand.c | 19 +--
1 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/mtd/nand/mxc_nand.c b/drivers/mtd/nand/mxc_nand.c
index 2a8dd7e..78e07cc 100644
--- a/drivers/mtd/nand/mxc_nand.c
+++ b/drivers/mtd/nand/mxc_nand.c
@@ -350,7 +350,7 @@ static void send_addr(struct mxc_nand_host *host, uint16_t
addr)
}
/*
- * This function requests the NANDFC to initate the transfer
+ * This function requests the NANDFC to initiate the transfer
* of data currently in the NANDFC RAM buffer to the NAND device.
*/
static void send_prog_page(struct mxc_nand_host *host, uint8_t buf_id,
@@ -394,7 +394,7 @@ static void send_prog_page(struct mxc_nand_host *host,
uint8_t buf_id,
}
/*
- * Requests NANDFC to initated the transfer of data from the
+ * Requests NANDFC to initiate the transfer of data from the
* NAND device into in the NANDFC ram buffer.
*/
static void send_read_page(struct mxc_nand_host *host, uint8_t buf_id,
@@ -637,7 +637,7 @@ static int mxc_nand_read_page_syndrome(struct mtd_info *mtd,
MTDDEBUG(MTD_DEBUG_LEVEL1, "Reading page %u to buf %p oob %p\n",
host->page_addr, buf, oob);
- /* first read out the data area and the available portion of OOB */
+ /* first read the data area and the available portion of OOB */
for (n = 0; eccsteps; n++, eccsteps--, p += eccsize) {
int stat;
@@ -1179,7 +1179,7 @@ void mxc_nand_command(struct mtd_info *mtd, unsigned
command,
/*
* before sending SEQIN command for partial write,
* we need read one page out. FSL NFC does not support
-* partial write. It alway send out 512+ecc+512+ecc ...
+* partial write. It always sends out 512+ecc+512+ecc
* for large page nand flash. But for small page nand
* flash, it does support SPARE ONLY operation.
*/
@@ -1209,7 +1209,7 @@ void mxc_nand_command(struct mtd_info *mtd, unsigned
command,
send_prog_page(host, 0, host->spare_only);
if (host->pagesize_2k && !is_mxc_nfc_11()) {
- /* data in 4 areas datas */
+ /* data in 4 areas */
send_prog_page(host, 1, host->spare_only);
send_prog_page(host, 2, host->spare_only);
send_prog_page(host, 3, host->spare_only);
@@ -1225,10 +1225,9 @@ void mxc_nand_command(struct mtd_info *mtd, unsigned
command,
if (column != -1) {
/*
* MXC NANDFC can only perform full page+spare or
-* spare-only read/write. When the upper layers
-* layers perform a read/write buf operation,
-* we will used the saved column adress to index into
-* the full page.
+* spare-only read/write. When the upper layers perform
+* a read/write buffer operation, we will use the saved
+* column address to index into the full page.
*/
send_addr(host, 0);
if (host->pagesize_2k)
@@ -1377,7 +1376,7 @@ int board_nand_init(struct nand_chip *this)
/* Unlock Block Command for given address range */
writew(0x4, &host->regs->nfc_wrprot);
- /* NAND bus width determines access funtions used by upper layer */
+ /* NAND bus width determines access functions used by upper layer */
if (is_16bit_nand())
this->options |= NAND_BUSWIDTH_16;
--
1.7.4.4
--
Scanned by MailScanner.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] net/eth.c: make eth_get_dev_by_name(NULL) safe
On 07/05/2011 05:44 AM, Mike Frysinger wrote:
> On Monday, July 04, 2011 06:29:51 helmut.rai...@hale.at wrote:
>> eth_get_dev_by_name() is not safe to use for devname being NULL
>> as it uses strcmp. This patch makes it return NULL if devname NULL
>> is passed.
> i'm not sure about this. passing NULL is wrong, and the caller should catch
> that shouldnt it ?
> -mike
So what is your suggestion how to deal with it?
It returns:
"There is no ethernet device with name NULL"
This is pretty much the only thing it can return. The user of the
function may handle this situation individually like:
printf("ethernet device '%s' not found\n, devname);
--> "ethernet device '(NULL)' not found".
A panic on a NULL pointer de-reference is probably not helpful either.
Helmut
--
Scanned by MailScanner.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
