[U-Boot] [PATCH] i2c: mxs: Staticize the functions in the driver
The local functions in the mxs i2c driver are not marked static, make it so.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Stefano Babic sba...@denx.de
Cc: Heiko Schocher h...@denx.de
---
drivers/i2c/mxs_i2c.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/mxs_i2c.c b/drivers/i2c/mxs_i2c.c
index 2a193c2..31bfd90 100644
--- a/drivers/i2c/mxs_i2c.c
+++ b/drivers/i2c/mxs_i2c.c
@@ -36,7 +36,7 @@
#defineMXS_I2C_MAX_TIMEOUT 100
-void mxs_i2c_reset(void)
+static void mxs_i2c_reset(void)
{
struct mxs_i2c_regs *i2c_regs = (struct mxs_i2c_regs *)MXS_I2C0_BASE;
int ret;
@@ -55,7 +55,7 @@ void mxs_i2c_reset(void)
writel(I2C_QUEUECTRL_PIO_QUEUE_MODE, i2c_regs-hw_i2c_queuectrl_set);
}
-void mxs_i2c_setup_read(uint8_t chip, int len)
+static void mxs_i2c_setup_read(uint8_t chip, int len)
{
struct mxs_i2c_regs *i2c_regs = (struct mxs_i2c_regs *)MXS_I2C0_BASE;
@@ -73,7 +73,7 @@ void mxs_i2c_setup_read(uint8_t chip, int len)
writel(I2C_QUEUECTRL_QUEUE_RUN, i2c_regs-hw_i2c_queuectrl_set);
}
-void mxs_i2c_write(uchar chip, uint addr, int alen,
+static void mxs_i2c_write(uchar chip, uint addr, int alen,
uchar *buf, int blen, int stop)
{
struct mxs_i2c_regs *i2c_regs = (struct mxs_i2c_regs *)MXS_I2C0_BASE;
@@ -117,7 +117,7 @@ void mxs_i2c_write(uchar chip, uint addr, int alen,
writel(I2C_QUEUECTRL_QUEUE_RUN, i2c_regs-hw_i2c_queuectrl_set);
}
-int mxs_i2c_wait_for_ack(void)
+static int mxs_i2c_wait_for_ack(void)
{
struct mxs_i2c_regs *i2c_regs = (struct mxs_i2c_regs *)MXS_I2C0_BASE;
uint32_t tmp;
--
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 RESEND 2/4] video: Fix compilation dependency of exynos_dp and exynos_mipi on exynos_fb
On 2012년 12월 15일 14:25, Minkyu Kang wrote:
Dear Ajay,
On 13/12/12 20:29, Ajay Kumar wrote:
When only DP is used, we need not enable CONFIG_EXYNOS_MIPI_DSIM.
Similarly, when only MIPI is used, we need not enable CONFIG_EXYNOS_DP.
But the current structuring of code forces us to enable both
CONFIG_EXYNOS_MIPI_DSIM and CONFIG_EXYNOS_DP.
This patch adds conditional compilation check to remove the dependency.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
drivers/video/exynos_fb.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/video/exynos_fb.c b/drivers/video/exynos_fb.c
index d9a3f9a..39d3b74 100644
--- a/drivers/video/exynos_fb.c
+++ b/drivers/video/exynos_fb.c
@@ -103,8 +103,10 @@ static void lcd_panel_on(vidinfo_t *vid)
udelay(vid-power_on_delay);
+#ifdef CONFIG_EXYNOS_DP
if (vid-dp_enabled)
exynos_init_dp();
+#endif
Unnecessary.
please see arch/arm/include/asm/arch-exynos/dp_info.h
#ifdef CONFIG_EXYNOS_DP
unsigned int exynos_init_dp(void);
#else
unsigned int exynos_init_dp(void)
{
return 0;
}
#endif
if (vid-reset_lcd) {
vid-reset_lcd();
@@ -120,8 +122,10 @@ static void lcd_panel_on(vidinfo_t *vid)
if (vid-enable_ldo)
vid-enable_ldo(1);
+#ifdef CONFIG_EXYNOS_MIPI_DSIM
if (vid-mipi_enabled)
exynos_mipi_dsi_init();
+#endif
This should be modified like exynos_init_dp?
Donghwa, how you think?
I agree with you. It looks better than using #ifdef.
Thank you,
Donghwa Lee
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/4] EXYNOS5: Change parent clock of FIMD to MPLL
On 2012년 12월 15일 14:13, Minkyu Kang wrote: Dear Donghwa, On 13/12/12 20:29, Ajay Kumar wrote: With VPLL as source clock to FIMD, Exynos DP Initializaton was failing sometimes with unstable clock. Changing FIMD source to MPLL resolves this issue. Signed-off-by: Ajay Kumar ajaykumar...@samsung.com Acked-by: Simon Glass s...@chromium.org --- arch/arm/cpu/armv7/exynos/clock.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/cpu/armv7/exynos/clock.c b/arch/arm/cpu/armv7/exynos/clock.c index fe61f88..bfcd5f7 100644 --- a/arch/arm/cpu/armv7/exynos/clock.c +++ b/arch/arm/cpu/armv7/exynos/clock.c @@ -603,7 +603,7 @@ void exynos5_set_lcd_clk(void) */ cfg = readl(clk-src_disp1_0); cfg = ~(0xf); - cfg |= 0x8; + cfg |= 0x6; Please check it. In order to use the configured refresh rate as closely as possible, it is more proper value(MPLL: 0x6) than using VPLL as source clock. Thank you, Donghwa Lee ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] input: Add MELFAS mms144 touchscreen driver
From: Sanggun Leesg0724@samsung.com
This is a TSP driver for touchscreen chip mms144 of MELFAS.
It uses soft I2C interface and supports single touch.
This driver uses polling method.
If there are touch events, mms144_interrupt() reads and returns 0.
If not, mms144_interrupt() returns -1.
Signed-off-by: SangGun Leesg0724@samsung.com
Signed-off-by: Joonyoung Shimjy0922.s...@samsung.com
Signed-off=by: MyungJoo Hammyungjoo@samsung.com
---
drivers/input/Makefile |1 +
drivers/input/mms144.c | 202
include/mms144.h | 41 ++
3 files changed, 244 insertions(+), 0 deletions(-)
create mode 100644 drivers/input/mms144.c
create mode 100644 include/mms144.h
diff --git a/drivers/input/Makefile b/drivers/input/Makefile
index 0805e86..c802188 100644
--- a/drivers/input/Makefile
+++ b/drivers/input/Makefile
@@ -33,6 +33,7 @@ COBJS-$(CONFIG_PS2MULT) += ps2mult.o ps2ser.o
endif
COBJS-y += input.o
COBJS-$(CONFIG_OF_CONTROL) += key_matrix.o
+COBJS-$(CONFIG_MMS144) += mms144.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/input/mms144.c b/drivers/input/mms144.c
new file mode 100644
index 000..7532131
--- /dev/null
+++ b/drivers/input/mms144.c
@@ -0,0 +1,202 @@
+/*
+ * (C) Copyright 2012 Samsung Electronics
+ * Sang-gun Leesg0724@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
+ *
+ */
+
+#include common.h
+#include mms144.h
+#include i2c.h
+
+/* Operating Mode */
+#define mms144_SLEEP 0x01
+#define mms144_ACTIVE 0x02
+#define mms144_SW_RESET0x03
+
+/* Write only registers */
+#define mms144_MODE_CONTROL0x01
+
+/* Read only registers */
+#define mms144_PACKET_SIZE 0x0F
+#define mms144_INFOMATION 0x10
+
+/* Minimum delay time is 50us between stop and start signal of i2c */
+#define mms144_I2C_DELAY 50
+
+/* 200ms needs after power on */
+#define mms144_POWERON_DELAY 200
+
+/* Touchscreen absolute values */
+#define mms144_MAX_TOUCH 10
+
+/* XY calculate */
+#define X_SHIFT8
+#define Y_SHIFT4
+#define XY_HI_MASK 0xF00
+#define XY_LOW_MASK0xFF
+#define X_LOW_MASK 0x0F
+#define Y_LOW_MASK 0xF0
+
+/* Others */
+#define SETUP_REG_LEN 6
+#define POWER_ON 1
+#define POWER_OFF 0
+
+struct mms144_touch {
+ unsigned char info;
+ unsigned char xy_hi;
+ unsigned char x_lo;
+ unsigned char y_lo;
+} __packed;
+
+static struct mms144_platform *pdata;
+
+static int
+mms144_read_reg(unsigned int addr, unsigned char *val, unsigned int len)
+{
+ int error;
+
+ i2c_set_bus_num(pdata-bus_num);
+
+ error = i2c_read(pdata-chip, addr, 1, val, len);
+ if (error != 0) {
+ printf(mms144_read_reg is failed\n);
+ return error;
+ }
+ udelay(mms144_I2C_DELAY);
+
+ return 0;
+}
+
+static int
+mms144_write_reg(unsigned int addr, unsigned char *val, unsigned int len)
+{
+ int error;
+
+ i2c_set_bus_num(pdata-bus_num);
+
+ error = i2c_write(pdata-chip, addr, 1, val, len);
+ if (error != 0) {
+ printf(mms144_write_reg is failed\n);
+ return error;
+ }
+ udelay(mms144_I2C_DELAY);
+
+ return 0;
+}
+
+static int mms144_setup_reg(void)
+{
+ unsigned char setup_reg_buf[SETUP_REG_LEN];
+ int error;
+
+ /*
+* 0 = Mode Control
+* 1 = XY hi resolution
+* 2 = X low resolution
+* 3 = Y low resolution
+* 4 = Contact on event Threshold
+* 5 = Moving event Threshold
+*/
+ setup_reg_buf[0] = mms144_ACTIVE;
+ setup_reg_buf[1] = ((pdata-y_size Y_SHIFT) Y_LOW_MASK) |
+ ((pdata-x_size X_SHIFT) X_LOW_MASK);
+ setup_reg_buf[2] = pdata-x_size XY_LOW_MASK;
+ setup_reg_buf[3] = pdata-y_size XY_LOW_MASK;
+ setup_reg_buf[4] = pdata-contact_threshold;
+ setup_reg_buf[5] = pdata-moving_threshold;
+
+ /* burst write */
+ error =
Re: [U-Boot] [PATCH v2] mmc: Split device init to decouple OCR-polling delay
On 12/16/2012 02:18 AM, Simon Glass wrote:
Hi,
On Fri, Nov 30, 2012 at 3:13 PM, Simon Glass s...@chromium.org wrote:
Hi Jaehoon,
On Fri, Nov 30, 2012 at 12:25 AM, Jaehoon Chung jh80.ch...@samsung.com
wrote:
Hi,
This concept is very good.
But I have one question. I think need to call mmc_init() one more, right?
how did you save the boot time(200ms)?
On 11/29/2012 10:21 AM, Simon Glass wrote:
From: Che-Liang Chiou clch...@chromium.org
Most of time that MMC driver spends on initializing a device is polling
OCR (operation conditions register). To decouple this polling loop,
device init is split into two parts: The first part fires the OCR query
command, and the second part polls the result. So the caller is now no
longer bound to the OCR-polling delay; he may fire the query, go
somewhere and then come back later for the result.
To use this, call mmc_set_preinit() on any device which needs this.
This can save significant amounts of time on boot (e.g. 200ms) by
hiding the MMC init time behind other init.
snip..
+int mmc_init(struct mmc *mmc)
+{
+ int err = IN_PROGRESS;
+ unsigned start = get_timer(0);
+
+ if (mmc-has_init)
+ return 0;
+ if (!mmc-init_in_progress)
+ err = mmc_start_init(mmc);
It need not to return? if err is IN_PROGRESS, next condition is immediately
run.
Then i think we didn't save the time before adjust this patch.
It's a little confusing, but the way it works is that mmc_preinit()
calls mmc_start_init() early in boot. Then when mmc_init() finally
gets called (later) it finishes off the init. We still need mmc_init()
to actually fully complete the init. If it were to return before
completing the init then we would be unable to use the MMC.
+
+ if (!err || err == IN_PROGRESS)
+ err = mmc_complete_init(mmc);
+ debug(%s: %d, time %lu\n, __func__, err, get_timer(start));
return err;
}
Does this patch look good now? I am wondering if it will be including
in release, or in next?
Well, concept is very good. But i didn't see the any benefit yet.
I will test more...and share the result.
Best Regards,
Jaehoon Chung
Regards,
Simon
[snip]
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mmc: Split device init to decouple OCR-polling delay
Hi,
On Sun, Dec 16, 2012 at 6:12 PM, Jaehoon Chung jh80.ch...@samsung.com wrote:
On 12/16/2012 02:18 AM, Simon Glass wrote:
Hi,
On Fri, Nov 30, 2012 at 3:13 PM, Simon Glass s...@chromium.org wrote:
Hi Jaehoon,
On Fri, Nov 30, 2012 at 12:25 AM, Jaehoon Chung jh80.ch...@samsung.com
wrote:
Hi,
This concept is very good.
But I have one question. I think need to call mmc_init() one more, right?
how did you save the boot time(200ms)?
On 11/29/2012 10:21 AM, Simon Glass wrote:
From: Che-Liang Chiou clch...@chromium.org
Most of time that MMC driver spends on initializing a device is polling
OCR (operation conditions register). To decouple this polling loop,
device init is split into two parts: The first part fires the OCR query
command, and the second part polls the result. So the caller is now no
longer bound to the OCR-polling delay; he may fire the query, go
somewhere and then come back later for the result.
To use this, call mmc_set_preinit() on any device which needs this.
This can save significant amounts of time on boot (e.g. 200ms) by
hiding the MMC init time behind other init.
snip..
+int mmc_init(struct mmc *mmc)
+{
+ int err = IN_PROGRESS;
+ unsigned start = get_timer(0);
+
+ if (mmc-has_init)
+ return 0;
+ if (!mmc-init_in_progress)
+ err = mmc_start_init(mmc);
It need not to return? if err is IN_PROGRESS, next condition is
immediately run.
Then i think we didn't save the time before adjust this patch.
It's a little confusing, but the way it works is that mmc_preinit()
calls mmc_start_init() early in boot. Then when mmc_init() finally
gets called (later) it finishes off the init. We still need mmc_init()
to actually fully complete the init. If it were to return before
completing the init then we would be unable to use the MMC.
+
+ if (!err || err == IN_PROGRESS)
+ err = mmc_complete_init(mmc);
+ debug(%s: %d, time %lu\n, __func__, err, get_timer(start));
return err;
}
Does this patch look good now? I am wondering if it will be including
in release, or in next?
Well, concept is very good. But i didn't see the any benefit yet.
I will test more...and share the result.
OK thanks. Assuming that make sure that the pre-init is definitely
done, I suggest you then make U-Boot go and do something else for
200ms, then do the full mmc init after that. It should complete
immediately.
So there is no time saving in mmc init, but you can do something else
while waiting for the MMC init to complete (it takes 200ms or so for
me).
Another thing to note with eMMC is that we probe for SD first. This
takes a little bit of time. We could perhaps use device tree to
provide information about the type of attached memory, and thus avoid
that probe.
Regards,
Simon
Best Regards,
Jaehoon Chung
Regards,
Simon
[snip]
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH resend] armv7/ltimer: Add support for local timer on armv7 cpus
On 12/16/2012 1:14 PM, Dennis Lan (dlan) wrote: Hi On Sat, Dec 15, 2012 at 6:20 AM, Wolfgang Denk w...@denx.de mailto:w...@denx.de wrote: Dear Vipin Kumar, In message 50caf0cb.1050...@st.com mailto:50caf0cb.1050...@st.com you wrote: ping again pong ;-) On 12/6/2012 2:52 PM, Vipin KUMAR wrote: Certain ARMV7 cpus eg. CortexA9 contains a local and a global timer within the CPU core itself. This patch adds generic support for local timer. What would be the use of such timer support? Is there any code that actually needs it, and why does it need anything beyond the existing timer support we have? Hi wolfgang: I think vipin here is trying to provide a generic timer support for ARMV7 architecture, which contains private(local) and global timer. It's general a good thing which means we can maximize the code usage.. Actually I was planing to test the code, but haven't find the time yet ;-) Hello Wolfgang Dennis is right. I am trying to provide the armv7 local timer support. Hi vipin: why you only support local timer(private)? shouldn't it different to support global timer too? Well, actually the local timer was used in the spear13xx support which is to be added later on. The global timer was not used and hence the driver was not needed (at least by us). but I agree that such a driver would be useful for a lot of people using armv7 cores and CPU timers The global timer support, even if it is added, would be added as a separate driver so this is infact complete in its own Regards Vipin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] EXYNOS4: Add ORIGEN_QUAD board support
Dear Minky Kang,
Thanks for your concern.
According to your suggestion, I will fix it.
BRs,
JHKIM
2012년 12월 15일 14:56, Minkyu Kang 쓴 글:
Dear Jeong-Hyeon Kim,
On 13/12/12 19:37, Jeong-Hyeon Kim wrote:
ORIGEN_QUAD board is based on Samsung's Exynos4412 SoC.
Signed-off-by: Jeong-Hyeon Kim jh...@insignal.co.kr
---
Makefile |2 +-
board/samsung/origen_quad/Makefile| 59 ++
board/samsung/origen_quad/boot.c | 72 +++
board/samsung/origen_quad/clock.c | 103 ++
board/samsung/origen_quad/dmc.c | 163
board/samsung/origen_quad/lowlevel_init.S | 151 +++
board/samsung/origen_quad/origen_quad.c | 163
board/samsung/origen_quad/setup.h | 300
+
boards.cfg|1 +
include/configs/origen_quad.h | 179 +
tools/Makefile|2 +
11 files changed, 1194 insertions(+), 1 deletion(-)
create mode 100644 board/samsung/origen_quad/Makefile
create mode 100644 board/samsung/origen_quad/boot.c
create mode 100644 board/samsung/origen_quad/clock.c
create mode 100644 board/samsung/origen_quad/dmc.c
create mode 100644 board/samsung/origen_quad/lowlevel_init.S
create mode 100644 board/samsung/origen_quad/origen_quad.c
create mode 100644 board/samsung/origen_quad/setup.h
create mode 100644 include/configs/origen_quad.h
missing MAINTAINER entry.
+void save_boot_params(u32 r0, u32 r1, u32 r2, u32 r3) {}
diff --git a/board/samsung/origen_quad/clock.c
b/board/samsung/origen_quad/clock.c
new file mode 100644
index 000..7570039
--- /dev/null
+++ b/board/samsung/origen_quad/clock.c
@@ -0,0 +1,103 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics
+ *BR
+ * Copyright (C) 2012 Insignal
+ *
+ * Clock setup for the Insignal OrigenQUAD board (Exynos4x12)
+ *
+ * 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 config.h
+#include asm/io.h
+#include asm/arch/cpu.h
+#include asm/arch/clock.h
+#include setup.h
+
+void clock_ctrl_init(void)
+{
+struct exynos4x12_clock *clk =
+(struct exynos4x12_clock *)EXYNOS4_CLOCK_BASE;
please use samsung_get_base_clock() function.
+
+/* CLK_SRC_CPU */
+writel(0x, clk-src_cpu);
+sdelay(0x1);
+
+/* CLK_DIV_DMC */
+writel(CLK_DIV_DMC0_VAL, clk-div_dmc0);
+writel(CLK_DIV_DMC1_VAL, clk-div_dmc1);
+
+/* CLK_SRC_TOP */
+writel(CLK_SRC_TOP0_VAL, clk-src_top0);
+writel(CLK_SRC_TOP1_VAL, clk-src_top1);
+sdelay(0x1);
+writel(CLK_DIV_TOP_VAL, clk-div_top);
+
+/* LEFTBUS */
+writel(CLK_SRC_LEFTBUS_VAL, clk-src_leftbus);
+sdelay(0x1);
+writel(CLK_DIV_LEFTBUS_VAL, clk-div_leftbus);
+/* RIGHTBUS */
+writel(CLK_SRC_RIGHTBUS_VAL, clk-src_rightbus);
+sdelay(0x1);
+writel(CLK_DIV_RIGHTBUS_VAL, clk-div_rightbus);
+
+/* PLL locktime */
+writel(APLL_LOCK_VAL, clk-apll_lock);
+writel(MPLL_LOCK_VAL, clk-mpll_lock);
+writel(EPLL_LOCK_VAL, clk-epll_lock);
+writel(VPLL_LOCK_VAL, clk-vpll_lock);
+
+/* CLK_DIV_CPU0/1 */
+writel(CLK_DIV_CPU0_VAL, clk-div_cpu0);
+writel(CLK_DIV_CPU1_VAL, clk-div_cpu1);
+
+/* APLL */
+writel(APLL_CON1_VAL, clk-apll_con1);
+writel(APLL_CON0_VAL, clk-apll_con0);
+/* MPLL */
+writel(MPLL_CON1_VAL, clk-mpll_con1);
+writel(MPLL_CON0_VAL, clk-mpll_con0);
+/* EPLL */
+writel(EPLL_CON2_VAL, clk-epll_con2);
+writel(EPLL_CON1_VAL, clk-epll_con1);
+writel(EPLL_CON0_VAL, clk-epll_con0);
+/* VPLL */
+writel(VPLL_CON2_VAL, clk-vpll_con2);
+writel(VPLL_CON1_VAL, clk-vpll_con1);
+writel(VPLL_CON0_VAL, clk-vpll_con0);
+sdelay(0x4);
+
+writel(CLK_SRC_CPU_VAL, clk-src_cpu);
+writel(CLK_SRC_DMC_VAL, clk-src_dmc);
+writel(CLK_SRC_TOP0_VAL, clk-src_top0);
+writel(CLK_SRC_TOP1_VAL, clk-src_top1);
+sdelay(0x1);
+
+/* UART */
+writel(CLK_SRC_PERIL0_VAL, clk-src_peril0);
+writel(CLK_DIV_PERIL0_VAL, clk-div_peril0);
+
Re: [U-Boot] Atheros ART data crc calculation
Hello, I'm glad that all was resolved! However, the two versions provided each has some issues, but together I was able to reload the device. The first revision was able to erase the FLASH correctly, and the ethernet initialized correctly, however, there was no cp command to copy from RAM to FLASH. The second revision had the cp instruction and could write to the FLASH (at least the upper area where the bootloader was stored), however, ethernet did not function, and it could not erase the FLASH correctly. I would like to recompile a fully working RAM loadable U-Boot incase problems arise the the future, but am not sure what you changed between the two versions, so if you could share that, I would be happy, or share how to change the ethernet type, FLASH type, etc. The main changes to load from the memory implemented in this patch: http://dioptimizer.narod.ru/files/ap96/path.diff When you have a problem with uboot command flinfo, this patch may fix this problem: http://dioptimizer.narod.ru/files/ap96/path2.diff GPL Used: http://www.tp-link.com/resources/GPL/mr3420_3220v1.tar.gz You can use any other GPL (but only with the support configuration ap96). For example, I use a specific GPL, since there is no need to compile a new version of toolchain. However, you should understand that the configuration of the flash memory is set in ap96/boot/u-boot/include/configs/ap96.h. And detect the size of flash memory on SPI is nowhere realized. The commands used in uboot console set in parameter: CONFIG_COMMANDS (( When using the RAM loader - need to disable all the commands that depend on the environment variables on flash. I do not know the full configuration of your device and do not have no possibility to experiment with the settings. Concerning the second bank of flash memory: Recently asked on the OpenWRT forum about the use of two chips of flash memory on the device with the processor AR7241. https://forum.openwrt.org/viewtopic.php?id=41019 http://svn.dd-wrt.com:8000/browser/src/linux/pb42/linux-2.6.34.6/drivers/mtd/devices/wzrag300nh_flash.h?rev=15106 On the same example need to patch ap96/boot/u-boot/board/ar7100/common/ar7100_flash.h P.S. And I would like to clarify about the bootloader on Compex devices: http://wiki.openwrt.org/doc/techref/bootloader/myloader#myloram There is need to load the bootloader in the memory at address 0x81F0 On my device (AR7241) bootloader is loaded, !!!but at boot time it erased firmware workspace on flash memory!!! and by the way, it correctly determined the flash memory size. Best regards, Dmytro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] sf: Add Quad-input Page Program(32h) instruction support
Hi Thomas,
On Tue, Dec 11, 2012 at 5:00 PM, Langer Thomas (LQDE RD ST PON SW)
thomas.lan...@lantiq.com wrote:
Hello Jagannadha,
I have some remarks and questions, as I currently work on a hw platform,
which also would allow
to support dual- or quad-io accesses.
Planning to add reads too..
So my first question: why is this restricted to write only? If you have a
hardware, which is capable
of supporting this, the read will definitely benefit from it, while the
speedup for write depends on
the internal programming time of the flash.
Yes I will try to add these in near feature.
The other questions: On which hardware platform was this tested and for which
flashes?
Patches for both components are missing from this patch series.
Yes I am missing flash info..My plan will add the flash source.
Once this code is in a recommended position.
And for both I have more remarks below.
Jagannadha Sutradharudu Teki wrote on 2012-12-10:
This patch provides support to program a flash using
Quad-input Page Program(32h) instruction.
This will effectively increases the data transfer rate
by up to four times, as compared to the Page Program(PP) instruction.
Respective flash drivers need to use spi_flash_cmd_write_multi_qpp()
based on their usage.
+#ifdef CONFIG_CMD_SF_QPP
+ else if (strcmp(argv[0], write.qpp) == 0)
+ ret = spi_flash_write_qpp(flash, offset, len, buf);
+#endif
Is it really necessary to have a dedicated command here? Wouldn't it be
better, if the SF layer or
the driver will use it automatically, if the hardware supports it and the
driver has detected the
feature of the flash?
But I couldn't see any way to detect the read/write modes though
dedicated flash register.
Appreciate if you give any suggestion.
+#ifdef CONFIG_CMD_SF_QPP
+int spi_flash_set_quad_enable_bit(struct spi_flash *flash)
+{
[...]
+
+ if (data 0x2) {
+ debug(SF: quad enable bit is already set.\n);
Is this bit common for all flashes? Otherwise add some comments on tested
flashed
and/or TODO for an extension to provide this info from the flash driver.
OK, Thanks.
+ return ret;
+ } else {
+ debug(SF: need to set quad enable bit\n);
+
+ ret = spi_flash_cmd_write_config(flash, 0x0200);
Same here. And why is this a 16-bit value here?
Yes WRR with 16-bit data.
WRR CMD+status reg+config reg.
8 + 8 + 8 = 8-bit CMD and 16-bit DATA.
+int spi_flash_cmd_write_multi_qpp(struct spi_flash *flash, u32 offset,
+ size_t len, const void *buf)
+{
+ unsigned long page_addr, byte_addr, page_size;
+ size_t chunk_len, actual;
+ int ret;
+ u8 cmd[4];
+
+ page_size = flash-page_size;
+ page_addr = offset / page_size;
+ byte_addr = offset % page_size;
+
+ ret = spi_claim_bus(flash-spi);
+ if (ret) {
+ debug(SF: unable to claim SPI bus\n);
+ return ret;
+ }
+
+ ret = spi_flash_set_quad_enable_bit(flash);
I don't like this implicit setting here. And as far as I know, this bit is
sticky/non-volatile. It is not
necessary to write this each time.
I just check the config reg for quad bit if it is set already, return.
otherwise set the bit and read it again.
Maybe it make more sense to have an interactive command to write this bit
(enabled or disabled)
to the flash?
yes i have the same thought, but thinking..this bit needs to set only
on QUAD modes.
Why this needs to be a separate commands.
And then the flash probe function can check the bit and map to the
appropriate read and write
functions.
I am unclear.
Can you elaborate?
+ if (ret) {
+ debug(SF: set quad enable bit failed\n);
+ return ret;
+ }
+
+ cmd[0] = CMD_QUAD_PAGE_PROGRAM;
+ for (actual = 0; actual len; actual += chunk_len) {
+ chunk_len = min(len - actual, page_size - byte_addr);
+
+ cmd[1] = page_addr 8;
+ cmd[2] = page_addr;
+ cmd[3] = byte_addr;
+
+ debug(PP: 0x%p = cmd = { 0x%02x 0x%02x%02x%02x }
chunk_len = %zu\n,
+ buf + actual, cmd[0], cmd[1], cmd[2], cmd[3], chunk_len);
+
+ ret = spi_flash_cmd_write_enable(flash);
+ if (ret 0) {
+ debug(SF: enabling write failed\n);
+ break;
+ }
+
+ ret = spi_flash_cmd_write(flash-spi, cmd, 4,
+ buf + actual, chunk_len);
+ if (ret 0) {
+ debug(SF: write failed\n);
+ break;
+ }
Except for the config bit and the different command code, I don't see any
difference to the
regular spi_flash_cmd_write_multi function. So the question is: How does
the SPI framework
Yes, most of the code is redundant..
But my plan will short it up in near future a/f more testing. (not
touch the
