[U-Boot] Handling hangs (was: [PATCH v1] arm: remove unneeded symbol offsets and _TEXT_BASE)
On Sun, 13 Oct 2013 19:16:33 +0200, Albert ARIBAUD wrote: > Hi Benoît, > > On Sun, 13 Oct 2013 17:00:25 +0200 (CEST), Benoît Thébaudeau > wrote: > > > Hi Albert, > > > > On Sunday, October 13, 2013 9:10:28 AM, Albert ARIBAUD wrote: > > > Remove the last uses of symbol offsets in ARM U-Boot. > > > Remove some needless uses of _TEXT_BASE. > > > Remove all _TEXT_BASE definitions. > > > > > > Signed-off-by: Albert ARIBAUD > > > --- > > > _TEXT_BASE was only used by ARM to allow resolution of > > > symbol offsets, themselves only needed due to absolute > > > relocations. > > > > > > In some places, _TEXT_BASE was locally defined only > > > to provide a literal for CONFIG_SYS_TEXT_BASE when the > > > latter could have been used directly. > > > > > > Sometimes even, _TEXT_BASE was defined but unused. > > > > > > Since all relocations in ARM are relative, offsets, > > > _TEXT_BASE and CONFIG_SYS_SYM_OFFSETS can be completely > > > removed, and their uses can be replaced with adequate > > > use of compiler-generated symbols from sections.c file. > > > > [...] > > > > > diff --git a/arch/arm/cpu/arm1136/start.S b/arch/arm/cpu/arm1136/start.S > > > index bd1e067..d15124b 100644 > > > --- a/arch/arm/cpu/arm1136/start.S > > > +++ b/arch/arm/cpu/arm1136/start.S > > > > [...] > > > > > @@ -295,7 +269,6 @@ cpu_init_crit: > > > #ifdef CONFIG_SPL_BUILD > > > .align 5 > > > do_hang: > > > - ldr sp, _TEXT_BASE /* use 32 words about stack */ > > > bl hang/* hang and never return */ > > > #else/* !CONFIG_SPL_BUILD */ > > > .align 5 > > > > Is this change (and the same change in the other start.S files) safe? > > > > lib/hang.c/hang() may need a valid stack pointer because the functions that > > it > > calls may use the stack. > > > > When the CPU lands in do_hang, it's because some exception occurred, which > > may > > follow a situation having corrupted sp. If sp is corrupted, the CPU won't be > > able to push the exception context onto the stack, but it might still be > > able to > > run the exception vector. > > > > Setting sp to *_TEXT_BASE was not great, but at least this provided a few > > valid > > words of RAM for the stack. > > Yes, there is a call to hang() which might or might not imply saving on > the stack depending on code generation, and sp might be incorrect > depending on the exception raised. I'll reintroduce the sp setting but > use the runtime value of _start as stack top. As you say, not great but > hey. Thinking further about hangs: when we call do_hang(), by definition we are in a critical situation where for some reason we cannot proceed any more; and in the worst scenario, the only guaranteed valid register we have is pc. Therefore, I'm not sure it is wise to try to do anything else than actually hanging. OTOH, I do understand that we may also want to do something else than hanging, such as trying to diagnose, but we should choose more clearly: - either we hang for the purpose of being post-mortem-debugged from there, and therefore, we limit alterations to the system state as much as we can, by only affecting pc (to the point that 'bl hang' should be turned into 'b do_hang' so that lr is also preserved); - or we want e.g. to tell the operator about it, and we make sure we have a correct setting, that is, we reserve and use a proper stack rather than set it just below _start and hope for luck. Choosing between one or the other would be done through a configuration option such as for instance CONFIG_SYS_LOG_HANGS. Regarding the stack, we could use some existing exception stack, but it might be better if it was preserved, so that its contents could be looked into. Comments? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Question about dfu flash rootfs image
Hi Heiko, On 10/14/2013 13:43, Heiko Schocher wrote: Hello Bo, Am 12.10.2013 09:18, schrieb Bo Shen: Hi All, Now I am implementing DFU support on Atmel sama5d3xek board, when try to download rootfs image to NAND flash through DFU, we need to drop ffs from rootfs image. Do you use ubi or jffs2? I tested with both ubi and jffs2 in raw mode. In dfu_nand.c when it call nand_write_skip_bad() with flags as 0. However, I need to call nand_write_skip_bad() with flags at least with WITH_DROP_FFS set. Till now, I don't find any good solution to pass the parameter, except hard code it or through "#ifdef CONFIG_CMD_NAND_TRIMFFS" to set it. Any suggestions for it and any other solution? There was a discussion, how to reorganize the dfu_alt_info var, see: http://lists.denx.de/pipermail/u-boot/2013-July/158920.html I think, your question fits into this thread ... Currently, I think, you should add in drivers/dfu/dfu_nand.c:dfu_fill_entity_nand() a new "partdropffs" ? string, and set a marker like for "partubi" the dfu->data.nand.ubi var, and use this marker, where you need it ... OK, I will wait the final decision. Maybe for raw and ubi both need this option. bye, Heiko Best Regards, Bo Shen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] usb: dfu: make nand upload working
Hi Lukasz Majewski,
On 10/13/2013 05:19, Lukasz Majewski wrote:
On Sat, 12 Oct 2013 15:47:14 +0800
Bo Shen wrote:
If won't pass value to dfu->r_left, it always 0, make no transfer,
the dfu-util on host side report failed. So, before starting transfer,
pass the value, then nand uploading can work.
Signed-off-by: Bo Shen
---
drivers/dfu/dfu.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 56b21c7..3c3ad1b 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -274,6 +274,7 @@ int dfu_read(struct dfu_entity *dfu, void *buf,
int size, int blk_seq_num) if (dfu->i_buf_start == NULL)
return -ENOMEM;
+ dfu->r_left = dfu->data.nand.size;
Please do not add nand related code to "generic" DFU code. This can
damage DFU operation with other memories (like eMMC).
Such code shall be added to dfu_nand.c file.
Thanks for point out this.
I will check it.
ret = dfu->read_medium(dfu, 0, dfu->i_buf_start,
&dfu->r_left); if (ret != 0) {
debug("%s: failed to get r_left\n",
__func__);
Best regards,
Lukasz Majewski
Best Regards,
Bo Shen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: mxs: Do not reconfigure FEC clock in FEC init
Dear Marek,
On 10/13/2013 05:20 PM, Marek Vasut wrote:
Do not reconfigure the FEC clock during board_eth_init(), otherwise
the FEC might have stability issues, refuse to autonegotiate link
entirely or even corrupt packets while indicating correct checksum
on them. Instead, move the FEC clock init to board_early_init_f(),
where all the other upstream clock are initialized and also make
sure there is proper stabilization delay.
Do you have any means to reproduce the problem?
I have seldom seen times when the Ethernet did not work, but it was so infrequent that
it was impossible to know where it came from or how to reproduce it.
[...]
diff --git a/board/denx/m28evk/m28evk.c b/board/denx/m28evk/m28evk.c
index 33d38cf..5065ee8 100644
--- a/board/denx/m28evk/m28evk.c
+++ b/board/denx/m28evk/m28evk.c
@@ -26,6 +26,9 @@ DECLARE_GLOBAL_DATA_PTR;
*/
int board_early_init_f(void)
{
+ struct mxs_clkctrl_regs *clkctrl_regs =
+ (struct mxs_clkctrl_regs *)MXS_CLKCTRL_BASE;
+
You may want to wrap these within #ifdef CONFIG_CMD_NET to avoid a warning if
not defined.
diff --git a/board/schulercontrol/sc_sps_1/sc_sps_1.c
b/board/schulercontrol/sc_sps_1/sc_sps_1.c
index 7f0b591..9d3c970 100644
--- a/board/schulercontrol/sc_sps_1/sc_sps_1.c
+++ b/board/schulercontrol/sc_sps_1/sc_sps_1.c
@@ -26,6 +26,9 @@ DECLARE_GLOBAL_DATA_PTR;
*/
int board_early_init_f(void)
{
+ struct mxs_clkctrl_regs *clkctrl_regs =
+ (struct mxs_clkctrl_regs *)MXS_CLKCTRL_BASE;
+
And the same here.
It works ok, but I can't say if it fixes exactly those seldom initialization problems
because I don't have a reliable way to reproduce them.
Tested-by: Hector Palacios
Best regards,
--
Hector Palacios
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] i2c_reloc_fixup fails on m68k
Hello Heiko, Am 2013-10-14 07:51, schrieb Heiko Schocher: > Hello Jens, > > Am 24.09.2013 09:41, schrieb Jens Scharsig: >> Hello Heiko, >>> Hello Jens, I have a access violation problem with i2c_reloc_fixup on coldfire m68k systems. I found out, the i2c_reloc_fixup tries to relocate the adapter itself, but at this time i2c_adap_p is already relocated. >>> >>> Which toolchain? >> >> m68k-elf-gcc (Sourcery CodeBench Lite 2011.09-21) 4.6.1 >> Copyright (C) 2011 Free Software Foundation, Inc. >> This is free software; see the source for copying conditions. There is NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. >> >>> Can anybody confirm this? >>> >>> Added Mike Frysinger, Sonic Zhang (for blackfin) Jason Jin (for m68k) >>> and Macpaul Lin (for nds32) to Cc ... >>> I think also m68k, backfin and nds32 systems are affected >>> >>> Sorry, I have no such system ... maybe you are the first who stepped >>> in it ... >> >> I have only a m68k system, but only this tree arch's call i2c_reloc_fixup >> in this way. > > Any news here? No, silence anywhere > > @Jens: I want to add this patch in the new merge window, could you send > a correct patch please, thanks! I will do this soon. Regards Jens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/5] sf: Add GPL-2.0+ SPDX-License-Identifier for missing ones
Added GPL-2.0+ SPDX-License-Identifier for missed sf source files. Signed-off-by: Jagannadha Sutradharudu Teki Signed-off-by: Bo Shen --- Changes for v2: - none common/cmd_sf.c | 3 ++- drivers/mtd/spi/sf.c | 2 +- drivers/mtd/spi/sf_internal.h | 2 +- drivers/mtd/spi/sf_ops.c | 2 +- drivers/mtd/spi/sf_probe.c| 2 +- 5 files changed, 6 insertions(+), 5 deletions(-) diff --git a/common/cmd_sf.c b/common/cmd_sf.c index 3f60979..3994b06 100644 --- a/common/cmd_sf.c +++ b/common/cmd_sf.c @@ -2,7 +2,8 @@ * Command for accessing SPI flash. * * Copyright (C) 2008 Atmel Corporation - * Licensed under the GPL-2 or later. + * + * SPDX-License-Identifier:GPL-2.0+ */ #include diff --git a/drivers/mtd/spi/sf.c b/drivers/mtd/spi/sf.c index ddbdda0..d5e175c 100644 --- a/drivers/mtd/spi/sf.c +++ b/drivers/mtd/spi/sf.c @@ -4,7 +4,7 @@ * Copyright (C) 2008 Atmel Corporation * Copyright (C) 2010 Reinhard Meyer, EMK Elektronik * - * Licensed under the GPL-2 or later. + * SPDX-License-Identifier:GPL-2.0+ */ #include diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h index ad044ee..732ddf8 100644 --- a/drivers/mtd/spi/sf_internal.h +++ b/drivers/mtd/spi/sf_internal.h @@ -4,7 +4,7 @@ * Copyright (C) 2008 Atmel Corporation * Copyright (C) 2013 Jagannadha Sutradharudu Teki, Xilinx Inc. * - * Licensed under the GPL-2 or later. + * SPDX-License-Identifier:GPL-2.0+ */ #ifndef _SF_INTERNAL_H_ diff --git a/drivers/mtd/spi/sf_ops.c b/drivers/mtd/spi/sf_ops.c index dde6231..108665f 100644 --- a/drivers/mtd/spi/sf_ops.c +++ b/drivers/mtd/spi/sf_ops.c @@ -5,7 +5,7 @@ * Copyright (C) 2010 Reinhard Meyer, EMK Elektronik * Copyright (C) 2013 Jagannadha Sutradharudu Teki, Xilinx Inc. * - * Licensed under the GPL-2 or later. + * SPDX-License-Identifier:GPL-2.0+ */ #include diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c index 9bb5a5f..633a6eb 100644 --- a/drivers/mtd/spi/sf_probe.c +++ b/drivers/mtd/spi/sf_probe.c @@ -5,7 +5,7 @@ * Copyright (C) 2010 Reinhard Meyer, EMK Elektronik * Copyright (C) 2013 Jagannadha Sutradharudu Teki, Xilinx Inc. * - * Licensed under the GPL-2 or later. + * SPDX-License-Identifier:GPL-2.0+ */ #include -- 1.8.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/5] spi: Add GPL-2.0+ SPDX-License-Identifier for missing files
Added GPL-2.0+ SPDX-License-Identifier for missed spi source files. Signed-off-by: Jagannadha Sutradharudu Teki --- Changes for v2: - none drivers/spi/altera_spi.c | 2 +- drivers/spi/bfin_spi.c| 2 +- drivers/spi/oc_tiny_spi.c | 2 +- drivers/spi/xilinx_spi.c | 2 +- drivers/spi/xilinx_spi.h | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/spi/altera_spi.c b/drivers/spi/altera_spi.c index b53607a..5accbb5 100644 --- a/drivers/spi/altera_spi.c +++ b/drivers/spi/altera_spi.c @@ -5,7 +5,7 @@ * Copyright (c) 2005-2008 Analog Devices Inc. * Copyright (C) 2010 Thomas Chou * - * Licensed under the GPL-2 or later. + * SPDX-License-Identifier:GPL-2.0+ */ #include #include diff --git a/drivers/spi/bfin_spi.c b/drivers/spi/bfin_spi.c index f7192c2..bb88f30 100644 --- a/drivers/spi/bfin_spi.c +++ b/drivers/spi/bfin_spi.c @@ -3,7 +3,7 @@ * * Copyright (c) 2005-2010 Analog Devices Inc. * - * Licensed under the GPL-2 or later. + * SPDX-License-Identifier:GPL-2.0+ */ /*#define DEBUG*/ diff --git a/drivers/spi/oc_tiny_spi.c b/drivers/spi/oc_tiny_spi.c index 6f7b1ed..4de5d00 100644 --- a/drivers/spi/oc_tiny_spi.c +++ b/drivers/spi/oc_tiny_spi.c @@ -7,7 +7,7 @@ * Copyright (c) 2005-2008 Analog Devices Inc. * Copyright (C) 2010 Thomas Chou * - * Licensed under the GPL-2 or later. + * SPDX-License-Identifier:GPL-2.0+ */ #include diff --git a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c index a82b056..5ac0184 100644 --- a/drivers/spi/xilinx_spi.c +++ b/drivers/spi/xilinx_spi.c @@ -9,7 +9,7 @@ * Copyright (c) 2010 Graeme Smecher * Copyright (c) 2012 Stephan Linz * - * Licensed under the GPL-2 or later. + * SPDX-License-Identifier:GPL-2.0+ * * [0]: http://www.xilinx.com/support/documentation * diff --git a/drivers/spi/xilinx_spi.h b/drivers/spi/xilinx_spi.h index 69d0b94..ce7d82c 100644 --- a/drivers/spi/xilinx_spi.h +++ b/drivers/spi/xilinx_spi.h @@ -9,7 +9,7 @@ * Copyright (c) 2010 Graeme Smecher * Copyright (c) 2012 Stephan Linz * - * Licensed under the GPL-2 or later. + * SPDX-License-Identifier:GPL-2.0+ * * [0]: http://www.xilinx.com/support/documentation * -- 1.8.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/5] spi: cleanup set for v2013.10 rel
Cleanup set for v2013.10 release. -- Thanks, Jagan. Bo Shen (1): sf: probe: Add missing Atmel at25df321 flash Jagannadha Sutradharudu Teki (4): sf_ops: Unify bank_sel calculation code sf: Minor cleanups. sf: Add GPL-2.0+ SPDX-License-Identifier for missing ones spi: Add GPL-2.0+ SPDX-License-Identifier for missing files common/cmd_sf.c | 3 ++- drivers/mtd/spi/sf.c | 2 +- drivers/mtd/spi/sf_internal.h | 8 drivers/mtd/spi/sf_ops.c | 40 ++-- drivers/mtd/spi/sf_probe.c| 8 +--- drivers/spi/altera_spi.c | 2 +- drivers/spi/bfin_spi.c| 2 +- drivers/spi/oc_tiny_spi.c | 2 +- drivers/spi/xilinx_spi.c | 2 +- drivers/spi/xilinx_spi.h | 2 +- include/spi.h | 14 +++--- 11 files changed, 46 insertions(+), 39 deletions(-) -- 1.8.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/5] sf_ops: Unify bank_sel calculation code
Unified the bank_sel calculation code for erase and
write ops.
Signed-off-by: Jagannadha Sutradharudu Teki
---
Changes for v2:
- none
drivers/mtd/spi/sf_ops.c | 36
1 file changed, 20 insertions(+), 16 deletions(-)
diff --git a/drivers/mtd/spi/sf_ops.c b/drivers/mtd/spi/sf_ops.c
index 2396e22..1003038 100644
--- a/drivers/mtd/spi/sf_ops.c
+++ b/drivers/mtd/spi/sf_ops.c
@@ -59,6 +59,22 @@ static int spi_flash_cmd_bankaddr_write(struct spi_flash
*flash, u8 bank_sel)
return 0;
}
+
+static int spi_flash_bank(struct spi_flash *flash, u32 offset)
+{
+ u8 bank_sel;
+ int ret;
+
+ bank_sel = offset / SPI_FLASH_16MB_BOUN;
+
+ ret = spi_flash_cmd_bankaddr_write(flash, bank_sel);
+ if (ret) {
+ debug("SF: fail to set bank%d\n", bank_sel);
+ return ret;
+ }
+
+ return 0;
+}
#endif
int spi_flash_cmd_wait_ready(struct spi_flash *flash, unsigned long timeout)
@@ -162,15 +178,9 @@ int spi_flash_cmd_erase_ops(struct spi_flash *flash, u32
offset, size_t len)
cmd[0] = flash->erase_cmd;
while (len) {
#ifdef CONFIG_SPI_FLASH_BAR
- u8 bank_sel;
-
- bank_sel = offset / SPI_FLASH_16MB_BOUN;
-
- ret = spi_flash_cmd_bankaddr_write(flash, bank_sel);
- if (ret) {
- debug("SF: fail to set bank%d\n", bank_sel);
+ ret = spi_flash_bank(flash, offset);
+ if (ret < 0)
return ret;
- }
#endif
spi_flash_addr(offset, cmd);
@@ -203,15 +213,9 @@ int spi_flash_cmd_write_ops(struct spi_flash *flash, u32
offset,
cmd[0] = CMD_PAGE_PROGRAM;
for (actual = 0; actual < len; actual += chunk_len) {
#ifdef CONFIG_SPI_FLASH_BAR
- u8 bank_sel;
-
- bank_sel = offset / SPI_FLASH_16MB_BOUN;
-
- ret = spi_flash_cmd_bankaddr_write(flash, bank_sel);
- if (ret) {
- debug("SF: fail to set bank%d\n", bank_sel);
+ ret = spi_flash_bank(flash, offset);
+ if (ret < 0)
return ret;
- }
#endif
byte_addr = offset % page_size;
chunk_len = min(len - actual, page_size - byte_addr);
--
1.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/5] sf: Minor cleanups.
- Add comments.
- Renamed few macros.
- Add tabs.
Signed-off-by: Jagannadha Sutradharudu Teki
Signed-off-by: Bo Shen
---
Changes for v2:
- none
drivers/mtd/spi/sf_internal.h | 6 +++---
drivers/mtd/spi/sf_ops.c | 2 +-
drivers/mtd/spi/sf_probe.c| 5 +++--
include/spi.h | 14 +++---
4 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
index 12d02f9..ad044ee 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -7,8 +7,8 @@
* Licensed under the GPL-2 or later.
*/
-#ifndef _SPI_FLASH_INTERNAL_H_
-#define _SPI_FLASH_INTERNAL_H_
+#ifndef _SF_INTERNAL_H_
+#define _SF_INTERNAL_H_
#define SPI_FLASH_16MB_BOUN0x100
@@ -139,4 +139,4 @@ int spi_flash_read_common(struct spi_flash *flash, const u8
*cmd,
int spi_flash_cmd_read_ops(struct spi_flash *flash, u32 offset,
size_t len, void *data);
-#endif /* _SPI_FLASH_INTERNAL_H_ */
+#endif /* _SF_INTERNAL_H_ */
diff --git a/drivers/mtd/spi/sf_ops.c b/drivers/mtd/spi/sf_ops.c
index 1003038..dde6231 100644
--- a/drivers/mtd/spi/sf_ops.c
+++ b/drivers/mtd/spi/sf_ops.c
@@ -292,7 +292,7 @@ int spi_flash_cmd_read_ops(struct spi_flash *flash, u32
offset,
return ret;
}
#endif
- remain_len = (SPI_FLASH_16MB_BOUN * (bank_sel + 1) - offset);
+ remain_len = (SPI_FLASH_16MB_BOUN * (bank_sel + 1)) - offset;
if (len < remain_len)
read_len = len;
else
diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
index 4251b1b..9bb5a5f 100644
--- a/drivers/mtd/spi/sf_probe.c
+++ b/drivers/mtd/spi/sf_probe.c
@@ -25,7 +25,7 @@ DECLARE_GLOBAL_DATA_PTR;
* @jedec: Device jedec ID (0x[1byte_manuf_id][2byte_dev_id])
* @ext_jedec: Device ext_jedec ID
* @sector_size: Sector size of this device
- * @nr_sectors:No.of sectors on this device
+ * @nr_sectors:No.of sectors on this device
* @flags: Importent param, for flash specific behaviour
*/
struct spi_flash_params {
@@ -139,7 +139,7 @@ static const struct spi_flash_params
spi_flash_params_table[] = {
#endif
/*
* Note:
-* Below paired flash devices has similar spi_flash_params params.
+* Below paired flash devices has similar spi_flash params.
* (S25FL129P_64K, S25FL128S_64K)
* (W25Q80BL, W25Q80BV)
* (W25Q16CL, W25Q16DV)
@@ -188,6 +188,7 @@ static struct spi_flash *spi_flash_validate_params(struct
spi_slave *spi,
}
memset(flash, '\0', sizeof(*flash));
+ /* Assign spi data */
flash->spi = spi;
flash->name = params->name;
flash->memory_map = spi->memory_map;
diff --git a/include/spi.h b/include/spi.h
index 5164d43..ad9248b 100644
--- a/include/spi.h
+++ b/include/spi.h
@@ -1,4 +1,6 @@
/*
+ * Common SPI Interface: Controller-specific definitions
+ *
* (C) Copyright 2001
* Gerald Van Baren, Custom IDEAS, vanba...@cideas.com.
*
@@ -8,8 +10,6 @@
#ifndef _SPI_H_
#define _SPI_H_
-/* Controller-specific definitions: */
-
/* SPI mode flags */
#defineSPI_CPHA0x01/* clock phase */
#defineSPI_CPOL0x02/* clock polarity */
@@ -241,11 +241,11 @@ static inline int spi_w8r8(struct spi_slave *slave,
unsigned char byte)
* This calls spi_setup_slave() with the correct bus number. Call
* spi_free_slave() to free it later.
*
- * @param blob Device tree blob
- * @param node SPI peripheral node to use
- * @param cs Chip select to use
- * @param max_hz Maximum SCK rate in Hz (0 for default)
- * @param mode Clock polarity, clock phase and other parameters
+ * @param blob:Device tree blob
+ * @param node:SPI peripheral node to use
+ * @param cs: Chip select to use
+ * @param max_hz: Maximum SCK rate in Hz (0 for default)
+ * @param mode:Clock polarity, clock phase and other parameters
* @return pointer to new spi_slave structure
*/
struct spi_slave *spi_setup_slave_fdt(const void *blob, int node,
--
1.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 5/5] sf: probe: Add missing Atmel at25df321 flash
From: Bo Shen
As the spi flash transfer to multiple parts, it is forgot to add
Atmel AT25DF321 spi flash support, which broken several Atmel EK
boards which this chip. So, add it
Signed-off-by: Bo Shen
---
Changes for v2:
- none
drivers/mtd/spi/sf_probe.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
index 633a6eb..5eb8ffe 100644
--- a/drivers/mtd/spi/sf_probe.c
+++ b/drivers/mtd/spi/sf_probe.c
@@ -46,6 +46,7 @@ static const struct spi_flash_params spi_flash_params_table[]
= {
{"AT45DB161D", 0x1f2600, 0x0, 64 * 1024,32,
SECT_4K},
{"AT45DB321D", 0x1f2700, 0x0, 64 * 1024,64,
SECT_4K},
{"AT45DB641D", 0x1f2800, 0x0, 64 * 1024, 128,
SECT_4K},
+ {"AT25DF321", 0x1f4701, 0x0, 64 * 1024,64,
SECT_4K},
#endif
#ifdef CONFIG_SPI_FLASH_EON/* EON */
{"EN25Q32B", 0x1c3016, 0x0, 64 * 1024,64,
0},
--
1.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] sf: add missing Atmel at25df321 spi flash support
On Sat, Oct 12, 2013 at 6:50 AM, Bo Shen wrote: > Hi Jagan, > Cc Tom. > > > On 10/11/2013 09:24, Bo Shen wrote: >> >> Hi Jagan, >> >> On 10/10/2013 22:14, Jagan Teki wrote: >>> >>> Thanks for this. >>> >>> On Thu, Oct 10, 2013 at 10:37 AM, Bo Shen wrote: As the spi flash transfer to multiple parts, it is forgot to add Atmel AT25DF321 spi flash support, which broken several Atmel EK boards which this chip. So, add it Signed-off-by: Bo Shen --- drivers/mtd/spi/sf_probe.c |1 + 1 file changed, 1 insertion(+) > > > If this patch not applied before release at Oct 14, it will make a > regression for several Atmel EK boards boot from spi flash. Agreed, thanks for your concern. > > Would you please pick it before release? Yes, I will pick this. and will send one more pull request for cleanup, this should be part of. -- Thanks, Jagan. Jagannadha Sutradharudu Teki, E: jagannadh.t...@gmail.com, P: +91-9676773388 Engineer - System Software Hacker U-boot - SPI Custodian and Zynq APSOC Ln: http://www.linkedin.com/in/jaganteki ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: mxs: Do not reconfigure FEC clock in FEC init
Dear Marek, On 10/13/2013 05:20 PM, Marek Vasut wrote: Do not reconfigure the FEC clock during board_eth_init(), otherwise the FEC might have stability issues, refuse to autonegotiate link entirely or even corrupt packets while indicating correct checksum on them. Instead, move the FEC clock init to board_early_init_f(), where all the other upstream clock are initialized and also make sure there is proper stabilization delay. Signed-off-by: Marek Vasut Cc: Fabio Estevam Cc: Hector Palacios Cc: Oliver Metz Cc: Otavio Salvador Cc: Stefano Babic Cc: Tom Rini --- board/bluegiga/apx4devkit/apx4devkit.c | 10 -- board/denx/m28evk/m28evk.c | 21 +++-- board/freescale/mx28evk/mx28evk.c| 9 + board/schulercontrol/sc_sps_1/sc_sps_1.c | 19 +++ 4 files changed, 31 insertions(+), 28 deletions(-) [...] diff --git a/board/freescale/mx28evk/mx28evk.c b/board/freescale/mx28evk/mx28evk.c index 5005fe2..2c93c44 100644 --- a/board/freescale/mx28evk/mx28evk.c +++ b/board/freescale/mx28evk/mx28evk.c @@ -41,6 +41,11 @@ int board_early_init_f(void) /* SSP2 clock at 160MHz */ mxs_set_sspclk(MXC_SSPCLK2, 16, 0); +#ifdef CONFIG_CMD_NET + cpu_eth_init(NULL); + udelay(1); +#endif + #ifdefCONFIG_CMD_USB mxs_iomux_setup_pad(MX28_PAD_SSP2_SS1__USB1_OVERCURRENT); mxs_iomux_setup_pad(MX28_PAD_AUART2_RX__GPIO_3_8 | @@ -102,10 +107,6 @@ int board_eth_init(bd_t *bis) struct eth_device *dev; int ret; - ret = cpu_eth_init(bis); - if (ret) - return ret; - /* MX28EVK uses ENET_CLK PAD to drive FEC clock */ writel(CLKCTRL_ENET_TIME_SEL_RMII_CLK | CLKCTRL_ENET_CLK_OUT_EN, &clkctrl_regs->hw_clkctrl_enet); Why didn't you move the clk enable instruction on mx28evk, as you did with the rest of platforms? Best regards, -- Hector Palacios ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Fix: nommu I2C adapter relocation error
From: "Jens Scharsig (BuS Elektronik)"
NoMMU systems have a access violation problem with i2c_reloc_fixup.
Blame for it is a double relocation of the adapter itself. The
i2c_adap_p is already relocated, if i2c_reloc_fixup is called.
This patch removes the relocation of i2c_adap_p from i2c_reloc_fixup
to fix this.
Signed-off-by: Jens Scharsig (BuS Elektronik)
---
drivers/i2c/i2c_core.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/i2c/i2c_core.c b/drivers/i2c/i2c_core.c
index d1072e8..bb5d4db 100644
--- a/drivers/i2c/i2c_core.c
+++ b/drivers/i2c/i2c_core.c
@@ -53,10 +53,6 @@ void i2c_reloc_fixup(void)
return;
for (i = 0; i < max; i++) {
- /* adapter itself */
- addr = (unsigned long)i2c_adap_p;
- addr += gd->reloc_off;
- i2c_adap_p = (struct i2c_adapter *)addr;
/* i2c_init() */
addr = (unsigned long)i2c_adap_p->init;
addr += gd->reloc_off;
--
1.8.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] disk:efi: avoid unaligned access on efi partition
> -Original Message- > From: Måns Rullgård [mailto:m...@mansr.com] > Sent: Saturday, October 12, 2013 1:29 AM > To: Piotr Wilczek > Cc: u-boot@lists.denx.de; Tom Rini; Kyungmin Park > Subject: Re: [PATCH] disk:efi: avoid unaligned access on efi partition > > Piotr Wilczek writes: > > > In this patch static variable and memcpy instead of an assignment are > > used to avoid unaligned access exception on some ARM platforms. > > > > Signed-off-by: Piotr Wilczek > > Signed-off-by: Kyungmin Park > > CC: Tom Rini > > --- > > disk/part_efi.c |6 -- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > diff --git a/disk/part_efi.c b/disk/part_efi.c index b7524d6..303b8af > > 100644 > > --- a/disk/part_efi.c > > +++ b/disk/part_efi.c > > @@ -224,7 +224,8 @@ static int set_protective_mbr(block_dev_desc_t > *dev_desc) > > p_mbr->signature = MSDOS_MBR_SIGNATURE; > > p_mbr->partition_record[0].sys_ind = EFI_PMBR_OSTYPE_EFI_GPT; > > p_mbr->partition_record[0].start_sect = 1; > > - p_mbr->partition_record[0].nr_sects = (u32) dev_desc->lba; > > + memcpy(&p_mbr->partition_record[0].nr_sects, &dev_desc->lba, > > + sizeof(dev_desc->lba)); > > Why is this assignment problematic? Note that the compiler may > optimise the memcpy() call into a plain assignment including any > alignment assumptions it was making in the original code. > > The correct fix is either to ensure that pointers are properly aligned > or that things are annotated as potentially unaligned, whichever is > more appropriate. > Problem is that the legacy_mbr structure consists 'le16 unknown' field before 'partition_record' filed and the structure is packed. As a result the address of 'partition_record' filed is halfword aligned. The compiler uses str/ldr instructions (address must be 4-byte aligned) to copy u32 'lba' data thus causing unaligned access exception. The best option would be to rearrange field in the structure but for other reasons I cannot do that. I will use put/get_unaligned as Albert suggested. Best regards Piotr Wilczek > -- > Måns Rullgård > m...@mansr.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] sf: add missing Atmel at25df321 spi flash support
Hi Jagan, On 10/14/2013 16:14, Jagan Teki wrote: On Sat, Oct 12, 2013 at 6:50 AM, Bo Shen wrote: Hi Jagan, Cc Tom. On 10/11/2013 09:24, Bo Shen wrote: Hi Jagan, On 10/10/2013 22:14, Jagan Teki wrote: Thanks for this. On Thu, Oct 10, 2013 at 10:37 AM, Bo Shen wrote: As the spi flash transfer to multiple parts, it is forgot to add Atmel AT25DF321 spi flash support, which broken several Atmel EK boards which this chip. So, add it Signed-off-by: Bo Shen --- drivers/mtd/spi/sf_probe.c |1 + 1 file changed, 1 insertion(+) If this patch not applied before release at Oct 14, it will make a regression for several Atmel EK boards boot from spi flash. Agreed, thanks for your concern. Would you please pick it before release? Yes, I will pick this. and will send one more pull request for cleanup, this should be part of. Thanks. Best Regards, Bo Shen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: mxs: Do not reconfigure FEC clock in FEC init
Hi Marek,
On 13/10/2013 17:20, Marek Vasut wrote:
> Do not reconfigure the FEC clock during board_eth_init(), otherwise
> the FEC might have stability issues, refuse to autonegotiate link
> entirely or even corrupt packets while indicating correct checksum
> on them. Instead, move the FEC clock init to board_early_init_f(),
> where all the other upstream clock are initialized and also make
> sure there is proper stabilization delay.
However, it seems to me that moving the code remove the problem on the
mx28evk without finding the cause. Really there is still a big chunk of
time between the initialization of the clock and the first packet is
sent to the network, when the autonegotiation should occur.
>
> Signed-off-by: Marek Vasut
> Cc: Fabio Estevam
> Cc: Hector Palacios
> Cc: Oliver Metz
> Cc: Otavio Salvador
> Cc: Stefano Babic
> Cc: Tom Rini
> ---
> board/bluegiga/apx4devkit/apx4devkit.c | 10 --
> board/denx/m28evk/m28evk.c | 21 +++--
> board/freescale/mx28evk/mx28evk.c| 9 +
> board/schulercontrol/sc_sps_1/sc_sps_1.c | 19 +++
> 4 files changed, 31 insertions(+), 28 deletions(-)
>
> NOTE: I'd like to get this into current release as it fixes a serious
> issue I observe here on the MX28EVK (packets being corrupted on
> long transfers initiated early after boot). Please test this and
> report back ASAP.
>
> diff --git a/board/bluegiga/apx4devkit/apx4devkit.c
> b/board/bluegiga/apx4devkit/apx4devkit.c
> index 08e79bd..044a182 100644
> --- a/board/bluegiga/apx4devkit/apx4devkit.c
> +++ b/board/bluegiga/apx4devkit/apx4devkit.c
> @@ -39,6 +39,10 @@ int board_early_init_f(void)
> /* SSP0 clock at 96MHz */
> mxs_set_sspclk(MXC_SSPCLK0, 96000, 0);
>
> +#ifdef CONFIG_CMD_NET
> + cpu_eth_init(NULL);
> + udelay(1);
> +#endif
This looks like a hack...
Calling cpu_eth_init() without parameters is absolutely an exception in
u-boot, there is no other instance / SOC doing this.
Are we sure that the issue you see on mx28evk are reproducible on the
other boards ? You are starting to fix all boards, but you report
corruption only on one board.
> return 0;
> }
>
> @@ -79,12 +83,6 @@ int board_eth_init(bd_t *bis)
> int ret;
> struct eth_device *dev;
>
> - ret = cpu_eth_init(bis);
> - if (ret) {
> - printf("FEC MXS: Unable to init FEC clocks\n");
> - return ret;
> - }
> -
> ret = fecmxc_initialize(bis);
> if (ret) {
> printf("FEC MXS: Unable to init FEC\n");
> diff --git a/board/denx/m28evk/m28evk.c b/board/denx/m28evk/m28evk.c
> index 33d38cf..5065ee8 100644
> --- a/board/denx/m28evk/m28evk.c
> +++ b/board/denx/m28evk/m28evk.c
> @@ -26,6 +26,9 @@ DECLARE_GLOBAL_DATA_PTR;
> */
> int board_early_init_f(void)
> {
> + struct mxs_clkctrl_regs *clkctrl_regs =
> + (struct mxs_clkctrl_regs *)MXS_CLKCTRL_BASE;
> +
> /* IO0 clock at 480MHz */
> mxs_set_ioclk(MXC_IOCLK0, 48);
> /* IO1 clock at 480MHz */
> @@ -36,6 +39,14 @@ int board_early_init_f(void)
> /* SSP2 clock at 160MHz */
> mxs_set_sspclk(MXC_SSPCLK2, 16, 0);
>
> +#ifdef CONFIG_CMD_NET
> + cpu_eth_init(NULL);
> + clrsetbits_le32(&clkctrl_regs->hw_clkctrl_enet,
> + CLKCTRL_ENET_TIME_SEL_MASK | CLKCTRL_ENET_CLK_OUT_EN,
> + CLKCTRL_ENET_TIME_SEL_RMII_CLK);
> + udelay(1);
It seems to me that the most obvious change is the 10mS delay you added
after setting the clock. If we find that such delay is really necessary,
should we not fix it insife the cpu_eth_init() else in all board
initialization functions ?
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] kirkwood: ib62x0: use device tree and update config
Hi Fabio, On Sun, Oct 13, 2013 at 11:41:44PM -0300, Fabio Estevam wrote: > On Sun, Oct 13, 2013 at 11:38 PM, Luka Perkov wrote: > > /* > > - * Machine type > > + * Enable device tree support > > */ > > -#define CONFIG_MACH_TYPE MACH_TYPE_NAS6210 > > +#define CONFIG_OF_LIBFDT > > I am not familiar with this platform, but couldn't you also keep > CONFIG_MACH_TYPE ? > > This way people have the option to load both dt and non-dt kernels. Upstream uses only DT. When uboot support was pushed we had non-DT kernel patches that were never merged upstream. IMO we should just drop CONFIG_MACH_TYPE and use CONFIG_OF_LIBFDT. Luka ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Suggestion for building all boards
Hi Simon, On Fri, 11 Oct 2013 16:00:37 -0600, Simon Glass wrote: > Hi Masahiro, > > On Fri, Oct 11, 2013 at 5:29 AM, Masahiro Yamada > wrote: > > Hello experts, custodians. > > > > > To sum up my suggestion, > > > > - Collect pre-built suitable crosstools for all architectures > >on U-boot ftp site. > > Great idea. If you can organize a tarball (or more than one) and a > place to put it then we could make buildman fetch and setup > automatically. > > > > > - Check all boards automatically using those recommended > >crosstools and post the result to the mailing list. > > Would be very helpful. > > > > > - Add new status to boards.cfg to mark boards with a problem. > > This is for boards that are already broken I think. There is some discussion about the Status field in boards.cfg, which might result in moving it from its current "build/don't build" semantics into something more like "maintainers mentioned at the end are active / inactive, but the board still builds anyway". Still, boards.Cfg is for long-term board info, whereas the build breaks discussed here are short-term: if someone submits a patch which breaks some board, we don't apply it until there is a new version that fixes the break. Granted, we may detect board breaks after a patch is applied, but then we as the submitter to provide a separate fix patch within the same release cycle. Also, adding some "builds / doesn't build right now" info in boards.cfg will IMO cause either one of two bad side effects: an observable volume of patches submitted just to keep boards.cfg up to date wrt which board builds or not; or a burden to submitters whose patch (series) break or fix some board(s) and who would then have to also update boards.cfg with this. I don't think we want to ask any submitter to add this to their work, or even to build-test across all of U-Boot's boards to see if they're breaking some board they don't know in an architecture they know nothing about. That's for custodians to do, not for submitters. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v3] cmd/gpt: Support gpt command for all devices
> -Original Message-
> From: Egbert Eich [mailto:egbert.e...@gmail.com]
> Sent: Sunday, October 13, 2013 1:14 AM
> To: Piotr Wilczek
> Cc: 'Egbert Eich'; u-boot@lists.denx.de; 'Tom Rini'; 'Egbert Eich'
> Subject: Re: [Patch v3] cmd/gpt: Support gpt command for all devices
>
> On Fri, Oct 11, 2013 at 09:13:22AM +0200, Piotr Wilczek wrote:
> > Dear Egbert Eich,
> >
> > > -Original Message-
> > > From: Egbert Eich [mailto:egbert.e...@gmail.com]
> > > Sent: Friday, October 04, 2013 6:53 PM
> > > To: u-boot@lists.denx.de
> > > Cc: Piotr Wilczek; Tom Rini; Egbert Eich; Egbert Eich
> > > Subject: [Patch v3] cmd/gpt: Support gpt command for all devices
> > >
> > > From: Egbert Eich
> > >
> > > The gpt command was only implemented for mmc devices. There is no
> > > reason why this command should not be generalized and be applied
> all
> > > other storage device classes.
> > > This change both simplifies the implementation and eliminates a
> > > build failure for systems that don't support mmcs.
> > >
> > > Signed-off-by: Egbert Eich
> > > ---
> > > Changes for v2:
> > >- Coding style cleanup.
> > > Changes for v3:
> > >- Removed wrong '&'
> > >- Removed unused variable
> > >- Fixed argument checking
> > >Spotted by Piotr Wilczek
> > >
> > > common/cmd_gpt.c | 45 +++-
> -
> > > 1 file changed, 19 insertions(+), 26 deletions(-)
> > >
> > > diff --git a/common/cmd_gpt.c b/common/cmd_gpt.c index
> > > a46f5cc..17b1180
> > > 100644
> > > --- a/common/cmd_gpt.c
> > > +++ b/common/cmd_gpt.c
>
> [..]
>
> > >
> > > @@ -287,27 +279,28 @@ static int do_gpt(cmd_tbl_t *cmdtp, int flag,
> > > int
>
> [..]
>
> > > - /* device: 'mmc' */
> > > - if (strcmp(argv[2], "mmc") == 0) {
> > > - /* check if 'dev' is a number */
> > > - for (pstr = argv[3]; *pstr != '\0'; pstr++)
> > > - if (!isdigit(*pstr)) {
> > > - printf("'%s' is not a number\n",
> > > - argv[3]);
> > > - return CMD_RET_USAGE;
> > > - }
> > > - dev = (int)simple_strtoul(argv[3], NULL, 10);
> > > - /* write to mmc */
> > > - if (gpt_mmc_default(dev, argv[4]))
> > > - return CMD_RET_FAILURE;
> > > + char *ep;
> > > + block_dev_desc_t *blk_dev_desc;
> > This probably should be at the beginning of the function
>
> I personally prefer to keep symbols as local as possible (ie. declare
> them in the block they are used in if they are just used within a
> single block) for the following rasons:
> 1. It makes the code more readable ie. the definition is closeby to
>the location where it is used and doesn't require scrolling to
>the beginning of a function and the scope of the variable is is
>much more obvious.
> 2. The compiler can optimize much better as it knows that a variable
>can be discarded at the end of the block also by reusing stack
>slots stack sapce can be used much more efficiently by the compiler.
>
> I agree that in the case at hand the second argument is not too
> relevant, it is more a coding style issue. If there is a coding style
> requirement to have those definitions at the beginning of the function
> I will create a new patch.
>
Agreed, I think it is a coding style rule in U-boot. Let the maintainer to
decide.
>
> [..]
>
> > > + blk_dev_desc = get_dev(argv[2], dev);
> > > + if (!blk_dev_desc) {
> > > + printf("%s: %s dev %d NOT available\n",
> > > +__func__, argv[2], dev);
> > I think it is not necessary since the mmc subsystem prints 'MMC
> Device
> > not found'.
>
> I've done a quick look over the code - of all subsystems MMC seems to
> be the only one which prints a message when its get_dev() method is
> called but no device is found. Therefore I'd prefer to leave this
> there.
>
Ok.
> >
> > Except minor comments this patch looks good to me.
> > I tested it on mmc device (Trats2) and works well.
>
> Ok, thanks!
>
> >
> > Tested-by: Piotr Wilczek
> >
>
> Thanks a lot for testing!
>
> Cheers,
> Egbert.
Best regards,
Piotr Wilczek
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Handling hangs (was: [PATCH v1] arm: remove unneeded symbol offsets and _TEXT_BASE)
Hi Albert, On Monday, October 14, 2013 8:59:17 AM, Albert ARIBAUD wrote: > On Sun, 13 Oct 2013 19:16:33 +0200, Albert ARIBAUD > wrote: > > > Hi Benoît, > > > > On Sun, 13 Oct 2013 17:00:25 +0200 (CEST), Benoît Thébaudeau > > wrote: > > > > > Hi Albert, > > > > > > On Sunday, October 13, 2013 9:10:28 AM, Albert ARIBAUD wrote: > > > > Remove the last uses of symbol offsets in ARM U-Boot. > > > > Remove some needless uses of _TEXT_BASE. > > > > Remove all _TEXT_BASE definitions. > > > > > > > > Signed-off-by: Albert ARIBAUD > > > > --- > > > > _TEXT_BASE was only used by ARM to allow resolution of > > > > symbol offsets, themselves only needed due to absolute > > > > relocations. > > > > > > > > In some places, _TEXT_BASE was locally defined only > > > > to provide a literal for CONFIG_SYS_TEXT_BASE when the > > > > latter could have been used directly. > > > > > > > > Sometimes even, _TEXT_BASE was defined but unused. > > > > > > > > Since all relocations in ARM are relative, offsets, > > > > _TEXT_BASE and CONFIG_SYS_SYM_OFFSETS can be completely > > > > removed, and their uses can be replaced with adequate > > > > use of compiler-generated symbols from sections.c file. > > > > > > [...] > > > > > > > diff --git a/arch/arm/cpu/arm1136/start.S > > > > b/arch/arm/cpu/arm1136/start.S > > > > index bd1e067..d15124b 100644 > > > > --- a/arch/arm/cpu/arm1136/start.S > > > > +++ b/arch/arm/cpu/arm1136/start.S > > > > > > [...] > > > > > > > @@ -295,7 +269,6 @@ cpu_init_crit: > > > > #ifdef CONFIG_SPL_BUILD > > > > .align 5 > > > > do_hang: > > > > - ldr sp, _TEXT_BASE /* use 32 words about > > > > stack */ > > > > bl hang/* hang and never > > > > return */ > > > > #else /* !CONFIG_SPL_BUILD */ > > > > .align 5 > > > > > > Is this change (and the same change in the other start.S files) safe? > > > > > > lib/hang.c/hang() may need a valid stack pointer because the functions > > > that it > > > calls may use the stack. > > > > > > When the CPU lands in do_hang, it's because some exception occurred, > > > which may > > > follow a situation having corrupted sp. If sp is corrupted, the CPU won't > > > be > > > able to push the exception context onto the stack, but it might still be > > > able to > > > run the exception vector. > > > > > > Setting sp to *_TEXT_BASE was not great, but at least this provided a few > > > valid > > > words of RAM for the stack. > > > > Yes, there is a call to hang() which might or might not imply saving on > > the stack depending on code generation, and sp might be incorrect > > depending on the exception raised. I'll reintroduce the sp setting but > > use the runtime value of _start as stack top. As you say, not great but > > hey. > > Thinking further about hangs: when we call do_hang(), by definition we > are in a critical situation where for some reason we cannot proceed > any more; and in the worst scenario, the only guaranteed valid register > we have is pc. Therefore, I'm not sure it is wise to try to do anything > else than actually hanging. > > OTOH, I do understand that we may also want to do something else > than hanging, such as trying to diagnose, but we should choose more > clearly: > > - either we hang for the purpose of being post-mortem-debugged from > there, and therefore, we limit alterations to the system state as > much as we can, by only affecting pc (to the point that 'bl hang' > should be turned into 'b do_hang' so that lr is also preserved); > > - or we want e.g. to tell the operator about it, and we make sure we > have a correct setting, that is, we reserve and use a proper stack > rather than set it just below _start and hope for luck. > > Choosing between one or the other would be done through a configuration > option such as for instance CONFIG_SYS_LOG_HANGS. > > Regarding the stack, we could use some existing exception stack, but it > might be better if it was preserved, so that its contents could be > looked into. > > Comments? This configuration option would be great. The verbose log should be enabled by default, indicating the configuration option to change in order to investigate the hang. In the log case, we care about having a valid stack, not about preserving the possible exception stack contents. In the post-mortem debug case, this is the opposite. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request for u-boot-marvell.git
> -Original Message- > From: Holger Brunck [mailto:holger.bru...@keymile.com] > Sent: 10 October 2013 22:37 > To: Prafulla Wadaskar > Cc: Albert ARIBAUD; 'u-boot@lists.denx.de'; Manas > Saksena > Subject: Re: Pull request for u-boot-marvell.git > > On 10/07/2013 02:58 PM, Prafulla Wadaskar wrote: > > > > > >> -Original Message- > >> From: Holger Brunck > [mailto:holger.bru...@keymile.com] > >> Sent: 07 October 2013 12:48 > >> To: Prafulla Wadaskar > >> Cc: Albert ARIBAUD; 'u-boot@lists.denx.de'; Manas > >> Saksena > >> Subject: Re: Pull request for u-boot-marvell.git > >> > >> Hi, > >> > >> On 10/02/2013 02:51 PM, Albert ARIBAUD wrote: > >>> Hi Prafulla, > >>> > >>> On Wed, 25 Sep 2013 04:20:24 -0700, Prafulla > Wadaskar > >>> wrote: > >>> > Hi Albert, > Please kindly pull > The following changes since commit > >> 12eba1b49380988fd87cc0b3af44014cca8b71c4: > Jeroen Hofstee (1): > README: update ARM register usage > > are available in the git repository at: > > u-boot-marvell.git master branch. > > Holger Brunck (2): > arm/km: drop unneeded define > arm/km: make local function startup_allowed > >> static > > Karlheinz Jerg (1): > arm/km: add support for km_kirkwood_128m16 > >> board > > board/keymile/km_arm/km_arm.c |6 +- > boards.cfg|1 + > include/configs/km_kirkwood.h | 10 ++ > 3 files changed, 12 insertions(+), 5 deletions(-) > > Regards... > Prafulla . . . > >>> > >>> For km_kirkwood_128m16: > >>> > >>> ../common/ivm.c: In function 'ivm_read_eeprom': > >>> ../common/ivm.c:304:18: error: 'CONFIG_KM_IVM_BUS' > >> undeclared (first > >>> use in this function) ../common/ivm.c:304:18: note: > >> each undeclared > >>> identifier is reported only once for each function > it > >> appears in > >>> make[1]: *** > >>> [/home/albert/src/u-boot- > >> > arm/build/km_kirkwood_128m16/board/keymile/km_arm/../co > >> mmon/ivm.o] > >>> Error 1 make: *** > >>> [/home/albert/src/u-boot- > >> > arm/build/km_kirkwood_128m16/board/keymile/km_arm/libkm > >> _arm.o] > >>> Error 2 > >> > >> ok there is some interdependency with Heikos i2c mux > >> rework. > >> > >> Prafulla should I send a patch on top of your branch > >> which fixes this or should > >> I send a v3 of the whole patch? > > > > Please send the patch to fix this issue on the top of > branch. > > > > done three days ago. So could you please pick it up and > send Albert a new pull > request? Surely I will be doing the same. Regards... Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] disk:efi: avoid unaligned access on efi partition
Piotr Wilczek writes: >> -Original Message- >> From: Måns Rullgård [mailto:m...@mansr.com] >> Sent: Saturday, October 12, 2013 1:29 AM >> To: Piotr Wilczek >> Cc: u-boot@lists.denx.de; Tom Rini; Kyungmin Park >> Subject: Re: [PATCH] disk:efi: avoid unaligned access on efi partition >> >> Piotr Wilczek writes: >> >> > In this patch static variable and memcpy instead of an assignment are >> > used to avoid unaligned access exception on some ARM platforms. >> > >> > Signed-off-by: Piotr Wilczek >> > Signed-off-by: Kyungmin Park >> > CC: Tom Rini >> > --- >> > disk/part_efi.c |6 -- >> > 1 file changed, 4 insertions(+), 2 deletions(-) >> > >> > diff --git a/disk/part_efi.c b/disk/part_efi.c index b7524d6..303b8af >> > 100644 >> > --- a/disk/part_efi.c >> > +++ b/disk/part_efi.c >> > @@ -224,7 +224,8 @@ static int set_protective_mbr(block_dev_desc_t >> *dev_desc) >> >p_mbr->signature = MSDOS_MBR_SIGNATURE; >> >p_mbr->partition_record[0].sys_ind = EFI_PMBR_OSTYPE_EFI_GPT; >> >p_mbr->partition_record[0].start_sect = 1; >> > - p_mbr->partition_record[0].nr_sects = (u32) dev_desc->lba; >> > + memcpy(&p_mbr->partition_record[0].nr_sects, &dev_desc->lba, >> > + sizeof(dev_desc->lba)); >> >> Why is this assignment problematic? Note that the compiler may >> optimise the memcpy() call into a plain assignment including any >> alignment assumptions it was making in the original code. >> >> The correct fix is either to ensure that pointers are properly aligned >> or that things are annotated as potentially unaligned, whichever is >> more appropriate. >> > Problem is that the legacy_mbr structure consists 'le16 unknown' field > before 'partition_record' filed and the structure is packed. As a result the > address of 'partition_record' filed is halfword aligned. The compiler uses > str/ldr instructions (address must be 4-byte aligned) to copy u32 'lba' data > thus causing unaligned access exception. If the struct has __attribute__((packed)), gcc should do the right thing already. Note that on ARMv6 and later ldr/str support unaligned addresses unless this is explicitly disabled in the system control register. If you do this, you _MUST_ compile with -mno-unaligned-access. Otherwise you will get problems. -- Måns Rullgård m...@mansr.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Handling hangs (was: [PATCH v1] arm: remove unneeded symbol offsets and _TEXT_BASE)
Hi Benoît, On Mon, 14 Oct 2013 12:22:31 +0200 (CEST), Benoît Thébaudeau wrote: > Hi Albert, > > On Monday, October 14, 2013 8:59:17 AM, Albert ARIBAUD wrote: > > On Sun, 13 Oct 2013 19:16:33 +0200, Albert ARIBAUD > > wrote: > > > > > Hi Benoît, > > > > > > On Sun, 13 Oct 2013 17:00:25 +0200 (CEST), Benoît Thébaudeau > > > wrote: > > > > > > > Hi Albert, > > > > > > > > On Sunday, October 13, 2013 9:10:28 AM, Albert ARIBAUD wrote: > > > > > Remove the last uses of symbol offsets in ARM U-Boot. > > > > > Remove some needless uses of _TEXT_BASE. > > > > > Remove all _TEXT_BASE definitions. > > > > > > > > > > Signed-off-by: Albert ARIBAUD > > > > > --- > > > > > _TEXT_BASE was only used by ARM to allow resolution of > > > > > symbol offsets, themselves only needed due to absolute > > > > > relocations. > > > > > > > > > > In some places, _TEXT_BASE was locally defined only > > > > > to provide a literal for CONFIG_SYS_TEXT_BASE when the > > > > > latter could have been used directly. > > > > > > > > > > Sometimes even, _TEXT_BASE was defined but unused. > > > > > > > > > > Since all relocations in ARM are relative, offsets, > > > > > _TEXT_BASE and CONFIG_SYS_SYM_OFFSETS can be completely > > > > > removed, and their uses can be replaced with adequate > > > > > use of compiler-generated symbols from sections.c file. > > > > > > > > [...] > > > > > > > > > diff --git a/arch/arm/cpu/arm1136/start.S > > > > > b/arch/arm/cpu/arm1136/start.S > > > > > index bd1e067..d15124b 100644 > > > > > --- a/arch/arm/cpu/arm1136/start.S > > > > > +++ b/arch/arm/cpu/arm1136/start.S > > > > > > > > [...] > > > > > > > > > @@ -295,7 +269,6 @@ cpu_init_crit: > > > > > #ifdef CONFIG_SPL_BUILD > > > > > .align 5 > > > > > do_hang: > > > > > - ldr sp, _TEXT_BASE /* use 32 words about > > > > > stack */ > > > > > bl hang/* hang and never > > > > > return */ > > > > > #else/* !CONFIG_SPL_BUILD */ > > > > > .align 5 > > > > > > > > Is this change (and the same change in the other start.S files) safe? > > > > > > > > lib/hang.c/hang() may need a valid stack pointer because the functions > > > > that it > > > > calls may use the stack. > > > > > > > > When the CPU lands in do_hang, it's because some exception occurred, > > > > which may > > > > follow a situation having corrupted sp. If sp is corrupted, the CPU > > > > won't > > > > be > > > > able to push the exception context onto the stack, but it might still be > > > > able to > > > > run the exception vector. > > > > > > > > Setting sp to *_TEXT_BASE was not great, but at least this provided a > > > > few > > > > valid > > > > words of RAM for the stack. > > > > > > Yes, there is a call to hang() which might or might not imply saving on > > > the stack depending on code generation, and sp might be incorrect > > > depending on the exception raised. I'll reintroduce the sp setting but > > > use the runtime value of _start as stack top. As you say, not great but > > > hey. > > > > Thinking further about hangs: when we call do_hang(), by definition we > > are in a critical situation where for some reason we cannot proceed > > any more; and in the worst scenario, the only guaranteed valid register > > we have is pc. Therefore, I'm not sure it is wise to try to do anything > > else than actually hanging. > > > > OTOH, I do understand that we may also want to do something else > > than hanging, such as trying to diagnose, but we should choose more > > clearly: > > > > - either we hang for the purpose of being post-mortem-debugged from > > there, and therefore, we limit alterations to the system state as > > much as we can, by only affecting pc (to the point that 'bl hang' > > should be turned into 'b do_hang' so that lr is also preserved); > > > > - or we want e.g. to tell the operator about it, and we make sure we > > have a correct setting, that is, we reserve and use a proper stack > > rather than set it just below _start and hope for luck. > > > > Choosing between one or the other would be done through a configuration > > option such as for instance CONFIG_SYS_LOG_HANGS. > > > > Regarding the stack, we could use some existing exception stack, but it > > might be better if it was preserved, so that its contents could be > > looked into. > > > > Comments? > > This configuration option would be great. The verbose log should be enabled by > default, indicating the configuration option to change in order to investigate > the hang. I suspect some people would argue that for SPL, the default should be to hang rather than log. > In the log case, we care about having a valid stack, not about preserving the > possible exception stack contents. In the post-mortem debug case, this is the > opposite. Depends. You may want the log to o as faithful a state dump as feasible. > Best regards, > Benoît Amicalement, -- Albert. ___
Re: [U-Boot] [PATCH] disk:efi: avoid unaligned access on efi partition
Hi Måns, On Mon, 14 Oct 2013 11:50:42 +0100, Måns Rullgård wrote: > Piotr Wilczek writes: > > >> -Original Message- > >> From: Måns Rullgård [mailto:m...@mansr.com] > >> Sent: Saturday, October 12, 2013 1:29 AM > >> To: Piotr Wilczek > >> Cc: u-boot@lists.denx.de; Tom Rini; Kyungmin Park > >> Subject: Re: [PATCH] disk:efi: avoid unaligned access on efi partition > >> > >> Piotr Wilczek writes: > >> > >> > In this patch static variable and memcpy instead of an assignment are > >> > used to avoid unaligned access exception on some ARM platforms. > >> > > >> > Signed-off-by: Piotr Wilczek > >> > Signed-off-by: Kyungmin Park > >> > CC: Tom Rini > >> > --- > >> > disk/part_efi.c |6 -- > >> > 1 file changed, 4 insertions(+), 2 deletions(-) > >> > > >> > diff --git a/disk/part_efi.c b/disk/part_efi.c index b7524d6..303b8af > >> > 100644 > >> > --- a/disk/part_efi.c > >> > +++ b/disk/part_efi.c > >> > @@ -224,7 +224,8 @@ static int set_protective_mbr(block_dev_desc_t > >> *dev_desc) > >> > p_mbr->signature = MSDOS_MBR_SIGNATURE; > >> > p_mbr->partition_record[0].sys_ind = EFI_PMBR_OSTYPE_EFI_GPT; > >> > p_mbr->partition_record[0].start_sect = 1; > >> > -p_mbr->partition_record[0].nr_sects = (u32) dev_desc->lba; > >> > +memcpy(&p_mbr->partition_record[0].nr_sects, &dev_desc->lba, > >> > + sizeof(dev_desc->lba)); > >> > >> Why is this assignment problematic? Note that the compiler may > >> optimise the memcpy() call into a plain assignment including any > >> alignment assumptions it was making in the original code. > >> > >> The correct fix is either to ensure that pointers are properly aligned > >> or that things are annotated as potentially unaligned, whichever is > >> more appropriate. > >> > > Problem is that the legacy_mbr structure consists 'le16 unknown' field > > before 'partition_record' filed and the structure is packed. As a result the > > address of 'partition_record' filed is halfword aligned. The compiler uses > > str/ldr instructions (address must be 4-byte aligned) to copy u32 'lba' data > > thus causing unaligned access exception. > > If the struct has __attribute__((packed)), gcc should do the right thing > already. Note that on ARMv6 and later ldr/str support unaligned > addresses unless this is explicitly disabled in the system control > register. If you do this, you _MUST_ compile with -mno-unaligned-access. > Otherwise you will get problems. Please do not advise using native unaligned accesses on code that is not strictly used by ARMv6+ architectures: the present code, for instance, might be run on pre-ARMv6 or non-ARM platforms, and thus, should never assume ability to perform unaligned accesses natively. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Handling hangs (was: [PATCH v1] arm: remove unneeded symbol offsets and _TEXT_BASE)
> Depends. You may want the log to o as faithful a state dump as feasible. "...to *do* as faithful..." Apologies, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] disk:efi: avoid unaligned access on efi partition
Albert ARIBAUD writes: > Hi Måns, > > On Mon, 14 Oct 2013 11:50:42 +0100, Måns Rullgård > wrote: > >> Piotr Wilczek writes: >> >> >> -Original Message- >> >> From: Måns Rullgård [mailto:m...@mansr.com] >> >> Sent: Saturday, October 12, 2013 1:29 AM >> >> To: Piotr Wilczek >> >> Cc: u-boot@lists.denx.de; Tom Rini; Kyungmin Park >> >> Subject: Re: [PATCH] disk:efi: avoid unaligned access on efi partition >> >> >> >> Piotr Wilczek writes: >> >> >> >> > In this patch static variable and memcpy instead of an assignment are >> >> > used to avoid unaligned access exception on some ARM platforms. >> >> > >> >> > Signed-off-by: Piotr Wilczek >> >> > Signed-off-by: Kyungmin Park >> >> > CC: Tom Rini >> >> > --- >> >> > disk/part_efi.c |6 -- >> >> > 1 file changed, 4 insertions(+), 2 deletions(-) >> >> > >> >> > diff --git a/disk/part_efi.c b/disk/part_efi.c index b7524d6..303b8af >> >> > 100644 >> >> > --- a/disk/part_efi.c >> >> > +++ b/disk/part_efi.c >> >> > @@ -224,7 +224,8 @@ static int set_protective_mbr(block_dev_desc_t >> >> *dev_desc) >> >> > p_mbr->signature = MSDOS_MBR_SIGNATURE; >> >> > p_mbr->partition_record[0].sys_ind = EFI_PMBR_OSTYPE_EFI_GPT; >> >> > p_mbr->partition_record[0].start_sect = 1; >> >> > - p_mbr->partition_record[0].nr_sects = (u32) dev_desc->lba; >> >> > + memcpy(&p_mbr->partition_record[0].nr_sects, &dev_desc->lba, >> >> > + sizeof(dev_desc->lba)); >> >> >> >> Why is this assignment problematic? Note that the compiler may >> >> optimise the memcpy() call into a plain assignment including any >> >> alignment assumptions it was making in the original code. >> >> >> >> The correct fix is either to ensure that pointers are properly aligned >> >> or that things are annotated as potentially unaligned, whichever is >> >> more appropriate. >> >> >> > Problem is that the legacy_mbr structure consists 'le16 unknown' >> > field before 'partition_record' filed and the structure is >> > packed. As a result the address of 'partition_record' filed is >> > halfword aligned. The compiler uses str/ldr instructions (address >> > must be 4-byte aligned) to copy u32 'lba' data thus causing >> > unaligned access exception. >> >> If the struct has __attribute__((packed)), gcc should do the right thing >> already. Note that on ARMv6 and later ldr/str support unaligned >> addresses unless this is explicitly disabled in the system control >> register. If you do this, you _MUST_ compile with -mno-unaligned-access. >> Otherwise you will get problems. > > Please do not advise using native unaligned accesses on code that is > not strictly used by ARMv6+ architectures: the present code, for > instance, might be run on pre-ARMv6 or non-ARM platforms, and thus, > should never assume ability to perform unaligned accesses natively. I'm advising no such thing. I said two things: 1. Declaring a struct with the 'packed' attribute makes gcc automatically generate correct code for all targets. _IF_ the selected target supports unaligned ldr/str, these might get used. 2. If your target is ARMv6 or later _AND_ you enable strict alignment checking in the system control register, you _MUST_ build with the -mno-unaligned-access flag. -- Måns Rullgård m...@mansr.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] disk:efi: avoid unaligned access on efi partition
Hi Måns, On Mon, 14 Oct 2013 13:19:27 +0100, Måns Rullgård wrote: > Albert ARIBAUD writes: > > > Hi Måns, > > > > On Mon, 14 Oct 2013 11:50:42 +0100, Måns Rullgård > > wrote: > > > >> Piotr Wilczek writes: > >> > >> >> -Original Message- > >> >> From: Måns Rullgård [mailto:m...@mansr.com] > >> >> Sent: Saturday, October 12, 2013 1:29 AM > >> >> To: Piotr Wilczek > >> >> Cc: u-boot@lists.denx.de; Tom Rini; Kyungmin Park > >> >> Subject: Re: [PATCH] disk:efi: avoid unaligned access on efi partition > >> >> > >> >> Piotr Wilczek writes: > >> >> > >> >> > In this patch static variable and memcpy instead of an assignment are > >> >> > used to avoid unaligned access exception on some ARM platforms. > >> >> > > >> >> > Signed-off-by: Piotr Wilczek > >> >> > Signed-off-by: Kyungmin Park > >> >> > CC: Tom Rini > >> >> > --- > >> >> > disk/part_efi.c |6 -- > >> >> > 1 file changed, 4 insertions(+), 2 deletions(-) > >> >> > > >> >> > diff --git a/disk/part_efi.c b/disk/part_efi.c index b7524d6..303b8af > >> >> > 100644 > >> >> > --- a/disk/part_efi.c > >> >> > +++ b/disk/part_efi.c > >> >> > @@ -224,7 +224,8 @@ static int set_protective_mbr(block_dev_desc_t > >> >> *dev_desc) > >> >> > p_mbr->signature = MSDOS_MBR_SIGNATURE; > >> >> > p_mbr->partition_record[0].sys_ind = EFI_PMBR_OSTYPE_EFI_GPT; > >> >> > p_mbr->partition_record[0].start_sect = 1; > >> >> > - p_mbr->partition_record[0].nr_sects = (u32) dev_desc->lba; > >> >> > + memcpy(&p_mbr->partition_record[0].nr_sects, &dev_desc->lba, > >> >> > +sizeof(dev_desc->lba)); > >> >> > >> >> Why is this assignment problematic? Note that the compiler may > >> >> optimise the memcpy() call into a plain assignment including any > >> >> alignment assumptions it was making in the original code. > >> >> > >> >> The correct fix is either to ensure that pointers are properly aligned > >> >> or that things are annotated as potentially unaligned, whichever is > >> >> more appropriate. > >> >> > >> > Problem is that the legacy_mbr structure consists 'le16 unknown' > >> > field before 'partition_record' filed and the structure is > >> > packed. As a result the address of 'partition_record' filed is > >> > halfword aligned. The compiler uses str/ldr instructions (address > >> > must be 4-byte aligned) to copy u32 'lba' data thus causing > >> > unaligned access exception. > >> > >> If the struct has __attribute__((packed)), gcc should do the right thing > >> already. Note that on ARMv6 and later ldr/str support unaligned > >> addresses unless this is explicitly disabled in the system control > >> register. If you do this, you _MUST_ compile with -mno-unaligned-access. > >> Otherwise you will get problems. > > > > Please do not advise using native unaligned accesses on code that is > > not strictly used by ARMv6+ architectures: the present code, for > > instance, might be run on pre-ARMv6 or non-ARM platforms, and thus, > > should never assume ability to perform unaligned accesses natively. > > I'm advising no such thing. I said two things: > > 1. Declaring a struct with the 'packed' attribute makes gcc > automatically generate correct code for all targets. _IF_ the > selected target supports unaligned ldr/str, these might get used. > > 2. If your target is ARMv6 or later _AND_ you enable strict alignment > checking in the system control register, you _MUST_ build with the > -mno-unaligned-access flag. Then I apologize; I had read "Note that on ARMv6 and later ldr/str support unaligned addresses unless this is explicitly disabled in the system control register" as a suggestion to use that capability. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] disk:efi: avoid unaligned access on efi partition
Albert ARIBAUD writes: >> > Please do not advise using native unaligned accesses on code that is >> > not strictly used by ARMv6+ architectures: the present code, for >> > instance, might be run on pre-ARMv6 or non-ARM platforms, and thus, >> > should never assume ability to perform unaligned accesses natively. >> >> I'm advising no such thing. I said two things: >> >> 1. Declaring a struct with the 'packed' attribute makes gcc >> automatically generate correct code for all targets. _IF_ the >> selected target supports unaligned ldr/str, these might get used. >> >> 2. If your target is ARMv6 or later _AND_ you enable strict alignment >> checking in the system control register, you _MUST_ build with the >> -mno-unaligned-access flag. > > Then I apologize; I had read "Note that on ARMv6 and later ldr/str > support unaligned addresses unless this is explicitly disabled in > the system control register" as a suggestion to use that capability. If building for ARMv6 or later, I do suggest allowing unaligned accesses. The moment you add -march=armv6 (or equivalent), you allow for a number of things not supported by older versions, so why not unaligned memory accesses? -- Måns Rullgård m...@mansr.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] spi: omap3: add support for more word lengths
Hi Nikita,
On 10/09/13 16:46, Nikita Kiryanov wrote:
> Current implementation only supports 8 bit word lengths, even though
> omap3 can handle anything between 4 and 32.
>
> Update the spi interface to support changing the SPI word length,
> and implement it in omap3_spi driver to support the full range of
> possible word lengths.
> This implementation is backwards compatible by defaulting to the old
> behavior of 8 bit word lengths.
> Also, it required a change to the omap3_spi non static I/O functions,
> but since they are not used anywhere else, no collateral changes are required.
>
> Cc: Tom Rini
> Cc: Igor Grinberg
> Cc: Jagannadha Sutradharudu Teki
> Signed-off-by: Nikita Kiryanov
> ---
> drivers/spi/omap3_spi.c | 78
> ++---
> drivers/spi/omap3_spi.h | 11 ---
> include/spi.h | 13 +
> 3 files changed, 81 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/spi/omap3_spi.c b/drivers/spi/omap3_spi.c
> index 6bac245..add98e1 100644
> --- a/drivers/spi/omap3_spi.c
> +++ b/drivers/spi/omap3_spi.c
> @@ -20,7 +20,7 @@
> #include
> #include "omap3_spi.h"
>
> -#define WORD_LEN 8
> +#define SPI_DEFAULT_WORDLEN 8;
As already pointed out, the semicolon should not be there...
> #define SPI_WAIT_TIMEOUT 300;
While at this, can you please, send a separate patch
to fix the above semicolon?
>
> static void spi_reset(struct omap3_spi_slave *ds)
> @@ -128,10 +128,32 @@ struct spi_slave *spi_setup_slave(unsigned int bus,
> unsigned int cs,
> ds->regs = regs;
> ds->freq = max_hz;
> ds->mode = mode;
> + ds->wordlen = SPI_DEFAULT_WORDLEN;
While we know, OMAP SPI controller supports this,
I think many other controllers can also support this feature
and thus their drivers can benefit from this option.
Wouldn't it be better to add the wordlen field to the generic slave
structure instead of the OMAP specific structure?
>
> return &ds->slave;
> }
>
> +int spi_set_wordlen(struct spi_slave *slave, unsigned int wordlen)
> +{
> + struct omap3_spi_slave *ds;
> + int chconf;
> +
> + if (wordlen < 4 || wordlen > 32) {
> + printf("SPI error: unsupported wordlen %d\n", wordlen);
> + return -1;
> + }
> +
> + ds = to_omap3_spi(slave);
> + ds->wordlen = wordlen;
> +
> + chconf = readl(&ds->regs->channel[ds->slave.cs].chconf);
> + chconf &= ~OMAP3_MCSPI_CHCONF_WL_MASK;
> + chconf |= (wordlen - 1) << 7;
> + omap3_spi_write_chconf(ds, chconf);
I would recommend to update the controller just before the transaction
takes place, e.g. in spi_xfer() function, so the spi_set_wordlen() function
will only update the slave structure and will not touch the hardware.
Thus spi_set_wordlen() can be placed in the generic SPI code.
> +
> + return 0;
> +}
> +
> void spi_free_slave(struct spi_slave *slave)
> {
> struct omap3_spi_slave *ds = to_omap3_spi(slave);
> @@ -185,7 +207,7 @@ int spi_claim_bus(struct spi_slave *slave)
>
> /* wordlength */
> conf &= ~OMAP3_MCSPI_CHCONF_WL_MASK;
> - conf |= (WORD_LEN - 1) << 7;
> + conf |= (ds->wordlen - 1) << 7;
>
> /* set chipselect polarity; manage with FORCE */
> if (!(ds->mode & SPI_CS_HIGH))
> @@ -223,7 +245,7 @@ void spi_release_bus(struct spi_slave *slave)
> spi_reset(ds);
> }
>
> -int omap3_spi_write(struct spi_slave *slave, unsigned int len, const u8 *txp,
> +int omap3_spi_write(struct spi_slave *slave, unsigned int len, const void
> *txp,
> unsigned long flags)
> {
> struct omap3_spi_slave *ds = to_omap3_spi(slave);
> @@ -250,7 +272,13 @@ int omap3_spi_write(struct spi_slave *slave, unsigned
> int len, const u8 *txp,
> }
> }
> /* Write the data */
> - writel(txp[i], &ds->regs->channel[ds->slave.cs].tx);
> + unsigned int *tx = &ds->regs->channel[ds->slave.cs].tx;
> + if (ds->wordlen > 16)
> + writel(((u32 *)txp)[i], tx);
> + else if (ds->wordlen > 8)
> + writel(((u16 *)txp)[i], tx);
> + else
> + writel(((u8 *)txp)[i], tx);
Can we always have u32 for the txp and use masks ans shifts instead of
the ugly castings?
> }
>
> /* wait to finish of transfer */
> @@ -268,7 +296,7 @@ int omap3_spi_write(struct spi_slave *slave, unsigned int
> len, const u8 *txp,
> return 0;
> }
>
> -int omap3_spi_read(struct spi_slave *slave, unsigned int len, u8 *rxp,
> +int omap3_spi_read(struct spi_slave *slave, unsigned int len, void *rxp,
> unsigned long flags)
> {
> struct omap3_spi_slave *ds = to_omap3_spi(slave);
> @@ -302,7 +330,13 @@ int omap3_spi_read(struct spi_slave *slave, unsigned int
> len, u8 *rxp,
> omap3_spi_set_enable(ds,OMAP3_MCSPI_CHCTRL_DIS);
>
> /* Read the data */
> -
Re: [U-Boot] [PATCH 2/3] lcd: add DataImage SCF0403x LCD panel support
Hi Nikita,
On 10/09/13 16:46, Nikita Kiryanov wrote:
> Add SPI-based driver for DataImage SCF0403852GGU04 and SCF0403526GGU20
> LCD panels.
>
> Cc: Tom Rini
> Cc: Anatolij Gustschin
> Cc: Igor Grinberg
> Signed-off-by: Nikita Kiryanov
> ---
> drivers/video/Makefile | 1 +
> drivers/video/scf0403_lcd.c | 298
>
> include/scf0403_lcd.h | 22
> include/spi.h | 1 +
> 4 files changed, 322 insertions(+)
> create mode 100644 drivers/video/scf0403_lcd.c
> create mode 100644 include/scf0403_lcd.h
[...]
> diff --git a/drivers/video/scf0403_lcd.c b/drivers/video/scf0403_lcd.c
> new file mode 100644
> index 000..1d1c3ff
> --- /dev/null
> +++ b/drivers/video/scf0403_lcd.c
> @@ -0,0 +1,298 @@
[...]
> +static void scf0403_gpio_reset(unsigned int gpio)
> +{
> + if (!gpio_is_valid(gpio))
> + return;
> +
> + gpio_set_value(gpio, 1);
> + mdelay(100);
> + gpio_set_value(gpio, 0);
> + mdelay(40);
> + gpio_set_value(gpio, 1);
> + mdelay(100);
> +}
[...]
> +int scf0403_init(int reset_gpio)
> +{
> + int error;
> +
> + if (!gpio_is_valid(reset_gpio)) {
> + printf("scf0403 reset_gpio not valid\n");
> + return -1;
The LCD reset pin does not have to be connected to a GPIO.
Instead, it can be handled in another manner (e.g. by hardware).
So, I don't think you should fail the LCD initialization if
some kind of -EINVAL is passed.
> + }
> +
> + priv.reset_gpio = reset_gpio;
> + error = scf0403_request_reset_gpio(reset_gpio);
> + if (error) {
> + printf("Failed requesting reset GPIO%d: %d\n",
> +reset_gpio, error);
> + return error;
> + }
> +
> + priv.spi = spi_setup_slave(3, 0, 100, SPI_MODE_0);
> + error = spi_claim_bus(priv.spi);
> + if (error) {
> + gpio_free(priv.reset_gpio);
> + return error;
> + }
> +
> + /* reset LCD */
> + scf0403_gpio_reset(reset_gpio);
> +
> + error = scf0403_spi_read_rddid(priv.spi, &priv.rddid);
> + if (error) {
> + printf("IDs read failed\n");
> + gpio_free(priv.reset_gpio);
> + spi_release_bus(priv.spi);
> +
> + return error;
> + }
> +
> + if (priv.rddid == SCF0403852GGU04_ID) {
> + priv.init_seq = scf0403_initseq_sn04;
> + priv.seq_size = ARRAY_SIZE(scf0403_initseq_sn04);
> + } else {
> + priv.init_seq = scf0403_initseq_sn20;
> + priv.seq_size = ARRAY_SIZE(scf0403_initseq_sn20);
> + }
> +
> + scf0403_lcd_init(&priv);
> +
> + /* Start operation */
> + scf0403_spi_transfer(priv.spi, &scf0403_cmd_dison);
> + mdelay(100);
> + scf0403_spi_transfer(priv.spi, &scf0403_cmd_slpout);
> + spi_release_bus(priv.spi);
> +
> + return 0;
> +}
[...]
> diff --git a/include/spi.h b/include/spi.h
> index ae318ff..4441527 100644
> --- a/include/spi.h
> +++ b/include/spi.h
> @@ -27,6 +27,7 @@
> /* SPI transfer flags */
> #define SPI_XFER_BEGIN 0x01/* Assert CS before
> transfer */
> #define SPI_XFER_END 0x02/* Deassert CS after transfer */
> +#define SPI_XFER_ONCE(SPI_XFER_BEGIN | SPI_XFER_END)
This bit does not belong to the patch.
>
> /* Header byte that marks the start of the message */
> #define SPI_PREAMBLE_END_BYTE0xec
>
--
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4] socfpga: Adding Freeze Controller driver
Adding Freeze Controller driver. All HPS IOs need to be
in freeze state during pin mux or IO buffer configuration.
It is to avoid any glitch which might happen
during the configuration from propagating to external devices.
Signed-off-by: Chin Liang See
Cc: Wolfgang Denk
CC: Pavel Machek
Cc: Dinh Nguyen
Cc: Tom Rini
Cc: Albert Aribaud
---
Changes for v4
- Removed additional lines
- Single function call to freeze and thaw all channels
Changes for v3
- Removed unused macro in freeze_controller.h
Changes for v2
- Removed FREEZE_CONTROLLER_FSM_HW
- Removed the get_timer_count_masked and convert to use delay in us
- Used shorter local variables
---
arch/arm/cpu/armv7/socfpga/Makefile|2 +-
arch/arm/cpu/armv7/socfpga/freeze_controller.c | 216
arch/arm/cpu/armv7/socfpga/spl.c |9 +
.../include/asm/arch-socfpga/freeze_controller.h | 50 +
4 files changed, 276 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/cpu/armv7/socfpga/freeze_controller.c
create mode 100644 arch/arm/include/asm/arch-socfpga/freeze_controller.h
diff --git a/arch/arm/cpu/armv7/socfpga/Makefile
b/arch/arm/cpu/armv7/socfpga/Makefile
index 0859e44..10d20f2 100644
--- a/arch/arm/cpu/armv7/socfpga/Makefile
+++ b/arch/arm/cpu/armv7/socfpga/Makefile
@@ -14,7 +14,7 @@ LIB = $(obj)lib$(SOC).o
SOBJS := lowlevel_init.o
COBJS-y:= misc.o timer.o reset_manager.o system_manager.o
-COBJS-$(CONFIG_SPL_BUILD) += spl.o
+COBJS-$(CONFIG_SPL_BUILD) += spl.o freeze_controller.o
COBJS := $(COBJS-y)
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
diff --git a/arch/arm/cpu/armv7/socfpga/freeze_controller.c
b/arch/arm/cpu/armv7/socfpga/freeze_controller.c
new file mode 100644
index 000..330b4aa
--- /dev/null
+++ b/arch/arm/cpu/armv7/socfpga/freeze_controller.c
@@ -0,0 +1,216 @@
+/*
+ * Copyright (C) 2013 Altera Corporation
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static const struct socfpga_freeze_controller *freeze_controller_base =
+ (void *)(SOCFPGA_SYSMGR_ADDRESS + SYSMGR_FRZCTRL_ADDRESS);
+
+/*
+ * Default state from cold reset is FREEZE_ALL; the global
+ * flag is set to TRUE to indicate the IO banks are frozen
+ */
+static uint32_t frzctrl_channel_freeze[FREEZE_CHANNEL_NUM]
+ = { FREEZE_CTRL_FROZEN, FREEZE_CTRL_FROZEN,
+ FREEZE_CTRL_FROZEN, FREEZE_CTRL_FROZEN};
+
+/* Freeze HPS IOs */
+void sys_mgr_frzctrl_freeze_req(void)
+{
+ u32 ioctrl_reg_offset;
+ u32 reg_value;
+ u32 reg_cfg_mask;
+ u32 channel_id;
+
+ /* select software FSM */
+ writel(SYSMGR_FRZCTRL_SRC_VIO1_ENUM_SW, &freeze_controller_base->src);
+
+ /* Freeze channel 0 to 2 */
+ for (channel_id = 0; channel_id <= 2; channel_id++) {
+ ioctrl_reg_offset = (u32)(
+ &freeze_controller_base->vioctrl +
+ (channel_id << SYSMGR_FRZCTRL_VIOCTRL_SHIFT));
+
+ /*
+* Assert active low enrnsl, plniotri
+* and niotri signals
+*/
+ reg_cfg_mask =
+ SYSMGR_FRZCTRL_VIOCTRL_SLEW_MASK
+ | SYSMGR_FRZCTRL_VIOCTRL_WKPULLUP_MASK
+ | SYSMGR_FRZCTRL_VIOCTRL_TRISTATE_MASK;
+ clrbits_le32(ioctrl_reg_offset, reg_cfg_mask);
+
+ /*
+* Note: Delay for 20ns at min
+* Assert active low bhniotri signal and de-assert
+* active high csrdone
+*/
+ reg_cfg_mask
+ = SYSMGR_FRZCTRL_VIOCTRL_BUSHOLD_MASK
+ | SYSMGR_FRZCTRL_VIOCTRL_CFG_MASK;
+ clrbits_le32(ioctrl_reg_offset, reg_cfg_mask);
+
+ /* Set global flag to indicate channel is frozen */
+ frzctrl_channel_freeze[channel_id] = FREEZE_CTRL_FROZEN;
+ }
+
+ /* Freeze channel 3 */
+ /*
+* Assert active low enrnsl, plniotri and
+* niotri signals
+*/
+ reg_cfg_mask
+ = SYSMGR_FRZCTRL_HIOCTRL_SLEW_MASK
+ | SYSMGR_FRZCTRL_HIOCTRL_WKPULLUP_MASK
+ | SYSMGR_FRZCTRL_HIOCTRL_TRISTATE_MASK;
+ clrbits_le32(&freeze_controller_base->hioctrl, reg_cfg_mask);
+
+ /*
+* assert active low bhniotri & nfrzdrv signals,
+* de-assert active high csrdone and assert
+* active high frzreg and nfrzdrv signals
+*/
+ reg_value = readl(&freeze_controller_base->hioctrl);
+ reg_cfg_mask
+ = SYSMGR_FRZCTRL_HIOCTRL_BUSHOLD_MASK
+ | SYSMGR_FRZCTRL_HIOCTRL_CFG_MASK;
+ reg_value
+ = (reg_value & ~reg_cfg_mask)
+ | SYSMGR_FRZCTRL_HIOCTRL_REGRST_MASK
+ | SYSMGR_FRZCTRL_HIOCTRL_OCTRST_MASK;
+ writel(reg_value, &freeze_controller_base->hioctrl
Re: [U-Boot] [PATCH] disk:efi: avoid unaligned access on efi partition
Hi Måns, On Mon, 14 Oct 2013 14:05:13 +0100, Måns Rullgård wrote: > Albert ARIBAUD writes: > > >> > Please do not advise using native unaligned accesses on code that is > >> > not strictly used by ARMv6+ architectures: the present code, for > >> > instance, might be run on pre-ARMv6 or non-ARM platforms, and thus, > >> > should never assume ability to perform unaligned accesses natively. > >> > >> I'm advising no such thing. I said two things: > >> > >> 1. Declaring a struct with the 'packed' attribute makes gcc > >> automatically generate correct code for all targets. _IF_ the > >> selected target supports unaligned ldr/str, these might get used. > >> > >> 2. If your target is ARMv6 or later _AND_ you enable strict alignment > >> checking in the system control register, you _MUST_ build with the > >> -mno-unaligned-access flag. > > > > Then I apologize; I had read "Note that on ARMv6 and later ldr/str > > support unaligned addresses unless this is explicitly disabled in > > the system control register" as a suggestion to use that capability. > > If building for ARMv6 or later, I do suggest allowing unaligned > accesses. The moment you add -march=armv6 (or equivalent), you allow > for a number of things not supported by older versions, so why not > unaligned memory accesses? doc/README.arm-unaligned-accesses probably has the answer to your question, especially from line 21 onward. If not, I'll be happy to provide further clarification. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] disk:efi: avoid unaligned access on efi partition
Dear Albert and Måns, > -Original Message- > From: Måns Rullgård [mailto:m...@mansr.com] > Sent: Monday, October 14, 2013 3:05 PM > To: Albert ARIBAUD > Cc: Piotr Wilczek; 'Tom Rini'; u-boot@lists.denx.de; 'Kyungmin Park' > Subject: Re: [U-Boot] [PATCH] disk:efi: avoid unaligned access on efi > partition > > Albert ARIBAUD writes: > > >> > Please do not advise using native unaligned accesses on code that > >> > is not strictly used by ARMv6+ architectures: the present code, > for > >> > instance, might be run on pre-ARMv6 or non-ARM platforms, and > thus, > >> > should never assume ability to perform unaligned accesses > natively. > >> > >> I'm advising no such thing. I said two things: > >> > >> 1. Declaring a struct with the 'packed' attribute makes gcc > >> automatically generate correct code for all targets. _IF_ the > >> selected target supports unaligned ldr/str, these might get > used. > >> > >> 2. If your target is ARMv6 or later _AND_ you enable strict > alignment > >> checking in the system control register, you _MUST_ build with > the > >> -mno-unaligned-access flag. > > > > Then I apologize; I had read "Note that on ARMv6 and later ldr/str > > support unaligned addresses unless this is explicitly disabled in the > > system control register" as a suggestion to use that capability. > > If building for ARMv6 or later, I do suggest allowing unaligned > accesses. The moment you add -march=armv6 (or equivalent), you allow > for a number of things not supported by older versions, so why not > unaligned memory accesses? > Thank you for your comments, I will follow your advice. Best regards Piotr Wilczek > -- > Måns Rullgård > m...@mansr.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] disk:efi: avoid unaligned access on efi partition
Albert ARIBAUD writes: > Hi Måns, > > On Mon, 14 Oct 2013 14:05:13 +0100, Måns Rullgård > wrote: > >> Albert ARIBAUD writes: >> >> >> > Please do not advise using native unaligned accesses on code that is >> >> > not strictly used by ARMv6+ architectures: the present code, for >> >> > instance, might be run on pre-ARMv6 or non-ARM platforms, and thus, >> >> > should never assume ability to perform unaligned accesses natively. >> >> >> >> I'm advising no such thing. I said two things: >> >> >> >> 1. Declaring a struct with the 'packed' attribute makes gcc >> >> automatically generate correct code for all targets. _IF_ the >> >> selected target supports unaligned ldr/str, these might get used. >> >> >> >> 2. If your target is ARMv6 or later _AND_ you enable strict alignment >> >> checking in the system control register, you _MUST_ build with the >> >> -mno-unaligned-access flag. >> > >> > Then I apologize; I had read "Note that on ARMv6 and later ldr/str >> > support unaligned addresses unless this is explicitly disabled in >> > the system control register" as a suggestion to use that capability. >> >> If building for ARMv6 or later, I do suggest allowing unaligned >> accesses. The moment you add -march=armv6 (or equivalent), you allow >> for a number of things not supported by older versions, so why not >> unaligned memory accesses? > > doc/README.arm-unaligned-accesses probably has the answer to your > question, especially from line 21 onward. If not, I'll be happy to > provide further clarification. That is about as backwards as it can get. By adding -munaligned-access you are telling gcc that unaligned accesses are supported and welcome. With this setting enabled, gcc can and will generate unaligned accesses just about anywhere. This setting is NOT compatible with the SCTRL.A bit being set (strict hardware alignment checking). You cannot enable strict alignment checking in hardware, tell the compiler unaligned accesses are OK, and then expect not to have problems. This is no more a valid combination than allowing floating-point instructions when the target has no FPU. -- Måns Rullgård m...@mansr.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] disk:efi: avoid unaligned access on efi partition
Hi Piotr, On Mon, 14 Oct 2013 15:49:43 +0200, Piotr Wilczek wrote: > Dear Albert and Måns, > > > -Original Message- > > From: Måns Rullgård [mailto:m...@mansr.com] > > Sent: Monday, October 14, 2013 3:05 PM > > To: Albert ARIBAUD > > Cc: Piotr Wilczek; 'Tom Rini'; u-boot@lists.denx.de; 'Kyungmin Park' > > Subject: Re: [U-Boot] [PATCH] disk:efi: avoid unaligned access on efi > > partition > > > > Albert ARIBAUD writes: > > > > >> > Please do not advise using native unaligned accesses on code that > > >> > is not strictly used by ARMv6+ architectures: the present code, > > for > > >> > instance, might be run on pre-ARMv6 or non-ARM platforms, and > > thus, > > >> > should never assume ability to perform unaligned accesses > > natively. > > >> > > >> I'm advising no such thing. I said two things: > > >> > > >> 1. Declaring a struct with the 'packed' attribute makes gcc > > >> automatically generate correct code for all targets. _IF_ the > > >> selected target supports unaligned ldr/str, these might get > > used. > > >> > > >> 2. If your target is ARMv6 or later _AND_ you enable strict > > alignment > > >> checking in the system control register, you _MUST_ build with > > the > > >> -mno-unaligned-access flag. > > > > > > Then I apologize; I had read "Note that on ARMv6 and later ldr/str > > > support unaligned addresses unless this is explicitly disabled in the > > > system control register" as a suggestion to use that capability. > > > > If building for ARMv6 or later, I do suggest allowing unaligned > > accesses. The moment you add -march=armv6 (or equivalent), you allow > > for a number of things not supported by older versions, so why not > > unaligned memory accesses? > > > > Thank you for your comments, I will follow your advice. I will NAK building part_efi.c with options to allow native unaligned access. I will, OTOH, be ok with explicit unaligned reads/writes. > Best regards > Piotr Wilczek Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Makefile: Introduce ARCH_PLATFORM_LIBGCC variable
On Sat, Oct 12, 2013 at 09:43:33AM +0200, Albert ARIBAUD wrote:
> Hi Tom,
>
> On Fri, 11 Oct 2013 16:13:03 -0400, Tom Rini wrote:
>
> > In some cases, such as arm multi-lib hardfloat (hf) toolchains, we will
> > have multiple libgcc.a's available, and the arch needs to provide
> > additional logic to determine the right file to use
> > (-print-libgcc-file-name contains no CFLAG parsing logic).
> >
> > Cc: Albert Aribaud
> > Signed-off-by: Tom Rini
> > ---
> > Makefile |4
> > arch/arm/config.mk | 11 +++
> > 2 files changed, 15 insertions(+)
> >
> > diff --git a/Makefile b/Makefile
> > index b09bfcc..13b396f 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -357,8 +357,12 @@ else
> > PLATFORM_LIBGCC = -L $(USE_PRIVATE_LIBGCC) -lgcc
> > endif
> > else
> > +ifneq ("$(ARCH_PLATFORM_LIBGCC)","")
> > +PLATFORM_LIBGCC := -L $(shell dirname $(ARCH_PLATFORM_LIBGCC)) -lgcc
> > +else
> > PLATFORM_LIBGCC := -L $(shell dirname `$(CC) $(CFLAGS)
> > -print-libgcc-file-name`) -lgcc
> > endif
> > +endif
> > PLATFORM_LIBS += $(PLATFORM_LIBGCC)
> > export PLATFORM_LIBS
> >
> > diff --git a/arch/arm/config.mk b/arch/arm/config.mk
> > index d0cf43f..e1d0dec 100644
> > --- a/arch/arm/config.mk
> > +++ b/arch/arm/config.mk
> > @@ -19,6 +19,17 @@ LDFLAGS_FINAL += --gc-sections
> > PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections \
> > -fno-common -ffixed-r9 -msoft-float
> >
> > +#
> > +# When we use a hardfp toolchain if there are both 'libgcc.a' (hardfp) and
> > +# 'arm-linux-gnueabi/libgcc.a' (softfp) we need to use the latter. We
> > +# cannot always build with a hardfp-only toolchain.
>
> What does this last sentence mean exactly?
What it says. If a hardfp only toolchain is used certain targets shall
not link. I had Marek confirm this as well. I don't have the exact
logs handy, but today there's a few targets that will fail, and the nand
flash patchset introduces another because we enforce -msoft-float on
U-Boot, and rely on libgcc from the toolchain for certain functions
(__udivdi3 for example).
I don't know how you weren't making this fail on ELDK 5.x armv7a-fp, but
I was and the Linaro 2013.03 toolchain also will show this problem.
Once I push the nand PR (shortly), building for am3517_crane for example
will fail without this patch.
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: nand flash
On Wed, Oct 09, 2013 at 01:29:55PM -0500, Scott Wood wrote: > Sorry for the lateness, but here are some MTD/UBI bugfixes. They've > been acked by Stefan Roese. > > The following changes since commit b770e88a6c2548727f0d57a3e9e8bb0830f977b5: > > Fix number base handling of "load" command (2013-10-07 15:54:18 -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-nand-flash.git master > > for you to fetch changes up to cc734f5ab26134e5e8d57c34edc257c89ac5b1d2: > > cmd_ubi: add write.part command, to write a volume in multiple parts > (2013-10-09 12:52:22 -0500) > > > Paul Burton (4): > mtd: driver _read() returns max_bitflips; mtd_read() returns -EUCLEAN > cmd_mtdparts: use 64 bits for flash size, partition size & offset > cmd_ubi: use int64_t volume size for 'ubi create' > cmd_ubi: add write.part command, to write a volume in multiple parts > > common/cmd_mtdparts.c | 54 ++ > common/cmd_ubi.c | 79 > +++--- > doc/README.ubi | 3 ++ > drivers/mtd/mtdcore.c | 14 ++- > drivers/mtd/mtdpart.c | 12 +++--- > drivers/mtd/nand/nand_base.c | 18 +++-- > drivers/mtd/onenand/onenand_base.c | 3 +- > include/jffs2/load_kernel.h| 6 +-- > include/linux/mtd/nand.h | 3 ++ > 9 files changed, 129 insertions(+), 63 deletions(-) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] disk:efi: avoid unaligned access on efi partition
Hi Måns, On Mon, 14 Oct 2013 15:09:39 +0100, Måns Rullgård wrote: > Albert ARIBAUD writes: > > > Hi Måns, > > > > On Mon, 14 Oct 2013 14:05:13 +0100, Måns Rullgård > > wrote: > > > >> Albert ARIBAUD writes: > >> > >> >> > Please do not advise using native unaligned accesses on code that is > >> >> > not strictly used by ARMv6+ architectures: the present code, for > >> >> > instance, might be run on pre-ARMv6 or non-ARM platforms, and thus, > >> >> > should never assume ability to perform unaligned accesses natively. > >> >> > >> >> I'm advising no such thing. I said two things: > >> >> > >> >> 1. Declaring a struct with the 'packed' attribute makes gcc > >> >> automatically generate correct code for all targets. _IF_ the > >> >> selected target supports unaligned ldr/str, these might get used. > >> >> > >> >> 2. If your target is ARMv6 or later _AND_ you enable strict alignment > >> >> checking in the system control register, you _MUST_ build with the > >> >> -mno-unaligned-access flag. > >> > > >> > Then I apologize; I had read "Note that on ARMv6 and later ldr/str > >> > support unaligned addresses unless this is explicitly disabled in > >> > the system control register" as a suggestion to use that capability. > >> > >> If building for ARMv6 or later, I do suggest allowing unaligned > >> accesses. The moment you add -march=armv6 (or equivalent), you allow > >> for a number of things not supported by older versions, so why not > >> unaligned memory accesses? > > > > doc/README.arm-unaligned-accesses probably has the answer to your > > question, especially from line 21 onward. If not, I'll be happy to > > provide further clarification. > > That is about as backwards as it can get. By adding -munaligned-access > you are telling gcc that unaligned accesses are supported and welcome. > With this setting enabled, gcc can and will generate unaligned accesses > just about anywhere. This setting is NOT compatible with the SCTRL.A > bit being set (strict hardware alignment checking). > > You cannot enable strict alignment checking in hardware, tell the > compiler unaligned accesses are OK, and then expect not to have > problems. This is no more a valid combination than allowing > floating-point instructions when the target has no FPU. I sense that you have not understood the reason why I want alignment checking enabled in ARM yet also want ARMv6+ builds to emit native unaligned accesses if they consider it needed. The reason is, if we prevent ARMv6 builds from using native unaligned accesses, they would replace *all* such accesses with smaller, aligned, ones, which would not trigger a data abort; even those unaligned accesses cased by programming errors. Whereas if we allow ARMv6+ builds to use native unaligned accesses, yet enable alignment checks, then any native unaligned access will be caught as early as possible, and we'll find and cure the issue faster. This is, of course, assuming we don't voluntarily do native unaligned accesses, and in U-Boot, we indeed don't: in U-Boot, accesses are done on natural alignments. Since I have set up this policy, experience (and it has been a while) shows that very few problems arise from alignment checks + native unaligned accesses. These roughly come from hardware- or standards- mandated unaligned fields, in which case they are worth explicitly accessing with "unaligned" macros, or from programming errors, which should be fixed. Another benefit of it is, if the code builds and runs in mainline with alignment checks *and* native unaligned accesses enabled, then it builds and runs also if you disable either one; whereas code that builds and runs with alignment checks or native unaligned accesses disabled might fail if both are enabled. And I don't see what we would gain by going from a strict "natural alignment only" policy to a relaxed "unalignment allowed" one. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [ANN] Release slightly delayed
Hey all, Since I've pushed the nand PR today, and I see a few other patches in patchwork that we need to get to avoid regressions, I'm going to push the release out a few days (thinking Wednesday currently). We'll lengthen the merge window slightly and cut one of the early on -rc's a bit early in the next window to get us back on track. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-arm/master
On Fri, Oct 11, 2013 at 04:33:18PM +0200, Albert ARIBAUD wrote: > Hello Tom, > > The following changes since commit > 572886af5984febafa6f083e6b8af0465f4f5764: > > socfpga: Adding pin mux handoff files (2013-10-07 19:32:30 +0200) > > are available in the git repository at: > > git://git.denx.De/u-boot-arm master > > for you to fetch changes up to 5a9120439416a9101dec7c7dc65bb75a5ff09c4e: > > Merge branch 'u-boot-samsung/master' into > 'u-boot-arm/master' (2013-10-11 14:47:25 +0200) > > > > Albert ARIBAUD (1): > Merge branch 'u-boot-samsung/master' into 'u-boot-arm/master' > > Piotr Wilczek (4): > drivers:power:max77693: add support for new multi function pmic > max77693 power:battery: add battery support for Trats2 board > samsung:common:i2c: add definions for third soft I2C adapter for > Trats2 board samsung: trats2: add support for new board Trats2 > > Makefile | 1 + > board/samsung/common/multi_i2c.c | 12 + > board/samsung/trats2/Makefile | 34 +++ > board/samsung/trats2/trats2.c | 513 > + > boards.cfg | 1 + > drivers/power/battery/Makefile | 1 + > drivers/power/battery/bat_trats2.c | 65 + > drivers/power/mfd/Makefile | 33 +++ > drivers/power/mfd/fg_max77693.c| 139 ++ > drivers/power/mfd/muic_max77693.c | 77 ++ > drivers/power/mfd/pmic_max77693.c | 96 +++ > include/configs/trats2.h | 311 ++ > include/power/max77693_fg.h| 49 > include/power/max77693_muic.h | 74 ++ > include/power/max77693_pmic.h | 43 15 files changed, 1449 > insertions(+) create mode 100644 board/samsung/trats2/Makefile > create mode 100644 board/samsung/trats2/trats2.c > create mode 100644 drivers/power/battery/bat_trats2.c > create mode 100644 drivers/power/mfd/Makefile > create mode 100644 drivers/power/mfd/fg_max77693.c > create mode 100644 drivers/power/mfd/muic_max77693.c > create mode 100644 drivers/power/mfd/pmic_max77693.c > create mode 100644 include/configs/trats2.h > create mode 100644 include/power/max77693_fg.h > create mode 100644 include/power/max77693_muic.h > create mode 100644 include/power/max77693_pmic.h Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] fatls shows duplicated entries with long and short names
Dear Marek,
I noticed that 'fatls' displays duplicated filenames (short and long) for every file
in the media:
# fatls mmc 0
2083460 uimage-myplatform
2083460 uimage~1
1520 rootfs-dummy.jffs2
1520 rootfs~1.jff
3294952 uimage
3294952 uimage
The guilty commit is ff04f6d1224d8952b566b8671222151495883073 by you, who moved the
chksum calculation out of an if() and now the code never enters this:
#ifdef CONFIG_SUPPORT_VFAT
else if (dols == LS_ROOT && csum == prevcksum) {
prevcksum = 0x;
dentptr++;
continue;
}
#endif
Could you please check?
Best regards,
--
Hector Palacios
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] Release slightly delayed
Hi Tom, On Mon, 14 Oct 2013 11:19:58 -0400, Tom Rini wrote: > Hey all, > > Since I've pushed the nand PR today, and I see a few other patches in > patchwork that we need to get to avoid regressions, I'm going to push > the release out a few days (thinking Wednesday currently). We'll > lengthen the merge window slightly and cut one of the early on -rc's a > bit early in the next window to get us back on track. (Cc:in Prafulla) Prafulla, are you going to send a PR soon? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] disk:efi: avoid unaligned access on efi partition
Albert ARIBAUD writes: > Hi Måns, > > On Mon, 14 Oct 2013 15:09:39 +0100, Måns Rullgård > wrote: > >> Albert ARIBAUD writes: >> >> > Hi Måns, >> > >> > On Mon, 14 Oct 2013 14:05:13 +0100, Måns Rullgård >> > wrote: >> > >> >> Albert ARIBAUD writes: >> >> >> >> >> > Please do not advise using native unaligned accesses on code that is >> >> >> > not strictly used by ARMv6+ architectures: the present code, for >> >> >> > instance, might be run on pre-ARMv6 or non-ARM platforms, and thus, >> >> >> > should never assume ability to perform unaligned accesses natively. >> >> >> >> >> >> I'm advising no such thing. I said two things: >> >> >> >> >> >> 1. Declaring a struct with the 'packed' attribute makes gcc >> >> >> automatically generate correct code for all targets. _IF_ the >> >> >> selected target supports unaligned ldr/str, these might get used. >> >> >> >> >> >> 2. If your target is ARMv6 or later _AND_ you enable strict alignment >> >> >> checking in the system control register, you _MUST_ build with the >> >> >> -mno-unaligned-access flag. >> >> > >> >> > Then I apologize; I had read "Note that on ARMv6 and later ldr/str >> >> > support unaligned addresses unless this is explicitly disabled in >> >> > the system control register" as a suggestion to use that capability. >> >> >> >> If building for ARMv6 or later, I do suggest allowing unaligned >> >> accesses. The moment you add -march=armv6 (or equivalent), you allow >> >> for a number of things not supported by older versions, so why not >> >> unaligned memory accesses? >> > >> > doc/README.arm-unaligned-accesses probably has the answer to your >> > question, especially from line 21 onward. If not, I'll be happy to >> > provide further clarification. >> >> That is about as backwards as it can get. By adding -munaligned-access >> you are telling gcc that unaligned accesses are supported and welcome. >> With this setting enabled, gcc can and will generate unaligned accesses >> just about anywhere. This setting is NOT compatible with the SCTRL.A >> bit being set (strict hardware alignment checking). >> >> You cannot enable strict alignment checking in hardware, tell the >> compiler unaligned accesses are OK, and then expect not to have >> problems. This is no more a valid combination than allowing >> floating-point instructions when the target has no FPU. > > I sense that you have not understood the reason why I want alignment > checking enabled in ARM yet also want ARMv6+ builds to emit native > unaligned accesses if they consider it needed. Your wishes are mutually exclusive. You cannot both allow hardware unaligned access AND at the same time trap them. > The reason is, if we prevent ARMv6 builds from using native unaligned > accesses, they would replace *all* such accesses with smaller, aligned, > ones, which would not trigger a data abort; even those unaligned > accesses cased by programming errors. If you disable unaligned accesses in hardware (as u-boot does), you have no option but doing them a byte at a time. > Whereas if we allow ARMv6+ builds to use native unaligned accesses, yet > enable alignment checks, then any native unaligned access will be > caught as early as possible, and we'll find and cure the issue faster. > > This is, of course, assuming we don't voluntarily do native unaligned > accesses, and in U-Boot, we indeed don't: in U-Boot, accesses are done > on natural alignments. The hardware does not differentiate between intentional and unintentional unaligned accesses. Unlike some architectures, which have dedicated instructions for unaligned accesses, ARM uses the same instructions in both cases (with some limitations). > Since I have set up this policy, experience (and it has been a while) > shows that very few problems arise from alignment checks + native > unaligned accesses. These roughly come from hardware- or standards- > mandated unaligned fields, in which case they are worth explicitly > accessing with "unaligned" macros, or from programming errors, which > should be fixed. The problem is that when you tell gcc (using -munaligned-access) that hardware unaligned accesses are supported, you give it permission to compile even get/put_unaligned() calls (or otherwise annotated accesses) using regular LDR/STR instructions. If this code runs with strict checking enabled in hardware (SCTRL.A set), it will trap. What you probably want is to build with -mno-unaligned-access and enable strict hardware alignment checking. This ensures that any deliberate unaligned accesses (e.g. through get_unaligned) are split into multiple smaller accesses while trapping any (unintentional) unaligned word accesses. The most common alignment-related programming mistake is to dereference a pointer with insufficient alignment. It is far less common for pointers to be marked as unaligned when they do not need to be. > Another benefit of it is, if the code builds and runs in mainline with > alignment ch
Re: [U-Boot] fatls shows duplicated entries with long and short names
Dear Hector Palacios,
> Dear Marek,
>
> I noticed that 'fatls' displays duplicated filenames (short and long) for
> every file in the media:
>
> # fatls mmc 0
>2083460 uimage-myplatform
>2083460 uimage~1
> 1520 rootfs-dummy.jffs2
> 1520 rootfs~1.jff
>3294952 uimage
>3294952 uimage
>
> The guilty commit is ff04f6d1224d8952b566b8671222151495883073 by you, who
> moved the chksum calculation out of an if() and now the code never enters
> this:
>
> #ifdef CONFIG_SUPPORT_VFAT
> else if (dols == LS_ROOT && csum == prevcksum) {
> prevcksum = 0x;
> dentptr++;
> continue;
> }
> #endif
>
> Could you please check?
CCing Tom.
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] fatls shows duplicated entries with long and short names
On Mon, Oct 14, 2013 at 06:00:20PM +0200, Hector Palacios wrote:
> Dear Marek,
>
> I noticed that 'fatls' displays duplicated filenames (short and
> long) for every file in the media:
>
> # fatls mmc 0
> 2083460 uimage-myplatform
> 2083460 uimage~1
> 1520 rootfs-dummy.jffs2
> 1520 rootfs~1.jff
> 3294952 uimage
> 3294952 uimage
>
> The guilty commit is ff04f6d1224d8952b566b8671222151495883073 by
> you, who moved the chksum calculation out of an if() and now the
> code never enters this:
>
> #ifdef CONFIG_SUPPORT_VFAT
> else if (dols == LS_ROOT && csum == prevcksum) {
> prevcksum = 0x;
> dentptr++;
> continue;
> }
> #endif
>
> Could you please check?
Can you please provide more details about your platform and what U-Boot
rev you see this on exactly? I haven't seen anything like this on
Beaglebone Black recently, for example.
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] I2C:Zynq: Adapt this driver to the new model
I am submitting a patch for 'include/zynq.h' as well as for the README file.
I might be able to add code for certain particular boards which use this driver
-- however, I think it may be easier for everyone if we don't do that until
mainline is synchronized with Michal's Xilinx repo. (That's because the Xilinx
repo has config files for several individual boards, but the mainline repo
doesn't yet have those files.)
Michael Burr // Software Engineer II
Logic PD
T // 612.436.7273
NOTICE: Important disclaimers and limitations apply to this email.
Please see this web page for our disclaimers and limitations:
http://logicpd.com/email-disclaimer/
-Original Message-
From: Heiko Schocher [mailto:h...@denx.de]
Sent: Monday, October 14, 2013 1:00 AM
To: Michael Burr
Cc: u-boot@lists.denx.de; Michal Simek
Subject: Re: [PATCH] I2C:Zynq: Adapt this driver to the new model
Hello Michael,
Am 26.09.2013 17:43, schrieb Michael Burr:
> Signed-off-by: Michael Burr
> Cc: Heiko Schocher
> Cc: Michal Simek
> ---
> === Note: this patch depends on the previous patch titled === "[PATCH]
> I2C: Zynq: Support for 0-length register address"
> === submitted 24 Sep. 2013.
>
> Tested on Xilinx ZC702 eval board:
> Select various I2C chips using TI PCA9548 bus multiplexer.
> Write and read registers with addresses of length 0 and 1.
>
> drivers/i2c/zynq_i2c.c | 108
> ++--
> 1 file changed, 67 insertions(+), 41 deletions(-)
Could you please change the config define for this driver from CONFIG_ZYNQ_I2C
to CONFIG_SYS_I2C_ZYNQ ?
Also, adapt please all boards, which use this driver.
and add a entry in README.
Thanks!
> diff --git a/drivers/i2c/zynq_i2c.c b/drivers/i2c/zynq_i2c.c index
> 9cbd3e4..7972a59 100644
> --- a/drivers/i2c/zynq_i2c.c
> +++ b/drivers/i2c/zynq_i2c.c
> @@ -7,6 +7,8 @@
>*
>* Copyright (c) 2012-2013 Xilinx, Michal Simek
>*
> + * Copyright (c) 2013 Logic PD, Michael Burr
> + *
>* SPDX-License-Identifier: GPL-2.0+
>*/
>
> @@ -64,18 +66,28 @@ struct zynq_i2c_registers {
> #define ZYNQ_I2C_FIFO_DEPTH 16
> #define ZYNQ_I2C_TRANSFERT_SIZE_MAX 255 /* Controller transfer limit */
>
> -#if defined(CONFIG_ZYNQ_I2C0)
> -# define ZYNQ_I2C_BASE ZYNQ_I2C_BASEADDR0
> -#else
> -# define ZYNQ_I2C_BASE ZYNQ_I2C_BASEADDR1
> -#endif
> -
> -static struct zynq_i2c_registers *zynq_i2c =
> - (struct zynq_i2c_registers *)ZYNQ_I2C_BASE;
> +static struct zynq_i2c_registers *i2c_select(struct i2c_adapter
> +*adap) {
> + return adap->hwadapnr ?
> +/* Zynq PS I2C1 */
> +(struct zynq_i2c_registers *)ZYNQ_I2C_BASEADDR1 :
> +/* Zynq PS I2C0 */
> +(struct zynq_i2c_registers *)ZYNQ_I2C_BASEADDR0; }
>
> /* I2C init called by cmd_i2c when doing 'i2c reset'. */ -void
> i2c_init(int requested_speed, int slaveadd)
> +static void zynq_i2c_init(struct i2c_adapter *adap, int speed, int
> +slaveaddr)
> {
> + struct zynq_i2c_registers *zynq_i2c = i2c_select(adap);
> +
> + if (speed != 10)
> + debug("Warning: requested speed not supported.\n");
> + if (slaveaddr)
> + debug("Warning: slave mode not supported.\n");
> +
> + /* The following _assumes_ clock rate cpu_1x = 111 MHz */
> + /* This could use improvement! Also see 'i2c_set_bus_speed' below */
> +
> /* 111MHz / ( (3 * 17) * 22 ) = ~100KHz */
> writel((16<< ZYNQ_I2C_CONTROL_DIV_B_SHIFT) |
> (2<< ZYNQ_I2C_CONTROL_DIV_A_SHIFT),&zynq_i2c->control);
> @@ -86,7 +98,7 @@ void i2c_init(int requested_speed, int slaveadd)
> }
>
> #ifdef DEBUG
> -static void zynq_i2c_debug_status(void)
> +static void zynq_i2c_debug_status(struct zynq_i2c_registers
> +*zynq_i2c)
> {
> int int_status;
> int status;
> @@ -128,7 +140,7 @@ static void zynq_i2c_debug_status(void)
> #endif
>
> /* Wait for an interrupt */
> -static u32 zynq_i2c_wait(u32 mask)
> +static u32 zynq_i2c_wait(struct zynq_i2c_registers *zynq_i2c, u32
> +mask)
> {
> int timeout, int_status;
>
> @@ -139,7 +151,7 @@ static u32 zynq_i2c_wait(u32 mask)
> break;
> }
> #ifdef DEBUG
> - zynq_i2c_debug_status();
> + zynq_i2c_debug_status(zynq_i2c);
> #endif
> /* Clear interrupt status flags */
> writel(int_status& mask,&zynq_i2c->interrupt_status);
> @@ -151,17 +163,19 @@ static u32 zynq_i2c_wait(u32 mask)
>* I2C probe called by cmd_i2c when doing 'i2c probe'.
>* Begin read, nak data byte, end.
>*/
> -int i2c_probe(u8 dev)
> +static int zynq_i2c_probe(struct i2c_adapter *adap, uint8_t chip)
> {
> + struct zynq_i2c_registers *zynq_i2c = i2c_select(adap);
> +
> /* Attempt to read a byte */
> setbits_le32(&zynq_i2c->control, ZYNQ_I2C_CONTROL_CLR_FIFO |
> ZYNQ_I2C_CONTROL_RW);
> clrbits_le32(&zynq_i2c->control, ZYNQ_I2C_CONTROL_HOLD);
> writel(0xFF,&zynq_i2c->interrupt_status);
> - write
[U-Boot] [PATCH] I2C:Zynq: Adapt this driver to the new model
CONFIGs and README for driver 'zynq_i2c.c'. Signed-off-by: Michael Burr Cc: Heiko Schocher Cc: Michal Simek --- === This patch depends on the previous patch titled === "[PATCH] I2C:Zynq: Adapt this driver to the new model" === submitted 26 Sep. 2013. === This patch depends on the previous patch titled === "[PATCH] I2C: Zynq: Support for 0-length register address" === submitted 24 Sep. 2013. --- README |9 + include/configs/zynq.h | 10 -- 2 files changed, 13 insertions(+), 6 deletions(-) diff --git a/README b/README index ccd47fa..fd2c8fc 100644 --- a/README +++ b/README @@ -1995,6 +1995,15 @@ CBFS (Coreboot Filesystem) support - CONFIG_SYS_I2C_PPC4XX_CH0 activate hardware channel 0 - CONFIG_SYS_I2C_PPC4XX_CH1 activate hardware channel 1 + - drivers/i2c/zynq_i2c.c + - Activate this driver with CONFIG_SYS_I2C_ZYNQ + - This driver operates only as bus-master (i.e. slave- + address == 0) and supports only 100 kbps speed. + - Both bus-controller devices in the Zynq PS (I2C0 and I2C1) + are supported. (However, note that Zynq PL configuration + may be needed in order to route some bus lines to external + pins.) + additional defines: CONFIG_SYS_NUM_I2C_BUSES diff --git a/include/configs/zynq.h b/include/configs/zynq.h index b9f381f..1ae915f 100644 --- a/include/configs/zynq.h +++ b/include/configs/zynq.h @@ -56,15 +56,13 @@ # define CONFIG_DOS_PARTITION #endif -#define CONFIG_ZYNQ_I2C0 - /* I2C */ -#if defined(CONFIG_ZYNQ_I2C0) || defined(CONFIG_ZYNQ_I2C1) +#define CONFIG_SYS_I2C_ZYNQ +#ifdef CONFIG_SYS_I2C_ZYNQ +# define CONFIG_SYS_I2C # define CONFIG_CMD_I2C -# define CONFIG_ZYNQ_I2C -# define CONFIG_HARD_I2C # define CONFIG_SYS_I2C_SPEED 10 -# define CONFIG_SYS_I2C_SLAVE 1 +# define CONFIG_SYS_I2C_SLAVE 0 #endif #if defined(CONFIG_ZYNQ_DCC) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 2/2] arm:goni:dfu Add support for DFU at GONI target
From: Arkadiusz Wlodarczyk
Proper adjustment for supporting DFU at GONI target has been made.
The s5p_goni.h file has been updated. Moreover the code for low level
USB initialization has been added to GONI board code.
The malloc pool has been enlarged in order to support larger buffer
sizes needed by DFU implementation.
Change-Id: I1b4953368176e8a7588abb0da37de6321f835698
Signed-off-by: Arkadiusz Wlodarczyk
Signed-off-by: Kyungmin Park
Signed-off-by: Mateusz Zalega
Tested-by: Arkadiusz Wlodarczyk
Tested-by: Mateusz Zalega
Cc: Minkyu Kang
---
Changes since v3:
- adjusted to match recently accepted USB patches
---
board/samsung/goni/goni.c | 80 ++
include/configs/s5p_goni.h | 69 ++-
2 files changed, 127 insertions(+), 22 deletions(-)
diff --git a/board/samsung/goni/goni.c b/board/samsung/goni/goni.c
index 366f648..3a2f686 100644
--- a/board/samsung/goni/goni.c
+++ b/board/samsung/goni/goni.c
@@ -13,6 +13,9 @@
#include
#include
#include
+#include
+#include
+
DECLARE_GLOBAL_DATA_PTR;
static struct s5pc110_gpio *s5pc110_gpio;
@@ -172,4 +175,81 @@ struct s3c_plat_otg_data s5pc110_otg_data = {
.regs_otg = S5PC110_OTG_BASE,
.usb_phy_ctrl = S5PC110_USB_PHY_CONTROL,
};
+
+int board_usb_init(int index, enum board_usb_init_type init)
+{
+ debug("USB_udc_probe\n");
+ s3c_udc_probe(&s5pc110_otg_data);
+ return 0;
+}
+#endif
+
+#ifdef CONFIG_USB_GADGET_MASS_STORAGE
+static int ums_read_sector(struct ums_device *ums_dev,
+ ulong start, lbaint_t blkcnt, void *buf)
+{
+ if (ums_dev->mmc->block_dev.block_read(ums_dev->dev_num,
+ start + ums_dev->offset,
+ blkcnt, buf) != blkcnt)
+ return -1;
+
+ return 0;
+}
+
+static int ums_write_sector(struct ums_device *ums_dev,
+ ulong start, lbaint_t blkcnt, const void *buf)
+{
+ if (ums_dev->mmc->block_dev.block_write(ums_dev->dev_num,
+ start + ums_dev->offset,
+ blkcnt, buf) != blkcnt)
+ return -1;
+
+ return 0;
+}
+
+static void ums_get_capacity(struct ums_device *ums_dev,
+ long long int *capacity)
+{
+ long long int tmp_capacity;
+
+ tmp_capacity = (long long int) ((ums_dev->offset + ums_dev->part_size)
+ * SECTOR_SIZE);
+ *capacity = ums_dev->mmc->capacity - tmp_capacity;
+}
+
+static struct ums_board_info ums_board = {
+ .read_sector = ums_read_sector,
+ .write_sector = ums_write_sector,
+ .get_capacity = ums_get_capacity,
+ .name = "GONI UMS disk",
+ .ums_dev = {
+ .mmc = NULL,
+ .dev_num = 0,
+ .offset = 0,
+ .part_size = 0.
+ },
+};
+
+struct ums_board_info *board_ums_init(unsigned int dev_num, unsigned int
offset,
+ unsigned int part_size)
+{
+ struct mmc *mmc;
+
+ mmc = find_mmc_device(dev_num);
+ /*
+* mmc initialization is necessary prior to the ums command usage
+* due to fact that on goni target environment is read from oneNand
+* memory, so the mmc remains uninitialized when u-boot prompt appears
+*/
+ if (!mmc || mmc_init(mmc))
+ return NULL;
+
+ ums_board.ums_dev.mmc = mmc;
+ ums_board.ums_dev.dev_num = dev_num;
+ ums_board.ums_dev.offset = offset;
+ ums_board.ums_dev.part_size = part_size;
+
+ return &ums_board;
+}
+
#endif
diff --git a/include/configs/s5p_goni.h b/include/configs/s5p_goni.h
index fd441c8..218cf3d 100644
--- a/include/configs/s5p_goni.h
+++ b/include/configs/s5p_goni.h
@@ -41,7 +41,7 @@
* Size of malloc() pool
* 1MB = 0x10, 0x10 = 1024 * 1024
*/
-#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (1 << 20))
+#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (16 << 20))
/*
* select serial console configuration
*/
@@ -71,28 +71,46 @@
#define CONFIG_CMD_CACHE
#define CONFIG_CMD_REGINFO
#define CONFIG_CMD_ONENAND
-#define CONFIG_CMD_MTDPARTS
#define CONFIG_CMD_MMC
+#define CONFIG_CMD_DFU
+#define CONFIG_CMD_GPT
-#define CONFIG_BOOTDELAY 1
-#define CONFIG_ZERO_BOOTDELAY_CHECK
+/* USB Composite download gadget - g_dnl */
+#define CONFIG_USBDOWNLOAD_GADGET
+#define CONFIG_DFU_FUNCTION
+#define CONFIG_DFU_MMC
-#define CONFIG_MTD_DEVICE
-#define CONFIG_MTD_PARTITIONS
+/* USB Samsung's IDs */
+#define CONFIG_G_DNL_VENDOR_NUM 0x04E8
+#define CONFIG_G_DNL_PRODUCT_NUM 0x6601
+#define CONFIG_G_DNL_MANUFACTURER "Samsung"
-/* Actual modem binary size is 16MiB. Add 2MiB for bad block handling */
-#define MTDIDS_DEFAULT "onenand0=samsung-onenand"
-#defin
[U-Boot] [PATCH v4 1/2] arm:goni: Update configuration for goni target
From: Arkadiusz Wlodarczyk
Configuration file for GONI has been updated to support FAT file system,
new mmc partitioning scheme and read linux kernel from eMMC instead of
OneNAND.
Signed-off-by: Arkadiusz Wlodarczyk
Signed-off-by: Kyungmin Park
Signed-off-by: Mateusz Zalega
Tested-by: Arkadiusz Wlodarczyk
Tested-by: Mateusz Zalega
Cc: Minkyu Kang
---
Changes since v3:
- added CMD_EXT4
- made it conform with current, recently accepted USB patches
---
include/configs/s5p_goni.h | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/include/configs/s5p_goni.h b/include/configs/s5p_goni.h
index c303244..fd441c8 100644
--- a/include/configs/s5p_goni.h
+++ b/include/configs/s5p_goni.h
@@ -94,7 +94,7 @@
#define NORMAL_MTDPARTS_DEFAULT MTDPARTS_DEFAULT
-#define CONFIG_BOOTCOMMAND "run ubifsboot"
+#define CONFIG_BOOTCOMMAND "run mmcboot"
#define CONFIG_DEFAULT_CONSOLE "console=ttySAC2,115200n8\0"
@@ -124,7 +124,7 @@
"onenand erase 0x0156 0x1eaa;" \
"onenand write 0x3200 0x126 0x8C\0" \
"bootk=" \
- "onenand read 0x30007FC0 0xc0 0x60;" \
+ "run loaduimage;" \
"bootm 0x30007FC0\0" \
"flashboot=" \
"set bootargs root=/dev/mtdblock${bootblock} " \
@@ -143,16 +143,21 @@
"set bootargs " CONFIG_RAMDISK_BOOT \
" initrd=0x3300,8M ramdisk=8192\0" \
"mmcboot=" \
- "set bootargs root=${mmcblk} rootfstype=${rootfstype}" \
+ "set bootargs root=/dev/mmcblk${mmcdev}p${mmcrootpart} " \
+ "rootfstype=${rootfstype}" \
CONFIG_UBI_MTD " ${opts} ${lcdinfo} " \
CONFIG_COMMON_BOOT "; run bootk\0" \
"boottrace=setenv opts initcall_debug; run bootcmd\0" \
"bootchart=set opts init=/sbin/bootchartd; run bootcmd\0" \
"verify=n\0" \
- "rootfstype=cramfs\0" \
+ "rootfstype=ext4\0" \
"console=" CONFIG_DEFAULT_CONSOLE \
"mtdparts=" MTDPARTS_DEFAULT \
"meminfo=mem=80M mem=256M@0x4000 mem=128M@0x5000\0" \
+ "loaduimage=fatload mmc ${mmcdev}:${mmcbootpart} 0x30007FC0 uImage\0" \
+ "mmcdev=0\0" \
+ "mmcbootpart=2\0" \
+ "mmcrootpart=5\0" \
"mmcblk=/dev/mmcblk1p1\0" \
"bootblock=9\0" \
"ubiblock=8\0" \
@@ -198,6 +203,11 @@
#define CONFIG_DOS_PARTITION 1
+/* FAT */
+#define CONFIG_CMD_FAT
+#define CONFIG_CMD_EXT4
+#define CONFIG_FAT_WRITE
+
#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_LOAD_ADDR - 0x100)
#define CONFIG_SYS_CACHELINE_SIZE 64
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] fatls shows duplicated entries with long and short names
On Mon, Oct 14, 2013 at 9:37 PM, Tom Rini wrote:
> On Mon, Oct 14, 2013 at 06:00:20PM +0200, Hector Palacios wrote:
>> Dear Marek,
>>
>> I noticed that 'fatls' displays duplicated filenames (short and
>> long) for every file in the media:
>>
>> # fatls mmc 0
>> 2083460 uimage-myplatform
>> 2083460 uimage~1
>> 1520 rootfs-dummy.jffs2
>> 1520 rootfs~1.jff
>> 3294952 uimage
>> 3294952 uimage
>>
>> The guilty commit is ff04f6d1224d8952b566b8671222151495883073 by
>> you, who moved the chksum calculation out of an if() and now the
>> code never enters this:
>>
>> #ifdef CONFIG_SUPPORT_VFAT
>> else if (dols == LS_ROOT && csum == prevcksum) {
>> prevcksum = 0x;
>> dentptr++;
>> continue;
>> }
>> #endif
>>
>> Could you please check?
>
> Can you please provide more details about your platform and what U-Boot
> rev you see this on exactly? I haven't seen anything like this on
> Beaglebone Black recently, for example.
>
This kind of issue we faced(by Michal)
http://u-boot.10912.n7.nabble.com/FAT-problem-with-new-mkcksum-implementation-td145817.html
Where the issue got resolved with the change from Marek
"vfat: Fix mkcksum argument sizes"
(sha: 6ad77d88e57f6ab815ec7e85c5ac329054318c73)
My suggestion to Hector, can you try to reproduce the same by format
the card again.
--
Thanks,
Jagan.
Jagannadha Sutradharudu Teki,
E: jagannadh.t...@gmail.com, P: +91-9676773388
Engineer - System Software Hacker
U-boot - SPI Custodian and Zynq APSOC
Ln: http://www.linkedin.com/in/jaganteki
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Makefile: Introduce ARCH_PLATFORM_LIBGCC variable
Hi Tom,
On Mon, 14 Oct 2013 11:16:37 -0400, Tom Rini wrote:
> On Sat, Oct 12, 2013 at 09:43:33AM +0200, Albert ARIBAUD wrote:
> > Hi Tom,
> >
> > On Fri, 11 Oct 2013 16:13:03 -0400, Tom Rini wrote:
> >
> > > In some cases, such as arm multi-lib hardfloat (hf) toolchains, we will
> > > have multiple libgcc.a's available, and the arch needs to provide
> > > additional logic to determine the right file to use
> > > (-print-libgcc-file-name contains no CFLAG parsing logic).
> > >
> > > Cc: Albert Aribaud
> > > Signed-off-by: Tom Rini
> > > ---
> > > Makefile |4
> > > arch/arm/config.mk | 11 +++
> > > 2 files changed, 15 insertions(+)
> > >
> > > diff --git a/Makefile b/Makefile
> > > index b09bfcc..13b396f 100644
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -357,8 +357,12 @@ else
> > > PLATFORM_LIBGCC = -L $(USE_PRIVATE_LIBGCC) -lgcc
> > > endif
> > > else
> > > +ifneq ("$(ARCH_PLATFORM_LIBGCC)","")
> > > +PLATFORM_LIBGCC := -L $(shell dirname $(ARCH_PLATFORM_LIBGCC)) -lgcc
> > > +else
> > > PLATFORM_LIBGCC := -L $(shell dirname `$(CC) $(CFLAGS)
> > > -print-libgcc-file-name`) -lgcc
> > > endif
> > > +endif
> > > PLATFORM_LIBS += $(PLATFORM_LIBGCC)
> > > export PLATFORM_LIBS
> > >
> > > diff --git a/arch/arm/config.mk b/arch/arm/config.mk
> > > index d0cf43f..e1d0dec 100644
> > > --- a/arch/arm/config.mk
> > > +++ b/arch/arm/config.mk
> > > @@ -19,6 +19,17 @@ LDFLAGS_FINAL += --gc-sections
> > > PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections \
> > > -fno-common -ffixed-r9 -msoft-float
> > >
> > > +#
> > > +# When we use a hardfp toolchain if there are both 'libgcc.a' (hardfp)
> > > and
> > > +# 'arm-linux-gnueabi/libgcc.a' (softfp) we need to use the latter. We
> > > +# cannot always build with a hardfp-only toolchain.
> >
> > What does this last sentence mean exactly?
>
> What it says. If a hardfp only toolchain is used certain targets shall
> not link. I had Marek confirm this as well. I don't have the exact
> logs handy, but today there's a few targets that will fail, and the nand
> flash patchset introduces another because we enforce -msoft-float on
> U-Boot, and rely on libgcc from the toolchain for certain functions
> (__udivdi3 for example).
I was wondering if the sentence meant this, or if it meant "there is no
way we can ensure that we'll always build with a hardfp-only
toolchain".
Maybe the ambiguity would be lifted by saying "Building with a
hardfp-only toolchain will fail [for some targets]"?
> I don't know how you weren't making this fail on ELDK 5.x armv7a-fp, but
> I was and the Linaro 2013.03 toolchain also will show this problem.
> Once I push the nand PR (shortly), building for am3517_crane for example
> will fail without this patch.
That may be because I have several toolchains installed, one of which
is in the standard path (/usr/bin, /usr/lib, etc).
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] disk:efi: avoid unaligned access on efi partition
Hi Måns, On Mon, 14 Oct 2013 16:59:56 +0100, Måns Rullgård wrote: > Albert ARIBAUD writes: > > > Hi Måns, > > > > On Mon, 14 Oct 2013 15:09:39 +0100, Måns Rullgård > > wrote: > > > >> Albert ARIBAUD writes: > >> > >> > Hi Måns, > >> > > >> > On Mon, 14 Oct 2013 14:05:13 +0100, Måns Rullgård > >> > wrote: > >> > > >> >> Albert ARIBAUD writes: > >> >> > >> >> >> > Please do not advise using native unaligned accesses on code that > >> >> >> > is > >> >> >> > not strictly used by ARMv6+ architectures: the present code, for > >> >> >> > instance, might be run on pre-ARMv6 or non-ARM platforms, and thus, > >> >> >> > should never assume ability to perform unaligned accesses natively. > >> >> >> > >> >> >> I'm advising no such thing. I said two things: > >> >> >> > >> >> >> 1. Declaring a struct with the 'packed' attribute makes gcc > >> >> >> automatically generate correct code for all targets. _IF_ the > >> >> >> selected target supports unaligned ldr/str, these might get used. > >> >> >> > >> >> >> 2. If your target is ARMv6 or later _AND_ you enable strict > >> >> >> alignment > >> >> >> checking in the system control register, you _MUST_ build with > >> >> >> the > >> >> >> -mno-unaligned-access flag. > >> >> > > >> >> > Then I apologize; I had read "Note that on ARMv6 and later ldr/str > >> >> > support unaligned addresses unless this is explicitly disabled in > >> >> > the system control register" as a suggestion to use that capability. > >> >> > >> >> If building for ARMv6 or later, I do suggest allowing unaligned > >> >> accesses. The moment you add -march=armv6 (or equivalent), you allow > >> >> for a number of things not supported by older versions, so why not > >> >> unaligned memory accesses? > >> > > >> > doc/README.arm-unaligned-accesses probably has the answer to your > >> > question, especially from line 21 onward. If not, I'll be happy to > >> > provide further clarification. > >> > >> That is about as backwards as it can get. By adding -munaligned-access > >> you are telling gcc that unaligned accesses are supported and welcome. > >> With this setting enabled, gcc can and will generate unaligned accesses > >> just about anywhere. This setting is NOT compatible with the SCTRL.A > >> bit being set (strict hardware alignment checking). > >> > >> You cannot enable strict alignment checking in hardware, tell the > >> compiler unaligned accesses are OK, and then expect not to have > >> problems. This is no more a valid combination than allowing > >> floating-point instructions when the target has no FPU. > > > > I sense that you have not understood the reason why I want alignment > > checking enabled in ARM yet also want ARMv6+ builds to emit native > > unaligned accesses if they consider it needed. > > Your wishes are mutually exclusive. You cannot both allow hardware > unaligned access AND at the same time trap them. These are not wishes, there are actual settings chosen for the reason already laid out. They do appear contradictory if your goal is to use ARMv6+ features to their maximum, but this is not the goal here. > > The reason is, if we prevent ARMv6 builds from using native unaligned > > accesses, they would replace *all* such accesses with smaller, aligned, > > ones, which would not trigger a data abort; even those unaligned > > accesses cased by programming errors. > > If you disable unaligned accesses in hardware (as u-boot does), you have > no option but doing them a byte at a time. Indeed, but I do *not* *disable* native unaligned accesses, I *allow* them; and I do not *want* them to be replaced by byte-by-byte emulation. > > Whereas if we allow ARMv6+ builds to use native unaligned accesses, yet > > enable alignment checks, then any native unaligned access will be > > caught as early as possible, and we'll find and cure the issue faster. > > > > This is, of course, assuming we don't voluntarily do native unaligned > > accesses, and in U-Boot, we indeed don't: in U-Boot, accesses are done > > on natural alignments. > > The hardware does not differentiate between intentional and > unintentional unaligned accesses. Unlike some architectures, which have > dedicated instructions for unaligned accesses, ARM uses the same > instructions in both cases (with some limitations). Indeed, the hardware does not differentiate between intentional vs unintentional unaligned accesses, which is why I decided that rather than suffer the latter, we should trap them both and fix them according to their nature: intentional ones get replaced by emulation, and the cause of unintentional ones gets fixed. > > Since I have set up this policy, experience (and it has been a while) > > shows that very few problems arise from alignment checks + native > > unaligned accesses. These roughly come from hardware- or standards- > > mandated unaligned fields, in which case they are worth explicitly > > accessing with "unaligned" macros, or from programming errors, wh
Re: [U-Boot] [RFC] i2c_reloc_fixup fails on m68k
On Tuesday 24 September 2013 02:33:55 Heiko Schocher wrote: > Am 23.09.2013 15:50, schrieb Jens Scharsig: > > Hello, > > > > I have a access violation problem with i2c_reloc_fixup on coldfire > > m68k systems. > > > > I found out, the i2c_reloc_fixup tries to relocate the adapter itself, > > but at this time i2c_adap_p is already relocated. > > Which toolchain? > > > Can anybody confirm this? > > Added Mike Frysinger, Sonic Zhang (for blackfin) Jason Jin (for m68k) > and Macpaul Lin (for nds32) to Cc ... > > > I think also m68k, backfin and nds32 systems are affected > > Sorry, I have no such system ... maybe you are the first who stepped > in it ... Blackfin doesn't do self-relocation like that, so we don't care :) -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] u-boot-xlnx 'master-next' branch: usb not working for microzed
Hi, I've been working with xilinx's microzed board (zynq) recently. The actual goal is a fsbl-less u-boot. But even with fsbl - USB is not working in u-boot-xlnx 'master-next' branch. At the same time it works in the 'master'. Mostly interested in 'master-next'. Has anyone tried USB in the 'master-next' for microzed/zedboard? OS: Ubuntu 13.04 x64 board: MicroZed u-boot-xlnx 'master-next' rev: bbd91fc9ae290c31dc52fd8322f43f67ddd39247 u-boot-xlnx 'master' rev: 0f6dbff16b792a106f52ca37f4503335af30601b cross-tools: cross compiler built with yocto poky: > export CROSS_COMPILE=arm-poky-linux-gnueabi- > export > PATH=/opt/poky/1.4.2/sysroots/x86_64-pokysdk-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/:$PATH incorrect output: > ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver > ehci-pci: EHCI PCI platform driver correct output: > Found SMSC USB3320 ULPI transceiver. > ULPI integrity check: passed. > xusbps-ehci xusbps-ehci.0: Xilinx PS USB EHCI Host Controller > xusbps-ehci xusbps-ehci.0: new USB bus registered, assigned bus number 1 > xusbps-ehci xusbps-ehci.0: irq 53, io mem 0x > xusbps-ehci xusbps-ehci.0: USB 2.0 started, EHCI 1.00 Thanks -- View this message in context: http://u-boot.10912.n7.nabble.com/u-boot-xlnx-master-next-branch-usb-not-working-for-microzed-tp165384.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] u-boot-xlnx/master-next: build error
Hi, Building u-boot-xlnx/master-next:4cb9c3de73d66372d40d24baf82fa87a702f0c9b throws an error: > lowlevel_init.S: Assembler messages: > lowlevel_init.S:35: Error: selected processor does not support ARM mode > `fmrx r1,FPEXC' > lowlevel_init.S:37: Error: selected processor does not support ARM mode > `fmxr FPEXC,r1' > make[1]: *** [lowlevel_init.o] Error 1 OS: Ubuntu 13.04 x64 target: zynq_zed_config cross-tools: cross compiler built with yocto poky: > export CROSS_COMPILE=arm-poky-linux-gnueabi- > export > PATH=/opt/poky/1.4.2/sysroots/x86_64-pokysdk-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/:$PATH > Thanks -- View this message in context: http://u-boot.10912.n7.nabble.com/u-boot-xlnx-master-next-build-error-tp165385.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] declaring and initializing variables
On 10/07/2013 03:03 PM, Kim Phillips wrote: > On Mon, 30 Sep 2013 17:04:33 -0700 > York Sun wrote: > >> Kim, et al., >> >> I know I have asked this before. Pardon me as I don't consider myself a >> savy programmer. >> >> I am cleaning up the DDR driver for mpc83xx, mpc85xx and mpc86xx. The >> question is the accetable formats of declaring and initializing variable >> at the same time. The variables are the ccsr register pointers. I have >> two formats here >> >> struct ccsr_ddr __iomem *ddr = (void *) CONFIG_FOO_ADDR; >> struct ccsr_ddr __iomem *ddr = >> (struct ccsr_ddr __iomem *) CONFIG_FOO_ADDR; >> >> You have told me the second format is preferred. I have been using this >> format since. But in practice, the second format is often too long and I >> have to wrap to next line. It's not a problem for new code. As I am >> trying to cleanup the existing code, I would have to make more changes. >> So I am back to this question. Is the first format (using void *) >> accetable in long term? > > you're not running sparse, are you? :) > > Use 'make C=1' or 'MAKEALL -C' when building u-boot. > I see what you mean. We have so many issue with existing code. Is it practical to enforce? York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-xlnx/master-next: build error
Hi Oleg, On Mon, 14 Oct 2013 11:54:18 -0700 (PDT), Oleg Dzhimiev wrote: > Hi, > > Building u-boot-xlnx/master-next:4cb9c3de73d66372d40d24baf82fa87a702f0c9b > throws an error: > > lowlevel_init.S: Assembler messages: > > lowlevel_init.S:35: Error: selected processor does not support ARM mode > > `fmrx r1,FPEXC' > > lowlevel_init.S:37: Error: selected processor does not support ARM mode > > `fmxr FPEXC,r1' > > make[1]: *** [lowlevel_init.o] Error 1 > > OS: Ubuntu 13.04 x64 > target: zynq_zed_config > cross-tools: cross compiler built with yocto poky: > > export CROSS_COMPILE=arm-poky-linux-gnueabi- > > export > > PATH=/opt/poky/1.4.2/sysroots/x86_64-pokysdk-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/:$PATH > > > > Thanks U-boot-xlnx is not a sub-repo of the official U-Boot; it is Xilinx' own version, located at https://github.com/Xilinx/u-boot-xlnx. I suggest you ask the Xilinx folks about it. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] env_mmc: fix buffer allocation for armv7
On Fri, Oct 04, 2013 at 03:48:03PM +0200, Markus Niebel wrote: > From: Markus Niebel > > commit d196bd880347373237d73e0d115b4d51c68cf2ad adds > redundand environment to mmc. The usage of malloc in > env_relocate_spec triggers cache errors on armv7. > > Tested on a not mainlined i.MX53 board: > > Board: TQMa53 > I2C: ready > DRAM: 512 MiB > MMC: FSL_SDHC: 0, FSL_SDHC: 1 > ERROR: v7_dcache_inval_range - start address is not aligned - 0x8f57c2d8 > ERROR: v7_dcache_inval_range - stop address is not aligned - 0x8f57e2d8 > ERROR: v7_dcache_inval_range - start address is not aligned - 0x8f57e2e0 > ERROR: v7_dcache_inval_range - stop address is not aligned - 0x8f5802e0 > Using default environment > > Signed-off-by: Markus Niebel Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] pmic: max77686: fix the wrong offset
On Mon, Sep 30, 2013 at 02:23:37PM +0900, Jaehoon Chung wrote: > 0x1D is reserved. So BUCK3DVS1 is started from 0x1e. > > Signed-off-by: Jaehoon Chung Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/4, V2] Coding Style cleanup: remove trailing white space
On Mon, Oct 07, 2013 at 01:07:26PM +0200, Wolfgang Denk wrote: > Signed-off-by: Wolfgang Denk > > --- > Changes in V2: > - dropped incorrect modifications to > tools/easylogo/linux_blackfin.tga and > tools/easylogo/linux_logo.tga > Cudos to Michal Simek for pointing out. Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/4] Coding Style cleanup: replace leading SPACEs by TABs
On Fri, Oct 04, 2013 at 05:43:24PM +0200, Wolfgang Denk wrote: > Signed-off-by: Wolfgang Denk With the change to dropping the changes to python tools that follow PEP 4 for an indentation method (if we want to convert them, we need to do it fully, this did not), applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 3/4] Coding Style cleanup: remove trailing empty lines
On Fri, Oct 04, 2013 at 05:43:25PM +0200, Wolfgang Denk wrote: > Signed-off-by: Wolfgang Denk Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 4/4] Coding Style cleanup: drop some excessive empty lines
On Fri, Oct 04, 2013 at 05:43:26PM +0200, Wolfgang Denk wrote: > Signed-off-by: Wolfgang Denk Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] env: dataflash: fix env_init issue
On Tue, Oct 08, 2013 at 04:30:21PM +0800, Bo Shen wrote: > As the SPI controller is not initialized before env_init(), it causes > reading env in dataflash failed. So, although saveenv() successfully, > it shows warning information when reboot the system as following: > > *** Warning - bad CRC, using default environment > > Let the env_relocate() to check env CRC and import it. > > Signed-off-by: Bo Shen Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: omap4: Update sdram setting for panda rev A6
On Wed, Oct 09, 2013 at 01:53:58PM -0500, Dan Murphy wrote: > OMAP4 panda rev A6 is a 4430 es2.3 IC with an updated memory > part. > > The panda rev A6 uses Elpida 2x4Gb memory and no longer uses Micron > so the timings needs to be updated > > Signed-off-by: Dan Murphy Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPDX: document dual license notation
On Tue, Oct 08, 2013 at 09:53:45PM +0200, Wolfgang Denk wrote: > In [1] we discussed how we should deal with dual (or, more generally, > multiple) licensed files. Add this to Licenses/README so it's > properly documented. > > [1] http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/166518 > > Signed-off-by: Wolfgang Denk Applied to u-boot/master with an ammendment of "list" as per Stephen's suggestion to the line in question, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] am335x_evm.h: Make 'am335x_boneblack' use redundant environment
On Thu, Oct 10, 2013 at 10:25:18AM -0400, Tom Rini wrote: > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] .gitignore: add auto-generated /include/[s|t]pl-autoconf.mk
On Sun, Oct 13, 2013 at 05:08:02PM +0200, Daniel Schwierzeck wrote: > Signed-off-by: Daniel Schwierzeck Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2] ARM: omap4-panda: Add MAC address creation for panda
On Thu, Oct 10, 2013 at 08:54:23AM -0500, Dan Murphy wrote: > Add a MAC address create based on the OMAP die ID registers. > Then poplulate the ethaddr enviroment variable so that the device > tree alias can be updated prior to boot. > > Signed-off-by: Dan Murphy Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v14 04/10] arm64: Add tool to statically apply RELA relocations
On Sat, 2013-10-12 at 16:14 +0800, feng...@phytium.com.cn wrote: > From: David Feng Please fix the From: line on patches which are from me. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-x86 buildman
On Thu, Oct 10, 2013 at 02:50:25PM -0600, Simon Glass wrote: > Hi Tom, > > The following changes since commit 99b4eaa68e0e2fdd9b0d0b1d40809d7e8f92044f: > > usb: Prevent using reserved registers on DM36x usb (2013-10-10 07:58:00 > -0400) > > are available in the git repository at: > > http://git.denx.de/u-boot-x86.git buildman > > for you to fetch changes up to 8bb2bddc2c18a3643ce53e793d5bc27a40e98a4f: > > buildman: don't fail --list-toolchains when toolchains fail > (2013-10-10 10:40:42 -0600) > > > Stephen Warren (1): > buildman: don't fail --list-toolchains when toolchains fail > > tools/buildman/toolchain.py | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Prevent null pointer dereference originating in cmd_pxe.c
On Mon, Oct 07, 2013 at 09:51:48AM -0400, Steven Falco wrote: > Pass a valid cmdtp into do_tftpb(), do_ext2load(), and do_get_fat(), to avoid > possible crashes due to null pointer dereferencing. > > Signed-off-by: Steven A. Falco > > --- > > This doesn't apply cleanly, nor with --ignore-whitespace for me. Can > > you please re-check and re-send the patch? Thanks. > > Sorry - I've been having trouble getting Thunderbird to leave my text > alone. There was some insane "flowed text" setting that I just discovered > and disabled. > > I think I've got it right now. I'll download this email from the list > after I post it, and do a diff to be sure. > > Commit d7884e047d08447dfd1374e9fa2fdf7ab36e56f5 does not go far enough. There > is still at least one call chain that can result in a crash. > > The do_tftpb(), do_ext2load(), and do_get_fat() functions expect a valid > cmdtp. > Passing in NULL is particularly bad in the do_tftpb() case, because eventually > boot_get_kernel() will be called with a NULL cmdtp: > > do_tftpb() -> netboot_common() -> bootm_maybe_autostart() -> do_bootm() -> > do_bootm_states() -> bootm_find_os() -> boot_get_kernel() > > Around line 991 in cmd_bootm.c, boot_get_kernel() will dereference the null > pointer, and the board will crash. With a reworded commit message to include more details, applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd_sandbox.c: Update for do_(load|save) not taking a number base
On Thu, Oct 10, 2013 at 10:46:56AM -0400, Tom Rini wrote: > Signed-off-by: Tom Rini > --- > common/cmd_sandbox.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Applied to u-boot/master -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 0/2] add sdhci generic framework
Hello Lei, I am looking into adding eMMC support for some intel SDHCI controllers based on this common SDHCI driver submission. One thing which is not quite clear is the quirks - can you (or somebody else on this list) please shed some light on what the quirks are. Is there some kind of formal description/definition of various defined quirks and their processing. Thank you in advance, --vb On Wed, Jun 29, 2011 at 12:50 AM, Lei Wen wrote: > V1: > add sdhci generic framework and with marvell sdhci implementation > > V2: > rename the previous file name from sdhci-mv to mv_sdhci > > Lei Wen (2): > MMC: add sdhci generic framework > MMC: add marvell sdhci driver > > drivers/mmc/Makefile |2 + > drivers/mmc/mv_sdhci.c | 21 +++ > drivers/mmc/sdhci.c| 433 > > include/sdhci.h| 325 > 4 files changed, 781 insertions(+), 0 deletions(-) > create mode 100644 drivers/mmc/mv_sdhci.c > create mode 100644 drivers/mmc/sdhci.c > create mode 100644 include/sdhci.h > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] serial: mxs_auart: Staticize local functions
Staticize local functions in mxs_auart driver.
Signed-off-by: Axel Lin
---
drivers/serial/mxs_auart.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/serial/mxs_auart.c b/drivers/serial/mxs_auart.c
index 7cfe5bc..fc0fa96 100644
--- a/drivers/serial/mxs_auart.c
+++ b/drivers/serial/mxs_auart.c
@@ -40,7 +40,7 @@ static struct mxs_uartapp_regs *get_uartapp_registers(void)
* Sets the baud rate and settings.
* The settings are: 8 data bits, no parit and 1 stop bit.
*/
-void mxs_auart_setbrg(void)
+static void mxs_auart_setbrg(void)
{
u32 div;
u32 linectrl = 0;
@@ -77,7 +77,7 @@ void mxs_auart_setbrg(void)
writel(linectrl, ®s->hw_uartapp_linectrl);
}
-int mxs_auart_init(void)
+static int mxs_auart_init(void)
{
struct mxs_uartapp_regs *regs = get_uartapp_registers();
/* Reset everything */
@@ -99,7 +99,7 @@ int mxs_auart_init(void)
return 0;
}
-void mxs_auart_putc(const char c)
+static void mxs_auart_putc(const char c)
{
struct mxs_uartapp_regs *regs = get_uartapp_registers();
/* Wait in loop while the transmit FIFO is full */
@@ -112,14 +112,14 @@ void mxs_auart_putc(const char c)
mxs_auart_putc('\r');
}
-int mxs_auart_tstc(void)
+static int mxs_auart_tstc(void)
{
struct mxs_uartapp_regs *regs = get_uartapp_registers();
/* Checks if receive FIFO is empty */
return !(readl(®s->hw_uartapp_stat) & UARTAPP_STAT_RXFE_MASK);
}
-int mxs_auart_getc(void)
+static int mxs_auart_getc(void)
{
struct mxs_uartapp_regs *regs = get_uartapp_registers();
/* Wait until a character is available to read */
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 0/2] add sdhci generic framework
Hi Vadim, The quirk is standing for some workaround for those host that has some limitation that it cannot directly be applied with standard sdhci.c code, so that we add one quirk for it, which let it could use the sdhci.c. Like the quirk as SDHCI_QUIRK_32BIT_DMA_ADDR, it indicate that some host has dma engine limitation that it must start from address with alignement. So if sdhci find caller set this quirk, it would follow corresponding workaround for it. There is no formal description for it as I could see. Thanks, Lei > -Original Message- > From: vben...@gmail.com [mailto:vben...@gmail.com] On Behalf Of Vadim > Bendebury > Sent: Tuesday, October 15, 2013 10:09 AM > To: Lei Wen > Cc: Prafulla Wadaskar; aflem...@gmail.com; Rob Herring; u- > b...@lists.denx.de; Yu Tang; Prabhanjan Sarnaik; Ashish Karkare; Andy > Fleming > Subject: Re: [U-Boot] [PATCH V2 0/2] add sdhci generic framework > > Hello Lei, > > I am looking into adding eMMC support for some intel SDHCI controllers > based on this common SDHCI driver submission. > > One thing which is not quite clear is the quirks - can you (or somebody > else on this list) please shed some light on what the quirks are. Is > there some kind of formal description/definition of various defined > quirks and their processing. > > Thank you in advance, > > --vb > > > On Wed, Jun 29, 2011 at 12:50 AM, Lei Wen wrote: > > V1: > > add sdhci generic framework and with marvell sdhci implementation > > > > V2: > > rename the previous file name from sdhci-mv to mv_sdhci > > > > Lei Wen (2): > > MMC: add sdhci generic framework > > MMC: add marvell sdhci driver > > > > drivers/mmc/Makefile |2 + > > drivers/mmc/mv_sdhci.c | 21 +++ > > drivers/mmc/sdhci.c| 433 > > > include/sdhci.h| 325 > > 4 files changed, 781 insertions(+), 0 deletions(-) create mode > > 100644 drivers/mmc/mv_sdhci.c create mode 100644 drivers/mmc/sdhci.c > > create mode 100644 include/sdhci.h > > > > ___ > > U-Boot mailing list > > U-Boot@lists.denx.de > > http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RESEND PATCH v14 03/10] add weak entry definition
From: David Feng Signed-off-by: David Feng --- include/linux/linkage.h |4 1 file changed, 4 insertions(+) diff --git a/include/linux/linkage.h b/include/linux/linkage.h index 9ddf830..2a2848a 100644 --- a/include/linux/linkage.h +++ b/include/linux/linkage.h @@ -49,6 +49,10 @@ .globl SYMBOL_NAME(name); \ LENTRY(name) +#define WEAK(name) \ + .weak SYMBOL_NAME(name); \ + LENTRY(name) + #ifndef END #define END(name) \ .size name, .-name -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RESEND PATCH v14 00/10] arm64 pat
From: David Feng The content is same with original v14. 04/05/06 patches is totally provided by scott wood. Them are mistakenly encoded "From: David Feng", so modify its to "From: Scott Wood". Changes for v14: - Merge rela relocation patches from Scott Wood . - Remove all CONFIG_NEED_MANUAL_RELOC and other fixups due to manual relocation. With rela relocation patches them are not needed. - Fix the bug of MEMORY_ATTRIBUTES definition due to assembler. That need put brackets around (MT_NORMAL*8). Otherwise the result is wrong.This bug is reported by York Sun . - -msoft-float is not supported by aarch64-gcc, make a test though $(call cc-option,-msoft-float). - Adjust the virtual address space to 42 bits. - Filter armv8 boards from LIST_arm in MAKEALL. - remove gpio.h in asm/arch-armv8/ and move mmu.h to asm/armv8/ directory. - remove vexpress64.dts from this patch, it could be accessed from linux kernel. Changes for v13: - fix the bug of board_r.c and arm/lib/board.c due to CONFIG_NEED_MANUAL_RELOC. adjust initr_serial() in board_r.c to the first entry of init_sequence_r[] and relocate serial_initialize() in arm/lib/board.c, routines of serial_device should be relocated firstly by serial_initialize(), so that printf access the correct puts function, otherwise uninitialized serial_current will be selected as the output device. - fix the bug of dcache_enable(). after mmu_setup the sctrl register value should be fetched again because it has been modifed by mmu_seup() function. This bug is reported by York Sun . - add macro branch_if_slave to macro.h, it choose processor with all zero affinity value as the master and is used in start.S. Changes for v12: - custom the patches to new format boards.cfg. Changes for v11: - Replace CONFIG_ARMV8 with CONFIG_ARM64. Currently, it's hard to distinguish what is armv8 specific and what is aarch64 specific, so we use CONFIG_ARM64 only, no CONFIG_ARMV8 used. - rename README.armv8 with README.arm64 and make some modification. Changes for v10: - add weak definition to include/linux/linkage.h and make setup_el2/setup_el3/lowlevel_init weak routines, so them can be easily overridden by processor specific code. - modify s-o-f of 0002-board-support-of-vexpress_aemv8a which use wrong mail address of Bhupesh Sharma. Changes for v9: - add Signed-off-by information to patch "board support of vexpress_aemv8a" which SMC9 support is integrated from Sharma Bhupesh's patch. - adjust pt_regs struct and add exception state preservation in exception.S. Changes for v8: - Integrate SMC9 patch of sharma bhupesh. - remove v8_outer_cache* which is not need currently. - Change license tag. - Mov crt0.S/relocate.S/interrupts.c to arm/lib and rename them with _64 suffix. - Make el3/el2 initializing process of start.S as two separate routines. It could be easier to be replaced with processor specific codes. - Remove exception stack save and restore routine, it is unnecessary now. - simplify __weak function declaration. Changes for v7: - Check the patches with checkpatch.pl and get rid of almost all warnings. There are a few warnings still, but I think it should be that. - change printf format in cmd_pxe.c, use %zd indtead of %ld to format size_t type variable. - add macro PGTABLE_SIZE to identify tlb table size. Changes for v6: - Make modification to inappropriate licensed file and bugs according to ScottWood's advice. Thanks Scott for his checking to these patches. - Enable u-boot's running at EL1. - Get rid of compiling warnings originated from cmd_pxe.c. Changes for v5: - fix the generic board_f.c, remove zero_global_data from init_sequence_f array and move it to board_init_f() function with CONFIG_X86 switch. The previous fixup is inaccurate. - Replace __ARMEB__ with __AARCH64EB__ in byteorder.h and unaligned.h, gcc for aarch64 use __AARCH64EB__ and __AARCH64EL__ to identify endian. - Some modification to README.armv8 Changes for v4: - merge arm64 to arm architecture. David Feng (10): fdt_support: 64bit initrd start address support cmd_pxe.c: remove compiling warnings add weak entry definition arm64: Add tool to statically apply RELA relocations arm64: Turn u-boot.bin back into an ELF file after relocate-rela arm64: Make checkarmreloc accept arm64 relocations arm64: core support arm64: generic board support arm64: board support of vexpress_aemv8a arm64: MAKEALL, filter armv8 boards from LIST_arm MAKEALL | 13 +- Makefile| 39 +- arch/arm/config.mk |3 +- arch/arm/cpu/armv8/Makefile | 38 + arch/arm/cpu/armv8/cache.S | 130 + arch/arm/cpu/armv8/cache_v8.c | 218 +++
[U-Boot] [RESEND PATCH v14 06/10] arm64: Make checkarmreloc accept arm64 relocations
From: Scott Wood Signed-off-by: Scott Wood Signed-off-by: David Feng --- Makefile | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/Makefile b/Makefile index 86464c9..edf52f2 100644 --- a/Makefile +++ b/Makefile @@ -805,12 +805,16 @@ tools: $(VERSION_FILE) $(TIMESTAMP_FILE) $(MAKE) -C $@ all endif # config.mk -# ARM relocations should all be R_ARM_RELATIVE. +# ARM relocations should all be R_ARM_RELATIVE (32-bit) or +# R_AARCH64_RELATIVE (64-bit). checkarmreloc: $(obj)u-boot - @if test "R_ARM_RELATIVE" != \ - "`$(CROSS_COMPILE)readelf -r $< | cut -d ' ' -f 4 | grep R_ARM | sort -u`"; \ - then echo "$< contains relocations other than \ - R_ARM_RELATIVE"; false; fi + @RELOC="`$(CROSS_COMPILE)readelf -r -W $< | cut -d ' ' -f 4 | \ + grep R_A | sort -u`"; \ + if test "$$RELOC" != "R_ARM_RELATIVE" -a \ +"$$RELOC" != "R_AARCH64_RELATIVE"; then \ + echo "$< contains unexpected relocations: $$RELOC"; \ + false; \ + fi $(VERSION_FILE): @mkdir -p $(dir $(VERSION_FILE)) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RESEND PATCH v14 05/10] arm64: Turn u-boot.bin back into an ELF file after relocate-rela
From: Scott Wood While performing relocations on u-boot.bin should be good enough for booting on real hardware, some simulators insist on booting an ELF file (and yet don't perform ELF relocations), so convert the relocated binary back into an ELF file. This can go away in the future if we change relocate-rela to operate directly on the ELF file, or if and when we stop caring about a simulator with this restriction. Signed-off-by: Scott Wood Signed-off-by: David Feng --- Makefile | 13 + 1 file changed, 13 insertions(+) diff --git a/Makefile b/Makefile index 5dd28a9..86464c9 100644 --- a/Makefile +++ b/Makefile @@ -415,6 +415,7 @@ ALL-$(CONFIG_OF_SEPARATE) += $(obj)u-boot.dtb $(obj)u-boot-dtb.bin ifneq ($(CONFIG_SPL_TARGET),) ALL-$(CONFIG_SPL) += $(obj)$(subst ",,$(CONFIG_SPL_TARGET)) endif +ALL-$(CONFIG_REMAKE_ELF) += $(obj)u-boot.elf # enable combined SPL/u-boot/dtb rules for tegra ifneq ($(CONFIG_TEGRA),) @@ -581,6 +582,18 @@ $(obj)u-boot-img-spl-at-end.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.img conv=notrunc 2>/dev/null cat $(obj)u-boot-pad.img $(obj)spl/u-boot-spl.bin > $@ +# Create a new ELF from a raw binary file. This is useful for arm64 +# where static relocation needs to be performed on the raw binary, +# but certain simulators only accept an ELF file (but don't do the +# relocation). +# FIXME refactor dts/Makefile to share target/arch detection +$(obj)u-boot.elf: $(obj)u-boot.bin + @$(OBJCOPY) -B aarch64 -I binary -O elf64-littleaarch64 \ + $< $(obj)u-boot-elf.o + @$(LD) $(obj)u-boot-elf.o -o $@ \ + --defsym=_start=$(CONFIG_SYS_TEXT_BASE) \ + -Ttext=$(CONFIG_SYS_TEXT_BASE) + ifeq ($(CONFIG_SANDBOX),y) GEN_UBOOT = \ cd $(LNDIR) && $(CC) $(SYMS) -T $(obj)u-boot.lds \ -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RESEND PATCH v14 04/10] arm64: Add tool to statically apply RELA relocations
From: Scott Wood
ARM64 uses the newer RELA-style relocations rather than the older REL.
RELA relocations have an addend in the relocation struct, rather than
expecting the loader to read a value from the location to be updated.
While this is beneficial for ordinary program loading, it's problematic
for U-Boot because the location to be updated starts out with zero,
rather than a pre-relocation value. Since we need to be able to run C
code before relocation, we need a tool to apply the relocations at
build time.
In theory this tool is applicable to other newer architectures (mainly
64-bit), but currently the only relocations it supports are for arm64,
and it assumes a 64-bit little-endian target. If the latter limitation
is ever to be changed, we'll need a way to tell the tool what format
the image is in. Eventually this may be replaced by a tool that uses
libelf or similar and operates directly on the ELF file. I've written
some code for such an approach but libelf does not make it easy to poke
addresses by memory address (rather than by section), and I was
hesitant to write code to manually parse the program headers and do the
update outside of libelf (or to iterate over sections) -- especially
since it wouldn't get test coverage on things like binaries with
multiple PT_LOAD segments. This should be good enough for now to let
the manual relocation stuff be removed from the arm64 patches.
NOTE: Please make sure R_AARCH64_RELATIVE is defined at system include
files or manually defined. Otherwise, the rela relocation will
not apply.
Signed-off-by: Scott Wood
Signed-off-by: David Feng
---
Makefile | 12
tools/Makefile|6 ++
tools/relocate-rela.c | 185 +
3 files changed, 203 insertions(+)
create mode 100644 tools/relocate-rela.c
diff --git a/Makefile b/Makefile
index b09bfcc..5dd28a9 100644
--- a/Makefile
+++ b/Makefile
@@ -392,6 +392,17 @@ else
BOARD_SIZE_CHECK =
endif
+# Statically apply RELA-style relocations (currently arm64 only)
+ifneq ($(CONFIG_STATIC_RELA),)
+# $(1) is u-boot ELF, $(2) is u-boot bin, $(3) is text base
+DO_STATIC_RELA = \
+ start=$$($(NM) $(1) | grep __rel_dyn_start | cut -f 1 -d ' '); \
+ end=$$($(NM) $(1) | grep __rel_dyn_end | cut -f 1 -d ' '); \
+ $(obj)tools/relocate-rela $(2) $(3) $$start $$end
+else
+DO_STATIC_RELA =
+endif
+
# Always append ALL so that arch config.mk's can add custom ones
ALL-y += $(obj)u-boot.srec $(obj)u-boot.bin $(obj)System.map
@@ -431,6 +442,7 @@ $(obj)u-boot.srec: $(obj)u-boot
$(obj)u-boot.bin: $(obj)u-boot
$(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
+ $(call DO_STATIC_RELA,$<,$@,$(CONFIG_SYS_TEXT_BASE))
$(BOARD_SIZE_CHECK)
$(obj)u-boot.ldr: $(obj)u-boot
diff --git a/tools/Makefile b/tools/Makefile
index c36cde2..a5eb85e 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -59,6 +59,7 @@ BIN_FILES-$(CONFIG_NETCONSOLE) += ncb$(SFX)
BIN_FILES-$(CONFIG_SHA1_CHECK_UB_IMG) += ubsha1$(SFX)
BIN_FILES-$(CONFIG_KIRKWOOD) += kwboot$(SFX)
BIN_FILES-y += proftool(SFX)
+BIN_FILES-$(CONFIG_STATIC_RELA) += relocate-rela$(SFX)
# Source files which exist outside the tools directory
EXT_OBJ_FILES-$(CONFIG_BUILD_ENVCRC) += common/env_embedded.o
@@ -84,6 +85,7 @@ NOPED_OBJ_FILES-y += os_support.o
NOPED_OBJ_FILES-y += pblimage.o
NOPED_OBJ_FILES-y += proftool.o
NOPED_OBJ_FILES-y += ublimage.o
+NOPED_OBJ_FILES-y += relocate-rela.o
OBJ_FILES-$(CONFIG_BUILD_ENVCRC) += envcrc.o
OBJ_FILES-$(CONFIG_CMD_LOADS) += img2srec.o
OBJ_FILES-$(CONFIG_CMD_NET) += gen_eth_addr.o
@@ -250,6 +252,10 @@ $(obj)kwboot$(SFX): $(obj)kwboot.o
$(HOSTCC) $(HOSTCFLAGS) $(HOSTLDFLAGS) -o $@ $^
$(HOSTSTRIP) $@
+$(obj)relocate-rela$(SFX): $(obj)relocate-rela.o
+ $(HOSTCC) $(HOSTCFLAGS) $(HOSTLDFLAGS) -o $@ $^
+ $(HOSTSTRIP) $@
+
# Some of the tool objects need to be accessed from outside the tools directory
$(obj)%.o: $(SRCTREE)/common/%.c
$(HOSTCC) -g $(HOSTCFLAGS_NOPED) -c -o $@ $<
diff --git a/tools/relocate-rela.c b/tools/relocate-rela.c
new file mode 100644
index 000..47afe0b
--- /dev/null
+++ b/tools/relocate-rela.c
@@ -0,0 +1,185 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+ BSD-2-Clause
+ *
+ * 64-bit and little-endian target only until we need to support a different
+ * arch that needs this.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static const bool debug_en;
+
+static void debug(const char *fmt, ...)
+{
+ va_list args;
+
+ va_start(args, fmt);
+ if (debug_en)
+ vprintf(fmt, args);
+}
+
+static bool supported_rela(Elf64_Rela *rela)
+{
+ uint64_t mask = 0xULL; /* would be different on 32-bit */
+ uint32_t type = rela->r_info & mask;
+
+ switch (type) {
+#ifdef R_AARCH64_RELATIVE
+ c
[U-Boot] [RESEND PATCH v14 10/10] arm64: MAKEALL, filter armv8 boards from LIST_arm
From: David Feng Signed-off-by: David Feng --- MAKEALL | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/MAKEALL b/MAKEALL index 956f3da..cb414ca 100755 --- a/MAKEALL +++ b/MAKEALL @@ -370,6 +370,12 @@ LIST_ARM11="$(boards_by_cpu arm1136) \ LIST_ARMV7="$(boards_by_cpu armv7)" # +## ARMV8 Systems +# + +LIST_ARMV8="$(boards_by_cpu armv8)" + +# ## AT91 Systems # @@ -393,7 +399,11 @@ LIST_spear="$(boards_by_soc spear)" ## ARM groups # -LIST_arm="$(boards_by_arch arm)" +LIST_arm="$(boards_by_arch arm | \ + for ARMV8_BOARD in $LIST_ARMV8; \ + do sed "/$ARMV8_BOARD/d"; \ + done) \ +" # ## MIPS Systems(default = big endian) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RESEND PATCH v14 01/10] fdt_support: 64bit initrd start address support
From: David Feng
Signed-off-by: David Feng
---
common/fdt_support.c | 66 ++
1 file changed, 34 insertions(+), 32 deletions(-)
diff --git a/common/fdt_support.c b/common/fdt_support.c
index b034c98..9bc5821 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -21,6 +21,34 @@
*/
DECLARE_GLOBAL_DATA_PTR;
+/*
+ * Get cells len in bytes
+ * if #-cells property is 2 then len is 8
+ * otherwise len is 4
+ */
+static int get_cells_len(void *blob, char *nr_cells_name)
+{
+ const fdt32_t *cell;
+
+ cell = fdt_getprop(blob, 0, nr_cells_name, NULL);
+ if (cell && fdt32_to_cpu(*cell) == 2)
+ return 8;
+
+ return 4;
+}
+
+/*
+ * Write a 4 or 8 byte big endian cell
+ */
+static void write_cell(u8 *addr, u64 val, int size)
+{
+ int shift = (size - 1) * 8;
+ while (size-- > 0) {
+ *addr++ = (val >> shift) & 0xff;
+ shift -= 8;
+ }
+}
+
/**
* fdt_getprop_u32_default - Find a node and return it's property or a default
*
@@ -131,9 +159,9 @@ static int fdt_fixup_stdout(void *fdt, int chosenoff)
int fdt_initrd(void *fdt, ulong initrd_start, ulong initrd_end, int force)
{
- int nodeoffset;
+ int nodeoffset, addr_cell_len;
int err, j, total;
- fdt32_t tmp;
+ fdt64_t tmp;
const char *path;
uint64_t addr, size;
@@ -170,9 +198,11 @@ int fdt_initrd(void *fdt, ulong initrd_start, ulong
initrd_end, int force)
return err;
}
+ addr_cell_len = get_cells_len(fdt, "#address-cells");
+
path = fdt_getprop(fdt, nodeoffset, "linux,initrd-start", NULL);
if ((path == NULL) || force) {
- tmp = cpu_to_fdt32(initrd_start);
+ write_cell((u8 *)&tmp, initrd_start, addr_cell_len);
err = fdt_setprop(fdt, nodeoffset,
"linux,initrd-start", &tmp, sizeof(tmp));
if (err < 0) {
@@ -181,7 +211,7 @@ int fdt_initrd(void *fdt, ulong initrd_start, ulong
initrd_end, int force)
fdt_strerror(err));
return err;
}
- tmp = cpu_to_fdt32(initrd_end);
+ write_cell((u8 *)&tmp, initrd_end, addr_cell_len);
err = fdt_setprop(fdt, nodeoffset,
"linux,initrd-end", &tmp, sizeof(tmp));
if (err < 0) {
@@ -343,34 +373,6 @@ void do_fixup_by_compat_u32(void *fdt, const char *compat,
do_fixup_by_compat(fdt, compat, prop, &tmp, 4, create);
}
-/*
- * Get cells len in bytes
- * if #-cells property is 2 then len is 8
- * otherwise len is 4
- */
-static int get_cells_len(void *blob, char *nr_cells_name)
-{
- const fdt32_t *cell;
-
- cell = fdt_getprop(blob, 0, nr_cells_name, NULL);
- if (cell && fdt32_to_cpu(*cell) == 2)
- return 8;
-
- return 4;
-}
-
-/*
- * Write a 4 or 8 byte big endian cell
- */
-static void write_cell(u8 *addr, u64 val, int size)
-{
- int shift = (size - 1) * 8;
- while (size-- > 0) {
- *addr++ = (val >> shift) & 0xff;
- shift -= 8;
- }
-}
-
#ifdef CONFIG_NR_DRAM_BANKS
#define MEMORY_BANKS_MAX CONFIG_NR_DRAM_BANKS
#else
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RESEND PATCH v14 02/10] cmd_pxe: remove compiling warnings
From: David Feng
Signed-off-by: David Feng
---
common/cmd_pxe.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/common/cmd_pxe.c b/common/cmd_pxe.c
index c5f4a22..1df9a8a 100644
--- a/common/cmd_pxe.c
+++ b/common/cmd_pxe.c
@@ -57,7 +57,7 @@ static int format_mac_pxe(char *outbuf, size_t outbuf_len)
uchar ethaddr[6];
if (outbuf_len < 21) {
- printf("outbuf is too small (%d < 21)\n", outbuf_len);
+ printf("outbuf is too small (%zd < 21)\n", outbuf_len);
return -EINVAL;
}
@@ -100,7 +100,7 @@ static int get_bootfile_path(const char *file_path, char
*bootfile_path,
path_len = (last_slash - bootfile) + 1;
if (bootfile_path_size < path_len) {
- printf("bootfile_path too small. (%d < %d)\n",
+ printf("bootfile_path too small. (%zd < %zd)\n",
bootfile_path_size, path_len);
return -1;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RESEND PATCH v14 07/10] arm64: core support
From: David Feng Relocation code based on a patch by Scott Wood, which is: Signed-off-by: Scott Wood Signed-off-by: David Feng --- arch/arm/config.mk |3 +- arch/arm/cpu/armv8/Makefile | 38 + arch/arm/cpu/armv8/cache.S | 130 + arch/arm/cpu/armv8/cache_v8.c | 218 arch/arm/cpu/armv8/config.mk| 15 ++ arch/arm/cpu/armv8/cpu.c| 67 + arch/arm/cpu/armv8/exceptions.S | 112 +++ arch/arm/cpu/armv8/start.S | 234 +++ arch/arm/cpu/armv8/timer.c | 80 +++ arch/arm/cpu/armv8/tlb.S| 30 arch/arm/cpu/armv8/u-boot.lds | 89 arch/arm/include/asm/armv8/mmu.h| 110 +++ arch/arm/include/asm/byteorder.h| 12 ++ arch/arm/include/asm/cache.h|5 + arch/arm/include/asm/config.h |6 + arch/arm/include/asm/global_data.h |6 +- arch/arm/include/asm/io.h | 15 +- arch/arm/include/asm/macro.h| 36 + arch/arm/include/asm/posix_types.h | 10 ++ arch/arm/include/asm/proc-armv/ptrace.h | 21 +++ arch/arm/include/asm/proc-armv/system.h | 59 +++- arch/arm/include/asm/system.h | 77 ++ arch/arm/include/asm/types.h|4 + arch/arm/include/asm/u-boot.h |4 + arch/arm/include/asm/unaligned.h|2 +- arch/arm/lib/Makefile | 14 ++ arch/arm/lib/board.c|7 +- arch/arm/lib/bootm.c| 16 +++ arch/arm/lib/crt0_64.S | 113 +++ arch/arm/lib/interrupts_64.c| 120 arch/arm/lib/relocate_64.S | 58 common/image.c |1 + doc/README.arm64| 45 ++ examples/standalone/stubs.c | 15 ++ include/image.h |1 + 35 files changed, 1762 insertions(+), 11 deletions(-) create mode 100644 arch/arm/cpu/armv8/Makefile create mode 100644 arch/arm/cpu/armv8/cache.S create mode 100644 arch/arm/cpu/armv8/cache_v8.c create mode 100644 arch/arm/cpu/armv8/config.mk create mode 100644 arch/arm/cpu/armv8/cpu.c create mode 100644 arch/arm/cpu/armv8/exceptions.S create mode 100644 arch/arm/cpu/armv8/start.S create mode 100644 arch/arm/cpu/armv8/timer.c create mode 100644 arch/arm/cpu/armv8/tlb.S create mode 100644 arch/arm/cpu/armv8/u-boot.lds create mode 100644 arch/arm/include/asm/armv8/mmu.h create mode 100644 arch/arm/lib/crt0_64.S create mode 100644 arch/arm/lib/interrupts_64.c create mode 100644 arch/arm/lib/relocate_64.S create mode 100644 doc/README.arm64 diff --git a/arch/arm/config.mk b/arch/arm/config.mk index d0cf43f..a259193 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -17,7 +17,8 @@ endif LDFLAGS_FINAL += --gc-sections PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections \ - -fno-common -ffixed-r9 -msoft-float + -fno-common -ffixed-r9 +PLATFORM_RELFLAGS += $(call cc-option, -msoft-float) # Support generic board on ARM __HAVE_ARCH_GENERIC_BOARD := y diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile new file mode 100644 index 000..b216f27 --- /dev/null +++ b/arch/arm/cpu/armv8/Makefile @@ -0,0 +1,38 @@ +# +# (C) Copyright 2000-2003 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# SPDX-License-Identifier: GPL-2.0+ +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(CPU).o + +START := start.o + +COBJS += cpu.o +COBJS += timer.o +COBJS += cache_v8.o + +SOBJS += exceptions.o +SOBJS += cache.o +SOBJS += tlb.o + +SRCS := $(START:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) +START := $(addprefix $(obj),$(START)) + +all: $(obj).depend $(START) $(LIB) + +$(LIB):$(OBJS) + $(call cmd_link_o_target, $(OBJS)) + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/arch/arm/cpu/armv8/cache.S b/arch/arm/cpu/armv8/cache.S new file mode 100644 index 000..419f169 --- /dev/null +++ b/arch/arm/cpu/armv8/cache.S @@ -0,0 +1,130 @@ +/* + * (C) Copyright 2013 + * David Feng + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include +#include +#include +#include +#include + +/* + * void __asm_flush_dcache_level(level) + * + * clean and invalidate one level cache. + * + * x0: cache level + * x1~x9: clobbered + */ +ENTRY(__asm_flush_dcache_level) + lsl x1, x0, #1 + msr csselr_el1, x1 /* select cache level */ + isb /* isb to sych the new
[U-Boot] [RESEND PATCH v14 08/10] arm64: generic board support
From: David Feng
Signed-off-by: David Feng
---
common/board_f.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/common/board_f.c b/common/board_f.c
index 0ada1af..d821dbe 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -458,7 +458,7 @@ static int reserve_round_4k(void)
static int reserve_mmu(void)
{
/* reserve TLB table */
- gd->arch.tlb_size = 4096 * 4;
+ gd->arch.tlb_size = PGTABLE_SIZE;
gd->relocaddr -= gd->arch.tlb_size;
/* round down to next 64 kB limit */
@@ -610,7 +610,7 @@ static int reserve_stacks(void)
* TODO(s...@chromium.org): Perhaps create arch_reserve_stack()
* to handle this and put in arch/xxx/lib/stack.c
*/
-# ifdef CONFIG_ARM
+# if defined(CONFIG_ARM) && !defined(CONFIG_ARM64)
# ifdef CONFIG_USE_IRQ
gd->start_addr_sp -= (CONFIG_STACKSIZE_IRQ + CONFIG_STACKSIZE_FIQ);
debug("Reserving %zu Bytes for IRQ stack at: %08lx\n",
@@ -807,11 +807,6 @@ static int mark_bootstage(void)
}
static init_fnc_t init_sequence_f[] = {
-#if !defined(CONFIG_CPM2) && !defined(CONFIG_MPC512X) && \
- !defined(CONFIG_MPC83xx) && !defined(CONFIG_MPC85xx) && \
- !defined(CONFIG_MPC86xx) && !defined(CONFIG_X86)
- zero_global_data,
-#endif
#ifdef CONFIG_SANDBOX
setup_ram_buf,
#endif
@@ -1005,6 +1000,17 @@ void board_init_f(ulong boot_flags)
gd = &data;
#endif
+ /*
+* Clear global data before it is accessed at debug print
+* in initcall_run_list. Otherwise the debug print probably
+* get the wrong vaule of gd->have_console.
+*/
+#if !defined(CONFIG_CPM2) && !defined(CONFIG_MPC512X) && \
+ !defined(CONFIG_MPC83xx) && !defined(CONFIG_MPC85xx) && \
+ !defined(CONFIG_MPC86xx) && !defined(CONFIG_X86)
+ zero_global_data();
+#endif
+
gd->flags = boot_flags;
if (initcall_run_list(init_sequence_f))
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RESEND PATCH v14 09/10] arm64: board support of vexpress_aemv8a
From: David Feng
Signed-off-by: David Feng
Signed-off-by: Bhupesh Sharma
---
board/armltd/vexpress64/Makefile | 27 +
board/armltd/vexpress64/vexpress64.c | 50 +
boards.cfg |1 +
include/configs/vexpress_aemv8a.h| 191 ++
4 files changed, 269 insertions(+)
create mode 100644 board/armltd/vexpress64/Makefile
create mode 100644 board/armltd/vexpress64/vexpress64.c
create mode 100644 include/configs/vexpress_aemv8a.h
diff --git a/board/armltd/vexpress64/Makefile b/board/armltd/vexpress64/Makefile
new file mode 100644
index 000..f907c92
--- /dev/null
+++ b/board/armltd/vexpress64/Makefile
@@ -0,0 +1,27 @@
+#
+# (C) Copyright 2000-2004
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS := vexpress64.o
+
+SRCS := $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+
+$(LIB):$(obj).depend $(OBJS)
+ $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/armltd/vexpress64/vexpress64.c
b/board/armltd/vexpress64/vexpress64.c
new file mode 100644
index 000..dae18d4
--- /dev/null
+++ b/board/armltd/vexpress64/vexpress64.c
@@ -0,0 +1,50 @@
+/*
+ * (C) Copyright 2013
+ * David Feng
+ * Sharma Bhupesh
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int board_init(void)
+{
+ return 0;
+}
+
+int dram_init(void)
+{
+ gd->ram_size = PHYS_SDRAM_1_SIZE;
+ return 0;
+}
+
+int timer_init(void)
+{
+ return 0;
+}
+
+/*
+ * Board specific reset that is system reset.
+ */
+void reset_cpu(ulong addr)
+{
+}
+
+/*
+ * Board specific ethernet initialization routine.
+ */
+int board_eth_init(bd_t *bis)
+{
+ int rc = 0;
+#ifdef CONFIG_SMC9
+ rc = smc9_initialize(0, CONFIG_SMC9_BASE);
+#endif
+ return rc;
+}
diff --git a/boards.cfg b/boards.cfg
index 85143c6..6d3dd69 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -383,6 +383,7 @@ Active arm pxa- -
vpac270
Active arm pxa- icpdas lp8x4x
lp8x4x -
Sergey Yanovich
Active arm pxa- toradex -
colibri_pxa270 -
Marek Vasut
Active arm sa1100 - - -
jornada -
Kristoffer Ericson
+Active arm armv8 - armltd vexpress64
vexpress_aemv8a vexpress_aemv8a:ARM64
David Feng
Active avr32 at32ap at32ap700x atmel -
atngw100 -
Haavard Skinnemoen
Active avr32 at32ap at32ap700x atmel -
atngw100mkii -
Andreas Bießmann
Active avr32 at32ap at32ap700x atmel atstk1000
atstk1002-
Haavard Skinnemoen
diff --git a/include/configs/vexpress_aemv8a.h
b/include/configs/vexpress_aemv8a.h
new file mode 100644
index 000..e93b00f
--- /dev/null
+++ b/include/configs/vexpress_aemv8a.h
@@ -0,0 +1,191 @@
+/*
+ * Configuration for Versatile Express. Parts were derived from other ARM
+ * configurations.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __VEXPRESS_AEMV8A_H
+#define __VEXPRESS_AEMV8A_H
+
+#define DEBUG
+
+#define CONFIG_REMAKE_ELF
+
+/*#define CONFIG_BOOTING_EL1*/
+
+/*#define CONFIG_SYS_GENERIC_BOARD*/
+
+#define CONFIG_SYS_NO_FLASH
+
+#define CONFIG_SUPPORT_RAW_INITRD
+
+/* Cache Definitions */
+#define CONFIG_SYS_DCACHE_OFF
Re: [U-Boot] [PATCH V2 0/2] add sdhci generic framework
On Mon, Oct 14, 2013 at 7:16 PM, Lei Wen wrote: > Hi Vadim, > > The quirk is standing for some workaround for those host that has some > limitation that it cannot directly be applied with standard sdhci.c code, > so that we add one quirk for it, which let it could use the sdhci.c. > > Like the quirk as SDHCI_QUIRK_32BIT_DMA_ADDR, it indicate that some host > has dma engine limitation that it must start from address with alignement. > So if sdhci find caller set this quirk, it would follow corresponding > workaround > for it. > > There is no formal description for it as I could see. > All right, that's what I figured :). Thank you for the explanation, --vb > Thanks, > Lei > >> -Original Message- >> From: vben...@gmail.com [mailto:vben...@gmail.com] On Behalf Of Vadim >> Bendebury >> Sent: Tuesday, October 15, 2013 10:09 AM >> To: Lei Wen >> Cc: Prafulla Wadaskar; aflem...@gmail.com; Rob Herring; u- >> b...@lists.denx.de; Yu Tang; Prabhanjan Sarnaik; Ashish Karkare; Andy >> Fleming >> Subject: Re: [U-Boot] [PATCH V2 0/2] add sdhci generic framework >> >> Hello Lei, >> >> I am looking into adding eMMC support for some intel SDHCI controllers >> based on this common SDHCI driver submission. >> >> One thing which is not quite clear is the quirks - can you (or somebody >> else on this list) please shed some light on what the quirks are. Is >> there some kind of formal description/definition of various defined >> quirks and their processing. >> >> Thank you in advance, >> >> --vb >> >> >> On Wed, Jun 29, 2011 at 12:50 AM, Lei Wen wrote: >> > V1: >> > add sdhci generic framework and with marvell sdhci implementation >> > >> > V2: >> > rename the previous file name from sdhci-mv to mv_sdhci >> > >> > Lei Wen (2): >> > MMC: add sdhci generic framework >> > MMC: add marvell sdhci driver >> > >> > drivers/mmc/Makefile |2 + >> > drivers/mmc/mv_sdhci.c | 21 +++ >> > drivers/mmc/sdhci.c| 433 >> >> > include/sdhci.h| 325 >> > 4 files changed, 781 insertions(+), 0 deletions(-) create mode >> > 100644 drivers/mmc/mv_sdhci.c create mode 100644 drivers/mmc/sdhci.c >> > create mode 100644 include/sdhci.h >> > >> > ___ >> > U-Boot mailing list >> > U-Boot@lists.denx.de >> > http://lists.denx.de/mailman/listinfo/u-boot > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3 v2] exynos: i2c: Fix i2c driver to handle NACKs properly
Hello Naveen, Am 15.10.2013 06:48, schrieb Naveen Krishna Ch: On 14 October 2013 11:59, Heiko Schocher wrote: Hello Naveen, Am 03.10.2013 13:22, schrieb Naveen Krishna Chatradhi: The Exynos5 i2c driver does not handle NACKs properly. This change: - fixes the NACK processing problem (do not continue transaction if address cycle was NACKed) - eliminates a fair amount of duplicate code Signed-off-by: Vadim Bendebury Reviewed-by: Simon Glass Signed-off-by: Naveen Krishna Chatradhi --- Changes since v1: 1. Removed the compilation error mentioned by Heiko for VCMA9 board... Hmm.. just tried your patchset and I get for the VCMA9 board: http://patchwork.ozlabs.org/patch/280286/ http://patchwork.ozlabs.org/patch/280287/ http://patchwork.ozlabs.org/patch/280288/ Configuring for VCMA9 board... s3c24x0_i2c.c:125:39: error: 'CONFIG_MAX_I2C_NUM' undeclared here (not in a function) arm-linux-gnueabi-size: './u-boot': No such file s3c24x0_i2c.c:125:39: error: 'CONFIG_MAX_I2C_NUM' undeclared here (not in a function) s3c24x0_i2c.c:125:31: warning: 'i2c_bus' defined but not used [-Wunused-variable] s3c24x0_i2c.c:295:12: warning: 'hsi2c_get_clk_details' defined but not used [-Wunused-function] make[1]: *** [s3c24x0_i2c.o] Fehler 1 make: *** [drivers/i2c/libi2c.o] Fehler 2 make: *** Warte auf noch nicht beendete Prozesse... Could you check this complete patchset, thanks! Just check with "make VCMA9 -j4> err" I see the errors. Heiko, Whats the best way to check the compilation errors for all boards related to Samsung. in U-Boot tree: all s3c24x0 boards: ./MAKEALL -s s3c24x0 (prefered check) all arm boards: ./MAKEALL arm Will resubmit the patchset. 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 1/3 v2] exynos: i2c: Fix i2c driver to handle NACKs properly
On 14 October 2013 11:59, Heiko Schocher wrote: > Hello Naveen, > > Am 03.10.2013 13:22, schrieb Naveen Krishna Chatradhi: > >> The Exynos5 i2c driver does not handle NACKs properly. This change: >> >> - fixes the NACK processing problem (do not continue transaction if >>address cycle was NACKed) >> >> - eliminates a fair amount of duplicate code >> >> Signed-off-by: Vadim Bendebury >> Reviewed-by: Simon Glass >> Signed-off-by: Naveen Krishna Chatradhi >> --- >> Changes since v1: >> 1. Removed the compilation error mentioned by Heiko for VCMA9 board... > > > Hmm.. just tried your patchset and I get for the VCMA9 board: > > http://patchwork.ozlabs.org/patch/280286/ > http://patchwork.ozlabs.org/patch/280287/ > http://patchwork.ozlabs.org/patch/280288/ > > > Configuring for VCMA9 board... > s3c24x0_i2c.c:125:39: error: 'CONFIG_MAX_I2C_NUM' undeclared here (not in a > function) > arm-linux-gnueabi-size: './u-boot': No such file > s3c24x0_i2c.c:125:39: error: 'CONFIG_MAX_I2C_NUM' undeclared here (not in a > function) > s3c24x0_i2c.c:125:31: warning: 'i2c_bus' defined but not used > [-Wunused-variable] > s3c24x0_i2c.c:295:12: warning: 'hsi2c_get_clk_details' defined but not used > [-Wunused-function] > make[1]: *** [s3c24x0_i2c.o] Fehler 1 > make: *** [drivers/i2c/libi2c.o] Fehler 2 > make: *** Warte auf noch nicht beendete Prozesse... > > Could you check this complete patchset, thanks! Just check with "make VCMA9 -j4 > err" I see the errors. Heiko, Whats the best way to check the compilation errors for all boards related to Samsung. Will resubmit the patchset. > > bye, > Heiko > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany -- Shine bright, (: Nav :) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] I2C:Zynq: Adapt this driver to the new model
Hello Michael, Am 14.10.2013 18:25, schrieb Michael Burr: I am submitting a patch for 'include/zynq.h' as well as for the README file. and the drivers/i2c/Makefile ;-) Thanks! I might be able to add code for certain particular boards which use this driver -- however, I think it may be easier for everyone if we don't do that until mainline is synchronized with Michal's Xilinx repo. (That's because the Xilinx repo has config files for several individual boards, but the mainline repo doesn't yet have those files.) Ok, please sent this patches, if this is done ... or Michal pick up this patches? Maybe it is time to make a common include file for this boards, if all use the same i2c (not only i2c) settings? 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] I2C:Zynq: Adapt this driver to the new model
Hi Michael and Heiko, On 10/15/2013 07:13 AM, Heiko Schocher wrote: > Hello Michael, > > Am 14.10.2013 18:25, schrieb Michael Burr: >> I am submitting a patch for 'include/zynq.h' as well as for the README file. > > and the drivers/i2c/Makefile ;-) > Thanks! Regarding this change. I have asked Siva and Jagan to retest this patch. It was holiday/day off in India that's why I haven't got any reply yet. > >> I might be able to add code for certain particular boards which use this >> driver -- however, I think it may be easier for everyone if we don't do that >> until mainline is synchronized with Michal's Xilinx repo. (That's because >> the Xilinx repo has config files for several individual boards, but the >> mainline repo doesn't yet have those files.) > > Ok, please sent this patches, if this is done ... or Michal pick up > this patches? > > Maybe it is time to make a common include file for this boards, if all > use the same i2c (not only i2c) settings? v2013.10 hasn't been tagged yet that's why I or Jagan haven't started with unification. But for the next release I want to synchronize our configuration with mainline one. It is mostly in include/configs/ folder. There should be a week after ELCE to look at it. 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] cm_t35: use scf0403 driver
On 10/09/13 16:46, Nikita Kiryanov wrote: > Use scf0403 driver to add scf0403x LCD support for cm-t35 and cm-t3730 > boards. > > Cc: Tom Rini > Cc: Anatolij Gustschin > Cc: Igor Grinberg > Signed-off-by: Nikita Kiryanov Acked-by: Igor Grinberg -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-xlnx/master-next: build error
Hi, On 10/14/2013 09:05 PM, Albert ARIBAUD wrote: > Hi Oleg, > > On Mon, 14 Oct 2013 11:54:18 -0700 (PDT), Oleg Dzhimiev > wrote: > >> Hi, >> >> Building u-boot-xlnx/master-next:4cb9c3de73d66372d40d24baf82fa87a702f0c9b >> throws an error: >>> lowlevel_init.S: Assembler messages: >>> lowlevel_init.S:35: Error: selected processor does not support ARM mode >>> `fmrx r1,FPEXC' >>> lowlevel_init.S:37: Error: selected processor does not support ARM mode >>> `fmxr FPEXC,r1' >>> make[1]: *** [lowlevel_init.o] Error 1 >> >> OS: Ubuntu 13.04 x64 >> target: zynq_zed_config >> cross-tools: cross compiler built with yocto poky: >>> export CROSS_COMPILE=arm-poky-linux-gnueabi- >>> export >>> PATH=/opt/poky/1.4.2/sysroots/x86_64-pokysdk-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/:$PATH >>> >> >> Thanks > > U-boot-xlnx is not a sub-repo of the official U-Boot; it is Xilinx' own > version, located at https://github.com/Xilinx/u-boot-xlnx. > > I suggest you ask the Xilinx folks about it. just FYI: this should be Linux issue not u-boot issue. I have got another message from your colleague which I have already answered. 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] I2C:Zynq: Adapt this driver to the new model
Hello Michael, Am 15.10.2013 07:24, schrieb Michal Simek: Hi Michael and Heiko, On 10/15/2013 07:13 AM, Heiko Schocher wrote: Hello Michael, Am 14.10.2013 18:25, schrieb Michael Burr: I am submitting a patch for 'include/zynq.h' as well as for the README file. and the drivers/i2c/Makefile ;-) Thanks! Regarding this change. I have asked Siva and Jagan to retest this patch. It was holiday/day off in India that's why I haven't got any reply yet. Ah, ok! So you can pickup this patch after it is tested. If patch is tested please resend it, so I can add my Acked-by to it. I might be able to add code for certain particular boards which use this driver -- however, I think it may be easier for everyone if we don't do that until mainline is synchronized with Michal's Xilinx repo. (That's because the Xilinx repo has config files for several individual boards, but the mainline repo doesn't yet have those files.) Ok, please sent this patches, if this is done ... or Michal pick up this patches? Maybe it is time to make a common include file for this boards, if all use the same i2c (not only i2c) settings? v2013.10 hasn't been tagged yet that's why I or Jagan haven't started with unification. But for the next release I want to synchronize our configuration with mainline one. It is mostly in include/configs/ folder. There should be a week after ELCE to look at it. Great! 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] I2C:Zynq: Adapt this driver to the new model
Hello Michal, Am 14.10.2013 18:25, schrieb Michael Burr: CONFIGs and README for driver 'zynq_i2c.c'. Signed-off-by: Michael Burr Cc: Heiko Schocher Cc: Michal Simek --- === This patch depends on the previous patch titled === "[PATCH] I2C:Zynq: Adapt this driver to the new model" === submitted 26 Sep. 2013. please squash this patch into the above patch, and add the rename of the drivers config define, and resubmit it, 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 v2] mxc_spi: bugfix for double incrementing read pointer on unaligned buffers in spi_xchg_single
Yes I tested it on the master-probe branch of u-boot-spi.git.
Am 7.10.2013 09:24, schrieb Jagan Teki:
> Did you test this on u-boot-spi.git with master-probe branch?
>
> On Mon, Oct 7, 2013 at 12:20 PM, Timo Herbrecher
> wrote:
>> If dout buffer is not 32 bit-aligned or data to transmit is not multiple
>> of 32 bit the read data pointer is already incremented on single byte reads.
>>
>> Signed-off-by: Timo Herbrecher
>> ---
>> drivers/spi/mxc_spi.c |2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
>> index fd72a65..95dd03f 100644
>> --- a/drivers/spi/mxc_spi.c
>> +++ b/drivers/spi/mxc_spi.c
>> @@ -255,8 +255,8 @@ int spi_xchg_single(struct spi_slave *slave,
>> unsigned int bitlen,
>> } else {
>> data = *(u32 *)dout;
>> data = cpu_to_be32(data);
>> + dout += 4;
>> }
>> - dout += 4;
>> }
>> debug("Sending SPI 0x%x\n", data);
>> reg_write(®s->txdata, data);
>> --
>> 1.7.0.4
>>
>>
>
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3 v3] exynos: i2c: Fix i2c driver to handle NACKs properly
The Exynos5 i2c driver does not handle NACKs properly. This change:
- fixes the NACK processing problem (do not continue transaction if
address cycle was NACKed)
- eliminates a fair amount of duplicate code
Signed-off-by: Vadim Bendebury
Reviewed-by: Simon Glass
Signed-off-by: Naveen Krishna Chatradhi
---
Changes since v1:
Fixed complilation warning in function i2c_init()
Changes since v2:
None
drivers/i2c/s3c24x0_i2c.c | 214 +++--
1 file changed, 90 insertions(+), 124 deletions(-)
diff --git a/drivers/i2c/s3c24x0_i2c.c b/drivers/i2c/s3c24x0_i2c.c
index cd09c78..c65360d 100644
--- a/drivers/i2c/s3c24x0_i2c.c
+++ b/drivers/i2c/s3c24x0_i2c.c
@@ -43,7 +43,7 @@
#define I2C_START_STOP 0x20/* START / STOP */
#define I2C_TXRX_ENA 0x10/* I2C Tx/Rx enable */
-#define I2C_TIMEOUT 1 /* 1 second */
+#define I2C_TIMEOUT_MS 1000/* 1 second */
/*
@@ -84,22 +84,26 @@ static void SetI2CSCL(int x)
}
#endif
+/*
+ * Wait til the byte transfer is completed.
+ *
+ * @param i2c- pointer to the appropriate i2c register bank.
+ * @return I2C_OK, if transmission was ACKED
+ * I2C_NACK, if transmission was NACKED
+ * I2C_NOK_TIMEOUT, if transaction did not complete in I2C_TIMEOUT_MS
+ */
+
static int WaitForXfer(struct s3c24x0_i2c *i2c)
{
- int i;
+ ulong start_time = get_timer(0);
- i = I2C_TIMEOUT * 1;
- while (!(readl(&i2c->iiccon) & I2CCON_IRPND) && (i > 0)) {
- udelay(100);
- i--;
- }
+ do {
+ if (readl(&i2c->iiccon) & I2CCON_IRPND)
+ return (readl(&i2c->iicstat) & I2CSTAT_NACK) ?
+ I2C_NACK : I2C_OK;
+ } while (get_timer(start_time) < I2C_TIMEOUT_MS);
- return (readl(&i2c->iiccon) & I2CCON_IRPND) ? I2C_OK : I2C_NOK_TOUT;
-}
-
-static int IsACK(struct s3c24x0_i2c *i2c)
-{
- return !(readl(&i2c->iicstat) & I2CSTAT_NACK);
+ return I2C_NOK_TOUT;
}
static void ReadWriteByte(struct s3c24x0_i2c *i2c)
@@ -180,21 +184,27 @@ unsigned int i2c_get_bus_num(void)
void i2c_init(int speed, int slaveadd)
{
+ int i;
struct s3c24x0_i2c *i2c;
#if !(defined CONFIG_EXYNOS4 || defined CONFIG_EXYNOS5)
struct s3c24x0_gpio *gpio = s3c24x0_get_base_gpio();
#endif
- int i;
+ ulong start_time = get_timer(0);
/* By default i2c channel 0 is the current bus */
g_current_bus = 0;
i2c = get_base_i2c();
- /* wait for some time to give previous transfer a chance to finish */
- i = I2C_TIMEOUT * 1000;
- while ((readl(&i2c->iicstat) & I2CSTAT_BSY) && (i > 0)) {
- udelay(1000);
- i--;
+ /*
+* In case the previous transfer is still going, wait to give it a
+* chance to finish.
+*/
+ while (readl(&i2c->iicstat) & I2CSTAT_BSY) {
+ if (get_timer(start_time) > I2C_TIMEOUT_MS) {
+ printf("%s: I2C bus busy for %p\n", __func__,
+ &i2c->iicstat);
+ return;
+ }
}
#if !(defined CONFIG_EXYNOS4 || defined CONFIG_EXYNOS5)
@@ -260,7 +270,8 @@ static int i2c_transfer(struct s3c24x0_i2c *i2c,
unsigned char data[],
unsigned short data_len)
{
- int i, result;
+ int i = 0, result;
+ ulong start_time = get_timer(0);
if (data == 0 || data_len == 0) {
/*Don't support data transfer of no length or to address 0 */
@@ -268,128 +279,78 @@ static int i2c_transfer(struct s3c24x0_i2c *i2c,
return I2C_NOK;
}
- /* Check I2C bus idle */
- i = I2C_TIMEOUT * 1000;
- while ((readl(&i2c->iicstat) & I2CSTAT_BSY) && (i > 0)) {
- udelay(1000);
- i--;
+ while (readl(&i2c->iicstat) & I2CSTAT_BSY) {
+ if (get_timer(start_time) > I2C_TIMEOUT_MS)
+ return I2C_NOK_TOUT;
}
- if (readl(&i2c->iicstat) & I2CSTAT_BSY)
- return I2C_NOK_TOUT;
-
writel(readl(&i2c->iiccon) | I2CCON_ACKGEN, &i2c->iiccon);
- result = I2C_OK;
- switch (cmd_type) {
- case I2C_WRITE:
- if (addr && addr_len) {
- writel(chip, &i2c->iicds);
- /* send START */
- writel(I2C_MODE_MT | I2C_TXRX_ENA | I2C_START_STOP,
- &i2c->iicstat);
- i = 0;
- while ((i < addr_len) && (result == I2C_OK)) {
- result = WaitForXfer(i2c);
- writel(addr[i], &i2c->iicds);
- ReadWriteByte(i2c);
- i++;
- }
- i = 0;
- while ((i < data_len) && (re
[U-Boot] [PATCH 2/3 v3] exynos: i2c: Change FDT bus setup code to enumerate ports correctly
From: Simon Glass
At present the i2c ports are enumerated in a strange way - the
fdtdec_find_aliases_for_id() function is used, but then the ID returned
is ignored and the ports are renumbered. The effect is the same provided
that the device tree has the ports in the same order, or uses aliases,
and has no gaps, but it is not correct.
Adjust the code to use the function as intended. This will allows device
tree aliases to change the device order if required.
As a result, the i2c_busses variable is dropped. We can't be sure that
there are no 'holes' in the list of buses, so must check the whole
array.
Note: it seems that non-FDT operation is now broken in this drive and
will need to be reinstated for upstream.
Signed-off-by: Simon Glass
Reviewed-on: https://gerrit.chromium.org/gerrit/59369
Signed-off-by: Naveen Krishna Chatradhi
---
Changes since v1:
Nonei
Changes since v2:
None
drivers/i2c/s3c24x0_i2c.c | 25 ++---
drivers/i2c/s3c24x0_i2c.h |1 +
2 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/s3c24x0_i2c.c b/drivers/i2c/s3c24x0_i2c.c
index c65360d..0e6f241 100644
--- a/drivers/i2c/s3c24x0_i2c.c
+++ b/drivers/i2c/s3c24x0_i2c.c
@@ -52,7 +52,6 @@
*/
static unsigned int g_current_bus __attribute__((section(".data")));
#ifdef CONFIG_OF_CONTROL
-static int i2c_busses __attribute__((section(".data")));
static struct s3c24x0_i2c_bus i2c_bus[CONFIG_MAX_I2C_NUM]
__attribute__((section(".data")));
#endif
@@ -164,8 +163,8 @@ int i2c_set_bus_num(unsigned int bus)
{
struct s3c24x0_i2c *i2c;
- if ((bus < 0) || (bus >= CONFIG_MAX_I2C_NUM)) {
- debug("Bad bus: %d\n", bus);
+ i2c_bus = get_bus(bus);
+ if (!i2c_bus)
return -1;
}
@@ -483,19 +482,31 @@ void board_i2c_init(const void *blob)
if (node <= 0)
continue;
bus = &i2c_bus[i];
+ bus->active = true;
bus->regs = (struct s3c24x0_i2c *)
fdtdec_get_addr(blob, node, "reg");
bus->id = pinmux_decode_periph_id(blob, node);
bus->node = node;
- bus->bus_num = i2c_busses++;
+ bus->bus_num = i;
exynos_pinmux_config(bus->id, 0);
}
}
+/**
+ * Get a pointer to the given bus index
+ *
+ * @bus_idx: Bus index to look up
+ * @return pointer to bus, or NULL if invalid or not available
+ */
static struct s3c24x0_i2c_bus *get_bus(unsigned int bus_idx)
{
- if (bus_idx < i2c_busses)
- return &i2c_bus[bus_idx];
+ if (bus_idx < ARRAY_SIZE(i2c_bus)) {
+ struct s3c24x0_i2c_bus *bus;
+
+ bus = &i2c_bus[bus_idx];
+ if (bus->active)
+ return bus;
+ }
debug("Undefined bus: %d\n", bus_idx);
return NULL;
@@ -505,7 +516,7 @@ int i2c_get_bus_num_fdt(int node)
{
int i;
- for (i = 0; i < i2c_busses; i++) {
+ for (i = 0; i < ARRAY_SIZE(i2c_bus); i++) {
if (node == i2c_bus[i].node)
return i;
}
diff --git a/drivers/i2c/s3c24x0_i2c.h b/drivers/i2c/s3c24x0_i2c.h
index b4a337a..882af62 100644
--- a/drivers/i2c/s3c24x0_i2c.h
+++ b/drivers/i2c/s3c24x0_i2c.h
@@ -16,6 +16,7 @@ struct s3c24x0_i2c {
};
struct s3c24x0_i2c_bus {
+ bool active;/* port is active and available */
int node; /* device tree node */
int bus_num;/* i2c bus number */
struct s3c24x0_i2c *regs;
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
