Re: [U-Boot] [PATCH V2 00/21] Add mx6solo/mx6duallite support
Hi Troy, On 22.09.2012 04:38, Troy Kisky wrote: After this series the same binary will run on a Saberlite board using any of the pin compatible processors mx6 quad, mx6 duallite, or mx6 solo. This is accomplished using a plugin and a table built by mkimage. Could you briefly explain or give a link to some documentation how this does work? It sounds to me that the plugin concept is something the boot ROM has to understand? Or in other words: How does the boot ROM decide on which processor it runs and which DCD table to execute then? Sorry if I misunderstood something, I'm not so familiar with the boot ROM options. Many thanks Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/5] Marvell SDIO/MMC driver for Sheevaplug
This serie of patch add SDIO/MMC support to Sheevaplug board Change from v1: - Fix an issue with most SDHC cards because of timeout delay drEagle (5): Add Marvell SDIO/MMC driver for Kirkwood SoC Add SDIO/MMC support for kirkwood SoC Add SDIO/MMC support for Sheevaplug board Fix env address for Sheevaplug board Fix timeout in Marvell SDIO MMC driver ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/5] Add Marvell SDIO/MMC driver for Kirkwood SoC
Add Marvell SDIO/MMC driver for Kirkwood SoC
Signed-off-by: Gérald Kerma ub...@doukki.net
Signed-off-by: Lior Amsalem al...@marvell.com
---
drivers/mmc/Makefile |1 +
drivers/mmc/mrvl_mmc.c | 277
include/mrvl_mmc.h | 191 +
3 files changed, 469 insertions(+)
create mode 100644 drivers/mmc/mrvl_mmc.c
create mode 100644 include/mrvl_mmc.h
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index 2b96cdc..7f3b7c1 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -37,6 +37,7 @@ COBJS-$(CONFIG_GENERIC_MMC) += mmc.o
COBJS-$(CONFIG_GENERIC_ATMEL_MCI) += gen_atmel_mci.o
COBJS-$(CONFIG_MMC_SPI) += mmc_spi.o
COBJS-$(CONFIG_ARM_PL180_MMCI) += arm_pl180_mmci.o
+COBJS-$(CONFIG_MRVL_MMC) += mrvl_mmc.o
COBJS-$(CONFIG_MV_SDHCI) += mv_sdhci.o
COBJS-$(CONFIG_MXC_MMC) += mxcmmc.o
COBJS-$(CONFIG_MXS_MMC) += mxsmmc.o
diff --git a/drivers/mmc/mrvl_mmc.c b/drivers/mmc/mrvl_mmc.c
new file mode 100644
index 000..8127961
--- /dev/null
+++ b/drivers/mmc/mrvl_mmc.c
@@ -0,0 +1,277 @@
+/*
+ * Driver for Marvell SDIO/MMC controller
+ *
+ * (C) Copyright 2012
+ * Marvell Semiconductor www.marvell.com
+ * Written-by: Lior Amsalem al...@marvell.com
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include malloc.h
+#include part.h
+#include mmc.h
+
+#include mrvl_mmc.h
+#define MRVL_MMC_MAKE_CMD(c, f) (((c 0xff) 8) | (f 0xff))
+
+
+static int mrvl_mmc_setup_data(struct mmc_data *data)
+{
+ if (data-flags MMC_DATA_READ) {
+ SDIO_REG_WRITE16(SDIO_SYS_ADDR_LOW,((ulong)(data-dest))
0x);
+ SDIO_REG_WRITE16(SDIO_SYS_ADDR_HI,(((ulong)data-dest) 16)
0x);
+ } else {
+ SDIO_REG_WRITE16(SDIO_SYS_ADDR_LOW,((ulong)(data-src))
0x);
+ SDIO_REG_WRITE16(SDIO_SYS_ADDR_HI,(((ulong)data-src) 16)
0x);
+ }
+
+ SDIO_REG_WRITE16(SDIO_BLK_SIZE, data-blocksize);
+ SDIO_REG_WRITE16(SDIO_BLK_COUNT, data-blocks);
+
+ return 0;
+}
+
+static int mrvl_mmc_send_cmd (struct mmc *mmc, struct mmc_cmd *cmd, struct
mmc_data *data)
+{
+ int timeout = 10;
+ ushort waittype = 0;
+ int err = 0 ;
+ ushort response[8], resp_indx = 0;
+ ushort resptype = 0;
+ ushort xfertype = 0;
+
+#ifdef DEBUG
+ printf(cmd [0x%x] resp_type[0x%x] arg[0x%x]\n, cmd-cmdidx,
cmd-resp_type, cmd-cmdarg);
+#endif
+
+ /* clear status */
+ SDIO_REG_WRITE16(SDIO_NOR_INTR_STATUS, 0x);
+ SDIO_REG_WRITE16(SDIO_ERR_INTR_STATUS, 0x);
+
+ /* Checking if card is busy */
+ while ((SDIO_REG_READ16(SDIO_PRESENT_STATE0) CARD_BUSY)) {
+ if (timeout == 0) {
+ printf(MRVL MMC: card busy!\n);
+ return -1;
+ }
+ timeout--;
+ udelay(1000);
+ }
+
+ /* Set up for a data transfer if we have one */
+ if (data) {
+ int err;
+ err = mrvl_mmc_setup_data(data);
+ if(err)
+ return err;
+ }
+
+ /* Analyzing resptype/xfertype/waittype for the command */
+ if (cmd-resp_type MMC_RSP_BUSY)
+ resptype |= SDIO_CMD_RSP_48BUSY;
+ else if (cmd-resp_type MMC_RSP_136)
+ resptype |= SDIO_CMD_RSP_136;
+ else if (cmd-resp_type MMC_RSP_PRESENT)
+ resptype |= SDIO_CMD_RSP_48;
+ else
+ resptype |= SDIO_CMD_RSP_NONE;
+
+ if (cmd-resp_type MMC_RSP_CRC)
+ resptype |= SDIO_CMD_CHECK_CMDCRC;
+
+ if (cmd-resp_type MMC_RSP_OPCODE)
+ resptype |= SDIO_CMD_INDX_CHECK;
+
+ if (cmd-resp_type MMC_RSP_PRESENT) {
+ resptype |= SDIO_UNEXPECTED_RESP;
+ waittype |= SDIO_NOR_UNEXP_RSP;
+ }
+
+ if (data) {
+ resptype |= SDIO_CMD_DATA_PRESENT | SDIO_CMD_CHECK_DATACRC16;
+ xfertype |= SDIO_XFER_MODE_HW_WR_DATA_EN;
+ if (data-flags MMC_DATA_READ) {
+ xfertype |= SDIO_XFER_MODE_TO_HOST;
+ waittype = SDIO_NOR_DMA_INI;
+
[U-Boot] [PATCH v2 2/5] Add SDIO/MMC support for kirkwood SoC
Add SDIO/MMC support for kirkwood SoC Signed-off-by: drEagle drea...@doukki.net --- arch/arm/include/asm/arch-kirkwood/kirkwood.h |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/include/asm/arch-kirkwood/kirkwood.h b/arch/arm/include/asm/arch-kirkwood/kirkwood.h index 47771d5..343214b 100644 --- a/arch/arm/include/asm/arch-kirkwood/kirkwood.h +++ b/arch/arm/include/asm/arch-kirkwood/kirkwood.h @@ -55,6 +55,7 @@ #define KW_EGIGA0_BASE (KW_REGISTER(0x72000)) #define KW_EGIGA1_BASE (KW_REGISTER(0x76000)) #define KW_SATA_BASE (KW_REGISTER(0x8)) +#define KW_SDIO_BASE (KW_REGISTER(0x9)) /* Kirkwood Sata controller has two ports */ #define KW_SATA_PORT0_OFFSET 0x2000 -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/5] Add SDIO/MMC support for Sheevaplug board
Add SDIO/MMC support for Sheevaplug board
Signed-off-by: drEagle drea...@doukki.net
---
board/Marvell/sheevaplug/sheevaplug.c | 11 +++
include/configs/sheevaplug.h | 12
2 files changed, 23 insertions(+)
diff --git a/board/Marvell/sheevaplug/sheevaplug.c
b/board/Marvell/sheevaplug/sheevaplug.c
index 688d308..db64a05 100644
--- a/board/Marvell/sheevaplug/sheevaplug.c
+++ b/board/Marvell/sheevaplug/sheevaplug.c
@@ -28,6 +28,9 @@
#include asm/arch/kirkwood.h
#include asm/arch/mpp.h
#include sheevaplug.h
+#ifdef CONFIG_MRVL_MMC
+#include mrvl_mmc.h
+#endif /* CONFIG_MRVL_MMC */
DECLARE_GLOBAL_DATA_PTR;
@@ -147,3 +150,11 @@ void reset_phy(void)
printf(88E1116 Initialized on %s\n, name);
}
#endif /* CONFIG_RESET_PHY_R */
+
+#ifdef CONFIG_MRVL_MMC
+int board_mmc_init(bd_t *bis)
+{
+ mrvl_mmc_initialize(bis);
+ return 0;
+}
+#endif /* CONFIG_MRVL_MMC */
diff --git a/include/configs/sheevaplug.h b/include/configs/sheevaplug.h
index 83dd8ff..7d710bf 100644
--- a/include/configs/sheevaplug.h
+++ b/include/configs/sheevaplug.h
@@ -47,6 +47,7 @@
#define CONFIG_CMD_DHCP
#define CONFIG_CMD_ENV
#define CONFIG_CMD_MII
+#define CONFIG_CMD_MMC
#define CONFIG_CMD_NAND
#define CONFIG_CMD_PING
#define CONFIG_CMD_USB
@@ -98,6 +99,17 @@
#endif /* CONFIG_CMD_NET */
/*
+ * SDIO/MMC Card Configuration
+ */
+#ifdef CONFIG_CMD_MMC
+#define CONFIG_MMC
+#define CONFIG_GENERIC_MMC
+#define CONFIG_MRVL_MMC
+#define CONFIG_SYS_MMC_BASE KW_SDIO_BASE
+#endif /* CONFIG_CMD_MMC */
+
+
+/*
* File system
*/
#define CONFIG_CMD_EXT2
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/5] Fix env address for Sheevaplug board
Fix env address for Sheevaplug board Move env address and offset from 0x6 to 0x8 Signed-off-by: drEagle drea...@doukki.net --- include/configs/sheevaplug.h |5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/include/configs/sheevaplug.h b/include/configs/sheevaplug.h index 7d710bf..a10e825 100644 --- a/include/configs/sheevaplug.h +++ b/include/configs/sheevaplug.h @@ -71,9 +71,8 @@ * it has to be rounded to sector size */ #define CONFIG_ENV_SIZE0x2 /* 128k */ -#define CONFIG_ENV_ADDR0x6 -#define CONFIG_ENV_OFFSET 0x6 /* env starts here */ - +#define CONFIG_ENV_ADDR0x8 +#define CONFIG_ENV_OFFSET 0x8 /* env starts here */ /* * Default environment variables */ -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 5/5] Fix timeout in Marvell SDIO MMC driver
Fix an issue with most SDHC cards because of timeout delay
Signed-off-by: drEagle drea...@doukki.net
---
drivers/mmc/mrvl_mmc.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/mrvl_mmc.c b/drivers/mmc/mrvl_mmc.c
index 8127961..bdafbc7 100644
--- a/drivers/mmc/mrvl_mmc.c
+++ b/drivers/mmc/mrvl_mmc.c
@@ -4,6 +4,7 @@
* (C) Copyright 2012
* Marvell Semiconductor www.marvell.com
* Written-by: Lior Amsalem al...@marvell.com
+ * Written-by: Gérald Kerma ub...@doukki.net
* See file CREDITS for list of people who contributed to this
* project.
*
@@ -127,10 +128,9 @@ static int mrvl_mmc_send_cmd (struct mmc *mmc, struct
mmc_cmd *cmd, struct mmc_d
SDIO_REG_WRITE16(SDIO_CMD, MRVL_MMC_MAKE_CMD(cmd-cmdidx, resptype));
/* Waiting for completion */
- timeout = 100;
+ timeout = 1;
while (!((SDIO_REG_READ16(SDIO_NOR_INTR_STATUS)) waittype)) {
- udelay(1);
if (SDIO_REG_READ16(SDIO_NOR_INTR_STATUS) SDIO_NOR_ERROR) {
#ifdef DEBUG
printf(mrvl_mmc_send_cmd: error! cmd : %d, err reg:
%04x\n, cmd-cmdidx, SDIO_REG_READ16(SDIO_ERR_INTR_STATUS));
@@ -139,6 +139,7 @@ static int mrvl_mmc_send_cmd (struct mmc *mmc, struct
mmc_cmd *cmd, struct mmc_d
return TIMEOUT;
return COMM_ERR;
}
+ udelay(1000);
timeout--;
if (timeout = 0) {
printf(MRVL MMC: command timed out\n);
--
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 0/5] Marvell SDIO/MMC driver for Sheevaplug
Hi, I found an issue of timeout problems. Now all my cards read correctly, quickly and efficiently. If someone need a precompiled u-boot binary for testing this version, fell free to ask. I will put it available online. Le 22/09/2012 09:15, DrEagle a écrit : This serie of patch add SDIO/MMC support to Sheevaplug board Change from v1: - Fix an issue with most SDHC cards because of timeout delay drEagle (5): Add Marvell SDIO/MMC driver for Kirkwood SoC Add SDIO/MMC support for kirkwood SoC Add SDIO/MMC support for Sheevaplug board Fix env address for Sheevaplug board Fix timeout in Marvell SDIO MMC driver signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5] [RFC] early_malloc for DM added.
Hello Marek,
On Sat, Sep 22, 2012 at 2:28 AM, Marek Vasut ma...@denx.de wrote:
Dear Tomas Hlavacek,
early_malloc for DM with support for more heaps and lightweight
first heap in the same memory as an early stack.
Adaptation layer for seamless calling of early_malloc or dlmalloc from
DM based on init stage added (dmmalloc() and related functions).
Signed-off-by: Tomas Hlavacek tmshl...@gmail.com
[...]
31 files changed, 363 insertions(+)
create mode 100644 common/dmmalloc.c
create mode 100644 include/dmmalloc.h
What exactly changed in this version? Changelog is missing.
Preprocessor config-dependent (ifdef ... endif) blocks are different.
early_brk call from early_malloc when the heaps are full.
default early_brk checks existing heap for before setting.
[...]
+static int early_malloc_active(void)
+{
+ if ((gd-flags GD_FLG_RELOC) == GD_FLG_RELOC)
+ return 0;
Did you completely ignore the comments?
Yes, this is ugly and I did not notice the point of (your?) comment
while reworking this tiny part again and again... Sorry.
+ return 1;
+}
+#endif /* CONFIG_SYS_EARLY_MALLOC */
+
+#ifdef CONFIG_SYS_EARLY_MALLOC
+void *dmmalloc(size_t size)
+{
+ if (early_malloc_active())
+ return early_malloc(size);
+ return malloc(size);
+}
+#else /* CONFIG_SYS_EARLY_MALLOC */
+#define dmmalloc malloc
How is this actually supposed to work?
Of course, this have to be in the header file dmmalloc.h. Just ignore
the #else ... #endif part.
+#endif /* CONFIG_SYS_EARLY_MALLOC */
+
+#ifdef CONFIG_SYS_EARLY_MALLOC
+void dmfree(void *ptr)
+{
+ if (early_malloc_active())
+ return;
+ free(ptr);
+}
+#else /* CONFIG_SYS_EARLY_MALLOC */
+#define dmfree free
+#endif /* CONFIG_SYS_EARLY_MALLOC */
+
+#ifdef CONFIG_SYS_EARLY_MALLOC
+void *dmcalloc(size_t n, size_t elem_size)
+{
+ if (early_malloc_active())
+ return NULL;
+ return calloc(n, elem_size);
+}
+#else /* CONFIG_SYS_EARLY_MALLOC */
+#define dmcalloc calloc
+#endif /* CONFIG_SYS_EARLY_MALLOC */
+
+#ifdef CONFIG_SYS_EARLY_MALLOC
+void *dmrealloc(void *oldmem, size_t bytes)
+{
+ if (early_malloc_active())
+ return NULL;
+ return dmrealloc(oldmem, bytes);
+}
+#else /* CONFIG_SYS_EARLY_MALLOC */
+#define dmrealloc realloc
+#endif /* CONFIG_SYS_EARLY_MALLOC */
+
diff --git a/include/dmmalloc.h b/include/dmmalloc.h
new file mode 100644
index 000..726c6c9
--- /dev/null
+++ b/include/dmmalloc.h
@@ -0,0 +1,56 @@
+/*
+ * (C) Copyright 2012
+ * Tomas Hlavacek (tmshl...@gmail.com)
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef __INCLUDE_DMMALLOC_H
+#define __INCLUDE_DMMALLOC_H
+
+#include config.h
+#include linux/stddef.h /* for size_t */
+
+#if (!defined(CONFIG_SYS_EARLY_HEAP_ADDR)) || \
+ (!defined(CONFIG_SYS_EARLY_HEAP_SIZE))
+#undef CONFIG_SYS_EARLY_MALLOC
+#endif /* CONFIG_SYS_EARLY_HEAP_ADDR */
+
+#ifdef CONFIG_SYS_EARLY_MALLOC
+struct early_heap_header {
+ void *free_space_pointer;
+ size_t free_bytes;
+ void *next_early_heap;
+};
+
+struct early_heap_header *early_brk(size_t size);
+void *early_malloc(size_t size);
+
+#endif /* CONFIG_SYS_EARLY_MALLOC */
+
+#ifdef CONFIG_SYS_DM
Isn't it CONFIG_DM ?
I will change that. (Is it consistent with the naming convention? I
mean: What the _SYS_ exactly means?)
Tomas
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v2 0/6] Port of MUSB driver from Linux
Dear Marek, On Sat, Sep 22, 2012 at 4:55 AM, Marek Vasut ma...@denx.de wrote: [...] I'm glad about this. But how can we make this work if we already have a driver for this in u-boot, now we will have another. Tom ? What's so wrong in letting the two coexist for some time so people could migrate smoothly? Of course we don't want any duplicate drivers... in the perfect world. But we are not in the perfect world (look, there is a bunch of OHCI drivers which are almost the same and they are in the tree for years) and the drivers are rather different. Of course, we should encourage people to switch to the new code, probably by marking the old one deprecated and scheduled for removal. BTW, anybody here use the current musb code? In my experience it never worked as expected... Probably we can drop it right away without much pain... Regards, Ilya. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v2 5/6] am33xx: init OTG hardware and new musb gadget driver
Dear Marek,
On Sat, Sep 22, 2012 at 4:49 AM, Marek Vasut ma...@denx.de wrote:
+{
+ u32 usb_ctrl_reg;
+
+ usb_ctrl_reg = readl(reg_addr);
+ if (on) {
+ usb_ctrl_reg = ~(CM_PHY_PWRDN | CM_PHY_OTG_PWRDN);
+ usb_ctrl_reg |= (OTGVDET_EN | OTGSESSENDEN);
+ } else {
+ usb_ctrl_reg |= (CM_PHY_PWRDN | CM_PHY_OTG_PWRDN);
+ }
+ writel(usb_ctrl_reg, reg_addr);
+static void am33xx_usb_set_phy_power(u8 on, u32 *reg_addr)
clrsetbits_le32() ?
Will change.
Regards, Ilya.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v2 4/6] musb-new: dsps backend driver
Dear Marek, On Sat, Sep 22, 2012 at 4:48 AM, Marek Vasut ma...@denx.de wrote: +COBJS-$(CONFIG_USB_MUSB_DSPS) += musb_dsps.o CONFIG_MUSB_... ? I'm following Linux here. We can change this, but should we? BTW, it looks to be in line with the current code where all USB lowlevel drivers have CONFIG_USB_* configuration options. Regards, Ilya. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: lacie_kw: add support for WIRELESS_SPACE
Hi Simon, On Wed, 22 Aug 2012 17:16:21 +0200, Simon Guinot simon.gui...@sequanux.org wrote: On Tue, Aug 21, 2012 at 12:16:40AM -0700, Prafulla Wadaskar wrote: -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot- boun...@lists.denx.de] On Behalf Of Albert ARIBAUD Sent: 18 August 2012 02:59 To: Tom Rini Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] ARM: lacie_kw: add support for WIRELESS_SPACE Hi Tom, On Fri, 17 Aug 2012 10:55:38 -0700, Tom Rini tr...@ti.com wrote: On Thu, Aug 16, 2012 at 08:08:34PM +0200, Albert ARIBAUD wrote: Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net [snip] @@ -90,8 +100,14 @@ #define CONFIG_SYS_IDE_MAXDEVICE1 #if defined(CONFIG_NET2BIG_V2) #define CONFIG_SYS_PROMPT2big2 -#else +#elif defined(CONFIG_NETSPACE_V2) #define CONFIG_SYS_PROMPTns2 +#elif defined(CONFIG_INETSPACE_V2) +#define CONFIG_SYS_PROMPTis2 +#elif defined(CONFIG_WIRELESS_SPACE) +#define CONFIG_SYS_PROMPTws +#else +#define CONFIG_SYS_PROMPTlacie-kw Is this really a good thing? Over here I've been trying / hoping to get everyone to just use 'U-Boot # ' as the prompt as this makes automated testing easier and there's other run-time ways to see what we're on. I personally vote to have common boot prompt 'U-boot #'. I quite like prompts that identify the board I'm on, but it's not a must either. Cc:ing Simon in cas his own patches re lacie_kw would be impacted by your suggestion. Well, we can expose a command to detect/print the board info, if needed. The run-time command version already returns both the system and the machine informations. This command can be used for testing purposes. IMHO the only requirement for an U-Boot prompt is to be short enough. Everything else is a matter of taste. Mine goes for the machine name. Regards, Simon Tom, Can automated test cope with a general prompt of the form '.*#' ? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/11] DM: add block device core
On Saturday 22 of September 2012 02:09:15 Marek Vasut wrote: Dear Pavel Herrmann, [...] one or none - requests on USB flashes should not pass through block_controller_driver. Uh, what do they pass into then ? their parent (an USB hub) block_device instance (aka. partition/disk) directly connected to USB hub instance does not seem right. why? every child of block_controller should be a block_device (not necessarily the other way around I doubt it's even possible to be the other way around. ), so there is no way you pass more instances block_controller on your way up. Ok, let me explain again. Let's look at the USB case to make it more real-world- ish. Imagine you have a thumb drive with 2 partitions. Thus you have two instances of struct block_device [denote BDp] for the partitions and one more for the whole disc [denote BDd]. When you read from partition, you end up poking BDp, which pushes the request up into BDd. This in turn calls USB-flashdisc- block_controller_driver [call it UFc]. For flash disc to read data, it needs to do some USB transfers. These are provided by USB host controller [UHC]. Thus you need some glue between UHC and UFc ... this is what I'm talking about. there should be no UFc, your BDd driver should talk directly to your UHC So my generic partition implementation (BDd) would have to implement USB flashdisc stuff, correct? This makes no sense. no. your generic USB flash would have to implement USB flashdisc stuff, your generic partition implements block_device operations on top of other block_device (aka diosk, memory card, USB flash) please read the letters you came up with right. (maybe after getting some sleep by the looks of it) the point you are not getting is that there should be more block_device drivers than there is now - one for partitions, one for disk, one for USB flash, one for SD and so on, each one using a different parent API (a driver that has blockdev API on one end, USB on the other) Ok, so how would this work, every partition implementation implements upcalls for all USB, SCSI, SATA, IDE, SD, ... and gazilion other types of drive it can sit on? no, partition only implements call onto another block device Ok, I see the issue at hand. In case of a regular drive, this implements the IO directly. In case of SD, this is a proxy object which interfaces with some SD-library and prepares the SD commands and then pushes that up into the controller to do the job? Same thing for USB flashes ? not every block device will have a block controller as a parent (or parent-of- parent in case of a partition). there would be a blockdev-usb that has a USB hub as a parent, and a blockdev-mmc, that has a mmc/sdio controller as a parent. So you would have a specific partition implementation for SD, SATA, IDE, SCSI, USB ... ? This is flawed. no, read above The partition should be a generic thing which knows nothing about where it's sitting at. So is the whole drive, same thing, it just has partitions hooked under it. I'd expect a block_controller to be the proxy object under which the block_device representing the disc is connected. And this block_controller to be proxifying the requests to the respective drivers (be it SD, SATA, whatever). your idea is wrong - you expect there will always be only one block_device representig a disk, and all the proxy would be done by the block_controller above it. this is not true Pavel Herrmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] SBx81CFC960: embed Fman microcode in the bootloader
On 09/22/2012 03:58 AM, Wolfgang Denk wrote: Dear judge.pack...@gmail.com, In message 1348216335-18105-1-git-send-email-judge.pack...@gmail.com you wrote: From: Chris Packham judge.pack...@gmail.com Instead of storing the mircocode in a separate flash block simply embed the image as C code array of bytes. What exactly is the licensing of this code? Good point. I got the firmware out of the SDK that came with our P2041RDB. I believe the intent was that the Fman microcode is written to a reserved flash block and downloaded to the frame manager by the OS when needed. As a Freescale customer I would actually prefer to have the source released under the GPL and build everything into the u-boot image. Would it not have to be GPL compatible to link it in such a way, which in turn would require the source code and the tools to build it ? Well I took one law paper at university and quickly decided to major in computer science instead so I am entirely unqualified to comment :). That being said it probably depends on the definition of link. No code is actually being called directly from u-boot, it's just a convenient transportation mechanism. Still there are statements in the GPL about what constitutes distributing the code, someone more qualified can tackle that. I can understand why for u-boot this might be a gray area. Writing firmware blobs to a flash block somewhere is a solution that avoids any problems and makes my patch unsuitable/unnecessary. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/11] DM: add block device core
Dear Pavel Herrmann, On Saturday 22 of September 2012 02:09:15 Marek Vasut wrote: Dear Pavel Herrmann, [...] one or none - requests on USB flashes should not pass through block_controller_driver. Uh, what do they pass into then ? their parent (an USB hub) block_device instance (aka. partition/disk) directly connected to USB hub instance does not seem right. why? It doesn't make sense ... you need some kind of interim controller (like the chip between the USB and NAND in the thumbdrive. every child of block_controller should be a block_device (not necessarily the other way around I doubt it's even possible to be the other way around. ), so there is no way you pass more instances block_controller on your way up. Ok, let me explain again. Let's look at the USB case to make it more real-world- ish. Imagine you have a thumb drive with 2 partitions. Thus you have two instances of struct block_device [denote BDp] for the partitions and one more for the whole disc [denote BDd]. When you read from partition, you end up poking BDp, which pushes the request up into BDd. This in turn calls USB-flashdisc- block_controller_driver [call it UFc]. For flash disc to read data, it needs to do some USB transfers. These are provided by USB host controller [UHC]. Thus you need some glue between UHC and UFc ... this is what I'm talking about. there should be no UFc, your BDd driver should talk directly to your UHC So my generic partition implementation (BDd) would have to implement USB flashdisc stuff, correct? This makes no sense. no. your generic USB flash would have to implement USB flashdisc stuff, your generic partition implements block_device operations on top of other block_device (aka diosk, memory card, USB flash) Ok, so in your parlance, the block_device is either partition/disc or a SD card controller driver or USB flashdisc driver ? You are mixing these two things together? please read the letters you came up with right. (maybe after getting some sleep by the looks of it) I'd prefer to read some documented code. the point you are not getting is that there should be more block_device drivers than there is now - one for partitions, one for disk, one for USB flash, one for SD and so on, each one using a different parent API Ok, now I understand your intention. Split it -- make partitions separate, since this is flat out confusing! Make partitions / whole disc a separate thing ... Make USB flash driver / SD card driver / etc. another thing ... You can not mix these two together, it makes no sense. (a driver that has blockdev API on one end, USB on the other) Ok, so how would this work, every partition implementation implements upcalls for all USB, SCSI, SATA, IDE, SD, ... and gazilion other types of drive it can sit on? no, partition only implements call onto another block device Ok, I see the issue at hand. In case of a regular drive, this implements the IO directly. In case of SD, this is a proxy object which interfaces with some SD-library and prepares the SD commands and then pushes that up into the controller to do the job? Same thing for USB flashes ? not every block device will have a block controller as a parent (or parent-of- parent in case of a partition). there would be a blockdev-usb that has a USB hub as a parent, and a blockdev-mmc, that has a mmc/sdio controller as a parent. So you would have a specific partition implementation for SD, SATA, IDE, SCSI, USB ... ? This is flawed. no, read above The partition should be a generic thing which knows nothing about where it's sitting at. So is the whole drive, same thing, it just has partitions hooked under it. I'd expect a block_controller to be the proxy object under which the block_device representing the disc is connected. And this block_controller to be proxifying the requests to the respective drivers (be it SD, SATA, whatever). your idea is wrong - you expect there will always be only one block_device representig a disk, and all the proxy would be done by the block_controller above it. this is not true Any amount of block_device can be connected under the block_controller. Given that block_device is a partition/disc _only_ and block_controller is the interface driver ... which is probably not true, so you lost me again. I stop here, this discussion leads nowhere. Can you please write proper documentation from which I can get an idea how this exactly works? Ideally with diagrams ... doc/driver-model/UDM-block.txt would be a good place. Pavel Herrmann 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 v5] [RFC] early_malloc for DM added.
Dear Tomas Hlavacek,
Hello Marek,
On Sat, Sep 22, 2012 at 2:28 AM, Marek Vasut ma...@denx.de wrote:
Dear Tomas Hlavacek,
early_malloc for DM with support for more heaps and lightweight
first heap in the same memory as an early stack.
Adaptation layer for seamless calling of early_malloc or dlmalloc from
DM based on init stage added (dmmalloc() and related functions).
Signed-off-by: Tomas Hlavacek tmshl...@gmail.com
[...]
31 files changed, 363 insertions(+)
create mode 100644 common/dmmalloc.c
create mode 100644 include/dmmalloc.h
What exactly changed in this version? Changelog is missing.
Preprocessor config-dependent (ifdef ... endif) blocks are different.
early_brk call from early_malloc when the heaps are full.
default early_brk checks existing heap for before setting.
[...]
+static int early_malloc_active(void)
+{
+ if ((gd-flags GD_FLG_RELOC) == GD_FLG_RELOC)
+ return 0;
Did you completely ignore the comments?
Yes, this is ugly and I did not notice the point of (your?) comment
while reworking this tiny part again and again... Sorry.
I think it was GR.
+ return 1;
+}
+#endif /* CONFIG_SYS_EARLY_MALLOC */
+
+#ifdef CONFIG_SYS_EARLY_MALLOC
+void *dmmalloc(size_t size)
+{
+ if (early_malloc_active())
+ return early_malloc(size);
+ return malloc(size);
+}
+#else /* CONFIG_SYS_EARLY_MALLOC */
+#define dmmalloc malloc
How is this actually supposed to work?
Of course, this have to be in the header file dmmalloc.h. Just ignore
the #else ... #endif part.
That won't work well either ... I'd say make the wrapper static inline for
typechecking, no ?
+#endif /* CONFIG_SYS_EARLY_MALLOC */
+
+#ifdef CONFIG_SYS_EARLY_MALLOC
+void dmfree(void *ptr)
+{
+ if (early_malloc_active())
+ return;
+ free(ptr);
+}
+#else /* CONFIG_SYS_EARLY_MALLOC */
+#define dmfree free
+#endif /* CONFIG_SYS_EARLY_MALLOC */
+
+#ifdef CONFIG_SYS_EARLY_MALLOC
+void *dmcalloc(size_t n, size_t elem_size)
+{
+ if (early_malloc_active())
+ return NULL;
+ return calloc(n, elem_size);
+}
+#else /* CONFIG_SYS_EARLY_MALLOC */
+#define dmcalloc calloc
+#endif /* CONFIG_SYS_EARLY_MALLOC */
+
+#ifdef CONFIG_SYS_EARLY_MALLOC
+void *dmrealloc(void *oldmem, size_t bytes)
+{
+ if (early_malloc_active())
+ return NULL;
+ return dmrealloc(oldmem, bytes);
+}
+#else /* CONFIG_SYS_EARLY_MALLOC */
+#define dmrealloc realloc
+#endif /* CONFIG_SYS_EARLY_MALLOC */
+
diff --git a/include/dmmalloc.h b/include/dmmalloc.h
new file mode 100644
index 000..726c6c9
--- /dev/null
+++ b/include/dmmalloc.h
@@ -0,0 +1,56 @@
+/*
+ * (C) Copyright 2012
+ * Tomas Hlavacek (tmshl...@gmail.com)
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef __INCLUDE_DMMALLOC_H
+#define __INCLUDE_DMMALLOC_H
+
+#include config.h
+#include linux/stddef.h /* for size_t */
+
+#if (!defined(CONFIG_SYS_EARLY_HEAP_ADDR)) || \
+ (!defined(CONFIG_SYS_EARLY_HEAP_SIZE))
+#undef CONFIG_SYS_EARLY_MALLOC
+#endif /* CONFIG_SYS_EARLY_HEAP_ADDR */
+
+#ifdef CONFIG_SYS_EARLY_MALLOC
+struct early_heap_header {
+ void *free_space_pointer;
+ size_t free_bytes;
+ void *next_early_heap;
+};
+
+struct early_heap_header *early_brk(size_t size);
+void *early_malloc(size_t size);
+
+#endif /* CONFIG_SYS_EARLY_MALLOC */
+
+#ifdef CONFIG_SYS_DM
Isn't it CONFIG_DM ?
I will change that. (Is it consistent with the naming convention? I
mean: What the _SYS_ exactly means?)
Tomas
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v2 4/6] musb-new: dsps backend driver
Dear Ilya Yanok, Dear Marek, On Sat, Sep 22, 2012 at 4:48 AM, Marek Vasut ma...@denx.de wrote: +COBJS-$(CONFIG_USB_MUSB_DSPS) += musb_dsps.o CONFIG_MUSB_... ? I'm following Linux here. We can change this, but should we? BTW, it looks to be in line with the current code where all USB lowlevel drivers have CONFIG_USB_* configuration options. ok Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Disabling video in bootm (cleanup_before_linux)
On Fri, Sep 21, 2012 at 2:44 PM, Eric Nelson eric.nel...@boundarydevices.com wrote: On 09/21/2012 10:22 AM, Anatolij Gustschin wrote: Hi Eric, On Fri, 21 Sep 2012 09:38:23 -0700 Eric Nelsoneric.nel...@boundarydevices.com wrote: Hi all, While looking into some trouble booting the latest Linux kernel patches for i.MX6 display support, I found that the kernel driver was thrown off by the interrupt status bits in the i.MX6 IPU. Until and unless we have the ability to hand off a 'live' display, it seems that we should disable the video driver as a part of the 'bootm' process. At the very least, doing this will avoid the possibility of trash on the display during the transition. I've been looking, and I don't see a place to tap into this process. It seems that having a shutdown routine for the display drivers (cfb_console?) is the way to go. cfb_console driver is a renderer of the characters and bitmaps to the framebuffer memory and is not a good place for a shutdown routine, I think. But we can add a shutdown function to the IPU driver drivers/video/mxc_ipuv3_fb.c and call it before booting. bootm code in common/cmd_bootm.c has a weak arch_preboot_os() function that can be overridden by platform specific preboot routine. We could define a preboot function in arch/arm/cpu/armv7/mx6/soc.c or in arch/arm/cpu/armv7/imx-common/cpu.c and call IPU shutdown routine in it. Thanks Anatolij. This is just what we need. I'll send a patch shortly. It would be nice to try to add support for mx5 too so we fix same boot hungs in mx5 kernels. I am adding Fabio in CC as he knows more about it. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] i.MX: mxc_ipuv3_fb: add ipuv3_fb_shutdown() routine to stop IPU before bootm
Hello Eric, On Fri, Sep 21, 2012 at 5:36 PM, Eric Nelson eric.nel...@boundarydevices.com wrote: Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com Did you test it in mx5 too? We seem to need to handle it in mx5 too as we had hungs in FSL kernel when using framebuffer in U-Boot. We're using a patch in kernel for workaround it but it seems your fix does what is need. Fabio did the workaround patch and knows the details. Added him in CC. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ELCE] Nov. 5.-7. meeting
On Fri, Sep 21, 2012 at 8:21 PM, Marek Vasut ma...@denx.de wrote: Hi guys, let's do some informal beer-drinking meeting at the ELCE [1] that takes place Nov. 5.-7. in Barcelona. Who's joining? [1] http://events.linuxfoundation.org/events/embedded-linux-conference-europe I'd like to meet you guys :-) I will be there :-D -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] pci: fix some warnings related to assumptions about
On Sep 21, 2012, at 5:34 PM, Anatolij Gustschin wrote:
Hi,
On Wed, 19 Sep 2012 09:47:36 -0500
Kumar Gala ga...@kernel.crashing.org wrote:
The following commit introduced some warnings associated with using
pci_addr_t instead of a proper 32-bit data type.
commit af778c6d9e2b945ee03cbc53bb976238a3374f33
Author: Andrew Sharp andywy...@gmail.com
Date: Wed Aug 1 12:27:16 2012 +
pci: fix errant data types and corresponding access functions
On some platforms pci_addr_t is defined as a 64-bit data type so its not
proper to use with pci_{read,write}_config_dword.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
drivers/pci/pci.c |6 +++---
drivers/pci/pci_auto.c |2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
Applied to staging/ag...@denx.de.
Thanks,
Anatolij
Thanks,
This should get in before v2012.10 is released
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/11] DM: add block device core
On Saturday 22 of September 2012 15:33:10 Marek Vasut wrote: Dear Pavel Herrmann, On Saturday 22 of September 2012 02:09:15 Marek Vasut wrote: Dear Pavel Herrmann, [...] one or none - requests on USB flashes should not pass through block_controller_driver. Uh, what do they pass into then ? their parent (an USB hub) block_device instance (aka. partition/disk) directly connected to USB hub instance does not seem right. why? It doesn't make sense ... you need some kind of interim controller (like the chip between the USB and NAND in the thumbdrive. yes, but you dont make drivers for every chip there is, instead the chips understand a common language, where you describe block operations by USB transfers, and that is exactly what saib block_device_usb_flash would do. every child of block_controller should be a block_device (not necessarily the other way around I doubt it's even possible to be the other way around. ), so there is no way you pass more instances block_controller on your way up. Ok, let me explain again. Let's look at the USB case to make it more real-world- ish. Imagine you have a thumb drive with 2 partitions. Thus you have two instances of struct block_device [denote BDp] for the partitions and one more for the whole disc [denote BDd]. When you read from partition, you end up poking BDp, which pushes the request up into BDd. This in turn calls USB-flashdisc- block_controller_driver [call it UFc]. For flash disc to read data, it needs to do some USB transfers. These are provided by USB host controller [UHC]. Thus you need some glue between UHC and UFc ... this is what I'm talking about. there should be no UFc, your BDd driver should talk directly to your UHC So my generic partition implementation (BDd) would have to implement USB flashdisc stuff, correct? This makes no sense. no. your generic USB flash would have to implement USB flashdisc stuff, your generic partition implements block_device operations on top of other block_device (aka diosk, memory card, USB flash) Ok, so in your parlance, the block_device is either partition/disc or a SD card controller driver or USB flashdisc driver ? You are mixing these two things together? please read the letters you came up with right. (maybe after getting some sleep by the looks of it) I'd prefer to read some documented code. im missing the point of this. you stateted that you have a partition BDp and a disk BDd. i said your BDd will sit above USB API, and you stared ranting about partitions implementing USB stuff, which was totaly off. the point you are not getting is that there should be more block_device drivers than there is now - one for partitions, one for disk, one for USB flash, one for SD and so on, each one using a different parent API Ok, now I understand your intention. Split it -- make partitions separate, since this is flat out confusing! Make partitions / whole disc a separate thing ... Make USB flash driver / SD card driver / etc. another thing ... You can not mix these two together, it makes no sense. well, disks, SD cards and USB flashes are one thing at the moment (see struct block_dev_desc). i am only adding partitions to the mix. (a driver that has blockdev API on one end, USB on the other) Ok, so how would this work, every partition implementation implements upcalls for all USB, SCSI, SATA, IDE, SD, ... and gazilion other types of drive it can sit on? no, partition only implements call onto another block device Ok, I see the issue at hand. In case of a regular drive, this implements the IO directly. In case of SD, this is a proxy object which interfaces with some SD-library and prepares the SD commands and then pushes that up into the controller to do the job? Same thing for USB flashes ? not every block device will have a block controller as a parent (or parent-of- parent in case of a partition). there would be a blockdev-usb that has a USB hub as a parent, and a blockdev-mmc, that has a mmc/sdio controller as a parent. So you would have a specific partition implementation for SD, SATA, IDE, SCSI, USB ... ? This is flawed. no, read above The partition should be a generic thing which knows nothing about where it's sitting at. So is the whole drive, same thing, it just has partitions hooked under it. I'd expect a block_controller to be the proxy object under which the block_device representing the disc is connected. And this block_controller to be proxifying the requests to the respective drivers (be it SD, SATA, whatever). your idea is wrong - you expect there will always be only one block_device representig a disk, and all the proxy would be done by the
Re: [U-Boot] [PATCH 1/3] mmc: sdhci: increase the timeout value for data transfer
Jaehoon Chung jh80.chung at samsung.com writes: Timeout value is tunable. When run read/write operation, sometime returned the timeout error. Because the timeout value is too short. Hello, I think it is better to fine tune CONFIG_SYS_MMC_MAX_BLK_COUNT. This gets assigned to mmc-b_max, unless you specifically set mmc-b_max value during mmc_register(). b_max is important since when you adjust b_max properly, mmc_bread() and mmc_bwrite() will properly partition the read/write operation (in b_max blocks) so that the timeout does not occur. All the best, Rommel (replying via gmane since i just joined the list) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-mpc85xx (for v2012.10)
Tom, Sorry for both sending this and the late request. I think Andy's been swamped with some chip bringup and lost notice of window (thus my sending this request). Would be good to get this stuff (and some fixes, etc) into v2012.10. Thanks - k The following changes since commit ee1f4caaa2a3f79d692155eec8a4c7289d60e106: Tom Rini (1): Prepare v2012.10-rc1 are available in the git repository at: git://git.denx.de/u-boot-mpc85xx.git master Andy Fleming (1): Revert powerpc: Fix declaration type for I/O functions Joakim Tjernlund (2): mpc85xx: Initial SP alignment is wrong. powerpc: Stack Pointer not properly aligned Kumar Gala (3): Add e6500 processor detection Add IFC offset for DPAA/Corenet platforms Added new ext fields to IFC Liu Gang (6): powerpc/corenet_ds: Update README.srio-boot-corenet powerpc/corenet_ds: Get rid of the SRIOBOOT_MASTER build target powerpc/corenet_ds: Get rid of the CONFIG_SRIOBOOT_SLAVE_PORTx macro powerpc/corenet_ds: Update README and README.srio-pcie-boot-corenet powerpc/corenet_ds: Master module for boot from PCIE powerpc/corenet_ds: Slave module for boot from PCIE Matthew McClintock (6): p1014rdb: set ddr bus width properly depending on SVR p1010rdb: fix ddr values for p1014rdb (setting bus width to 16bit) powerpc/p1010rdb: nandboot: compare SVR properly nand_spl: update udelay for Freescale boards nand_spl: p1023rds: wait before enabling DDR controller nand_spl: change out_be32 to raw_writel and depend on subsequent sync Paul Gortmaker (1): mpc85xx: use LCRR_DBYP define instead of raw constant Prabhakar Kushwaha (2): powerpc/mpc85xx:Enable debugger support to missed e500v2 SoC powerpc/mpc85xx: Add IFC LAW target ID for FSL High-End SoC Scott Wood (6): nand/fsl_elbc: shrink SPL a bit by converting out_be32() to __raw_writel() powerpc/fsl-corenet: remove dead variant symbols powerpc/fsl-corenet: work around erratum A004510 powerpc/85xx: clear out TLB on boot powerpc/p1_p2_rdb_pc: print -PC suffix in board name powerpc/mpc85xx/p1_p2_rdb: add all LAWs during SPL Shaohui Xie (1): powerpc/CoreNet: add tool to support pbl image build. Timur Tabi (6): powerpc/85xx: add support for FM2 DTSEC5 fm-eth: add function fm_info_get_phy_address() powerpc/85xx: introduce function serdes_device_from_fm_port() fm-eth: use fdt_status_disabled() function in ft_fixup_port() powerpc/85xx: get rid of enum board_slots in P4080 MDIO driver powerpc/85xx: remove support for the Freescale P3060 York Sun (14): powerpc/mpc85xx: Make NMG_CPU_A011 workaround conditional powerpc/mpc8xxx: Remove P1015 and P1016 from CPU list powerpc/mpc8xxx: Add immap for topology and rcpm registers powerpc/mpc8xxx: use topology registers to calculate number of cores powerpc/mpc8xxx: fix core id for multicore booting powerpc/mpc85xx: Skip zero values for DDR debug registers powerpc/mpc8xxx: Add fine timing support for DDR3 powerpc/mpc8xxx: Add support for cas latency 12 and above powerpc/mpc8xxx: Enable 3-way and 4-way DDR interleaving powerpc/mpc8xxx: Fix bug for extended DDR timing powerpc/mpc8xxx DDR: Fix CAS latency calculation powerpc/mpc8xxx DDR: Fall back to raw timing for first controller only powerpc/mpc8xxx DDR: Fix interactive DDR debugging powerpc/mpc8xxx: Move HWCONFIG_BUFFER_SIZE into config.h Makefile |6 + README | 37 +- arch/powerpc/cpu/mpc85xx/Makefile | 10 - arch/powerpc/cpu/mpc85xx/cmd_errata.c |9 +- arch/powerpc/cpu/mpc85xx/cpu.c | 15 +- arch/powerpc/cpu/mpc85xx/cpu_init.c| 52 ++- arch/powerpc/cpu/mpc85xx/ddr-gen3.c| 26 +- arch/powerpc/cpu/mpc85xx/fdt.c |7 +- arch/powerpc/cpu/mpc85xx/fsl_corenet_serdes.c |8 +- arch/powerpc/cpu/mpc85xx/p3060_ids.c | 117 - arch/powerpc/cpu/mpc85xx/p3060_serdes.c| 118 - arch/powerpc/cpu/mpc85xx/release.S | 87 +++- arch/powerpc/cpu/mpc85xx/speed.c |3 +- arch/powerpc/cpu/mpc85xx/start.S | 376 +-- arch/powerpc/cpu/mpc8xxx/cpu.c | 68 ++- arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c | 223 - arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c| 25 +- arch/powerpc/cpu/mpc8xxx/ddr/interactive.c | 26 +- .../cpu/mpc8xxx/ddr/lc_common_dimm_params.c| 18 +- arch/powerpc/cpu/mpc8xxx/ddr/main.c| 307 +++-- arch/powerpc/cpu/mpc8xxx/ddr/options.c | 212 ++--- arch/powerpc/cpu/mpc8xxx/ddr/util.c| 67 ++-
Re: [U-Boot] [PATCH 1/2] i.MX: mxc_ipuv3_fb: add ipuv3_fb_shutdown() routine to stop IPU before bootm
On Sat, Sep 22, 2012 at 10:42 AM, Otavio Salvador ota...@ossystems.com.br wrote: Hello Eric, On Fri, Sep 21, 2012 at 5:36 PM, Eric Nelson eric.nel...@boundarydevices.com wrote: Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com Did you test it in mx5 too? We seem to need to handle it in mx5 too as we had hungs in FSL kernel when using framebuffer in U-Boot. We're using a patch in kernel for workaround it but it seems your fix does what is need. I have just tested Eric's series on a mx53loco and it does fix the kernel hang issue. I made some comments on this series and hopefully Eric's v2 can get into 2012.10, since this is a bug fix. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] i.MX: mxc_ipuv3_fb: add ipuv3_fb_shutdown() routine to stop IPU before bootm
On Sat, Sep 22, 2012 at 11:37 AM, Fabio Estevam feste...@gmail.com wrote: On Sat, Sep 22, 2012 at 10:42 AM, Otavio Salvador ota...@ossystems.com.br wrote: Hello Eric, On Fri, Sep 21, 2012 at 5:36 PM, Eric Nelson eric.nel...@boundarydevices.com wrote: Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com Did you test it in mx5 too? We seem to need to handle it in mx5 too as we had hungs in FSL kernel when using framebuffer in U-Boot. We're using a patch in kernel for workaround it but it seems your fix does what is need. I have just tested Eric's series on a mx53loco and it does fix the kernel hang issue. I made some comments on this series and hopefully Eric's v2 can get into 2012.10, since this is a bug fix. Neat. :-) -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC - PatchTrack Specification (revised)
Dear Graeme Russ, [...] Are we getting anywhere with this? 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 V4] i.MX6: mx6qsabrelite: Add splash screen support
Hi Eric, On Fri, Sep 21, 2012 at 7:53 PM, Eric Nelson eric.nel...@boundarydevices.com wrote: Adds support for two LVDS panels and one RGB panel to the SABRE-Lite board: Hannstar-XGA - 1024 x 768 LVDS (Freescale part number MCIMX-LVDS1) wsvga-lvds - 1024 x 600 LVDS (Boundary p/n Nit6X_1024x600) wvga-rgb - 800 x 480 RGB (Boundary p/n Nit6X_800x480) Auto-detects panel by probing the I2C touch controller of each. That's a nice solution! Is HDMI splash screen support also in the pipeline? Thanks, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Disabling video in bootm (cleanup_before_linux)
On 09/22/2012 06:35 AM, Otavio Salvador wrote: On Fri, Sep 21, 2012 at 2:44 PM, Eric Nelson eric.nel...@boundarydevices.com wrote: On 09/21/2012 10:22 AM, Anatolij Gustschin wrote: Hi Eric, On Fri, 21 Sep 2012 09:38:23 -0700 Eric Nelsoneric.nel...@boundarydevices.com wrote: Hi all, While looking into some trouble booting the latest Linux kernel patches for i.MX6 display support, I found that the kernel driver was thrown off by the interrupt status bits in the i.MX6 IPU. Until and unless we have the ability to hand off a 'live' display, it seems that we should disable the video driver as a part of the 'bootm' process. At the very least, doing this will avoid the possibility of trash on the display during the transition. I've been looking, and I don't see a place to tap into this process. It seems that having a shutdown routine for the display drivers (cfb_console?) is the way to go. cfb_console driver is a renderer of the characters and bitmaps to the framebuffer memory and is not a good place for a shutdown routine, I think. But we can add a shutdown function to the IPU driver drivers/video/mxc_ipuv3_fb.c and call it before booting. bootm code in common/cmd_bootm.c has a weak arch_preboot_os() function that can be overridden by platform specific preboot routine. We could define a preboot function in arch/arm/cpu/armv7/mx6/soc.c or in arch/arm/cpu/armv7/imx-common/cpu.c and call IPU shutdown routine in it. Thanks Anatolij. This is just what we need. I'll send a patch shortly. It would be nice to try to add support for mx5 too so we fix same boot hungs in mx5 kernels. I am adding Fabio in CC as he knows more about it. Hi Otavio, I believe it will work on MX5 boards as well, though I haven't tested. http://patchwork.ozlabs.org/patch/185928/ Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Disabling video in bootm (cleanup_before_linux)
On Sat, Sep 22, 2012 at 12:35 PM, Eric Nelson eric.nel...@boundarydevices.com wrote: On 09/22/2012 06:35 AM, Otavio Salvador wrote: On Fri, Sep 21, 2012 at 2:44 PM, Eric Nelson eric.nel...@boundarydevices.com wrote: On 09/21/2012 10:22 AM, Anatolij Gustschin wrote: Hi Eric, On Fri, 21 Sep 2012 09:38:23 -0700 Eric Nelsoneric.nel...@boundarydevices.com wrote: Hi all, While looking into some trouble booting the latest Linux kernel patches for i.MX6 display support, I found that the kernel driver was thrown off by the interrupt status bits in the i.MX6 IPU. Until and unless we have the ability to hand off a 'live' display, it seems that we should disable the video driver as a part of the 'bootm' process. At the very least, doing this will avoid the possibility of trash on the display during the transition. I've been looking, and I don't see a place to tap into this process. It seems that having a shutdown routine for the display drivers (cfb_console?) is the way to go. cfb_console driver is a renderer of the characters and bitmaps to the framebuffer memory and is not a good place for a shutdown routine, I think. But we can add a shutdown function to the IPU driver drivers/video/mxc_ipuv3_fb.c and call it before booting. bootm code in common/cmd_bootm.c has a weak arch_preboot_os() function that can be overridden by platform specific preboot routine. We could define a preboot function in arch/arm/cpu/armv7/mx6/soc.c or in arch/arm/cpu/armv7/imx-common/cpu.c and call IPU shutdown routine in it. Thanks Anatolij. This is just what we need. I'll send a patch shortly. It would be nice to try to add support for mx5 too so we fix same boot hungs in mx5 kernels. I am adding Fabio in CC as he knows more about it. Hi Otavio, I believe it will work on MX5 boards as well, though I haven't tested. http://patchwork.ozlabs.org/patch/185928/ Yes; Fabio tested it and it proved to work. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] mx6: Remove lowlevel_init.S
From: Fabio Estevam fabio.este...@freescale.com lowlevel_init.S is not used on mx6, so remove the file and the associated calls. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Changes since v1: - Also remove SOBJS arch/arm/cpu/armv7/mx6/Makefile|5 ++--- arch/arm/cpu/armv7/mx6/lowlevel_init.S | 25 - arch/arm/cpu/armv7/start.S | 24 3 files changed, 2 insertions(+), 52 deletions(-) delete mode 100644 arch/arm/cpu/armv7/mx6/lowlevel_init.S diff --git a/arch/arm/cpu/armv7/mx6/Makefile b/arch/arm/cpu/armv7/mx6/Makefile index cbce411..10f512f 100644 --- a/arch/arm/cpu/armv7/mx6/Makefile +++ b/arch/arm/cpu/armv7/mx6/Makefile @@ -28,10 +28,9 @@ include $(TOPDIR)/config.mk LIB= $(obj)lib$(SOC).o COBJS = soc.o clock.o -SOBJS = lowlevel_init.o -SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) -OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS)) +SRCS := $(COBJS:.o=.c) +OBJS := $(addprefix $(obj), $(COBJS)) all: $(obj).depend $(LIB) diff --git a/arch/arm/cpu/armv7/mx6/lowlevel_init.S b/arch/arm/cpu/armv7/mx6/lowlevel_init.S deleted file mode 100644 index acadef2..000 --- a/arch/arm/cpu/armv7/mx6/lowlevel_init.S +++ /dev/null @@ -1,25 +0,0 @@ -/* - * Copyright (C) 2010-2011 Freescale Semiconductor, Inc. - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License as - * published by the Free Software Foundation; either version 2 of - * the License, or (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, - * MA 02111-1307 USA - */ -.section .text.init, x - -#include linux/linkage.h - -ENTRY(lowlevel_init) - mov pc, lr -ENDPROC(lowlevel_init) diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index 32658eb..4c7c385 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -152,7 +152,6 @@ reset: /* the mask ROM code should have PLL and others stable */ #ifndef CONFIG_SKIP_LOWLEVEL_INIT bl cpu_init_cp15 - bl cpu_init_crit #endif /* Set stackpointer in internal RAM to call board_init_f */ @@ -353,29 +352,6 @@ ENTRY(cpu_init_cp15) mov pc, lr @ back to my caller ENDPROC(cpu_init_cp15) -#ifndef CONFIG_SKIP_LOWLEVEL_INIT -/* - * - * CPU_init_critical registers - * - * setup important registers - * setup memory timing - * - */ -ENTRY(cpu_init_crit) - /* -* Jump to board specific initialization... -* The Mask ROM will have already initialized -* basic memory. Go here to bump up clock rate and handle -* wake up conditions. -*/ - mov ip, lr @ persevere link reg across call - bl lowlevel_init @ go setup pll,mux,memory - mov lr, ip @ restore link - mov pc, lr @ back to my caller -ENDPROC(cpu_init_crit) -#endif - #ifndef CONFIG_SPL_BUILD /* * -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4] i.MX6: mx6qsabrelite: Add splash screen support
On 09/22/2012 08:12 AM, Fabio Estevam wrote: Hi Eric, On Fri, Sep 21, 2012 at 7:53 PM, Eric Nelson eric.nel...@boundarydevices.com wrote: Adds support for two LVDS panels and one RGB panel to the SABRE-Lite board: Hannstar-XGA - 1024 x 768 LVDS (Freescale part number MCIMX-LVDS1) wsvga-lvds - 1024 x 600 LVDS (Boundary p/n Nit6X_1024x600) wvga-rgb - 800 x 480 RGB (Boundary p/n Nit6X_800x480) Auto-detects panel by probing the I2C touch controller of each. That's a nice solution! Is HDMI splash screen support also in the pipeline? Yep. I want to get that one done before we add a second board which uses this structure. Interestingly, I saw U-Boot display on HDMI during my testing, so I'm pretty certain that all we need is the HDMI transmitter initialization sequence. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 00/21] Add mx6solo/mx6duallite support
On 9/21/2012 11:21 PM, Dirk Behme wrote: Hi Troy, On 22.09.2012 04:38, Troy Kisky wrote: After this series the same binary will run on a Saberlite board using any of the pin compatible processors mx6 quad, mx6 duallite, or mx6 solo. This is accomplished using a plugin and a table built by mkimage. Could you briefly explain or give a link to some documentation how this does work? It sounds to me that the plugin concept is something the boot ROM has to understand? Or in other words: How does the boot ROM decide on which processor it runs and which DCD table to execute then? Sorry if I misunderstood something, I'm not so familiar with the boot ROM options. Many thanks Dirk The table generated by mkimage for use with the plugin is not a standard ROM decodable table. Only the plugin itself will decode the table. After it processes the table to initialize memory, it calls back into the ROM to finish the u-boot load. see file arch/arm/include/asm/arch-mx6/imx-mkimage.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] common/lcd: fix build breakage for at91sam9x5ek and trats boards
Commit 203c37b8c5556aad1901ce4954792afd718c7d42 (common lcd: simplify core functions) and commit bfdcc65e1163b4891643c2a670570c478b9af2a4 (common lcd: simplify lcd_display_bitmap) caused build breakage for at91sam9x5ek board configurations and for trats board. Fix these build errors. Signed-off-by: Anatolij Gustschin ag...@denx.de --- common/lcd.c | 14 ++ 1 files changed, 10 insertions(+), 4 deletions(-) diff --git a/common/lcd.c b/common/lcd.c index fcc09ac..b6be800 100644 --- a/common/lcd.c +++ b/common/lcd.c @@ -509,8 +509,14 @@ static inline ushort *configuration_get_cmap(void) return (ushort *)(cp-lcd_cmap[255 * sizeof(ushort)]); #elif defined(CONFIG_ATMEL_LCD) return (ushort *)(panel_info.mmio + ATMEL_LCDC_LUT(0)); +#elif !defined(CONFIG_ATMEL_HLCD) !defined(CONFIG_EXYNOS_FB) + return panel_info.cmap; #else - return (ushort *)panel_info.cmap; +#if defined(CONFIG_LCD_LOGO) + return bmp_logo_palette; +#else + return NULL; +#endif #endif } @@ -636,10 +642,10 @@ static void splash_align_axis(int *axis, unsigned long panel_size, } #endif -#if defined CONFIG_CPU_PXA || defined(CONFIG_ATMEL_LCD) -#define FB_PUT_BYTE(fb, from) *(fb)++ = *(from)++ -#elif defined(CONFIG_MPC823) || defined(CONFIG_MCC200) +#if defined(CONFIG_MPC823) || defined(CONFIG_MCC200) #define FB_PUT_BYTE(fb, from) *(fb)++ = (255 - *(from)++) +#else +#define FB_PUT_BYTE(fb, from) *(fb)++ = *(from)++ #endif #if defined(CONFIG_BMP_16BPP) -- 1.7.7.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] h2200: Add support for iPAQ h2200
On 19.09.2012 23:02, Marek Vasut wrote:
and at the offset
+ * 0x40 ascii characters 'ECEC', secondly 1st stage
+ * loads code from flash into SDRAM at address 0xa004
+ * so all instructions which reinitializes memory
+ * controller have to be disabled.
+ */
+
+static inline void writelrb(uint32_t val, uint32_t addr)
Replace this with clrsetbits_le32()
I've copied writelrb and pxa2xx_dram_init from pxa2xx.c
and I think there is a reason why it's done that way and not by
clrsetbits_le32. But if you insist I can replace all calls to writelrb
by clrsetbits.
+{
+ writel(val, addr);
+ asm volatile( : : : memory);
+ readl(addr);
+ asm volatile( : : : memory);
+}
+
+static void h2200_pxa2xx_dram_init(void)
Why do you duplicate it ?!
[...]
Because code in pxa2xx.c disable and then re-enable memory.
And u-boot is executed from memory (1st stage bootloder
copied it there).
+
+# define CONFIG_USB_ETHER 1
+# define CONFIG_USBNET_DEV_ADDRde:ad:be:ef:00:01
+# define CONFIG_USBNET_HOST_ADDR de:ad:be:ef:00:02
Definitelly not, any mac address setting should not be present, Joe ?
So tell me how should I specify mac addresses? By EXTRA_ENV_SETTINGS?
Łukasz Dałek
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4] i.MX6: mx6qsabrelite: Add splash screen support
Hi Eric, On Sat, Sep 22, 2012 at 1:51 PM, Eric Nelson eric.nel...@boundarydevices.com wrote: Interestingly, I saw U-Boot display on HDMI during my testing, so I'm pretty certain that all we need is the HDMI transmitter initialization sequence. Excellent, could you please share the HDMI transmitter init sequence? Thanks, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] h2200: Add support for iPAQ h2200
Dear Łukasz Dałek,
On 19.09.2012 23:02, Marek Vasut wrote:
and at the offset
+ * 0x40 ascii characters 'ECEC', secondly 1st stage
+ * loads code from flash into SDRAM at address 0xa004
+ * so all instructions which reinitializes memory
+ * controller have to be disabled.
+ */
+
+static inline void writelrb(uint32_t val, uint32_t addr)
Replace this with clrsetbits_le32()
I've copied writelrb and pxa2xx_dram_init from pxa2xx.c
and I think there is a reason why it's done that way and not by
clrsetbits_le32. But if you insist I can replace all calls to writelrb
by clrsetbits.
And can you elaborate on the reason please?
(hint: clrsetbits() wasn't there by the time)
+{
+ writel(val, addr);
+ asm volatile( : : : memory);
+ readl(addr);
+ asm volatile( : : : memory);
+}
+
+static void h2200_pxa2xx_dram_init(void)
Why do you duplicate it ?!
[...]
Because code in pxa2xx.c disable and then re-enable memory.
And u-boot is executed from memory (1st stage bootloder
copied it there).
So don't reinit the memory at all, just skip this whole part.
+
+# define CONFIG_USB_ETHER 1
+# define CONFIG_USBNET_DEV_ADDRde:ad:be:ef:00:01
+# define CONFIG_USBNET_HOST_ADDR de:ad:be:ef:00:02
Definitelly not, any mac address setting should not be present, Joe ?
So tell me how should I specify mac addresses? By EXTRA_ENV_SETTINGS?
Joe explained it, your adapter doesn't carry it's own mac?
Łukasz Dałek
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 17/21] mx6: soc: add get_cpu_type
On 9/21/2012 7:50 PM, Fabio Estevam wrote:
Hi Troy,
On Fri, Sep 21, 2012 at 11:39 PM, Troy Kisky
troy.ki...@boundarydevices.com wrote:
Add function to return the processor type.
i.e. MX6Q, MX6DL, MX6SOLO, MX6SOLOLITE
On arch/arm/imx-common/cpu.c we have:
static const char *get_imx_type(u32 imxtype)
{
switch (imxtype) {
case 0x63:
return 6Q; /* Quad-core version of the mx6 */
case 0x61:
return 6DS; /* Dual/Solo version of the mx6 */
case 0x60:
return 6SL; /* Solo-Lite version of the mx6 */
case 0x51:
return 51;
case 0x53:
return 53;
default:
return ??;
}
}
,which seems to serve the same purpose.
Regards,
Fabio Estevam
No, not similar to get_imx_type, but it is similar to get_cpu_rev.
I guess I should fix get_imx_type, and get_cpu_rev, instead of
adding a new one.
Thanks for the heads up!
Troy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] h2200: Add support for iPAQ h2200
On 22.09.2012 19:04, Marek Vasut wrote:
Dear Łukasz Dałek,
On 19.09.2012 23:02, Marek Vasut wrote:
and at the offset
+ * 0x40 ascii characters 'ECEC', secondly 1st stage
+ * loads code from flash into SDRAM at address 0xa004
+ * so all instructions which reinitializes memory
+ * controller have to be disabled.
+ */
+
+static inline void writelrb(uint32_t val, uint32_t addr)
Replace this with clrsetbits_le32()
I've copied writelrb and pxa2xx_dram_init from pxa2xx.c
and I think there is a reason why it's done that way and not by
clrsetbits_le32. But if you insist I can replace all calls to writelrb
by clrsetbits.
And can you elaborate on the reason please?
(hint: clrsetbits() wasn't there by the time)
I don't know what was the reason. I didn't change becuse I didn't
want to break it.
+{
+ writel(val, addr);
+ asm volatile( : : : memory);
+ readl(addr);
+ asm volatile( : : : memory);
+}
+
+static void h2200_pxa2xx_dram_init(void)
Why do you duplicate it ?!
[...]
Because code in pxa2xx.c disable and then re-enable memory.
And u-boot is executed from memory (1st stage bootloder
copied it there).
So don't reinit the memory at all, just skip this whole part.
1st stage loader doesn't init everything (for example MSC).
+
+# define CONFIG_USB_ETHER 1
+# define CONFIG_USBNET_DEV_ADDRde:ad:be:ef:00:01
+# define CONFIG_USBNET_HOST_ADDR de:ad:be:ef:00:02
Definitelly not, any mac address setting should not be present, Joe ?
So tell me how should I specify mac addresses? By EXTRA_ENV_SETTINGS?
Joe explained it, your adapter doesn't carry it's own mac?
No.
Łukasz Dałek
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 18/21] arch-mx6: add mx6dl_pins.h
On 9/21/2012 9:10 PM, Vikram Narayanan wrote: On 9/22/2012 8:09 AM, Troy Kisky wrote: Only the values used in the sabrelite board are added currently. Add more as other boards use them. Though there are no users, better add it for completeness. This should also avoid people patching this file often. U-boot has a policy of not adding dead code. One patch per added board will not cause a burden. Also, since the entries are sorted, merge conflicts should be rare. Troy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4] i.MX6: mx6qsabrelite: Add splash screen support
On 09/22/2012 10:02 AM, Fabio Estevam wrote: Hi Eric, On Sat, Sep 22, 2012 at 1:51 PM, Eric Nelson eric.nel...@boundarydevices.com wrote: Interestingly, I saw U-Boot display on HDMI during my testing, so I'm pretty certain that all we need is the HDMI transmitter initialization sequence. Excellent, could you please share the HDMI transmitter init sequence? Hi Fabio, I haven't worked through the details, but I'm sure they're in here ;) https://github.com/boundarydevices/linux-imx6/blob/boundary-L3.0.35_MX6DQ_ER_1208-Beta/drivers/video/mxc_hdmi.c Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 19/21] mx6qsabrelite: add support for mx6 solo/duallite
On 9/21/2012 9:12 PM, Vikram Narayanan wrote:
On 9/22/2012 8:09 AM, Troy Kisky wrote:
Signed-off-by: Troy Kiskytroy.ki...@boundarydevices.com
---
board/freescale/mx6qsabrelite/mx6qsabrelite.c | 231
++---
board/freescale/mx6qsabrelite/pads.h | 172
++
2 files changed, 226 insertions(+), 177 deletions(-)
create mode 100644 board/freescale/mx6qsabrelite/pads.h
diff --git a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
index 4b4e89b..ad2347d 100644
--- a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
+++ b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
@@ -26,6 +26,8 @@
#includeasm/arch/imx-regs.h
#includeasm/arch/iomux.h
#includeasm/arch/mx6x_pins.h
+#includeasm/arch/mx6dl_pins.h
+#includeasm/arch/sys_proto.h
#includeasm/errno.h
#includeasm/gpio.h
#includeasm/imx-common/iomux-v3.h
@@ -38,163 +40,46 @@
#includenetdev.h
DECLARE_GLOBAL_DATA_PTR;
-#define UART_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE | \
- PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \
- PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST | PAD_CTL_HYS)
+#include pads.h
+#define FOR_DL_SOLO
+#include pads.h
-#define USDHC_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE | \
- PAD_CTL_PUS_47K_UP | PAD_CTL_SPEED_LOW | \
- PAD_CTL_DSE_80ohm | PAD_CTL_SRE_FAST | PAD_CTL_HYS)
+int cpu_is_mx6q(void)
+{
+return get_cpu_type() == MXC_CPU_MX6Q;
+}
-#define ENET_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE |\
-PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED |\
-PAD_CTL_DSE_40ohm | PAD_CTL_HYS)
+#define IOMUX_SETUP(list) iomux_setup(mx6q_##list,
ARRAY_SIZE(mx6q_##list), \
+mx6dl_solo_##list, ARRAY_SIZE(mx6dl_solo_##list))
-#define SPI_PAD_CTRL (PAD_CTL_HYS |\
-PAD_CTL_PUS_100K_DOWN | PAD_CTL_SPEED_MED |\
-PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST)
+int iomux_setup(iomux_v3_cfg_t *mx6q_pad_list, int mx6q_pad_cnt,
+iomux_v3_cfg_t *mx6dl_solo_pad_list, int mx6dl_solo_pad_cnt)
+{
+int mx6q = cpu_is_mx6q();
+iomux_v3_cfg_t *p = mx6q ? mx6q_pad_list : mx6dl_solo_pad_list;
+int cnt = mx6q ? mx6q_pad_cnt : mx6dl_solo_pad_cnt;
-#define BUTTON_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE |\
-PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED |\
-PAD_CTL_DSE_40ohm | PAD_CTL_HYS)
+return imx_iomux_v3_setup_multiple_pads(p, cnt);
+}
-#define I2C_PAD_CTRL(PAD_CTL_PKE | PAD_CTL_PUE |\
-PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED |\
-PAD_CTL_DSE_40ohm | PAD_CTL_HYS |\
-PAD_CTL_ODE | PAD_CTL_SRE_FAST)
+static const unsigned char col_lookup[] = {9, 10, 11, 8, 12, 9, 9, 9};
+static const unsigned char bank_lookup[] = {3, 2};
int dram_init(void)
{
- gd-ram_size = get_ram_size((void *)PHYS_SDRAM,
PHYS_SDRAM_SIZE);
-
- return 0;
+unsigned mdctl = readl(MMDC_P0_BASE_ADDR + 0x000);
+unsigned mdmisc = readl(MMDC_P0_BASE_ADDR + 0x018);
+int bits = 11 + 0 + 0 + 1; /* row+col+bank+width */
+
+bits += (mdctl 24) 7; /* row */
+bits += col_lookup[(mdctl 20) 7]; /* col */
+bits += bank_lookup[(mdmisc 5) 1]; /* bank */
+bits += (mdctl 16) 3; /* width */
+bits += (mdctl 30) 1; /* cs1 enabled*/
+gd-ram_size = 1 bits;
+return 0;
}
No magic numbers please. Replace it with macros.
Right, will move to a common file as well so that other may use it.
Troy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 15/21] mx6q_4x_mt41j128.cfg: reorder for more efficient storage
Hi Troy, On Fri, Sep 21, 2012 at 11:39 PM, Troy Kisky troy.ki...@boundarydevices.com wrote: Repeating data values can be stored more efficiently. Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com I am not a ddr init expert, but my understanding is that the DDR init sequence is important and probably we should keep it as is. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 15/21] mx6q_4x_mt41j128.cfg: reorder for more efficient storage
On 9/22/2012 10:27 AM, Fabio Estevam wrote: Hi Troy, On Fri, Sep 21, 2012 at 11:39 PM, Troy Kisky troy.ki...@boundarydevices.com wrote: Repeating data values can be stored more efficiently. Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com I am not a ddr init expert, but my understanding is that the DDR init sequence is important and probably we should keep it as is. Regards, Fabio Estevam The order of writes to IOMUXC registers is not important, other than to be finished before accessing the DDR chips. Troy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: lacie_kw: add support for WIRELESS_SPACE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/22/12 01:51, Albert ARIBAUD wrote: Hi Simon, On Wed, 22 Aug 2012 17:16:21 +0200, Simon Guinot simon.gui...@sequanux.org wrote: On Tue, Aug 21, 2012 at 12:16:40AM -0700, Prafulla Wadaskar wrote: -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot- boun...@lists.denx.de] On Behalf Of Albert ARIBAUD Sent: 18 August 2012 02:59 To: Tom Rini Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] ARM: lacie_kw: add support for WIRELESS_SPACE Hi Tom, On Fri, 17 Aug 2012 10:55:38 -0700, Tom Rini tr...@ti.com wrote: On Thu, Aug 16, 2012 at 08:08:34PM +0200, Albert ARIBAUD wrote: Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net [snip] @@ -90,8 +100,14 @@ #define CONFIG_SYS_IDE_MAXDEVICE 1 #if defined(CONFIG_NET2BIG_V2) #define CONFIG_SYS_PROMPT2big2 -#else +#elif defined(CONFIG_NETSPACE_V2) #define CONFIG_SYS_PROMPT ns2 +#elif defined(CONFIG_INETSPACE_V2) +#define CONFIG_SYS_PROMPTis2 +#elif defined(CONFIG_WIRELESS_SPACE) +#define CONFIG_SYS_PROMPT ws +#else +#define CONFIG_SYS_PROMPT lacie-kw Is this really a good thing? Over here I've been trying / hoping to get everyone to just use 'U-Boot # ' as the prompt as this makes automated testing easier and there's other run-time ways to see what we're on. I personally vote to have common boot prompt 'U-boot #'. I quite like prompts that identify the board I'm on, but it's not a must either. Cc:ing Simon in cas his own patches re lacie_kw would be impacted by your suggestion. Well, we can expose a command to detect/print the board info, if needed. The run-time command version already returns both the system and the machine informations. This command can be used for testing purposes. IMHO the only requirement for an U-Boot prompt is to be short enough. Everything else is a matter of taste. Mine goes for the machine name. Regards, Simon Tom, Can automated test cope with a general prompt of the form '.*#' ? Sure, probably. It's really just something that popped into my head rather than a hard requirement or anything. It's also possible to just setup your testing framework to take the prompt as a variable, so this is just a personal preference thing. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQXfeOAAoJENk4IS6UOR1W0tUP/RIANji/ltjv29q/64C7Q6Vo JreBmUcXI3BcUF13WIH8SVwW80DG0J29Pa2k2t9X+UxvXwXvv2eJCdEk5Pq6Fu4u ksHS58kca/ufA5Rb+6JlvlCbLwet9kfyyk+4At5D4DfFnAX0XqbhfbkaA5Qay+U5 fccb9R8bY+HD3A5euKKLMZDP3bKij9293yJIOuaD6BIw8qVSkcy+a4Zgm4PvlPsx b6W04IGW1w1NEArej2gpDutawDGfTulFpfFzNnR1a4BnxyII+VzZxuIMdbyc7MLc /nbeSynRh35af892Xuzx6NCtpASYvN776BGws0kNLcR699pA0BcMRSCVaOKVpF3P wMkx6bUXQQ0FsvLy5OD5yJt2xSNLSxbIAV/ZiU3GsZ4AbWrmKhax53+XRcWmasPa HyhozQ0/lMaSkK4KOu6LHmRSHrSSEsUmJnVzyjWm7BOb+IY0WHntq47A+T8QoMuF foed5J0ON5XRHDzbzk34pPBdfg+qCIc4+PQ2XsiRYJe+T3DNOCZgOwByzo0sasRh EC53I2Q95fQsafhgSs0EVCw0nJIa1z0uWEnQIH0K6gyffkNGyj1UPkLPf+qva+t0 GJXqwkgRfvjO/MQIN+SFn6flMKfxgobqztcDck5tvS+8s5mMZtsoy24F6jW/znXo 2Cqs4OFBzE5Efbv1PWcC =DhtF -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v2 0/6] Port of MUSB driver from Linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/21/12 17:55, Marek Vasut wrote: Dear Ilya Yanok, Current MUSB driver in U-Boot uses old UDC API while new gagdet client drivers need new gadget API. Also current MUSB driver has some significant limitations (like inability to handle tx for endpoints other than ep0). So I think port of new Linux driver is desirable. This is initial port, performed mostly by putting DM and OTG code under #ifndef __UBOOT__ clauses. My intention was to be as close as possible to the original to ease of possible resyncs. Some warnings are suppressed via CFLAGS. There are some style problems but I'm not touching them for now for the above mentioned reason. There is obviously some room for optimisation, some structure fields are unused as well as (probably) some code. This is not a replacement for existing MUSB driver (at least for now), cause there are still consumers of the old interface and the only ported backend is for TI AM335X (while the old code has a bunch of other backends). OTG and DMA are not supported. The only ported driver is for TI AM33xx, but others should be easy to port too. Virtual root hub is not implemented but this shouldn't be a big problem as the old code has virtual root hub support enabled only for Blackfin platform. Tested it on AM335x EVM and BeagleBone with CDC Ethernet gadget and a bunch of storage devices. Pathes are rather big because of the original code size (and I didn't delete unused code, just disabled it). So it's probably better to look at changes as compared to Linux code. I prepared such version also, you can find it at [1]. Hopefully it will be also useful if resync with the kernel will be needed in future. [1] https://github.com/yanok/u-boot/tree/musb-changes-from-linux [...] I'm glad about this. But how can we make this work if we already have a driver for this in u-boot, now we will have another. Tom ? Part of our pain point here is that, if I'm following everything right, we're switching from our home-grown MUSB framework to the kernel one. The good thing is that there's not many users of the existing framework. Being able to switch to a codebase we can re-sync with the kernel for is a good thing. It comes down to how much of an effort it is to convert and leave untested the other platforms. The good news I believe is that aside from am335x everything else already has a kernel portion to work from. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQXfj2AAoJENk4IS6UOR1WOaYP/2GyTGP2GLxu6R7NymMqXp4N Q2G3qe7wfBMr89ISqYc05QNXnSBcmEgklMoNr2u4XXws4hvtDawX+KGshJfDlPJD r9LNWygZ3bPi39d/hrzgjgdrICZLcl6BqArgNSrj0UDhOdW5u5Xh1jK2h9113IVI 2SYcTyWtFgcgCZ7GIk3nd6z7RqMaFarTywKEiShP3hzcS1MVVqodk7js129jEORS e6WdNK4ijg9xaMY93eprIg7Lr9B4OttLt/Xwo96gQO0ww5tHDY+zZaZ30UXBj9HT mBIYlAvE9eA53Z5QhX6pUcfUZvg5zWvaYNhXqGnRe7frrA+t2PomKk6WFS7vJ+JM BT9fDR75n3cXcXwcKm9E0vxNAU9NHMEuLH78erdoJWwTir4F7gFRkg7ykGeQhXl8 W+UFG76OVVSaoSjiEU6XQf34j4OHG1ynej7xCklFBBY57i3n3cuhSN33TpyvfzpW bfwJjYBFhwZT7y9jEAJIKMeul28hWINPVarE/gOFeCoFJbVu+ZqI7HSg6Gd0+8CV DE3P4Oj93a96FtUHJ/H8WiYMs5sV6bqE6fDkFxD+edgGbI4ATqJq6JUGJ5kYh1lz B+yICnu6fyobhAAWTvXqayQbRupQKYskmbBj1o1VGl1qJPRHZJUpVFdPacqDZ5kQ 31wdacKo393lIImQku+5 =NvNG -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] pci: fix some warnings related to assumptions about
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/22/12 06:57, Kumar Gala wrote:
On Sep 21, 2012, at 5:34 PM, Anatolij Gustschin wrote:
Hi,
On Wed, 19 Sep 2012 09:47:36 -0500 Kumar Gala
ga...@kernel.crashing.org wrote:
The following commit introduced some warnings associated with
using pci_addr_t instead of a proper 32-bit data type.
commit af778c6d9e2b945ee03cbc53bb976238a3374f33 Author: Andrew
Sharp andywy...@gmail.com Date: Wed Aug 1 12:27:16 2012
+
pci: fix errant data types and corresponding access functions
On some platforms pci_addr_t is defined as a 64-bit data type
so its not proper to use with pci_{read,write}_config_dword.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org ---
drivers/pci/pci.c |6 +++--- drivers/pci/pci_auto.c |
2 +- 2 files changed, 4 insertions(+), 4 deletions(-)
Applied to staging/ag...@denx.de.
Thanks, Anatolij
Thanks,
This should get in before v2012.10 is released
Staging branch was included in -rc1 so we should be good (and I
noticed the builds with warning set of powerpc went away).
- --
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQIcBAEBAgAGBQJQXfkuAAoJENk4IS6UOR1W2AUP/A9YxyD6u5F8bI6uQbFjCgvj
BEgEhc2KENHWX8gUYPvQMFQosCwDvAB4EOrb9a9ouC5ppHS7flzUZ1HwbCiSFim1
lBVT/MrpQGbxDwfbqNltEB3LbPWVY4uRnszRiUvW0y6FL9ikYx+v8JZZ5PVlAarE
dDaR1YoM7T+ePdyv3+fXegfBYIKQFEBFr3FRaF9KGwn6L8cqQKI3/9O33ofI1uiS
6devhuIQc7IT/vJPWoG5dFVDJSB+0EyDbhxqKXXDGhUIFs9wyywhgAb1qbHwZ4ec
vRBYstPbVAkWXxrWwxLBfvvwYSPVCZD8T9oiCIZay2XqjkEmIE7RdgVgNzidyb6e
1oSUvrHL+AZVbEhEdudbb6rmkXyb8hEcaiKWNkKhm6eoKIZVy5ZhqefuoSIdMPrV
IyN79zgmnOVOez0cTYJgzvV70zF4at2Xs335Aznb7AbvjB+pg0bm/NtY40aFIOMQ
UlniQDCCk5vXSnGymS0LbDy42F69rLtRw9zpR0oJkqiP/rT0+bKgHzCT3+O41p/7
ExuHzs7FP14i8lCS5Tnlvcgu1HxFvWnZZAqLZuDDL6aYr3XDDzPL3itSfNi3uZmD
Mc322A6A6wOldbYX3JvEyIZnNSpiikt0zHT6fjtTA/Inv/WlhpGOOMqJwtKyNavU
l4XjadVB8XPhEohWnm/v
=MKhp
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] h2200: Add support for iPAQ h2200
Dear Łukasz Dałek,
On 22.09.2012 19:04, Marek Vasut wrote:
Dear Łukasz Dałek,
On 19.09.2012 23:02, Marek Vasut wrote:
and at the offset
+ * 0x40 ascii characters 'ECEC', secondly 1st stage
+ * loads code from flash into SDRAM at address 0xa004
+ * so all instructions which reinitializes memory
+ * controller have to be disabled.
+ */
+
+static inline void writelrb(uint32_t val, uint32_t addr)
Replace this with clrsetbits_le32()
I've copied writelrb and pxa2xx_dram_init from pxa2xx.c
and I think there is a reason why it's done that way and not by
clrsetbits_le32. But if you insist I can replace all calls to writelrb
by clrsetbits.
And can you elaborate on the reason please?
(hint: clrsetbits() wasn't there by the time)
I don't know what was the reason. I didn't change becuse I didn't
want to break it.
If you have time, replace it with clrsetbits() please ... in the original file.
+{
+writel(val, addr);
+asm volatile( : : : memory);
+readl(addr);
+asm volatile( : : : memory);
+}
+
+static void h2200_pxa2xx_dram_init(void)
Why do you duplicate it ?!
[...]
Because code in pxa2xx.c disable and then re-enable memory.
And u-boot is executed from memory (1st stage bootloder
copied it there).
So don't reinit the memory at all, just skip this whole part.
1st stage loader doesn't init everything (for example MSC).
So I checked ... every board calls the dram init on it's own in dram_init() ...
so just don't do that.
+
+# define CONFIG_USB_ETHER1
+# define CONFIG_USBNET_DEV_ADDR de:ad:be:ef:00:01
+# define CONFIG_USBNET_HOST_ADDR de:ad:be:ef:00:02
Definitelly not, any mac address setting should not be present, Joe ?
So tell me how should I specify mac addresses? By EXTRA_ENV_SETTINGS?
Joe explained it, your adapter doesn't carry it's own mac?
No.
Then leave it in ?
Łukasz Dałek
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 1/6] h2200: Add support for iPAQ h2200
On 22.09.2012 20:00, Marek Vasut wrote:
Dear Łukasz Dałek,
On 22.09.2012 19:04, Marek Vasut wrote:
Dear Łukasz Dałek,
On 19.09.2012 23:02, Marek Vasut wrote:
and at the offset
+ * 0x40 ascii characters 'ECEC', secondly 1st stage
+ * loads code from flash into SDRAM at address 0xa004
+ * so all instructions which reinitializes memory
+ * controller have to be disabled.
+ */
+
+static inline void writelrb(uint32_t val, uint32_t addr)
Replace this with clrsetbits_le32()
I've copied writelrb and pxa2xx_dram_init from pxa2xx.c
and I think there is a reason why it's done that way and not by
clrsetbits_le32. But if you insist I can replace all calls to writelrb
by clrsetbits.
And can you elaborate on the reason please?
(hint: clrsetbits() wasn't there by the time)
I don't know what was the reason. I didn't change becuse I didn't
want to break it.
If you have time, replace it with clrsetbits() please ... in the original file.
In arch/arm/cpu/pxa/pxa2xx.c?
+{
+ writel(val, addr);
+ asm volatile( : : : memory);
+ readl(addr);
+ asm volatile( : : : memory);
+}
+
+static void h2200_pxa2xx_dram_init(void)
Why do you duplicate it ?!
[...]
Because code in pxa2xx.c disable and then re-enable memory.
And u-boot is executed from memory (1st stage bootloder
copied it there).
So don't reinit the memory at all, just skip this whole part.
1st stage loader doesn't init everything (for example MSC).
So I checked ... every board calls the dram init on it's own in dram_init() ...
so just don't do that.
Do what? Don't call modified pxa2xx_dram_init?
+
+# define CONFIG_USB_ETHER 1
+# define CONFIG_USBNET_DEV_ADDRde:ad:be:ef:00:01
+# define CONFIG_USBNET_HOST_ADDR de:ad:be:ef:00:02
Definitelly not, any mac address setting should not be present, Joe ?
So tell me how should I specify mac addresses? By EXTRA_ENV_SETTINGS?
Joe explained it, your adapter doesn't carry it's own mac?
No.
Then leave it in ?
leave CONFIG_USBNET_DEV_ADDR...?
Łukasz Dałek
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] h2200: Add support for iPAQ h2200
Dear Łukasz Dałek,
On 22.09.2012 20:00, Marek Vasut wrote:
Dear Łukasz Dałek,
On 22.09.2012 19:04, Marek Vasut wrote:
Dear Łukasz Dałek,
On 19.09.2012 23:02, Marek Vasut wrote:
and at the offset
+ * 0x40 ascii characters 'ECEC', secondly 1st stage
+ * loads code from flash into SDRAM at address 0xa004
+ * so all instructions which reinitializes memory
+ * controller have to be disabled.
+ */
+
+static inline void writelrb(uint32_t val, uint32_t addr)
Replace this with clrsetbits_le32()
I've copied writelrb and pxa2xx_dram_init from pxa2xx.c
and I think there is a reason why it's done that way and not by
clrsetbits_le32. But if you insist I can replace all calls to writelrb
by clrsetbits.
And can you elaborate on the reason please?
(hint: clrsetbits() wasn't there by the time)
I don't know what was the reason. I didn't change becuse I didn't
want to break it.
If you have time, replace it with clrsetbits() please ... in the original
file.
In arch/arm/cpu/pxa/pxa2xx.c?
Yes, and you don't need the copy of it now.
+{
+ writel(val, addr);
+ asm volatile( : : : memory);
+ readl(addr);
+ asm volatile( : : : memory);
+}
+
+static void h2200_pxa2xx_dram_init(void)
Why do you duplicate it ?!
[...]
Because code in pxa2xx.c disable and then re-enable memory.
And u-boot is executed from memory (1st stage bootloder
copied it there).
So don't reinit the memory at all, just skip this whole part.
1st stage loader doesn't init everything (for example MSC).
So I checked ... every board calls the dram init on it's own in
dram_init() ... so just don't do that.
Do what? Don't call modified pxa2xx_dram_init?
What exactly do you need to do ? What registers do you need to set ? How come
the bootloader kick dram in, but won't configure MSC ?
Split out the MSC config and memory config maybe ?
+
+# define CONFIG_USB_ETHER 1
+# define CONFIG_USBNET_DEV_ADDRde:ad:be:ef:00:01
+# define CONFIG_USBNET_HOST_ADDR de:ad:be:ef:00:02
Definitelly not, any mac address setting should not be present, Joe ?
So tell me how should I specify mac addresses? By EXTRA_ENV_SETTINGS?
Joe explained it, your adapter doesn't carry it's own mac?
No.
Then leave it in ?
leave CONFIG_USBNET_DEV_ADDR...?
Łukasz Dałek
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 1/6] h2200: Add support for iPAQ h2200
On 22.09.2012 20:21, Marek Vasut wrote:
+{
+ writel(val, addr);
+ asm volatile( : : : memory);
+ readl(addr);
+ asm volatile( : : : memory);
+}
+
+static void h2200_pxa2xx_dram_init(void)
Why do you duplicate it ?!
[...]
Because code in pxa2xx.c disable and then re-enable memory.
And u-boot is executed from memory (1st stage bootloder
copied it there).
So don't reinit the memory at all, just skip this whole part.
1st stage loader doesn't init everything (for example MSC).
So I checked ... every board calls the dram init on it's own in
dram_init() ... so just don't do that.
Do what? Don't call modified pxa2xx_dram_init?
What exactly do you need to do ? What registers do you need to set ? How come
the bootloader kick dram in, but won't configure MSC ?
Split out the MSC config and memory config maybe ?
Ok, I will rewrite that.
Łukasz Dałek
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] h2200: Add support for iPAQ h2200
Dear Łukasz Dałek,
On 22.09.2012 20:21, Marek Vasut wrote:
+{
+writel(val, addr);
+asm volatile( : : : memory);
+readl(addr);
+asm volatile( : : : memory);
+}
+
+static void h2200_pxa2xx_dram_init(void)
Why do you duplicate it ?!
[...]
Because code in pxa2xx.c disable and then re-enable memory.
And u-boot is executed from memory (1st stage bootloder
copied it there).
So don't reinit the memory at all, just skip this whole part.
1st stage loader doesn't init everything (for example MSC).
So I checked ... every board calls the dram init on it's own in
dram_init() ... so just don't do that.
Do what? Don't call modified pxa2xx_dram_init?
What exactly do you need to do ? What registers do you need to set ? How
come the bootloader kick dram in, but won't configure MSC ?
Split out the MSC config and memory config maybe ?
Ok, I will rewrite that.
Just pull it out, but make sure you don't break the other boards ...
Łukasz Dałek
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 1/6] h2200: Add support for iPAQ h2200
On 22.09.2012 20:37, Marek Vasut wrote:
Dear Łukasz Dałek,
On 22.09.2012 20:21, Marek Vasut wrote:
+{
+ writel(val, addr);
+ asm volatile( : : : memory);
+ readl(addr);
+ asm volatile( : : : memory);
+}
+
+static void h2200_pxa2xx_dram_init(void)
Why do you duplicate it ?!
[...]
Because code in pxa2xx.c disable and then re-enable memory.
And u-boot is executed from memory (1st stage bootloder
copied it there).
So don't reinit the memory at all, just skip this whole part.
1st stage loader doesn't init everything (for example MSC).
So I checked ... every board calls the dram init on it's own in
dram_init() ... so just don't do that.
Do what? Don't call modified pxa2xx_dram_init?
What exactly do you need to do ? What registers do you need to set ? How
come the bootloader kick dram in, but won't configure MSC ?
Split out the MSC config and memory config maybe ?
Ok, I will rewrite that.
Just pull it out, but make sure you don't break the other boards ...
I was only thinking about my board...
Łukasz Dałek
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 8/8] FAT: Make it possible to read from any file position
On Saturday, September 15, 2012 12:02:53 AM, Tom Rini wrote:
On 09/14/2012 03:03 PM, Benoît Thébaudeau wrote:
On Friday, September 14, 2012 10:49:04 PM, Tom Rini wrote:
On Mon, Sep 03, 2012 at 04:17:09PM +0200, Beno??t Th??baudeau
wrote:
Dear Wolfgang Denk,
On Sunday, September 2, 2012 5:28:09 PM, Wolfgang Denk wrote:
Dear Beno??t Th??baudeau,
In message
1285759492.332736.1342790529256.javamail.r...@advansee.com you
wrote:
When storage devices contain files larger than the embedded
RAM, it
is usef ul to
be able to read these files by chunks, e.g. for a software
update
to the
embedded NAND Flash from an external storage device (USB stick,
SD
card, et c.).
Hence, this patch makes it possible by adding a new FAT API to
read
files f rom a
given position.
Signed-off-by: Beno??t Th??baudeau
benoit.thebaud...@advansee.com
Cc: Wolfgang Denk w...@denx.de
---
Changes for v2:
- Patch renumbering because of the new v2 1/8.
- Possible code style changes due to the new v2 1/8.
- Add missing vairable renaming to fat_write.c.
.../fs/fat/fat.c | 88
.../fs/fat/fat_write.c | 18 ++--
2 files changed, 80 insertions(+), 26 deletions(-)
I don't see any command line interface to actually use this
code.
How would I put this to use?
Here is the current fatload command line interface:
fatload interface dev[:part] addr filename [bytes]
Do you prefer to change it to:
fatload interface dev[:part] addr filename [offset]
[bytes]
or to have a new dedicated command, or something else?
Lets go with:
fatload interface dev[:part] addr filename [bytes]
[offset]
and
update the long help text to mention both bytes and offset and
that
offset requires bytes.
OK. Do you want that in an update of this patch or in a separate
patch?
New patch to replace this.
You're right: Having [bytes] before [offset] will avoid breaking
the current
users of this command. However, this has one drawback: fatls first
has to be
used to get the file size (with [offset] first, 0 could be easily
used for
offset to access [bytes]). Hence, still with [bytes] first, would
you like to
have some special bytes value (let's say -1 or any negative value)
meaning from
offset to end of file?
Lets go with -1 meaning until end of file since we don't have a good
way
today to determine total filesize.
OK. I took 0 instead of -1 because 0 already had this behavior.
Done here:
http://patchwork.ozlabs.org/patch/184793/
Best regards,
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] mx25: add CPU revision 1.2
tested on a MCIMX257CJM4A which now reports :
CPU: Freescale i.MX25 rev1.2 at 399 MHz
Signed-off-by: Eric Bénard e...@eukrea.com
---
arch/arm/cpu/arm926ejs/mx25/generic.c |3 +++
arch/arm/include/asm/arch-mx25/imx-regs.h |1 +
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx25/generic.c
b/arch/arm/cpu/arm926ejs/mx25/generic.c
index 8b07dae..cb74b82 100644
--- a/arch/arm/cpu/arm926ejs/mx25/generic.c
+++ b/arch/arm/cpu/arm926ejs/mx25/generic.c
@@ -140,6 +140,9 @@ u32 get_cpu_rev(void)
case 0x01:
system_rev |= CHIP_REV_1_1;
break;
+ case 0x02:
+ system_rev |= CHIP_REV_1_2;
+ break;
default:
system_rev |= 0x8000;
break;
diff --git a/arch/arm/include/asm/arch-mx25/imx-regs.h
b/arch/arm/include/asm/arch-mx25/imx-regs.h
index cf925d7..35a2fb6 100644
--- a/arch/arm/include/asm/arch-mx25/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx25/imx-regs.h
@@ -355,5 +355,6 @@ struct aips_regs {
#define CHIP_REV_1_0 0x10
#define CHIP_REV_1_1 0x11
+#define CHIP_REV_1_2 0x12
#endif /* _IMX_REGS_H */
--
1.7.7.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] mx25: fix compilation when CONFIG_FSL_ESDHC is enabled
else we get :
generic.c: In function 'get_clocks':
generic.c:210: error: 'MXC_ESDHC_CLK' undeclared (first use in this function)
please note this fix is a hack similar to the one used in
arch/arm/cpu/arm1136/mx35/generic.c
and will pevent the usage of eSDHC2 (as done on i/MX35).
Signed-off-by: Eric Bénard e...@eukrea.com
---
arch/arm/cpu/arm926ejs/mx25/generic.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx25/generic.c
b/arch/arm/cpu/arm926ejs/mx25/generic.c
index cb74b82..6a3a8b3 100644
--- a/arch/arm/cpu/arm926ejs/mx25/generic.c
+++ b/arch/arm/cpu/arm926ejs/mx25/generic.c
@@ -207,7 +207,7 @@ int cpu_eth_init(bd_t *bis)
int get_clocks(void)
{
#ifdef CONFIG_FSL_ESDHC
- gd-sdhc_clk = mxc_get_clock(MXC_ESDHC_CLK);
+ gd-sdhc_clk = mxc_get_clock(MXC_ESDHC1_CLK);
#endif
return 0;
}
--
1.7.7.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] add Eukrea's CPUIMX25
this board is based on an i.MX25 from Freescale. It consists of a SOM containing : - NAND flash (internal or external boot supported and tested) - mDDR (64MB tested) - ethernet PHY connected in RMII mode (tested) and a baseboard containing : - a serial transceiver on UART1 (tested) - a SDCard connector on eSDHC1 (tested) bootlog : U-Boot 2012.07-rc1-00029-gca2becc-dirty (Sep 22 2012 - 22:28:35) CPU: Freescale i.MX25 rev1.2 at 399 MHz Reset cause: POR DRAM: 64 MiB WARNING: Caches not enabled NAND: 256 MiB MMC: FSL_SDHC: 0 *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial Net: FEC Hit any key to stop autoboot: 0 CPUIMX25 U-Boot mmc rescan CPUIMX25 U-Boot mmc part Partition Map for MMC device 0 -- Partition Type: DOS Partition Start Sector Num Sectors Type 1 2048 262144 b Signed-off-by: Eric Bénard e...@eukrea.com --- MAINTAINERS |2 + board/eukrea/cpuimx25/Makefile| 44 +++ board/eukrea/cpuimx25/config.mk |5 + board/eukrea/cpuimx25/cpuimx25.c | 123 ++ board/eukrea/cpuimx25/imximage.cfg| 55 board/eukrea/cpuimx25/lowlevel_init.S | 113 + boards.cfg|2 + include/configs/cpuimx25.h| 196 + nand_spl/board/eukrea/cpuimx25/Makefile | 79 nand_spl/board/eukrea/cpuimx25/config.mk |1 + nand_spl/board/eukrea/cpuimx25/u-boot.lds | 83 11 files changed, 703 insertions(+), 0 deletions(-) create mode 100644 board/eukrea/cpuimx25/Makefile create mode 100644 board/eukrea/cpuimx25/config.mk create mode 100644 board/eukrea/cpuimx25/cpuimx25.c create mode 100644 board/eukrea/cpuimx25/imximage.cfg create mode 100644 board/eukrea/cpuimx25/lowlevel_init.S create mode 100644 include/configs/cpuimx25.h create mode 100644 nand_spl/board/eukrea/cpuimx25/Makefile create mode 100644 nand_spl/board/eukrea/cpuimx25/config.mk create mode 100644 nand_spl/board/eukrea/cpuimx25/u-boot.lds diff --git a/MAINTAINERS b/MAINTAINERS index fd0c65c..25a58ab 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -603,6 +603,8 @@ Eric Benard e...@eukrea.com cpuat91 ARM920T cpu9260 ARM926EJS (AT91SAM9260 SoC) cpu9G20 ARM926EJS (AT91SAM9G20 SoC) + cpuimx25i.MX25 + cpuimx25nandi.MX25 Ajay Bhargav ajay.bhar...@einfochips.com diff --git a/board/eukrea/cpuimx25/Makefile b/board/eukrea/cpuimx25/Makefile new file mode 100644 index 000..46131fd --- /dev/null +++ b/board/eukrea/cpuimx25/Makefile @@ -0,0 +1,44 @@ +# +# (C) Copyright 2009 DENX Software Engineering +# Author: John Rigby jcri...@gmail.com +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).o + +COBJS := cpuimx25.o +SOBJS := lowlevel_init.o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(call cmd_link_o_target, $(OBJS) $(SOBJS)) + +# + +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/eukrea/cpuimx25/config.mk b/board/eukrea/cpuimx25/config.mk new file mode 100644 index 000..18b2883 --- /dev/null +++ b/board/eukrea/cpuimx25/config.mk @@ -0,0 +1,5 @@ +ifdef CONFIG_NAND_SPL +CONFIG_SYS_TEXT_BASE = 0x810c +else +CONFIG_SYS_TEXT_BASE = 0x8120 +endif diff --git a/board/eukrea/cpuimx25/cpuimx25.c b/board/eukrea/cpuimx25/cpuimx25.c new file mode 100644 index 000..72fa8a5 --- /dev/null +++ b/board/eukrea/cpuimx25/cpuimx25.c @@ -0,0 +1,123 @@ +/* + * (C) Copyright 2009 DENX Software Engineering + * (C) Copyright 2012 Eukrea Electromatique www.eukrea.com + * Eric Benard e...@eukrea.com + * + * Based on tx25.c: + * Author: John Rigby jri...@gmail.com + * + * Based on imx27lite.c: + * Copyright (C) 2008,2009 Eric Jarrige jora...@users.sourceforge.net + *
Re: [U-Boot] [PATCH 1/3] mx25: add CPU revision 1.2
On Sat, Sep 22, 2012 at 5:50 PM, Eric Bénard e...@eukrea.com wrote: tested on a MCIMX257CJM4A which now reports : CPU: Freescale i.MX25 rev1.2 at 399 MHz Signed-off-by: Eric Bénard e...@eukrea.com Acked-by: Otavio Salvador ota...@ossystems.com.br -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] mx25: fix compilation when CONFIG_FSL_ESDHC is enabled
On Sat, Sep 22, 2012 at 5:50 PM, Eric Bénard e...@eukrea.com wrote: else we get : generic.c: In function 'get_clocks': generic.c:210: error: 'MXC_ESDHC_CLK' undeclared (first use in this function) please note this fix is a hack similar to the one used in arch/arm/cpu/arm1136/mx35/generic.c and will pevent the usage of eSDHC2 (as done on i/MX35). Signed-off-by: Eric Bénard e...@eukrea.com What about working in the proper fix then? -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] add Eukrea's CPUIMX25
On Sat, Sep 22, 2012 at 5:50 PM, Eric Bénard e...@eukrea.com wrote: this board is based on an i.MX25 from Freescale. It consists of a SOM containing : - NAND flash (internal or external boot supported and tested) - mDDR (64MB tested) - ethernet PHY connected in RMII mode (tested) and a baseboard containing : - a serial transceiver on UART1 (tested) - a SDCard connector on eSDHC1 (tested) bootlog : U-Boot 2012.07-rc1-00029-gca2becc-dirty (Sep 22 2012 - 22:28:35) Please rebase it against 2012.10. For iMX patches please keep Stefano Babic sba...@denx.de in CC as he is the iMX custodian. Cheers, -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] mx25: fix compilation when CONFIG_FSL_ESDHC is enabled
Hi Otavio, Eric, On Saturday, September 22, 2012 11:14:40 PM, Otavio Salvador wrote: On Sat, Sep 22, 2012 at 5:50 PM, Eric Bénard e...@eukrea.com wrote: else we get : generic.c: In function 'get_clocks': generic.c:210: error: 'MXC_ESDHC_CLK' undeclared (first use in this function) please note this fix is a hack similar to the one used in arch/arm/cpu/arm1136/mx35/generic.c and will pevent the usage of eSDHC2 (as done on i/MX35). Signed-off-by: Eric Bénard e...@eukrea.com What about working in the proper fix then? Note that I have such a fix. I have already posted it for i.MX35, but it's missing a part that I will post soon, and I have the same fix for i.MX25 that I will also post soon. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6] [RFC] early_malloc for DM added.
early_malloc for DM with support for more heaps and lightweight
first heap in the same memory as an early stack.
Adaptation layer for seamless calling of early_malloc or dlmalloc from
DM based on init stage added (dmmalloc() and related functions).
Signed-off-by: Tomas Hlavacek tmshl...@gmail.com
---
Changelog since v5:
dmmalloc() and all dm* functions has been moved to header, made static
inline and preprocessor-dependent blocks are reworked.
early_malloc_active() corrected and made not static.
s/CONFIG_SYS_DM/CONFIG_DM/ applied.
arch/arm/include/asm/global_data.h|3 +
arch/arm/lib/board.c |8 +++
arch/avr32/include/asm/global_data.h |3 +
arch/avr32/lib/board.c|9 +++
arch/blackfin/include/asm/global_data.h |3 +
arch/blackfin/lib/board.c |8 +++
arch/m68k/include/asm/global_data.h |3 +
arch/m68k/lib/board.c |8 +++
arch/microblaze/include/asm/global_data.h |3 +
arch/microblaze/lib/board.c |9 +++
arch/mips/include/asm/global_data.h |3 +
arch/mips/lib/board.c |8 +++
arch/nds32/include/asm/global_data.h |3 +
arch/nds32/lib/board.c|8 +++
arch/nios2/include/asm/global_data.h |3 +
arch/nios2/lib/board.c|8 +++
arch/openrisc/include/asm/global_data.h |3 +
arch/openrisc/lib/board.c |8 +++
arch/powerpc/include/asm/global_data.h|3 +
arch/powerpc/lib/board.c |8 +++
arch/sandbox/include/asm/global_data.h|3 +
arch/sandbox/lib/board.c |8 +++
arch/sh/include/asm/global_data.h |3 +
arch/sh/lib/board.c |8 +++
arch/sparc/include/asm/global_data.h |3 +
arch/sparc/lib/board.c|8 +++
arch/x86/include/asm/global_data.h|3 +
arch/x86/lib/board.c | 18 ++
common/Makefile |1 +
common/dmmalloc.c | 93 +
include/dmmalloc.h| 89 +++
31 files changed, 349 insertions(+)
create mode 100644 common/dmmalloc.c
create mode 100644 include/dmmalloc.h
diff --git a/arch/arm/include/asm/global_data.h
b/arch/arm/include/asm/global_data.h
index f8088fe..ef727b0 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -82,6 +82,9 @@ typedef struct global_data {
unsigned long post_log_res; /* success of POST test */
unsigned long post_init_f_time; /* When post_init_f started */
#endif
+#ifdef CONFIG_SYS_EARLY_MALLOC
+ void*early_heap_first; /* heap for early_malloc */
+#endif
} gd_t;
#include asm-generic/global_data_flags.h
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index f1951e8..f73d8b2 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -53,6 +53,10 @@
#include post.h
#include logbuff.h
+#ifdef CONFIG_DM
+#include dmmalloc.h
+#endif
+
#ifdef CONFIG_BITBANGMII
#include miiphy.h
#endif
@@ -281,6 +285,10 @@ void board_init_f(ulong bootflag)
memset((void *)gd, 0, sizeof(gd_t));
+#ifdef CONFIG_SYS_EARLY_MALLOC
+ gd-early_heap_first = early_brk(CONFIG_SYS_EARLY_HEAP_SIZE);
+#endif /* CONFIG_SYS_EARLY_MALLOC */
+
gd-mon_len = _bss_end_ofs;
#ifdef CONFIG_OF_EMBED
/* Get a pointer to the FDT */
diff --git a/arch/avr32/include/asm/global_data.h
b/arch/avr32/include/asm/global_data.h
index 7878bb1..0654a61 100644
--- a/arch/avr32/include/asm/global_data.h
+++ b/arch/avr32/include/asm/global_data.h
@@ -48,6 +48,9 @@ typedef struct global_data {
#endif
void**jt; /* jump table */
charenv_buf[32];/* buffer for getenv() before reloc. */
+#ifdef CONFIG_SYS_EARLY_MALLOC
+ void*early_heap_first; /* heap for early_malloc */
+#endif
} gd_t;
#include asm-generic/global_data_flags.h
diff --git a/arch/avr32/lib/board.c b/arch/avr32/lib/board.c
index d7a64b4..f1bd946 100644
--- a/arch/avr32/lib/board.c
+++ b/arch/avr32/lib/board.c
@@ -42,6 +42,11 @@
#ifdef CONFIG_GENERIC_ATMEL_MCI
#include mmc.h
#endif
+
+#ifdef CONFIG_DM
+#include dmmalloc.h
+#endif
+
DECLARE_GLOBAL_DATA_PTR;
unsigned long monitor_flash_len;
@@ -161,6 +166,10 @@ void board_init_f(ulong board_type)
memset(gd_data, 0, sizeof(gd_data));
gd = gd_data;
+#ifdef CONFIG_SYS_EARLY_MALLOC
+ gd-early_heap_first = early_brk(CONFIG_SYS_EARLY_HEAP_SIZE);
+#endif /* CONFIG_SYS_EARLY_MALLOC */
+
/* Perform initialization sequence */
board_early_init_f();
cpu_init();
diff --git a/arch/blackfin/include/asm/global_data.h
b/arch/blackfin/include/asm/global_data.h
index 290a9e7..2ae395c 100644
--- a/arch/blackfin/include/asm/global_data.h
+++
Re: [U-Boot] [PATCH 3/3] add Eukrea's CPUIMX25
Le Sat, 22 Sep 2012 18:18:58 -0300, Otavio Salvador ota...@ossystems.com.br a écrit : On Sat, Sep 22, 2012 at 5:50 PM, Eric Bénard e...@eukrea.com wrote: this board is based on an i.MX25 from Freescale. It consists of a SOM containing : - NAND flash (internal or external boot supported and tested) - mDDR (64MB tested) - ethernet PHY connected in RMII mode (tested) and a baseboard containing : - a serial transceiver on UART1 (tested) - a SDCard connector on eSDHC1 (tested) bootlog : U-Boot 2012.07-rc1-00029-gca2becc-dirty (Sep 22 2012 - 22:28:35) Please rebase it against 2012.10. For iMX patches please keep Stefano Babic sba...@denx.de in CC as he is the iMX custodian. that should have been the case ... but I forget one = before his mail ... git send-email --to u-boot@lists.denx.de --cc sba...@denx.de --suppress-cc=self -3 Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] add Eukrea's CPUIMX25
Hi Otavio, Le Sat, 22 Sep 2012 18:18:58 -0300, Otavio Salvador ota...@ossystems.com.br a écrit : On Sat, Sep 22, 2012 at 5:50 PM, Eric Bénard e...@eukrea.com wrote: this board is based on an i.MX25 from Freescale. It consists of a SOM containing : - NAND flash (internal or external boot supported and tested) - mDDR (64MB tested) - ethernet PHY connected in RMII mode (tested) and a baseboard containing : - a serial transceiver on UART1 (tested) - a SDCard connector on eSDHC1 (tested) bootlog : U-Boot 2012.07-rc1-00029-gca2becc-dirty (Sep 22 2012 - 22:28:35) Please rebase it against 2012.10. the patch serie can be applied cleanly (and even compiled ;-) on 2012.10-rc1 Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cfb_console: flush FB cache at end of public functions
Removed internal cache_flush operations and placed a flush of the
entire frame-buffer at the end of each public function.
Changed logo_plot() to static because it isn't called externally or
declared in a header.
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
drivers/video/cfb_console.c | 16 +---
1 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
index 19d061f..1372353 100644
--- a/drivers/video/cfb_console.c
+++ b/drivers/video/cfb_console.c
@@ -557,8 +557,6 @@ static void video_drawchars(int xx, int yy, unsigned char
*s, int count)
SWAP32((video_font_draw_table32
[bits 15][3] eorx) ^ bgx);
}
- if (cfb_do_flush_cache)
- flush_cache((ulong)dest0, 32);
dest0 += VIDEO_FONT_WIDTH * VIDEO_PIXEL_SIZE;
s++;
}
@@ -627,8 +625,6 @@ static void video_invertchar(int xx, int yy)
for (x = firstx; x lastx; x++) {
u8 *dest = (u8 *)(video_fb_address) + x + y;
*dest = ~*dest;
- if (cfb_do_flush_cache)
- flush_cache((ulong)dest, 4);
}
}
}
@@ -672,6 +668,8 @@ void console_cursor(int state)
}
cursor_state = state;
}
+ if (cfb_do_flush_cache)
+ flush_cache(VIDEO_FB_ADRS, VIDEO_SIZE);
}
#endif
@@ -724,8 +722,6 @@ static void console_clear_line(int line, int begin, int end)
memsetl(offset + i * VIDEO_LINE_LEN, size, bgx);
}
#endif
- if (cfb_do_flush_cache)
- flush_cache((ulong)CONSOLE_ROW_FIRST, CONSOLE_SIZE);
}
static void console_scrollup(void)
@@ -828,6 +824,8 @@ void video_putc(const char c)
}
}
CURSOR_SET;
+ if (cfb_do_flush_cache)
+ flush_cache(VIDEO_FB_ADRS, VIDEO_SIZE);
}
void video_puts(const char *s)
@@ -1474,13 +1472,15 @@ int video_display_bitmap(ulong bmp_image, int x, int y)
}
#endif
+ if (cfb_do_flush_cache)
+ flush_cache(VIDEO_FB_ADRS, VIDEO_SIZE);
return (0);
}
#endif
#ifdef CONFIG_VIDEO_LOGO
-void logo_plot(void *screen, int width, int x, int y)
+static void logo_plot(void *screen, int width, int x, int y)
{
int xcount, i;
@@ -1862,6 +1862,8 @@ int drv_video_init(void)
if (stdio_register(console_dev) != 0)
return 0;
+ if (cfb_do_flush_cache)
+ flush_cache(VIDEO_FB_ADRS, VIDEO_SIZE);
/* Return success */
return 1;
}
--
1.7.9
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] edminiv2: increase malloc len to 256K
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot- boun...@lists.denx.de] On Behalf Of Albert ARIBAUD Sent: 22 September 2012 06:27 To: u-boot@lists.denx.de Subject: [U-Boot] [PATCH] edminiv2: increase malloc len to 256K Malloc len of 128K caused a warning from ehci_hcd asking for more. Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net --- Note: this has been tested on target -- actually, target is now flashed with the merge of u-boot/arm and u-boot master branches plus this patch. include/configs/edminiv2.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/edminiv2.h b/include/configs/edminiv2.h index f2cfaf8..adb505e 100644 --- a/include/configs/edminiv2.h +++ b/include/configs/edminiv2.h @@ -222,7 +222,7 @@ /* * Size of malloc() pool */ -#define CONFIG_SYS_MALLOC_LEN(1024 * 128) /* 128kB for malloc() */ +#define CONFIG_SYS_MALLOC_LEN(1024 * 256) /* 256kB for malloc() */ /* * Other required minimal configurations Acked-by: Prafulla Wadaskar prafu...@marvell.com Will pull this patch latter. Regards... Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
