[U-Boot] [PATCH v3 1/3] net: Adds Fast Ethernet Controller driver for Armada100

[Ajay Bhargav]

This patch adds support for Fast Ethernet Controller driver for
Armada100 series.

Signed-off-by: Ajay Bhargav 
---
Changes for v2:
- removed random MAC generation
- driver init function changed to register as per new naming convention
- code cleanup (Thanks to Wolfgang, Marek & Mike for tips)
Changes for v3:
- code cleanup

 arch/arm/include/asm/arch-armada100/armada100.h |1 +
 drivers/net/Makefile|1 +
 drivers/net/armada100_fec.c |  759 +++
 drivers/net/armada100_fec.h |  232 +++
 include/netdev.h|1 +
 5 files changed, 994 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/armada100_fec.c
 create mode 100644 drivers/net/armada100_fec.h

diff --git a/arch/arm/include/asm/arch-armada100/armada100.h 
b/arch/arm/include/asm/arch-armada100/armada100.h
index d5d125a..3d567eb 100644
--- a/arch/arm/include/asm/arch-armada100/armada100.h
+++ b/arch/arm/include/asm/arch-armada100/armada100.h
@@ -59,6 +59,7 @@
 #define ARMD1_MPMU_BASE0xD405
 #define ARMD1_APMU_BASE0xD4282800
 #define ARMD1_CPU_BASE 0xD4282C00
+#define ARMD1_FEC_BASE 0xC080
 
 /*
  * Main Power Management (MPMU) Registers
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 819b197..34b4322 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -28,6 +28,7 @@ LIB   := $(obj)libnet.o
 COBJS-$(CONFIG_DRIVER_3C589) += 3c589.o
 COBJS-$(CONFIG_PPC4xx_EMAC) += 4xx_enet.o
 COBJS-$(CONFIG_ALTERA_TSE) += altera_tse.o
+COBJS-$(CONFIG_ARMADA100_FEC) += armada100_fec.o
 COBJS-$(CONFIG_DRIVER_AT91EMAC) += at91_emac.o
 COBJS-$(CONFIG_DRIVER_AX88180) += ax88180.o
 COBJS-$(CONFIG_BCM570x) += bcm570x.o
diff --git a/drivers/net/armada100_fec.c b/drivers/net/armada100_fec.c
new file mode 100644
index 000..9362fe1
--- /dev/null
+++ b/drivers/net/armada100_fec.c
@@ -0,0 +1,759 @@
+/*
+ * (C) Copyright 2011
+ * eInfochips Ltd. 
+ * Written-by: Ajay Bhargav 
+ *
+ * (C) Copyright 2010
+ * Marvell Semiconductor 
+ * Contributor: Mahavir Jain 
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "armada100_fec.h"
+
+#define  PHY_ADR_REQ 0xFF  /* Magic number to read/write PHY address */
+
+#ifdef DEBUG
+static int eth_dump_regs(struct eth_device *dev)
+{
+   struct armdfec_device *darmdfec = to_darmdfec(dev);
+   struct armdfec_reg *regs = darmdfec->regs;
+   unsigned int i = 0;
+
+   printf("\noffset: phy_adr, value: 0x%x\n", readl(®s->phyadr));
+   printf("offset: smi, value: 0x%x\n", readl(®s->smi));
+   for (i = 0x400; i <= 0x4e4; i += 4)
+   printf("offset: 0x%x, value: 0x%x\n",
+   i, readl(ARMD1_FEC_BASE + i));
+   return 0;
+}
+#endif
+
+static int armdfec_phy_timeout(u32 *reg, u32 flag, int cond)
+{
+   u32 timeout = PHY_WAIT_ITERATIONS;
+   u32 reg_val;
+
+   while (--timeout) {
+   reg_val = readl(reg);
+   if (cond && (reg_val & flag))
+   break;
+   else if (!cond && !(reg_val & flag))
+   break;
+   udelay(PHY_WAIT_MICRO_SECONDS);
+   }
+   return !timeout;
+}
+
+static int smi_reg_read(const char *devname, u8 phy_addr, u8 phy_reg,
+   u16 *value)
+{
+   struct eth_device *dev = eth_get_dev_by_name(devname);
+   struct armdfec_device *darmdfec = to_darmdfec(dev);
+   struct armdfec_reg *regs = darmdfec->regs;
+   u32 val, reg_data;
+
+   if (phy_addr == PHY_ADR_REQ && phy_reg == PHY_ADR_REQ) {
+   reg_data = readl(®s->phyadr);
+   *value = (u16) (reg_data & 0x1f);
+   return 0;
+   }
+
+   /* check parameters */
+   if (phy_addr > PHY_MASK) {
+   printf("Err..(%s) Invalid phy address: 0x%X\n",
+   __func__, phy_addr);
+   return -EINVAL;
+   }
+   if (phy_reg > PHY_MASK) {
+   printf("Err..(%s) In

[U-Boot] [PATCH v3 2/3] Armada100: Enable Ethernet support for GplugD

[Ajay Bhargav]

This patch enables ethernet support for Marvell GplugD board. Network
related commands works.

Signed-off-by: Ajay Bhargav 
---
Changes for v2:
- armada100_fec_initialize changed to armada100_fec_register
Changes for v3:
- fec base address as argument to armada100_fec_register

 arch/arm/include/asm/arch-armada100/armada100.h |   57 +++
 arch/arm/include/asm/arch-armada100/mfp.h   |   19 
 board/Marvell/gplugd/gplugd.c   |   39 +++
 include/configs/gplugd.h|   19 +++-
 4 files changed, 132 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/arch-armada100/armada100.h 
b/arch/arm/include/asm/arch-armada100/armada100.h
index 3d567eb..849638d 100644
--- a/arch/arm/include/asm/arch-armada100/armada100.h
+++ b/arch/arm/include/asm/arch-armada100/armada100.h
@@ -41,6 +41,10 @@
 /* Functional Clock Selection Mask */
 #define APBC_FNCLKSEL(x)(((x) & 0xf) << 4)
 
+/* Fast Ethernet Controller Clock register definition */
+#define FE_CLK_RST 0x1
+#define FE_CLK_ENA 0x8
+
 /* Register Base Addresses */
 #define ARMD1_DRAM_BASE0xB000
 #define ARMD1_TIMER_BASE   0xD4014000
@@ -85,6 +89,59 @@ struct armd1mpmu_registers {
 };
 
 /*
+ * Application Subsystem Power Management
+ * Refer Datasheet Appendix A.9
+ */
+struct armd1apmu_registers {
+   u32 pcr;/* 0x000 */
+   u32 ccr;/* 0x004 */
+   u32 pad1;
+   u32 ccsr;   /* 0x00C */
+   u32 fc_timer;   /* 0x010 */
+   u32 pad2;
+   u32 ideal_cfg;  /* 0x018 */
+   u8 pad3[0x04C - 0x018 - 4];
+   u32 lcdcrc; /* 0x04C */
+   u32 cciccrc;/* 0x050 */
+   u32 sd1crc; /* 0x054 */
+   u32 sd2crc; /* 0x058 */
+   u32 usbcrc; /* 0x05C */
+   u32 nfccrc; /* 0x060 */
+   u32 dmacrc; /* 0x064 */
+   u32 pad4;
+   u32 buscrc; /* 0x06C */
+   u8 pad5[0x07C - 0x06C - 4];
+   u32 wake_clr;   /* 0x07C */
+   u8 pad6[0x090 - 0x07C - 4];
+   u32 core_status;/* 0x090 */
+   u32 rfsc;   /* 0x094 */
+   u32 imr;/* 0x098 */
+   u32 irwc;   /* 0x09C */
+   u32 isr;/* 0x0A0 */
+   u8 pad7[0x0B0 - 0x0A0 - 4];
+   u32 mhst;   /* 0x0B0 */
+   u32 msr;/* 0x0B4 */
+   u8 pad8[0x0C0 - 0x0B4 - 4];
+   u32 msst;   /* 0x0C0 */
+   u32 pllss;  /* 0x0C4 */
+   u32 smb;/* 0x0C8 */
+   u32 gccrc;  /* 0x0CC */
+   u8 pad9[0x0D4 - 0x0CC - 4];
+   u32 smccrc; /* 0x0D4 */
+   u32 pad10;
+   u32 xdcrc;  /* 0x0DC */
+   u32 sd3crc; /* 0x0E0 */
+   u32 sd4crc; /* 0x0E4 */
+   u8 pad11[0x0F0 - 0x0E4 - 4];
+   u32 cfcrc;  /* 0x0F0 */
+   u32 mspcrc; /* 0x0F4 */
+   u32 cmucrc; /* 0x0F8 */
+   u32 fecrc;  /* 0x0FC */
+   u32 pciecrc;/* 0x100 */
+   u32 epdcrc; /* 0x104 */
+};
+
+/*
  * APB1 Clock Reset/Control Registers
  * Refer Datasheet Appendix A.10
  */
diff --git a/arch/arm/include/asm/arch-armada100/mfp.h 
b/arch/arm/include/asm/arch-armada100/mfp.h
index d6e0494..da76b58 100644
--- a/arch/arm/include/asm/arch-armada100/mfp.h
+++ b/arch/arm/include/asm/arch-armada100/mfp.h
@@ -64,6 +64,25 @@
 #define MFP105_CI2C_SDA(MFP_REG(0x1a4) | MFP_AF1 | 
MFP_DRIVE_MEDIUM)
 #define MFP106_CI2C_SCL(MFP_REG(0x1a8) | MFP_AF1 | 
MFP_DRIVE_MEDIUM)
 
+/* Fast Ethernet */
+#define MFP086_ETH_TXCLK   (MFP_REG(0x158) | MFP_AF5 | MFP_DRIVE_MEDIUM)
+#define MFP087_ETH_TXEN(MFP_REG(0x15C) | MFP_AF5 | 
MFP_DRIVE_MEDIUM)
+#define MFP088_ETH_TXDQ3   (MFP_REG(0x160) | MFP_AF5 | MFP_DRIVE_MEDIUM)
+#define MFP089_ETH_TXDQ2   (MFP_REG(0x164) | MFP_AF5 | MFP_DRIVE_MEDIUM)
+#define MFP090_ETH_TXDQ1   (MFP_REG(0x168) | MFP_AF5 | MFP_DRIVE_MEDIUM)
+#define MFP091_ETH_TXDQ0   (MFP_REG(0x16C) | MFP_AF5 | MFP_DRIVE_MEDIUM)
+#define MFP092_ETH_CRS (MFP_REG(0x170) | MFP_AF5 | MFP_DRIVE_MEDIUM)
+#define MFP093_ETH_COL (MFP_REG(0x174) | MFP_AF5 | MFP_DRIVE_MEDIUM)
+#define MFP094_ETH_RXCLK   (MFP_REG(0x178) | MFP_AF5 | MFP_DRIVE_MEDIUM)
+#define MFP095_ETH_RXER(MFP_REG(0x17C) | MFP_AF5 | 
MFP_DRIVE_MEDIUM)
+#define MFP096_ETH_RXDQ3   (MFP_REG(0x180) | MFP_AF5 | MFP_DRIVE_MEDIUM)
+#define MFP097_ETH_RXDQ2   (MFP_REG(0x184) | MFP_AF5 | MFP_DRIVE_MEDIUM)
+#define MFP098_ETH_RXDQ1   (MFP_REG(0x188) | MFP_AF5 | MFP_DRIVE_MEDIUM)
+#define MFP099_ETH_RXDQ0   (MFP_REG(0x18C) | MFP_AF5 | MFP_DRIVE_MEDIUM)
+#define MFP100_ETH_MDC (MFP_REG(0x190) | MFP_AF5 | MFP_DRIVE_MEDIU

[U-Boot] [PATCH v3 3/3] Armada100: Enable 88E3015 PHY support for GplugD

[Ajay Bhargav]

This patch adds support for 88E3015 PHY for Marvell GplugD board.
This patch depends on series of patch which adds support for Marvell
GuruPlug-Display.

Signed-off-by: Ajay Bhargav 
---
Changes for v2:
- Not changed
Changes for v3:
- code cleanup; removed unwated cast

 board/Marvell/gplugd/gplugd.c |   33 -
 include/configs/gplugd.h  |   14 ++
 2 files changed, 46 insertions(+), 1 deletions(-)

diff --git a/board/Marvell/gplugd/gplugd.c b/board/Marvell/gplugd/gplugd.c
index db4d776..a7cabcd 100644
--- a/board/Marvell/gplugd/gplugd.c
+++ b/board/Marvell/gplugd/gplugd.c
@@ -32,6 +32,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #ifdef CONFIG_ARMADA100_FEC
 #include 
@@ -83,6 +85,11 @@ int board_init(void)
gd->bd->bi_arch_number = MACH_TYPE_SHEEVAD;
/* adress of boot parameters */
gd->bd->bi_boot_params = armd1_sdram_base(0) + 0x100;
+   /* Assert PHY_RST# */
+   gpio_direction_output(CONFIG_SYS_GPIO_PHY_RST, GPIO_LOW);
+   udelay(10);
+   /* Deassert PHY_RST# */
+   gpio_set_value(CONFIG_SYS_GPIO_PHY_RST, GPIO_HIGH);
return 0;
 }
 
@@ -97,5 +104,29 @@ int board_eth_init(bd_t *bis)
 
return armada100_fec_register(ARMD1_FEC_BASE);
 }
-#endif /* CONFIG_ARMADA100_FEC */
+#ifdef CONFIG_RESET_PHY_R
+/* Configure and initialize PHY chip 88E3015 */
+void reset_phy(void)
+{
+   u16 phy_adr;
+   const char *name = "armd-fec0";
+
+   if (miiphy_set_current_dev(name))
+   return;
+
+   /* command to read PHY dev address */
+   if (miiphy_read(name, 0xff, 0xff, (u16 *) &phy_adr)) {
+   printf("Err..%s could not read PHY dev address\n", __func__);
+   return;
+   }
 
+   /* Set Ethernet LED in TX blink mode */
+   miiphy_write(name, phy_adr, PHY_LED_MAN_REG, 0x00);
+   miiphy_write(name, phy_adr, PHY_LED_PAR_SEL_REG, PHY_LED_VAL);
+
+   /* reset the phy */
+   miiphy_reset(name, phy_adr);
+   debug("88E3015 Initialized on %s\n", name);
+}
+#endif /* CONFIG_RESET_PHY_R */
+#endif /* CONFIG_ARMADA100_FEC */
diff --git a/include/configs/gplugd.h b/include/configs/gplugd.h
index f3b94d8..b63ffd5 100644
--- a/include/configs/gplugd.h
+++ b/include/configs/gplugd.h
@@ -80,6 +80,20 @@
 #define CONFIG_ROOTPATH"/tftpboot"
 #define CONFIG_SYS_IMG_NAME"uImage"
 
+/* GPIO Support */
+#define CONFIG_MARVELL_GPIO
+
+/* PHY configuration */
+#define CONFIG_MII
+#define CONFIG_CMD_MII
+#define CONFIG_RESET_PHY_R
+/* 88E3015 register definition */
+#define PHY_LED_PAR_SEL_REG22
+#define PHY_LED_MAN_REG25
+#define PHY_LED_VAL0x5b/* LINK LED1, ACT LED2 */
+/* GPIO Configuration for PHY */
+#define CONFIG_SYS_GPIO_PHY_RST104 /* GPIO104 */
+
 /*
  * mv-common.h should be defined after CMD configs since it used them
  * to enable certain macros
-- 
1.7.0.4

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

Re: [U-Boot] mii_phy.h

[Wolfgang Denk]

Dear Michal Simek,

In message <4e573aee.2060...@monstr.eu> you wrote:
>
> Who is responsible for ep8260 and rpxsuper boards?
> 
> For ep8260: I cc'ed Frank Panno but his email address doesn't work.

I guess it's safe to assume these boards are orphaned / unmaintained.

Shall we remove them?

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
If only God would give me some clear sign! Like making a large  depo-
sit in my name at a Swiss Bank. - Woody Allen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] mii_phy.h

[Michal Simek]

Mike Frysinger wrote:
> On Thursday, August 25, 2011 03:25:32 Michal Simek wrote:
>> Can someone clear me purpose of mii_phy.h? It looks like that it is really
>> ancient file which hasn't been touched from 2003.
>>
>> It is use for two files
>> [monstr@monstr u-boot]$ grep -rn "mii_phy.h" *
>> board/ep8260/mii_phy.c:2:#include 
>> board/rpxsuper/mii_phy.c:2:#include 
> 
> yes, if you look at old files, you often see people using generic names when 
> they should have been driver or arch specific, or people who thought about 
> starting a framework but then nothing ever materialized.
> 
>> The best will be to remove mii_phy entirely.
> 
> sounds good to me ... i imagine the existing functionality might need to be 
> converted into one of the common net frameworks that has been adopted ?

Who is responsible for ep8260 and rpxsuper boards?

For ep8260: I cc'ed Frank Panno but his email address doesn't work.

Thanks,
Michal


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

Re: [U-Boot] [PATCH] ppc460: read get_sys_info from CPR registers instead of STRP registers

[Stefan Roese]

Marri, Mike

On Thursday 25 August 2011 20:05:15 Tirumala Marri wrote:
> >make[1]: *** [speed.o] Error 1
> >make[1]: *** Waiting for unfinished jobs
> >make: *** [arch/powerpc/cpu/ppc4xx/libppc4xx.o] Error 2
> >make: *** Waiting for unfinished jobs
> >
> >Could you please check, if the 460SX has the same registers and bits as
> >460EX/GT and extend its header as well?
> 
> [marri] 460Ex/Gt and 460Sx has different clocking subsystems. This code
> will
>  Have to split to support to read the speed settings from CPU registers.
> 
>  If you can include the change to split this function we will submit our
> patch
> Based on yours. Please suggest.

Yes. Mike, could you please re-send your patch with this suggested split?

Marri, could you please test this result on an 460SX board? And perhaps send 
send a patch to fix potentially remaining 460SX issues?

Thanks.

Best regards,
Stefan

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

Re: [U-Boot] [PATCH v2 1/3] net: Adds Fast Ethernet Controller driver for Armada100

[Ajay Bhargav]

- "Mike Frysinger"  wrote:

> On Thursday, August 25, 2011 01:10:30 Ajay Bhargav wrote:
> > - "Mike Frysinger"  wrote:
> > > On Wednesday, August 24, 2011 09:07:18 Ajay Bhargav wrote:
> > > > +   /* Read mac from env if available */
> > > > +   eth_getenv_enetaddr("ethaddr", dev->enetaddr);
> > > 
> > > you shouldnt need to do this.  the higher layers will take care
> of
> > > this for
> > > you when you set write_hwaddr
> > 
> > I do not have a hardware storage for MAC on my controller.
> write_hwaddr
> > is not needed for me.
> 
> ok, but you should not be touching dev->enetaddr in your registration
> 
> function.  the main net/eth.c:eth_initialize() takes care of this for
> you.
> 
> > > > +int armada100_fec_initialize()
> > > > +{
> > > > ...
> > > > + darmdfec->regs = (void *) ARMD1_FEC_BASE;
> > > 
> > > make the reg base a parameter to armada100_fec_initialize()
> > 
> > This driver is for Armada100 series and base address is same for
> > the whole series, so i did not feel passing it as a parameter. Can
> > you please tell me if there is any specific reason for the same?
> 
> drivers should be written for the IP they control, not for specific
> SoCs or 
> boards.  and what people often start off with "this SoC only has one
> MAC so 
> screw multi-instance" quite frequently turns into "this next SoC
> supports 
> multiple MACs!".
> 
> i'm not familiar with the Armada100, or the MAC IP that is in that
> SoC, but 
> this story repeats itself constantly in the SoC world because people
> focus on 
> the one specific SoC they have in their hand and not the bigger
> picture.  
> simply witness the ARM hell that Linux is currently in and is being
> cleaned up 
> through the Linaro organization.
> -mike

Hi Mike,

I got your point.. Thanks for clearing this. I will make sure that this
kind of problem does not happen in my case :)

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

Re: [U-Boot] RFC: Testing U-Boot Part 1

[Graeme Russ]

Hi Simon,

On Fri, Aug 26, 2011 at 1:32 PM, Simon Glass  wrote:
> Hi,
>
> Thanks all for comments. It sounds like people are keen on the idea so
> far as it goes. I will work on a patch set complete enough to bring up
> a U-Boot prompt, allowing typing of 'help' and with a special segfault
> feature for anything else.
>
> Before I do this, and to avoid me redoing work later:
>
> 1. What should I call the architecture? I have so far called it 'native'.

sandbox

>
> 2. What should I call the vendor (board/xxx)? 'test' or 'sandbox'?

sandbox

>
> 3. What should I call the board? Is that 'sandbox'?

sandbox

>
> 4. When I create a driver, like the serial test driver, should that be
> serial_test.c, test_serial.c, sandbox_serial or something else?

I guess you'll have /drivers/serial/sandbox.c, /drivers/net/sandbox.c
etc.

/include/configs/sandbox.h will need to include defaults for how
these devices are configured. For example, you may want to have
the sandbox serial go to /dev/ttyS0 or /dev/ttyS1

Make sure that printf() goes through U-Boot printf() not the host's libc

And have you dealt with putc() and getc() hooking so that the U-Boot
stdio can go to either the hosts stdio or a serial port?


> 5. I need an arch/xxx/lib/board.c. Rather than try to create a new
> minimal one, I think I should copy an existing one and change it as
> little as possible (in the light of Graeme's comments and to avoid yet
> another version of this file). Thoughts?

Make this board an example of a New World Order ;) - Seriously, take
arch/x86/lib/board.c as it has arrays for both init_f and init_r.
If you look at board_init_f it has very little other than the loop. But
board_init_r is a mess - It starts out as a loop and finished being a
sequence of function calls. Implement board_init_r so it consists of
only a processing loop - Debatable as to whether or not to but the
while(1) { main_loop;} as a final 'init' function or whether to have
this after the init loop is processed

I imagine that sandbox will have no _f init functions as there will
be no relocation anyway. Still, put in board_init_f but have an
empty sequence.

[snip]

> Wolfgang Denk: I'm not sure what you mean by "a mocked remote host".
> We should be
> able to send and receive packets from a real network interface as
> well.
>
> - I mean that the tftp command will 'obtain' a file when it asks for
> one, although the actual Ethernet layer is mocked and doesn't actually
> go out on the wire. Imagine an Ethernet driver which has a half-baked
> tftp server in it. Yes I also see value in actually using machine
> interfaces since the testing can be more thorough.

Yes, using a real interface (loopback even) would be good as you can then
also test that your host's tftp server is working

[snip]

Regards,

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

Re: [U-Boot] RFC: Testing U-Boot Part 1

[Simon Glass]

Hi,

Thanks all for comments. It sounds like people are keen on the idea so
far as it goes. I will work on a patch set complete enough to bring up
a U-Boot prompt, allowing typing of 'help' and with a special segfault
feature for anything else.

Before I do this, and to avoid me redoing work later:

1. What should I call the architecture? I have so far called it 'native'.

2. What should I call the vendor (board/xxx)? 'test' or 'sandbox'?

3. What should I call the board? Is that 'sandbox'?

4. When I create a driver, like the serial test driver, should that be
serial_test.c, test_serial.c, sandbox_serial or something else?

5. I need an arch/xxx/lib/board.c. Rather than try to create a new
minimal one, I think I should copy an existing one and change it as
little as possible (in the light of Graeme's comments and to avoid yet
another version of this file). Thoughts?

Regarding the actual test framework, I think this can come later.
Clearly we can do unit tests at the file level, or more
integration-like tests such as I listed in my email. But I know very
little about Ruby (little girl up the road?)

Summary of suggestions so that I don't flood this thread with replies:

Andreas Bießmann: why don't use some unit testing framework like
cunit, or ceedling (which
can do HW mocks easily)?

- the test framework is TBD - as Mike commented this is something else
- another level that can be piled on later.

Marek Vasut: sounds just awesome. I was planning on doing a similar
thing, but "from the
other side". I'm sure you're aware of the POST test framework. I was planning to
either extend it or write new self-standing implementation that'd allow debuging
platform-dependent drivers.

- sounds great to me - perhaps we could have a standard test for SPI
flash, another for NAND, another for USB, etc.

Mike Frysinger: i certainly think it's a worthwhile exercise,
especially if it gets us to the
point where we can do `make check` and have confidence in our common code
changes not being completely f-ed up.

- that is my hope, particularly if 'make check' is fast.

Wolfgang Denk: In a later step it might even be possible to implement some "pass
through" mode to acces actual devices / drivers in some way.  Think of
using libusb to talk to USB devices.

- Yes - that would allow checking of more layers of the USB stack. But
I even see some value in just mocking out the whole USB stack and
providing a pretend USB memory stick as a block device..

Wolfgang Denk: I'm not sure what you mean by "a mocked remote host".
We should be
able to send and receive packets from a real network interface as
well.

- I mean that the tftp command will 'obtain' a file when it asks for
one, although the actual Ethernet layer is mocked and doesn't actually
go out on the wire. Imagine an Ethernet driver which has a half-baked
tftp server in it. Yes I also see value in actually using machine
interfaces since the testing can be more thorough.

Wolfgang Denk: Some parts of what you are looking for can be done by
running U-Boot
images in a QEMU based emulated envrionment.  So far we have only a
few targets in the tree that actually support this.  I wish we had
more of them.

...I am aware that this is a different thing from what you propose here,
but I would like to state that we should not forget this option -
anybody who wants to work in that area will be more than welcome, too.

-Yes, both are valuable. Maybe one day we will get a s/w model of an
SOC when it is released. For now, this sort of thing is quite a bit of
work. There are loads of automated ways to test things- ones I can
think of are:

1.  real hardware, with some sort of control board which can push
buttons, produce/access Ethernet/USB traffic, camera to watch the LCD,
LCD to driver the camera, etc.

2. test code which runs on real hardware either at the board level or
at the U-Boot command level. Requires a user to watch / driver things

3. test code which runs on faked hardware (this is what I am proposing
here). Basically the opposite of 2.

4. test code could run on real hardware, but is actually run on QEMU
etc., with special hooks in the simulator for injecting failure,
handling the other end of ethernet//USB, etc..A lot of work but really
cool.

5. unit tests for each file, where anything that it calls is mocked
and replaced with something which can inject failure, etc. We should
have more of this anyway. People often don't like writing it though
:-(

Graeme Russ: Indead - And I think it will serve as further impetus to
arch-neutralise
code outside /arch/

- Yes - let's hope so.

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

[U-Boot] (no subject)

[Ronny D]

http://www.locksplususa.com/images/vfst.htm";>http://www.locksplususa.com/images/vfst.htm___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] RFC: Testing U-Boot Part 1

[Graeme Russ]

Hi Simon, Mike

On Fri, Aug 26, 2011 at 1:01 AM, Mike Frysinger  wrote:
> On Thursday, August 25, 2011 08:58:00 Simon Glass wrote:
>> Proposal
>> 
>
> for people who might be familiar with the barebox boot loader, Simon is
> basically proposing the same thing as barebox's "sandbox" target.
>
> to avoid confusion/fragmentation in this area, and since the name is a large
> part bike shedding, i propose we adopt the same name that barebox has.  that
> way we can sanely use the same term when comparing/contrasting.
>

Yes, I agree that naming the target 'sandbox' is a good idea

>
>> Comments
>> 
>> At this early stage I am looking for comments on the concept - how
>> useful it is and how best to implement it.
>
> i certainly think it's a worthwhile exercise, especially if it gets us to the
> point where we can do `make check` and have confidence in our common code
> changes not being completely f-ed up.

Indead - And I think it will serve as further impetus to arch-neutralise
code outside /arch/

Regards,

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

[U-Boot] Why are have_console and env_valid not in gd->flags?

[Graeme Russ]

Does anyone know why have_console and env_valid are not part of gd->flags?
I know env_valid is tri-state, but it could still be put in flags as a
double-bit

Regards,

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

Re: [U-Boot] standalone application export eth_receive: undefined index

[Wolfgang Denk]

Dear Robin Theunis,

In message  
you wrote:
> 
> I have a little problem. I need to access the eth_receive function in
> my standalone application. The U-boot version is 1.3.3 (I know it is
> old but it is a requirement).

eth_receive is (intentionally) not an exported interface for
standalone applications.

> Is this a dummy problem? Or something else?

It's policy.  Keep in mind that standalone applications allow youto
create proprietary code.  We accept that this is sometimes needed or
evenuseful, so we provide a mechanism for it, on the other hand we
strongly discourage closed source software, so we intentionally
provide not too much of the U-Boot features to such code.

If you write Free Software, then just link it with the U-Boot image
(and distribut eit under GPL).  If you write proprietary software, then
please implement your own, proprietary network drivers and network
stack as well.

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
Time is a drug. Too much of it kills you.
  - Terry Pratchett, _Small Gods_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/7] powerpc/mpc83xx: Migrate from spd_sdram to unified DDR driver

[Wolfgang Denk]

Dear York Sun,

In message <1314308192.29220.29.camel@oslab-l1> you wrote:
> 
> I am introducing it to this file as it is already being used somewhere
> else. If you are trying to enforce this new policy, please start with
> brand new files/typedefs, as you pointed out in my another patch. I will
> be happy to fix that.

It is in no way a new policy that U-Boot uses the Linux CodingStyle as
model.  We've been doing this for years.  It's just that checkpatch
allows for more regular and more strict tests for violations.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
I believe you find life such a problem because you  think  there  are
the  good  people  and the bad people. You're wrong, of course. There
are, always and only, the bad people, but some of them are  on  oppo-
site sides.  - Terry Pratchett, _Guards! Guards!_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] RFC: Testing U-Boot Part 1

[Marek Vasut]

On Thursday, August 25, 2011 04:56:39 PM Mike Frysinger wrote:
> On Thursday, August 25, 2011 09:56:02 Andreas Bießmann wrote:
> > Am 25.08.2011 14:58, schrieb Simon Glass:
> > > Summary: I am quite keen on improving the test infrastructure in
> > > U-Boot. I would like to have a test suite that can run in a minute or
> > > two on a Linux PC and test all non-platform code.
> > 
> > 
> > 
> > > To get around this I propose that we create a new ‘native’
> > > architecture. We write code in ‘arch/native’ which can run under
> > > Linux. Since all the non-platform code will happily run under this new
> > > ‘architecture’, we can then write tests which run quickly under x86
> > > Linux (or another Linux for that matter). This U-Boot 'architecture'
> > > should build natively on any 32/64-bit Linux machine since it just
> > > uses standard Linux system calls. Calls to Linux would be entirely
> > > within this arch/native subdirectory.
> > 
> > why don't use some unit testing framework like cunit, or ceedling (which
> > can do HW mocks easily)?
> 
> these testing frameworks wont make any difference to what Simon is
> proposing. he is focusing on getting u-boot to build & run on your desktop
> machine. after that is done, we can talk about the actual tests and
> harnesses (although anything that requires ruby should immediately be
> disqualified imo :P). -mike

Definitelly agree with the RUBY part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] fw_env bug for multi-sector environments on NOR flash

[Fei, Yiyang]

Dear Mr. Denk,

> Stupid question: why do you define an environment size of 128 kB?
> I bet you use less than 10% of this, right?

Correct

> Are you aware that this has a lof of disadvantages, lile
> significantly slowing down your boot process?

I am now, but the first product is already released and cannot be
changed easily.

> Your Signed-off-by: line is missing...

I resubmitted updated message.

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

[U-Boot] [PATCH] NAND: Add nand read.raw and write.raw commands

[Marek Vasut]

These commands should work around various "hardware" ECC and BCH methods. This
is important for example in case where the user needs to write precisely what's
in a buffer to a NAND page, with no interference of hardware ECC engine or such.

Signed-off-by: Marek Vasut 
---
 common/cmd_nand.c |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/common/cmd_nand.c b/common/cmd_nand.c
index b767cd2..ca510ae 100644
--- a/common/cmd_nand.c
+++ b/common/cmd_nand.c
@@ -606,6 +606,20 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char * 
const argv[])
ret = nand->read_oob(nand, off, &ops);
else
ret = nand->write_oob(nand, off, &ops);
+   } else if (!strcmp(s, ".raw")) {
+   /* Raw access */
+   mtd_oob_ops_t ops = {
+   .datbuf = (u8 *)addr,
+   .oobbuf = ((u8 *)addr) + nand->writesize,
+   .len = nand->writesize,
+   .ooblen = nand->oobsize,
+   .mode = MTD_OOB_RAW
+   };
+
+   if (read)
+   ret = nand->read_oob(nand, off, &ops);
+   else
+   ret = nand->write_oob(nand, off, &ops);
} else {
printf("Unknown nand command suffix '%s'.\n", s);
return 1;
-- 
1.7.5.4

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

Re: [U-Boot] gcc-4.6 warnings

[Mike Frysinger]

On Thursday, August 25, 2011 17:44:58 Timur Tabi wrote:
> Mike Frysinger wrote:
> > if we let the optimizer do it instead of the preprocessor, we get better
> > code coverage in the face of different config settings.
> 
> Oh, I thought this was some new feature of U-Boot.
> 
> Can you give me an example of where DCE could be used to eliminate an
> #ifdef?

a change i talked about but havent yet posted would be to fix debug().  
currently it looks more or less like:
#ifdef DEBUG
# define debug(...) printf(...)
#else
# define debug(...)
#endif
this causes people to do things like put local variables only used with 
debug() code behind an #ifdef DEBUG in their code otherwise they get unused 
variable warnings.

if, instead, we did something like:
#ifdef DEBUG
# define __DEBUG_KNOB 1
#else
# define __DEBUG_KNOB 0
#endif
#define debug(...) do { if (__DEBUG_KNOB) printf(...); } while (0)

the code would always get compiled and checked, but gcc would throw away it at 
DCE time, and there would be no unused variable warnings.
-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] gcc-4.6 warnings

[Timur Tabi]

Timur Tabi wrote:
> Oh, I thought this was some new feature of U-Boot.
> 
I meant a new feature of gcc. Ugh.

-- 
Timur Tabi
Linux kernel developer at Freescale

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

Re: [U-Boot] gcc-4.6 warnings

[Timur Tabi]

Mike Frysinger wrote:
> if we let the optimizer do it instead of the preprocessor, we get better code 
> coverage in the face of different config settings.

Oh, I thought this was some new feature of U-Boot.

Can you give me an example of where DCE could be used to eliminate an #ifdef?

-- 
Timur Tabi
Linux kernel developer at Freescale

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

[U-Boot] standalone application export eth_receive: undefined index

[Robin Theunis]

Hi all

I have a little problem. I need to access the eth_receive function in
my standalone application. The U-boot version is 1.3.3 (I know it is
old but it is a requirement).
Also I have seen that I need to enable #define CONFIG_API but building
with this option fails. Current platfom is a AT91RM9200, 16MB sdram,
16MB flash.
If I comment out the switches in the net/eth.c net/net.c and
include/net.h. It could work. I exported also eth_send. This function
doesn't give me any problems when compiling the application.

Is this a dummy problem? Or something else?

Thanks

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

Re: [U-Boot] [PATCH 5/7] powerpc/mpc83xx: Migrate from spd_sdram to unified DDR driver

[York Sun]

Wolfgang,

On Thu, 2011-08-25 at 23:30 +0200, Wolfgang Denk wrote:
> Dear York Sun,
> 
> In message <1314307500.29220.24.camel@oslab-l1> you wrote:
> >
> > Fixing all existing reference to ccs_ddr is a lot of work, comparing
> > with defining it for 83xx. There are many other typedefs in the very
> > same files. Would we fix all of them? I don't think so. The bottom of
> 
> well, if you could fix all of these while you are at it that would be
> just great :-)

There are nearly 400 typedefs for powerpc and 52 for immap_85xx.h, not
mentioned when they are used by .c files. Too many to fix.

> 
> > line is ccsr_ddr is not a new typedef.
> 
> But you are adding it new to this file.

I am introducing it to this file as it is already being used somewhere
else. If you are trying to enforce this new policy, please start with
brand new files/typedefs, as you pointed out in my another patch. I will
be happy to fix that.

York


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

Re: [U-Boot] [PATCH 5/7] powerpc/mpc83xx: Migrate from spd_sdram to unified DDR driver

[Wolfgang Denk]

Dear York Sun,

In message <1314307500.29220.24.camel@oslab-l1> you wrote:
>
> Fixing all existing reference to ccs_ddr is a lot of work, comparing
> with defining it for 83xx. There are many other typedefs in the very
> same files. Would we fix all of them? I don't think so. The bottom of

well, if you could fix all of these while you are at it that would be
just great :-)

> line is ccsr_ddr is not a new typedef.

But you are adding it new to this file.

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
Few people do business well who do nothing else.
   -- Philip Earl of Chesterfield
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/7] powerpc/mpc83xx: Migrate from spd_sdram to unified DDR driver

[York Sun]

On Thu, 2011-08-25 at 23:20 +0200, Wolfgang Denk wrote:
> Dear York Sun,
> 
> In message <1314305821.29220.21.camel@oslab-l1> you wrote:
> > 
> > > WARNING: do not add new typedefs
> > > #408: FILE: arch/powerpc/include/asm/immap_83xx.h:289:
> > > +typedef struct ccsr_ddr {
> > > 
> > > Please fix.
> > 
> > I can fix the new tyepdef. But this one isn't. It has been used for a
> > long time by 85xx. I am trying to unified the code. It is inevitable to
> > define the same typedef for 83xx.
> 
> Is it?  I don't think so.  You can, for example, fix the 85xx code as
> well...

Fixing all existing reference to ccs_ddr is a lot of work, comparing
with defining it for 83xx. There are many other typedefs in the very
same files. Would we fix all of them? I don't think so. The bottom of
line is ccsr_ddr is not a new typedef.

York



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

Re: [U-Boot] [PATCH 5/7] powerpc/mpc83xx: Migrate from spd_sdram to unified DDR driver

[Wolfgang Denk]

Dear York Sun,

In message <1314305821.29220.21.camel@oslab-l1> you wrote:
> 
> > WARNING: do not add new typedefs
> > #408: FILE: arch/powerpc/include/asm/immap_83xx.h:289:
> > +typedef struct ccsr_ddr {
> > 
> > Please fix.
> 
> I can fix the new tyepdef. But this one isn't. It has been used for a
> long time by 85xx. I am trying to unified the code. It is inevitable to
> define the same typedef for 83xx.

Is it?  I don't think so.  You can, for example, fix the 85xx code as
well...

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
Our business is run on trust.  We trust you will pay in advance.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] RFC: Testing U-Boot Part 1

[Mike Frysinger]

On Thursday, August 25, 2011 16:21:51 Wolfgang Denk wrote:
> Simon Glass wrote:
> > For speed, debugging and convenience, it would be nice to run U-Boot
> > under a generic Linux environment on a workstation, and test all the
> > generic non-platform code. The basic problem with this is that the
> > non-platform code requires the platform code to operate. Even the x86
> > platform code is designed for standalone operation on a particular x86
> > board, and is not suitable for running under x86 Linux.
> 
> Some parts of what you are looking for can be done by running U-Boot
> images in a QEMU based emulated envrionment.  So far we have only a
> few targets in the tree that actually support this.  I wish we had
> more of them.
> 
> I am aware that this is a different thing from what you propose here,
> but I would like to state that we should not forget this option -
> anybody who wants to work in that area will be more than welcome, too.

i do a lot of testing using the GNU sim and Blackfin boards.  the goal there 
is that the GNU sim is able to execute all of the Blackfin builds 
*unmodified*, so i dont need sep configs.  as you say, both methods are very 
useful to have.
-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 5/7] powerpc/mpc83xx: Migrate from spd_sdram to unified DDR driver

[York Sun]

Wolfgang,

On Thu, 2011-08-25 at 00:36 +0200, Wolfgang Denk wrote:
> Dear York Sun,
> 
> In message <1312923045-2612-5-git-send-email-york...@freescale.com> you wrote:
> > Unified DDR driver is maintained for better performance, robustness and bug
> > fixes. Upgrading to use unified DDR driver for MPC83xx takes advantage of
> > overall improvement. It requires changes for board files to customize
> > platform-dependent parameters.
> > 
> > To utilize the unified DDR driver, a board needs to define CONFIG_FSL_DDRx
> > in the header file. No more boards will be accepted without such definition.
> > 
> > Note: the workaround for erratum DDR6 for the very old MPC834x Rev 1.0/1.1
> > and MPC8360 Rev 1.1/1.2 parts is not migrated to unified driver.
> > 
> > Signed-off-by: Kim Phillips 
> > Signed-off-by: York Sun 
> 
> Checkpatch says:
> 
> WARNING: do not add new typedefs
> #408: FILE: arch/powerpc/include/asm/immap_83xx.h:289:
> +typedef struct ccsr_ddr {
> 
> Please fix.
> 

I can fix the new tyepdef. But this one isn't. It has been used for a
long time by 85xx. I am trying to unified the code. It is inevitable to
define the same typedef for 83xx.

Regards,

York
 


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

Re: [U-Boot] fw_env bug for multi-sector environments on NOR flash

[Wolfgang Denk]

Dear "Fei, Yiyang",

In message  you 
wrote:
> 
> # MTD device name   Device offset   Env. size   Flash sector
> size   Number of sectors
> /dev/mtd12  0x  0x2 0x1
> 2

Stupid question: why do you define an environment size of 128 kB?
I bet you use less than 10% of this, right?

Are you aware that this has a lof of disadvantages, lile
significantly slowing down your boot process?


> The reason for the error is that although both sectors are written in
> one pass, the loop for the write is executed twice because the
> "processed" variable is incremented by the incorrect amount.  The
> following change is needed to fix this issue for NOR multi-sector
> environments.  
...
> Are there any objections to committing this change?

Your Signed-off-by: line is missing...

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
Hiring experienced unix people is  like  a  built-in  filter  against
idiots. Hiring experienced NT people provides no such guarantee.
-- Miguel Cruz in WgL96.349$cc.122...@typhoon2.ba-dsg.net
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] ns16550: change to allow 32 bit access to registers

[Wolfgang Denk]

Dear Dave Aldridge,

In message <1314286215-29470-1-git-send-email-fovs...@gmail.com> you wrote:
>
> @@ -19,6 +19,12 @@
>  #ifdef CONFIG_SYS_NS16550_PORT_MAPPED
>  #define serial_out(x,y)  outb(x,(ulong)y)
>  #define serial_in(y) inb((ulong)y)
> +#elif defined(CONFIG_SYS_NS16550_MEM32) && (CONFIG_SYS_NS16550_REG_SIZE > 0)
> +#define serial_out(x,y) writel(cpu_to_be32(x),y)
> +#define serial_in(y) cpu_to_be32(readl(y))
> +#elif defined(CONFIG_SYS_NS16550_MEM32) && (CONFIG_SYS_NS16550_REG_SIZE < 0)
> +#define serial_out(x,y) writel(cpu_to_le32(x),y)
> +#define serial_in(y) cpu_to_le32(readl(y))

This looks broken to me.  Why are you suing little endian accessors
(readl() and writel() are originally intended as PCI bus accessors and
thus littelendian) in the first place?

Why don't you use in_le32()/out_le32() resp. in_be32()/out_be32()
directly?

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 a human characteristic to love little  animals,  especially  if
they're attractive in some way.
-- McCoy, "The Trouble with Tribbles", stardate 4525.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] gcc-4.6 warnings

[Wolfgang Denk]

Dear Kumar Gala,

In message <7056f5b1-ad6c-459e-80f1-8ee436cc7...@kernel.crashing.org> you wrote:
> 
> > well, that's the reason for the warnings showing up, it isn't the
> > reason why we cannot fix these?
>
> :), Thus my query if we really wanted to try and fix them by adding more
> #ifdef's or live with that as an acceptable thing to do.

My experience is that hushing up GCC warnings is not really a good
idea.  First, you will then also fail to see when new code adds such
problems.  Second, there have been cases where warnings in one GCC
version because serious bugs in later versions, so we better fix them.

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 a good thing for an uneducated man to read books of quotations.
- Sir Winston Churchill _My Early Life_ ch. 9
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [STATUS] ARM: board removal

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <4e564825.8080...@aribaud.net> you wrote:
> 
> Well, to the first question the answer is "all boards in the patch set 
> for which an action is still required in patchwork" and to the second 

That would be:

[U-Boot,46/52] ARM: remove broken "at91rm9200dk" board
[U-Boot,45/52] ARM: remove broken "m501sk" board
[U-Boot,44/52] ARM: remove broken "kb9202" board
[U-Boot,43/52] ARM: remove broken "csb637" board
[U-Boot,42/52] ARM: remove broken "cmc_pu2" board
[U-Boot,40/52] ARM: remove broken "at91cap9adk" board
[U-Boot,37/52] ARM: remove broken "voiceblue" board
[U-Boot,36/52] ARM: remove broken "versatile" boards.
[U-Boot,34/52] ARM: remove broken "smdk2400" board
[U-Boot,32/52] ARM: remove broken "sbc2410x" board
[U-Boot,31/52] ARM: remove broken "netstar" board
[U-Boot,30/52] ARM: remove broken "mx1fs2" board
[U-Boot,29/52] ARM: remove broken "lpd7a40x" boards
[U-Boot,28/52] ARM: remove broken "edb93xx" boards
[U-Boot,10/52] ARM: remove broken "B2" board
[U-Boot,09/52] ARM: remove broken "armadillo" board

Correct?

> one, u-boot-arm/master. Are you asking because you intend to generate a 
> V2 patch set?

Yes. [Somebody has to do this...]

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
"My name is Linus Torvalds, you messed with my kernel, prepare to die"
  - Linus Torvalds in
  
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] gcc-4.6 warnings

[Mike Frysinger]

On Thursday, August 25, 2011 15:50:57 Tabi Timur-B04825 wrote:
> On Thu, Aug 25, 2011 at 9:51 AM, Mike Frysinger  wrote:
> > i feel like some (many?) #ifdef's in the tree could be done without
> > ifdefs (by relying on gcc's DCE) thus improving overall code quality
> 
> What's DCE?

dead code elimination
http://en.wikipedia.org/wiki/Dead_code_elimination

if we let the optimizer do it instead of the preprocessor, we get better code 
coverage in the face of different config settings.
-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] RFC: Testing U-Boot Part 1

[Wolfgang Denk]

Dear Simon Glass,

In message  
you wrote:
> 
> Summary: I am quite keen on improving the test infrastructure in
> U-Boot. I would like to have a test suite that can run in a minute or
> two on a Linux PC and test all non-platform code.

I highly appreaciate such efforts!

> For speed, debugging and convenience, it would be nice to run U-Boot
> under a generic Linux environment on a workstation, and test all the
> generic non-platform code. The basic problem with this is that the
> non-platform code requires the platform code to operate. Even the x86
> platform code is designed for standalone operation on a particular x86
> board, and is not suitable for running under x86 Linux.

Some parts of what you are looking for can be done by running U-Boot
images in a QEMU based emulated envrionment.  So far we have only a
few targets in the tree that actually support this.  I wish we had
more of them.

I am aware that this is a different thing from what you propose here,
but I would like to state that we should not forget this option -
anybody who wants to work in that area will be more than welcome, too.


> To get around this I propose that we create a new ‘native’
> architecture. We write code in ‘arch/native’ which can run under
> Linux. Since all the non-platform code will happily run under this new
> ‘architecture’, we can then write tests which run quickly under x86
> Linux (or another Linux for that matter). This U-Boot 'architecture'
> should build natively on any 32/64-bit Linux machine since it just
> uses standard Linux system calls. Calls to Linux would be entirely
> within this arch/native subdirectory.

As Mike already pointed out, this is what BB has as "sandbox"
configuration.

> - Create a test SPI flash device, which is file-backed. Use this to
> write a test of the cmd_sf layer by issuing a series of commands and
> making sure that the correct SPI flash contents is obtained
>
> - Create a test MMC or IDE device, backed by a file. Use this to issue
> ext2 and fat commands to manipulate the filesystem. Then loopback
> mount the file and check from Linux that U-Boot did the right thing

In a later step it might even be possible to implement some "pass
through" mode to acces actual devices / drivers in some way.  Think of
using libusb to talk to USB devices.

> - Create a test Ethernet device with a mocked remote host attached.

I'm not sure what you mean by "a mocked remote host".  We should be
able to send and receive packets from a real network interface as
well.

> At this early stage I am looking for comments on the concept - how
> useful it is and how best to implement it.

Any step in this direction, how inclomplete it may be in the
beginning, is highly appreciated.  It may make sense to look over the
fence and study how BBis doing this.

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

Re: [U-Boot] gcc-4.6 warnings

[Tabi Timur-B04825]

On Thu, Aug 25, 2011 at 9:51 AM, Mike Frysinger  wrote:

> i feel like some (many?) #ifdef's in the tree could be done without ifdefs (by
> relying on gcc's DCE) thus improving overall code quality

What's DCE?

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

[U-Boot] Get a Legitimate Business offer

[Mr. Ma Guang Lu]

Business Mail
I am Mr. Ma Guang Lu; with a business deal worth $17.3Million, for us to
transact from my bank. please reply for details.

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

[U-Boot] fw_env bug for multi-sector environments on NOR flash

[Fei, Yiyang]

Hi,

I am storing u-boot environment variables on a NOR flash using two
sectors.  I encountered an error when writing changes using fw_setenv.  

/etc # cat fw_env.config
# Configuration file for fw_(printenv/saveenv) utility.
# Up to two entries are valid, in this case the redundand
# environment sector is assumed present.
# MTD device name   Device offset   Env. size   Flash sector
size   Number of sectors
/dev/mtd12  0x  0x2 0x1
2

/etc # fw_setenv test test
End of range reached, aborting
Error: can't write fw_env to flash


The reason for the error is that although both sectors are written in
one pass, the loop for the write is executed twice because the
"processed" variable is incremented by the incorrect amount.  The
following change is needed to fix this issue for NOR multi-sector
environments.  

diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
index ed6b53f..e6b2cae 100644
--- a/tools/env/fw_env.c
+++ b/tools/env/fw_env.c
@@ -880,9 +880,8 @@ static int flash_write_buf (int dev, int fd, void
*buf, size_t count,

ioctl (fd, MEMLOCK, &erase);

-   processed  += blocklen;
-   block_seek = 0;
-   blockstart += blocklen;
+   processed  += erasesize;
+   blockstart += erasesize;
}

if (write_total > count)

Are there any objections to committing this change?

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

Re: [U-Boot] RFC: Testing U-Boot Part 1

[Anton Staaf]

On Thu, Aug 25, 2011 at 8:01 AM, Mike Frysinger  wrote:
> On Thursday, August 25, 2011 08:58:00 Simon Glass wrote:
>> Proposal
>> 
>
> for people who might be familiar with the barebox boot loader, Simon is
> basically proposing the same thing as barebox's "sandbox" target.
>
> to avoid confusion/fragmentation in this area, and since the name is a large
> part bike shedding, i propose we adopt the same name that barebox has.  that
> way we can sanely use the same term when comparing/contrasting.
>
> from the barebox website:
>        Sandbox
>
>        If you develop features for Barebox, you can use the 'sandbox' target
>        which compiles Barebox as a POSIX application in the Linux userspace: 
> it
>        can be started like a normal command and even has network access
>        (tun/tap). Files from the local filesytem can be used to simulate
>        devices.

Makes good sense.

>> Comments
>> 
>> At this early stage I am looking for comments on the concept - how
>> useful it is and how best to implement it.
>
> i certainly think it's a worthwhile exercise, especially if it gets us to the
> point where we can do `make check` and have confidence in our common code
> changes not being completely f-ed up.

Indeed, I am very excited about this as well.  :)

Thanks,
Anton

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

Re: [U-Boot] [PATCH] ppc460: read get_sys_info from CPR registers instead of STRP registers

[Tirumala Marri]

Mike and Stefan,



>Thanks. Unfortunately this patch introduces compile errors for 460SX
boards
>(e.g. redwood):

>[stefan@kubuntu u-boot-ppc4xx (master)]$ ./MAKEALL redwood
>Configuring for redwood board...
>speed.c: In function 'get_sys_info':
>speed.c:339: error: 'PLLD_FWDVA_MASK' undeclared (first use in this
function)
>speed.c:339: error: (Each undeclared identifier is reported only once
>speed.c:339: error: for each function it appears in.)
>speed.c:340: error: 'PLLD_FWDVB_MASK' undeclared (first use in this
function)
>speed.c:341: error: 'PLLD_FBDV_MASK' undeclared (first use in this
function)
>speed.c:344: error: 'OPBDV_MASK' undeclared (first use in this function)
>speed.c:348: error: 'PERDV_MASK' undeclared (first use in this function)
>speed.c:351: error: 'CPR0_PLBED' undeclared (first use in this function)
>speed.c:352: error: 'PLBEDDV_MASK' undeclared (first use in this
function)
>speed.c:357: error: 'PLLC_FBSEL_MASK' undeclared (first use in this
function)
>make[1]: *** [speed.o] Error 1
>make[1]: *** Waiting for unfinished jobs
>make: *** [arch/powerpc/cpu/ppc4xx/libppc4xx.o] Error 2
>make: *** Waiting for unfinished jobs

>Could you please check, if the 460SX has the same registers and bits as
>460EX/GT and extend its header as well?

[marri] 460Ex/Gt and 460Sx has different clocking subsystems. This code
will
 Have to split to support to read the speed settings from CPU registers.

 If you can include the change to split this function we will submit our
patch
Based on yours. Please suggest.

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

Re: [U-Boot] [PATCH] ppc460: read get_sys_info from CPR registers instead of STRP registers

[Tirumala Marri]

Hi Wolfgang,


Stefan asked before, but you did not reply yet, so here I ask again:
What exactly are your plans?  You did not respond to the Eiger patches
for the last 9 months, so I somewhat doubt you are going to submit
usable patches within the next couple of days, or are you?
[marri] I will have the patches submitted by Aug29. Sorry for the
inconvenience.

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

Re: [U-Boot] [PATCH 1/1] mmc: omap: config VMMC, MMC1_PBIAS

[T Krishnamoorthy, Balaji]

On Thu, Aug 25, 2011 at 8:25 PM, Marek Vasut  wrote:
>
> On Thursday, August 25, 2011 04:48:25 PM Balaji T K wrote:
> > Config VMMC voltage to 3V for MMC/SD card slot
> > and PBIAS settings needed for OMAP4
> > Fixes MMC/SD detection on boot from eMMC.
> >
> > Signed-off-by: Balaji T K 
> > Signed-off-by: Aneesh V 
> > ---
> >  arch/arm/include/asm/arch-omap4/omap4.h |    1 +
> >  drivers/mmc/omap_hsmmc.c                |   28
> > +--- drivers/power/twl6030.c                 |
> > 7 +++
> >  include/configs/omap4_sdp4430.h         |    2 ++
> >  include/twl6030.h                       |    3 +++
> >  5 files changed, 38 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/arch-omap4/omap4.h
> > b/arch/arm/include/asm/arch-omap4/omap4.h index 9aad0e6..13fc8c9 100644
> > --- a/arch/arm/include/asm/arch-omap4/omap4.h
> > +++ b/arch/arm/include/asm/arch-omap4/omap4.h
> > @@ -55,6 +55,7 @@
> >  #define LPDDR2_IO_REGS_BASE  0x4A100638
> >
> >  #define CONTROL_EFUSE_2              0x4A100704
> > +#define CONTROL_PBIASLITE    0x4A100600
>
> Can't you use struct omap_something_regs { ... } like most of U-Boot code ?

Currently only these 3 registers are used in u-boot for this CONTROL module IP.
Above 3 registers don't have such API with base address(0x4a10)
But I think there is a patch coming soon. Should this patch wait until then ?

>
> >
> >  /* CONTROL_ID_CODE */
> >  #define CONTROL_ID_CODE              0x4A002204
> > diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
> > index 6627905..95bb661 100644
> > --- a/drivers/mmc/omap_hsmmc.c
> > +++ b/drivers/mmc/omap_hsmmc.c
> > @@ -28,6 +28,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -38,7 +39,24 @@
> >  static int mmc_read_data(hsmmc_t *mmc_base, char *buf, unsigned int size);
> >  static int mmc_write_data(hsmmc_t *mmc_base, const char *buf, unsigned int
> > siz); static struct mmc hsmmc_dev[2];
> > -unsigned char mmc_board_init(hsmmc_t *mmc_base)
> > +
> > +#if defined(CONFIG_OMAP44XX) && defined(CONFIG_TWL6030_POWER)
> > +static void omap4_vmmc_pbias_config(struct mmc *mmc)
> > +{
> > +     u32 value = 0;
> > +
> > +     value = readl(CONTROL_PBIASLITE);
> > +     value &= ~((1 << 22) | (1 << 26));
>
> What's this magic ?
>

will use #define

> > +     writel(value, CONTROL_PBIASLITE);
> > +     /* set VMMC to 3V */
> > +     twl6030_power_mmc_init();
> > +     value = readl(CONTROL_PBIASLITE);
> > +     value |= (1 << 21) | (1 << 22) | (1 << 26);
>
> And this magic ?

will use #define

>
> > +     writel(value, CONTROL_PBIASLITE);
> > +}
> > +#endif
> > +
> > +unsigned char mmc_board_init(struct mmc *mmc)
> >  {
> >  #if defined(CONFIG_TWL4030_POWER)
> >       twl4030_power_mmc_init();
> > @@ -67,7 +85,11 @@ unsigned char mmc_board_init(hsmmc_t *mmc_base)
> >               &prcm_base->iclken1_core);
> >  #endif
> >
> > -/* TODO add appropriate OMAP4 init - none currently necessary */
> > +#if defined(CONFIG_OMAP44XX) && defined(CONFIG_TWL6030_POWER)
> > +     /* PBIAS config needed for MMC1 only */
>
> You have == 0 below ... so you're numbering from 1 here ? It's a bit 
> confusing.

uboot mmc starts numbering from 0, But OMAP data manual starts the IP numbering
from 1

>
> > +     if (mmc->block_dev.dev == 0)
> > +             omap4_vmmc_pbias_config(mmc);
> > +#endif
> >
> >       return 0;
> >  }
> > @@ -108,7 +130,7 @@ static int mmc_init_setup(struct mmc *mmc)
> >       unsigned int dsor;
> >       ulong start;
> >
> > -     mmc_board_init(mmc_base);
> > +     mmc_board_init(mmc);
>
> Is this a bugfix ?

I changed the prototype for checking mmc->block_dev.dev in mmc_board_init.
Without this change, regulator to MMC is not set to correct voltage,
MMC/SD fails to get detected. mmc_init fails and read/write also fails.

>
> >
> >       writel(readl(&mmc_base->sysconfig) | MMC_SOFTRESET,
> >               &mmc_base->sysconfig);
> > diff --git a/drivers/power/twl6030.c b/drivers/power/twl6030.c
> > index fef57b4..c5a0038 100644
> > --- a/drivers/power/twl6030.c
> > +++ b/drivers/power/twl6030.c
> > @@ -182,6 +182,13 @@ void twl6030_init_battery_charging(void)
> >       return;
> >  }
> >
> > +void twl6030_power_mmc_init()
> > +{
> > +     /* set voltage to 3.0 and turnon for APP */
> > +     twl6030_i2c_write_u8(TWL6030_CHIP_PM, 0x15, VMMC_CFG_VOLTATE);
> > +     twl6030_i2c_write_u8(TWL6030_CHIP_PM, 0x21, VMMC_CFG_STATE);
> > +}
> > +
> >  void twl6030_usb_device_settings()
> >  {
> >       u8 data = 0;
> > diff --git a/include/configs/omap4_sdp4430.h
> > b/include/configs/omap4_sdp4430.h index 5b3110c..50797ab 100644
> > --- a/include/configs/omap4_sdp4430.h
> > +++ b/include/configs/omap4_sdp4430.h
> > @@ -98,8 +98,10 @@
> >  #define CONFIG_I2C_MULTI_BUS         1
> >
> >  /* TWL6030 */
> > +#ifndef CONFIG_SPL_BUILD
> >  #define CONFIG_TWL6030_POWER         1
> >  #define CONFIG_CMD_BAT                       1
> > +#en

[U-Boot] [PATCH v2] ns16550: change to allow 32 bit access to registers

[Dave Aldridge]

If CONFIG_SYS_NS16550_MEM32 is defined then 32 bit memory
mapped access will be used to read/write the uart registers.

This is especially useful for SoC devices that implement 16550
compatible uarts but that have peripheral access width constraints.

Signed-off-by: Dave Aldridge 
---
Changes for v2:
- Add endian support

 drivers/serial/ns16550.c |6 ++
 include/ns16550.h|2 ++
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 8eeb48f..e16685b 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -19,6 +19,12 @@
 #ifdef CONFIG_SYS_NS16550_PORT_MAPPED
 #define serial_out(x,y)outb(x,(ulong)y)
 #define serial_in(y)   inb((ulong)y)
+#elif defined(CONFIG_SYS_NS16550_MEM32) && (CONFIG_SYS_NS16550_REG_SIZE > 0)
+#define serial_out(x,y) writel(cpu_to_be32(x),y)
+#define serial_in(y)   cpu_to_be32(readl(y))
+#elif defined(CONFIG_SYS_NS16550_MEM32) && (CONFIG_SYS_NS16550_REG_SIZE < 0)
+#define serial_out(x,y) writel(cpu_to_le32(x),y)
+#define serial_in(y)   cpu_to_le32(readl(y))
 #else
 #define serial_out(x,y) writeb(x,y)
 #define serial_in(y)   readb(y)
diff --git a/include/ns16550.h b/include/ns16550.h
index 9ea81e9..d4ffac9 100644
--- a/include/ns16550.h
+++ b/include/ns16550.h
@@ -23,6 +23,8 @@
 
 #if !defined(CONFIG_SYS_NS16550_REG_SIZE) || (CONFIG_SYS_NS16550_REG_SIZE == 0)
 #error "Please define NS16550 registers size."
+#elif defined(CONFIG_SYS_NS16550_MEM32)
+#define UART_REG(x) unsigned int x;
 #elif (CONFIG_SYS_NS16550_REG_SIZE > 0)
 #define UART_REG(x)   \
unsigned char prepad_##x[CONFIG_SYS_NS16550_REG_SIZE - 1]; \
-- 
1.7.3.4

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

[U-Boot] [PATCH] OMAP3: DIG297: Use generic MMC driver

[Tom Rini]

Switch from the legacy omap3 mmc driver to the new generic omap hsmmc
driver.  This patch is based on the work done for Beagle, etc.

Tested-by: Luca Ceresoli 
Signed-off-by: Tom Rini 

---

V2 changes:
Follow board config format, just use #define CONFIG_GENERIC_MMC, etc)
---
 board/comelit/dig297/dig297.c |9 +
 include/configs/dig297.h  |3 ++-
 2 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/board/comelit/dig297/dig297.c b/board/comelit/dig297/dig297.c
index 0062f12..a7071cd 100644
--- a/board/comelit/dig297/dig297.c
+++ b/board/comelit/dig297/dig297.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -145,6 +146,14 @@ void set_muxconf_regs(void)
MUX_DIG297();
 }
 
+#ifdef CONFIG_GENERIC_MMC
+int board_mmc_init(bd_t *bis)
+{
+   omap_mmc_init(0);
+   return 0;
+}
+#endif
+
 #ifdef CONFIG_CMD_NET
 /*
  * Routine: setup_net_chip
diff --git a/include/configs/dig297.h b/include/configs/dig297.h
index b68f073..4186ab6 100644
--- a/include/configs/dig297.h
+++ b/include/configs/dig297.h
@@ -97,8 +97,9 @@
 #define CONFIG_BAUDRATE115200
 #define CONFIG_SYS_BAUDRATE_TABLE  {4800, 9600, 19200, 38400, 57600,\
115200}
+#define CONFIG_GENERIC_MMC
 #define CONFIG_MMC
-#define CONFIG_OMAP3_MMC
+#define CONFIG_OMAP_HSMMC
 #define CONFIG_DOS_PARTITION
 
 /* DDR - I use Micron DDR */
-- 
1.7.0.4

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

Re: [U-Boot] RFC: Testing U-Boot Part 1

[Mike Frysinger]

On Thursday, August 25, 2011 08:58:00 Simon Glass wrote:
> Proposal
> 

for people who might be familiar with the barebox boot loader, Simon is 
basically proposing the same thing as barebox's "sandbox" target.

to avoid confusion/fragmentation in this area, and since the name is a large 
part bike shedding, i propose we adopt the same name that barebox has.  that 
way we can sanely use the same term when comparing/contrasting.

from the barebox website:
Sandbox

If you develop features for Barebox, you can use the 'sandbox' target
which compiles Barebox as a POSIX application in the Linux userspace: it
can be started like a normal command and even has network access
(tun/tap). Files from the local filesytem can be used to simulate
devices.

> Comments
> 
> At this early stage I am looking for comments on the concept - how
> useful it is and how best to implement it.

i certainly think it's a worthwhile exercise, especially if it gets us to the 
point where we can do `make check` and have confidence in our common code 
changes not being completely f-ed up.
-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] RFC: Testing U-Boot Part 1

[Mike Frysinger]

On Thursday, August 25, 2011 09:56:02 Andreas Bießmann wrote:
> Am 25.08.2011 14:58, schrieb Simon Glass:
> > Summary: I am quite keen on improving the test infrastructure in
> > U-Boot. I would like to have a test suite that can run in a minute or
> > two on a Linux PC and test all non-platform code.
> 
> 
> 
> > To get around this I propose that we create a new ‘native’
> > architecture. We write code in ‘arch/native’ which can run under
> > Linux. Since all the non-platform code will happily run under this new
> > ‘architecture’, we can then write tests which run quickly under x86
> > Linux (or another Linux for that matter). This U-Boot 'architecture'
> > should build natively on any 32/64-bit Linux machine since it just
> > uses standard Linux system calls. Calls to Linux would be entirely
> > within this arch/native subdirectory.
> 
> why don't use some unit testing framework like cunit, or ceedling (which
> can do HW mocks easily)?

these testing frameworks wont make any difference to what Simon is proposing.  
he is focusing on getting u-boot to build & run on your desktop machine.  
after that is done, we can talk about the actual tests and harnesses (although 
anything that requires ruby should immediately be disqualified imo :P).
-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 1/1] mmc: omap: config VMMC, MMC1_PBIAS

[Marek Vasut]

On Thursday, August 25, 2011 04:48:25 PM Balaji T K wrote:
> Config VMMC voltage to 3V for MMC/SD card slot
> and PBIAS settings needed for OMAP4
> Fixes MMC/SD detection on boot from eMMC.
> 
> Signed-off-by: Balaji T K 
> Signed-off-by: Aneesh V 
> ---
>  arch/arm/include/asm/arch-omap4/omap4.h |1 +
>  drivers/mmc/omap_hsmmc.c|   28
> +--- drivers/power/twl6030.c |   
> 7 +++
>  include/configs/omap4_sdp4430.h |2 ++
>  include/twl6030.h   |3 +++
>  5 files changed, 38 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/include/asm/arch-omap4/omap4.h
> b/arch/arm/include/asm/arch-omap4/omap4.h index 9aad0e6..13fc8c9 100644
> --- a/arch/arm/include/asm/arch-omap4/omap4.h
> +++ b/arch/arm/include/asm/arch-omap4/omap4.h
> @@ -55,6 +55,7 @@
>  #define LPDDR2_IO_REGS_BASE  0x4A100638
> 
>  #define CONTROL_EFUSE_2  0x4A100704
> +#define CONTROL_PBIASLITE0x4A100600

Can't you use struct omap_something_regs { ... } like most of U-Boot code ?

> 
>  /* CONTROL_ID_CODE */
>  #define CONTROL_ID_CODE  0x4A002204
> diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
> index 6627905..95bb661 100644
> --- a/drivers/mmc/omap_hsmmc.c
> +++ b/drivers/mmc/omap_hsmmc.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -38,7 +39,24 @@
>  static int mmc_read_data(hsmmc_t *mmc_base, char *buf, unsigned int size);
>  static int mmc_write_data(hsmmc_t *mmc_base, const char *buf, unsigned int
> siz); static struct mmc hsmmc_dev[2];
> -unsigned char mmc_board_init(hsmmc_t *mmc_base)
> +
> +#if defined(CONFIG_OMAP44XX) && defined(CONFIG_TWL6030_POWER)
> +static void omap4_vmmc_pbias_config(struct mmc *mmc)
> +{
> + u32 value = 0;
> +
> + value = readl(CONTROL_PBIASLITE);
> + value &= ~((1 << 22) | (1 << 26));

What's this magic ?

> + writel(value, CONTROL_PBIASLITE);
> + /* set VMMC to 3V */
> + twl6030_power_mmc_init();
> + value = readl(CONTROL_PBIASLITE);
> + value |= (1 << 21) | (1 << 22) | (1 << 26);

And this magic ?

> + writel(value, CONTROL_PBIASLITE);
> +}
> +#endif
> +
> +unsigned char mmc_board_init(struct mmc *mmc)
>  {
>  #if defined(CONFIG_TWL4030_POWER)
>   twl4030_power_mmc_init();
> @@ -67,7 +85,11 @@ unsigned char mmc_board_init(hsmmc_t *mmc_base)
>   &prcm_base->iclken1_core);
>  #endif
> 
> -/* TODO add appropriate OMAP4 init - none currently necessary */
> +#if defined(CONFIG_OMAP44XX) && defined(CONFIG_TWL6030_POWER)
> + /* PBIAS config needed for MMC1 only */

You have == 0 below ... so you're numbering from 1 here ? It's a bit confusing.

> + if (mmc->block_dev.dev == 0)
> + omap4_vmmc_pbias_config(mmc);
> +#endif
> 
>   return 0;
>  }
> @@ -108,7 +130,7 @@ static int mmc_init_setup(struct mmc *mmc)
>   unsigned int dsor;
>   ulong start;
> 
> - mmc_board_init(mmc_base);
> + mmc_board_init(mmc);

Is this a bugfix ?

> 
>   writel(readl(&mmc_base->sysconfig) | MMC_SOFTRESET,
>   &mmc_base->sysconfig);
> diff --git a/drivers/power/twl6030.c b/drivers/power/twl6030.c
> index fef57b4..c5a0038 100644
> --- a/drivers/power/twl6030.c
> +++ b/drivers/power/twl6030.c
> @@ -182,6 +182,13 @@ void twl6030_init_battery_charging(void)
>   return;
>  }
> 
> +void twl6030_power_mmc_init()
> +{
> + /* set voltage to 3.0 and turnon for APP */
> + twl6030_i2c_write_u8(TWL6030_CHIP_PM, 0x15, VMMC_CFG_VOLTATE);
> + twl6030_i2c_write_u8(TWL6030_CHIP_PM, 0x21, VMMC_CFG_STATE);
> +}
> +
>  void twl6030_usb_device_settings()
>  {
>   u8 data = 0;
> diff --git a/include/configs/omap4_sdp4430.h
> b/include/configs/omap4_sdp4430.h index 5b3110c..50797ab 100644
> --- a/include/configs/omap4_sdp4430.h
> +++ b/include/configs/omap4_sdp4430.h
> @@ -98,8 +98,10 @@
>  #define CONFIG_I2C_MULTI_BUS 1
> 
>  /* TWL6030 */
> +#ifndef CONFIG_SPL_BUILD
>  #define CONFIG_TWL6030_POWER 1
>  #define CONFIG_CMD_BAT   1
> +#endif
> 
>  /* MMC */
>  #define CONFIG_GENERIC_MMC   1
> diff --git a/include/twl6030.h b/include/twl6030.h
> index 6ed68a0..a9fcadb 100644
> --- a/include/twl6030.h
> +++ b/include/twl6030.h
> @@ -33,6 +33,8 @@
>  #define TWL6030_CHIP_PWM 0x49
> 
>  /* Slave Address 0x48 */
> +#define VMMC_CFG_STATE   0x9A
> +#define VMMC_CFG_VOLTATE 0x9B
>  #define VUSB_CFG_STATE   0xA2
> 
>  #define MISC10xE4
> @@ -130,3 +132,4 @@ void twl6030_start_usb_charging(void);
>  void twl6030_stop_usb_charging(void);
>  int twl6030_get_battery_voltage(void);
>  int twl6030_get_battery_current(void);
> +void twl6030_power_mmc_init(void);

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

Re: [U-Boot] gcc-4.6 warnings

[Mike Frysinger]

On Thursday, August 25, 2011 10:27:42 Kumar Gala wrote:
> On Aug 25, 2011, at 12:52 AM, Wolfgang Denk wrote:
> > Kumar Gala wrote:
> >>> If the variable is not used, why don't we remove it, then?
> >> 
> >> In the vast number of cases it because of some #ifdef case not be
> >> defined in the given build.
> > 
> > well, that's the reason for the warnings showing up, it isn't the
> > reason why we cannot fix these?
> :
> :), Thus my query if we really wanted to try and fix them by adding more
> :#ifdef's or live with that as an acceptable thing to do.

i feel like some (many?) #ifdef's in the tree could be done without ifdefs (by 
relying on gcc's DCE) thus improving overall code quality
-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] mmc: omap: config VMMC, MMC1_PBIAS

[Balaji T K]

Config VMMC voltage to 3V for MMC/SD card slot
and PBIAS settings needed for OMAP4
Fixes MMC/SD detection on boot from eMMC.

Signed-off-by: Balaji T K 
Signed-off-by: Aneesh V 
---
 arch/arm/include/asm/arch-omap4/omap4.h |1 +
 drivers/mmc/omap_hsmmc.c|   28 +---
 drivers/power/twl6030.c |7 +++
 include/configs/omap4_sdp4430.h |2 ++
 include/twl6030.h   |3 +++
 5 files changed, 38 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/arch-omap4/omap4.h 
b/arch/arm/include/asm/arch-omap4/omap4.h
index 9aad0e6..13fc8c9 100644
--- a/arch/arm/include/asm/arch-omap4/omap4.h
+++ b/arch/arm/include/asm/arch-omap4/omap4.h
@@ -55,6 +55,7 @@
 #define LPDDR2_IO_REGS_BASE0x4A100638
 
 #define CONTROL_EFUSE_20x4A100704
+#define CONTROL_PBIASLITE  0x4A100600
 
 /* CONTROL_ID_CODE */
 #define CONTROL_ID_CODE0x4A002204
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index 6627905..95bb661 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -38,7 +39,24 @@
 static int mmc_read_data(hsmmc_t *mmc_base, char *buf, unsigned int size);
 static int mmc_write_data(hsmmc_t *mmc_base, const char *buf, unsigned int 
siz);
 static struct mmc hsmmc_dev[2];
-unsigned char mmc_board_init(hsmmc_t *mmc_base)
+
+#if defined(CONFIG_OMAP44XX) && defined(CONFIG_TWL6030_POWER)
+static void omap4_vmmc_pbias_config(struct mmc *mmc)
+{
+   u32 value = 0;
+
+   value = readl(CONTROL_PBIASLITE);
+   value &= ~((1 << 22) | (1 << 26));
+   writel(value, CONTROL_PBIASLITE);
+   /* set VMMC to 3V */
+   twl6030_power_mmc_init();
+   value = readl(CONTROL_PBIASLITE);
+   value |= (1 << 21) | (1 << 22) | (1 << 26);
+   writel(value, CONTROL_PBIASLITE);
+}
+#endif
+
+unsigned char mmc_board_init(struct mmc *mmc)
 {
 #if defined(CONFIG_TWL4030_POWER)
twl4030_power_mmc_init();
@@ -67,7 +85,11 @@ unsigned char mmc_board_init(hsmmc_t *mmc_base)
&prcm_base->iclken1_core);
 #endif
 
-/* TODO add appropriate OMAP4 init - none currently necessary */
+#if defined(CONFIG_OMAP44XX) && defined(CONFIG_TWL6030_POWER)
+   /* PBIAS config needed for MMC1 only */
+   if (mmc->block_dev.dev == 0)
+   omap4_vmmc_pbias_config(mmc);
+#endif
 
return 0;
 }
@@ -108,7 +130,7 @@ static int mmc_init_setup(struct mmc *mmc)
unsigned int dsor;
ulong start;
 
-   mmc_board_init(mmc_base);
+   mmc_board_init(mmc);
 
writel(readl(&mmc_base->sysconfig) | MMC_SOFTRESET,
&mmc_base->sysconfig);
diff --git a/drivers/power/twl6030.c b/drivers/power/twl6030.c
index fef57b4..c5a0038 100644
--- a/drivers/power/twl6030.c
+++ b/drivers/power/twl6030.c
@@ -182,6 +182,13 @@ void twl6030_init_battery_charging(void)
return;
 }
 
+void twl6030_power_mmc_init()
+{
+   /* set voltage to 3.0 and turnon for APP */
+   twl6030_i2c_write_u8(TWL6030_CHIP_PM, 0x15, VMMC_CFG_VOLTATE);
+   twl6030_i2c_write_u8(TWL6030_CHIP_PM, 0x21, VMMC_CFG_STATE);
+}
+
 void twl6030_usb_device_settings()
 {
u8 data = 0;
diff --git a/include/configs/omap4_sdp4430.h b/include/configs/omap4_sdp4430.h
index 5b3110c..50797ab 100644
--- a/include/configs/omap4_sdp4430.h
+++ b/include/configs/omap4_sdp4430.h
@@ -98,8 +98,10 @@
 #define CONFIG_I2C_MULTI_BUS   1
 
 /* TWL6030 */
+#ifndef CONFIG_SPL_BUILD
 #define CONFIG_TWL6030_POWER   1
 #define CONFIG_CMD_BAT 1
+#endif
 
 /* MMC */
 #define CONFIG_GENERIC_MMC 1
diff --git a/include/twl6030.h b/include/twl6030.h
index 6ed68a0..a9fcadb 100644
--- a/include/twl6030.h
+++ b/include/twl6030.h
@@ -33,6 +33,8 @@
 #define TWL6030_CHIP_PWM   0x49
 
 /* Slave Address 0x48 */
+#define VMMC_CFG_STATE 0x9A
+#define VMMC_CFG_VOLTATE   0x9B
 #define VUSB_CFG_STATE 0xA2
 
 #define MISC1  0xE4
@@ -130,3 +132,4 @@ void twl6030_start_usb_charging(void);
 void twl6030_stop_usb_charging(void);
 int twl6030_get_battery_voltage(void);
 int twl6030_get_battery_current(void);
+void twl6030_power_mmc_init(void);
-- 
1.7.0.4

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

[U-Boot] [PATCH 1/1] mmc: omap: enable high capacity

[Balaji T K]

Enable high capacity to host capability.
Fixes eMMC detection on boot from MMC/SD card.

Signed-off-by: Balaji T K 
Signed-off-by: Aneesh V 
---
 drivers/mmc/omap_hsmmc.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index ef12ecd..6627905 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -461,7 +461,8 @@ int omap_mmc_init(int dev_index)
return 1;
}
mmc->voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195;
-   mmc->host_caps = MMC_MODE_4BIT | MMC_MODE_HS_52MHz | MMC_MODE_HS;
+   mmc->host_caps = MMC_MODE_4BIT | MMC_MODE_HS_52MHz | MMC_MODE_HS |
+   MMC_MODE_HC;
 
mmc->f_min = 40;
mmc->f_max = 5200;
-- 
1.7.0.4

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

Re: [U-Boot] RFC: Testing U-Boot Part 1

[Marek Vasut]

On Thursday, August 25, 2011 02:58:00 PM Simon Glass wrote:
> Hi,
> 
> Summary: I am quite keen on improving the test infrastructure in
> U-Boot. I would like to have a test suite that can run in a minute or
> two on a Linux PC and test all non-platform code.
> 
> Detail
> ==
> We can break the U-Boot code base into two parts:
> 
> 1. Platform code, which is SOC-specifc. At present this is the CPU
> init (arch/xxx/cpu/...) and SOC-specific drivers (mostly in the
> drivers directory). There is also a small amount of generic CPU code
> in arch/xxx/lib and some board-specific code/drivers (e.g. drivers not
> within the SOC).
> 
> 2. Portable/Generic U-Boot code, which is cross-platform. This
> includes many drivers, the various commands, file system support,
> things like the MMC, USB and network stacks, etc.
> 
> My focus in this email the the second part of the code base - all the
> code which is not platform-specific, but can still have bugs.
> 
> Proposal
> 
> To a large extent, testing of this part of the code base could simply
> be built on one or more of the available platforms. We could then run
> the tests on that platform, and announce that the code base works fine
> on that platform. Obviously the platform needs to support all possible
> features of U-Boot.
> 
> However, this approach fails to take advantage of two useful
> properties of this code:
> 
> - It is cross-platform, and even runs on x86
> - It is standalone, requiring no OS libraries to run
> 
> For speed, debugging and convenience, it would be nice to run U-Boot
> under a generic Linux environment on a workstation, and test all the
> generic non-platform code. The basic problem with this is that the
> non-platform code requires the platform code to operate. Even the x86
> platform code is designed for standalone operation on a particular x86
> board, and is not suitable for running under x86 Linux.
> 
> To get around this I propose that we create a new ‘native’
> architecture. We write code in ‘arch/native’ which can run under
> Linux. Since all the non-platform code will happily run under this new
> ‘architecture’, we can then write tests which run quickly under x86
> Linux (or another Linux for that matter). This U-Boot 'architecture'
> should build natively on any 32/64-bit Linux machine since it just
> uses standard Linux system calls. Calls to Linux would be entirely
> within this arch/native subdirectory.
> 
> Benefit
> ===
> What will this buy us? Well we can do things like:
> 
> - Create a test SPI flash device, which is file-backed. Use this to
> write a test of the cmd_sf layer by issuing a series of commands and
> making sure that the correct SPI flash contents is obtained
> 
> - Create a test MMC or IDE device, backed by a file. Use this to issue
> ext2 and fat commands to manipulate the filesystem. Then loopback
> mount the file and check from Linux that U-Boot did the right thing
> 
> - Create a test Ethernet device with a mocked remote host attached.
> Use this to issue network commands like bootp and tftp and check that
> the correct results are obtained.
> 
> Ultimately (one day) we might have a set of unit tests for U-Boot
> which can run to very quickly check that a patch does not break the
> core U-Boot code.
> 
> Comments
> 
> At this early stage I am looking for comments on the concept - how
> useful it is and how best to implement it.

Hi Simon, 

sounds just awesome. I was planning on doing a similar thing, but "from the 
other side". I'm sure you're aware of the POST test framework. I was planning 
to 
either extend it or write new self-standing implementation that'd allow 
debuging 
platform-dependent drivers.

I can CC you on that if you have some interest.

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

Re: [U-Boot] gcc-4.6 warnings

[Kumar Gala]

On Aug 25, 2011, at 12:52 AM, Wolfgang Denk wrote:

> Dear Kumar Gala,
> 
> In message <348935c0-0c2d-4a7a-8abe-9d09e2904...@kernel.crashing.org> you 
> wrote:
>> 
>>> If the variable is not used, why don't we remove it, then?
>> 
>> In the vast number of cases it because of some #ifdef case not be
>> defined in the given build.
> 
> well, that's the reason for the warnings showing up, it isn't the
> reason why we cannot fix these?

:), Thus my query if we really wanted to try and fix them by adding more 
#ifdef's or live with that as an acceptable thing to do.

- k

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

Re: [U-Boot] mii_phy.h

[Mike Frysinger]

On Thursday, August 25, 2011 03:25:32 Michal Simek wrote:
> Can someone clear me purpose of mii_phy.h? It looks like that it is really
> ancient file which hasn't been touched from 2003.
> 
> It is use for two files
> [monstr@monstr u-boot]$ grep -rn "mii_phy.h" *
> board/ep8260/mii_phy.c:2:#include 
> board/rpxsuper/mii_phy.c:2:#include 

yes, if you look at old files, you often see people using generic names when 
they should have been driver or arch specific, or people who thought about 
starting a framework but then nothing ever materialized.

> The best will be to remove mii_phy entirely.

sounds good to me ... i imagine the existing functionality might need to be 
converted into one of the common net frameworks that has been adopted ?
-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] phylib + mii + _parse_status

[Mike Frysinger]

On Thursday, August 25, 2011 03:56:50 Michal Simek wrote:
> Then will be good to synchronize FULL/HALF and DUPLEX_FULL/DUPLEX_HALF.
> 
> miiphy.h
> #define HALF22
> #define FULL44
> 
> include/linux/ethtool.h
> #define DUPLEX_HALF 0x00
> #define DUPLEX_FULL 0x01
> 
> 
> And of course speeds:
> miiphy.h
> #define _1000BASET  1000
> #define _100BASET   100
> #define _10BASET10
> 
> include/linux/ethtool.h
> #define SPEED_1010
> #define SPEED_100   100
> #define SPEED_1000  1000
> #define SPEED_2500  2500
> #define SPEED_1 1
> 
> Have someone looked at it? Any comments?

ive glanced at unification of these defines in the past and couldnt see any 
reason as to why it couldnt be done ... it just touched a bunch of drivers i 
had no way of testing, and didnt feel like embarking on another tree wide 
cleanup at that time.  i can only do so many before i get bored ;).
-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 v2 1/3] net: Adds Fast Ethernet Controller driver for Armada100

[Mike Frysinger]

On Thursday, August 25, 2011 01:10:30 Ajay Bhargav wrote:
> - "Mike Frysinger"  wrote:
> > On Wednesday, August 24, 2011 09:07:18 Ajay Bhargav wrote:
> > > + /* Read mac from env if available */
> > > + eth_getenv_enetaddr("ethaddr", dev->enetaddr);
> > 
> > you shouldnt need to do this.  the higher layers will take care of
> > this for
> > you when you set write_hwaddr
> 
> I do not have a hardware storage for MAC on my controller. write_hwaddr
> is not needed for me.

ok, but you should not be touching dev->enetaddr in your registration 
function.  the main net/eth.c:eth_initialize() takes care of this for you.

> > > +int armada100_fec_initialize()
> > > +{
> > > ...
> > > + darmdfec->regs = (void *) ARMD1_FEC_BASE;
> > 
> > make the reg base a parameter to armada100_fec_initialize()
> 
> This driver is for Armada100 series and base address is same for
> the whole series, so i did not feel passing it as a parameter. Can
> you please tell me if there is any specific reason for the same?

drivers should be written for the IP they control, not for specific SoCs or 
boards.  and what people often start off with "this SoC only has one MAC so 
screw multi-instance" quite frequently turns into "this next SoC supports 
multiple MACs!".

i'm not familiar with the Armada100, or the MAC IP that is in that SoC, but 
this story repeats itself constantly in the SoC world because people focus on 
the one specific SoC they have in their hand and not the bigger picture.  
simply witness the ARM hell that Linux is currently in and is being cleaned up 
through the Linaro organization.
-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] Error : Not finding asm/arch/gpio.h

[Mike Frysinger]

On Thursday, August 25, 2011 02:29:12 Faisal H wrote:
> While building with omap3_beagle_config configuration,
> getting an error about not finding asm/arch/gpio.h (which does not exist).
> Found that header files are moved to arch/arm/include/asm/arch-.
> Fixed the includes to find the file..

NAK on all the Blackfin pieces as that arch properly sets up asm/gpio.h for 
people to include (all the board/*bf5*/ dirs).
-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] RFC: Testing U-Boot Part 1

[Andreas Bießmann]

Dear Simon,

Am 25.08.2011 14:58, schrieb Simon Glass:
> Hi,
> 
> Summary: I am quite keen on improving the test infrastructure in
> U-Boot. I would like to have a test suite that can run in a minute or
> two on a Linux PC and test all non-platform code.



> To get around this I propose that we create a new ‘native’
> architecture. We write code in ‘arch/native’ which can run under
> Linux. Since all the non-platform code will happily run under this new
> ‘architecture’, we can then write tests which run quickly under x86
> Linux (or another Linux for that matter). This U-Boot 'architecture'
> should build natively on any 32/64-bit Linux machine since it just
> uses standard Linux system calls. Calls to Linux would be entirely
> within this arch/native subdirectory.

why don't use some unit testing framework like cunit, or ceedling (which
can do HW mocks easily)?

regards

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

Re: [U-Boot] [STATUS] ARM: board removal

[Albert ARIBAUD]

Hi Wolfgang,

Le 24/08/2011 20:11, Wolfgang Denk a écrit :
> Dear Albert ARIBAUD,
>
> In message<4e553288.9000...@aribaud.net>  you wrote:
>>
>> Wolfgang, did you by any chance use some kind of script to produce your
>> patchset, and if so, could you regenerate the set of patches for the
>> remaining boards, those that currently have an 'action required' status
>> in patchwork?
>
> No, this was done manually.
>
> Do you have a list of the boards that shall eb removed?
>
> And which exact tree shall the patches be based on?

Well, to the first question the answer is "all boards in the patch set 
for which an action is still required in patchwork" and to the second 
one, u-boot-arm/master. Are you asking because you intend to generate a 
V2 patch set?

> Best regards,
>
> Wolfgang Denk

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

Re: [U-Boot] [PATCH v2 2/3] Armada100: Enable Ethernet support for GplugD

[Marek Vasut]

On Thursday, August 25, 2011 02:09:46 PM Ajay Bhargav wrote:
> - "Marek Vasut"  wrote:
> > On Thursday, August 25, 2011 07:15:17 AM Ajay Bhargav wrote:
> > > - "Marek Vasut"  wrote:
> > > [...]
> > > 
> > > > > +/* Disable DCACHE */
> > > > > +#define CONFIG_SYS_DCACHE_OFF
> > > > 
> > > > ARMADA100 is still ARMv5? Then maybe you can try Hong Xu's patches
> > 
> > for
> > 
> > > > dcache on
> > > > armv5. You'll have to modify the ethernet driver to be aware of
> > 
> > the
> > 
> > > > dcache then
> > > > though.
> > > > 
> > > > As dcache support is on the way, it might be worth it.
> > > 
> > > Yes ARMADA100 is ARMv5. I had problems with dcache enabled, driver
> > 
> > get
> > 
> > > stuck. Can you please link me to Hong Xu's patches? Is there a
> > 
> > problem if
> > 
> > > i keep it disabled?
> > 
> > http://lists.denx.de/pipermail/u-boot/2011-August/098405.html Look
> > around this.
> > You'd better search for V2 of the patches or V3 in U-Boot ML archive.
> > 
> > There's no problem if you keep it disabled, but eventually, you'll
> > have to
> > enable it ;-)
> > 
> > Cheers
> 
> Hi Marek,
> 
> I searched mail list after I emailed you.. There has been a lot of
> discussion going on Hong Xu's patches. I think it would be better if I
> work on enabling dcache once the patch is mainlined.

You can always give it a whirl to test the patch. You can also find pieces of 
your driver that will need redesign because of the cache-line alignment and 
avoid such trouble in advance. But this is just an offer, it's not a firm 
requirement for the patch to be mainlined!

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

[U-Boot] RFC: Testing U-Boot Part 1

[Simon Glass]

Hi,

Summary: I am quite keen on improving the test infrastructure in
U-Boot. I would like to have a test suite that can run in a minute or
two on a Linux PC and test all non-platform code.

Detail
==
We can break the U-Boot code base into two parts:

1. Platform code, which is SOC-specifc. At present this is the CPU
init (arch/xxx/cpu/...) and SOC-specific drivers (mostly in the
drivers directory). There is also a small amount of generic CPU code
in arch/xxx/lib and some board-specific code/drivers (e.g. drivers not
within the SOC).

2. Portable/Generic U-Boot code, which is cross-platform. This
includes many drivers, the various commands, file system support,
things like the MMC, USB and network stacks, etc.

My focus in this email the the second part of the code base - all the
code which is not platform-specific, but can still have bugs.

Proposal

To a large extent, testing of this part of the code base could simply
be built on one or more of the available platforms. We could then run
the tests on that platform, and announce that the code base works fine
on that platform. Obviously the platform needs to support all possible
features of U-Boot.

However, this approach fails to take advantage of two useful
properties of this code:

- It is cross-platform, and even runs on x86
- It is standalone, requiring no OS libraries to run

For speed, debugging and convenience, it would be nice to run U-Boot
under a generic Linux environment on a workstation, and test all the
generic non-platform code. The basic problem with this is that the
non-platform code requires the platform code to operate. Even the x86
platform code is designed for standalone operation on a particular x86
board, and is not suitable for running under x86 Linux.

To get around this I propose that we create a new ‘native’
architecture. We write code in ‘arch/native’ which can run under
Linux. Since all the non-platform code will happily run under this new
‘architecture’, we can then write tests which run quickly under x86
Linux (or another Linux for that matter). This U-Boot 'architecture'
should build natively on any 32/64-bit Linux machine since it just
uses standard Linux system calls. Calls to Linux would be entirely
within this arch/native subdirectory.

Benefit
===
What will this buy us? Well we can do things like:

- Create a test SPI flash device, which is file-backed. Use this to
write a test of the cmd_sf layer by issuing a series of commands and
making sure that the correct SPI flash contents is obtained

- Create a test MMC or IDE device, backed by a file. Use this to issue
ext2 and fat commands to manipulate the filesystem. Then loopback
mount the file and check from Linux that U-Boot did the right thing

- Create a test Ethernet device with a mocked remote host attached.
Use this to issue network commands like bootp and tftp and check that
the correct results are obtained.

Ultimately (one day) we might have a set of unit tests for U-Boot
which can run to very quickly check that a patch does not break the
core U-Boot code.

Comments

At this early stage I am looking for comments on the concept - how
useful it is and how best to implement it.

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

Re: [U-Boot] [PATCH v2 1/3] net: Adds Fast Ethernet Controller driver for Armada100

[Ajay Bhargav]

- "Marek Vasut"  wrote:

> On Thursday, August 25, 2011 01:07:32 PM Ajay Bhargav wrote:
> > - "Marek Vasut"  wrote:
> > 
> > [...]
> > 
> > > > +static void abortdma(struct eth_device *dev)
> > > > +{
> > > > +   struct armdfec_device *darmdfec = to_darmdfec(dev);
> > > > +   struct armdfec_reg *regs = darmdfec->regs;
> > > > +   int delay;
> > > > +   int maxretries = 40;
> > > > +
> > > > +   do {
> > > > +   writel(SDMA_CMD_AR | SDMA_CMD_AT, ®s->sdma_cmd);
> > > > +   udelay(100);
> > > > +
> > > > +   delay = 10;
> > > > +   while ((readl(®s->sdma_cmd) &
> > > > +   (SDMA_CMD_AR | SDMA_CMD_AT))
> > > > +   && delay-- > 0) {
> > > > +   udelay(10);
> > > > +   }
> > > > +   } while (maxretries-- > 0 && delay <= 0);
> > > 
> > > Didn't I comment on this one in V1?
> > 
> > I modified it as follows... Is it more readable now? :)
> > 
> > while (maxretries--) {
> > writel(SDMA_CMD_AR | SDMA_CMD_AT, ®s->sdma_cmd);
> > udelay(100);
> > 
> > delay = 10;
> > while ((readl(®s->sdma_cmd) & (SDMA_CMD_AR | SDMA_CMD_AT))
> > && delay--)
> > udelay(10);
> > if(delay)
> > break;
> 
>   delay = 10;
>   while (--delay) {
>   tmp = readl(®s->sdma_cmd);
>   if (!(tmp & (SDMA_CMD_AR | SDMA_CMD_AT))
>   break;
>   udelay(10);
>   }
>   if (delay)
>   break;
> 
> It makes the code horizontally shorter. What do you think? Btw there's
> a rule in 
> U-Boot that multi-line statements must have braces.
> 

Thanks Marek, Yes it looks much better :) see the plus point on working with 
experts rather
running away? :D

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

Re: [U-Boot] [PATCH v2 2/3] Armada100: Enable Ethernet support for GplugD

[Ajay Bhargav]

- "Marek Vasut"  wrote:

> On Thursday, August 25, 2011 07:15:17 AM Ajay Bhargav wrote:
> > - "Marek Vasut"  wrote:
> > [...]
> > 
> > > > +/* Disable DCACHE */
> > > > +#define CONFIG_SYS_DCACHE_OFF
> > > 
> > > ARMADA100 is still ARMv5? Then maybe you can try Hong Xu's patches
> for
> > > dcache on
> > > armv5. You'll have to modify the ethernet driver to be aware of
> the
> > > dcache then
> > > though.
> > > 
> > > As dcache support is on the way, it might be worth it.
> > 
> > Yes ARMADA100 is ARMv5. I had problems with dcache enabled, driver
> get
> > stuck. Can you please link me to Hong Xu's patches? Is there a
> problem if
> > i keep it disabled?
> 
> http://lists.denx.de/pipermail/u-boot/2011-August/098405.html Look
> around this. 
> You'd better search for V2 of the patches or V3 in U-Boot ML archive.
> 
> There's no problem if you keep it disabled, but eventually, you'll
> have to 
> enable it ;-)
> 
> Cheers

Hi Marek,

I searched mail list after I emailed you.. There has been a lot of discussion
going on Hong Xu's patches. I think it would be better if I work on enabling
dcache once the patch is mainlined.

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

Re: [U-Boot] [PATCH v2 1/3] net: Adds Fast Ethernet Controller driver for Armada100

[Marek Vasut]

On Thursday, August 25, 2011 01:07:32 PM Ajay Bhargav wrote:
> - "Marek Vasut"  wrote:
> 
> [...]
> 
> > > +static void abortdma(struct eth_device *dev)
> > > +{
> > > + struct armdfec_device *darmdfec = to_darmdfec(dev);
> > > + struct armdfec_reg *regs = darmdfec->regs;
> > > + int delay;
> > > + int maxretries = 40;
> > > +
> > > + do {
> > > + writel(SDMA_CMD_AR | SDMA_CMD_AT, ®s->sdma_cmd);
> > > + udelay(100);
> > > +
> > > + delay = 10;
> > > + while ((readl(®s->sdma_cmd) &
> > > + (SDMA_CMD_AR | SDMA_CMD_AT))
> > > + && delay-- > 0) {
> > > + udelay(10);
> > > + }
> > > + } while (maxretries-- > 0 && delay <= 0);
> > 
> > Didn't I comment on this one in V1?
> 
> I modified it as follows... Is it more readable now? :)
> 
> while (maxretries--) {
>   writel(SDMA_CMD_AR | SDMA_CMD_AT, ®s->sdma_cmd);
>   udelay(100);
> 
>   delay = 10;
>   while ((readl(®s->sdma_cmd) & (SDMA_CMD_AR | SDMA_CMD_AT))
>   && delay--)
>   udelay(10);
>   if(delay)
>   break;

delay = 10;
while (--delay) {
tmp = readl(®s->sdma_cmd);
if (!(tmp & (SDMA_CMD_AR | SDMA_CMD_AT))
break;
udelay(10);
}
if (delay)
break;

It makes the code horizontally shorter. What do you think? Btw there's a rule 
in 
U-Boot that multi-line statements must have braces.

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

Re: [U-Boot] [PATCH v2 1/3] net: Adds Fast Ethernet Controller driver for Armada100

[Marek Vasut]

On Thursday, August 25, 2011 07:21:25 AM Ajay Bhargav wrote:
> - "Marek Vasut"  wrote:
> > On Wednesday, August 24, 2011 03:07:18 PM Ajay Bhargav wrote:
> > > This patch adds support for Fast Ethernet Controller driver for
> > > Armada100 series.
> > > 
> > > Signed-off-by: Ajay Bhargav 
> > > ---
> > 
> > [...]
> 
> [...]
> 
> > > +
> > > +static int armdfec_phy_timeout(u32 reg, u32 flag, int cond)
> > > +{
> > > + u32 timeout = PHY_WAIT_ITERATIONS;
> > > + while (--timeout) {
> > > + if (cond && (readl(reg) & flag))
> > > + break;
> > > + else if (!cond && !(readl(reg) & flag))
> > 
> > You can read the register into some temporary variable so you don't
> > need the
> > readl() at two places.
> 
> readl will be called only once... do i really need a temp var?
> 

I think it'll help the readability a bit.

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

Re: [U-Boot] [PATCH v2 1/3] net: Adds Fast Ethernet Controller driver for Armada100

[Marek Vasut]

On Thursday, August 25, 2011 07:24:22 AM Ajay Bhargav wrote:
> - "Marek Vasut"  wrote:
> > On Wednesday, August 24, 2011 05:42:06 PM Mike Frysinger wrote:
> > > On Wednesday, August 24, 2011 09:07:18 Ajay Bhargav wrote:
> > > > +   darmdfec->p_rxdesc = (struct rx_desc *)
> > 
> > memalign(PKTALIGN,
> > 
> > > > +   ARMDFEC_RXQ_DESC_ALIGNED_SIZE * RINGSZ +
> > 
> > 1);
> > 
> > > memalign() returns a void*, so you shouldnt need to cast its return
> > 
> > value
> > 
> > > (you do this a couple of times)
> > > 
> > > > +   /* Read mac from env if available */
> > > > +   eth_getenv_enetaddr("ethaddr", dev->enetaddr);
> > > 
> > > you shouldnt need to do this.  the higher layers will take care of
> > 
> > this for
> > 
> > > you when you set write_hwaddr
> > > 
> > > also, it seems like some of my previous feedback wasnt addressed ?
> > 
> > I have exactly the same feeling :-(
> > 
> > Ajay, please go through the feedback, if you don't understand
> > something, just
> > ask instead of hoping we won't notice ... we will, we see everything
> > ;-)
> > 
> > Cheers
> 
> I did go through your feedbacks.. My apologies if I missed. Marek, Its good
> for me that you guys are monitoring :) it will surely help me to write a
> better code :)

It's good thing you don't whine and run away ... some people do. Btw. your code 
is quite good, it just need the finishing touch :)

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

Re: [U-Boot] [PATCH v2 2/3] Armada100: Enable Ethernet support for GplugD

[Marek Vasut]

On Thursday, August 25, 2011 07:15:17 AM Ajay Bhargav wrote:
> - "Marek Vasut"  wrote:
> [...]
> 
> > > +/* Disable DCACHE */
> > > +#define CONFIG_SYS_DCACHE_OFF
> > 
> > ARMADA100 is still ARMv5? Then maybe you can try Hong Xu's patches for
> > dcache on
> > armv5. You'll have to modify the ethernet driver to be aware of the
> > dcache then
> > though.
> > 
> > As dcache support is on the way, it might be worth it.
> 
> Yes ARMADA100 is ARMv5. I had problems with dcache enabled, driver get
> stuck. Can you please link me to Hong Xu's patches? Is there a problem if
> i keep it disabled?

http://lists.denx.de/pipermail/u-boot/2011-August/098405.html Look around this. 
You'd better search for V2 of the patches or V3 in U-Boot ML archive.

There's no problem if you keep it disabled, but eventually, you'll have to 
enable it ;-)

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

Re: [U-Boot] [PATCH V3 4/8] omap-common/spl: Add linux boot to SPL

[Andreas Bießmann]

Dear Simon,

Am 25.08.2011 10:33, schrieb Simon Schwarz:
> This adds Linux booting to the SPL
> 
> Related CONFIGs:
> CONFIG_SPL_OS_BOOT
>   Activates/Deactivates the OS booting feature
> CONFIG_SPL_OS_BOOT_KEY
>   defines the IO-pin number u-boot switch - if pressed u-boot is booted
> CONFIG_SYS_SPL_MACHID
>   Machine ID of the used board
> CONFIG_SYS_NAND_SPL_KERNEL_OFFS
>   Offset in NAND of direct boot kernel image to use in SPL
> CONFIG_SYS_SPL_ARGS_ADDR
>   Address where the kernel boot arguments are expected - this is normaly
>   RAM-begin + 0x100
> 
> Signed-off-by: Simon Schwarz 
> ---
> 
> V2 changes:
> nothing
> 
> V3 changes:
> nothing
> ---
>  arch/arm/cpu/armv7/omap-common/spl.c |   48 -
>  include/configs/devkit8000.h |7 +++-
>  2 files changed, 51 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv7/omap-common/spl.c 
> b/arch/arm/cpu/armv7/omap-common/spl.c
> index c76fea6..9c22c7a 100644
> --- a/arch/arm/cpu/armv7/omap-common/spl.c
> +++ b/arch/arm/cpu/armv7/omap-common/spl.c
> @@ -35,6 +35,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  
> @@ -63,6 +64,25 @@ void board_init_f(ulong dummy)
>   relocate_code(CONFIG_SPL_STACK, &gdata, CONFIG_SPL_TEXT_BASE);
>  }
>  
> +#ifdef CONFIG_SPL_OS_BOOT

Is this required? -ffunction-sections and --gc-sections should do he job.

> +/* Return the value of the U-boot key
> + *
> + * RETURN
> + * 0 if not pressed
> + * positiv if pressed
> + */
> +int spl_uboot_key(void)
> +{
> + int val = 0;
> + if (!omap_request_gpio(CONFIG_SPL_OS_BOOT_KEY)) {
> + omap_set_gpio_direction(CONFIG_SPL_OS_BOOT_KEY, 1);
> + val = omap_get_gpio_datain(CONFIG_SPL_OS_BOOT_KEY);
> + omap_free_gpio(CONFIG_SPL_OS_BOOT_KEY);
> + }
> + return !val;
> +}
> +#endif  /* CONFIG_SPL_OS_BOOT */
> +
>  void spl_parse_image_header(const struct image_header *header)
>  {
>   u32 header_size = sizeof(struct image_header);
> @@ -90,7 +110,25 @@ void spl_parse_image_header(const struct image_header 
> *header)
>   }
>  }
>  
> -static void jump_to_image_no_args(void)
> +#ifdef CONFIG_SPL_OS_BOOT

here too.

> +/* This function jumps to an image with argument. Normally an FDT or ATAGS
> + * image.
> + * arg: Pointer to paramter image in RAM
> + */
> +void jump_to_image_linux(void *arg)
> +{
> + debug("Entering kernel arg pointer: 0x%X\n", arg);
> + typedef void (*image_entry_arg_t)(int, int, void *)
> + __attribute__ ((noreturn));
> + image_entry_arg_t image_entry =
> + (image_entry_arg_t) spl_image.entry_point;
> + /* cleanup_before_linux(); */ /*write SPL function for that*/
> + image_entry(0, CONFIG_SYS_SPL_MACHID, arg);

the MACHID is saved in gd->bd, couldn't this be used here?
BTW: You missed setting CONFIG_SYS_SPL_MACHID in your board
configuration header in this patch. Where is it done?

> +}
> +void jump_to_image_linux(void *) __attribute__ ((noreturn));
> +#endif
> +
> +void jump_to_image_no_args(void)
>  {
>   typedef void (*image_entry_noargs_t)(void)__attribute__ ((noreturn));
>   image_entry_noargs_t image_entry =
> @@ -99,8 +137,8 @@ static void jump_to_image_no_args(void)
>   debug("image entry point: 0x%X\n", spl_image.entry_point);
>   image_entry();
>  }
> -
>  void jump_to_image_no_args(void) __attribute__ ((noreturn));
> +
>  void board_init_r(gd_t *id, ulong dummy)
>  {
>   u32 boot_device;
> @@ -134,6 +172,12 @@ void board_init_r(gd_t *id, ulong dummy)
>   debug("Jumping to U-Boot\n");
>   jump_to_image_no_args();
>   break;
> +#ifdef CONFIG_SPL_OS_BOOT
> + case IH_OS_LINUX:
> + debug("Jumping to Linux\n");
> + jump_to_image_linux((void *)CONFIG_SYS_SPL_ARGS_ADDR);
> + break;
> +#endif
>   default:
>   puts("Unsupported OS image.. Jumping nevertheless..\n");
>   jump_to_image_no_args();
> diff --git a/include/configs/devkit8000.h b/include/configs/devkit8000.h
> index 4d0573c..3897ab4 100644
> --- a/include/configs/devkit8000.h
> +++ b/include/configs/devkit8000.h
> @@ -38,7 +38,7 @@
>  #define CONFIG_OMAP3430  1   /* which is in a 3430 */
>  #define CONFIG_OMAP3_DEVKIT8000  1   /* working with DevKit8000 */
>  
> -#define  CONFIG_SYS_TEXT_BASE0x80008000
> +#define  CONFIG_SYS_TEXT_BASE0x8010
>  
>  #define CONFIG_SDRC  /* The chip has SDRC controller */
>  
> @@ -328,7 +328,7 @@
>  #define CONFIG_SPL_MAX_SIZE  0xB400  /* 45 K */
>  #define CONFIG_SPL_STACK LOW_LEVEL_SRAM_STACK
>  
> -#define CONFIG_SPL_BSS_START_ADDR0x8000 /*CONFIG_SYS_SDRAM_BASE*/
> +#define CONFIG_SPL_BSS_START_ADDR0x8500 /* leave space for bootargs*/
>  #define CONFIG_SPL_BSS_MAX_SIZE  0x8
>  
>  /* NAND boot config */
> @@ -358,6 +358,9 @@
>  #define CON

Re: [U-Boot] [PATCH V3 0/8] SPL Linux boot

[Simon Schwarz]

Dear Wolfgang Denk,

On 08/25/2011 12:17 PM, Wolfgang Denk wrote:
> Dear Simon Schwarz,
>
> In message<1314261196-23197-1-git-send-email-simonschwarz...@gmail.com>  you 
> wrote:
>> Adds direct Linux boot to SPL. It implements a savebp command to save
>> ATAGS or FDT to NAND flash. The kernel image has to be in place for this!
>
> Thanks for this work.  It is highly appreciated.
>
>> checkpatch whines about not using strict_strtoull - since this is not
>> available - I can't change this.
>
> That's OK.
>
> A question ex ante: what is the "bp" in "savebp" supposed to mean? I
> cannot come up with a good interpretation (might might show the
> effects of me working in a way too hot environment, or might indicate
> that we should chose a better name).
Today: Definatly too hot ;)

It means "save boot parameters" - better proposals welcome.

>
> Best regards,
>
> Wolfgang Denk
>

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

Re: [U-Boot] [PATCH v2 1/3] net: Adds Fast Ethernet Controller driver for Armada100

[Ajay Bhargav]

- "Marek Vasut"  wrote:

[...]
> > +static void abortdma(struct eth_device *dev)
> > +{
> > +   struct armdfec_device *darmdfec = to_darmdfec(dev);
> > +   struct armdfec_reg *regs = darmdfec->regs;
> > +   int delay;
> > +   int maxretries = 40;
> > +
> > +   do {
> > +   writel(SDMA_CMD_AR | SDMA_CMD_AT, ®s->sdma_cmd);
> > +   udelay(100);
> > +
> > +   delay = 10;
> > +   while ((readl(®s->sdma_cmd) &
> > +   (SDMA_CMD_AR | SDMA_CMD_AT))
> > +   && delay-- > 0) {
> > +   udelay(10);
> > +   }
> > +   } while (maxretries-- > 0 && delay <= 0);
> 
> Didn't I comment on this one in V1?
> 

I modified it as follows... Is it more readable now? :)

while (maxretries--) {
writel(SDMA_CMD_AR | SDMA_CMD_AT, ®s->sdma_cmd);
udelay(100);

delay = 10;
while ((readl(®s->sdma_cmd) & (SDMA_CMD_AR | SDMA_CMD_AT))
&& delay--)
udelay(10);
if(delay)
break;
}

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

Re: [U-Boot] [PATCH V3 8/8] savebp: added Readme

[Andreas Bießmann]

Dear Simon,

Am 25.08.2011 10:33, schrieb Simon Schwarz:
> Adds a Readme for the savebp command

This patch should be merged with 'Add savebp command'
> 
> Signed-off-by: Simon Schwarz 
> ---
> 
> V2 changes:
> ADDED in V2
> 
> V3 changes:
> nothing
> ---
>  doc/README.commands.savebp |   28 
>  1 files changed, 28 insertions(+), 0 deletions(-)
>  create mode 100644 doc/README.commands.savebp
> 
> diff --git a/doc/README.commands.savebp b/doc/README.commands.savebp
> new file mode 100644
> index 000..dc05ee0
> --- /dev/null
> +++ b/doc/README.commands.savebp
> @@ -0,0 +1,28 @@
> +The savebp (=save boot parameters) is used to save a boot parameter image to
> +non-volatile memory.
> +
> +To execute the command everything has to be in place as if bootm should be
> +used.
> +(kernel image, initrd-image, fdt-image etc.)
> +
> +Call is:
> +savebp [ftd|atags] [nand_offset] [kernel_addr] [initrd_addr] [fdt_addr]
> +
> +Only the first parameter [ftd|atags] is mandatory if the others are left 
> blank
> +standard values are used.
> +
> +e.g:
> +savebp fdt 0x68 0x8200 0x8100 -
> +savebo atags
> +
> +typical call on OMAP3:
> +nandecc hw
> +nand read 0x8200 0x28 0x40 /* Read kernel image from NAND */

why read the kernel image here?

> +tftpboot 0x8100 devkit8000.dtb /* Read fdt */
> +savebp fdt 0x68 0x8200 0x8100 - /* Save the image */
> +
> +Behind the scene---
> +Atm the implementation is that we have /common/cmd_savebp.c which implements
> +the command tself and the subcommand calls to bootm.
  ^itself
> +Then the arch specific implementation of do_save_atags or do_savebp_fdt
> +in /arch/arm/lib is called.

(therefore a errormessage should/could be added to common/cmd_savebp.c,
if ARCH != ARM)

regrads

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

Re: [U-Boot] [PATCH V3 3/8] arm: Add savebp implementation for arm

[Andreas Bießmann]

Dear Simon,

Am 25.08.2011 10:33, schrieb Simon Schwarz:
> This adds the savebp implementation to the arm platform.

please reorder your series and let this come before 'Add savebp command'
cause that patch uses functionality from this one.

> Related CONFIGs:
> CONFIG_CMD_SAVEBP_WRITE_SIZE defines the size of the image to write
> 
> Signed-off-by: Simon Schwarz 
> ---
> 
> V2 changes:
> DEL _cosmetic_ old comment
> 
> V3 changes:
> nothing
> ---
>  arch/arm/include/asm/savebp.h |   27 
>  arch/arm/lib/Makefile |1 +
>  arch/arm/lib/savebp.c |   91 
> +
>  include/command.h |5 ++
>  include/configs/devkit8000.h  |1 +

documentation of  CONFIG_CMD_SAVEBP_WRITE_SIZE  is missing

> diff --git a/arch/arm/include/asm/savebp.h b/arch/arm/include/asm/savebp.h
> new file mode 100644
> index 000..3774e45
> --- /dev/null
> +++ b/arch/arm/include/asm/savebp.h
> @@ -0,0 +1,27 @@
> +/* Copyright (C) 2011
> + * Corscience GmbH & Co. KG - Simon Schwarz 
> + *
> + * 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 _SAVEBP_H_
> +#define _SAVEBP_H_
> +
> +extern bootm_headers_t images;

You made that available globally in your first patch of this series,
please remove that from first patch and move to this one.



BTW while reading this patch I got another idea to solve problem 'how
get we saved the boot information to '.
The required information regardless of whether it is ATAGS or FDT is
only a blob at some place in ram after the 'bootm x' commands used in
'Add savebp command'. Saving a blob from location X with size Y to
location Z is easy and already implemented.

So the only required thing is to get the 'blob' prepared in RAM. In my
opinion this could be a subcommand of bootm instead of a new command.

How about:

---8<---
# bootm savebp
...done boot information is @0x8100 with size 0x100
# nandecc hw
# nand erase ...
# nand write 8100 ...
--->8---

regards

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

[U-Boot] [RFC] himport_r() with the first call malloc() (with bin relocation) problem in NDS32 architecture

[馬克泡]

Hi all,

I'm doing the relocation work for NDS32 architecture.
Currently I've encountered bin relocation problem on malloc().
I've called malloc_bin_reloc() in my lib/board.c however the malloc
for env_relocate still get problem.
Hope someone whom has experience could help me and give me some suggestion.

The relocation parameters are list as below.
1. relocation Offset is: 03fc4000.
2. Three parameters to call relocate_code() and then passed to
board_init_r() is
addr_sp: 03f41f60, id: 03f41f6c, addr: 03fc4000
3. mem_malloc_init related parameters are:
mem_malloc_init: mem_malloc_start: 03F42000, size: 00082000
mem_malloc_init: mem_malloc_start: 03F42000, mem_malloc_end: 03FC4000

4. gd->reloc_off = dest_addr = 0x3fc4000 (The binary of u-boot is
relocated from 0x0 to 0x3fc4000.)

5. All cache is disabled.

6. The first call malloc() will be called is 29 bytes memory
allocation in himport_r().
Hence the procedure will into
"if (is_small_request(nb)) " in malloc() in dlmalloc.c.
The first malloc() will usually fail and execute malloc_extend_top().
However, after malloc_extend_top(), we should be able to get the first
allocated memory.

But I've found a really strange problem when the first malloc() within
himport_r().
That is I will continually get malloc() is fail if the first env
import in himport_r() is fail.
If I do the first memory allocate before the malloc() in himport_r(),
then the hash table and the continue
himport_r() will be success. Is there anything I should do before or
after bin relocation?
If anyone has experience with the same problem,
please give me some advice and suggestions for helping on this issue

The following two debugging log is the default env import process
which the first result is env import fail, and
the second result is env import success while the first malloc() is
called before himport_r() is called.

A. Default env import failed.
himport_r: htab addr: 03feb250, env addr: 03fe2e14, size: 001d,
sep: , flag: 
malloc: mem_malloc_start: 03F42000, mem_malloc_end: 03FC4000
val: victim: 03fea71c, last_remainder->fd: 03fea6f4, last_remaider: 03fea6f4
remainder_size: ffd8, top: 03fea6ec, MINSIZE: 0010
remainder_size: ffd8, top: 03f42000, MINSIZE: 0010
himport_r: can't malloc 29 bytes
ERROR: Environment import failed: errno = 12

at env_common.c:194/set_default_env()

malloc: mem_malloc_start: 03F42000, mem_malloc_end: 03FC4000
val: victim: 03fea734, last_remainder->fd: 03fea6f4, last_remaider: 03fea6f4
victim=top: top: addr: 03fea6f4, val: 03f42000
malloc: mem_malloc_start: 03F42000, mem_malloc_end: 03FC4000
val: victim: 03fea76c, last_remainder->fd: 03fea6f4, last_remaider: 03fea6f4
victim=top: top: addr: 03fea6f4, val: 03f42040
In:serial
Out:   serial
Err:   serial
malloc: mem_malloc_start: 03F42000, mem_malloc_end: 03FC4000
val: victim: 03fea704, last_remainder->fd: 03fea6f4, last_remaider: 03fea6f4
victim=top: top: addr: 03fea6f4, val: 03f420b8
## Error inserting "stdin" variable, errno=12 (nomem)

B. The default env is imported successfully and we need the first
malloc() been called before
the first call himport_r().

val: victim: 03fea7cc, last_remainder->fd: 03fea7a4, last_remaider: 03fea7a4
remainder_size: ffd8, top: 03fea79c, MINSIZE: 0010
after malloc_extend_top: remainder_size: ffd8, top: 03f42000,
MINSIZE: 0010
board_init_r: test: 
val: victim: 03fea7cc, last_remainder->fd: 03fea7a4, last_remaider: 03fea7a4
victim=top: top: addr: 03fea7a4, val: 03f42000, remainder_size: 0fd8
chunk2mem(victim): 03f42008
board_init_r: test: 03f42008
env_reloc
*** Warning - bad CRC, using default environment

himport_r: htab addr: 03feb300, env addr: 03fe2e3c, size: 001d,
sep: , flag: 
val: victim: 03fea7cc, last_remainder->fd: 03fea7a4, last_remaider: 03fea7a4
victim=top: top: addr: 03fea7a4, val: 03f42028, remainder_size: 0fb0
chunk2mem(victim): 03f42030
Destroy Hash Table: 03feb300 table = (null)
Create Hash Table: N=67
val: victim: 03fea9bc, last_remainder->fd: 03fea7a4, last_remaider: 03fea7a4
victim=top: top: addr: 03fea7a4, val: 03f42050, remainder_size: 0c78
chunk2mem(victim): 03f42058

Thank for your help.

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

Re: [U-Boot] [PATCH V3 2/8] Add savebp command

[Andreas Bießmann]

Dear Simon,

Am 25.08.2011 10:33, schrieb Simon Schwarz:
> This adds a savebp command to the u-boot.
> 
> Related config:
> CONFIG_CMD_SAVEBP
>   activate/deactivate the command
> CONFIG_CMD_SAVEBP_NAND_OFS
>   Offset in NAND to use
> CONFIG_SYS_NAND_SPL_KERNEL_OFFS
>   Offset in NAND of direct boot kernel image to use in SPL

This is not used in the code ... why defining it then (here)?

> CONFIG_SYS_SPL_ARGS_ADDR
>   Address where the kernel boot arguments are expected - this is
>   normally RAM-start + 0x100 (on ARM)

Well this is gd->bd->bi_boot_params (at least on ARM), so why don't you
use that parameter here?

> 
> Signed-off-by: Simon Schwarz 
> ---
> 
> V2 changes:
> CHG corrected bootm call. Now bootm is called with five parameters including
>   Address of FDT in RAM. This fixes the hang on savebp fdt call.
> ADD debug output of the actual bootm parameter call
> CHG help message
> 
> V3 changes:
> FIX added missing brackets
> ---
>  common/Makefile  |1 +
>  common/cmd_savebp.c  |  149 
> ++
>  include/configs/devkit8000.h |6 ++

where is the documentation?

>  3 files changed, 156 insertions(+), 0 deletions(-)
>  create mode 100644 common/cmd_savebp.c
> 
> diff --git a/common/Makefile b/common/Makefile
> index 124a427..0b42968 100644
> --- a/common/Makefile
> +++ b/common/Makefile
> @@ -158,6 +158,7 @@ COBJS-$(CONFIG_USB_STORAGE) += usb_storage.o
>  endif
>  COBJS-$(CONFIG_CMD_XIMG) += cmd_ximg.o
>  COBJS-$(CONFIG_YAFFS2) += cmd_yaffs2.o
> +COBJS-$(CONFIG_CMD_SAVEBP) += cmd_savebp.o
>  
>  # others
>  COBJS-$(CONFIG_DDR_SPD) += ddr_spd.o
> diff --git a/common/cmd_savebp.c b/common/cmd_savebp.c
> new file mode 100644
> index 000..4091ccb
> --- /dev/null
> +++ b/common/cmd_savebp.c
> @@ -0,0 +1,149 @@
> +/* Copyright (C) 2011
> + * Corscience GmbH & Co. KG - Simon Schwarz 
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +#include 
> +#include 
> +
> +#define TYPE_FDT 0
> +#define TYPE_ATAGS   1

should'nt this go into some header? How about enum here?

> +
> +static inline int str2off(const char *p, loff_t *num)
> +{
> + char *endptr;
> +
> + *num = simple_strtoull(p, &endptr, 16);
> + return *p != '\0' && *endptr == '\0';
> +}

could be merged with the one in cmd_nand.c. Maybe move the one from
cmd_nand.c to some header?

> +
> +int do_savebp(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> +{
> + loff_t offset;
> + int img_type = TYPE_ATAGS;
> + int ret = 0;
> + int bootm_argc = 5;
> + char *bootm_argsv[] = {"do_bootm", "xxx", "0x8200", "-",
> + "0x8100"};
> +
> + offset = (loff_t)CONFIG_CMD_SAVEBP_NAND_OFS;
> + bootm_argsv[2] = getenv("loadaddr");
> + /* - Validate args - */
> + switch (argc) {
> + case 6: /* 4. fdt addr */
   ^ wrong number?

> + if (strcmp(argv[5], "-"))
> + strcpy(bootm_argsv[4], argv[5]);

If one set '-' as fifth argument bootm_argsv will stay with your given
"0x8100" ... shouldn't the default argument be pre-calculated at
compile time. I guess the 0x8100 is CONFIG_SYS_SDRAM_BASE + 0x100 in
your case (or tell it CONFIG_SYS_SPL_ARGS_ADDR).

BTW: it is unsafe to use strcpy() here cause you may have some greater
string in 'src' than in 'dst' you should use strncpy() with strlen(dst)
as 'count' or even strdup() here.

In my opinion it would be best to use something like this here:

---8<---
char *bootm_argsv[5];

bootm_argsv[0] = "bootm";
...
bootm_argsv[4] = strdup(argv[5]);
...
--->8---

Or even

bootm_argsv[4] = argv[5];

But that have to be investigated, I don't know currently if it will work.

> + case 5: /* 5. initrd addr */
   ^ wrong number?

> + if (strcmp(argv[4], "-"))
> + strcpy(bootm_argsv[3], argv[4]);
> + case 4: /* 3. arg kernel addr */
> + if (strcmp(argv[3], "-"))
> + strcpy(bootm_argsv[2], argv[3]);
> + case 3: /* 2. arg offset */
> + if (strcmp(argv[2], "-")) {
> + if (!str2off(argv[2], &offset)) {
>

Re: [U-Boot] [PATCH V3 0/8] SPL Linux boot

[Wolfgang Denk]

Dear Simon Schwarz,

In message <1314261196-23197-1-git-send-email-simonschwarz...@gmail.com> you 
wrote:
> Adds direct Linux boot to SPL. It implements a savebp command to save  
> ATAGS or FDT to NAND flash. The kernel image has to be in place for this! 

Thanks for this work.  It is highly appreciated.

> checkpatch whines about not using strict_strtoull - since this is not  
> available - I can't change this. 

That's OK.

A question ex ante: what is the "bp" in "savebp" supposed to mean? I
cannot come up with a good interpretation (might might show the
effects of me working in a way too hot environment, or might indicate
that we should chose a better name).

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
WARNING:  This Product Attracts Every Other Piece  of  Matter in  the
Universe, Including the Products of Other Manufacturers, with a Force
Proportional  to the Product of the Masses and Inversely Proportional
to the Distance Between Them.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] xilinx_emaclite.c ping-pong macro names

[Wolfgang Denk]

Dear Michal Simek,

In message <4e561eb2.1010...@monstr.eu> you wrote:
>
> 1. Wolfgang if you see any patches for xilinx fpga and microblaze and I don't 
> reply
> that posts for a while, please ping me. I am more focus on other things and 
> not checking
> u-boot malling list so often - it will be better soon.

Sorry, but I don't have time and resources to track things like that -
there are way too many custodians and developers out there that I
could maintain a list of unanswered mails for each of them.

> 2. This change is caused by misunderstanding of xparameters.h for 
> microblaze/xilinx ppc boards.
> If someone wants to use looong xilinx xparameters from EDK/SDK project, not 
> the correct one generated by u-boot bsp,
> reach problems like this and wants to rename it.
> The reason why I decided several years ago to use u-boot BSP was that new 
> xparameters.h in board contains
> just minimum parameters which are important for u-boot. It wasn't and I 
> believe it is unacceptable to
> add hundreds line with unimportant macros which are totally unrelated to 
> u-boot.

I'm afraid I don;t understand what you want to tell me here.   In any
case, the patch cannot be applied as is, so if there are parts of it
that should be merged it has to be reposted anyway.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
There were meetings. There were always meetings. And they were  dull,
which is part of the reason they were meetings. Dull likes company.
- Terry Pratchett, _Making_Money_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] xilinx_emaclite.c ping-pong macro names

[Michal Simek]

Wolfgang Denk wrote:
> Dear alain.pet...@space.unibe.ch,
> 
> In message <20110415144908.16476jnz1wxcp...@mail.unibe.ch> you wrote:
>> Please find attached the checked patch. Sorry for the inconvenience.
> 
> Please send patches inline. No attachments!
> 
> And please stick to the rules with updated versions - mark the
> version in the Subject, and provide a Changelog.  See
> http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions
> 
> Also, please provide a meaningful Subject: and commit message - I have
> to admit that I have no idea what this patch is suposed to be about.
> 
>>  /*
>> - * TX - TX_PING & TX_PONG initialization
>> +  TX - TX_PING & TX_PONG initialization
>>   */
> 
> Why are you messing up a previously correct multinine comment into an
> incorrect one?
> 
> Please undo.
> 
>>  out_be32 (emaclite.baseaddress + XEL_TSR_OFFSET, 0);
>> @@ -155,12 +157,13 @@ static int emaclite_init(struct eth_device *dev, bd_t 
>> > *bis)
>>  while ((in_be32 (emaclite.baseaddress + XEL_TSR_OFFSET) &
>>  XEL_TSR_PROG_MAC_ADDR) != 0) ;
>>  
>> -#ifdef CONFIG_XILINX_EMACLITE_TX_PING_PONG
>> +#ifdef XILINX_EMACLITE_TX_PING_PONG
> 
> Why are you making this change?  Configurable parameteres are supposed
> to start with CONFIG_ resp. CONFIG_SYS_ ?
> 
>> -out_be32 (emaclite.baseaddress + XEL_TPLR_OFFSET, ENET_ADDR_LENGTH);
>> +out_be32 (emaclite.baseaddress + XEL_TPLR_OFFSET + XEL_BUFFER_OFFSET,
>> +ENET_ADDR_LENGTH);
> 
> This change appears to be unrelated to macro names.  Please split
> into separate patches, and provde information what you change and why.

I have found this old post.
Just some my comments.

1. Wolfgang if you see any patches for xilinx fpga and microblaze and I don't 
reply
that posts for a while, please ping me. I am more focus on other things and not 
checking
u-boot malling list so often - it will be better soon.

2. This change is caused by misunderstanding of xparameters.h for 
microblaze/xilinx ppc boards.
If someone wants to use looong xilinx xparameters from EDK/SDK project, not the 
correct one generated by u-boot bsp,
reach problems like this and wants to rename it.
The reason why I decided several years ago to use u-boot BSP was that new 
xparameters.h in board contains
just minimum parameters which are important for u-boot. It wasn't and I believe 
it is unacceptable to
add hundreds line with unimportant macros which are totally unrelated to u-boot.

Thanks,
Michal


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

Re: [U-Boot] [PATCH V3 1/8] arm: Add Prep subcommand support to bootm

[Andreas Bießmann]

Dear Simon,

Am 25.08.2011 10:33, schrieb Simon Schwarz:
> Adds prep subcommand to bootm implementation of ARM. When bootm is called with
> the subcommand prep the function stops right after ATAGS creation and before
> announce_and_cleanup.
> 
> This is used in savebp command
> 
> Signed-off-by: Simon Schwarz 
> 
> 
> V2 changes:
> nothing
> 
> V3 changes:
> nothing
> ---
>  arch/arm/lib/bootm.c |  116 +++--
>  common/cmd_bootm.c   |2 +-
>  2 files changed, 65 insertions(+), 53 deletions(-)
> 
> diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
> index 802e833..d3152ae 100644
> --- a/arch/arm/lib/bootm.c
> +++ b/arch/arm/lib/bootm.c
> @@ -1,4 +1,7 @@
> -/*
> +/* Copyright (C) 2011
> + * Corscience GmbH & Co. KG - Simon Schwarz 
> + *  - Added prep subcommand support
> + *
>   * (C) Copyright 2002
>   * Sysgo Real-Time Solutions, GmbH 
>   * Marius Groeger 
> @@ -55,7 +58,7 @@ static struct tag *params;
>  
>  static ulong get_sp(void);
>  #if defined(CONFIG_OF_LIBFDT)
> -static int bootm_linux_fdt(int machid, bootm_headers_t *images);
> +static int bootm_linux_fdt(int machid, bootm_headers_t *images, int flag);
>  #endif
>  
>  void arch_lmb_reserve(struct lmb *lmb)
> @@ -98,63 +101,67 @@ int do_bootm_linux(int flag, int argc, char *argv[], 
> bootm_headers_t *images)
>   bd_t*bd = gd->bd;
>   char*s;
>   int machid = bd->bi_arch_number;
> - void(*kernel_entry)(int zero, int arch, uint params);
> + void(*kernel_entry)(int zero, int arch, uint params) = NULL;

This should not be necessary, kernel_entry would be on bss which should
be initialized to zero by start.S.
>  
>  #ifdef CONFIG_CMDLINE_TAG
>   char *commandline = getenv ("bootargs");
>  #endif
> -
> - if ((flag != 0) && (flag != BOOTM_STATE_OS_GO))
> - return 1;
> -
> - s = getenv ("machid");
> - if (s) {
> - machid = simple_strtoul (s, NULL, 16);
> - printf ("Using machid 0x%x from environment\n", machid);
> - }
> -
> - show_boot_progress (15);
> + if ((flag != 0) && (!(flag & BOOTM_STATE_OS_GO ||
> +  flag & BOOTM_STATE_OS_PREP)))

switch'n'case would be much cleaner here. And seperating the
functionality into functions would be nice too.

> + return 1; /* subcommand not implemented */
> + else if ((flag == 0) || flag & BOOTM_STATE_OS_PREP) {
> + s = getenv("machid");
> + if (s) {
> + strict_strtoul(s, 16, (long unsigned int *) &machid);
> + printf("Using machid 0x%x from environment\n", machid);
> + }
> +
> + show_boot_progress(15);
>  
>  #ifdef CONFIG_OF_LIBFDT
> - if (images->ft_len)
> - return bootm_linux_fdt(machid, images);
> + if (images->ft_len)
> + return bootm_linux_fdt(machid, images, flag);
>  #endif
>  
> - kernel_entry = (void (*)(int, int, uint))images->ep;
> + kernel_entry = (void (*)(int, int, uint))images->ep;
>  
> - debug ("## Transferring control to Linux (at address %08lx) ...\n",
> -(ulong) kernel_entry);
> + debug("## Transferring control to Linux (at address %08lx)" \
> + "...\n", (ulong) kernel_entry);
>  
>  #if defined (CONFIG_SETUP_MEMORY_TAGS) || \
>  defined (CONFIG_CMDLINE_TAG) || \
>  defined (CONFIG_INITRD_TAG) || \
>  defined (CONFIG_SERIAL_TAG) || \
>  defined (CONFIG_REVISION_TAG)
> - setup_start_tag (bd);
> + setup_start_tag(bd);
>  #ifdef CONFIG_SERIAL_TAG
> - setup_serial_tag (¶ms);
> + setup_serial_tag(¶ms);
>  #endif
>  #ifdef CONFIG_REVISION_TAG
> - setup_revision_tag (¶ms);
> + setup_revision_tag(¶ms);
>  #endif
>  #ifdef CONFIG_SETUP_MEMORY_TAGS
> - setup_memory_tags (bd);
> + setup_memory_tags(bd);
>  #endif
>  #ifdef CONFIG_CMDLINE_TAG
> - setup_commandline_tag (bd, commandline);
> + setup_commandline_tag(bd, commandline);
>  #endif
>  #ifdef CONFIG_INITRD_TAG
> - if (images->rd_start && images->rd_end)
> - setup_initrd_tag (bd, images->rd_start, images->rd_end);
> + if (images->rd_start && images->rd_end)
> + setup_initrd_tag(bd, images->rd_start, images->rd_end);
>  #endif
> - setup_end_tag(bd);
> + setup_end_tag(bd);
>  #endif
> + if (flag & BOOTM_STATE_OS_PREP)
> + return 0;
> + }
>  
> - announce_and_cleanup();
> -
> - kernel_entry(0, machid, bd->bi_boot_params);
> - /* does not return */
> + if (flag == 0 || flag & BOOTM_STATE_OS_GO) {

flag == 0? Shouldn't that be flag == BOOTM_STATE_OS_GO?

> + announce_and_cleanup();
>  
> + kernel_entry(0, machid, bd->bi_boot_params);
> + /* does not return */
> + }
>   return 1;
>  }
>  
> @@ -174,10 +181,10 @@ static int fixup_m

Re: [U-Boot] [PATCH] dcache: Dcache line size aligned stack buffer allocation

[Wolfgang Denk]

Dear Lukasz Majewski,

In message <1314261435-29789-1-git-send-email-l.majew...@samsung.com> you wrote:
> This commit is defining new include/cache.h file, which defines macro
> needed for cache aligned buffers.
> ALLOC_CACHE_ALIGN_BUFFER shall be used in functions, which are using
> stack allocated buffers for DMA transfers.
> 
> Signed-off-by: Lukasz Majewski 
> Signed-off-by: Kyungmin Park 
> CC: Albert ARIBAUD 
> ---
>  include/cache.h |   42 ++
>  1 files changed, 42 insertions(+), 0 deletions(-)
>  create mode 100644 include/cache.h

I don't think it makes sense to create a new header file just for this
macro.  Please add this to an existing header file instead; if no
better place is found even to common.h

> +#if defined(CONFIG_SYS_CACHELINE_SIZE) && !defined(CONFIG_SYS_DCACHE_OFF)

Please omit this #ifdef.

CONFIG_SYS_CACHELINE_SIZE is a mandatory #define, and it's OK that a
build breaks when it's missing.  On the other hand I don;t se why this
macro needs top be removed when the data cache is off.

> +#define ALIGN_ADDR(addr) ((void *)(((unsigned long) addr + \
> + CONFIG_SYS_CACHELINE_SIZE - 1)  \
> +& ~(CONFIG_SYS_CACHELINE_SIZE - 1)))
> +

This is not needed. common.h defines ALIGN() which should be
sufficient here.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The use of Microsoft crippleware systems is a sin that  carries  with
it its own punishment.
 -- Tom Christiansen in <6bo3fr$pj8$5...@csnews.cs.colorado.edu>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH V2 8/9] ColdFire:Define the DM9000 byteswap for M5253 board.

[Jason Jin]

The M5253DEMO board swapped the io pins which make
the standard IO function did not work for dm9000.
Define the byte swap to use raw io for dm9000.

Signed-off-by: Jason Jin 
---
Changes for V2: rename the DM9000_BYTE_SWAPPED to CONFIG_DM9000_BYTE_SWAPPED

 include/configs/M5253DEMO.h |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/include/configs/M5253DEMO.h b/include/configs/M5253DEMO.h
index f2f3159..8120b68 100644
--- a/include/configs/M5253DEMO.h
+++ b/include/configs/M5253DEMO.h
@@ -95,6 +95,7 @@
 #  define DM9000_IOCONFIG_DM9000_BASE
 #  define DM9000_DATA  (CONFIG_DM9000_BASE + 4)
 #  undef CONFIG_DM9000_DEBUG
+#  define CONFIG_DM9000_BYTE_SWAPPED
 
 #  define CONFIG_OVERWRITE_ETHADDR_ONCE
 
-- 
1.6.4


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

[U-Boot] [PATCH V4 7/9] DM9000:Add a byte swap macro for dm9000 io operation.

[Jason Jin]

commit a45dde2293c816138e53c26eca6fd0322583f9a6 changed the dm9000
direct register access to standard IO. This should work
on the ColdFire platform as there are corresponding macros for
the LE devices. But the hardware settings on some ColdFire boards had
swapped the byte order which make the original macros such as out_le16
cannot work. To avoid changing the common io access code on ColdFire
platform, the DM9000_BYTE_SWAPPED define was added to make the dm9000 use
__raw* IO access on some ColdFire boards.

Signed-off-by: Jason Jin 
---
Changes for V2: Remove the 'volatile' in the macro.

Changes for V3: Seperate the dm9000 code support and the platform
code to two patches so that it can be accepted by different custodian.

Resend: Add Ben Warren

Changes for V4: rename the DM9000_BYTE_SWAPPED to CONFIG_DM9000_BYTE_SWAPPED

 drivers/net/dm9000x.c |   10 +-
 1 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/drivers/net/dm9000x.c b/drivers/net/dm9000x.c
index b5c5573..05cd8eb 100644
--- a/drivers/net/dm9000x.c
+++ b/drivers/net/dm9000x.c
@@ -116,13 +116,21 @@ static u8 DM9000_ior(int);
 static void DM9000_iow(int reg, u8 value);
 
 /* DM9000 network board routine  */
-
+#ifndef CONFIG_DM9000_BYTE_SWAPPED
 #define DM9000_outb(d,r) writeb(d, (volatile u8 *)(r))
 #define DM9000_outw(d,r) writew(d, (volatile u16 *)(r))
 #define DM9000_outl(d,r) writel(d, (volatile u32 *)(r))
 #define DM9000_inb(r) readb((volatile u8 *)(r))
 #define DM9000_inw(r) readw((volatile u16 *)(r))
 #define DM9000_inl(r) readl((volatile u32 *)(r))
+#else
+#define DM9000_outb(d, r) __raw_writeb(d, r)
+#define DM9000_outw(d, r) __raw_writew(d, r)
+#define DM9000_outl(d, r) __raw_writel(d, r)
+#define DM9000_inb(r) __raw_readb(r)
+#define DM9000_inw(r) __raw_readw(r)
+#define DM9000_inl(r) __raw_readl(r)
+#endif
 
 #ifdef CONFIG_DM9000_DEBUG
 static void
-- 
1.6.4


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

[U-Boot] [PATCH] dcache: Dcache line size aligned stack buffer allocation

[Lukasz Majewski]

This commit is defining new include/cache.h file, which defines macro
needed for cache aligned buffers.
ALLOC_CACHE_ALIGN_BUFFER shall be used in functions, which are using
stack allocated buffers for DMA transfers.

Signed-off-by: Lukasz Majewski 
Signed-off-by: Kyungmin Park 
CC: Albert ARIBAUD 
---
 include/cache.h |   42 ++
 1 files changed, 42 insertions(+), 0 deletions(-)
 create mode 100644 include/cache.h

diff --git a/include/cache.h b/include/cache.h
new file mode 100644
index 000..d06a0ac
--- /dev/null
+++ b/include/cache.h
@@ -0,0 +1,42 @@
+/*
+ * Copyright (C) 2011 Samsung Electronics
+ * Łukasz Majewski 
+ *
+ * Configuation settings for the SAMSUNG Universal (s5pc100) board.
+ *
+ * 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 __GENERIC_CACHE_H_
+#define __GENERIC_CACHE_H_
+
+#if defined(CONFIG_SYS_CACHELINE_SIZE) && !defined(CONFIG_SYS_DCACHE_OFF)
+#define ALIGN_ADDR(addr) ((void *)(((unsigned long) addr + \
+   CONFIG_SYS_CACHELINE_SIZE - 1)  \
+  & ~(CONFIG_SYS_CACHELINE_SIZE - 1)))
+
+#define ALLOC_CACHE_ALIGN_BUFFER(type, name, size) \
+   char *__##name[size + CONFIG_SYS_CACHELINE_SIZE]; \
+   type *name = ALIGN_ADDR(__##name);
+#else
+#define ALLOC_CACHE_ALIGN_BUFFER(type, name, size) \
+   type name[size];
+#endif
+
+#endif  /* __GENERIC_CACHE_H_ */
-- 
1.7.2.3

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

[U-Boot] [PATCH V3 7/8] omap-common: fixes BSS overwriting problem

[Simon Schwarz]

spl_nand overwrote BSS section because it reads a whole block everytime. Now
loads the block to spare area and just copy the needed junk to destination.
Whole block read is necessary for ecc check!

Signed-off-by: Simon Schwarz 
---

V2 changes:
nothing

V3 changes:
nothing
---
 arch/arm/cpu/armv7/omap-common/spl_nand.c |   21 ++---
 1 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap-common/spl_nand.c 
b/arch/arm/cpu/armv7/omap-common/spl_nand.c
index 06254b2..408892f 100644
--- a/arch/arm/cpu/armv7/omap-common/spl_nand.c
+++ b/arch/arm/cpu/armv7/omap-common/spl_nand.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -33,6 +34,7 @@
 void spl_nand_load_image(void)
 {
struct image_header *header;
+   int *src, *dst;
switch (omap_boot_mode()) {
case NAND_MODE_HW_ECC:
debug("spl: nand - using hw ecc\n");
@@ -49,16 +51,29 @@ void spl_nand_load_image(void)
 #ifdef CONFIG_SPL_OS_BOOT
if (!spl_uboot_key()) {
/* load parameter image */
-   nand_spl_load_image(CONFIG_CMD_SAVEBP_NAND_OFS ,
+   /* load to temp position since nand_spl_load_image reads
+* a whole block which is typically larger than
+* CONFIG_CMD_SAVEBP_WRITE_SIZE therefore may overwrite
+* following sections like BSS */
+   nand_spl_load_image(CONFIG_CMD_SAVEBP_NAND_OFS,
CONFIG_CMD_SAVEBP_WRITE_SIZE,
-   (void *)CONFIG_SYS_SPL_ARGS_ADDR);
+   (void *)CONFIG_SYS_TEXT_BASE);
+   /* copy to destintion */
+   for (dst = (int *)CONFIG_SYS_SPL_ARGS_ADDR,
+   src = (int *)CONFIG_SYS_TEXT_BASE;
+   src < (int *)(CONFIG_SYS_TEXT_BASE +
+   CONFIG_CMD_SAVEBP_WRITE_SIZE);
+   src++, dst++) {
+   writel(readl(src), dst);
+   }
 
/* load linux */
nand_spl_load_image(CONFIG_SYS_NAND_SPL_KERNEL_OFFS,
CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
spl_parse_image_header(header);
nand_spl_load_image(CONFIG_SYS_NAND_SPL_KERNEL_OFFS,
-   spl_image.size, (void *)spl_image.load_addr);
+   spl_image.size,
+   (void *)spl_image.load_addr - sizeof(header));
} else
 #endif
{
-- 
1.7.4.1

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

[U-Boot] [PATCH V3 8/8] savebp: added Readme

[Simon Schwarz]

Adds a Readme for the savebp command

Signed-off-by: Simon Schwarz 
---

V2 changes:
ADDED in V2

V3 changes:
nothing
---
 doc/README.commands.savebp |   28 
 1 files changed, 28 insertions(+), 0 deletions(-)
 create mode 100644 doc/README.commands.savebp

diff --git a/doc/README.commands.savebp b/doc/README.commands.savebp
new file mode 100644
index 000..dc05ee0
--- /dev/null
+++ b/doc/README.commands.savebp
@@ -0,0 +1,28 @@
+The savebp (=save boot parameters) is used to save a boot parameter image to
+non-volatile memory.
+
+To execute the command everything has to be in place as if bootm should be
+used.
+(kernel image, initrd-image, fdt-image etc.)
+
+Call is:
+savebp [ftd|atags] [nand_offset] [kernel_addr] [initrd_addr] [fdt_addr]
+
+Only the first parameter [ftd|atags] is mandatory if the others are left blank
+standard values are used.
+
+e.g:
+savebp fdt 0x68 0x8200 0x8100 -
+savebo atags
+
+typical call on OMAP3:
+nandecc hw
+nand read 0x8200 0x28 0x40 /* Read kernel image from NAND */
+tftpboot 0x8100 devkit8000.dtb /* Read fdt */
+savebp fdt 0x68 0x8200 0x8100 - /* Save the image */
+
+Behind the scene---
+Atm the implementation is that we have /common/cmd_savebp.c which implements
+the command tself and the subcommand calls to bootm.
+Then the arch specific implementation of do_save_atags or do_savebp_fdt
+in /arch/arm/lib is called.
-- 
1.7.4.1

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

[U-Boot] [PATCH V3 6/8] omap-common: Add NAND SPL linux booting

[Simon Schwarz]

This implements booting of Linux from NAND in SPL

Signed-off-by: Simon Schwarz 
---

V2 changes:
nothing

V3 changes:
nothing
---
 arch/arm/cpu/armv7/omap-common/spl_nand.c |   48 +++-
 1 files changed, 32 insertions(+), 16 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap-common/spl_nand.c 
b/arch/arm/cpu/armv7/omap-common/spl_nand.c
index af02a59..06254b2 100644
--- a/arch/arm/cpu/armv7/omap-common/spl_nand.c
+++ b/arch/arm/cpu/armv7/omap-common/spl_nand.c
@@ -46,26 +46,42 @@ void spl_nand_load_image(void)
 
/*use CONFIG_SYS_TEXT_BASE as temporary storage area */
header = (struct image_header *)(CONFIG_SYS_TEXT_BASE);
+#ifdef CONFIG_SPL_OS_BOOT
+   if (!spl_uboot_key()) {
+   /* load parameter image */
+   nand_spl_load_image(CONFIG_CMD_SAVEBP_NAND_OFS ,
+   CONFIG_CMD_SAVEBP_WRITE_SIZE,
+   (void *)CONFIG_SYS_SPL_ARGS_ADDR);
 
+   /* load linux */
+   nand_spl_load_image(CONFIG_SYS_NAND_SPL_KERNEL_OFFS,
+   CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
+   spl_parse_image_header(header);
+   nand_spl_load_image(CONFIG_SYS_NAND_SPL_KERNEL_OFFS,
+   spl_image.size, (void *)spl_image.load_addr);
+   } else
+#endif
+   {
 #ifdef CONFIG_NAND_ENV_DST
-   nand_spl_load_image(CONFIG_ENV_OFFSET,
-   CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
-   spl_parse_image_header(header);
-   nand_spl_load_image(CONFIG_ENV_OFFSET, spl_image.size,
-   (void *)image_load_addr);
+   nand_spl_load_image(CONFIG_ENV_OFFSET,
+   CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
+   spl_parse_image_header(header);
+   nand_spl_load_image(CONFIG_ENV_OFFSET, spl_image.size,
+   (void *)spl_image.load_addr);
 #ifdef CONFIG_ENV_OFFSET_REDUND
-   nand_spl_load_image(CONFIG_ENV_OFFSET_REDUND,
-   CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
-   spl_parse_image_header(header);
-   nand_spl_load_image(CONFIG_ENV_OFFSET_REDUND, spl_image.size,
-   (void *)image_load_addr);
+   nand_spl_load_image(CONFIG_ENV_OFFSET_REDUND,
+   CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
+   spl_parse_image_header(header);
+   nand_spl_load_image(CONFIG_ENV_OFFSET_REDUND, spl_image.size,
+   (void *)spl_image.load_addr);
 #endif
 #endif
-   /* Load u-boot */
-   nand_spl_load_image(CONFIG_SYS_NAND_U_BOOT_OFFS,
-   CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
-   spl_parse_image_header(header);
-   nand_spl_load_image(CONFIG_SYS_NAND_U_BOOT_OFFS,
-   spl_image.size, (void *)spl_image.load_addr);
+   /* Load u-boot */
+   nand_spl_load_image(CONFIG_SYS_NAND_U_BOOT_OFFS,
+   CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
+   spl_parse_image_header(header);
+   nand_spl_load_image(CONFIG_SYS_NAND_U_BOOT_OFFS,
+   spl_image.size, (void *)spl_image.load_addr);
+   }
nand_deselect();
 }
-- 
1.7.4.1

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

[U-Boot] [PATCH V3 5/8] devkit8000/spl: init GPMC for dm9000 in SPL

[Simon Schwarz]

Linux crashes if the GPMC isn't configured for the dm9000.

Signed-off-by: Simon Schwarz 
---

V2 changes:
nothing

V3 changes:
nothing
---
 arch/arm/cpu/armv7/omap-common/spl.c |1 +
 arch/arm/include/asm/omap_common.h   |2 ++
 board/timll/devkit8000/devkit8000.c  |   33 -
 3 files changed, 27 insertions(+), 9 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap-common/spl.c 
b/arch/arm/cpu/armv7/omap-common/spl.c
index 9c22c7a..0c38bbb 100644
--- a/arch/arm/cpu/armv7/omap-common/spl.c
+++ b/arch/arm/cpu/armv7/omap-common/spl.c
@@ -175,6 +175,7 @@ void board_init_r(gd_t *id, ulong dummy)
 #ifdef CONFIG_SPL_OS_BOOT
case IH_OS_LINUX:
debug("Jumping to Linux\n");
+   spl_board_prepare_for_linux();
jump_to_image_linux((void *)CONFIG_SYS_SPL_ARGS_ADDR);
break;
 #endif
diff --git a/arch/arm/include/asm/omap_common.h 
b/arch/arm/include/asm/omap_common.h
index 015cede..0906f49 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -77,6 +77,8 @@ u32 omap_boot_mode(void);
 
 /* SPL common function s*/
 void spl_parse_image_header(const struct image_header *header);
+int spl_uboot_key(void);
+void spl_board_prepare_for_linux(void);
 
 /* NAND SPL functions */
 void spl_nand_load_image(void);
diff --git a/board/timll/devkit8000/devkit8000.c 
b/board/timll/devkit8000/devkit8000.c
index 9b53742..3dd0eeb 100644
--- a/board/timll/devkit8000/devkit8000.c
+++ b/board/timll/devkit8000/devkit8000.c
@@ -62,6 +62,18 @@ int board_init(void)
return 0;
 }
 
+/* Configure GPMC registers for DM9000 */
+static void gpmc_dm9000_config(void)
+{
+   writel(NET_GPMC_CONFIG1, &gpmc_cfg->cs[6].config1);
+   writel(NET_GPMC_CONFIG2, &gpmc_cfg->cs[6].config2);
+   writel(NET_GPMC_CONFIG3, &gpmc_cfg->cs[6].config3);
+   writel(NET_GPMC_CONFIG4, &gpmc_cfg->cs[6].config4);
+   writel(NET_GPMC_CONFIG5, &gpmc_cfg->cs[6].config5);
+   writel(NET_GPMC_CONFIG6, &gpmc_cfg->cs[6].config6);
+   writel(NET_GPMC_CONFIG7, &gpmc_cfg->cs[6].config7);
+}
+
 /*
  * Routine: misc_init_r
  * Description: Configure board specific parts
@@ -80,14 +92,7 @@ int misc_init_r(void)
 #endif
 
 #ifdef CONFIG_DRIVER_DM9000
-   /* Configure GPMC registers for DM9000 */
-   writel(NET_GPMC_CONFIG1, &gpmc_cfg->cs[6].config1);
-   writel(NET_GPMC_CONFIG2, &gpmc_cfg->cs[6].config2);
-   writel(NET_GPMC_CONFIG3, &gpmc_cfg->cs[6].config3);
-   writel(NET_GPMC_CONFIG4, &gpmc_cfg->cs[6].config4);
-   writel(NET_GPMC_CONFIG5, &gpmc_cfg->cs[6].config5);
-   writel(NET_GPMC_CONFIG6, &gpmc_cfg->cs[6].config6);
-   writel(NET_GPMC_CONFIG7, &gpmc_cfg->cs[6].config7);
+   gpmc_dm9000_config();
 
/* Use OMAP DIE_ID as MAC address */
if (!eth_getenv_enetaddr("ethaddr", enetaddr)) {
@@ -119,7 +124,7 @@ void set_muxconf_regs(void)
MUX_DEVKIT8000();
 }
 
-#if defined(CONFIG_DRIVER_DM9000) & !defined(CONFIG_SPL_BUILD)
+#ifdef CONFIG_DRIVER_DM9000
 /*
  * Routine: board_eth_init
  * Description: Setting up the Ethernet hardware.
@@ -129,3 +134,13 @@ int board_eth_init(bd_t *bis)
return dm9000_initialize(bis);
 }
 #endif
+
+#ifdef CONFIG_SPL_OS_BOOT
+/* do board specific preperation before SPL
+ * Linux boot */
+void spl_board_prepare_for_linux(void)
+{
+   gpmc_dm9000_config();
+}
+
+#endif
-- 
1.7.4.1

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

[U-Boot] [PATCH V3 4/8] omap-common/spl: Add linux boot to SPL

[Simon Schwarz]

This adds Linux booting to the SPL

Related CONFIGs:
CONFIG_SPL_OS_BOOT
Activates/Deactivates the OS booting feature
CONFIG_SPL_OS_BOOT_KEY
defines the IO-pin number u-boot switch - if pressed u-boot is booted
CONFIG_SYS_SPL_MACHID
Machine ID of the used board
CONFIG_SYS_NAND_SPL_KERNEL_OFFS
Offset in NAND of direct boot kernel image to use in SPL
CONFIG_SYS_SPL_ARGS_ADDR
Address where the kernel boot arguments are expected - this is normaly
RAM-begin + 0x100

Signed-off-by: Simon Schwarz 
---

V2 changes:
nothing

V3 changes:
nothing
---
 arch/arm/cpu/armv7/omap-common/spl.c |   48 -
 include/configs/devkit8000.h |7 +++-
 2 files changed, 51 insertions(+), 4 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap-common/spl.c 
b/arch/arm/cpu/armv7/omap-common/spl.c
index c76fea6..9c22c7a 100644
--- a/arch/arm/cpu/armv7/omap-common/spl.c
+++ b/arch/arm/cpu/armv7/omap-common/spl.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -63,6 +64,25 @@ void board_init_f(ulong dummy)
relocate_code(CONFIG_SPL_STACK, &gdata, CONFIG_SPL_TEXT_BASE);
 }
 
+#ifdef CONFIG_SPL_OS_BOOT
+/* Return the value of the U-boot key
+ *
+ * RETURN
+ * 0 if not pressed
+ * positiv if pressed
+ */
+int spl_uboot_key(void)
+{
+   int val = 0;
+   if (!omap_request_gpio(CONFIG_SPL_OS_BOOT_KEY)) {
+   omap_set_gpio_direction(CONFIG_SPL_OS_BOOT_KEY, 1);
+   val = omap_get_gpio_datain(CONFIG_SPL_OS_BOOT_KEY);
+   omap_free_gpio(CONFIG_SPL_OS_BOOT_KEY);
+   }
+   return !val;
+}
+#endif  /* CONFIG_SPL_OS_BOOT */
+
 void spl_parse_image_header(const struct image_header *header)
 {
u32 header_size = sizeof(struct image_header);
@@ -90,7 +110,25 @@ void spl_parse_image_header(const struct image_header 
*header)
}
 }
 
-static void jump_to_image_no_args(void)
+#ifdef CONFIG_SPL_OS_BOOT
+/* This function jumps to an image with argument. Normally an FDT or ATAGS
+ * image.
+ * arg: Pointer to paramter image in RAM
+ */
+void jump_to_image_linux(void *arg)
+{
+   debug("Entering kernel arg pointer: 0x%X\n", arg);
+   typedef void (*image_entry_arg_t)(int, int, void *)
+   __attribute__ ((noreturn));
+   image_entry_arg_t image_entry =
+   (image_entry_arg_t) spl_image.entry_point;
+   /* cleanup_before_linux(); */ /*write SPL function for that*/
+   image_entry(0, CONFIG_SYS_SPL_MACHID, arg);
+}
+void jump_to_image_linux(void *) __attribute__ ((noreturn));
+#endif
+
+void jump_to_image_no_args(void)
 {
typedef void (*image_entry_noargs_t)(void)__attribute__ ((noreturn));
image_entry_noargs_t image_entry =
@@ -99,8 +137,8 @@ static void jump_to_image_no_args(void)
debug("image entry point: 0x%X\n", spl_image.entry_point);
image_entry();
 }
-
 void jump_to_image_no_args(void) __attribute__ ((noreturn));
+
 void board_init_r(gd_t *id, ulong dummy)
 {
u32 boot_device;
@@ -134,6 +172,12 @@ void board_init_r(gd_t *id, ulong dummy)
debug("Jumping to U-Boot\n");
jump_to_image_no_args();
break;
+#ifdef CONFIG_SPL_OS_BOOT
+   case IH_OS_LINUX:
+   debug("Jumping to Linux\n");
+   jump_to_image_linux((void *)CONFIG_SYS_SPL_ARGS_ADDR);
+   break;
+#endif
default:
puts("Unsupported OS image.. Jumping nevertheless..\n");
jump_to_image_no_args();
diff --git a/include/configs/devkit8000.h b/include/configs/devkit8000.h
index 4d0573c..3897ab4 100644
--- a/include/configs/devkit8000.h
+++ b/include/configs/devkit8000.h
@@ -38,7 +38,7 @@
 #define CONFIG_OMAP34301   /* which is in a 3430 */
 #define CONFIG_OMAP3_DEVKIT80001   /* working with DevKit8000 */
 
-#defineCONFIG_SYS_TEXT_BASE0x80008000
+#defineCONFIG_SYS_TEXT_BASE0x8010
 
 #define CONFIG_SDRC/* The chip has SDRC controller */
 
@@ -328,7 +328,7 @@
 #define CONFIG_SPL_MAX_SIZE0xB400  /* 45 K */
 #define CONFIG_SPL_STACK   LOW_LEVEL_SRAM_STACK
 
-#define CONFIG_SPL_BSS_START_ADDR  0x8000 /*CONFIG_SYS_SDRAM_BASE*/
+#define CONFIG_SPL_BSS_START_ADDR  0x8500 /* leave space for bootargs*/
 #define CONFIG_SPL_BSS_MAX_SIZE0x8
 
 /* NAND boot config */
@@ -358,6 +358,9 @@
 #define CONFIG_CMD_SAVEBP_WRITE_SIZE   0x400 /* 1024 byte */
 #define CONFIG_CMD_SAVEBP_NAND_OFS (CONFIG_SYS_NAND_SPL_KERNEL_OFFS+\
0x40)
+#define CONFIG_SPL_OS_BOOT
+#define CONFIG_SPL_OS_BOOT_KEY 26
+#define CONFIG_SYS_SPL_MACHID  MACH_TYPE_DEVKIT8000
 #define CONFIG_SYS_NAND_SPL_KERNEL_OFFS0x28
 #define CONFIG_SYS_SPL_ARGS_ADDR   (PHYS_SDRAM_1 + 0x100)
 #endif /* __CONFIG_H */
-- 
1.7.4.1

___
U-B

[U-Boot] [PATCH V3 3/8] arm: Add savebp implementation for arm

[Simon Schwarz]

This adds the savebp implementation to the arm platform.

Related CONFIGs:
CONFIG_CMD_SAVEBP_WRITE_SIZE defines the size of the image to write

Signed-off-by: Simon Schwarz 
---

V2 changes:
DEL _cosmetic_ old comment

V3 changes:
nothing
---
 arch/arm/include/asm/savebp.h |   27 
 arch/arm/lib/Makefile |1 +
 arch/arm/lib/savebp.c |   91 +
 include/command.h |5 ++
 include/configs/devkit8000.h  |1 +
 5 files changed, 125 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/include/asm/savebp.h
 create mode 100644 arch/arm/lib/savebp.c

diff --git a/arch/arm/include/asm/savebp.h b/arch/arm/include/asm/savebp.h
new file mode 100644
index 000..3774e45
--- /dev/null
+++ b/arch/arm/include/asm/savebp.h
@@ -0,0 +1,27 @@
+/* Copyright (C) 2011
+ * Corscience GmbH & Co. KG - Simon Schwarz 
+ *
+ * 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 _SAVEBP_H_
+#define _SAVEBP_H_
+
+extern bootm_headers_t images;
+
+#endif /* _SAVEBP_H_ */
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 300c8fa..abf7a6a 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -44,6 +44,7 @@ COBJS-y   += cache-cp15.o
 COBJS-$(CONFIG_SYS_L2_PL310) += cache-pl310.o
 COBJS-y+= interrupts.o
 COBJS-y+= reset.o
+COBJS-$(CONFIG_CMD_SAVEBP) += savebp.o
 SOBJS-$(CONFIG_USE_ARCH_MEMSET) += memset.o
 SOBJS-$(CONFIG_USE_ARCH_MEMCPY) += memcpy.o
 endif
diff --git a/arch/arm/lib/savebp.c b/arch/arm/lib/savebp.c
new file mode 100644
index 000..e0cfd83
--- /dev/null
+++ b/arch/arm/lib/savebp.c
@@ -0,0 +1,91 @@
+/* Copyright (C) 2011
+ * Corscience GmbH & Co. KG - Simon Schwarz 
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#ifdef CONFIG_OMAP34XX
+#include 
+#endif
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* This function writes given bootparams to NAND flash
+ *  adr: Start adress of Kernel parameter image (ATAGS, FDT)
+ *  length: length of the image in byte
+ * off: offset in NAND flash
+ *
+ * borrowd heavily from common/cmd_nand.c
+ */
+static void boot_params_to_nand(u_char *adr, size_t length, loff_t off)
+{
+   nand_info_t *nand = &nand_info[0]; /* use 0 as in SPL */
+   nand_erase_options_t opts;
+#ifdef CONFIG_OMAP34XX
+   omap_nand_switch_ecc(1); /* use hw ecc on omap for SPL compat */
+#endif
+   /* erase */
+   memset(&opts, 0, sizeof(opts));
+   opts.offset = off;
+   opts.length = length;
+   opts.quiet = 1;
+   opts.spread = 1;
+   nand_erase_opts(nand, &opts);
+
+   /* write */
+   if (nand_write_skip_bad(nand, off, &length, adr, 0)) {
+   printf("FAILED!\n");
+   return;
+   }
+
+   printf("Written to offset 0x%llX, size: %d bytes\n",
+   off, length);
+}
+
+/* Saves FDT to NAND */
+int do_savebp_fdt(loff_t offset)
+{
+   boot_params_to_nand((u_char *)images.ft_addr,
+   CONFIG_CMD_SAVEBP_WRITE_SIZE, offset);
+   return 0;
+}
+
+
+/* Saves ATAGS to NAND */
+int do_savebp_atags(loff_t offset)
+{
+   /* Vars */
+   bd_t *bd = gd->bd;
+
+   printf("write ATAGS to NAND...\n");
+
+   /* save em */
+   /* used fixed size - easier to read later just ignore garbage */
+   boot_params_to_nand((u_char *)bd->bi_boot_params,
+   CONFIG_CMD_SAVEBP_WRITE_SIZE, offset);
+
+   return 0;

[U-Boot] [PATCH V3 2/8] Add savebp command

[Simon Schwarz]

This adds a savebp command to the u-boot.

Related config:
CONFIG_CMD_SAVEBP
activate/deactivate the command
CONFIG_CMD_SAVEBP_NAND_OFS
Offset in NAND to use
CONFIG_SYS_NAND_SPL_KERNEL_OFFS
Offset in NAND of direct boot kernel image to use in SPL
CONFIG_SYS_SPL_ARGS_ADDR
Address where the kernel boot arguments are expected - this is
normally RAM-start + 0x100 (on ARM)

Signed-off-by: Simon Schwarz 
---

V2 changes:
CHG corrected bootm call. Now bootm is called with five parameters including
Address of FDT in RAM. This fixes the hang on savebp fdt call.
ADD debug output of the actual bootm parameter call
CHG help message

V3 changes:
FIX added missing brackets
---
 common/Makefile  |1 +
 common/cmd_savebp.c  |  149 ++
 include/configs/devkit8000.h |6 ++
 3 files changed, 156 insertions(+), 0 deletions(-)
 create mode 100644 common/cmd_savebp.c

diff --git a/common/Makefile b/common/Makefile
index 124a427..0b42968 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -158,6 +158,7 @@ COBJS-$(CONFIG_USB_STORAGE) += usb_storage.o
 endif
 COBJS-$(CONFIG_CMD_XIMG) += cmd_ximg.o
 COBJS-$(CONFIG_YAFFS2) += cmd_yaffs2.o
+COBJS-$(CONFIG_CMD_SAVEBP) += cmd_savebp.o
 
 # others
 COBJS-$(CONFIG_DDR_SPD) += ddr_spd.o
diff --git a/common/cmd_savebp.c b/common/cmd_savebp.c
new file mode 100644
index 000..4091ccb
--- /dev/null
+++ b/common/cmd_savebp.c
@@ -0,0 +1,149 @@
+/* Copyright (C) 2011
+ * Corscience GmbH & Co. KG - Simon Schwarz 
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include 
+#include 
+
+#define TYPE_FDT   0
+#define TYPE_ATAGS 1
+
+static inline int str2off(const char *p, loff_t *num)
+{
+   char *endptr;
+
+   *num = simple_strtoull(p, &endptr, 16);
+   return *p != '\0' && *endptr == '\0';
+}
+
+int do_savebp(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+   loff_t offset;
+   int img_type = TYPE_ATAGS;
+   int ret = 0;
+   int bootm_argc = 5;
+   char *bootm_argsv[] = {"do_bootm", "xxx", "0x8200", "-",
+   "0x8100"};
+
+   offset = (loff_t)CONFIG_CMD_SAVEBP_NAND_OFS;
+   bootm_argsv[2] = getenv("loadaddr");
+   /* - Validate args - */
+   switch (argc) {
+   case 6: /* 4. fdt addr */
+   if (strcmp(argv[5], "-"))
+   strcpy(bootm_argsv[4], argv[5]);
+   case 5: /* 5. initrd addr */
+   if (strcmp(argv[4], "-"))
+   strcpy(bootm_argsv[3], argv[4]);
+   case 4: /* 3. arg kernel addr */
+   if (strcmp(argv[3], "-"))
+   strcpy(bootm_argsv[2], argv[3]);
+   case 3: /* 2. arg offset */
+   if (strcmp(argv[2], "-")) {
+   if (!str2off(argv[2], &offset)) {
+   printf("'%s' is not a number\n", argv[2]);
+   return cmd_usage(cmdtp);
+   }
+   }
+   case 2: /* 1. arg atags or fdt */
+   if (!strcmp(argv[1], "fdt")) {
+   img_type = TYPE_FDT;
+   bootm_argc = 5;
+   } else if (!strcmp(argv[1], "atags")) {
+   img_type = TYPE_ATAGS;
+   bootm_argc = 4;
+   } else {
+   return cmd_usage(cmdtp);
+   }
+   /* using standard offset */
+   printf("using standard destination at: 0x%x\n",
+   (uint32_t)offset);
+   break;
+   default:
+   return cmd_usage(cmdtp);
+   }
+   debug("using as bootm arsgs: %s / %s / %s / %s / %s\n"
+   , bootm_argsv[0], bootm_argsv[1], bootm_argsv[2],
+   bootm_argsv[3], bootm_argsv[4]);
+
+   /* - do the work - */
+   /* exec bootm_start as subcommand of do_bootm to init the images
+* data structure */
+   debug("exec bootm subcommand start\n");
+   bootm_argsv[1] = "start";
+   ret = do_bootm(find_cmd("do_bootm"), 0, bootm_argc, bootm_argsv);
+   debug("Subcommand start bootm retcode: %d\n", ret);
+
+   debug("

[U-Boot] [PATCH V3 1/8] arm: Add Prep subcommand support to bootm

[Simon Schwarz]

Adds prep subcommand to bootm implementation of ARM. When bootm is called with
the subcommand prep the function stops right after ATAGS creation and before
announce_and_cleanup.

This is used in savebp command

Signed-off-by: Simon Schwarz 


V2 changes:
nothing

V3 changes:
nothing
---
 arch/arm/lib/bootm.c |  116 +++--
 common/cmd_bootm.c   |2 +-
 2 files changed, 65 insertions(+), 53 deletions(-)

diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 802e833..d3152ae 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -1,4 +1,7 @@
-/*
+/* Copyright (C) 2011
+ * Corscience GmbH & Co. KG - Simon Schwarz 
+ *  - Added prep subcommand support
+ *
  * (C) Copyright 2002
  * Sysgo Real-Time Solutions, GmbH 
  * Marius Groeger 
@@ -55,7 +58,7 @@ static struct tag *params;
 
 static ulong get_sp(void);
 #if defined(CONFIG_OF_LIBFDT)
-static int bootm_linux_fdt(int machid, bootm_headers_t *images);
+static int bootm_linux_fdt(int machid, bootm_headers_t *images, int flag);
 #endif
 
 void arch_lmb_reserve(struct lmb *lmb)
@@ -98,63 +101,67 @@ int do_bootm_linux(int flag, int argc, char *argv[], 
bootm_headers_t *images)
bd_t*bd = gd->bd;
char*s;
int machid = bd->bi_arch_number;
-   void(*kernel_entry)(int zero, int arch, uint params);
+   void(*kernel_entry)(int zero, int arch, uint params) = NULL;
 
 #ifdef CONFIG_CMDLINE_TAG
char *commandline = getenv ("bootargs");
 #endif
-
-   if ((flag != 0) && (flag != BOOTM_STATE_OS_GO))
-   return 1;
-
-   s = getenv ("machid");
-   if (s) {
-   machid = simple_strtoul (s, NULL, 16);
-   printf ("Using machid 0x%x from environment\n", machid);
-   }
-
-   show_boot_progress (15);
+   if ((flag != 0) && (!(flag & BOOTM_STATE_OS_GO ||
+flag & BOOTM_STATE_OS_PREP)))
+   return 1; /* subcommand not implemented */
+   else if ((flag == 0) || flag & BOOTM_STATE_OS_PREP) {
+   s = getenv("machid");
+   if (s) {
+   strict_strtoul(s, 16, (long unsigned int *) &machid);
+   printf("Using machid 0x%x from environment\n", machid);
+   }
+
+   show_boot_progress(15);
 
 #ifdef CONFIG_OF_LIBFDT
-   if (images->ft_len)
-   return bootm_linux_fdt(machid, images);
+   if (images->ft_len)
+   return bootm_linux_fdt(machid, images, flag);
 #endif
 
-   kernel_entry = (void (*)(int, int, uint))images->ep;
+   kernel_entry = (void (*)(int, int, uint))images->ep;
 
-   debug ("## Transferring control to Linux (at address %08lx) ...\n",
-  (ulong) kernel_entry);
+   debug("## Transferring control to Linux (at address %08lx)" \
+   "...\n", (ulong) kernel_entry);
 
 #if defined (CONFIG_SETUP_MEMORY_TAGS) || \
 defined (CONFIG_CMDLINE_TAG) || \
 defined (CONFIG_INITRD_TAG) || \
 defined (CONFIG_SERIAL_TAG) || \
 defined (CONFIG_REVISION_TAG)
-   setup_start_tag (bd);
+   setup_start_tag(bd);
 #ifdef CONFIG_SERIAL_TAG
-   setup_serial_tag (¶ms);
+   setup_serial_tag(¶ms);
 #endif
 #ifdef CONFIG_REVISION_TAG
-   setup_revision_tag (¶ms);
+   setup_revision_tag(¶ms);
 #endif
 #ifdef CONFIG_SETUP_MEMORY_TAGS
-   setup_memory_tags (bd);
+   setup_memory_tags(bd);
 #endif
 #ifdef CONFIG_CMDLINE_TAG
-   setup_commandline_tag (bd, commandline);
+   setup_commandline_tag(bd, commandline);
 #endif
 #ifdef CONFIG_INITRD_TAG
-   if (images->rd_start && images->rd_end)
-   setup_initrd_tag (bd, images->rd_start, images->rd_end);
+   if (images->rd_start && images->rd_end)
+   setup_initrd_tag(bd, images->rd_start, images->rd_end);
 #endif
-   setup_end_tag(bd);
+   setup_end_tag(bd);
 #endif
+   if (flag & BOOTM_STATE_OS_PREP)
+   return 0;
+   }
 
-   announce_and_cleanup();
-
-   kernel_entry(0, machid, bd->bi_boot_params);
-   /* does not return */
+   if (flag == 0 || flag & BOOTM_STATE_OS_GO) {
+   announce_and_cleanup();
 
+   kernel_entry(0, machid, bd->bi_boot_params);
+   /* does not return */
+   }
return 1;
 }
 
@@ -174,10 +181,10 @@ static int fixup_memory_node(void *blob)
return fdt_fixup_memory_banks(blob, start, size, CONFIG_NR_DRAM_BANKS);
 }
 
-static int bootm_linux_fdt(int machid, bootm_headers_t *images)
+static int bootm_linux_fdt(int machid, bootm_headers_t *images, int flag)
 {
ulong rd_len;
-   void (*kernel_entry)(int zero, int dt_machid, void *dtblob);
+   void (*kernel_entry)(int zero, int dt_machid, void *dtblob) = NULL;
ulong of_size = images->ft_len;
char **of_flat_tree = &i

[U-Boot] [PATCH V3 0/8] SPL Linux boot

[Simon Schwarz]

Adds direct Linux boot to SPL. It implements a savebp command to save  
ATAGS or FDT to NAND flash. The kernel image has to be in place for this! 
 
checkpatch whines about not using strict_strtoull - since this is not  
available - I can't change this. 
 
V2 changes: 
FIX FDT creation 
ADD Readme 

V3 changes:
FIX missing brackets

based on: 
- The new SPL layout 
- OMAP3 new SPL layout 
  (http://article.gmane.org/gmane.comp.boot-loaders.u-boot/105260) 
 
Related to: 
- http://article.gmane.org/gmane.comp.boot-loaders.u-boot/102669 

Simon Schwarz (8):
  arm: Add Prep subcommand support to bootm
  Add savebp command
  arm: Add savebp implementation for arm
  omap-common/spl: Add linux boot to SPL
  devkit8000/spl: init GPMC for dm9000 in SPL
  omap-common: Add NAND SPL linux booting
  omap-common: fixes BSS overwriting problem
  savebp: added Readme

 arch/arm/cpu/armv7/omap-common/spl.c  |   49 +-
 arch/arm/cpu/armv7/omap-common/spl_nand.c |   63 +---
 arch/arm/include/asm/omap_common.h|2 +
 arch/arm/include/asm/savebp.h |   27 +
 arch/arm/lib/Makefile |1 +
 arch/arm/lib/bootm.c  |  116 --
 arch/arm/lib/savebp.c |   91 ++
 board/timll/devkit8000/devkit8000.c   |   33 +--
 common/Makefile   |1 +
 common/cmd_bootm.c|2 +-
 common/cmd_savebp.c   |  149 +
 doc/README.commands.savebp|   28 ++
 include/command.h |5 +
 include/configs/devkit8000.h  |   14 +++-
 14 files changed, 499 insertions(+), 82 deletions(-)
 create mode 100644 arch/arm/include/asm/savebp.h
 create mode 100644 arch/arm/lib/savebp.c
 create mode 100644 common/cmd_savebp.c
 create mode 100644 doc/README.commands.savebp

-- 
1.7.4.1

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

[U-Boot] phylib + mii + _parse_status

[Michal Simek]

Hi,

I have done some experiments with phylib and Xilinx ethernet drivers
and I found that mii code show different values for speed and duplex.
I think that the main problem is that there are called miiphy_speed
and miiphy_duplex functions instead of phy parsing functions.

I think that it will be the best to extend
struct phy_driver for
int (*parse_status)(struct phy_device *phydev);

and then reread phydev->speed or phydev->duplex instead of using generic
code which does wrong things.

Then will be good to synchronize FULL/HALF and DUPLEX_FULL/DUPLEX_HALF.

miiphy.h
#define HALF22
#define FULL44

include/linux/ethtool.h
#define DUPLEX_HALF 0x00
#define DUPLEX_FULL 0x01


And of course speeds:
miiphy.h
#define _1000BASET  1000
#define _100BASET   100
#define _10BASET10

include/linux/ethtool.h
#define SPEED_1010
#define SPEED_100   100
#define SPEED_1000  1000
#define SPEED_2500  2500
#define SPEED_1 1


Have someone looked at it? Any comments?

Thanks,
Michal

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

[U-Boot] mii_phy.h

[Michal Simek]

Hi,

Can someone clear me purpose of mii_phy.h? It looks like that it is really
ancient file which hasn't been touched from 2003.

It is use for two files
[monstr@monstr u-boot]$ grep -rn "mii_phy.h" *
board/ep8260/mii_phy.c:2:#include 
board/rpxsuper/mii_phy.c:2:#include 

+ different numbers of arguments against new "version"
[monstr@monstr u-boot]$ grep -rn "mii_discover_phy" *
arch/m68k/include/asm/fec.h:359:int mii_discover_phy(struct eth_device *dev);
arch/powerpc/cpu/mpc8xx/fec.c:63:static int mii_discover_phy(struct eth_device 
*dev);
arch/powerpc/cpu/mpc8xx/fec.c:728:  efis->actual_phy_addr = 
mii_discover_phy (dev);
arch/powerpc/cpu/mpc8xx/fec.c:872:static int mii_discover_phy(struct eth_device 
*dev)
arch/powerpc/cpu/mpc85xx/ether_fcc.c:237:mii_discover_phy();
arch/powerpc/cpu/mpc8260/ether_fcc.c:234:mii_discover_phy();
board/ep8260/mii_phy.c:10:mii_discover_phy(void)
board/rpxsuper/mii_phy.c:10:mii_discover_phy(void)
drivers/net/mcfmii.c:150:int mii_discover_phy(struct eth_device *dev)
drivers/net/mcfmii.c:253:   info->phy_addr = mii_discover_phy(dev);
include/mii_phy.h:4:void mii_discover_phy(void);

+ that functions without arg are not called either
arch/powerpc/cpu/mpc85xx/ether_fcc.c:237:mii_discover_phy();
arch/powerpc/cpu/mpc8260/ether_fcc.c:234:mii_discover_phy();

I found that Frank Panno is ep8260 maintainer. Any comment?

The best will be to remove mii_phy entirely.
Wolfgang: What do you think?

Thanks,
Michal


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

Re: [U-Boot] [PATCH] Error : Not finding asm/arch/gpio.h

[Stefano Babic]

On 08/25/2011 08:29 AM, Faisal H wrote:
> While building with omap3_beagle_config configuration,
> getting an error about not finding asm/arch/gpio.h (which does not exist).
> Found that header files are moved to arch/arm/include/asm/arch-.

"make _config" sets a link for asm/arch to
arch/arm/include/asm/arch-. The file is not moved.

Then in my understanding asm/arch/gpio.h is included in asm/gpio.h, and
must not be included directly. Have I missed something ?


> Fixed the includes to find the file..
> 
> Signed-off-by: Faisal Hassan
> Cc: Wolfgang Denk
> 
> 
> --- a/board/cm-bf537e/gpio_cfi_flash.c
> +++ b/board/cm-bf537e/gpio_cfi_flash.c
> @@ -8,7 +8,7 @@
> 
>   #include
>   #include
> -#include
> +#include

However, asm/gpio.h is the correct general interface. The specific part
for the microprocessor is included with #include  in
asm/gpio.h.

You should not need to change it if the links are correctly set. If not,
it is another bug.

>   #include
> -#include
> +#include

IMHO this change is wrong, and it is correct how it is done currently.

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