Re: [U-Boot] [PATCH V2 0/5] ARM: OMAP: Cleanup save_boot_params function
Hi Tom, On Friday 31 May 2013 07:52 PM, Tom Rini wrote: On Fri, May 31, 2013 at 10:18:46AM -0400, Tom Rini wrote: On Wed, Apr 24, 2013 at 04:11:20PM +0530, Sricharan R wrote: The save_boot_params function does not store the data in a always writable area. So the code is broken for a 'XIP' boot. This series corrects this by storing it in 'gd' and also adds a 'C' equivalent function for the same. The essential cleanups for the same are added in this. Tested this on omap5 uevm board with SD/EMMC boot. omap4/5 boards does not have a XIP flash. So yet to test XIP with this series. Also verfied a MAKEALL for armv7. OK, do you have a beaglebone or am335x_evm around? This switch up breaks them, and I'm not sure what's going on. Part of the issue is that the NON_SECURE_SRAM_START/END weren't quite right, but they weren't so wrong as to be a problem (END wasn't quite the end, and start was in the middle of our image, but we didn't reference it). I'm going to keep poking at this as well. Thanks! Answered my own question now, am33xx (andti81xx) doesn't opt-in for omap-common/hwinit-common.c Ok, Thanks for the pointer. So i will add this in the series. and boot test once on am33xx Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] lcd: align bmp header when uncopmressing image
Dear Wolfgang Denk, -Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Friday, May 31, 2013 4:23 PM To: Piotr Wilczek Cc: u-boot@lists.denx.de; Minkyu Kang; Kyungmin Park; Lukasz Majewski; Anatolij Gustschin Subject: Re: [PATCH] lcd: align bmp header when uncopmressing image Dear Piotr Wilczek, In message 136573-15449-1-git-send-email-p.wilc...@samsung.com you wrote: When compressed image is loaded, it must be decompressed to an aligned address + 2 to avoid unaligned access exception on some ARM platforms. If you do this, you must also account for the up to 2 additional bytes needed in the allocated buffer. Otherwise you might write over the end of the buffer... Because 8-byte alignment is guaranteed by malloc I don't think might over write anything when moving by only 2 bytes. But you are right that in principle extra bytes should be allocated. 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 Die ganzen Zahlen hat der liebe Gott geschaffen, alles andere ist Menschenwerk... Leopold Kronecker Best regards, Piotr Wilczek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] lcd: align bmp header when uncopmressing image
Hello Nikita,
-Original Message-
From: Nikita Kiryanov [mailto:nik...@compulab.co.il]
Sent: Sunday, June 02, 2013 1:06 PM
To: Piotr Wilczek
Cc: u-boot@lists.denx.de; Kyungmin Park
Subject: Re: [U-Boot] [PATCH] lcd: align bmp header when uncopmressing
image
Hello Piotr,
On 05/31/2013 02:26 PM, Piotr Wilczek wrote:
-bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp)
+bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp,
+ void **alloc_addr)
{
void *dst;
unsigned long len;
@@ -60,7 +65,14 @@ bmp_image_t *gunzip_bmp(unsigned long addr,
unsigned long *lenp)
puts(Error: malloc in gunzip failed!\n);
return NULL;
}
- if (gunzip(dst, CONFIG_SYS_VIDEO_LOGO_MAX_SIZE, (uchar *)addr,
len) != 0) {
+
+ bmp = dst;
+
+ /* align to 32-bit-aligned-address + 2 */
+ if ((unsigned int)bmp % 0x04 != 0x02)
+ bmp = (bmp_image_t *)(((unsigned int)dst + 0x02) ~0x01);
This is wrong. Suppose that bmp % 4 == 3, then (dst + 2) % 4 == 1, and
thus ((dst + 2) ~1) % 4 == 0, which is not an aligned+2 address.
You are right but here I'm aligning a pointer returned by malloc which is
guaranteed to be aligned to 8 bytes. In fact it is sufficient only to add
two bytes.
Anyway, to make the code universal I provide a better alignment method.
+
+ if (gunzip(bmp, CONFIG_SYS_VIDEO_LOGO_MAX_SIZE, (uchar *)addr,
len)
+!= 0) {
free(dst);
return NULL;
}
@@ -68,8 +80,6 @@ bmp_image_t *gunzip_bmp(unsigned long addr,
unsigned long *lenp)
puts(Image could be truncated
(increase
CONFIG_SYS_VIDEO_LOGO_MAX_SIZE)!\n);
--
Regards,
Nikita.
Best regards,
Piotr
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] arm: lds: Remove libgcc eabi exception handling tables
Hi Albert, On 05/14/2013 05:44 PM, Albert ARIBAUD wrote: Hi Michal, On Mon, 13 May 2013 09:45:12 +0200, Michal Simek mon...@monstr.eu wrote: On 05/10/2013 09:07 PM, Albert ARIBAUD wrote: Hi Michal, On Thu, 9 May 2013 11:35:33 +0200, Michal Simek michal.si...@xilinx.com wrote: Remove ARM eabi exception handling tables (for frame unwinding). AFAICT, u-boot stubs away the frame unwiding routines, so the tables will more or less just consume space. It should be OK to remove them. Signed-off-by: Edgar E. Iglesias edgar.igles...@xilinx.com Signed-off-by: Michal Simek michal.si...@xilinx.com --- Other options could be to complete u-boot/arch/arm/lib/* so that libgcc routines with exception handling dont get pulled in. Or to avoid user code (like the mentioned patch) which causes external libgcc functions to get pulled in... Er... which mentioned patch? Ah yeah. Let me give you background. After adding: arm: zynq: U-Boot udelay 1000 FIX (sha1: d54cc007878697a92e7f696b71a3eb203c0386e2) we have found that new program header is added to u-boot for zynq. Program Header: 0x7001 off0x000405fc vaddr 0x040385fc paddr 0x040385fc align 2**2 filesz 0x0020 memsz 0x0020 flags r-- LOAD off0x8000 vaddr 0x0400 paddr 0x0400 align 2**15 filesz 0x00041240 memsz 0x00041240 flags rwx STACK off0x vaddr 0x paddr 0x align 2**2 filesz 0x memsz 0x flags rwx Tracing down this we found that uldivmod is used 27: 0 NOTYPE GLOBAL DEFAULT UND __aeabi_uldivmod Based on that Edgar proposed this patch. Ok, so Michal and I just did some fiddling with zynq builds and *exidx* sections. By default the *exidx* sections are between rodata and data, so removing them causes many apparent changes at the binary level. However, builds of zynq based on ARM master with the patch above vs master with a patch mapping *exidx* sections after BSS gives identical binaries. Thus the RFC has no functional effect. Also, ARM EHABI states that [exception] Tables are not required for ABI compliance at the C/Assembler level but are required for C++. http://infocenter.arm.com/help/topic/com.arm.doc.ihi0038a/IHI0038A_ehabi.pdf So as long as we don't put any C++ code in U-Boot (a prospect that I don't see happening any time soon), this RFC is safe and either is a no-op or removes useless bytes from the binary. Any update on this? Have you decided to add or not to add to this release? If you I need to fix zynq timer code do not use exception handling table. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] am33xx/omap: Move save_omap_boot_params to omap-common/boot-common.c
On Friday 31 May 2013 11:48 PM, Tom Rini wrote:
We need to call the save_omap_boot_params function on am33xx/ti81xx and
other newer TI SoCs, so move the function to boot-common. Only OMAP4+
has the omap_hw_init_context function so add ifdefs to not call it on
am33xx/ti81xx. Call save_omap_boot_params from s_init on am33xx/ti81xx
boards.
Signed-off-by: Tom Rini tr...@ti.com
---
arch/arm/cpu/armv7/omap-common/boot-common.c | 39
arch/arm/cpu/armv7/omap-common/hwinit-common.c | 36 --
arch/arm/include/asm/arch-am33xx/sys_proto.h |1 +
arch/arm/include/asm/arch-omap4/sys_proto.h|1 +
arch/arm/include/asm/arch-omap5/sys_proto.h|1 +
board/isee/igep0033/board.c|9 ++
board/phytec/pcm051/board.c|9 ++
board/ti/am335x/board.c|9 ++
board/ti/ti814x/evm.c |9 ++
9 files changed, 78 insertions(+), 36 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/boot-common.c
b/arch/arm/cpu/armv7/omap-common/boot-common.c
index bff7e9c..76ae1b6 100644
--- a/arch/arm/cpu/armv7/omap-common/boot-common.c
+++ b/arch/arm/cpu/armv7/omap-common/boot-common.c
@@ -25,6 +25,45 @@
DECLARE_GLOBAL_DATA_PTR;
+void save_omap_boot_params(void)
+{
+ u32 rom_params = *((u32 *)OMAP_SRAM_SCRATCH_BOOT_PARAMS);
+ u8 boot_device;
+ u32 dev_desc, dev_data;
+
+ if ((rom_params NON_SECURE_SRAM_START) ||
+ (rom_params NON_SECURE_SRAM_END))
+ return;
+
+ /*
+ * rom_params can be type casted to omap_boot_parameters and
+ * used. But it not correct to assume that romcode structure
+ * encoding would be same as u-boot. So use the defined offsets.
+ */
+ gd-arch.omap_boot_params.omap_bootdevice = boot_device =
+*((u8 *)(rom_params + BOOT_DEVICE_OFFSET));
+
+ gd-arch.omap_boot_params.ch_flags =
+ *((u8 *)(rom_params + CH_FLAGS_OFFSET));
+
+ if ((boot_device = MMC_BOOT_DEVICES_START)
+ (boot_device = MMC_BOOT_DEVICES_END)) {
+#if !defined(CONFIG_AM33XX) !defined(CONFIG_TI81XX)
+ if ((omap_hw_init_context() ==
+ OMAP_INIT_CONTEXT_UBOOT_AFTER_SPL)) {
+ gd-arch.omap_boot_params.omap_bootmode =
+ *((u8 *)(rom_params + BOOT_MODE_OFFSET));
+ } else
+#endif
This is fine, as long as omap_bootmode is not required in u-boot,
which i think is the case now.
+ {
+ dev_desc = *((u32 *)(rom_params + DEV_DESC_PTR_OFFSET));
+ dev_data = *((u32 *)(dev_desc + DEV_DATA_PTR_OFFSET));
+ gd-arch.omap_boot_params.omap_bootmode =
+ *((u32 *)(dev_data + BOOT_MODE_OFFSET));
+ }
+ }
+}
+
#ifdef CONFIG_SPL_BUILD
u32 spl_boot_device(void)
{
diff --git a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
index e614641..0776d5c 100644
--- a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
+++ b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
@@ -111,42 +111,6 @@ void __weak srcomp_enable(void)
{
}
-static void save_omap_boot_params(void)
-{
- u32 rom_params = *((u32 *)OMAP_SRAM_SCRATCH_BOOT_PARAMS);
- u8 boot_device;
- u32 dev_desc, dev_data;
-
- if ((rom_params NON_SECURE_SRAM_START) ||
- (rom_params NON_SECURE_SRAM_END))
- return;
-
- /*
- * rom_params can be type casted to omap_boot_parameters and
- * used. But it not correct to assume that romcode structure
- * encoding would be same as u-boot. So use the defined offsets.
- */
- gd-arch.omap_boot_params.omap_bootdevice = boot_device =
-*((u8 *)(rom_params + BOOT_DEVICE_OFFSET));
-
- gd-arch.omap_boot_params.ch_flags =
- *((u8 *)(rom_params + CH_FLAGS_OFFSET));
-
- if ((boot_device = MMC_BOOT_DEVICES_START)
- (boot_device = MMC_BOOT_DEVICES_END)) {
- if ((omap_hw_init_context() ==
- OMAP_INIT_CONTEXT_UBOOT_AFTER_SPL)) {
- gd-arch.omap_boot_params.omap_bootmode =
- *((u8 *)(rom_params + BOOT_MODE_OFFSET));
- } else {
- dev_desc = *((u32 *)(rom_params + DEV_DESC_PTR_OFFSET));
- dev_data = *((u32 *)(dev_desc + DEV_DATA_PTR_OFFSET));
- gd-arch.omap_boot_params.omap_bootmode =
- *((u32 *)(dev_data + BOOT_MODE_OFFSET));
- }
- }
-}
-
#ifdef CONFIG_ARCH_CPU_INIT
/*
* SOC specific cpu init
diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h
Re: [U-Boot] [PATCH V2 0/5] ARM: OMAP: Cleanup save_boot_params function
On Monday 03 June 2013 11:39 AM, Sricharan R wrote: Hi Tom, On Friday 31 May 2013 07:52 PM, Tom Rini wrote: On Fri, May 31, 2013 at 10:18:46AM -0400, Tom Rini wrote: On Wed, Apr 24, 2013 at 04:11:20PM +0530, Sricharan R wrote: The save_boot_params function does not store the data in a always writable area. So the code is broken for a 'XIP' boot. This series corrects this by storing it in 'gd' and also adds a 'C' equivalent function for the same. The essential cleanups for the same are added in this. Tested this on omap5 uevm board with SD/EMMC boot. omap4/5 boards does not have a XIP flash. So yet to test XIP with this series. Also verfied a MAKEALL for armv7. OK, do you have a beaglebone or am335x_evm around? This switch up breaks them, and I'm not sure what's going on. Part of the issue is that the NON_SECURE_SRAM_START/END weren't quite right, but they weren't so wrong as to be a problem (END wasn't quite the end, and start was in the middle of our image, but we didn't reference it). I'm going to keep poking at this as well. Thanks! Answered my own question now, am33xx (andti81xx) doesn't opt-in for omap-common/hwinit-common.c Ok, Thanks for the pointer. So i will add this in the series. and boot test once on am33xx Ok, you have already addressed this . Thanks a lot.. Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add splash screen support via loading from flash
Hi Robert,
On 30/05/2013 23:03, Robert Winkler wrote:
Signed-off-by: Robert Winkler robert.wink...@boundarydevices.com
---
board/boundary/nitrogen6x/nitrogen6x.c | 22 ++
include/configs/nitrogen6x.h | 11 ++-
2 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/board/boundary/nitrogen6x/nitrogen6x.c
b/board/boundary/nitrogen6x/nitrogen6x.c
index 3b228cf..648b877 100644
--- a/board/boundary/nitrogen6x/nitrogen6x.c
+++ b/board/boundary/nitrogen6x/nitrogen6x.c
@@ -401,6 +401,24 @@ int board_eth_init(bd_t *bis)
return 0;
}
+
+void splash_screen_prepare(void)
+{
+ char *env_loadsplash;
+
+ if (!getenv(splashimage) || !getenv(splashsize))
+ return;
+
+ env_loadsplash = getenv(loadsplash);
+ if (!env_loadsplash) {
+ printf(Environment variable loadsplash not found!\n);
+ return;
+ }
+
+ if (run_command_list(env_loadsplash, -1, 0))
+ printf(failed to run loadsplash %s\n\n, env_loadsplash);
+}
+
Which is the advantage instead of using the preboot variable setting
CONFIG_PREBOOT ? It does pretty the same and you can move the whole
script outside of board code.
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 6/7] arm: vf610: Add Vybrid VF610 to mxc_ocotp document
On 28/05/2013 10:55, Alison Wang wrote: This patch adds Vybrid VF610 to mxc_ocotp document. Signed-off-by: Alison Wang b18...@freescale.com --- At the end, I left this patch without squashing to not drop also Benoit's reviewed-by. As we have already said, it does not really matter. Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 5/7] arm: vf610: Add uart support for Vybrid VF610
On 28/05/2013 10:55, Alison Wang wrote: This patch adds lpuart support for Vybrid VF610 platform. Signed-off-by: TsiChung Liew tsicl...@gmail.com Signed-off-by: Alison Wang b18...@freescale.com --- Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 7/7] arm: vf610: Add basic support for Vybrid VF610TWR board
On 28/05/2013 10:55, Alison Wang wrote: VF610TWR is a board based on Vybrid VF610 SoC. This patch adds basic support for Vybrid VF610TWR board. Signed-off-by: Alison Wang b18...@freescale.com Signed-off-by: Jason Jin jason@freescale.com Signed-off-by: TsiChung Liew tsicl...@gmail.com --- Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/7] arm: vf610: Add IOMUX support for Vybrid VF610
On 28/05/2013 10:55, Alison Wang wrote: This patch adds the IOMUX support for Vybrid VF610 platform. There is a little difference for IOMUXC module between VF610 and i.MX platform, the muxmode and pad configuration share one 32bit register on VF610, but they are two independent registers on I.MX platform. A CONFIG_IOMUX_SHARE_CONFIG_REG was introduced to fit this difference. Signed-off-by: Alison Wang b18...@freescale.com --- Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/7] net: fec_mxc: Add support for Vybrid VF610
On 28/05/2013 10:55, Alison Wang wrote: This patch adds FEC support for Vybrid VF610 platform. In function fec_open(), RCR register is only set as RGMII mode. But RCR register should be set as RMII mode for VF610 platform. This configuration is already done in fec_reg_setup(), so this piece of code could just leave untouched the FEC_RCNTRL_RGMII / FEC_RCNTRL_RMII / FEC_RCNTRL_MII_MODE bits. Signed-off-by: Alison Wang b18...@freescale.com Reviewed-by: Benoit Thebaudeau benoit.thebaud...@advansee.com --- Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 4/7] arm: vf610: Add watchdog support for Vybrid VF610
On 28/05/2013 10:55, Alison Wang wrote: This patch adds watchdog support for Vybrid VF610 platform. Signed-off-by: Alison Wang b18...@freescale.com --- Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/7] arm: vf610: Add Vybrid VF610 CPU support
On 28/05/2013 10:55, Alison Wang wrote: This patch adds generic codes to support Freescale's Vybrid VF610 CPU. It aligns Vybrid VF610 platform with i.MX platform. As there are some differences between VF610 and i.MX platforms, the specific codes are in the arch/arm/cpu/armv7/vf610 directory. Signed-off-by: Alison Wang b18...@freescale.com --- Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [u-boot] spi/arm-pl022: Add support for ARM PL022 spi controller
This patch adds the support for the ARM PL022 SPI controller for the standard
variant (0x00041022), which has a 16bit wide and 8 locations deep TX/RX FIFO.
Signed-off-by: Armando Visconti armando.visco...@st.com
Signed-off-by: Vipin Kumar vipin.ku...@st.com
---
This driver has been tested on the ST SPEAr1340 evaluation board.
Patch has just been rebased on http://git.denx.de/u-boot-spi.git
master branch and can be cleanly applied there.
Armando
drivers/spi/Makefile| 1 +
drivers/spi/pl022_spi.c | 308
2 files changed, 309 insertions(+)
create mode 100644 drivers/spi/pl022_spi.c
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index d08609e..b6443b1 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -47,6 +47,7 @@ COBJS-$(CONFIG_MXC_SPI) += mxc_spi.o
COBJS-$(CONFIG_MXS_SPI) += mxs_spi.o
COBJS-$(CONFIG_OC_TINY_SPI) += oc_tiny_spi.o
COBJS-$(CONFIG_OMAP3_SPI) += omap3_spi.o
+COBJS-$(CONFIG_PL022_SPI) += pl022_spi.o
COBJS-$(CONFIG_SOFT_SPI) += soft_spi.o
COBJS-$(CONFIG_SH_SPI) += sh_spi.o
COBJS-$(CONFIG_FSL_ESPI) += fsl_espi.o
diff --git a/drivers/spi/pl022_spi.c b/drivers/spi/pl022_spi.c
new file mode 100644
index 000..3ea769a
--- /dev/null
+++ b/drivers/spi/pl022_spi.c
@@ -0,0 +1,308 @@
+/*
+ * (C) Copyright 2012
+ * Armando Visconti, ST Microelectronics, armando.visco...@st.com.
+ *
+ * Driver for ARM PL022 SPI Controller. Based on atmel_spi.c
+ * by Atmel Corporation.
+ *
+ * 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 spi.h
+#include asm/io.h
+#include asm/arch/hardware.h
+
+/* SSP registers mapping */
+#define SSP_CR00x000
+#define SSP_CR10x004
+#define SSP_DR 0x008
+#define SSP_SR 0x00C
+#define SSP_CPSR 0x010
+#define SSP_IMSC 0x014
+#define SSP_RIS0x018
+#define SSP_MIS0x01C
+#define SSP_ICR0x020
+#define SSP_DMACR 0x024
+#define SSP_ITCR 0x080
+#define SSP_ITIP 0x084
+#define SSP_ITOP 0x088
+#define SSP_TDR0x08C
+
+#define SSP_PID0 0xFE0
+#define SSP_PID1 0xFE4
+#define SSP_PID2 0xFE8
+#define SSP_PID3 0xFEC
+
+#define SSP_CID0 0xFF0
+#define SSP_CID1 0xFF4
+#define SSP_CID2 0xFF8
+#define SSP_CID3 0xFFC
+
+/* SSP Control Register 0 - SSP_CR0 */
+#define SSP_CR0_SPO(0x1 6)
+#define SSP_CR0_SPH(0x1 7)
+#define SSP_CR0_8BIT_MODE (0x07)
+#define SSP_SCR_MAX(0xFF)
+#define SSP_SCR_SHFT 8
+
+/* SSP Control Register 0 - SSP_CR1 */
+#define SSP_CR1_MASK_SSE (0x1 1)
+
+#define SSP_CPSR_MAX (0xFE)
+
+/* SSP Status Register - SSP_SR */
+#define SSP_SR_MASK_TFE(0x1 0) /* Transmit FIFO empty */
+#define SSP_SR_MASK_TNF(0x1 1) /* Transmit FIFO not full */
+#define SSP_SR_MASK_RNE(0x1 2) /* Receive FIFO not empty */
+#define SSP_SR_MASK_RFF(0x1 3) /* Receive FIFO full */
+#define SSP_SR_MASK_BSY(0x1 4) /* Busy Flag */
+
+struct pl022_spi_slave {
+ struct spi_slave slave;
+ void *regs;
+ unsigned int freq;
+};
+
+static inline struct pl022_spi_slave *to_pl022_spi(struct spi_slave *slave)
+{
+ return container_of(slave, struct pl022_spi_slave, slave);
+}
+
+/*
+ * Following three functions should be provided by the
+ * board support package.
+ */
+int spi_cs_is_valid(unsigned int bus, unsigned int cs)
+ __attribute__((weak, alias(__spi_cs_is_valid)));
+void spi_cs_activate(struct spi_slave *slave)
+ __attribute__((weak, alias(__spi_cs_activate)));
+void spi_cs_deactivate(struct spi_slave *slave)
+ __attribute__((weak, alias(__spi_cs_deactivate)));
+
+int __spi_cs_is_valid(unsigned int bus, unsigned int cs)
+{
+ return 1;
+}
+
+void __spi_cs_activate(struct spi_slave *slave)
+{
+ /* do nothing */
+}
+
+void __spi_cs_deactivate(struct spi_slave *slave)
+{
+ /* do nothing */
+}
+
+void spi_init()
+{
+ /* do nothing */
+}
+
+/*
+ * ARM PL022 exists in different 'flavors'.
+ * This drivers currently support the standard variant (0x00041022), that has a
+ * 16bit wide and 8 locations deep TX/RX
Re: [U-Boot] [PATCH v2] Add support for Wandboard quad.
Hi Tapani, On 28/05/2013 10:04, Tapani Utriainen wrote: Add support for Wandboard quad. Signed-off-by: Tapani Utriainen tap...@technexion.com --- Due to increased memory, a warning is generated for wandboard_quad: wandboard.c: In function 'dram_init': wandboard.c:47:31: warning: integer overflow in expression [-Woverflow] It is better to fix it directly into this patch. Can you fix it by casting to phys_size_t and resubmit ? gd-ram_size = (phys_size_t)CONFIG_DDR_MB * SZ_1M; By the way, I forget why it is not possible to use get_ram_size() here. I know this is not part of this patch (could be done later), but any hints why we cannot use as usual get_ram_size() in dram_init ? Thanks, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [u-boot] spi/arm-pl022: Add support for ARM PL022 spi controller
Hi,
Is this the v4? I sent some comment for v3 on same driver.
Thanks,
Jagan.
On Mon, Jun 3, 2013 at 1:54 PM, Armando Visconti
armando.visco...@st.com wrote:
This patch adds the support for the ARM PL022 SPI controller for the standard
variant (0x00041022), which has a 16bit wide and 8 locations deep TX/RX FIFO.
Signed-off-by: Armando Visconti armando.visco...@st.com
Signed-off-by: Vipin Kumar vipin.ku...@st.com
---
This driver has been tested on the ST SPEAr1340 evaluation board.
Patch has just been rebased on http://git.denx.de/u-boot-spi.git
master branch and can be cleanly applied there.
Armando
drivers/spi/Makefile| 1 +
drivers/spi/pl022_spi.c | 308
2 files changed, 309 insertions(+)
create mode 100644 drivers/spi/pl022_spi.c
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index d08609e..b6443b1 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -47,6 +47,7 @@ COBJS-$(CONFIG_MXC_SPI) += mxc_spi.o
COBJS-$(CONFIG_MXS_SPI) += mxs_spi.o
COBJS-$(CONFIG_OC_TINY_SPI) += oc_tiny_spi.o
COBJS-$(CONFIG_OMAP3_SPI) += omap3_spi.o
+COBJS-$(CONFIG_PL022_SPI) += pl022_spi.o
COBJS-$(CONFIG_SOFT_SPI) += soft_spi.o
COBJS-$(CONFIG_SH_SPI) += sh_spi.o
COBJS-$(CONFIG_FSL_ESPI) += fsl_espi.o
diff --git a/drivers/spi/pl022_spi.c b/drivers/spi/pl022_spi.c
new file mode 100644
index 000..3ea769a
--- /dev/null
+++ b/drivers/spi/pl022_spi.c
@@ -0,0 +1,308 @@
+/*
+ * (C) Copyright 2012
+ * Armando Visconti, ST Microelectronics, armando.visco...@st.com.
+ *
+ * Driver for ARM PL022 SPI Controller. Based on atmel_spi.c
+ * by Atmel Corporation.
+ *
+ * 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 spi.h
+#include asm/io.h
+#include asm/arch/hardware.h
+
+/* SSP registers mapping */
+#define SSP_CR00x000
+#define SSP_CR10x004
+#define SSP_DR 0x008
+#define SSP_SR 0x00C
+#define SSP_CPSR 0x010
+#define SSP_IMSC 0x014
+#define SSP_RIS0x018
+#define SSP_MIS0x01C
+#define SSP_ICR0x020
+#define SSP_DMACR 0x024
+#define SSP_ITCR 0x080
+#define SSP_ITIP 0x084
+#define SSP_ITOP 0x088
+#define SSP_TDR0x08C
+
+#define SSP_PID0 0xFE0
+#define SSP_PID1 0xFE4
+#define SSP_PID2 0xFE8
+#define SSP_PID3 0xFEC
+
+#define SSP_CID0 0xFF0
+#define SSP_CID1 0xFF4
+#define SSP_CID2 0xFF8
+#define SSP_CID3 0xFFC
+
+/* SSP Control Register 0 - SSP_CR0 */
+#define SSP_CR0_SPO(0x1 6)
+#define SSP_CR0_SPH(0x1 7)
+#define SSP_CR0_8BIT_MODE (0x07)
+#define SSP_SCR_MAX(0xFF)
+#define SSP_SCR_SHFT 8
+
+/* SSP Control Register 0 - SSP_CR1 */
+#define SSP_CR1_MASK_SSE (0x1 1)
+
+#define SSP_CPSR_MAX (0xFE)
+
+/* SSP Status Register - SSP_SR */
+#define SSP_SR_MASK_TFE(0x1 0) /* Transmit FIFO empty */
+#define SSP_SR_MASK_TNF(0x1 1) /* Transmit FIFO not full
*/
+#define SSP_SR_MASK_RNE(0x1 2) /* Receive FIFO not empty
*/
+#define SSP_SR_MASK_RFF(0x1 3) /* Receive FIFO full */
+#define SSP_SR_MASK_BSY(0x1 4) /* Busy Flag */
+
+struct pl022_spi_slave {
+ struct spi_slave slave;
+ void *regs;
+ unsigned int freq;
+};
+
+static inline struct pl022_spi_slave *to_pl022_spi(struct spi_slave *slave)
+{
+ return container_of(slave, struct pl022_spi_slave, slave);
+}
+
+/*
+ * Following three functions should be provided by the
+ * board support package.
+ */
+int spi_cs_is_valid(unsigned int bus, unsigned int cs)
+ __attribute__((weak, alias(__spi_cs_is_valid)));
+void spi_cs_activate(struct spi_slave *slave)
+ __attribute__((weak, alias(__spi_cs_activate)));
+void spi_cs_deactivate(struct spi_slave *slave)
+ __attribute__((weak, alias(__spi_cs_deactivate)));
+
+int __spi_cs_is_valid(unsigned int bus, unsigned int cs)
+{
+ return 1;
+}
+
+void __spi_cs_activate(struct spi_slave *slave)
+{
+ /* do nothing */
+}
+
Re: [U-Boot] [u-boot] spi/arm-pl022: Add support for ARM PL022 spi controller
On 06/03/2013 11:48 AM, Jagan Teki wrote: Hi, Is this the v4? I sent some comment for v3 on same driver. Sorry, I completely lost the original thread... I will re-start from V3... Pls discard this noisy thread, Armando ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [u-boot] spi/arm-pl022: Add support for ARM PL022 spi controller
I completely lost the original thread... I will re-start from V3... Pls discard this noisy thread, Please check the below thread for earlier v3 http://patchwork.ozlabs.org/patch/205814/ -- Thanks, Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: mxs: Fix vectoring table crafting
On 26/04/2013 04:37, Marek Vasut wrote: The vectoring table has to be placed at 0x0, but U-Boot on MX23/MX28 starts from RAM, so the vectoring table at 0x0 is not present. Craft code that will be placed at 0x0 and will redirect interrupt vectoring to proper location of the U-Boot in RAM. Signed-off-by: Marek Vasut ma...@denx.de CC: Stefano Babic sba...@denx.de CC: Fabio Estevam fabio.este...@freescale.com --- Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 09/12] mmc: omap_hsmmc: add mmc1 pbias, ldo1
Hi Lubomir,
On Thursday 30 May 2013 07:56 PM, Lubomir Popov wrote:
Hi Lokesh,
On 30/05/13 16:19, Lokesh Vutla wrote:
From: Balaji T K balaj...@ti.com
add dra mmc pbias support and ldo1 power on
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/include/asm/arch-omap5/omap.h |3 ++-
drivers/mmc/omap_hsmmc.c | 26 ++
drivers/power/palmas.c | 25 -
include/configs/omap5_common.h |4
include/configs/omap5_uevm.h |5 -
include/palmas.h |6 +-
6 files changed, 49 insertions(+), 20 deletions(-)
[snip]
diff --git a/drivers/power/palmas.c b/drivers/power/palmas.c
index 09c832d..1bcff52 100644
--- a/drivers/power/palmas.c
+++ b/drivers/power/palmas.c
@@ -28,7 +28,7 @@ void palmas_init_settings(void)
return;
}
-int palmas_mmc1_poweron_ldo(void)
+int palmas_mmc1_poweron_ldo9(void)
{
u8 val = 0;
@@ -50,3 +50,26 @@ int palmas_mmc1_poweron_ldo(void)
return 0;
}
+
+int palmas_mmc1_poweron_ldo1(void)
+{
+ u8 val = 0;
+
+ /* set LDO9 TWL6035 to 3V */
LDO9? TWL6035? If this function is used on the DRA7xx boards only (with
TPS659038), you should add some comment above.
Ok ll add the comment.
+ val = 0x2b; /* (3 - 0.9) * 20 + 1 */
Why not use definitions for the voltage? You could take them from
http://patchwork.ozlabs.org/patch/244103/ where some values are
defined.
Yes, Ill rebase this patch on top of your patch and use those defines.
+
+ if (palmas_i2c_write_u8(TPS659038_CHIP_ADDR, LDO1_VOLTAGE, val)) {
+ printf(tps659038: could not set LDO1 voltage\n);
+ return 1;
+ }
+
+ /* TURN ON LDO9 */
LDO9?
+ val = LDO_ON | LDO_MODE_SLEEP | LDO_MODE_ACTIVE;
Bit LDO_ON in all LDOx_CTRL Palmas registers is Read-Only (and reflects the
current status of the LDO). While it makes no harm to try writing to it, this
may be misleading about actual LDO operation, and anyway has no sense.
Yes, I see a similar update in your patch for LDO9. ll do the same for
LDO1 also.
Thanks
Lokesh
+
+ if (palmas_i2c_write_u8(TPS659038_CHIP_ADDR, LDO1_CTRL, val)) {
+ printf(tps659038: could not turn on LDO1\n);
+ return 1;
+ }
+
[snip]
/* I2C chip addresses */
#define PALMAS_CHIP_ADDR 0x48
+#define TPS659038_CHIP_ADDR0x58
Now we have a mess again. The files were recently renamed from twl6035.x
to palmas.x, implying that palmas is the generic family name of a series
of PMICs. Having TPS659038_CHIP_ADDR above is OK, but then we should have
TWL603X_CHIP_ADDR instead of PALMAS_CHIP_ADDR.
Best regards,
Lubomir
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] lcd: align bmp header when uncopmressing image
Dear Piotr Wilczek, In message 000601ce6021$fcb8f490$f62addb0$%wilc...@samsung.com you wrote: If you do this, you must also account for the up to 2 additional bytes needed in the allocated buffer. Otherwise you might write over the end of the buffer... Because 8-byte alignment is guaranteed by malloc I don't think might over write anything when moving by only 2 bytes. Oops??? Initial alignment has NOTHING to do with writing over the allocated end of memory! But you are right that in principle extra bytes should be allocated. This is not a questions of pricniple, but plainly of invoking undefined behaviour. Please fix. 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 A direct quote from the Boss: We passed over a lot of good people to get the ones we hired. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6slevk: Allow booting a device tree kernel
On 24/05/2013 01:57, Fabio Estevam wrote: From: Fabio Estevam fabio.este...@freescale.com When the mx6slevk board support was added in U-boot there was no device tree support for mx6sl, so only a FSL 3.0.35 was tested at that time. Now that mx6slevk support is available we can boot a device tree kernel, by adjusting CONFIG_LOADADDR into a proper location, so that a non-dt and a dt kernels can be booted. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] lcd: align bmp header when uncopmressing image
Dear Piotr Wilczek, In message 000701ce6025$173886c0$45a99440$%wilc...@samsung.com you wrote: + /* align to 32-bit-aligned-address + 2 */ + if ((unsigned int)bmp % 0x04 != 0x02) + bmp = (bmp_image_t *)(((unsigned int)dst + 0x02) ~0x01); This is wrong. Suppose that bmp % 4 == 3, then (dst + 2) % 4 == 1, and thus ((dst + 2) ~1) % 4 == 0, which is not an aligned+2 address. You are right but here I'm aligning a pointer returned by malloc which is guaranteed to be aligned to 8 bytes. In fact it is sufficient only to add two bytes. Such assumptions are black magic at best. Please always consider the mentalk welfare of your follow programmers who for example might change this into a character array (say, a buffer on the stack) and suddenly experience mysetrious crashes. Please always write code such that it is NOT based on non-obvious requirements. Anyway, to make the code universal I provide a better alignment method. Thanks. 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 God is a comedian playing to an audience too afraid to laugh. - Voltaire ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mx6qsabreauto: Add i2c to mx6qsabreauto board
On 14/05/2013 06:01, Renato Frias wrote: Add i2c2 and 3 to mx6qsabreauto board, i2c3 is multiplexed use gpio to set steering. Signed-off-by: Renato Frias b13...@freescale.com --- Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] mx6qsabreauto: Add Port Expander reset
On 14/05/2013 06:01, Renato Frias wrote: There are 3 IO expanders on the mx6qsabreauto all reset by the same GPIO, just set it to high to use the IO. Signed-off-by: Renato Frias b13...@freescale.com --- Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Add support for Wandboard quad.
Dear Stefano Babic, In message 51ac61a6.9050...@denx.de you wrote: It is better to fix it directly into this patch. Can you fix it by casting to phys_size_t and resubmit ? gd-ram_size = (phys_size_t)CONFIG_DDR_MB * SZ_1M; Please do NOT use these terrible SZ_* defines. Never, ever. They are dangerous and should be avoided. 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 Carelessly planned projects take three times longer to complete than expected. Carefully planned projects take four times longer to complete than expected, mostly because the planners expect their planning to reduce the time it takes. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Add support for Wandboard quad.
On Mon, Jun 3, 2013 at 8:21 AM, Wolfgang Denk w...@denx.de wrote: Dear Stefano Babic, In message 51ac61a6.9050...@denx.de you wrote: It is better to fix it directly into this patch. Can you fix it by casting to phys_size_t and resubmit ? gd-ram_size = (phys_size_t)CONFIG_DDR_MB * SZ_1M; Please do NOT use these terrible SZ_* defines. Never, ever. They are dangerous and should be avoided. Do you mind to explain why? -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6: mx6qsabrelite/nitrogen6x: Remove incorrect setting of gpio CS signal
On 30/05/2013 16:47, Andrew Gabbasov wrote: The number of gpio signal is packed inside CONFIG_SF_DEFAULT_CS macro (shifted and or'ed with chip select), so it's incorrect to pass that macro directly as an argument to gpio_direction_output() call. Also, SPI driver sets the direction and initial value of a gpio, used as a chip select signal, before any actual activity happens on the bus. So, it is safe to just remove the gpio_direction_output call, that works incorrectly, thus making no effect, anyway. Signed-off-by: Andrew Gabbasov andrew_gabba...@mentor.com --- Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6] Add support for Congatec Conga-QEVAl board
Hi Leo,
On 16/05/2013 18:13, SARTRE Leo wrote:
+int board_init(void)
+{
+ u32 reg;
+ /*Same init as the sabrelite*/
+ writel(0x41736166, SNVS_BASE_ADDR + 0x64);/*set LPPGDR*/
+ udelay(10);
+ reg = readl(SNVS_BASE_ADDR + 0x4c);
+ reg |= (1 3);
+ writel(reg, SNVS_BASE_ADDR + 0x4c);/*clear LPSR*/
Sorry that it was not checked before. Can you substitute fix constants
with useful defines ? Comment seems also deviant : it seems we can find
the same initialization in mx6qsabrelite.c, it is not. Please also
remove fix offsets when you access to the internal registres, and use C
structures instead. This is a must in u-boot, access with BASE + OFFSET
are not allowed.
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] build: Use generic boot logo matching
On 28/05/2013 00:18, Otavio Salvador wrote: The boot logo matching is now done in following way: - use LOGO_BMP if it is set, or - use $(BOARD).bmp if it exists in tools/logos, or - use $(VENDOR).bmp if it exists in tools/logos, or - use denx.bmp otherwise. Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] wandboard: Enable HDMI splashscreen
On 23/05/2013 19:50, Fabio Estevam wrote: Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/2] wandboard: Add Boot Splash image with Wandboard logo
On 28/05/2013 00:18, Otavio Salvador wrote: Signed-off-by: Otavio Salvador ota...@ossystems.com.br --- Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v1 1/1] mpc512x: adjust and improve AC14xx board support
minor improvements for the 'ifm AC14xx' board setup
- adjust diagnostics (reworded, silent by default)
- re-order the list of recovery conditions
- update and improve comments
- adjust the board configuration
- use the builtin serial baudrate table
- use the official 'ac14xx' name everywhere (remove 'k6' remainders)
- fix a NUL termination issue in the rootpath spec
- rephrase the 'muster_nr' suffix for development network boot
- reduce the ARP timeout for faster network boot
Signed-off-by: Gerhard Sittig g...@denx.de
---
board/ifm/ac14xx/ac14xx.c | 44 +---
include/configs/ac14xx.h | 25 -
2 files changed, 33 insertions(+), 36 deletions(-)
all of the modifications only affect the 'ifm AC14xx' board, the changes
were tested and verified on the hardware, but a style related question
remains:
shall I split this patch into a series of tiny patches each addressing a
specific aspect of the whole set, or is the aggregation acceptable since
the modifications are so small?
nothing was broken in the previous implementation given that an external
environment image existed, so the patch is not a fix but just improves
the existing board support -- except for the builtin 'rootpath' spec
which was incorrectly terminated and shadowed the 'netdev' spec, while
both variables only apply to network boot which isn't the default
configuration and exclusively relates to development support
diff --git a/board/ifm/ac14xx/ac14xx.c b/board/ifm/ac14xx/ac14xx.c
index 7442591..e47f63d 100644
--- a/board/ifm/ac14xx/ac14xx.c
+++ b/board/ifm/ac14xx/ac14xx.c
@@ -23,6 +23,10 @@
#include i2c.h
#endif
+static int eeprom_diag;
+static int mac_diag;
+static int gpio_diag;
+
DECLARE_GLOBAL_DATA_PTR;
static void gpio_configure(void)
@@ -37,7 +41,7 @@ static void gpio_configure(void)
/*
* out_be32(gpioregs-gpdir, 0xC2293020);
-* workaround for a hardware affect: configure direction in pieces,
+* workaround for a hardware effect: configure direction in pieces,
* setting all outputs at once drops the reset line too low and
* makes us lose the MII connection (breaks ethernet for us)
*/
@@ -126,8 +130,6 @@ static u32 gpio_querykbd(void)
/* excerpt from the recovery's hw_info.h */
-static int eeprom_diag = 1;
-
struct __attribute__ ((__packed__)) eeprom_layout {
charmagic[3]; /** 'ifm' */
u8 len[2]; /** content length without magic/len fields */
@@ -230,8 +232,8 @@ int mac_read_from_eeprom(void)
if (mac is_valid_ether_addr(mac)) {
eth_setenv_enetaddr(ethaddr, mac);
- printf(DIAG: %s() MAC value [%s]\n,
- __func__, getenv(ethaddr));
+ if (mac_diag)
+ printf(DIAG: MAC [%s]\n, getenv(ethaddr));
}
return 0;
@@ -326,42 +328,38 @@ int misc_init_r(void)
gpio_configure();
/*
-* check the GPIO keyboard,
-* enforced start of the recovery when
+* enforce the start of the recovery system when
* - the appropriate keys were pressed
-* - a previous installation was aborted or has failed
* - some external software told us to
+* - a previous installation was aborted or has failed
*/
want_recovery = 0;
keys = gpio_querykbd();
- printf(GPIO keyboard status [0x%08X]\n, keys);
- /* XXX insist in the _exact_ combination? */
+ if (gpio_diag)
+ printf(GPIO keyboard status [0x%02X]\n, keys);
if ((keys GPIOKEY_BITS_RECOVERY) == GPIOKEY_BITS_RECOVERY) {
- printf(GPIO keyboard requested RECOVERY\n);
- /* XXX TODO
-* refine the logic to detect the first keypress, and
-* wait to recheck IF it was the recovery combination?
-*/
+ printf(detected recovery request (keyboard)\n);
want_recovery = 1;
}
- s = getenv(install_in_progress);
+ s = getenv(want_recovery);
if ((s != NULL) (*s != '\0')) {
- printf(previous installation aborted, running RECOVERY\n);
+ printf(detected recovery request (environment)\n);
want_recovery = 1;
}
- s = getenv(install_failed);
+ s = getenv(install_in_progress);
if ((s != NULL) (*s != '\0')) {
- printf(previous installation FAILED, running RECOVERY\n);
+ printf(previous installation has not completed\n);
want_recovery = 1;
}
- s = getenv(want_recovery);
+ s = getenv(install_failed);
if ((s != NULL) (*s != '\0')) {
- printf(running RECOVERY according to the request\n);
+ printf(previous installation has failed\n);
want_recovery = 1;
}
-
- if (want_recovery)
+ if
[U-Boot] [PATCH V3] mmc: omap_hsmmc: add mmc1 pbias, ldo1
From: Balaji T K balaj...@ti.com
add dra mmc pbias support and ldo1 power on
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
Changes since V2:
* Addressed comments from lpo...@mm-sol.com
* Rebased on top of
http://patchwork.ozlabs.org/patch/244103/
arch/arm/include/asm/arch-omap5/omap.h |2 +-
drivers/mmc/omap_hsmmc.c | 26 ++
drivers/power/palmas.c | 25 -
include/configs/omap5_common.h |4
include/configs/omap5_uevm.h |5 -
include/palmas.h |8 +++-
6 files changed, 50 insertions(+), 20 deletions(-)
diff --git a/arch/arm/include/asm/arch-omap5/omap.h
b/arch/arm/include/asm/arch-omap5/omap.h
index 8105c14..1076494 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -106,9 +106,9 @@
/* CONTROL_EFUSE_2 */
#define CONTROL_EFUSE_2_NMOS_PMOS_PTV_CODE_1 0x00ffc000
+#define SDCARD_BIAS_PWRDNZ (1 27)
#define SDCARD_PWRDNZ (1 26)
#define SDCARD_BIAS_HIZ_MODE (1 25)
-#define SDCARD_BIAS_PWRDNZ (1 22)
#define SDCARD_PBIASLITE_VMODE (1 21)
#ifndef __ASSEMBLY__
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index afdfa88..3d3281e 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -113,23 +113,25 @@ static void omap5_pbias_config(struct mmc *mmc)
u32 value = 0;
value = readl((*ctrl)-control_pbias);
- value = ~(SDCARD_PWRDNZ | SDCARD_BIAS_PWRDNZ);
- value |= SDCARD_BIAS_HIZ_MODE;
+ value = ~SDCARD_PWRDNZ;
+ writel(value, (*ctrl)-control_pbias);
+ udelay(10); /* wait 10 us */
+ value = ~SDCARD_BIAS_PWRDNZ;
writel(value, (*ctrl)-control_pbias);
- palmas_mmc1_poweron_ldo();
+#if defined(CONFIG_DRA7XX)
+ tps659038_mmc1_poweron_ldo1();
+#else
+ palmas_mmc1_poweron_ldo9();
+#endif
value = readl((*ctrl)-control_pbias);
- value = ~SDCARD_BIAS_HIZ_MODE;
- value |= SDCARD_PBIASLITE_VMODE | SDCARD_PWRDNZ | SDCARD_BIAS_PWRDNZ;
+ value |= SDCARD_BIAS_PWRDNZ;
writel(value, (*ctrl)-control_pbias);
-
- value = readl((*ctrl)-control_pbias);
- if (value (1 23)) {
- value = ~(SDCARD_PWRDNZ | SDCARD_BIAS_PWRDNZ);
- value |= SDCARD_BIAS_HIZ_MODE;
- writel(value, (*ctrl)-control_pbias);
- }
+ udelay(150); /* wait 150 us */
+ value |= SDCARD_PWRDNZ;
+ writel(value, (*ctrl)-control_pbias);
+ udelay(150); /* wait 150 us */
}
#endif
diff --git a/drivers/power/palmas.c b/drivers/power/palmas.c
index 1f9bd7e..b94ed5d 100644
--- a/drivers/power/palmas.c
+++ b/drivers/power/palmas.c
@@ -37,7 +37,7 @@ void palmas_init_settings(void)
#endif
}
-int palmas_mmc1_poweron_ldo(void)
+int palmas_mmc1_poweron_ldo9(void)
{
u8 val = 0;
@@ -56,6 +56,29 @@ int palmas_mmc1_poweron_ldo(void)
return 0;
}
+int tps659038_mmc1_poweron_ldo1(void)
+{
+ u8 val = 0;
+
+ /* set LDO1 to 3V */
+ val = LDO_VOLT_3V0;
+
+ if (palmas_i2c_write_u8(TPS659038_CHIP_P1, LDO1_VOLTAGE, val)) {
+ printf(tps659038: could not set LDO1 voltage\n);
+ return 1;
+ }
+
+ /* TURN ON LDO1 */
+ val = RSC_MODE_SLEEP | RSC_MODE_ACTIVE;
+
+ if (palmas_i2c_write_u8(TPS659038_CHIP_P1, LDO1_CTRL, val)) {
+ printf(tps659038: could not turn on LDO1\n);
+ return 1;
+ }
+
+ return 0;
+}
+
/*
* On some hardware the SD card socket and LDO9_IN are powered by an
* external 3.3 V regulator, while the output of LDO9 delivers VDDS_SDCARD
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index 83b91d1..ddf2ad4 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -238,6 +238,10 @@
#define CONFIG_SYS_DEFAULT_LPDDR2_TIMINGS
#endif
+#ifndef CONFIG_SPL_BUILD
+#define CONFIG_PALMAS_POWER
+#endif
+
/* Defines for SPL */
#define CONFIG_SPL
#define CONFIG_SPL_FRAMEWORK
diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h
index ba81e30..f4a2d31 100644
--- a/include/configs/omap5_uevm.h
+++ b/include/configs/omap5_uevm.h
@@ -39,11 +39,6 @@
#define CONFIG_SYS_NS16550_COM3UART3_BASE
#define CONFIG_BAUDRATE115200
-/* TWL6035 */
-#ifndef CONFIG_SPL_BUILD
-#define CONFIG_PALMAS_POWER
-#endif
-
/* MMC ENV related defines */
#define CONFIG_ENV_IS_IN_MMC
#define CONFIG_SYS_MMC_ENV_DEV 1 /* SLOT2: eMMC(1) */
diff --git a/include/palmas.h b/include/palmas.h
index 7becb97..2355801 100644
--- a/include/palmas.h
+++ b/include/palmas.h
@@ -30,9 +30,14 @@
#define PALMAS_CHIP_P1 0x48
Re: [U-Boot] [PATCH v2] Add support for Wandboard quad.
Dear Otavio, In message cap9odkonqm3qleryobrgvgfqwdrt+2epfk+mbeczewdhjq6...@mail.gmail.com you wrote: Please do NOT use these terrible SZ_* defines. Never, ever. They are dangerous and should be avoided. Do you mind to explain why? Well, what does SZ_1M mean? Is it 1000 * 1000 (as on hard disk drives) or 1000 * 1024 (as on floppy disks) or 1024 * 1024 (as for memory sizes)? Instead of just seeing at first look what the code does, you have to look up the actual define, i. e. it obfuscates the code instead of being helpful. This has been discussed several times before on the list; see for example [1] or [2]. [1] http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/67552/focus=67575 [2] http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/93425 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 I paid too much for it, but its worth it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: Complete the pin definitions for the i.MX6DL / i.MX6Solo
Hi Pierre, On 18/04/2013 13:57, Pierre Aubert wrote: Signed-off-by: Pierre Aubert p.aub...@staubli.com CC: Stefano Babic sba...@denx.de --- Patch needs a rebased to be merge. Could you repost them (also 2/2) after rebasing on current u-boot-imx ? Thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/1] mpc512x: adjust and improve AC14xx board support
Dear Gerhard, In message 1370257851-27583-1-git-send-email-...@denx.de you wrote: + if (mac_diag) + printf(DIAG: MAC [%s]\n, getenv(ethaddr)); What happens if ethaddr is not defined in the environment? ... + rootpath=/opt/eldk/ppc_6xx\0 \ You are really still using ELDK 4.x ? 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] [PATCH v1 1/1] mpc512x: adjust and improve AC14xx board support
Hi Gerhard,
On 03/06/2013 13:10, Gerhard Sittig wrote:
- s = getenv(install_in_progress);
+ s = getenv(want_recovery);
if ((s != NULL) (*s != '\0')) {
- printf(previous installation aborted, running RECOVERY\n);
+ printf(detected recovery request (environment)\n);
want_recovery = 1;
}
- s = getenv(install_failed);
+ s = getenv(install_in_progress);
if ((s != NULL) (*s != '\0')) {
- printf(previous installation FAILED, running RECOVERY\n);
+ printf(previous installation has not completed\n);
want_recovery = 1;
}
- s = getenv(want_recovery);
+ s = getenv(install_failed);
I am asking myself if it is strictly required to have multiple variables
to identify if the recovery script must be run or not. If a previous
install was interrupted (install_in_progress
), or a request was initiated (want recovery) or the last installation
failed, is not so important. In all cases you set the want_recovery flag
and starts the script. But using multiple variables it is not atomic,
and could be, due for example to a system reset, that a variable is set
without clearing the other one.
Why is not better to set a single variable, maybe with multiple values ?
Value could be a simple integer (0=no recovery,
1=install_in_progress,,..) or still a string, if you prefer this solution.
- rootpath=/opt/eldk/ppc_6xx\n \
+ rootpath=/opt/eldk/ppc_6xx\0 \
We do not set IP addresses or fix rootpath. Someone could have installed
the rootfs on NFS on a different path. Also, IMHO rootpath should be
simply removed.
Best regards,
Stefano
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/1] mpc512x: adjust and improve AC14xx board support
On Mon, Jun 03, 2013 at 15:07 +0200, Wolfgang Denk wrote: In message 1370257851-27583-1-git-send-email-...@denx.de you wrote: + if (mac_diag) + printf(DIAG: MAC [%s]\n, getenv(ethaddr)); What happens if ethaddr is not defined in the environment? The context is the mac_read_from_eeprom() routine, and the getenv() call for the message is immediately preceeded by a setenv() call. Right, the lookup may fail if the setup failed as well. That's a yet uncaught followup failure. Will include an improved check in v2 of the patch. ... + rootpath=/opt/eldk/ppc_6xx\0 \ You are really still using ELDK 4.x ? In this specific project? Yes! Although development setups used to run with both 4.2 and 5.3 here for some time, the evaluation hasn't comleted yet, so the final switch wasn't made so far. I'll look into what else is involved in the ELDK-5 switch (using a mere symlink here from under /opt/eldk/ppc_6xx-sign to /opt/eldk-5.3/powerpc/rootfs-*), although /opt/eldk itself may perfectly legally be a symlink to /opt/eldk-5.3 for those setups which want to switch back and forth. Wasn't this the usual approach before ELDK-5? Somehow I'm reluctant to encode the ELDK version into the binary, hmm ... virtually yours Gerhard Sittig -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] lcd: align bmp header when uncopmressing image
When compressed image is loaded, it must be decompressed
to an aligned address + 2 to avoid unaligned access exception
on some ARM platforms.
Signed-off-by: Piotr Wilczek p.wilc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Anatolij Gustschin ag...@denx.de
CC: Wolfgang Denk w...@denx.de
---
Changes for V2:
- add additional space for uncompressed bmp header due to alignment requirements
- fix to 32-bit-aligned-address + 2 alignent
common/cmd_bmp.c | 42 --
include/lcd.h|3 ++-
2 files changed, 30 insertions(+), 15 deletions(-)
diff --git a/common/cmd_bmp.c b/common/cmd_bmp.c
index 5a52edd..06634b2 100644
--- a/common/cmd_bmp.c
+++ b/common/cmd_bmp.c
@@ -38,14 +38,19 @@ static int bmp_info (ulong addr);
/*
* Allocate and decompress a BMP image using gunzip().
*
- * Returns a pointer to the decompressed image data. Must be freed by
- * the caller after use.
+ * Returns a pointer to the decompressed image data. This pointer is
+ * is aligned to 32-bit-aligned-address + 2.
+ * See doc/README.displaying-bmps for explanation.
+ *
+ * The allocation address is passed to 'alloc_addr' and must be freed
+ * by the caller after use.
*
* Returns NULL if decompression failed, or if the decompressed data
* didn't contain a valid BMP signature.
*/
#ifdef CONFIG_VIDEO_BMP_GZIP
-bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp)
+bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp,
+ void **alloc_addr)
{
void *dst;
unsigned long len;
@@ -55,12 +60,19 @@ bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long
*lenp)
* Decompress bmp image
*/
len = CONFIG_SYS_VIDEO_LOGO_MAX_SIZE;
- dst = malloc(CONFIG_SYS_VIDEO_LOGO_MAX_SIZE);
+ dst = malloc(CONFIG_SYS_VIDEO_LOGO_MAX_SIZE + 0x04);
if (dst == NULL) {
puts(Error: malloc in gunzip failed!\n);
return NULL;
}
- if (gunzip(dst, CONFIG_SYS_VIDEO_LOGO_MAX_SIZE, (uchar *)addr, len) !=
0) {
+
+ bmp = dst;
+
+ /* align to 32-bit-aligned-address + 2 */
+ if ((unsigned int)bmp % 0x04 != 0x02)
+ bmp = (bmp_image_t *)unsigned int)dst + 0x2) ~0x1) | 0x2);
+
+ if (gunzip(bmp, CONFIG_SYS_VIDEO_LOGO_MAX_SIZE, (uchar *)addr, len) !=
0) {
free(dst);
return NULL;
}
@@ -68,8 +80,6 @@ bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long
*lenp)
puts(Image could be truncated
(increase
CONFIG_SYS_VIDEO_LOGO_MAX_SIZE)!\n);
- bmp = dst;
-
/*
* Check for bmp mark 'BM'
*/
@@ -81,10 +91,12 @@ bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long
*lenp)
debug(Gzipped BMP image detected!\n);
+ *alloc_addr = dst;
return bmp;
}
#else
-bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp)
+bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp,
+ void **alloc_addr)
{
return NULL;
}
@@ -189,11 +201,12 @@ U_BOOT_CMD(
static int bmp_info(ulong addr)
{
bmp_image_t *bmp=(bmp_image_t *)addr;
+ void *bmp_alloc_addr = NULL;
unsigned long len;
if (!((bmp-header.signature[0]=='B')
(bmp-header.signature[1]=='M')))
- bmp = gunzip_bmp(addr, len);
+ bmp = gunzip_bmp(addr, len, bmp_alloc_addr);
if (bmp == NULL) {
printf(There is no valid bmp file at the given address\n);
@@ -205,8 +218,8 @@ static int bmp_info(ulong addr)
printf(Bits per pixel: %d\n, le16_to_cpu(bmp-header.bit_count));
printf(Compression : %d\n, le32_to_cpu(bmp-header.compression));
- if ((unsigned long)bmp != addr)
- free(bmp);
+ if (bmp_alloc_addr)
+ free(bmp_alloc_addr);
return(0);
}
@@ -225,11 +238,12 @@ int bmp_display(ulong addr, int x, int y)
{
int ret;
bmp_image_t *bmp = (bmp_image_t *)addr;
+ void *bmp_alloc_addr = NULL;
unsigned long len;
if (!((bmp-header.signature[0]=='B')
(bmp-header.signature[1]=='M')))
- bmp = gunzip_bmp(addr, len);
+ bmp = gunzip_bmp(addr, len, bmp_alloc_addr);
if (!bmp) {
printf(There is no valid bmp file at the given address\n);
@@ -244,8 +258,8 @@ int bmp_display(ulong addr, int x, int y)
# error bmp_display() requires CONFIG_LCD or CONFIG_VIDEO
#endif
- if ((unsigned long)bmp != addr)
- free(bmp);
+ if (bmp_alloc_addr)
+ free(bmp_alloc_addr);
return ret;
}
diff --git a/include/lcd.h b/include/lcd.h
index c6e7fc5..482e606 100644
--- a/include/lcd.h
+++ b/include/lcd.h
@@ -46,7 +46,8 @@ void lcd_initcolregs(void);
int lcd_getfgcolor(void);
/* gunzip_bmp used if CONFIG_VIDEO_BMP_GZIP
Re: [U-Boot] [PATCH] lcd: align bmp header when uncopmressing image
Dear Wolfgang Denk, -Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Monday, June 03, 2013 1:16 PM To: Piotr Wilczek Cc: u-boot@lists.denx.de; 'Minkyu Kang'; 'Kyungmin Park'; Lukasz Majewski; 'Anatolij Gustschin' Subject: Re: [PATCH] lcd: align bmp header when uncopmressing image Dear Piotr Wilczek, In message 000601ce6021$fcb8f490$f62addb0$%wilc...@samsung.com you wrote: If you do this, you must also account for the up to 2 additional bytes needed in the allocated buffer. Otherwise you might write over the end of the buffer... Because 8-byte alignment is guaranteed by malloc I don't think might over write anything when moving by only 2 bytes. Oops??? Initial alignment has NOTHING to do with writing over the allocated end of memory! No, I meant only that malloc allocates memory in at least 4-byte resolution. I surely should have allocated extra memory for the aligned header in the first patch. Please see my fixed patch. Best regards, Piotr Wilczek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/1] mpc512x: adjust and improve AC14xx board support
On Mon, Jun 03, 2013 at 15:31 +0200, Stefano Babic wrote:
On 03/06/2013 13:10, Gerhard Sittig wrote:
- s = getenv(install_in_progress);
+ s = getenv(want_recovery);
if ((s != NULL) (*s != '\0')) {
- printf(previous installation aborted, running RECOVERY\n);
+ printf(detected recovery request (environment)\n);
want_recovery = 1;
}
- s = getenv(install_failed);
+ s = getenv(install_in_progress);
if ((s != NULL) (*s != '\0')) {
- printf(previous installation FAILED, running RECOVERY\n);
+ printf(previous installation has not completed\n);
want_recovery = 1;
}
- s = getenv(want_recovery);
+ s = getenv(install_failed);
I am asking myself if it is strictly required to have multiple variables
to identify if the recovery script must be run or not. If a previous
install was interrupted (install_in_progress
), or a request was initiated (want recovery) or the last installation
failed, is not so important. In all cases you set the want_recovery flag
and starts the script. But using multiple variables it is not atomic,
and could be, due for example to a system reset, that a variable is set
without clearing the other one.
Why is not better to set a single variable, maybe with multiple values ?
Value could be a simple integer (0=no recovery,
1=install_in_progress,,..) or still a string, if you prefer this solution.
Quick answer: holy compatibility with shipped products on one
hand, and simplicity on the initiators' sides on the other hand.
The full answer is more involved than one may think at first
glance, as usual. :)
There are at least three (or four depending on how you count it)
parties involved: The installer within the recovery system, the
user in front of the product, and the regular application
software including potential remote access (all of them are
initiators, and the bootloader (who is trying to help or to
mediate between the former).
Some requests are carried out willingly (the user's pressing
keys, the regular product software's or the remote access'
wanting to enter maintenance mode), others are not so much of a
willingly initiated request but instead mere consequence of
failure (the installer's not being able to finish or to succeed).
Some requests are done interactively in a moment (the user's
pressing buttons during power on), others get queued and acted
upon at any random later point in time (scheduling to enter
maintenance mode but not before the next reboot). Notice also
that the three parts (boot loader, recovery system, product
software) may get developed and maintained by individual teams or
under differing circumstances (regarding the targetted set of
feature or supported complexity, differing schedules for releases
or updates, maybe even locks or freezes after first shipping).
The current approach is appropriate because you don't have to
coordinate the individual initiators, they don't have to agree on
one common way of expressing their request, they don't even have
to know about each other.
The evaluation of reasons in the boot loader is simple and
straight forward and just errs to the safe side. The evaluation
may look redundant yet the cost is acceptable and the complexity
is rather low (totally cheap, mere OR, nothing else involved when
you ignore the diagnostics).
Any pending reason will make the product enter maintenance mode,
and not change any of the information which led there.
Processing the interactive request upon key press or remote
support intervention won't clobber the information about
potentially incomplete or failed installation attempts. Error
conditions will stick as long as they apply, without further
logic needed. The product keeps nagging and enforces that a
working status gets established (software gets installed,
completely and successfully verified please), while additional
manual intervention is possible as the need arises (one time
access to the recovery system, not voiding any of the other
information which may apply).
I feel that this is a good thing, simple to explain and to
understand (once you know the motivation), and to test and to
verify, and to maintain and support.
Introducing a uniform way of carrying the start recovery mode,
please request interestingly increases complexity, you need to
coordinate all the initiators. Having the one variable hold only
one reason for the request opens a new area of unwanted
interaction, having the variable hold multiple reasons introduces
complex manipulation activities and may make you need to update
all initiators when the logic changes or gets extended.
Manipulating the variable instead of just setting or deleting it
may introduce atomicity issues, unless you add complexity by
adding locking (which all participants have to agree upon and
respect).
So I see the desire to reduce the redundancy, but I'm afraid that
this comes at the cost of increased
Re: [U-Boot] [PATCH] fdt: allow bootdelay to be specified via device tree
On 06/02/2013 06:44 AM, Gerald Van Baren wrote: Hi Stephen, On 06/02/2013 01:24 AM, Stephen Warren wrote: On 05/14/2013 12:02 PM, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com This can be useful to force bootcmd to execute as soon as U-Boot has started. My use-case is: An SoC-specific tool pushes U-Boot into RAM, along with an image to be written to device boot flash, with the DT config property bootcmd set to contain a command to write that image to flash. In this scenario, we don't want to allow any stale bootdelay value taken from the current flash content to affect how long it takes before the flashing process starts. Jerry, does this patch look OK, or do you have comments on it? Thanks. I'm good with the patch. Acked-by: Gerald Van Baren vanba...@cideas.com Oh, I'm not sure who you're expecting to apply this then; I assume since it was a DT-related feature it'd be applied to your DT tree. Are you expecting Tom Rini to apply it to the main U-Boot repo? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add splash screen support via loading from flash
Hello Stefano
On Mon, Jun 3, 2013 at 12:44 AM, Stefano Babic sba...@denx.de wrote:
Hi Robert,
On 30/05/2013 23:03, Robert Winkler wrote:
Signed-off-by: Robert Winkler robert.wink...@boundarydevices.com
---
board/boundary/nitrogen6x/nitrogen6x.c | 22 ++
include/configs/nitrogen6x.h | 11 ++-
2 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/board/boundary/nitrogen6x/nitrogen6x.c
b/board/boundary/nitrogen6x/nitrogen6x.c
index 3b228cf..648b877 100644
--- a/board/boundary/nitrogen6x/nitrogen6x.c
+++ b/board/boundary/nitrogen6x/nitrogen6x.c
@@ -401,6 +401,24 @@ int board_eth_init(bd_t *bis)
return 0;
}
+
+void splash_screen_prepare(void)
+{
+ char *env_loadsplash;
+
+ if (!getenv(splashimage) || !getenv(splashsize))
+ return;
+
+ env_loadsplash = getenv(loadsplash);
+ if (!env_loadsplash) {
+ printf(Environment variable loadsplash not found!\n);
+ return;
+ }
+
+ if (run_command_list(env_loadsplash, -1, 0))
+ printf(failed to run loadsplash %s\n\n, env_loadsplash);
+}
+
Which is the advantage instead of using the preboot variable setting
CONFIG_PREBOOT ? It does pretty the same and you can move the whole
script outside of board code.
The preboot command is run too late. It looks like it is run in
main_loop but U-Boot looks for the splash image
at the address in the splashimage variable in board_init_r -
stdio_init - drv_lcd_init or drv_video_init (depending on
whether you have CONFIG_LCD or CONFIG_VIDEO).
I have a patch ready that will fix the underlying problem with
CONFIG_SPLASH_SCREEN_PREPARE not working
for CONFIG_VIDEO so the nitrogen specific code (in a separate patch of
course) will change to use the provided callback instead of just
calling it in our own board_video_skip, but other than that it'll be
the same as the patch I already submitted.
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
Thanks,
Robert Winkler
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fdt: allow bootdelay to be specified via device tree
On 06/03/2013 11:05 AM, Stephen Warren wrote: On 06/02/2013 06:44 AM, Gerald Van Baren wrote: Hi Stephen, On 06/02/2013 01:24 AM, Stephen Warren wrote: On 05/14/2013 12:02 PM, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com This can be useful to force bootcmd to execute as soon as U-Boot has started. My use-case is: An SoC-specific tool pushes U-Boot into RAM, along with an image to be written to device boot flash, with the DT config property bootcmd set to contain a command to write that image to flash. In this scenario, we don't want to allow any stale bootdelay value taken from the current flash content to affect how long it takes before the flashing process starts. Jerry, does this patch look OK, or do you have comments on it? Thanks. I'm good with the patch. Acked-by: Gerald Van Baren vanba...@cideas.com Oh, I'm not sure who you're expecting to apply this then; I assume since it was a DT-related feature it'd be applied to your DT tree. Are you expecting Tom Rini to apply it to the main U-Boot repo? Ahh, one of those fuzzy gray areas... the patch is to main.c, I mostly focus on files in the libfdt subdirectory. I can apply it via the FDT repo. Tom Rini, do you have any preference? The merge window closed May 11 and the original patch was emailed on May 14... is it a candidate to go into the July 15 release? It is a simple patch arguably fixing a bug, but it did miss the window. Thanks, gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] video:lcd:cfb_console: cm_t35: Add CONFIG_SPLASH_SCREEN_PREPARE support to CONFIG_VIDEO
Also change splash_screen_prepare to a weak function.
Signed-off-by: Robert Winkler robert.wink...@boundarydevices.com
---
board/compulab/cm_t35/cm_t35.c | 2 +-
common/lcd.c | 10 --
drivers/video/cfb_console.c| 14 ++
3 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/board/compulab/cm_t35/cm_t35.c b/board/compulab/cm_t35/cm_t35.c
index b0b80e5..95098af 100644
--- a/board/compulab/cm_t35/cm_t35.c
+++ b/board/compulab/cm_t35/cm_t35.c
@@ -120,7 +120,7 @@ static inline int splash_load_from_nand(void)
}
#endif /* CONFIG_CMD_NAND */
-int board_splash_screen_prepare(void)
+int splash_screen_prepare(void)
{
char *env_splashimage_value;
u32 bmp_load_addr;
diff --git a/common/lcd.c b/common/lcd.c
index edae835..90f1143 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -1069,15 +1069,13 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
#endif
#ifdef CONFIG_SPLASH_SCREEN_PREPARE
-static inline int splash_screen_prepare(void)
-{
- return board_splash_screen_prepare();
-}
-#else
-static inline int splash_screen_prepare(void)
+int __splash_screen_prepare(void)
{
return 0;
}
+
+int splash_screen_prepare(void)
+ __attribute__ ((weak, alias(__splash_screen_prepare)));
#endif
static void *lcd_logo(void)
diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
index 0793f07..9180998 100644
--- a/drivers/video/cfb_console.c
+++ b/drivers/video/cfb_console.c
@@ -1966,6 +1966,16 @@ static void plot_logo_or_black(void *screen, int width,
int x, int y, int black)
#endif
}
+#ifdef CONFIG_SPLASH_SCREEN_PREPARE
+int __splash_screen_prepare(void)
+{
+ return 0;
+}
+
+int splash_screen_prepare(void)
+ __attribute__ ((weak, alias(__splash_screen_prepare)));
+#endif
+
static void *video_logo(void)
{
char info[128];
@@ -1996,6 +2006,10 @@ static void *video_logo(void)
s = getenv(splashimage);
if (s != NULL) {
+#ifdef CONFIG_SPLASH_SCREEN_PREPARE
+ splash_screen_prepare();
+#endif
+
addr = simple_strtoul(s, NULL, 16);
--
1.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 04/10] SPI: Add Orion SPI driver
Dear Jagan, Jagan Teki jagannadh.t...@gmail.com writes: Does this tested on hw, please re-base the tree and send the next version patch. Let me know if it ok to review under current tree. I'd appreciate a review of the latest patch [1,2]. There have been no changes in master to the files touched by the patch since I sent it. After rebasing the entire series on today's master (d6639d1) I've successfully verified SPI flash functionality on CuBox Pro. Sascha [1] mid:1369593423-19763-6-git-send-email-t-ub...@infra-silbe.de [2] http://patchwork.ozlabs.org/patch/246468/ pgpWOycwgx9zs.pgp Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 04/10] SPI: Add Orion SPI driver
On Mon, Jun 3, 2013 at 11:01 PM, Sascha Silbe t-ub...@infra-silbe.de wrote: Dear Jagan, Jagan Teki jagannadh.t...@gmail.com writes: Does this tested on hw, please re-base the tree and send the next version patch. Let me know if it ok to review under current tree. I'd appreciate a review of the latest patch [1,2]. There have been no changes in master to the files touched by the patch since I sent it. After rebasing the entire series on today's master (d6639d1) I've successfully verified SPI flash functionality on CuBox Pro. Sascha [1] mid:1369593423-19763-6-git-send-email-t-ub...@infra-silbe.de [2] http://patchwork.ozlabs.org/patch/246468/ Thank you, means this v4 is the latest one? http://patchwork.ozlabs.org/patch/246468/ -- Thanks, Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Add SPI Flash STMicro's N25Q512A add flag status check during SPI Flash write
Hi,
I've made two changes while I was working on STMidro's SPI Flash N25Q512A
- add the device entry for STMidro's SPI Flash N25Q512A
- add Flag status check during
Without this flag checking sf write will fail and SPI flash is locked
up
Please see the patch and let me know your feedback.
-
From 97572b32c49d06ca6f8548ed88e6e381fb719a08 Mon Sep 17 00:00:00 2001
From: Insop Song insop.s...@cohere.net
Date: Sun, 2 Jun 2013 13:33:37 -0700
Subject: [PATCH] Add SPI Flash STMicro's N25Q512A add flag status check
during SPI Flash write
Signed-off-by: Insop Song insop.s...@cohere.net
---
drivers/mtd/spi/spi_flash.c | 25 +
drivers/mtd/spi/spi_flash_internal.h |1 +
drivers/mtd/spi/stmicro.c|6 ++
3 files changed, 32 insertions(+)
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 00aece9..f53756d 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -72,6 +72,7 @@ int spi_flash_cmd_write_multi(struct spi_flash *flash, u32
offset,
size_t chunk_len, actual;
int ret;
u8 cmd[4];
+ u8 flag_status;
page_size = flash-page_size;
page_addr = offset / page_size;
@@ -83,6 +84,18 @@ int spi_flash_cmd_write_multi(struct spi_flash *flash, u32
offset,
return ret;
}
+wait_flag:
+ ret = spi_flash_cmd(flash-spi, CMD_READ_FLAG_STATUS, flag_status,
sizeof(flag_status));
+ if (ret 0) {
+ printf(SF: reading flag failed\n);
+ return ret;
+ }
+ debug(flag_status %d\n, flag_status);
+ if ((flag_status 0x80) == 0) {
+ udelay(10);
+ goto wait_flag;
+ }
+
cmd[0] = CMD_PAGE_PROGRAM;
for (actual = 0; actual len; actual += chunk_len) {
chunk_len = min(len - actual, page_size - byte_addr);
@@ -106,6 +119,18 @@ int spi_flash_cmd_write_multi(struct spi_flash *flash, u32
offset,
debug(SF: write failed\n);
break;
}
+ /* check status */
+flag_check:
+ ret = spi_flash_cmd(flash-spi, CMD_READ_FLAG_STATUS,
flag_status, sizeof(flag_status));
+ if (ret 0) {
+ printf(SF: reading flag failed\n);
+ break;
+ }
+ debug(flag_status %d\n, flag_status);
+ if (!(flag_status 0x80)) {
+ udelay(100);
+ goto flag_check;
+ }
ret = spi_flash_cmd_wait_ready(flash, SPI_FLASH_PROG_TIMEOUT);
if (ret)
diff --git a/drivers/mtd/spi/spi_flash_internal.h
b/drivers/mtd/spi/spi_flash_internal.h
index 141cfa8..90b6993 100644
--- a/drivers/mtd/spi/spi_flash_internal.h
+++ b/drivers/mtd/spi/spi_flash_internal.h
@@ -22,6 +22,7 @@
#define CMD_PAGE_PROGRAM 0x02
#define CMD_WRITE_DISABLE 0x04
#define CMD_READ_STATUS0x05
+#define CMD_READ_FLAG_STATUS 0x70
#define CMD_WRITE_ENABLE 0x06
#define CMD_ERASE_4K 0x20
#define CMD_ERASE_32K 0x52
diff --git a/drivers/mtd/spi/stmicro.c b/drivers/mtd/spi/stmicro.c
index 30b626a..ad94ad2 100644
--- a/drivers/mtd/spi/stmicro.c
+++ b/drivers/mtd/spi/stmicro.c
@@ -110,6 +110,12 @@ static const struct stmicro_spi_flash_params
stmicro_spi_flash_table[] = {
.nr_sectors = 512,
.name = N25Q256,
},
+ {
+ .id = 0xba20,
+ .pages_per_sector = 256,
+ .nr_sectors = 1024,
+ .name = N25Q512A,
+ },
};
struct spi_flash *spi_flash_probe_stmicro(struct spi_slave *spi, u8 * idcode)
--
1.7.9.5
0001-Add-SPI-Flash-STMicro-s-N25Q512A-add-flag-status-che.patch
Description: 0001-Add-SPI-Flash-STMicro-s-N25Q512A-add-flag-status-che.patch
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 04/10] SPI: Add Orion SPI driver
Dear Jagan, Jagan Teki jagannadh.t...@gmail.com writes: I'd appreciate a review of the latest patch [1,2]. [...] [1] mid:1369593423-19763-6-git-send-email-t-ub...@infra-silbe.de [2] http://patchwork.ozlabs.org/patch/246468/ Thank you, means this v4 is the latest one? http://patchwork.ozlabs.org/patch/246468/ Yes, it is. Sascha pgpgMrapTfTCb.pgp Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/1] mpc512x: adjust and improve AC14xx board support
Dear Gerhard Sittig, In message 20130603135004.gh2...@book.gsilab.sittig.org you wrote: + if (mac_diag) + printf(DIAG: MAC [%s]\n, getenv(ethaddr)); What happens if ethaddr is not defined in the environment? The context is the mac_read_from_eeprom() routine, and the getenv() call for the message is immediately preceeded by a setenv() call. ...which, as everything, can fail for a number of reasons. It is utterly wrong to rely on results of any previous actions and assume that nothing can go wrong. Murphy will teach you. + rootpath=/opt/eldk/ppc_6xx\0 \ You are really still using ELDK 4.x ? In this specific project? Yes! Although development setups used to run with both 4.2 and 5.3 here for some time, the evaluation hasn't comleted yet, so the final switch wasn't made so far. ...which makes clear that setting such variables in the default config is of questionable value. 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 By the way, ALL software projects are done by iterative prototyping. Some companies call their prototypes releases, that's all. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 05/10] SPI: Add Dove SPI driver
Hi,
Looks ok to me as per coding style after a quick look.
On Mon, May 27, 2013 at 12:06 AM, Sascha Silbe t-ub...@infra-silbe.de wrote:
From: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
This adds an SPI driver for Marvell Dove SoCs. This driver is taken
from kirkwood_spi but removes mpp configuration as dove has dedicated
spi pins.
As a future clean-up step, the code for orion5x, kirkwood and dove
could be merged, with MPP configuration being be handled as part of
cpu/board-specific setup.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Signed-off-by: Sascha Silbe t-ub...@infra-silbe.de
---
v3-v4: renamed to dove, adjusted description, removed unused
variable, made checkpatch clean
drivers/spi/Makefile | 1 +
drivers/spi/dove_spi.c | 212
+
2 files changed, 213 insertions(+)
create mode 100644 drivers/spi/dove_spi.c
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index d08609e..62ad970 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -38,6 +38,7 @@ COBJS-$(CONFIG_BFIN_SPI6XX) += bfin_spi6xx.o
COBJS-$(CONFIG_CF_SPI) += cf_spi.o
COBJS-$(CONFIG_CF_QSPI) += cf_qspi.o
COBJS-$(CONFIG_DAVINCI_SPI) += davinci_spi.o
+COBJS-$(CONFIG_DOVE_SPI) += dove_spi.o
COBJS-$(CONFIG_EXYNOS_SPI) += exynos_spi.o
COBJS-$(CONFIG_ICH_SPI) += ich.o
COBJS-$(CONFIG_KIRKWOOD_SPI) += kirkwood_spi.o
diff --git a/drivers/spi/dove_spi.c b/drivers/spi/dove_spi.c
new file mode 100644
index 000..c61ba89
--- /dev/null
+++ b/drivers/spi/dove_spi.c
@@ -0,0 +1,212 @@
+/*
+ * Marvell Dove SoCs common spi driver
+ *
+ * Sebastian Hesselbarth sebastian.hesselba...@gmail.com
+ * based on kirkwood_spi.c written by
+ * Prafulla Wadaskar prafu...@marvell.com
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#include common.h
+#include malloc.h
+#include spi.h
+#include asm/io.h
+#include asm/arch/config.h
+
+/* SPI Registers on dove SOC */
+struct dovespi_registers {
+ u32 ctrl; /* 0x00 */
+ u32 cfg;/* 0x04 */
+ u32 dout; /* 0x08 */
+ u32 din;/* 0x0c */
+ u32 irq_cause; /* 0x10 */
+ u32 irq_mask; /* 0x14 */
+};
+
+#define DOVESPI_CLKPRESCL_MASK 0x1f
+#define DOVESPI_CLKPRESCL_MIN 0x12
+#define DOVESPI_CSN_ACT1 /* Activates serial memory interface */
+#define DOVESPI_SMEMRDY(1 1) /* SerMem Data xfer ready */
+#define DOVESPI_IRQUNMASK 1 /* unmask SPI interrupt */
+#define DOVESPI_IRQMASK0 /* mask SPI interrupt */
+#define DOVESPI_SMEMRDIRQ 1 /* SerMem data xfer ready irq */
+#define DOVESPI_XFERLEN_1BYTE 0
+#define DOVESPI_XFERLEN_2BYTE (1 5)
+#define DOVESPI_XFERLEN_MASK (1 5)
+#define DOVESPI_ADRLEN_1BYTE 0
+#define DOVESPI_ADRLEN_2BYTE (1 8)
+#define DOVESPI_ADRLEN_3BYTE (2 8)
+#define DOVESPI_ADRLEN_4BYTE (3 8)
+#define DOVESPI_ADRLEN_MASK(3 8)
+#define DOVESPI_TIMEOUT1
+
+static struct dovespi_registers *spireg =
+ (struct dovespi_registers *)DOVE_SPI_BASE;
+
+struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
+ unsigned int max_hz, unsigned int mode)
+{
+ struct spi_slave *slave;
+ u32 data;
+
+ if (!spi_cs_is_valid(bus, cs))
+ return NULL;
+
Done use the below tag code instead go for spi_alloc_slave()
see the sample code on drivers/spi/exynos_spi.c
--- TAG+
+ slave = malloc(sizeof(struct spi_slave));
+ if (!slave)
+ return NULL;
+
+ slave-bus = bus;
+ slave-cs = cs;
+
- TAG-
+ writel(~DOVESPI_CSN_ACT | DOVESPI_SMEMRDY, spireg-ctrl);
+
+ /* calculate spi clock prescaller using max_hz */
+ data = ((CONFIG_SYS_TCLK / 2) / max_hz) + 0x10;
+ data = data DOVESPI_CLKPRESCL_MIN ? DOVESPI_CLKPRESCL_MIN : data;
+ data = data DOVESPI_CLKPRESCL_MASK ? DOVESPI_CLKPRESCL_MASK : data;
+
+ /* program spi clock prescaller using max_hz */
+ writel(DOVESPI_ADRLEN_3BYTE | data, spireg-cfg);
+ debug(data
Re: [U-Boot] [PATCH V2] lcd: align bmp header when uncopmressing image
Dear Piotr Wilczek, In message 1370267979-17800-1-git-send-email-p.wilc...@samsung.com you wrote: When compressed image is loaded, it must be decompressed to an aligned address + 2 to avoid unaligned access exception on some ARM platforms. ... - dst = malloc(CONFIG_SYS_VIDEO_LOGO_MAX_SIZE); + dst = malloc(CONFIG_SYS_VIDEO_LOGO_MAX_SIZE + 0x04); Why + 4? This needs a comment. And please write 4 as 4, and not as 0x4 when there is no good reason for it. + /* align to 32-bit-aligned-address + 2 */ + if ((unsigned int)bmp % 0x04 != 0x02) + bmp = (bmp_image_t *)unsigned int)dst + 0x2) ~0x1) | 0x2); This is difficult to read and inefficient. If you want to do it manually, just write it as bmp = (bmp_image_t *)unsigned int)dst + 1) ~3) + 2); [Actually adding 3 to the malloc() size above would be sufficient with this]. A more readable way but slightly less efficient way might be: u32_t n = (u32_t)dst; bmp = (bmp_image_t *)(ALIGN(n, 4) + 2); 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 I've got to get something inside me. Some coffee or something. And then the world will somehow be better. - Terry Pratchett, _Men at Arms_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] Add support of IB8315 board
Dear Sergey, please do not repost patches without making clear thatthese are reposts, and without explaining _why_ you are reposting, and what has been changed. Please see http://www.denx.de/wiki/U-Boot/Patches for detail. In message 94EB659E3D5E594D80696B67540292A2F6FA7966A8@nov-exch01.astro.local you wrote: --===1618536833== Content-Language: en-US Content-Type: multipart/alternative; boundary=_000_94EB659E3D5E594D80696B67540292A2F6FA7966A8novexch01astr_ --_000_94EB659E3D5E594D80696B67540292A2F6FA7966A8novexch01astr_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable And never ever send patches as MIME attachments, always send plain text only. You want to use git format-patch and git send-email to do that. Signed-off-by: Sergey Gerasimov sergey.gerasi...@astrosoft-development.com= --- board/ib8315/Makefile| 49 +++ board/ib8315/sdram.c | 123 +++ board/ib8315/tqm8315.c | 194 +++ boards.cfg | 1 + drivers/block/fsl_sata.c | 21 ++ drivers/block/fsl_sata.h | 7 + include/configs/IB8315.h | 839 = +++ include/sata.h | 4 + Entry to MAINTAINERS missing. create mode 100644 board/ib8315/sdram.c create mode 100644 board/ib8315/tqm8315.c create mode 100644 include/configs/IB8315.h And before posting, please make sure to tun your patch through checkpatch (as explained in the docs); here we get: total: 345 errors, 479 warnings, 0 checks, 1270 lines checked These need to be fixed. Please also pay attention to correct multiline comment style. No further review done. 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 not best to swap horses while crossing the river. - Abraham Lincoln ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] lcd: align bmp header when uncopmressing image
Dear Piotr Wilczek, In message 000b01ce6064$b52a7de0$1f7f79a0$%wilc...@samsung.com you wrote: Oops??? Initial alignment has NOTHING to do with writing over the allocated end of memory! No, I meant only that malloc allocates memory in at least 4-byte resolution. Does it? I see no such guarantee in the specification. 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 No problem is insoluble. -- Dr. Janet Wallace, The Deadly Years, stardate 3479.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add SPI Flash STMicro's N25Q512A add flag status check during SPI Flash write
Hi,
Thanks for your new changes.
I don't know may be you sent these changes intentionally.
I personally not encouraging these as you sent all changes in one
patch, attached a patch series to mail and
did n't follow commit message header.
http://www.denx.de/wiki/view/U-Boot/Patches#Commit_message_conventions
On Mon, Jun 3, 2013 at 10:16 PM, Insop Song insop.s...@cohere.net wrote:
Hi,
I've made two changes while I was working on STMidro's SPI Flash N25Q512A
- add the device entry for STMidro's SPI Flash N25Q512A
- add Flag status check during
Without this flag checking sf write will fail and SPI flash is
locked up
Please see the patch and let me know your feedback.
-
From 97572b32c49d06ca6f8548ed88e6e381fb719a08 Mon Sep 17 00:00:00 2001
From: Insop Song insop.s...@cohere.net
Date: Sun, 2 Jun 2013 13:33:37 -0700
Subject: [PATCH] Add SPI Flash STMicro's N25Q512A add flag status check
during SPI Flash write
Signed-off-by: Insop Song insop.s...@cohere.net
---
drivers/mtd/spi/spi_flash.c | 25 +
drivers/mtd/spi/spi_flash_internal.h |1 +
drivers/mtd/spi/stmicro.c|6 ++
3 files changed, 32 insertions(+)
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 00aece9..f53756d 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -72,6 +72,7 @@ int spi_flash_cmd_write_multi(struct spi_flash *flash, u32
offset,
size_t chunk_len, actual;
int ret;
u8 cmd[4];
+ u8 flag_status;
page_size = flash-page_size;
page_addr = offset / page_size;
@@ -83,6 +84,18 @@ int spi_flash_cmd_write_multi(struct spi_flash *flash, u32
offset,
return ret;
}
+wait_flag:
+ ret = spi_flash_cmd(flash-spi, CMD_READ_FLAG_STATUS, flag_status,
sizeof(flag_status));
+ if (ret 0) {
+ printf(SF: reading flag failed\n);
+ return ret;
+ }
+ debug(flag_status %d\n, flag_status);
+ if ((flag_status 0x80) == 0) {
+ udelay(10);
+ goto wait_flag;
+ }
+
cmd[0] = CMD_PAGE_PROGRAM;
for (actual = 0; actual len; actual += chunk_len) {
chunk_len = min(len - actual, page_size - byte_addr);
@@ -106,6 +119,18 @@ int spi_flash_cmd_write_multi(struct spi_flash *flash,
u32 offset,
debug(SF: write failed\n);
break;
}
+ /* check status */
+flag_check:
+ ret = spi_flash_cmd(flash-spi, CMD_READ_FLAG_STATUS,
flag_status, sizeof(flag_status));
+ if (ret 0) {
+ printf(SF: reading flag failed\n);
+ break;
+ }
+ debug(flag_status %d\n, flag_status);
+ if (!(flag_status 0x80)) {
+ udelay(100);
+ goto flag_check;
+ }
Instead doing this poll on actaual write, may be do it on
spi_flash_cmd_wait_ready()
for code compatibility.
Did you tested these changes, i think the same Flag_status must
require on erase as well.
ret = spi_flash_cmd_wait_ready(flash, SPI_FLASH_PROG_TIMEOUT);
if (ret)
diff --git a/drivers/mtd/spi/spi_flash_internal.h
b/drivers/mtd/spi/spi_flash_internal.h
index 141cfa8..90b6993 100644
--- a/drivers/mtd/spi/spi_flash_internal.h
+++ b/drivers/mtd/spi/spi_flash_internal.h
@@ -22,6 +22,7 @@
#define CMD_PAGE_PROGRAM 0x02
#define CMD_WRITE_DISABLE 0x04
#define CMD_READ_STATUS0x05
+#define CMD_READ_FLAG_STATUS 0x70
#define CMD_WRITE_ENABLE 0x06
#define CMD_ERASE_4K 0x20
#define CMD_ERASE_32K 0x52
diff --git a/drivers/mtd/spi/stmicro.c b/drivers/mtd/spi/stmicro.c
index 30b626a..ad94ad2 100644
--- a/drivers/mtd/spi/stmicro.c
+++ b/drivers/mtd/spi/stmicro.c
@@ -110,6 +110,12 @@ static const struct stmicro_spi_flash_params
stmicro_spi_flash_table[] = {
.nr_sectors = 512,
.name = N25Q256,
},
+ {
+ .id = 0xba20,
This is wrong, 0xba20 is for N25Q512, 0xbb20 is for N25Q512A., agree?
Please see there is a patch available in spi bucket
http://patchwork.ozlabs.org/patch/247953/
The main agenda about this patch is trying to use same wait_poll func
which is used for
read_status register, to make code reliable and modular.
Please test the above patch http://patchwork.ozlabs.org/patch/247953/
Let me know if you have any concerns/issues.
--
Thanks,
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 04/10] SPI: Add Orion SPI driver
On 06/03/2013 07:31 PM, Sascha Silbe wrote: From: Sebastian Hesselbarth sebastian.hesselba...@gmail.com This adds an SPI driver for Marvell Dove SoCs. This driver is taken from kirkwood_spi but removes mpp configuration as dove has dedicated spi pins. As a future clean-up step, the code for orion5x, kirkwood and dove could be merged, with MPP configuration being be handled as part of cpu/board-specific setup. Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com Signed-off-by: Sascha Silbe t-ub...@infra-silbe.de --- v3-v4: renamed to dove, adjusted description, removed unused variable, made checkpatch clean Sascha, renaming it to dove_spi to obfuscate it is actually a copy of kirkwood_spi that will also work for orion5x and mv78x00 does _not_ match my intention when I posted this driver. Feel free to pick up the patches but it should remain generic for all Orion SoCs. kirkwood_spi has mpp stuff inside that is totally wrong there, move it to board setup and just rename kirkwood_spi to something more generic. Sebastian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 09/12] mmc: omap_hsmmc: add mmc1 pbias, ldo1
Hi Lokesh,
Hi Lubomir,
On Thursday 30 May 2013 07:56 PM, Lubomir Popov wrote:
Hi Lokesh,
On 30/05/13 16:19, Lokesh Vutla wrote:
From: Balaji T K balaj...@ti.com
add dra mmc pbias support and ldo1 power on
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/include/asm/arch-omap5/omap.h |3 ++-
drivers/mmc/omap_hsmmc.c | 26 ++
drivers/power/palmas.c | 25 -
include/configs/omap5_common.h |4
include/configs/omap5_uevm.h |5 -
include/palmas.h |6 +-
6 files changed, 49 insertions(+), 20 deletions(-)
[snip]
+ /* set LDO9 TWL6035 to 3V */
LDO9? TWL6035? If this function is used on the DRA7xx boards only (with
TPS659038), you should add some comment above.
Ok ll add the comment.
+ val = 0x2b; /* (3 - 0.9) * 20 + 1 */
Why not use definitions for the voltage? You could take them from
http://patchwork.ozlabs.org/patch/244103/ where some values are
defined.
Yes, Ill rebase this patch on top of your patch and use those defines.
Please be aware that my above mentioned patch has not been reviewed/
tested/acked/nacked/whatever by nobody (except possibly a quick look by
Nishanth Menon, who had some objections). I wrote it when bringing up a
custom OMAP5 board, and most probably it shall not go into mainline in
its current form, if ever. I gave it only as an example of how things
could be done cleaner. Feel free to use the code as you wish, but I'm
afraid that applying it as a patch to your tree and basing upon it might
run you into problems when you later sync with mainline.
Tom, your opinion?
+
+ if (palmas_i2c_write_u8(TPS659038_CHIP_ADDR, LDO1_VOLTAGE, val)) {
+ printf(tps659038: could not set LDO1 voltage\n);
+ return 1;
+ }
+
+ /* TURN ON LDO9 */
LDO9?
+ val = LDO_ON | LDO_MODE_SLEEP | LDO_MODE_ACTIVE;
Bit LDO_ON in all LDOx_CTRL Palmas registers is Read-Only (and reflects the
current status of the LDO). While it makes no harm to try writing to it, this
may be misleading about actual LDO operation, and anyway has no sense.
Yes, I see a similar update in your patch for LDO9. ll do the same for
LDO1 also.
But are you sure that the TPS659038 has the same LDOx_CTRL register layout
as the TWL6035/37? It belongs to the family, yes, but I don't have a
Register Manual for this chip... Hope you have checked.
Thanks
Lokesh
[snip]
Best regards,
Lubo
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] patches never reviewed
Dear All, i worked hardly through v6 for approval of this AMCORE Coldfire board support. Waited patiently for review of this patches: http://patchwork.ozlabs.org/patch/215904/ http://patchwork.ozlabs.org/patch/214686/ then asked again later for the review: http://marc.info/?l=u-bootm=136059580219228w=2 still, at today, i had no feedbacks. Unfortunately (i can be wrong) but i have the impression at freescale no-one have time to spend for following this board addition. Best Regards Angelo Dureghello ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] TPM patches to pull if you wish
Hi Tom,
I pushed the TPM patches to a branch for you if you want to pick them up.
I ended up squashing the config patch into the others - since otherwise
snow will not build for one commit. Does that seem acceptable or should I
resend the whole series again?
Here are the original patches:
http://patchwork.ozlabs.org/bundle/sjg/tpm/
The following changes since commit d6639d10dbfa42dc888f8917012550b632a88959:
Merge branch 'master' of git://git.denx.de/u-boot-nand-flash (2013-05-31
18:28:47 -0400)
are available in the git repository at:
git://git.denx.de/u-boot-x86.git tpm
for you to fetch changes up to 1b393db5870927d68c42a46e6c5877c8d0d83910:
tpm: Reorganize the I2C TPM driver (2013-06-03 01:31:23 -0700)
Che-liang Chiou (1):
tpm: Rename generic_lpc_tpm to tpm_tis_lpc
Tom Wai-Hong Tam (2):
x86: config: Reflect the name changes of LPC TPM configs
tpm: Reorganize the I2C TPM driver
Vincent Palatin (1):
tpm: Add support for new Infineon I2C TPM (SLB 9645 TT 1.2 I2C)
README | 18 +++-
drivers/tpm/Makefile | 7 +-
drivers/tpm/slb9635_i2c/compatibility.h | 51 -
drivers/tpm/tis_i2c.c| 4 +
drivers/tpm/{slb9635_i2c = }/tpm.c | 280
++-
drivers/tpm/{slb9635_i2c/tpm.h = tpm_private.h} | 46 ++--
drivers/tpm/{slb9635_i2c = }/tpm_tis_i2c.c | 354
drivers/tpm/{generic_lpc_tpm.c = tpm_tis_lpc.c} | 0
include/configs/coreboot.h | 3 +-
include/configs/exynos5250-dt.h | 6 +-
include/fdtdec.h | 1 +
lib/fdtdec.c | 1 +
12 files changed, 486 insertions(+), 285 deletions(-)
delete mode 100644 drivers/tpm/slb9635_i2c/compatibility.h
rename drivers/tpm/{slb9635_i2c = }/tpm.c (63%)
rename drivers/tpm/{slb9635_i2c/tpm.h = tpm_private.h} (71%)
rename drivers/tpm/{slb9635_i2c = }/tpm_tis_i2c.c (59%)
rename drivers/tpm/{generic_lpc_tpm.c = tpm_tis_lpc.c} (100%)
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-Boot fit_image_load() refactor patches
Hi Tom, I am not sure that anyone has reviewed these patches, but they are the next stage on cleaning up the image code. Here is a pull request: The following changes since commit d6639d10dbfa42dc888f8917012550b632a88959: Merge branch 'master' of git://git.denx.de/u-boot-nand-flash (2013-05-31 18:28:47 -0400) are available in the git repository at: git://git.denx.de/u-boot-x86.git image3 for you to fetch changes up to e4a91c94b31c651856fbd644987c6ac236ccf46a: sandbox: image: Create a test for loading FIT images (2013-06-03 01:41:56 -0700) Simon Glass (10): bootstage: Introduce sub-IDs for use with image loading mkimage: Add map_sysmem() and IH_ARCH_DEFAULT to simplfy building image: Introduce fit_image_load() to load images from FITs image: Use fit_image_load() to load ramdisk image: Use fit_image_load() to load FDT sandbox: Adjust bootm command to work with sandbox image: Use fit_image_load() to load kernel sandbox: image: Adjust FIT image printing to work with sandbox bootstage: Remove unused entries related to kernel/ramdisk/fdt load sandbox: image: Create a test for loading FIT images common/cmd_bootm.c | 170 +-- common/image-fdt.c | 207 ++ common/image-fit.c | 310 +-- common/image.c | 122 - include/bootstage.h| 51 ++- include/image.h| 105 -- test/image/test-fit.py | 422 ++ tools/mkimage.h| 12 +++ 8 files changed, 846 insertions(+), 553 deletions(-) create mode 100755 test/image/test-fit.py Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot fit_image_load() refactor patches
Hi Tom, On Mon, Jun 3, 2013 at 6:12 PM, Simon Glass s...@chromium.org wrote: Hi Tom, I am not sure that anyone has reviewed these patches, but they are the next stage on cleaning up the image code. Sorry, I sent thatbyy mistake. The bundle is here: http://patchwork.ozlabs.org/bundle/sjg/image3/ I have given it a reasonable amount of testing, but it would be nice if others could try it. The idea is to reduce duplication in the FIT image handling code. Here is a pull request: The following changes since commit d6639d10dbfa42dc888f8917012550b632a88959: Merge branch 'master' of git://git.denx.de/u-boot-nand-flash(2013-05-31 18:28:47 -0400) are available in the git repository at: git://git.denx.de/u-boot-x86.git image3 for you to fetch changes up to e4a91c94b31c651856fbd644987c6ac236ccf46a: sandbox: image: Create a test for loading FIT images (2013-06-03 01:41:56 -0700) Simon Glass (10): bootstage: Introduce sub-IDs for use with image loading mkimage: Add map_sysmem() and IH_ARCH_DEFAULT to simplfy building image: Introduce fit_image_load() to load images from FITs image: Use fit_image_load() to load ramdisk image: Use fit_image_load() to load FDT sandbox: Adjust bootm command to work with sandbox image: Use fit_image_load() to load kernel sandbox: image: Adjust FIT image printing to work with sandbox bootstage: Remove unused entries related to kernel/ramdisk/fdt load sandbox: image: Create a test for loading FIT images common/cmd_bootm.c | 170 +-- common/image-fdt.c | 207 ++ common/image-fit.c | 310 +-- common/image.c | 122 - include/bootstage.h| 51 ++- include/image.h| 105 -- test/image/test-fit.py | 422 ++ tools/mkimage.h| 12 +++ 8 files changed, 846 insertions(+), 553 deletions(-) create mode 100755 test/image/test-fit.py Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] buildman: Allow make flags to be specified for each board
Hi, On Sat, May 25, 2013 at 7:36 AM, Simon Glass s...@chromium.org wrote: There are a few make options such as BUILD_TAG which can be provided when building U-Boot. Provide a way for buildman to pass these flags to make also. The flags should be in a [make-flags] section and arranged by target name (the 'target' column in boards.cfg. See the README for more details. Signed-off-by: Simon Glass s...@chromium.org This is a new feature - I think it should wait until next time, so I did not put it in the recent pull request. If no objections it can sit there until the next merge window. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/B4860: enable PBL tool for B4860
Use a default RCW of protocol 0x2A_0x98, and a PBI configure file which uses CPC1 as 512KB SRAM, then PBL tool can be used on B4860 to build a pbl boot image. Signed-off-by: Shaohui Xie shaohui@freescale.com --- board/freescale/b4860qds/b4_pbi.cfg | 27 +++ board/freescale/b4860qds/b4_rcw.cfg | 7 +++ include/configs/B4860QDS.h | 2 ++ 3 files changed, 36 insertions(+) create mode 100644 board/freescale/b4860qds/b4_pbi.cfg create mode 100644 board/freescale/b4860qds/b4_rcw.cfg diff --git a/board/freescale/b4860qds/b4_pbi.cfg b/board/freescale/b4860qds/b4_pbi.cfg new file mode 100644 index 000..57b726e --- /dev/null +++ b/board/freescale/b4860qds/b4_pbi.cfg @@ -0,0 +1,27 @@ +#PBI commands +#Initialize CPC1 +0901 00200400 +09138000 +091380c0 0100 +#Configure CPC1 as 512KB SRAM +09010100 +09010104 fff80009 +09010f00 0800 +0901 8000 +#Configure LAW for CPC1 +09000d00 +09000d04 fff8 +09000d08 8112 +#Configure alternate space +0910 +0914 ff00 +0918 8100 +#Configure SPI controller +0911 8403 +09110020 2d170008 +09110024 0018 +09110028 0018 +0911002c 0018 +#Flush PBL data +09138000 +091380c0 diff --git a/board/freescale/b4860qds/b4_rcw.cfg b/board/freescale/b4860qds/b4_rcw.cfg new file mode 100644 index 000..7bf0066 --- /dev/null +++ b/board/freescale/b4860qds/b4_rcw.cfg @@ -0,0 +1,7 @@ +#PBL preamble and RCW header +aa55aa55 010e0100 +# serdes protocol 0x2A_0x98 +140e0018 0f001218 +5498 9000a000 e8904000 a900 +0100 0001f1f8 + 1420 0011 diff --git a/include/configs/B4860QDS.h b/include/configs/B4860QDS.h index 1c9d08e..f8ab478 100644 --- a/include/configs/B4860QDS.h +++ b/include/configs/B4860QDS.h @@ -32,6 +32,8 @@ #ifdef CONFIG_RAMBOOT_PBL #define CONFIG_RAMBOOT_TEXT_BASE CONFIG_SYS_TEXT_BASE #define CONFIG_RESET_VECTOR_ADDRESS0xfffc +#define CONFIG_PBLPBI_CONFIG $(SRCTREE)/board/freescale/b4860qds/b4_pbi.cfg +#define CONFIG_PBLRCW_CONFIG $(SRCTREE)/board/freescale/b4860qds/b4_rcw.cfg #endif /* High Level Configuration Options */ -- 1.8.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-BOOT] [PATCH] arm: da830: moved pinmux configurations to the arch tree
Hi Tom,
On Thu, May 30, 2013 at 13:25:11, Vishwanathrao Badarkhe, Manish wrote:
Move pinmux configurations for the DA830 SoCs from board file
to the arch tree so that it can be used for all da830 based devices.
Also, avoids duplicate pinmuxing in case of NAND.
Signed-off-by: Vishwanathrao Badarkhe, Manish manish...@ti.com
---
Depends on:
http://u-boot.10912.n7.nabble.com/PATCH-da830-add-MMC-support-td155590.html
:100644 100644 dec7bfb... bba4671... M
arch/arm/cpu/arm926ejs/davinci/Makefile
:00 100644 000... d0c964a... A
arch/arm/cpu/arm926ejs/davinci/da830_pinmux.c
:100644 100644 a851f1f... beaf0d6... M
arch/arm/include/asm/arch-davinci/pinmux_defs.h
:100644 100644 bf014ae... a4e9254... M
board/davinci/da8xxevm/da830evm.c
:100644 100644 28995a0... 00e92a6... Minclude/configs/da830evm.h
arch/arm/cpu/arm926ejs/davinci/Makefile |1 +
arch/arm/cpu/arm926ejs/davinci/da830_pinmux.c | 151
+++
arch/arm/include/asm/arch-davinci/pinmux_defs.h | 15 ++-
board/davinci/da8xxevm/da830evm.c | 145 ++
include/configs/da830evm.h |1 +
5 files changed, 181 insertions(+), 132 deletions(-)
Please let me know, are there any review comments on this patch?
diff --git a/arch/arm/cpu/arm926ejs/davinci/Makefile
b/arch/arm/cpu/arm926ejs/davinci/Makefile
index dec7bfb..bba4671 100644
--- a/arch/arm/cpu/arm926ejs/davinci/Makefile
+++ b/arch/arm/cpu/arm926ejs/davinci/Makefile
@@ -33,6 +33,7 @@ COBJS-$(CONFIG_SOC_DM355) += dm355.o
COBJS-$(CONFIG_SOC_DM365)+= dm365.o
COBJS-$(CONFIG_SOC_DM644X) += dm644x.o
COBJS-$(CONFIG_SOC_DM646X) += dm646x.o
+COBJS-$(CONFIG_SOC_DA830)+= da830_pinmux.o
COBJS-$(CONFIG_SOC_DA850)+= da850_pinmux.o
COBJS-$(CONFIG_DRIVER_TI_EMAC) += lxt972.o dp83848.o et1011c.o
ksz8873.o
diff --git a/arch/arm/cpu/arm926ejs/davinci/da830_pinmux.c
b/arch/arm/cpu/arm926ejs/davinci/da830_pinmux.c
new file mode 100644
index 000..d0c964a
--- /dev/null
+++ b/arch/arm/cpu/arm926ejs/davinci/da830_pinmux.c
@@ -0,0 +1,151 @@
+/*
+ * Pinmux configurations for the DA830 SoCs
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include common.h
+#include asm/arch/davinci_misc.h
+#include asm/arch/hardware.h
+#include asm/arch/pinmux_defs.h
+
+/* SPI0 pin muxer settings */
+const struct pinmux_config spi0_pins_base[] = {
+ { pinmux(7), 1, 3 }, /* SPI0_SOMI */
+ { pinmux(7), 1, 4 }, /* SPI0_SIMO */
+ { pinmux(7), 1, 6 } /* SPI0_CLK */
+};
+
+const struct pinmux_config spi0_pins_scs0[] = {
+ { pinmux(7), 1, 7 } /* SPI0_SCS[0] */
+};
+
+const struct pinmux_config spi0_pins_ena[] = {
+ { pinmux(7), 1, 5 } /* SPI0_ENA */
+};
+
+/* NAND pin muxer settings */
+const struct pinmux_config emifa_pins_cs0[] = {
+ { pinmux(18), 1, 2 } /* EMA_CS[0] */
+};
+
+const struct pinmux_config emifa_pins_cs2[] = {
+ { pinmux(18), 1, 3 } /* EMA_CS[2] */
+};
+
+const struct pinmux_config emifa_pins_cs3[] = {
+ { pinmux(18), 1, 4 } /* EMA_CS[3] */
+};
+
+#ifdef CONFIG_USE_NAND
+const struct pinmux_config emifa_pins[] = {
+ { pinmux(13), 1, 6 }, /* EMA_D[0] */
+ { pinmux(13), 1, 7 }, /* EMA_D[1] */
+ { pinmux(14), 1, 0 }, /* EMA_D[2] */
+ { pinmux(14), 1, 1 }, /* EMA_D[3] */
+ { pinmux(14), 1, 2 }, /* EMA_D[4] */
+ { pinmux(14), 1, 3 }, /* EMA_D[5] */
+ { pinmux(14), 1, 4 }, /* EMA_D[6] */
+ { pinmux(14), 1, 5 }, /* EMA_D[7] */
+ { pinmux(14), 1, 6 }, /* EMA_D[8] */
+ { pinmux(14), 1, 7 }, /* EMA_D[9] */
+ { pinmux(15), 1, 0 }, /* EMA_D[10] */
+ { pinmux(15), 1, 1 }, /* EMA_D[11] */
+ { pinmux(15), 1, 2 }, /* EMA_D[12] */
+ { pinmux(15), 1, 3 }, /* EMA_D[13] */
+ { pinmux(15), 1, 4 }, /* EMA_D[14] */
+ { pinmux(15), 1, 5 }, /* EMA_D[15] */
+ { pinmux(15), 1, 6 }, /* EMA_A[0] */
+ { pinmux(15), 1, 7 }, /* EMA_A[1] */
+ { pinmux(16), 1, 0 }, /* EMA_A[2] */
+ { pinmux(16), 1, 1 }, /* EMA_A[3] */
+ { pinmux(16), 1, 2 }, /* EMA_A[4] */
+ { pinmux(16), 1, 3 }, /* EMA_A[5]
Re: [U-Boot] [PATCH V2 09/12] mmc: omap_hsmmc: add mmc1 pbias, ldo1
Hi Lubomir,,
On Tuesday 04 June 2013 01:28 AM, Lubomir Popov wrote:
Hi Lokesh,
Hi Lubomir,
On Thursday 30 May 2013 07:56 PM, Lubomir Popov wrote:
Hi Lokesh,
On 30/05/13 16:19, Lokesh Vutla wrote:
From: Balaji T K balaj...@ti.com
add dra mmc pbias support and ldo1 power on
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/include/asm/arch-omap5/omap.h |3 ++-
drivers/mmc/omap_hsmmc.c | 26 ++
drivers/power/palmas.c | 25 -
include/configs/omap5_common.h |4
include/configs/omap5_uevm.h |5 -
include/palmas.h |6 +-
6 files changed, 49 insertions(+), 20 deletions(-)
[snip]
+ /* set LDO9 TWL6035 to 3V */
LDO9? TWL6035? If this function is used on the DRA7xx boards only (with
TPS659038), you should add some comment above.
Ok ll add the comment.
+ val = 0x2b; /* (3 - 0.9) * 20 + 1 */
Why not use definitions for the voltage? You could take them from
http://patchwork.ozlabs.org/patch/244103/ where some values are
defined.
Yes, Ill rebase this patch on top of your patch and use those defines.
Please be aware that my above mentioned patch has not been reviewed/
tested/acked/nacked/whatever by nobody (except possibly a quick look by
Nishanth Menon, who had some objections). I wrote it when bringing up a
custom OMAP5 board, and most probably it shall not go into mainline in
its current form, if ever. I gave it only as an example of how things
could be done cleaner. Feel free to use the code as you wish, but I'm
afraid that applying it as a patch to your tree and basing upon it might
run you into problems when you later sync with mainline.
Ahh sorry, I was in a dilemma whether to ask this or not. Since it is
posted I assumed
that the patch ll get merged. I have already posted a patch on top of
your patch.
Ill wait for Tom to comment.
Tom, your opinion?
+
+ if (palmas_i2c_write_u8(TPS659038_CHIP_ADDR, LDO1_VOLTAGE, val)) {
+ printf(tps659038: could not set LDO1 voltage\n);
+ return 1;
+ }
+
+ /* TURN ON LDO9 */
LDO9?
+ val = LDO_ON | LDO_MODE_SLEEP | LDO_MODE_ACTIVE;
Bit LDO_ON in all LDOx_CTRL Palmas registers is Read-Only (and reflects the
current status of the LDO). While it makes no harm to try writing to it, this
may be misleading about actual LDO operation, and anyway has no sense.
Yes, I see a similar update in your patch for LDO9. ll do the same for
LDO1 also.
But are you sure that the TPS659038 has the same LDOx_CTRL register layout
as the TWL6035/37? It belongs to the family, yes, but I don't have a
Register Manual for this chip... Hope you have checked.
Yes, TPS659038 has same LDOx_CTRL register layout.
Thanks,
Lokesh
Thanks
Lokesh
[snip]
Best regards,
Lubo
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5] ARM: OMAP: I2C: New read, write and probe functions
Hello Lubomir, Am 03.06.2013 07:13, schrieb Heiko Schocher: Hello Lubomir, Am 02.06.2013 13:42, schrieb Lubomir Popov: Hello Lubomir, Am 01.06.2013 18:44, schrieb Lubomir Popov: New i2c_read, i2c_write and i2c_probe functions, tested on OMAP4 (4430/60/70), OMAP5 (5430) and AM335X (3359); should work on older OMAPs and derivatives as well. The only anticipated exception would be the OMAP2420, which shall require driver modification. [...] drivers/i2c/omap24xx_i2c.c | 490 +++-- 1 file changed, 299 insertions(+), 191 deletions(-) Tested on 3 arm335x based boards, which one uses i2c in SPL code for getting ram parameters, so: Tested-by: Heiko Schocher h...@denx.de Many thanks for testing, to Tom as well (he did it on the Beagleboards, but for one of the older versions, V3 I believe, right?). When it comes to versions, I see that V1 and V2 are still listed in patchwork, probably because of slightly different wording of the subject: http://patchwork.ozlabs.org/patch/233823/ http://patchwork.ozlabs.org/patch/246204/ Could you or Tom clean this up, please? Thanks. Cleared the v3 v4 version, but missed the v2 and v1, Done. just doing a MAKEALL arm with your patch applied and get this error: Configuring for omap2420h4 board... omap24xx_i2c.c:497:17: error: 'struct i2c' has no member named 'irqstatus_raw' omap24xx_i2c.c:528:12: error: 'struct i2c' has no member named 'irqstatus_raw' arm-linux-gnueabi-size: './u-boot': No such file omap24xx_i2c.c: In function 'wait_for_bb': omap24xx_i2c.c:497:17: error: 'struct i2c' has no member named 'irqstatus_raw' omap24xx_i2c.c: In function 'wait_for_event': omap24xx_i2c.c:528:12: error: 'struct i2c' has no member named 'irqstatus_raw' make[1]: *** [omap24xx_i2c.o] Fehler 1 make: *** [drivers/i2c/libi2c.o] Fehler 2 make: *** Warte auf noch nicht beendete Prozesse... Please fix this and run a MAKEALL arm before repost, thanks! 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] imx: Complete the pin definitions for the i.MX6DL / i.MX6Solo
Hi Stephano, Le 03/06/2013 15:03, Stefano Babic a écrit : ... Patch needs a rebased to be merge. Could you repost them (also 2/2) after rebasing on current u-boot-imx ? Thanks ! Best regards, Stefano Babic I will submit a V3 today. Best regards ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add SPI Flash STMicro's N25Q512A add flag status check during SPI Flash write
On Tue, Jun 4, 2013 at 10:34 AM, Insop Song insop.s...@cohere.net wrote:
Hi,
Thank you for your feedback.
-Original Message-
From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
Sent: Monday, June 03, 2013 12:14 PM
To: Insop Song
Cc: u-boot@lists.denx.de; york...@freescale.com
Subject: Re: [U-Boot] [PATCH] Add SPI Flash STMicro's N25Q512A add flag
status check during SPI Flash write
I don't know may be you sent these changes intentionally.
I personally not encouraging these as you sent all changes in one patch,
attached a patch series to mail and did n't follow commit message header.
http://www.denx.de/wiki/view/U-
Boot/Patches#Commit_message_conventions
I've put two changes in one patch because flag status check is needed for
Micron's device.
This is already started mailing thread, so I will keep as it is, but I will
follow the patch convention as the link you told me.
On Mon, Jun 3, 2013 at 10:16 PM, Insop Song insop.s...@cohere.net
wrote:
Hi,
I've made two changes while I was working on STMidro's SPI Flash
N25Q512A
- add the device entry for STMidro's SPI Flash N25Q512A
- add Flag status check during
Without this flag checking sf write will fail and SPI flash
is locked up
Please see the patch and let me know your feedback.
-
From 97572b32c49d06ca6f8548ed88e6e381fb719a08 Mon Sep 17 00:00:00
2001
From: Insop Song insop.s...@cohere.net
Date: Sun, 2 Jun 2013 13:33:37 -0700
Subject: [PATCH] Add SPI Flash STMicro's N25Q512A add flag status
check during SPI Flash write
Signed-off-by: Insop Song insop.s...@cohere.net
---
drivers/mtd/spi/spi_flash.c | 25 +
drivers/mtd/spi/spi_flash_internal.h |1 +
drivers/mtd/spi/stmicro.c|6 ++
3 files changed, 32 insertions(+)
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 00aece9..f53756d 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -72,6 +72,7 @@ int spi_flash_cmd_write_multi(struct spi_flash *flash,
u32 offset,
size_t chunk_len, actual;
int ret;
u8 cmd[4];
+ u8 flag_status;
page_size = flash-page_size;
page_addr = offset / page_size; @@ -83,6 +84,18 @@ int
spi_flash_cmd_write_multi(struct spi_flash *flash, u32 offset,
return ret;
}
+wait_flag:
+ ret = spi_flash_cmd(flash-spi, CMD_READ_FLAG_STATUS,
flag_status, sizeof(flag_status));
+ if (ret 0) {
+ printf(SF: reading flag failed\n);
+ return ret;
+ }
+ debug(flag_status %d\n, flag_status);
+ if ((flag_status 0x80) == 0) {
+ udelay(10);
+ goto wait_flag;
+ }
+
cmd[0] = CMD_PAGE_PROGRAM;
for (actual = 0; actual len; actual += chunk_len) {
chunk_len = min(len - actual, page_size - byte_addr);
@@ -106,6 +119,18 @@ int spi_flash_cmd_write_multi(struct spi_flash
*flash, u32 offset,
debug(SF: write failed\n);
break;
}
+ /* check status */
+flag_check:
+ ret = spi_flash_cmd(flash-spi, CMD_READ_FLAG_STATUS,
flag_status, sizeof(flag_status));
+ if (ret 0) {
+ printf(SF: reading flag failed\n);
+ break;
+ }
+ debug(flag_status %d\n, flag_status);
+ if (!(flag_status 0x80)) {
+ udelay(100);
+ goto flag_check;
+ }
Instead doing this poll on actaual write, may be do it on
spi_flash_cmd_wait_ready()
for code compatibility.
Did you tested these changes, i think the same Flag_status must require on
erase as well.
I've made a change and add spi_flash_cmd_wait_program to align with existing
code structure.
Please see the patch below.
Erase is okay without checking, so I didn't add the check.
No i see without the check in erase when i erase and read back i
couldn't see 0xff
Please check.
ret = spi_flash_cmd_wait_ready(flash,
SPI_FLASH_PROG_TIMEOUT);
if (ret)
diff --git a/drivers/mtd/spi/spi_flash_internal.h
b/drivers/mtd/spi/spi_flash_internal.h
index 141cfa8..90b6993 100644
--- a/drivers/mtd/spi/spi_flash_internal.h
+++ b/drivers/mtd/spi/spi_flash_internal.h
@@ -22,6 +22,7 @@
#define CMD_PAGE_PROGRAM 0x02
#define CMD_WRITE_DISABLE 0x04
#define CMD_READ_STATUS0x05
+#define CMD_READ_FLAG_STATUS 0x70
#define CMD_WRITE_ENABLE 0x06
#define CMD_ERASE_4K 0x20
#define CMD_ERASE_32K 0x52
diff --git a/drivers/mtd/spi/stmicro.c b/drivers/mtd/spi/stmicro.c
