[U-Boot] [PATCH 1/2 v4] fdt: Add a do_fixup_by_path_string() function

[Chunhe Lan]

The do_fixup_by_path_string() will set the specified node's property to the
value contained in "status". It would just be an inline wrapper for
do_fixup_by_path() that calls strlen on the argument.

Signed-off-by: Chunhe Lan 
---
 include/fdt_support.h |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/include/fdt_support.h b/include/fdt_support.h
index 863024f..1de4a1d 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -36,6 +36,13 @@ void do_fixup_by_path(void *fdt, const char *path, const 
char *prop,
  const void *val, int len, int create);
 void do_fixup_by_path_u32(void *fdt, const char *path, const char *prop,
  u32 val, int create);
+
+static inline void do_fixup_by_path_string(void *fdt, const char *path,
+  const char *prop, const char *status)
+{
+   do_fixup_by_path(fdt, path, prop, status, strlen(status) + 1, 1);
+}
+
 void do_fixup_by_prop(void *fdt,
  const char *pname, const void *pval, int plen,
  const char *prop, const void *val, int len,
-- 
1.5.6.5


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

[U-Boot] [PATCH 2/2 v4] powerpc/p1023rds: Disable nor flash node and enable nand flash node

[Chunhe Lan]

In the p1023rds, accessing exclusively nor flash or nand flash device by
BR0/OR0.

Default device tree nor and nand node should have the following structure:

Example:

nor_flash: nor@0,0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "cfi-flash";
reg = <0x0 0x0 0x0200>;
bank-width = <2>;
device-width = <1>;

partition@0 {
label = "ramdisk";
reg = <0x 0x01c0>;
};
}

nand_flash: nand@1,0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,p1023-fcm-nand",
 "fsl,elbc-fcm-nand";
reg = <0x2 0x0 0x0004>;
status = "disabled";

u-boot-nand@0 {
/* This location must not be altered  */
/* 1MB for u-boot Bootloader Image */
reg = <0x0 0x0010>;
read-only;
};
}

When booting from nor flash, the status of nor node is null that means it
is enabled and the status of nand node is disabled in the default dts file,
so do not do anything.

But, when booting from nand flash, need to do some operations:

o the status of nor node should be disabled.
o the status of nand node should be enabled.

Signed-off-by: Chunhe Lan 
---
 board/freescale/p1023rds/p1023rds.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/board/freescale/p1023rds/p1023rds.c 
b/board/freescale/p1023rds/p1023rds.c
index 8cfd199..c99ccee 100644
--- a/board/freescale/p1023rds/p1023rds.c
+++ b/board/freescale/p1023rds/p1023rds.c
@@ -158,5 +158,10 @@ void ft_board_setup(void *blob, bd_t *bd)
size = getenv_bootm_size();
 
fdt_fixup_memory(blob, (u64)base, (u64)size);
+
+#ifdef CONFIG_NAND_U_BOOT
+   do_fixup_by_path_string(fdt, "nor_flash", "status", "disabled");
+   do_fixup_by_path_string(fdt, "nand_flash", "status", "okay");
+#endif
 }
 #endif
-- 
1.5.6.5


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

Re: [U-Boot] [PATCH 2/2 v4] powerpc/p1023rds: Disable nor flash node and enable nand flash node

[Wolfgang Denk]

Dear Chunhe Lan,

In message <1314602152-9114-1-git-send-email-chunhe@freescale.com> you 
wrote:
> In the p1023rds, accessing exclusively nor flash or nand flash device by
> BR0/OR0.
...
> When booting from nor flash, the status of nor node is null that means it
> is enabled and the status of nand node is disabled in the default dts file,
> so do not do anything.

It would be more intuitive to the reader, when the enabled node would
use an explicit

status = "enabled";

> +#ifdef CONFIG_NAND_U_BOOT
> + do_fixup_by_path_string(fdt, "nor_flash", "status", "disabled");
> + do_fixup_by_path_string(fdt, "nand_flash", "status", "okay");
> +#endif

What does ""okay" mean?  This is not documented anywhere.  Is this
supposed to mean "enabled"?  Then please write "enabled" - for certain
configurations it is definitely OK to disable the device.

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's an old story about the person who wished his computer were as
easy to use as his telephone. That wish has come  true,  since  I  no
longer know how to use my telephone.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH] net: Check network device driver name

[Michal Simek]

Mike Frysinger wrote:
> On Friday, August 26, 2011 08:52:40 Michal Simek wrote:
>> If name is longer than allocated space NAMESIZE
>> mac address is rewritten which show error
>> message like:
> 
> since you overflowed the buffer, who knows what could happen ...
> 
>> +if (strlen(dev->name) > NAMESIZE) {
>> +printf("Long(%d>%d) network driver name for %s\n",
>> +strlen(dev->name), NAMESIZE, dev->name);
>> +return 0;
>> +}
> 
> size_t len = strlen(dev->name);
> if (len >= NAMESIZE) {
>   printf("network driver name is too long (%zu >= %zu): %s\n",
>   len, NAMESIZE, dev->name);
>   return -1;
> }

ok. I see it is 15 chars space + terminated characters.

Mike: Will you propose this patch or should I do it?

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 2/2 v4] powerpc/p1023rds: Disable nor flash node and enable nand flash node

[Chunhe Lan]

On Mon, 29 Aug 2011 15:42:09 +0800, Wolfgang Denk  wrote:

> Dear Chunhe Lan,
>
> In message <1314602152-9114-1-git-send-email-chunhe@freescale.com>  
> you wrote:
>> In the p1023rds, accessing exclusively nor flash or nand flash device by
>> BR0/OR0.
> ...
>> When booting from nor flash, the status of nor node is null that means  
>> it
>> is enabled and the status of nand node is disabled in the default dts  
>> file,
>> so do not do anything.
>
> It would be more intuitive to the reader, when the enabled node would
> use an explicit
>
>   status = "enabled";
>
>> +#ifdef CONFIG_NAND_U_BOOT
>> +do_fixup_by_path_string(fdt, "nor_flash", "status", "disabled");
>> +do_fixup_by_path_string(fdt, "nand_flash", "status", "okay");
>> +#endif
>
> What does ""okay" mean?  This is not documented anywhere.  Is this
> supposed to mean "enabled"?  Then please write "enabled" - for certain
> configurations it is definitely OK to disable the device.

In the kernel, whether the status of node is enabled or not, it is  
determined by
of_device_is_available( ).

The following content of of_device_is_available( ):

245 /**
246  *  of_device_is_available - check if a device is available for use
247  *
248  *  @device: Node to check for availability
249  *
250  *  Returns 1 if the status property is absent or set to "okay" or  
"ok",
251  *  0 otherwise
252  */
253 int of_device_is_available(const struct device_node *device)
254 {
255 const char *status;
256 int statlen;
257
258 status = of_get_property(device, "status", &statlen);
259 if (status == NULL)
260 return 1;
261
262 if (statlen > 0) {
263 if (!strcmp(status, "okay") || !strcmp(status, "ok"))
264 return 1;
265 }
266
267 return 0;
268 }

  " return 1" is enabled.
  " return 0" is disabled.
  So, we do NOT use "enabled" to set status.

Thanks.

-Jack Lan

> Best regards,
>
> Wolfgang Denk
>

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

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

[Marek Vasut]

On Monday, August 29, 2011 07:39:18 AM Ajay Bhargav wrote:
> - "Mike Frysinger"  wrote:
> > On Monday, August 29, 2011 01:10:49 Ajay Bhargav wrote:
> > > - "Mike Frysinger"  wrote:
> > > > On Friday, August 26, 2011 02:36:51 Ajay Bhargav wrote:
> > > > > +darmdfec = malloc(sizeof(struct armdfec_device));
> > > > > +if (!darmdfec)
> > > > > +goto error;
> > > > 
> > > > if this first one fails, we jump to:
> > > > > +error:
> > > > > +free(darmdfec->p_aligned_txbuf);
> > > > > +free(darmdfec->p_rxbuf);
> > > > > +free(darmdfec->p_rxdesc);
> > > > > +free(darmdfec->htpr);
> > > > 
> > > > looks like 4 NULL pointer derefs.  so you'll need one specific
> > 
> > path
> > 
> > > > for the first malloc(), but the rest are fine.
> > > 
> > > so you mean like this...
> > > 
> > > if(!darmdfec)
> > > 
> > > goto error;
> > > 
> > > ...
> > > 
> > > error1:
> > > free(darmdfec->p_aligned_txbuf);
> > > free(darmdfec->p_rxbuf);
> > > free(darmdfec->p_rxdesc);
> > > free(darmdfec->htpr);
> > > 
> > > error:
> > > free(darmdfec);
> > > return -1;
> > 
> > that's one way of fixing it
> > -mike
> 
> Any other better way?

I'd love to be enlightened on this topic too ...

> 
> --Ajay
> ___
> 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 v3 1/8] da850: indicate cache usage disable in config file

[Netagunte, Nagabhushana]

Gentlemen,

We will address cache coherency issues soon after these patches.
Earlier also, chache was disabled. Only due to new cache management
Framework which was added recently, it is explicitly needed to be 
Indicated to turn off cache. 

Since fixing the cache coherency issues with EMAC will take some time,
I want this patch to go in mainline so that issue doesn't crop up for
People who use u-boot.

Regards,
Nag
-Original Message-
From: Laurence Withers [mailto:lwith...@guralp.com] 
Sent: Thursday, August 18, 2011 8:50 PM
To: Ben Gardiner
Cc: Netagunte, Nagabhushana; u-boot@lists.denx.de; Rajashekhara, Sudhakar; 
Hadli, Manjunath; Stefan Roese
Subject: Re: [U-Boot] [PATCH v3 1/8] da850: indicate cache usage disable in 
config file

On Thu, Aug 18, 2011 at 11:13:19AM -0400, Ben Gardiner wrote:
> I understand that both Laurence and Stefan (cc'd) have confirmed that
> there dcache issues with the EMA; I am assuming that the 'issue'
> results in a delay in tftp'ing...

No; the issue was that packets were being sent on to the wire with incorrect
IP checksums. It twigged that the problem was cache coherency when I put a
full hexdump of each outgoing packet in and suddenly the outbound packets
started being valid.

> Disabling the caches will slow down decompression which will slow down
> boot overall when booting from flash.
> 
> Rather than masking the issue by disabling caches and slowing down
> u-boot for it's users perhaps TI should be fixing the EMAC drivers'
> cache bugs instead?

Indeed, the correct solution is to properly manage the net buffers with
respect to the cache, although I have not attempted that change myself. I
have seen some patches start to flow that make changes in drivers to work
correctly with caches enabled, such as
http://lists.denx.de/pipermail/u-boot/2011-August/098484.html .

Bye for now,
-- 
Laurence Withers, http://www.guralp.com/
Direct tel:+447753988197 or tel:+44408643   Software Engineer
General support queries:  CMG-DCM CMG-EAM CMG-NAM
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] da850evm: Move LPSC configuration to board_early_init_f()

[Christian Riesch]

Since commit f1d2b313c9eb6808d30c16a9eb5251240452a56c the serial
port of the da850evm is accessed before the UART2 peripheral of
the SoC is powered on in the function board_init() in
board/davinci/da8xxevm/da850evm.c.

When u-boot is used in conjunction with the UBL (user boot loader, see
doc/README.davinci) on this board, the UART2 peripheral is already
turned on by UBL at the time u-boot is started. However, if UBL is not
used, u-boot must power on the peripheral before using it.

This patch adds a board_early_init_f() function for the LPSC
configuration to the da850evm board configuration.

Signed-off-by: Christian Riesch 
Cc: Sudhakar Rajashekhara 
Cc: Sandeep Paulraj 
Cc: Heiko Schocher 
Cc: Ben Gardiner 
---

In my first submission of this patch I forgot to cc Sudhakar Rajashekhara
as the board's maintainer. Sorry! Thank you for your comments!
Best regards, Christian

 board/davinci/da8xxevm/da850evm.c |   23 ++-
 include/configs/da850evm.h|1 +
 2 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/board/davinci/da8xxevm/da850evm.c 
b/board/davinci/da8xxevm/da850evm.c
index 73eaa48..11ad88d 100644
--- a/board/davinci/da8xxevm/da850evm.c
+++ b/board/davinci/da8xxevm/da850evm.c
@@ -166,6 +166,20 @@ u32 get_board_rev(void)
return rev;
 }
 
+int board_early_init_f(void)
+{
+   /*
+* Power on required peripherals
+* ARM does not have access by default to PSC0 and PSC1
+* assuming here that the DSP bootloader has set the IOPU
+* such that PSC access is available to ARM
+*/
+   if (da8xx_configure_lpsc_items(lpsc, ARRAY_SIZE(lpsc)))
+   return 1;
+
+   return 0;
+}
+
 int board_init(void)
 {
 #ifndef CONFIG_USE_IRQ
@@ -195,15 +209,6 @@ int board_init(void)
/* address of boot parameters */
gd->bd->bi_boot_params = LINUX_BOOT_PARAM_ADDR;
 
-   /*
-* Power on required peripherals
-* ARM does not have access by default to PSC0 and PSC1
-* assuming here that the DSP bootloader has set the IOPU
-* such that PSC access is available to ARM
-*/
-   if (da8xx_configure_lpsc_items(lpsc, ARRAY_SIZE(lpsc)))
-   return 1;
-
/* setup the SUSPSRC for ARM to control emulation suspend */
writel(readl(&davinci_syscfg_regs->suspsrc) &
   ~(DAVINCI_SYSCFG_SUSPSRC_EMAC | DAVINCI_SYSCFG_SUSPSRC_I2C |
diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h
index bbb5a9b..5d0f5bf 100644
--- a/include/configs/da850evm.h
+++ b/include/configs/da850evm.h
@@ -42,6 +42,7 @@
 #define CONFIG_SYS_HZ  1000
 #define CONFIG_SKIP_LOWLEVEL_INIT
 #define CONFIG_SYS_TEXT_BASE   0xc108
+#define CONFIG_BOARD_EARLY_INIT_F
 
 /*
  * Memory Info
-- 
1.7.0.4

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

[U-Boot] [PATCH] net: ll_temac: Add LL TEMAC driver to u-boot

[Michal Simek]

LL Temac driver can be used by microblaze, xilinx ppc405/440
in sdma and fifo mode. DCR or XPS bus can be used.

The driver uses and requires PHYLIB.

Signed-off-by: Michal Simek 
---
 drivers/net/Makefile  |1 +
 drivers/net/xilinx_ll_temac.c |  686 +
 include/netdev.h  |1 +
 3 files changed, 688 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/xilinx_ll_temac.c

diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 819b197..4541eaf 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -84,6 +84,7 @@ COBJS-$(CONFIG_TSI108_ETH) += tsi108_eth.o
 COBJS-$(CONFIG_ULI526X) += uli526x.o
 COBJS-$(CONFIG_VSC7385_ENET) += vsc7385.o
 COBJS-$(CONFIG_XILINX_EMACLITE) += xilinx_emaclite.o
+COBJS-$(CONFIG_XILINX_LL_TEMAC) += xilinx_ll_temac.o
 
 COBJS  := $(sort $(COBJS-y))
 SRCS   := $(COBJS:.o=.c)
diff --git a/drivers/net/xilinx_ll_temac.c b/drivers/net/xilinx_ll_temac.c
new file mode 100644
index 000..04b685d
--- /dev/null
+++ b/drivers/net/xilinx_ll_temac.c
@@ -0,0 +1,686 @@
+/*
+ * Xilinx xps_ll_temac ethernet driver for u-boot
+
+ * Copyright (C) 2008 - 2011 Michal Simek 
+ * June 2008 Microblaze optimalization, FIFO mode support
+ *
+ * Based on Yoshio Kashiwagi kashiw...@co-nss.co.jp driver
+ * Copyright (C) 2008 Nissin Systems Co.,Ltd.
+ * March 2008 created
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#undef ETH_HALTING
+
+#define XTE_EMMC_LINKSPEED_MASK0xC000 /* Link speed */
+/* XTE_EMCFG_LINKSPD_MASK */
+#define XTE_EMMC_LINKSPD_100x /* for 10 Mbit */
+#define XTE_EMMC_LINKSPD_100   0x4000 /* for 100 Mbit */
+#define XTE_EMMC_LINKSPD_1000  0x8000 /* forr 1000 Mbit */
+
+/* XPS_LL_TEMAC direct registers definition */
+#define TEMAC_LSW0 0x24
+#define TEMAC_CTL0 0x28
+#define TEMAC_RDY0 0x2c
+
+#define XTE_RSE_MIIM_RR_MASK   0x0002
+#define XTE_RSE_MIIM_WR_MASK   0x0004
+#define XTE_RSE_CFG_RR_MASK0x0020
+#define XTE_RSE_CFG_WR_MASK0x0040
+
+/* XPS_LL_TEMAC indirect registers offset definition */
+#define RCW1   0x240
+#define TC 0x280
+#define EMMC   0x300
+#define MC 0x340
+#define UAW0   0x380
+#define UAW1   0x384
+#define AFM0x390
+#define MIIMWD 0x3b0
+#define MIIMAI 0x3b4
+
+#define CNTLREG_WRITE_ENABLE_MASK  0x8000
+
+#define MDIO_ENABLE_MASK   0x40
+#define MDIO_CLOCK_DIV_100MHz  0x28
+
+/* Backwards compatibility to older xparameters.h files */
+#ifndef XILINX_LLTEMAC_SDMA_USE_DCR
+#define XILINX_LLTEMAC_SDMA_USE_DCR 0
+#endif
+
+#ifdef XILINX_LLTEMAC_FIFO_BASEADDR
+# define FIFO_MODE 1
+#elif XILINX_LLTEMAC_SDMA_CTRL_BASEADDR
+# define SDMA_MODE 1
+# if XILINX_LLTEMAC_SDMA_USE_DCR == 1
+
+static void mtdcr_local(u32 reg, u32 val)
+{
+   mtdcr(0x00, reg);
+   mtdcr(0x01, val);
+}
+
+static u32 mfdcr_local(u32 reg)
+{
+   u32 val;
+   mtdcr(0x00, reg);
+   val = mfdcr(0x01);
+   return val;
+}
+
+#  define sdma_out_be32(addr, offset, val) \
+   mtdcr_local((u32) (addr + offset), (val))
+#  define sdma_in_be32(addr, offset)   mfdcr_local((u32) (addr + offset))
+
+# else
+#  define sdma_out_be32(addr, offset, val) \
+   out_be32((u32 *)(addr + offset * 4), (val))
+#  define sdma_in_be32(addr, offset)   in_be32((u32 *)(addr + offset * 4))
+# endif
+#else
+# error Xilinx LL Temac: Unsupported mode - Please setup SDMA or FIFO mode
+#endif
+
+#ifdef SDMA_MODE
+/* XPS_LL_TEMAC SDMA registers definition */
+# define TX_CURDESC_PTR0x03
+# define TX_TAILDESC_PTR   0x04
+# define TX_CHNL_CTRL  0x05
+# define TX_IRQ_REG0x06
+# define TX_CHNL_STS   0x07
+# define RX_NXTDESC_PTR0x08
+# define RX_CURDESC_PTR0x0b
+# define RX_TAILDESC_PTR   0x0c
+# define RX_CHNL_CTRL  0x0d
+# define RX_IRQ_REG0x0e
+# define RX_CHNL_STS   0x0f
+# define DMA_CONTROL_REG   0x10
+
+/* CDMAC descriptor status bit definitions */
+# define BDSTAT_STOP_ON_END_MASK   0x20
+# define BDSTAT_COMPLETED_MASK 0x10
+# define BDSTAT_SOP_MASK   0x08
+# define BDSTAT_EOP_MASK   0x04
+# define CHNL_STS_ERROR_MASK   0x80
+
+/* All interrupt enable bits */
+#define XLLDMA_CR_IRQ_ALL_EN_MASK  0x0087
+/* All interrupt bits */
+#define XLLDMA_IRQ_ALL_MASK0x001F
+/* Disable error when 2 or 4 bit coalesce counter overflows */
+#define XLLDMA_DMACR_RX_OVERFLOW_ERR_DIS_MASK  0x0010
+/* Disable error when 2 or 4 bit coalesce counter overflows */
+#define XLLDMA_DMACR_TX_OVERFLOW_ERR_DIS_M

Re: [U-Boot] [PATCH 2/2 v4] powerpc/p1023rds: Disable nor flash node and enable nand flash node

[Wolfgang Denk]

Dear Chunhe Lan,

In message  you wrote:
> 
> > It would be more intuitive to the reader, when the enabled node would
> > use an explicit
> >
> > status = "enabled";
> >
> >> +#ifdef CONFIG_NAND_U_BOOT
> >> +  do_fixup_by_path_string(fdt, "nor_flash", "status", "disabled");
> >> +  do_fixup_by_path_string(fdt, "nand_flash", "status", "okay");
> >> +#endif
> >
> > What does ""okay" mean?  This is not documented anywhere.  Is this
> > supposed to mean "enabled"?  Then please write "enabled" - for certain
> > configurations it is definitely OK to disable the device.
> 
> In the kernel, whether the status of node is enabled or not, it is  
> determined by
> of_device_is_available( ).

well, maybe you take my hint to understand that this is not an optimal
implementation?

>   " return 1" is enabled.
>   " return 0" is disabled.
>   So, we do NOT use "enabled" to set status.

This is highly counter-intuitive and fragile.

Also, you fail to comment on my note about the strange "okay" string
in yoru code above - this makes no sense then, either.

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 bad reputation UNIX has gotten is totally undeserved, laid on by
people who don't understand, who have not gotten in there  and  tried
anything."  -- Jim Joyce, owner of Jim Joyce's UNIX Bookstore
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCHv4] new tool mkenvimage: generates an env image from an arbitrary config file

[David Wagner]

This tool takes a key=value configuration file (same as would a `printenv' show)
and generates the corresponding environment image, ready to be flashed.

For now, it doesn't work properly if environment variables have embedded
newlines.

Signed-off-by: David Wagner 
---

changes since v3


 * cosmetic changes (checkpatch, spelling, blank lines)

 * fail with an error message if it's impossible to have two ending '\0'

 @Wolgang:
What is the advantage of using mmap() here ? the file is read entirely and
sequentially ; does it make much of a difference compared to fread() ?

PS: Until a proper way is found for replacing only newlines that separate two
environment variables (and not the ones inside a variable), let's just warn that
it isn't supported.

 tools/Makefile |5 +
 tools/mkenvimage.c |  219 
 2 files changed, 224 insertions(+), 0 deletions(-)
 create mode 100644 tools/mkenvimage.c

diff --git a/tools/Makefile b/tools/Makefile
index fc741d3..8e7e85e 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -69,6 +69,7 @@ BIN_FILES-$(CONFIG_XWAY_SWAP_BYTES) += xway-swap-bytes$(SFX)
 BIN_FILES-y += mkimage$(SFX)
 BIN_FILES-$(CONFIG_NETCONSOLE) += ncb$(SFX)
 BIN_FILES-$(CONFIG_SHA1_CHECK_UB_IMG) += ubsha1$(SFX)
+BIN_FILES-y += mkenvimage$(SFX)
 
 # Source files which exist outside the tools directory
 EXT_OBJ_FILES-$(CONFIG_BUILD_ENVCRC) += common/env_embedded.o
@@ -94,6 +95,7 @@ OBJ_FILES-$(CONFIG_NETCONSOLE) += ncb.o
 NOPED_OBJ_FILES-y += os_support.o
 OBJ_FILES-$(CONFIG_SHA1_CHECK_UB_IMG) += ubsha1.o
 NOPED_OBJ_FILES-y += ublimage.o
+NOPED_OBJ_FILES-y += mkenvimage.o
 
 # Don't build by default
 #ifeq ($(ARCH),ppc)
@@ -172,6 +174,9 @@ $(obj)bmp_logo$(SFX):   $(obj)bmp_logo.o
 $(obj)envcrc$(SFX):$(obj)crc32.o $(obj)env_embedded.o $(obj)envcrc.o 
$(obj)sha1.o
$(HOSTCC) $(HOSTCFLAGS) $(HOSTLDFLAGS) -o $@ $^
 
+$(obj)mkenvimage$(SFX):$(obj)crc32.o $(obj)mkenvimage.o
+   $(HOSTCC) $(HOSTCFLAGS) $(HOSTLDFLAGS) -o $@ $^
+
 $(obj)gen_eth_addr$(SFX):  $(obj)gen_eth_addr.o
$(HOSTCC) $(HOSTCFLAGS) $(HOSTLDFLAGS) -o $@ $^
$(HOSTSTRIP) $@
diff --git a/tools/mkenvimage.c b/tools/mkenvimage.c
new file mode 100644
index 000..9c06e1e
--- /dev/null
+++ b/tools/mkenvimage.c
@@ -0,0 +1,219 @@
+/*
+ * (C) Copyright 2011 Free Electrons
+ * David Wagner 
+ *
+ * Inspired from envcrc.c:
+ * (C) Copyright 2001
+ * Paolo Scaffardi, AIRVENT SAM s.p.a - RIMINI(ITALY), arse...@tin.it
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define CRC_SIZE sizeof(uint32_t)
+
+static void usage(const char *exec_name)
+{
+   printf("%s [-h] [-r] [-b] [-p ] "
+  "-s  -o  \n"
+  "\n"
+  "\tThe input file is in format:\n"
+  "\t\tkey1=value1\n"
+  "\t\tkey2=value2\n"
+  "\t\t...\n"
+  "\t-r : the environment has two copies in flash\n"
+  "\t-b : the target is big endian (default is little endian)\n"
+  "\t-p  : fill the image with  bytes instead of 0xff "
+  "bytes\n",
+  exec_name);
+}
+
+int main(int argc, char **argv)
+{
+   uint32_t crc, targetendian_crc;
+   const char *txt_filename = NULL, *bin_filename = NULL;
+   FILE *txt_file, *bin_file;
+   unsigned char *dataptr, *envptr;
+   unsigned int envsize, datasize = 0;
+   int bigendian = 0;
+   int redundant = 0;
+   unsigned char padbyte = 0xff;
+
+   int option;
+   int ret = EXIT_SUCCESS;
+
+   struct stat txt_file_stat;
+
+   int i;
+
+   /* Parse the cmdline */
+   while ((option = getopt(argc, argv, "s:o:rbp:h")) != -1) {
+   switch (option) {
+   case 's':
+   datasize = strtol(optarg, NULL, 0);
+   break;
+   case 'o':
+   bin_filename = strdup(optarg);
+   if (!bin_filename) {
+   fprintf(stderr, "Can't strdup() the output "
+   

[U-Boot] [PATCH 0/2] console: Squelch and pre-console buffer

[Graeme Russ]

This is a more complete followup patch to my original 'Pre-console buffer'
patch. This series includes squelching of all console I/O if
gd->have_console is 0 (console not initialised yet) unless the board is
configured to use the pre-console buffer (in which case console output
prior to the console being initialised is redirected to the buffer - All
console input is still squelched prior to the console being initialised)

If the pre-console buffer is enabled, the buffer is sent to console as
soon as the console is initialised.

Graeme Russ (2):
  console: Squelch pre-console output in console functions
  console: Implement pre-console buffer

 arch/arm/include/asm/global_data.h|3 +
 arch/avr32/include/asm/global_data.h  |3 +
 arch/blackfin/include/asm/global_data.h   |3 +
 arch/m68k/include/asm/global_data.h   |3 +
 arch/microblaze/include/asm/global_data.h |3 +
 arch/mips/include/asm/global_data.h   |3 +
 arch/nios2/include/asm/global_data.h  |3 +
 arch/powerpc/cpu/mpc5xxx/i2c.c|   30 +--
 arch/powerpc/cpu/mpc8xx/i2c.c |   18 +++--
 arch/powerpc/include/asm/global_data.h|3 +
 arch/sh/include/asm/global_data.h |3 +
 arch/sparc/include/asm/global_data.h  |4 +-
 arch/x86/include/asm/global_data.h|3 +
 common/console.c  |   60 +
 drivers/i2c/ppc4xx_i2c.c  |5 +--
 drivers/i2c/soft_i2c.c|1 -
 16 files changed, 110 insertions(+), 38 deletions(-)

--
1.7.5.2.317.g391b14

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

[U-Boot] [PATCH 1/2] console: Squelch pre-console output in console functions

[Graeme Russ]

There are some locations in the code which anticipate printf() being called
before the console is ready by squelching printf() on gd->have_console.
Move this squelching into printf(), vprintf(), puts() and putc(). Also
make tstc() and getc() return 0 if console is not yet initialised

Signed-off-by: Graeme Russ 
---
 arch/powerpc/cpu/mpc5xxx/i2c.c |   30 ++
 arch/powerpc/cpu/mpc8xx/i2c.c  |   18 ++
 common/console.c   |   18 ++
 drivers/i2c/ppc4xx_i2c.c   |5 +
 drivers/i2c/soft_i2c.c |1 -
 5 files changed, 35 insertions(+), 37 deletions(-)

diff --git a/arch/powerpc/cpu/mpc5xxx/i2c.c b/arch/powerpc/cpu/mpc5xxx/i2c.c
index 9fb330f..f9d293b 100644
--- a/arch/powerpc/cpu/mpc5xxx/i2c.c
+++ b/arch/powerpc/cpu/mpc5xxx/i2c.c
@@ -332,8 +332,7 @@ static int mpc_get_fdr(int speed)
if (gd->flags & GD_FLG_RELOC) {
fdr = divider;
} else {
-   if (gd->have_console)
-   printf("%ld kHz, ", best_speed / 1000);
+   printf("%ld kHz, ", best_speed / 1000);
return divider;
}
}
@@ -374,34 +373,29 @@ int i2c_read(uchar chip, uint addr, int alen, uchar *buf, 
int len)
xaddr[3] =  addr& 0xFF;
 
if (wait_for_bb()) {
-   if (gd->have_console)
-   printf("i2c_read: bus is busy\n");
+   printf("i2c_read: bus is busy\n");
goto Done;
}
 
mpc_reg_out(®s->mcr, I2C_STA, I2C_STA);
if (do_address(chip, 0)) {
-   if (gd->have_console)
-   printf("i2c_read: failed to address chip\n");
+   printf("i2c_read: failed to address chip\n");
goto Done;
}
 
if (send_bytes(chip, &xaddr[4-alen], alen)) {
-   if (gd->have_console)
-   printf("i2c_read: send_bytes failed\n");
+   printf("i2c_read: send_bytes failed\n");
goto Done;
}
 
mpc_reg_out(®s->mcr, I2C_RSTA, I2C_RSTA);
if (do_address(chip, 1)) {
-   if (gd->have_console)
-   printf("i2c_read: failed to address chip\n");
+   printf("i2c_read: failed to address chip\n");
goto Done;
}
 
if (receive_bytes(chip, (char *)buf, len)) {
-   if (gd->have_console)
-   printf("i2c_read: receive_bytes failed\n");
+   printf("i2c_read: receive_bytes failed\n");
goto Done;
}
 
@@ -423,27 +417,23 @@ int i2c_write(uchar chip, uint addr, int alen, uchar 
*buf, int len)
xaddr[3] =  addr& 0xFF;
 
if (wait_for_bb()) {
-   if (gd->have_console)
-   printf("i2c_write: bus is busy\n");
+   printf("i2c_write: bus is busy\n");
goto Done;
}
 
mpc_reg_out(®s->mcr, I2C_STA, I2C_STA);
if (do_address(chip, 0)) {
-   if (gd->have_console)
-   printf("i2c_write: failed to address chip\n");
+   printf("i2c_write: failed to address chip\n");
goto Done;
}
 
if (send_bytes(chip, &xaddr[4-alen], alen)) {
-   if (gd->have_console)
-   printf("i2c_write: send_bytes failed\n");
+   printf("i2c_write: send_bytes failed\n");
goto Done;
}
 
if (send_bytes(chip, (char *)buf, len)) {
-   if (gd->have_console)
-   printf("i2c_write: send_bytes failed\n");
+   printf("i2c_write: send_bytes failed\n");
goto Done;
}
 
diff --git a/arch/powerpc/cpu/mpc8xx/i2c.c b/arch/powerpc/cpu/mpc8xx/i2c.c
index 338caba..1ca51fd 100644
--- a/arch/powerpc/cpu/mpc8xx/i2c.c
+++ b/arch/powerpc/cpu/mpc8xx/i2c.c
@@ -633,22 +633,19 @@ int i2c_read(uchar chip, uint addr, int alen, uchar 
*buffer, int len)
 
rc = i2c_send(&state, chip, 0, I2CF_START_COND, alen, &xaddr[4-alen]);
if (rc != 0) {
-   if (gd->have_console)
-   printf("i2c_read: i2c_send failed (%d)\n", rc);
+   printf("i2c_read: i2c_send failed (%d)\n", rc);
return 1;
}
 
rc = i2c_receive(&state, chip, 0, I2CF_STOP_COND, len, buffer);
if (rc != 0) {
-   if (gd->have_console)
-   printf("i2c_read: i2c_receive failed (%d)\n", rc);
+   printf("i2c_read: i2c_receive failed (%d)\n", rc);
return 1;
}
 
rc = i2c_doio(&state);
if (rc != 0) {
-   if (gd->have_console)
-   printf("i2c_read: i2c_doio failed (%d)\n", rc);
+   printf("i2c_read: i2c_doio failed (%d)\n", rc);
return 1;
}

[U-Boot] [PATCH 2/2] console: Implement pre-console buffer

[Graeme Russ]

Allow redirection of console output prior to console initialisation to a
temporary buffer.

To enable this functionality, the board configuration file must define:
 - CONFIG_PRE_CONSOLE_BUFFER - Enable pre-console buffer
 - CONFIG_PRE_CON_BUF_ADDR - Base address of pre-console buffer
 - CONFIG_PRE_CON_BUF_SZ - Size of pre-console buffer (in bytes)

The pre-console buffer will buffer the first (CONFIG_PRE_CON_BUF_SZ -1)
bytes (need to allow for a null terminator). Any remaining characters are
silently dropped.

Signed-off-by: Graeme Russ 
---
 arch/arm/include/asm/global_data.h|3 ++
 arch/avr32/include/asm/global_data.h  |3 ++
 arch/blackfin/include/asm/global_data.h   |3 ++
 arch/m68k/include/asm/global_data.h   |3 ++
 arch/microblaze/include/asm/global_data.h |3 ++
 arch/mips/include/asm/global_data.h   |3 ++
 arch/nios2/include/asm/global_data.h  |3 ++
 arch/powerpc/include/asm/global_data.h|3 ++
 arch/sh/include/asm/global_data.h |3 ++
 arch/sparc/include/asm/global_data.h  |4 ++-
 arch/x86/include/asm/global_data.h|3 ++
 common/console.c  |   50 ++--
 12 files changed, 79 insertions(+), 5 deletions(-)

diff --git a/arch/arm/include/asm/global_data.h 
b/arch/arm/include/asm/global_data.h
index 4fc51fd..b85b7fe 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -38,6 +38,9 @@ typedef   struct  global_data {
unsigned long   flags;
unsigned long   baudrate;
unsigned long   have_console;   /* serial_init() was called */
+#ifdef CONFIG_PRE_CONSOLE_BUFFER
+   unsigned long   precon_buf_idx; /* Pre-Console buffer index */
+#endif
unsigned long   env_addr;   /* Address  of Environment struct */
unsigned long   env_valid;  /* Checksum of Environment valid? */
unsigned long   fb_base;/* base address of frame buffer */
diff --git a/arch/avr32/include/asm/global_data.h 
b/arch/avr32/include/asm/global_data.h
index 4ef8fc5..5c654bd 100644
--- a/arch/avr32/include/asm/global_data.h
+++ b/arch/avr32/include/asm/global_data.h
@@ -38,6 +38,9 @@ typedef   struct  global_data {
unsigned long   baudrate;
unsigned long   stack_end;  /* highest stack address */
unsigned long   have_console;   /* serial_init() was called */
+#ifdef CONFIG_PRE_CONSOLE_BUFFER
+   unsigned long   precon_buf_idx; /* Pre-Console buffer index */
+#endif
unsigned long   reloc_off;  /* Relocation Offset */
unsigned long   env_addr;   /* Address of env struct */
unsigned long   env_valid;  /* Checksum of env valid? */
diff --git a/arch/blackfin/include/asm/global_data.h 
b/arch/blackfin/include/asm/global_data.h
index eba5e93..f7aa711 100644
--- a/arch/blackfin/include/asm/global_data.h
+++ b/arch/blackfin/include/asm/global_data.h
@@ -45,6 +45,9 @@ typedef struct global_data {
unsigned long board_type;
unsigned long baudrate;
unsigned long have_console; /* serial_init() was called */
+#ifdef CONFIG_PRE_CONSOLE_BUFFER
+   unsigned long   precon_buf_idx; /* Pre-Console buffer index */
+#endif
phys_size_t ram_size;   /* RAM size */
unsigned long env_addr; /* Address  of Environment struct */
unsigned long env_valid;/* Checksum of Environment valid? */
diff --git a/arch/m68k/include/asm/global_data.h 
b/arch/m68k/include/asm/global_data.h
index fc486fd..0ba2b43 100644
--- a/arch/m68k/include/asm/global_data.h
+++ b/arch/m68k/include/asm/global_data.h
@@ -57,6 +57,9 @@ typedef   struct  global_data {
unsigned long   env_addr;   /* Address  of Environment struct   
*/
unsigned long   env_valid;  /* Checksum of Environment valid?   
*/
unsigned long   have_console;   /* serial_init() was called 
*/
+#ifdef CONFIG_PRE_CONSOLE_BUFFER
+   unsigned long   precon_buf_idx; /* Pre-Console buffer index */
+#endif
 #if defined(CONFIG_LCD) || defined(CONFIG_VIDEO)
unsigned long   fb_base;/* Base addr of framebuffer memory */
 #endif
diff --git a/arch/microblaze/include/asm/global_data.h 
b/arch/microblaze/include/asm/global_data.h
index 557ad27..6e8537c 100644
--- a/arch/microblaze/include/asm/global_data.h
+++ b/arch/microblaze/include/asm/global_data.h
@@ -39,6 +39,9 @@ typedef   struct  global_data {
unsigned long   flags;
unsigned long   baudrate;
unsigned long   have_console;   /* serial_init() was called */
+#ifdef CONFIG_PRE_CONSOLE_BUFFER
+   unsigned long   precon_buf_idx; /* Pre-Console buffer index */
+#endif
unsigned long   env_addr;   /* Address  of Environment struct */
unsigned long   env_valid;  /* Checksum of Environment valid? */
unsigned long   fb_base;/* base address of frame buffer */
diff --git a/arch/mips/incl

[U-Boot] From the Google UK Office**** Confirm your E-mail usage immediately***

[Online Team® UK]

We urgently wish to inform you again that your e-mail has w o n £850,000 UK 
Pounds {with L u c k y # :12-12-23-35-40-41(12) & T i c k e t # :008 695 757 
336 64} in our on-going Google UK 12th Anniversary Online P r o m o.
As indicated in your play coupon,Your w i n n i n g details falls under our 
ASIA Zone Disbursement booklet where your claim shall be processed.
Kindly confirm if this email is "still in use" by sending your Name and Country 
to enable us provide you with full information.
 
Email: thegoogleuk.giveawayt...@london.com
For Inquiry : +44 7031 810 508 
Congrats!!!
 
Mr. Brian
®2011 Giveaway Online Announcer


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

[U-Boot] Problem with u-boot after stage 0

[Mirko Banchi]

Hi all, we have developed a board very similar to MPC8306SOM board. We have 
some problems to run u-boot on. Briefly, the board has the same main components 
of the som board (RAM, NAND chip and a MPC8306 microprocessor) so we tried to 
use the same u-boot-nand.bin image for the boot. Something happens: the board 
starts, prints the message "NAND boot...transfering control" and nothing else 
happens. The first code is executed in NAND until nand_boot function (defined 
in the file nand_spl/nand_boot_fsl_elbc.c) is called: this copies in RAM the 
u-boot image and jumps at the address 0x0100. To make we sure that RAM is 
working ok we have modified the u-boot-nand.bin with istructions that reset the 
processor and all works ok. Surely the jump at 0x0100 happens and u-boot 
code starts to be executed but surely for some unknown reasons something goes 
wrong. Follow the u-boot code is very difficult also because is not clear to us 
how the "parts" of the boot loader are linked toghet
 er. Now some questions:

1- Looking at the dump of u-boot-nand.bin we saw that there are two "parts" of 
code very similar: one starts at offset 0x0 and the other at offset 0x2. 
Both parts begin with a reset configuration word followed by the u-boot magic 
number, string version etc... Which is the purpose of this two parts?This could 
be useful to better understand the boot process. For now we know only that the 
processor reads the configuration word in NAND at offset 0x0 and starts to 
execute istructions from offset 0x100 in NAND. The second "part" (that starts 
at offset 0x2) is then copied in RAM and the code that is executed is at 
location 0x01000120 in RAM.

2 - In the function nand_boot defined in nand_spl/nand_boot_fsl_elbc.c the last 
istruction is the call to the function pointed by the function pointer uboot 
(its value is 0x01000120). Where can i find the code executed here? Which is 
the relative source file? Looking at that source file maybe i can find where 
the boot could stop.  

Thank you all very much!

Best regards,

Mirko

--
Mirko Banchi

e-mail:mk.ban...@gmail.com
id-jabber: mk.ban...@jabber.org

PGP key fingerprint:

308F BFB1 4E67 2522 C88E 
DC69 7631 52ED 32A5 6456



___
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

[Mike Williams]

All,

On Fri, Aug 26, 2011 at 11:32 AM, Tirumala Marri  wrote:
> Hi Stefan,
>
>
>
>
>
> 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?
>
>  [Tirumala Marri] Sure we will test Mike’s fix on our 460Sx board. Once
> Mike’s patch accepted we will post follow-up patch for 460Sx changes.
>
>
>
> Regards,
>
> Marri

Unfortunately, our internal project ended and I've been moved to
another one with no access to the original hardware, which is out
indefinitely for demos. It should be as simple as adding an additional
#ifdef check with the new code for the 460GT/EX and the old code for
the 460SX, but I wouldn't be able to test anything past compilation.

Sorry for being unhelpful,
Mike
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Uboot 1.3.4 - splash screen problem

[Ramonf]

Hi, I'm running uboot 1.3.4 on AT91SAM9M10EKES board. I'm trying to load BMP
into it, but I get
"There is no valid bmp file at the given address" when I'm running bmp info.

what I do is this:

$ tftp 1 tftpboot/ramon.bmp
$ bmp i 1

I checked the BMP on my PC, and it's ok. what can be the problem ?
-- 
View this message in context: 
http://old.nabble.com/Uboot-1.3.4---splash-screen-problem-tp32357132p32357132.html
Sent from the Uboot - Users mailing list archive at Nabble.com.

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

[U-Boot] MIPS malta platform support in u-boot

[Abbas Raza]

Hello,

I want to use u-boot on MIPS malta platform. But as far as i know, 
u-boot has no support for MIPS malta platform. Is that right ? Can 
anyone guide me how to get support for this platform in u-boot , anyone 
has worked on it? will it require all work from scratch? Currently YAMON 
is available for this platform.


Thanks !

Abbas Raza

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

[U-Boot] [PATCH] MX25: tx25: Fix build by making use of GPIO framework

[Fabio Estevam]

From: Fabio Estevam 

Make use of GPIO framework and avoid the following build error:

tx25.c: In function 'tx25_fec_init':
tx25.c:73: error: dereferencing pointer to incomplete type
tx25.c:74: error: dereferencing pointer to incomplete type
tx25.c:75: error: dereferencing pointer to incomplete type
tx25.c:76: error: dereferencing pointer to incomplete type
tx25.c:83: error: dereferencing pointer to incomplete type
tx25.c:84: error: dereferencing pointer to incomplete type
tx25.c:114: error: dereferencing pointer to incomplete type
tx25.c:115: error: dereferencing pointer to incomplete type
tx25.c:116: error: dereferencing pointer to incomplete type
tx25.c:117: error: dereferencing pointer to incomplete type
tx25.c:124: error: dereferencing pointer to incomplete type
tx25.c:125: error: dereferencing pointer to incomplete type
tx25.c:126: error: dereferencing pointer to incomplete type

Signed-off-by: Fabio Estevam 
---
 board/karo/tx25/tx25.c |1 +
 include/configs/tx25.h |2 ++
 2 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/board/karo/tx25/tx25.c b/board/karo/tx25/tx25.c
index 25b99e8..ce75468 100644
--- a/board/karo/tx25/tx25.c
+++ b/board/karo/tx25/tx25.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static void mdelay(int n)
 {
diff --git a/include/configs/tx25.h b/include/configs/tx25.h
index b284daa..cb604a5 100644
--- a/include/configs/tx25.h
+++ b/include/configs/tx25.h
@@ -91,6 +91,8 @@
 #define CONFIG_BAUDRATE115200  /* Default baud rate */
 #define CONFIG_SYS_BAUDRATE_TABLE  { 9600, 19200, 38400, 57600, 115200 }
 
+#define CONFIG_MXC_GPIO
+
 /*
  * Flash & Environment
  */
-- 
1.7.1


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

Re: [U-Boot] [PATCH] MX25: tx25: Fix build by making use of GPIO framework

[Stefano Babic]

On 08/29/2011 04:27 PM, Fabio Estevam wrote:
> From: Fabio Estevam 
> 
> Make use of GPIO framework and avoid the following build error:


Hi Fabio,

> tx25.c:126: error: dereferencing pointer to incomplete type
> 
> Signed-off-by: Fabio Estevam 
> ---
>  board/karo/tx25/tx25.c |1 +
>  include/configs/tx25.h |2 ++
>  2 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/board/karo/tx25/tx25.c b/board/karo/tx25/tx25.c
> index 25b99e8..ce75468 100644
> --- a/board/karo/tx25/tx25.c
> +++ b/board/karo/tx25/tx25.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  

Thanks, I missed this board !

Acked-by: Stefano Babic 

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

[U-Boot] [PATCH] Makefile: remove tx25 exception

[Stefano Babic]

An entry in the main Makefile for the tx25 board is not
necessary, and the board is added to boards.cfg as all
other targets.

Signed-off-by: Stefano Babic 
CC: Wolfgang Denk 
---
 Makefile   |4 
 boards.cfg |1 +
 2 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/Makefile b/Makefile
index 676dc29..2166644 100644
--- a/Makefile
+++ b/Makefile
@@ -847,10 +847,6 @@ SX1_config:unconfig
fi;
@$(MKCONFIG) -n $@ SX1 arm arm925t sx1
 
-tx25_config: unconfig
-   @echo "CONFIG_NAND_U_BOOT = y" >> $(obj)include/config.mk
-   @$(MKCONFIG) $@ arm arm926ejs tx25 karo mx25
-
 edb9301_config \
 edb9302_config \
 edb9302a_config \
diff --git a/boards.cfg b/boards.cfg
index c31114d..6585163 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -162,6 +162,7 @@ rd6281a  arm arm926ejs   -  
 Marvell
 sheevaplug   arm arm926ejs   -   
Marvellkirkwood
 dockstar arm arm926ejs   -   
Seagatekirkwood
 jadecpu  arm arm926ejs   jadecpu 
syteco mb86r0x
+tx25 arm arm926ejs   tx25karo  
 mx25
 zmx25arm arm926ejs   zmx25   
syteco mx25
 imx27litearm arm926ejs   imx27lite   
logicpdmx27
 magnesiumarm arm926ejs   imx27lite   
logicpdmx27
-- 
1.7.1

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

[U-Boot] [PATCH 2/2] Add check that console is ready before output

[Simon Glass]

If puts() or printf() is called before the console is ready, U-Boot will
either hang or die. This adds a check for this so that debug() can be used
in early code without concern that it will hang.

U-Boot boots properly

Tested-by: Simon Glass 
Signed-off-by: Simon Glass 
---
 common/console.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/common/console.c b/common/console.c
index 8c650e0..28ddb95 100644
--- a/common/console.c
+++ b/common/console.c
@@ -338,7 +338,7 @@ void putc(const char c)
if (gd->flags & GD_FLG_DEVINIT) {
/* Send to the standard output */
fputc(stdout, c);
-   } else {
+   } else if (gd->have_console) {
/* Send directly to the handler */
serial_putc(c);
}
@@ -359,7 +359,7 @@ void puts(const char *s)
if (gd->flags & GD_FLG_DEVINIT) {
/* Send to the standard output */
fputs(stdout, s);
-   } else {
+   } else if (gd->have_console) {
/* Send directly to the handler */
serial_puts(s);
}
-- 
1.7.3.1

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

[U-Boot] [PATCH 1/2] Add board_panic_no_console to deal with early critical errors

[Simon Glass]

Tested-by: Simon Glass 
Signed-off-by: Simon Glass 
---
 include/common.h |8 
 lib/vsprintf.c   |   26 --
 2 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/include/common.h b/include/common.h
index 12a1074..856df9a 100644
--- a/include/common.h
+++ b/include/common.h
@@ -250,6 +250,14 @@ intlast_stage_init(void);
 extern ulong monitor_flash_len;
 int mac_read_from_eeprom(void);
 
+/*
+ * Called during a panic() when no console is available. The board should do
+ * its best to get a message to the user any way it can. This function should
+ * return if it can, in which case the system will either hang or reset.
+ * See panic().
+ */
+void board_panic_no_console(const char *str);
+
 /* common/flash.c */
 void flash_perror (int);
 
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index c029fbb..fd742a9 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -24,6 +24,8 @@
 # define NUM_TYPE long long
 #define noinline __attribute__((noinline))
 
+DECLARE_GLOBAL_DATA_PTR;
+
 const char hex_asc[] = "0123456789abcdef";
 #define hex_asc_lo(x)   hex_asc[((x) & 0x0f)]
 #define hex_asc_hi(x)   hex_asc[((x) & 0xf0) >> 4]
@@ -714,13 +716,33 @@ int sprintf(char * buf, const char *fmt, ...)
return i;
 }
 
+/* Provide a default function for when no console is available */
+static void __board_panic_no_console(const char *msg)
+{
+   /* Just return since we can't access the console */
+}
+
+void board_panic_no_console(const char *msg) __attribute__((weak,
+   alias("__board_panic_no_console")));
+
 void panic(const char *fmt, ...)
 {
+   char str[CONFIG_SYS_PBSIZE];
va_list args;
+
va_start(args, fmt);
-   vprintf(fmt, args);
-   putc('\n');
+
+   /* TODO)sjg): Move to vsnprintf() when available */
+   vsprintf(str, fmt, args);
va_end(args);
+
+   if (gd->have_console) {
+   puts(str);
+   putc('\n');
+   } else {
+   board_panic_no_console(str);
+   }
+
 #if defined (CONFIG_PANIC_HANG)
hang();
 #else
-- 
1.7.3.1

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

[U-Boot] [RFC PATCH 0/2] Early panic support

[Simon Glass]

This patch set adds support for calling panic() before stdio is initialized.
At present this will just hang with little or no indication of what the
problem is.

A new board_panic_no_console() function is added to the board API. If provided
by the board it will be called in the event of a panic before the console is
ready. This function should turn on all UARTS and spray the message out if
it possibly can.

This is somewhat related to the Graeme's pre-console buffer patch, which is
why I am sending it for comment now.


Simon Glass (2):
  Add board_panic_no_console to deal with early critical errors
  Add check that console is ready before output

 common/console.c |4 ++--
 include/common.h |8 
 lib/vsprintf.c   |   26 --
 3 files changed, 34 insertions(+), 4 deletions(-)

-- 
1.7.3.1

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

[U-Boot] [PATCH] 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

changes after slicing this from patch
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/106422:
DEL Prototype declaration - not necessary if reordered
DEL Most #ifdefs - relying on -ffunction-sections and --gc-sections to handle 
unused
CHG reorganized bootm. powerpc implementation was the model
ADD get_board_serial fake implementation - this is needed if setup_serial_tag
is compiled but the board doesn't support it - tradeoff for removing
#ifdefs
---
 arch/arm/lib/bootm.c |  330 +
 1 files changed, 168 insertions(+), 162 deletions(-)

diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 802e833..5f112e2 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -1,4 +1,8 @@
-/*
+/* Copyright (C) 2011
+ * Corscience GmbH & Co. KG - Simon Schwarz 
+ *  - Added prep subcommand support
+ *  - Reorganized source - modeled after powerpc version
+ *
  * (C) Copyright 2002
  * Sysgo Real-Time Solutions, GmbH 
  * Marius Groeger 
@@ -32,31 +36,16 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-#if defined (CONFIG_SETUP_MEMORY_TAGS) || \
-defined (CONFIG_CMDLINE_TAG) || \
-defined (CONFIG_INITRD_TAG) || \
-defined (CONFIG_SERIAL_TAG) || \
-defined (CONFIG_REVISION_TAG)
-static void setup_start_tag (bd_t *bd);
-
-# ifdef CONFIG_SETUP_MEMORY_TAGS
-static void setup_memory_tags (bd_t *bd);
-# endif
-static void setup_commandline_tag (bd_t *bd, char *commandline);
-
-# ifdef CONFIG_INITRD_TAG
-static void setup_initrd_tag (bd_t *bd, ulong initrd_start,
- ulong initrd_end);
-# endif
-static void setup_end_tag (bd_t *bd);
-
+static void (*kernel_entry)(int zero, int arch, uint params);
 static struct tag *params;
-#endif /* CONFIG_SETUP_MEMORY_TAGS || CONFIG_CMDLINE_TAG || CONFIG_INITRD_TAG 
*/
 
-static ulong get_sp(void);
-#if defined(CONFIG_OF_LIBFDT)
-static int bootm_linux_fdt(int machid, bootm_headers_t *images);
-#endif
+static ulong get_sp(void)
+{
+   ulong ret;
+
+   asm("mov %0, sp" : "=r"(ret) : );
+   return ret;
+}
 
 void arch_lmb_reserve(struct lmb *lmb)
 {
@@ -80,85 +69,6 @@ void arch_lmb_reserve(struct lmb *lmb)
gd->bd->bi_dram[0].start + gd->bd->bi_dram[0].size - sp);
 }
 
-static void announce_and_cleanup(void)
-{
-   printf("\nStarting kernel ...\n\n");
-
-#ifdef CONFIG_USB_DEVICE
-   {
-   extern void udc_disconnect(void);
-   udc_disconnect();
-   }
-#endif
-   cleanup_before_linux();
-}
-
-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);
-
-#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);
-
-#ifdef CONFIG_OF_LIBFDT
-   if (images->ft_len)
-   return bootm_linux_fdt(machid, images);
-#endif
-
-   kernel_entry = (void (*)(int, int, uint))images->ep;
-
-   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);
-#ifdef CONFIG_SERIAL_TAG
-   setup_serial_tag (¶ms);
-#endif
-#ifdef CONFIG_REVISION_TAG
-   setup_revision_tag (¶ms);
-#endif
-#ifdef CONFIG_SETUP_MEMORY_TAGS
-   setup_memory_tags (bd);
-#endif
-#ifdef CONFIG_CMDLINE_TAG
-   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);
-#endif
-   setup_end_tag(bd);
-#endif
-
-   announce_and_cleanup();
-
-   kernel_entry(0, machid, bd->bi_boot_params);
-   /* does not return */
-
-   return 1;
-}
-
-#if defined(CONFIG_OF_LIBFDT)
 static int fixup_memory_node(void *blob)
 {
bd_t*bd = gd->bd;
@@ -174,54 +84,19 @@ 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 void announce_and_cleanup(void)
 {
-   ulong rd_len;
-   void 

Re: [U-Boot] [PATCH 2/2 v4] powerpc/p1023rds: Disable nor flash node and enable nand flash node

[Scott Wood]

On 08/29/2011 02:42 AM, Wolfgang Denk wrote:
> Dear Chunhe Lan,
> 
> In message <1314602152-9114-1-git-send-email-chunhe@freescale.com> you 
> wrote:
>> In the p1023rds, accessing exclusively nor flash or nand flash device by
>> BR0/OR0.
> ...
>> When booting from nor flash, the status of nor node is null that means it
>> is enabled and the status of nand node is disabled in the default dts file,
>> so do not do anything.
> 
> It would be more intuitive to the reader, when the enabled node would
> use an explicit
> 
>   status = "enabled";
> 
>> +#ifdef CONFIG_NAND_U_BOOT
>> +do_fixup_by_path_string(fdt, "nor_flash", "status", "disabled");
>> +do_fixup_by_path_string(fdt, "nand_flash", "status", "okay");
>> +#endif
> 
> What does ""okay" mean?  This is not documented anywhere.

It is documented in ePAPR and IEEE 1275.

> Is this supposed to mean "enabled"?

Yes, or more specifically, "The device is believed to be operational."

It's generally equivalent to having no status property at all.

> Then please write "enabled" 

Please don't redefine well-established standards.

-Scott

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

[U-Boot] [RFC PATCH] Pre-console buffer for ARM

[Simon Glass]

This patch is for Graeme to take a look at. I found that have_console is
not a flag yet. Also a few tidy-ups to handle buffer overflow and to avoid
printing a 'dumping buffer' message when nothing was outputted.

Also I tried to simplify the maths for the location of the pre-console buffer.
IMO this should be done in board.c though.

Signed-off-by: Simon Glass 
---
 arch/arm/include/asm/global_data.h |1 +
 common/console.c   |   36 
 include/configs/tegra2-common.h|8 ++--
 3 files changed, 43 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/global_data.h 
b/arch/arm/include/asm/global_data.h
index 4fc51fd..8b028cc 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -71,6 +71,7 @@ typedef   struct  global_data {
unsigned long   start_addr_sp;  /* start_addr_stackpointer */
unsigned long   reloc_off;
 #if !(defined(CONFIG_SYS_ICACHE_OFF) && defined(CONFIG_SYS_DCACHE_OFF))
+   unsigned long   con_buf_idx;/* Console buffer index */
unsigned long   tlb_addr;
 #endif
void**jt;   /* jump table */
diff --git a/common/console.c b/common/console.c
index 8c650e0..2a7d2c8 100644
--- a/common/console.c
+++ b/common/console.c
@@ -323,6 +323,36 @@ int tstc(void)
return serial_tstc();
 }
 
+void pre_console_putc(const char c)
+{
+   char *buffer =  (char *)CONFIG_SYS_TMP_CON_BUF_ADDR;
+
+   if (gd->con_buf_idx < CONFIG_SYS_TMP_CON_BUF_SZ)
+   buffer[gd->con_buf_idx++] = c;
+}
+
+void pre_console_puts(const char *s)
+{
+   while (*s)
+   pre_console_putc(*s++);
+}
+
+void print_pre_console_buffer(void)
+{
+   char *buffer =  (char *)CONFIG_SYS_TMP_CON_BUF_ADDR;
+   int index = gd->con_buf_idx;
+
+   if (index) {
+   printf("console initialised - dumping pre-console buffer:\n");
+   index = min(index, CONFIG_SYS_TMP_CON_BUF_SZ - 1);
+   buffer[index] = '\0';
+   puts(buffer);
+   if (gd->con_buf_idx == CONFIG_SYS_TMP_CON_BUF_SZ)
+   puts("... (buffer overflowed)\n");
+   printf("buffer dumped\n");
+   }
+}
+
 void putc(const char c)
 {
 #ifdef CONFIG_SILENT_CONSOLE
@@ -341,6 +371,8 @@ void putc(const char c)
} else {
/* Send directly to the handler */
serial_putc(c);
+   } else {
+   pre_console_putc(c);
}
 }
 
@@ -362,6 +394,8 @@ void puts(const char *s)
} else {
/* Send directly to the handler */
serial_puts(s);
+   } else {
+   pre_console_puts(s);
}
 }
 
@@ -529,6 +563,8 @@ int console_init_f(void)
gd->flags |= GD_FLG_SILENT;
 #endif
 
+   print_pre_console_buffer();
+
return 0;
 }
 
diff --git a/include/configs/tegra2-common.h b/include/configs/tegra2-common.h
index 73e0f05..a42cce1 100644
--- a/include/configs/tegra2-common.h
+++ b/include/configs/tegra2-common.h
@@ -156,8 +156,12 @@
 
 #define CONFIG_SYS_INIT_RAM_ADDR   CONFIG_STACKBASE
 #define CONFIG_SYS_INIT_RAM_SIZE   CONFIG_SYS_MALLOC_LEN
-#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_INIT_RAM_ADDR + \
-   CONFIG_SYS_INIT_RAM_SIZE - \
+#define CONFIG_SYS_TMP_CON_BUF_SZ  (1 * 1024)
+#define CONFIG_SYS_INIT_RAM_TOP(CONFIG_SYS_INIT_RAM_ADDR  + \
+   CONFIG_SYS_INIT_RAM_SIZE)
+#define CONFIG_SYS_TMP_CON_BUF_ADDR(CONFIG_SYS_INIT_RAM_TOP - \
+   CONFIG_SYS_TMP_CON_BUF_SZ)
+#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_TMP_CON_BUF_ADDR - \
GENERATED_GBL_DATA_SIZE)
 
 #define CONFIG_TEGRA2_GPIO
-- 
1.7.3.1

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

Re: [U-Boot] Uboot 1.3.4 - splash screen problem

[Jens Scharsig]

Am 2011-08-29 16:04, schrieb Ramonf:
> 
> Hi, I'm running uboot 1.3.4 on AT91SAM9M10EKES board. I'm trying to load BMP
> into it, but I get
> "There is no valid bmp file at the given address" when I'm running bmp info.
> 
> what I do is this:
> 
> $ tftp 1 tftpboot/ramon.bmp
> $ bmp i 1
> 
> I checked the BMP on my PC, and it's ok. what can be the problem ?

Dear Ramonf,

are you sure, that 1 is located in an RAM area?
AT91 SDRAM starts ant 0x2000

By the way, 1.3 is an legacy version of u-boot (over 3 year old)

Best Regards

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

Re: [U-Boot] [RFC PATCH] net: Check network device driver name

[Mike Frysinger]

On Monday, August 29, 2011 04:07:14 Michal Simek wrote:
> Mike Frysinger wrote:
> > On Friday, August 26, 2011 08:52:40 Michal Simek wrote:
> >> If name is longer than allocated space NAMESIZE
> >> mac address is rewritten which show error
> > 
> >> message like:
> > since you overflowed the buffer, who knows what could happen ...
> > 
> >> +  if (strlen(dev->name) > NAMESIZE) {
> >> +  printf("Long(%d>%d) network driver name for %s\n",
> >> +  strlen(dev->name), NAMESIZE, dev->name);
> >> +  return 0;
> >> +  }
> > 
> > size_t len = strlen(dev->name);
> > if (len >= NAMESIZE) {
> > 
> > printf("network driver name is too long (%zu >= %zu): %s\n",
> > 
> > len, NAMESIZE, dev->name);
> > 
> > return -1;
> > 
> > }
> 
> ok. I see it is 15 chars space + terminated characters.
> 
> Mike: Will you propose this patch or should I do it?

since you've got stuff pending here, best for you to do it :)
-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] Global Data: Flagify have_console and env_valid

[Scott Wood]

On 08/26/2011 03:15 PM, Mike Frysinger wrote:
> looks sane enough to me
> 
> when changing the global_data structure, do we need to bump the u-boot 
> standalone API number (XF_VERSION in exports.h) ?  and i vaguely recall 
> global 
> data being passed to like Linux for some arches ?  although looking at the 
> number of #ifdef's in there, maybe that's already been a long lost battle.

The data passed to Linux in the non-device-tree case was bd_t, not gd_t.

Of course, that's full of ifdefs too, at least on powerpc. :-P

-Scott

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

Re: [U-Boot] [RFC PATCH] Pre-console buffer for ARM

[Mike Frysinger]

On Monday, August 29, 2011 13:21:57 Simon Glass wrote:
> +void pre_console_putc(const char c)
> +{
> + char *buffer =  (char *)CONFIG_SYS_TMP_CON_BUF_ADDR;

excess space after the "="

> + if (gd->con_buf_idx < CONFIG_SYS_TMP_CON_BUF_SZ)
> + buffer[gd->con_buf_idx++] = c;

seems like a circular buffer would make more sense ... usually the part of the 
log you want is the last chunk and not the first
-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] net: ll_temac: Add LL TEMAC driver to u-boot

[Mike Frysinger]

On Monday, August 29, 2011 07:34:12 Michal Simek wrote:
> --- /dev/null
> +++ b/drivers/net/xilinx_ll_temac.c
> 
> +#include 

what do you need from this header ?

> +#ifdef SDMA_MODE
> +static unsigned char tx_buffer[PKTSIZE_ALIGN ] __attribute((aligned(32)));
> +#endif
> +static unsigned char rx_buffer[PKTSIZE_ALIGN ] __attribute((aligned(32)));

no space before that "]"

> +static inline void temac_out_be32(u32 addr, u32 offset, u32 val)
> +{
> + out_be32((u32 *)(addr + offset), val);
> +}
> +
> +static inline u32 temac_in_be32(u32 addr, u32 offset)
> +{
> + return in_be32((u32 *)(addr + offset));
> +}

write a C struct describing the register layout, then your code can simply do:
in_be32(®s->lsw0)
and you don't need these two helpers

> +static int xps_ll_temac_addr_setup(struct eth_device *dev)
> +{
> + int val;
> +
> + /* set up unicast MAC address filter */
> + val = ((dev->enetaddr[3] << 24) | (dev->enetaddr[2] << 16) |
> + (dev->enetaddr[1] << 8) | (dev->enetaddr[0]));
> + xps_ll_temac_indirect_set(dev, 0, UAW0, val);
> + val = (dev->enetaddr[5] << 8) | dev->enetaddr[4] ;
> + xps_ll_temac_indirect_set(dev, 0, UAW1, val);
> +
> + return 0;
> +}

this should be set to dev->write_hwaddr in the initialize func

> +int xilinx_ll_temac_initialize(bd_t *bis, int base_addr)

the register base address really should be "unsigned long" and not "int"
-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 v3 1/3] net: Adds Fast Ethernet Controller driver for Armada100

[Mike Frysinger]

On Monday, August 29, 2011 01:39:18 Ajay Bhargav wrote:
> - "Mike Frysinger"  wrote:
> > On Monday, August 29, 2011 01:10:49 Ajay Bhargav wrote:
> > > - "Mike Frysinger"  wrote:
> > > > On Friday, August 26, 2011 02:36:51 Ajay Bhargav wrote:
> > > > > +darmdfec = malloc(sizeof(struct armdfec_device));
> > > > > +if (!darmdfec)
> > > > > +goto error;
> > > > 
> > > > if this first one fails, we jump to:
> > > > > +error:
> > > > > +free(darmdfec->p_aligned_txbuf);
> > > > > +free(darmdfec->p_rxbuf);
> > > > > +free(darmdfec->p_rxdesc);
> > > > > +free(darmdfec->htpr);
> > > > 
> > > > looks like 4 NULL pointer derefs.  so you'll need one specific
> > 
> > path
> > 
> > > > for the first malloc(), but the rest are fine.
> > > 
> > > so you mean like this...
> > > 
> > > if(!darmdfec)
> > > 
> > > goto error;
> > > 
> > > ...
> > > 
> > > error1:
> > > free(darmdfec->p_aligned_txbuf);
> > > free(darmdfec->p_rxbuf);
> > > free(darmdfec->p_rxdesc);
> > > free(darmdfec->htpr);
> > > 
> > > error:
> > > free(darmdfec);
> > > return -1;
> > 
> > that's one way of fixing it
> 
> Any other better way?

since all your buffers are known fixed (at compile time) sizes, you could 
simply inline them into the structure so you only malloc() one buffer
-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 PATCH] Pre-console buffer for ARM

[Simon Glass]

Hi Mike,

On Mon, Aug 29, 2011 at 12:20 PM, Mike Frysinger  wrote:
> On Monday, August 29, 2011 13:21:57 Simon Glass wrote:
>> +void pre_console_putc(const char c)
>> +{
>> +     char *buffer =  (char *)CONFIG_SYS_TMP_CON_BUF_ADDR;
>
> excess space after the "="

Thanks - I will leave this to Graeme to tidy as our patches overlap
(and most of the patch is just his).

>
>> +     if (gd->con_buf_idx < CONFIG_SYS_TMP_CON_BUF_SZ)
>> +             buffer[gd->con_buf_idx++] = c;
>
> seems like a circular buffer would make more sense ... usually the part of the
> log you want is the last chunk and not the first

Yes I agree, although if you have more than 1KB of data it might be a bug.

Regards,
SImon

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

Re: [U-Boot] [PATCH] Makefile: remove tx25 exception

[Wolfgang Denk]

Dear Stefano Babic,

In message <1314629830-32588-1-git-send-email-sba...@denx.de> you wrote:
> An entry in the main Makefile for the tx25 board is not
> necessary, and the board is added to boards.cfg as all
> other targets.

In theorey you are right, but this patch appears to be wrong:

> -tx25_config  : unconfig
> - @echo "CONFIG_NAND_U_BOOT = y" >> $(obj)include/config.mk
> - @$(MKCONFIG) $@ arm arm926ejs tx25 karo mx25

The Makefile defined CONFIG_NAND_U_BOOT

> +tx25 arm arm926ejs   tx25
> karo   mx25

This new entry fails to do that.   Please make sure to add NAND_U_BOOT
in the "Options" column.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
In accord with UNIX philosophy, Perl gives you enough  rope  to  hang
yourself.  - L. Wall & R. L. Schwartz, _Programming Perl_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2 v4] powerpc/p1023rds: Disable nor flash node and enable nand flash node

[Wolfgang Denk]

Dear Scott Wood,

In message <4e5bbe52.7080...@freescale.com> you wrote:
>
> >> +#ifdef CONFIG_NAND_U_BOOT
> >> +  do_fixup_by_path_string(fdt, "nor_flash", "status", "disabled");
> >> +  do_fixup_by_path_string(fdt, "nand_flash", "status", "okay");
> >> +#endif
> > 
> > What does ""okay" mean?  This is not documented anywhere.
> 
> It is documented in ePAPR and IEEE 1275.

Ah, thanks for poointing out.

> > Is this supposed to mean "enabled"?
> 
> Yes, or more specifically, "The device is believed to be operational."
> 
> It's generally equivalent to having no status property at all.
> 
> > Then please write "enabled" 
> 
> Please don't redefine well-established standards.

Agreed.  Sorry, I was not aware of this definition in ePAPR.

But I guess most lreaders will - like me - fail to recognize this
relation, and the presented documentation is more confusing than
helpful.

If the recommendation is to omit the status entry in the device tree,
we should omit it in the code above, too.   Otherwise, we should set
status to okay in both cases.  Having one here and the other there is
at best confusing.

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
Remember that Beethoven wrote his first symphony in C ...
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH] Pre-console buffer for ARM

[Mike Frysinger]

On Monday, August 29, 2011 15:42:23 Simon Glass wrote:
> On Mon, Aug 29, 2011 at 12:20 PM, Mike Frysinger wrote:
> > On Monday, August 29, 2011 13:21:57 Simon Glass wrote:
> >> + if (gd->con_buf_idx < CONFIG_SYS_TMP_CON_BUF_SZ)
> >> + buffer[gd->con_buf_idx++] = c;
> > 
> > seems like a circular buffer would make more sense ... usually the part
> > of the log you want is the last chunk and not the first
> 
> Yes I agree, although if you have more than 1KB of data it might be a bug.

give people a foot and they'll take 1MiB :p

it's fairly easy as well:
#define CIRC_BUF_IDX(idx) ((idx) & (CONFIG_SYS_TMP_CON_BUF_SZ-1))
buffer[CIRC_BUF_IDX(gd->conf_buf_idx++)] = c;
-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] mmc:dcache: Cache line size aligned internal MMC buffers

[Anton Staaf]

On Wed, Aug 24, 2011 at 1:13 PM, Anton Staaf  wrote:
> On Wed, Aug 24, 2011 at 12:18 PM, Lukasz Majewski  
> wrote:
>> On Wed, 24 Aug 2011 11:25:42 -0700
>> Anton Staaf  wrote:
>>
>>> On Wed, Aug 24, 2011 at 11:12 AM, Wolfgang Denk  wrote:
>>> > Dear Anton Staaf,
>>> >
>>> > In message
>>> > 
>>> > you wrote:
>>> >>
>>> >> >> 4. get_dcache_line_size() can be simply defined as
>>> >> >> #define get_dcache_line_size() CONFIG_SYS_CACHE_LINE_SIZE if we
>>> >> >> _really_ want to save a few bytes.
>>> >> >
>>> >> > Actually I fail to understand why we would ever need
>>> >> > get_dcache_line_size() in a boot loader.
>>> >>
>>> >> It is required so that we can correctly allocate buffers that will
>>> >> be used by DMA engines to read or write data.  The reason that
>>> >> these
>>> >
>>> > No, it is definitely NOT needed for this purpose - we have been
>>> > using CONFIG_SYS_CACHE_LINE_SIZE for more than a decade without
>>> > problems, so I don't really understand why we now would need a new
>>> > function for this?
>>>
>>
>> Ok, so one problem solved :-).
>>
>>> Ahh, I misunderstood your question.  I thought you were asking about
>>> the need to know the cache line size.  Not it's specific
>>> implementation as a function call.  In which case, I agree, and am
>>> happy to use CONFIG_SYS_CACHE_LINE_SIZE, though I don't see any
>>> definitions of CONFIG_SYS_CACHE_LINE_SIZE in the entire U-Boot tree.
>>> What have I missed?
>>>
>>
>> There are some similar definitions:
>> ./include/configs/atstk1006.h:#define CONFIG_SYS_DCACHE_LINESZ 32
>> ./include/configs/atngw100.h:#define CONFIG_SYS_DCACHE_LINESZ 32
>> ./include/configs/favr-32-ezkit.h:#define
>> CONFIG_SYS_DCACHE_LINESZ 32
>
> I would assume that these should be changed to the one mentioned by
> Wolfgang.  But this still leaves us with a question of how to make a
> simple, easy to use macro for allocating cache line size aligned stack
> buffers.  I'll work on that some more and see if I can come up with
> something.

OK, better late than never, I've run down all of the solutions I can
think of.  Below are three solutions and one non-solution, how they
would be used, and what I see as pro's and con's for each.


1) Mikes's macro

#define DMA_ALIGN_SIZE(size) \
   (((size) + CONFIG_SYS_CACHELINE_SIZE - 1)

#define DMA_DECLARE_BUFFER(type, name, size) \
   void __##name[DMA_ALIGN_SIZE(size * sizeof(type))]; \
   type * name = __##name & ~(CONFIG_SYS_CACHELINE_SIZE - 1));

DMA_DECLARE_BUFFER(int, buffer, 100);

Pros: Doesn't use alloca, doesn't use malloc and doesn't use new GCC
alignment attribute abilities.  This makes it the most portable, and
the most supported solution.

Cons: It's a pretty ugly macro that obfuscates the creation of
multiple variables.  Thus I would say it falls into the macro magic
category.


It looks like this is already working it's way into a patch.  So the
rest of my comments below may be moot.


2) Use alloca wrapped in a macro:

#define alloca_cacheline_alligned(size) alloca(size +
CONFIG_SYS_CACHELINE_SIZE - 1) & ~(CONFIG_SYS_CACHELINE_SIZE - 1)

int * buffer = alloca_cacheline_alligned(100 * sizeof(int));

Pros: It is fairly obvious what the above code is intended to do, even
to someone that doesn't know the underlying implementation of the
macro.

Cons: Wolfgang does not want alloca in the U-Boot codebase.


I would like to know, mainly for my education, why you do not want
alloca, but are OK with dynamic array sizing (as in the first solution
above).  My understanding is that they pretty much equate to the same
thing.  What is it about alloca that is objectionable?


3) Use GCC specific alignment attribute:

#define CACHLINE_ALIGNED __attribute__ ((aligned (CONFIG_SYS_CACHELINE_SIZE)))

int buffer[100] CACHELINE_ALIGNED;

Pros: The declaration of the buffer is even simpler and more obvious,
no use of alloca at all.

Cons: This doesn't work in any version of GCC before October 2010.
Meaning that it probably doesn't work in whatever compiler you're
using.


It's really too bad that this isn't a usable solution.  I suppose that
we could switch to it at some point when we expect U-Boot to only be
compiled by versions of GCC that support this.  By the way, the
failure mode here is pretty bad.  If you compile the above code with
an older GCC it will silently fail to align the variable.  :(


4) Use memalign and free:

int * buffer = memalign(CONFIG_SYS_CACHELINE_SIZE, 100 * sizeof(int));

free(buffer);

Pros: portable.

Cons: Heap instead of Stack allocation.  The result is that it's
slower, and requires more manual management of buffers.  Also,
Wolfgang is opposed to this solution.


I think I agree with this not being a great solution.  I do wonder if
it would be useful to consider a dedicated buffer management API that
could be used to allocate and free cache line aligned power of two
buffers.  Perhaps something like a buddy heap for simplicity.


Thanks,
Anton

> Thanks,
>    Anton
>
>>
>>> Thanks,
>>>     Anton
>>

Re: [U-Boot] [PATCH 2/2 v4] powerpc/p1023rds: Disable nor flash node and enable nand flash node

[Tabi Timur-B04825]

On Mon, Aug 29, 2011 at 2:15 AM, Chunhe Lan  wrote:
> In the p1023rds, accessing exclusively nor flash or nand flash device by
> BR0/OR0.

This is not an English sentence.  I do not understand what you're saying.

-- 
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] [PATCH 1/2] MX25: tx25: Avoid the usage of extern in C file

[Fabio Estevam]

Avoid the usage of extern in C file as pointed out by checkpatch.

Signed-off-by: Fabio Estevam 
---
 arch/arm/include/asm/arch-mx27/imx-regs.h |1 +
 board/karo/tx25/tx25.c|2 --
 2 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/arch-mx27/imx-regs.h 
b/arch/arm/include/asm/arch-mx27/imx-regs.h
index b4b2fe6..0c1cda9 100644
--- a/arch/arm/include/asm/arch-mx27/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx27/imx-regs.h
@@ -27,6 +27,7 @@
 #ifndef __ASSEMBLY__
 
 extern void imx_gpio_mode (int gpio_mode);
+extern void mx25_uart1_init_pins(void);
 
 #ifdef CONFIG_MXC_UART
 extern void mx27_uart1_init_pins(void);
diff --git a/board/karo/tx25/tx25.c b/board/karo/tx25/tx25.c
index 25b99e8..c34672a 100644
--- a/board/karo/tx25/tx25.c
+++ b/board/karo/tx25/tx25.c
@@ -141,8 +141,6 @@ void tx25_fec_init(void)
 int board_init()
 {
 #ifdef CONFIG_MXC_UART
-   extern void mx25_uart1_init_pins(void);
-
mx25_uart1_init_pins();
 #endif
/* board id for linux */
-- 
1.7.1


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

Re: [U-Boot] [PATCH] mmc:dcache: Cache line size aligned internal MMC buffers

[Wolfgang Denk]

Dear Anton Staaf,

In message  
you wrote:
>
> I would like to know, mainly for my education, why you do not want
> alloca, but are OK with dynamic array sizing (as in the first solution
> above).  My understanding is that they pretty much equate to the same
> thing.  What is it about alloca that is objectionable?

First, I've got bitten by alloca() before, when GCC misbehaved.
Admitted, that was in some _very_ old version, but such experience
sticks.

Second, the behaviour of alloca() depends on a number of non-obvious
settings and compiler flags, and results are not always obvious.  rom
the man page:

   Notes on the GNU Version
   Normally, gcc(1) translates calls to alloca() with inlined
   code. This is not done when either the -ansi, -std=c89,
   -std=c99, or the -fno-builtin option is given (and the header
is not included). But beware! By default the glibc
   version of  includes  and that contains
   the line:

   #define alloca(size)   __builtin_alloca (size)

   with messy consequences if one has a private version of this function.

This is nothing I want to have in any production software. OK, you
may argument that U-Boot has a strictly controlled environment, but
anyway.

Third, the man page says:

NOTES

   The alloca() function is machine- and compiler-dependent. For
   certain applications, its use can improve efficiency compared
   to the use of malloc(3) plus free(3). In certain cases, it can
   also simplify memory deallocation in applications that use
   longjmp(3) or siglongjmp(3).
   Otherwise, its use is discouraged.

In my opinion, U-Boot falls into the "otherwise" category...


> I think I agree with this not being a great solution.  I do wonder if
> it would be useful to consider a dedicated buffer management API that
> could be used to allocate and free cache line aligned power of two
> buffers.  Perhaps something like a buddy heap for simplicity.

The longer I read this thread, the less frightening Mikes's macro
becomes (compared tho the alternatives).

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
"Though a program be but three lines long,
someday it will have to be maintained."
- The Tao of Programming
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/2] MX25: Add initial support for MX25PDK

[Fabio Estevam]

Add the initial support for MX25PDK booting from SD card via internal boot.

Signed-off-by: Fabio Estevam 
---
 MAINTAINERS |1 +
 board/freescale/mx25pdk/Makefile|   49 ++
 board/freescale/mx25pdk/imximage.cfg|   73 +
 board/freescale/mx25pdk/lowlevel_init.S |   21 ++
 board/freescale/mx25pdk/mx25pdk.c   |   62 +
 boards.cfg  |1 +
 include/configs/mx25pdk.h   |  109 +++
 7 files changed, 316 insertions(+), 0 deletions(-)
 create mode 100644 board/freescale/mx25pdk/Makefile
 create mode 100644 board/freescale/mx25pdk/imximage.cfg
 create mode 100644 board/freescale/mx25pdk/lowlevel_init.S
 create mode 100644 board/freescale/mx25pdk/mx25pdk.c
 create mode 100644 include/configs/mx25pdk.h

diff --git a/MAINTAINERS b/MAINTAINERS
index f895e9a..7f07b60 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -645,6 +645,7 @@ Kristoffer Ericson 
 
 Fabio Estevam 
 
+   mx25pdk i.MX25
mx31pdk i.MX31
mx53ard i.MX53
mx53smd i.MX53
diff --git a/board/freescale/mx25pdk/Makefile b/board/freescale/mx25pdk/Makefile
new file mode 100644
index 000..4d45ae3
--- /dev/null
+++ b/board/freescale/mx25pdk/Makefile
@@ -0,0 +1,49 @@
+#
+# Copyright (C) 2007, Guennadi Liakhovetski 
+#
+# (C) Copyright 2011 Freescale Semiconductor, Inc.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS  := mx25pdk.o
+SOBJS  := lowlevel_init.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+   $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+clean:
+   rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+   rm -f $(LIB) core *.bak .depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/freescale/mx25pdk/imximage.cfg 
b/board/freescale/mx25pdk/imximage.cfg
new file mode 100644
index 000..f7af7ff
--- /dev/null
+++ b/board/freescale/mx25pdk/imximage.cfg
@@ -0,0 +1,73 @@
+#
+# (C) Copyright 2009
+# Stefano Babic DENX Software Engineering sba...@denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# Refer docs/README.imxmage for more details about how-to configure
+# and create imximage boot image
+#
+# The syntax is taken as close as possible with the kwbimage
+
+# Boot Device : one of
+# spi, sd (the board has no nand neither onenand)
+
+BOOT_FROM  sd
+
+# Device Configuration Data (DCD)
+#
+# Each entry must have the format:
+# Addr-type   AddressValue
+#
+# where:
+#  Addr-type register length (1,2 or 4 bytes)
+#  Address   absolute address of the register
+#  value value to be stored in the register
+
+# EIM config-CS5 init -- CPLD
+DATA 4 0xB8002050 0xD843
+DATA 4 0xB8002054 0x22252521
+DATA 4 0xB8002058 0x0A00
+
+# DDR2 init
+DATA 4 0xB8001004 0x0076E83A
+DATA 4 0xB8001010 0x0204
+DATA 4 0xB8001000 0x9221
+DATA 4 0x8f00 0x12344321
+DATA 4 0xB8001000 0xB221
+DATA 1 0x8200 0xda
+DATA 1 0x8300 0xda
+DATA 1 0x81000400 0xda
+DATA 1 0x8333 0xda
+
+DATA 4 0xB8001000 0x9221
+DATA 1 0x8400 0x12345678
+
+DATA 4 0xB8001000 0xA221
+DATA 4 0x8000 0x87654321
+DATA 4 0x8000 0x87654321
+
+DATA 4 0xB8001000 0xB221
+DATA 1 0x8233 0xda
+DATA 1 0x81000780 0xda
+DATA 1 0x81000400 0xda
+DATA 4 0xB8001000 0x82216080
+DATA 4 0x43FAC454 0x1000
+
+DATA

Re: [U-Boot] [PATCH] mmc:dcache: Cache line size aligned internal MMC buffers

[Scott Wood]

On 08/29/2011 03:12 PM, Anton Staaf wrote:
> 1) Mikes's macro
> 
> #define DMA_ALIGN_SIZE(size) \
>(((size) + CONFIG_SYS_CACHELINE_SIZE - 1)
> 
> #define DMA_DECLARE_BUFFER(type, name, size) \
>void __##name[DMA_ALIGN_SIZE(size * sizeof(type))]; \
>type * name = __##name & ~(CONFIG_SYS_CACHELINE_SIZE - 1));
> 
> DMA_DECLARE_BUFFER(int, buffer, 100);

This doesn't compile, and it tries to round the buffer down below its
starting point.

After fixing the more obvious issues, I get "error: initializer element
is not constant".

There might be no way to express and-by-constant as a relocation.

You could set the pointer at runtime, though, and remove some of the
macrification:

#define DMA_ALIGN_SIZE(size) \
((size) + CONFIG_SYS_CACHELINE_SIZE - 1)
#define DMA_ALIGN_ADDR(addr) \
(DMA_ALIGN_SIZE(addr) & (CONFIG_SYS_CACHELINE_SIZE - 1))

int buffer_unaligned[DMA_ALIGN_SIZE(100)];
int *buffer;

some_init_func()
{
buffer = (int *)(DMA_ALIGN_ADDR((uintptr_t)buffer_unaligned));
}

> 3) Use GCC specific alignment attribute:
> 
> #define CACHLINE_ALIGNED __attribute__ ((aligned (CONFIG_SYS_CACHELINE_SIZE)))
> 
> int buffer[100] CACHELINE_ALIGNED;
> 
> Pros: The declaration of the buffer is even simpler and more obvious,
> no use of alloca at all.
> 
> Cons: This doesn't work in any version of GCC before October 2010.
> Meaning that it probably doesn't work in whatever compiler you're
> using.
> 
> 
> It's really too bad that this isn't a usable solution.  I suppose that
> we could switch to it at some point when we expect U-Boot to only be
> compiled by versions of GCC that support this.  By the way, the
> failure mode here is pretty bad.  If you compile the above code with
> an older GCC it will silently fail to align the variable.  :(

If the decision is made to depend on newer compilers, U-Boot could check
for it and #error out if the compiler is too old (possibly just in the
files that depend on this feature).

-Scott

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

Re: [U-Boot] [PATCH] mmc:dcache: Cache line size aligned internal MMC buffers

[Anton Staaf]

On Mon, Aug 29, 2011 at 1:47 PM, Scott Wood  wrote:
> On 08/29/2011 03:12 PM, Anton Staaf wrote:
>> 1) Mikes's macro
>>
>> #define DMA_ALIGN_SIZE(size) \
>>        (((size) + CONFIG_SYS_CACHELINE_SIZE - 1)
>>
>> #define DMA_DECLARE_BUFFER(type, name, size) \
>>        void __##name[DMA_ALIGN_SIZE(size * sizeof(type))]; \
>>        type * name = __##name & ~(CONFIG_SYS_CACHELINE_SIZE - 1));
>>
>> DMA_DECLARE_BUFFER(int, buffer, 100);
>
> This doesn't compile, and it tries to round the buffer down below its
> starting point.

You are correct.  I wrote that one as a modification of mikes initial
proposal.  I should have caught the incorrect rounding when I did.
The patch that Lukasz sent titled "dcache: Dcache line size aligned
stack buffer allocation" has a correct implementation.

> After fixing the more obvious issues, I get "error: initializer element
> is not constant".

I think this requires the use of -std=c99 or GCC extensions.  More
specifics can be found here:
http://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html

> There might be no way to express and-by-constant as a relocation.
>
> You could set the pointer at runtime, though, and remove some of the
> macrification:
>
> #define DMA_ALIGN_SIZE(size) \
>        ((size) + CONFIG_SYS_CACHELINE_SIZE - 1)
> #define DMA_ALIGN_ADDR(addr) \
>        (DMA_ALIGN_SIZE(addr) & (CONFIG_SYS_CACHELINE_SIZE - 1))
>
> int buffer_unaligned[DMA_ALIGN_SIZE(100)];
> int *buffer;
>
> some_init_func()
> {
>        buffer = (int *)(DMA_ALIGN_ADDR((uintptr_t)buffer_unaligned));
> }

:) This was one of my suggestions earlier on a different thread.  It
was rejected there, I believe because it makes things less clear.

>> 3) Use GCC specific alignment attribute:
>>
>> #define CACHLINE_ALIGNED __attribute__ ((aligned 
>> (CONFIG_SYS_CACHELINE_SIZE)))
>>
>> int buffer[100] CACHELINE_ALIGNED;
>>
>> Pros: The declaration of the buffer is even simpler and more obvious,
>> no use of alloca at all.
>>
>> Cons: This doesn't work in any version of GCC before October 2010.
>> Meaning that it probably doesn't work in whatever compiler you're
>> using.
>>
>>
>> It's really too bad that this isn't a usable solution.  I suppose that
>> we could switch to it at some point when we expect U-Boot to only be
>> compiled by versions of GCC that support this.  By the way, the
>> failure mode here is pretty bad.  If you compile the above code with
>> an older GCC it will silently fail to align the variable.  :(
>
> If the decision is made to depend on newer compilers, U-Boot could check
> for it and #error out if the compiler is too old (possibly just in the
> files that depend on this feature).

Yup, I think whatever macro we come up with we can simplify it
eventually using the GCC attribute solution and we can make the macro
conditional on compiler version.

Thanks,
Anton

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

Re: [U-Boot] [PATCH] mmc:dcache: Cache line size aligned internal MMC buffers

[Anton Staaf]

On Mon, Aug 29, 2011 at 1:35 PM, Wolfgang Denk  wrote:
> Dear Anton Staaf,
>
> In message 
>  you 
> wrote:
>>
>> I would like to know, mainly for my education, why you do not want
>> alloca, but are OK with dynamic array sizing (as in the first solution
>> above).  My understanding is that they pretty much equate to the same
>> thing.  What is it about alloca that is objectionable?
>
> First, I've got bitten by alloca() before, when GCC misbehaved.
> Admitted, that was in some _very_ old version, but such experience
> sticks.

Very fair, I have programming constructs I avoid for the same reason.
*cough* exceptions *cough*

> Second, the behaviour of alloca() depends on a number of non-obvious
> settings and compiler flags, and results are not always obvious.  rom
> the man page:
>
>   Notes on the GNU Version
>       Normally, gcc(1) translates calls to alloca() with inlined
>       code. This is not done when either the -ansi, -std=c89,
>       -std=c99, or the -fno-builtin option is given (and the header
>        is not included). But beware! By default the glibc
>       version of  includes  and that contains
>       the line:
>
>           #define alloca(size)   __builtin_alloca (size)
>
>       with messy consequences if one has a private version of this function.
>
> This is nothing I want to have in any production software. OK, you
> may argument that U-Boot has a strictly controlled environment, but
> anyway.

Yes, I don't expect that we will allow a custom implementation of
alloca into U-Boot, but it's a good point that the compiler treats it
in strange ways.  One alternative here would be to always call
__builtin_alloca...  This would probably have other issues though.

> Third, the man page says:
>
> NOTES
>
>       The alloca() function is machine- and compiler-dependent. For
>       certain applications, its use can improve efficiency compared
>       to the use of malloc(3) plus free(3). In certain cases, it can
>       also simplify memory deallocation in applications that use
>       longjmp(3) or siglongjmp(3).
>       Otherwise, its use is discouraged.
>
> In my opinion, U-Boot falls into the "otherwise" category...

Yup, and another man page in the "Bugs" section says:

The alloca() function is machine and compiler dependent. On many
systems its implementation is buggy. Its use is discouraged.

Which seems even worse.  So, OK, I think we've run this to the ground.
 And we can always find and replace all of the uses of Mikes macro
easily if we think of something better later.

Thank you,
Anton

>
>> I think I agree with this not being a great solution.  I do wonder if
>> it would be useful to consider a dedicated buffer management API that
>> could be used to allocate and free cache line aligned power of two
>> buffers.  Perhaps something like a buddy heap for simplicity.
>
> The longer I read this thread, the less frightening Mikes's macro
> becomes (compared tho the alternatives).
>
> 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
> "Though a program be but three lines long,
> someday it will have to be maintained."
> - The Tao of Programming
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mmc:dcache: Cache line size aligned internal MMC buffers

[Scott Wood]

On 08/29/2011 03:58 PM, Anton Staaf wrote:
> On Mon, Aug 29, 2011 at 1:47 PM, Scott Wood  wrote:
>> On 08/29/2011 03:12 PM, Anton Staaf wrote:
>>> 1) Mikes's macro
>>>
>>> #define DMA_ALIGN_SIZE(size) \
>>>(((size) + CONFIG_SYS_CACHELINE_SIZE - 1)
>>>
>>> #define DMA_DECLARE_BUFFER(type, name, size) \
>>>void __##name[DMA_ALIGN_SIZE(size * sizeof(type))]; \
>>>type * name = __##name & ~(CONFIG_SYS_CACHELINE_SIZE - 1));
>>>
>>> DMA_DECLARE_BUFFER(int, buffer, 100);
>>
>> This doesn't compile, and it tries to round the buffer down below its
>> starting point.
> 
> You are correct.  I wrote that one as a modification of mikes initial
> proposal.  I should have caught the incorrect rounding when I did.
> The patch that Lukasz sent titled "dcache: Dcache line size aligned
> stack buffer allocation" has a correct implementation.

With the version in that patch I get the slightly different "error:
initializer element is not computable at load time".  Seems like whether
you cast the address to (type *) or (void *) determines which error you
get.  This is with GCC 4.5.1 (powerpc) and 4.6.0 (x86).  Maybe it's
arch-dependent, based on available relocation types.

Also, shouldn't the array be of type "char" rather than "char *"?

How do you make the declaration static?

>> After fixing the more obvious issues, I get "error: initializer element
>> is not constant".
> 
> I think this requires the use of -std=c99 or GCC extensions.  More
> specifics can be found here:
> http://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html

-std=c99 doesn't help.

The problem isn't the array itself, it's the pointer initializer.

>> You could set the pointer at runtime, though, and remove some of the
>> macrification:
>>
>> #define DMA_ALIGN_SIZE(size) \
>>((size) + CONFIG_SYS_CACHELINE_SIZE - 1)
>> #define DMA_ALIGN_ADDR(addr) \
>>(DMA_ALIGN_SIZE(addr) & (CONFIG_SYS_CACHELINE_SIZE - 1))
>>
>> int buffer_unaligned[DMA_ALIGN_SIZE(100)];
>> int *buffer;
>>
>> some_init_func()
>> {
>>buffer = (int *)(DMA_ALIGN_ADDR((uintptr_t)buffer_unaligned));
>> }
> 
> :) This was one of my suggestions earlier on a different thread.  It
> was rejected there, I believe because it makes things less clear.

So, the complex macro is bad because it obscures things, and this
version is bad because it doesn't? :-)

-Scott

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

Re: [U-Boot] [PATCH] mmc:dcache: Cache line size aligned internal MMC buffers

[Anton Staaf]

On Mon, Aug 29, 2011 at 2:23 PM, Scott Wood  wrote:
> On 08/29/2011 03:58 PM, Anton Staaf wrote:
>> On Mon, Aug 29, 2011 at 1:47 PM, Scott Wood  wrote:
>>> On 08/29/2011 03:12 PM, Anton Staaf wrote:
 1) Mikes's macro

 #define DMA_ALIGN_SIZE(size) \
        (((size) + CONFIG_SYS_CACHELINE_SIZE - 1)

 #define DMA_DECLARE_BUFFER(type, name, size) \
        void __##name[DMA_ALIGN_SIZE(size * sizeof(type))]; \
        type * name = __##name & ~(CONFIG_SYS_CACHELINE_SIZE - 1));

 DMA_DECLARE_BUFFER(int, buffer, 100);
>>>
>>> This doesn't compile, and it tries to round the buffer down below its
>>> starting point.
>>
>> You are correct.  I wrote that one as a modification of mikes initial
>> proposal.  I should have caught the incorrect rounding when I did.
>> The patch that Lukasz sent titled "dcache: Dcache line size aligned
>> stack buffer allocation" has a correct implementation.
>
> With the version in that patch I get the slightly different "error:
> initializer element is not computable at load time".  Seems like whether
> you cast the address to (type *) or (void *) determines which error you
> get.  This is with GCC 4.5.1 (powerpc) and 4.6.0 (x86).  Maybe it's
> arch-dependent, based on available relocation types.
>
> Also, shouldn't the array be of type "char" rather than "char *"?

Yes, you are correct, it should be a char.  That may be the problem.

> How do you make the declaration static?

you can't with this version of the macro.  Are there cases where you
need the buffer to be static?

Thanks,
Anton

>>> After fixing the more obvious issues, I get "error: initializer element
>>> is not constant".
>>
>> I think this requires the use of -std=c99 or GCC extensions.  More
>> specifics can be found here:
>> http://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html
>
> -std=c99 doesn't help.
>
> The problem isn't the array itself, it's the pointer initializer.
>
>>> You could set the pointer at runtime, though, and remove some of the
>>> macrification:
>>>
>>> #define DMA_ALIGN_SIZE(size) \
>>>        ((size) + CONFIG_SYS_CACHELINE_SIZE - 1)
>>> #define DMA_ALIGN_ADDR(addr) \
>>>        (DMA_ALIGN_SIZE(addr) & (CONFIG_SYS_CACHELINE_SIZE - 1))
>>>
>>> int buffer_unaligned[DMA_ALIGN_SIZE(100)];
>>> int *buffer;
>>>
>>> some_init_func()
>>> {
>>>        buffer = (int *)(DMA_ALIGN_ADDR((uintptr_t)buffer_unaligned));
>>> }
>>
>> :) This was one of my suggestions earlier on a different thread.  It
>> was rejected there, I believe because it makes things less clear.
>
> So, the complex macro is bad because it obscures things, and this
> version is bad because it doesn't? :-)
>
> -Scott
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mmc:dcache: Cache line size aligned internal MMC buffers

[Scott Wood]

On 08/29/2011 04:54 PM, Anton Staaf wrote:
> On Mon, Aug 29, 2011 at 2:23 PM, Scott Wood  wrote:
>> With the version in that patch I get the slightly different "error:
>> initializer element is not computable at load time".  Seems like whether
>> you cast the address to (type *) or (void *) determines which error you
>> get.  This is with GCC 4.5.1 (powerpc) and 4.6.0 (x86).  Maybe it's
>> arch-dependent, based on available relocation types.
>>
>> Also, shouldn't the array be of type "char" rather than "char *"?
> 
> Yes, you are correct, it should be a char.  That may be the problem.

It didn't make a difference.

>> How do you make the declaration static?
> 
> you can't with this version of the macro.  Are there cases where you
> need the buffer to be static?

I think you'd want it to be static more often than not.

-Scott

___
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 Graeme,

On Fri, Aug 26, 2011 at 7:23 PM, Graeme Russ  wrote:
> Hi Simon,
>
> On 27/08/11 10:25, Simon Glass wrote:
>> Hi Mike,
>>
>> On Fri, Aug 26, 2011 at 1:55 PM, Mike Frysinger  wrote:
>>> On Thursday, August 25, 2011 23:32:38 Simon Glass wrote:
>
> [snip]
>
 - 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.
>>>
>>> why not just build on top of tun/tap ?  then we do get "real" network 
>>> traffic,
>>> and you dont have to write your own tftp server because you can simply use 
>>> the
>>> same exact one on your development machine that the board would connect to.
>>> -mike
>>
>> Because then you need to set up a real tftp server. It's fine to do
>> what you suggest, but if possible it would be nice to have
>> self-contained tests also, so long as it isn't too much work.
>>
>
> I don't consider having to set up a tftp server as a bad thing - Quite the
> opposite really. There is plenty of network code in U-Boot that will
> benefit from testing under the sandbox target because it is much easier to
> debug. And there will be minimal impact on U-Boot code (just a sandbox
> 'Ethernet' driver is all that will be needed)
>
> I am reminded of when the R&D department that developed to eNET board were
> doing the firmware development before the first prototypes were available -
> The created a HAL which used pcap from memory. I wasn't part of that team,
> so I really don't know the details...

Yes, sounds good, will put you down for the network testing part :-)

I will work on a basic patch set and try to get it to the list early next week.

Regards,
Simon

>
> Regards,
>
> Graeme
>
___
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]

http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mmc:dcache: Cache line size aligned internal MMC buffers

[Anton Staaf]

On Mon, Aug 29, 2011 at 3:03 PM, Scott Wood  wrote:
> On 08/29/2011 04:54 PM, Anton Staaf wrote:
>> On Mon, Aug 29, 2011 at 2:23 PM, Scott Wood  wrote:
>>> With the version in that patch I get the slightly different "error:
>>> initializer element is not computable at load time".  Seems like whether
>>> you cast the address to (type *) or (void *) determines which error you
>>> get.  This is with GCC 4.5.1 (powerpc) and 4.6.0 (x86).  Maybe it's
>>> arch-dependent, based on available relocation types.
>>>
>>> Also, shouldn't the array be of type "char" rather than "char *"?
>>
>> Yes, you are correct, it should be a char.  That may be the problem.
>
> It didn't make a difference.

Hmm, I haven't played with this code yet, so I can't say for sure.
But it would certainly throw a wrench in the works if Mike's solution
was also unavailable on some platforms.  By chance, you aren't also
adding static here are you?  I could certainly see that that wouldn't
work.

>>> How do you make the declaration static?
>>
>> you can't with this version of the macro.  Are there cases where you
>> need the buffer to be static?
>
> I think you'd want it to be static more often than not.

If the buffer is allocated at file scope, then yes, we would want it
to be static.  But not at function scope.  It would no longer be
allocated on the stack in that case, and that was frowned upon
earlier.

Thanks,
Anton

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

Re: [U-Boot] [RFC PATCH] Pre-console buffer for ARM

[Graeme Russ]

Hi Simon

On Tue, Aug 30, 2011 at 3:21 AM, Simon Glass  wrote:
> This patch is for Graeme to take a look at. I found that have_console is
> not a flag yet. Also a few tidy-ups to handle buffer overflow and to avoid
> printing a 'dumping buffer' message when nothing was outputted.
>
> Also I tried to simplify the maths for the location of the pre-console buffer.
> IMO this should be done in board.c though.

[snip]

Have you seen my latest pre-console buffer series?:

http://lists.denx.de/pipermail/u-boot/2011-August/099607.html

I think that is a better base to work from as I think we can also fold in
your 'Early panic support' series as well - I'll comment on that series
seperately

Regards,

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

Re: [U-Boot] [RFC PATCH] Pre-console buffer for ARM

[Graeme Russ]

Hi Mike,

On Tue, Aug 30, 2011 at 6:10 AM, Mike Frysinger  wrote:
> On Monday, August 29, 2011 15:42:23 Simon Glass wrote:
>> On Mon, Aug 29, 2011 at 12:20 PM, Mike Frysinger wrote:
>> > On Monday, August 29, 2011 13:21:57 Simon Glass wrote:
>> >> + if (gd->con_buf_idx < CONFIG_SYS_TMP_CON_BUF_SZ)
>> >> + buffer[gd->con_buf_idx++] = c;
>> >
>> > seems like a circular buffer would make more sense ... usually the part
>> > of the log you want is the last chunk and not the first
>>

Well you would need an 'overflow' flag and then based on that you would need
to do two printf()'s when dumping the buffer - One from the 'index to end'
which is the 'top' of the buffer and one from 'start to index' which is the
bottom.

>> Yes I agree, although if you have more than 1KB of data it might be a bug.

I personally don't see the need - I expect the amount of pre-console output
would be faily limited considering that the board should do everything it
can to initialise console as early as possible.

>
> give people a foot and they'll take 1MiB :p
>
> it's fairly easy as well:
> #define CIRC_BUF_IDX(idx) ((idx) & (CONFIG_SYS_TMP_CON_BUF_SZ-1))
> buffer[CIRC_BUF_IDX(gd->conf_buf_idx++)] = c;

But does that work for non power-of-two buffer sizes...

Buffer size = 100 = 1100100
(size - 1)= 1100011
idx = 100 = 1100100
idx & (size - 1)  = 110

Nope :(

Regards,

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

Re: [U-Boot] [RFC PATCH] Pre-console buffer for ARM

[Simon Glass]

Hi Graeme,

On Mon, Aug 29, 2011 at 3:49 PM, Graeme Russ  wrote:
> Hi Simon
>
> On Tue, Aug 30, 2011 at 3:21 AM, Simon Glass  wrote:
>> This patch is for Graeme to take a look at. I found that have_console is
>> not a flag yet. Also a few tidy-ups to handle buffer overflow and to avoid
>> printing a 'dumping buffer' message when nothing was outputted.
>>
>> Also I tried to simplify the maths for the location of the pre-console 
>> buffer.
>> IMO this should be done in board.c though.
>
> [snip]
>
> Have you seen my latest pre-console buffer series?:
>
> http://lists.denx.de/pipermail/u-boot/2011-August/099607.html

No - I foolishly didn't look at the mailing list in those 4 hours :-)

Will take a look, thanks.

Regards,
Simon

>
> I think that is a better base to work from as I think we can also fold in
> your 'Early panic support' series as well - I'll comment on that series
> seperately
>
> 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

[Graeme Russ]

Hi Simon,

On Tue, Aug 30, 2011 at 8:04 AM, Simon Glass  wrote:
> Hi Graeme,
>
> On Fri, Aug 26, 2011 at 7:23 PM, Graeme Russ  wrote:
>> Hi Simon,
>>
>> On 27/08/11 10:25, Simon Glass wrote:
>>> Hi Mike,
>>>
>>> On Fri, Aug 26, 2011 at 1:55 PM, Mike Frysinger  wrote:
 On Thursday, August 25, 2011 23:32:38 Simon Glass wrote:

[snip]

>>
>> I don't consider having to set up a tftp server as a bad thing - Quite the
>> opposite really. There is plenty of network code in U-Boot that will
>> benefit from testing under the sandbox target because it is much easier to
>> debug. And there will be minimal impact on U-Boot code (just a sandbox
>> 'Ethernet' driver is all that will be needed)
>>
>> I am reminded of when the R&D department that developed to eNET board were
>> doing the firmware development before the first prototypes were available -
>> The created a HAL which used pcap from memory. I wasn't part of that team,
>> so I really don't know the details...
>
> Yes, sounds good, will put you down for the network testing part :-)

Arghh - Rope, meet neck. Neck, meet rope ;)

>
> I will work on a basic patch set and try to get it to the list early next 
> week.
>

Sounds good

Regards,

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

Re: [U-Boot] [PATCH] mmc:dcache: Cache line size aligned internal MMC buffers

[Scott Wood]

On 08/29/2011 05:49 PM, Anton Staaf wrote:
 How do you make the declaration static?
>>>
>>> you can't with this version of the macro.  Are there cases where you
>>> need the buffer to be static?
>>
>> I think you'd want it to be static more often than not.
> 
> If the buffer is allocated at file scope, then yes, we would want it
> to be static.  But not at function scope.  It would no longer be
> allocated on the stack in that case, and that was frowned upon
> earlier.

Ah, that's the issue.  I was trying to declare it at file scope. :-P

-Scott

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

Re: [U-Boot] [PATCH] mmc:dcache: Cache line size aligned internal MMC buffers

[Anton Staaf]

On Mon, Aug 29, 2011 at 4:01 PM, Scott Wood  wrote:
> On 08/29/2011 05:49 PM, Anton Staaf wrote:
> How do you make the declaration static?

 you can't with this version of the macro.  Are there cases where you
 need the buffer to be static?
>>>
>>> I think you'd want it to be static more often than not.
>>
>> If the buffer is allocated at file scope, then yes, we would want it
>> to be static.  But not at function scope.  It would no longer be
>> allocated on the stack in that case, and that was frowned upon
>> earlier.
>
> Ah, that's the issue.  I was trying to declare it at file scope. :-P

Thank goodness, I was trying to figure out how that couldn't be a
valid GCC complaint.  :)

Thanks,
 Anton

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

Re: [U-Boot] [PATCH 1/2] Add board_panic_no_console to deal with early critical errors

[Graeme Russ]

Hi Simon

On Tue, Aug 30, 2011 at 2:05 AM, Simon Glass  wrote:
> Tested-by: Simon Glass 
> Signed-off-by: Simon Glass 
> ---
>  include/common.h |8 
>  lib/vsprintf.c   |   26 --
>  2 files changed, 32 insertions(+), 2 deletions(-)
>
> diff --git a/include/common.h b/include/common.h
> index 12a1074..856df9a 100644
> --- a/include/common.h
> +++ b/include/common.h
> @@ -250,6 +250,14 @@ intlast_stage_init(void);
>  extern ulong monitor_flash_len;
>  int mac_read_from_eeprom(void);
>

[snip]

> +/* Provide a default function for when no console is available */
> +static void __board_panic_no_console(const char *msg)
> +{
> +   /* Just return since we can't access the console */
> +}
> +
> +void board_panic_no_console(const char *msg) __attribute__((weak,
> +   alias("__board_panic_no_console")));
> +
>  void panic(const char *fmt, ...)
>  {
> +   char str[CONFIG_SYS_PBSIZE];
>va_list args;
> +
>va_start(args, fmt);
> -   vprintf(fmt, args);
> -   putc('\n');
> +
> +   /* TODO)sjg): Move to vsnprintf() when available */
> +   vsprintf(str, fmt, args);
>va_end(args);
> +
> +   if (gd->have_console) {
> +   puts(str);
> +   putc('\n');
> +   } else {
> +   board_panic_no_console(str);
> +   }
> +

This patch highlights why console squelching should be done in console.c.
We are ending up with more and more if (gd->have_console) all over the
place. With the console squelching patch I posted earlier, I think it might
be easier to create a weak 'panic_printf()' which aliases to printf() which
the board can override if it has the ability to generate emergency output
before console is initialised. Console output will be squelched if the
board does not define such an override.

Regards,

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

Re: [U-Boot] [PATCH 2/2] Add check that console is ready before output

[Graeme Russ]

Hi Simon,

On Tue, Aug 30, 2011 at 2:05 AM, Simon Glass  wrote:
> If puts() or printf() is called before the console is ready, U-Boot will
> either hang or die. This adds a check for this so that debug() can be used
> in early code without concern that it will hang.
>
> U-Boot boots properly
>
> Tested-by: Simon Glass 
> Signed-off-by: Simon Glass 
> ---
>  common/console.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/common/console.c b/common/console.c
> index 8c650e0..28ddb95 100644
> --- a/common/console.c
> +++ b/common/console.c
> @@ -338,7 +338,7 @@ void putc(const char c)
>        if (gd->flags & GD_FLG_DEVINIT) {
>                /* Send to the standard output */
>                fputc(stdout, c);
> -       } else {
> +       } else if (gd->have_console) {
>                /* Send directly to the handler */
>                serial_putc(c);
>        }
> @@ -359,7 +359,7 @@ void puts(const char *s)
>        if (gd->flags & GD_FLG_DEVINIT) {
>                /* Send to the standard output */
>                fputs(stdout, s);
> -       } else {
> +       } else if (gd->have_console) {
>                /* Send directly to the handler */
>                serial_puts(s);
>        }

Please have a look at my console squelching patches

Regards,

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

Re: [U-Boot] [RFC PATCH] Pre-console buffer for ARM

[Mike Frysinger]

On Monday, August 29, 2011 19:00:46 Graeme Russ wrote:
> On Tue, Aug 30, 2011 at 6:10 AM, Mike Frysinger wrote:
> > On Monday, August 29, 2011 15:42:23 Simon Glass wrote:
> >> On Mon, Aug 29, 2011 at 12:20 PM, Mike Frysinger wrote:
> >> > On Monday, August 29, 2011 13:21:57 Simon Glass wrote:
> >> >> + if (gd->con_buf_idx < CONFIG_SYS_TMP_CON_BUF_SZ)
> >> >> + buffer[gd->con_buf_idx++] = c;
> >> > 
> >> > seems like a circular buffer would make more sense ... usually the
> >> > part of the log you want is the last chunk and not the first
> 
> Well you would need an 'overflow' flag and then based on that you would
> need to do two printf()'s when dumping the buffer - One from the 'index to
> end' which is the 'top' of the buffer and one from 'start to index' which
> is the bottom.

you wouldnt need an overflow flag unless you wrote out more than 2^32 bytes.  
look at the logic again ... it isnt masking the write, it's masking the read.  
so by virtual of the con_buf_idx being larger than the max, you know you've 
wrapped around.

otherwise yes, you'd need to split up the writes.  not that big of a deal i 
dont think ...

> >> Yes I agree, although if you have more than 1KB of data it might be a
> >> bug.
> 
> I personally don't see the need - I expect the amount of pre-console output
> would be faily limited considering that the board should do everything it
> can to initialise console as early as possible.

until people hit an early fail and add a lot of debug printf's and then the 
output gets silently clipped.  it's confusing imo, and i say this having 
implemented early debug output in other systems (including linux) and seeing 
how people used/reacted to it.

> > give people a foot and they'll take 1MiB :p
> > 
> > it's fairly easy as well:
> > #define CIRC_BUF_IDX(idx) ((idx) & (CONFIG_SYS_TMP_CON_BUF_SZ-1))
> > buffer[CIRC_BUF_IDX(gd->conf_buf_idx++)] = c;
> 
> But does that work for non power-of-two buffer sizes...

no, but not that big of a deal.  so you get limited to the last 1KiB, 4KiB, 
8KiB, 16KiB, etc... amount of data.
-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 PATCH] Pre-console buffer for ARM

[Graeme Russ]

Hi Mike,

On Tue, Aug 30, 2011 at 11:32 AM, Mike Frysinger  wrote:
> On Monday, August 29, 2011 19:00:46 Graeme Russ wrote:
>> On Tue, Aug 30, 2011 at 6:10 AM, Mike Frysinger wrote:
>> > On Monday, August 29, 2011 15:42:23 Simon Glass wrote:
>> >> On Mon, Aug 29, 2011 at 12:20 PM, Mike Frysinger wrote:
>> >> > On Monday, August 29, 2011 13:21:57 Simon Glass wrote:
>> >> >> + if (gd->con_buf_idx < CONFIG_SYS_TMP_CON_BUF_SZ)
>> >> >> + buffer[gd->con_buf_idx++] = c;
>> >> >
>> >> > seems like a circular buffer would make more sense ... usually the
>> >> > part of the log you want is the last chunk and not the first
>>
>> Well you would need an 'overflow' flag and then based on that you would
>> need to do two printf()'s when dumping the buffer - One from the 'index to
>> end' which is the 'top' of the buffer and one from 'start to index' which
>> is the bottom.
>
> you wouldnt need an overflow flag unless you wrote out more than 2^32 bytes.
> look at the logic again ... it isnt masking the write, it's masking the read.
> so by virtual of the con_buf_idx being larger than the max, you know you've
> wrapped around.
>
> otherwise yes, you'd need to split up the writes.  not that big of a deal i
> dont think ...

OK, so you let gd->con_buf_idx increment always and modulo to get the array
index - fine if CONFIG_SYS_TMP_CON_BUF_SZ is ^2 - see below

>> >> Yes I agree, although if you have more than 1KB of data it might be a
>> >> bug.
>>
>> I personally don't see the need - I expect the amount of pre-console output
>> would be faily limited considering that the board should do everything it
>> can to initialise console as early as possible.
>
> until people hit an early fail and add a lot of debug printf's and then the
> output gets silently clipped.  it's confusing imo, and i say this having
> implemented early debug output in other systems (including linux) and seeing
> how people used/reacted to it.

We can easily have a 'output clipped' so people know what happened and can
trim their debugging messages accordingly

>> > give people a foot and they'll take 1MiB :p
>> >
>> > it's fairly easy as well:
>> > #define CIRC_BUF_IDX(idx) ((idx) & (CONFIG_SYS_TMP_CON_BUF_SZ-1))
>> > buffer[CIRC_BUF_IDX(gd->conf_buf_idx++)] = c;
>>
>> But does that work for non power-of-two buffer sizes...
>
> no, but not that big of a deal.  so you get limited to the last 1KiB, 4KiB,
> 8KiB, 16KiB, etc... amount of data.

Until someone doesn't read the documentation and figures they can only
squeeze 200 bytes out of their L1 cache after making room for gd and stack
and then tries to print 201 bytes of debug info and trashes either the
stack or gd and then things start to get a lot weirder than simply having
their early debug messgaes clipped...

To be safe, CONFIG_SYS_TMP_CON_BUF_SZ would need to be checked for ^2 size
and now we only get 128 bytes rather than 200 :( - Better to add another
long in gd and get 196

Regards,

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

Re: [U-Boot] [RFC PATCH] Pre-console buffer for ARM

[Mike Frysinger]

On Monday, August 29, 2011 21:49:33 Graeme Russ wrote:
> On Tue, Aug 30, 2011 at 11:32 AM, Mike Frysinger wrote:
> > On Monday, August 29, 2011 19:00:46 Graeme Russ wrote:
> >> On Tue, Aug 30, 2011 at 6:10 AM, Mike Frysinger wrote:
> >> > On Monday, August 29, 2011 15:42:23 Simon Glass wrote:
> >> >> Yes I agree, although if you have more than 1KB of data it might be a
> >> >> bug.
> >> 
> >> I personally don't see the need - I expect the amount of pre-console
> >> output would be faily limited considering that the board should do
> >> everything it can to initialise console as early as possible.
> > 
> > until people hit an early fail and add a lot of debug printf's and then
> > the output gets silently clipped.  it's confusing imo, and i say this
> > having implemented early debug output in other systems (including linux)
> > and seeing how people used/reacted to it.
> 
> We can easily have a 'output clipped' so people know what happened and can
> trim their debugging messages accordingly

much easier said than done.  clipping the head rather than the tail is much 
more often the right default.

> >> > give people a foot and they'll take 1MiB :p
> >> > 
> >> > it's fairly easy as well:
> >> > #define CIRC_BUF_IDX(idx) ((idx) & (CONFIG_SYS_TMP_CON_BUF_SZ-1))
> >> > buffer[CIRC_BUF_IDX(gd->conf_buf_idx++)] = c;
> >> 
> >> But does that work for non power-of-two buffer sizes...
> > 
> > no, but not that big of a deal.  so you get limited to the last 1KiB,
> > 4KiB, 8KiB, 16KiB, etc... amount of data.
> 
> Until someone doesn't read the documentation and figures they can only
> squeeze 200 bytes out of their L1 cache after making room for gd and stack
> and then tries to print 201 bytes of debug info and trashes either the
> stack or gd and then things start to get a lot weirder than simply having
> their early debug messgaes clipped...

this is really a non-issue as it's trivial to catch at CPP time:
#if (CONFIG_SYS_TMP_CON_BUF_SZ & (CONFIG_SYS_TMP_CON_BUF_SZ - 1))
# error "CONFIG_SYS_TMP_CON_BUF_SZ must be a power-of-two"
#endif

> To be safe, CONFIG_SYS_TMP_CON_BUF_SZ would need to be checked for ^2 size
> and now we only get 128 bytes rather than 200 :( - Better to add another
> long in gd and get 196

my systems dont have nearly the size restrictions yours do, so if you think 
that's better, that's fine by me.  i dont care so much about the internal 
implementation details of the circular buffer ... i only care that it is a 
circular buffer and not one that stops too soon.
-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 2/2 v4] powerpc/p1023rds: Disable nor flash node and enable nand flash node

[Chunhe Lan]

On Tue, 30 Aug 2011 04:23:11 +0800, Tabi Timur-B04825  
 wrote:

> On Mon, Aug 29, 2011 at 2:15 AM, Chunhe Lan   
> wrote:
>> In the p1023rds, accessing exclusively nor flash or nand flash device by
>> BR0/OR0.
>
> This is not an English sentence.  I do not understand what you're saying.

OK. I will rewrite it.

Thanks.

-Jack Lan

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

Re: [U-Boot] [RFC PATCH] Pre-console buffer for ARM

[Graeme Russ]

Hi Mike,

On Tue, Aug 30, 2011 at 12:50 PM, Mike Frysinger  wrote:
> On Monday, August 29, 2011 21:49:33 Graeme Russ wrote:
>> On Tue, Aug 30, 2011 at 11:32 AM, Mike Frysinger wrote:
>> > On Monday, August 29, 2011 19:00:46 Graeme Russ wrote:
>> >> On Tue, Aug 30, 2011 at 6:10 AM, Mike Frysinger wrote:
>> >> > On Monday, August 29, 2011 15:42:23 Simon Glass wrote:
>> >> >> Yes I agree, although if you have more than 1KB of data it might be a
>> >> >> bug.
>> >>
>> >> I personally don't see the need - I expect the amount of pre-console
>> >> output would be faily limited considering that the board should do
>> >> everything it can to initialise console as early as possible.
>> >
>> > until people hit an early fail and add a lot of debug printf's and then
>> > the output gets silently clipped.  it's confusing imo, and i say this
>> > having implemented early debug output in other systems (including linux)
>> > and seeing how people used/reacted to it.
>>
>> We can easily have a 'output clipped' so people know what happened and can
>> trim their debugging messages accordingly
>
> much easier said than done.  clipping the head rather than the tail is much
> more often the right default.

One could argue that not clipping at all is the _right_ default ;)

But I can easily add to print_pre_console_buffer()...

if (gd->conf_buf_idx >= CONFIG_SYS_TMP_CON_BUF_SZ)
puts("Pre-console buffer clipped")

>> >> > give people a foot and they'll take 1MiB :p
>> >> >
>> >> > it's fairly easy as well:
>> >> > #define CIRC_BUF_IDX(idx) ((idx) & (CONFIG_SYS_TMP_CON_BUF_SZ-1))
>> >> > buffer[CIRC_BUF_IDX(gd->conf_buf_idx++)] = c;
>> >>
>> >> But does that work for non power-of-two buffer sizes...
>> >
>> > no, but not that big of a deal.  so you get limited to the last 1KiB,
>> > 4KiB, 8KiB, 16KiB, etc... amount of data.
>>
>> Until someone doesn't read the documentation and figures they can only
>> squeeze 200 bytes out of their L1 cache after making room for gd and stack
>> and then tries to print 201 bytes of debug info and trashes either the
>> stack or gd and then things start to get a lot weirder than simply having
>> their early debug messgaes clipped...
>
> this is really a non-issue as it's trivial to catch at CPP time:
> #if (CONFIG_SYS_TMP_CON_BUF_SZ & (CONFIG_SYS_TMP_CON_BUF_SZ - 1))
> # error "CONFIG_SYS_TMP_CON_BUF_SZ must be a power-of-two"
> #endif

Nice - hadn't thought of that

>> To be safe, CONFIG_SYS_TMP_CON_BUF_SZ would need to be checked for ^2 size
>> and now we only get 128 bytes rather than 200 :( - Better to add another
>> long in gd and get 196
>
> my systems dont have nearly the size restrictions yours do, so if you think
> that's better, that's fine by me.  i dont care so much about the internal
> implementation details of the circular buffer ... i only care that it is a
> circular buffer and not one that stops too soon.

Well actually, I have a 12-year old CPU with 16kB of cache - More than
enough for initial stack, gd and pre-console buffer. It was actually
Wolgang who raised the size issue, but that was probably more aimed at
those that do not have the space for the buffer at all

I'll do another rev of the two-patch series implementing the 'power of
two' trap and circular buffer.

P.S. Can we move this discussion over to that thread now:

[PATCH 0/2] console: Squelch and pre-console buffer
http://lists.denx.de/pipermail/u-boot/2011-August/099607.html

Regards,

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

Re: [U-Boot] [PATCH 2/2] MX25: Add initial support for MX25PDK

[Jason Liu]

2011/8/30 Fabio Estevam :
> Add the initial support for MX25PDK booting from SD card via internal boot.
>
> Signed-off-by: Fabio Estevam 
> ---
[...]
> --- /dev/null
> +++ b/include/configs/mx25pdk.h
> @@ -0,0 +1,109 @@
> +/*
> + * (C) Copyright 2011 Freescale Semiconductor, Inc.
> + *
> + * 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.
> + */
> +
> +#ifndef __CONFIG_H
> +#define __CONFIG_H
> +
> +/* High Level Configuration Options */
> +
> +#define CONFIG_ARM926EJS                       /* arm926ejs CPU core */
> +#define CONFIG_MX25
> +#define CONFIG_MX25PDK
> +#define CONFIG_MX25_CLK32              32768   /* OSC32K frequency */
> +#define CONFIG_SYS_HZ                  1000
> +#define CONFIG_SYS_TEXT_BASE           0x8120
> +
> +#define CONFIG_DISPLAY_CPUINFO
> +#define CONFIG_DISPLAY_BOARDINFO
> +
> +#define CONFIG_CMDLINE_TAG             /* enable passing of ATAGs */
> +#define CONFIG_SETUP_MEMORY_TAGS
> +#define CONFIG_INITRD_TAG
> +
> +/* Size of malloc() pool */
> +#define CONFIG_SYS_MALLOC_LEN          (CONFIG_ENV_SIZE + 2 * 1024 * 1024)
> +
> +/* Physical Memory Map */
> +
> +#define CONFIG_NR_DRAM_BANKS   1
> +#define PHYS_SDRAM_1           0x8000
> +#define PHYS_SDRAM_1_SIZE      (64 * 1024 * 1024)
> +
> +#define CONFIG_BOARD_EARLY_INIT_F
> +
> +#define CONFIG_SYS_SDRAM_BASE          PHYS_SDRAM_1
> +#define CONFIG_SYS_INIT_SP_ADDR                (CONFIG_SYS_SDRAM_BASE + 
> 0x1000 - \
> +                                               GENERATED_GBL_DATA_SIZE)
> +
> +/* Memory Test */
> +#define CONFIG_SYS_MEMTEST_START       PHYS_SDRAM_1
> +#define CONFIG_SYS_MEMTEST_END         (PHYS_SDRAM_1 + PHYS_SDRAM_1_SIZE)

Can we test the full DDR memory size?


Jason

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

Re: [U-Boot] [PATCH 2/2] MX25: Add initial support for MX25PDK

[Fabio Estevam]

On Tue, Aug 30, 2011 at 12:16 AM, Jason Liu  wrote:
...
>> +/* Memory Test */
>> +#define CONFIG_SYS_MEMTEST_START       PHYS_SDRAM_1
>> +#define CONFIG_SYS_MEMTEST_END         (PHYS_SDRAM_1 + PHYS_SDRAM_1_SIZE)
>
> Can we test the full DDR memory size?

There is a total amount of 64MB of DDR on MX25PDK, so this means that
the full DDR size will be tested.

Regards,

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

[U-Boot] [PATCH 1/2 v5] fdt: Add a do_fixup_by_path_string() function

[Chunhe Lan]

The do_fixup_by_path_string() will set the specified node's property to the
value contained in "status". It would just be an inline wrapper for
do_fixup_by_path() that calls strlen on the argument.

Signed-off-by: Chunhe Lan 
---
 include/fdt_support.h |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/include/fdt_support.h b/include/fdt_support.h
index 863024f..1de4a1d 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -36,6 +36,13 @@ void do_fixup_by_path(void *fdt, const char *path, const 
char *prop,
  const void *val, int len, int create);
 void do_fixup_by_path_u32(void *fdt, const char *path, const char *prop,
  u32 val, int create);
+
+static inline void do_fixup_by_path_string(void *fdt, const char *path,
+  const char *prop, const char *status)
+{
+   do_fixup_by_path(fdt, path, prop, status, strlen(status) + 1, 1);
+}
+
 void do_fixup_by_prop(void *fdt,
  const char *pname, const void *pval, int plen,
  const char *prop, const void *val, int len,
-- 
1.5.6.5


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

[U-Boot] [PATCH 2/2 v5] powerpc/p1023rds: Disable nor flash node and enable nand flash node

[Chunhe Lan]

In the p1023rds, when system boots from nor flash, kernel only accesses nor
flash and can not access nand flash with BR0/OR0; when system boots from
nand flash, kernel only accesses nand flash and can not access nor flash
with BR0/OR0.

Default device tree nor and nand node should have the following structure:

Example:

nor_flash: nor@0,0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "cfi-flash";
reg = <0x0 0x0 0x0200>;
bank-width = <2>;
device-width = <1>;
status = "okay";

partition@0 {
label = "ramdisk";
reg = <0x 0x01c0>;
};
}

nand_flash: nand@1,0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,p1023-fcm-nand",
 "fsl,elbc-fcm-nand";
reg = <0x2 0x0 0x0004>;
status = "disabled";

u-boot-nand@0 {
/* This location must not be altered  */
/* 1MB for u-boot Bootloader Image */
reg = <0x0 0x0010>;
read-only;
};
}

When booting from nor flash, the status of nor node is null that means it
is enabled and the status of nand node is disabled in the default dts file,
so do not do anything.

But, when booting from nand flash, need to do some operations:

o the status of nor node should be disabled.
o the status of nand node should be enabled.

Signed-off-by: Chunhe Lan 
---
 board/freescale/p1023rds/p1023rds.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/board/freescale/p1023rds/p1023rds.c 
b/board/freescale/p1023rds/p1023rds.c
index 8cfd199..c99ccee 100644
--- a/board/freescale/p1023rds/p1023rds.c
+++ b/board/freescale/p1023rds/p1023rds.c
@@ -158,5 +158,10 @@ void ft_board_setup(void *blob, bd_t *bd)
size = getenv_bootm_size();
 
fdt_fixup_memory(blob, (u64)base, (u64)size);
+
+#ifdef CONFIG_NAND_U_BOOT
+   do_fixup_by_path_string(fdt, "nor_flash", "status", "disabled");
+   do_fixup_by_path_string(fdt, "nand_flash", "status", "okay");
+#endif
 }
 #endif
-- 
1.5.6.5


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

Re: [U-Boot] [PATCH v6 1/2] i2c:gpio:s5p: I2C GPIO Software implementation (via soft_i2c)

[Minkyu Kang]

Dear Lukasz Majewski,

On 23 August 2011 17:34, Lukasz Majewski  wrote:
> This patch adds support for software I2C for GONI and Universal C210 
> reference targets.
> It adds support for access to GPIOs by number, not as it is present,
> by bank and offset.
>
> Signed-off-by: Lukasz Majewski 
> Signed-off-by: Kyungmin Park 
> Cc: Minkyu Kang 
> Cc: Heiko Schocher 
>
> ---
> Changes for v2:
>        - Generic GPIO code added to arch/arm/gpio.h
>        - Platform dependent GPIO code added to board/samsung/goni.c
>        - Code cleanup
> Changes for v3:
>        - I2C GPIO common code added to drivers/gpio/s5p_gpio.c
>        - i2c_init_board() function added(required by soft_i2c)
> Changes for v4:
>        - i2x_init_board() removed
>        - s5pc210 support added
>        - GPIO code and I2C enable code split to separate patches
> Changes for v5:
>        - s5p_gpio pointer removed and replaced with generic s5p_gpio_base
>        function
>        - removed duplicated code
> Changes for v6:
>        - s5pc[1|2]10_gpio_get_nr macro added. More redable code for I2C
>        gpio pins definition
> ---
>  arch/arm/include/asm/arch-s5pc1xx/gpio.h |   13 +
>  arch/arm/include/asm/arch-s5pc2xx/gpio.h |   29 +++
>  drivers/gpio/s5p_gpio.c                  |   44 
> ++
>  3 files changed, 86 insertions(+), 0 deletions(-)
>

applied to u-boot-samsung

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

Re: [U-Boot] [PATCH v2 2/2] i2c:gpio:s5p: Enable I2C GPIO on the GONI target

[Minkyu Kang]

Dear Lukasz Majewski,

On 23 August 2011 17:34, Lukasz Majewski  wrote:
> This patch enables the software I2C for GONI reference target.
>
> Signed-off-by: Lukasz Majewski 
> Signed-off-by: Kyungmin Park 
> Cc: Minkyu Kang 
> Cc: Heiko Schocher 
>
> ---
> Changes for v2:
>        - Replace explicit GPIO definition with more readable one
> ---
>  include/configs/s5p_goni.h |   12 
>  1 files changed, 12 insertions(+), 0 deletions(-)
>

applied to u-boot-samsung

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

Re: [U-Boot] [PATCH v5 1/2] ARMV7: Add support for Samsung ORIGEN board

[Minkyu Kang]

Dear Chander Kashyap,

On 19 August 2011 17:37, Chander Kashyap  wrote:
> Origen board is based upon S5PV310 SoC which is similiar to
> S5PC210 SoC.
>
> Signed-off-by: Chander Kashyap 
> ---
> Changes for v2:
>        - None
> Changes for v3:
>        - Board entry added Alphabetically in boards.cfg
>        - Used get_Ram_size function to calculate ram size
> Changes for v4:
>        - CONFIG_MACH_TYPE defined to initialise MACH_TYPE in generic way
>        - Used s5p_gpio_* functions for gpio operations
> Changes for v5:
>        - Used Symbolic names for hard-coded macros
>        - Used get_ram_size() while initialising gd->bd->bi_dram[].size
>
>  MAINTAINERS                          |    1 +
>  board/samsung/origen/Makefile        |   46 +++
>  board/samsung/origen/lowlevel_init.S |  357 ++
>  board/samsung/origen/mem_setup.S     |  421 ++
>  board/samsung/origen/origen.c        |  109 +++
>  board/samsung/origen/origen_setup.h  |  546 
> ++
>  boards.cfg                           |    1 +
>  include/configs/origen.h             |  160 ++
>  8 files changed, 1641 insertions(+), 0 deletions(-)
>  create mode 100644 board/samsung/origen/Makefile
>  create mode 100644 board/samsung/origen/lowlevel_init.S
>  create mode 100644 board/samsung/origen/mem_setup.S
>  create mode 100644 board/samsung/origen/origen.c
>  create mode 100644 board/samsung/origen/origen_setup.h
>  create mode 100644 include/configs/origen.h
>

applied to u-boot-samsung

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

Re: [U-Boot] [PATCH v5 2/2] ORIGEN: Add MMC SPL support

[Minkyu Kang]

Dear Chander Kashyap,

On 19 August 2011 17:37, Chander Kashyap  wrote:
> Adds mmc boot support.
>
> Signed-off-by: Chander Kashyap 
> ---
> Changes for v2:
>        - Added Dirk Behme's patch
>        - SMDKV310: Fix host compilation of mkv310_image
> Changes for v3:
>        - None
> Changes for v4:
>        - None
> Changes for v5:
>        - Use spl framwork for mmc spl support
>        - Removed typedef for function pointer
>                (API to copy u-boot from mmc to ram)
>
>  board/samsung/origen/Makefile             |   20 +-
>  board/samsung/origen/mmc_boot.c           |   58 +
>  board/samsung/origen/tools/mkv310_image.c |  126 
> +
>  include/configs/origen.h                  |    8 ++
>  spl/Makefile                              |   10 +++
>  5 files changed, 221 insertions(+), 1 deletions(-)
>  create mode 100644 board/samsung/origen/mmc_boot.c
>  create mode 100644 board/samsung/origen/tools/mkv310_image.c
>

applied to u-boot-samsung

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

Re: [U-Boot] [PATCH 9/9] OMAP3: Remove legacy mmc driver

[Premi, Sanjeev]

> -Original Message-
> From: u-boot-boun...@lists.denx.de 
> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Rini, Tom
> Sent: Tuesday, August 23, 2011 3:44 AM
> To: u-boot@lists.denx.de
> Subject: [U-Boot] [PATCH 9/9] OMAP3: Remove legacy mmc driver
> 
> Now that all platforms have been migrated to the new MMC 
> driver, remove
> the old one.
> 
> Signed-off-by: Tom Rini 
> ---
>  drivers/mmc/Makefile|1 -
>  drivers/mmc/omap3_mmc.c |  570 
> ---
>  drivers/mmc/omap3_mmc.h |  233 ---
>  3 files changed, 0 insertions(+), 804 deletions(-)
>  delete mode 100644 drivers/mmc/omap3_mmc.c
>  delete mode 100644 drivers/mmc/omap3_mmc.h
> 

Similar patch was posted earlier in the month:
http://marc.info/?l=u-boot&m=131220851719468&w=2

You may still want to keep the "legacy" mmc driver. Should help
the new boards during early development.

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

Re: [U-Boot] [RFC PATCH] Pre-console buffer for ARM

[Wolfgang Denk]

Dear Graeme Russ,

In message 
 you wrote:
> 
> >> > it's fairly easy as well:
> >> > #define CIRC_BUF_IDX(idx) ((idx) & (CONFIG_SYS_TMP_CON_BUF_SZ-1))
> >> > buffer[CIRC_BUF_IDX(gd->conf_buf_idx++)] = c;
> >>
> >> But does that work for non power-of-two buffer sizes...
> >
> > no, but not that big of a deal.  so you get limited to the last 1KiB, 4KiB,
> > 8KiB, 16KiB, etc... amount of data.
> 
> Until someone doesn't read the documentation and figures they can only
> squeeze 200 bytes out of their L1 cache after making room for gd and stack
> and then tries to print 201 bytes of debug info and trashes either the
> stack or gd and then things start to get a lot weirder than simply having
> their early debug messgaes clipped...
> 
> To be safe, CONFIG_SYS_TMP_CON_BUF_SZ would need to be checked for ^2 size
> and now we only get 128 bytes rather than 200 :( - Better to add another
> long in gd and get 196

Grrrgh.

If you want to support arbitrary buffer sizes, then just use

#define CIRC_BUF_IDX(idx) ((idx) % CONFIG_SYS_TMP_CON_BUF_SZ)

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
Use C++ to confuse your enemies; use C to produce stable code.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] MX25: Add initial support for MX25PDK

[Wolfgang Denk]

Dear Jason Liu,

In message  
you wrote:
>
> > +#define CONFIG_SYS_MEMTEST_STARTPHYS_SDRAM_1
> > +#define CONFIG_SYS_MEMTEST_END (PHYS_SDRAM_1 + PHYS_SDRA> M_1_SIZE)
>
> Can we test the full DDR memory size?

Not without crashing the system.

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
How many seconds are there in a year? If I tell you there are 3.155 x
10^7, you won't even try to remember it. On the other hand, who could
forget that, to within half a percent, pi seconds is a nanocentury.
- Tom Duff, Bell Labs
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] MX25: Add initial support for MX25PDK

[Wolfgang Denk]

Dear Fabio Estevam,

In message  
you wrote:
> On Tue, Aug 30, 2011 at 12:16 AM, Jason Liu  wrote:
> ...
> >> +/* Memory Test */
> >> +#define CONFIG_SYS_MEMTEST_START       PHYS_SDRAM_1
> >> +#define CONFIG_SYS_MEMTEST_END         (PHYS_SDRAM_1 + 
> >> PHYS_SDRAM_1_SIZE)
> >
> > Can we test the full DDR memory size?
> 
> There is a total amount of 64MB of DDR on MX25PDK, so this means that
> the full DDR size will be tested.

...thus overwriting U-Boot's code, data, stack, exception vectors and
everything.

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
That was the thing about deserts. They had their  own  gravity.  They
sucked you into the centre.   - 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 1/2 v5] fdt: Add a do_fixup_by_path_string() function

[Wolfgang Denk]

Dear Chunhe Lan,

In message <1314675674-9825-1-git-send-email-chunhe@freescale.com> you 
wrote:
> The do_fixup_by_path_string() will set the specified node's property to the
> value contained in "status". It would just be an inline wrapper for
> do_fixup_by_path() that calls strlen on the argument.
> 
> Signed-off-by: Chunhe Lan 
> ---
>  include/fdt_support.h |7 +++
>  1 files changed, 7 insertions(+), 0 deletions(-)

This is v5, but there is no log of changes.

This change log is MANDATORY!!

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
Men don't talk peace unless they're ready to back it up with war.
-- Col. Green, "The Savage Curtain", stardate 5906.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2 v5] powerpc/p1023rds: Disable nor flash node and enable nand flash node

[Wolfgang Denk]

Dear Chunhe Lan,

In message <1314675698-9847-1-git-send-email-chunhe@freescale.com> you 
wrote:
...
>   status = "okay";
...
> When booting from nor flash, the status of nor node is null that means it

Description does not match code.

> is enabled and the status of nand node is disabled in the default dts file,
...
> But, when booting from nand flash, need to do some operations:
> 
>   o the status of nor node should be disabled.
>   o the status of nand node should be enabled.

Make this:

o Disable the NOR node by setting status = "disabled";
o Enable the NAND node by setting status = "okay";

> Signed-off-by: Chunhe Lan 
> ---
>  board/freescale/p1023rds/p1023rds.c |5 +
>  1 files changed, 5 insertions(+), 0 deletions(-)

This is patch v5, but there is no change log.  This is MANDATORY!

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
Making files is easy under  the  UNIX  operating  system.  Therefore,
users  tend  to  create  numerous  files  using large amounts of file
space. It has been said that the only standard thing about  all  UNIX
systems  is  the  message-of-the-day  telling users to clean up their
files.-- System V.2 administrator's guide
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Ajay Bhargav]

- "Mike Frysinger"  wrote:

> On Monday, August 29, 2011 01:39:18 Ajay Bhargav wrote:
> > - "Mike Frysinger"  wrote:
> > > On Monday, August 29, 2011 01:10:49 Ajay Bhargav wrote:
> > > > - "Mike Frysinger"  wrote:
> > > > > On Friday, August 26, 2011 02:36:51 Ajay Bhargav wrote:
> > > > > > +darmdfec = malloc(sizeof(struct armdfec_device));
> > > > > > +if (!darmdfec)
> > > > > > +goto error;
> > > > > 
> > > > > if this first one fails, we jump to:
> > > > > > +error:
> > > > > > +free(darmdfec->p_aligned_txbuf);
> > > > > > +free(darmdfec->p_rxbuf);
> > > > > > +free(darmdfec->p_rxdesc);
> > > > > > +free(darmdfec->htpr);
> > > > > 
> > > > > looks like 4 NULL pointer derefs.  so you'll need one
> specific
> > > 
> > > path
> > > 
> > > > > for the first malloc(), but the rest are fine.
> > > > 
> > > > so you mean like this...
> > > > 
> > > > if(!darmdfec)
> > > > 
> > > > goto error;
> > > > 
> > > > ...
> > > > 
> > > > error1:
> > > > free(darmdfec->p_aligned_txbuf);
> > > > free(darmdfec->p_rxbuf);
> > > > free(darmdfec->p_rxdesc);
> > > > free(darmdfec->htpr);
> > > > 
> > > > error:
> > > > free(darmdfec);
> > > > return -1;
> > > 
> > > that's one way of fixing it
> > 
> > Any other better way?
> 
> since all your buffers are known fixed (at compile time) sizes, you
> could 
> simply inline them into the structure so you only malloc() one buffer
> -mike

Yes.. thats another way of coding :) I will stick to previous one..

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

Re: [U-Boot] [RFC PATCH] Pre-console buffer for ARM

[Graeme Russ]

Hi Wolfgang

On Tue, Aug 30, 2011 at 3:17 PM, Wolfgang Denk  wrote:
> Dear Graeme Russ,
>
> In message 
>  you 
> wrote:
>>
>> >> > it's fairly easy as well:
>> >> > #define CIRC_BUF_IDX(idx) ((idx) & (CONFIG_SYS_TMP_CON_BUF_SZ-1))
>> >> > buffer[CIRC_BUF_IDX(gd->conf_buf_idx++)] = c;
>> >>
>> >> But does that work for non power-of-two buffer sizes...
>> >
>> > no, but not that big of a deal.  so you get limited to the last 1KiB, 4KiB,
>> > 8KiB, 16KiB, etc... amount of data.
>>
>> Until someone doesn't read the documentation and figures they can only
>> squeeze 200 bytes out of their L1 cache after making room for gd and stack
>> and then tries to print 201 bytes of debug info and trashes either the
>> stack or gd and then things start to get a lot weirder than simply having
>> their early debug messgaes clipped...
>>
>> To be safe, CONFIG_SYS_TMP_CON_BUF_SZ would need to be checked for ^2 size
>> and now we only get 128 bytes rather than 200 :( - Better to add another
>> long in gd and get 196
>
> Grrrgh.
>
> If you want to support arbitrary buffer sizes, then just use
>
>#define CIRC_BUF_IDX(idx) ((idx) % CONFIG_SYS_TMP_CON_BUF_SZ)

I know, but I was concerned that you wouldn't like the use of modulo
arithmetic for every putc() - But I suppose thats cheaper than a compare
plus branch...

If you prefer modulo over the 'must be a power of two' restriction, then
I am happy to do it that way instead

Regards,

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

Re: [U-Boot] Support for Intel i7 2nd GEneration processors

[Flash K]

Hi Graeme,

I was checking out other alternatives to BIOS. I came across EFI , a new 
technology that seems to replace the BIOS in the near future. However I am 
still not clear as to where EFI fits in the booting process. They say that EFI 
cannot replace the BIOS but plans to do so in the near future. 


FAQs at http://www.uefi.org/about/

Intel also says that they are providing support for some motherboards. So is 
UEFI meant for use with the existing BIOS or with a custom developed BIOS from 
Uboot/Coreboot? Some information online also says that UEFI can be used as a 
payload for Coreboot. The entire thing is a little confusing. I am not able to 
understand where UEFI fits in with the BIOIS? 


Could you please help?

Regards,
Flash






From: Graeme Russ 
To: Flash K 
Cc: "u-boot@lists.denx.de" 
Sent: Thursday, August 18, 2011 11:57:00 AM
Subject: Re: [U-Boot] Support for Intel i7 2nd GEneration processors

Hi Flash

On Thu, Aug 18, 2011 at 4:10 PM, Flash K  wrote:
> Thanks Graeme,
> Okay, so that means that U boot is a combination of Primary and Secondary
> bootloaders, ie loading the MBR and then loading the Kernel image.

U-Boot (like coreboot) sits at the lowest level - It starts executing
from the 'Reset Vector' when the CPU is powered-up or reset

> So is U Boot along the lines of Syslinux, Lilo, GRUB etc. I mean does it
> work in conjunction with a  BIOS?  I thought that U Boot was a combination
> of BIOS + Bootloaders. But thanks for clearing the doubt.

BIOS is a (somewhat standard) set of low-level functions which are
accessed via software interrupts. Linux does not need BIOS (well,
technically it still does for ACPI and possibly some PCI stuff)
because it's drivers are written to control the hardware directly, so
to run the Linux kernel, U-Boot does not have to implement a complete
BIOS. U-Boot implements a very basic set which Linux needs early on to
detect memory - It is just enough to fool Linux into booting after
U-Boot has loaded the kernel image into memory (typically from a Flash
memory devices, but some boards also support SATA interfaces and
various file systems)

Regards,

Graeme

>
> Will check out Coreboot.
>
> Regards,
> Flash
>
> 
> From: Graeme Russ 
> To: Flash K 
> Cc: "u-boot@lists.denx.de" 
> Sent: Wednesday, August 17, 2011 10:54:30 PM
> Subject: Re: [U-Boot] Support for Intel i7 2nd GEneration processors
>
> Hi Flash,
>
> On Thu, Aug 18, 2011 at 3:38 PM, Flash K  wrote:
>> Hi,
>>
>> I would like to know if U boot supports the Intel 2nd generation core i7
>> processors.
>
> No it doesn't (at least not yet)
>
> Be aware that U-Boot is a boot-loader for embedded devices (phones,
> routers, set-top boxes, TV's etc) and not a general purpose BIOS for a
> PC. You might want to have a look at coreboot (www.coreboot.org) if
> you are looking for a FOSS implementation of a PC BIOS - They may have
> i7 support.
>
> Regards,
>
> Graeme
>
>
>___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 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
Changes for v4:
- Debug and Error messages updated
- base_addr param for armada100_fec_register changed to unsigned long

 arch/arm/include/asm/arch-armada100/armada100.h |1 +
 drivers/net/Makefile|1 +
 drivers/net/armada100_fec.c |  762 +++
 drivers/net/armada100_fec.h |  232 +++
 include/netdev.h|1 +
 5 files changed, 997 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..626b50c
--- /dev/null
+++ b/drivers/net/armada100_fec.c
@@ -0,0 +1,762 @@
+/*
+ * (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 = reg_data & 0x1f;
+   return 0;
+   }
+
+   /* check parameters */
+   if (phy_addr > PHY_MASK) {
+   printf("ARMD100 FEC: (%s) Invalid phy address: 0x%X\n",
+   

[U-Boot] [PATCH v4 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
Changes for v4:
- Not changed

 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

[U-Boot] [PATCH v4 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
Changes for v4:
- Not changed

 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_

Re: [U-Boot] Support for Intel i7 2nd GEneration processors

[Graeme Russ]

Hi Flash,

Note: I have no experience with (U)EFI
On Tue, Aug 30, 2011 at 3:35 PM, Flash K  wrote:
> Hi Graeme,
> I was checking out other alternatives to BIOS. I came across EFI , a new
> technology that seems to replace the BIOS in the near future. However I am
> still not clear as to where EFI fits in the booting process. They say that
> EFI cannot replace the BIOS but plans to do so in the near future.

(U)EFI cannot replace BIOS because most OS's still depend on BIOS to boot.
BIOS provides a standard way for an OS to do some fundamental operations
in real-mode (the mode the x86 CPU boots into) before the OS's switches to
protected mode (and hence can no longer use BIOS). After the switch to
protected mode, the OS's drivers interface directly to the hardware. Some
of these fundamental operations include determining memory size and loading
the core OS components from the hard drive

> FAQs at http://www.uefi.org/about/
> Intel also says that they are providing support for some motherboards. So is
> UEFI meant for use with the existing BIOS or with a custom developed BIOS
> from Uboot/Coreboot? Some information online also says that UEFI can be used
> as a payload for Coreboot. The entire thing is a little confusing. I am not
> able to understand where UEFI fits in with the BIOIS?

I suppose you could call (U)EFI a 'bootloader' of sorts. I theory, you could
write an (U)EFI for a motherboard and have it do everything BIOS currently
does (provided you knew all the ins-and-outs of the hardware components). I
gather that (U)EFI is far more extensible than coreboot or U-Boot - But it
is also a lot bigger (I have heard numbers up to 2MB - U-Boot is <256kB).
I gather that the size is due to a single (U)EFI image being able to cater
for multiple hardware configurations - Each U-Boot image is tailored to a
very specific hardware configuration (or very limited set thereof)

As a coreboot payload, I think coreboot does some low-level init of the
motherboard hardware (SDRAM for example) and then passes control onto
(U)EFI

So until Linux and Windows support (U)EFI and stop supporting BIOS, (U)EFI
is not going to replace BIOS

Regards,

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

Re: [U-Boot] [PATCH] arm: a320: fix broken timer

[馬克泡]

Hi Albert and Po-Yu,

2011/8/11 Po-Yu Chuang 
>
> From: Po-Yu Chuang 
>
> timer.c used static data and are called before relocation.
> Move all static variables into global_data structure. Also cleanup
> timer.c from unused stubs and make it truly use 64 bit tick values.

This patch has been tested by Macpaul on AG101 and AG101P boards.

Tested-by: Macpaul Lin 

--
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 v2 01/16] ARM: remove broken "armadillo" board

[Albert ARIBAUD]

Hi Marek,

> This one can be fixed with such a patch, though I dunno if it's worth it.
>
> diff --git a/include/configs/armadillo.h b/include/configs/armadillo.h
> [...]

I have seen the rest of the discussion already, and will apply the 
armadillo removal patch. I just want to make a quick note (again) to all:

Please avoid copy-pasting a patch or even part of a patch in your 
replies to an official patch, because patchwork then believes you have 
actually posted a new patch and created a new entry, "hijacking" the 
comments for the original one.

The 'armadillo' patch shows the issue:

 is the actual patch which 
should have had the comments, but these were 'hijacked' and stored under 
 which is actually not a 
patch but one of the replies.

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