Re: [U-Boot] [PATCH v3] dfu: Introduction of the dfu_hash_algo env variable for checksum method setting
Hi Wolfgang, Dear Lukasz, In message 20140515154334.626923b4@amdc2363 you wrote: This reinforces my speculation that you are actually addressing the wrong problem. Instead of adding new code and environment variables and making the system even more complex, we should just leave everything as is, During working on this patch I've replaced the crc32() method with the call to hash_method(), which IMHO is welcome. Yes, indeed this is highly welcome. Thanks a lot for that! I also don't personally like the crc32, hence I like the choice which this patch gives me to use other algorithm (for which I've got HW support on my platform - e.g. MD5). Well, is this really useful? dfu-utils provides only CRC caculation, so where would you get the reference value for any other checksum metod from? I was rather thinking about a test setup with my target connected via serial console to HOST machine. Then I could compare the CRC32/MD5/SHA1 just after sending the data. For my target it is better to use MD5 or SHA1 since support for them is provided via the specialized, embedded crypto IP. and you should try to find out why the CRC calculation is so low for you. Checking if caches are enabled is probably among the things that should be done first. L1 is enabled. L2 has been disabled on purpose (power consumption reduction). This certainly contributes to slow code execution. Please note that the last revision of DFU is from 2004. I've contacted Greg KH (one of the original authors) and he replied that no new attempt to revise the standard was made. This may just mean that users were just happy with the current situation. It is hard to say. It's definitely better than if changed had been proposed but rejected. True. The best however, would be to revise the standard to include such functionality to it. In the same time I'm fully aware that this is very unlikely to happen. Why do you think it is unlikely? I don't have the experience with preparing USB standards, but I assume that it is somewhat hard to revise the standard after 10 years. Of course, it would require that someone comes up with such a proposal in the first place. But you sound as if you were certain a proposal had no chance for being considered. No, this is not what I meant. I may be naive, but should we not at least try before giving up? Unfortunately my time budget is limited and I feel like this has lower priority than fixing/solving current DFU problems. Best regards, Wolfgang Denk -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: consolidate arch/arm/include/asm/arch-*/spl.h
On Mon, Apr 28, 2014 at 1:16 AM, Masahiro Yamada
yamad...@jp.panasonic.com wrote:
Hi Tom,
On Fri, 25 Apr 2014 14:52:06 -0400
Tom Rini tr...@ti.com wrote:
On Wed, Apr 16, 2014 at 03:44:36PM +0900, Masahiro Yamada wrote:
arch/arm/include/asm/spl.h requires all SoCs to have
arch/arm/include/asm/arch-*/spl.h.
But many of them just define BOOT_DEVICE_* macros.
Those macros are used in the switch (boot_device) { ... }
statement in common/spl/spl.c.
So they should not be archtecture specific, but described as
a simpile enumeration.
This commit merge most of arch/arm/include/asm/arch-*/spl.h
into arch/arm/include/asm/spl.h.
With a little more effort, arch-zynq/spl.h and arch-socfpga/spl.h
will be merged, while I am not sure about OMAP and Exynos.
The problem is that on TI platforms these values have meaning defined by
ROM (which changes occasionally). When ROM starts us up, we get a
little bit of info that says I found and loaded you on So while
we could move towards moving BOOT_DEVICE_FOO into spl.h we'd need in
arch/arm/cpu/armv7/omap-common/boot-common.c some logic to translate
from ROM numbers to U-Boot numbers.
Could you apply my patch first and fix the OMAP translation logic lator?
I want to stop duplication of similar spl.h headers.
Best Regards
Masahiro Yamada
Tom / Masahiro,
Any update on this? This is a very useful cleanup and there is at
least one pending patch series that depend on it.
Regards,
Tim
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: consolidate arch/arm/include/asm/arch-*/spl.h
Hi Tim, Tom, Tom / Masahiro, Any update on this? This is a very useful cleanup and there is at least one pending patch series that depend on it. No update from me. Version 2 is the latest one. http://patchwork.ozlabs.org/patch/341817/ I am also waiting for the review. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] examples: select libgcc for non-default architecture
In case of multilib-enabled toolchains if default architecture differ from the one examples are being built for linker will fail to link example object files with libgcc of another (non-compatible) architecture. Interesting enough for years in main Makefile we used CFLAGS/c_flags for this but not for examples. So fixing it now. Signed-off-by: Alexey Brodkin abrod...@synopsys.com Cc: Masahiro Yamada yamad...@jp.panasonic.com Cc: Tom Rini tr...@ti.com Cc: Wolfgang Denx w...@denx.de --- v2 copies functoinality for libgcc selection from main Makefile. This takes care of CONFIG_USE_PRIVATE_LIBGCC if one is used. examples/standalone/Makefile | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/examples/standalone/Makefile b/examples/standalone/Makefile index 9ab5446..2c13c07 100644 --- a/examples/standalone/Makefile +++ b/examples/standalone/Makefile @@ -38,7 +38,17 @@ targets += $(patsubst $(obj)/%,%,$(LIB)) $(COBJS) $(LIBOBJS-y) LIBOBJS:= $(addprefix $(obj)/,$(LIBOBJS-y)) ELF:= $(addprefix $(obj)/,$(ELF)) -gcclibdir := $(shell dirname `$(CC) -print-libgcc-file-name`) +# Add GCC lib +ifdef CONFIG_USE_PRIVATE_LIBGCC +ifeq ($(CONFIG_USE_PRIVATE_LIBGCC),y) +PLATFORM_LIBGCC = arch/$(ARCH)/lib/lib.a +else +PLATFORM_LIBGCC = -L $(CONFIG_USE_PRIVATE_LIBGCC) -lgcc +endif +else +PLATFORM_LIBGCC := -L $(shell dirname `$(CC) $(PLATFORM_CPPFLAGS) \ + -print-libgcc-file-name`) -lgcc +endif # For PowerPC there's no need to compile standalone applications as a # relocatable executable. The relocation data is not needed, and @@ -63,7 +73,7 @@ $(LIB): $(LIBOBJS) FORCE quiet_cmd_link_elf = LD $@ cmd_link_elf = $(LD) $(LDFLAGS) -g -Ttext $(CONFIG_STANDALONE_LOAD_ADDR) \ --o $@ -e $(SYM_PREFIX)$(@F) $ $(LIB) -L$(gcclibdir) -lgcc +-o $@ -e $(SYM_PREFIX)$(@F) $ $(LIB) $(PLATFORM_LIBGCC) $(ELF): $(obj)/%: $(obj)/%.o $(LIB) FORCE $(call if_changed,link_elf) -- 1.9.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: exynos5420: removed undefined gpio structure
On 14/05/14 19:44, Jaehoon Chung wrote:
It's removed the exynos5_gpio_part1.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
---
board/samsung/smdk5420/smdk5420.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/board/samsung/smdk5420/smdk5420.c
b/board/samsung/smdk5420/smdk5420.c
index 9207522..183c522 100644
--- a/board/samsung/smdk5420/smdk5420.c
+++ b/board/samsung/smdk5420/smdk5420.c
@@ -42,9 +42,6 @@ int exynos_init(void)
#ifdef CONFIG_LCD
void cfg_lcd_gpio(void)
{
- struct exynos5_gpio_part1 *gpio1 =
- (struct exynos5_gpio_part1 *)samsung_get_base_gpio_part1();
-
/* For Backlight */
gpio_cfg_pin(EXYNOS5420_GPIO_B20, S5P_GPIO_OUTPUT);
gpio_set_value(EXYNOS5420_GPIO_B20, 1);
applied to u-boot-samsung.
Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv5 00/14] mmc: exynos: code cleanup and support DDR mode
On 16/05/14 13:59, Jaehoon Chung wrote: If card and host are supported DDR mode, then it can be used the DDR mode. This patch-set has dependency about beomho's patch-set. (Based-on u-boot-samsung repository) It's result for loading image. sdhci controller -5260488 bytes read in 259 ms (19.4 MiB/s) dwmmc controller without DDR mode - 5260488 bytes read in 202 ms (24.8 MiB/s) dwmmc controller with DDR mode - 5260488 bytes read in 118 ms (42.5 MiB/s) Download the 400M image with lthor. sdhci controller - 59.4sec (Avg 6.95 MB/s) dwmmc controller without DDR mode - 61.6sec (Avg 6.72MB/s) dwmmc controller with DDR mode - 60.4sec (Avg 6.85MB/s) Beomho Seo (3): arm: exynos: pinmux: add sdmmc4 gpio configratuion arm: exynos: clock: Remove exynos4x12_set_mmc_clk function board: trats2: Enable device tree on Trats2 Jaehoon Chung (11): ARM: exynos: board: change the mmc/sd init sequence ARM: exynos: clock: modify the set_mmc_clk for exynos4 ARM: dts: exynos: rename from EXYNOS5_DWMMC to EXYNOS_DWMMC mmc: exynos_dw_mmc: restore the property into host mmc: remove the unnecessary define and fix the wrong bit control mmc: support the DDR mode for eMMC mmc: dw_mmc: support the DDR mode ARM: dts: exnyos: enable dw-mmc controller mmc: exynos_dw_mmc: enable the DDR mode ARM: exynos4: enable the dwmmc configuration mmc: s5p_sdhci: add the s5p_sdhci_core_init function arch/arm/cpu/armv7/exynos/clock.c | 45 ++- arch/arm/cpu/armv7/exynos/pinmux.c| 35 - arch/arm/dts/exynos4.dtsi |8 ++ arch/arm/dts/exynos4412-trats2.dts| 12 ++ arch/arm/dts/exynos5.dtsi |8 +- arch/arm/include/asm/arch-exynos/clk.h|5 + board/samsung/common/board.c | 13 +- doc/device-tree-bindings/exynos/dwmmc.txt |8 +- drivers/mmc/dw_mmc.c | 12 +- drivers/mmc/exynos_dw_mmc.c | 205 +++-- drivers/mmc/mmc.c | 16 ++- drivers/mmc/s5p_sdhci.c | 42 +++--- include/configs/exynos4-dt.h |3 + include/dwmmc.h |5 + include/fdtdec.h |2 +- include/mmc.h | 25 ++-- lib/fdtdec.c |2 +- 17 files changed, 275 insertions(+), 171 deletions(-) applied to u-boot-samsung. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 12/12] arm: goni: enable USB Mass Storage
On 29/04/14 04:13, Mateusz Zalega wrote: UMS-related defines were added to Samsung Goni config header. Signed-off-by: Mateusz Zalega m.zal...@samsung.com Cc: Minkyu Kang mk7.k...@samsung.com --- Changes since v1: - reordered --- include/configs/s5p_goni.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/s5p_goni.h b/include/configs/s5p_goni.h index c52a00a..f551c22 100644 --- a/include/configs/s5p_goni.h +++ b/include/configs/s5p_goni.h @@ -267,5 +267,7 @@ #define CONFIG_USB_GADGET_S3C_UDC_OTG #define CONFIG_USB_GADGET_DUALSPEED #define CONFIG_USB_GADGET_VBUS_DRAW 2 +#define CONFIG_CMD_USB_MASS_STORAGE +#define CONFIG_USB_GADGET_MASS_STORAGE #endif /* __CONFIG_H */ applied to u-boot-samsung. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 11/12] arm: goni: enable GPT command
On 29/04/14 04:13, Mateusz Zalega wrote: Signed-off-by: Mateusz Zalega m.zal...@samsung.com Cc: Minkyu Kang mk7.k...@samsung.com --- Changes since v1: - reordered --- include/configs/s5p_goni.h | 5 + 1 file changed, 5 insertions(+) applied to u-boot-samsung. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 09/12] arm: goni: Update configuration for Goni target
On 29/04/14 04:13, Mateusz Zalega wrote: 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 a.wlodarc...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Signed-off-by: Mateusz Zalega m.zal...@samsung.com Tested-by: Arkadiusz Wlodarczyk a.wlodarc...@samsung.com Tested-by: Mateusz Zalega m.zal...@samsung.com Cc: Minkyu Kang mk7.k...@samsung.com --- Changes since v1: - reordered --- include/configs/s5p_goni.h | 56 +- 1 file changed, 30 insertions(+), 26 deletions(-) applied to u-boot-samsung. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 10/12] arm: goni: dfu: Add support for DFU to Goni target
On 29/04/14 04:13, Mateusz Zalega wrote: 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. Signed-off-by: Arkadiusz Wlodarczyk a.wlodarc...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Signed-off-by: Mateusz Zalega m.zal...@samsung.com Tested-by: Arkadiusz Wlodarczyk a.wlodarc...@samsung.com Tested-by: Mateusz Zalega m.zal...@samsung.com Cc: Minkyu Kang mk7.k...@samsung.com --- Changes since v1: - reordered --- board/samsung/goni/goni.c | 8 +++ include/configs/s5p_goni.h | 54 -- 2 files changed, 51 insertions(+), 11 deletions(-) applied to u-boot-samsung. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] examples: select libgcc for non-default architecture
Hi Alexey, Wolfgang, --- a/examples/standalone/Makefile +++ b/examples/standalone/Makefile @@ -38,7 +38,17 @@ targets += $(patsubst $(obj)/%,%,$(LIB)) $(COBJS) $(LIBOBJS-y) LIBOBJS := $(addprefix $(obj)/,$(LIBOBJS-y)) ELF := $(addprefix $(obj)/,$(ELF)) -gcclibdir := $(shell dirname `$(CC) -print-libgcc-file-name`) +# Add GCC lib +ifdef CONFIG_USE_PRIVATE_LIBGCC +ifeq ($(CONFIG_USE_PRIVATE_LIBGCC),y) +PLATFORM_LIBGCC = arch/$(ARCH)/lib/lib.a +else +PLATFORM_LIBGCC = -L $(CONFIG_USE_PRIVATE_LIBGCC) -lgcc +endif +else +PLATFORM_LIBGCC := -L $(shell dirname `$(CC) $(PLATFORM_CPPFLAGS) \ +-print-libgcc-file-name`) -lgcc +endif This is duplicating the code. I think you should export PLATFORM_LIBGCC from the top Makefile and use it. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv5 00/14] mmc: exynos: code cleanup and support DDR mode
Hi, Thanks Minkyu! To Pantelis, There are the patches related with mmc. So i think you need to check also.(To prevent conflict). Best Regards, Jaehoon Chung On 05/16/2014 03:53 PM, Minkyu Kang wrote: On 16/05/14 13:59, Jaehoon Chung wrote: If card and host are supported DDR mode, then it can be used the DDR mode. This patch-set has dependency about beomho's patch-set. (Based-on u-boot-samsung repository) It's result for loading image. sdhci controller -5260488 bytes read in 259 ms (19.4 MiB/s) dwmmc controller without DDR mode - 5260488 bytes read in 202 ms (24.8 MiB/s) dwmmc controller with DDR mode - 5260488 bytes read in 118 ms (42.5 MiB/s) Download the 400M image with lthor. sdhci controller - 59.4sec (Avg 6.95 MB/s) dwmmc controller without DDR mode - 61.6sec (Avg 6.72MB/s) dwmmc controller with DDR mode - 60.4sec (Avg 6.85MB/s) Beomho Seo (3): arm: exynos: pinmux: add sdmmc4 gpio configratuion arm: exynos: clock: Remove exynos4x12_set_mmc_clk function board: trats2: Enable device tree on Trats2 Jaehoon Chung (11): ARM: exynos: board: change the mmc/sd init sequence ARM: exynos: clock: modify the set_mmc_clk for exynos4 ARM: dts: exynos: rename from EXYNOS5_DWMMC to EXYNOS_DWMMC mmc: exynos_dw_mmc: restore the property into host mmc: remove the unnecessary define and fix the wrong bit control mmc: support the DDR mode for eMMC mmc: dw_mmc: support the DDR mode ARM: dts: exnyos: enable dw-mmc controller mmc: exynos_dw_mmc: enable the DDR mode ARM: exynos4: enable the dwmmc configuration mmc: s5p_sdhci: add the s5p_sdhci_core_init function arch/arm/cpu/armv7/exynos/clock.c | 45 ++- arch/arm/cpu/armv7/exynos/pinmux.c| 35 - arch/arm/dts/exynos4.dtsi |8 ++ arch/arm/dts/exynos4412-trats2.dts| 12 ++ arch/arm/dts/exynos5.dtsi |8 +- arch/arm/include/asm/arch-exynos/clk.h|5 + board/samsung/common/board.c | 13 +- doc/device-tree-bindings/exynos/dwmmc.txt |8 +- drivers/mmc/dw_mmc.c | 12 +- drivers/mmc/exynos_dw_mmc.c | 205 +++-- drivers/mmc/mmc.c | 16 ++- drivers/mmc/s5p_sdhci.c | 42 +++--- include/configs/exynos4-dt.h |3 + include/dwmmc.h |5 + include/fdtdec.h |2 +- include/mmc.h | 25 ++-- lib/fdtdec.c |2 +- 17 files changed, 275 insertions(+), 171 deletions(-) applied to u-boot-samsung. Thanks, Minkyu Kang. ___ 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 v2] examples: select libgcc for non-default architecture
Dear Masahiro, In message 20140516160556.e1a8.aa925...@jp.panasonic.com you wrote: +# Add GCC lib +ifdef CONFIG_USE_PRIVATE_LIBGCC +ifeq ($(CONFIG_USE_PRIVATE_LIBGCC),y) +PLATFORM_LIBGCC = arch/$(ARCH)/lib/lib.a +else +PLATFORM_LIBGCC = -L $(CONFIG_USE_PRIVATE_LIBGCC) -lgcc +endif +else +PLATFORM_LIBGCC := -L $(shell dirname `$(CC) $(PLATFORM_CPPFLAGS) \ + -print-libgcc-file-name`) -lgcc +endif This is duplicating the code. I think you should export PLATFORM_LIBGCC from the top Makefile and use it. Yes, this is what I head in mind, too. we already have this setting, so there should be no need to redo it. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Your own mileage may vary. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] ARM: atmel: sama5d3xek: convert to generic board
Hi, Voice On 4/24/2014 11:42 AM, Bo Shen wrote: Enable CONFIG_SYS_GENERIC_BOARD, so that we get rid of the following warning on boot: Warning: Your board does not use generic board. Please read doc/README.generic-board and take action. Boards not upgraded by the late 2014 may break or be removed. Signed-off-by: Bo Shen voice.s...@atmel.com --- Tested-by: Josh Wu josh...@atmel.com Best Regards, Josh Wu include/configs/sama5d3xek.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/sama5d3xek.h b/include/configs/sama5d3xek.h index 516be85..20a5f6e 100644 --- a/include/configs/sama5d3xek.h +++ b/include/configs/sama5d3xek.h @@ -34,6 +34,8 @@ #define CONFIG_CMD_BOOTZ #define CONFIG_OF_LIBFDT /* Device Tree support */ +#define CONFIG_SYS_GENERIC_BOARD + /* general purpose I/O */ #define CONFIG_AT91_GPIO ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] ARM: atmel: at91sam9m10g45ek: convert to generic board
On 4/24/2014 11:42 AM, Bo Shen wrote: Enable CONFIG_SYS_GENERIC_BOARD, so that we get rid of the following warning on boot: Warning: Your board does not use generic board. Please read doc/README.generic-board and take action. Boards not upgraded by the late 2014 may break or be removed. Signed-off-by: Bo Shen voice.s...@atmel.com Tested-by: Josh Wu josh...@atmel.com Best Regards, Josh Wu --- include/configs/at91sam9m10g45ek.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/at91sam9m10g45ek.h b/include/configs/at91sam9m10g45ek.h index ccfda71..7a3c9b5 100644 --- a/include/configs/at91sam9m10g45ek.h +++ b/include/configs/at91sam9m10g45ek.h @@ -34,6 +34,8 @@ #define CONFIG_CMD_BOOTZ #define CONFIG_OF_LIBFDT +#define CONFIG_SYS_GENERIC_BOARD + /* general purpose I/O */ #define CONFIG_ATMEL_LEGACY /* required until (g)pio is fixed */ #define CONFIG_AT91_GPIO ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] ARMv7: at91: Enable ICache and DCache for at91 armv7 cpu
First, before we enable DCache. We need add dcache support for macb driver. Then enable ICache/DCache. Tested on SAMA5D3x-EK board and AT91SAM9M10G45EK. Josh Wu (2): net: macb: enable dcache in macb ARMv7: at91: enable ICache and DCache. arch/arm/cpu/armv7/at91/cpu.c |6 + board/atmel/sama5d3xek/sama5d3xek.c |6 - drivers/net/macb.c | 51 +++ 3 files changed, 62 insertions(+), 1 deletion(-) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] ARMv7: at91: enable ICache and DCache.
As SAMA5D3 is a at91 ARMv7 cpu, so we should enable LCD DCache
flush for SAMA5D3X-EK.
Signed-off-by: Josh Wu josh...@atmel.com
---
arch/arm/cpu/armv7/at91/cpu.c |6 ++
board/atmel/sama5d3xek/sama5d3xek.c |6 +-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/at91/cpu.c b/arch/arm/cpu/armv7/at91/cpu.c
index 2fbf60d..6f2164f 100644
--- a/arch/arm/cpu/armv7/at91/cpu.c
+++ b/arch/arm/cpu/armv7/at91/cpu.c
@@ -61,6 +61,12 @@ int print_cpuinfo(void)
void enable_caches(void)
{
+#ifndef CONFIG_SYS_ICACHE_OFF
+ icache_enable();
+#endif
+#ifndef CONFIG_SYS_DCACHE_OFF
+ dcache_enable();
+#endif
}
unsigned int get_chip_id(void)
diff --git a/board/atmel/sama5d3xek/sama5d3xek.c
b/board/atmel/sama5d3xek/sama5d3xek.c
index c835c12..1fc91d9 100644
--- a/board/atmel/sama5d3xek/sama5d3xek.c
+++ b/board/atmel/sama5d3xek/sama5d3xek.c
@@ -200,8 +200,12 @@ int board_init(void)
at91_gmac_hw_init();
#endif
#ifdef CONFIG_LCD
- if (has_lcdc())
+ if (has_lcdc()) {
sama5d3xek_lcd_hw_init();
+
+ /* Enable flushing as we enabled dcache */
+ lcd_set_flush_dcache(1);
+ }
#endif
return 0;
}
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] net: macb: enable dcache in macb
Add to code to flush the dcache after we writing in DMA buffer.
Also we need invalidate the dcache before we check the status in the
DMA buffer.
Tested in SAMA5D3x-EK with gmac0. Tftp download speed shows in below:
Disable DCache: 1.1 MiB/s
Enable DCache: 1.6 MiB/s
Increase speed with about 40%.
The code should have no impact with the boards which are not
enable_dcache().
Tested in AT91SAM9M10G45EK.
Signed-off-by: Josh Wu josh...@atmel.com
---
drivers/net/macb.c | 51 +++
1 file changed, 51 insertions(+)
diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index 781a272..b18f07b 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -194,6 +194,39 @@ int macb_miiphy_write(const char *devname, u8 phy_adr, u8
reg, u16 value)
}
#endif
+#defineIS_RX 1
+#defineIS_TX 0
+static inline void macb_invalidate_ring_desc(struct macb_device *macb, bool
is_rx)
+{
+ if (is_rx)
+ invalidate_dcache_range(macb-rx_ring_dma, macb-rx_ring_dma +
+ CONFIG_SYS_MACB_RX_RING_SIZE * sizeof(struct
macb_dma_desc));
+ else
+ invalidate_dcache_range(macb-tx_ring_dma, macb-tx_ring_dma +
+ CONFIG_SYS_MACB_TX_RING_SIZE * sizeof(struct
macb_dma_desc));
+}
+
+static inline void macb_flush_ring_desc(struct macb_device *macb, bool is_rx)
+{
+ if (is_rx)
+ flush_dcache_range(macb-rx_ring_dma, macb-rx_ring_dma +
+ CONFIG_SYS_MACB_RX_RING_SIZE * sizeof(struct
macb_dma_desc));
+ else
+ flush_dcache_range(macb-tx_ring_dma, macb-tx_ring_dma +
+ CONFIG_SYS_MACB_TX_RING_SIZE * sizeof(struct
macb_dma_desc));
+}
+
+static inline void macb_flush_rx_buffer(struct macb_device *macb)
+{
+ flush_dcache_range(macb-rx_buffer_dma,
+ macb-rx_buffer_dma + CONFIG_SYS_MACB_RX_BUFFER_SIZE);
+}
+
+static inline void macb_invalidate_rx_buffer(struct macb_device *macb)
+{
+ invalidate_dcache_range(macb-rx_buffer_dma,
+ macb-rx_buffer_dma + CONFIG_SYS_MACB_RX_BUFFER_SIZE);
+}
#if defined(CONFIG_CMD_NET)
@@ -217,6 +250,9 @@ static int macb_send(struct eth_device *netdev, void
*packet, int length)
macb-tx_ring[tx_head].ctrl = ctrl;
macb-tx_ring[tx_head].addr = paddr;
barrier();
+ macb_flush_ring_desc(macb, IS_TX);
+ /* Do we need check paddr and length is dcache line aligned? */
+ flush_dcache_range(paddr, paddr + length);
macb_writel(macb, NCR, MACB_BIT(TE) | MACB_BIT(RE) | MACB_BIT(TSTART));
/*
@@ -225,6 +261,7 @@ static int macb_send(struct eth_device *netdev, void
*packet, int length)
*/
for (i = 0; i = CONFIG_SYS_MACB_TX_TIMEOUT; i++) {
barrier();
+ macb_invalidate_ring_desc(macb, IS_TX);
ctrl = macb-tx_ring[tx_head].ctrl;
if (ctrl TXBUF_USED)
break;
@@ -253,6 +290,8 @@ static void reclaim_rx_buffers(struct macb_device *macb,
unsigned int i;
i = macb-rx_tail;
+
+ macb_invalidate_ring_desc(macb, IS_RX);
while (i new_tail) {
macb-rx_ring[i].addr = ~RXADDR_USED;
i++;
@@ -266,6 +305,7 @@ static void reclaim_rx_buffers(struct macb_device *macb,
}
barrier();
+ macb_flush_ring_desc(macb, IS_RX);
macb-rx_tail = new_tail;
}
@@ -279,6 +319,8 @@ static int macb_recv(struct eth_device *netdev)
u32 status;
for (;;) {
+ macb_invalidate_ring_desc(macb, IS_RX);
+
if (!(macb-rx_ring[rx_tail].addr RXADDR_USED))
return -1;
@@ -292,6 +334,8 @@ static int macb_recv(struct eth_device *netdev)
if (status RXBUF_FRAME_END) {
buffer = macb-rx_buffer + 128 * macb-rx_tail;
length = status RXBUF_FRMLEN_MASK;
+
+ macb_invalidate_rx_buffer(macb);
if (wrapped) {
unsigned int headlen, taillen;
@@ -506,6 +550,9 @@ static int macb_init(struct eth_device *netdev, bd_t *bd)
macb-rx_ring[i].ctrl = 0;
paddr += 128;
}
+ macb_flush_ring_desc(macb, IS_RX);
+ macb_flush_rx_buffer(macb);
+
for (i = 0; i CONFIG_SYS_MACB_TX_RING_SIZE; i++) {
macb-tx_ring[i].addr = 0;
if (i == (CONFIG_SYS_MACB_TX_RING_SIZE - 1))
@@ -513,6 +560,8 @@ static int macb_init(struct eth_device *netdev, bd_t *bd)
else
macb-tx_ring[i].ctrl = TXBUF_USED;
}
+ macb_flush_ring_desc(macb, IS_TX);
+
macb-rx_tail = macb-tx_head = macb-tx_tail = 0;
macb_writel(macb, RBQP, macb-rx_ring_dma);
@@ -663,6 +712,8 @@ int macb_eth_initialize(int id, void *regs, unsigned int
phy_addr)
Re: [U-Boot] [PATCH 2/2] ARMv7: at91: enable ICache and DCache.
Hi Josh,
On 05/16/2014 04:15 PM, Josh Wu wrote:
As SAMA5D3 is a at91 ARMv7 cpu, so we should enable LCD DCache
flush for SAMA5D3X-EK.
Signed-off-by: Josh Wu josh...@atmel.com
---
arch/arm/cpu/armv7/at91/cpu.c |6 ++
board/atmel/sama5d3xek/sama5d3xek.c |6 +-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/at91/cpu.c b/arch/arm/cpu/armv7/at91/cpu.c
index 2fbf60d..6f2164f 100644
--- a/arch/arm/cpu/armv7/at91/cpu.c
+++ b/arch/arm/cpu/armv7/at91/cpu.c
@@ -61,6 +61,12 @@ int print_cpuinfo(void)
void enable_caches(void)
{
+#ifndef CONFIG_SYS_ICACHE_OFF
+ icache_enable();
+#endif
No need this one. Ifdef CONFIG_SYS_ICACHE_OFF, it will be disabled.
+#ifndef CONFIG_SYS_DCACHE_OFF
+ dcache_enable();
+#endif
}
unsigned int get_chip_id(void)
diff --git a/board/atmel/sama5d3xek/sama5d3xek.c
b/board/atmel/sama5d3xek/sama5d3xek.c
index c835c12..1fc91d9 100644
--- a/board/atmel/sama5d3xek/sama5d3xek.c
+++ b/board/atmel/sama5d3xek/sama5d3xek.c
@@ -200,8 +200,12 @@ int board_init(void)
at91_gmac_hw_init();
#endif
#ifdef CONFIG_LCD
- if (has_lcdc())
+ if (has_lcdc()) {
sama5d3xek_lcd_hw_init();
+
+ /* Enable flushing as we enabled dcache */
+ lcd_set_flush_dcache(1);
Why not implement in driver, or else, each SoC enable dcache will need
add this.
+ }
#endif
return 0;
}
Best Regards,
Bo Shen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] corvus: remove unneeded CONFIG_AT91_LEGACY
Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com Cc: Heiko Schocher h...@denx.de --- include/configs/corvus.h |1 - 1 file changed, 1 deletion(-) diff --git a/include/configs/corvus.h b/include/configs/corvus.h index 959e188..631add3 100644 --- a/include/configs/corvus.h +++ b/include/configs/corvus.h @@ -27,7 +27,6 @@ #define CONFIG_SYS_TEXT_BASE 0x73f0 -#define CONFIG_AT91_LEGACY #define CONFIG_ATMEL_LEGACY/* required until (g)pio is fixed */ /* ARM asynchronous clock */ -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] examples: select libgcc for non-default architecture
In case of multilib-enabled toolchains if default architecture differ from the one examples are being built for linker will fail to link example object files with libgcc of another (non-compatible) architecture. Interesting enough for years in main Makefile we used CFLAGS/c_flags for this but not for examples. So fixing it now. Signed-off-by: Alexey Brodkin abrod...@synopsys.com Cc: Masahiro Yamada yamad...@jp.panasonic.com Cc: Tom Rini tr...@ti.com Cc: Wolfgang Denx w...@denx.de --- In v3 we export PLATFORM_LIBGCC from the main Makefile and use it for examples --- Makefile | 1 + examples/standalone/Makefile | 4 +--- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index ff38a43..fd4e176 100644 --- a/Makefile +++ b/Makefile @@ -696,6 +696,7 @@ PLATFORM_LIBGCC := -L $(shell dirname `$(CC) $(c_flags) -print-libgcc-file-name` endif PLATFORM_LIBS += $(PLATFORM_LIBGCC) export PLATFORM_LIBS +export PLATFORM_LIBGCC # Special flags for CPP when processing the linker script. # Pass the version down so we can handle backwards compatibility diff --git a/examples/standalone/Makefile b/examples/standalone/Makefile index 9ab5446..2dacba2 100644 --- a/examples/standalone/Makefile +++ b/examples/standalone/Makefile @@ -38,8 +38,6 @@ targets += $(patsubst $(obj)/%,%,$(LIB)) $(COBJS) $(LIBOBJS-y) LIBOBJS:= $(addprefix $(obj)/,$(LIBOBJS-y)) ELF:= $(addprefix $(obj)/,$(ELF)) -gcclibdir := $(shell dirname `$(CC) -print-libgcc-file-name`) - # For PowerPC there's no need to compile standalone applications as a # relocatable executable. The relocation data is not needed, and # also causes the entry point of the standalone application to be @@ -63,7 +61,7 @@ $(LIB): $(LIBOBJS) FORCE quiet_cmd_link_elf = LD $@ cmd_link_elf = $(LD) $(LDFLAGS) -g -Ttext $(CONFIG_STANDALONE_LOAD_ADDR) \ --o $@ -e $(SYM_PREFIX)$(@F) $ $(LIB) -L$(gcclibdir) -lgcc +-o $@ -e $(SYM_PREFIX)$(@F) $ $(LIB) $(PLATFORM_LIBGCC) $(ELF): $(obj)/%: $(obj)/%.o $(LIB) FORCE $(call if_changed,link_elf) -- 1.9.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] ARM: atmel: at91sam9x5ek: convert to generic board
On 4/24/2014 11:42 AM, Bo Shen wrote: Enable CONFIG_SYS_GENERIC_BOARD, so that we get rid of the following warning on boot: Warning: Your board does not use generic board. Please read doc/README.generic-board and take action. Boards not upgraded by the late 2014 may break or be removed. Signed-off-by: Bo Shen voice.s...@atmel.com Tested on at91sam9x35ek board. Tested-by: Josh Wu josh...@atmel.com Best Regards, Josh Wu --- include/configs/at91sam9x5ek.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/at91sam9x5ek.h b/include/configs/at91sam9x5ek.h index f0a6757..5fc00af 100644 --- a/include/configs/at91sam9x5ek.h +++ b/include/configs/at91sam9x5ek.h @@ -30,6 +30,8 @@ #define CONFIG_CMD_BOOTZ #define CONFIG_OF_LIBFDT +#define CONFIG_SYS_GENERIC_BOARD + /* general purpose I/O */ #define CONFIG_ATMEL_LEGACY /* required until (g)pio is fixed */ #define CONFIG_AT91_GPIO ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Mainline u-boot SPL for socfpga
Hi, On Thu, 2014-05-15 at 07:01 +1200, Charles Manning wrote: On Thursday 15 May 2014 04:42:58 Pavel Machek wrote: Hi! I am trying to understand the state of the socfpga preloader in mainline u-boot. From what I see, this is broken and perhaps has never worked. That's correct AFAICT. Yup, Preloader without the SDRAM would not work correctly. When I build the code in u-boot-socfpga I get a healthy working u-boot-spl.bin of approx 45kbytes. When I build the mainline u-boot code I get a broken u-boot-spl.bin of approx 3kbytes. It seems the mainline u-boot is missing stuff, including the all-critical sdram initialisation without which the SPL is useless. Are you able to build working u-boot proper from recent sources? I know u-boot SPL misses critical parts, but I was told that u-boot proper should have everything. Only... I was not able to get it to work. [I'm attempting to load recent u-boot from patched/old u-boot; I know this is not exactly recommended, but due to spl/proper split, it should work AFAIK... and does for old versions.] I have not tried booting u-boot proper from mainline. It just seemed pointless to me to be working from 2 source trees to make a single product. I will give it a go though. Actually the U-Boot is working. You just need to #undef CONFIG_SOCFPGA_VIRTUAL_TARGET and build it. I loaded it using a working Preloader and I can reach the U-Boot console. U-Boot SPL 2013.01.01 (May 16 2014 - 10:42:39) BOARD : Altera SOCFPGA Cyclone V Board CLOCK: EOSC1 clock 25000 KHz CLOCK: EOSC2 clock 25000 KHz CLOCK: F2S_SDR_REF clock 0 KHz CLOCK: F2S_PER_REF clock 0 KHz CLOCK: MPU clock 925 MHz CLOCK: DDR clock 400 MHz CLOCK: UART clock 10 KHz CLOCK: MMC clock 5 KHz CLOCK: QSPI clock 37 KHz INFO : Watchdog enabled SDRAM: Initializing MMR registers SDRAM: Calibrating PHY SEQ.C: Preparing to start memory calibration SEQ.C: CALIBRATION PASSED SDRAM: 1024 MiB SDRAM: ECC Enabled ALTERA DWMMC: 0 reading u-boot.img reading u-boot.img U-Boot 2014.07-rc1-00079-g2072e72-dirty (May 16 2014 - 15:54:55) CPU : Altera SOCFPGA Platform BOARD : Altera SOCFPGA Cyclone5 Board DRAM: 1 GiB WARNING: Caches not enabled Using default environment In:serial Out: serial Err: serial Net: No ethernet found. Hit any key to stop autoboot: 0 Wrong Image Format for bootm command ERROR: can't get kernel image! SOCFPGA_CYCLONE5 # help ? - alias for 'help' base- print or set address offset bdinfo - print Board Info structure boot- boot default, i.e., run 'bootcmd' bootd - boot default, i.e., run 'bootcmd' bootm - boot application image from memory bootp - boot image via network using BOOTP/TFTP protocol cmp - memory compare coninfo - print console devices and information cp - memory copy crc32 - checksum calculation echo- echo args to console editenv - edit environment variable env - environment handling commands exit- exit script false - do nothing, unsuccessfully fatinfo - print information about filesystem fatload - load binary file from a dos filesystem fatls - list files in a directory (default /) fdt - flattened device tree utility commands go - start application at address 'addr' help- print command description/usage iminfo - print header information for application image imxtract- extract a part of a multi-image itest - return true/false on integer compare loadb - load binary file over serial line (kermit mode) loads - load S-Record file over serial line loadx - load binary file over serial line (xmodem mode) loady - load binary file over serial line (ymodem mode) loop- infinite loop on address range md - memory display mm - memory modify (auto-incrementing address) mw - memory write (fill) nfs - boot image via network using NFS protocol nm - memory modify (constant address) printenv- print environment variables reset - Perform RESET of the CPU run - run commands in an environment variable setenv - set environment variables showvar - print local hushshell variables sleep - delay execution for some time source - run script from memory test- minimal test like /bin/sh tftpboot- boot image via network using TFTP protocol true- do nothing, successfully version - print monitor, compiler and linker version SOCFPGA_CYCLONE5 # As Chin Liang See has said, there are two issues thwarting this: legal AND source conformance. The code we can fix, the legal can only be fixed by bending Altera - I am going to do that too. We are making some progress on this. Once we have final green light, we will start the upstreaming of SDRAM code. :) Thanks Chin Liang Regards Charles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] dfu: Introduction of the dfu_hash_algo env variable for checksum method setting
Hi Wolfgang, Tom, Hi Wolfgang, Dear Lukasz, In message 20140515090904.32f1d13d@amdc2363 you wrote: What I complained about is the change in behaviour. I asked to make the existing behaviour the default, so unaware users will not be affected. Only if you intentionally want some other behaviour you can then enable this by setting the env variable. Well, looking at mainline usage of DFU, Lukasz is speaking for about half of the users / implementors. Since Denx is working with the other half, can you shed some light on actual use vs theoretical possibilities? I don't want to urge anybody on making any conclusion here :-), but I would be very grateful if we could come up with an agreement. As I've stated previously, my opinion is similar to the one presented by Tom in this message. For me it would be best to not calculate any checksum on default and only enable it when needed. I asked Heiko to run some actual tests on the boards where he has to maintain DFU for. For a 288 MiB image he did not measure any difference - with your patch applied, both with and without CRC enabled, we would get the same (slow) 1:54 minutes download time. As I've spoken with Heiko, am33xx uses NAND memory. I deal with eMMC. Moreover, the size of chunks are different - 1 MiB and 32 MiB. I must double check for the rationale for chunk size of 32 MiB at Trats/Trats2 boards. I suspect, that eMMC write performance depend on that. I will perform some performance tests with 1 MiB chunk size and share the result. Unfortunately the 32 MiB is fixed for our platform. since lthor uses it by default. This reinforces my speculation that you are actually addressing the wrong problem. Instead of adding new code and environment variables and making the system even more complex, we should just leave everything as is, During working on this patch I've replaced the crc32() method with the call to hash_method(), which IMHO is welcome. I also don't personally like the crc32, hence I like the choice which this patch gives me to use other algorithm (for which I've got HW support on my platform - e.g. MD5). and you should try to find out why the CRC calculation is so low for you. Checking if caches are enabled is probably among the things that should be done first. L1 is enabled. L2 has been disabled on purpose (power consumption reduction). Regarding L2 - our platform requires SMC calls to enable and manage L2 cache. In my opinion support for this in u-boot is an overkill. Can we conclude this whole discussion? The main point was if we should keep calculating and displaying crc32 as default for DFU transfers. I'm for the option to NOT display and calculate it by default (PATCH v3). -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] at91: move CONFIG_AT91FAMILY from board config file to hardware.h
Signed-off-by: Josh Wu josh...@atmel.com --- arch/arm/include/asm/arch-at91/at91sam9x5.h |2 ++ include/configs/at91sam9m10g45ek.h |1 - include/configs/at91sam9n12ek.h |1 - include/configs/at91sam9x5ek.h |1 - include/configs/sama5d3_xplained.h |1 - include/configs/sama5d3xek.h|1 - 6 files changed, 2 insertions(+), 5 deletions(-) diff --git a/arch/arm/include/asm/arch-at91/at91sam9x5.h b/arch/arm/include/asm/arch-at91/at91sam9x5.h index a471038..36a5cdf 100644 --- a/arch/arm/include/asm/arch-at91/at91sam9x5.h +++ b/arch/arm/include/asm/arch-at91/at91sam9x5.h @@ -12,6 +12,8 @@ #ifndef __AT91SAM9X5_H__ #define __AT91SAM9X5_H__ +#define CONFIG_AT91FAMILY /* it's a member of AT91 family */ + /* * Peripheral identifiers/interrupts. */ diff --git a/include/configs/at91sam9m10g45ek.h b/include/configs/at91sam9m10g45ek.h index 7a3c9b5..5d5fbe5 100644 --- a/include/configs/at91sam9m10g45ek.h +++ b/include/configs/at91sam9m10g45ek.h @@ -22,7 +22,6 @@ #define CONFIG_SYS_AT91_MAIN_CLOCK 1200 /* from 12 MHz crystal */ #define CONFIG_AT91SAM9M10G45EK -#define CONFIG_AT91FAMILY #define CONFIG_CMDLINE_TAG /* enable passing of ATAGs */ #define CONFIG_SETUP_MEMORY_TAGS diff --git a/include/configs/at91sam9n12ek.h b/include/configs/at91sam9n12ek.h index e23549d..ebfc26e 100644 --- a/include/configs/at91sam9n12ek.h +++ b/include/configs/at91sam9n12ek.h @@ -19,7 +19,6 @@ #define CONFIG_SYS_TEXT_BASE 0x26f0 #define CONFIG_ARM926EJS -#define CONFIG_AT91FAMILY /* ARM asynchronous clock */ #define CONFIG_SYS_AT91_SLOW_CLOCK 32768 /* slow clock xtal */ diff --git a/include/configs/at91sam9x5ek.h b/include/configs/at91sam9x5ek.h index f0a6757..b2dd252 100644 --- a/include/configs/at91sam9x5ek.h +++ b/include/configs/at91sam9x5ek.h @@ -18,7 +18,6 @@ #define CONFIG_SYS_AT91_MAIN_CLOCK 1200/* 12 MHz crystal */ #define CONFIG_AT91SAM9X5EK -#define CONFIG_AT91FAMILY #define CONFIG_CMDLINE_TAG /* enable passing of ATAGs */ #define CONFIG_SETUP_MEMORY_TAGS diff --git a/include/configs/sama5d3_xplained.h b/include/configs/sama5d3_xplained.h index 41c946d..d7fb850 100644 --- a/include/configs/sama5d3_xplained.h +++ b/include/configs/sama5d3_xplained.h @@ -18,7 +18,6 @@ #define CONFIG_SYS_AT91_SLOW_CLOCK 32768 #define CONFIG_SYS_AT91_MAIN_CLOCK 1200 /* from 12 MHz crystal */ -#define CONFIG_AT91FAMILY #define CONFIG_ARCH_CPU_INIT #define CONFIG_SKIP_LOWLEVEL_INIT #define CONFIG_BOARD_EARLY_INIT_F diff --git a/include/configs/sama5d3xek.h b/include/configs/sama5d3xek.h index b509c2d..72f0f27 100644 --- a/include/configs/sama5d3xek.h +++ b/include/configs/sama5d3xek.h @@ -21,7 +21,6 @@ #define CONFIG_SYS_AT91_SLOW_CLOCK 32768 #define CONFIG_SYS_AT91_MAIN_CLOCK 1200 /* from 12 MHz crystal */ -#define CONFIG_AT91FAMILY #define CONFIG_ARCH_CPU_INIT #ifndef CONFIG_SPL_BUILD -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ARMv7: at91: enable ICache and DCache.
Hi, Bo
Thanks for the review ;-)
On 5/16/2014 4:29 PM, Bo Shen wrote:
Hi Josh,
On 05/16/2014 04:15 PM, Josh Wu wrote:
As SAMA5D3 is a at91 ARMv7 cpu, so we should enable LCD DCache
flush for SAMA5D3X-EK.
Signed-off-by: Josh Wu josh...@atmel.com
---
arch/arm/cpu/armv7/at91/cpu.c |6 ++
board/atmel/sama5d3xek/sama5d3xek.c |6 +-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/at91/cpu.c
b/arch/arm/cpu/armv7/at91/cpu.c
index 2fbf60d..6f2164f 100644
--- a/arch/arm/cpu/armv7/at91/cpu.c
+++ b/arch/arm/cpu/armv7/at91/cpu.c
@@ -61,6 +61,12 @@ int print_cpuinfo(void)
void enable_caches(void)
{
+#ifndef CONFIG_SYS_ICACHE_OFF
+icache_enable();
+#endif
No need this one. Ifdef CONFIG_SYS_ICACHE_OFF, it will be disabled.
ok, good. I will remove this #if.
+#ifndef CONFIG_SYS_DCACHE_OFF
+dcache_enable();
+#endif
This will be removed too.
}
unsigned int get_chip_id(void)
diff --git a/board/atmel/sama5d3xek/sama5d3xek.c
b/board/atmel/sama5d3xek/sama5d3xek.c
index c835c12..1fc91d9 100644
--- a/board/atmel/sama5d3xek/sama5d3xek.c
+++ b/board/atmel/sama5d3xek/sama5d3xek.c
@@ -200,8 +200,12 @@ int board_init(void)
at91_gmac_hw_init();
#endif
#ifdef CONFIG_LCD
-if (has_lcdc())
+if (has_lcdc()) {
sama5d3xek_lcd_hw_init();
+
+/* Enable flushing as we enabled dcache */
+lcd_set_flush_dcache(1);
Why not implement in driver, or else, each SoC enable dcache will need
add this.
hmm, the thing is some at91 board, for example at91sam9x5ek board, not
defined CONFIG_SYS_DCACHE_OFF, that means DCache is enabled. But
actually it doesn't implement dcache_enable().
In above situation, if we implement it in driver, I can't tell whether
dcache is really enabled or not.
For this reason, I manually call lcd_set_flush_dcache(1) in the board file.
In the future if all boards (use hlcd driver) enabled dcache I will move
this function to hlcd driver.
Best Regards,
Josh Wu
+}
#endif
return 0;
}
Best Regards,
Bo Shen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/t4rdb: Add alternate serdes protocols to align with A-007186
A-007186: SerDes Ring VCO does not maintain lock
throughout specified temperature range.
Option 1 of the workaround states:
-
For all 1.25/2.5/5 GHz protocols, use LC VCO instead
of Ring VCO. Rather than selecting the SRDS_PRTCL_Sx
in the RCW, use the Alternate SRDS_PRTCL_Sx option.
The alternate option has the same functionality as
the original option; the only difference being LC VCO
rather than Ring VCO.
The alternate Protocols are:
Serdes1: 27 instead of 28
Serdes2: Not impacted
Serdes3: 1 instead of 2
Serdes4: 9 instead of 10
Signed-off-by: Chunhe Lan chunhe@freescale.com
---
board/freescale/t4rdb/eth.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/board/freescale/t4rdb/eth.c b/board/freescale/t4rdb/eth.c
index d220475..142c6a8 100644
--- a/board/freescale/t4rdb/eth.c
+++ b/board/freescale/t4rdb/eth.c
@@ -67,7 +67,7 @@ int board_eth_init(bd_t *bis)
/* Register the 10G MDIO bus */
fm_memac_mdio_init(bis, tgec_mdio_info);
- if (srds_prtcl_s1 == 28) {
+ if ((srds_prtcl_s1 == 28) || (srds_prtcl_s1 == 27)) {
/* SGMII */
fm_info_set_phy_address(FM1_DTSEC1, SGMII_PHY_ADDR1);
fm_info_set_phy_address(FM1_DTSEC2, SGMII_PHY_ADDR2);
--
1.7.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] patman: Suppress duplicate signoffs only for real patches
On 05/13/2014 08:14 PM, Simon Glass wrote: There is an unfortunate bug in the signoff suppression logic. The first pass is performed with 'git log', and all signoffs are added to the supression set, such that the second time (when processing the real patches) we always suppress the signoffs. Correct this by only suppressing signoffs in the second pass. Signed-off-by: Simon Glass s...@chromium.org Tested-by: Andreas Bießmann andreas.de...@googlemail.com should be applied ASAP. Patman is a really useful tool but unusable without this patch. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ARMv7: at91: enable ICache and DCache.
Hi Josh,
On 05/16/2014 05:17 PM, Josh Wu wrote:
diff --git a/board/atmel/sama5d3xek/sama5d3xek.c
b/board/atmel/sama5d3xek/sama5d3xek.c
index c835c12..1fc91d9 100644
--- a/board/atmel/sama5d3xek/sama5d3xek.c
+++ b/board/atmel/sama5d3xek/sama5d3xek.c
@@ -200,8 +200,12 @@ int board_init(void)
at91_gmac_hw_init();
#endif
#ifdef CONFIG_LCD
-if (has_lcdc())
+if (has_lcdc()) {
sama5d3xek_lcd_hw_init();
+
+/* Enable flushing as we enabled dcache */
+lcd_set_flush_dcache(1);
Why not implement in driver, or else, each SoC enable dcache will need
add this.
hmm, the thing is some at91 board, for example at91sam9x5ek board, not
defined CONFIG_SYS_DCACHE_OFF, that means DCache is enabled. But
actually it doesn't implement dcache_enable().
In above situation, if we implement it in driver, I can't tell whether
dcache is really enabled or not.
For this reason, I manually call lcd_set_flush_dcache(1) in the board file.
In the future if all boards (use hlcd driver) enabled dcache I will move
this function to hlcd driver.
I don't see any issue to implement this in driver, may be I am wrong?
Can you figure out what issue you met?
Btw, if there is really have issues, can make this condition with
CONFIG_SYS_DCACHE_OFF?
Best Regards,
Josh Wu
Best Regards,
Bo Shen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/3] Add atmel ROM code image
This series add atmelimage support to mkimage. An atmelimage is a quite dumb image type cause it has no real header. The file is mostly unmodified but the 6'th ARM vector gets replaced by the image size to load. Heiko, I know your approach setting the vector in start.S but I think this solution is a bit smarter. We would need to patch at least 2 start.S files (arm926ejs and armv7), maybe also the arm920t one too. In fact is the conversion of executable BLOB to ROM detected executable BLOB something that should really be done afterwards as all other SoC vendors do. In version 2 of this patchset the atmelimage mkimage target can also generate PMECC NAND header. Changes in v2: * do not check filesize in atmelimage * add PMECC header generation and printout * add printout of 6'th vector * add -n switch to mkimage for PMECC type NAND and CONFIG_SYS_NANDFLASH Andreas Bießmann (3): mkimage: add atmelimage arm:at91: enable ROM loadable atmel image sama5d3xek: enable PMECC header generation arch/arm/cpu/armv7/at91/config.mk | 10 ++ common/image.c|1 + doc/README.atmel_pmecc| 30 include/configs/sama5d3xek.h |6 + include/image.h |1 + spl/Makefile | 18 ++ tools/Makefile|1 + tools/atmelimage.c| 345 + tools/imagetool.c |2 + tools/imagetool.h |1 + 10 files changed, 415 insertions(+) create mode 100644 arch/arm/cpu/armv7/at91/config.mk create mode 100644 tools/atmelimage.c -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/3] mkimage: add atmelimage
The new atmelimage converts a machine code BLOB to bootable ROM image. Atmel
ROM has no sophisticated image format, it only checks the first 7 ARM vectors.
The vectors can contain valid B or LDR opcodes, the 6'th vector contains the
image size to load.
Additionally the PMECC header can be written by the atmelimage target. The
parameters must be given via the -n switch as a coma separated list. For
example:
mkimage -T atmelimage \
-n
usePmecc=1,sectorPerPage=4,sectorSize=512,spareSize=64,eccBits=4,eccOffset=36 \
-d spl/u-boot-spl.bin boot.bin
A provided image can be checked for correct header setup. It prints out the
PMECC header parameters if it has one and the 6'th interrupt vector content.
---8---
Image Type: ATMEL ROM-Boot Image with PMECC Header
PMECC header
eccOffset:36
sectorSize: 512
eccBitReq: 4
spareSize:64
nbSectorPerPage: 4
usePmecc: 1
6'th vector has 17044 set
---8---
A SPL binary modified with the atmelimage mkimage target was succesfully
booted on a sama5d34ek via MMC and NAND.
Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com
Cc: Bo Shen voice.s...@atmel.com
Cc: Heiko Schocher h...@denx.de
---
Changes in v2:
* do not check filesize in atmelimage
* add PMECC header generation and printout
* add printout of 6'th vector
common/image.c |1 +
include/image.h|1 +
tools/Makefile |1 +
tools/atmelimage.c | 345
tools/imagetool.c |2 +
tools/imagetool.h |1 +
6 files changed, 351 insertions(+)
create mode 100644 tools/atmelimage.c
diff --git a/common/image.c b/common/image.c
index fcc5a9c..7cb0bd7 100644
--- a/common/image.c
+++ b/common/image.c
@@ -139,6 +139,7 @@ static const table_entry_t uimage_type[] = {
{ IH_TYPE_STANDALONE, standalone, Standalone Program, },
{ IH_TYPE_UBLIMAGE, ublimage, Davinci UBL image,},
{ IH_TYPE_MXSIMAGE, mxsimage, Freescale MXS Boot Image,},
+ { IH_TYPE_ATMELIMAGE, atmelimage, ATMEL ROM-Boot Image,},
{ -1, , , },
};
diff --git a/include/image.h b/include/image.h
index b278778..9c3b9b8 100644
--- a/include/image.h
+++ b/include/image.h
@@ -225,6 +225,7 @@ struct lmb;
#define IH_TYPE_PBLIMAGE 15 /* Freescale PBL Boot Image */
#define IH_TYPE_MXSIMAGE 16 /* Freescale MXSBoot Image */
#define IH_TYPE_GPIMAGE17 /* TI Keystone GPHeader Image
*/
+#define IH_TYPE_ATMELIMAGE 18 /* ATMEL ROM bootable Image */
/*
* Compression Types
diff --git a/tools/Makefile b/tools/Makefile
index 6e43a01..421ff50 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -69,6 +69,7 @@ RSA_OBJS-$(CONFIG_FIT_SIGNATURE) := rsa-sign.o rsa-verify.o
rsa-checksum.o
# common objs for dumpimage and mkimage
dumpimage-mkimage-objs := aisimage.o \
+ atmelimage.o \
$(FIT_SIG_OBJS-y) \
crc32.o \
default_image.o \
diff --git a/tools/atmelimage.c b/tools/atmelimage.c
new file mode 100644
index 000..099a326
--- /dev/null
+++ b/tools/atmelimage.c
@@ -0,0 +1,345 @@
+/*
+ * (C) Copyright 2014
+ * Andreas Bießmann andreas.de...@googlemail.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include imagetool.h
+#include mkimage.h
+
+#include image.h
+
+#define pr_err(fmt, args...) fprintf(stderr, atmelimage Error: fmt, ##args)
+
+static int atmel_check_image_type(uint8_t type)
+{
+ if (type == IH_TYPE_ATMELIMAGE)
+ return EXIT_SUCCESS;
+ else
+ return EXIT_FAILURE;
+}
+
+static uint32_t nand_pmecc_header[52];
+
+/*
+ * A helper struct for parsing the mkimage -n parameter
+ *
+ * Keep in same order as the configs array!
+ */
+static struct pmecc_config {
+ int use_pmecc;
+ int sector_per_page;
+ int spare_size;
+ int ecc_bits;
+ int sector_size;
+ int ecc_offset;
+} pmecc;
+
+/*
+ * Strings used for configure the PMECC header via -n mkimage switch
+ *
+ * We estimate a coma separated list of key=value pairs. The mkimage -n
+ * parameter argument should not contain any whitespace.
+ *
+ * Keep in same order as struct pmecc_config!
+ */
+static const char * const configs[] = {
+ usePmecc,
+ sectorPerPage,
+ spareSize,
+ eccBits,
+ sectorSize,
+ eccOffset
+};
+
+static int atmel_find_pmecc_parameter_in_token(const char *token)
+{
+ size_t pos;
+ char *param;
+
+ debug(token: '%s'\n, token);
+
+ for (pos = 0; pos ARRAY_SIZE(configs); pos++) {
+ if (strncmp(token, configs[pos], strlen(configs[pos])) == 0) {
+
[U-Boot] [PATCH v2 3/3] sama5d3xek: enable PMECC header generation
Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com Cc: Bo Shen voice.s...@atmel.com --- Changes in v2: None include/configs/sama5d3xek.h |6 ++ 1 file changed, 6 insertions(+) diff --git a/include/configs/sama5d3xek.h b/include/configs/sama5d3xek.h index 516be85..bddd7e4 100644 --- a/include/configs/sama5d3xek.h +++ b/include/configs/sama5d3xek.h @@ -201,6 +201,12 @@ #define CONFIG_BOOTCOMMAND nand read 0x2100 0x18 0x8; \ nand read 0x2200 0x20 0x60; \ bootm 0x2200 - 0x2100 +#define CONFIG_SPL_AT91_HEADER_USE_PMECC 1 +#define CONFIG_SPL_AT91_HEADER_SECTOR_PER_PAGE 4 +#define CONFIG_SPL_AT91_HEADER_SECTOR_SIZE CONFIG_PMECC_SECTOR_SIZE +#define CONFIG_SPL_AT91_HEADER_SPARE_SIZE 64 +#define CONFIG_SPL_AT91_HEADER_ECC_BITSCONFIG_PMECC_CAP +#define CONFIG_SPL_AT91_HEADER_ECC_OFFSET 36 #elif CONFIG_SYS_USE_MMC /* bootstrap + u-boot + env in sd card */ #define CONFIG_ENV_IS_IN_MMC -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/3] arm:at91: enable ROM loadable atmel image
For sama5d3xek we need to modify the SPL image for correct detection by ROM code. Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com --- Changes in v2: * add -n switch to mkimage for PMECC type NAND and CONFIG_SYS_NANDFLASH arch/arm/cpu/armv7/at91/config.mk | 10 ++ doc/README.atmel_pmecc| 30 ++ spl/Makefile | 18 ++ 3 files changed, 58 insertions(+) create mode 100644 arch/arm/cpu/armv7/at91/config.mk diff --git a/arch/arm/cpu/armv7/at91/config.mk b/arch/arm/cpu/armv7/at91/config.mk new file mode 100644 index 000..09eab70 --- /dev/null +++ b/arch/arm/cpu/armv7/at91/config.mk @@ -0,0 +1,10 @@ +# +# Copyright (C) 2014, Andreas Bießmann andreas.de...@googlemail.com +# +# SPDX-License-Identifier: GPL-2.0+ +# +ifdef CONFIG_SPL_BUILD +ALL-y += boot.bin +else +ALL-y += u-boot.img +endif diff --git a/doc/README.atmel_pmecc b/doc/README.atmel_pmecc index cf8373b..5a93123 100644 --- a/doc/README.atmel_pmecc +++ b/doc/README.atmel_pmecc @@ -27,3 +27,33 @@ Take AT91SAM9X5EK as an example, the board definition file likes: #define CONFIG_ATMEL_NAND_HW_PMECC 1 #define CONFIG_PMECC_CAP 2 #define CONFIG_PMECC_SECTOR_SIZE 512 + +How to enable PMECC header for direct programmable boot.bin +--- +2014-05-15 Andreas Bießmann andreas.de...@googlemail.com + +The usual way to program SPL into NAND flash is to use the SAM-BA Atmel tool. +This however is often not usable when doing field updates. To be able to +program a SPL binary into NAND flash we need to add the PMECC header to the +binary before. Chapter '12.4.4.1 NAND Flash Boot: NAND Flash Detection' in +sama5d3 SoC spec (as of 03. April 2014). We have a new image type added to +mkimage to generate this PMECC header and integrated into the build process of +SPL. +The required parameters in board configuration header are as follows: + +This example is working for sama5d3xek: + +#define CONFIG_SPL_AT91_HEADER_USE_PMECC 1 +#define CONFIG_SPL_AT91_HEADER_SECTOR_PER_PAGE 4 +#define CONFIG_SPL_AT91_HEADER_SECTOR_SIZE CONFIG_PMECC_SECTOR_SIZE +#define CONFIG_SPL_AT91_HEADER_SPARE_SIZE 64 +#define CONFIG_SPL_AT91_HEADER_ECC_BITSCONFIG_PMECC_CAP +#define CONFIG_SPL_AT91_HEADER_ECC_OFFSET 36 + +It enables the PMECC hardware and set the relevant parameters as known from +the SAM-BA tool. We are able to use other defined values here cause we check +these values in the buildsystem. Therefore the CONFIG_PMECC_SECTOR_SIZE is +expanded to the correct value set some lines above. + +The mkimage image type atmelimage also set the 6'th interrupt vector to the +correct value. This feature can also be used to setup a boot.bin for MMC boot. diff --git a/spl/Makefile b/spl/Makefile index 55500fd..8c6397e 100644 --- a/spl/Makefile +++ b/spl/Makefile @@ -183,6 +183,24 @@ MKIMAGEFLAGS_MLO.byteswap = -T omapimage -n byteswap -a $(CONFIG_SPL_TEXT_BASE) MLO MLO.byteswap: $(obj)/u-boot-spl.bin $(call if_changed,mkimage) +ATMEL_NAND_HEADER = usePmecc=$(CONFIG_SPL_AT91_HEADER_USE_PMECC), \ + sectorPerPage=$(CONFIG_SPL_AT91_HEADER_SECTOR_PER_PAGE), \ + sectorSize=$(CONFIG_SPL_AT91_HEADER_SECTOR_SIZE), \ + spareSize=$(CONFIG_SPL_AT91_HEADER_SPARE_SIZE), \ + eccBits=$(CONFIG_SPL_AT91_HEADER_ECC_BITS), \ + eccOffset=$(CONFIG_SPL_AT91_HEADER_ECC_OFFSET) + +MKIMAGEFLAGS_boot.bin = -T atmelimage + +ifdef CONFIG_ATMEL_NAND_HW_PMECC +ifeq ($(CONFIG_SYS_USE_NANDFLASH),y) +MKIMAGEFLAGS_boot.bin += -n $(subst $(space),,$(ATMEL_NAND_HEADER)) +endif +endif + +boot.bin: $(obj)/u-boot-spl.bin + $(call if_changed,mkimage) + ALL-y += $(obj)/$(SPL_BIN).bin ifdef CONFIG_SAMSUNG -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] at91: move CONFIG_AT91FAMILY from board config file to hardware.h
Hi Josh, On 05/16/2014 04:52 PM, Josh Wu wrote: Signed-off-by: Josh Wu josh...@atmel.com --- arch/arm/include/asm/arch-at91/at91sam9x5.h |2 ++ include/configs/at91sam9m10g45ek.h |1 - include/configs/at91sam9n12ek.h |1 - include/configs/at91sam9x5ek.h |1 - include/configs/sama5d3_xplained.h |1 - include/configs/sama5d3xek.h|1 - 6 files changed, 2 insertions(+), 5 deletions(-) I think this patch should be split into two patches at least. One is move the CONFIG_AT91FAMILY to SoC header (while not hardware.h). The other is to remove multiple times definition CONFIG_AT91FAMILY. Btw, can you add a little bit words into commit message. Best Regards, Bo Shen diff --git a/arch/arm/include/asm/arch-at91/at91sam9x5.h b/arch/arm/include/asm/arch-at91/at91sam9x5.h index a471038..36a5cdf 100644 --- a/arch/arm/include/asm/arch-at91/at91sam9x5.h +++ b/arch/arm/include/asm/arch-at91/at91sam9x5.h @@ -12,6 +12,8 @@ #ifndef __AT91SAM9X5_H__ #define __AT91SAM9X5_H__ +#define CONFIG_AT91FAMILY /* it's a member of AT91 family */ + /* * Peripheral identifiers/interrupts. */ diff --git a/include/configs/at91sam9m10g45ek.h b/include/configs/at91sam9m10g45ek.h index 7a3c9b5..5d5fbe5 100644 --- a/include/configs/at91sam9m10g45ek.h +++ b/include/configs/at91sam9m10g45ek.h @@ -22,7 +22,6 @@ #define CONFIG_SYS_AT91_MAIN_CLOCK 1200 /* from 12 MHz crystal */ #define CONFIG_AT91SAM9M10G45EK -#define CONFIG_AT91FAMILY #define CONFIG_CMDLINE_TAG/* enable passing of ATAGs */ #define CONFIG_SETUP_MEMORY_TAGS diff --git a/include/configs/at91sam9n12ek.h b/include/configs/at91sam9n12ek.h index e23549d..ebfc26e 100644 --- a/include/configs/at91sam9n12ek.h +++ b/include/configs/at91sam9n12ek.h @@ -19,7 +19,6 @@ #define CONFIG_SYS_TEXT_BASE 0x26f0 #define CONFIG_ARM926EJS -#define CONFIG_AT91FAMILY /* ARM asynchronous clock */ #define CONFIG_SYS_AT91_SLOW_CLOCK32768 /* slow clock xtal */ diff --git a/include/configs/at91sam9x5ek.h b/include/configs/at91sam9x5ek.h index f0a6757..b2dd252 100644 --- a/include/configs/at91sam9x5ek.h +++ b/include/configs/at91sam9x5ek.h @@ -18,7 +18,6 @@ #define CONFIG_SYS_AT91_MAIN_CLOCK1200/* 12 MHz crystal */ #define CONFIG_AT91SAM9X5EK -#define CONFIG_AT91FAMILY #define CONFIG_CMDLINE_TAG/* enable passing of ATAGs */ #define CONFIG_SETUP_MEMORY_TAGS diff --git a/include/configs/sama5d3_xplained.h b/include/configs/sama5d3_xplained.h index 41c946d..d7fb850 100644 --- a/include/configs/sama5d3_xplained.h +++ b/include/configs/sama5d3_xplained.h @@ -18,7 +18,6 @@ #define CONFIG_SYS_AT91_SLOW_CLOCK 32768 #define CONFIG_SYS_AT91_MAIN_CLOCK 1200 /* from 12 MHz crystal */ -#define CONFIG_AT91FAMILY #define CONFIG_ARCH_CPU_INIT #define CONFIG_SKIP_LOWLEVEL_INIT #define CONFIG_BOARD_EARLY_INIT_F diff --git a/include/configs/sama5d3xek.h b/include/configs/sama5d3xek.h index b509c2d..72f0f27 100644 --- a/include/configs/sama5d3xek.h +++ b/include/configs/sama5d3xek.h @@ -21,7 +21,6 @@ #define CONFIG_SYS_AT91_SLOW_CLOCK 32768 #define CONFIG_SYS_AT91_MAIN_CLOCK 1200 /* from 12 MHz crystal */ -#define CONFIG_AT91FAMILY #define CONFIG_ARCH_CPU_INIT #ifndef CONFIG_SPL_BUILD ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [AVR32] CONFIG_SYS_TEXT_BASE is missing from atngw100mkii board
Hi Masahiro, On 05/16/2014 07:48 AM, Masahiro Yamada wrote: Hi Andreass, I noticed by chance atngw100mkii board does not define CONFIG_SYS_TEXT_BASE, although the other AVR32 boards define it. Is this your intention, or mistake? oups. I can't remember why this is missing. Maybe cause the CONFIG_SYS_TEXT_BASE is set to 0x0 implicitly? abiessmann@punisher % PATH=$AVR32_PATH:$PATH make atngw100mkii_config Configuring for atngw100mkii board... abiessmann@punisher % PATH=$AVR32_PATH:$PATH make V=1 -j16 CROSS_COMPILE=avr32-linux- | grep CONFIG_SYS_TEXT_BASE avr32-linux-gcc -x c -DDO_DEPS_ONLY -M -Wall -Wstrict-prototypes -Wno-format-security -fno-builtin -ffreestanding -Os -fno-stack-protector -g -Wno-format-nonliteral -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x -DCONFIG_AVR32 -ffixed-r5 -fPIC -mno-init-got -mrelax -ffunction-sections -fdata-sections -mcpu=ap7000 -pipe -Iinclude -I/home/abiessmann/src/u-boot/arch/avr32/include -nostdinc -isystem /opt/OSELAS.Toolchain-2011.11.0/avr32-linux/gcc-4.4.7-uclibc-0.9.33.2-binutils-2.20.1a-kernel-2.6.39-sanitized/lib/gcc/avr32-linux/4.4.7/include -MQ include/autoconf.mk /home/abiessmann/src/u-boot/include/common.h include/autoconf.mk.dep || rm include/autoconf.mk.dep ... 0x0 is the correct address for avr32 devices, so presumably the CONFIG_SYS_TEXT_BASE parameter was forgotten when writing the atngw100mkii header file. I'll prepare a patch to add it. Best regards Andreas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] atngw100mkii: add missing CONFIG_SYS_TEXT_BASE
Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com Cc: Masahiro Yamada yamad...@jp.panasonic.com --- include/configs/atngw100mkii.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/atngw100mkii.h b/include/configs/atngw100mkii.h index 066d09a..7b4f9cf 100644 --- a/include/configs/atngw100mkii.h +++ b/include/configs/atngw100mkii.h @@ -151,6 +151,7 @@ #define CONFIG_SYS_MAX_FLASH_SECT 135 #define CONFIG_SYS_MONITOR_BASECONFIG_SYS_FLASH_BASE +#define CONFIG_SYS_TEXT_BASE 0x #define CONFIG_SYS_INTRAM_BASE INTERNAL_SRAM_BASE #define CONFIG_SYS_INTRAM_SIZE INTERNAL_SRAM_SIZE -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [AVR32] CONFIG_SYS_TEXT_BASE is missing from atngw100mkii board
Hi Andreas, 0x0 is the correct address for avr32 devices, so presumably the CONFIG_SYS_TEXT_BASE parameter was forgotten when writing the atngw100mkii header file. I'll prepare a patch to add it. If CONFIG_SYS_TEXT_BASE is missing, .text section will start at 0x and it works in this case. But it would be better to fix it just in case. Thank you for posting the patch. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] examples: select libgcc for non-default architecture
Dear Alexey Brodkin, In message 1400230457-11075-1-git-send-email-abrod...@synopsys.com you wrote: In case of multilib-enabled toolchains if default architecture differ from the one examples are being built for linker will fail to link example object files with libgcc of another (non-compatible) architecture. Interesting enough for years in main Makefile we used CFLAGS/c_flags for this but not for examples. So fixing it now. Signed-off-by: Alexey Brodkin abrod...@synopsys.com Cc: Masahiro Yamada yamad...@jp.panasonic.com Cc: Tom Rini tr...@ti.com Cc: Wolfgang Denx w...@denx.de --- In v3 we export PLATFORM_LIBGCC from the main Makefile and use it for examples Thanks! Acked-by: WOlfgang Denk w...@denx.de Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Pull the wool over your own eyes!- J.R. Bob Dobbs ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: zynq: sdhci clock frequency init question
On 05/12/2014 08:48 PM, Krunal Desai wrote: From: Michal Simek [mailto:monstr AT monstr.eu] Sent: Wednesday, May 07, 2014 04:46 To: Krunal Desai; u-boot AT lists.denx.de Subject: Re: [U-Boot] ARM: zynq: sdhci clock frequency init question we didn't test this configuration that's why 52MHz is there as default case. I think that should be easily possible to detect MIO setting as we are doing for qspi/nand/usb. (Trying again due to base64-oddness with Outlook) Thanks for the reply Michal; that sounds very sane to me. To be clear, you'd basically read the MIO configuration registers to see whether SD is active on MIO, and if not, assume EMIO? (Or not used?) We have this code in our xilinx repository and I have sent patches for mainline review 2 weeks ago or something like that. I haven't got any NACK and I am going to send pull request to ARM custodian when I fix fpga patches. Looking forward to seeing it, thanks for following up! Sorry for delay. I have sent pull request to Albert http://git.denx.de/?p=u-boot/u-boot-microblaze.git;a=shortlog;h=refs/heads/zynq but here is the code we are talking about. ARM: zynq: Add MIO detection code 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 v4] mx6sabred: Add PFUZE100 PMIC support
Hi Stefano, On Fri, May 9, 2014 at 1:15 PM, Fabio Estevam feste...@gmail.com wrote: From: Fabio Estevam fabio.este...@freescale.com mx6sabresd boards have a PFUZE100 PMIC connected to I2C2 bus. Add support for it Signed-off-by: Fabio Estevam fabio.este...@freescale.com Does this version look good? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc85xx: configs: remove c=ffe from default environment
From: York Sun york...@freescale.com On 05/14/2014 07:33 PM, Kim Phillips wrote: AFAICT, c=ffe does nothing and was a typo from the original commit d17123696c6180ac8b74fbd318bf14652623e982 powerpc/p4080: Add support for the P4080DS board and just kept on getting duplicated in subsequently added board config files. Thanks. I have been trying to get Kumar to respond but haven't heard from him. It does look odd. I think we can delete them. ACK. It was a convenience variable to access ccsrbar space from scripts, but should have been changed to c=fe on p4080 and subsequent soc's. Ed ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] mx6sabred: Add PFUZE100 PMIC support
Hi Fabio, On 16/05/2014 15:06, Fabio Estevam wrote: Hi Stefano, On Fri, May 9, 2014 at 1:15 PM, Fabio Estevam feste...@gmail.com wrote: From: Fabio Estevam fabio.este...@freescale.com mx6sabresd boards have a PFUZE100 PMIC connected to I2C2 bus. Add support for it Signed-off-by: Fabio Estevam fabio.este...@freescale.com Does this version look good? It is fine with me. Acked-by : Stefano Babic sba...@denx.de Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] armv8 relocation questions
hi Darwin, It's a little late. I'm hoping someone can help answer these questions about armv8 relocation. The CONFIG_SYS_TEXT_BASE seems to be be usually setup to a decent amount of alignment. For the purposes of this discussion, let's say it would normally be 0x8800 and all is well. The relocation address moves to near the end of memory, to say, 0xfffa8000. So far so good. Now let's say I want to shift the image a bit so that I can add a small 32-byte header required by a previous bootloader. So I set CONFIG_SYS_TEXT_BASE to 0x8820, and the relocated address is still 0xfffa8000 and the relocated vectors should be at 0xfffa9000. The image crashes so after some debugging, I find that the code appears to be relocated fine, but some sections have symbols that are not relocated properly. The vectors try to relocate to 0xfffa8fe0 and rodata.str1.1 printf format strings are also 0x20 off. There are likely other offset sections with issues as well. The relocation offset is 0x77fa7fe0 due to the calculations in arch/arm/lib/board.c. Simplifying, they look like this: addr = CONFIG_SYS_SDRAM_BASE + gd-ram_size; /* round down to next 4 kB limit */ addr = ~(4096 - 1); debug(Top of RAM usable for U-Boot at: %08lx\n, addr); /* * reserve memory for U-Boot code, data bss * round down to next 4 kB limit */ addr -= gd-mon_len; addr = ~(4096 - 1); addr += 0x20; // hack to adjust relocaddr to aligned address... snip gd-relocaddr = addr; gd-start_addr_sp = addr_sp; gd-reloc_off = addr - _TEXT_BASE; debug(relocation Offset is: %08lx\n, gd-reloc_off); Since _TEXT_BASE is 0x8820 and addr is 0xfffa8000, the reloc_off is a number like 0x77fa7fe0. Now if I add 0x20 to 'addr' above just before the snip, relocaddr becomes 0x77fa8000 and the relocation works perfectly and no more crashes happen. So my question - is the CONFIG_SYS_TEXT_BASE alignment requirement related to to any assumptions in the linker itself about image base alignment, specifically referring to creation of the rela.dyn sections and their use for image relocation? A related question is if CONFIG_SYS_TEXT_BASE needs to be at a specific alignment. The maximum alignment in the armv8 code base is .align 11 which I believe means 0x800 or 2048. Note that an armv7 target appears to relocate properly with smaller offsets such as 0x20. Thanks. I traced the problem you described and found it is caused by 'adrp' instruction. 'adrp' instruction produces 4kb aligned address of a label. So, if CONFIG_SYS_TEXT_BASE is not 4kb aligned the address produced by 'adrp' and following 'add' instruction will be incorrect. For example, if CONFIG_SYS_TEXT_BASE = 0x20 then address of '_start' is 0x20 and address of '_end_ofs' is 0x30, where u-boot access variable '_end_ofs' gcc generate code as following: adrp x0, ... add x0, x0, 0x30 We noticed that 0x30 is added to 'x0' to produce the address of '_end_ofs'. So when CONFIG_SYS_TEXT_BASE=0x20 and relocated destination address is not 0x020 register x0 contain incorrect address of '_end_ofs'. David. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
Hi Tom,
On Tue, 13 May 2014 21:36:51 -0400, Tom Rini tr...@ti.com wrote:
Hey,
The following changes since commit d2a3e911390f9fc4d8c0ee4b3c7fc75f4fd3fd19:
Merge branch 'u-boot/master' (2014-05-09 11:50:14 +0200)
are available in the git repository at:
git://git.denx.de/u-boot-ti.git master
for you to fetch changes up to 97eeae1a0735fc17351f10b9978e966392badedc:
mtd: nand: omap_gpmc: Fix update of read_ecc in oob (2014-05-13 19:48:17
-0400)
Ash Charles (1):
am335x: pepper: Add Gumstix Pepper AM335x-based machine
Belisko Marek (1):
mtd: nand: omap_gpmc: Fix update of read_ecc in oob
Christian Riesch (1):
arm, davinci: Use CONFIG_SPL_PAD_TO for padding the SPL in an ais image
Dmitry Lifshitz (3):
ARM: OMAP5: add UART4 support
ARM: OMAP5: Power: add LDO2 support for Palmas driver
ARM: OMAP5: add CKO buffer control mask
Egli, Samuel (7):
siemens: cosmetic: remove unused and rename defines
siemens: update DDR3 parameters for dxr2
siemens: add led cmd for flexible LED control
siemens: change LED indication in DFU mode
siemens: cosmetic: rename project_dir
siemens:cosmetic, dxr2: rename dxr2 to draco
siemens, draco: add new target
Khoronzhuk, Ivan (1):
config: k2hk_evm: Add generic board support
Robert Nelson (2):
omap3_beagle: use omap3-beagle-xm-ab.dtb for the xM AB revision
omap3_beagle: xM A/B validate new dtb exits in file system
Yegor Yefremov (1):
am33xx: add SSC enable macro
Makefile |2 +-
arch/arm/include/asm/arch-am33xx/clock.h |2 +
arch/arm/include/asm/arch-omap5/clock.h |3 +
arch/arm/include/asm/arch-omap5/omap.h |1 +
board/gumstix/pepper/Makefile| 13 ++
board/gumstix/pepper/board.c | 226
++
board/gumstix/pepper/board.h | 19 +++
board/gumstix/pepper/mux.c | 78 +++
board/siemens/common/board.c | 46 +-
board/siemens/{dxr2 = draco}/Makefile |0
board/siemens/{dxr2 = draco}/board.c| 112 ---
board/siemens/{dxr2 = draco}/board.h| 26 ++--
board/siemens/{dxr2 = draco}/mux.c |2 +-
board/siemens/pxm2/board.c | 10 +-
board/siemens/rut/board.c|2 +-
boards.cfg |4 +-
drivers/mtd/nand/omap_gpmc.c |2 +-
include/configs/da850evm.h |1 +
include/configs/draco.h | 92
include/configs/dxr2.h |4 +-
include/configs/k2hk_evm.h |1 +
include/configs/omap3_beagle.h | 10 +-
include/configs/pepper.h | 99 +
include/configs/pxm2.h |2 +-
include/configs/siemens-am33x-common.h |8 +-
include/palmas.h |4 +
26 files changed, 686 insertions(+), 83 deletions(-)
create mode 100644 board/gumstix/pepper/Makefile
create mode 100644 board/gumstix/pepper/board.c
create mode 100644 board/gumstix/pepper/board.h
create mode 100644 board/gumstix/pepper/mux.c
rename board/siemens/{dxr2 = draco}/Makefile (100%)
rename board/siemens/{dxr2 = draco}/board.c (63%)
rename board/siemens/{dxr2 = draco}/board.h (71%)
rename board/siemens/{dxr2 = draco}/mux.c (99%)
create mode 100644 include/configs/draco.h
create mode 100644 include/configs/pepper.h
Thanks!
Applied to u-boot-arm/master, thanks!
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-sh/rmobile into u-boot-arm/master
Hi Nobuhiro, On Fri, 16 May 2014 11:14:26 +0900, Nobuhiro Iwamatsu iwama...@nigauri.org wrote: Hi, Albert. Could you apply this PR? Sorry, for some reason it was off my radar. Will apply it along with the pending ones. Best regards, Nobuhiro Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-sh/rmobile into u-boot-arm/master
Hi Albert, On Fri, 16 May 2014 17:22:41 +0200, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Nobuhiro, On Fri, 16 May 2014 11:14:26 +0900, Nobuhiro Iwamatsu iwama...@nigauri.org wrote: Hi, Albert. Could you apply this PR? Sorry, for some reason it was off my radar. Will apply it along with the pending ones. Hmm, there's a merge conflict in boards.cfg whereby the same board is asigned to two different maintainers: HEAD Active arm armv7 rmobile renesas lager lager_nor lager:NORFLASH Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com Active arm armv7 s5pc1xx samsung goni s5p_goni - Przemyslaw Marczak p.marc...@samsung.com === Active arm armv7 s5pc1xx samsung goni s5p_goni - Mateusz Zalega m.zal...@samsung.com u-boot-sh/rmobile Which one am I supposed to keep? Or both? Best regards, Nobuhiro Amicalement, Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] armv8 relocation questions
On 14-05-16 06:47 AM, feng...@phytium.com.cn wrote: hi Darwin, It's a little late. I'm hoping someone can help answer these questions about armv8 relocation. The CONFIG_SYS_TEXT_BASE seems to be be usually setup to a decent amount of alignment. For the purposes of this discussion, let's say it would normally be 0x8800 and all is well. The relocation address moves to near the end of memory, to say, 0xfffa8000. So far so good. Now let's say I want to shift the image a bit so that I can add a small 32-byte header required by a previous bootloader. So I set CONFIG_SYS_TEXT_BASE to 0x8820, and the relocated address is still 0xfffa8000 and the relocated vectors should be at 0xfffa9000. The image crashes so after some debugging, I find that the code appears to be relocated fine, but some sections have symbols that are not relocated properly. The vectors try to relocate to 0xfffa8fe0 and rodata.str1.1 printf format strings are also 0x20 off. There are likely other offset sections with issues as well. The relocation offset is 0x77fa7fe0 due to the calculations in arch/arm/lib/board.c. Simplifying, they look like this: addr = CONFIG_SYS_SDRAM_BASE + gd-ram_size; /* round down to next 4 kB limit */ addr = ~(4096 - 1); debug(Top of RAM usable for U-Boot at: %08lx\n, addr); /* * reserve memory for U-Boot code, data bss * round down to next 4 kB limit */ addr -= gd-mon_len; addr = ~(4096 - 1); addr += 0x20; // hack to adjust relocaddr to aligned address... snip gd-relocaddr = addr; gd-start_addr_sp = addr_sp; gd-reloc_off = addr - _TEXT_BASE; debug(relocation Offset is: %08lx\n, gd-reloc_off); Since _TEXT_BASE is 0x8820 and addr is 0xfffa8000, the reloc_off is a number like 0x77fa7fe0. Now if I add 0x20 to 'addr' above just before the snip, relocaddr becomes 0x77fa8000 and the relocation works perfectly and no more crashes happen. So my question - is the CONFIG_SYS_TEXT_BASE alignment requirement related to to any assumptions in the linker itself about image base alignment, specifically referring to creation of the rela.dyn sections and their use for image relocation? A related question is if CONFIG_SYS_TEXT_BASE needs to be at a specific alignment. The maximum alignment in the armv8 code base is .align 11 which I believe means 0x800 or 2048. Note that an armv7 target appears to relocate properly with smaller offsets such as 0x20. Thanks. I traced the problem you described and found it is caused by 'adrp' instruction. 'adrp' instruction produces 4kb aligned address of a label. So, if CONFIG_SYS_TEXT_BASE is not 4kb aligned the address produced by 'adrp' and following 'add' instruction will be incorrect. For example, if CONFIG_SYS_TEXT_BASE = 0x20 then address of '_start' is 0x20 and address of '_end_ofs' is 0x30, where u-boot access variable '_end_ofs' gcc generate code as following: adrp x0, ... add x0, x0, 0x30 We noticed that 0x30 is added to 'x0' to produce the address of '_end_ofs'. So when CONFIG_SYS_TEXT_BASE=0x20 and relocated destination address is not 0x020 register x0 contain incorrect address of '_end_ofs'. Thank you David. I agree that the adrp will cause problems if the string sections and label used are not relocated to correct boundaries. The adrp used before the relocation works because the symbols are on aligned boundaries. I think I have a way to explain this problem better now. 1. Working generic code: CONFIG_SYS_TEXT_BASE = 0x8800 unrelocated vectors = 0x888001000 relocation address = 0xfffa8000 = 0xfffa8000 - 0x8800 relocation offset = 77fa8000 relocated vectors = 0xfffa9000 (0x800 alignment, but pushed to fffa9000 because of code after 0xfffa8800) Now in this case, the .align directive for the vectors section wants the vectors sitting at 0x800 alignment, which they are. When the symbols are relocated, the vectors are now at 0xfffa9000 which is aligned properly. 2. Failing offset case: CONFIG_SYS_TEXT_BASE = 0x8820 unrelocated vectors = 0x888001000 (respecting .align 11 directive) relocation address = 0xfffa8000 relocation offset = 77fa7fe0 = 0xfffa8000 - 0x8820 relocated vectors = 0xfffa8fe0 (BAD ALIGNMENT) Now the relocated rodata.str1.1 string tables are not aligned, which I believe breaks the adrp instruction. The strings are offset by 0x20 and the printf fails. 3. Fixed offset case: CONFIG_SYS_TEXT_BASE = 0x8820 unrelocated vectors = 0x888001000 (respecting .align 11 directive) relocation address = 0xfffa8020 relocation offset = 77fa8000 = 0xfffa8020 - 0x8820 relocated vectors = 0xfffa9000 (GOOD ALIGNMENT, respects .align 11 after relocation) So in this fixed offset case, the adrp label is aligned to a 4K page size. General comments: Any section in the image that requires a particular alignment must have that alignment
[U-Boot] [PATCH] armv7:TI: Add asm/ti-common/sys_proto.h and migrate omap_hw_init_context
The omap_hw_init_context function (and assorted helpers) is the same for
all OMAP-derived parts as when CHSETTINGS are used, that's the same and
our DDR base is also always the same. In order to make this common we
simply need to update the names of the define for DDR address space
which is also common.
Cc: Sricharan R. r.sricha...@ti.com
Cc: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Tom Rini tr...@ti.com
---
arch/arm/cpu/armv7/omap-common/hwinit-common.c |4 +-
arch/arm/include/asm/arch-am33xx/sys_proto.h |1 +
arch/arm/include/asm/arch-omap4/sys_proto.h| 51 +
arch/arm/include/asm/arch-omap5/omap.h |5 --
arch/arm/include/asm/arch-omap5/sys_proto.h| 50 +---
arch/arm/include/asm/omap_common.h |6 --
arch/arm/include/asm/ti-common/sys_proto.h | 72
7 files changed, 77 insertions(+), 112 deletions(-)
create mode 100644 arch/arm/include/asm/ti-common/sys_proto.h
diff --git a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
index 8ebc0ce..132454c 100644
--- a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
+++ b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
@@ -194,8 +194,8 @@ u32 omap_sdram_size(void)
addr = section EMIF_SYS_ADDR_MASK;
/* See if the address is valid */
- if ((addr = DRAM_ADDR_SPACE_START)
- (addr DRAM_ADDR_SPACE_END)) {
+ if ((addr = TI_ARMV7_DRAM_ADDR_SPACE_START)
+ (addr TI_ARMV7_DRAM_ADDR_SPACE_END)) {
size = ((section EMIF_SYS_SIZE_MASK)
EMIF_SYS_SIZE_SHIFT);
size = 1 size;
diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h
b/arch/arm/include/asm/arch-am33xx/sys_proto.h
index 91ff2ad..33a82fc 100644
--- a/arch/arm/include/asm/arch-am33xx/sys_proto.h
+++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h
@@ -11,6 +11,7 @@
#ifndef _SYS_PROTO_H_
#define _SYS_PROTO_H_
#include linux/mtd/omap_gpmc.h
+#include asm/ti-common/sys_proto.h
#include asm/arch/cpu.h
#define BOARD_REV_ID 0x0
diff --git a/arch/arm/include/asm/arch-omap4/sys_proto.h
b/arch/arm/include/asm/arch-omap4/sys_proto.h
index 80172f3..83d858f 100644
--- a/arch/arm/include/asm/arch-omap4/sys_proto.h
+++ b/arch/arm/include/asm/arch-omap4/sys_proto.h
@@ -14,6 +14,7 @@
#include asm/omap_common.h
#include linux/mtd/omap_gpmc.h
#include asm/arch/mux_omap4.h
+#include asm/ti-common/sys_proto.h
DECLARE_GLOBAL_DATA_PTR;
@@ -53,54 +54,4 @@ int omap_vc_bypass_send_value(u8 sa, u8 reg_addr, u8
reg_data);
u32 warm_reset(void);
void force_emif_self_refresh(void);
void setup_warmreset_time(void);
-
-static inline u32 running_from_sdram(void)
-{
- u32 pc;
- asm volatile (mov %0, pc : =r (pc));
- return ((pc = OMAP44XX_DRAM_ADDR_SPACE_START)
- (pc OMAP44XX_DRAM_ADDR_SPACE_END));
-}
-
-static inline u8 uboot_loaded_by_spl(void)
-{
- /*
-* u-boot can be running from sdram either because of configuration
-* Header or by SPL. If because of CH, then the romcode sets the
-* CHSETTINGS executed bit to true in the boot parameter structure that
-* it passes to the bootloader.This parameter is stored in the ch_flags
-* variable by both SPL and u-boot.Check out for CHSETTINGS, which is a
-* mandatory section if CH is present.
-*/
- if ((gd-arch.omap_boot_params.ch_flags) (CH_FLAGS_CHSETTINGS))
- return 0;
- else
- return running_from_sdram();
-}
-/*
- * The basic hardware init of OMAP(s_init()) can happen in 4
- * different contexts:
- * 1. SPL running from SRAM
- * 2. U-Boot running from FLASH
- * 3. Non-XIP U-Boot loaded to SDRAM by SPL
- * 4. Non-XIP U-Boot loaded to SDRAM by ROM code using the
- * Configuration Header feature
- *
- * This function finds this context.
- * Defining as inline may help in compiling out unused functions in SPL
- */
-static inline u32 omap_hw_init_context(void)
-{
-#ifdef CONFIG_SPL_BUILD
- return OMAP_INIT_CONTEXT_SPL;
-#else
- if (uboot_loaded_by_spl())
- return OMAP_INIT_CONTEXT_UBOOT_AFTER_SPL;
- else if (running_from_sdram())
- return OMAP_INIT_CONTEXT_UBOOT_AFTER_CH;
- else
- return OMAP_INIT_CONTEXT_UBOOT_FROM_NOR;
-#endif
-}
-
#endif
diff --git a/arch/arm/include/asm/arch-omap5/omap.h
b/arch/arm/include/asm/arch-omap5/omap.h
index 19fdece..54fc825 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -23,11 +23,6 @@
#define OMAP54XX_L4_WKUP_BASE 0x4Ae0
#define OMAP54XX_L4_PER_BASE 0x4800
-#define OMAP54XX_DRAM_ADDR_SPACE_START 0x8000
-#define OMAP54XX_DRAM_ADDR_SPACE_END 0x
-#define DRAM_ADDR_SPACE_START OMAP54XX_DRAM_ADDR_SPACE_START
-#define
Re: [U-Boot] [PULL] : Please pull u-boot-imx
Hi Stefano, On Thu, 15 May 2014 11:02:01 +0200, Stefano Babic sba...@denx.de wrote: Hi Albert, please pull from u-boot-imx, thanks ! The following changes since commit d2a3e911390f9fc4d8c0ee4b3c7fc75f4fd3fd19: Merge branch 'u-boot/master' (2014-05-09 11:50:14 +0200) are available in the git repository at: git://www.denx.de/git/u-boot-imx.git master for you to fetch changes up to e7f9350525d73233d4eaf1793f8fe618e9fd4910: Merge branch 'master' of git://git.denx.de/u-boot-arm (2014-05-15 10:27:32 +0200) Eric Benard (8): imx-common: add board_video_skip nitrogen6x: use common board_video_skip mx6sabresd: use common board_video_skip RiOTboard and MarSBoard: add new boards support imx-common/video: add detect_hdmi nitrogen6x: use common detect_hdmi mx6sabresd: use common detect_hdmi embest/mx6boards: use common detect_hdmi Eric Nelson (1): ARM: imx6: nitrogen6x: Enable CONFIG_SYS_GENERIC_BOARD Fabio Estevam (11): wandboard: Convert to generic board mx53loco: Convert to generic board mx6sabre_common: Convert to generic board mx53ard: Convert to generic board mx53smd: Convert to generic board mx53evk: Convert to generic board udoo: Convert to generic board hummingboard: Convert to generic board mx6slevk: Add SPI NOR flash support nitrogen6x: Fix the PAD settings for the ECSPI chipselect iomux-v3: Add support for mx6sl LVE bit Marek Vasut (1): arm: mxs: Enable CONFIG_SYS_GENERIC_BOARD Otavio Salvador (2): wandboard: add Future Eletronics 7 WVGA LCD extension board wandboard: Pass video kernel arguments for HDMI and LCD Stefano Babic (3): mx6: fix weird formatting in imx6q-sabreauto.dts Merge branch 'master' of git://git.denx.de/u-boot-arm Merge branch 'master' of git://git.denx.de/u-boot-arm Thomas Diener (2): imx25: Add new hardware registers video: Add support for imx25 lcd controller Tim Harvey (10): ventana: fixed comments in eeprom header ventana: remove redundant include power: make pfuze100 be able to coexist with other pmics ventana: use non-generic pfuze100 init power: Add support for LTC3676 PMIC ventana: Add support for the LTC3676 PMIC imx6: ventana: fix system-serial dt property imx: ventana: Convert to generic board imx: ventana: add HDMI and LVDS display capability nand: remove CONFIG_SYS_NAND_PAGE_SIZE arch/arm/dts/imx6q-sabreauto.dts| 10 +- arch/arm/imx-common/Makefile| 1 + arch/arm/imx-common/iomux-v3.c | 8 + arch/arm/imx-common/video.c | 65 arch/arm/include/asm/arch-mx25/imx-regs.h | 175 arch/arm/include/asm/arch-mx6/mx6sl_pins.h | 4 + arch/arm/include/asm/imx-common/iomux-v3.h | 5 + arch/arm/include/asm/imx-common/video.h | 24 +++ board/boundary/nitrogen6x/nitrogen6x.c | 69 +--- board/embest/mx6boards/Makefile | 9 ++ board/embest/mx6boards/mx6boards.c | 601 + board/freescale/mx6sabresd/mx6sabresd.c | 67 +--- board/freescale/mx6slevk/mx6slevk.c | 20 +++ board/gateworks/gw_ventana/gw_ventana.c | 215 ++--- board/gateworks/gw_ventana/ventana_eeprom.h | 14 +- board/wandboard/wandboard.c | 146 ++--- boards.cfg | 2 + common/spl/spl_nand.c | 2 +- drivers/power/pmic/Makefile | 1 + drivers/power/pmic/pmic_ltc3676.c | 32 drivers/power/pmic/pmic_pfuze100.c | 2 +- drivers/video/Makefile | 1 + drivers/video/imx25lcdc.c | 121 ++ include/configs/embestmx6boards.h | 336 +++ include/configs/gw_ventana.h| 20 +++ include/configs/hummingboard.h | 2 + include/configs/m28evk.h| 1 - include/configs/mx53ard.h | 2 + include/configs/mx53evk.h | 2 + include/configs/mx53loco.h | 2 + include/configs/mx53smd.h | 2 + include/configs/mx6sabre_common.h | 2 + include/configs/mx6sabresd.h| 1 + include/configs/mx6slevk.h | 12 ++ include/configs/mxs.h | 1 + include/configs/nitrogen6x.h| 2 + include/configs/udoo.h | 2 + include/configs/wandboard.h | 38 - include/power/ltc3676_pmic.h| 51 ++
[U-Boot] error when building env
Hi, when trying to build env with -mfloat-abi=hard I'm hitting this error: /opt/openwrt/trunk/staging_dir/toolchain-arm_cortex-a9+neon_gcc-4.8-linaro_uClibc-0.9.33.2_eabi/bin/arm-openwrt-linux-uclibcgnueabi-gcc -o tools/env/fw_printenv_unstripped tools/env/fw_env.o tools/env/fw_env_main.o tools/env/crc32.o tools/env/ctype.o tools/env/linux_string.o tools/env/env_attr.o tools/env/env_flags.o tools/env/aes.o /opt/build/owrt_staging_dir/toolchain-arm_cortex-a9+neon_gcc-4.8-linaro_uClibc-0.9.33.2_eabi/bin/../lib/gcc/arm-openwrt-linux-uclibcgnueabi/4.8.3/../../../../arm-openwrt-linux-uclibcgnueabi/bin/ld: error: tools/env/fw_printenv_unstripped uses VFP register arguments, tools/env/fw_env.o does not /opt/build/owrt_staging_dir/toolchain-arm_cortex-a9+neon_gcc-4.8-linaro_uClibc-0.9.33.2_eabi/bin/../lib/gcc/arm-openwrt-linux-uclibcgnueabi/4.8.3/../../../../arm-openwrt-linux-uclibcgnueabi/bin/ld: failed to merge target specific data of file tools/env/fw_env.o /opt/build/owrt_staging_dir/toolchain-arm_cortex-a9+neon_gcc-4.8-linaro_uClibc-0.9.33.2_eabi/bin/../lib/gcc/arm-openwrt-linux-uclibcgnueabi/4.8.3/../../../../arm-openwrt-linux-uclibcgnueabi/bin/ld: error: tools/env/fw_printenv_unstripped uses VFP register arguments, tools/env/fw_env_main.o does not /opt/build/owrt_staging_dir/toolchain-arm_cortex-a9+neon_gcc-4.8-linaro_uClibc-0.9.33.2_eabi/bin/../lib/gcc/arm-openwrt-linux-uclibcgnueabi/4.8.3/../../../../arm-openwrt-linux-uclibcgnueabi/bin/ld: failed to merge target specific data of file tools/env/fw_env_main.o /opt/build/owrt_staging_dir/toolchain-arm_cortex-a9+neon_gcc-4.8-linaro_uClibc-0.9.33.2_eabi/bin/../lib/gcc/arm-openwrt-linux-uclibcgnueabi/4.8.3/../../../../arm-openwrt-linux-uclibcgnueabi/bin/ld: error: tools/env/fw_printenv_unstripped uses VFP register arguments, tools/env/crc32.o does not /opt/build/owrt_staging_dir/toolchain-arm_cortex-a9+neon_gcc-4.8-linaro_uClibc-0.9.33.2_eabi/bin/../lib/gcc/arm-openwrt-linux-uclibcgnueabi/4.8.3/../../../../arm-openwrt-linux-uclibcgnueabi/bin/ld: failed to merge target specific data of file tools/env/crc32.o /opt/build/owrt_staging_dir/toolchain-arm_cortex-a9+neon_gcc-4.8-linaro_uClibc-0.9.33.2_eabi/bin/../lib/gcc/arm-openwrt-linux-uclibcgnueabi/4.8.3/../../../../arm-openwrt-linux-uclibcgnueabi/bin/ld: error: tools/env/fw_printenv_unstripped uses VFP register arguments, tools/env/ctype.o does not /opt/build/owrt_staging_dir/toolchain-arm_cortex-a9+neon_gcc-4.8-linaro_uClibc-0.9.33.2_eabi/bin/../lib/gcc/arm-openwrt-linux-uclibcgnueabi/4.8.3/../../../../arm-openwrt-linux-uclibcgnueabi/bin/ld: failed to merge target specific data of file tools/env/ctype.o /opt/build/owrt_staging_dir/toolchain-arm_cortex-a9+neon_gcc-4.8-linaro_uClibc-0.9.33.2_eabi/bin/../lib/gcc/arm-openwrt-linux-uclibcgnueabi/4.8.3/../../../../arm-openwrt-linux-uclibcgnueabi/bin/ld: error: tools/env/fw_printenv_unstripped uses VFP register arguments, tools/env/linux_string.o does not /opt/build/owrt_staging_dir/toolchain-arm_cortex-a9+neon_gcc-4.8-linaro_uClibc-0.9.33.2_eabi/bin/../lib/gcc/arm-openwrt-linux-uclibcgnueabi/4.8.3/../../../../arm-openwrt-linux-uclibcgnueabi/bin/ld: failed to merge target specific data of file tools/env/linux_string.o /opt/build/owrt_staging_dir/toolchain-arm_cortex-a9+neon_gcc-4.8-linaro_uClibc-0.9.33.2_eabi/bin/../lib/gcc/arm-openwrt-linux-uclibcgnueabi/4.8.3/../../../../arm-openwrt-linux-uclibcgnueabi/bin/ld: error: tools/env/fw_printenv_unstripped uses VFP register arguments, tools/env/env_attr.o does not /opt/build/owrt_staging_dir/toolchain-arm_cortex-a9+neon_gcc-4.8-linaro_uClibc-0.9.33.2_eabi/bin/../lib/gcc/arm-openwrt-linux-uclibcgnueabi/4.8.3/../../../../arm-openwrt-linux-uclibcgnueabi/bin/ld: failed to merge target specific data of file tools/env/env_attr.o /opt/build/owrt_staging_dir/toolchain-arm_cortex-a9+neon_gcc-4.8-linaro_uClibc-0.9.33.2_eabi/bin/../lib/gcc/arm-openwrt-linux-uclibcgnueabi/4.8.3/../../../../arm-openwrt-linux-uclibcgnueabi/bin/ld: error: tools/env/fw_printenv_unstripped uses VFP register arguments, tools/env/env_flags.o does not /opt/build/owrt_staging_dir/toolchain-arm_cortex-a9+neon_gcc-4.8-linaro_uClibc-0.9.33.2_eabi/bin/../lib/gcc/arm-openwrt-linux-uclibcgnueabi/4.8.3/../../../../arm-openwrt-linux-uclibcgnueabi/bin/ld: failed to merge target specific data of file tools/env/env_flags.o /opt/build/owrt_staging_dir/toolchain-arm_cortex-a9+neon_gcc-4.8-linaro_uClibc-0.9.33.2_eabi/bin/../lib/gcc/arm-openwrt-linux-uclibcgnueabi/4.8.3/../../../../arm-openwrt-linux-uclibcgnueabi/bin/ld: error: tools/env/fw_printenv_unstripped uses VFP register arguments, tools/env/aes.o does not When env is built with -mfloat-abi=soft everything is fine. Has this been triggered by anyone else? Thanks! Luka ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] error when building env
On Fri, May 16, 2014 at 07:26:51PM +0200, Luka Perkov wrote: Hi, when trying to build env with -mfloat-abi=hard I'm hitting this error: /opt/openwrt/trunk/staging_dir/toolchain-arm_cortex-a9+neon_gcc-4.8-linaro_uClibc-0.9.33.2_eabi/bin/arm-openwrt-linux-uclibcgnueabi-gcc -o tools/env/fw_printenv_unstripped tools/env/fw_env.o tools/env/fw_env_main.o tools/env/crc32.o tools/env/ctype.o tools/env/linux_string.o tools/env/env_attr.o tools/env/env_flags.o tools/env/aes.o /opt/build/owrt_staging_dir/toolchain-arm_cortex-a9+neon_gcc-4.8-linaro_uClibc-0.9.33.2_eabi/bin/../lib/gcc/arm-openwrt-linux-uclibcgnueabi/4.8.3/../../../../arm-openwrt-linux-uclibcgnueabi/bin/ld: error: tools/env/fw_printenv_unstripped uses VFP register arguments, tools/env/fw_env.o does not Odd. I can build 'tools-only' with my hard float toolchain fine. Can you build with V=1 and see what files are perhaps not getting passed in a -mfloat option? -- 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] [U-boot] [Patch 0/2] keystone: nand: add additional nand ecclayout
This series adds a nand ecclayout command to davinci nand that allows the ecclayout of the current nand device to be changed during run time. This feature is useful when using u-boot to write something to nand flash that will be read by other applications, such as ROM bootloader, that expects a different ECC layout. In that case, change the current nand device ecclayout using the nand ecclayout set command before writing the data to nand flash. Based on u-boot.git/master WingMan Kwok (2): common: cmd_nand: add nand ecclayout command mtd: nand: davinci: allow to change ecclayout by ecclayout command common/cmd_nand.c | 115 +++- drivers/mtd/nand/davinci_nand.c | 101 +++ include/nand.h | 10 3 files changed, 225 insertions(+), 1 deletion(-) -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] [Patch 2/2] mtd: nand: davinci: allow to change ecclayout by ecclayout command
From: WingMan Kwok w-kw...@ti.com
This patch adds opportunity to change ecclayout of current nand
device during runtime. So we can change the current nand device
ecclayout using the nand ecclayout set command before writing
the data to nand flash.
Signed-off-by: Hao Zhang hzh...@ti.com
Signed-off-by: WingMan Kwok w-kw...@ti.com
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
drivers/mtd/nand/davinci_nand.c | 101
1 file changed, 101 insertions(+)
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 75b03a7..b33de0d 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -306,6 +306,103 @@ static struct nand_ecclayout
nand_davinci_4bit_layout_oobfirst = {
#endif
};
+#if defined(CONFIG_CMD_NAND_ECCLAYOUT)
+#if defined(CONFIG_SYS_NAND_PAGE_2K)
+static struct nand_ecclayout nand_keystone_rbl_4bit_layout_oobfirst = {
+ .eccbytes = 40,
+ .eccpos = {
+ 6, 7,
+ 8, 9, 10, 11, 12, 13, 14, 15,
+ 22, 23,
+ 24, 25, 26, 27, 28, 29, 30, 31,
+ 38, 39,
+ 40, 41, 42, 43, 44, 45, 46, 47,
+ 54, 55,
+ 56, 57, 58, 59, 60, 61, 62, 63,
+ },
+ .oobfree = {
+ {.offset = 2, .length = 4, },
+ {.offset = 16, .length = 6, },
+ {.offset = 32, .length = 6, },
+ {.offset = 48, .length = 6, },
+ },
+};
+#elif defined(CONFIG_SYS_NAND_PAGE_4K)
+static struct nand_ecclayout nand_keystone_rbl_4bit_layout_oobfirst = {
+ .eccbytes = 80,
+ .eccpos = {
+ 6, 7,
+ 8, 9, 10, 11, 12, 13, 14, 15,
+ 22, 23,
+ 24, 25, 26, 27, 28, 29, 30, 31,
+ 38, 39,
+ 40, 41, 42, 43, 44, 45, 46, 47,
+ 54, 55,
+ 56, 57, 58, 59, 60, 61, 62, 63,
+ 70, 71,
+ 72, 73, 74, 75, 76, 77, 78, 79,
+ 86, 87,
+ 88, 89, 90, 91, 92, 93, 94, 95,
+ 102, 103,
+ 104, 105, 106, 107, 108, 109, 110, 111,
+ 118, 119,
+ 120, 121, 122, 123, 124, 125, 126, 127,
+ },
+ .oobfree = {
+ {.offset = 2, .length = 4, },
+ {.offset = 16, .length = 6, },
+ {.offset = 32, .length = 6, },
+ {.offset = 48, .length = 6, },
+ {.offset = 64, .length = 6, },
+ {.offset = 80, .length = 6, },
+ {.offset = 96, .length = 6, },
+ {.offset = 112, .length = 6, },
+ },
+};
+#endif
+
+#define NAND_ECCLAYOUT_NUM 2
+
+struct nand_ecclayout *davinci_nand_ecclayouts[NAND_ECCLAYOUT_NUM] = {
+ nand_davinci_4bit_layout_oobfirst,
+ nand_keystone_rbl_4bit_layout_oobfirst,
+};
+
+int board_nand_ecclayout_get_idx(struct nand_chip *nand,
+struct nand_ecclayout *p)
+{
+ int i;
+
+ if (!p)
+ return -1;
+
+ for (i = 0; i NAND_ECCLAYOUT_NUM; i++)
+ if (davinci_nand_ecclayouts[i] == p)
+ return i;
+
+ return -1;
+}
+
+struct nand_ecclayout *board_nand_ecclayout_get_layout(struct nand_chip *nand,
+ int idx)
+{
+ if ((idx = 0) (idx NAND_ECCLAYOUT_NUM))
+ return davinci_nand_ecclayouts[idx];
+ else
+ return NULL;
+}
+
+int board_nand_ecclayout_set(struct nand_chip *nand, int idx)
+{
+ if (idx 0 || idx = NAND_ECCLAYOUT_NUM)
+ return -1;
+
+ nand-ecc.layout = davinci_nand_ecclayouts[idx];
+
+ return 0;
+}
+#endif
+
static void nand_davinci_4bit_enable_hwecc(struct mtd_info *mtd, int mode)
{
u32 val;
@@ -631,7 +728,11 @@ void davinci_nand_init(struct nand_chip *nand)
nand-ecc.calculate = nand_davinci_4bit_calculate_ecc;
nand-ecc.correct = nand_davinci_4bit_correct_data;
nand-ecc.hwctl = nand_davinci_4bit_enable_hwecc;
+#ifndef CONFIG_CMD_NAND_ECCLAYOUT
nand-ecc.layout = nand_davinci_4bit_layout_oobfirst;
+#else
+ nand-ecc.layout = nand_keystone_rbl_4bit_layout_oobfirst;
+#endif
#endif
/* Set address of hardware control function */
nand-cmd_ctrl = nand_davinci_hwcontrol;
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] [Patch 1/2] common: cmd_nand: add nand ecclayout command
From: WingMan Kwok w-kw...@ti.com
This commit adds a nand ecclayout command that allows the ecclayout of
the current nand device to be changed during run time. This feature is
useful when using u-boot to write something to nand flash that will be
read by other applications, such as ROM bootloader, that expects a
different ECC layout. In that case, change the current nand device
ecclayout using the nand ecclayout set command before writing the
data to nand flash.
Signed-off-by: WingMan Kwok w-kw...@ti.com
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
common/cmd_nand.c | 115 +-
include/nand.h| 10 +
2 files changed, 124 insertions(+), 1 deletion(-)
diff --git a/common/cmd_nand.c b/common/cmd_nand.c
index 04ab0f1..7cbe6fc 100644
--- a/common/cmd_nand.c
+++ b/common/cmd_nand.c
@@ -462,6 +462,53 @@ static void adjust_size_for_badblocks(loff_t *size, loff_t
offset, int dev)
}
}
+#ifdef CONFIG_CMD_NAND_ECCLAYOUT
+static void nand_print_ecclayout_info(struct nand_ecclayout *p)
+{
+ int i;
+ struct nand_oobfree *oobfree;
+
+ if (!p)
+ return;
+
+ printf( num ecc bytes: %d\n, p-eccbytes);
+ puts( ecc pos:\n);
+
+ for (i = 0; i p-eccbytes; i++) {
+ if (i !(i % 9))
+ printf(\n);
+
+ printf(%2d , p-eccpos[i]);
+ }
+
+ puts(\n oobfree:\n);
+ puts(offset length\n);
+
+ oobfree = p-oobfree;
+ for (i = 0; oobfree-length i MTD_MAX_OOBFREE_ENTRIES_LARGE; i++) {
+ printf( %2d%2d\n, oobfree-offset, oobfree-length);
+ oobfree++;
+ }
+}
+
+static void nand_print_device_ecclayout(int dev)
+{
+ int idx;
+ nand_info_t *nand = nand_info[dev];
+ struct nand_chip *chip = nand-priv;
+
+ idx = board_nand_ecclayout_get_idx(chip, chip-ecc.layout);
+
+ if (idx 0) {
+ puts(no ecc layout\n);
+ return;
+ }
+
+ printf(\necc layout %d:\n, idx);
+ nand_print_ecclayout_info(chip-ecc.layout);
+}
+#endif
+
static int do_nand(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
int i, ret = 0;
@@ -506,8 +553,12 @@ static int do_nand(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
putc('\n');
if (dev 0 || dev = CONFIG_SYS_MAX_NAND_DEVICE)
puts(no devices available\n);
- else
+ else {
nand_print_and_set_info(dev);
+#ifdef CONFIG_CMD_NAND_ECCLAYOUT
+ nand_print_device_ecclayout(dev);
+#endif
+ }
return 0;
}
@@ -836,6 +887,60 @@ static int do_nand(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
}
#endif
+#ifdef CONFIG_CMD_NAND_ECCLAYOUT
+ if (strcmp(cmd, ecclayout) == 0) {
+ int idx;
+ struct nand_ecclayout *p;
+ nand_info_t *nand = nand_info[dev];
+ struct nand_chip *chip = nand-priv;
+
+ if (argc 3) {
+ puts(Current device ecclayout:\n);
+ nand_print_device_ecclayout(dev);
+ return 0;
+ }
+
+ if (!strcmp(argv[2], set)) {
+ if (argc 4)
+ return 1;
+
+ idx = (int)simple_strtoul(argv[3], NULL, 10);
+ if (!board_nand_ecclayout_set(chip, idx)) {
+ p = chip-ecc.layout;
+ p-oobavail = 0;
+ for (i = 0; p-oobfree[i].length
+ i ARRAY_SIZE(p-oobfree); i++)
+ p-oobavail += p-oobfree[i].length;
+
+ nand-oobavail = p-oobavail;
+ } else {
+ printf(Setting current device
+ to ecc layout %d FAILED!\n, idx);
+ }
+
+ return 0;
+ }
+
+ if (strcmp(argv[2], all) != 0)
+ return 1;
+
+ /* show all available ecc layouts */
+ puts(Available ecc layouts:\n);
+
+ idx = 0;
+ while (1) {
+ p = board_nand_ecclayout_get_layout(chip, idx);
+ if (!p)
+ break;
+
+ printf(\n ecc layout %d:\n, idx++);
+ nand_print_ecclayout_info(p);
+ }
+
+ return 0;
+ }
+#endif
+
usage:
return CMD_RET_USAGE;
}
@@ -890,6 +995,14 @@ static char nand_help_text[] =
nand env.oob set
Re: [U-Boot] Pull request: u-boot-sh/rmobile into u-boot-arm/master
Hi Albert, On Fri, 16 May 2014 17:53:21 +0200, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Albert, On Fri, 16 May 2014 17:22:41 +0200, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Nobuhiro, On Fri, 16 May 2014 11:14:26 +0900, Nobuhiro Iwamatsu iwama...@nigauri.org wrote: Hi, Albert. Could you apply this PR? Sorry, for some reason it was off my radar. Will apply it along with the pending ones. Hmm, there's a merge conflict in boards.cfg whereby the same board is asigned to two different maintainers: HEAD Active arm armv7 rmobile renesas lager lager_nor lager:NORFLASH Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com Active arm armv7 s5pc1xx samsung goni s5p_goni - Przemyslaw Marczak p.marc...@samsung.com === Active arm armv7 s5pc1xx samsung goni s5p_goni - Mateusz Zalega m.zal...@samsung.com u-boot-sh/rmobile Which one am I supposed to keep? Or both? Ok, got it (commit bfbc47cc9fc) Amicalement, Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/11] kconfig: add board Kconfig and defconfig files
Wading in here later than I had wanted to, sorry.
On Mon, Apr 28, 2014 at 06:39:33PM +0900, Masahiro Yamada wrote:
On Thu, 24 Apr 2014 14:36:33 -0600
Stephen Warren swar...@wwwdotorg.org wrote:
On 04/23/2014 11:04 PM, Masahiro Yamada wrote:
This commit adds
- arch/*/Kconfig: provide a menu to select target boards
- board/*/Kconfig: set CONFIG macros to the appropriate values
for each board
- configs/*_defconfig: default setting of each board
[snip]
Perhaps we can change the command-line used to build U-Boot, rather than
shoe-horning U-Boot's Kconfig usage to fit that current limitation.
I am afraid something like
make ARCH=arm seaboard_defconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-
is annoying for some users.
This item was an open discussion in the RFC version, but
Simon was the only person who replyed this question.
See
https://www.mail-archive.com/u-boot@lists.denx.de/msg134502.html
How ARCH should be given? section.
Of course, this part is changable if other people accept
Linux's ARCH=${ARCH} way.
Comments are still welcome.
To start with, I think we should try and keep things the way they are
and not have to specify ARCH at least.
Besides, we must configure boards for SPL and TPL too
if they are supported.
For those boards, defconfig files with the same name are placed
in configs/spl/, configs/tpl/ directories.
I really don't think we should have separate defconfig files for SPL/TPL/...
I don't think that the approach of a single huge Kconfig file (albeit
split into multiple included files per architecture and board) is going
to work; it requires a massive amount of irrelevant Kconfig to be
parsed, whereas scanning boards.cfg is a much simpler
scan-until-you-find-a-matching-line approach.
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
+config TARGET_SEABOARD
+ bool Support seaboard
If U-Boot is built like:
make seaboard_config
make
... then I'm not sure why there is a Kconfig option for TARGET_SEABAORD.
Are you intending for the .config file to dictate that we're building
for Seaboard? If so, then presumably the make commands above will no
longer be valid, and if we can change that aspect, why couldn't we
require the user to add the architecture to the build command-line, just
like the kernel does?
While all of us kernel folks have well trained our fingers to add in
ARCH= when building something other than x86 (unless of course we're
doing native kernel compiles, which are a handy stress test of the
system at least), that the kernel happily tries to build for x86
generally isn't the nicest thing ever. Which is why we've all trained
ourselves to pass in ARCH. /end old guy rant
TARGET_SEABOARD is used just for selecting hard-coded
CONFIG_SYS_CPU=armv7(CONFIG_SYS_CPU=arm720t in spl/.config)
CONFIG_SYS_BOARD=seaboard
CONFIG_SYS_VENDOR=nvidia
etc.
You said adding non-user-editable CONFIG to defconfig is odd.
So, this patch selects a board with CONFIG_TARGET_* and then
selects hard-coded macros.
So, here's my question / hope. We can incrementally move from what this
patch provides us today of strict but not as flexible set of Kconfig
choices and options to something more flexible later. For example, this
converts am335x_evm_uart[12345] directly but I would like to just drop
them all and make CONS_INDEX (the only thing different between _uartN
and am335x_evm itself) be a choice the user selects. That's not
something I expect to be done at the start of the series of course.
[snip]
Should SPL/non-SPL be two build targets that get built when you ask to
build for Seaboard, not two entirely unrelated defconfig files?
This is another item worth discussion.
The idea in my mind is to not treat SPL and TPL as special cases.
(This is an idea proposed by Simon.)
I was thinking of handling Non-SPL, SPL, TPL as generic images.
Currently, C sources and Makefiles are really dirty because of
ifdef CONFIG_SPL_BUILD everywhere.
But, roughly, the difference among them is how many CONFIG_ macros
are enabled.
Non-SPL: enable hush command line, many useful commands,
many drivers, net work feature etc. But the image size is big.
SPL: disable hush command line all commands
enable only some drivers enough for loading another image.
The image size is small.
So, in future, many user ediatable settings will be moved to Kconfig.
And then,
config/seaboard_defconfig will include
CONFIG_SYS_HUSH_PARSER=y
CONFIG_CMD_FOO=y
CONFIG_CMD_BAR=y
...
but config/spl/seaboard_defconfig will disable most of them.
But, if people don't like this,
I can change this part as only one defconfig per board
in the next version.
(Instead, we may lose flexibility to some extent
because SPL and non-SPL will share the same defconfig.)
So this I believe answers what I was hoping which is that yes, down the
line more
[U-Boot] Please pull u-boot-x86.git branch tom
Hi Tom,
I collected these three fixes for pulling.
Regards,
Simon
The following changes since commit 2072e7262965bb48d7fffb1e283101e6ed8b21a8:
mvtwsi: Remove unnecessary twsi_baud_rate and twsi_slave_address
globals (2014-05-14 12:59:12 +0200)
are available in the git repository at:
git://git.denx.de/u-boot-x86.git
for you to fetch changes up to 6be6b6bcbac62e356d05bdde488fc9f0eef7084a:
patman: Suppress duplicate signoffs only for real patches
(2014-05-16 11:42:29 -0700)
Masahiro Yamada (2):
Revert sandbox: move source files from board/ to arch/sandbox/
sandbox: set sandbox's vendor to null
Simon Glass (1):
patman: Suppress duplicate signoffs only for real patches
arch/sandbox/lib/Makefile | 2 +-
board/sandbox/Makefile| 7 +++
{doc = board/sandbox}/README.sandbox | 0
{arch/sandbox/lib = board/sandbox}/sandbox.c | 0
boards.cfg| 2 +-
tools/patman/patchstream.py | 3 ++-
6 files changed, 11 insertions(+), 3 deletions(-)
create mode 100644 board/sandbox/Makefile
rename {doc = board/sandbox}/README.sandbox (100%)
rename {arch/sandbox/lib = board/sandbox}/sandbox.c (100%)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/11] kconfig: add board Kconfig and defconfig files
On 05/16/2014 12:55 PM, Tom Rini wrote: Wading in here later than I had wanted to, sorry. On Mon, Apr 28, 2014 at 06:39:33PM +0900, Masahiro Yamada wrote: ... But, if people don't like this, I can change this part as only one defconfig per board in the next version. (Instead, we may lose flexibility to some extent because SPL and non-SPL will share the same defconfig.) So this I believe answers what I was hoping which is that yes, down the line more things will be questions and less things selected, which means defconfig are more about providing config options. And then yes, we need to re-evaluate what we do for SPL/TPL and see if really we can't just handle things with a user-selected CONFIG_SPL/TPL (for the just very different parts) and perhaps decouple these parts of the build. A somewhat tangential thought: I was recently trying to build a really tiny U-Boot. I first tried building a regular main U-Boot, but to get a small enough binary (256KB RAM total), I had to strip too much out to be useful. Without doing that, the resultant run-time image was too large to allow relocation; text+data+bss was more than half the size of my possible RAM footprint. So, I tried switching to building SPL instead, since SPL doesn't do relocation. However, SPL is far too limited in terms of features and APIs to allow the feature-set I want (I wanted device-mode USB, with some custom protocol sitting on top, which I think currently requires pulling in the host-mode EHCI stack, a malloc pool, etc.). I guess I could go add a bunch more stuff to spl/Makefile to start fixing this, but I started wondering exactly why I needed to do that. I'd love to see CONFIG_SPL/CONFIG_TPL completely disappear. Instead, we should just select all the features we want through Kconfig, and things like CONFIG_DO_RELOCATION that the main U-Boot selects, and whatever SPL currently does to minify itself, should be Kconfig options just like any other. Does that seem reasonable? For this part of the conversation, I'm completely ignoring whether we'd then represent our current SPL and main U-Boot binaries via separate user-visible defconfigs, sub-defconfigs pulled in as sub-builds by other defconfigs, or some other means. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] armv8 relocation questions
Dear Darwin, In message 53763b78.6030...@broadcom.com you wrote: 3. Fixed offset case: CONFIG_SYS_TEXT_BASE = 0x8820 You completely fail to respond to my repeated statement that a CONFIG_SYS_TEXT_BASE like this is bogus. I guess i give up on this. Any section in the image that requires a particular alignment must have that alignment respected after relocation. You cannot relocate to an arbitrary address if it breaks the maximum image alignment requirement after relocation. Who was it who asked why we had such unreasonable strict alignment requirements for the relocation address? But if for some reason, the hardware ever required a 0x2000 (.align 13) alignment, then the generic code's 0x1000 (.align 12) relocation alignment would not work because the alignment after relocation would not respect the .align 13 directive. We just haven't run into this issue Is this a theoretical or a practical question? Where exactly do you have such a use case? yet and may never do so, but it is important to understand the limitations of relocation relative to image alignment requirements. The current hardcoded 4096 (0x1000) image relocation alignment just happens to work and looks nice, that's all, but not by consideration of image alignment. Ummm... experience from 15 years of PPCBoot / U-Boot history don't count here, I guess? And if any text base alignment is less than the image's maximum alignment requirement, the load will fail, and then we likely scratch our heads and set the CONFIG_SYS_TEXT_BASE alignment higher until it works. CONFIG_SYS_TEXT_BASE should always be reasonable aligned. There is no good reason to add arbitrary small offsets like you do. I've explained to you a feww times before that you should include your header into the text segment, and the problem would be just gone. But since most people just use higher alignments naturally, this issues remain mostly hidden I think. Not hidden, they don't exist. Non-random sig this time. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. - Doug Gwyn ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-sh/rmobile into u-boot-arm/master
Hi Nobuhiro,
On Fri, 2 May 2014 05:14:44 +0900, Nobuhiro Iwamatsu
iwama...@nigauri.org wrote:
Dear Albert Aribaud,
Please pull u-boot-sh/rmobile into u-boot-arm/master.
The following changes since commit c9aab0f9dd23fddcebf5984dc19e62b514e759a7:
Merge branch 'u-boot-ti/master' into 'u-boot-arm/master' (2014-04-21
21:01:35 +0200)
are available in the git repository at:
git://git.denx.de/u-boot-sh.git rmobile
for you to fetch changes up to 8d18bcfd439b8422ab3bada2001cc2abd525d9f8:
arm: rmobile: lager: Remove MACH_TYPE_LAGER and CONFIG_MACH_TYPE
(2014-04-28 04:35:12 +0900)
Nobuhiro Iwamatsu (22):
arm: rmobile: Coordinate the common part of the header file of
r8a7790 and r8a7791
arm: rmobile: r8a779x: Fix L2 cache init and latency setting
arm: rmobile: koelsch: Change name of structure
arm: rmobile: koelsch: Remove NOR-Flash support
arm: rmobile: lager: Change name of the structure
arm: rmobile: lager: Remove NOR-Flash support
arm: rmobile: Merge functions to get the CPU information of
R8A7790 and R8A7791
arm: rmobile: Add 1 to value of the CPU revision in
rmobile_get_cpu_rev_integer()
arm: rmobile: Add rmobile_get_cpu_rev_fraction() for R-Car SoCs
arm: rmobile: Add prototype for function to get the CPU
information to rmobile.h
arm: rmobile: Update print_cpuinfo function
arm: rmobile: r8a7790: Add support ES2 revision
arm: rmobile: r8a7791: Add support ES2 revision
arm: rmobile: keolsch: Add support ES2 revision of R8A7791
arm: rmobile: lager: Update QoS initialization to version 0.955
arm: rmobile: koelsch: Update QoS initialization
arm: rmobile: koelsch: Update calculation of CONFIG_SH_TMU_CLK_FREQ
arm: rmobile: Add register infomation of PLL regsiter
arm: rmobile: koelsch: Change to maximum CPU frequency
arm: rmobile: lager: Update calculation of CONFIG_SH_TMU_CLK_FREQ
arm: rmobile: lager: Change to maximum CPU frequency
arm: rmobile: lager: Remove MACH_TYPE_LAGER and CONFIG_MACH_TYPE
arch/arm/cpu/armv7/rmobile/Makefile| 4 +-
arch/arm/cpu/armv7/rmobile/cpu_info-r8a7791.c | 29 -
.../{cpu_info-r8a7790.c = cpu_info-rcar.c}| 12 +-
arch/arm/cpu/armv7/rmobile/cpu_info.c | 49 +-
arch/arm/cpu/armv7/rmobile/lowlevel_init_ca15.S| 20 +-
arch/arm/include/asm/arch-rmobile/r8a7790.h| 609 +---
arch/arm/include/asm/arch-rmobile/r8a7791.h| 626 +---
arch/arm/include/asm/arch-rmobile/rcar-base.h | 637
+
arch/arm/include/asm/arch-rmobile/rmobile.h| 6 +
board/renesas/koelsch/koelsch.c| 194 +--
board/renesas/koelsch/qos.c| 404 +++--
board/renesas/lager/lager.c| 196 +--
board/renesas/lager/qos.c | 236
boards.cfg | 2 -
include/configs/koelsch.h | 36 +-
include/configs/lager.h| 40 +-
16 files changed, 1092 insertions(+), 2008 deletions(-)
delete mode 100644 arch/arm/cpu/armv7/rmobile/cpu_info-r8a7791.c
rename arch/arm/cpu/armv7/rmobile/{cpu_info-r8a7790.c = cpu_info-rcar.c}
(50%)
create mode 100644 arch/arm/include/asm/arch-rmobile/rcar-base.h
Applied to u-boot-arm/master, thanks!
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] uboot.lds
Hi, On 10 May 2014 23:51, zhaobin xv xvzhao...@gmail.com wrote: Hi, When I read the scource of uboot 1.1.6,I find . = .; in the file of \board\smdk2410\u-boot.lds. I can't understand why . = .; is here.why not . = ALIGN(4);? what does . = .; mean? It just assigns . to itself, which I think is a nop. That's quite an old U-Boot - you might be best to pick up the latest one. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] video: imx25lcdc: add board_video_init() call
Hello Thomas,
On do, 2014-05-15 at 16:34 +0200, die...@gmx.de wrote:
From: Thomas Diener die...@gmx.de
Signed-off-by: Thomas Diener die...@gmx.de
---
drivers/video/imx25lcdc.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/video/imx25lcdc.c b/drivers/video/imx25lcdc.c
index 3b45472..94ef033 100644
--- a/drivers/video/imx25lcdc.c
+++ b/drivers/video/imx25lcdc.c
@@ -23,6 +23,19 @@
#define FB_SYNC_CLK_INV (116) /* pixel clock inverted */
/*
+ * We do not enforce board code to provide empty/unused
+ * functions for this driver and define weak default
+ * functions here.
+ */
+unsigned int __board_video_init (void)
+{
+ return 0;
+}
+
+unsigned int board_video_init (void)
+ __attribute__((weak, alias(__board_video_init)));
+
Cosmetic remark. You can merge these with a single __weak.
Regards,
Jeroen
___
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.git branch tom
On Fri, May 16, 2014 at 01:02:48PM -0600, Simon Glass wrote:
Hi Tom,
I collected these three fixes for pulling.
Regards,
Simon
The following changes since commit 2072e7262965bb48d7fffb1e283101e6ed8b21a8:
mvtwsi: Remove unnecessary twsi_baud_rate and twsi_slave_address
globals (2014-05-14 12:59:12 +0200)
are available in the git repository at:
git://git.denx.de/u-boot-x86.git
for you to fetch changes up to 6be6b6bcbac62e356d05bdde488fc9f0eef7084a:
patman: Suppress duplicate signoffs only for real patches
(2014-05-16 11:42:29 -0700)
Masahiro Yamada (2):
Revert sandbox: move source files from board/ to arch/sandbox/
sandbox: set sandbox's vendor to null
Simon Glass (1):
patman: Suppress duplicate signoffs only for real patches
arch/sandbox/lib/Makefile | 2 +-
board/sandbox/Makefile| 7 +++
{doc = board/sandbox}/README.sandbox | 0
{arch/sandbox/lib = board/sandbox}/sandbox.c | 0
boards.cfg| 2 +-
tools/patman/patchstream.py | 3 ++-
6 files changed, 11 insertions(+), 3 deletions(-)
create mode 100644 board/sandbox/Makefile
rename {doc = board/sandbox}/README.sandbox (100%)
rename {arch/sandbox/lib = board/sandbox}/sandbox.c (100%)
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] PowerPC 405EX Hynix DDR DRAM Fails
We have several designs that use the AMCC 405EX processor with a 200 SO-DIMM. We use these SO-DIMMs to allow memory upgrades and because we can buy memory modules cheaper than the individual memory ICs.The 405EX is only X32 interface so, we hard-code the memory size parameters in the header file and do not use the SPD data. The designs work fine with modules built using Micron or Samsung DRAM. We specified a Crucial part number and everything was great. Then a shipment of Crucial modules arrived with the same manufacturer's part number, but populated with Hynix or SKHynix instead of the usual Micron parts. The SKHynix based modules will not even boot. The Hynix based modules will boot, but running a memory test after booting will either show byte wide fails or the processor will just lock up. Our U-Boot source was from 2011, so I tried a tarball from late 2013 with the same fails. I can find nothing wrong in the header file defining our board. The Samsung and Micron modules run without any issues. Our header file was based on the kilaeua board and I did find that it was turning on ODT for both writes and reads. The Hynix and SKHynix would fail to calibrate at that setting. When I changed to just ODT for writes as the AMCC User's Guide recommends, then the Hynix parts would calibrate. If I take the Hynix modules and put them into a Canyonlands development board, they boot up fine. Running the same mem test in the Canyonlands board that fails with Hynix on our boards and it passes fine there as well. The main difference that I can see is that the 405EX is single-ended DQS only and the 460 on the Canyonlands is differential DQS. The modules are PC2-5300 and rated at 667MHZ CL5. We are running 400MHZ data at CL4 on the 405EX. The Canyonlands board is running 400MHZ data at CL3. Was anyone seen issues with Hynix parts running single-ended DQS?The unused DQS~ nets are tied to ground with 1K ohm resistors. Any hints on what to try next? Is it possible to bump or alter the Data and DQS timings from a U-Boot prompt? This would tell me whether I am just on the edge of the windows and not centered on it. Thanks for any suggestions. - Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] armv8 relocation questions
On Fri, May 16, 2014 at 10:28:25PM +0200, Wolfgang Denk wrote: Dear Darwin, In message 53763b78.6030...@broadcom.com you wrote: 3. Fixed offset case: CONFIG_SYS_TEXT_BASE = 0x8820 You completely fail to respond to my repeated statement that a CONFIG_SYS_TEXT_BASE like this is bogus. This. What the heck is going on? CONFIG_SYS_TEXT_BASE is where the text section ends up, and the rest of the binary that follows, until we relocate. If we're being loaded by something else, it needs to be placing us at the right spot. If there's some header on top of the image to be considered by the loader, adjust where THAT loads us. If we cannot, then you must change CONFIG_SYS_TEXT_BASE around. Pad things up a bit for proper alignment. It seems where somewhere around Doctor, it hurts when I hit myself with a hammer! and can't stop hammering our poor finger. -- 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] armv8 relocation questions
On 14-05-16 01:28 PM, Wolfgang Denk wrote: Dear Darwin, In message 53763b78.6030...@broadcom.com you wrote: 3. Fixed offset case: CONFIG_SYS_TEXT_BASE = 0x8820 You completely fail to respond to my repeated statement that a CONFIG_SYS_TEXT_BASE like this is bogus. I want to set it this way to avoid carrying a downstream patch in start.S if the header is added by a post processing step. I understand that I can put a custom header inside start.S but wanted a different solution that keeps the code with less patches. I guess i give up on this. I'm sorry we couldn't converge on this. Any section in the image that requires a particular alignment must have that alignment respected after relocation. You cannot relocate to an arbitrary address if it breaks the maximum image alignment requirement after relocation. Who was it who asked why we had such unreasonable strict alignment requirements for the relocation address? The relocation address isn't unreasonably strict. I am happy with the 0x1000 alignment. What was breaking was the relocation offset which needs to have an alignment equal to or greater than the section alignments inside the image so that the symbols get relocated correctly. But if for some reason, the hardware ever required a 0x2000 (.align 13) alignment, then the generic code's 0x1000 (.align 12) relocation alignment would not work because the alignment after relocation would not respect the .align 13 directive. We just haven't run into this issue Is this a theoretical or a practical question? Where exactly do you have such a use case? This is a theoretical statement, just to try to demonstrate that the 4K page alignment is itself subject to future breakage if new hardware has alignment requirements that are greater than 4K. For example, if some new architecture had to have vectors on a 0x2000 alignment, and we put them on a 0x1000 alignment after relocation, the vector table would be corrupted. yet and may never do so, but it is important to understand the limitations of relocation relative to image alignment requirements. The current hardcoded 4096 (0x1000) image relocation alignment just happens to work and looks nice, that's all, but not by consideration of image alignment. Ummm... experience from 15 years of PPCBoot / U-Boot history don't count here, I guess? And if any text base alignment is less than the image's maximum alignment requirement, the load will fail, and then we likely scratch our heads and set the CONFIG_SYS_TEXT_BASE alignment higher until it works. CONFIG_SYS_TEXT_BASE should always be reasonable aligned. There is no good reason to add arbitrary small offsets like you do. I've explained to you a feww times before that you should include your header into the text segment, and the problem would be just gone. I agree that is a solution, but I didn't want to carry a downstream patch when the issue with relocation and alignment is understood and fixable. I thought it might be an interesting discussion, I guess we certainly got that. :) Thanks again. Best regards, Darwin But since most people just use higher alignments naturally, this issues remain mostly hidden I think. Not hidden, they don't exist. Non-random sig this time. Best regards, Wolfgang Denk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] armv8 relocation questions
On Fri, May 16, 2014 at 02:24:47PM -0700, Darwin Rambo wrote: On 14-05-16 01:28 PM, Wolfgang Denk wrote: Dear Darwin, In message 53763b78.6030...@broadcom.com you wrote: 3. Fixed offset case: CONFIG_SYS_TEXT_BASE = 0x8820 You completely fail to respond to my repeated statement that a CONFIG_SYS_TEXT_BASE like this is bogus. I want to set it this way to avoid carrying a downstream patch in start.S if the header is added by a post processing step. I understand that I can put a custom header inside start.S but wanted a different solution that keeps the code with less patches. Then you need to either pad your header out a page worth I suspect based on skimming the rest of these threads or fix what's loading your tagged u-boot to load to 0x87c0. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-mpc85xx master
Tom, The following changes since commit 557a3319089499aa0e55d65a6b43b7137f362003: Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx (2014-05-13 17:09:28 -0400) are available in the git repository at: git://git.denx.de/u-boot-mpc85xx.git master for you to fetch changes up to e4911815cf98237b65a817a3c791f143794f2837: powerpc/srio-pcie-boot: Adjust addresses for SRIO/PCIE boot (2014-05-16 16:29:16 -0500) Aneesh Bansal (1): powerpc/mpc85xx: SECURE BOOT- corrected CSPR settings for BSC9132QDS NAND Chunhe Lan (3): net: phy/vitesse: Add support for VSC8664 phy module fsl/pci: Add workaround for erratum A-005434 powerpc/85xx: Add T4160RDB board support Ebony Zhu (1): board/freescale: Move CRC32 offset in NXID v1 data format Kim Phillips (1): mpc85xx: configs: remove c=ffe from default environment Liu Gang (1): powerpc/srio-pcie-boot: Adjust addresses for SRIO/PCIE boot Nikhil Badola (1): drivers/usb : Define usb control register mask for w1c bits Prabhakar Kushwaha (1): board/p1_p2_rdb:Enable p1_p2_rdb boot from NAND/SD/SPI in SPL Shaveta Leekha (1): powerpc/mpc85xx: Added B4460 support Tang Yuantian (1): powerpc/t104xrdb: Toggle deep sleep management signals after resume ramneek mehresh (1): mpc85xx/p1020:Define number of USB controllers used on P1020RDB-PD platform arch/powerpc/cpu/mpc85xx/cmd_errata.c |3 + arch/powerpc/cpu/mpc8xxx/cpu.c |1 + arch/powerpc/include/asm/config_mpc85xx.h |3 + arch/powerpc/include/asm/processor.h |1 + board/freescale/common/sys_eeprom.c|7 +- board/freescale/p1_p2_rdb/Makefile | 21 +- board/freescale/p1_p2_rdb/ddr.c| 16 +- board/freescale/p1_p2_rdb/spl.c| 141 + board/freescale/p1_p2_rdb/spl_minimal.c| 84 board/freescale/p1_p2_rdb/tlb.c| 18 +- board/freescale/t104xrdb/t104xrdb.c|2 + boards.cfg |1 + drivers/net/phy/vitesse.c | 46 drivers/pci/fsl_pci_init.c |9 +- drivers/usb/host/ehci-fsl.c| 15 +- include/configs/B4860QDS.h | 13 +- include/configs/BSC9132QDS.h |2 +- include/configs/P1_P2_RDB.h| 265 include/configs/P2041RDB.h | 13 +- include/configs/T1040QDS.h |3 +- include/configs/T104xRDB.h |3 +- include/configs/T208xQDS.h | 13 +- include/configs/T208xRDB.h | 13 +- include/configs/T4240EMU.h |3 +- include/configs/T4240QDS.h | 13 +- include/configs/T4240RDB.h |4 + include/configs/corenet_ds.h | 13 +- include/configs/p1_p2_rdb_pc.h |4 + include/usb/ehci-fsl.h |2 + nand_spl/board/freescale/p1_p2_rdb/Makefile| 91 nand_spl/board/freescale/p1_p2_rdb/nand_boot.c | 82 31 files changed, 578 insertions(+), 327 deletions(-) create mode 100644 board/freescale/p1_p2_rdb/spl.c create mode 100644 board/freescale/p1_p2_rdb/spl_minimal.c delete mode 100644 nand_spl/board/freescale/p1_p2_rdb/Makefile delete mode 100644 nand_spl/board/freescale/p1_p2_rdb/nand_boot.c Thanks, York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] armv8 relocation questions
Hello Tom, On vr, 2014-05-16 at 17:15 -0400, Tom Rini wrote: On Fri, May 16, 2014 at 10:28:25PM +0200, Wolfgang Denk wrote: Dear Darwin, In message 53763b78.6030...@broadcom.com you wrote: 3. Fixed offset case: CONFIG_SYS_TEXT_BASE = 0x8820 You completely fail to respond to my repeated statement that a CONFIG_SYS_TEXT_BASE like this is bogus. This. What the heck is going on? CONFIG_SYS_TEXT_BASE is where the text section ends up, and the rest of the binary that follows, until we relocate. If we're being loaded by something else, it needs to be placing us at the right spot. If there's some header on top of the image to be considered by the loader, adjust where THAT loads us. If we cannot, then you must change CONFIG_SYS_TEXT_BASE around. Pad things up a bit for proper alignment. It seems where somewhere around Doctor, it hurts when I hit myself with a hammer! and can't stop hammering our poor finger. Not really I guess, I read it as Doctor, it hurts when I hit myself with a hammer! But morphine prevents it to hurt, so everybody should use morphine. But a bit more serious, as far as understood it u-boot is loaded to the CONFIG_SYS_TEXT_BASE being set, but not aligned to the requirements of adrp (which assumes 4k). Did someone find a decent description of adrp and how it should be relocated? Is adrp always required or an optimization? And yes, obviously obeying alignment requirements before and after relocating obviously helps, but I am also curious how Darwin gets away with this by adding an offset (in the wrong direction) and if this would always work (given the former is fixed). And yes, I don't know a single thing about arm64 so perhaps above sounds completely stupid... Regards, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] dfu: mmc: return data from raw partition reads
From: Stephen Warren swar...@nvidia.com
Nothing in dfu_mmc.c ever sets dfu-r_left. Consequently, reads from
MMC DFU altsettings would return 0 bytes.
Fix this by modifying dfu_read_medium_mmc() to set *len in the same way
that dfu_nand.c's dfu_read_medium_nand() does.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
Even though this mirrors how dfu_nand.c works, it feels odd to do this
every time a HW read is performed, since I believe this can happen
multiple times in a single DFU read transaction. Surely *len (and hence
dfu-r_left) should be set up once when the altsetting is initialized,
likely by calling a separate function in struct dfu_entity?
P.S. Could you please add a dfu entry into doc/git-mailrc?
---
drivers/dfu/dfu_mmc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
index 63cc876612c9..3addcef68bde 100644
--- a/drivers/dfu/dfu_mmc.c
+++ b/drivers/dfu/dfu_mmc.c
@@ -203,6 +203,7 @@ int dfu_read_medium_mmc(struct dfu_entity *dfu, u64 offset,
void *buf,
switch (dfu-layout) {
case DFU_RAW_ADDR:
+ *len = dfu-data.mmc.lba_size * dfu-data.mmc.lba_blk_size;
ret = mmc_block_op(DFU_OP_READ, dfu, offset, buf, len);
break;
case DFU_FS_FAT:
--
1.8.1.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] armv8 relocation questions
Hi Jeroen， Hello Tom, On vr, 2014-05-16 at 17:15 -0400, Tom Rini wrote: On Fri, May 16, 2014 at 10:28:25PM +0200, Wolfgang Denk wrote: Dear Darwin, In message 53763b78.6030...@broadcom.com you wrote: 3. Fixed offset case: CONFIG_SYS_TEXT_BASE = 0x8820 You completely fail to respond to my repeated statement that a CONFIG_SYS_TEXT_BASE like this is bogus. This. What the heck is going on? CONFIG_SYS_TEXT_BASE is where the text section ends up, and the rest of the binary that follows, until we relocate. If we're being loaded by something else, it needs to be placing us at the right spot. If there's some header on top of the image to be considered by the loader, adjust where THAT loads us. If we cannot, then you must change CONFIG_SYS_TEXT_BASE around. Pad things up a bit for proper alignment. It seems where somewhere around Doctor, it hurts when I hit myself with a hammer! and can't stop hammering our poor finger. Not really I guess, I read it as Doctor, it hurts when I hit myself with a hammer! But morphine prevents it to hurt, so everybody should use morphine. But a bit more serious, as far as understood it u-boot is loaded to the CONFIG_SYS_TEXT_BASE being set, but not aligned to the requirements of adrp (which assumes 4k). Did someone find a decent description of adrp and how it should be relocated? Is adrp always required or an optimization? We can not make gcc-aarch64 do not use adrp instruction when constructing address of label. So, I think the 4kb alignment would be a requirement or restriction. Gcc did not declare it explicitly due to in normal world memory are allocated with page aligned. If u-boot for aarch64 want to be compiled at address not 4kb aligned the relocated address should also be shifted with the same offset. David ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] armv8 relocation questions
hi Darwin, It's a little late. I'm hoping someone can help answer these questions about armv8 relocation. The CONFIG_SYS_TEXT_BASE seems to be be usually setup to a decent amount of alignment. For the purposes of this discussion, let's say it would normally be 0x8800 and all is well. The relocation address moves to near the end of memory, to say, 0xfffa8000. So far so good. Now let's say I want to shift the image a bit so that I can add a small 32-byte header required by a previous bootloader. So I set CONFIG_SYS_TEXT_BASE to 0x8820, and the relocated address is still 0xfffa8000 and the relocated vectors should be at 0xfffa9000. The image crashes so after some debugging, I find that the code appears to be relocated fine, but some sections have symbols that are not relocated properly. The vectors try to relocate to 0xfffa8fe0 and rodata.str1.1 printf format strings are also 0x20 off. There are likely other offset sections with issues as well. The relocation offset is 0x77fa7fe0 due to the calculations in arch/arm/lib/board.c. Simplifying, they look like this: addr = CONFIG_SYS_SDRAM_BASE + gd-ram_size; /* round down to next 4 kB limit */ addr = ~(4096 - 1); debug(Top of RAM usable for U-Boot at: %08lx\n, addr); /* * reserve memory for U-Boot code, data bss * round down to next 4 kB limit */ addr -= gd-mon_len; addr = ~(4096 - 1); addr += 0x20; // hack to adjust relocaddr to aligned address... snip gd-relocaddr = addr; gd-start_addr_sp = addr_sp; gd-reloc_off = addr - _TEXT_BASE; debug(relocation Offset is: %08lx\n, gd-reloc_off); Since _TEXT_BASE is 0x8820 and addr is 0xfffa8000, the reloc_off is a number like 0x77fa7fe0. Now if I add 0x20 to 'addr' above just before the snip, relocaddr becomes 0x77fa8000 and the relocation works perfectly and no more crashes happen. So my question - is the CONFIG_SYS_TEXT_BASE alignment requirement related to to any assumptions in the linker itself about image base alignment, specifically referring to creation of the rela.dyn sections and their use for image relocation? A related question is if CONFIG_SYS_TEXT_BASE needs to be at a specific alignment. The maximum alignment in the armv8 code base is .align 11 which I believe means 0x800 or 2048. Note that an armv7 target appears to relocate properly with smaller offsets such as 0x20. Thanks. I traced the problem you described and found it is caused by 'adrp' instruction. 'adrp' instruction produces 4kb aligned address of a label. So, if CONFIG_SYS_TEXT_BASE is not 4kb aligned the address produced by 'adrp' and following 'add' instruction will be incorrect. For example, if CONFIG_SYS_TEXT_BASE = 0x20 then address of '_start' is 0x20 and address of '_end_ofs' is 0x30, where u-boot access variable '_end_ofs' gcc generate code as following: adrp x0, ... add x0, x0, 0x30 We noticed that 0x30 is added to 'x0' to produce the address of '_end_ofs'. So when CONFIG_SYS_TEXT_BASE=0x20 and relocated destination address is not 0x020 register x0 contain incorrect address of '_end_ofs'. David. Another point, if the relocated address is not shifted with the same offset with CONFIG_SYS_TEXT_BASE all the alignment in u-boot maybe lost, for example the interrupt vector table. So, this issue is not only related with aarch64. David ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
