Re: [U-Boot] [PATCH 6/8 V2] I2C: Modify the I2C driver for EXYNOS5
Hi,
2012/6/7 Rajeshwari Shinde rajeshwar...@samsung.com:
This patch modifies the S3C I2C driver to suppport EXYNOS5.
The cahnges made to driver are as follows:
- I2C base address is passed as a parameter to many
functions to avoid multiple #ifdef
- I2C init for Exynos5 is made as different function.
- Channel initialisation is moved to a commom funation
as it is required by both the i2c_init.
- Separate functions written to get I2C base address,
peripheral id for pinmux support.
- Hardcoding for I2CCON_ACKGEN removed.
- Replaced printf with debug.
- Checkpatch issues resolved.
Signed-off-by: Alim Akhtar alim.akh...@samsung.com
Signed-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes in V2:
- Removed #define for I2C cahnnels from hearder file except for I2C0.
- Incorporated review comments from Simon Glass.
drivers/i2c/s3c24x0_i2c.c | 254
-
drivers/i2c/s3c24x0_i2c.h | 3 +
2 files changed, 184 insertions(+), 73 deletions(-)
diff --git a/drivers/i2c/s3c24x0_i2c.c b/drivers/i2c/s3c24x0_i2c.c
index ba6f39b..a71f147 100644
--- a/drivers/i2c/s3c24x0_i2c.c
+++ b/drivers/i2c/s3c24x0_i2c.c
@@ -27,10 +27,17 @@
*/
#include common.h
+#ifdef CONFIG_EXYNOS5
+#include asm/arch/clk.h
+#include asm/arch/cpu.h
+#include asm/arch/gpio.h
+#include asm/arch/pinmux.h
+#else
#include asm/arch/s3c24x0_cpu.h
-
+#endif
#include asm/io.h
#include i2c.h
+#include s3c24x0_i2c.h
#ifdef CONFIG_HARD_I2C
@@ -45,6 +52,7 @@
#define I2CSTAT_BSY 0x20 /* Busy bit */
#define I2CSTAT_NACK 0x01 /* Nack bit */
+#define I2CCON_ACKGEN 0x80 /* Acknowledge generation */
#define I2CCON_IRPND 0x10 /* Interrupt pending bit */
#define I2C_MODE_MT 0xC0 /* Master Transmit Mode */
#define I2C_MODE_MR 0x80 /* Master Receive Mode */
@@ -53,6 +61,44 @@
#define I2C_TIMEOUT 1 /* 1 second */
+#ifdef CONFIG_EXYNOS5
+static unsigned int g_current_bus; /* Stores Current I2C Bus */
+
+/* We should not rely on any particular ordering of these IDs */
+static enum periph_id periph_for_dev[] = {
+ PERIPH_ID_I2C0,
+ PERIPH_ID_I2C1,
+ PERIPH_ID_I2C2,
+ PERIPH_ID_I2C3,
+ PERIPH_ID_I2C4,
+ PERIPH_ID_I2C5,
+ PERIPH_ID_I2C6,
+ PERIPH_ID_I2C7,
+};
+
+static enum periph_id i2c_get_periph_id(unsigned dev_index)
+{
+ if (dev_index ARRAY_SIZE(periph_for_dev))
+ return periph_for_dev[dev_index];
+
+ debug(%s: invalid bus %d, __func__, dev_index);
+
+ return PERIPH_ID_NONE;
+}
+
+static struct s3c24x0_i2c *get_base_i2c(int bus_idx)
+{
+ struct s3c24x0_i2c *i2c = (struct s3c24x0_i2c
*)samsung_get_base_i2c();
+
+ return i2c[bus_idx];
+}
This function can use in the s3c24xx adding #ifdef in this fuction, then
you can reduce #ifdef.
+
+static inline struct exynos5_gpio_part1 *exynos_get_base_gpio1(void)
+{
+ return (struct exynos5_gpio_part1 *)(EXYNOS5_GPIO_PART1_BASE);
+}
+
+#else
static int GetI2CSDA(void)
{
struct s3c24x0_gpio *gpio = s3c24x0_get_base_gpio();
@@ -77,16 +123,17 @@ static void SetI2CSCL(int x)
struct s3c24x0_gpio *gpio = s3c24x0_get_base_gpio();
#ifdef CONFIG_S3C2410
- writel((readl(gpio-gpedat) ~0x4000) | (x 1) 14,
gpio-gpedat);
+ writel((readl(gpio-gpedat) ~0x4000) |
+ (x 1) 14, gpio-gpedat);
#endif
#ifdef CONFIG_S3C2400
writel((readl(gpio-pgdat) ~0x0040) | (x 1) 6, gpio-pgdat);
#endif
}
+#endif
-static int WaitForXfer(void)
+static int WaitForXfer(struct s3c24x0_i2c *i2c)
{
- struct s3c24x0_i2c *i2c = s3c24x0_get_base_i2c();
int i;
i = I2C_TIMEOUT * 1;
@@ -98,25 +145,84 @@ static int WaitForXfer(void)
return (readl(i2c-iiccon) I2CCON_IRPND) ? I2C_OK : I2C_NOK_TOUT;
}
-static int IsACK(void)
+static int IsACK(struct s3c24x0_i2c *i2c)
{
- struct s3c24x0_i2c *i2c = s3c24x0_get_base_i2c();
-
return !(readl(i2c-iicstat) I2CSTAT_NACK);
}
-static void ReadWriteByte(void)
+static void ReadWriteByte(struct s3c24x0_i2c *i2c)
{
- struct s3c24x0_i2c *i2c = s3c24x0_get_base_i2c();
-
writel(readl(i2c-iiccon) ~I2CCON_IRPND, i2c-iiccon);
}
+static void i2c_ch_init(struct s3c24x0_i2c *i2c, int speed, int slaveadd)
+{
+ ulong freq, pres = 16, div;
+#ifdef CONFIG_EXYNOS5
+ freq = get_i2c_clk();
+#else
+ freq = get_PCLK();
+#endif
+ /* calculate prescaler and divisor values */
+ if ((freq / pres / (16 + 1)) speed)
+ /* set prescaler to 512 */
+ pres = 512;
+
+ div = 0;
+ while ((freq / pres / (div + 1)) speed)
+
Re: [U-Boot] [PATCH 7/8 V2] I2C: Add support for Multi channel
Hi,
2012/6/7 Rajeshwari Shinde rajeshwar...@samsung.com:
This adds multiple i2c channel support for I2C.
Signed-off-by: Alim Akhtar alim.akh...@samsung.com
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
drivers/i2c/s3c24x0_i2c.c | 27 +++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/s3c24x0_i2c.c b/drivers/i2c/s3c24x0_i2c.c
index a71f147..7521cb8 100644
--- a/drivers/i2c/s3c24x0_i2c.c
+++ b/drivers/i2c/s3c24x0_i2c.c
@@ -191,6 +191,33 @@ static void i2c_bus_init(struct s3c24x0_i2c *i2c,
unsigned int bus)
i2c_ch_init(i2c, CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
}
+/*
+ * MULTI BUS I2C support
+ */
+
+#ifdef CONFIG_I2C_MULTI_BUS
+int i2c_set_bus_num(unsigned int bus)
+{
+ struct s3c24x0_i2c *i2c;
+
+ if ((bus 0) || (bus = CONFIG_MAX_I2C_NUM)) {
+ debug(Bad bus: %d\n, bus);
+ return -1;
+ }
+
+ g_current_bus = bus;
+ i2c = get_base_i2c(g_current_bus);
+ i2c_bus_init(i2c, g_current_bus);
This causes duplicated pin configuration whenever calls i2c_set_bus_num().
+
+ return 0;
+}
+
+unsigned int i2c_get_bus_num(void)
+{
+ return g_current_bus;
+}
+#endif
Does only EXYNOS5 support CONFIG_I2C_MULTI_BUS?
+
#ifdef CONFIG_EXYNOS5
void i2c_init(int speed, int slaveadd)
{
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Thanks.
--
- Joonyoung Shim
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 V2] PMIC: MAX77686: Add support for MAX77686
Hi,
2012/5/23 Rajeshwari Birje rajeshwari.bi...@gmail.com:
ccing Lukasz Majewski.
On Wed, May 23, 2012 at 2:27 PM, Rajeshwari Shinde
rajeshwar...@samsung.com wrote:
This patch adds driver and register definitions for PMIC chip
MAX77686.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
changes for V2:
- using the generic PMIC framework instead of writing separate driver.
drivers/misc/Makefile | 1 +
drivers/misc/pmic_max77686.c | 42 +++
include/max77686_pmic.h | 158
++
3 files changed, 201 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/pmic_max77686.c
create mode 100644 include/max77686_pmic.h
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 271463c..9fac190 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -39,6 +39,7 @@ COBJS-$(CONFIG_DIALOG_PMIC) += pmic_dialog.o
COBJS-$(CONFIG_PMIC_FSL) += pmic_fsl.o
COBJS-$(CONFIG_PMIC_I2C) += pmic_i2c.o
COBJS-$(CONFIG_PMIC_SPI) += pmic_spi.o
+COBJS-$(CONFIG_PMIC_MAX77686) += pmic_max77686.o
COBJS-$(CONFIG_PMIC_MAX8998) += pmic_max8998.o
COBJS-$(CONFIG_PMIC_MAX8997) += pmic_max8997.o
diff --git a/drivers/misc/pmic_max77686.c b/drivers/misc/pmic_max77686.c
new file mode 100644
index 000..36f7f4d
--- /dev/null
+++ b/drivers/misc/pmic_max77686.c
@@ -0,0 +1,42 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics
+ * Rajeshwari Shinde rajeshwar...@samsung.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 pmic.h
+#include max77686_pmic.h
+
+int pmic_init(void)
+{
+ struct pmic *p = get_pmic();
+ static const char name[] = MAX77686_PMIC;
+
+ puts(Board PMIC init\n);
+ p-name = name;
+ p-interface = PMIC_I2C;
+ p-number_of_regs = PMIC_NUM_OF_REGS;
+ p-hw.i2c.addr = MAX77686_I2C_ADDR;
+ p-hw.i2c.tx_num = 1;
+ p-bus = I2C_PMIC;
If board supports I2C_MULTI_BUS, bus number of pmic can be other value,
so let's add function parameter for bus number.
Thanks.
--
- Joonyoung Shim
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] tegra: usb: Fix device enumeration problem of USB1
On 06/14/2012 04:40 AM, Jim Lin wrote:
For some reason, bit 1 (connect status change) of PORTSC will be set
after issuing Port Reset (like usb reset in u-boot command line).
This will be treated as an error and stops later device enumeration.
Therefore we add a definition in header file to ignore checking of that bit
after Port Reset.
CONFIG_USB_RESET_IGNORE_CONNECT_CHANGE
(Again, I'm CC'ing the USB maintainer here)
Looking at the Linux kernel's Tegra EHCI driver:
a) This WAR is only needed on the first USB port, not all of them.
[Jim] No penalty for USB2 and USB3 ports. Because u-boot hub_port_reset
has at most 5 times of retry for a port.
USB2 and USB3 ports will reset once in retry loop
('port connect change' bit will not set after reset).
USB1 will have at most 2 times of reset in the retry loop after adding
this patch.
b) This WAR is not complete; there's a loop in the kernel that resets
the port twice in order to guarantee that the port will become enabled.
[Jim] Disagree. Because u-boot hub_port_reset has at most 5 times of retry
for a port. U-boot and kernel code are not entirely same.
c) The kernel driver actively clears this CSC bit rather than leaving it
set and ignoring it. Is there any implication to this difference?
[Jim] I can make next change to be consistent with kernel driver to clear
CSC bit after Port Reset.
So, rather than just ifdef'ing this fix into the driver, wouldn't it be
better to add a callback from the USB core into the USB driver, so that
the Tegra EHCI driver could choose to only implement this WAR for port
1, and also do the multiple-reset-loop thing.
[Jim] No callback for me to cut in. Also no penalty for other ports.
Finally, in the change description, the text for some reason is quite
unclear; it sounds like you have absolutely no idea why this happens. Is
this a known and root-caused HW bug for which this fix has been fully
validated? Or, is this patch just some random hack that seems to work
for you?
[Jim] This is a known and root-caused HW bug.
---
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
---
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] MMC: DWMMC: Add DWMMC driver
Hi Jaehoon Chung,
Thank you for comments.
On Thu, Jun 14, 2012 at 7:06 PM, Jaehoon Chung jh80.ch...@samsung.com wrote:
Hi Rajeshwari,
This patch has too many dependence with other patches.
(Pinmux and PeripID, patches for MSHCI setting).
And as i mentioned, designWare controller isn't exynos specific.
I think good that separate two files. (dw_mmc.c and exynos_dw_mmc.c)
Like this...dw_mmc.c is generic code and exynos_dw_mmc.c is samsung specific
code..
If you want, I will send to you patch that related with them. (based-on your
patch)
-- Ok. Will do the change and send the patch for review.
And Added some comment
On 06/12/2012 06:33 PM, Rajeshwari Birje wrote:
Hi Jaehoon Chung,
Yes you need to apply the following patchset
http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/132754
Regards,
Rajeshwari Shinde.
On Tue, Jun 12, 2012 at 2:07 PM, Jaehoon Chung jh80.ch...@samsung.com
wrote:
Hi Rajeshwari,
Before applied this patch, it must apply your patch for PINMUX. right?
Best Regards,
Jaehoon Chung
On 06/12/2012 03:14 PM, Chander Kashyap wrote:
Hi,
On 11 June 2012 19:26, Rajeshwari Birje rajeshwari.bi...@gmail.com wrote:
Hi All,
ccing Jaehoon Chung
Regards,
Rajeshwari Shinde.
On Mon, Jun 11, 2012 at 6:18 PM, Rajeshwari Shinde
rajeshwar...@samsung.com wrote:
Add DWMMC driver support and resgister description for same.
Signed-off-by: Alim Akhtar alim.akh...@samsung.com
Signed-off-by: Terry Lambert tlamb...@chromium.org
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
Changes in V2:
- Incorporated comments from Jaehung Chung.
- Renamed MSHCI to DWMMC through out the driver.
- Renamed files to exynos_dwmmc from exynos_mshc.
- Removed major hard codings of values.
- Wrote dw_mci_writel and dw_mci_readl functions for writel and
readl.
- Removed structure of registers and defined each one separately.
orch/arm/include/asm/arch-exynos/exynos_dwmmc.h | 229 +
drivers/mmc/Makefile | 1 +
drivers/mmc/exynos_dwmmc.c | 566
+++
3 files changed, 796 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/arch-exynos/exynos_dwmmc.h
create mode 100644 drivers/mmc/exynos_dwmmc.c
diff --git a/arch/arm/include/asm/arch-exynos/exynos_dwmmc.h
b/arch/arm/include/asm/arch-exynos/exynos_dwmmc.h
new file mode 100644
index 000..349bd75
--- /dev/null
+++ b/arch/arm/include/asm/arch-exynos/exynos_dwmmc.h
@@ -0,0 +1,229 @@
+/*
+ * (C) Copyright 2012 SAMSUNG Electronics
+ * Abhilash Kesavan a.kesa...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
USA
+ *
+ */
+#ifndef __ASM_ARCH_COMMON_DWMMC_H
+#define __ASM_ARCH_COMMON_DWMMC_H
+
+#include asm/arch/pinmux.h
+
+#ifndef __ASSEMBLY__
+struct dw_mci_host {
+ void *ioaddr;
+ unsigned int clock; /* Current clock in MHz */
+ enum periph_id peripheral;
+ unsigned int verid; /* SDHCI spec. version */
+ unsigned int data_offset; /* DATA offset */
+};
+
+/*
+ * Struct idma
+ * Holds the descriptor list
+ */
+struct dw_mci_idmac {
+ u32 des0;
+ u32 des1;
+ u32 des2;
+ u32 des3;
+};
+
#endif
+/* Control Register Register */
+#define DWMCI_CONTROL 0x00
+#define CTRL_RESET (0x1 0)
+#define FIFO_RESET (0x1 1)
+#define DMA_RESET (0x1 2)
+#define DMA_ENABLE (0x1 5)
+#define SEND_AS_CCSD (0x1 10)
+#define ENABLE_IDMAC (0x1 25)
+
+/* Power Enable Register */
+#define DWMCI_PWREN 0x04
+#define POWER_ENABLE (0x1 0)
+
+#define DWMCI_CLKDIV 0x08
+#define DWMCI_CLKSRC 0x0c
+
+/* Clock Enable Register */
+#define DWMCI_CLKENA 0x10
+#define CLK_ENABLE (0x1 0)
+#define CLK_DISABLE (0x0 0)
+
+/* Timeout Register */
+#define DWMCI_TMOUT 0x14
+#define TMOUT_MAX 0x
+
+/* Card Type Register */
+#define DWMCI_CTYPE 0x18
+#define PORT0_CARD_WIDTH1 0
+#define PORT0_CARD_WIDTH4 (0x1 0)
+#define PORT0_CARD_WIDTH8 (0x1 16)
+
+#define DWMCI_BLKSIZE 0x1c
+#define DWMCI_BYTCNT 0x20
[U-Boot] am35xx, twister: could not write nand flash
Hello Scott,
I currently tried current U-Boot HEAD
commit fedab338f3459315cb69627fcf46032ec8df1753
Merge: 74b5b5d f6b690e
Author: Wolfgang Denk w...@denx.de
Date: Thu Jun 7 23:42:17 2012 +0200
Merge branch 'master' of git://git.denx.de/u-boot-video
on the twister board, and detected that a run update fails with:
twister = run update
SW ECC selected
NAND erase: device 0 offset 0x8, size 0x10
Erasing at 0x16 -- 100% complete.
OK
NAND write:
(board hangs ...)
Environment var:
update=nandecc sw;nand erase ${uboot_addr} 10;nand write ${loadaddr}
${uboot_addr} 8
So I started git bisection:
[hs@pollux u-boot]$ git bisect start
[hs@pollux u-boot]$ git bisect bad
[hs@pollux u-boot]$ git bisect good 415d386877df49eb051b85ef74fa59a16dc17c7d
Bisecting: 211 revisions left to test after this (roughly 8 steps)
[...]
[hs@pollux u-boot]$ git bisect bad
418396e212b59bf907dbccad997ff50f7eb61b16 is the first bad commit
commit 418396e212b59bf907dbccad997ff50f7eb61b16
Author: Scott Wood scottw...@freescale.com
Date: Fri Mar 2 14:01:57 2012 -0600
nand: extend .raw accesses to work on multiple pages
A use for this is to read, modify, erase, and write an entire block as a
single unit, as a replacement for the biterr command. This way gives
more flexibility in that you can also test multiple bit errors, errors
in the ECC, etc.
Signed-off-by: Scott Wood scottw...@freescale.com
:04 04 ad5ce55a0fdf3a40e1aaae0546aae68bf7a0b480
f57e87a8630715e37170b5bb3a109a58b6b89333 M common
:04 04 83834ae80a73f20357132875078f643b4064f9dd
ed0004e44b4da8b2734168a3950733afba0a0b64 M doc
[hs@pollux u-boot]$
following patch helps:
diff --git a/common/cmd_nand.c b/common/cmd_nand.c
index fa44295..edeb093 100644
--- a/common/cmd_nand.c
+++ b/common/cmd_nand.c
@@ -617,7 +617,7 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char *
const argv[])
s = strchr(cmd, '.');
- if (!strcmp(s, .raw)) {
+ if ((s != NULL) (!strcmp(s, .raw))) {
raw = 1;
if (arg_off(argv[3], dev, off, size))
What do you think? Is this a correct fix, and I should sent this as
a real patch, or did I overlook something?
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx6: Make pad name macro consistent with the datasheet
Use the same name as defined in the datasheet.
DSP_CLK - DISP_CLK
Signed-off-by: Ashok Kumar Reddy Kourla ashokkourla2...@gmail.com
---
arch/arm/include/asm/arch-mx6/mx6x_pins.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx6/mx6x_pins.h
b/arch/arm/include/asm/arch-mx6/mx6x_pins.h
index afaa068..377d97f 100644
--- a/arch/arm/include/asm/arch-mx6/mx6x_pins.h
+++ b/arch/arm/include/asm/arch-mx6/mx6x_pins.h
@@ -530,8 +530,8 @@ enum {
MX6Q_PAD_EIM_BCLK__IPU1_DI1_PIN16 = IOMUX_PAD(0x046C, 0x0158, 1,
0x, 0, 0),
MX6Q_PAD_EIM_BCLK__GPIO_6_31= IOMUX_PAD(0x046C, 0x0158, 5,
0x, 0, 0),
MX6Q_PAD_EIM_BCLK__TPSMP_HDATA_31 = IOMUX_PAD(0x046C, 0x0158, 6,
0x, 0, 0),
- MX6Q_PAD_DI0_DISP_CLK__IPU1_DI0_DSP_CLK = IOMUX_PAD(0x0470, 0x015C, 0,
0x, 0, 0),
- MX6Q_PAD_DI0_DISP_CLK__IPU2_DI0_DSP_CLK = IOMUX_PAD(0x0470, 0x015C, 1,
0x, 0, 0),
+ MX6Q_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK = IOMUX_PAD(0x0470, 0x015C, 0,
0x, 0, 0),
+ MX6Q_PAD_DI0_DISP_CLK__IPU2_DI0_DISP_CLK = IOMUX_PAD(0x0470, 0x015C, 1,
0x, 0, 0),
MX6Q_PAD_DI0_DISP_CLK__MIPI_CR_DPY_OT28 = IOMUX_PAD(0x0470, 0x015C, 3,
0x, 0, 0),
MX6Q_PAD_DI0_DISP_CLK__SDMA_DBG_CR_STA0 = IOMUX_PAD(0x0470, 0x015C, 4,
0x, 0, 0),
MX6Q_PAD_DI0_DISP_CLK__GPIO_4_16= IOMUX_PAD(0x0470, 0x015C, 5,
0x, 0, 0),
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] cache_v7: Check for dcache enablement in dcache flush functions
On 06/14/2012 10:48 PM, R, Sricharan wrote: Hi Tom, On Fri, Jun 15, 2012 at 12:31 AM, Tom Rini tr...@ti.com wrote: If we are built with D-CACHE enabled but have run 'dcache off' and then attempt to flush unaligned regions we spam the console with problems that aren't true (as the cache was off). Today we do cache maintenance operations after the dcache is turned off. One example is before jumping to kernel, we try to invalidate the caches, in cache turned off state. So with this patch those maintenance calls will do nothing, which is not correct. Ah yes, But, shouldn't we be doing these same operations as part of turning the cache off? If it is a problem with unaligned regions, then that is the only thing to be fixed right ?. Just trying to understand why this change is required ? The problem is that within the USB/network/filesystem stacks we have a lot of not cache safe alignments apparently. Without this every '#' of a tftp gives a screen full of error printfs. So tftp'ing a kernel takes minutes, not seconds, to complete. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] cache_v7: Check for dcache enablement in dcache flush functions
Dear Tom Rini, On 06/14/2012 10:48 PM, R, Sricharan wrote: Hi Tom, On Fri, Jun 15, 2012 at 12:31 AM, Tom Rini tr...@ti.com wrote: If we are built with D-CACHE enabled but have run 'dcache off' and then attempt to flush unaligned regions we spam the console with problems that aren't true (as the cache was off). Today we do cache maintenance operations after the dcache is turned off. One example is before jumping to kernel, we try to invalidate the caches, in cache turned off state. So with this patch those maintenance calls will do nothing, which is not correct. Ah yes, But, shouldn't we be doing these same operations as part of turning the cache off? If it is a problem with unaligned regions, then that is the only thing to be fixed right ?. Just trying to understand why this change is required ? The problem is that within the USB/network/filesystem stacks we have a lot of not cache safe alignments apparently. Without this every '#' of a tftp gives a screen full of error printfs. So tftp'ing a kernel takes minutes, not seconds, to complete. I think we should augment uboot to disallow tftp, fatload etc. to cache- unaligned address when caches are on ... this'd squash away the need for any shitty bounce buffers right away. Tom, will you be able to implement it, pretty please? Of course, this doesn't squash the need for fixing FS code etc. 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] mx6: Avoid writing to read-only bits in imximage.cfg
On 12/06/2012 16:50, Vikram Narayanan wrote: If in case this is valid according to the latest datasheet, ignore this patch. -- According to REV C manual, the register IOMUXC_IOMUXC_GPR4 has bits 4 and 5 read-only and the value is always set as zero. So write '0' to these bits instead of writing '1'. Signed-off-by: Vikram Narayanan vikram...@gmail.com Cc: Jason Liu r64...@freescale.com Cc: Dirk Behme dirk.be...@googlemail.com --- Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] cache_v7: Check for dcache enablement in dcache flush functions
On 06/15/2012 07:25 AM, Marek Vasut wrote: Dear Tom Rini, On 06/14/2012 10:48 PM, R, Sricharan wrote: Hi Tom, On Fri, Jun 15, 2012 at 12:31 AM, Tom Rini tr...@ti.com wrote: If we are built with D-CACHE enabled but have run 'dcache off' and then attempt to flush unaligned regions we spam the console with problems that aren't true (as the cache was off). Today we do cache maintenance operations after the dcache is turned off. One example is before jumping to kernel, we try to invalidate the caches, in cache turned off state. So with this patch those maintenance calls will do nothing, which is not correct. Ah yes, But, shouldn't we be doing these same operations as part of turning the cache off? If it is a problem with unaligned regions, then that is the only thing to be fixed right ?. Just trying to understand why this change is required ? The problem is that within the USB/network/filesystem stacks we have a lot of not cache safe alignments apparently. Without this every '#' of a tftp gives a screen full of error printfs. So tftp'ing a kernel takes minutes, not seconds, to complete. I think we should augment uboot to disallow tftp, fatload etc. to cache- unaligned address when caches are on ... this'd squash away the need for any shitty bounce buffers right away. Tom, will you be able to implement it, pretty please? But that's not the problem. The problem is all of the stuff going on within the USB/networking stack. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i.MX6 USDHC: Use the ESDHC clock
On 14/06/2012 15:44, Dirk Behme wrote:
From: Michael Langer michael.lan...@de.bosch.com
The commit i.mx: fsl_esdhc: add the i.mx6q support (4692708d) introduces
support for the i.MX6Q MMC host controller USDHC.
MXC_IPG_PERCLK sets the clock to 66MHz. This seems to be the default clock
of the ESDHC IP found in i.MX6 silicon. However, the default clock for the
USDHC
IP found in i.MX6 is 200MHz (MXC_ESDHC_CLK). This difference will cause a 3
times
higher clock on SD_CLK than expected (see fsl_esdh.c - set_sysctl()).
Signed-off-by: Michael Langer michael.lan...@de.bosch.com
CC: Stefano Babic sba...@denx.de
CC: Jason Liu r64...@freescale.com
---
arch/arm/cpu/armv7/imx-common/speed.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/armv7/imx-common/speed.c
b/arch/arm/cpu/armv7/imx-common/speed.c
index 2187e8e..80989c4 100644
--- a/arch/arm/cpu/armv7/imx-common/speed.c
+++ b/arch/arm/cpu/armv7/imx-common/speed.c
@@ -35,7 +35,11 @@ DECLARE_GLOBAL_DATA_PTR;
int get_clocks(void)
{
#ifdef CONFIG_FSL_ESDHC
+#ifdef CONFIG_FSL_USDHC
+ gd-sdhc_clk = mxc_get_clock(MXC_ESDHC_CLK);
+#else
gd-sdhc_clk = mxc_get_clock(MXC_IPG_PERCLK);
#endif
+#endif
return 0;
}
Acked-by: Stefano Babic sba...@denx.de
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] cache_v7: Check for dcache enablement in dcache flush functions
Dear Tom Rini, On 06/15/2012 07:25 AM, Marek Vasut wrote: Dear Tom Rini, On 06/14/2012 10:48 PM, R, Sricharan wrote: Hi Tom, On Fri, Jun 15, 2012 at 12:31 AM, Tom Rini tr...@ti.com wrote: If we are built with D-CACHE enabled but have run 'dcache off' and then attempt to flush unaligned regions we spam the console with problems that aren't true (as the cache was off). Today we do cache maintenance operations after the dcache is turned off. One example is before jumping to kernel, we try to invalidate the caches, in cache turned off state. So with this patch those maintenance calls will do nothing, which is not correct. Ah yes, But, shouldn't we be doing these same operations as part of turning the cache off? If it is a problem with unaligned regions, then that is the only thing to be fixed right ?. Just trying to understand why this change is required ? The problem is that within the USB/network/filesystem stacks we have a lot of not cache safe alignments apparently. Without this every '#' of a tftp gives a screen full of error printfs. So tftp'ing a kernel takes minutes, not seconds, to complete. I think we should augment uboot to disallow tftp, fatload etc. to cache- unaligned address when caches are on ... this'd squash away the need for any shitty bounce buffers right away. Tom, will you be able to implement it, pretty please? But that's not the problem. The problem is all of the stuff going on within the USB/networking stack. Correct. This will shield you from the users, I think it's worth to implement like that asap anyway. Or do we want a bounce buffer? I doubt that. The other part is to fix the internals of u-boot. This will be the harder part. 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] mx53ard: Remove unused CONFIG_MII_GASKET
On 07/06/2012 20:05, Fabio Estevam wrote: From: Fabio Estevam fabio.este...@freescale.com CONFIG_MII_GASKET is not defined anywhere, so remove it. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] imx31_phycore: Remove CONFIG_SYS_I2C_SLAVE definition
On 03/06/2012 09:53, Fabio Estevam wrote: From: Fabio Estevam fabio.este...@freescale.com According to include/i2c.h: /* * Many boards/controllers/drivers don't support an I2C slave interface so * provide a default slave address for them for use in common code. A real * value for CONFIG_SYS_I2C_SLAVE should be defined for any board which does * support a slave interface. */ #ifndef CONFIG_SYS_I2C_SLAVE #define CONFIG_SYS_I2C_SLAVE0xfe #endif Whole series applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] cache_v7: Check for dcache enablement in dcache flush functions
Hi, On Fri, Jun 15, 2012 at 12:31 AM, Tom Rini tr...@ti.com wrote: If we are built with D-CACHE enabled but have run 'dcache off' and then attempt to flush unaligned regions we spam the console with problems that aren't true (as the cache was off). Today we do cache maintenance operations after the dcache is turned off. One example is before jumping to kernel, we try to invalidate the caches, in cache turned off state. So with this patch those maintenance calls will do nothing, which is not correct. Ah yes, But, shouldn't we be doing these same operations as part of turning the cache off? The problem is that while turning of dcaches, we flush it, and turn cache and MMU off. But these operations are not happening automatically in a single call. So there is a chance of valid entries present in cache even after it is OFF. So we invalidate it before jumping to kernel. In fact our procedure of turning off the caches and MMU should have a relook, to really ensure things are safe. I will check on this more. If it is a problem with unaligned regions, then that is the only thing to be fixed right ?. Just trying to understand why this change is required ? The problem is that within the USB/network/filesystem stacks we have a lot of not cache safe alignments apparently. Without this every '#' of a tftp gives a screen full of error printfs. So tftp'ing a kernel takes minutes, not seconds, to complete. Ok,but when buffers are not aligned isn't that you are going to have coherency problems ? Thanks, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] imx25: Move MXC_GPIO_PORT_TO_NUM to imx-regs.h
On 13/06/2012 13:37, Fabio Estevam wrote: On Mon, Jun 11, 2012 at 12:02 PM, Vikram Narayanan vikram...@gmail.com wrote: Also, this macro is useful not only for mx25, and it would be nice to let it avaible for the other i.MX SoCs as well. Agree. But I guess u-boot doesn't have a common folder where this can be put up something like plat-mxc. So, I should think where to place this macro to avoid duplicates in many header files. Any pointers? Yes, a common folder would help indeed. Copying Stefano, so that he could provide us some suggestion on this. A general common folder helps - we have already an imx-common, whose name was copied from omap-common we already head. At the moment, it contains files common to i.MX5 and i.MX6. However, it is located under armv7, and it is not accessible for other i.MX. Really I am for a solution like in kernel, with a plat-mxc into include/asm/, where we can put common things for all i.MX. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] cache_v7: Check for dcache enablement in dcache flush functions
On 06/15/2012 07:48 AM, R, Sricharan wrote: Hi, On Fri, Jun 15, 2012 at 12:31 AM, Tom Rini tr...@ti.com wrote: If we are built with D-CACHE enabled but have run 'dcache off' and then attempt to flush unaligned regions we spam the console with problems that aren't true (as the cache was off). Today we do cache maintenance operations after the dcache is turned off. One example is before jumping to kernel, we try to invalidate the caches, in cache turned off state. So with this patch those maintenance calls will do nothing, which is not correct. Ah yes, But, shouldn't we be doing these same operations as part of turning the cache off? The problem is that while turning of dcaches, we flush it, and turn cache and MMU off. But these operations are not happening automatically in a single call. So there is a chance of valid entries present in cache even after it is OFF. So we invalidate it before jumping to kernel. In fact our procedure of turning off the caches and MMU should have a relook, to really ensure things are safe. I will check on this more. OK, thanks. If it is a problem with unaligned regions, then that is the only thing to be fixed right ?. Just trying to understand why this change is required ? The problem is that within the USB/network/filesystem stacks we have a lot of not cache safe alignments apparently. Without this every '#' of a tftp gives a screen full of error printfs. So tftp'ing a kernel takes minutes, not seconds, to complete. Ok,but when buffers are not aligned isn't that you are going to have coherency problems ? Exactly. USB requires dcache to be turned off today. With it turned off it spams these messages making tftp to an aligned address take minutes because the console is busy printing all of these messages about flushes it didn't need to do. The alternative is to build omap4/omap5/etc with dcache disabled or USB disabled. I think the answer here is we need to make sure that when we switch the cache off (dcache_off()) we're always doing the kind of flushing that we had been doing for the kernel. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] cache_v7: Check for dcache enablement in dcache flush functions
Hi, [snip..] If it is a problem with unaligned regions, then that is the only thing to be fixed right ?. Just trying to understand why this change is required ? The problem is that within the USB/network/filesystem stacks we have a lot of not cache safe alignments apparently. Without this every '#' of a tftp gives a screen full of error printfs. So tftp'ing a kernel takes minutes, not seconds, to complete. Ok,but when buffers are not aligned isn't that you are going to have coherency problems ? Exactly. USB requires dcache to be turned off today. With it turned off it spams these messages making tftp to an aligned address take minutes because the console is busy printing all of these messages about flushes it didn't need to do. The alternative is to build omap4/omap5/etc with dcache disabled or USB disabled. Ok, but who is calling cache maintenance in your case after turning off caches ? I think the answer here is we need to make sure that when we switch the cache off (dcache_off()) we're always doing the kind of flushing that we had been doing for the kernel. Yes, and also unaligned buffers will always be a problem. There should be a way to address that as well. Thanks, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] cache_v7: Check for dcache enablement in dcache flush functions
On 06/15/2012 08:18 AM, R, Sricharan wrote: Hi, [snip..] If it is a problem with unaligned regions, then that is the only thing to be fixed right ?. Just trying to understand why this change is required ? The problem is that within the USB/network/filesystem stacks we have a lot of not cache safe alignments apparently. Without this every '#' of a tftp gives a screen full of error printfs. So tftp'ing a kernel takes minutes, not seconds, to complete. Ok,but when buffers are not aligned isn't that you are going to have coherency problems ? Exactly. USB requires dcache to be turned off today. With it turned off it spams these messages making tftp to an aligned address take minutes because the console is busy printing all of these messages about flushes it didn't need to do. The alternative is to build omap4/omap5/etc with dcache disabled or USB disabled. Ok, but who is calling cache maintenance in your case after turning off caches ? The USB stack currently. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] am35xx, twister: could not write nand flash
On 06/15/2012 07:01 AM, Heiko Schocher wrote:
Hello Scott,
I currently tried current U-Boot HEAD
commit fedab338f3459315cb69627fcf46032ec8df1753
Merge: 74b5b5d f6b690e
Author: Wolfgang Denk w...@denx.de
Date: Thu Jun 7 23:42:17 2012 +0200
Merge branch 'master' of git://git.denx.de/u-boot-video
on the twister board, and detected that a run update fails with:
twister = run update
SW ECC selected
NAND erase: device 0 offset 0x8, size 0x10
Erasing at 0x16 -- 100% complete.
OK
NAND write:
(board hangs ...)
Environment var:
update=nandecc sw;nand erase ${uboot_addr} 10;nand write ${loadaddr}
${uboot_addr} 8
So I started git bisection:
[hs@pollux u-boot]$ git bisect start
[hs@pollux u-boot]$ git bisect bad
[hs@pollux u-boot]$ git bisect good
415d386877df49eb051b85ef74fa59a16dc17c7d
Bisecting: 211 revisions left to test after this (roughly 8 steps)
[...]
[hs@pollux u-boot]$ git bisect bad
418396e212b59bf907dbccad997ff50f7eb61b16 is the first bad commit
commit 418396e212b59bf907dbccad997ff50f7eb61b16
Author: Scott Wood scottw...@freescale.com
Date: Fri Mar 2 14:01:57 2012 -0600
nand: extend .raw accesses to work on multiple pages
A use for this is to read, modify, erase, and write an entire block
as a
single unit, as a replacement for the biterr command. This way gives
more flexibility in that you can also test multiple bit errors, errors
in the ECC, etc.
Signed-off-by: Scott Wood scottw...@freescale.com
:04 04 ad5ce55a0fdf3a40e1aaae0546aae68bf7a0b480
f57e87a8630715e37170b5bb3a109a58b6b89333 M common
:04 04 83834ae80a73f20357132875078f643b4064f9dd
ed0004e44b4da8b2734168a3950733afba0a0b64 M doc
[hs@pollux u-boot]$
following patch helps:
diff --git a/common/cmd_nand.c b/common/cmd_nand.c
index fa44295..edeb093 100644
--- a/common/cmd_nand.c
+++ b/common/cmd_nand.c
@@ -617,7 +617,7 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc,
char * const argv[])
s = strchr(cmd, '.');
- if (!strcmp(s, .raw)) {
+ if ((s != NULL) (!strcmp(s, .raw))) {
raw = 1;
if (arg_off(argv[3], dev, off, size))
What do you think? Is this a correct fix, and I should sent this as
a real patch, or did I overlook something?
This is the correct fix, and I have a pull request pending that contains
it. :-)
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] tegra: usb: Fix device enumeration problem of USB1
On 06/15/2012 03:38 AM, Jim Lin wrote:
On 06/14/2012 04:40 AM, Jim Lin wrote:
For some reason, bit 1 (connect status change) of PORTSC will be set
after issuing Port Reset (like usb reset in u-boot command line).
This will be treated as an error and stops later device enumeration.
Therefore we add a definition in header file to ignore checking of that bit
after Port Reset.
CONFIG_USB_RESET_IGNORE_CONNECT_CHANGE
(Again, I'm CC'ing the USB maintainer here)
Looking at the Linux kernel's Tegra EHCI driver:
a) This WAR is only needed on the first USB port, not all of them.
[Jim] No penalty for USB2 and USB3 ports. Because u-boot hub_port_reset
has at most 5 times of retry for a port.
USB2 and USB3 ports will reset once in retry loop
('port connect change' bit will not set after reset).
USB1 will have at most 2 times of reset in the retry loop after adding
this patch.
Yes, there is no time penalty, but presumably there's a reason that
hub_port_reset() explicitly checks whether PORT_STAT_C_CONNECTION is set
and fails if it is. This change will remove that check for USB2 and USB3
and thus change the behavior of those ports which are not affected by
the bug this patch is trying to fix.
b) This WAR is not complete; there's a loop in the kernel that resets
the port twice in order to guarantee that the port will become enabled.
[Jim] Disagree. Because u-boot hub_port_reset has at most 5 times of retry
for a port. U-boot and kernel code are not entirely same.
OK, I see the loop. It's not doing exactly what the kernel is to the HW,
but it's hopefully close enough.
So, rather than just ifdef'ing this fix into the driver, wouldn't it be
better to add a callback from the USB core into the USB driver, so that
the Tegra EHCI driver could choose to only implement this WAR for port
1, and also do the multiple-reset-loop thing.
[Jim] No callback for me to cut in. Also no penalty for other ports.
My point was that a callback (or perhaps some kind of per-port flag if
not an actual callback) could be added, not that there was one already
that should be used.
Finally, in the change description, the text for some reason is quite
unclear; it sounds like you have absolutely no idea why this happens. Is
this a known and root-caused HW bug for which this fix has been fully
validated? Or, is this patch just some random hack that seems to work
for you?
[Jim] This is a known and root-caused HW bug.
That's good to know. It'd be great if the commit description could be
more assertive on this point.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: support for cache coherent allocations
On Thu, Jun 14, 2012 at 8:13 AM, Ilya Yanok ilya.ya...@cogentembedded.com wrote: Hi All, On Thu, May 31, 2012 at 1:41 AM, Ilya Yanok ilya.ya...@cogentembedded.comwrote: This is a draft implementation of cache coherent memory allocator. This simple implementation just reserves memory area below malloc space and leave it uncached even if data cache is enabled. Allocations are even simpler: code just verifies that we have enough space and increments the offset counter. No deallocations supported for now. In future versions we could probably use dlmalloc allocator to get space out of coherent pool. Any comments on this? Albert? -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] imx25: Move MXC_GPIO_PORT_TO_NUM to imx-regs.h
Hi Stefano, On 6/15/2012 8:25 PM, Stefano Babic wrote: On 13/06/2012 13:37, Fabio Estevam wrote: On Mon, Jun 11, 2012 at 12:02 PM, Vikram Narayananvikram...@gmail.com wrote: Also, this macro is useful not only for mx25, and it would be nice to let it avaible for the other i.MX SoCs as well. Agree. But I guess u-boot doesn't have a common folder where this can be put up something like plat-mxc. So, I should think where to place this macro to avoid duplicates in many header files. Any pointers? Yes, a common folder would help indeed. Copying Stefano, so that he could provide us some suggestion on this. A general common folder helps - we have already an imx-common, whose name was copied from omap-common we already head. At the moment, it contains files common to i.MX5 and i.MX6. However, it is located under armv7, and it is not accessible for other i.MX. Really I am for a solution like in kernel, with a plat-mxc into include/asm/, where we can put common things for all i.MX. I'm with the same idea too. In this way we can avoid duplicate datastructures spread across many arch directories. So, are there any opposers for this? Regards, Vikram ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] imx25: Move MXC_GPIO_PORT_TO_NUM to imx-regs.h
On Fri, Jun 15, 2012 at 3:10 PM, Vikram Narayanan vikram...@gmail.com wrote: Really I am for a solution like in kernel, with a plat-mxc into include/asm/, where we can put common things for all i.MX. I'm with the same idea too. In this way we can avoid duplicate datastructures spread across many arch directories. Agree! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] tx25: Use generic gpio_* calls
Instead of manipulating gpio registers directly, use the calls
from the gpio library.
Signed-off-by: Vikram Narayanan vikram...@gmail.com
Acked-by: Stefano Babic sba...@denx.de
Cc: John Rigby jcri...@gmail.com
Cc: Fabio Estevam fabio.este...@freescale.com
---
Changes from v2:
Swap the place of the change log and commit message.
Changes from v1:
Used appropriate gpio_* lib calls.
board/karo/tx25/tx25.c | 25 +
1 files changed, 9 insertions(+), 16 deletions(-)
diff --git a/board/karo/tx25/tx25.c b/board/karo/tx25/tx25.c
index 2a29943..ff2de38 100644
--- a/board/karo/tx25/tx25.c
+++ b/board/karo/tx25/tx25.c
@@ -34,14 +34,13 @@
DECLARE_GLOBAL_DATA_PTR;
#ifdef CONFIG_FEC_MXC
+#define GPIO_FEC_RESET_B MXC_GPIO_PORT_TO_NUM(4, 7)
+#define GPIO_FEC_ENABLE_B MXC_GPIO_PORT_TO_NUM(4, 9)
void tx25_fec_init(void)
{
struct iomuxc_mux_ctl *muxctl;
struct iomuxc_pad_ctl *padctl;
- u32 val;
u32 gpio_mux_mode = MX25_PIN_MUX_MODE(5);
- struct gpio_regs *gpio4 = (struct gpio_regs *)IMX_GPIO4_BASE;
- struct gpio_regs *gpio3 = (struct gpio_regs *)IMX_GPIO3_BASE;
u32 saved_rdata0_mode, saved_rdata1_mode, saved_rx_dv_mode;
debug(tx25_fec_init\n);
@@ -66,18 +65,15 @@ void tx25_fec_init(void)
writel(0x0, padctl-pad_d11);
/* drop PHY power and assert reset (low) */
- val = readl(gpio4-gpio_dr) ~((1 7) | (1 9));
- writel(val, gpio4-gpio_dr);
- val = readl(gpio4-gpio_dir) | (1 7) | (1 9);
- writel(val, gpio4-gpio_dir);
+ gpio_direction_output(GPIO_FEC_RESET_B, 0);
+ gpio_direction_output(GPIO_FEC_ENABLE_B, 0);
mdelay(5);
debug(resetting phy\n);
/* turn on PHY power leaving reset asserted */
- val = readl(gpio4-gpio_dr) | 1 9;
- writel(val, gpio4-gpio_dr);
+ gpio_direction_output(GPIO_FEC_ENABLE_B, 1);
mdelay(10);
@@ -107,19 +103,16 @@ void tx25_fec_init(void)
/*
* set each to 1 and make each an output
*/
- val = readl(gpio3-gpio_dr) | (1 10) | (1 11) | (1 12);
- writel(val, gpio3-gpio_dr);
- val = readl(gpio3-gpio_dir) | (1 10) | (1 11) | (1 12);
- writel(val, gpio3-gpio_dir);
+ gpio_direction_output(MXC_GPIO_PORT_TO_NUM(3, 10), 1);
+ gpio_direction_output(MXC_GPIO_PORT_TO_NUM(3, 11), 1);
+ gpio_direction_output(MXC_GPIO_PORT_TO_NUM(3, 12), 1);
mdelay(22); /* this value came from RedBoot */
/*
* deassert PHY reset
*/
- val = readl(gpio4-gpio_dr) | 1 7;
- writel(val, gpio4-gpio_dr);
- writel(val, gpio4-gpio_dr);
+ gpio_set_value(GPIO_FEC_RESET_B, 1);
mdelay(5);
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] tx25: Use generic gpio_* calls
On Fri, Jun 15, 2012 at 3:26 PM, Vikram Narayanan vikram...@gmail.com wrote: /* turn on PHY power leaving reset asserted */ - val = readl(gpio4-gpio_dr) | 1 9; - writel(val, gpio4-gpio_dr); + gpio_direction_output(GPIO_FEC_ENABLE_B, 1); Please use gpio_set_value instead. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] USB DFU support into mailline.
Hi, Referring to http://elinux.org/Merge_DFU_support_into_mainline_U-Boot, it seems some work is going on for adding USB DFU support in the mainline for u-boot. But I could not find any code already in mainline. Is there anyone working on getting USB DFU support to mainline? I am working on USB DFU on AM335x BeagleBone, and I want help get USB DFU to mainline. Thanks, Harman ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/83xx: increment malloc heap size for the MPC832x MDS boards
On Sat, 17 Mar 2012 17:44:00 -0500 Timur Tabi ti...@freescale.com wrote: The malloc buffer is not large enough to hold a flash sector (0x2 bytes) in addition to whatever else it normally holds, so double its size. This fixes a failure trying to save the environment: = save Saving Environment to Flash... Unable to save the rest of sector (122880) . done Protected 1 sectors This problem probably surfaced from some other change that significantly increased the normal memory usage, thereby not leaving enough room for the saveenv command. Signed-off-by: Timur Tabi ti...@freescale.com --- applied, Thanks. Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] powerpc/83xx/km: use tuxx1.h for kmsupx5 target
On Thu, 14 Jun 2012 12:55:34 +0200 Holger Brunck holger.bru...@keymile.com wrote: Hi Kim, On 03/21/2012 01:42 PM, Holger Brunck wrote: This additional header is unneeded, we can use the tuxx1.h for this target. Signed-off-by: Holger Brunck holger.bru...@keymile.com cc: Kim Phillips kim.phill...@freescale.com cc: Valentin Longchamp valentin.longch...@keymile.com cc: Gerlando Falauto gerlando.fala...@keymile.com cc: Heiko Schocher h...@denx.de --- when do you find the time to pick up these two patch series or is something missing? : applied 6 out of 6 patches. Sorry for the delay. Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6: Make pad name macro consistent with the datasheet
Dear Ashok,
Use the same name as defined in the datasheet.
DSP_CLK - DISP_CLK
Signed-off-by: Ashok Kumar Reddy Kourla ashokkourla2...@gmail.com
Acked-by: Marek Vasut ma...@denx.de
---
arch/arm/include/asm/arch-mx6/mx6x_pins.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx6/mx6x_pins.h
b/arch/arm/include/asm/arch-mx6/mx6x_pins.h index afaa068..377d97f 100644
--- a/arch/arm/include/asm/arch-mx6/mx6x_pins.h
+++ b/arch/arm/include/asm/arch-mx6/mx6x_pins.h
@@ -530,8 +530,8 @@ enum {
MX6Q_PAD_EIM_BCLK__IPU1_DI1_PIN16 = IOMUX_PAD(0x046C, 0x0158, 1,
0x,
0, 0), MX6Q_PAD_EIM_BCLK__GPIO_6_31 = IOMUX_PAD(0x046C, 0x0158, 5,
0x, 0, 0), MX6Q_PAD_EIM_BCLK__TPSMP_HDATA_31 = IOMUX_PAD(0x046C,
0x0158, 6, 0x, 0, 0), - MX6Q_PAD_DI0_DISP_CLK__IPU1_DI0_DSP_CLK =
IOMUX_PAD(0x0470, 0x015C, 0, 0x, 0, 0),
- MX6Q_PAD_DI0_DISP_CLK__IPU2_DI0_DSP_CLK = IOMUX_PAD(0x0470, 0x015C, 1,
0x, 0, 0), + MX6Q_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK =
IOMUX_PAD(0x0470, 0x015C, 0, 0x, 0, 0),
+ MX6Q_PAD_DI0_DISP_CLK__IPU2_DI0_DISP_CLK = IOMUX_PAD(0x0470, 0x015C, 1,
0x, 0, 0), MX6Q_PAD_DI0_DISP_CLK__MIPI_CR_DPY_OT28 = IOMUX_PAD(0x0470,
0x015C, 3, 0x, 0, 0), MX6Q_PAD_DI0_DISP_CLK__SDMA_DBG_CR_STA0 =
IOMUX_PAD(0x0470, 0x015C, 4, 0x, 0, 0),
MX6Q_PAD_DI0_DISP_CLK__GPIO_4_16 = IOMUX_PAD(0x0470, 0x015C, 5, 0x,
0,
0),
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] USB DFU support into mailline.
Dear Sohanpal, Harman, Hi, Referring to http://elinux.org/Merge_DFU_support_into_mainline_U-Boot, it seems some work is going on for adding USB DFU support in the mainline for u-boot. But I could not find any code already in mainline. Is there anyone working on getting USB DFU support to mainline? I am working on USB DFU on AM335x BeagleBone, and I want help get USB DFU to mainline. Try looking through the u-boot mailing list. I think someone tried, but it needed more work. Thanks, Harman 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 0/6] further updates for keymile powerpc 83xx boards
On Fri, 4 May 2012 10:55:52 +0200 Holger Brunck holger.bru...@keymile.com wrote: This patchserie provides further updates for km ppc 83xx boards. One serie is already posted but until now not committed. This patch serie therefore is made on top of the first serie: http://lists.denx.de/pipermail/u-boot/2012-March/120694.html Beside some enhancements for kmcoge5ne, there are two common features for keymile boards changed. This is the change in the bootlimit and the addition of the check of the SW in a test_bank. Only km code is changed, there is no change in common u-boot code. Holger Brunck (1): km/common: increase bootlimit to 3 Stefan Bigler (1): powerpc/83xx/km: added missing enable of application buffer Thomas Herzmann (4): km/common: fixed error in ethaddr (1-byte-shift) powerpc/83xx: configure CONFIG_POST for kmcoge5ne powerpc/83xx/km: readout dip_switch on kmcoge5ne km/common: check test_bank and testpin for testboot board/keymile/common/common.c | 36 + board/keymile/common/common.h |8 +- board/keymile/common/ivm.c |2 +- board/keymile/km83xx/km83xx.c | 50 +++ include/configs/km/keymile-common.h |6 +++- include/configs/km8360.h|8 + 6 files changed, 106 insertions(+), 4 deletions(-) patches 1-6 out of 6 applied. Thanks, Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: support for cache coherent allocations
Dear Ilya Yanok, This is a draft implementation of cache coherent memory allocator. This simple implementation just reserves memory area below malloc space and leave it uncached even if data cache is enabled. Allocations are even simpler: code just verifies that we have enough space and increments the offset counter. No deallocations supported for now. In future versions we could probably use dlmalloc allocator to get space out of coherent pool. Signed-off-by: Ilya Yanok ilya.ya...@cogentembedded.com Hm, can't we just punch a hole in the MMU table at runtime instead of preallocating it like this? Also, what is this for? Can we not simply flush/invalidate the caches? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [GIT PULL] u-boot-mpc83xx: keymile boards updates
Hello Wolfgang Denk, Please pull: The following changes since commit fedab338f3459315cb69627fcf46032ec8df1753: Merge branch 'master' of git://git.denx.de/u-boot-video (2012-06-07 23:42:17 +0200) are available in the git repository at: git://git.denx.de/u-boot-mpc83xx.git master for you to fetch changes up to c1b3d84168ad423b3932f671c0863327fb005599: km/common: check test_bank and testpin for testboot (2012-06-15 17:12:52 -0500) Andreas Huber (1): km/common: add support for second flash Christian Herzig (1): powerpc83xx/km: lock the window size to 2GiB befor fixing sdram size Holger Brunck (5): powerpc/83xx/km: use tuxx1.h for kmsupx5 target powerpc83xx/km: remove unneeded CONFIG_PCI for kmeter1 powerpc/83xx: add kmcoge5ne board support MAINTAINERS: cleanup for keymile boards km/common: increase bootlimit to 3 Stefan Bigler (1): powerpc/83xx/km: added missing enable of application buffer Thomas Herzmann (4): km/common: fixed error in ethaddr (1-byte-shift) powerpc/83xx: configure CONFIG_POST for kmcoge5ne powerpc/83xx/km: readout dip_switch on kmcoge5ne km/common: check test_bank and testpin for testboot Timur Tabi (1): powerpc/83xx: increment malloc heap size for the MPC832x MDS boards MAINTAINERS | 12 +- board/keymile/common/common.c | 36 + board/keymile/common/common.h |8 +- board/keymile/common/ivm.c |2 +- board/keymile/km83xx/km83xx.c | 54 ++- boards.cfg | 11 +- include/configs/MPC832XEMDS.h |2 +- include/configs/km/keymile-common.h | 40 +++-- include/configs/km/km82xx-common.h |2 +- include/configs/km/km83xx-common.h | 13 +- include/configs/km/km_arm.h | 15 +- include/configs/km8360.h| 289 +++ include/configs/kmeter1.h | 187 --- include/configs/kmsupx5.h | 91 --- include/configs/tuxx1.h | 22 +-- 15 files changed, 461 insertions(+), 323 deletions(-) create mode 100644 include/configs/km8360.h delete mode 100644 include/configs/kmeter1.h Thanks, Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] ARM: add basic support for the Broadcom BCM2835 SoC
On 06/06/2012 11:45 PM, Stephen Warren wrote: This SoC is used in the Raspberry Pi, for example. Initial support is enough to boot to a serial console, and execute a minimal set of U-Boot commands. No drivers are implemented. For more details, see http://www.broadcom.com/products/BCM2835 or http://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf. Albert, Do these patches look good? I'm assuming you do accept direct patch emails, and aren't waiting for this to be part of a pull request or anything like that? Oleksandr Tymoshenko reports that he now has a working U-Boot USB driver for this SoC/board, so the port will soon be quite practically useful. Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ARM: bcm2835: add Raspberry Pi model B board
Hi Stephen, On 06/07/2012 03:45 PM, Stephen Warren wrote: The Raspberry Pi model B uses the BCM2835 SoC, has 256MB of RAM, contains an SMSC 9512 USB LAN/Hub chip, and various IO connectors. For more details, see http://www.raspberrypi.org/. Signed-off-by: Stephen Warren swar...@wwwdotorg.org Now I really can't wait for my Raspberry Pi to turn up (due on 25 June) Looking forward to trying this out - any hints / traps for young players? Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
