Re: [U-Boot] [PATCH] EXYNOS5: Add L2 Cache Support.
Hi Simon, Yes it is a V2 patch. Sorry I missed the add the same will submitting the patch. Regards, Rajeshwari Shinde. On Sun, Dec 9, 2012 at 1:08 AM, Simon Glass s...@chromium.org wrote: On Sat, Dec 8, 2012 at 11:38 AM, Simon Glass s...@chromium.org wrote: On Thu, Nov 29, 2012 at 10:29 PM, Rajeshwari Shinde rajeshwar...@samsung.com wrote: This patch set adds L2 Cache Support to EXYNOS. Signed-off-by: Arun Mankuzhi aru...@samsung.com Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com Acked-by: Simon Glass s...@chromium.org BTW I am assuming this is v2? It looks like it. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] universal_c210: fix compiler error and compiler warning
Dear Minkyu Kang,
In message 50c58623.3090...@samsung.com you wrote:
...
@@ -337,7 +341,7 @@ static void init_pmic_lcd(void)
unsigned char val;
int ret = 0;
- struct pmic *p = get_pmic();
+ struct pmic *p = pmic_get(MAX8998_PMIC);
if (pmic_probe(p))
return;
@@ -428,7 +432,7 @@ static void reset_lcd(void)
static void lcd_power_on(void)
{
- struct pmic *p = get_pmic();
+ struct pmic *p = pmic_get(MAX8998_PMIC);
if (pmic_probe(p))
return;
This is unrelated to your patch - but what if pmic_get() returns NULL?
pmic_probe() will crashif you pass it a NULL pointer...
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Digital computers are themselves more complex than most things people
build: They have very large numbers of states. This makes conceiving,
describing, and testing them hard. Software systems have orders-of-
magnitude more states than computers do. - Fred Brooks, Jr.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] universal_c210: fix compiler error and compiler warning
Hi Wolfgang,
Dear Minkyu Kang,
In message 50c58623.3090...@samsung.com you wrote:
...
@@ -337,7 +341,7 @@ static void init_pmic_lcd(void)
unsigned char val;
int ret = 0;
- struct pmic *p = get_pmic();
+ struct pmic *p = pmic_get(MAX8998_PMIC);
if (pmic_probe(p))
return;
@@ -428,7 +432,7 @@ static void reset_lcd(void)
static void lcd_power_on(void)
{
- struct pmic *p = get_pmic();
+ struct pmic *p = pmic_get(MAX8998_PMIC);
if (pmic_probe(p))
return;
This is unrelated to your patch - but what if pmic_get() returns NULL?
pmic_probe() will crashif you pass it a NULL pointer...
The PMIC 2.0 uses malloc to allocate pmic structure.
The fix, which has been proposed would work for old pmic.
In the new one PMIC 2.0, we require to test return pointer from
pmic_get() (similar to all malloc allocations):
struct pmic *p = pmic_get(MAX8998_PMIC);
if (!p)
return -ENODEV;
Best regards,
Wolfgang Denk
--
Best regards,
Lukasz Majewski
Samsung Poland RD Center | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/10] Add Marvell Dove and SolidRun CuBox
-Original Message- From: Sebastian Hesselbarth [mailto:sebastian.hesselba...@gmail.com] Sent: 04 December 2012 14:02 To: Sebastian Hesselbarth Cc: u-boot@lists.denx.de; Rabeeh Khoury; Albert Aribaud; Prafulla Wadaskar; Andy Fleming; Joe Hershberger; Daniel Stodden; Luka Perkov Subject: [PATCH v2 00/10] Add Marvell Dove and SolidRun CuBox This patch set add support for the Marvell Dove 88AP510 SoC and the SolidRun CuBox board based on that SoC. The patch set is divided into the four following sections: (1) Patches 1-5: Add support for the Dove SoC and related drivers. Where possible drivers from Marvell Kirkwood are reused (mvsata, mvgbe), or forked to allow more generic usage (SPI, GPIO). The SDHCI driver is different and a new driver is added for it. The forked drivers can also be reused on Kirkwood but that would have required patching existing boards. (2) Patches 6-8: Allow mvgbe to use the phylib API, add support for 88E1310 PHY and allow Dove to use the driver. (3) Patch 9 Add the SolidRun CuBox as the first board based on Marvell Dove SoC. (4) Patch 10 Add support for different UART boot mode found on Dove. Changelog: v1-v2: respect review comments by Luka Perkov - fix commenting styles and typos - add MAINTAINERS entry - also update kwboot.1 manpage Sebastian Hesselbarth (10): ARM: dove: add support for Marvell Dove SoC GPIO: add gpio driver for Orion SoCs MMC: sdhci: Add support for dove sdhci SPI: Add Orion SPI driver block: mvsata: add dove include NET: phy: add 88E1310 PHY initialization NET: mvgbe: add phylib support NET: mvgbe: add support for Dove Boards: Add support for SolidRun CuBox tools: Add support for Dove to kwboot MAINTAINERS |4 + arch/arm/cpu/armv7/dove/Makefile| 49 + arch/arm/cpu/armv7/dove/cpu.c | 266 ++ arch/arm/cpu/armv7/dove/dram.c | 118 arch/arm/cpu/armv7/dove/lowlevel_init.S | 83 arch/arm/cpu/armv7/dove/mpp.c | 318 +++ arch/arm/cpu/armv7/dove/timer.c | 176 + arch/arm/cpu/armv7/dove/usb.c | 101 ++ arch/arm/include/asm/arch-dove/config.h | 153 +++ arch/arm/include/asm/arch-dove/cpu.h| 204 arch/arm/include/asm/arch-dove/dove.h | 93 + arch/arm/include/asm/arch-dove/gpio.h | 35 arch/arm/include/asm/arch-dove/mpp.h| 283 +++ board/solidrun/cubox/Makefile | 45 + board/solidrun/cubox/cubox.c| 141 ++ board/solidrun/cubox/kwbimage.cfg | 76 boards.cfg |1 + doc/kwboot.1| 13 +- drivers/block/mvsata_ide.c |2 + drivers/gpio/Makefile |1 + drivers/gpio/orion_gpio.c | 167 drivers/mmc/Makefile|1 + drivers/mmc/dove_sdhci.c| 101 ++ drivers/net/mvgbe.c | 70 ++- drivers/net/mvgbe.h |7 + drivers/net/phy/marvell.c | 48 + drivers/spi/Makefile|1 + drivers/spi/orion_spi.c | 217 + include/configs/cubox.h | 175 + include/orion_gpio.h| 64 +++ tools/Makefile |2 + tools/kwboot.c | 44 - 32 files changed, 3048 insertions(+), 11 deletions(-) create mode 100644 arch/arm/cpu/armv7/dove/Makefile create mode 100644 arch/arm/cpu/armv7/dove/cpu.c create mode 100644 arch/arm/cpu/armv7/dove/dram.c create mode 100644 arch/arm/cpu/armv7/dove/lowlevel_init.S create mode 100644 arch/arm/cpu/armv7/dove/mpp.c create mode 100644 arch/arm/cpu/armv7/dove/timer.c create mode 100644 arch/arm/cpu/armv7/dove/usb.c create mode 100644 arch/arm/include/asm/arch-dove/config.h create mode 100644 arch/arm/include/asm/arch-dove/cpu.h create mode 100644 arch/arm/include/asm/arch-dove/dove.h create mode 100644 arch/arm/include/asm/arch-dove/gpio.h create mode 100644 arch/arm/include/asm/arch-dove/mpp.h create mode 100644 board/solidrun/cubox/Makefile create mode 100644 board/solidrun/cubox/cubox.c create mode 100644 board/solidrun/cubox/kwbimage.cfg create mode 100644 drivers/gpio/orion_gpio.c create mode 100644 drivers/mmc/dove_sdhci.c create mode 100644 drivers/spi/orion_spi.c create mode 100644 include/configs/cubox.h create mode 100644 include/orion_gpio.h Hi Sebastian First of all thanks for this patch series. FYI: I'll review and provide the comments towards the end of this week. Regards... Prafulla . . . ___ U-Boot mailing list
Re: [U-Boot] universal_c210: fix compiler error and compiler warning
Dear Wolfgang,
On 10/12/12 18:32, Lukasz Majewski wrote:
Hi Wolfgang,
Dear Minkyu Kang,
In message 50c58623.3090...@samsung.com you wrote:
...
@@ -337,7 +341,7 @@ static void init_pmic_lcd(void)
unsigned char val;
int ret = 0;
- struct pmic *p = get_pmic();
+ struct pmic *p = pmic_get(MAX8998_PMIC);
if (pmic_probe(p))
return;
@@ -428,7 +432,7 @@ static void reset_lcd(void)
static void lcd_power_on(void)
{
- struct pmic *p = get_pmic();
+ struct pmic *p = pmic_get(MAX8998_PMIC);
if (pmic_probe(p))
return;
This is unrelated to your patch - but what if pmic_get() returns NULL?
pmic_probe() will crashif you pass it a NULL pointer...
The PMIC 2.0 uses malloc to allocate pmic structure.
The fix, which has been proposed would work for old pmic.
In the new one PMIC 2.0, we require to test return pointer from
pmic_get() (similar to all malloc allocations):
struct pmic *p = pmic_get(MAX8998_PMIC);
if (!p)
return -ENODEV;
I will fix it by another patch.
Thanks.
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] universal_c210: fix compiler error and compiler warning
On 12/10/2012 07:50 AM, Minkyu Kang wrote:
This patch fix following errors
universal.c: In function 'init_pmic_lcd':
universal.c:340: warning: implicit declaration of function 'get_pmic'
universal.c:340: warning: initialization makes pointer from integer without a
cast
universal.c: In function 'lcd_power_on':
universal.c:431: warning: initialization makes pointer from integer without a
cast
universal.c: At top level:
universal.c:335: warning: 'init_pmic_lcd' defined but not used
Signed-off-by: Minkyu Kang mk7.k...@samsung.com
Cc: Donghwa Lee dh09@samsung.com
Cc: Lukasz Majewski l.majew...@samsung.com
---
board/samsung/universal_c210/universal.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/board/samsung/universal_c210/universal.c
b/board/samsung/universal_c210/universal.c
index 3d508be..4869798 100644
--- a/board/samsung/universal_c210/universal.c
+++ b/board/samsung/universal_c210/universal.c
@@ -55,6 +55,8 @@ static int get_hwrev(void)
return board_rev 0xFF;
}
+static void init_pmic_lcd(void);
+
int power_init_board(void)
{
int ret;
@@ -63,6 +65,8 @@ int power_init_board(void)
if (ret)
return ret;
+ init_pmic_lcd();
+
return 0;
}
@@ -337,7 +341,7 @@ static void init_pmic_lcd(void)
unsigned char val;
int ret = 0;
- struct pmic *p = get_pmic();
+ struct pmic *p = pmic_get(MAX8998_PMIC);
if (pmic_probe(p))
return;
@@ -428,7 +432,7 @@ static void reset_lcd(void)
static void lcd_power_on(void)
{
- struct pmic *p = get_pmic();
+ struct pmic *p = pmic_get(MAX8998_PMIC);
if (pmic_probe(p))
return;
Tested-by: Piotr Wilczek p.wilc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] universal_c210: fix compiler error and compiler warning
Dear Lukasz Majewski, In message 20121210103224.372c572e@amdc308.digital.local you wrote: This is unrelated to your patch - but what if pmic_get() returns NULL? pmic_probe() will crashif you pass it a NULL pointer... The PMIC 2.0 uses malloc to allocate pmic structure. ...and malloc() can fail. The fix, which has been proposed would work for old pmic. In the new one PMIC 2.0, we require to test return pointer from pmic_get() (similar to all malloc allocations): struct pmic *p = pmic_get(MAX8998_PMIC); if (!p) return -ENODEV; So this code here needs fixing. This is what I wanted to point out. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If you want to eat hippopatomus, you've got to pay the freight. - attributed to an IBM guy, about why IBM software uses so much memory ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Unable to Receive 1Kb of data
Dear lokesh nijalinge, In message cab-o9pgawedyszx7dqyczgvd-xsw_xffyxc-_rtlqmqipri...@mail.gmail.com you wrote: I am using the TI's DM3730 processors for one of my project. I want to *receive 1Kb of data* from UART2. At kernel i am able to send and receive full 1Kb of data. I am sending a buffer of 1Kb at UART2 and able to receive only 64 Bytes of data, i suppose this is due to the FIFO limitation. Please read http://catb.org/esr/faqs/smart-questions.html The describe exactly what you mean by sending and receiving. Are you talking about the standard console interface? Are you trying to transfer data using one of the download protocols? Which one? How exactly do you send your data? How do you configure the serial port on your host? etc. etc. - provide more details! Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There are no data that cannot be plotted on a straight line if the axis are chosen correctly. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] SMDK5250: Modify MAX77686 as per the latest Implementation
Resolved the compilation errors for PMIC MAX77686 on SMDK5250. Based on resolve branch of u-boot-samsung. Rajeshwari Shinde (2): POWER: MAX77686: Modified as per the latest Implementation SMDK5250: Enable pmic MAX77686 board/samsung/smdk5250/smdk5250.c | 15 +++- drivers/misc/pmic_max77686.c | 42 -- drivers/power/pmic/Makefile|1 + drivers/power/pmic/pmic_max77686.c | 48 +++ include/configs/smdk5250.h |8 +- include/max77686_pmic.h| 158 include/power/max77686_pmic.h | 158 7 files changed, 222 insertions(+), 208 deletions(-) delete mode 100644 drivers/misc/pmic_max77686.c create mode 100644 drivers/power/pmic/pmic_max77686.c delete mode 100644 include/max77686_pmic.h create mode 100644 include/power/max77686_pmic.h -- 1.7.4.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] POWER: MAX77686: Modified as per the latest Implementation
Moved the pmic_max77686.c max77686_pmic.h to drivers/power
and made required changes accordingly
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
drivers/misc/pmic_max77686.c | 42 --
drivers/power/pmic/Makefile|1 +
drivers/power/pmic/pmic_max77686.c | 48 +++
include/max77686_pmic.h| 158
include/power/max77686_pmic.h | 158
5 files changed, 207 insertions(+), 200 deletions(-)
delete mode 100644 drivers/misc/pmic_max77686.c
create mode 100644 drivers/power/pmic/pmic_max77686.c
delete mode 100644 include/max77686_pmic.h
create mode 100644 include/power/max77686_pmic.h
diff --git a/drivers/misc/pmic_max77686.c b/drivers/misc/pmic_max77686.c
deleted file mode 100644
index 36f7f4d..000
--- a/drivers/misc/pmic_max77686.c
+++ /dev/null
@@ -1,42 +0,0 @@
-/*
- * 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;
-
- return 0;
-}
diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
index e19a9a8..14d426f 100644
--- a/drivers/power/pmic/Makefile
+++ b/drivers/power/pmic/Makefile
@@ -28,6 +28,7 @@ LIB := $(obj)libpmic.o
COBJS-$(CONFIG_POWER_MAX8998) += pmic_max8998.o
COBJS-$(CONFIG_POWER_MAX8997) += pmic_max8997.o
COBJS-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
+COBJS-$(CONFIG_POWER_MAX77686) += pmic_max77686.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/power/pmic/pmic_max77686.c
b/drivers/power/pmic/pmic_max77686.c
new file mode 100644
index 000..fce0183
--- /dev/null
+++ b/drivers/power/pmic/pmic_max77686.c
@@ -0,0 +1,48 @@
+/*
+ * 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 power/pmic.h
+#include power/max77686_pmic.h
+#include errno.h
+
+int pmic_init(unsigned char bus)
+{
+ static const char name[] = MAX77686_PMIC;
+ struct pmic *p = pmic_alloc();
+
+ if (!p) {
+ printf(%s: POWER allocation error!\n, __func__);
+ return -ENOMEM;
+ }
+
+ 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 = bus;
+
+ return 0;
+}
diff --git a/include/max77686_pmic.h b/include/max77686_pmic.h
deleted file mode 100644
index d949ace..000
--- a/include/max77686_pmic.h
+++ /dev/null
@@ -1,158 +0,0 @@
-/*
- * 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
- *
[U-Boot] [PATCH 2/2] SMDK5250: Enable pmic MAX77686
Enabled pmic MAX77686 for SMDK5250.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
board/samsung/smdk5250/smdk5250.c | 15 +++
include/configs/smdk5250.h|8
2 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/board/samsung/smdk5250/smdk5250.c
b/board/samsung/smdk5250/smdk5250.c
index 4c50342..9c926d6 100644
--- a/board/samsung/smdk5250/smdk5250.c
+++ b/board/samsung/smdk5250/smdk5250.c
@@ -30,7 +30,7 @@
#include asm/arch/mmc.h
#include asm/arch/pinmux.h
#include asm/arch/sromc.h
-#include pmic.h
+#include power/pmic.h
DECLARE_GLOBAL_DATA_PTR;
@@ -65,9 +65,6 @@ static int smc9115_pre_init(void)
int board_init(void)
{
gd-bd-bi_boot_params = (PHYS_SDRAM_1 + 0x100UL);
-#if defined(CONFIG_PMIC)
- pmic_init();
-#endif
#ifdef CONFIG_EXYNOS_SPI
spi_init();
#endif
@@ -87,6 +84,16 @@ int dram_init(void)
return 0;
}
+#if defined(CONFIG_POWER)
+int power_init_board(void)
+{
+ if (pmic_init(I2C_PMIC))
+ return -1;
+ else
+ return 0;
+}
+#endif
+
void dram_init_banksize(void)
{
gd-bd-bi_dram[0].start = PHYS_SDRAM_1;
diff --git a/include/configs/smdk5250.h b/include/configs/smdk5250.h
index e412da8..df00305 100644
--- a/include/configs/smdk5250.h
+++ b/include/configs/smdk5250.h
@@ -65,7 +65,7 @@
#define INFORM1_OFFSET 0x804
/* Size of malloc() pool */
-#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (1 20))
+#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (4 20))
/* select serial console configuration */
#define CONFIG_SERIAL3 /* use SERIAL 3 */
@@ -209,9 +209,9 @@
#define CONFIG_SYS_I2C_SLAVE0x0
/* PMIC */
-#define CONFIG_PMIC
-#define CONFIG_PMIC_I2C
-#define CONFIG_PMIC_MAX77686
+#define CONFIG_POWER
+#define CONFIG_POWER_I2C
+#define CONFIG_POWER_MAX77686
/* SPI */
#define CONFIG_ENV_IS_IN_SPI_FLASH
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] EXYNOS: Add support for Exynos4x10
Dear Minkyu, The idea was to have Exynos4x10 and Exynos4x12 separately instead of Exynos4. As for now, when we use ex. exynos4_gpio_part1 it is not obvious which Exynos we refer to. Best regards, Piotr Wilczek From: Minkyu Kang [mailto:proms...@gmail.com] Sent: Friday, December 07, 2012 10:57 AM To: Piotr Wilczek Cc: u-boot@lists.denx.de; Kyungmin Park Subject: Re: [U-Boot] [PATCH 0/6] EXYNOS: Add support for Exynos4x10 2012년 10월 13일 토요일에 Piotr Wilczek님이 작성: This patch series adds Register base addresses, clock, gpio, power and system structures for Exynos4x10. Piotr Wilczek (6): Exynos: Exynos4x10: Add base addresses for Exynos4x10 Exynos: Exynos4x10: Add clock structure for exynos4x10 Exynos: Exynos4x10: Add gpio structure for Exynos4X10 Exynos: Exynos4x10: add power structure for Exynos4x10 Exynos: Exynos4x10: add sysreg structure for exynos4x10 arm: trats: Use exynos4x10 structures on Trats board arch/arm/include/asm/arch-exynos/clock.h | 236 + arch/arm/include/asm/arch-exynos/cpu.h| 43 +- arch/arm/include/asm/arch-exynos/gpio.h | 47 ++ arch/arm/include/asm/arch-exynos/power.h | 201 arch/arm/include/asm/arch-exynos/system.h |9 + board/samsung/trats/trats.c | 40 +++--- 6 files changed, 551 insertions(+), 25 deletions(-) I've rechecked this patch. Why we need to add exynos4x10? exynos4x10 is same with exynos4. Thanks. Minkyu Kang. -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-boot : compare read and expect value
Hi, I'm newbie and I want to use scripts to test the board peripherals (I2C, SPI, LAN, PCIe, USB, ...) using u-boot. My problem is how to compare the reading with the expected value? the reading is in an environment variable? If so which one? I searched the forums and docs without success. Thanks Best Regards, Khalid ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Unable to Receive 1Kb of data
Hi Sir, Thanks for the reply. I am trying to read around 1Kbyte of data from the serial port uart2. Standard serial console is uart1. I am using the function* NS16550_init() in drivers/serial/ns16550.c* file for the console initialization or configuration. I am using functions* NS16550_putc() *for sending data byte by byte and * NS16550_getc()* for receiving data(same file). By receiving and sending i mean to say the UART2 RX(receive) and UART2 TX(transmit) respectively. I have a device connected to serial port UART2 which sends the data around 1Kb. I am able to receive only 64 bytes now. This may be because of the FIFO limitation in H/W, which is 64bytes. Regards, Lokesh Kumar On Mon, Dec 10, 2012 at 4:28 PM, Wolfgang Denk w...@denx.de wrote: Dear lokesh nijalinge, In message cab-o9pgawedyszx7dqyczgvd-xsw_xffyxc-_rtlqmqipri...@mail.gmail.com you wrote: I am using the TI's DM3730 processors for one of my project. I want to *receive 1Kb of data* from UART2. At kernel i am able to send and receive full 1Kb of data. I am sending a buffer of 1Kb at UART2 and able to receive only 64 Bytes of data, i suppose this is due to the FIFO limitation. Please read http://catb.org/esr/faqs/smart-questions.html The describe exactly what you mean by sending and receiving. Are you talking about the standard console interface? Are you trying to transfer data using one of the download protocols? Which one? How exactly do you send your data? How do you configure the serial port on your host? etc. etc. - provide more details! Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There are no data that cannot be plotted on a straight line if the axis are chosen correctly. -- Thanks Regards, Lokesh Kumar, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Unable to Receive 1Kb of data
Dear lokesh nijalinge, please don't top post / full quote. In message cab-o9pjgvqndjgd7p9fhn0ey9f6erdjfr0nvfk8ofrny+56...@mail.gmail.com you wrote: I am trying to read around 1Kbyte of data from the serial port uart2. Standard serial console is uart1. I am using the function* NS16550_init() in drivers/serial/ns16550.c* file for the console initialization or configuration. I am using functions* NS16550_putc() *for sending data byte by byte and * NS16550_getc()* for receiving data(same file). By receiving and sending i mean to say the UART2 RX(receive) and UART2 TX(transmit) respectively. You add very little information actually. Sorry, With so little context it's impossible to comment. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It is dangerous to be sincere unless you are also stupid. - George Bernard Shaw ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot : compare read and expect value
Dear Khalid Tourabi, In message 50c5c063.2020...@planar.com you wrote: I'm newbie and I want to use scripts to test the board peripherals (I2C, SPI, LAN, PCIe, USB, ...) using u-boot. My problem is how to compare the reading with the expected value? the reading is in an environment variable? If so which one? I searched the forums and docs without success. Have a look at the setexpr command... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Ein weiser Herrscher kann in einem großen Land mehr Gutes bewirken als in einem kleinen - ein dummer Herrscher aber auch viel mehr Un- fug. Da weise Herrscher seltener sind als dumme, war ich schon immer gegen große Reiche skeptisch. - Herbert Rosendorfer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] SMDK5250: Modify MAX77686 as per the latest Implementation
Hi Rajeshwari, Resolved the compilation errors for PMIC MAX77686 on SMDK5250. Based on resolve branch of u-boot-samsung. Rajeshwari Shinde (2): POWER: MAX77686: Modified as per the latest Implementation SMDK5250: Enable pmic MAX77686 board/samsung/smdk5250/smdk5250.c | 15 +++- drivers/misc/pmic_max77686.c | 42 -- drivers/power/pmic/Makefile|1 + drivers/power/pmic/pmic_max77686.c | 48 +++ include/configs/smdk5250.h |8 +- include/max77686_pmic.h| 158 include/power/max77686_pmic.h | 158 7 files changed, 222 insertions(+), 208 deletions(-) delete mode 100644 drivers/misc/pmic_max77686.c create mode 100644 drivers/power/pmic/pmic_max77686.c delete mode 100644 include/max77686_pmic.h create mode 100644 include/power/max77686_pmic.h Reviewed-by: Lukasz Majewski l.majew...@samsung.com Acked-by: Lukasz Majewski l.majew...@samsung.com Thanks :-) -- Best regards, Lukasz Majewski Samsung Poland RD Center | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] env_nand.c: support falling back to redundant env when writing
On Fri, Dec 07, 2012 at 11:38:11AM -0600, Scott Wood wrote: On 12/07/2012 10:58:53 AM, Phil Sutter wrote: Scott, On Fri, Dec 07, 2012 at 12:53:34PM +0100, Phil Sutter wrote: On Thu, Dec 06, 2012 at 12:18:39PM -0600, Scott Wood wrote: On 11/28/2012 03:06:00 PM, Phil Sutter wrote: Hi, On Tue, Nov 27, 2012 at 04:04:15PM -0600, Scott Wood wrote: On 11/21/2012 06:59:19 AM, Phil Sutter wrote: Without this patch, when the currently chosen environment to be written has bad blocks, saveenv fails completely. Instead, when there is redundant environment fall back to the other copy. Environment reading needs no adjustment, as the fallback logic for incomplete writes applies to this case as well. Signed-off-by: Phil Sutter phil.sut...@viprinet.com Isn't this what CONFIG_ENV_RANGE is supposed to deal with? Yes, that is more or less what is supposed to help for cases like this. But given the fact that CONFIG_ENV_RANGE needs to span multiple erase pages which in our case are 128k in size, this is quite a deal. Especially since one needs to have multiple pages for both normal and redundant environment to be really sure. And *that* is what CONFIG_ENV_OFFSET_OOB is supposed to deal with. :-) Good to know, I already wondered what exactly this option is there for. Hmm. Does not look like CONFIG_ENV_OFFSET_OOB is used to select the block(s) within the erase page to save the environment. Looking at common/env_nand.c:318, the environment offset saved in the OOB seems to be in erase page unit. I'm not sure what you mean by block(s) within the erase page -- blocks are the unit of erasing, and of bad block marking. Not always, at least not with NAND flash. Erase pages are mostly bigger than write pages (or blocks). In my case, flash consists of 0x800 bytes write pages and 0x2000 bytes erase pages. The block to hold the environment is stored in the OOB of block zero, which is usually guaranteed to not be bad. Erase or write block? Note that every write block has it's own OOB. On the other hand, I could not find code that alters this setting based on bad blocks found or whatever. This seems to simply be an alternative to setting CONFIG_ENV_OFFSET at build-time. It is set by the nand env.oob command. It is currently a manual process (or rather, automation is left to the user's board preparation process rather than being built into U-Boot), as U-Boot wouldn't know how to give back unused blocks to other purposes. So that assumes that any block initially identified 'good' will ever turn 'bad' later on? Best wishes, Phil Sutter Software Engineer -- Viprinet Europe GmbH Mainzer Str. 43 55411 Bingen am Rhein Germany Phone/Zentrale: +49 6721 49030-0 Direct line/Durchwahl:+49 6721 49030-134 Fax: +49 6721 49030-109 phil.sut...@viprinet.com http://www.viprinet.com Registered office/Sitz der Gesellschaft: Bingen am Rhein, Germany Commercial register/Handelsregister: Amtsgericht Mainz HRB44090 CEO/Geschäftsführer: Simon Kissel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] universal_c210: check the NULL pointer when get the PMIC
PMIC 2.0 require to test return pointer from pmic_get()
Signed-off-by: Minkyu Kang mk7.k...@samsung.com
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Wolfgang Denk w...@denx.de
---
board/samsung/universal_c210/universal.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/board/samsung/universal_c210/universal.c
b/board/samsung/universal_c210/universal.c
index 4869798..ae24469 100644
--- a/board/samsung/universal_c210/universal.c
+++ b/board/samsung/universal_c210/universal.c
@@ -343,6 +343,9 @@ static void init_pmic_lcd(void)
struct pmic *p = pmic_get(MAX8998_PMIC);
+ if (!p)
+ return -ENODEV;
+
if (pmic_probe(p))
return;
@@ -434,6 +437,9 @@ static void lcd_power_on(void)
{
struct pmic *p = pmic_get(MAX8998_PMIC);
+ if (!p)
+ return -ENODEV;
+
if (pmic_probe(p))
return;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/4] sf: New flash command support
Patches mostly provides a new flash command (QPP), config register writing and some print support on flash read/write. Thanks, Jagan. Jagannadha Sutradharudu Teki (4): sf: Enable prints on erase and write functions sf: Add print message on flash read function sf: Add configuration register writing sf: Add Quad-input Page Program(32h) instruction support README |1 + common/cmd_sf.c | 12 +++- drivers/mtd/spi/spi_flash.c | 146 +- drivers/mtd/spi/spi_flash_internal.h | 16 include/spi_flash.h | 12 +++ 5 files changed, 182 insertions(+), 5 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] sf: Enable prints on erase and write functions
This patch provides to enabled the prints on erase and write functions to make sure that how many bytes erase/write into flash device. Signed-off-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com --- drivers/mtd/spi/spi_flash.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c index 00aece9..464c2ab 100644 --- a/drivers/mtd/spi/spi_flash.c +++ b/drivers/mtd/spi/spi_flash.c @@ -115,7 +115,7 @@ int spi_flash_cmd_write_multi(struct spi_flash *flash, u32 offset, byte_addr = 0; } - debug(SF: program %s %zu bytes @ %#x\n, + printf(SF: program %s %zu bytes @ %#x\n, ret ? failure : success, len, offset); spi_release_bus(flash-spi); @@ -235,7 +235,7 @@ int spi_flash_cmd_erase(struct spi_flash *flash, u32 offset, size_t len) goto out; } - debug(SF: Successfully erased %zu bytes @ %#x\n, len, start); + printf(SF: Successfully erased %zu bytes @ %#x\n, len, start); out: spi_release_bus(flash-spi); -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] sf: Add print message on flash read function
This patch adds a print message on spi_flash_cmd_read_fast()
to make sure that how many bytes read from flash device.
Signed-off-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com
---
drivers/mtd/spi/spi_flash.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 464c2ab..800ed8b 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -139,12 +139,17 @@ int spi_flash_cmd_read_fast(struct spi_flash *flash, u32
offset,
size_t len, void *data)
{
u8 cmd[5];
+ int ret;
cmd[0] = CMD_READ_ARRAY_FAST;
spi_flash_addr(offset, cmd);
cmd[4] = 0x00;
- return spi_flash_read_common(flash, cmd, sizeof(cmd), data, len);
+ ret = spi_flash_read_common(flash, cmd, sizeof(cmd), data, len);
+ printf(SF: re-program %s %zu bytes @ %#x\n,
+ ret ? failure : success, len, offset);
+
+ return ret;
}
int spi_flash_cmd_poll_bit(struct spi_flash *flash, unsigned long timeout,
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] sf: Add configuration register writing
This patch provides support to program a flash config register.
Configuration register contains the control bits used to configure
the different configurations and security features of a device.
User need to set these bits through spi_flash_cmd_write_config()
based on their usage.
Signed-off-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com
---
drivers/mtd/spi/spi_flash.c | 27 +++
drivers/mtd/spi/spi_flash_internal.h |3 +++
2 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 800ed8b..a8f0af0 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -274,6 +274,33 @@ int spi_flash_cmd_write_status(struct spi_flash *flash, u8
sr)
return 0;
}
+int spi_flash_cmd_write_config(struct spi_flash *flash, u16 cr)
+{
+ u8 cmd;
+ int ret;
+
+ ret = spi_flash_cmd_write_enable(flash);
+ if (ret 0) {
+ debug(SF: enabling write failed\n);
+ return ret;
+ }
+
+ cmd = CMD_WRITE_STATUS;
+ ret = spi_flash_cmd_write(flash-spi, cmd, 1, cr, 2);
+ if (ret) {
+ debug(SF: fail to write config register\n);
+ return ret;
+ }
+
+ ret = spi_flash_cmd_wait_ready(flash, SPI_FLASH_PROG_TIMEOUT);
+ if (ret 0) {
+ debug(SF: write config register timed out\n);
+ return ret;
+ }
+
+ return 0;
+}
+
/*
* The following table holds all device probe functions
*
diff --git a/drivers/mtd/spi/spi_flash_internal.h
b/drivers/mtd/spi/spi_flash_internal.h
index 141cfa8..9287778 100644
--- a/drivers/mtd/spi/spi_flash_internal.h
+++ b/drivers/mtd/spi/spi_flash_internal.h
@@ -77,6 +77,9 @@ static inline int spi_flash_cmd_write_disable(struct
spi_flash *flash)
/* Program the status register. */
int spi_flash_cmd_write_status(struct spi_flash *flash, u8 sr);
+/* Program the config register. */
+int spi_flash_cmd_write_config(struct spi_flash *flash, u16 cr);
+
/*
* Same as spi_flash_cmd_read() except it also claims/releases the SPI
* bus. Used as common part of the -read() operation.
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] sf: Add Quad-input Page Program(32h) instruction support
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.
Signed-off-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com
---
README |1 +
common/cmd_sf.c | 12 +++-
drivers/mtd/spi/spi_flash.c | 108 ++
drivers/mtd/spi/spi_flash_internal.h | 13
include/spi_flash.h | 12
5 files changed, 144 insertions(+), 2 deletions(-)
diff --git a/README b/README
index 5a86ae9..a01de13 100644
--- a/README
+++ b/README
@@ -869,6 +869,7 @@ The following options need to be configured:
CONFIG_CMD_SETGETDCR Support for DCR Register access
(4xx only)
CONFIG_CMD_SF * Read/write/erase SPI NOR flash
+ CONFIG_CMD_SF_QPP * Program SPI flash using Quad-input
Page Program
CONFIG_CMD_SHA1SUMprint sha1 memory digest
(requires CONFIG_CMD_MEMORY)
CONFIG_CMD_SOURCE source command Support
diff --git a/common/cmd_sf.c b/common/cmd_sf.c
index 5ac1d0c..a449d2c 100644
--- a/common/cmd_sf.c
+++ b/common/cmd_sf.c
@@ -228,6 +228,10 @@ static int do_spi_flash_read_write(int argc, char * const
argv[])
ret = spi_flash_update(flash, offset, len, buf);
else if (strcmp(argv[0], read) == 0)
ret = spi_flash_read(flash, offset, len, buf);
+#ifdef CONFIG_CMD_SF_QPP
+ else if (strcmp(argv[0], write.qpp) == 0)
+ ret = spi_flash_write_qpp(flash, offset, len, buf);
+#endif
else
ret = spi_flash_write(flash, offset, len, buf);
@@ -300,7 +304,7 @@ static int do_spi_flash(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[
}
if (strcmp(cmd, read) == 0 || strcmp(cmd, write) == 0 ||
- strcmp(cmd, update) == 0)
+ strcmp(cmd, update) == 0 || strcmp(cmd, write.qpp) == 0)
ret = do_spi_flash_read_write(argc, argv);
else if (strcmp(cmd, erase) == 0)
ret = do_spi_flash_erase(argc, argv);
@@ -327,5 +331,9 @@ U_BOOT_CMD(
sf erase offset [+]len - erase `len' bytes from `offset'\n
`+len' round up `len' to block size\n
sf update addr offset len - erase and write `len' bytes from
memory\n
-at `addr' to flash at `offset'
+at `addr' to flash at `offset'\n
+#ifdef CONFIG_CMD_SF_QPP
+ sf write.qpp addr offset len - write `len' bytes from memory\n
+at `addr' to flash at `offset' using
Quad-input Page Program(32h)
+#endif
);
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index a8f0af0..3545f59 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -122,6 +122,114 @@ int spi_flash_cmd_write_multi(struct spi_flash *flash,
u32 offset,
return ret;
}
+#ifdef CONFIG_CMD_SF_QPP
+int spi_flash_set_quad_enable_bit(struct spi_flash *flash)
+{
+ u8 cmd = CMD_READ_CONFIG;
+ u8 data = 0;
+ int ret;
+
+ ret = spi_flash_read_common(flash,
+ cmd, sizeof(cmd), data, sizeof(data));
+ if (ret 0) {
+ debug(SF: fail to read config register\n);
+ return ret;
+ }
+
+ if (data 0x2) {
+ debug(SF: quad enable bit is already set.\n);
+ return ret;
+ } else {
+ debug(SF: need to set quad enable bit\n);
+
+ ret = spi_flash_cmd_write_config(flash, 0x0200);
+ if (ret 0) {
+ debug(SF: fail to write quad enable bit\n);
+ return ret;
+ }
+
+ ret = spi_flash_read_common(flash,
+ cmd, sizeof(cmd), data, sizeof(data));
+ if (ret 0) {
+ debug(SF: fail to read config register\n);
+ return ret;
+ }
+
+ if (data 0x2)
+ debug(SF: successfully set quad enable bit\n);
+ else {
+ printf(SF: fail to set quad enable bit\n);
+ return -1;
+ }
+ }
+
+ return ret;
+}
+
+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 =
Re: [U-Boot] U-boot : compare read and expect value
Dear Khalid Tourabi, please don't top post / full quote, and keep the mailing list on Cc: In message 50c5f2d6.5060...@planar.com you wrote: Thanks for your answer. setexpr command allows set the result operation in an environment variable. But I want to set the result command (string) in an environment variable to compare it with the expect value. Build it from parts. Start with putting the expected value in an environment variable, so you can use setexpr to compareit against the actual value. Then use conditionals to react as needed. Use standard shell scripting methods. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You can't have everything... where would you put it? - Steven Wright ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] u-boot-mips/master
On Sat, Dec 08, 2012 at 09:57:28PM +0100, Daniel Schwierzeck wrote: Hi Tom, please pull two bugfixes for MIPS The following changes since commit fd4d564b3c80b111f18c93adb14233a6a7ddb0e9: Merge branch 'master' of git://git.denx.de/u-boot-x86 (2012-12-07 08:47:59 -0700) are available in the git repository at: git://git.denx.de/u-boot-mips.git master for you to fetch changes up to ea40a05422bdc87a7af5dc349e8adce59f982e72: MIPS: constify address pointer in test_bit() (2012-12-08 21:48:19 +0100) Daniel Schwierzeck (1): MIPS: constify address pointer in test_bit() Zhi-zhou Zhang (1): MIPS: fix a latent bug on initialize $gp arch/mips/cpu/mips64/start.S | 7 ++- arch/mips/include/asm/bitops.h | 2 +- 2 files changed, 7 insertions(+), 2 deletions(-) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] [nand] Implement nand_extent_skip_bad
When accessing nand any bad blocks encountered are skipped, with no
indication about the amount of bad blocks encountered.
While this is normally fine, when you have to write a large amount
of data in chunks, you need to account for the skipped amount due
to the presence of the bad blocks.
nand_extend_skip_bad() returns the offset where the next access
should occur.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/mtd/nand/nand_util.c | 50
include/nand.h | 2 ++
2 files changed, 52 insertions(+)
diff --git a/drivers/mtd/nand/nand_util.c b/drivers/mtd/nand/nand_util.c
index 2ba0c5e..a25a4cb 100644
--- a/drivers/mtd/nand/nand_util.c
+++ b/drivers/mtd/nand/nand_util.c
@@ -684,6 +684,56 @@ int nand_read_skip_bad(nand_info_t *nand, loff_t offset,
size_t *length,
return 0;
}
+/**
+ * nand_extent_skip_bad:
+ *
+ * Find the extent of a chunk, return the offset where it ends
+ * Blocks that are marked bad are skipped and the next block is examined
+ * instead as long as the extend is short enough to fit even after skipping the
+ * bad blocks.
+ *
+ * @param nand NAND device
+ * @param offset offset in flash
+ * @param length extend length
+ * @return next offset in case of success (loff_t)-1 on error
+ */
+loff_t nand_extent_skip_bad(nand_info_t *nand, loff_t offset, size_t length)
+{
+ size_t block_len, block_off;
+ loff_t block_start;
+
+ if ((offset (nand-writesize - 1)) != 0) {
+ printf (%s: Attempt to check extend non page aligned data\n,
+ __func__);
+ return (loff_t)-1;
+ }
+
+ while (length 0) {
+
+ if (offset = nand-size) {
+ printf(%s: offset = nand-size (%llx = %llx)\n,
+ __func__, offset, nand-size);
+ return (loff_t)-1;
+ }
+
+ block_start = offset ~(loff_t)(nand-erasesize - 1);
+ block_off = offset (nand-erasesize - 1);
+ block_len = nand-erasesize - block_off;
+ if (block_len length) /* left over */
+ block_len = length;
+
+ if (!nand_block_isbad(nand, block_start))
+ length -= block_len;
+ else
+ debug(%s: bad block at %llx (left %x)\n,
+ __func__, block_start, length);
+
+ offset += block_len;
+ }
+
+ return offset;
+}
+
#ifdef CONFIG_CMD_NAND_TORTURE
/**
diff --git a/include/nand.h b/include/nand.h
index dded4e2..710c11a 100644
--- a/include/nand.h
+++ b/include/nand.h
@@ -168,3 +168,5 @@ __attribute__((noreturn)) void nand_boot(void);
#define ENV_OFFSET_SIZE 8
int get_nand_env_oob(nand_info_t *nand, unsigned long *result);
#endif
+
+loff_t nand_extent_skip_bad(nand_info_t *nand, loff_t offset, size_t length);
--
1.7.12
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] [DFU] Implement NAND dfu support
Introduce on-the fly DFU NAND support.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/dfu/Makefile | 1 +
drivers/dfu/dfu.c | 7 ++
drivers/dfu/dfu_nand.c | 194 +
include/dfu.h | 23 ++
4 files changed, 225 insertions(+)
create mode 100644 drivers/dfu/dfu_nand.c
diff --git a/drivers/dfu/Makefile b/drivers/dfu/Makefile
index 7b717bc..153095d 100644
--- a/drivers/dfu/Makefile
+++ b/drivers/dfu/Makefile
@@ -27,6 +27,7 @@ LIB = $(obj)libdfu.o
COBJS-$(CONFIG_DFU_FUNCTION) += dfu.o
COBJS-$(CONFIG_DFU_MMC) += dfu_mmc.o
+COBJS-$(CONFIG_DFU_NAND) += dfu_nand.o
SRCS:= $(COBJS-y:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS-y))
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index fb9b417..1972b17 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -234,6 +234,8 @@ int dfu_read(struct dfu_entity *dfu, void *buf, int size,
int blk_seq_num)
dfu-i_buf = dfu-i_buf_start;
dfu-b_left = 0;
+ dfu-bad_skip = 0;
+
dfu-inited = 1;
}
@@ -263,6 +265,8 @@ int dfu_read(struct dfu_entity *dfu, void *buf, int size,
int blk_seq_num)
dfu-i_buf = dfu-i_buf_start;
dfu-b_left = 0;
+ dfu-bad_skip = 0;
+
dfu-inited = 0;
}
@@ -285,6 +289,9 @@ static int dfu_fill_entity(struct dfu_entity *dfu, char *s,
int alt,
if (strcmp(interface, mmc) == 0) {
if (dfu_fill_entity_mmc(dfu, s))
return -1;
+ } else if (strcmp(interface, nand) == 0) {
+ if (dfu_fill_entity_nand(dfu, s))
+ return -1;
} else {
printf(%s: Device %s not (yet) supported!\n,
__func__, interface);
diff --git a/drivers/dfu/dfu_nand.c b/drivers/dfu/dfu_nand.c
new file mode 100644
index 000..9ea5f0c
--- /dev/null
+++ b/drivers/dfu/dfu_nand.c
@@ -0,0 +1,194 @@
+/*
+ * dfu_nand.c -- DFU for NAND routines.
+ *
+ * Copyright (C) 2012 Texas Instruments, Inc.
+ *
+ * Based on dfu_mmc.c which is:
+ * Copyright (C) 2012 Samsung Electronics
+ * author: Lukasz Majewski l.majew...@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 malloc.h
+#include errno.h
+#include div64.h
+#include dfu.h
+#include linux/mtd/mtd.h
+#include jffs2/load_kernel.h
+#include nand.h
+
+enum dfu_nand_op {
+ DFU_OP_READ = 1,
+ DFU_OP_WRITE,
+};
+
+static int nand_block_op(enum dfu_nand_op op, struct dfu_entity *dfu,
+ u64 offset, void *buf, long *len)
+{
+ char cmd_buf[DFU_CMD_BUF_SIZE];
+ u64 start, count;
+ int ret;
+ int dev;
+ loff_t actual;
+
+ /* if buf == NULL return total size of the area */
+ if (buf == NULL) {
+ *len = dfu-data.nand.size;
+ return 0;
+ }
+
+ start = dfu-data.nand.start + offset + dfu-bad_skip;
+ count = *len;
+ if (start + count
+ dfu-data.nand.start + dfu-data.nand.size) {
+ printf(%s: block_op out of bounds\n, __func__);
+ return -1;
+ }
+ dev = nand_curr_device;
+ if (dev 0 || dev = CONFIG_SYS_MAX_NAND_DEVICE ||
+ !nand_info[dev].name) {
+ printf(%s: invalid nand device\n, __func__);
+ return -1;
+ }
+
+ sprintf(cmd_buf, nand %s %p %llx %llx,
+ op == DFU_OP_READ ? read : write,
+buf, start, count);
+
+ debug(%s: %s 0x%p\n, __func__, cmd_buf, cmd_buf);
+ ret = run_command(cmd_buf, 0);
+
+ /* find out how much actual bytes have been written */
+ /* the difference is the amount of skip we must add from now on */
+ actual = nand_extent_skip_bad(nand_info[dev], start, count);
+ if (actual == (loff_t)-1) {
+ printf(nand_extend_skip_bad: error!\n);
+ return ret;
+ }
+
+ if (actual (start + count)) {
+ debug(%s: skipped %llx bad bytes at %llx\n, __func__,
+ actual - (start + count), start);
+ dfu-bad_skip += (u32)(actual - (start + count));
+ }
+
+
Re: [U-Boot] Conflicting commits for seaboard USB keyboard handling
Will do. On Sat, Dec 8, 2012 at 11:03 PM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hello, It seems like two commits 5ddcc38b (in u-boot, committed by Marek) 29f3e3f2 (in u-boot-arm, committed by Tom from u-boot-tegra) are conflicting on the seaboard configuration header file for USB (and possibly other areas). Tom, can you look into it (and involve whoever is needed) and provide a pull request with a fix, the same way I asked Stefano and Minkyu for the same? Thanks in advance! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] m28evk/mx28evk: fix nand_update_full
- commit 418396e212b59bf907dbccad997ff50f7eb61b16 chenged the behaviour
of nand write.raw which now takes a pagecount as a parameter and no more
the size to be written so update the default environment of these boards
to fix the problem.
- tested on a mx28evk with a 4k page NAND and on a custom board with a
2k page NAND.
Signed-off-by: Eric Bénard e...@eukrea.com
Cc: Marek Vasut ma...@denx.de
Cc: Fabio Estevam fabio.este...@freescale.com
---
include/configs/m28evk.h |2 +-
include/configs/mx28evk.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/configs/m28evk.h b/include/configs/m28evk.h
index b49ec8c..3f37e84 100644
--- a/include/configs/m28evk.h
+++ b/include/configs/m28evk.h
@@ -297,7 +297,7 @@
if tftp ${update_nand_full_filename} ; then \
run update_nand_get_fcb_size ;\
nand scrub -y 0x0 ${filesize} ; \
- nand write.raw ${loadaddr} 0x0 ${update_nand_fcb} ; \
+ nand write.raw ${loadaddr} 0x0 ${fcb_sz} ;\
setexpr update_off ${loadaddr} + ${update_nand_fcb} ; \
setexpr update_sz ${filesize} - ${update_nand_fcb} ; \
nand write ${update_off} ${update_nand_fcb} ${update_sz} ; \
diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h
index 0511cd1..d474a92 100644
--- a/include/configs/mx28evk.h
+++ b/include/configs/mx28evk.h
@@ -264,7 +264,7 @@
if tftp ${update_nand_full_filename} ; then \
run update_nand_get_fcb_size ; \
nand scrub -y 0x0 ${filesize} ; \
- nand write.raw ${loadaddr} 0x0 ${update_nand_fcb} ; \
+ nand write.raw ${loadaddr} 0x0 ${fcb_sz} ; \
setexpr update_off ${loadaddr} + ${update_nand_fcb} ; \
setexpr update_sz ${filesize} - ${update_nand_fcb} ; \
nand write ${update_off} ${update_nand_fcb} ${update_sz} ; \
--
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] m28evk/mx28evk: fix nand_update_full
Dear Eric Bénard, - commit 418396e212b59bf907dbccad997ff50f7eb61b16 chenged the behaviour of nand write.raw which now takes a pagecount as a parameter and no more the size to be written so update the default environment of these boards to fix the problem. - tested on a mx28evk with a 4k page NAND and on a custom board with a 2k page NAND. Signed-off-by: Eric Bénard e...@eukrea.com Cc: Marek Vasut ma...@denx.de Cc: Fabio Estevam fabio.este...@freescale.com Thanks, Ccing Stefano and Scott. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Conflicting commits for seaboard USB keyboard handling
Albert, On Mon, Dec 10, 2012 at 9:25 AM, Tom Warren twarren.nvi...@gmail.com wrote: Will do. On Sat, Dec 8, 2012 at 11:03 PM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hello, It seems like two commits 5ddcc38b (in u-boot, committed by Marek) 29f3e3f2 (in u-boot-arm, committed by Tom from u-boot-tegra) are conflicting on the seaboard configuration header file for USB (and possibly other areas). Looking at Allen's commit, it only added CONFIG_USB_KEYBOARD (plus a comment) to seaboard.h. That should be conflict-free with my rename of TEGRA20_ to TEGRA_ in seaboard.h. Looking at Allen's patchset (which is marked 'Awaiting upstream' in Patchwork, BTW), you can see that my patch had already been applied to Allen's source (CONFIG_TEGRA_KEYBOARD instead of CONFIG_TEGRA20_KEYBOARD precedes Allen's CONFIG_USB_KEYBOARD in seaboard.h). I pulled TOT u-boot/master, and both commits seem to be just fine for seaboard.h. It builds fine, too. Can you be more explicit about the exact conflict, including which exact repos branches you are merging when you see the conflict? Thanks, Tom Tom, can you look into it (and involve whoever is needed) and provide a pull request with a fix, the same way I asked Stefano and Minkyu for the same? Thanks in advance! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/7] Tegra30: Add/enable Cardhu build (T30 reference board)
Simon, On Sat, Dec 8, 2012 at 1:00 PM, Simon Glass s...@chromium.org wrote: Hi, On Tue, Dec 4, 2012 at 2:41 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 12/04/2012 01:40 PM, Lucas Stach wrote: Hi Tom, Am Dienstag, den 04.12.2012, 13:22 -0700 schrieb Tom Warren: [...] +#define V_NS16550_CLK21600 /* 216MHz (pllp_out0) */ I thought PLL_P ran at 408MHz on Tegra30? The kernel certainly sets it up that way. See my previous reply. In the internal U-Boot repo I ported from, PLLP was initially set to 216MHz, then sped up to 408MHz. When this first round of patches is in, I can address going to 408MHz first thing. Is running the PLL_P at 408MHz something which requires a lot of work? If not, please do this and fold it into this patchset. It doesn't look too nice adding things to upstream which have to be changed/removed immediately after going in. Naively I'd have to agree here; it seems that programming the PLL for the correct rate would probably just work right from the outset? After all, if the code runs OK with the higher rate enabled a little later in boot, I see no reason it shouldn't run OK with that exact same rate the whole way through. From memory, the problem was originally that we wanted to be able to configure the PLL speed at run time, because we we using both speeds. Since T30 now apparently only uses 408MHz, it should be ok to set it once and hard-code it. Regards, Simon Thanks. As I remember it, it was a user-config option for early T30 boards to run at 216MHz or 408MHz. The 408MHz PLLP change generated a lot of email traffic on what the best output clocks (pllp_out1 thru 4) would be for the various periphs, subclocks, etc. When I did the original bringup for upstream U-Boot on my (older) Cardhu, I wanted to start at 216MHz first, then step up to 408MHz when I was at a stable point. Much like when I rebuilt my Mustang - I took it out around the block first, to be sure everything was working OK before I took it on the highway ;) I'm running OK at 408MHz on my Cardhu T33. I'll resubmit V3 of the patchset in the next day or so. Thanks, Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/9] dfu: Send correct DFU response from composite_setup
Hi Pantelis,
DFU is a bit peculiar. It needs to hook to composite setup and
return it's function descriptor.
So when get-descriptor request comes with a type of DFU_DT_FUNC
we iterate over the configs, and functions, and when we find
the DFU function we call the setup method which is prepared
to return the appropriate function descriptor.
Sorry, but could you be more informative here? Have you had any non
standard problems? I wonder why dfu-util on my linux works OK without
this patch?
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/usb/gadget/composite.c | 27 +++
drivers/usb/gadget/ep0.c | 1 +
drivers/usb/gadget/f_dfu.c | 6 --
3 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/composite.c
b/drivers/usb/gadget/composite.c index ebb5131..6496436 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -773,6 +773,33 @@ composite_setup(struct usb_gadget *gadget, const
struct usb_ctrlrequest *ctrl) if (value = 0)
value = min(w_length, (u16) value);
break;
+
+#ifdef CONFIG_DFU_FUNCTION
+ /* DFU is mighty weird */
^^ - please explain this
wiredness.
I don't recall such a hacks in linux kernel composite.c (any special
#ifdef). Am I missing something important in DFU?
Does your device have any special requirement, so you need this hack?
I generally don't like the idea to patch composite gadget code with
#ifdefs for special function. Please convince me.
+ case DFU_DT_FUNC:
+ w_value = 0xff;
+ list_for_each_entry(c, cdev-configs, list)
{
+ if (w_value != 0) {
+ w_value--;
+ continue;
+ }
+
+ list_for_each_entry(f,
c-functions, list) { +
+ /* DFU function only */
+ if (strcmp(f-name,
dfu) != 0)
+ continue;
+
+ value = f-setup(f, ctrl);
+ goto dfu_func_done;
+ }
+ }
+dfu_func_done:
+ if (value = 0)
+ value = min(w_length, (u16) value);
+ break;
+#endif
+
default:
goto unknown;
}
diff --git a/drivers/usb/gadget/ep0.c b/drivers/usb/gadget/ep0.c
index aa8f916..971d846 100644
--- a/drivers/usb/gadget/ep0.c
+++ b/drivers/usb/gadget/ep0.c
@@ -221,6 +221,7 @@ static int ep0_get_descriptor (struct
usb_device_instance *device, break;
case USB_DESCRIPTOR_TYPE_CONFIGURATION:
+ case USB_DESCRIPTOR_TYPE_OTHER_SPEED_CONFIGURATION:
^- why do you need that?
{
struct usb_configuration_descriptor
*configuration_descriptor;
diff --git a/drivers/usb/gadget/f_dfu.c b/drivers/usb/gadget/f_dfu.c
index 10547e3..6494f5e 100644
--- a/drivers/usb/gadget/f_dfu.c
+++ b/drivers/usb/gadget/f_dfu.c
@@ -534,8 +534,10 @@ dfu_handle(struct usb_function *f, const struct
usb_ctrlrequest *ctrl) value = min(len, (u16) sizeof(dfu_func));
memcpy(req-buf, dfu_func, value);
}
- } else /* DFU specific request */
- value = dfu_state[f_dfu-dfu_state] (f_dfu, ctrl,
gadget, req);
+ return value;
+ }
+
+ value = dfu_state[f_dfu-dfu_state] (f_dfu, ctrl, gadget,
req);
Why do you change state even after receiving req_type ==
USB_TYPE_STANDARD? I would expect to change the dfu state only when DFU
specific request appears.
if (value = 0) {
req-length = value;
--
Best regards,
Lukasz Majewski
Samsung Poland RD Center | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] JFFS2 seems to drop nand data with ECC corrections
On 12/10/2012 01:33:52 AM, Deltour, Stephane wrote: Hi, Thanks for the confirmation. Is this something that may be patched ? I mean, would a patch for this be accepted ? Yes, please send a patch. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/9] dfu: Send correct DFU response from composite_setup
Hi Lukasz,
On Dec 10, 2012, at 7:11 PM, Lukasz Majewski wrote:
Hi Pantelis,
DFU is a bit peculiar. It needs to hook to composite setup and
return it's function descriptor.
So when get-descriptor request comes with a type of DFU_DT_FUNC
we iterate over the configs, and functions, and when we find
the DFU function we call the setup method which is prepared
to return the appropriate function descriptor.
Sorry, but could you be more informative here? Have you had any non
standard problems? I wonder why dfu-util on my linux works OK without
this patch?
I have absolutely no idea why it works at your side.
At our side it just didn't work at all without the patches.
If I had to guess maybe your gadget h/w takes care of replying
properly for the DFU case.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/usb/gadget/composite.c | 27 +++
drivers/usb/gadget/ep0.c | 1 +
drivers/usb/gadget/f_dfu.c | 6 --
3 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/composite.c
b/drivers/usb/gadget/composite.c index ebb5131..6496436 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -773,6 +773,33 @@ composite_setup(struct usb_gadget *gadget, const
struct usb_ctrlrequest *ctrl) if (value = 0)
value = min(w_length, (u16) value);
break;
+
+#ifdef CONFIG_DFU_FUNCTION
+/* DFU is mighty weird */
^^ - please explain this
wiredness.
I don't recall such a hacks in linux kernel composite.c (any special
#ifdef). Am I missing something important in DFU?
Does your device have any special requirement, so you need this hack?
I generally don't like the idea to patch composite gadget code with
#ifdefs for special function. Please convince me.
It doesn't work otherwise. I have no idea why you think I would be hacking
around there if the thing worked at all. And trust me on that, it just doesn't
without those patches, not to mention the way it unceremoniously blows up if
you transfer anything larger than the buffer set aside originally.
The way I see it, instead of complaining you should be rejoicing since now
DFU will be used in an actual production environment.
More users == less bugs.
When I get a few free cycles I will post a tcpdump capture of the DFU USB
transaction hanging.
+case DFU_DT_FUNC:
+w_value = 0xff;
+list_for_each_entry(c, cdev-configs, list)
{
+if (w_value != 0) {
+w_value--;
+continue;
+}
+
+list_for_each_entry(f,
c-functions, list) { +
+/* DFU function only */
+if (strcmp(f-name,
dfu) != 0)
+continue;
+
+value = f-setup(f, ctrl);
+goto dfu_func_done;
+}
+}
+dfu_func_done:
+if (value = 0)
+value = min(w_length, (u16) value);
+break;
+#endif
+
default:
goto unknown;
}
diff --git a/drivers/usb/gadget/ep0.c b/drivers/usb/gadget/ep0.c
index aa8f916..971d846 100644
--- a/drivers/usb/gadget/ep0.c
+++ b/drivers/usb/gadget/ep0.c
@@ -221,6 +221,7 @@ static int ep0_get_descriptor (struct
usb_device_instance *device, break;
case USB_DESCRIPTOR_TYPE_CONFIGURATION:
+case USB_DESCRIPTOR_TYPE_OTHER_SPEED_CONFIGURATION:
^- why do you need that?
{
struct usb_configuration_descriptor
*configuration_descriptor;
diff --git a/drivers/usb/gadget/f_dfu.c b/drivers/usb/gadget/f_dfu.c
index 10547e3..6494f5e 100644
--- a/drivers/usb/gadget/f_dfu.c
+++ b/drivers/usb/gadget/f_dfu.c
@@ -534,8 +534,10 @@ dfu_handle(struct usb_function *f, const struct
usb_ctrlrequest *ctrl) value = min(len, (u16) sizeof(dfu_func));
memcpy(req-buf, dfu_func, value);
}
-} else /* DFU specific request */
-value = dfu_state[f_dfu-dfu_state] (f_dfu, ctrl,
gadget, req);
+return value;
+}
+
+value = dfu_state[f_dfu-dfu_state] (f_dfu, ctrl, gadget,
req);
Why do you change state even after receiving req_type ==
USB_TYPE_STANDARD? I would expect to change the dfu state only when DFU
specific request appears.
if (value = 0) {
req-length = value;
--
Best regards,
Lukasz Majewski
Samsung Poland RD Center | Linux Platform Group
Regards
Re: [U-Boot] U-boot : compare read and expect value
Dear Wolfgang Denk Dear Khalid Tourabi, please don't top post / full quote, and keep the mailing list on Cc: Ok sorry thanks. In message50c5f2d6.5060...@planar.com you wrote: Thanks for your answer. setexpr command allows set the result operation in an environment variable. But I want to set the result command (string) in an environment variable to compare it with the expect value. Build it from parts. Start with putting the expected value in an environment variable, so you can use setexpr to compareit against the actual value. Then use conditionals to react as needed. Use standard shell scripting methods. Best regards, Wolfgang Denk I added setexpr command, but I don't understand how to use it for my need. For example : u-boot# set expct FF7F7F7F7F7F7FC2 u-boot# sspi 8 64 9F FF7F7F7F7F7F7FC2 u-boot# This SPI command allows to read the NVRAM code ID, I want to compare with $expct unsuccessfully u-boot# if test sspi 8 64 9F = $expct ; then echo Success; else echo Error; fi; Success u-boot# set expct FF7F7F7F7F7F7FC u-boot# if test sspi 8 64 9F = $expct ; then echo Success; else echo Error; fi; Success $expct either equal to FF7F7F7F7F7F7FC2 or FF7F7F7F7F7F7FC the result of if condition is the same. Many Thanks for your help. Khalid ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/7] Tegra30: Add/enable Cardhu build (T30 reference board)
Hi Tom, On Mon, Dec 10, 2012 at 9:05 AM, Tom Warren twarren.nvi...@gmail.com wrote: Simon, On Sat, Dec 8, 2012 at 1:00 PM, Simon Glass s...@chromium.org wrote: Hi, On Tue, Dec 4, 2012 at 2:41 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 12/04/2012 01:40 PM, Lucas Stach wrote: Hi Tom, Am Dienstag, den 04.12.2012, 13:22 -0700 schrieb Tom Warren: [...] +#define V_NS16550_CLK21600 /* 216MHz (pllp_out0) */ I thought PLL_P ran at 408MHz on Tegra30? The kernel certainly sets it up that way. See my previous reply. In the internal U-Boot repo I ported from, PLLP was initially set to 216MHz, then sped up to 408MHz. When this first round of patches is in, I can address going to 408MHz first thing. Is running the PLL_P at 408MHz something which requires a lot of work? If not, please do this and fold it into this patchset. It doesn't look too nice adding things to upstream which have to be changed/removed immediately after going in. Naively I'd have to agree here; it seems that programming the PLL for the correct rate would probably just work right from the outset? After all, if the code runs OK with the higher rate enabled a little later in boot, I see no reason it shouldn't run OK with that exact same rate the whole way through. From memory, the problem was originally that we wanted to be able to configure the PLL speed at run time, because we we using both speeds. Since T30 now apparently only uses 408MHz, it should be ok to set it once and hard-code it. Regards, Simon Thanks. As I remember it, it was a user-config option for early T30 boards to run at 216MHz or 408MHz. The 408MHz PLLP change generated a lot of email traffic on what the best output clocks (pllp_out1 thru 4) would be for the various periphs, subclocks, etc. When I did the original bringup for upstream U-Boot on my (older) Cardhu, I wanted to start at 216MHz first, then step up to 408MHz when I was at a stable point. Much like when I rebuilt my Mustang - I took it out around the block first, to be sure everything was working OK before I took it on the highway ;) I'm running OK at 408MHz on my Cardhu T33. I'll resubmit V3 of the patchset in the next day or so. Sounds good, thanks. It would be good to get this in. Regards, Simon Thanks, Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Conflicting commits for seaboard USB keyboard handling
On Mon, Dec 10, 2012 at 08:59:59AM -0800, Tom Warren wrote: Albert, On Mon, Dec 10, 2012 at 9:25 AM, Tom Warren twarren.nvi...@gmail.com wrote: Will do. On Sat, Dec 8, 2012 at 11:03 PM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hello, It seems like two commits 5ddcc38b (in u-boot, committed by Marek) 29f3e3f2 (in u-boot-arm, committed by Tom from u-boot-tegra) are conflicting on the seaboard configuration header file for USB (and possibly other areas). Looking at Allen's commit, it only added CONFIG_USB_KEYBOARD (plus a comment) to seaboard.h. That should be conflict-free with my rename of TEGRA20_ to TEGRA_ in seaboard.h. Looking at Allen's patchset (which is marked 'Awaiting upstream' in Patchwork, BTW), you can see that my patch had already been applied to Allen's source (CONFIG_TEGRA_KEYBOARD instead of CONFIG_TEGRA20_KEYBOARD precedes Allen's CONFIG_USB_KEYBOARD in seaboard.h). I pulled TOT u-boot/master, and both commits seem to be just fine for seaboard.h. It builds fine, too. Can you be more explicit about the exact conflict, including which exact repos branches you are merging when you see the conflict? I can see the conflict if I checkout u-boot-arm/master and then merge u-boot-tegra/next and u-boot/master. If we pull the following commit from u-boot/master into u-boot-tegra/next it helps: 5ddcc38 tegra: Enable USB keyboard There's still a conflict between the LCD config file changes and the USB keyboard config file changes, but it's pretty straightforward to resolve. -Allen -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] sf: Enable prints on erase and write functions
Hi, On Mon, Dec 10, 2012 at 6:41 AM, Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com wrote: This patch provides to enabled the prints on erase and write functions to make sure that how many bytes erase/write into flash device. Signed-off-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com --- drivers/mtd/spi/spi_flash.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c index 00aece9..464c2ab 100644 --- a/drivers/mtd/spi/spi_flash.c +++ b/drivers/mtd/spi/spi_flash.c @@ -115,7 +115,7 @@ int spi_flash_cmd_write_multi(struct spi_flash *flash, u32 offset, byte_addr = 0; } - debug(SF: program %s %zu bytes @ %#x\n, + printf(SF: program %s %zu bytes @ %#x\n, ret ? failure : success, len, offset); I don't think we want this - it will make programming very slow and verbose. spi_release_bus(flash-spi); @@ -235,7 +235,7 @@ int spi_flash_cmd_erase(struct spi_flash *flash, u32 offset, size_t len) goto out; } - debug(SF: Successfully erased %zu bytes @ %#x\n, len, start); + printf(SF: Successfully erased %zu bytes @ %#x\n, len, start); You may want to put this code into cmd_sf instead, where it is reasonable to add messages. You are changing core spi code which might be used from many places. out: spi_release_bus(flash-spi); -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [STATUS] 'next' is now open
Hey all, I pushed earlier (and it's live now) an update making the next branch be in-sync with master. Seeing as for this release we do not have any planned changes that will require a rebase (last time we wanted the very first commits to be to switch to the right fix for ARM and alignment stuff) I've now opened the next branch and do not plan to rebase it but instead just merge it to master on release (baring people shouting that this is a terrible idea). Thanks all! If I do need to rebase at some point I will give notice so we can all sync up and try and avoid as much of a mess as we can. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/9] dfu: Send correct DFU response from composite_setup
Pantelis,
Hi Lukasz,
On Dec 10, 2012, at 7:11 PM, Lukasz Majewski wrote:
Hi Pantelis,
DFU is a bit peculiar. It needs to hook to composite setup and
return it's function descriptor.
So when get-descriptor request comes with a type of DFU_DT_FUNC
we iterate over the configs, and functions, and when we find
the DFU function we call the setup method which is prepared
to return the appropriate function descriptor.
Sorry, but could you be more informative here? Have you had any non
standard problems? I wonder why dfu-util on my linux works OK
without this patch?
I have absolutely no idea why it works at your side.
At our side it just didn't work at all without the patches.
If I had to guess maybe your gadget h/w takes care of replying
properly for the DFU case.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/usb/gadget/composite.c | 27 +++
drivers/usb/gadget/ep0.c | 1 +
drivers/usb/gadget/f_dfu.c | 6 --
3 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/composite.c
b/drivers/usb/gadget/composite.c index ebb5131..6496436 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -773,6 +773,33 @@ composite_setup(struct usb_gadget *gadget,
const struct usb_ctrlrequest *ctrl) if (value = 0)
value = min(w_length, (u16) value);
break;
+
+#ifdef CONFIG_DFU_FUNCTION
+ /* DFU is mighty weird */
^^ - please explain this
wiredness.
I don't recall such a hacks in linux kernel composite.c (any special
#ifdef). Am I missing something important in DFU?
Does your device have any special requirement, so you need this
hack?
I generally don't like the idea to patch composite gadget code
with #ifdefs for special function. Please convince me.
It doesn't work otherwise. I have no idea why you think I would be
hacking around there if the thing worked at all. And trust me on
that, it just doesn't without those patches, not to mention the way
it unceremoniously blows up if you transfer anything larger than the
buffer set aside originally.
The way I see it, instead of complaining you should be rejoicing
since now DFU will be used in an actual production environment.
I'm not complaining. I try to resolve the problem, since this can make
dfu support better at u-boot.
Moreover I'm aware that USB is tricky, so I want to understand your
problem.
Tomorrow I will prepare output of USB Ellisys analizer on my side, so we
could get clue what is going on.
More users == less bugs.
I'm really happy, that you have posted patches for NAND flashing.
Without your determination at debugging, problem with buffer overflow
wouldn't be discovered.
We only needs to share knowledge and provide solution acceptable for
community and us.
I'm open.
When I get a few free cycles I will post a tcpdump capture of the DFU
USB transaction hanging.
Yes, please.
+ case DFU_DT_FUNC:
+ w_value = 0xff;
+ list_for_each_entry(c, cdev-configs,
list) {
+ if (w_value != 0) {
+ w_value--;
+ continue;
+ }
+
+ list_for_each_entry(f,
c-functions, list) { +
+ /* DFU function only */
+ if (strcmp(f-name,
dfu) != 0)
+ continue;
+
+ value = f-setup(f, ctrl);
+ goto dfu_func_done;
+ }
+ }
+dfu_func_done:
+ if (value = 0)
+ value = min(w_length, (u16)
value);
+ break;
+#endif
+
default:
goto unknown;
}
diff --git a/drivers/usb/gadget/ep0.c b/drivers/usb/gadget/ep0.c
index aa8f916..971d846 100644
--- a/drivers/usb/gadget/ep0.c
+++ b/drivers/usb/gadget/ep0.c
@@ -221,6 +221,7 @@ static int ep0_get_descriptor (struct
usb_device_instance *device, break;
case USB_DESCRIPTOR_TYPE_CONFIGURATION:
+ case USB_DESCRIPTOR_TYPE_OTHER_SPEED_CONFIGURATION:
^- why do you need that?
{
struct usb_configuration_descriptor
*configuration_descriptor;
diff --git a/drivers/usb/gadget/f_dfu.c
b/drivers/usb/gadget/f_dfu.c index 10547e3..6494f5e 100644
--- a/drivers/usb/gadget/f_dfu.c
+++ b/drivers/usb/gadget/f_dfu.c
@@ -534,8 +534,10 @@ dfu_handle(struct usb_function *f, const
struct usb_ctrlrequest *ctrl) value = min(len, (u16)
Re: [U-Boot] omap3_beagle.h: Fix comment for true/false return value.
On Sun, Nov 11, 2012 at 11:20:58PM -, Robert P. J. Day wrote: Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca --- pretty sure that comment is inaccurate, but i'm willing to be corrected. Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pass sdrc timing values through board_sdrc_timings structure
On Tue, Nov 13, 2012 at 07:40:28AM -, Peter Barada wrote: Instead of passing individual registers by value to board_get_mem_timings, pass a board_mem_timings structure pointer for the board files to fill in. Pass same structure pointer to write_sdrc_timings. This saves about 90 bytes of space in SPL. Signed-off-by: Peter Barada peter.bar...@logicpd.com (This is actually v2, just applying vs current of an older patch, pre MW closing). Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] omap3: Add a few comments to #endifs for readability.
On Tue, Nov 13, 2012 at 07:57:54AM -, Robert P. J. Day wrote: No functional changes, just more comments for readability when a preprocessor check spans more than a few lines, and for consistency. Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] omap4: Add comments on some #endifs for readability.
On Tue, Nov 13, 2012 at 08:12:08AM -, Robert P. J. Day wrote: No functional changes, simply for readability. Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP: Tweak omap-common/Makefile since reset.S - reset.c
On Thu, Nov 15, 2012 at 01:21:18AM -, Robert P. J. Day wrote: Git commit d417d1db5f9092d125ddea882ced77eaa5f3d236 replaced the omap-common file reset.S with reset.c, but the Makefile was not adjusted for that. Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, V2] omap: emif: configure emif only when required
On Thu, Nov 15, 2012 at 09:06:33PM -, Lokesh Vutla wrote: DMM_LISA_MAP registers program whether memory is mapped on particular EMIF or not. Irrespective of these registers EMIF is getting configured. Correcting the same. Signed-off-by: Lokesh Vutla lokeshvu...@ti.com Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP3 SPI : Fixed bugs related to SPI transfer
On Sat, Nov 17, 2012 at 09:10:15PM -, Ajoy Kumar Das wrote: From: ajoy akda...@yahoo.in Added posted writes (read after writes) to effect the change immediately for channel confiuration and channel enable register Disable the channel to purge receieve data in TX_ONLY mode transfer otherwise rx data will get affected by the next immediate RX_ONLY mode transfer Wait for the EOT bit to be set after last byte has been loaded to TX shift register in the the TX_ONLY mode.This ensures TX data has been completely shifted out Disable the channel in RX_ONLY mode before reading the last data from RXX register to prevent the SPI slave to transmit next word Signed-off-by: Ajoy Kumar Das akda...@yahoo.in Cc: Tom Rini tr...@ti.com Cc: jacopo mondi j.mo...@voltaelectronics.com Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,v0] davinci: fixed cpu reset
On Wed, Nov 21, 2012 at 12:45:12AM -, Davide Bonfanti wrote: The reset procedure works on watchdog timer while before it was modifying TIMER_1 registers. Tested on DM365. Signed-off-by: Davide Bonfanti davide.bonfa...@bticino.it Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] am335x: disable internal delay for RGMII mode
On Mon, Nov 26, 2012 at 03:30:42AM -, Yegor Yefremov wrote: From: Yegor Yefremov yegorsli...@googlemail.com According to errata the AM335x device does not support internal delay mode, so RGMII1_IDMODE and RGMII2_IDMODE must be set to 1. Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] am335x: cpsw: make phy address configurable
On Mon, Nov 26, 2012 at 04:03:16AM -, Yegor Yefremov wrote: From: Yegor Yefremov yegorsli...@googlemail.com Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, RFC/PATCHv2] OMAP3: Remove unused PHYS_SDRAM_1_SIZE
On Tue, Nov 27, 2012 at 10:32:40AM -, Thomas Weber wrote: Remove the unused PHYS_SDRAM_1_SIZE from OMAP3 config files. Signed-off-by: Thomas Weber tho...@tomweber.eu Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, V2] gpio: add gpio_is_valid() to omap_gpio API
On Tue, Nov 27, 2012 at 10:40:57PM -, Nikita Kiryanov wrote: Add gpio_is_valid() to omap_gpio API Signed-off-by: Nikita Kiryanov nik...@compulab.co.il Signed-off-by: Igor Grinberg grinb...@compulab.co.il Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,1/2] omap24xx_i2c: Handle wait_for_bb error
On Mon, Dec 03, 2012 at 05:23:16AM -, Vincent Stehl?? wrote: We add a return code to wait_for_bb() to be able to report errors to the callers properly. We in turn handle this new error code in i2c_read, i2c_write and i2c_probe. Signed-off-by: Vincent Stehl?? v-ste...@ti.com Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,2/2] power: twl6035: complain on LDO9 error
On Mon, Dec 03, 2012 at 05:23:17AM -, Vincent Stehl?? wrote: We handle i2c_write return code and complain in case of error. We propagate the error, too, to allow better handling at the upper level in the future. Signed-off-by: Vincent Stehl?? v-ste...@ti.com Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] cm-t35: enable zero bootdelay check
On Tue, Dec 04, 2012 at 11:28:26PM -, Nikita Kiryanov wrote: Enable zero bootdelay check to make it possible to abort autoboot even if bootdelay == 0 Signed-off-by: Nikita Kiryanov nik...@compulab.co.il Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3/mem.c: remove unused defines
On Fri, Nov 02, 2012 at 11:14:57AM +0100, Andreas Bie??mann wrote: These GPMC_CS defines are a leftover from prior gpmc_init(). Commit 187af954 removed the need for these definitions but missed to remove them. Signed-off-by: Andreas Bie??mann andreas.de...@googlemail.com Cc: Tom Rini tr...@ti.com Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] OMAP3: fix panel timing on the mt_ventoux board
On Fri, Nov 23, 2012 at 04:19:24PM +0100, Stefano Babic wrote: Signed-off-by: Stefano Babic sba...@denx.de Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] OMAP3: TAM3517: add macros for reading eeprom
On Fri, Nov 23, 2012 at 04:19:25PM +0100, Stefano Babic wrote: Added macros to read SOM information from the I2C EEPROM. Signed-off-by: Stefano Babic sba...@denx.de Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/8] NAND support for AM33XX
On Wed, Nov 07, 2012 at 12:06:27AM +0100, Ilya Yanok wrote: These series add support for NAND on AM33XX. AM33XX has the same GPMC controller as OMAP3 so the first part of the series just add required defines/initialization to enable the existing omap_gpmc driver to work on AM33XX. The rest of the series adds support for BCH8 error correction code. We use GPMC to generate codes/syndromes and ELM to find the errors. Changes in v2: -fix nand mux settings (profiles 23 don't have NAND) - rebased on current master - clean up mem.c (remove unused stuff that was copied from OMAP3) - nand headers: remove unneeded stuff - rebased onto master - minor config style fix (wrt nand) - fix wrong braces in Makefile Ilya Yanok (6): OMAP: include sys_proto.h from boot-common am335x_evm: add nand pinmux definition am33xx: NAND support am335x_evm: enable NAND support am33xx_spl_bch: simple SPL nand loader for AM33XX am335x_evm: enable SPL NAND support Mansoor Ahamed (2): am33xx: add ELM support omap_gpmc: BCH8 support (ELM based) arch/arm/cpu/armv7/am33xx/Makefile |2 + arch/arm/cpu/armv7/am33xx/board.c|1 + arch/arm/cpu/armv7/am33xx/clock.c| 10 + arch/arm/cpu/armv7/am33xx/elm.c | 212 ++ arch/arm/cpu/armv7/am33xx/mem.c | 101 +++ arch/arm/cpu/armv7/omap-common/boot-common.c |1 + arch/arm/include/asm/arch-am33xx/cpu.h | 53 arch/arm/include/asm/arch-am33xx/elm.h | 93 ++ arch/arm/include/asm/arch-am33xx/hardware.h |3 + arch/arm/include/asm/arch-am33xx/mem.h | 83 ++ arch/arm/include/asm/arch-am33xx/omap_gpmc.h | 120 arch/arm/include/asm/arch-am33xx/sys_proto.h |3 + board/ti/am335x/board.c |2 + board/ti/am335x/mux.c| 22 ++ drivers/mtd/nand/Makefile|1 + drivers/mtd/nand/am335x_spl_bch.c| 238 +++ drivers/mtd/nand/omap_gpmc.c | 403 +- include/configs/am335x_evm.h | 46 +++ 18 files changed, 1393 insertions(+), 1 deletion(-) create mode 100644 arch/arm/cpu/armv7/am33xx/elm.c create mode 100644 arch/arm/cpu/armv7/am33xx/mem.c create mode 100644 arch/arm/include/asm/arch-am33xx/elm.h create mode 100644 arch/arm/include/asm/arch-am33xx/mem.h create mode 100644 arch/arm/include/asm/arch-am33xx/omap_gpmc.h create mode 100644 drivers/mtd/nand/am335x_spl_bch.c For the series, applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-ti/master
Hello, The following changes since commit b8a7c467960ffb4d5a5e1eef5f7783fb6f594542: Merge branch 'u-boot-imx/master' into 'u-boot-arm/master' (2012-11-25 13:01:58 +0100) are available in the git repository at: git://git.denx.de/u-boot-ti.git master for you to fetch changes up to 9bd5c1ad0db802c9f8d49d72b443f03431cf6a89: cm-t35: enable zero bootdelay check (2012-12-10 12:45:35 -0700) Andreas Bie??mann (1): omap3/mem.c: remove unused defines Davide Bonfanti (1): davinci: fixed cpu reset Ilya Yanok (6): OMAP: include sys_proto.h from boot-common am335x_evm: add nand pinmux definition am33xx: NAND support am335x_evm: enable NAND support am33xx_spl_bch: simple SPL nand loader for AM33XX am335x_evm: enable SPL NAND support Lokesh Vutla (1): omap: emif: configure emif only when required Mansoor Ahamed (2): am33xx: add ELM support omap_gpmc: BCH8 support (ELM based) Nikita Kiryanov (2): gpio: add gpio_is_valid() to omap_gpio API cm-t35: enable zero bootdelay check Peter Barada (1): Pass sdrc timing values through board_sdrc_timings structure Robert P. J. Day (4): omap3_beagle.h: Fix comment for true/false return value. omap3: Add a few comments to #endifs for readability. omap4: Add comments on some #endifs for readability. OMAP: Tweak omap-common/Makefile since reset.S - reset.c Stefano Babic (2): OMAP3: fix panel timing on the mt_ventoux board OMAP3: TAM3517: add macros for reading eeprom Thomas Weber (1): OMAP3: Remove unused PHYS_SDRAM_1_SIZE Vincent Stehl?? (2): omap24xx_i2c: Handle wait_for_bb error power: twl6035: complain on LDO9 error Yegor Yefremov (2): am335x: disable internal delay for RGMII mode am335x: cpsw: make phy address configurable ajoy (1): OMAP3 SPI : Fixed bugs related to SPI transfer arch/arm/cpu/arm926ejs/davinci/reset.c |2 +- arch/arm/cpu/armv7/am33xx/Makefile |2 + arch/arm/cpu/armv7/am33xx/board.c|1 + arch/arm/cpu/armv7/am33xx/clock.c| 10 + arch/arm/cpu/armv7/am33xx/elm.c | 212 ++ arch/arm/cpu/armv7/am33xx/mem.c | 101 +++ arch/arm/cpu/armv7/omap-common/Makefile |5 +- arch/arm/cpu/armv7/omap-common/boot-common.c |1 + arch/arm/cpu/armv7/omap-common/emif-common.c | 41 ++- arch/arm/cpu/armv7/omap3/board.c |4 +- arch/arm/cpu/armv7/omap3/mem.c | 18 +- arch/arm/cpu/armv7/omap3/sdrc.c | 36 +-- arch/arm/cpu/armv7/omap4/clocks.c|2 +- arch/arm/cpu/armv7/omap4/hwinit.c|4 +- arch/arm/include/asm/arch-am33xx/cpu.h | 53 arch/arm/include/asm/arch-am33xx/elm.h | 93 ++ arch/arm/include/asm/arch-am33xx/hardware.h |3 + arch/arm/include/asm/arch-am33xx/mem.h | 83 ++ arch/arm/include/asm/arch-am33xx/omap_gpmc.h | 120 arch/arm/include/asm/arch-am33xx/sys_proto.h |3 + arch/arm/include/asm/arch-omap3/sys_proto.h | 13 +- arch/arm/include/asm/omap_gpio.h |7 + board/corscience/tricorder/tricorder.c | 13 +- board/isee/igep0020/igep0020.c | 29 +- board/isee/igep0030/igep0030.c | 29 +- board/overo/overo.c | 37 ++- board/technexion/twister/twister.c | 10 +- board/teejet/mt_ventoux/mt_ventoux.c | 23 +- board/ti/am335x/board.c |4 +- board/ti/am335x/mux.c| 22 ++ board/ti/beagle/beagle.c | 53 ++-- board/ti/evm/evm.c | 19 +- board/timll/devkit8000/devkit8000.c | 13 +- drivers/gpio/omap_gpio.c | 10 +- drivers/i2c/omap24xx_i2c.c | 20 +- drivers/mtd/nand/Makefile|1 + drivers/mtd/nand/am335x_spl_bch.c| 238 +++ drivers/mtd/nand/omap_gpmc.c | 403 +- drivers/net/cpsw.c |5 +- drivers/power/twl6035.c | 17 +- drivers/spi/omap3_spi.c | 76 +++-- drivers/spi/omap3_spi.h |1 + include/configs/am335x_evm.h | 47 +++ include/configs/cm_t35.h |2 +- include/configs/dig297.h |1 - include/configs/igep00x0.h |1 - include/configs/mcx.h|1 - include/configs/omap3_beagle.h |2 +- include/configs/omap3_mvblx.h|1 - include/configs/omap3_pandora.h |1 - include/configs/omap3_sdp3430.h |1 - include/configs/omap3_zoom1.h|1 - include/configs/omap3_zoom2.h
Re: [U-Boot] Conflicting commits for seaboard USB keyboard handling
u-boot-arm/master and u-boot-tegra/next should have the same base commit (b8a7c46), so merging them isn't a big deal, and goes smoothly for me. If I then take u-boot/master and merge it, I see a conflict in drivers/power/power_fls.c and include/configs/mx35pdk.h and mx53loco.h, but no problems with Tegra code. I could resolve those conflicts and continue with the rebase, but ... Correct me if I'm wrong, but u-boot-tegra and u-boot-usb are both pulled into u-boot-arm, and (I thought) u-boot-arm is then (or eventually) pulled into u-boot/master. I don't pull from u-boot-usb (or any other 'sub' repo), since that would appear to create conflicts when Albert pulls into u-boot-arm. I also don't pull from u-boot/master, since it's essentially 2 levels above me. Albert - if you can, please show me exactly what fetch/merge or rebase command sequence is failing for you. I'm still not clear on what the exact merge conflict error is, nor how to fix it. Or Allen, if you have better visibility into exactly what the merge conflict is w/Tegra that I'm just not seeing, maybe you could provide either a patchset that'll fix it or steps I can take to do the same. Thanks, Tom On Mon, Dec 10, 2012 at 12:25 PM, Allen Martin amar...@nvidia.com wrote: On Mon, Dec 10, 2012 at 08:59:59AM -0800, Tom Warren wrote: Albert, On Mon, Dec 10, 2012 at 9:25 AM, Tom Warren twarren.nvi...@gmail.com wrote: Will do. On Sat, Dec 8, 2012 at 11:03 PM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hello, It seems like two commits 5ddcc38b (in u-boot, committed by Marek) 29f3e3f2 (in u-boot-arm, committed by Tom from u-boot-tegra) are conflicting on the seaboard configuration header file for USB (and possibly other areas). Looking at Allen's commit, it only added CONFIG_USB_KEYBOARD (plus a comment) to seaboard.h. That should be conflict-free with my rename of TEGRA20_ to TEGRA_ in seaboard.h. Looking at Allen's patchset (which is marked 'Awaiting upstream' in Patchwork, BTW), you can see that my patch had already been applied to Allen's source (CONFIG_TEGRA_KEYBOARD instead of CONFIG_TEGRA20_KEYBOARD precedes Allen's CONFIG_USB_KEYBOARD in seaboard.h). I pulled TOT u-boot/master, and both commits seem to be just fine for seaboard.h. It builds fine, too. Can you be more explicit about the exact conflict, including which exact repos branches you are merging when you see the conflict? I can see the conflict if I checkout u-boot-arm/master and then merge u-boot-tegra/next and u-boot/master. If we pull the following commit from u-boot/master into u-boot-tegra/next it helps: 5ddcc38 tegra: Enable USB keyboard There's still a conflict between the LCD config file changes and the USB keyboard config file changes, but it's pretty straightforward to resolve. -Allen -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Conflicting commits for seaboard USB keyboard handling
Albert, On Sat, Dec 8, 2012 at 11:03 PM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hello, It seems like two commits 5ddcc38b (in u-boot, committed by Marek) 29f3e3f2 (in u-boot-arm, committed by Tom from u-boot-tegra) are conflicting on the seaboard configuration header file for USB (and possibly other areas). One possible problem is that I've got new commits ready in u-boot-tegra/next that were almost ready for a pull request, so I copied them over to my tegra/master branch and pushed to u-boot-tegra/master on denx. I assumed that once I got the 'applied to u-boot-arm/master' response from you, that I could stage the next pull request. But if you (or Allen) are pulling from u-boot-tegra/master )or /next), you're gonna get commits that haven't been merged into u-boot-arm/master. I can push the older tegra/master branch back to denx.de (the one that I requested a pull from on Nov 19th) if that'll help. But I'm not sure how it would help, since all those commits should have been present in u-boot-arm/master (from my pull request) when you went to merge w/u-boot/master. So I'm still not seeing how the conflict arose, or what the path is to fixing it. Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [nand] Implement nand_extent_skip_bad
On 12/10/2012 09:24:24 AM, Pantelis Antoniou wrote:
When accessing nand any bad blocks encountered are skipped, with no
indication about the amount of bad blocks encountered.
While this is normally fine, when you have to write a large amount
of data in chunks, you need to account for the skipped amount due
to the presence of the bad blocks.
nand_extend_skip_bad() returns the offset where the next access
should occur.
s/extend/extent/
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/mtd/nand/nand_util.c | 50
include/nand.h | 2 ++
2 files changed, 52 insertions(+)
diff --git a/drivers/mtd/nand/nand_util.c
b/drivers/mtd/nand/nand_util.c
index 2ba0c5e..a25a4cb 100644
--- a/drivers/mtd/nand/nand_util.c
+++ b/drivers/mtd/nand/nand_util.c
@@ -684,6 +684,56 @@ int nand_read_skip_bad(nand_info_t *nand, loff_t
offset, size_t *length,
return 0;
}
+/**
+ * nand_extent_skip_bad:
+ *
+ * Find the extent of a chunk, return the offset where it ends
+ * Blocks that are marked bad are skipped and the next block is
examined
+ * instead as long as the extend is short enough to fit even after
skipping the
+ * bad blocks.
+ *
+ * @param nand NAND device
+ * @param offset offset in flash
+ * @param length extend length
+ * @return next offset in case of success (loff_t)-1 on error
+ */
Would it be better to return this information from existing read/write
functions -- either instead of or in addition to exporting this
functionality?
+loff_t nand_extent_skip_bad(nand_info_t *nand, loff_t offset, size_t
length)
+{
+ size_t block_len, block_off;
+ loff_t block_start;
+
+ if ((offset (nand-writesize - 1)) != 0) {
+ printf (%s: Attempt to check extend non page aligned
data\n,
+ __func__);
+ return (loff_t)-1;
+ }
+
+ while (length 0) {
+
+ if (offset = nand-size) {
+ printf(%s: offset = nand-size (%llx =
%llx)\n,
+ __func__, offset, nand-size);
+ return (loff_t)-1;
+ }
+
+ block_start = offset ~(loff_t)(nand-erasesize - 1);
+ block_off = offset (nand-erasesize - 1);
+ block_len = nand-erasesize - block_off;
+ if (block_len length) /* left over */
+ block_len = length;
+
+ if (!nand_block_isbad(nand, block_start))
+ length -= block_len;
+ else
+ debug(%s: bad block at %llx (left %x)\n,
+ __func__, block_start, length);
+
+ offset += block_len;
+ }
+
+ return offset;
+}
This seems duplicative of check_skip_len().
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] m28evk/mx28evk: fix nand_update_full
On 12/10/2012 10:41:59 AM, Eric Bénard wrote: - commit 418396e212b59bf907dbccad997ff50f7eb61b16 chenged the behaviour of nand write.raw which now takes a pagecount as a parameter and no more the size to be written so update the default environment of these boards to fix the problem. It never really took the size to be written -- the size was implicitly one page before. It looks like there may have been a bug in the old code, where common code expected a size to be there anyway, even though it was ignored other than for error checking. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/9] dfu: Send correct DFU response from composite_setup
Dear Lukasz Majewski, Pantelis, [...] Hm hm ... I suspect it'd be nice to have a separate DFU custodian. That'd leverage some burden from me. I like that idea. I wonder if it'd be nice to start building such bigger net of custodians. Hm ? 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] [DFU] Implement NAND dfu support
On 12/10/2012 09:24:32 AM, Pantelis Antoniou wrote:
Introduce on-the fly DFU NAND support.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/dfu/Makefile | 1 +
drivers/dfu/dfu.c | 7 ++
drivers/dfu/dfu_nand.c | 194
+
include/dfu.h | 23 ++
4 files changed, 225 insertions(+)
create mode 100644 drivers/dfu/dfu_nand.c
What is DFU? I don't see anything in README or doc/, despite there
already being CONFIG symbols for it.
+static int nand_block_op(enum dfu_nand_op op, struct dfu_entity *dfu,
+ u64 offset, void *buf, long *len)
+{
+ char cmd_buf[DFU_CMD_BUF_SIZE];
+ u64 start, count;
+ int ret;
+ int dev;
+ loff_t actual;
+
+ /* if buf == NULL return total size of the area */
+ if (buf == NULL) {
+ *len = dfu-data.nand.size;
+ return 0;
+ }
+
+ start = dfu-data.nand.start + offset + dfu-bad_skip;
+ count = *len;
+ if (start + count
+ dfu-data.nand.start + dfu-data.nand.size) {
+ printf(%s: block_op out of bounds\n, __func__);
+ return -1;
+ }
+ dev = nand_curr_device;
+ if (dev 0 || dev = CONFIG_SYS_MAX_NAND_DEVICE ||
+ !nand_info[dev].name) {
+ printf(%s: invalid nand device\n, __func__);
+ return -1;
+ }
+
+ sprintf(cmd_buf, nand %s %p %llx %llx,
+ op == DFU_OP_READ ? read : write,
+buf, start, count);
+
+ debug(%s: %s 0x%p\n, __func__, cmd_buf, cmd_buf);
+ ret = run_command(cmd_buf, 0);
Why not use the C interface to NAND?
+ /* find out how much actual bytes have been written */
+ /* the difference is the amount of skip we must add from now on
*/
+ actual = nand_extent_skip_bad(nand_info[dev], start, count);
...especially since you already need to interact with it here?
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Question regarding Problems with CONFIG_SYS_64BIT_LBA in disk/part_efi.c
In the current source tree, in disk/part_efi.c , we see: /* * Problems with CONFIG_SYS_64BIT_LBA: * * struct disk_partition.start in include/part.h is sized as ulong. * When CONFIG_SYS_64BIT_LBA is activated, lbaint_t changes from ulong to uint64_t. * For now, it is cast back to ulong at assignment. * * This limits the maximum size of addressable storage to 2 Terra Bytes */ Is this last comment correct, that there is indeed a maximum size of addressable storage less that 2TB? Or is this an old comment that was never removed? Thanks, Davy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [DFU] Implement NAND dfu support
On Mon, Dec 10, 2012 at 07:09:55PM -0600, Scott Wood wrote:
On 12/10/2012 09:24:32 AM, Pantelis Antoniou wrote:
Introduce on-the fly DFU NAND support.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/dfu/Makefile | 1 +
drivers/dfu/dfu.c | 7 ++
drivers/dfu/dfu_nand.c | 194
+
include/dfu.h | 23 ++
4 files changed, 225 insertions(+)
create mode 100644 drivers/dfu/dfu_nand.c
What is DFU? I don't see anything in README or doc/, despite there
already being CONFIG symbols for it.
Pah... Yes, we let that one slip past. DFU is USB Device Firmware
Upgrade, something from the openmoko folks (roughly) that various
devices support for sending payload via USB to be written to $flash.
+static int nand_block_op(enum dfu_nand_op op, struct dfu_entity *dfu,
+u64 offset, void *buf, long *len)
+{
+char cmd_buf[DFU_CMD_BUF_SIZE];
+u64 start, count;
+int ret;
+int dev;
+loff_t actual;
+
+/* if buf == NULL return total size of the area */
+if (buf == NULL) {
+*len = dfu-data.nand.size;
+return 0;
+}
+
+start = dfu-data.nand.start + offset + dfu-bad_skip;
+count = *len;
+if (start + count
+dfu-data.nand.start + dfu-data.nand.size) {
+printf(%s: block_op out of bounds\n, __func__);
+return -1;
+}
+dev = nand_curr_device;
+if (dev 0 || dev = CONFIG_SYS_MAX_NAND_DEVICE ||
+!nand_info[dev].name) {
+printf(%s: invalid nand device\n, __func__);
+return -1;
+}
+
+sprintf(cmd_buf, nand %s %p %llx %llx,
+op == DFU_OP_READ ? read : write,
+ buf, start, count);
+
+debug(%s: %s 0x%p\n, __func__, cmd_buf, cmd_buf);
+ret = run_command(cmd_buf, 0);
Why not use the C interface to NAND?
+/* find out how much actual bytes have been written */
+/* the difference is the amount of skip we must add from now on
*/
+actual = nand_extent_skip_bad(nand_info[dev], start, count);
...especially since you already need to interact with it here?
I've been talking with Pantelis about this as well and in short, this
series adds NAND support ala MMC (which is to say, (ab)using the command
interface). I think he was thinking we need a bit more generic help to
avoid having to duplicate the code the command interface also uses
(state, sanity checking), iirc.
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: nand: mxs: reset BCH earlier, too, to avoid NAND startup problems
Dear Wolfram Sang, It could happen (1 out of 100 times) that NAND did not start up correctly after warm rebooting, so we end up with various failures or DMA timed out due to a stalled BCH. When resetting BCH together with GPMI, the issue could not be observed anymore (after 1+ reboots). We probably need the consistent state already before sending commands to NAND. This behaviour was observed in barebox and kernel, so I assume it affects U-Boot as well. I chose to keep the extra reset for BCH when changing the flash layout to be on the safe side. Signed-off-by: Wolfram Sang w.s...@pengutronix.de [...] Good, thanks. Ccing Scott to pick this up. Acked-by: Marek Vasut ma...@denx.de Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] universal_c210: check the NULL pointer when get the PMIC
PMIC 2.0 require to test return pointer from pmic_get()
Signed-off-by: Minkyu Kang mk7.k...@samsung.com
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Wolfgang Denk w...@denx.de
---
Changes in V2:
- Since functions are void type, remove the return value.
board/samsung/universal_c210/universal.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/board/samsung/universal_c210/universal.c
b/board/samsung/universal_c210/universal.c
index 4869798..e742707 100644
--- a/board/samsung/universal_c210/universal.c
+++ b/board/samsung/universal_c210/universal.c
@@ -343,6 +343,9 @@ static void init_pmic_lcd(void)
struct pmic *p = pmic_get(MAX8998_PMIC);
+ if (!p)
+ return;
+
if (pmic_probe(p))
return;
@@ -434,6 +437,9 @@ static void lcd_power_on(void)
{
struct pmic *p = pmic_get(MAX8998_PMIC);
+ if (!p)
+ return;
+
if (pmic_probe(p))
return;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] universal_c210: fix compiler error and compiler warning
On 10/12/12 15:50, Minkyu Kang wrote: This patch fix following errors universal.c: In function 'init_pmic_lcd': universal.c:340: warning: implicit declaration of function 'get_pmic' universal.c:340: warning: initialization makes pointer from integer without a cast universal.c: In function 'lcd_power_on': universal.c:431: warning: initialization makes pointer from integer without a cast universal.c: At top level: universal.c:335: warning: 'init_pmic_lcd' defined but not used Signed-off-by: Minkyu Kang mk7.k...@samsung.com Cc: Donghwa Lee dh09@samsung.com Cc: Lukasz Majewski l.majew...@samsung.com --- board/samsung/universal_c210/universal.c |8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) applied to u-boot-samsung/resolve Thanks. Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] SMDK5250: Modify MAX77686 as per the latest Implementation
On 10/12/12 22:16, Lukasz Majewski wrote: Hi Rajeshwari, Resolved the compilation errors for PMIC MAX77686 on SMDK5250. Based on resolve branch of u-boot-samsung. Rajeshwari Shinde (2): POWER: MAX77686: Modified as per the latest Implementation SMDK5250: Enable pmic MAX77686 board/samsung/smdk5250/smdk5250.c | 15 +++- drivers/misc/pmic_max77686.c | 42 -- drivers/power/pmic/Makefile|1 + drivers/power/pmic/pmic_max77686.c | 48 +++ include/configs/smdk5250.h |8 +- include/max77686_pmic.h| 158 include/power/max77686_pmic.h | 158 7 files changed, 222 insertions(+), 208 deletions(-) delete mode 100644 drivers/misc/pmic_max77686.c create mode 100644 drivers/power/pmic/pmic_max77686.c delete mode 100644 include/max77686_pmic.h create mode 100644 include/power/max77686_pmic.h Reviewed-by: Lukasz Majewski l.majew...@samsung.com Acked-by: Lukasz Majewski l.majew...@samsung.com Thanks :-) applied to u-boot-samsung/resolve Thanks. Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] sf: Enable prints on erase and write functions
Hi Simon, I understand your concern. But currently there is no prints a/f reading/writing/erasing the SPI flash. User's are unable to confirm whether that particular sf commands are properly done/not. Thanks, Jagan. On Tue, Dec 11, 2012 at 12:56 AM, Simon Glass s...@chromium.org wrote: Hi, On Mon, Dec 10, 2012 at 6:41 AM, Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com wrote: This patch provides to enabled the prints on erase and write functions to make sure that how many bytes erase/write into flash device. Signed-off-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com --- drivers/mtd/spi/spi_flash.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c index 00aece9..464c2ab 100644 --- a/drivers/mtd/spi/spi_flash.c +++ b/drivers/mtd/spi/spi_flash.c @@ -115,7 +115,7 @@ int spi_flash_cmd_write_multi(struct spi_flash *flash, u32 offset, byte_addr = 0; } - debug(SF: program %s %zu bytes @ %#x\n, + printf(SF: program %s %zu bytes @ %#x\n, ret ? failure : success, len, offset); I don't think we want this - it will make programming very slow and verbose. spi_release_bus(flash-spi); @@ -235,7 +235,7 @@ int spi_flash_cmd_erase(struct spi_flash *flash, u32 offset, size_t len) goto out; } - debug(SF: Successfully erased %zu bytes @ %#x\n, len, start); + printf(SF: Successfully erased %zu bytes @ %#x\n, len, start); You may want to put this code into cmd_sf instead, where it is reasonable to add messages. You are changing core spi code which might be used from many places. out: spi_release_bus(flash-spi); -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [GIT PULL] u-boot-i2c/master
Hello Tom, The following changes since commit fd4d564b3c80b111f18c93adb14233a6a7ddb0e9: Merge branch 'master' of git://git.denx.de/u-boot-x86 (2012-12-07 08:47:59 -0700) are available in the git repository at: git://git.denx.de/u-boot-i2c.git master Andreas Bießmann (1): soft_i2c: add necessary includes for AVR32 Armando Visconti (5): designware_i2c.c: Added the support for MULTI_BUS designware_i2c: Added s/w generation of stop bit designware_i2c: Fixed the setting of the i2c bus speed designware_i2c.h: Fixed the correct values for SCL low/high time designware_i2c.h: Define IC_CLK only if not already defined in config file Marek Vasut (9): i2c: Use __weak instead of __attribute__((weak, alias)) i2c: Staticize local functions in mxc i2c driver i2c: kerneldoc: Add kerneldoc annotations to cmd_i2c.c i2c: mxs: Abstract out the MXS I2C speed setup i2c: mxs: Implement i2c_get/set_bus_speed() i2c: mxs: Use i2c_set_bus_speed() in i2c_init() i2c: mxs: Fix TIMING2 register value mxs: i2c: Restore speed setting after block reset mxs: i2c: Implement algorithm to set up arbitrary i2c speed Piotr Wilczek (4): exynos:clock: Add i2c clock exynos:cpu: Add Exynos4 I2C spacing exynos:pinmux: Add pinmux support for i2c drivers:i2c: Modify I2C driver for Exynos4 Vincent Stehlé (1): omap24xx_i2c: Handle OMAP5 like OMAP2,3,4 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
Re: [U-Boot] [PATCH] [DFU] Implement NAND dfu support
Hi Scott,
On 12/10/2012 09:24:32 AM, Pantelis Antoniou wrote:
Introduce on-the fly DFU NAND support.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/dfu/Makefile | 1 +
drivers/dfu/dfu.c | 7 ++
drivers/dfu/dfu_nand.c | 194
+
include/dfu.h | 23 ++
4 files changed, 225 insertions(+)
create mode 100644 drivers/dfu/dfu_nand.c
What is DFU? I don't see anything in README or doc/, despite there
already being CONFIG symbols for it.
DFU means Device Firmware Upgrade. It is a relatively simple protocol
to update firmware on the target (mainly with small files - e.g.
uImage).
For more information please skim:
http://www.usb.org/developers/devclass_docs/usbdfu10.pdf
+static int nand_block_op(enum dfu_nand_op op, struct dfu_entity
*dfu,
+ u64 offset, void *buf, long *len)
+{
+ char cmd_buf[DFU_CMD_BUF_SIZE];
+ u64 start, count;
+ int ret;
+ int dev;
+ loff_t actual;
+
+ /* if buf == NULL return total size of the area */
+ if (buf == NULL) {
+ *len = dfu-data.nand.size;
+ return 0;
+ }
+
+ start = dfu-data.nand.start + offset + dfu-bad_skip;
+ count = *len;
+ if (start + count
+ dfu-data.nand.start +
dfu-data.nand.size) {
+ printf(%s: block_op out of bounds\n, __func__);
+ return -1;
+ }
+ dev = nand_curr_device;
+ if (dev 0 || dev = CONFIG_SYS_MAX_NAND_DEVICE ||
+ !nand_info[dev].name) {
+ printf(%s: invalid nand device\n, __func__);
+ return -1;
+ }
+
+ sprintf(cmd_buf, nand %s %p %llx %llx,
+ op == DFU_OP_READ ? read : write,
+buf, start, count);
+
+ debug(%s: %s 0x%p\n, __func__, cmd_buf, cmd_buf);
+ ret = run_command(cmd_buf, 0);
Why not use the C interface to NAND?
We also support there eMMC (both with raw and file systems). Moreover
we had this discussion some time ago (if we shall use command or
native C API).
+ /* find out how much actual bytes have been written */
+ /* the difference is the amount of skip we must add from
now on */
+ actual = nand_extent_skip_bad(nand_info[dev], start,
count);
...especially since you already need to interact with it here?
-Scott
--
Best regards,
Lukasz Majewski
Samsung Poland RD Center | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] universal_c210: check the NULL pointer when get the PMIC
Hi Minkyu,
PMIC 2.0 require to test return pointer from pmic_get()
Signed-off-by: Minkyu Kang mk7.k...@samsung.com
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Wolfgang Denk w...@denx.de
---
Changes in V2:
- Since functions are void type, remove the return value.
board/samsung/universal_c210/universal.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/board/samsung/universal_c210/universal.c
b/board/samsung/universal_c210/universal.c index 4869798..e742707
100644 --- a/board/samsung/universal_c210/universal.c
+++ b/board/samsung/universal_c210/universal.c
@@ -343,6 +343,9 @@ static void init_pmic_lcd(void)
struct pmic *p = pmic_get(MAX8998_PMIC);
+ if (!p)
+ return;
+
if (pmic_probe(p))
return;
@@ -434,6 +437,9 @@ static void lcd_power_on(void)
{
struct pmic *p = pmic_get(MAX8998_PMIC);
+ if (!p)
+ return;
+
if (pmic_probe(p))
return;
Acked-by: Lukasz Majewski l.majew...@samsung.com
--
Best regards,
Lukasz Majewski
Samsung Poland RD Center | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
