Re: [U-Boot] [PATCH v8 3/3] MIPS: Jz4740: Add qi_lb60 board support
Dear Wolfgang and Tom, Am 03.07.2013 11:54, schrieb Wolfgang Denk: Dear Xiangfu Liu, In message <4e95a3ba.8000...@pobox.com> you wrote: Add support for the qi_lb60 (a.k.a QI Ben NanoNote) clamshell device from Qi hardware: http://en.qi-hardware.com/wiki/Ben_NanoNote http://en.qi-hardware.com/wiki/Main_Page http://en.wikipedia.org/wiki/Qi_hardware This Jz4740-based clamshell device does not use NOR flash to boot. The initial bring-up assumes that U-Boot is directly loaded into SDRAM using USB boot tool, and starts from 0x8010. ... MAINTAINERS |4 + MAKEALL |4 +- board/qi/qi_lb60/Makefile | 45 + board/qi/qi_lb60/config.mk | 31 +++ board/qi/qi_lb60/qi_lb60.c | 104 + board/qi/qi_lb60/u-boot.lds | 61 + boards.cfg |1 + include/configs/qi_lb60.h | 211 +++ 8 files changed, 460 insertions(+), 1 deletions(-) create mode 100644 board/qi/qi_lb60/Makefile create mode 100644 board/qi/qi_lb60/config.mk create mode 100644 board/qi/qi_lb60/qi_lb60.c create mode 100644 board/qi/qi_lb60/u-boot.lds create mode 100644 include/configs/qi_lb60.h It has been pointed out (see [1]) that the files board/qi/qi_lb60/qi_lb60.c include/configs/qi_lb60.h added by this patch are licensed as GPL "version 3 of the License, or (at your option) any later version" - however, this is incompatible with the GPLv2 and GPLv2+ licenses that cover the rest of U-Boot. Would you be willing to re-license these files under GPLv2+ (and submit apatch to do that) ? Otherwise we would probably be forced to remove the qi_lb60 board support to be legally clean. Sorry for the inconvenience, but obviously this issue slipped through at the initial review of the code... [1] http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/164965 No answer since > one week. Should we revert this for v2013.07, then? Best regards Dirk [1] http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commit;h=3c945542dad99b1ec4a324ad6b69b8de8829827b ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] v2013.07-rc3
On 07/12/2013 03:27 PM, Tom Rini wrote: > Hey all, > > I've tagged and pushed v2013.07-rc3 out, and it should sync its > way around in a few hours. I believe we should be all sorted out > with FIT images and bootz and bootm finally, but a quick check that > we've really got things merged would be greatly appreciated. Everything seems to work fine on Raspberry Pi. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
On 7/11/2013 4:18 PM, Fabio Estevam wrote:
On Thu, Jul 11, 2013 at 8:03 PM, Marek Vasut wrote:
The MX28 multi-layer AHB bus can be too slow and trigger the
FEC DMA too early, before all the data hit the DRAM. This patch
ensures the data are written in the RAM before the DMA starts.
Please see the comment in the patch for full details.
This patch was produced with an amazing help from Albert Aribaud,
who pointed out it can possibly be such a bus synchronisation
issue.
Signed-off-by: Marek Vasut
Cc: Albert ARIBAUD
Cc: Fabio Estevam
Cc: Stefano Babic
Excellent, managed to transfer 90MB via TFTP on mx28evk without a
single timeout.
Tested-by: Fabio Estevam
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Perhaps this because our memory barriers are lacking.
Linux has this code
asm/io.h:#define writel(v,c)({ __iowmb();
writel_relaxed(v,c); })
asm/io.h-#ifdef CONFIG_ARM_DMA_MEM_BUFFERABLE
asm/io.h-#include
asm/io.h-#define __iormb() rmb()
asm/io.h:#define __iowmb() wmb()
asm/io.h-#else
asm/io.h-#define __iormb() do { } while (0)
asm/io.h:#define __iowmb() do { } while (0)
asm/io.h-#endif
asm/io.h-#ifdef CONFIG_ARM_DMA_MEM_BUFFERABLE
asm/io.h-#include
asm/io.h-#define __iormb() rmb()
asm/io.h:#define __iowmb() wmb()
asm/io.h-#else
asm/io.h-#define __iormb() do { } while (0)
asm/io.h:#define __iowmb() do { } while (0)
asm/io.h-#endif
asm/barrier.h-#elif defined(CONFIG_ARM_DMA_MEM_BUFFERABLE) ||
defined(CONFIG_SMP)
asm/barrier.h-#define mb() do { dsb(); outer_sync(); }
while (0)
asm/barrier.h-#define rmb() dsb()
asm/barrier.h:#define wmb() mb()
asm/barrier.h-#else
asm/barrier.h-#define mb() barrier()
asm/barrier.h-#define rmb() barrier()
asm/barrier.h:#define wmb() barrier()
asm/barrier.h-#endif
asm/barrier.h-#if __LINUX_ARM_ARCH__ >= 7
asm/barrier.h-#define isb() __asm__ __volatile__ ("isb" : : : "memory")
asm/barrier.h:#define dsb() __asm__ __volatile__ ("dsb" : : : "memory")
asm/barrier.h-#define dmb() __asm__ __volatile__ ("dmb" : : : "memory")
asm/barrier.h-#elif defined(CONFIG_CPU_XSC3) || __LINUX_ARM_ARCH__ == 6
asm/barrier.h-#define isb() __asm__ __volatile__ ("mcr p15, 0, %0, c7,
c5, 4" \
asm/barrier.h- : : "r" (0) : "memory")
asm/barrier.h:#define dsb() __asm__ __volatile__ ("mcr p15, 0, %0, c7,
c10, 4" \
asm/barrier.h- : : "r" (0) : "memory")
asm/barrier.h-#define dmb() __asm__ __volatile__ ("mcr p15, 0, %0, c7,
c10, 5" \
_
Can you try just adding a dsb() instead of the dummy read?
If this also fixes your problem, it seems better to fix our writel macro
Thanks
Troy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] usb: Use well-known descriptor sizes when parsing configuration
The existing USB configuration parsing code relies on the descriptors'
own length values when reading through the configuration blob. Since the
size of those descriptors is always well-defined, we should rather use
the known sizes instead of trusting device-provided values to be
correct. Also adds some safety to potential out-of-order descriptors.
Change-Id: I16f69dfdd6793aa0fe930b5148d4521f3e5c3090
Signed-off-by: Julius Werner
---
common/usb.c | 62
common/usb_hub.c | 14 -
2 files changed, 53 insertions(+), 23 deletions(-)
diff --git a/common/usb.c b/common/usb.c
index 55fff5b..4cf1d7a 100644
--- a/common/usb.c
+++ b/common/usb.c
@@ -341,6 +341,7 @@ static int usb_set_maxpacket(struct usb_device *dev)
/***
* Parse the config, located in buffer, and fills the dev->config structure.
* Note that all little/big endian swapping are done automatically.
+ * (wTotalLength has already been swapped when it was read.)
*/
static int usb_parse_config(struct usb_device *dev,
unsigned char *buffer, int cfgno)
@@ -361,24 +362,34 @@ static int usb_parse_config(struct usb_device *dev,
head->bDescriptorType);
return -1;
}
- memcpy(&dev->config, buffer, buffer[0]);
- le16_to_cpus(&(dev->config.desc.wTotalLength));
+ memcpy(&dev->config, buffer, USB_DT_CONFIG_SIZE);
dev->config.no_of_if = 0;
index = dev->config.desc.bLength;
/* Ok the first entry must be a configuration entry,
* now process the others */
head = (struct usb_descriptor_header *) &buffer[index];
- while (index + 1 < dev->config.desc.wTotalLength) {
+ while (index + 1 < dev->config.desc.wTotalLength && head->bLength) {
switch (head->bDescriptorType) {
case USB_DT_INTERFACE:
+ if (index + USB_DT_INTERFACE_SIZE >
+ dev->config.desc.wTotalLength) {
+ puts("USB IF descriptor overflowed buffer!\n");
+ break;
+ }
if (((struct usb_interface_descriptor *) \
&buffer[index])->bInterfaceNumber != curr_if_num) {
/* this is a new interface, copy new desc */
ifno = dev->config.no_of_if;
+ if (ifno >= USB_MAXINTERFACES) {
+ puts("Too many USB interfaces!\n");
+ /* try to go on with what we have */
+ return 1;
+ }
if_desc = &dev->config.if_desc[ifno];
dev->config.no_of_if++;
- memcpy(if_desc, &buffer[index], buffer[index]);
+ memcpy(if_desc, &buffer[index],
+ USB_DT_INTERFACE_SIZE);
if_desc->no_of_ep = 0;
if_desc->num_altsetting = 1;
curr_if_num =
@@ -392,12 +403,26 @@ static int usb_parse_config(struct usb_device *dev,
}
break;
case USB_DT_ENDPOINT:
+ if (index + USB_DT_ENDPOINT_SIZE >
+ dev->config.desc.wTotalLength) {
+ puts("USB EP descriptor overflowed buffer!\n");
+ break;
+ }
+ if (ifno < 0) {
+ puts("Endpoint descriptor out of order!\n");
+ break;
+ }
epno = dev->config.if_desc[ifno].no_of_ep;
if_desc = &dev->config.if_desc[ifno];
+ if (epno > USB_MAXENDPOINTS) {
+ printf("Interface %d has too many endpoints!\n",
+ if_desc->desc.bInterfaceNumber);
+ return 1;
+ }
/* found an endpoint */
if_desc->no_of_ep++;
memcpy(&if_desc->ep_desc[epno],
- &buffer[index], buffer[index]);
+ &buffer[index], USB_DT_ENDPOINT_SIZE);
ep_wMaxPacketSize = get_unaligned(&dev->config.\
if_desc[ifno].\
ep_desc[epno].\
@@ -410,9 +435,18 @@ static int usb_parse_config(struct usb_device *dev,
debug("if %d, ep %d\n", ifno, epno);
[U-Boot] How to?
Hi! My name's Kristoffer & I would like to get some help in making a new updated version of Uboot, but AFAIK the latest Uboot-version doesn't have sufficient support for my board which has the following properties: Titania MIPSEL (32-bit if I'm not mistaken). Uboot. mstar# I have bootloader-access debug-access (at least I used to have it) It's a TV that LG made & it's called 60PK550N-ZE It's somewhat lacking source can be found here (You'll find the current Uboot-source there as well): http://www.lg.com/lgecs.downloadFile.ldwf?OPENSOURCE_FILE_NAME=%5BEurope%5DGP1R_M_PDP_FI_2010.tar.gz&OPENSOURCE_ORIGINAL_NAME=%2FOpCAT0007%2F%5BEurope%5DGP1R_M_PDP_FI_2010.tar.gz&newOpensource=Y How can I use the stuff in that tarball when it comes to building a new updated version of Uboot? I have read some guides, but none are for my board so I could use some help if you're willing to provide some. I'll do the work if you tell me what I can do. I'm hoping for a serious answer. /Kristoffer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix memory stomper in DFU. Loop NULL-initted one past allocated array size.
On Fri, 12 Jul 2013 13:48:51 -0400 mboa...@prograde.net wrote: Hi Michael, > From: Michael Cashwell > > The memory layout arranged itself such that a long-standing memory > stomper in a DFU prepare callback used during USB registration > mangled the malloc heap enough to cause my board to panic much later > in a call to free(). Since it hadn't happened before but was > repeatable I decided to investigate before it vanished again. > > The actual stomp happened in this line after the for loop: > f_dfu->function[i] = NULL; Thanks for investigation, but I've already fixed that: dfu:function: Fix number of allocated DFU function pointers SHA1: e059a400ad780328cd5ad22c396298cac520c856 This patch has been included to v2013.07-rc2. > > git blame says this code was introduced here: > b819ddbf (Lukasz Majewski 2012-08-06 14:41:06 +0200 587) > > I'm not sure if the function[] array actually needs a NULL entry at > the end. If so then this patch is the right fix. If it really always > knows the last array index and doesn't need the NULL then removing > the offending assignment would be better. Not knowing makes this > patch safer. > > Signed-off-by: Michael Cashwell > --- > drivers/usb/gadget/f_dfu.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/usb/gadget/f_dfu.c b/drivers/usb/gadget/f_dfu.c > index a322ae5..b24de09 100644 > --- a/drivers/usb/gadget/f_dfu.c > +++ b/drivers/usb/gadget/f_dfu.c > @@ -589,7 +589,7 @@ static int dfu_prepare_function(struct f_dfu > *f_dfu, int n) struct usb_interface_descriptor *d; > int i = 0; > > - f_dfu->function = calloc(sizeof(struct usb_descriptor_header > *), n); > + f_dfu->function = calloc(sizeof(struct usb_descriptor_header > *), n + 1); if (!f_dfu->function) > goto enomem; > Anyway its nice to hear, that +1 user of DFU is out there :-) Best regards, Lukasz Majewski signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] mx6qsabresd: Add splash screen support via HDMI
Signed-off-by: Pardeep Kumar Singla
---
board/freescale/mx6sabresd/mx6sabresd.c | 48 +++
include/configs/mx6sabre_common.h |2 +-
include/configs/mx6sabresd.h| 18
3 files changed, 67 insertions(+), 1 deletion(-)
diff --git a/board/freescale/mx6sabresd/mx6sabresd.c
b/board/freescale/mx6sabresd/mx6sabresd.c
index 222ee98..fc00063 100644
--- a/board/freescale/mx6sabresd/mx6sabresd.c
+++ b/board/freescale/mx6sabresd/mx6sabresd.c
@@ -29,6 +29,11 @@
#include
#include
#include
+#include
+#include
+#include
+#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -131,6 +136,37 @@ static void setup_iomux_uart(void)
imx_iomux_v3_setup_multiple_pads(uart1_pads, ARRAY_SIZE(uart1_pads));
}
+#if defined(CONFIG_VIDEO_IPUV3)
+static struct display_info_t const displays = {
+ .pixfmt = IPU_PIX_FMT_RGB24,
+ .enable = imx_enable_hdmi_phy,
+ .mode = {
+ .name = "HDMI",
+ .refresh= 60,
+ .xres = 1024,
+ .yres = 768,
+ .pixclock = 15385,
+ .left_margin= 220,
+ .right_margin = 40,
+ .upper_margin = 21,
+ .lower_margin = 7,
+ .hsync_len = 60,
+ .vsync_len = 10,
+ .sync = FB_SYNC_EXT,
+ .vmode = FB_VMODE_NONINTERLACED
+} };
+
+int board_video_skip(void)
+{
+ int ret;
+ ret = ipuv3_fb_init(&displays.mode, 0, displays.pixfmt);
+ if (ret)
+ printf("HDMI cannot be configured: %d\n", ret);
+ displays.enable(&displays);
+ return ret;
+}
+#endif /* CONFIG_VIDEO_IPUV3 */
+
#ifdef CONFIG_FSL_ESDHC
struct fsl_esdhc_cfg usdhc_cfg[3] = {
{USDHC2_BASE_ADDR},
@@ -255,10 +291,22 @@ int board_eth_init(bd_t *bis)
int board_early_init_f(void)
{
setup_iomux_uart();
+#if defined(CONFIG_VIDEO_IPUV3)
+ imx_setup_hdmi();
+#endif
return 0;
}
+/*
+ * Do not overwrite the console
+ * Use always serial for U-Boot console
+ */
+int overwrite_console(void)
+{
+ return 1;
+}
+
int board_init(void)
{
/* address of boot parameters */
diff --git a/include/configs/mx6sabre_common.h
b/include/configs/mx6sabre_common.h
index 53cc559..bb1ac8c 100644
--- a/include/configs/mx6sabre_common.h
+++ b/include/configs/mx6sabre_common.h
@@ -32,7 +32,7 @@
#define CONFIG_REVISION_TAG
/* Size of malloc() pool */
-#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + 2 * 1024 * 1024)
+#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + 2 * 1024 * 1024)
#define CONFIG_BOARD_EARLY_INIT_F
#define CONFIG_BOARD_LATE_INIT
diff --git a/include/configs/mx6sabresd.h b/include/configs/mx6sabresd.h
index 76675f4..3d3ec9f 100644
--- a/include/configs/mx6sabresd.h
+++ b/include/configs/mx6sabresd.h
@@ -25,6 +25,24 @@
#define PHYS_SDRAM_SIZE(1u * 1024 * 1024 * 1024)
#include "mx6sabre_common.h"
+#include
+
+/* Size of malloc() pool */
+#define CONFIG_SYS_MALLOC_LEN (10 * SZ_1M)
+
+/* Framebuffer */
+#define CONFIG_VIDEO
+#define CONFIG_VIDEO_IPUV3
+#define CONFIG_CFB_CONSOLE
+#define CONFIG_VGA_AS_SINGLE_DEVICE
+#define CONFIG_SYS_CONSOLE_IS_IN_ENV
+#define CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE
+#define CONFIG_VIDEO_BMP_RLE8
+#define CONFIG_SPLASH_SCREEN
+#define CONFIG_BMP_16BPP
+#define CONFIG_VIDEO_LOGO
+#define CONFIG_IPUV3_CLK 26000
+#define CONFIG_IMX_HDMI
#define CONFIG_SYS_FSL_USDHC_NUM 3
#if defined(CONFIG_ENV_IS_IN_MMC)
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] mx6: Factor out common HDMI setup code
Instead of duplicating HDMI setup code for every mx6 board, factor out the
common code
Signed-off-by: Pardeep Kumar Singla
---
arch/arm/cpu/armv7/mx6/soc.c | 51 ++
arch/arm/include/asm/arch-mx6/mxc_hdmi.h |6 ++
arch/arm/include/asm/arch-mx6/sys_proto.h | 13
board/boundary/nitrogen6x/nitrogen6x.c| 57 +---
board/freescale/mx6qsabrelite/mx6qsabrelite.c | 60 ++--
board/wandboard/wandboard.c | 91 ++---
include/configs/mx6qsabrelite.h |8 ++-
include/configs/nitrogen6x.h |2 +-
include/configs/wandboard.h |1 +
9 files changed, 106 insertions(+), 183 deletions(-)
diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
index fc436fb..6e79310 100644
--- a/arch/arm/cpu/armv7/mx6/soc.c
+++ b/arch/arm/cpu/armv7/mx6/soc.c
@@ -32,6 +32,8 @@
#include
#include
#include
+#include
+#include
struct scu_regs {
u32 ctrl;
@@ -228,3 +230,52 @@ const struct boot_mode soc_boot_modes[] = {
void s_init(void)
{
}
+
+#ifdef CONFIG_IMX_HDMI
+void imx_enable_hdmi_phy(struct display_info_t const *dev)
+{
+ struct hdmi_regs *hdmi = (struct hdmi_regs *)HDMI_ARB_BASE_ADDR;
+ u8 reg;
+ reg = readb(&hdmi->phy_conf0);
+ reg |= HDMI_PHY_CONF0_PDZ_MASK;
+ writeb(reg, &hdmi->phy_conf0);
+ udelay(3000);
+ reg |= HDMI_PHY_CONF0_ENTMDS_MASK;
+ writeb(reg, &hdmi->phy_conf0);
+ udelay(3000);
+ reg |= HDMI_PHY_CONF0_GEN2_TXPWRON_MASK;
+ writeb(reg, &hdmi->phy_conf0);
+ writeb(HDMI_MC_PHYRSTZ_ASSERT, &hdmi->mc_phyrstz);
+}
+
+void imx_setup_hdmi(void)
+{
+ struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
+ struct hdmi_regs *hdmi = (struct hdmi_regs *)HDMI_ARB_BASE_ADDR;
+ int reg;
+
+ /* Turn on IPU clock */
+ reg = readl(&mxc_ccm->CCGR3);
+ reg |= MXC_CCM_CCGR3_IPU1_IPU_DI0_OFFSET;
+ writel(reg, &mxc_ccm->CCGR3);
+
+ /* Turn on HDMI PHY clock */
+ reg = readl(&mxc_ccm->CCGR2);
+ reg |= MXC_CCM_CCGR2_HDMI_TX_IAHBCLK_MASK|
+MXC_CCM_CCGR2_HDMI_TX_ISFRCLK_MASK;
+ writel(reg, &mxc_ccm->CCGR2);
+/* clear HDMI PHY reset */
+writeb(HDMI_MC_PHYRSTZ_DEASSERT, &hdmi->mc_phyrstz);
+ reg = readl(&mxc_ccm->chsccdr);
+ reg &= ~(MXC_CCM_CHSCCDR_IPU1_DI0_PRE_CLK_SEL_MASK|
+MXC_CCM_CHSCCDR_IPU1_DI0_PODF_MASK|
+MXC_CCM_CHSCCDR_IPU1_DI0_CLK_SEL_MASK);
+ reg |= (CHSCCDR_CLK_SEL_LDB_DI0
+<< MXC_CCM_CHSCCDR_IPU1_DI0_CLK_SEL_OFFSET)|
+(CHSCCDR_PODF_DIVIDE_BY_3
+<< MXC_CCM_CHSCCDR_IPU1_DI0_PODF_OFFSET)
+|(CHSCCDR_IPU_PRE_CLK_540M_PFD
+<< MXC_CCM_CHSCCDR_IPU1_DI0_PRE_CLK_SEL_OFFSET);
+ writel(reg, &mxc_ccm->chsccdr);
+}
+#endif
diff --git a/arch/arm/include/asm/arch-mx6/mxc_hdmi.h
b/arch/arm/include/asm/arch-mx6/mxc_hdmi.h
index 9dccb3f..9e2074b 100644
--- a/arch/arm/include/asm/arch-mx6/mxc_hdmi.h
+++ b/arch/arm/include/asm/arch-mx6/mxc_hdmi.h
@@ -21,6 +21,12 @@
#ifndef __MXC_HDMI_H__
#define __MXC_HDMI_H__
+#ifdef CONFIG_IMX_HDMI
+#include
+void imx_enable_hdmi_phy(struct display_info_t const *dev);
+void imx_setup_hdmi(void);
+#endif
+
/*
* Hdmi controller registers
*/
diff --git a/arch/arm/include/asm/arch-mx6/sys_proto.h
b/arch/arm/include/asm/arch-mx6/sys_proto.h
index 38e4e51..9fb539b 100644
--- a/arch/arm/include/asm/arch-mx6/sys_proto.h
+++ b/arch/arm/include/asm/arch-mx6/sys_proto.h
@@ -25,6 +25,9 @@
#define _SYS_PROTO_H_
#include
+#include
+#include
+#include
#define MXC_CPU_MX51 0x51
#define MXC_CPU_MX53 0x53
@@ -34,6 +37,16 @@
#define MXC_CPU_MX6Q 0x63
#define is_soc_rev(rev)((get_cpu_rev() & 0xFF) - rev)
+
+struct display_info_t {
+ intbus;
+ intaddr;
+ intpixfmt;
+ int(*detect)(struct display_info_t const *dev);
+ void(*enable)(struct display_info_t const *dev);
+ structfb_videomode mode;
+};
+
u32 get_cpu_rev(void);
const char *get_imx_type(u32 imxtype);
unsigned imx_ddr_size(void);
diff --git a/board/boundary/nitrogen6x/nitrogen6x.c
b/board/boundary/nitrogen6x/nitrogen6x.c
index 8f0f9b8..d97d47a 100644
--- a/board/boundary/nitrogen6x/nitrogen6x.c
+++ b/board/boundary/nitrogen6x/nitrogen6x.c
@@ -464,40 +464,12 @@ static iomux_v3_cfg_t const rgb_pads[] = {
MX6_PAD_DISP0_DAT23__IPU1_DISP0_DAT_23,
};
-struct display_info_t {
- int bus;
- int addr;
- int pixfmt;
- int (*detect)(struct display_info_t const *dev);
- void(*enable)(struct display_info_t const *dev);
- struct fb_videomode mode;
-};
-
-
static int detect_hdmi(struct display_info_t const *dev)
{
struct hdmi_regs *hdmi =
Re: [U-Boot] [PATCH V2] mtd: mxc_nand: Fix crash after MTD resync
Dear Scott Wood, > Oh, sorry... didn't realize the release was in three days. :-( > > I'll send a pull request. > > -Scott Thanks ;-) Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [[PATCH v3 2/2] gpio: omap5-uevm: Configure the tca6424 gpio expander
On Fri, Jul 12, 2013 at 12:30 PM, Dan Murphy wrote:
> On 07/11/2013 01:02 PM, Nishanth Menon wrote:
diff --git a/board/ti/omap5_uevm/mux_data.h
>> b/board/ti/omap5_uevm/mux_data.h
> index a82795d..7e6415e 100644
> --- a/board/ti/omap5_uevm/mux_data.h
> +++ b/board/ti/omap5_uevm/mux_data.h
> @@ -56,6 +56,8 @@ const struct pad_conf_entry
>> core_padconf_array_essential[] = {
> {USBD0_HS_DP, (IEN | M0)},/* USBD0_HS_DP */
> {USBD0_HS_DM, (IEN | M0)},/* USBD0_HS_DM */
> {USBD0_SS_RX, (IEN | M0)},/* USBD0_SS_RX */
> +{I2C5_SCL, (IEN | M0)}, /* I2C5_SCL */
nit pick -> SCL (or i2c clk) is out put from master - always. IEN
>> enables full duplex, but anyways.. just a nitpick :)
>>> OK I changed this and did a test and reads fail without the IEN set.
>>> This is to sync the client clocks.
>> Scl? I2c clock? Does not work without input- something is fishy no?
> Nope. There is clock synchronization and clock arbitration that happens and
> the I2C master needs to see the SCL as an input.
Also, Table 24-1. HS I2C Input/Output in OMAP5 ES2.0 TRM Rev U
supports the requirement of SCL being input as well.
I think you mean bus busy condition here[1] rather than multi-master
arbitration? in the case of arbitration, the SDA will be monitored
than SCL - See "Figure 24-9. HS I2C Arbitration Between Master
Transmitters" in TRM.
Bus busy on the other hand needs stop condition detection for
transmission which involves SCL and SDA. yet another need is the
requirement to support clock stretching[2] (where the i2c slave holds
the SCL low while it does "something").
Either way, it explains why SCL needs to be in IEN.
[1] http://www.i2c-bus.org/MultiMaster/
[2] http://www.i2c-bus.org/clock-stretching/
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] RAMBOOT
I have a requirement that would be solved nicely by U-Boot booting U-Boot (and perhaps even another time). Is this a reasonable thing to do? I'm working with the mpc85xx CPU, P5020DS board and have gotten somewhat familiar with the design & flow running the P5020_NAND configuration (which is RAMBOOTed). I took a quick stab at build after reading README.ramboot-ppc85xx which failed -- think I've got config define dependencies to work through yet. Guess I'm somewhat skeptical this will work with all the TLB & LAW set-up that'd get redone along the way. Any advice would be appreciated. Thanks, Dean ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/7 v7] NAND: TPL : introduce the TPL based on the SPL
On 07/09/2013 04:50:49 AM, ying.zh...@freescale.com wrote: +During the TPL build a variable named CONFIG_TPL_BUILD is exported +in the make environment and also appended to CPPFLAGS with -DCONFIG_TPL_BUILD. +Source files can therefore be compiled for TPL with different settings. + +For example: + +ifeq ($(CONFIG_TPL_BUILD),y) +COBJS-y += board_tpl.o +else +COBJS-y += board.o +endif + +COBJS-$(CONFIG_TPL_BUILD) += foo.o This is not how it should normally be done. Normally the board config file should determine which SPL options to choose, based on whether CONFIG_TPL_BUILD is set. diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index bb81e84..6507fcf 100644 --- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -29,6 +29,8 @@ ifdef CONFIG_CMD_NAND ifdef CONFIG_SPL_BUILD +ifndef CONFIG_TPL_BUILD Why? Let the board file define what it wants for the TPL case, just as in SPL. ifdef CONFIG_SPL_NAND_DRIVERS NORMAL_DRIVERS=y endif @@ -40,6 +42,10 @@ COBJS-$(CONFIG_SPL_NAND_LOAD) += nand_spl_load.o COBJS-$(CONFIG_SPL_NAND_ECC) += nand_ecc.o COBJS-$(CONFIG_SPL_NAND_BASE) += nand_base.o +else +COBJS-y += nand.o +endif What do you need nand.c for? Why do you think all other TPLs will have the same need? else # not spl NORMAL_DRIVERS=y @@ -82,9 +88,11 @@ COBJS-$(CONFIG_NAND_DOCG4) += docg4.o else # minimal SPL drivers +ifdef CONFIG_SPL_BUILD COBJS-$(CONFIG_NAND_FSL_ELBC) += fsl_elbc_spl.o COBJS-$(CONFIG_NAND_FSL_IFC) += fsl_ifc_spl.o COBJS-$(CONFIG_NAND_MXC) += mxc_nand_spl.o +endif How are you going to get here in the first place without CONFIG_SPL_BUILD? @@ -162,6 +173,17 @@ $(OBJTREE)/SPL : $(obj)u-boot-spl.bin depend $(MAKE) -C $(SRCTREE)/arch/arm/imx-common $@ ALL-y += $(obj)u-boot-spl.bin +else +$(OBJTREE)/MLO: $(obj)u-boot-tpl.bin + $(OBJTREE)/tools/mkimage -T omapimage \ + -a $(CONFIG_SPL_TEXT_BASE) -d $< $@ + +$(OBJTREE)/MLO.byteswap: $(obj)u-boot-tpl.bin + $(OBJTREE)/tools/mkimage -T omapimage -n byteswap \ + -a $(CONFIG_SPL_TEXT_BASE) -d $< $@ + +ALL-y += $(obj)u-boot-tpl.bin +endif Why? There's not even a user of MLO with TPL. In any case, is there no way we can just set filename variables based on SPL/TPL here, rather than duplicating code? +ifndef CONFIG_TPL_BUILD $(obj)u-boot-spl.bin: $(obj)u-boot-spl $(OBJCOPY) $(OBJCFLAGS) -O binary $< $@ @@ -185,6 +208,18 @@ GEN_UBOOT = \ $(obj)u-boot-spl: depend $(START) $(LIBS) $(obj)u-boot-spl.lds $(GEN_UBOOT) +else +$(obj)u-boot-tpl.bin: $(obj)u-boot-tpl + $(OBJCOPY) $(OBJCFLAGS) -O binary $< $@ + +GEN_UBOOT = \ + cd $(obj) && $(LD) $(LDFLAGS) $(LDFLAGS_$(@F)) $(__START) \ + --start-group $(__LIBS) --end-group $(PLATFORM_LIBS) \ + -Map u-boot-tpl.map -o u-boot-tpl + +$(obj)u-boot-tpl: depend $(START) $(LIBS) $(obj)u-boot-spl.lds + $(GEN_UBOOT) +endif Likewise. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [ANN] v2013.07-rc3
Hey all, I've tagged and pushed v2013.07-rc3 out, and it should sync its way around in a few hours. I believe we should be all sorted out with FIT images and bootz and bootm finally, but a quick check that we've really got things merged would be greatly appreciated. I expect on Monday to have a bugfix for exynos clock things to apply. And I'm fine just applying to master, once it's been ack'd by everyone that needs to. This leaves the "OMAP3 SPL" issue to sort out. So I'm going to see about reproducing that myself to weigh in better on the fix. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd_bootm.c: Re-order bootm_load_os return check for ELDK4.2
On Thu, Jul 11, 2013 at 09:38:04AM -0400, Tom Rini wrote: > With ELDK4.2 we were getting a warning that load_end may be used > uninitialized in calling lmb_reserve. This could not be the case, > however. If we re-order the checks (and make them slightly clearer as > well) the warning goes away. bootm_load_os may only return 0 on > success, BOOTM_ERR_OVERLAP in a non-fatal overlap (already covered in > comments) or a fatal BOOTM_ERR that is covered in the error handler. > > Signed-off-by: Tom Rini Applied to u-boot/master. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: fix FIT image with ramdisk
On Fri, Jul 12, 2013 at 03:09:23PM +0200, Stefano Babic wrote: > Booting a FIT image containing a ramdisk, > the ramdisk is loaded at address 0x0 that causes > bus errors for architectures that do not have > RAM starting at address zero. > > Signed-off-by: Stefano Babic I've re-worded this as: common/image.c: Fix regression with ramdisk load/entry points in FIT A FIT image with a ramdisk that sets the entry or load points to 0x0 must be treated as meaning "leave in place" and NOT "relocate to 0x0". This regression was introduced in a51ec63. And applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
On Wed, Jul 10, 2013 at 08:44:34PM +0200, Marek Vasut wrote: > The following changes since commit 225fd8c5d4556547896a5d32ee092a258f3df638: > > cmd_bootm.c: Make bootz handle BOOTM_STATE_FINDOTHER itself (2013-07-10 > 09:15:15 -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-usb.git master > > for you to fetch changes up to ecc8edbf6995558d8a47b43ac6645840c98a7b95: > > usb: pxa27x_udc: fix compiler warnings (2013-07-10 20:18:57 +0200) > > > Mike Dunn (1): > usb: pxa27x_udc: fix compiler warnings > > ??ukasz Majewski (1): > dfu: Update DFU's authorship history > > drivers/usb/gadget/f_dfu.c |7 +++ > drivers/usb/gadget/pxa27x_udc.c | 14 +- > 2 files changed, 12 insertions(+), 9 deletions(-) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: nand flash
On Fri, Jul 12, 2013 at 04:13:41PM -0500, Scott Wood wrote: > Sorry for the lateness, but this patch fixes a BUG() regression > with CONFIG_MXC_NAND_HWECC. > > The following changes since commit 225fd8c5d4556547896a5d32ee092a258f3df638: > > cmd_bootm.c: Make bootz handle BOOTM_STATE_FINDOTHER itself (2013-07-10 > 09:15:15 -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-nand-flash.git master > > for you to fetch changes up to 1c903694370259738abccc67ff0d6e5eaf7886f9: > > mtd: mxc_nand: Fix crash after MTD resync (2013-07-12 16:12:33 -0500) > > > Marek Vasut (1): > mtd: mxc_nand: Fix crash after MTD resync > > drivers/mtd/nand/mxc_nand.c | 10 -- > 1 file changed, 4 insertions(+), 6 deletions(-) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] Correct some remaining bootm problems
On Wed, Jul 10, 2013 at 11:08:07PM -0700, Simon Glass wrote: > The tortuous refactoring of bootm and fit_image_load() has thrown up > four more issues: > > - Support for bootm (without arguments) on many OSes is broken since the > OS functions do not handle the PREP stage, which is now required > - In the case of loading a FIT image with a bootm-selected kernel > configuration, this is not used for ramdisk and fdt but must be manually > specified for each. > - The Elf image loader arguments are out by 1 > - There is an extra OK message in the case of loading an uncompressed > kernel > > This series corrects these problems. Verification was done using some > sandbox tests written for the occassion. These will be sent to the list > during the next merge window (or earlier if anyone wants to try them). Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] UPDATED: pull request: u-boot-arm/master
On Fri, Jul 12, 2013 at 02:12:20PM +0200, Albert ARIBAUD wrote: > Hello Tom, > > Update to my previous PR, to include the last Tegra and IMX PRs: > > The following changes since commit > fbf87b1823dd5ebc2a384711ea2c677543019ece: > > arm: optimize relocate_code routine (2013-06-21 23:05:50 +0200) > > are available in the git repository at: > > git://git.denx.de/u-boot-arm master > > for you to fetch changes up to efc284e32503b240dbd35c6e8b8d098d702b4be7: > > Merge branch 'u-boot-imx/master' into 'u-boot-arm/master' (2013-07-12 > 13:20:35 +0200) > > > > Ajay Kumar (1): > video: exynos_fb: Add the missing #else clause > > Albert ARIBAUD (3): > Merge branch 'u-boot-imx/master' into 'u-boot-arm/master' > Merge branch 'u-boot-samsung/master' into 'u-boot-arm/master' > Merge branch 'u-boot-imx/master' into 'u-boot-arm/master' > > Amar (2): > EXYNOS5: I2C: Add FDT and non-FDT support for I2C > EXYNOS: Resolve the i2c compilation error > > Axel Lin (3): > gpio: s3c2440_gpio: Fix wrong writel arguments > gpio: s5p_gpio: Call s5p_gpio_set_value() instead of open-code > ARM: OMAP: GPIO: Fix valid range and enable usage of all GPIOs on > OMAP5 > > Bernie Thompson (1): > exynos: Adjust the starting MIF voltage to 1.05v > > Dirk Behme (2): > spi: mxc_spi: Fix pre and post divider calculation > spi: mxc_spi: Update pre and post divider algorithm > > Eric Nelson (1): > dwc_ahsata: Allow use with dcache enabled > > Fabio Estevam (8): > README: mx28_common: Keep the text within 80 columns > README: mx28_common: Do not hardcode the SSP port > README: mx28_common: Fix structure of sentence > README: mxs: Introduce README.mxs > mx28evk: Move README file inside board directory > m28evk: Move README file inside board directory > MAINTAINERS: Add an entry to the mx6q wandboard variant > video: mxsfb: Break the line in videomode message > > Ilya Ledvich (1): > am33xx: fix the ddr_cmdtctrl structure > > Jim Lin (3): > ARM: Tegra: FDT: Add USB EHCI function for T30/T114 > ARM: Tegra: USB: EHCI: Add support for Tegra30/Tegra114 > Tegra: Config: Enable Tegra30/Tegra114 USB function > > Lokesh Vutla (1): > ARM: OMAP4+: Fix MA detection during SDRAM_AUTO_DETECTION > > Marek Vasut (3): > m28evk: add trimffs to nand command > net: fec: Remove bogus flush_dcache_range() call > net: fec: Avoid MX28 bus sync issue > > Michael Trimarchi (1): > usb: omap: ulpi: fix ulpi transceiver access > > Mike Dunn (5): > pxa: add support for palmtreo680 board > pxa: palmtreo680 flash programming utility > pxa: turn icache off in cpu_init_crit() > pxa: use -mcpu=xscale compiler option > pxa: fix memory coherency problem after relocation > > Minkyu Kang (1): > arm: exynos: fix clock calculation > > Otavio Salvador (8): > vf610twr: Add default environment in line with other Freescale > boards vf610twr: Remove SoC name from U-Boot prompt > mx53loco: Change default environment to cope with OE changes > mx6qsabrelite: Change default environment to cope with OE changes > mx6slevk: Change default environment to cope with OE changes > wandboard: Change default environment to cope with OE changes > mx51evk: Change default environment to cope with OE changes > mx53ard: Change default environment to cope with OE changes > > Pierre Aubert (3): > imx6: fix GPR2 wrong definition > imx: Complete the pin definitions for the i.MX6DL / i.MX6Solo > imx: Add support for the SabreSD shipped with i.MX6DL > > Rajeshwari Shinde (9): > EXYNOS5: FDT: Add compatible strings for Serial > EXYNOS5: FDT: Add serial device node values > S5P: Serial: Add fdt support to driver > CONFIG: EXYNOS5: Enable silent console > SMDK5250: Remove reduntant code > EXYNOS: Add API for power reset and exit wakeup > EXYNOS: LDS file move to common > EXYNOS4210: Configure GPIO for uart > EXYNOS: Move files from board/samsung to arch/arm > > Robert Winkler (4): > imx: nitrogen6x: Enabled data cache > imx: nitrogen6x: Enable bootz > imx: nitrogen6x: Enable raw initrd > imx: nitrogen6x: Enable filesystem generic commands > > Simon Glass (1): > exynos: Enable mmc for snow > > Stephen Warren (2): > ARM: tegra: enable LCD panel on Harmony > ARM: tegra: enable LCD panel on Ventana > > Tapani Utriainen (1): > Add support for Wandboard Quad > > trem (2): > mx27: add function enable_caches > mx27: add i2c clock > > ??ukasz Majewski (2): > arm:trats: Increase malloc pool size (for DFU ext4 transfers) > power:bat:trats: Break battery charging with ctrl+C Applied to u-boot/master, thanks! -- Tom signature.asc Descri
Re: [U-Boot] [PATCH v3] bootm: Handle errors consistently
On Wed, Jul 10, 2013 at 09:25:33AM -0400, Tom Rini wrote: > From: Simon Glass > > A recent bootm fix left the error path incomplete. If CONFIG_TRACE is > set it may still not be a supported command, so cover that with the > unsupported subcommand print. Once we handle BOOTM_STATE_OS_GO, we can > just move into the error handler itself, no need for a goto there. > > Signed-off-by: Simon Glass > [trini: Update slightly based on Simon's changes to also cover > CONFIG_TRACE/BOOTM_STATE_FAKE_OS_GO] > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: nand flash
Sorry for the lateness, but this patch fixes a BUG() regression with CONFIG_MXC_NAND_HWECC. The following changes since commit 225fd8c5d4556547896a5d32ee092a258f3df638: cmd_bootm.c: Make bootz handle BOOTM_STATE_FINDOTHER itself (2013-07-10 09:15:15 -0400) are available in the git repository at: git://git.denx.de/u-boot-nand-flash.git master for you to fetch changes up to 1c903694370259738abccc67ff0d6e5eaf7886f9: mtd: mxc_nand: Fix crash after MTD resync (2013-07-12 16:12:33 -0500) Marek Vasut (1): mtd: mxc_nand: Fix crash after MTD resync drivers/mtd/nand/mxc_nand.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL size issues on OMAP4
Hi On 07/12/2013 11:03 PM, Michael Cashwell wrote: > On Jul 11, 2013, at 1:29 PM, Tom Rini wrote: > >> On Thu, Jul 11, 2013 at 01:01:30PM -0400, Michael Cashwell wrote: >>> I've been absent for a while and couldn't find a way to search the >>> list archives so I apologize if this has already been discussed? >>> >>> I've been fighting the SPL binary growing too large on OMAP4 (using >>> custom configs and features). It's annoying that too large just fails >>> to run with no build or runtime notice. But that's a different issue. >> >> What version are you using? When SPL is too large a build-time failure >> is expected. > > I've seen that happen in gross cases where it exceeds the 38K limit in > omap4_common.h's CONFIG_SPL_MAX_SIZE but I currently have two configs > that are both well below that size yet the larger one doesn't run. > > The larger MLO is 0x8a21 bytes (0x8c29 with the GP header) and _end is > 0x4030cd74. This loops endlessly at 0x30080. I get no console output. > Even if the additional code is buggy it's not called early enough to > prevent at least the banner from going out so I'm pretty sure it's the > ROM not even starting it. > > The smaller MLO is 0x757c bytes (0x7784 with the GP header) and _end is > 0x4030b8cc. This runs OK. > > I am still exploring. > 41K Jul 12 15:07 MLO I have an hybrid booting (serial + eMMC raw) or (sdcard + eMMC raw) both are working. Michael >> This is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303 which seems to >> have gotten little attention after initial triage. I guess I need to >> find a little time to show it's still there. > > Yes, I'd seen that. What I don't understand is why gcc doesn't just put > such strings into different sections like it does with its own __func__ > strings. Then it would all just work. > > I also don't get them implementing anonymous string merging while ignoring > GC. Both are size optimizations and the one they don't seem to care about > I'd expect to produce more savings. > >>> Is there a work around I haven't thought of? I'm thinking along the >>> lines of disabling all printfs in SPL in the hope that will take the >>> strings away (since many are some sort of debug / progress message). >> >> One option would be to add a "disable all output" option to SPL that >> would get all of the strings dropped. I'm not sure how cleanly this can >> be done, but I know it has been done. > > I have a pile of WIP to submit (a tiny one went today). I'm loath to > do anything major that would be unlikely to be accepted upstream because > of the work to keep it clean when I pull. > > I'm thinking about a config option for SPL that would define away all > printf() and puts() calls. That would cover most of the low-hanging fruit. > It's not a complete solution and would mean no console output in SPL but > I'd think it could be done with a small source impact. Still noodling. > >> Another option would be to do some careful splitting and #ifdef'ery of >> files so that we can just never link in the stuff with strings we don't >> need. > > Yes, lacking a toolchain that has any vowels in it's tray I must agree. > > -Mike > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] mtd: mxc_nand: Fix crash after MTD resync
Oh, sorry... didn't realize the release was in three days. :-(
I'll send a pull request.
-Scott
On 07/12/2013 08:26:04 AM, Marek Vasut wrote:
Hi,
Tom/Stefano, can you pick this for .07? Otherwise all mxc with NAND
are broken.
Thanks
> The driver triggered a BUG() in nand_base.c:3214/nand_scan_tail()
> because the ecc.strength was not set in NAND_ECC_HW_SYNDROME ECC
> mode.
>
> Signed-off-by: Marek Vasut
> Cc: Benoit Thebaudeau
> Cc: Fabio Estevam
> Cc: Scott Wood
> Cc: Stefano Babic
> ---
> drivers/mtd/nand/mxc_nand.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> V2: Set ecc.strength for both NAND_ECC_HW and NAND_ECC_HW_SYNDROME
mode
>
> diff --git a/drivers/mtd/nand/mxc_nand.c
b/drivers/mtd/nand/mxc_nand.c
> index ac435f2..40b0741 100644
> --- a/drivers/mtd/nand/mxc_nand.c
> +++ b/drivers/mtd/nand/mxc_nand.c
> @@ -1242,12 +1242,10 @@ int board_nand_init(struct nand_chip *this)
>this->ecc.mode = NAND_ECC_HW;
>}
>
> - if (this->ecc.mode == NAND_ECC_HW) {
> - if (is_mxc_nfc_1())
> - this->ecc.strength = 1;
> - else
> - this->ecc.strength = 4;
> - }
> + if (is_mxc_nfc_1())
> + this->ecc.strength = 1;
> + else
> + this->ecc.strength = 4;
>
>host->pagesize_2k = 0;
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL size issues on OMAP4
On Jul 11, 2013, at 1:29 PM, Tom Rini wrote: > On Thu, Jul 11, 2013 at 01:01:30PM -0400, Michael Cashwell wrote: >> I've been absent for a while and couldn't find a way to search the >> list archives so I apologize if this has already been discussed? >> >> I've been fighting the SPL binary growing too large on OMAP4 (using >> custom configs and features). It's annoying that too large just fails >> to run with no build or runtime notice. But that's a different issue. > > What version are you using? When SPL is too large a build-time failure > is expected. I've seen that happen in gross cases where it exceeds the 38K limit in omap4_common.h's CONFIG_SPL_MAX_SIZE but I currently have two configs that are both well below that size yet the larger one doesn't run. The larger MLO is 0x8a21 bytes (0x8c29 with the GP header) and _end is 0x4030cd74. This loops endlessly at 0x30080. I get no console output. Even if the additional code is buggy it's not called early enough to prevent at least the banner from going out so I'm pretty sure it's the ROM not even starting it. The smaller MLO is 0x757c bytes (0x7784 with the GP header) and _end is 0x4030b8cc. This runs OK. I am still exploring. > This is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303 which seems to > have gotten little attention after initial triage. I guess I need to > find a little time to show it's still there. Yes, I'd seen that. What I don't understand is why gcc doesn't just put such strings into different sections like it does with its own __func__ strings. Then it would all just work. I also don't get them implementing anonymous string merging while ignoring GC. Both are size optimizations and the one they don't seem to care about I'd expect to produce more savings. >> Is there a work around I haven't thought of? I'm thinking along the >> lines of disabling all printfs in SPL in the hope that will take the >> strings away (since many are some sort of debug / progress message). > > One option would be to add a "disable all output" option to SPL that > would get all of the strings dropped. I'm not sure how cleanly this can > be done, but I know it has been done. I have a pile of WIP to submit (a tiny one went today). I'm loath to do anything major that would be unlikely to be accepted upstream because of the work to keep it clean when I pull. I'm thinking about a config option for SPL that would define away all printf() and puts() calls. That would cover most of the low-hanging fruit. It's not a complete solution and would mean no console output in SPL but I'd think it could be done with a small source impact. Still noodling. > Another option would be to do some careful splitting and #ifdef'ery of > files so that we can just never link in the stuff with strings we don't > need. Yes, lacking a toolchain that has any vowels in it's tray I must agree. -Mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] Introducing SPDX-License-Identifiers
all, Quoting Marek Vasut : Dear Wolfgang Denk, Like many other projects, U-Boot has a tradition of including big blocks of License headers in all files. This not only blows up the source code with mostly redundant information, but also makes it very difficult to generate License Clearing Reports. An additional problem is that even the same lincenses are referred to by a number of slightly varying text blocks (full, abbreviated, different indentation, line wrapping and/or white space, with obsolete address information, ...) which makes automatic processing a nightmare. To make this easier, such license headers in the source files will be replaced with a single line reference to Unique Lincense Identifiers as defined by the Linux Foundation's SPDX project [1]. For example, in a source file the full "GPL v2.0 or later" header text will be replaced by a single line: I think we have a winner for this round of u-boot commit statistics ;-) For the MXS part and PXA part, series: Acked-by: Marek Vasut Wow this was a huge meal and I did the whole menu... Reviewed-by: Roger Meier Great to see such a resourceful approach to simplify the licensing topic. Thank you Wolfgang Denk for this effort! I have one question related to the following exception that was removed from COPYING file: --- a/COPYING +++ b/Licenses/gpl-2.0.txt - NOTE! This license does *not* cover the so-called "standalone" -applications that use U-Boot services by means of the jump table -provided by U-Boot exactly for this purpose - this is merely -considered normal use of U-Boot, and does *not* fall under the -heading of "derived work". Do you plan to add this info to the new Licenses/README file again or do you consider to create kind of a U-Boot-exception? thanks again and good night! -roger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] v2013.07 _not_ on Monday
On Fri, Jul 12, 2013 at 3:03 PM, Tom Rini wrote: > Hey all, > > Looking things over, right now: > - We've got one more bootm/related fixup posted today (I've confirmed it > works) > - The OMAP3 SPL issue (I need to confirm just how bad it is) > - The exynos4 clock issue > > Given the above, and that I'm build testing a rather large set of > changes right now, I'm _not_ going to do the next release on Monday. If > all of my local tests pass, I will tag -rc3 today. Thanks! Agreed; it is better to delay it and have a solid release than make a bugfix release short after it... :-) -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [ANN] v2013.07 _not_ on Monday
Hey all, Looking things over, right now: - We've got one more bootm/related fixup posted today (I've confirmed it works) - The OMAP3 SPL issue (I need to confirm just how bad it is) - The exynos4 clock issue Given the above, and that I'm build testing a rather large set of changes right now, I'm _not_ going to do the next release on Monday. If all of my local tests pass, I will tag -rc3 today. Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Fix memory stomper in DFU. Loop NULL-initted one past allocated array size.
From: Michael Cashwell The memory layout arranged itself such that a long-standing memory stomper in a DFU prepare callback used during USB registration mangled the malloc heap enough to cause my board to panic much later in a call to free(). Since it hadn't happened before but was repeatable I decided to investigate before it vanished again. The actual stomp happened in this line after the for loop: f_dfu->function[i] = NULL; git blame says this code was introduced here: b819ddbf (Lukasz Majewski 2012-08-06 14:41:06 +0200 587) I'm not sure if the function[] array actually needs a NULL entry at the end. If so then this patch is the right fix. If it really always knows the last array index and doesn't need the NULL then removing the offending assignment would be better. Not knowing makes this patch safer. Signed-off-by: Michael Cashwell --- drivers/usb/gadget/f_dfu.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/f_dfu.c b/drivers/usb/gadget/f_dfu.c index a322ae5..b24de09 100644 --- a/drivers/usb/gadget/f_dfu.c +++ b/drivers/usb/gadget/f_dfu.c @@ -589,7 +589,7 @@ static int dfu_prepare_function(struct f_dfu *f_dfu, int n) struct usb_interface_descriptor *d; int i = 0; - f_dfu->function = calloc(sizeof(struct usb_descriptor_header *), n); + f_dfu->function = calloc(sizeof(struct usb_descriptor_header *), n + 1); if (!f_dfu->function) goto enomem; -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] regression:Exynos4: Clock calculation fix
Hi Tom, I've checked out the origin/master HEAD: SHA1: 225fd8c5d4556547896a5d32ee092a258f3df638 It turns out that the Exynos4 Trats serial console output is broken because of APLL clock frequency change. Responsible change [*]: Exynos5: clock: Update the equation to calculate PLL output frequency SHA1: 234370cab4b2f096e095fe8f3284fd39740a4023 The above change is already at mainline (v2013.07-rc2) Minkyu has provided a correction patch [**]: [U-Boot] [PATCH] arm: exynos: fix clock calculation Unfortunately, this fixed the problem partially (and has been pulled by Albert already). I've just sent the fix for the Exynos4210 based boards [***]: http://patchwork.ozlabs.org/patch/258775/ [U-Boot] arm:exynos:fix: Fix clock calculation for Exynos4210 based targets. The solution was tested at Exynos4210 Trats board. I hope, that we will manage to fix things before final v2013.07 release. Clock change is crucial, and I'm afraid that Minkyu and Rajeshwari will read this mail on Monday. Can we wait for final release until then? For now, change [*] is at v2013.07, but fixes [**] and [***] aren't. I would opt for giving the interested party time to test all three patches together before we release the final v2013.07. -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [[PATCH v3 2/2] gpio: omap5-uevm: Configure the tca6424 gpio expander
NM
On 07/11/2013 01:02 PM, Nishanth Menon wrote:
>>> diff --git a/board/ti/omap5_uevm/mux_data.h
> b/board/ti/omap5_uevm/mux_data.h
index a82795d..7e6415e 100644
--- a/board/ti/omap5_uevm/mux_data.h
+++ b/board/ti/omap5_uevm/mux_data.h
@@ -56,6 +56,8 @@ const struct pad_conf_entry
> core_padconf_array_essential[] = {
{USBD0_HS_DP, (IEN | M0)},/* USBD0_HS_DP */
{USBD0_HS_DM, (IEN | M0)},/* USBD0_HS_DM */
{USBD0_SS_RX, (IEN | M0)},/* USBD0_SS_RX */
+{I2C5_SCL, (IEN | M0)}, /* I2C5_SCL */
>>> nit pick -> SCL (or i2c clk) is out put from master - always. IEN
> enables full duplex, but anyways.. just a nitpick :)
>> OK I changed this and did a test and reads fail without the IEN set.
>> This is to sync the client clocks.
> Scl? I2c clock? Does not work without input- something is fishy no?
Nope. There is clock synchronization and clock arbitration that happens and
the I2C master needs to see the SCL as an input.
Kernel configures the I2C mux for 1 and 5 the same way.
--
--
Dan Murphy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm:exynos:fix: Fix clock calculation for Exynos4210 based targets.
Provide proper setting for the APLL fout frequency calculation for
Exynos4 based targets (especially Exynos4210 - Trats board).
Signed-off-by: Lukasz Majewski
Cc: Minkyu Kang
---
arch/arm/cpu/armv7/exynos/clock.c |9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/clock.c
b/arch/arm/cpu/armv7/exynos/clock.c
index 9f07181..5a5cfa1 100644
--- a/arch/arm/cpu/armv7/exynos/clock.c
+++ b/arch/arm/cpu/armv7/exynos/clock.c
@@ -141,18 +141,17 @@ static int exynos_get_pll_clk(int pllreg, unsigned int r,
unsigned int k)
fout = (m + k / div) * (freq / (p * (1 << s)));
} else {
/*
-* Exynos4210
+* Exynos4412 / Exynos5250
* FOUT = MDIV * FIN / (PDIV * 2^SDIV)
*
-* Exynos4412 / Exynos5250
+* Exynos4210
* FOUT = MDIV * FIN / (PDIV * 2^(SDIV-1))
*/
if (proid_is_exynos4210())
- fout = m * (freq / (p * (1 << s)));
- else
fout = m * (freq / (p * (1 << (s - 1;
+ else
+ fout = m * (freq / (p * (1 << s)));
}
-
return fout;
}
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling
Hi Sughosh, On Fri, Jul 12, 2013 at 1:21 AM, Sughosh Ganu wrote: > hi, > > On Wed Jul 10, 2013 at 11:56:30PM -0700, Simon Glass wrote: > > > > > I have netbsd running on hawkboard, but i do not boot it using the > > > > bootm command, but use the go command instead. I will try to build a > > > > netbsd image with the u-boot header and give it a try with bootm. > Need > > > > a day or two to check this out though. > > > > > > > > > > Tried to boot netbsd with u-boot head 225fd8c5d45, and the boot fails. > Was > > > able to boot netbsd with v2012.10 u-boot image. Btw, am i supposed to > > apply > > > any patch on top of the said commit. > > > > Yes please see the four commits I sent earlier today. > > Tried after applying the series from Simon, and now the netbsd image > boots fine with the bootm command. > Thanks very much for testing this. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
Hi Hector, [...] > > Try Stefano's tree as Fabio suggested. I think it's already pushed and > > includes the fixes. > > I just tried, but it didn't help. OK, then it's something else. > >> Considering the other guys seem to work without problems I guess this > >> scenario is specific to my board. I'm using a Micrel KSZ8031RNLI at > >> 50MHz. I always suspect from the PHY. > > > > You can try using the PHYLIB (CONFIG_PHYLIB and CONFIG_PHY_SMSC as in > > sc_sps_1.h ) . Also, can you check which of the two "ret = -EINVAL" is > > triggered in fec_send() ? You can add simple printf() alongside both of > > them. > > fec_send() *does not* ever fail OK, it might be something else entirely. Let's take a look ... > but I found something: > It is very strange that the timeouts appear always after transferring > between 20 and 24 MiB. So I thought maybe it was not an issue with the > size of the file or the number of packets received, but instead a timed > issue (an issue that happens after some period of time). I checked, and in > fact the timeouts occur exactly 10 seconds after running the tftp command. > I verified that this is what is happening by adding a udelay(10) at > fec_send(). In this case, the timeout also occurs after 10 seconds, but > due to the delay, I have transferred only a few Kbytes. Holy moly! > I tried to change different timeout related constants at tftp.c but still > the issue happens after 10s. > It's like if, after these 10 seconds, the PHY lost the link or something. > Really odd. Does it tell you anything? LAN8720 phy, right? Try implementing something like [1], by clearing the EDPWRDOWN bit , the PHY will never enter low-power mode. It's just a simple PHY register RMW which you can stick somewhere into the PHY net/phy/smsc.c code. [1] https://kernel.googlesource.com/pub/scm/linux/kernel/git/djbw/dmaengine/+/b629820d18fa65cc598390e4b9712fd5f83ee693%5E!/#F0 Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
Hi Hector, On Fri, 12 Jul 2013 17:08:59 +0200, Hector Palacios wrote: > Hi Marek, > > On 07/12/2013 02:01 PM, Marek Vasut wrote: > > Hi Hector, > > > >> Dear Marek, > >> > >> On 07/12/2013 05:51 AM, Marek Vasut wrote: > >>> Hi, > >>> > On Thu, Jul 11, 2013 at 8:18 PM, Fabio Estevam > wrote: > > On Thu, Jul 11, 2013 at 8:03 PM, Marek Vasut wrote: > >> The MX28 multi-layer AHB bus can be too slow and trigger the > >> FEC DMA too early, before all the data hit the DRAM. This patch > >> ensures the data are written in the RAM before the DMA starts. > >> Please see the comment in the patch for full details. > >> > >> This patch was produced with an amazing help from Albert Aribaud, > >> who pointed out it can possibly be such a bus synchronisation > >> issue. > >> > >> Signed-off-by: Marek Vasut > >> Cc: Albert ARIBAUD > >> Cc: Fabio Estevam > >> Cc: Stefano Babic > > > > Excellent, managed to transfer 90MB via TFTP on mx28evk without a > > single timeout. > > > > Tested-by: Fabio Estevam > > It's working here too. > > Tested-by: Alexandre Pereira da Silva > >>> > >>> Nice to hear, thank Albert for finding this. > >> > >> Thanks for sharing. > >> > >> Unfortunately I'm still seeing non-recoverable timeouts when doing tftp > >> transfers. Nevertheless, with this patch sometimes I'm able to transfer > >> big files (100MiB) without problems (I was never able before). So this is > >> a big improvement. I applied this patch over a v2013.01, does it need any > >> additional patch? I think I saw one email about flush dcache... > > > > Try Stefano's tree as Fabio suggested. I think it's already pushed and > > includes > > the fixes. > > I just tried, but it didn't help. > > >> Considering the other guys seem to work without problems I guess this > >> scenario is specific to my board. I'm using a Micrel KSZ8031RNLI at 50MHz. > >> I always suspect from the PHY. > > > > You can try using the PHYLIB (CONFIG_PHYLIB and CONFIG_PHY_SMSC as in > > sc_sps_1.h > > ) . Also, can you check which of the two "ret = -EINVAL" is triggered in > > fec_send() ? You can add simple printf() alongside both of them. > > fec_send() *does not* ever fail, but I found something: > It is very strange that the timeouts appear always after transferring between > 20 and > 24 MiB. So I thought maybe it was not an issue with the size of the file or > the number > of packets received, but instead a timed issue (an issue that happens after > some > period of time). I checked, and in fact the timeouts occur exactly 10 seconds > after > running the tftp command. > I verified that this is what is happening by adding a udelay(10) at > fec_send(). In > this case, the timeout also occurs after 10 seconds, but due to the delay, I > have > transferred only a few Kbytes. > I tried to change different timeout related constants at tftp.c but still the > issue > happens after 10s. > It's like if, after these 10 seconds, the PHY lost the link or something. > Really odd. > Does it tell you anything? Well, such a round number makes me think of an application-layer time-out. Do you have control over how your TFTP server is configured? > Best regards, > -- > Hector Palacios Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
Hi Marek, On 07/12/2013 02:01 PM, Marek Vasut wrote: Hi Hector, Dear Marek, On 07/12/2013 05:51 AM, Marek Vasut wrote: Hi, On Thu, Jul 11, 2013 at 8:18 PM, Fabio Estevam wrote: On Thu, Jul 11, 2013 at 8:03 PM, Marek Vasut wrote: The MX28 multi-layer AHB bus can be too slow and trigger the FEC DMA too early, before all the data hit the DRAM. This patch ensures the data are written in the RAM before the DMA starts. Please see the comment in the patch for full details. This patch was produced with an amazing help from Albert Aribaud, who pointed out it can possibly be such a bus synchronisation issue. Signed-off-by: Marek Vasut Cc: Albert ARIBAUD Cc: Fabio Estevam Cc: Stefano Babic Excellent, managed to transfer 90MB via TFTP on mx28evk without a single timeout. Tested-by: Fabio Estevam It's working here too. Tested-by: Alexandre Pereira da Silva Nice to hear, thank Albert for finding this. Thanks for sharing. Unfortunately I'm still seeing non-recoverable timeouts when doing tftp transfers. Nevertheless, with this patch sometimes I'm able to transfer big files (100MiB) without problems (I was never able before). So this is a big improvement. I applied this patch over a v2013.01, does it need any additional patch? I think I saw one email about flush dcache... Try Stefano's tree as Fabio suggested. I think it's already pushed and includes the fixes. I just tried, but it didn't help. Considering the other guys seem to work without problems I guess this scenario is specific to my board. I'm using a Micrel KSZ8031RNLI at 50MHz. I always suspect from the PHY. You can try using the PHYLIB (CONFIG_PHYLIB and CONFIG_PHY_SMSC as in sc_sps_1.h ) . Also, can you check which of the two "ret = -EINVAL" is triggered in fec_send() ? You can add simple printf() alongside both of them. fec_send() *does not* ever fail, but I found something: It is very strange that the timeouts appear always after transferring between 20 and 24 MiB. So I thought maybe it was not an issue with the size of the file or the number of packets received, but instead a timed issue (an issue that happens after some period of time). I checked, and in fact the timeouts occur exactly 10 seconds after running the tftp command. I verified that this is what is happening by adding a udelay(10) at fec_send(). In this case, the timeout also occurs after 10 seconds, but due to the delay, I have transferred only a few Kbytes. I tried to change different timeout related constants at tftp.c but still the issue happens after 10s. It's like if, after these 10 seconds, the PHY lost the link or something. Really odd. Does it tell you anything? Best regards, -- Hector Palacios ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 0/6] omap3_beagle: configs: improve BOOT_CMD options
On Thu, Jul 11, 2013 at 05:33:19PM -0500, Nishanth Menon wrote: > With the latest transition to device tree, there is a need to simplify > the load of device tree depending on board type etc. While at it, simplify > few other changes as well. > > Testing: > with a uEnv.txt as: > bootdir=/ > bootpart=0:1 > > The following were the boot results: > Beagle (rev C1D): http://pastebin.com/fMdsKkgr > Beagle XM (rev C1): http://pastebin.com/p1zp9AhG > > > Changes in V2 since v1: > - removed xMB version support based on review comments. > http://marc.info/?t=13735797054&r=1&w=2&n=5 > > V1: http://marc.info/?l=u-boot&m=137357963227510&w=2 I have no new comments on the series, awaiting V3 Monday'ish, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] omap3_beagle: support findfdt and loadfdt for devicetree support
On 08:32-20130712, Robert Nelson wrote:
> On Thu, Jul 11, 2013 at 11:06 PM, Nishanth Menon wrote:
> > ok, here is how the code looks like with the V2 of my series:
> >
> > Do we just default to none for XM_AB for dvi_pup?
> >
> > static void beagle_dvi_pup(void)
> > {
> > uchar val;
> >
> > switch (get_board_revision()) {
> > case REVISION_AXBX:
> > case REVISION_CX:
> > case REVISION_C4:
> > case REVISION_XM_AB:
> > gpio_request(170, "");
> > gpio_direction_output(170, 0);
> > gpio_set_value(170, 1);
> > break;
> > case REVISION_XM_C:
> > default:
> > #define GPIODATADIR1 (TWL4030_BASEADD_GPIO+3)
> > #define GPIODATAOUT1 (TWL4030_BASEADD_GPIO+6)
> >
> > i2c_read(TWL4030_CHIP_GPIO, GPIODATADIR1, 1, &val, 1);
> > val |= 4;
> > i2c_write(TWL4030_CHIP_GPIO, GPIODATADIR1, 1, &val, 1);
> >
> > i2c_read(TWL4030_CHIP_GPIO, GPIODATAOUT1, 1, &val, 1);
> > val |= 4;
> > i2c_write(TWL4030_CHIP_GPIO, GPIODATAOUT1, 1, &val, 1);
> > break;
> > }
> > }
>
> I'd do it like this, as...
>
> On the xMA, xMA1, & xMA2: TPS_GPIO2 is not connected to anything...
> xMA3->xMC: TPS_GPIO2 is connected to dvi_pup
>
> static void beagle_dvi_pup(void)
> {
> uchar val;
>
> switch (get_board_revision()) {
> case REVISION_AXBX:
> case REVISION_CX:
> case REVISION_C4:
> gpio_request(170, "");
> gpio_direction_output(170, 0);
> gpio_set_value(170, 1);
> break;
> case REVISION_XM_AB:
> case REVISION_XM_C:
> default:
> #define GPIODATADIR1 (TWL4030_BASEADD_GPIO+3)
> #define GPIODATAOUT1 (TWL4030_BASEADD_GPIO+6)
>
> i2c_read(TWL4030_CHIP_GPIO, GPIODATADIR1, 1, &val, 1);
> val |= 4;
> i2c_write(TWL4030_CHIP_GPIO, GPIODATADIR1, 1, &val, 1);
>
> i2c_read(TWL4030_CHIP_GPIO, GPIODATAOUT1, 1, &val, 1);
> val |= 4;
> i2c_write(TWL4030_CHIP_GPIO, GPIODATAOUT1, 1, &val, 1);
> break;
> }
> }
Thanks for the review. sounds good. I will update
http://patchwork.ozlabs.org/patch/258634/ accordingly for a rev3.
Will wait till Monday before posting a new series to accommodate any
further comments.
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] omap3_beagle: support findfdt and loadfdt for devicetree support
On Thu, Jul 11, 2013 at 11:06 PM, Nishanth Menon wrote:
> On 18:17-20130711, Robert Nelson wrote:
>> On Thu, Jul 11, 2013 at 5:17 PM, Nishanth Menon wrote:
>> > On 17:05-20130711, Robert Nelson wrote:
>> >> On Thu, Jul 11, 2013 at 5:03 PM, Nishanth Menon wrote:
>> >> > On 17:02-20130711, Robert Nelson wrote:
>> >> >> On Thu, Jul 11, 2013 at 4:52 PM, Nishanth Menon wrote:
>> >> >> > For folks not using concatenated device tree with uImage, having
>> >> >> > an handy function to find and load device tree is very handy.
>> >> >> >
>> >> >> > So introduce findfdt and loadfdt and run findfdt by default to make
>> >> >> > it easier on user scripts.
>> >> >> >
>> >> >> > Signed-off-by: Nishanth Menon
>> >> >> > ---
>> >> >> > include/configs/omap3_beagle.h | 17 +
>> >> >> > 1 file changed, 17 insertions(+)
>> >> >> >
>> >> >> > diff --git a/include/configs/omap3_beagle.h
>> >> >> > b/include/configs/omap3_beagle.h
>> >> >> > index bdeee17..7833208 100644
>> >> >> > --- a/include/configs/omap3_beagle.h
>> >> >> > +++ b/include/configs/omap3_beagle.h
>> >> >> > @@ -210,6 +210,8 @@
>> >> >> > #define CONFIG_EXTRA_ENV_SETTINGS \
>> >> >> > "loadaddr=0x8020\0" \
>> >> >> > "rdaddr=0x8100\0" \
>> >> >> > + "fdt_high=0x\0" \
>> >> >> > + "fdtaddr=0x80f8\0" \
>> >> >> > "usbtty=cdc_acm\0" \
>> >> >> > "bootfile=uImage\0" \
>> >> >> > "ramdisk=ramdisk.gz\0" \
>> >> >> > @@ -250,6 +252,19 @@
>> >> >> > "omapdss.def_disp=${defaultdisplay} " \
>> >> >> > "root=${nandroot} " \
>> >> >> > "rootfstype=${nandrootfstype}\0" \
>> >> >> > + "findfdt=" \
>> >> >> > + "if test $beaglerev = AxBx; then " \
>> >> >> > + "setenv fdtfile omap3-beagle.dtb; fi; " \
>> >> >> > + "if test $beaglerev = Cx; then " \
>> >> >> > + "setenv fdtfile omap3-beagle.dtb; fi; " \
>> >> >> > + "if test $beaglerev = xMA; then " \
>> >> >> > + "setenv fdtfile omap3-beagle-xm.dtb; fi; " \
>> >> >> > + "if test $beaglerev = xMB; then " \
>> >> >> > + "setenv fdtfile omap3-beagle-xm.dtb; fi; " \
>> >> >>
>> >> >> There is no need for the "xMB" variant, as the gpio pins used for
>> >> >> identification where never changed from the xMA when the newer silcon
>> >> >> was used for the xMB (i guess if we look at the omap's es revision, we
>> >> >> could figure out which are xMB's, but right now that isn't done in
>> >> >> u-boot)
>> >> > I suppose then the following is ok to do as well?
>> >> > diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
>> >> > index c686f40..6094b0f 100644
>> >> > --- a/board/ti/beagle/beagle.c
>> >> > +++ b/board/ti/beagle/beagle.c
>> >> > @@ -369,16 +369,6 @@ int misc_init_r(void)
>> >> >
>> >> > TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
>> >> > TWL4030_PM_RECEIVER_DEV_GRP_P1);
>> >> > break;
>> >> > - case REVISION_XM_B:
>> >> > - printf("Beagle xM Rev B\n");
>> >> > - setenv("beaglerev", "xMB");
>> >> > - MUX_BEAGLE_XM();
>> >> > - /* Set VAUX2 to 1.8V for EHCI PHY */
>> >> > -
>> >> > twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VAUX2_DEDICATED,
>> >> > -
>> >> > TWL4030_PM_RECEIVER_VAUX2_VSEL_18,
>> >> > -
>> >> > TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
>> >> > - TWL4030_PM_RECEIVER_DEV_GRP_P1);
>> >> > - break;
>> >> > case REVISION_XM_C:
>> >> > printf("Beagle xM Rev C\n");
>> >> > setenv("beaglerev", "xMC");
>> >>
>> >> Correct, as a cleanup we can nuke that xMB section..
>> >>
>> >> For some bike shed paining we could rename:
>> >>
>> >> Beagle xM Rev A -> Beagle xM Rev A/B
>> >>
>> >> Above that too. ;)
>> > OK - I suspect and am not sure how dvi_pup will get handled in the
>> > resultant diff, What do folks think of the following?
>>
>> A quick review of all my old xM schematics i have access to and the
>> ones on https://github.com/CircuitCo/
>>
>> For the "dvi_pup" function
>>
>> GPIO_170 was only used on the pre-production xM's P8/P9, i doubt any
>> of them still operate (mine died)..
>>
>> It was then switched to GPIO_129 for the xMA, however there where MMC
>> issues, so it was changed for xMA1 (and thus xMA2)
>> notes, top of this:
>> https://github.com/CircuitCo/BeagleBoard-xM-RevC/blob/master/BeagleBoard-xM_revC_SCH.pdf
>>
>> TPS_GPIO_2: was then used on xMA3 -> and all later generations...
>>
>> So also looking at:
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-omap2/board-omap3beagle.c#n161
>>
>> Looks like the original beagle needs GPIO_170..
>>
Re: [U-Boot] [PATCH V2] mtd: mxc_nand: Fix crash after MTD resync
Hi,
Tom/Stefano, can you pick this for .07? Otherwise all mxc with NAND are broken.
Thanks
> The driver triggered a BUG() in nand_base.c:3214/nand_scan_tail()
> because the ecc.strength was not set in NAND_ECC_HW_SYNDROME ECC
> mode.
>
> Signed-off-by: Marek Vasut
> Cc: Benoit Thebaudeau
> Cc: Fabio Estevam
> Cc: Scott Wood
> Cc: Stefano Babic
> ---
> drivers/mtd/nand/mxc_nand.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> V2: Set ecc.strength for both NAND_ECC_HW and NAND_ECC_HW_SYNDROME mode
>
> diff --git a/drivers/mtd/nand/mxc_nand.c b/drivers/mtd/nand/mxc_nand.c
> index ac435f2..40b0741 100644
> --- a/drivers/mtd/nand/mxc_nand.c
> +++ b/drivers/mtd/nand/mxc_nand.c
> @@ -1242,12 +1242,10 @@ int board_nand_init(struct nand_chip *this)
> this->ecc.mode = NAND_ECC_HW;
> }
>
> - if (this->ecc.mode == NAND_ECC_HW) {
> - if (is_mxc_nfc_1())
> - this->ecc.strength = 1;
> - else
> - this->ecc.strength = 4;
> - }
> + if (is_mxc_nfc_1())
> + this->ecc.strength = 1;
> + else
> + this->ecc.strength = 4;
>
> host->pagesize_2k = 0;
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: fix FIT image with ramdisk
Hi Stefano, On Fri, 12 Jul 2013 15:09:23 +0200, Stefano Babic wrote: > Booting a FIT image containing a ramdisk, > the ramdisk is loaded at address 0x0 that causes > bus errors for architectures that do not have > RAM starting at address zero. Kind-of-minor nitpick: ARMs which have RAM at address 0 might well have their exception tables there too (and will if they don't right now), which makes it always bad to to load anything there anyway. Properly major nitpick: the commit message explains what needed fixing, but neither the commit message nor the code (to an admittedly completely unFIT reader) explain *how* exactly it was fixed. > Signed-off-by: Stefano Babic > > --- > common/image.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/common/image.c b/common/image.c > index 1be384f..08f712a 100644 > --- a/common/image.c > +++ b/common/image.c > @@ -910,7 +910,7 @@ int boot_get_ramdisk(int argc, char * const argv[], > bootm_headers_t *images, > fit_uname_config, arch, > IH_TYPE_RAMDISK, > BOOTSTAGE_ID_FIT_RD_START, > - FIT_LOAD_REQUIRED, &rd_data, &rd_len); > + FIT_LOAD_IGNORED, &rd_data, &rd_len); > if (rd_noffset < 0) > return 1; > Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] tools: fix FIT image with ramdisk
Booting a FIT image containing a ramdisk, the ramdisk is loaded at address 0x0 that causes bus errors for architectures that do not have RAM starting at address zero. Signed-off-by: Stefano Babic --- common/image.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/image.c b/common/image.c index 1be384f..08f712a 100644 --- a/common/image.c +++ b/common/image.c @@ -910,7 +910,7 @@ int boot_get_ramdisk(int argc, char * const argv[], bootm_headers_t *images, fit_uname_config, arch, IH_TYPE_RAMDISK, BOOTSTAGE_ID_FIT_RD_START, - FIT_LOAD_REQUIRED, &rd_data, &rd_len); + FIT_LOAD_IGNORED, &rd_data, &rd_len); if (rd_noffset < 0) return 1; -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] UPDATED: pull request: u-boot-arm/master
Hello Tom, Update to my previous PR, to include the last Tegra and IMX PRs: The following changes since commit fbf87b1823dd5ebc2a384711ea2c677543019ece: arm: optimize relocate_code routine (2013-06-21 23:05:50 +0200) are available in the git repository at: git://git.denx.de/u-boot-arm master for you to fetch changes up to efc284e32503b240dbd35c6e8b8d098d702b4be7: Merge branch 'u-boot-imx/master' into 'u-boot-arm/master' (2013-07-12 13:20:35 +0200) Ajay Kumar (1): video: exynos_fb: Add the missing #else clause Albert ARIBAUD (3): Merge branch 'u-boot-imx/master' into 'u-boot-arm/master' Merge branch 'u-boot-samsung/master' into 'u-boot-arm/master' Merge branch 'u-boot-imx/master' into 'u-boot-arm/master' Amar (2): EXYNOS5: I2C: Add FDT and non-FDT support for I2C EXYNOS: Resolve the i2c compilation error Axel Lin (3): gpio: s3c2440_gpio: Fix wrong writel arguments gpio: s5p_gpio: Call s5p_gpio_set_value() instead of open-code ARM: OMAP: GPIO: Fix valid range and enable usage of all GPIOs on OMAP5 Bernie Thompson (1): exynos: Adjust the starting MIF voltage to 1.05v Dirk Behme (2): spi: mxc_spi: Fix pre and post divider calculation spi: mxc_spi: Update pre and post divider algorithm Eric Nelson (1): dwc_ahsata: Allow use with dcache enabled Fabio Estevam (8): README: mx28_common: Keep the text within 80 columns README: mx28_common: Do not hardcode the SSP port README: mx28_common: Fix structure of sentence README: mxs: Introduce README.mxs mx28evk: Move README file inside board directory m28evk: Move README file inside board directory MAINTAINERS: Add an entry to the mx6q wandboard variant video: mxsfb: Break the line in videomode message Ilya Ledvich (1): am33xx: fix the ddr_cmdtctrl structure Jim Lin (3): ARM: Tegra: FDT: Add USB EHCI function for T30/T114 ARM: Tegra: USB: EHCI: Add support for Tegra30/Tegra114 Tegra: Config: Enable Tegra30/Tegra114 USB function Lokesh Vutla (1): ARM: OMAP4+: Fix MA detection during SDRAM_AUTO_DETECTION Marek Vasut (3): m28evk: add trimffs to nand command net: fec: Remove bogus flush_dcache_range() call net: fec: Avoid MX28 bus sync issue Michael Trimarchi (1): usb: omap: ulpi: fix ulpi transceiver access Mike Dunn (5): pxa: add support for palmtreo680 board pxa: palmtreo680 flash programming utility pxa: turn icache off in cpu_init_crit() pxa: use -mcpu=xscale compiler option pxa: fix memory coherency problem after relocation Minkyu Kang (1): arm: exynos: fix clock calculation Otavio Salvador (8): vf610twr: Add default environment in line with other Freescale boards vf610twr: Remove SoC name from U-Boot prompt mx53loco: Change default environment to cope with OE changes mx6qsabrelite: Change default environment to cope with OE changes mx6slevk: Change default environment to cope with OE changes wandboard: Change default environment to cope with OE changes mx51evk: Change default environment to cope with OE changes mx53ard: Change default environment to cope with OE changes Pierre Aubert (3): imx6: fix GPR2 wrong definition imx: Complete the pin definitions for the i.MX6DL / i.MX6Solo imx: Add support for the SabreSD shipped with i.MX6DL Rajeshwari Shinde (9): EXYNOS5: FDT: Add compatible strings for Serial EXYNOS5: FDT: Add serial device node values S5P: Serial: Add fdt support to driver CONFIG: EXYNOS5: Enable silent console SMDK5250: Remove reduntant code EXYNOS: Add API for power reset and exit wakeup EXYNOS: LDS file move to common EXYNOS4210: Configure GPIO for uart EXYNOS: Move files from board/samsung to arch/arm Robert Winkler (4): imx: nitrogen6x: Enabled data cache imx: nitrogen6x: Enable bootz imx: nitrogen6x: Enable raw initrd imx: nitrogen6x: Enable filesystem generic commands Simon Glass (1): exynos: Enable mmc for snow Stephen Warren (2): ARM: tegra: enable LCD panel on Harmony ARM: tegra: enable LCD panel on Ventana Tapani Utriainen (1): Add support for Wandboard Quad trem (2): mx27: add function enable_caches mx27: add i2c clock Łukasz Majewski (2): arm:trats: Increase malloc pool size (for DFU ext4 transfers) power:bat:trats: Break battery charging with ctrl+C CREDITS|4 + MAINTAINERS|7 +- arch/arm/cpu/arm926ejs/mx27/generic.c | 10 + arch/arm/cpu/armv7/exynos/Makefile | 17 +- arch/arm/cpu/armv7/exynos/clock.c | 43 +- .../arm/cpu/armv7/exynos}/clock_init.h |0 arch/arm/cpu/armv7/exynos/clock_ini
Re: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
Hi Hector, > Dear Marek, > > On 07/12/2013 05:51 AM, Marek Vasut wrote: > > Hi, > > > >> On Thu, Jul 11, 2013 at 8:18 PM, Fabio Estevam wrote: > >>> On Thu, Jul 11, 2013 at 8:03 PM, Marek Vasut wrote: > The MX28 multi-layer AHB bus can be too slow and trigger the > FEC DMA too early, before all the data hit the DRAM. This patch > ensures the data are written in the RAM before the DMA starts. > Please see the comment in the patch for full details. > > This patch was produced with an amazing help from Albert Aribaud, > who pointed out it can possibly be such a bus synchronisation > issue. > > Signed-off-by: Marek Vasut > Cc: Albert ARIBAUD > Cc: Fabio Estevam > Cc: Stefano Babic > >>> > >>> Excellent, managed to transfer 90MB via TFTP on mx28evk without a > >>> single timeout. > >>> > >>> Tested-by: Fabio Estevam > >> > >> It's working here too. > >> > >> Tested-by: Alexandre Pereira da Silva > > > > Nice to hear, thank Albert for finding this. > > Thanks for sharing. > > Unfortunately I'm still seeing non-recoverable timeouts when doing tftp > transfers. Nevertheless, with this patch sometimes I'm able to transfer > big files (100MiB) without problems (I was never able before). So this is > a big improvement. I applied this patch over a v2013.01, does it need any > additional patch? I think I saw one email about flush dcache... Try Stefano's tree as Fabio suggested. I think it's already pushed and includes the fixes. > Considering the other guys seem to work without problems I guess this > scenario is specific to my board. I'm using a Micrel KSZ8031RNLI at 50MHz. > I always suspect from the PHY. You can try using the PHYLIB (CONFIG_PHYLIB and CONFIG_PHY_SMSC as in sc_sps_1.h ) . Also, can you check which of the two "ret = -EINVAL" is triggered in fec_send() ? You can add simple printf() alongside both of them. > I'm disconcerted because usually the timeouts occur after having > successfully downloaded 22 or 24 MiB. Other times it just downloads > completely. > > In any case, good job! > > Best regards, > -- > Hector Palacios Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
Hi Albert, > Afterthought: > > On Fri, 12 Jul 2013 07:57:18 +0200, Albert ARIBAUD > > wrote: > > except it tends to minimize Marek's own contribution to the fix, which > > is by far the most important. > > 'The most important' 'by far' being of course Marek's contribution, not > minimizing it. :) I'm convinced I owe you a truckload of tartelette ;-) Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] : Updated: Please pull u-boot-imx
Hi Stefano, On Fri, 12 Jul 2013 13:10:34 +0200, Stefano Babic wrote: > Hi Albert, > > some more small fixes, sorry. Please pull from u-boot-imx, thanks. > > The following changes since commit d6c6d127c5b948ec381fad5b24a2bc5497720644: > > vf610twr: Remove SoC name from U-Boot prompt (2013-06-28 16:59:08 +0200) > > are available in the git repository at: > > git://www.denx.de/git/u-boot-imx.git master > > for you to fetch changes up to a3f170cdbf7ae0bd24c94c2f46725699bbd69f05: > > mx53ard: Change default environment to cope with OE changes > (2013-07-12 13:05:42 +0200) > > > Marek Vasut (3): > m28evk: add trimffs to nand command > net: fec: Remove bogus flush_dcache_range() call > net: fec: Avoid MX28 bus sync issue > > Otavio Salvador (6): > mx53loco: Change default environment to cope with OE changes > mx6qsabrelite: Change default environment to cope with OE changes > mx6slevk: Change default environment to cope with OE changes > wandboard: Change default environment to cope with OE changes > mx51evk: Change default environment to cope with OE changes > mx53ard: Change default environment to cope with OE changes > > drivers/net/fec_mxc.c | 23 ++- > include/configs/m28evk.h|1 + > include/configs/mx51evk.h |4 ++-- > include/configs/mx53ard.h |4 ++-- > include/configs/mx53loco.h |4 ++-- > include/configs/mx6qsabrelite.h |4 ++-- > include/configs/mx6slevk.h |4 ++-- > include/configs/wandboard.h |4 ++-- > 8 files changed, 35 insertions(+), 13 deletions(-) > > Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] README.mx28_common: Rename it to README.mxs
Dear Fabio Estevam,
> From: Fabio Estevam
>
> commit 54965b61360 (README: mxs: Introduce README.mxs) should have changed
> the file name to README.mxs, as it covers both mx23 and mx28 now.
>
> Signed-off-by: Fabio Estevam
> ---
> doc/{README.mx28_common => README.mxs} | 0
> 1 file changed, 0 insertions(+), 0 deletions(-)
> rename doc/{README.mx28_common => README.mxs} (100%)
>
> diff --git a/doc/README.mx28_common b/doc/README.mxs
> similarity index 100%
> rename from doc/README.mx28_common
> rename to doc/README.mxs
Acked-by: Marek Vasut
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx28evk: Convert to phylib framework
Dear Alexandre Pereira da Silva, > On Fri, Jul 12, 2013 at 1:58 AM, Marek Vasut wrote: > > Dear Fabio Estevam, > > > >> On Fri, Jul 12, 2013 at 1:40 AM, Marek Vasut wrote: > >> > Dear Fabio Estevam, > >> > > >> >> From: Fabio Estevam > >> >> > >> >> mx28evk has a LAN8270 ethernet phy and we can use the phylib > >> >> framework. > >> >> > >> >> One of the advantages of converting to phylib is that we no longer > >> >> see a timeout prior to the first transfer in the 'tftp' command. > >> >> > >> >> Signed-off-by: Fabio Estevam > >> >> --- > >> >> After applying this patch I get: > >> >> > >> >> U-Boot 2013.04-11810-gd6d75ec-dirty (Jul 12 2013 - 01:15:03) > >> >> > >> >> CPU: Freescale i.MX28 rev1.2 at 454 MHz > >> >> BOOT: SSP SD/MMC #0, 3V3 > >> >> DRAM: 128 MiB > >> >> MMC: MXS MMC: 0 > >> >> Video: MXSFB: 'videomode' variable not set! > >> >> In:serial > >> >> Out: serial > >> >> Err: serial > >> >> Net: Phy not found > >> >> > >> >> I still get this 'Phy not found' message, but I think this is not > >> >> related to the board code. > >> > > >> > This is because PHYlib doesn't know your PHY. You might need to add a > >> > definition for it into drivers/net/phy/smsc.c > >> > >> mx28evk uses a LAN8270. > >> > >> drivers/net/phy/smsc.c has an entry for "SMSC LAN8710/LAN8720", so not > >> sure why it fails to recognize it. > >> I haven't debugged it yet. > >> > >> Which phy does sc_sps_1.h use? Is it also a 8720? Is the phy recognized > >> on boot? > > > > I think it's 8720 , but it's recognised , yes. Are you sure the PHY > > addresses are correct ? You can dig into phylib a bit and see what IDs > > does it report. > > I think Fabio needs to define CONFIG_PHY_SMSC and use PHY address 3. He already did and the LAN8720 can use either phy addr 0x00 or 0x01, so that seem ok as well. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
Dear Marek, On 07/12/2013 05:51 AM, Marek Vasut wrote: Hi, On Thu, Jul 11, 2013 at 8:18 PM, Fabio Estevam wrote: On Thu, Jul 11, 2013 at 8:03 PM, Marek Vasut wrote: The MX28 multi-layer AHB bus can be too slow and trigger the FEC DMA too early, before all the data hit the DRAM. This patch ensures the data are written in the RAM before the DMA starts. Please see the comment in the patch for full details. This patch was produced with an amazing help from Albert Aribaud, who pointed out it can possibly be such a bus synchronisation issue. Signed-off-by: Marek Vasut Cc: Albert ARIBAUD Cc: Fabio Estevam Cc: Stefano Babic Excellent, managed to transfer 90MB via TFTP on mx28evk without a single timeout. Tested-by: Fabio Estevam It's working here too. Tested-by: Alexandre Pereira da Silva Nice to hear, thank Albert for finding this. Thanks for sharing. Unfortunately I'm still seeing non-recoverable timeouts when doing tftp transfers. Nevertheless, with this patch sometimes I'm able to transfer big files (100MiB) without problems (I was never able before). So this is a big improvement. I applied this patch over a v2013.01, does it need any additional patch? I think I saw one email about flush dcache... Considering the other guys seem to work without problems I guess this scenario is specific to my board. I'm using a Micrel KSZ8031RNLI at 50MHz. I always suspect from the PHY. I'm disconcerted because usually the timeouts occur after having successfully downloaded 22 or 24 MiB. Other times it just downloads completely. In any case, good job! Best regards, -- Hector Palacios ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
Hi Hector, On Fri, Jul 12, 2013 at 8:37 AM, Hector Palacios wrote: > Thanks for sharing. > > Unfortunately I'm still seeing non-recoverable timeouts when doing tftp > transfers. > Nevertheless, with this patch sometimes I'm able to transfer big files > (100MiB) without problems (I was never able before). So this is a big > improvement. > I applied this patch over a v2013.01, does it need any additional patch? I > think I saw one email about flush dcache... Please try Stefano's tree instead: http://git.denx.de/?p=u-boot/u-boot-imx.git;a=shortlog;h=refs/heads/master Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] README.mx28_common: Rename it to README.mxs
From: Fabio Estevam
commit 54965b61360 (README: mxs: Introduce README.mxs) should have changed the
file name to README.mxs, as it covers both mx23 and mx28 now.
Signed-off-by: Fabio Estevam
---
doc/{README.mx28_common => README.mxs} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename doc/{README.mx28_common => README.mxs} (100%)
diff --git a/doc/README.mx28_common b/doc/README.mxs
similarity index 100%
rename from doc/README.mx28_common
rename to doc/README.mxs
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/6] am335x_evm: Make NAND support modular
Am 2013-07-11 15:54, schrieb Justin Waters: > Give the user the ability to disable NAND support by defining > CONFIG_NO_NAND. This will allow custom hardware to easily support > this configuration. If NAND is not enabled, we could also ifdef the SPI/MTD/CMD_FS configurations since they are not used on BeagleBone Black either. Maybe something for a follow-up patch rather than a new version of this patchset. -- Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] : Updated: Please pull u-boot-imx
Hi Stefano, On Fri, 12 Jul 2013 13:10:34 +0200, Stefano Babic wrote: > Hi Albert, > > some more small fixes, sorry. Please pull from u-boot-imx, thanks. Ok -- restarting build tests on new head. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] : Updated: Please pull u-boot-imx
Hi Albert, some more small fixes, sorry. Please pull from u-boot-imx, thanks. The following changes since commit d6c6d127c5b948ec381fad5b24a2bc5497720644: vf610twr: Remove SoC name from U-Boot prompt (2013-06-28 16:59:08 +0200) are available in the git repository at: git://www.denx.de/git/u-boot-imx.git master for you to fetch changes up to a3f170cdbf7ae0bd24c94c2f46725699bbd69f05: mx53ard: Change default environment to cope with OE changes (2013-07-12 13:05:42 +0200) Marek Vasut (3): m28evk: add trimffs to nand command net: fec: Remove bogus flush_dcache_range() call net: fec: Avoid MX28 bus sync issue Otavio Salvador (6): mx53loco: Change default environment to cope with OE changes mx6qsabrelite: Change default environment to cope with OE changes mx6slevk: Change default environment to cope with OE changes wandboard: Change default environment to cope with OE changes mx51evk: Change default environment to cope with OE changes mx53ard: Change default environment to cope with OE changes drivers/net/fec_mxc.c | 23 ++- include/configs/m28evk.h|1 + include/configs/mx51evk.h |4 ++-- include/configs/mx53ard.h |4 ++-- include/configs/mx53loco.h |4 ++-- include/configs/mx6qsabrelite.h |4 ++-- include/configs/mx6slevk.h |4 ++-- include/configs/wandboard.h |4 ++-- 8 files changed, 35 insertions(+), 13 deletions(-) -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] Upstream environment changes being used in Yocto/OE
On 28/06/2013 23:52, Otavio Salvador wrote: > This changes were being done in every version of U-Boot and it > makes sense to try to merge them upstream. > > Please review them and ack/nack them. > > Whole series applied to u-boot-imx (fix), thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] Upstream environment changes being used in Yocto/OE
Hi Stefano, On Fri, Jul 12, 2013 at 4:43 AM, Stefano Babic wrote: > Hi Fabio, hi Jason, > > On 28/06/2013 23:52, Otavio Salvador wrote: >> This changes were being done in every version of U-Boot and it >> makes sense to try to merge them upstream. >> >> Please review them and ack/nack them. >> >> > > these are small fixes in the default environment and I have no problem > to merge them for 2013.07, but I have not seen yet ACK or NACk for them. > If you think these should flow into the release, please send your ACK. I am happy with this series: Acked-by: Fabio Estevam I have also updated Jason's email on Cc (not sure if his Linaro's email is still valid). Thanks, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL size issues on OMAP4
Hi
cc: Mailing List
On 07/11/2013 07:33 PM, Michael Trimarchi wrote:
> Hi Michael
>
> On 07/11/2013 07:01 PM, Michael Cashwell wrote:
>> Greetings,
>>
>> I've been absent for a while and couldn't find a way to search the list
>> archives so I apologize if this has already been discussed…
>>
>> I've been fighting the SPL binary growing too large on OMAP4 (using custom
>> configs and features). It's annoying that too large just fails to run with
>> no build or runtime notice. But that's a different issue.
>>
>> My main issue is that in looking through the map for SPL I've repeatedly
>> found code that I don't need and have a pretty good handle on that. My issue
>> is that code that is compiled but eliminated because it's not called leaves
>> behind all of its anonymous strings ("like this"). In my latest build I have
>> the following sections that are all anonymous strings:
>>
>> 0x4030b638 0x232 arch/arm/cpu/armv7/omap-common/libomap-common.o
>> 0x4030b8b5 0x19 arch/arm/cpu/armv7/omap4/libomap4.o
>> 0x4030b9ad 0xbe common/spl/libspl.o
>> 0x4030ba6b 0x57 drivers/gpio/libgpio.o
>> 0x4030bac2 0x44c drivers/i2c/libi2c.o
>> 0x4030bf0e 0x302 drivers/mmc/libmmc.o
>> 0x4030c27e 0x15 drivers/serial/libserial.o
>> 0x4030c293 0x145 drivers/spi/libspi.o
>> 0x4030c4d8 0x53 lib/libgeneric.o
>>
>> with more than half being unreferenced. This is a big deal when you only
>> have about 25K of SRAM for code and data.
>>
>
> I don't give an answer but some suggestions:
>
> - using a raw partition to boot and remove the vfat support in first stage
> boot
> - safety you can add 2Kb more to CONFIG_SPL_MAX_SIZE (tested on serial boot
> too)
> - do some tests on different toolchains
>
> Try to move all in the second stage when it's possible
>
> Michael
>
Michael
>> In searching the web it seems that dead code and data are removed using
>> --gc-sections, -ffunction-sections and -fdata-sections which u-boot is using
>> correctly.
>>
>> But it seems that gcc puts all anonymous strings into the same section
>> (.rodata or .rodata.str1.1 if string merging is on) which prevents them from
>> participating in the stripping process.
>>
>> Interestingly, it puts its own __func__ strings into separate sections and
>> they are eliminated if the function go away. It just doesn't do this for
>> plain "" strings. Grrr.
>>
>> I was shocked to find gcc posts asking about this more than 13 years ago
>> with barely any traction at all. Given that embarrassing history I'm not
>> hopefully that the gcc folks will ever address this.
>>
>> Is there a work around I haven't thought of? I'm thinking along the lines of
>> disabling all printfs in SPL in the hope that will take the strings away
>> (since many are some sort of debug / progress message).
>>
>> Any thoughts or guidance would be appreciated.
>>
>> -Mike
>>
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PULL] : Please pull u-boot-imx
Hi Alber, please pull these fixes from u-boot-imx, thanks. The following changes since commit d6c6d127c5b948ec381fad5b24a2bc5497720644: vf610twr: Remove SoC name from U-Boot prompt (2013-06-28 16:59:08 +0200) are available in the git repository at: git://www.denx.de/git/u-boot-imx.git master for you to fetch changes up to ab94cd491faf3e7b0a3b934f5817b15997bcb315: net: fec: Avoid MX28 bus sync issue (2013-07-12 09:29:32 +0200) Marek Vasut (3): m28evk: add trimffs to nand command net: fec: Remove bogus flush_dcache_range() call net: fec: Avoid MX28 bus sync issue drivers/net/fec_mxc.c| 23 ++- include/configs/m28evk.h |1 + 2 files changed, 23 insertions(+), 1 deletion(-) -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] spi: mpc8xxx_spi: Use DIV_ROUND_UP instead of open-coded
Use DIV_ROUND_UP to simplify the code.
Signed-off-by: Axel Lin
---
drivers/spi/mpc8xxx_spi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/mpc8xxx_spi.c b/drivers/spi/mpc8xxx_spi.c
index 6b0e3b4..c90c0ce 100644
--- a/drivers/spi/mpc8xxx_spi.c
+++ b/drivers/spi/mpc8xxx_spi.c
@@ -93,7 +93,7 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen,
const void *dout,
{
volatile spi8xxx_t *spi = &((immap_t *) (CONFIG_SYS_IMMR))->spi;
unsigned int tmpdout, tmpdin, event;
- int numBlks = bitlen / 32 + (bitlen % 32 ? 1 : 0);
+ int numBlks = DIV_ROUND_UP(bitlen, 32);
int tm, isRead = 0;
unsigned char charSize = 32;
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] spi: fsl_espi: Use DIV_ROUND_UP instead of open-coded
Use DIV_ROUND_UP to simplify the code.
Signed-off-by: Axel Lin
---
drivers/spi/fsl_espi.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/fsl_espi.c b/drivers/spi/fsl_espi.c
index 28609ee..e20ab9f 100644
--- a/drivers/spi/fsl_espi.c
+++ b/drivers/spi/fsl_espi.c
@@ -234,15 +234,13 @@ int spi_xfer(struct spi_slave *slave, unsigned int
bitlen, const void *data_out,
slave->bus, slave->cs, *(uint *) dout,
dout, *(uint *) din, din, len);
- num_chunks = data_len / max_tran_len +
- (data_len % max_tran_len ? 1 : 0);
+ num_chunks = DIV_ROUND_UP(data_len, max_tran_len);
while (num_chunks--) {
if (data_in)
din = buffer + rx_offset;
dout = buffer;
tran_len = min(data_len , max_tran_len);
- num_blks = (tran_len + cmd_len) / 4 +
- ((tran_len + cmd_len) % 4 ? 1 : 0);
+ num_blks = DIV_ROUND_UP(tran_len + cmd_len, 4);
num_bytes = (tran_len + cmd_len) % 4;
fsl->data_len = tran_len + cmd_len;
spi_cs_activate(slave);
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] spi: bfin_spi: Use DIV_ROUND_UP instead of open-coded
Use DIV_ROUND_UP to simplify the code. Signed-off-by: Axel Lin --- drivers/spi/bfin_spi.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/spi/bfin_spi.c b/drivers/spi/bfin_spi.c index a9a4d92..f7192c2 100644 --- a/drivers/spi/bfin_spi.c +++ b/drivers/spi/bfin_spi.c @@ -144,10 +144,8 @@ void spi_set_speed(struct spi_slave *slave, uint hz) u32 baud; sclk = get_sclk(); - baud = sclk / (2 * hz); /* baud should be rounded up */ - if (sclk % (2 * hz)) - baud += 1; + baud = DIV_ROUND_UP(sclk, 2 * hz); if (baud < 2) baud = 2; else if (baud > (u16)-1) -- 1.8.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 6/7] tools: add support for setting the CSF into imximage
Hi Wolfgang, On 11/07/2013 20:14, Wolfgang Denk wrote: > Dear Stefano Babic, > > In message <1373548001-19728-7-git-send-email-sba...@denx.de> you wrote: >> Add support for setting the CSF (Command Sequence File) pointer >> which is used for HAB (High Assurance Boot) in the imximage by >> adding e.g. > > This patch throws a checkpatch error that needs to be fixed: > > WARNING: quoted string split across lines > #265: FILE: tools/imximage.c:412: > + fprintf(stderr, "Error: %s[%d] - " > + "CSF only supported for IMAGE_VERSION > 2(%s)\n", Fixed in V2. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 7/7] imx: add status reporting for HAB status
Hi Marek,
On 11/07/2013 20:31, Marek Vasut wrote:
>> +void display_event(uint8_t *event_data, size_t bytes)
>> +{
>> +uint32_t i;
>> +
>> +if ((event_data) && (bytes > 0)) {
>
> if (!)
> return;
>
>
Fix in V2, thanks.
>> +if (is_hab_enabled())
>> +printf("\nSecure boot enabled\n");
>> +else
>> +printf("\nSecure boot disabled\n");
>
> Use puts() instead of printf() with no args.
>
Right, and I will fix also other similar cases in this file.
Regards,
Stefano
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 0/3] Add TI816X EVM support
Hi, Any news on the status of this serie ? -- Antoine ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] blackfin: x86: bootm: Handle PREP stage of bootm
On Wed Jul 10, 2013 at 11:08:09PM -0700, Simon Glass wrote: > The OS function is now always called with the PREP stage. Adjust the > remaining bootm OS functions to deal with this correctly. > > Signed-off-by: Simon Glass > --- > arch/blackfin/lib/boot.c | 2 ++ > arch/x86/lib/bootm.c | 2 ++ > common/cmd_bootm.c | 16 > 3 files changed, 20 insertions(+) > > diff --git a/arch/blackfin/lib/boot.c b/arch/blackfin/lib/boot.c > index 768a882..5644d58 100644 > --- a/arch/blackfin/lib/boot.c > +++ b/arch/blackfin/lib/boot.c > @@ -42,6 +42,8 @@ int do_bootm_linux(int flag, int argc, char * const argv[], > bootm_headers_t *ima > int (*appl) (char *cmdline); > char*cmdline; > > + if (flag & BOOTM_STATE_OS_PREP) > + return 0; > if ((flag != 0) && (flag != BOOTM_STATE_OS_GO)) > return 1; Minor nit; A blank line between the two if conditions would be good. Applies for all the hunks in this patch. -sughosh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 7/7] imx: add status reporting for HAB status
Hi Fabio, On 11/07/2013 19:17, Fabio Estevam wrote: > Hi Stefano, > > On Thu, Jul 11, 2013 at 10:06 AM, Stefano Babic wrote: > >> --- a/arch/arm/cpu/armv7/mx6/Makefile >> +++ b/arch/arm/cpu/armv7/mx6/Makefile >> @@ -27,7 +27,7 @@ include $(TOPDIR)/config.mk >> >> LIB= $(obj)lib$(SOC).o > > Whole series looks good. > > Only a minor comment: > >> -COBJS = soc.o clock.o >> +COBJS = soc.o clock.o hab.o > > What about: > > COBJS-y += soc.o clock.o > COBJS-$(CONFIG_SECURE_BOOT) += hab.o Correct, fix in V2. > > ,and then you remove this 'if defined' ? > Agree. Best regards, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] bootm: Add the missing PREP stage to bootz and correct image handling
hi, On Wed Jul 10, 2013 at 11:56:30PM -0700, Simon Glass wrote: > > > I have netbsd running on hawkboard, but i do not boot it using the > > > bootm command, but use the go command instead. I will try to build a > > > netbsd image with the u-boot header and give it a try with bootm. Need > > > a day or two to check this out though. > > > > > > > Tried to boot netbsd with u-boot head 225fd8c5d45, and the boot fails. Was > > able to boot netbsd with v2012.10 u-boot image. Btw, am i supposed to > apply > > any patch on top of the said commit. > > Yes please see the four commits I sent earlier today. Tried after applying the series from Simon, and now the netbsd image boots fine with the bootm command. -sughosh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] pull request for u-boot-tegra/master into ARM/master
Hi Tom, On Thu, 11 Jul 2013 15:00:53 -0700, Tom Warren wrote: > Albert, > > Please pull u-boot-tegra/master into ARM/master. Thanks! > > ./MAKEALL -s tegra AOK, checkpatch.pl is clean. > > The following changes since commit 630aacb0859c6e26b2b0311d8e245da5e5b8ac67: > > Merge branch 'u-boot-samsung/master' into 'u-boot-arm/master' (2013-07-10 > 20:4 > 0:47 +0200) > > are available in the git repository at: > > > git://git.denx.de/u-boot-tegra master > > for you to fetch changes up to d035fcf9b6a5a0d7ce8d3d5f3ef960618deea47e: > > ARM: tegra: enable LCD panel on Ventana (2013-07-11 14:15:16 -0700) > > > Jim Lin (3): > ARM: Tegra: FDT: Add USB EHCI function for T30/T114 > ARM: Tegra: USB: EHCI: Add support for Tegra30/Tegra114 > Tegra: Config: Enable Tegra30/Tegra114 USB function > > Stephen Warren (2): > ARM: tegra: enable LCD panel on Harmony > ARM: tegra: enable LCD panel on Ventana > > arch/arm/dts/tegra114.dtsi| 27 +++ > arch/arm/dts/tegra30.dtsi | 27 +++ > arch/arm/include/asm/arch-tegra/clk_rst.h | 10 + > arch/arm/include/asm/arch-tegra/usb.h | 182 +- > arch/arm/include/asm/arch-tegra114/usb.h | 156 +++ > arch/arm/include/asm/arch-tegra20/usb.h | 155 +++ > arch/arm/include/asm/arch-tegra30/usb.h | 168 + > board/nvidia/common/board.c | 1 + > board/nvidia/dts/tegra114-dalmore.dts | 7 + > board/nvidia/dts/tegra20-harmony.dts | 32 > board/nvidia/dts/tegra20-ventana.dts | 32 > board/nvidia/dts/tegra30-beaver.dts | 6 + > board/nvidia/dts/tegra30-cardhu.dts | 6 + > board/nvidia/harmony/harmony.c| 7 + > drivers/usb/host/ehci-tegra.c | 304 > ++ > include/configs/beaver.h | 14 ++ > include/configs/cardhu.h | 14 ++ > include/configs/dalmore.h | 14 ++ > include/configs/harmony.h | 9 + > include/configs/tegra114-common.h | 3 + > include/configs/tegra30-common.h | 3 + > include/configs/ventana.h | 9 + > include/fdtdec.h | 2 + > lib/fdtdec.c | 2 + > 24 files changed, 1015 insertions(+), 175 deletions(-) > create mode 100644 arch/arm/include/asm/arch-tegra114/usb.h > create mode 100644 arch/arm/include/asm/arch-tegra20/usb.h > create mode 100644 arch/arm/include/asm/arch-tegra30/usb.h Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] Upstream environment changes being used in Yocto/OE
Hi Fabio, hi Jason, On 28/06/2013 23:52, Otavio Salvador wrote: > This changes were being done in every version of U-Boot and it > makes sense to try to merge them upstream. > > Please review them and ack/nack them. > > these are small fixes in the default environment and I have no problem to merge them for 2013.07, but I have not seen yet ACK or NACk for them. If you think these should flow into the release, please send your ACK. Thanks, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] mx51evk: Change default environment to cope with OE changes
On 28/06/2013 23:52, Otavio Salvador wrote:
> OpenEmbedded has change partitioning layout of generated image so it
> does not raise warnings during the boot regarding unkown partition
> being used for U-Boot.
>
> Signed-off-by: Otavio Salvador
> ---
> include/configs/mx51evk.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/configs/mx51evk.h b/include/configs/mx51evk.h
> index 13d1839..4383375d 100644
> --- a/include/configs/mx51evk.h
> +++ b/include/configs/mx51evk.h
> @@ -162,8 +162,8 @@
> "boot_fdt=try\0" \
> "ip_dyn=yes\0" \
> "mmcdev=0\0" \
> - "mmcpart=2\0" \
> - "mmcroot=/dev/mmcblk0p3 rootwait rw\0" \
> + "mmcpart=1\0" \
> + "mmcroot=/dev/mmcblk0p2 rootwait rw\0" \
> "mmcargs=setenv bootargs console=ttymxc0,${baudrate} " \
> "root=${mmcroot}\0" \
> "loadbootscript=" \
>
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-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] arm: arm926ejs: flush cache before disable it
Hi Sughosh, On Wed, 10 Jul 2013 23:04:45 +0530, Sughosh Ganu wrote: > hi Albert, > > On Wed Jul 10, 2013 at 02:30:30PM +0200, Albert ARIBAUD wrote: > > > > > You are correct re the other policies of the DDI0198E (ARM926EJ-S > > > > TRM) MMU -- page 3-11, bits 3-2 of the section descriptor. Note however > > > > that you may have to refer to your specific SoC's TRM or equivalent, as > > > > the SoC designer may have defined its own system-level cache and MMU > > > > architecture. > > > > > > > > Note in any case that none of the policies mentioned in DDI0198E is > > > > described as read-allocate (let alone "read-allocate only" where writes > > > > would bypass the enabled cache); on the contrary, the only cache > > > > policies mentioned are write-through and write-back, both of which > > > > contradict cache bypass on write. > > > > > > I was referring to the cache allocation policy mentioned in section > > > 4.1 in the DDI0198E document -- this is also mentioned in table 12.1 > > > in chapter 12 of the arm developers guide. > > > > Can you please quote the exact part of 4.1 which describes the cache > > policy and then explain what you think it means exactly? > > I was referring to this particular point in section 4.1 > "Allocate on read-miss is supported. The caches perform critical-word > first cache refilling." This is not equivalent to "the cache policy is read-allocate". This paragraph does not specify the cache's general policy, only a read policy, and only the *read allocation* policy. Its write policies are not defined or even constrained by this paragraph. > Based on the cache line allocation policies described in section > 12.3.3 in the arm developers guide, my interpretation of 'allocate on > read-miss' was as above. The ARM926EJ-S is "allocate on read-miss" as well as "allocate on write-miss"; and none of its write policies bypasses the cache. > -sughosh Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
On 12/07/2013 01:03, Marek Vasut wrote: > The MX28 multi-layer AHB bus can be too slow and trigger the > FEC DMA too early, before all the data hit the DRAM. This patch > ensures the data are written in the RAM before the DMA starts. > Please see the comment in the patch for full details. > > This patch was produced with an amazing help from Albert Aribaud, > who pointed out it can possibly be such a bus synchronisation > issue. > > Signed-off-by: Marek Vasut > Cc: Albert ARIBAUD > Cc: Fabio Estevam > Cc: Stefano Babic > --- Applied to u-boot-imx (fix), thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fec: Remove bogus flush_dcache_range() call
On 11/07/2013 17:23, Marek Vasut wrote: > Remove incorrectly called and duplicate flush_dcache_range() call > from fec_mxc driver. The call is not needed, since the caches are > already flushed in fec_tbd_init(), moreover the second argument should > be the ending address, not size. > > Signed-off-by: Marek Vasut > Reported-by: Albert Aribaud > Cc: Stefano Babic > Cc: Tom Rini > --- > drivers/net/fec_mxc.c |1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c > index da95e28..97bf8fe 100644 > --- a/drivers/net/fec_mxc.c > +++ b/drivers/net/fec_mxc.c > @@ -560,7 +560,6 @@ static int fec_init(struct eth_device *dev, bd_t* bd) > } > memset(fec->tbd_base, 0, size); > fec_tbd_init(fec); > - flush_dcache_range((unsigned)fec->tbd_base, size); > } > > /* > Applied to u-boot-imx (fix), thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] m28evk: add trimffs to nand command
On 07/07/2013 20:20, Marek Vasut wrote: > this is usefull when writing an UBI image which contains > and UBIFS volume (check README.nand and UBI FAQ for more > details) > > Signed-off-by: Marek Vasut > Cc: Stefano Babic > --- Applied to u-boot-imx (fix), thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
