Re: [U-Boot] [PATCH v2 0/3] Add generic early debug UART feature
+tom, and pruning the cc list a little Hi, On 26 January 2015 at 18:27, Simon Glass s...@chromium.org wrote: This series adds debug UART infrastructure which can in principle be used on any architecture. It works best with those that don't need a stack to call functions (e.g. ARM, PowerPC). I'd really quite like to apply this series. I have used it on PowerPC and x86 and found it quite useful. Any objections? - Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: minnowmax: add GPIO mapping support
Hi Gabriel,
On 15 February 2015 at 14:55, Gabriel Huau cont...@huau-gabriel.fr wrote:
Configure the pinctrl as it required to make some IO controllers
working (USB/UART/I2C/...).
The idea would be in the next version to modify the pch GPIO driver and
configure these pins through the device tree.
These modifications are ported from the coreboot project.
Signed-off-by: Gabriel Huau cont...@huau-gabriel.fr
Thanks for the patch!
I have mostly nits except for one comment about register access which
is different in U-Boot...
---
arch/x86/cpu/baytrail/Makefile| 1 +
arch/x86/cpu/baytrail/gpio.c | 206 +++
arch/x86/include/asm/arch-baytrail/gpio.h | 364
++
arch/x86/include/asm/arch-baytrail/iomap.h| 73 ++
arch/x86/include/asm/arch-baytrail/irq.h | 119 +
arch/x86/include/asm/arch-baytrail/irqroute.h | 67 +
arch/x86/include/asm/arch-baytrail/pci_devs.h | 144 ++
arch/x86/include/asm/arch-baytrail/pmc.h | 253 ++
board/intel/minnowmax/minnowmax.c | 212 +++
include/configs/minnowmax.h | 11 +
10 files changed, 1450 insertions(+)
create mode 100644 arch/x86/cpu/baytrail/gpio.c
create mode 100644 arch/x86/include/asm/arch-baytrail/iomap.h
create mode 100644 arch/x86/include/asm/arch-baytrail/irq.h
create mode 100644 arch/x86/include/asm/arch-baytrail/irqroute.h
create mode 100644 arch/x86/include/asm/arch-baytrail/pci_devs.h
create mode 100644 arch/x86/include/asm/arch-baytrail/pmc.h
diff --git a/arch/x86/cpu/baytrail/Makefile b/arch/x86/cpu/baytrail/Makefile
index 8914e8b..c20a616 100644
--- a/arch/x86/cpu/baytrail/Makefile
+++ b/arch/x86/cpu/baytrail/Makefile
@@ -8,3 +8,4 @@ obj-y += early_uart.o
obj-y += fsp_configs.o
obj-y += pci.o
obj-y += valleyview.o
+obj-y += gpio.o
Please keep in alphabetical order.
diff --git a/arch/x86/cpu/baytrail/gpio.c b/arch/x86/cpu/baytrail/gpio.c
new file mode 100644
index 000..0ad41cc
--- /dev/null
+++ b/arch/x86/cpu/baytrail/gpio.c
@@ -0,0 +1,206 @@
+/*
+ * Copyright (c) 2012 The Chromium OS Authors.
Please add 'From coreboot filename' here so people know where it came from.
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include dm.h
+#include errno.h
+#include fdtdec.h
+#include pci.h
+#include asm/arch/gpio.h
+#include asm/arch/irqroute.h
+#include asm/arch/pmc.h
+#include asm/gpio.h
+#include asm/io.h
+#include asm/pci.h
+
+/* GPIO-to-Pad LUTs */
+static const u8 gpncore_gpio_to_pad[GPNCORE_COUNT] = {
+ 19, 18, 17, 20, 21, 22, 24, 25, /* [ 0: 7] */
+ 23, 16, 14, 15, 12, 26, 27, 1, /* [ 8:15] */
+ 4, 8, 11, 0, 3, 6, 10, 13, /* [16:23] */
+ 2, 5, 9 /* [24:26] */
+};
+
+static const u8 gpscore_gpio_to_pad[GPSCORE_COUNT] = {
+ 85, 89, 93, 96, 99, 102, 98, 101, /* [ 0: 7] */
+ 34, 37, 36, 38, 39, 35, 40, 84, /* [ 8: 15] */
+ 62, 61, 64, 59, 54, 56, 60, 55, /* [16: 23] */
+ 63, 57, 51, 50, 53, 47, 52, 49, /* [24: 31] */
+ 48, 43, 46, 41, 45, 42, 58, 44, /* [32: 39] */
+ 95, 105, 70, 68, 67, 66, 69, 71, /* [40: 47] */
+ 65, 72, 86, 90, 88, 92, 103, 77, /* [48: 55] */
+ 79, 83, 78, 81, 80, 82, 13, 12, /* [56: 63] */
+ 15, 14, 17, 18, 19, 16, 2, 1, /* [64: 71] */
+ 0, 4, 6, 7, 9, 8, 33, 32, /* [72: 79] */
+ 31, 30, 29, 27, 25, 28, 26, 23, /* [80: 87] */
+ 21, 20, 24, 22, 5, 3, 10, 11, /* [88: 95] */
+ 106, 87, 91, 104, 97, 100 /* [96:101] */
+};
+
+static const u8 gpssus_gpio_to_pad[GPSSUS_COUNT] = {
+ 29, 33, 30, 31, 32, 34, 36, 35, /* [ 0: 7] */
+ 38, 37, 18, 7, 11, 20, 17, 1, /* [ 8:15] */
+ 8, 10, 19, 12, 0, 2, 23, 39, /* [16:23] */
+ 28, 27, 22, 21, 24, 25, 26, 51, /* [24:31] */
+ 56, 54, 49, 55, 48, 57, 50, 58, /* [32:39] */
+ 52, 53, 59, 40 /* [40:43] */
+};
The above three tables are not quite lined up, but it looks like that
was your intention.
+
+/* GPIO bank descriptions */
+static const struct gpio_bank gpncore_bank = {
+ .gpio_count = GPNCORE_COUNT,
+ .gpio_to_pad = gpncore_gpio_to_pad,
+ .legacy_base = GP_LEGACY_BASE_NONE,
+ .pad_base = GPNCORE_PAD_BASE,
+ .has_wake_en = 0,
+ .gpio_f1_range_start = GPNCORE_GPIO_F1_RANGE_START,
+ .gpio_f1_range_end = GPNCORE_GPIO_F1_RANGE_END,
+};
+
+static const struct gpio_bank gpscore_bank = {
+ .gpio_count = GPSCORE_COUNT,
+ .gpio_to_pad = gpscore_gpio_to_pad,
+ .legacy_base = GPSCORE_LEGACY_BASE,
+ .pad_base = GPSCORE_PAD_BASE,
+ .has_wake_en = 0,
+ .gpio_f1_range_start = GPSCORE_GPIO_F1_RANGE_START,
+ .gpio_f1_range_end =
[U-Boot] unassigned-patches/131: Re: [PATCH] x86: minnowmax: add GPIO mapping support
Hi Gabriel,
On 15 February 2015 at 14:55, Gabriel Huau cont...@huau-gabriel.fr wrote:
Configure the pinctrl as it required to make some IO controllers
working (USB/UART/I2C/...).
The idea would be in the next version to modify the pch GPIO driver and
configure these pins through the device tree.
These modifications are ported from the coreboot project.
Signed-off-by: Gabriel Huau cont...@huau-gabriel.fr
Thanks for the patch!
I have mostly nits except for one comment about register access which
is different in U-Boot...
---
arch/x86/cpu/baytrail/Makefile| 1 +
arch/x86/cpu/baytrail/gpio.c | 206 +++
arch/x86/include/asm/arch-baytrail/gpio.h | 364
++
arch/x86/include/asm/arch-baytrail/iomap.h| 73 ++
arch/x86/include/asm/arch-baytrail/irq.h | 119 +
arch/x86/include/asm/arch-baytrail/irqroute.h | 67 +
arch/x86/include/asm/arch-baytrail/pci_devs.h | 144 ++
arch/x86/include/asm/arch-baytrail/pmc.h | 253 ++
board/intel/minnowmax/minnowmax.c | 212 +++
include/configs/minnowmax.h | 11 +
10 files changed, 1450 insertions(+)
create mode 100644 arch/x86/cpu/baytrail/gpio.c
create mode 100644 arch/x86/include/asm/arch-baytrail/iomap.h
create mode 100644 arch/x86/include/asm/arch-baytrail/irq.h
create mode 100644 arch/x86/include/asm/arch-baytrail/irqroute.h
create mode 100644 arch/x86/include/asm/arch-baytrail/pci_devs.h
create mode 100644 arch/x86/include/asm/arch-baytrail/pmc.h
diff --git a/arch/x86/cpu/baytrail/Makefile b/arch/x86/cpu/baytrail/Makefile
index 8914e8b..c20a616 100644
--- a/arch/x86/cpu/baytrail/Makefile
+++ b/arch/x86/cpu/baytrail/Makefile
@@ -8,3 +8,4 @@ obj-y += early_uart.o
obj-y += fsp_configs.o
obj-y += pci.o
obj-y += valleyview.o
+obj-y += gpio.o
Please keep in alphabetical order.
diff --git a/arch/x86/cpu/baytrail/gpio.c b/arch/x86/cpu/baytrail/gpio.c
new file mode 100644
index 000..0ad41cc
--- /dev/null
+++ b/arch/x86/cpu/baytrail/gpio.c
@@ -0,0 +1,206 @@
+/*
+ * Copyright (c) 2012 The Chromium OS Authors.
Please add 'From coreboot filename' here so people know where it came from.
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include dm.h
+#include errno.h
+#include fdtdec.h
+#include pci.h
+#include asm/arch/gpio.h
+#include asm/arch/irqroute.h
+#include asm/arch/pmc.h
+#include asm/gpio.h
+#include asm/io.h
+#include asm/pci.h
+
+/* GPIO-to-Pad LUTs */
+static const u8 gpncore_gpio_to_pad[GPNCORE_COUNT] = {
+ 19, 18, 17, 20, 21, 22, 24, 25, /* [ 0: 7] */
+ 23, 16, 14, 15, 12, 26, 27, 1, /* [ 8:15] */
+ 4, 8, 11, 0, 3, 6, 10, 13, /* [16:23] */
+ 2, 5, 9 /* [24:26] */
+};
+
+static const u8 gpscore_gpio_to_pad[GPSCORE_COUNT] = {
+ 85, 89, 93, 96, 99, 102, 98, 101, /* [ 0: 7] */
+ 34, 37, 36, 38, 39, 35, 40, 84, /* [ 8: 15] */
+ 62, 61, 64, 59, 54, 56, 60, 55, /* [16: 23] */
+ 63, 57, 51, 50, 53, 47, 52, 49, /* [24: 31] */
+ 48, 43, 46, 41, 45, 42, 58, 44, /* [32: 39] */
+ 95, 105, 70, 68, 67, 66, 69, 71, /* [40: 47] */
+ 65, 72, 86, 90, 88, 92, 103, 77, /* [48: 55] */
+ 79, 83, 78, 81, 80, 82, 13, 12, /* [56: 63] */
+ 15, 14, 17, 18, 19, 16, 2, 1, /* [64: 71] */
+ 0, 4, 6, 7, 9, 8, 33, 32, /* [72: 79] */
+ 31, 30, 29, 27, 25, 28, 26, 23, /* [80: 87] */
+ 21, 20, 24, 22, 5, 3, 10, 11, /* [88: 95] */
+ 106, 87, 91, 104, 97, 100 /* [96:101] */
+};
+
+static const u8 gpssus_gpio_to_pad[GPSSUS_COUNT] = {
+ 29, 33, 30, 31, 32, 34, 36, 35, /* [ 0: 7] */
+ 38, 37, 18, 7, 11, 20, 17, 1, /* [ 8:15] */
+ 8, 10, 19, 12, 0, 2, 23, 39, /* [16:23] */
+ 28, 27, 22, 21, 24, 25, 26, 51, /* [24:31] */
+ 56, 54, 49, 55, 48, 57, 50, 58, /* [32:39] */
+ 52, 53, 59, 40 /* [40:43] */
+};
The above three tables are not quite lined up, but it looks like that
was your intention.
+
+/* GPIO bank descriptions */
+static const struct gpio_bank gpncore_bank = {
+ .gpio_count = GPNCORE_COUNT,
+ .gpio_to_pad = gpncore_gpio_to_pad,
+ .legacy_base = GP_LEGACY_BASE_NONE,
+ .pad_base = GPNCORE_PAD_BASE,
+ .has_wake_en = 0,
+ .gpio_f1_range_start = GPNCORE_GPIO_F1_RANGE_START,
+ .gpio_f1_range_end = GPNCORE_GPIO_F1_RANGE_END,
+};
+
+static const struct gpio_bank gpscore_bank = {
+ .gpio_count = GPSCORE_COUNT,
+ .gpio_to_pad = gpscore_gpio_to_pad,
+ .legacy_base = GPSCORE_LEGACY_BASE,
+ .pad_base = GPSCORE_PAD_BASE,
+ .has_wake_en = 0,
+ .gpio_f1_range_start = GPSCORE_GPIO_F1_RANGE_START,
+ .gpio_f1_range_end =
Re: [U-Boot] [U-boot][PATCH] keystone2: add support for UART download
On Tue, Feb 17, 2015 at 4:27 PM, Murali Karicheri m-kariche...@ti.com wrote: is complete the boot-loader sets the PC to the first MSMC address 0x0c00. The u-boot.bin is linked to the address 0x0c001000. why not just shift u-boot.bin to start of MSMC address? What is wrong with the current implementation? NAND and SPI NOR boot modes use the GPH headers that has the load address defined. But in the case of UART, RBL So it GPH header has the load address defined, it does mean that we could infact change the start address to 0xc00 (instead of current 0xc001000) and appropriately update the GPH headers to point there? that way we can use 0xc00 without padding on UART, as well as use the same in NAND/SPI as well? correct? loads it to start of MSMC and adding 1K of NOP just avoid a jump instruction at the start of the memory to jump to 0xc001000. This way we can keep the same start address across all boot modes. Padding a 4kbytes (1K NOP at 32bits each) just because there is a difference between linked address and start address in a specific mode makes one wonder. This probably is not definitely a uniquely KS2 issue - we probably have similar behavior on other platforms as well. what if we chose a link address 2MB away (as an example)? agreed that the specific usage has no such size story in place, but conceptually we might be able to do better. In order to use the u-boot.bin as an image for UART download, we need to add 4K zeros prefix that act as 1K NOP instructions before reaching 0xc001000. OR, add a relocation logic which saves the 1k NOP and resultant load time? What saving are you talking about? Miliseconds? seconds? Maintainability? lets say we change link address tomorrow, we have to adjust padding appropriately, further we just dont need padding when we can just relocate self by being position independent in the first place!. we have learnt that over years OMAP3 link address has gone through a few transitions as we discovered better ways to do things. doing padding based on link address does, on the first look, seem unnecessary, makes sense only if all of the following are wrong: a) cannot change start address to the common start address for all boot modes. b) cannot add relocation and position independent u-boot code. And even when we do need to add padding, it is not a good idea to hard code the pad size, instead do it algorithmically (basically query the start and add the delta) allowing changes to link address to be something folks can do at a later point in time without unintentionally breaking uart boot. --- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Documentation: gpio: fix bindings document
On 12 February 2015 at 02:49, Masahiro Yamada yamad...@jp.panasonic.com wrote: [ imported from Linux Kernel, commit 74981fb81d83 ] Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Signed-off-by: Linus Walleij linus.wall...@linaro.org Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] ARM / OMAP5: Add workaround for ARM errata 798870
From: Praveen Rao p...@ti.com
This patch adds workaround for ARM errata 798870 which says
If back-to-back speculative cache line fills (fill A and fill B) are
issued from the L1 data cache of a CPU to the L2 cache, the second
request (fill B) is then cancelled, and the second request would have
detected a hazard against a recent write or eviction (write B) to the
same cache line as fill B then the L2 logic might deadlock.
Note: Every SoC has slightly different manner of setting up access
to L2ACLR and similar registers since the Secure Monitor handling
of Secure Monitor Call(smc) is diverse. Hence an ARCH specific
macro is introduced to implement SoC specific errata workaround
implementations.
An intial implementation for OMAP5 and DRA7 is introduced here as well.
Obviously, implementations for other SoC families such as Exynos etc
will be widely different.
Signed-off-by: Praveen Rao p...@ti.com
Signed-off-by: Angela Stegmaier angelaba...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/cpu/armv7/omap5/lowlevel_init.S | 35 ++
1 file changed, 35 insertions(+)
create mode 100644 arch/arm/cpu/armv7/omap5/lowlevel_init.S
diff --git a/arch/arm/cpu/armv7/omap5/lowlevel_init.S
b/arch/arm/cpu/armv7/omap5/lowlevel_init.S
new file mode 100644
index ..1cc3c7af5fe2
--- /dev/null
+++ b/arch/arm/cpu/armv7/omap5/lowlevel_init.S
@@ -0,0 +1,35 @@
+/*
+ * Board specific misc setup
+ *
+ * (C) Copyright 2015
+ * Texas Instruments, www.ti.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include config.h
+#include asm/arch/omap.h
+#include asm/omap_common.h
+#include asm/arch/spl.h
+#include linux/linkage.h
+
+#ifdef CONFIG_ARM_ARCH_CP15_ERRATA
+ .globl arch_cp15_errata_workaround
+ENTRY(arch_cp15_errata_workaround)
+ push{r4-r11, lr}@ save registers - ROM code may pollute
+
+#ifdef CONFIG_ARM_ERRATA_798870
+ mrc p15, 0, r0, c0, c0, 0 @ Read Main ID Register (MIDR)
+ and r0, r0, #0x00f0 @ check rev
+ cmp r0, #0x00f0 @ compare rev
+ bne skip_errata_798870 @ skip if not affected rev
+ mrc p15, 1, r1, c15, c0, 0 @ read l2 aux ctrl reg
+ orr r1, r1, #1 7 @ set bit #7
+ ldr r0, =OMAP5_SERVICE_L2ACTLR_SET@ Set L2 Cache Auxiliary
control register - value in R0
+ b omap_smc1
+skip_errata_798870:
+#endif
+ pop {r4-r11, pc}
+ENDPROC(arch_cp15_errata_workaround)
+
+#endif
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/4] ARM / OMAP5 / DRA7 : Enable proper l2actl configuration
Hi, Triggered by a user report, it was seen that recommended errata workaround and performance trade-offs as recommended by TI architects for ARM configuration was not being followed in OMAP5+ ARM A15 platforms in u-boot configuration. Note OMAP5, DRA7 all share the same cortex A15 revision (ID=0x412fc0f2) and the workarounds and improvement configurations apply equally. Certain errata workaround done in this series obviously have the controversy potential considering that each of the SoCs implement workaround based on secure monitor calls, but both the service requested and the parameters of secure monitor calls can be widely variant. Examples: OMAP family of processors have quite the family of SMC calls: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-omap2/omap-smc.S meanwhile Exynos has a much simpler invocation: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-exynos/exynos-smc.S To maintain some resemblance of symmetry the following series introduces a arch/machine dependent errata macro which must be enabled prior to any of such workarounds can be implemented. I am open to better ways of doing this which might benefit others in ARM community with similar needs. Lets discuss. These patches are based on: v2015.04-rc1 but also apply on latest master. Testing: AM5728 based Beagleboard-X15: http://pastebin.ubuntu.com/10280020/ DRA722 based Evm: http://pastebin.ubuntu.com/10280074/ DRA742 based Evm: http://pastebin.ubuntu.com/10280115/ OMAP5432 uEVM: http://pastebin.ubuntu.com/10280176/ OMAP4460 PandaBoard-ES: http://pastebin.ubuntu.com/10280208/ (just sanity) Appropriate CP15 configuration was cross verified by Lauterbach or by a custom kernel patch (http://paste.ubuntu.org.cn/2410711). Angela Stegmaier (1): configs: ti_omap5_common: Enable workaround for ARM errata 798870 Nishanth Menon (2): ARM: OMAP: Change set_pl310_ctrl_reg to be generic ARM: OMAP5 / DRA7: Setup L2 Aux Control Register with recommended configuration Praveen Rao (1): ARM / OMAP5: Add workaround for ARM errata 798870 arch/arm/cpu/armv7/omap-common/lowlevel_init.S |8 -- arch/arm/cpu/armv7/omap4/hwinit.c |4 +-- arch/arm/cpu/armv7/omap5/hwinit.c | 16 +++ arch/arm/cpu/armv7/omap5/lowlevel_init.S | 35 arch/arm/include/asm/arch-omap4/sys_proto.h|5 +++- arch/arm/include/asm/arch-omap5/sys_proto.h|4 +++ include/configs/ti_omap5_common.h |4 +++ 7 files changed, 70 insertions(+), 6 deletions(-) create mode 100644 arch/arm/cpu/armv7/omap5/lowlevel_init.S -- 1.7.9.5 Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] ARM: OMAP: Change set_pl310_ctrl_reg to be generic
set_pl310_ctrl_reg does use the Secure Monitor Call (SMC) to setup
PL310 control register, however, that is something that is generic
enough to be used for OMAP5 generation of processors as well. The
only difference being the service being invoked for the function.
So, convert the service to a macro and use a generic name (same as
that used in Linux for some consistency). While at that, also add
a data barrier which is necessary as per recommendation.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/cpu/armv7/omap-common/lowlevel_init.S |8 +---
arch/arm/cpu/armv7/omap4/hwinit.c |4 ++--
arch/arm/include/asm/arch-omap4/sys_proto.h|5 -
3 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
index 86c0e4217478..cc3603d798e9 100644
--- a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
@@ -22,11 +22,13 @@ ENTRY(save_boot_params)
bx lr
ENDPROC(save_boot_params)
-ENTRY(set_pl310_ctrl_reg)
+ENTRY(omap_smc1)
PUSH{r4-r11, lr}@ save registers - ROM code may pollute
@ our registers
- LDR r12, =0x102 @ Set PL310 control register - value in R0
+ MOV r12, r0 @ Service
+ MOV r0, r1 @ Argument
+ DSB
.word 0xe1600070 @ SMC #0 - hand assembled because -march=armv5
@ call ROM Code API to set control register
POP {r4-r11, pc}
-ENDPROC(set_pl310_ctrl_reg)
+ENDPROC(omap_smc1)
diff --git a/arch/arm/cpu/armv7/omap4/hwinit.c
b/arch/arm/cpu/armv7/omap4/hwinit.c
index db16548fac49..9792761d40a0 100644
--- a/arch/arm/cpu/armv7/omap4/hwinit.c
+++ b/arch/arm/cpu/armv7/omap4/hwinit.c
@@ -159,11 +159,11 @@ void init_omap_revision(void)
#ifndef CONFIG_SYS_L2CACHE_OFF
void v7_outer_cache_enable(void)
{
- set_pl310_ctrl_reg(1);
+ omap_smc1(OMAP4_SERVICE_PL310_CONTROL_REG_SET, 1);
}
void v7_outer_cache_disable(void)
{
- set_pl310_ctrl_reg(0);
+ omap_smc1(OMAP4_SERVICE_PL310_CONTROL_REG_SET, 0);
}
#endif /* !CONFIG_SYS_L2CACHE_OFF */
diff --git a/arch/arm/include/asm/arch-omap4/sys_proto.h
b/arch/arm/include/asm/arch-omap4/sys_proto.h
index e19975efaf50..f425e3af54f5 100644
--- a/arch/arm/include/asm/arch-omap4/sys_proto.h
+++ b/arch/arm/include/asm/arch-omap4/sys_proto.h
@@ -37,7 +37,7 @@ void do_set_mux(u32 base, struct pad_conf_entry const *array,
int size);
void set_muxconf_regs_essential(void);
u32 wait_on_value(u32, u32, void *, u32);
void sdelay(unsigned long);
-void set_pl310_ctrl_reg(u32 val);
+void omap_smc1(u32 service, u32 val);
void setup_clocks_for_console(void);
void prcm_init(void);
void bypass_dpll(u32 const base);
@@ -57,4 +57,7 @@ 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);
+
+#define OMAP4_SERVICE_PL310_CONTROL_REG_SET0x102
+
#endif
--
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/4] ARM: OMAP5 / DRA7: Setup L2 Aux Control Register with recommended configuration
Update to existing recommendation for L2ACTLR configuration to prevent
system instability and optimize performance.
These apply to both OMAP5 and DRA7.
Reported-by: Vivek Chengalvala vchengalv...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/cpu/armv7/omap5/hwinit.c | 16
arch/arm/include/asm/arch-omap5/sys_proto.h |4
2 files changed, 20 insertions(+)
diff --git a/arch/arm/cpu/armv7/omap5/hwinit.c
b/arch/arm/cpu/armv7/omap5/hwinit.c
index a8a474a88be9..632df4f0bfae 100644
--- a/arch/arm/cpu/armv7/omap5/hwinit.c
+++ b/arch/arm/cpu/armv7/omap5/hwinit.c
@@ -304,6 +304,21 @@ void config_data_eye_leveling_samples(u32 emif_base)
(*ctrl)-control_emif2_sdram_config_ext);
}
+void init_cpu_configuration(void)
+{
+ u32 l2actlr;
+
+ asm volatile(mrc p15, 1, %0, c15, c0, 0 : =r(l2actlr));
+ /*
+* L2ACTLR: Ensure to enable the following:
+* 3: Disable clean/evict push to external
+* 4: Disable WriteUnique and WriteLineUnique transactions from master
+* 8: Disable DVM/CMO message broadcast
+*/
+ l2actlr |= 0x118;
+ omap_smc1(OMAP5_SERVICE_L2ACTLR_SET, l2actlr);
+}
+
void init_omap_revision(void)
{
/*
@@ -342,6 +357,7 @@ void init_omap_revision(void)
default:
*omap_si_rev = OMAP5430_SILICON_ID_INVALID;
}
+ init_cpu_configuration();
}
void reset_cpu(ulong ignored)
diff --git a/arch/arm/include/asm/arch-omap5/sys_proto.h
b/arch/arm/include/asm/arch-omap5/sys_proto.h
index 103830319a41..e2e186859373 100644
--- a/arch/arm/include/asm/arch-omap5/sys_proto.h
+++ b/arch/arm/include/asm/arch-omap5/sys_proto.h
@@ -56,6 +56,7 @@ void force_emif_self_refresh(void);
void get_ioregs(const struct ctrl_ioregs **regs);
void srcomp_enable(void);
void setup_warmreset_time(void);
+void omap_smc1(u32 service, u32 val);
static inline u32 div_round_up(u32 num, u32 den)
{
@@ -66,4 +67,7 @@ static inline u32 usec_to_32k(u32 usec)
{
return div_round_up(32768 * usec, 100);
}
+
+#define OMAP5_SERVICE_L2ACTLR_SET0x104
+
#endif
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-socfpga/master
On Tue, Feb 17, 2015 at 09:11:01PM +0100, Marek Vasut wrote:
Hi Tom,
SoCFPGA stuff for current release.
The following changes since commit 7f641d53bbb3a426a3bfb132d8346153e86a9d08:
Merge branch 'master' of git://git.denx.de/u-boot-ubi (2015-02-04 13:30:00
-0500)
are available in the git repository at:
git://git.denx.de/u-boot-socfpga.git HEAD
for you to fetch changes up to 6da3e0c1758f7316025e342ef0801efba9bd7f23:
dt: socfpga: Import and enable Arria V DK DTS (2015-02-09 20:10:22 +0100)
I see:
$ ./tools/buildman/buildman -ve socfpga_arria5
boards.cfg is up to date. Nothing to do.
Building current source for 1 boards (1 thread, 6 jobs per thread)
arm: + socfpga_arria5
+ priv-qspi_calibrated_cs = spi_chip_select(bus);
+ ^
+drivers/spi/cadence_qspi.c: At top level:
+drivers/spi/cadence_qspi.c:320:21: error: variable 'cadence_spi_ops' has
initializer but incomplete type
+ static const struct dm_spi_ops cadence_spi_ops = {
+ ^
+drivers/spi/cadence_qspi.c:321:2: error: unknown field 'xfer' specified in
initializer
+ .xfer = cadence_spi_xfer,
+drivers/spi/cadence_qspi.c:322:2: error: unknown field 'set_speed' specified
in initializer
+ .set_speed = cadence_spi_set_speed,
+drivers/spi/cadence_qspi.c:323:2: error: unknown field 'set_mode' specified in
initializer
+ .set_mode = cadence_spi_set_mode,
+make[2]: *** [drivers/spi/cadence_qspi.o] Error 1
+make[1]: *** [drivers/spi] Error 2
+make: *** [sub-make] Error 2
w+drivers/spi/cadence_qspi.c: In function 'spi_calibration':
w+drivers/spi/cadence_qspi.c:115:2: warning: implicit declaration of function
'spi_chip_select' [-Wimplicit-function-declaration]
w+drivers/spi/cadence_qspi.c:321:2: warning: excess elements in struct
initializer [enabled by default]
w+drivers/spi/cadence_qspi.c:321:2: warning: (near initialization for
'cadence_spi_ops') [enabled by default]
w+drivers/spi/cadence_qspi.c:322:2: warning: excess elements in struct
initializer [enabled by default]
w+drivers/spi/cadence_qspi.c:322:2: warning: (near initialization for
'cadence_spi_ops') [enabled by default]
w+drivers/spi/cadence_qspi.c:323:2: warning: excess elements in struct
initializer [enabled by default]
w+drivers/spi/cadence_qspi.c:323:2: warning: (near initialization for
'cadence_spi_ops') [enabled by default]
001 /1 socfpga_arria5
$
--
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] [PULL v2] u-boot-avr32/master - u-boot/master
Hi Tom, reworked pull request for avr32 generic board support. The following changes since commit 5745f8c4fd5807becf7f246625e153388293aedc: Merge git://git.denx.de/u-boot-marvell (2015-02-16 08:44:03 -0500) are available in the git repository at: git://git.denx.de/u-boot-avr32.git master for you to fetch changes up to 5c98d7ffb0b11c9e3909f56ec5ce9dff682f1e30: atstk1002: enable generic board (2015-02-17 22:54:41 +0100) Andreas Bießmann (11): avr32: use dlmalloc for DMA buffers avr32: rename cpu_init() - arch_cpu_init() avr32: factor out cpu_mmc_init() avr32: rename mmu.h definitions avr32: convert to dram_init() avr32: use generic gd-start_addr_sp common/board_f: factor out reserve_stacks common/board_r: allocate bootparams avr32: add generic board support grasshopper: enable generic board atstk1002: enable generic board arch/arm/lib/Makefile|1 + arch/arm/lib/stack.c | 42 + arch/avr32/config.mk |3 + arch/avr32/cpu/Makefile |1 + arch/avr32/cpu/at32ap700x/mmu.c |8 +-- arch/avr32/cpu/cpu.c |2 +- arch/avr32/cpu/exception.c |6 +- arch/avr32/cpu/mmc.c | 16 + arch/avr32/cpu/u-boot.lds|2 + arch/avr32/include/asm/arch-at32ap700x/mmu.h |6 +- arch/avr32/include/asm/config.h |1 + arch/avr32/include/asm/dma-mapping.h |7 ++- arch/avr32/include/asm/global_data.h |1 - arch/avr32/include/asm/u-boot.h | 10 arch/avr32/lib/Makefile |3 + arch/avr32/lib/board.c | 83 -- arch/avr32/lib/dram_init.c | 17 ++ arch/avr32/lib/interrupts.c |5 ++ arch/powerpc/lib/Makefile|1 + arch/powerpc/lib/stack.c | 31 ++ board/atmel/atngw100/atngw100.c | 32 +++--- board/atmel/atngw100mkii/atngw100mkii.c | 39 board/atmel/atstk1000/atstk1000.c| 33 +++--- board/earthlcd/favr-32-ezkit/favr-32-ezkit.c | 33 +++--- board/in-circuit/grasshopper/grasshopper.c | 32 +++--- board/mimc/mimc200/mimc200.c | 38 board/miromico/hammerhead/hammerhead.c | 32 +++--- common/board_f.c | 46 -- common/board_r.c | 28 - common/cmd_bdinfo.c |4 +- include/asm-generic/u-boot.h |4 ++ include/common.h | 18 ++ include/configs/atngw100.h |1 - include/configs/atngw100mkii.h |1 - include/configs/atstk1002.h |5 +- include/configs/atstk1006.h |1 - include/configs/favr-32-ezkit.h |1 - include/configs/grasshopper.h|5 +- include/configs/hammerhead.h |1 - include/configs/mimc200.h|1 - 40 files changed, 294 insertions(+), 307 deletions(-) create mode 100644 arch/arm/lib/stack.c create mode 100644 arch/avr32/cpu/mmc.c create mode 100644 arch/avr32/lib/dram_init.c create mode 100644 arch/powerpc/lib/stack.c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 10/20] tegra: clock: Support enabling external clocks
Add a simple function to enable external clocks.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/arm/cpu/tegra-common/clock.c | 17 +
arch/arm/include/asm/arch-tegra/clock.h | 8
2 files changed, 25 insertions(+)
diff --git a/arch/arm/cpu/tegra-common/clock.c
b/arch/arm/cpu/tegra-common/clock.c
index 0d36b02..5d53444 100644
--- a/arch/arm/cpu/tegra-common/clock.c
+++ b/arch/arm/cpu/tegra-common/clock.c
@@ -17,10 +17,12 @@
/* Tegra SoC common clock control functions */
#include common.h
+#include errno.h
#include asm/io.h
#include asm/arch/clock.h
#include asm/arch/tegra.h
#include asm/arch-tegra/clk_rst.h
+#include asm/arch-tegra/pmc.h
#include asm/arch-tegra/timer.h
#include div64.h
#include fdtdec.h
@@ -698,3 +700,18 @@ void tegra30_set_up_pllp(void)
set_avp_clock_source(SCLK_SOURCE_PLLP_OUT4);
}
+
+int clock_external_output(int clk_id)
+{
+ struct pmc_ctlr *pmc = (struct pmc_ctlr *)NV_PA_PMC_BASE;
+
+ if (clk_id = 1 clk_id = 3) {
+ setbits_le32(pmc-pmc_clk_out_cntrl,
+1 (2 + (clk_id - 1) * 8));
+ } else {
+ printf(%s: Unknown output clock id %d\n, __func__, clk_id);
+ return -EINVAL;
+ }
+
+ return 0;
+}
diff --git a/arch/arm/include/asm/arch-tegra/clock.h
b/arch/arm/include/asm/arch-tegra/clock.h
index 04011ae..f9dd3c8 100644
--- a/arch/arm/include/asm/arch-tegra/clock.h
+++ b/arch/arm/include/asm/arch-tegra/clock.h
@@ -336,4 +336,12 @@ void arch_timer_init(void);
void tegra30_set_up_pllp(void);
+/**
+ * Enable output clock for external peripherals
+ *
+ * @param clk_id Clock ID to output (1, 2 or 3)
+ * @return 0 if OK. -ve on error
+ */
+int clock_external_output(int clk_id);
+
#endif /* _TEGRA_CLOCK_H_ */
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] configs: ti_omap5_common: Enable workaround for ARM errata 798870
From: Angela Stegmaier angelaba...@ti.com Enable the workaround for ARM errata 798870 for OMAP5 and DRA7xx since they are Coretx-A15 r2. Signed-off-by: Angela Stegmaier angelaba...@ti.com Signed-off-by: Nishanth Menon n...@ti.com --- include/configs/ti_omap5_common.h |4 1 file changed, 4 insertions(+) diff --git a/include/configs/ti_omap5_common.h b/include/configs/ti_omap5_common.h index 925cb42dd38d..bce9a505cbb3 100644 --- a/include/configs/ti_omap5_common.h +++ b/include/configs/ti_omap5_common.h @@ -21,6 +21,10 @@ #define CONFIG_DISPLAY_BOARDINFO #define CONFIG_ARCH_CPU_INIT +/* Common ARM Erratas */ +#define CONFIG_ARM_ARCH_CP15_ERRATA +#define CONFIG_ARM_ERRATA_798870 + #define CONFIG_SYS_CACHELINE_SIZE 64 /* Use General purpose timer 1 */ -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] omap_gpmc: Do not default to HAM1 when SW ECC is selected
The ECC scheme selection algorithm in OMAP GPMC appears to be left untested when
BCH8 handling code was added. Running 'nandecc sw' defaults to HAM1 even if
the board is using another scheme (ex. OMAP_ECC_BCH8_CODE_HW_DETECTION_SW on
OMAP3). This results in unrecoverable ECC errors when reading data. This commit
fixes the behavior by checking for CONFIG_BCH and using the scheme defined by
CONFIG_NAND_OMAP_ECCSCHEME in the board configuration file.
This has been tested on Gumstix Overo (OMAP3).
Signed-off-by: Adam YH Lee adam.yh@gmail.com
---
drivers/mtd/nand/omap_gpmc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c
index fc64f48..5daf932 100644
--- a/drivers/mtd/nand/omap_gpmc.c
+++ b/drivers/mtd/nand/omap_gpmc.c
@@ -901,8 +901,13 @@ int __maybe_unused omap_nand_switch_ecc(uint32_t hardware,
uint32_t eccstrength)
return -EINVAL;
}
} else {
+ #ifdef CONFIG_BCH
+ err = omap_select_ecc_scheme(nand, CONFIG_NAND_OMAP_ECCSCHEME,
+ mtd-writesize, mtd-oobsize);
+ #else
err = omap_select_ecc_scheme(nand, OMAP_ECC_HAM1_CODE_SW,
mtd-writesize, mtd-oobsize);
+ #endif
}
/* Update NAND handling after ECC mode switch */
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/8] exynos: config: enable arch memcpy and arch memset
On 16 February 2015 at 08:13, Przemyslaw Marczak p.marc...@samsung.com wrote: This commit enables the following configs: - CONFIG_USE_ARCH_MEMCPY - CONFIG_USE_ARCH_MEMSET This increases the performance of memcpy/memset and also reduces the boot time. This was tested on Trats2. A quick test with trace. Boot time from start to main_loop() entry: - ~1527ms - before this change (arch memset enabled for .bss clear) - ~1384ms - after this change Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com Cc: Minkyu Kang mk7.k...@samsung.com Cc: Akshay Saraswat aksha...@samsung.com Cc: Simon Glass s...@chromium.org Cc: Sjoerd Simons sjoerd.sim...@collabora.co.uk --- include/configs/exynos-common.h | 3 +++ 1 file changed, 3 insertions(+) Reviewed-by: Simon Glass s...@chromium.org BTW in case you are interested, in the Chromium U-Boot tree (chromeos-v2013.06 branch) we have exynos support for turning on the cache in SPL and leaving it on through to the end of U-Boot. It runs two SPLs and two U-Boots (with verified boot and kernel verification) in a total of about 750ms. This shipped last year with Pit and Pi (Samsung Chromebook 2). Might be some interesting patches there... Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] dm: cros_ec: Convert to Kconfig
On 13 February 2015 at 12:20, Simon Glass s...@chromium.org wrote: Since both I2C and SPI are converted to Kconfig, we can convert cros_ec to Kconfig for these buses. LPC will need to wait until driver mode PCI is available. Signed-off-by: Simon Glass s...@chromium.org --- configs/peach-pi_defconfig | 4 configs/peach-pit_defconfig | 4 configs/sandbox_defconfig | 5 configs/snow_defconfig | 5 drivers/input/Kconfig | 6 + drivers/misc/Kconfig| 48 - include/configs/exynos5-dt-common.h | 3 --- include/configs/peach-pi.h | 1 - include/configs/peach-pit.h | 1 - include/configs/sandbox.h | 4 include/configs/snow.h | 2 -- 11 files changed, 71 insertions(+), 12 deletions(-) Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] dm: mx6: Adjust mx6sxsabresd to use Kconfig for DM_THERMAL
On 13 February 2015 at 12:20, Simon Glass s...@chromium.org wrote: Use Kconfig instead of board config for DM and DM_THERMAL. Signed-off-by: Simon Glass s...@chromium.org --- configs/mx6sxsabresd_defconfig | 2 ++ configs/mx6sxsabresd_spl_defconfig | 2 ++ include/configs/mx6sxsabresd.h | 2 -- 3 files changed, 4 insertions(+), 2 deletions(-) Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/8] arm: relocation: clear .bss section with arch memset if defined
Hi Przemyslaw, On 16 February 2015 at 08:21, Przemyslaw Marczak p.marc...@samsung.com wrote: Hello, On 02/16/2015 04:13 PM, Przemyslaw Marczak wrote: For ARM architecture, enable the CONFIG_USE_ARCH_MEMSET/MEMCPY, will highly increase the memset/memcpy performance. This is able thanks to the ARM multiple register instructions. Unfortunatelly the relocation is done without the cache enabled, so it takes some time, but zeroing the BSS memory takes much more longer, especially for the configs with big static buffers. A quick test confirms, that the boot time improvement after using the arch memcpy for relocation has no significant meaning. The same test confirms that enable the memset for zeroing BSS, reduces the boot time. So this patch enables the arch memset for zeroing the BSS after the relocation process. For ARM boards, this can be enabled in board configs by defining: 'CONFIG_USE_ARCH_MEMSET'. This was tested on Trats2. A quick test with trace. Boot time from start to main_loop() entry: - ~1384ms - before this change - ~888ms - after this change Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Tom Rini tr...@ti.com --- arch/arm/lib/crt0.S | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S index 22df3e5..fab3d2c 100644 --- a/arch/arm/lib/crt0.S +++ b/arch/arm/lib/crt0.S @@ -115,14 +115,22 @@ here: bl c_runtime_cpu_setup /* we still call old routine here */ ldr r0, =__bss_start/* this is auto-relocated! */ - ldr r1, =__bss_end /* this is auto-relocated! */ +#ifdef CONFIG_USE_ARCH_MEMSET + ldr r3, =__bss_end /* this is auto-relocated! */ + mov r1, #0x /* prepare zero to clear BSS */ + + subsr2, r3, r0 /* r2 = memset len */ + bl memset +#else + ldr r1, =__bss_end /* this is auto-relocated! */ mov r2, #0x /* prepare zero to clear BSS */ clbss_l:cmp r0, r1 /* while not at end of BSS */ strlo r2, [r0]/* clear 32-bit BSS word */ addlo r0, r0, #4 /* move to next */ blo clbss_l +#endif bl coloured_LED_init bl red_led_on This commit left unchanged. After boot time test using oscilloscope and the clock cycle counter I didn't noticed a time difference in more then one ms. In this case I think that insert a duplicated code here, has no sense. I don't understand this comment, sorry. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/8] dfu: mmc: file buffer: remove static allocation
On 16 February 2015 at 08:13, Przemyslaw Marczak p.marc...@samsung.com wrote: For writing files, DFU implementation requires the file buffer with the len at least of file size. For big files it requires the same big buffer. Previously the file buffer was allocated as a static variable, so it was a part of U-Boot .bss section. For 32MiB len of buffer we have 32MiB of additional space, required for this section. The .bss needs to be cleared after the relocation. This introduces an additional boot delay at every start, but usually the dfu feature is not required at the standard boot, so the buffer should be allocated only if required. This patch removes the static allocation of this buffer, and alloc it with memalign after first call of function: - dfu_fill_entity_mmc() and the buffer is freed on dfu_free_entity() call. This was tested on Trats2. A quick test with trace. Boot time from start to main_loop() entry: - ~888ms - before this change (arch memset enabled for .bss clear) - ~464ms - after this change Wow. Reviewed-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/8] README: add info about skip memset at malloc init
Hi Przemyslaw, On 16 February 2015 at 08:13, Przemyslaw Marczak p.marc...@samsung.com wrote: Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com --- README | 7 +++ 1 file changed, 7 insertions(+) diff --git a/README b/README index fefa71c..8673640 100644 --- a/README +++ b/README @@ -3989,6 +3989,13 @@ Configuration Settings: - CONFIG_SYS_MALLOC_LEN: Size of DRAM reserved for malloc() use. +- CONFIG_SYS_MALLOC_INIT_SKIP_ZEROING: + Do not set to zero the reserved DRAM area when init malloc. + For very big CONFIG_SYS_MALLOC_LEN(more than one MB), this will + reduce the boot time. + Before enabling this, please check if malloc calls, maybe + should be replaced by calloc - if expects zeroed memory. + I think if you put this in Kconfig you can put this help there. - CONFIG_SYS_MALLOC_F_LEN Size of the malloc() pool for use before relocation. If this is defined, then a very simple malloc() implementation (this one is in Kconfig now too) Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/8] dlmalloc: add option for skip memset in malloc init
Hi Przemyslaw,
On 16 February 2015 at 08:13, Przemyslaw Marczak p.marc...@samsung.com wrote:
This commit introduces new config: CONFIG_SYS_MALLOC_INIT_SKIP_ZEROING.
Before this change, the all amount of memory reserved for the malloc,
was set to zero in mem_malloc_init(). When the malloc reserved memory
exceeds few MiB, then the boot process can slow down.
So enabling this config, is an option to reduce the boot time.
Note:
After enable this option, only calloc() will return the pointer to zeroed
memory area. Previously, without this option, the memory pointed to untouched
malloc memory region, was filled with zeros. So it means, that code with
malloc() calls should be reexamined.
Can this go in Kconfig somewhere?
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
---
common/dlmalloc.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index 6453ee9..63f68ed 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -1535,9 +1535,9 @@ void mem_malloc_init(ulong start, ulong size)
debug(using memory %#lx-%#lx for malloc()\n, mem_malloc_start,
mem_malloc_end);
-
- memset((void *)mem_malloc_start, 0, size);
-
+#ifndef CONFIG_SYS_MALLOC_INIT_SKIP_ZEROING
+ memset((void *)mem_malloc_start, 0x0, size);
+#endif
malloc_bin_reloc();
}
@@ -2948,10 +2948,12 @@ Void_t* cALLOc(n, elem_size) size_t n; size_t
elem_size;
/* check if expand_top called, in which case don't need to clear */
+#ifndef CONFIG_SYS_MALLOC_INIT_SKIP_ZEROING
#if MORECORE_CLEARS
mchunkptr oldtop = top;
INTERNAL_SIZE_T oldtopsize = chunksize(top);
#endif
+#endif
Void_t* mem = mALLOc (sz);
if ((long)n 0) return NULL;
@@ -2977,6 +2979,7 @@ Void_t* cALLOc(n, elem_size) size_t n; size_t elem_size;
csz = chunksize(p);
+#ifndef CONFIG_SYS_MALLOC_INIT_SKIP_ZEROING
#if MORECORE_CLEARS
if (p == oldtop csz oldtopsize)
{
@@ -2984,6 +2987,7 @@ Void_t* cALLOc(n, elem_size) size_t n; size_t elem_size;
csz = oldtopsize;
}
#endif
+#endif
MALLOC_ZERO(mem, csz - SIZE_SZ);
return mem;
--
1.9.1
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v3 07/14] dm: eth: Add basic driver model support to Ethernet stack
Hi Joe,
On 16 February 2015 at 21:37, Joe Hershberger joe.hershber...@gmail.com wrote:
Hi Simon,
On Sun, Feb 15, 2015 at 9:49 AM, Simon Glass s...@chromium.org wrote:
Hi Joe,
On 10 February 2015 at 18:30, Joe Hershberger joe.hershber...@ni.com
wrote:
First just add support for MAC drivers.
It has taken me a while to get through all this unfortunately.
This seems OK to me but needs a clean-up with more comments, etc. If
you like these could go in a separate patch, so if you want to do that
please add my Reviewed-by: Simon Glass s...@chromium.org to this one.
I would prefer that we sort out the bind/probe problem before this is
merged but I understand you now have quite a bit of work built on top,
and the problems can be separated.
So if you like we could do one more version, merge it, and continue
with refinements after that.
I'm a bit leery to merge this until I've actually got more of the real-world
implementation for a board done. I guess it could always be corrected in
the future, but at the same time, I think it should be fairly complete. Do
you prefer that it go in as smaller parts? There's still no actual board
supported and the MDIO / PHY support is not done yet.
It's up to you, but I know what it is like when you have a lot of
patches backed up. A real board certainly helps though.
Signed-off-by: Joe Hershberger joe.hershber...@ni.com
---
Changes in v3:
-Correct the pre_unbind logic
-Correct failure chaining from bind to probe to init
--Fail init if not activated
--Fail probe if ethaddr not set
-Update ethaddr from env unconditionally on init
-Use set current to select the current device regardless of the previous
selection
-Allow current eth dev to be NULL
-Fixed blank line formatting for variable declaration
Changes in v2:
-Updated comments
-Removed extra parentheses
-Changed eth_uclass_priv local var names to be uc_priv
-Update error codes
-Cause an invalid name to fail binding
-Rebase on top of dm/master
-Stop maintaining our own index and use DM seq now that it works for our
needs
-Move the hwaddr to platdata so that its memory is allocated at bind
when we need it
-Prevent device from being probed before used by a command (i.e. before
eth_init()).
common/board_r.c | 4 +-
common/cmd_bdinfo.c| 2 +
include/dm/uclass-id.h | 1 +
include/net.h | 25
net/eth.c | 336
-
5 files changed, 361 insertions(+), 7 deletions(-)
diff --git a/common/board_r.c b/common/board_r.c
index 68a9448..75147b7 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -556,7 +556,7 @@ static int initr_bbmii(void)
}
#endif
-#ifdef CONFIG_CMD_NET
+#if defined(CONFIG_CMD_NET) !defined(CONFIG_DM_ETH)
static int initr_net(void)
{
puts(Net: );
@@ -825,7 +825,7 @@ init_fnc_t init_sequence_r[] = {
#ifdef CONFIG_BITBANGMII
initr_bbmii,
#endif
-#ifdef CONFIG_CMD_NET
+#if defined(CONFIG_CMD_NET) !defined(CONFIG_DM_ETH)
INIT_FUNC_WATCHDOG_RESET
initr_net,
#endif
diff --git a/common/cmd_bdinfo.c b/common/cmd_bdinfo.c
index e6d8a7a..8688cf9 100644
--- a/common/cmd_bdinfo.c
+++ b/common/cmd_bdinfo.c
@@ -34,6 +34,7 @@ static void print_eth(int idx)
printf(%-12s= %s\n, name, val);
}
+#ifndef CONFIG_DM_ETH
__maybe_unused
static void print_eths(void)
{
@@ -52,6 +53,7 @@ static void print_eths(void)
printf(current eth = %s\n, eth_get_name());
printf(ip_addr = %s\n, getenv(ipaddr));
}
+#endif
__maybe_unused
static void print_lnum(const char *name, unsigned long long value)
diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
index 91bb90d..ad96682 100644
--- a/include/dm/uclass-id.h
+++ b/include/dm/uclass-id.h
@@ -34,6 +34,7 @@ enum uclass_id {
UCLASS_I2C_GENERIC, /* Generic I2C device */
UCLASS_I2C_EEPROM, /* I2C EEPROM device */
UCLASS_MOD_EXP, /* RSA Mod Exp device */
+ UCLASS_ETH, /* Ethernet device */
UCLASS_COUNT,
UCLASS_INVALID = -1,
diff --git a/include/net.h b/include/net.h
index 4d7575e..11471bd 100644
--- a/include/net.h
+++ b/include/net.h
@@ -78,6 +78,30 @@ enum eth_state_t {
ETH_STATE_ACTIVE
};
+#ifdef CONFIG_DM_ETH
+struct eth_pdata {
+ phys_addr_t iobase;
+ unsigned char enetaddr[6];
+};
+
+struct eth_ops {
+ int (*init)(struct udevice *dev, bd_t *bis);
Why do we pass in bd_t? Isn't that available through gd-bd?
Legacy. I can kill it if you like.
OK, that's fine, it can die later.
+ int (*send)(struct udevice *dev, void *packet, int length);
+ int (*recv)(struct udevice *dev);
+ void (*halt)(struct udevice *dev);
+#ifdef CONFIG_MCAST_TFTP
+ int (*mcast)(struct
Re: [U-Boot] [RFC PATCH v3 14/14] dm: eth: Add a bridge to a real network for sandbox
Hi Joe,
On 16 February 2015 at 22:16, Joe Hershberger joe.hershber...@gmail.com wrote:
Hi Simon,
On Sun, Feb 15, 2015 at 9:50 AM, Simon Glass s...@chromium.org wrote:
Hi Joe,
On 10 February 2015 at 18:30, Joe Hershberger joe.hershber...@ni.com
wrote:
Implement a bridge between u-boot's network stack and Linux's raw packet
API allowing the sandbox to send and receive packets using the host
machine's network interface.
This raw Ethernet API requires elevated privileges. You can either run
as root, or you can add the capability needed like so:
sudo /sbin/setcap CAP_NET_RAW+ep u-boot
Can you add a note about thsi in README.sandbox? This seems like a
major new feature. It was talked about a few years ago when sandbox
was first created.
OK. Can you maybe point me to that conversation so I can understand what
was anticipated potentially covering more of what was expected.
All I could find was this:
http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/108687
Signed-off-by: Joe Hershberger joe.hershber...@ni.com
---
Changes in v3:
-Made the os raw packet support for sandbox eth build and work.
Changes in v2:
-Added the raw packet proof-of-concept patch.
arch/sandbox/dts/sandbox.dts | 6 ++
arch/sandbox/include/asm/sandbox-raw-os.h | 16
drivers/net/Makefile | 11 +++
drivers/net/sandbox-raw-os.c | 105
drivers/net/sandbox-raw.c | 128
++
include/configs/sandbox.h | 1 +
6 files changed, 267 insertions(+)
create mode 100644 arch/sandbox/include/asm/sandbox-raw-os.h
create mode 100644 drivers/net/sandbox-raw-os.c
create mode 100644 drivers/net/sandbox-raw.c
diff --git a/arch/sandbox/dts/sandbox.dts b/arch/sandbox/dts/sandbox.dts
index ba635e8..13bd6c2 100644
--- a/arch/sandbox/dts/sandbox.dts
+++ b/arch/sandbox/dts/sandbox.dts
@@ -188,4 +188,10 @@
reg = 0x10002000 0x1000;
fake-host-hwaddr = 0x00 0x00 0x66 0x44 0x22 0x00;
};
+
+ eth@8000 {
+ compatible = sandbox,eth,raw;
We normally have vendor,device, so maybe sandbox,raw-eth
OK
+ reg = 0x8000 0x1000;
+ host-raw-interface = eth0;
+ };
};
diff --git a/arch/sandbox/include/asm/sandbox-raw-os.h
b/arch/sandbox/include/asm/sandbox-raw-os.h
new file mode 100644
index 000..4e5d418
--- /dev/null
+++ b/arch/sandbox/include/asm/sandbox-raw-os.h
@@ -0,0 +1,16 @@
+/*
+ * Copyright (c) 2015 National Instruments
+ *
+ * (C) Copyright 2015
+ * Joe Hershberger joe.hershber...@ni.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#pragma once
We use #ifdef for this in U-Boot at present. I'm not sure why -
perhaps compatibility?
OK
+
+int sandbox_raw_init(int *sd, void **devp, const char *ifname,
+unsigned char *ethmac);
+int sandbox_raw_send(void *packet, int length, int sd, void *device);
+int sandbox_raw_recv(void *packet, int *length, int sd, void *device);
+void sandbox_raw_halt(int *sd, void **devp);
Function comments, also what is 'device'?
Comments about what? These are just the functions that implement the
Ethernet driver ops. Is it not sufficient to document the driver ops
themselves (as you requested in the other patch)?
Well they seem to have different parameters:
- what is 'device'?
- what is'sd''?
I think these warrant comments.
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 15dc431..39975b3 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -51,6 +51,8 @@ obj-$(CONFIG_PCNET) += pcnet.o
obj-$(CONFIG_RTL8139) += rtl8139.o
obj-$(CONFIG_RTL8169) += rtl8169.o
obj-$(CONFIG_ETH_SANDBOX) += sandbox.o
+obj-$(CONFIG_ETH_SANDBOX_RAW) += sandbox-raw.o
+obj-$(CONFIG_ETH_SANDBOX_RAW) += sandbox-raw-os.o
obj-$(CONFIG_SH_ETHER) += sh_eth.o
obj-$(CONFIG_SMC9) += smc9.o
obj-$(CONFIG_SMC911X) += smc911x.o
@@ -68,3 +70,12 @@ obj-$(CONFIG_XILINX_LL_TEMAC) += xilinx_ll_temac.o
xilinx_ll_temac_mdio.o \
obj-$(CONFIG_ZYNQ_GEM) += zynq_gem.o
obj-$(CONFIG_FSL_MC_ENET) += fsl_mc/
obj-$(CONFIG_VSC9953) += vsc9953.o
+
+# sandbox-raw-os.c is built in the system env, so needs standard
includes
+# CFLAGS_REMOVE_sandbox-raw-os.o cannot be used to drop header include
path
+quiet_cmd_cc_sandbox-raw-os.o = CC $(quiet_modtag) $@
+cmd_cc_sandbox-raw-os.o = $(CC) $(filter-out -nostdinc, \
+ $(patsubst -I%,-idirafter%,$(c_flags))) -c -o $@ lt;
+
+$(obj)/sandbox-raw-os.o: $(src)/sandbox-raw-os.c FORCE
+ $(call if_changed_dep,cc_sandbox-raw-os.o)
Can we please move this to the same directory as os.c, so that all the
OS-specific stuff is in one place.
OK
diff --git a/drivers/net/sandbox-raw-os.c b/drivers/net/sandbox-raw-os.c
Re: [U-Boot] [PATCH v2 11/12] tegra124: Reserve secure RAM using MC_SECURITY_CFG{0, 1}_0
On 2015-02-17 22:06, Stephen Warren wrote: On 02/16/2015 05:54 AM, Jan Kiszka wrote: From: Ian Campbell i...@hellion.org.uk These registers can be used to prevent non-secure world from accessing a megabyte aligned region of RAM, use them to protect the u-boot secure monitor code. At first I tried to do this from s_init(), however this inexplicably causes u-boot's networking (e.g. DHCP) to fail, while networking under Linux was fine. So instead I have added a new weak arch function protect_secure_section() called from relocate_secure_section() and reserved the region there. This is better overall since it defers the reservation until after the sec vs. non-sec decision (which can be influenced by an envvar) has been made when booting the os. diff --git a/arch/arm/cpu/tegra-common/ap.c b/arch/arm/cpu/tegra-common/ap.c +void protect_secure_section(void) +writel(CONFIG_ARMV7_SECURE_BASE, mc-mc_security_cfg0); +writel(CONFIG_ARMV7_SECURE_RESERVE_SIZE20, mc-mc_security_cfg1); Spaces around the ? Fixed for v3. Thanks, Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 11/14] usb: UniPhier: add UniPhier on-chip xHCI host driver support
Hi Masahiro,
On 17 February 2015 at 00:00, Masahiro Yamada yamad...@jp.panasonic.com wrote:
Support xHCI host driver used on Panasonic UniPhier platform.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---
Hi Marek,
I want apply this patch onto u-boot-uniphier/master
to avoid conflicts.
If you are OK with it, could you issue your Acked-by tag, please?
Thanks,
Masahiro
doc/README.uniphier | 3 +-
drivers/usb/host/Kconfig | 8
drivers/usb/host/Makefile| 1 +
drivers/usb/host/xhci-uniphier.c | 85
4 files changed, 96 insertions(+), 1 deletion(-)
create mode 100644 drivers/usb/host/xhci-uniphier.c
diff --git a/doc/README.uniphier b/doc/README.uniphier
index aaeb50c..4902533 100644
--- a/doc/README.uniphier
+++ b/doc/README.uniphier
@@ -73,7 +73,8 @@ Supported devices
- UART (on-chip)
- NAND
- - USB (2.0)
+ - USB 2.0 (EHCI)
+ - USB 3.0 (xHCI)
- LAN (on-board SMSC9118)
- I2C
- EEPROM (connected to the on-board I2C bus)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 0e005c2..24a595f 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -17,6 +17,14 @@ config USB_XHCI
if USB_XHCI_HCD
+config USB_XHCI_UNIPHIER
+ bool Support for Panasonic UniPhier on-chip xHCI USB controller
+ depends on ARCH_UNIPHIER
+ default y
+ ---help---
+ Enables support for the on-chip xHCI controller on Panasonic
+ UniPhier SoCs.
+
endif
config USB_EHCI_HCD
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 66d6e9a..eb6f34b 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_USB_XHCI_KEYSTONE) += xhci-keystone.o
obj-$(CONFIG_USB_XHCI_EXYNOS) += xhci-exynos5.o
obj-$(CONFIG_USB_XHCI_OMAP) += xhci-omap.o
obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o
+obj-$(CONFIG_USB_XHCI_UNIPHIER) += xhci-uniphier.o
# designware
obj-$(CONFIG_USB_DWC2) += dwc2.o
diff --git a/drivers/usb/host/xhci-uniphier.c
b/drivers/usb/host/xhci-uniphier.c
new file mode 100644
index 000..9bbd65f
--- /dev/null
+++ b/drivers/usb/host/xhci-uniphier.c
@@ -0,0 +1,85 @@
+/*
+ * Copyright (C) 2015 Panasonic Corporation
+ * Author: Masahiro Yamada yamad...@jp.panasonic.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include linux/err.h
+#include usb.h
+#include fdtdec.h
+#include xhci.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define FDTgd-fdt_blob
Ick, please don't do this. Just use a local variable if you like.
+#define COMPAT panasonic,uniphier-xhci
This too.
+
+static int get_uniphier_xhci_base(int index, struct xhci_hccr **base)
+{
+ int offset;
+
+ for (offset = fdt_node_offset_by_compatible(FDT, 0, COMPAT);
+offset = 0;
+offset = fdt_node_offset_by_compatible(FDT, offset, COMPAT)) {
+ if (index == 0) {
+ *base = (struct xhci_hccr *)
+ fdtdec_get_addr(FDT, offset, reg);
+ return 0;
+ }
+ index--;
+ }
How about this
count = fdtdec_find_aliasses_for_id(gd-fdt_blob, usb,
COMPAT_PANASONIC_XHCI, node_list, 4);
if (index = count)
return -ENOENT;
offset = node_list[index];
then aliases will work. You need to ad the COMPAT to
include/fdtdec.h/c. See ehci-tegra.c for an example.
+
+ return -ENODEV; /* not found */
+}
+
+#define USB3_RST_CTRL 0x00100040
+#define IOMMU_RST_N(1 5)
+#define LINK_RST_N (1 4)
+
+static void uniphier_xhci_reset(void __iomem *base, int on)
+{
+ u32 tmp;
+
+ tmp = readl(base + USB3_RST_CTRL);
+
+ if (on)
+ tmp = ~(IOMMU_RST_N | LINK_RST_N);
+ else
+ tmp |= IOMMU_RST_N | LINK_RST_N;
+
+ writel(tmp, base + USB3_RST_CTRL);
+}
+
+int xhci_hcd_init(int index, struct xhci_hccr **hccr, struct xhci_hcor
**hcor)
+{
+ int ret;
+ struct xhci_hccr *cr;
+ struct xhci_hcor *or;
+
+ ret = get_uniphier_xhci_base(index, cr);
+ if (ret 0)
+ return ret;
+
+ uniphier_xhci_reset(cr, 0);
+
+ or = (void *)cr + HC_LENGTH(xhci_readl(cr-cr_capbase));
+
+ *hccr = cr;
+ *hcor = or;
+
+ return 0;
+}
+
+void xhci_hcd_stop(int index)
+{
+ int ret;
+ struct xhci_hccr *cr;
+
+ ret = get_uniphier_xhci_base(index, cr);
+ if (ret 0)
+ return;
+
+ uniphier_xhci_reset(cr, 1);
+}
--
1.9.1
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] mmc: exynos dwmmc: check boot mode before init dwmmc
Hi Przemyslaw,
On 17 February 2015 at 06:09, Przemyslaw Marczak p.marc...@samsung.com wrote:
Before this commit, the mmc devices were always registered
in the same order. So dwmmc channel 0 was registered as mmc 0,
channel 1 as mmc 1, etc.
In case of possibility to boot from more then one device,
the CONFIG_SYS_MMC_ENV_DEV should always point to right mmc device.
This can be achieved by init boot device as first, so it will be
always registered as mmc 0. Thanks to this, the 'saveenv' command
will work fine for all mmc boot devices.
Exynos based boards usually uses mmc host channels configuration:
- 0, or 0+1 for 8 bit - as a default boot device (usually eMMC)
- 2 for 4bit - as an optional boot device (usually SD card slot)
And usually the boot order is defined by OM pin configuration,
which can be changed in a few ways, eg.
- Odroid U3 - eMMC card insertion - first boot from eMMC
- Odroid X2/XU3 - boot priority jumper
By this commit, Exynos dwmmc driver will check the OM pin configuration,
and then try to init the boot device and register it as mmc 0.
I think a better way to do this would be to make
CONFIG_SYS_MMC_ENV_DEV support an option where the device can be
selected at run-time.
However that would probably be better done when the drive rmodel
conversion is complete.
So this seems a reasonable patch given where we are.
Reviewed-by: Simon Glass s...@chromium.org
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Jaehoon Chung jh80.ch...@samsung.com
Cc: Pantelis Antoniou pa...@intracom.gr
Cc: Simon Glass s...@chromium.org
Cc: Akshay Saraswat aksha...@samsung.com
---
drivers/mmc/exynos_dw_mmc.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/exynos_dw_mmc.c b/drivers/mmc/exynos_dw_mmc.c
index dfa209b..91f0163 100644
--- a/drivers/mmc/exynos_dw_mmc.c
+++ b/drivers/mmc/exynos_dw_mmc.c
@@ -13,6 +13,7 @@
#include asm/arch/dwmmc.h
#include asm/arch/clk.h
#include asm/arch/pinmux.h
+#include asm/arch/power.h
#include asm/gpio.h
#include asm-generic/errno.h
@@ -166,7 +167,6 @@ static int exynos_dwmci_get_config(const void *blob, int
node,
if (host-dev_index == host-dev_id)
host-dev_index = host-dev_id - PERIPH_ID_SDMMC0;
-
/* Get the bus width from the device node */
host-buswidth = fdtdec_get_int(blob, node, samsung,bus-width, 0);
if (host-buswidth = 0) {
@@ -229,12 +229,21 @@ int exynos_dwmmc_init(const void *blob)
{
int compat_id;
int node_list[DWMMC_MAX_CH_NUM];
+ int boot_dev_node;
int err = 0, count;
compat_id = COMPAT_SAMSUNG_EXYNOS_DWMMC;
count = fdtdec_find_aliases_for_id(blob, mmc,
compat_id, node_list, DWMMC_MAX_CH_NUM);
+
+ /* For DWMMC always set boot device as mmc 0 */
+ if (count = 3 get_boot_mode() == BOOT_MODE_SD) {
+ boot_dev_node = node_list[2];
+ node_list[2] = node_list[0];
+ node_list[0] = boot_dev_node;
+ }
+
err = exynos_dwmci_process_node(blob, node_list, count);
return err;
--
1.9.1
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v3 01/14] dm: core: Allow seq numbers to be resolved before probe
Hi Joe, On 16 February 2015 at 21:17, Joe Hershberger joe.hershber...@gmail.com wrote: Hi Simon, On Sun, Feb 15, 2015 at 9:59 AM, Simon Glass s...@chromium.org wrote: Hi Joe, On 13 February 2015 at 19:33, Joe Hershberger joe.hershber...@gmail.com wrote: On Thu, Feb 12, 2015 at 11:14 PM, Simon Glass s...@chromium.org wrote: Hi Joe, On 10 February 2015 at 23:08, Joe Hershberger joe.hershber...@gmail.com wrote: Hi Simon, On Tue, Feb 10, 2015 at 10:39 PM, Simon Glass s...@chromium.org wrote: Hi Joe, On 10 February 2015 at 18:30, Joe Hershberger joe.hershber...@ni.com wrote: Before this patch, if the sequence numbers were resolved before probe, this code would insist on defining new non-conflicting-with-itself seq numbers. Now any non -1 seq number is accepted as already resolved. Can you explain what problem this solves? At present, when probing a device, -seq must be -1 (sort-of by definition since it doesn't exist as an active device in the uclass). Please look at eth_post_bind() in patch 07/14. The Ethernet devices need to write their hardware addresses to the registers in bind (since it needs to happen regardless of the device being used so that Linux will see the MAC address). As such, the sequence number is needed to look up the ethaddr. In order to avoid probing all the devices to get the seq number resolved, I resolve it in post_bind to avoid the rest of the overhead (thus no longer probing in post_bind, which was one of the issues previously). Then when probe comes along, the seq is already resolved. That's why this patch is needed. OK I see. This is a bit messy. If the MAC address assignment is part of the bind step then it shouldn't need the seq number. Not sure why you say that. The reason I need the seq number is because I need to look up the proper env variable for the MAC address. E.g. ethaddr, eth2addr, etc. The seq number select which one to read from the env. We should be able to do this after a probe. A device which is bound but not probed does not have a sequence number, as things currently stand. I can think of some poor ways to do this but a nice way is not obvious! Not sure what you're referring to here. What is this in this context? Figuring out the sequence number. One option would be probe all the Ethernet devices on startup. If probe() only set up the hardware (including MAC address) then that might work. It would be fairly fast since it wouldn't involve starting up the link, etc. I suspect you are worried about a lot of Ethernet devices sitting around probed by unused. I'm not sure if that matters though. I had it probing the devices originally (by calling first and next) and you commented that it shouldn't happen until the devices are used. However, I That was because your code was probing things in the bind mehod. don't think we can guarantee that all drivers that come later will have simple probe (since that's not part of the contract). I think I agree with your original statement that we should not probe. It seems more suitable to write the hwaddr in bind as a known and limited side effect. I don't like the idea of an ethernet device supporting writing its hardware address before it is probed. Until it is probed we don't really know it is there, nor where it is exactly (bus, memory address). So I think writing the hardware address makes more sense after probe. But probe should not happen as part of bind. It seems to me it could happen in your eth_init(). OK. I can see why you prefer not to have the hardware accessed in bind. In order to probe the devices (but not from bind) I'll have to add back eth_initialize() and have it probe all of the devices. the eth_init() that you see here is what gets called when the network is enabled, so it certainly shouldn't go in eth_init(). I could potentially rename it to eth_start() or something. That would be clearer, but would break from the former naming for anyone familiar. I see. Maybe eth_probe_all_devices()? The seq number resolution seems fairly well contained as I implemented it in bind. I simply call the core function and write the result to the device member. Then of course this patch to remove the assert. Yes it is well contained, but I still don't think it is right. If you want to put '#ifndef CONFIG_DM_NET' around the assert in uclass_resolve_seq() while we work it out, that is OK with me. I will work on making it correct instead of adding that. OK. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] apalis/colibri_t30: fix MMC/SD card detect GPIOs
On 17 February 2015 at 07:28, Marcel Ziswiler mar...@ziswiler.com wrote: This fixes the MMC/SD card detect GPIOs for Apalis T30 which got broken by the following commit: 2b2b50bc8748bf1ddb2d96da7157f9eecbe24961 While at it also re-add the comments describing which particular Apalis/Colibri pins those GPIOs are on. Signed-off-by: Marcel Ziswiler mar...@ziswiler.com --- arch/arm/dts/tegra30-apalis.dts | 9 +++-- arch/arm/dts/tegra30-colibri.dts | 4 +++- 2 files changed, 10 insertions(+), 3 deletions(-) Reviewed-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Documentation: gpio: fix bindings document
On 17 February 2015 at 20:08, Simon Glass s...@chromium.org wrote: On 12 February 2015 at 02:49, Masahiro Yamada yamad...@jp.panasonic.com wrote: [ imported from Linux Kernel, commit 74981fb81d83 ] Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Signed-off-by: Linus Walleij linus.wall...@linaro.org Acked-by: Simon Glass s...@chromium.org Applied to u-boot-dm, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] dm: Move CONFIG_I2C_COMPAT to Kconfig
On 13 February 2015 at 12:20, Simon Glass s...@chromium.org wrote: Make this option available in Kconfig and clean up the board that uses it. Note there is also an entry in exynos5-common.h but this affects multiple boards and should be dropped as part of the Samsung I2C migration to driver model. Signed-off-by: Simon Glass s...@chromium.org --- configs/odroid_defconfig | 2 ++ drivers/i2c/Kconfig | 9 + include/configs/exynos5-common.h | 2 ++ include/configs/odroid.h | 2 -- 4 files changed, 13 insertions(+), 2 deletions(-) Applied to u-boot-dm. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] dm: gpio: extend gpio api by dm_gpio_set_pull()
+Stephen who might have an opinion on this.
Hi Przemyslaw,
On 17 February 2015 at 06:09, Przemyslaw Marczak p.marc...@samsung.com wrote:
This commits extends:
- dm gpio ops by: 'set_pull' call
- dm gpio uclass by: dm_gpio_set_pull() function
The pull mode is not defined so should be driver specific.
It's good to implement this, but I think you should try to have a
standard interface. You could define the options you want to support
and pass in a standard value.
Otherwise we are not really providing a driver abstraction, only an interface.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
CC: Simon Glass s...@chromium.org
---
drivers/gpio/gpio-uclass.c | 12
include/asm-generic/gpio.h | 12
2 files changed, 24 insertions(+)
diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
index a69bbd2..48b31c2 100644
--- a/drivers/gpio/gpio-uclass.c
+++ b/drivers/gpio/gpio-uclass.c
@@ -321,6 +321,18 @@ int dm_gpio_set_value(struct gpio_desc *desc, int value)
return 0;
}
+int dm_gpio_set_pull(struct gpio_desc *desc, int pull)
+{
+ int ret;
+
+ ret = check_reserved(desc, set_pull);
+ if (ret)
+ return ret;
+
+ gpio_get_ops(desc-dev)-set_pull(desc-dev, desc-offset, pull);
Should return this value.
+ return 0;
+}
+
int dm_gpio_set_dir_flags(struct gpio_desc *desc, ulong flags)
{
struct udevice *dev = desc-dev;
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index 3b96b82..7e0d426 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -241,6 +241,7 @@ struct dm_gpio_ops {
int value);
int (*get_value)(struct udevice *dev, unsigned offset);
int (*set_value)(struct udevice *dev, unsigned offset, int value);
+ int (*set_pull)(struct udevice *dev, unsigned offset, int pull);
/**
* get_function() Get the GPIO function
*
@@ -479,6 +480,7 @@ int gpio_free_list_nodev(struct gpio_desc *desc, int
count);
/**
* dm_gpio_get_value() - Get the value of a GPIO
+
*
* This is the driver model version of the existing gpio_get_value() function
* and should be used instead of that.
@@ -495,6 +497,16 @@ int dm_gpio_get_value(struct gpio_desc *desc);
int dm_gpio_set_value(struct gpio_desc *desc, int value);
/**
+ * dm_gpio_set_pull() - Set the pull-up/down value of a GPIO
+ *
+ * @desc: GPIO description containing device, offset and flags,
+ * previously returned by gpio_request_by_name()
+ * @pull: GPIO pull value - driver specific
+ * @return 0 on success or -ve on error
+*/
+int dm_gpio_set_pull(struct gpio_desc *desc, int pull);
+
+/**
* dm_gpio_set_dir() - Set the direction for a GPIO
*
* This sets up the direction according tot the provided flags. It will do
--
1.9.1
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] apalis_t30: enable gigabit ethernet via pcie
On 17 February 2015 at 07:28, Marcel Ziswiler mar...@ziswiler.com wrote: Now with all the Tegra PCIe and Intel E1000 gigabit Ethernet driver updates being merged actually make use of it. While at it get rid of the USB networking support which now does not make much sense any longer. Signed-off-by: Marcel Ziswiler mar...@ziswiler.com --- Reviewed-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v3 11/14] dm: eth: Add support for aliases
Hi Joe,
On 16 February 2015 at 22:04, Joe Hershberger joe.hershber...@gmail.com wrote:
On Sun, Feb 15, 2015 at 9:50 AM, Simon Glass s...@chromium.org wrote:
Hi Joe,
On 10 February 2015 at 18:30, Joe Hershberger joe.hershber...@ni.com
wrote:
Allow network devices to be referred to as eth0 instead of
eth@12345678 when specified in ethact.
Add tests to verify this behavior.
Signed-off-by: Joe Hershberger joe.hershber...@ni.com
---
Changes in v3:
-Added support for aliases
Changes in v2: None
include/configs/sandbox.h | 4 ++--
include/fdtdec.h | 1 +
include/net.h | 5 +
lib/fdtdec.c | 1 +
net/eth.c | 53
+++
test/dm/eth.c | 25 ++
test/dm/test.dts | 10 +
7 files changed, 84 insertions(+), 15 deletions(-)
diff --git a/include/configs/sandbox.h b/include/configs/sandbox.h
index fdba1c8..9df5f74 100644
--- a/include/configs/sandbox.h
+++ b/include/configs/sandbox.h
@@ -187,7 +187,7 @@
stderr=serial,lcd\0 \
ethaddr=00:00:11:22:33:44\0 \
eth1addr=00:00:11:22:33:45\0 \
- eth2addr=00:00:11:22:33:46\0 \
+ eth5addr=00:00:11:22:33:46\0 \
ipaddr=1.2.3.4\0
#else
@@ -196,7 +196,7 @@
stderr=serial,lcd\0 \
ethaddr=00:00:11:22:33:44\0 \
eth1addr=00:00:11:22:33:45\0 \
- eth2addr=00:00:11:22:33:46\0 \
+ eth5addr=00:00:11:22:33:46\0 \
ipaddr=1.2.3.4\0
#endif
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 231eed7..e945baa 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -167,6 +167,7 @@ enum fdt_compat_id {
COMPAT_INTEL_GMA, /* Intel Graphics Media
Accelerator */
COMPAT_AMS_AS3722, /* AMS AS3722 PMIC */
COMPAT_INTEL_ICH_SPI, /* Intel ICH7/9 SPI controller
*/
+ COMPAT_ETHERNET,/* Ethernet devices */
SANDBOX_ETHERNET
This is not limited to sandbox. This is needed for all Ethernet MACs. Is
there some other way that I should be identifying with all devices in the
device tree of a certain class?
Not that I know of. But each Ethernet driver would need its own
compatible string, since otherwise driver model won't use the right
driver.
COMPAT_COUNT,
};
diff --git a/include/net.h b/include/net.h
index 11471bd..4e98850 100644
--- a/include/net.h
+++ b/include/net.h
@@ -38,6 +38,8 @@
#define PKTALIGN ARCH_DMA_MINALIGN
+#define ETH_MAX_DEVS 32
+
/* IPv4 addresses are always 32 bits in size */
typedef __be32 IPaddr_t;
@@ -79,6 +81,8 @@ enum eth_state_t {
};
#ifdef CONFIG_DM_ETH
+#define ETH_ALIAS_ROOT eth
+
struct eth_pdata {
phys_addr_t iobase;
unsigned char enetaddr[6];
@@ -96,6 +100,7 @@ struct eth_ops {
};
struct udevice *eth_get_dev(void); /* get the current device */
+struct udevice *eth_get_dev_by_name(const char *devname);
unsigned char *eth_get_ethaddr(void); /* get the current device MAC */
int eth_init_state_only(bd_t *bis); /* Set active state */
void eth_halt_state_only(void); /* Set passive state */
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 5bf8f29..33b0a53 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -75,6 +75,7 @@ static const char * const compat_names[COMPAT_COUNT] =
{
COMPAT(INTEL_GMA, intel,gma),
COMPAT(AMS_AS3722, ams,as3722),
COMPAT(INTEL_ICH_SPI, intel,ich-spi),
+ COMPAT(ETHERNET, eth),
sandbox,eth
Again, this is used to identify all Ethernet controllers. Perhaps
fdtdec_find_aliases_for_id() should not be limiting the alias search to
those that have a certain compatible string?
I think you want 'sandbox,ethernet' here, or similar, but you probably
don't want to use that fdtdec function ultimately. Driver model should
do it all for you.
};
const char *fdtdec_get_compatible(enum fdt_compat_id id)
diff --git a/net/eth.c b/net/eth.c
index e84b948..762effe 100644
--- a/net/eth.c
+++ b/net/eth.c
@@ -10,11 +10,14 @@
#include command.h
#include dm.h
#include dm/device-internal.h
+#include fdtdec.h
#include net.h
#include miiphy.h
#include phy.h
#include asm/errno.h
+DECLARE_GLOBAL_DATA_PTR;
+
void eth_parse_enetaddr(const char *addr, uchar *enetaddr)
{
char *end;
@@ -121,6 +124,39 @@ static void eth_set_dev(struct udevice *dev)
Re: [U-Boot] [RFC PATCH v3 09/14] dm: eth: Add ARP and PING response to sandbox driver
Hi Joe,
On 16 February 2015 at 21:46, Joe Hershberger joe.hershber...@gmail.com wrote:
On Sun, Feb 15, 2015 at 9:49 AM, Simon Glass s...@chromium.org wrote:
Hi Joe,
On 10 February 2015 at 18:30, Joe Hershberger joe.hershber...@ni.com
wrote:
The sandbox driver will now generate response traffic to exercise the
ping command even when no network exists. This allows the basic data
pathways of the DM to be tested.
Signed-off-by: Joe Hershberger joe.hershber...@ni.com
Reviewed-by: Simon Glass s...@chromium.org
---
Changes in v3:
-Prevent a crash if memory is not allocated
Changes in v2:
-Change printfs to debug in sandbox driver
-Move static data to priv
-Move fake hwaddr to the device tree
arch/sandbox/dts/sandbox.dts | 1 +
drivers/net/sandbox.c| 101
+++
2 files changed, 102 insertions(+)
diff --git a/arch/sandbox/dts/sandbox.dts b/arch/sandbox/dts/sandbox.dts
index 502eb3d..ba635e8 100644
--- a/arch/sandbox/dts/sandbox.dts
+++ b/arch/sandbox/dts/sandbox.dts
@@ -186,5 +186,6 @@
eth@10002000 {
compatible = sandbox,eth;
reg = 0x10002000 0x1000;
+ fake-host-hwaddr = 0x00 0x00 0x66 0x44 0x22 0x00;
};
};
diff --git a/drivers/net/sandbox.c b/drivers/net/sandbox.c
index 2a2ad41..f9fa1a1 100644
--- a/drivers/net/sandbox.c
+++ b/drivers/net/sandbox.c
@@ -15,22 +15,121 @@
DECLARE_GLOBAL_DATA_PTR;
+struct eth_sandbox_priv {
+ uchar fake_host_hwaddr[ARP_HLEN];
+ IPaddr_t fake_host_ipaddr;
+ uchar recv_packet_buffer[PKTSIZE];
+ int recv_packet_length;
+};
+
static int sb_eth_init(struct udevice *dev, bd_t *bis)
{
debug(eth_sandbox: Init\n);
+ struct eth_sandbox_priv *priv = dev-priv;
+ u32 int_array[ARP_HLEN];
+ int i;
+
+ if (!priv)
+ return -EINVAL;
How can this happen?
If I recall this was happening when the probe failed due to being unable to
find a MAC address. This meant that the device was not active when the init
was called on it. I believe I later remedied it by checking that the
DM_FLAG_ACTIVATED was set, so this check is probably not needed any longer.
Is there a way in DM to iterate through only those devices that have been
successfully probed or is it my responsibility to check activated before
using any ops?
I normally check it in the uclass. The functions which return a device
-e.g. uclass_get_device...() normally probe the device before it is
returned. The idea is that it should be hard to obtain a 'struct
udevice' in non-core code (i.e. outside drivers/core) without it being
probed first.
But if you want to iterate across all devices and skip those that are
not probed you will need to do it yourself, or add helper functions.
[snip]
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot for Snow problem
On 18 February 2015 at 03:27, Simon Glass s...@chromium.org wrote: Hi Michal, On 16 February 2015 at 04:41, Michal Suchanek hramr...@gmail.com wrote: On 13 February 2015 at 05:51, Simon Glass s...@chromium.org wrote: Hi Michal, On 11 February 2015 at 10:16, Michal Suchanek hramr...@gmail.com wrote: Hello, I changed the SYS_START to work around the bug in the manufacturer firmware, applied snow_defconfig, built u-boot.bin, packed it into kernel uimage, signed it, copied it to a kernel partition, bumped priority of the partition, and rebooted. Do you mean u-boot-dtb.bin? If not you won't get a device tree and it won't work. No, u-boot.bin. With u-boot-dtb.bin I get a snow # prompt on the built-in LCD, and working keyboard. OK sounds like it is working, good! I wonder if we should have a page on elinux.org? Actually it turns out there is linux-exynos.org. Not that it has much information on the Snow hardware, though. Thanks Michal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2015.01-rc2 released
Hi Tom On 02/17/2015 03:25 PM, Tom Rini wrote: [...] In terms of big removal patches, now that -rc2 is out I'm going to take what Masahiro has posted and that didn't cause people to speak up and claim / fix the boards [...] I will be having access to : - mpc8323erdb and - mpc8308rdb and will provide generic board support. I'll also take over the maintainership of those boards if there is no response from current maintainers by then. Please give me a week or so to have all set up. Thanks Sinan Akman ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 10/12] jetson-tk1: Add PSCI configuration options and reserve secure code
On 2015-02-17 22:05, Stephen Warren wrote: On 02/16/2015 05:54 AM, Jan Kiszka wrote: The secure world code is relocated to the MB just below the top of 4G, we reserve it in the FDT (by setting CONFIG_ARMV7_SECURE_RESERVE_SIZE) but it is not protected in h/w. See next patch. diff --git a/include/configs/jetson-tk1.h b/include/configs/jetson-tk1.h +#define CONFIG_ARMV7_PSCI1 +/* Reserve top 1M for secure RAM */ +#define CONFIG_ARMV7_SECURE_BASE0xfff0 Can that not be dynamic? What if the system only has 1GB RAM not 2GB. It's true that all shipped/public versions of this board do have 2GB AFAIK, but we have had internal versions with different amounts of RAM, and I don't think there's anything else in Tegra U-Boots that hard-codes RAM sizes. I tested and checked the PSCI code again, and it turned out to be not position independent yet (vector tables, functions pointers). Everything can be fixed, but I wonder if this shouldn't be done on top, when we have a concrete need. Locating the monitor may involve more factors on different SoCs and boards. So a general solution may be more complicated, even when dynamic relocation itself is solved. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/8] trats2: defconfig: enable expert and skip memset at malloc init
On 16 February 2015 at 08:13, Przemyslaw Marczak p.marc...@samsung.com wrote: Reduce the boot time of Trats2 by disabling the memset at malloc init. This was tested on Trats2. A quick test with trace. Boot time from start to main_loop() entry: - ~464ms - before this change (arch memset enabled for .bss clear) - ~341ms - after this change Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com --- configs/trats2_defconfig | 2 ++ 1 file changed, 2 insertions(+) Reviewed-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 8/8] odroid: defconfig: enable expert and skip malloc memset
On 16 February 2015 at 08:13, Przemyslaw Marczak p.marc...@samsung.com wrote: Reduce the boot time of Odroid X2/U3 by disabling the memset at malloc init. This was tested on Odroid X2. A quick test with checking gpio pin state using the oscilloscope. Boot time from start to bootcmd (change gpio state by memory write command): - ~228ms - before this change (arch memset enabled for .bss clear) - ~100ms - after this change Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com Reviewed-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 6/8] kconfig: malloc: add option for skip memset at malloc init
Hi Przemyslaw, On 16 February 2015 at 08:13, Przemyslaw Marczak p.marc...@samsung.com wrote: Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com --- Kconfig | 26 +++--- 1 file changed, 19 insertions(+), 7 deletions(-) diff --git a/Kconfig b/Kconfig index 4157da3..e08e44a 100644 --- a/Kconfig +++ b/Kconfig @@ -57,13 +57,25 @@ config CC_OPTIMIZE_FOR_SIZE This option is enabled by default for U-Boot. Ah, you have done this. Then I think you can merge this patch with the dlmalloc patch and drop the README one. menuconfig EXPERT -bool Configure standard U-Boot features (expert users) -help - This option allows certain base U-Boot options and settings - to be disabled or tweaked. This is for specialized - environments which can tolerate a non-standard U-Boot. - Only use this if you really know what you are doing. - + bool Configure standard U-Boot features (expert users) + help + This option allows certain base U-Boot options and settings + to be disabled or tweaked. This is for specialized + environments which can tolerate a non-standard U-Boot. + Only use this if you really know what you are doing. + +if EXPERT + config SYS_MALLOC_INIT_SKIP_ZEROING + bool Skip memset at malloc init (reduce boot time) + help +This avoids zeroing memory reserved for malloc at malloc init. +Significant boot time reduction is visible for configs in which +CONFIG_SYS_MALLOC_LEN value, has more than few MiB. +Useful for bzip2, bmp logo. +Warning: +When enable, make sure that calloc() is used when zeroed +memory is needed. +endif endmenu# General setup menu Boot images -- 1.9.1 Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 09/12] tegra124: Add PSCI support for Tegra124
On 2015-02-17 22:03, Stephen Warren wrote:
On 02/16/2015 05:54 AM, Jan Kiszka wrote:
This is based on Thierry Reding's work and uses Ian Campell's
preparatory patches. It comes with full support for CPU_ON/OFF PSCI
services. The algorithm used in this version for turning CPUs on and
off was proposed by Thierry Reding in
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/210881. It
consists of first enabling CPU1..3 via the PMC, just to powergate them
again with the help of the Flow Controller. Once the Flow Controller is
in place, we can leave the PMC alone while processing CPU_ON and CPU_OFF
PSCI requests.
diff --git a/arch/arm/cpu/armv7/tegra124/ap.c
b/arch/arm/cpu/armv7/tegra124/ap.c
+void ap_pm_init(void)
+{
+struct flow_ctlr *flow = (struct flow_ctlr *)NV_PA_FLOW_BASE;
+struct pmc_ctlr *pmc = (struct pmc_ctlr *)NV_PA_PMC_BASE;
+
+writel((u32)park_cpu, EXCEP_VECTOR_CPU_RESET_VECTOR);
+
+tegra_powergate_power_on(TEGRA_POWERGATE_CPU1);
+tegra_powergate_power_on(TEGRA_POWERGATE_CPU2);
+tegra_powergate_power_on(TEGRA_POWERGATE_CPU3);
+
+writel((2 CSR_WAIT_WFI_SHIFT) | CSR_ENABLE, flow-cpu1_csr);
+writel((4 CSR_WAIT_WFI_SHIFT) | CSR_ENABLE, flow-cpu2_csr);
+writel((8 CSR_WAIT_WFI_SHIFT) | CSR_ENABLE, flow-cpu3_csr);
+
+writel(EVENT_MODE_STOP, flow-halt_cpu1_events);
+writel(EVENT_MODE_STOP, flow-halt_cpu2_events);
+writel(EVENT_MODE_STOP, flow-halt_cpu3_events);
I would expect to set up halt_cpu*_events before powering on the CPUs,
to make sure that they do the expected action on the very first WFI. So,
shouldn't the order above be:
Write to halt_cpu*_events
Write to cpu*_csr
power_on
Yeah, that was my original expectation as well. But
diff --git a/arch/arm/cpu/armv7/tegra124/ap.c b/arch/arm/cpu/armv7/tegra124/ap.c
index eebc0ea..240c71d 100644
--- a/arch/arm/cpu/armv7/tegra124/ap.c
+++ b/arch/arm/cpu/armv7/tegra124/ap.c
@@ -25,10 +25,6 @@ void ap_pm_init(void)
writel((u32)park_cpu, EXCEP_VECTOR_CPU_RESET_VECTOR);
- tegra_powergate_power_on(TEGRA_POWERGATE_CPU1);
- tegra_powergate_power_on(TEGRA_POWERGATE_CPU2);
- tegra_powergate_power_on(TEGRA_POWERGATE_CPU3);
-
writel((2 CSR_WAIT_WFI_SHIFT) | CSR_ENABLE, flow-cpu1_csr);
writel((4 CSR_WAIT_WFI_SHIFT) | CSR_ENABLE, flow-cpu2_csr);
writel((8 CSR_WAIT_WFI_SHIFT) | CSR_ENABLE, flow-cpu3_csr);
@@ -37,6 +33,10 @@ void ap_pm_init(void)
writel(EVENT_MODE_STOP, flow-halt_cpu2_events);
writel(EVENT_MODE_STOP, flow-halt_cpu3_events);
+ tegra_powergate_power_on(TEGRA_POWERGATE_CPU1);
+ tegra_powergate_power_on(TEGRA_POWERGATE_CPU2);
+ tegra_powergate_power_on(TEGRA_POWERGATE_CPU3);
+
while (readl(pmc-pmc_pwrgate_status) ((1 TEGRA_POWERGATE_CPU1) |
(1 TEGRA_POWERGATE_CPU2) |
(1 TEGRA_POWERGATE_CPU3)))
doesn't work in practice. I suspect the power-on overwrites what the
flow controller configures in the PMC beforehand. But maybe someone can
explain this better than me.
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/12] pxa: colibri_pxa270: migrate to generic board
On 16 February 2015 at 05:14, Marcel Ziswiler mar...@ziswiler.com wrote: Migrate Toradex Colibri PXA270 to use CONFIG_SYS_GENERIC_BOARD. Signed-off-by: Marcel Ziswiler mar...@ziswiler.com --- include/configs/colibri_pxa270.h | 2 ++ 1 file changed, 2 insertions(+) Reviewed-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot][PATCH v2] keystone2: add support for UART download
Currently to flash u-boot image onto NAND or SPI NOR flash, very first time user need to use Code Composer Studio (CCS). This is cumbersome for an user not familiar with CCS. This patch add simpler procedure using uart boot mode for K2 EVMs. When UART bootmode is set and board is rebooted, the ROM boot loader transfers the image at the beginning of the internal RAM. After the transfer is complete the boot-loader sets the PC to the first internal RAM address 0x0c00. The u-boot.bin is linked to the address 0x0c001000. In order to use the u-boot.bin as an image for UART download, we need to add 4K zeros prefix that act as 1K NOP instructions before reaching 0xc001000. Signed-off-by: Vitaly Andrianov vita...@ti.com Acked-by: Murali Karicheri m-kariche...@ti.com Tested-by: Murali Karicheri m-kariche...@ti.com --- Changes in V2: - removed extra EOL - MSMC replaced by internal RAM in the commit message Makefile| 6 ++ board/ti/ks2_evm/README | 15 +++ 2 files changed, 21 insertions(+) diff --git a/Makefile b/Makefile index 36a9a28..7a86cac 100644 --- a/Makefile +++ b/Makefile @@ -940,6 +940,12 @@ u-boot-nand.gph: u-boot.bin FORCE $(call if_changed,mkimage) @dd if=/dev/zero bs=8 count=1 2/dev/null $@ +u-boot.uart.pad: + @dd if=/dev/zero bs=4 count=1024 2/dev/null $@ + +u-boot.uart: u-boot.uart.pad u-boot.bin FORCE + $(call if_changed,cat) + # x86 uses a large ROM. We fill it with 0xff, put the 16-bit stuff (including # reset vector) at the top, Intel ME descriptor at the bottom, and U-Boot in # the middle. diff --git a/board/ti/ks2_evm/README b/board/ti/ks2_evm/README index 9ee90a4..7e2e096 100644 --- a/board/ti/ks2_evm/README +++ b/board/ti/ks2_evm/README @@ -81,6 +81,21 @@ To build u-boot-nand.gph make k2hk_evm_defconfig make u-boot-nand.gph +To build u-boot.uart + make k2hk_evm_defconfig + make u-boot.uart + +Load and Run U-Boot on keystone EVMs using UART download + + +Open BMC and regular UART terminals. + +1. On the regular UART port start xmodem transfer of the u-boot.uart +2. Using BMC terminal set the ARM-UART bootmode and reboot the EVM + BMC bootmode #4 + MBC reboot +3. When xmodem is complete you should see the u-boot starts on the UART port + Load and Run U-Boot on keystone EVMs using CCS = -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-boot][PATCH v2] keystone2: add support for UART download
On 02/17/2015 10:39 AM, Vitaly Andrianov wrote: Currently to flash u-boot image onto NAND or SPI NOR flash, very first time user need to use Code Composer Studio (CCS). This is cumbersome for an user not familiar with CCS. This patch add simpler procedure using uart boot mode for K2 EVMs. When UART bootmode is set and board is rebooted, the ROM boot loader transfers the image at the beginning of the internal RAM. After the transfer is complete the boot-loader sets the PC to the first internal RAM address 0x0c00. The u-boot.bin is linked to the address 0x0c001000. In order to use the u-boot.bin as an image for UART download, we need to add 4K zeros prefix that act as 1K NOP instructions before reaching 0xc001000. Signed-off-by: Vitaly Andrianov vita...@ti.com Acked-by: Murali Karicheri m-kariche...@ti.com Tested-by: Murali Karicheri m-kariche...@ti.com --- Changes in V2: - removed extra EOL - MSMC replaced by internal RAM in the commit message Makefile| 6 ++ board/ti/ks2_evm/README | 15 +++ 2 files changed, 21 insertions(+) diff --git a/Makefile b/Makefile index 36a9a28..7a86cac 100644 --- a/Makefile +++ b/Makefile @@ -940,6 +940,12 @@ u-boot-nand.gph: u-boot.bin FORCE $(call if_changed,mkimage) @dd if=/dev/zero bs=8 count=1 2/dev/null $@ +u-boot.uart.pad: + @dd if=/dev/zero bs=4 count=1024 2/dev/null $@ + +u-boot.uart: u-boot.uart.pad u-boot.bin FORCE + $(call if_changed,cat) + # x86 uses a large ROM. We fill it with 0xff, put the 16-bit stuff (including # reset vector) at the top, Intel ME descriptor at the bottom, and U-Boot in # the middle. diff --git a/board/ti/ks2_evm/README b/board/ti/ks2_evm/README index 9ee90a4..7e2e096 100644 --- a/board/ti/ks2_evm/README +++ b/board/ti/ks2_evm/README @@ -81,6 +81,21 @@ To build u-boot-nand.gph make k2hk_evm_defconfig make u-boot-nand.gph +To build u-boot.uart + make k2hk_evm_defconfig + make u-boot.uart + +Load and Run U-Boot on keystone EVMs using UART download + + +Open BMC and regular UART terminals. + +1. On the regular UART port start xmodem transfer of the u-boot.uart +2. Using BMC terminal set the ARM-UART bootmode and reboot the EVM + BMC bootmode #4 + MBC reboot +3. When xmodem is complete you should see the u-boot starts on the UART port + Load and Run U-Boot on keystone EVMs using CCS = Could you please address the comments provided in V1 of your patch first? https://patchwork.ozlabs.org/patch/440322/ I see my comments have not been responded to as to why the alternatives presented do not work. It is always a good practice to respond to review comments prior to posting a new revision and not just ignoring them. Sorry, I have to give a: Nak to this version of patch considering that there are still questions not addressed from V1. -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: nand: omap_gpmc: Make ready/busy pins configurable
Hi Michal, On 17.02.2015 14:52, Michal Sojka wrote: snip + omap_nand_info[cs].ws = ws[cs]; +#endif I've attached a new version of this patch. It removed the ifdef from the code. Please take a look at it and let me know what you think. Yes, it's better and it works for us. Just one point - what about making the variable const as in the patch below? Even better. Please submit it as a regular patch (v2) and my: Acked-by: Stefan Roese s...@denx.de Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-avr32/master - u-boot/master
On Tue, Feb 17, 2015 at 04:48:36PM +0100, Andreas Bießmann wrote: Hi Tom, On 02/17/2015 04:12 PM, Tom Rini wrote: On Mon, Feb 16, 2015 at 09:25:06PM +0100, Andreas Bießmann wrote: Hi Tom, finally generic board support for avr32! The following changes since commit bd2a4888b123713adec271d6c8040ca9f609aa2f: sunxi: configs/sunxi-common.h: Enable CONFIG_CMD_PART (2015-02-11 19:43:45 -0500) are available in the git repository at: git://git.denx.de/u-boot-avr32.git master for you to fetch changes up to 4d3dada78ec402dc51e4198dda316301e0d99f35: atstk1002: enable generic board (2015-02-16 21:21:26 +0100) NAK, sorry. This breaks MIPS: + malta +(malta) common/cmd_bdinfo.c: In function 'do_bdinfo': +(malta) common/cmd_bdinfo.c:328:34: error: 'bd_t' has no member named 'bi_dram' +(malta) common/cmd_bdinfo.c:329:32: error: 'bd_t' has no member named 'bi_dram' +(malta) make[2]: *** [common/cmd_bdinfo.o] Error 1 +(malta) make[1]: *** [common] Error 2 +(malta) make: *** [sub-make] Error 2 Ouch, my fault. The change was misaligned by 14 lines. The MIPS and the AVR32 part looks almost the same in this section. I'll send a fixed PR this evening. Great, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/1] usb: gadget: fastboot: Add fastboot erase
On Tue, Feb 17, 2015 at 5:57 AM, Dileep Katta dileep.ka...@linaro.org
wrote:
On 17 February 2015 at 02:51, Steve Rae s...@broadcom.com wrote:
On 15-02-16 12:40 PM, Dileep Katta wrote:
Hi Steve,
On 14 February 2015 at 02:15, Steve Rae s...@broadcom.com wrote:
On 15-02-12 12:29 AM, Dileep Katta wrote:
Hi Steve,
On 11 February 2015 at 05:25, Steve Rae s...@broadcom.com wrote:
Hi, Dileep
On 15-02-10 12:49 AM, Dileep Katta wrote:
Adds the fastboot erase functionality, to erase a partition
specified by name. The erase is performed based on erase group size,
to avoid erasing other partitions. The start address and the size
is aligned to the erase group size for this.
Currently only supports erasing from eMMC.
Signed-off-by: Dileep Katta dileep.ka...@linaro.org
---
Note: The changes are on top of oem command support added by
r...@kernel.org
common/fb_mmc.c | 58
++
+++
drivers/usb/gadget/f_fastboot.c | 23
include/fb_mmc.h| 1 +
3 files changed, 82 insertions(+)
diff --git a/common/fb_mmc.c b/common/fb_mmc.c
index 6ea3938..3911989 100644
--- a/common/fb_mmc.c
+++ b/common/fb_mmc.c
@@ -10,6 +10,7 @@
#include part.h
#include aboot.h
#include sparse_format.h
+#include mmc.h
#ifndef CONFIG_FASTBOOT_GPT_NAME
#define CONFIG_FASTBOOT_GPT_NAME GPT_ENTRY_NAME
@@ -110,3 +111,60 @@ void fb_mmc_flash_write(const char *cmd, void
*download_buffer,
write_raw_image(dev_desc, info, cmd,
download_buffer,
download_bytes);
}
+
+void fb_mmc_erase(const char *cmd, char *response)
+{
+ int ret;
+ block_dev_desc_t *dev_desc;
+ disk_partition_t info;
+ lbaint_t blks, blks_start, blks_size, grp_size;
+ struct mmc *mmc = find_mmc_device(CONFIG_
FASTBOOT_FLASH_MMC_DEV);
+
+ if (mmc == NULL) {
+ error(invalid mmc device\n);
no newline with error()
Will remove
+ fastboot_fail(invalid mmc device);
+ return;
+ }
+
+ /* initialize the response buffer */
+ response_str = response;
+
+ dev_desc = get_dev(mmc, CONFIG_FASTBOOT_FLASH_MMC_DEV);
+ if (!dev_desc || dev_desc-type == DEV_TYPE_UNKNOWN) {
+ error(invalid mmc device\n);
no newline with error()
Will remove
+ fastboot_fail(invalid mmc device);
+ return;
+ }
+
+ ret = get_partition_info_efi_by_name(dev_desc, cmd, info);
+ if (ret) {
+ error(cannot find partition: '%s'\n, cmd);
no newline with error()
Will remove
+ fastboot_fail(cannot find partition);
+ return;
+ }
+
+ puts(Erasing partition\n);
+
+ /* Align blocks to erase group size to avoid erasing other
partitions */
+ grp_size = mmc-erase_grp_size;
+ blks_start = (info.start + grp_size - 1) ~(grp_size - 1);
+ if (info.size = grp_size)
+ blks_size = (info.size - (blks_start - info.start))
+ (~(grp_size - 1));
+ else
+ blks_size = 0;
Is this logic correct??? Isn't the erase_grp_size in bytes? and the
info.start info.size in LBA's?
Yes, the math will take care of it. Ref: mmc_berase()
So, I have a partition:
2 0x0300 0x03ff test
attrs: 0x
type: 9e312af1-18fe-fa41-45f3-37b3bb1d1061
guid: 18a5d0db-d23a-aac1-0d4c-692c7ba9ab1c
and 'fastboot erase test' produces:
Erasing blocks 1024 to 1024 due to alignment
erased 0 bytes from 'test'
which is not correct!
Furthermore, doesn't the mmc_berase() already handle the
erase_grp_size
It does handle it, in a way, but the way it handles it is to erase more
blocks than requested if the request isn't aligned. In your example, you
requested the test partition to be erased (0x300 to 0x3ff), but what
was
actually erased (as printed in the Caution message from mmc_berase)
was
0x0 to 0x7ff.
If I remove your alignment logic, then it produces:
Erasing blocks 768 to 1024 due to alignment
Caution! Your devices Erase group is 0x400
The erase range would be change to 0x0~0x7ff
erased 131072 bytes from 'test'
which looks correct (except for the Caution message)
Thanks, Steve
Except that this one has now erased 0x0 to 0x300 and 0x400 to 0x7ff
also,
which you did not want to erase, right?
Aligning the start address is meant to protect this data from being
erased
unintentionally. The trade-off is that some small partitions won't get
erased at all, if they are
Re: [U-Boot] [PATCH v2 0/8] Extend LPC32xx functionality and add LPC32xx-based work_92015 board
On Tue, Feb 17, 2015 at 02:26:47PM +0100, Albert ARIBAUD wrote: Bonjour Tom, Le Tue, 17 Feb 2015 08:20:09 -0500, Tom Rini tr...@ti.com a écrit : On Thu, Feb 12, 2015 at 06:36:59PM +0100, Albert ARIBAUD (3ADEV) wrote: This series extends functionality for the LPC32xx platform and introduces the WORK Microwave work_92105 board which makes use of the extended functionality. Along with the work_92105 problem, just dropping that patch results in devkit3250 failing in another way: +(devkit3250) ../arch/arm/cpu/arm926ejs/lpc32xx/devices.c:11:26: fatal error: asm/arch/mux.h: No such file or directory +(devkit3250) #include asm/arch/mux.h +(devkit3250) compilation terminated. +(devkit3250) make[3]: *** [arch/arm/cpu/arm926ejs/lpc32xx/devices.o] Error 1 +(devkit3250) make[2]: *** [arch/arm/cpu/arm926ejs/lpc32xx] Error 2 +(devkit3250) make[1]: *** [arch/arm/cpu/arm926ejs] Error 2 Not that it should matter here but my default toolchain is ELDK 5.5.2 I've just (re-)tried building devkit3250 and it builds fine (apart from the warning that the board should be converted to generic). What commit did you apply the patch series over? There's a handful of things I'm merging shortly but that shouldn't matter, so this is odd. I see Jagan requested a few changes to the SPI stuff so I'll pick up the series after that? Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] mtd: nand: omap_gpmc: Make ready/busy pins configurable
From: Michal Sojka so...@merica.cz
Commit fb384c4720ca7496775d6578f184bf628db73456 introduced the use of
WAIT0 pin for determining whether the NAND is ready or not. This only
works if all NAND chips are connected to WAIT0. If some chips are
connected to the other available pin WAIT1, nand_wait() does not really
wait and prints a WARN_ON message.
This patch allows the board to provide configuration of which chip is
connected to which WAITx signal. For example, one can define in
include/configs/foo.h:
#define CONFIG_NAND_OMAP_GPMC_WSCFG 0,0,1,1
This would mean that chips using to CS0 and 1 are connected to WAIT0 and
chips with CS2 and 3 are connected to WAIT1.
Signed-off-by: Michal Sojka so...@merica.cz
Acked-by: Stefan Roese s...@denx.de
Tested-by: Michal Vokáč michal.vo...@comap.cz
Cc: Tom Rini tr...@ti.com
---
drivers/mtd/nand/omap_gpmc.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c
index fc64f48..8ba6550 100644
--- a/drivers/mtd/nand/omap_gpmc.c
+++ b/drivers/mtd/nand/omap_gpmc.c
@@ -30,13 +30,22 @@ static u8 bch8_polynomial[] = {0xef, 0x51, 0x2e, 0x09,
0xed, 0x93, 0x9a, 0xc2,
static uint8_t cs_next;
static __maybe_unused struct nand_ecclayout omap_ecclayout;
+#if defined(CONFIG_NAND_OMAP_GPMC_WSCFG)
+static const int8_t wscfg[CONFIG_SYS_MAX_NAND_DEVICE] =
+ { CONFIG_NAND_OMAP_GPMC_WSCFG };
+#else
+/* wscfg is preset to zero since its a static variable */
+static const int8_t wscfg[CONFIG_SYS_MAX_NAND_DEVICE];
+#endif
+
/*
* Driver configurations
*/
struct omap_nand_info {
struct bch_control *control;
enum omap_ecc ecc_scheme;
- int cs;
+ uint8_t cs;
+ uint8_t ws; /* wait status pin (0,1) */
};
/* We are wasting a bit of memory but al least we are safe */
@@ -76,7 +85,9 @@ static void omap_nand_hwcontrol(struct mtd_info *mtd, int32_t
cmd,
/* Check wait pin as dev ready indicator */
static int omap_dev_ready(struct mtd_info *mtd)
{
- return gpmc_cfg-status (1 8);
+ register struct nand_chip *this = mtd-priv;
+ struct omap_nand_info *info = this-priv;
+ return gpmc_cfg-status (1 (8 + info-ws));
}
/*
@@ -962,6 +973,7 @@ int board_nand_init(struct nand_chip *nand)
nand-IO_ADDR_W = (void __iomem *)gpmc_cfg-cs[cs].nand_cmd;
omap_nand_info[cs].control = NULL;
omap_nand_info[cs].cs = cs;
+ omap_nand_info[cs].ws = wscfg[cs];
nand-priv = omap_nand_info[cs];
nand-cmd_ctrl = omap_nand_hwcontrol;
nand-options |= NAND_NO_PADDING | NAND_CACHEPRG;
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] mmc: fsl_esdhc: Add support to force VSELECT set
On 2/17/2015 5:36 AM, Otavio Salvador wrote: On Mon, Feb 16, 2015 at 11:38 PM, Troy Kisky troy.ki...@boundarydevices.com wrote: On 2/16/2015 2:38 PM, Otavio Salvador wrote: Some boards cannot do voltage negotiation but need to set the VSELECT bit forcely to ensure it to work at 1.8V. This commit adds CONFIG_SYS_FSL_ESDHC_FORCE_VSELECT flag for this use. Signed-off-by: Otavio Salvador ota...@ossystems.com.br ... What if 1 controller needs it set and another needs it clear? I am not sure it makes much sense to have one in 3V3 and another 1V8. Does it? I guess if the need ever arises it can be changed then. It just seems better to pass this as a flag for the controller now. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot tftp problem
On Fri, Feb 13, 2015 at 8:05 PM, PF4Public pf4pub...@mail.ru wrote: Hi all I'm asking for your help to figure out what interferes with u-boot's tftp in my setup. I have a custom board with TI OMAP SoC. I'm trying to download uImage from linux machine via tftp. It fails with timeouts (most of the tries timeout limit exceeds) on several, but succeeds on others. However any other combination not involving u-boot is flawless. Even when the board in question has booted kernel. Comparing network settings (incl. sysctl) gave no significant difference between serving machines, which run Linux. Are you saying that it is completely consistent that when TFTPing from a specific TFTP server to u-boot you always get these time-outs, but with a different one you never get them? Have you compared the traffic on the wire? Try turning on debug traces in the network stack and compare what it sees to what's on the wire. Perhaps the davinci emac driver is causing you trouble. Is there a cache enabled on your board that you could disable to eliminate the driver's tolerance of a cache? Following tests were taken: u-boot - i686-pae Linux u-boot - i686-pae Linux kvm guest u-boot - x86_64 windows 7 Results are as follows: 1. u-boot - i686-pae Linux Using DaVinci-EMAC device TFTP from server 192.168.100.254; our IP address is 192.168.100.88 Filename 'uImage'. Load address: 0xc070 Loading: T ###T ##T ###T T ## ##T ### ###T ## T # # T # ## 11.7 KiB/s done Bytes transferred = 2418464 (24e720 hex) Corresponding traffic dump can be found here: http://pastebin.com/hBBwe9bL 2. u-boot - i686-pae Linux kvm guest Using DaVinci-EMAC device TFTP from server 192.168.100.112; our IP address is 192.168.100.88 Filename 'uImage'. Load address: 0xc070 Loading: # # # # # # # ## 795.9 KiB/s done Bytes transferred = 2418464 (24e720 hex) Corresponding traffic dump can be found here: http://pastebin.com/ZXYdpmSe 3. u-boot - x86_64 windows 7 Using DaVinci-EMAC device TFTP from server 192.168.100.86; our IP address is 192.168.100.88 Filename 'uImage'. Load address: 0xc070 Loading: # # ### 173.8 KiB/s done Bytes transferred = 2418464 (24e720 hex) Corresponding traffic dump can be found here: http://pastebin.com/UWFEZjTz At this point I have no idea, what could cause timeouts for u-boot and I have no more clues on how to solve this. Any help greatly appreciated. Simply that the packet that the network stack expects has not be received at that level. They could be lost in a number of places. Thanks in advance Best regards ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] Odroid U3: use common code for dram reservation
This commit removes the dram reservation from board file,
because it is done in a common code.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
---
board/samsung/odroid/odroid.c | 4
include/configs/odroid.h | 5 +++--
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/board/samsung/odroid/odroid.c b/board/samsung/odroid/odroid.c
index bff6ac9..44e062b 100644
--- a/board/samsung/odroid/odroid.c
+++ b/board/samsung/odroid/odroid.c
@@ -424,10 +424,6 @@ int exynos_early_init_f(void)
int exynos_init(void)
{
- /* The last MB of memory is reserved for secure firmware */
- gd-ram_size -= SZ_1M;
- gd-bd-bi_dram[CONFIG_NR_DRAM_BANKS - 1].size -= SZ_1M;
-
board_gpio_init();
return 0;
diff --git a/include/configs/odroid.h b/include/configs/odroid.h
index 9d5dbdc..46ec760 100644
--- a/include/configs/odroid.h
+++ b/include/configs/odroid.h
@@ -29,6 +29,9 @@
#define CONFIG_SYS_SDRAM_BASE 0x4000
#define SDRAM_BANK_SIZE(256 20) /* 256 MB */
#define PHYS_SDRAM_1 CONFIG_SYS_SDRAM_BASE
+/* Reserve the last 1 MiB for the secure firmware */
+#define CONFIG_SYS_MEM_TOP_HIDE(1UL 20UL)
+#define CONFIG_TZSW_RESERVED_DRAM_SIZE CONFIG_SYS_MEM_TOP_HIDE
/* memtest works on */
#define CONFIG_SYS_MEMTEST_START CONFIG_SYS_SDRAM_BASE
@@ -56,8 +59,6 @@
#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_LOAD_ADDR \
- GENERATED_GBL_DATA_SIZE)
-#define CONFIG_SYS_MEM_TOP_HIDE(SZ_1M) /* ram console */
-
#define CONFIG_SYS_MONITOR_BASE0x
#define CONFIG_ENV_IS_IN_MMC
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] samsung: board: reserve dram for the secure firmware
Since the few exynos based boards requires memory reservation, of last DRAM bank, the code could be in a common place. This patchset moves the reservation code from odroid board file to common samsung board file. Przemyslaw Marczak (3): board: samsung: reserve memory for the secure firmware Odroid-XU3: enable the last dram bank and reserve 22MiB Odroid U3: use common code for dram reservation board/samsung/common/board.c | 6 ++ board/samsung/odroid/odroid.c | 4 include/configs/odroid.h | 5 +++-- include/configs/odroid_xu3.h | 10 -- 4 files changed, 13 insertions(+), 12 deletions(-) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] apalis/colibri_t30: fix MMC/SD card detect GPIOs
This fixes the MMC/SD card detect GPIOs for Apalis T30 which got broken
by the following commit:
2b2b50bc8748bf1ddb2d96da7157f9eecbe24961
While at it also re-add the comments describing which particular
Apalis/Colibri pins those GPIOs are on.
Signed-off-by: Marcel Ziswiler mar...@ziswiler.com
---
arch/arm/dts/tegra30-apalis.dts | 9 +++--
arch/arm/dts/tegra30-colibri.dts | 4 +++-
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/arm/dts/tegra30-apalis.dts b/arch/arm/dts/tegra30-apalis.dts
index 75c5d5f..13ab42b 100644
--- a/arch/arm/dts/tegra30-apalis.dts
+++ b/arch/arm/dts/tegra30-apalis.dts
@@ -247,13 +247,15 @@
sdhci@7800 {
status = okay;
bus-width = 4;
- cd-gpios = gpio TEGRA_GPIO(CC, 5) GPIO_ACTIVE_HIGH;
+ /* SD1_CD# */
+ cd-gpios = gpio TEGRA_GPIO(CC, 5) GPIO_ACTIVE_LOW;
};
sdhci@78000400 {
status = okay;
bus-width = 8;
- cd-gpios = gpio TEGRA_GPIO(V, 3) GPIO_ACTIVE_HIGH;
+ /* MMC1_CD# */
+ cd-gpios = gpio TEGRA_GPIO(V, 3) GPIO_ACTIVE_LOW;
};
sdhci@78000600 {
@@ -266,12 +268,14 @@
usb@7d00 {
status = okay;
dr_mode = peripheral;
+ /* USBO1_EN */
nvidia,vbus-gpio = gpio TEGRA_GPIO(T, 5) GPIO_ACTIVE_HIGH;
};
/* EHCI instance 1: USB2_DP/N - USBH2_DP/N */
usb@7d004000 {
status = okay;
+ /* USBH_EN */
nvidia,vbus-gpio = gpio TEGRA_GPIO(DD, 1) GPIO_ACTIVE_HIGH;
phy_type = utmi;
};
@@ -279,6 +283,7 @@
/* EHCI instance 2: USB3_DP/N - USBH3_DP/N */
usb@7d008000 {
status = okay;
+ /* USBH_EN */
nvidia,vbus-gpio = gpio TEGRA_GPIO(DD, 1) GPIO_ACTIVE_HIGH;
};
diff --git a/arch/arm/dts/tegra30-colibri.dts b/arch/arm/dts/tegra30-colibri.dts
index 6cd1902..36533dc 100644
--- a/arch/arm/dts/tegra30-colibri.dts
+++ b/arch/arm/dts/tegra30-colibri.dts
@@ -64,7 +64,7 @@
sdhci@78000200 {
status = okay;
bus-width = 4;
- cd-gpios = gpio TEGRA_GPIO(C, 7) GPIO_ACTIVE_LOW;
+ cd-gpios = gpio TEGRA_GPIO(C, 7) GPIO_ACTIVE_LOW; /* MMCD */
};
sdhci@78000600 {
@@ -83,12 +83,14 @@
usb@7d004000 {
status = okay;
phy_type = utmi;
+ /* VBUS_LAN */
nvidia,vbus-gpio = gpio TEGRA_GPIO(DD, 2) GPIO_ACTIVE_HIGH;
};
/* EHCI instance 2: USB3_DP/N - USBH_P/N */
usb@7d008000 {
status = okay;
+ /* USBH_PEN */
nvidia,vbus-gpio = gpio TEGRA_GPIO(W, 2) GPIO_ACTIVE_LOW;
};
};
--
1.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] apalis/colibri_t30: add misc cmds increase buf sizes and max args
In order to work with our downstream U-Boot environment and update scripts add support for the following miscellaneous commands: CONFIG_CMD_SETEXPR CONFIG_FAT_WRITE CONFIG_CMDLINE_EDITING CONFIG_CMD_FS_GENERIC Increase the console I/O and print as well as argument buffer sizes: CONFIG_SYS_CBSIZE CONFIG_SYS_PBSIZE CONFIG_SYS_BARGSIZE Increase the maximum number of arguments allowed: CONFIG_SYS_MAXARGS Signed-off-by: Marcel Ziswiler mar...@ziswiler.com --- include/configs/apalis_t30.h | 21 + include/configs/colibri_t30.h | 26 -- 2 files changed, 45 insertions(+), 2 deletions(-) diff --git a/include/configs/apalis_t30.h b/include/configs/apalis_t30.h index b301f9e..bc87ed7 100644 --- a/include/configs/apalis_t30.h +++ b/include/configs/apalis_t30.h @@ -62,6 +62,27 @@ #define CONFIG_CMD_NET #define CONFIG_CMD_DHCP +/* Miscellaneous commands */ +#define CONFIG_CMD_FS_GENERIC +#define CONFIG_CMD_SETEXPR +#define CONFIG_CMDLINE_EDITING +#define CONFIG_FAT_WRITE + +/* Increase console I/O buffer size */ +#undef CONFIG_SYS_CBSIZE +#define CONFIG_SYS_CBSIZE 1024 + +/* Increase arguments buffer size */ +#undef CONFIG_SYS_BARGSIZE +#define CONFIG_SYS_BARGSIZE CONFIG_SYS_CBSIZE + +/* Increase print buffer size */ +#define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + sizeof(CONFIG_SYS_PROMPT) + 16) + +/* Increase maximum number of arguments */ +#undef CONFIG_SYS_MAXARGS +#define CONFIG_SYS_MAXARGS 32 + #include tegra-common-usb-gadget.h #include tegra-common-post.h diff --git a/include/configs/colibri_t30.h b/include/configs/colibri_t30.h index ce6f23b..10305d9 100644 --- a/include/configs/colibri_t30.h +++ b/include/configs/colibri_t30.h @@ -1,5 +1,5 @@ /* - * Copyright (c) 2013-2014 Stefan Agner + * Copyright (c) 2013-2015 Stefan Agner * * SPDX-License-Identifier:GPL-2.0+ */ @@ -11,10 +11,11 @@ #include tegra30-common.h +/* High-level configuration options */ #define V_PROMPT Colibri T30 # #define CONFIG_TEGRA_BOARD_STRING Toradex Colibri T30 -/* Board-specific config */ +/* Board-specific serial config */ #define CONFIG_SERIAL_MULTI #define CONFIG_TEGRA_ENABLE_UARTA #define CONFIG_SYS_NS16550_COM1NV_PA_APB_UARTA_BASE @@ -54,6 +55,27 @@ #define CONFIG_CMD_NET #define CONFIG_CMD_DHCP +/* Miscellaneous commands */ +#define CONFIG_CMD_FS_GENERIC +#define CONFIG_CMD_SETEXPR +#define CONFIG_CMDLINE_EDITING +#define CONFIG_FAT_WRITE + +/* Increase console I/O buffer size */ +#undef CONFIG_SYS_CBSIZE +#define CONFIG_SYS_CBSIZE 1024 + +/* Increase arguments buffer size */ +#undef CONFIG_SYS_BARGSIZE +#define CONFIG_SYS_BARGSIZE CONFIG_SYS_CBSIZE + +/* Increase print buffer size */ +#define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + sizeof(CONFIG_SYS_PROMPT) + 16) + +/* Increase maximum number of arguments */ +#undef CONFIG_SYS_MAXARGS +#define CONFIG_SYS_MAXARGS 32 + #include tegra-common-usb-gadget.h #include tegra-common-post.h -- 1.9.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-avr32/master - u-boot/master
On Mon, Feb 16, 2015 at 09:25:06PM +0100, Andreas Bießmann wrote: Hi Tom, finally generic board support for avr32! The following changes since commit bd2a4888b123713adec271d6c8040ca9f609aa2f: sunxi: configs/sunxi-common.h: Enable CONFIG_CMD_PART (2015-02-11 19:43:45 -0500) are available in the git repository at: git://git.denx.de/u-boot-avr32.git master for you to fetch changes up to 4d3dada78ec402dc51e4198dda316301e0d99f35: atstk1002: enable generic board (2015-02-16 21:21:26 +0100) NAK, sorry. This breaks MIPS: + malta +(malta) common/cmd_bdinfo.c: In function 'do_bdinfo': +(malta) common/cmd_bdinfo.c:328:34: error: 'bd_t' has no member named 'bi_dram' +(malta) common/cmd_bdinfo.c:329:32: error: 'bd_t' has no member named 'bi_dram' +(malta) make[2]: *** [common/cmd_bdinfo.o] Error 1 +(malta) make[1]: *** [common] Error 2 +(malta) make: *** [sub-make] Error 2 And it bisected down to: 09bf969d927f73b083101fabb77e5130bec3eec1 is the first bad commit commit 09bf969d927f73b083101fabb77e5130bec3eec1 Author: Andreas Bießmann andreas.de...@googlemail.com Date: Fri Feb 6 23:06:48 2015 +0100 avr32: add generic board support Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] board: samsung: reserve memory for the secure firmware
Since more than one board requires memory reservation for the secure firmware, the reservation code can be made in a common code. Now, to reserve some part of the the last bank, board config should define: - CONFIG_TZSW_RESERVED_DRAM - len in bytes - CONFIG_NR_DRAM_BANKS - number of memory banks Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com Cc: Akshay Saraswat aksha...@samsung.com Cc: Hyungwon Hwang human.hw...@samsung.com Cc: Minkyu Kang mk7.k...@samsung.com --- board/samsung/common/board.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c index da2245f..a2123cd 100644 --- a/board/samsung/common/board.c +++ b/board/samsung/common/board.c @@ -82,7 +82,13 @@ int board_init(void) } boot_temp_check(); #endif +#ifdef CONFIG_TZSW_RESERVED_DRAM_SIZE + /* The last few MB of memory can be reserved for secure firmware */ + ulong size = CONFIG_TZSW_RESERVED_DRAM_SIZE; + gd-ram_size -= size; + gd-bd-bi_dram[CONFIG_NR_DRAM_BANKS - 1].size -= size; +#endif return exynos_init(); } -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] Odroid-XU3: enable the last dram bank and reserve 22MiB
This commit enables the last DRAM bank and reserves the last 22 MiB of it, for the secure firmware. Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com Cc: Akshay Saraswat aksha...@samsung.com Cc: Hyungwon Hwang human.hw...@samsung.com Cc: Minkyu Kang mk7.k...@samsung.com --- include/configs/odroid_xu3.h | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/include/configs/odroid_xu3.h b/include/configs/odroid_xu3.h index 9fa8660..c395020 100644 --- a/include/configs/odroid_xu3.h +++ b/include/configs/odroid_xu3.h @@ -25,13 +25,11 @@ #define CONFIG_CMD_MMC -/* - * FIXME: The number of bank is actually 8. But there is no way to reserve the - * last 16 Mib in the last bank now. So I just excluded the last bank - * temporally. - */ -#define CONFIG_NR_DRAM_BANKS 7 +#define CONFIG_NR_DRAM_BANKS 8 #define SDRAM_BANK_SIZE(256UL 20UL) /* 256 MB */ +/* Reserve the last 22 MiB for the secure firmware */ +#define CONFIG_SYS_MEM_TOP_HIDE(22UL 20UL) +#define CONFIG_TZSW_RESERVED_DRAM_SIZE CONFIG_SYS_MEM_TOP_HIDE #define CONFIG_ENV_IS_IN_MMC -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-avr32/master - u-boot/master
Hi Tom, On 02/17/2015 04:12 PM, Tom Rini wrote: On Mon, Feb 16, 2015 at 09:25:06PM +0100, Andreas Bießmann wrote: Hi Tom, finally generic board support for avr32! The following changes since commit bd2a4888b123713adec271d6c8040ca9f609aa2f: sunxi: configs/sunxi-common.h: Enable CONFIG_CMD_PART (2015-02-11 19:43:45 -0500) are available in the git repository at: git://git.denx.de/u-boot-avr32.git master for you to fetch changes up to 4d3dada78ec402dc51e4198dda316301e0d99f35: atstk1002: enable generic board (2015-02-16 21:21:26 +0100) NAK, sorry. This breaks MIPS: + malta +(malta) common/cmd_bdinfo.c: In function 'do_bdinfo': +(malta) common/cmd_bdinfo.c:328:34: error: 'bd_t' has no member named 'bi_dram' +(malta) common/cmd_bdinfo.c:329:32: error: 'bd_t' has no member named 'bi_dram' +(malta) make[2]: *** [common/cmd_bdinfo.o] Error 1 +(malta) make[1]: *** [common] Error 2 +(malta) make: *** [sub-make] Error 2 Ouch, my fault. The change was misaligned by 14 lines. The MIPS and the AVR32 part looks almost the same in this section. I'll send a fixed PR this evening. And it bisected down to: 09bf969d927f73b083101fabb77e5130bec3eec1 is the first bad commit commit 09bf969d927f73b083101fabb77e5130bec3eec1 Author: Andreas Bießmann andreas.de...@googlemail.com Date: Fri Feb 6 23:06:48 2015 +0100 avr32: add generic board support Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/8] Extend LPC32xx functionality and add LPC32xx-based work_92015 board
Bonjour Tom, Le Tue, 17 Feb 2015 08:20:09 -0500, Tom Rini tr...@ti.com a écrit : On Thu, Feb 12, 2015 at 06:36:59PM +0100, Albert ARIBAUD (3ADEV) wrote: This series extends functionality for the LPC32xx platform and introduces the WORK Microwave work_92105 board which makes use of the extended functionality. Along with the work_92105 problem, just dropping that patch results in devkit3250 failing in another way: +(devkit3250) ../arch/arm/cpu/arm926ejs/lpc32xx/devices.c:11:26: fatal error: asm/arch/mux.h: No such file or directory +(devkit3250) #include asm/arch/mux.h +(devkit3250) compilation terminated. +(devkit3250) make[3]: *** [arch/arm/cpu/arm926ejs/lpc32xx/devices.o] Error 1 +(devkit3250) make[2]: *** [arch/arm/cpu/arm926ejs/lpc32xx] Error 2 +(devkit3250) make[1]: *** [arch/arm/cpu/arm926ejs] Error 2 Not that it should matter here but my default toolchain is ELDK 5.5.2 I've just (re-)tried building devkit3250 and it builds fine (apart from the warning that the board should be converted to generic). What commit did you apply the patch series over? [My toolchain is gcc version 4.7.4 (Ubuntu/Linaro 4.7.4-2ubuntu1) but I agree with you that it most probably does not matter.] Cordialement, Albert ARIBAUD 3ADEV ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/8] Extend LPC32xx functionality and add LPC32xx-based work_92015 board
On Thu, Feb 12, 2015 at 06:36:59PM +0100, Albert ARIBAUD (3ADEV) wrote: This series extends functionality for the LPC32xx platform and introduces the WORK Microwave work_92105 board which makes use of the extended functionality. Along with the work_92105 problem, just dropping that patch results in devkit3250 failing in another way: +(devkit3250) ../arch/arm/cpu/arm926ejs/lpc32xx/devices.c:11:26: fatal error: asm/arch/mux.h: No such file or directory +(devkit3250) #include asm/arch/mux.h +(devkit3250) compilation terminated. +(devkit3250) make[3]: *** [arch/arm/cpu/arm926ejs/lpc32xx/devices.o] Error 1 +(devkit3250) make[2]: *** [arch/arm/cpu/arm926ejs/lpc32xx] Error 2 +(devkit3250) make[1]: *** [arch/arm/cpu/arm926ejs] Error 2 Not that it should matter here but my default toolchain is ELDK 5.5.2 -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/4] mmc: fsl_esdhc: Add CMD11 support to switch to 1.8V
This adds support to switch to 1.8V in case CMD11 succeeds.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
Changes in v2:
- Fixed split string (Marek)
drivers/mmc/fsl_esdhc.c | 29 ++---
include/fsl_esdhc.h | 2 ++
include/mmc.h | 1 +
3 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index c55eb28..6a3e147 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -54,19 +54,21 @@ struct fsl_esdhc {
uintfevt; /* Force event register */
uintadmaes; /* ADMA error status register */
uintadsaddr;/* ADMA system address register */
- charreserved2[160]; /* reserved */
+ charreserved2[100]; /* reserved */
+ uintvendorspec; /* Vendor Specific register */
+ charreserved3[59]; /* reserved */
uinthostver;/* Host controller version register */
- charreserved3[4]; /* reserved */
- uintdmaerraddr; /* DMA error address register */
charreserved4[4]; /* reserved */
- uintdmaerrattr; /* DMA error attribute register */
+ uintdmaerraddr; /* DMA error address register */
charreserved5[4]; /* reserved */
+ uintdmaerrattr; /* DMA error attribute register */
+ charreserved6[4]; /* reserved */
uinthostcapblt2;/* Host controller capabilities register 2 */
- charreserved6[8]; /* reserved */
+ charreserved7[8]; /* reserved */
uinttcr;/* Tuning control register */
- charreserved7[28]; /* reserved */
+ charreserved8[28]; /* reserved */
uintsddirctl; /* SD direction control register */
- charreserved8[712]; /* reserved */
+ charreserved9[712]; /* reserved */
uintscr;/* eSDHC control register */
};
@@ -341,6 +343,15 @@ esdhc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd,
struct mmc_data *data)
goto out;
}
+ /* Switch voltage to 1.8V if CMD11 succeeded */
+ if (cmd-cmdidx == SD_CMD_SWITCH_UHS18V) {
+ esdhc_setbits32(regs-vendorspec, ESDHC_VENDORSPEC_VSELECT);
+
+ printf(Run CMD11 1.8V switch\n);
+ /* Sleep for 5 ms - max time for card to switch to 1.8V */
+ udelay(5000);
+ }
+
/* Workaround for ESDHC errata ENGcm03648 */
if (!data (cmd-resp_type MMC_RSP_BUSY)) {
int timeout = 2500;
@@ -413,6 +424,10 @@ out:
while ((esdhc_read32(regs-sysctl) SYSCTL_RSTD))
;
}
+
+ /* If this was CMD11, then notify that power cycle is needed */
+ if (cmd-cmdidx == SD_CMD_SWITCH_UHS18V)
+ printf(CMD11 to switch to 1.8V mode failed, card
requires power cycle.\n);
}
esdhc_write32(regs-irqstat, -1);
diff --git a/include/fsl_esdhc.h b/include/fsl_esdhc.h
index c1b6648..e3d6581 100644
--- a/include/fsl_esdhc.h
+++ b/include/fsl_esdhc.h
@@ -154,6 +154,8 @@
#define ESDHC_HOSTCAPBLT_DMAS 0x0040
#define ESDHC_HOSTCAPBLT_HSS 0x0020
+#define ESDHC_VENDORSPEC_VSELECT 0x0002 /* Use 1.8V */
+
struct fsl_esdhc_cfg {
u32 esdhc_base;
u32 sdhc_clk;
diff --git a/include/mmc.h b/include/mmc.h
index 56d97bb..e4b071e 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -88,6 +88,7 @@
#define SD_CMD_SEND_RELATIVE_ADDR 3
#define SD_CMD_SWITCH_FUNC 6
#define SD_CMD_SEND_IF_COND8
+#define SD_CMD_SWITCH_UHS18V 11
#define SD_CMD_APP_SET_BUS_WIDTH 6
#define SD_CMD_ERASE_WR_BLK_START 32
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,v3,07/12] common/board_f: factor out reserve_stacks
Dear Andreas Devel, Andreas Devel andreas.de...@googlemail.com writes: Introduce arch_reserve_stacks() to tailor gd-start_addr_sp and gd-irq_sp to the architecture needs. Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com Reviewed-by: Simon Glass s...@chromium.org --- Changes in v3: - make arch_reserve_stacks weak and adopt ppc/arm versions Changes in v2: - new since v1 Changes in v1: None arch/arm/lib/Makefile |1 + arch/arm/lib/stack.c | 42 ++ arch/powerpc/lib/Makefile |1 + arch/powerpc/lib/stack.c | 31 +++ common/board_f.c | 44 +--- include/common.h | 18 ++ 6 files changed, 102 insertions(+), 35 deletions(-) create mode 100644 arch/arm/lib/stack.c create mode 100644 arch/powerpc/lib/stack.c applied to u-boot-avr32/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] fs: ext4 write: return file len on success
After rework of the file system API, the size of ext4 write was missed. This causes printing unreliable write size at the end of the file system write operation. Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com Cc: Sjoerd Simons sjoerd.sim...@collabora.co.uk Cc: Lukasz Majewski l.majew...@samsung.com Cc: Simon Glass s...@chromium.org --- fs/ext4/ext4_write.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/ext4/ext4_write.c b/fs/ext4/ext4_write.c index f7c52cc..fbc4c4b 100644 --- a/fs/ext4/ext4_write.c +++ b/fs/ext4/ext4_write.c @@ -1000,10 +1000,13 @@ int ext4_write_file(const char *filename, void *buf, loff_t offset, } ext4fs_close(); + *actwrite = len; + return 0; fail: ext4fs_close(); + *actwrite = 0; return -1; } -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: nand: omap_gpmc: Make ready/busy pins configurable
Hi Stefan,
On Wed, Feb 11 2015, Stefan Roese wrote:
On 10.02.2015 14:21, Michal Sojka wrote:
Commit fb384c4720ca7496775d6578f184bf628db73456 introduced the use of
WAIT0 pin for determining whether the NAND is ready or not. This only
works if all NAND chips are connected to WAIT0. If some chips are
connected to the other available pin WAIT1, nand_wait() does not really
wait and prints a WARN_ON message.
This patch allows the board to provide configuration of which chip is
connected to which WAITx signal. For example, one can define in
include/configs/foo.h:
#define CONFIG_NAND_OMAP_GPMC_WSCFG 0,0,1,1
This would mean that chips using to CS0 and 1 are connected to WAIT0 and
chips with CS2 and 3 are connected to WAIT1.
Signed-off-by: Michal Sojka so...@merica.cz
Cc: Tom Rini tr...@ti.com
Cc: Stefan Roese s...@denx.de
---
drivers/mtd/nand/omap_gpmc.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c
index 459904d..57fc7b9 100644
--- a/drivers/mtd/nand/omap_gpmc.c
+++ b/drivers/mtd/nand/omap_gpmc.c
@@ -36,7 +36,8 @@ static __maybe_unused struct nand_ecclayout omap_ecclayout;
struct omap_nand_info {
struct bch_control *control;
enum omap_ecc ecc_scheme;
-int cs;
+uint8_t cs;
+uint8_t ws; /* wait status pin (0,1) */
};
/* We are wasting a bit of memory but al least we are safe */
@@ -76,7 +77,9 @@ static void omap_nand_hwcontrol(struct mtd_info *mtd,
int32_t cmd,
/* Check wait pin as dev ready indicator */
static int omap_dev_ready(struct mtd_info *mtd)
{
-return gpmc_cfg-status (1 8);
+register struct nand_chip *this = mtd-priv;
+struct omap_nand_info *info = this-priv;
+return gpmc_cfg-status (1 (8 + info-ws));
}
/*
@@ -853,6 +856,12 @@ int board_nand_init(struct nand_chip *nand)
nand-IO_ADDR_W = (void __iomem *)gpmc_cfg-cs[cs].nand_cmd;
omap_nand_info[cs].control = NULL;
omap_nand_info[cs].cs = cs;
+#if !defined(CONFIG_NAND_OMAP_GPMC_WSCFG)
+omap_nand_info[cs].ws = 0;
+#else
+int8_t ws[CONFIG_SYS_MAX_NAND_DEVICE] = { CONFIG_NAND_OMAP_GPMC_WSCFG };
Doesn't this declaration trigger a compilation warning?
Not with gcc-4.8.3 that we use.
+omap_nand_info[cs].ws = ws[cs];
+#endif
I've attached a new version of this patch. It removed the ifdef from the
code. Please take a look at it and let me know what you think.
Yes, it's better and it works for us. Just one point - what about making
the variable const as in the patch below?
Thanks,
-Michal
-8--
Commit fb384c4720ca7496775d6578f184bf628db73456 introduced the use of
WAIT0 pin for determining whether the NAND is ready or not. This only
works if all NAND chips are connected to WAIT0. If some chips are
connected to the other available pin WAIT1, nand_wait() does not really
wait and prints a WARN_ON message.
This patch allows the board to provide configuration of which chip is
connected to which WAITx signal. For example, one can define in
include/configs/foo.h:
#define CONFIG_NAND_OMAP_GPMC_WSCFG 0,0,1,1
This would mean that chips using to CS0 and 1 are connected to WAIT0 and
chips with CS2 and 3 are connected to WAIT1.
Signed-off-by: Michal Sojka so...@merica.cz
Cc: Tom Rini tr...@ti.com
Cc: Stefan Roese s...@denx.de
---
drivers/mtd/nand/omap_gpmc.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c
index 459904d..4f9120d 100644
--- a/drivers/mtd/nand/omap_gpmc.c
+++ b/drivers/mtd/nand/omap_gpmc.c
@@ -30,13 +30,22 @@ static u8 bch8_polynomial[] = {0xef, 0x51, 0x2e, 0x09,
0xed, 0x93, 0x9a, 0xc2,
static uint8_t cs_next;
static __maybe_unused struct nand_ecclayout omap_ecclayout;
+#if defined(CONFIG_NAND_OMAP_GPMC_WSCFG)
+static const int8_t wscfg[CONFIG_SYS_MAX_NAND_DEVICE] =
+ { CONFIG_NAND_OMAP_GPMC_WSCFG };
+#else
+/* wscfg is preset to zero since its a static variable */
+static const int8_t wscfg[CONFIG_SYS_MAX_NAND_DEVICE];
+#endif
+
/*
* Driver configurations
*/
struct omap_nand_info {
struct bch_control *control;
enum omap_ecc ecc_scheme;
- int cs;
+ uint8_t cs;
+ uint8_t ws; /* wait status pin (0,1) */
};
/* We are wasting a bit of memory but al least we are safe */
@@ -76,7 +85,9 @@ static void omap_nand_hwcontrol(struct mtd_info *mtd, int32_t
cmd,
/* Check wait pin as dev ready indicator */
static int omap_dev_ready(struct mtd_info *mtd)
{
- return gpmc_cfg-status (1 8);
+ register struct nand_chip *this = mtd-priv;
+ struct omap_nand_info *info = this-priv;
+ return gpmc_cfg-status (1 (8 + info-ws));
}
/*
@@ -853,6 +864,7 @@ int board_nand_init(struct nand_chip *nand)
nand-IO_ADDR_W = (void __iomem *)gpmc_cfg-cs[cs].nand_cmd;
[U-Boot] [PATCH 3/4] apalis_t30: enable gigabit ethernet via pcie
Now with all the Tegra PCIe and Intel E1000 gigabit Ethernet driver updates being merged actually make use of it. While at it get rid of the USB networking support which now does not make much sense any longer. Signed-off-by: Marcel Ziswiler mar...@ziswiler.com --- include/configs/apalis_t30.h | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/include/configs/apalis_t30.h b/include/configs/apalis_t30.h index 61809fc..b301f9e 100644 --- a/include/configs/apalis_t30.h +++ b/include/configs/apalis_t30.h @@ -1,5 +1,5 @@ /* - * Copyright (c) 2014 Marcel Ziswiler + * Copyright (c) 2014-2015 Marcel Ziswiler * * SPDX-License-Identifier:GPL-2.0+ */ @@ -47,12 +47,8 @@ #define CONFIG_USB_STORAGE #define CONFIG_CMD_USB -/* USB networking support */ -#define CONFIG_USB_HOST_ETHER -#define CONFIG_USB_ETHER_ASIX - /* PCI host support */ -#undef CONFIG_PCI /* just define once Tegra PCIe support got merged */ +#define CONFIG_PCI #define CONFIG_PCI_TEGRA #define CONFIG_PCI_PNP #define CONFIG_CMD_PCI @@ -60,7 +56,7 @@ /* PCI networking support */ #define CONFIG_E1000 -#undef CONFIG_E1000_NO_NVM /* just define once E1000 driver got fixed */ +#define CONFIG_E1000_NO_NVM /* General networking support */ #define CONFIG_CMD_NET -- 1.9.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] dm: tegra: dts: add aliases for spi on apalis_t30
All boards with a SPI interface have a suitable spi alias except Apalis T30. Add these missing aliases just as the following commit did for the others: d2f60f93325ac31f5f30ee94f15b87c89db46aec Signed-off-by: Marcel Ziswiler mar...@ziswiler.com --- arch/arm/dts/tegra30-apalis.dts | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/dts/tegra30-apalis.dts b/arch/arm/dts/tegra30-apalis.dts index 15db0f2..75c5d5f 100644 --- a/arch/arm/dts/tegra30-apalis.dts +++ b/arch/arm/dts/tegra30-apalis.dts @@ -18,6 +18,10 @@ sdhci0 = /sdhci@78000600; sdhci1 = /sdhci@78000400; sdhci2 = /sdhci@7800; + spi0 = /spi@7000d400; + spi1 = /spi@7000dc00; + spi2 = /spi@7000de00; + spi3 = /spi@7000da00; usb0 = /usb@7d00; usb1 = /usb@7d004000; usb2 = /usb@7d008000; -- 1.9.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/4] various fixes for apalis/colibri_t30
The following is a set of various fixes for Toradex Apalis and Colibri T30. Marcel Ziswiler (4): dm: tegra: dts: add aliases for spi on apalis_t30 apalis/colibri_t30: fix MMC/SD card detect GPIOs apalis_t30: enable gigabit ethernet via pcie apalis/colibri_t30: add misc cmds increase buf sizes and max args arch/arm/dts/tegra30-apalis.dts | 13 +++-- arch/arm/dts/tegra30-colibri.dts | 4 +++- include/configs/apalis_t30.h | 31 --- include/configs/colibri_t30.h| 26 -- 4 files changed, 62 insertions(+), 12 deletions(-) -- 1.9.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,v3,10/12] avr32: add generic board support
Dear Andreas Devel, Andreas Devel andreas.de...@googlemail.com writes: Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com --- This version still has the mmu_init_r() in common/board_r. Removing this now is not that easy ... I'd love to get it in as is and change it later to the board_init_f_r() sequence. Changes in v3: - remove unnecessary stack implementation for avr32 - fix bdinfo output Changes in v2: - remove bootparams allocation, provide as extra patch - use the else path in setup_mon_len() - provide arch_reserve_stacks() for avr32 - use the newly introduced dram_init() Changes in v1: - add timer_init in board_r - remove extern declaration of mmu_init_r() arch/avr32/config.mk|3 +++ arch/avr32/cpu/u-boot.lds |2 ++ arch/avr32/include/asm/config.h |1 + arch/avr32/include/asm/u-boot.h |7 +++ arch/avr32/lib/Makefile |2 ++ arch/avr32/lib/interrupts.c |5 + common/board_f.c|2 +- common/board_r.c| 13 ++--- common/cmd_bdinfo.c |4 ++-- include/asm-generic/u-boot.h|4 10 files changed, 37 insertions(+), 6 deletions(-) applied to u-boot-avr32/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: imagetool: Remove INSERT BEFORE from linker script
Hi Tom, Confirmed, Andreas sent the patch and I've tested both versions. The tools still works on Ubuntu host. Kind regards, 2015-02-16 15:12 GMT-02:00 Tom Rini tr...@ti.com: On Mon, Feb 16, 2015 at 11:55:09AM -0500, Tom Rini wrote: On Mon, Feb 16, 2015 at 03:05:45PM +0100, Lukasz Majewski wrote: Not all linkers are able to parse INSERT BEFORE part of the linker script. For example following (rather new) gold one: GNU gold (GNU Binutils for Debian 2.22) 1.11 produces following error: HOSTLD tools/mkenvimage /usr/bin/ld: error: ./tools/imagetool.lds:23:8: syntax error, unexpected STRING /usr/bin/ld: fatal error: unable to parse script file ./tools/imagetool.lds collect2: error: ld returned 1 exit status make[1]: *** [tools/mkenvimage] Error 1 make: *** [tools] Error 2 The problem has already been reported, but no evident solution has been proposed: https://bugzilla.redhat.com/show_bug.cgi?id=927573#c5 Signed-off-by: Lukasz Majewski l.majew...@samsung.com Guilherme, can you please confirm that things still work as expected for you with this patch applied? Thanks! On second thought I'm going to go with the patch that just drops the linker script and I see you tested that one as well, thanks! -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/1] usb: gadget: fastboot: Add fastboot erase
Adds the fastboot erase functionality, to erase a partition
specified by name. The erase is performed based on erase group size,
to avoid erasing other partitions. The start address and the size
is aligned to the erase group size for this.
Currently only supports erasing from eMMC.
Signed-off-by: Dileep Katta dileep.ka...@linaro.org
---
Changes in v2:
- Removed unnecessary newline for error() messages
- Made the command conditional on CONFIG_FASTBOOT_FLASH
- Updated doc/README.android-fastboot to reflect the support
common/fb_mmc.c | 56 +
doc/README.android-fastboot | 5 ++--
drivers/usb/gadget/f_fastboot.c | 25 ++
include/fb_mmc.h| 1 +
4 files changed, 84 insertions(+), 3 deletions(-)
diff --git a/common/fb_mmc.c b/common/fb_mmc.c
index 6ea3938..513b7ab 100644
--- a/common/fb_mmc.c
+++ b/common/fb_mmc.c
@@ -10,6 +10,7 @@
#include part.h
#include aboot.h
#include sparse_format.h
+#include mmc.h
#ifndef CONFIG_FASTBOOT_GPT_NAME
#define CONFIG_FASTBOOT_GPT_NAME GPT_ENTRY_NAME
@@ -110,3 +111,58 @@ void fb_mmc_flash_write(const char *cmd, void
*download_buffer,
write_raw_image(dev_desc, info, cmd, download_buffer,
download_bytes);
}
+
+void fb_mmc_erase(const char *cmd, char *response)
+{
+ int ret;
+ block_dev_desc_t *dev_desc;
+ disk_partition_t info;
+ lbaint_t blks, blks_start, blks_size, grp_size;
+ struct mmc *mmc = find_mmc_device(CONFIG_FASTBOOT_FLASH_MMC_DEV);
+
+ if (mmc == NULL) {
+ error(invalid mmc device);
+ fastboot_fail(invalid mmc device);
+ return;
+ }
+
+ /* initialize the response buffer */
+ response_str = response;
+
+ dev_desc = get_dev(mmc, CONFIG_FASTBOOT_FLASH_MMC_DEV);
+ if (!dev_desc || dev_desc-type == DEV_TYPE_UNKNOWN) {
+ error(invalid mmc device);
+ fastboot_fail(invalid mmc device);
+ return;
+ }
+
+ ret = get_partition_info_efi_by_name(dev_desc, cmd, info);
+ if (ret) {
+ error(cannot find partition: '%s', cmd);
+ fastboot_fail(cannot find partition);
+ return;
+ }
+
+ /* Align blocks to erase group size to avoid erasing other partitions */
+ grp_size = mmc-erase_grp_size;
+ blks_start = (info.start + grp_size - 1) ~(grp_size - 1);
+ if (info.size = grp_size)
+ blks_size = (info.size - (blks_start - info.start))
+ (~(grp_size - 1));
+ else
+ blks_size = 0;
+
+ printf(Erasing blocks LBAFU to LBAFU due to alignment\n,
+ blks_start, blks_start + blks_size);
+
+ blks = dev_desc-block_erase(dev_desc-dev, blks_start, blks_size);
+ if (blks != blks_size) {
+ error(failed erasing from device %d, dev_desc-dev);
+ fastboot_fail(failed erasing from device);
+ return;
+ }
+
+ printf( erased LBAFU bytes from '%s'\n,
+ blks_size * info.blksz, cmd);
+ fastboot_okay();
+}
diff --git a/doc/README.android-fastboot b/doc/README.android-fastboot
index 1677609..5526a43 100644
--- a/doc/README.android-fastboot
+++ b/doc/README.android-fastboot
@@ -6,9 +6,8 @@ Overview
The protocol that is used over USB is described in
README.android-fastboot-protocol in same directory.
-The current implementation does not yet support the erase command or the
-oem format command, and there is minimal support for the flash command;
-it only supports eMMC devices.
+The current implementation is a minimal support of the erase command,the
+oem format command and flash command;it only supports eMMC devices.
Client installation
===
diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
index f7d84bf..6138906 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -535,6 +535,28 @@ static void cb_oem(struct usb_ep *ep, struct usb_request
*req)
}
}
+#ifdef CONFIG_FASTBOOT_FLASH
+static void cb_erase(struct usb_ep *ep, struct usb_request *req)
+{
+ char *cmd = req-buf;
+ char response[RESPONSE_LEN];
+
+ strsep(cmd, :);
+ if (!cmd) {
+ error(missing partition name);
+ fastboot_tx_write_str(FAILmissing partition name);
+ return;
+ }
+
+ strcpy(response, FAILno flash device defined);
+
+#ifdef CONFIG_FASTBOOT_FLASH_MMC_DEV
+ fb_mmc_erase(cmd, response);
+#endif
+ fastboot_tx_write_str(response);
+}
+#endif
+
struct cmd_dispatch_info {
char *cmd;
void (*cb)(struct usb_ep *ep, struct usb_request *req);
@@ -561,6 +583,9 @@ static const struct cmd_dispatch_info cmd_dispatch_info[] =
{
{
.cmd = flash,
Re: [U-Boot] [PATCH 1/2] gunzip: add gzwrite routine for extracting compresed images to block device
On Monday, February 16, 2015 at 06:33:35 PM, Eric Nelson wrote:
Hi Tom and Marek,
On 02/16/2015 10:03 AM, Tom Rini wrote:
On Mon, Feb 16, 2015 at 05:27:59PM +0100, Marek Vasut wrote:
On Monday, February 16, 2015 at 12:16:06 AM, Eric Nelson wrote:
Initial filesystem images are generally highly compressible.
Add a routine gzwrite that allows gzip-compressed images to be
written to block devices.
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
Hi!
Stupid question -- can't you compress the thing in DRAM and then
use fatwrite or ext4write to write it to FS? Or are you really
after writing the data to a raw block device (in which case, you
can use similar commands for raw block devices) ?
I _think_ (and I really hope so otherwise yes, this series needs
more expanation) that was this adds is the ability to {de,}compress
on the
(or explanation ;))
Sometimes words fail. I thought that was clear from the commit
message but apparently not.
fly rather than need to duplicate in DDR which could be
hard-to-impossible depending on the size of the data in question.
That's exactly right.
The purpose of this is to aid in loading images onto storage devices
like eMMC where the storage size usually exceeds the size of RAM,
but the compressed image size doesn't.
Even if the compressed image size does exceed RAM, the gzwrite
routine and command give you the ability to do things piecewise,
and save lots of read transfer time.
To give a quick concrete example, we were looking at programming a
relatively small (100's) batch of boards that use a very light
O/S, but have 4GiB of eMMC.
Using ums takes over 25 minutes per board, but loading board.img.gz
and using gzwrite takes 5-6, which is pretty close to optimal given
the speed of the eMMC chip.
My hope is that this is useful as is, and also that the gzwrite
routine can be worked into the fastboot protocol.
Transferring gigabytes of data is slow over USB 2.0 and storage
sizes keep getting bigger.
Cool, thanks for explaining :)
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 4/6] 83xx/km83xx: read the IVM eeprom earlier
On Tue, Feb 10, 2015 at 05:10:16PM +0100, Valentin Longchamp wrote: This allows to define the ethaddr env variable according to the the IVM content by reading the IVM in misc_init_r. Later, when HUSH is available the content read earlier is analyzed to populate some non env variables. Signed-off-by: Valentin Longchamp valentin.longch...@keymile.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 5/6] 82xx/km82xx: read the IVM eeprom earlier
On Tue, Feb 10, 2015 at 05:10:17PM +0100, Valentin Longchamp wrote: This allows to define the ethaddr env variable according to the the IVM content by reading the IVM in misc_init_r. Later, when HUSH is available the content read earlier is analyzed to populate some non env variables. Signed-off-by: Valentin Longchamp valentin.longch...@keymile.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] net: keystone_net: move serdes setup to initialization function
On Wed, Feb 11, 2015 at 02:05:41PM -0500, Vitaly Andrianov wrote: On Keystone2 devices serdes must be initialized before accessing MDIO bus. This commit moves the keystone2_net_serdes_setup() from keystone2_eth_open to keystone2_emac_initialize to meet that requirement. This also eliminates unnecessary serdes initializatin every time when the keystone2_eth_open is being called. Signed-off-by: Vitaly Andrianov vita...@ti.com Acked-by: Joe Hershberger joe.hershber...@ni.com Tested-by: Nishanth Menon n...@ti.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 2/6] kirkwood/km_arm: read the IVM eeprom earlier
On Tue, Feb 10, 2015 at 05:10:14PM +0100, Valentin Longchamp wrote: This allows to define the ethaddr env variable according to the the IVM content by reading the IVM in misc_init_r. Later, when HUSH is available the content read earlier is analyzed to populate some non env variables. Signed-off-by: Valentin Longchamp valentin.longch...@keymile.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 3/6] 85xx/kmp204x: read the IVM eeprom earlier
On Tue, Feb 10, 2015 at 05:10:15PM +0100, Valentin Longchamp wrote: This allows to define the ethaddr env variable according to the the IVM content by reading the IVM in misc_init_r. Later, when HUSH is available the content read earlier is analyzed to populate some non env variables. Signed-off-by: Valentin Longchamp valentin.longch...@keymile.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] mmc: fsl_esdhc: Add support to force VSELECT set
On Tuesday, February 17, 2015 at 06:18:31 PM, Troy Kisky wrote: On 2/17/2015 5:36 AM, Otavio Salvador wrote: On Mon, Feb 16, 2015 at 11:38 PM, Troy Kisky troy.ki...@boundarydevices.com wrote: On 2/16/2015 2:38 PM, Otavio Salvador wrote: Some boards cannot do voltage negotiation but need to set the VSELECT bit forcely to ensure it to work at 1.8V. This commit adds CONFIG_SYS_FSL_ESDHC_FORCE_VSELECT flag for this use. Signed-off-by: Otavio Salvador ota...@ossystems.com.br ... What if 1 controller needs it set and another needs it clear? I am not sure it makes much sense to have one in 3V3 and another 1V8. Does it? I guess if the need ever arises it can be changed then. It just seems better to pass this as a flag for the controller now. Or even make it configurable via DT . Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PULL] u-boot-socfpga/master
Hi Tom,
SoCFPGA stuff for current release.
The following changes since commit 7f641d53bbb3a426a3bfb132d8346153e86a9d08:
Merge branch 'master' of git://git.denx.de/u-boot-ubi (2015-02-04 13:30:00
-0500)
are available in the git repository at:
git://git.denx.de/u-boot-socfpga.git HEAD
for you to fetch changes up to 6da3e0c1758f7316025e342ef0801efba9bd7f23:
dt: socfpga: Import and enable Arria V DK DTS (2015-02-09 20:10:22 +0100)
Marek Vasut (10):
arm: socfpga: Minor coding style fix
arm: socfpga: Sync Cyclone V DK pinmux configuration
arm: socfpga: Sync Cyclone V DK PLL configuration
arm: socfpga: Add USB and UDC support for Cyclone V DK
arm: socfpga: Drop cyclone5 suffix from board file name
arm: socfpga: Zap checkboard()
arm: socfpga: Zap board_early_init_f()
arm: socfpga: Add Altera Arria V DK support
dt: socfpga: Import and enable Cyclone V DK DTS
dt: socfpga: Import and enable Arria V DK DTS
arch/arm/Kconfig | 5 +
arch/arm/dts/Makefile | 5 +-
arch/arm/dts/socfpga_arria5.dtsi | 34 +
arch/arm/dts/socfpga_arria5_socdk.dts | 74 +
arch/arm/dts/socfpga_cyclone5_socdk.dts| 79 ++
board/altera/socfpga/Kconfig | 16 ++
board/altera/socfpga/Makefile | 2 +-
board/altera/socfpga/iocsr_config.c| 688
+++
board/altera/socfpga/iocsr_config.h| 17 ++-
board/altera/socfpga/pinmux_config.c | 403
+
board/altera/socfpga/pinmux_config.h | 14 +-
board/altera/socfpga/pll_config.h | 34 ++---
board/altera/socfpga/{socfpga_cyclone5.c = socfpga.c} | 17 ---
configs/socfpga_arria5_defconfig | 5 +
configs/socfpga_cyclone5_defconfig | 2 +
include/configs/socfpga_arria5.h | 107 +
include/configs/socfpga_common.h | 3 +-
include/configs/socfpga_cyclone5.h | 9 ++
18 files changed, 1365 insertions(+), 149 deletions(-)
create mode 100644 arch/arm/dts/socfpga_arria5.dtsi
create mode 100644 arch/arm/dts/socfpga_arria5_socdk.dts
create mode 100644 arch/arm/dts/socfpga_cyclone5_socdk.dts
rename board/altera/socfpga/{socfpga_cyclone5.c = socfpga.c} (86%)
create mode 100644 configs/socfpga_arria5_defconfig
create mode 100644 include/configs/socfpga_arria5.h
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] mmc: fsl_esdhc: Add support to force VSELECT set
On Tue, Feb 17, 2015 at 5:43 PM, Marek Vasut ma...@denx.de wrote: On Tuesday, February 17, 2015 at 06:18:31 PM, Troy Kisky wrote: On 2/17/2015 5:36 AM, Otavio Salvador wrote: On Mon, Feb 16, 2015 at 11:38 PM, Troy Kisky troy.ki...@boundarydevices.com wrote: On 2/16/2015 2:38 PM, Otavio Salvador wrote: Some boards cannot do voltage negotiation but need to set the VSELECT bit forcely to ensure it to work at 1.8V. This commit adds CONFIG_SYS_FSL_ESDHC_FORCE_VSELECT flag for this use. Signed-off-by: Otavio Salvador ota...@ossystems.com.br ... What if 1 controller needs it set and another needs it clear? I am not sure it makes much sense to have one in 3V3 and another 1V8. Does it? I guess if the need ever arises it can be changed then. It just seems better to pass this as a flag for the controller now. Or even make it configurable via DT . Could this be changed later? -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2] PCI: add 64-bit prefetchable memory support
On Mon, Feb 02, 2015 at 04:53:13PM +0800, feng...@phytium.com.cn wrote: From: David Feng feng...@phytium.com.cn PCI specification allow prefetchable memory to be 32-bit or 64-bit. PCI express specification states that all memmory bars for prefetchable memory must be implemented as 64-bit. They all require that 64 bit prefetchble memory are suported especially when u-boot is ported to more and more 64bit processors. Signed-off-by: David Feng feng...@phytium.com.cn Reviewed-by: Bin Meng bmeng...@gmail.com Applied to u-boot/master (and re-worded to drop changelog), 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] [ANN] U-Boot v2015.01-rc2 released
Hey all, I've pushed v2015.01-rc2 out. Due to a hiccup (that is being worked on right now), things aren't up in the usual place yet but I expect them to be in the next day or so. Until then, it's also available at https://github.com/u-boot/u-boot (but please don't start updating distro recipes to point there instead, that is a mirror of the regular site and I'm not moving us there by default right now). I'm a day late pushing this out but that's my fault for picking up some stuff at the last minute and then having to bisect a few issues, but we're close enough to on schedule that we can keep going with 2 weeks on Mondays. I'm still seeing a few boards fail to link that weren't linking at -rc1 time so I'm going to post the patches to drop them. In terms of big removal patches, now that -rc2 is out I'm going to take what Masahiro has posted and that didn't cause people to speak up and claim / fix the boards and then I'd like to see the re-org the directories patch again, unless people think that's a bad idea right now. Finally, the DM + SPL changes do need to come in, whatever still isn't, and we'll sort things out. I think that means Albert needs to ack a few changes tho, yes? As always, if anything is broken please speak up. Thanks all! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] dm: tegra: dts: add aliases for spi on apalis_t30
On 02/17/2015 07:28 AM, Marcel Ziswiler wrote: All boards with a SPI interface have a suitable spi alias except Apalis T30. Add these missing aliases just as the following commit did for the others: d2f60f93325ac31f5f30ee94f15b87c89db46aec You probably don't need to respin like this, but it's a good idea to include the commit subject too, so it can be found in other branches/... that have cherry-picked it. In this case: d2f60f93325a dm: tegra: dts: Add aliases for spi on tegra30 boards ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] apalis/colibri_t30: add misc cmds increase buf sizes and max args
On 02/17/2015 07:28 AM, Marcel Ziswiler wrote: In order to work with our downstream U-Boot environment and update scripts add support for the following miscellaneous commands: CONFIG_CMD_SETEXPR CONFIG_FAT_WRITE CONFIG_CMDLINE_EDITING README isn't very informative on this subject. What does this add? I can already up-arrow and edit command-lines on all Tegra devices. If it's not that big, I wonder if enabling it for all Tegra would make sense? CONFIG_CMD_FS_GENERIC Isn't that already set as part of the generic distro boot support? include/config_distro_defaults.h:#define CONFIG_CMD_FS_GENERIC ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] mmc: fsl_esdhc: Add CMD11 support to switch to 1.8V
On Tuesday, February 17, 2015 at 01:42:43 PM, Otavio Salvador wrote:
This adds support to switch to 1.8V in case CMD11 succeeds.
Signed-off-by: Otavio Salvador ota...@ossystems.com.br
---
Changes in v2:
- Fixed split string (Marek)
drivers/mmc/fsl_esdhc.c | 29 ++---
include/fsl_esdhc.h | 2 ++
include/mmc.h | 1 +
3 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index c55eb28..6a3e147 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -54,19 +54,21 @@ struct fsl_esdhc {
uintfevt; /* Force event register */
uintadmaes; /* ADMA error status register */
uintadsaddr;/* ADMA system address register */
- charreserved2[160]; /* reserved */
+ charreserved2[100]; /* reserved */
+ uintvendorspec; /* Vendor Specific register */
+ charreserved3[59]; /* reserved */
uinthostver;/* Host controller version register */
- charreserved3[4]; /* reserved */
- uintdmaerraddr; /* DMA error address register */
charreserved4[4]; /* reserved */
- uintdmaerrattr; /* DMA error attribute register */
+ uintdmaerraddr; /* DMA error address register */
charreserved5[4]; /* reserved */
+ uintdmaerrattr; /* DMA error attribute register */
+ charreserved6[4]; /* reserved */
uinthostcapblt2;/* Host controller capabilities register 2 */
- charreserved6[8]; /* reserved */
+ charreserved7[8]; /* reserved */
uinttcr;/* Tuning control register */
- charreserved7[28]; /* reserved */
+ charreserved8[28]; /* reserved */
uintsddirctl; /* SD direction control register */
- charreserved8[712]; /* reserved */
+ charreserved9[712]; /* reserved */
uintscr;/* eSDHC control register */
};
@@ -341,6 +343,15 @@ esdhc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd,
struct mmc_data *data) goto out;
}
+ /* Switch voltage to 1.8V if CMD11 succeeded */
+ if (cmd-cmdidx == SD_CMD_SWITCH_UHS18V) {
+ esdhc_setbits32(regs-vendorspec, ESDHC_VENDORSPEC_VSELECT);
+
+ printf(Run CMD11 1.8V switch\n);
+ /* Sleep for 5 ms - max time for card to switch to 1.8V */
+ udelay(5000);
+ }
+
/* Workaround for ESDHC errata ENGcm03648 */
if (!data (cmd-resp_type MMC_RSP_BUSY)) {
int timeout = 2500;
@@ -413,6 +424,10 @@ out:
while ((esdhc_read32(regs-sysctl) SYSCTL_RSTD))
;
This endless loop could use fixing ... anyone ?
}
+
+ /* If this was CMD11, then notify that power cycle is needed */
+ if (cmd-cmdidx == SD_CMD_SWITCH_UHS18V)
+ printf(CMD11 to switch to 1.8V mode failed, card
requires power
cycle.\n); }
esdhc_write32(regs-irqstat, -1);
Reviewed-by: Marek Vasut ma...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 3/3] rpi: add support for Raspberry Pi 2 model B
On Tue, Feb 17, 2015 at 12:35:41PM -0700, Stephen Warren wrote: On 02/16/2015 06:03 PM, Tom Rini wrote: On Mon, Feb 16, 2015 at 12:16:15PM -0700, Stephen Warren wrote: USB doesn't seem to work yet; the controller detects the on-board Hub/ Ethernet device but can't read the descriptors from it. I haven't investigated yet. Signed-off-by: Stephen Warren swar...@wwwdotorg.org --- v3: Rebased on top of u-boot-dm merge. v2: Implement new board_rev decoding scheme, to avoid hard-coding the board revision onthe RPi 2. +(rpi_2) make[3]: *** No rule to make target `arch/arm/cpu/armv7/bcm2835/../../arm1176/bcm2835//init.o', needed by `arch/arm/cpu/armv7/bcm2835/built-in.o'. Stop. +(rpi_2) make[2]: *** [arch/arm/cpu/armv7/bcm2835] Error 2 +(rpi_2) make[1]: *** [arch/arm/cpu/armv7] Error 2 When I try and build it with buildman. Something get left out somewhere? Thanks! I've reproduced this error on my machine at work, where I previously worked out the right stuff to put into ~/.buildman. Now that I try the regular build process (in-tree build using just make) multiple times after a git clean -f -d -x , I see the same error that way too, sometimes, so it's nothing to do with buildman. However, I don't always get the error with either plain make or with buildman, and it doesn't always complain about the same file: +make[1]: *** No rule to make target `arch//cpu/u-boot.lds', needed by `u-boot.lds'. Stop. +make[3]: *** No rule to make target `arch/arm/cpu/armv7/bcm2835/../../arm1176/bcm2835//init.o', needed by `arch/arm/cpu/armv7/bcm2835/built-in.o'. Stop. This isn't anything to do with these patches; I can see the exact same issue building the following existing boards in unmodified u-boot/master: rpi (arm1176, no SPL) tnetv107x_evm_defconfigs (arm1176 no SPL) mx35pdk_defconfig (arm1136, no SPL) nhk8815_defconfig (arm926ejs, no SPL) imx27lite_defconfig (arm926ejs, SPL) vexpress_ca15_tc2_defconfig (ARMv7, no SPL) Strangely I don't see the issue for: seaboard (ARMv7, SPL) maxbcm_defconfig (ARMv7, SPL) I wonder if bisecting would show up where this issue was introduced. I bet it will and I bet it's when we switch to Kconfig. Masahiro, any ideas? -- 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] keystone2: ddr3: eliminate using global ddr3_size variable
On Wed, Feb 11, 2015 at 02:07:58PM -0500, Vitaly Andrianov wrote: KS2 ddr3 initialization uses ddr3_size global variable before u-boot relocation. Even if the variable is not being used after relocation, writing to it corrupts relocation table. This patch removes the global ddr3_size variable and uses local one instead. Signed-off-by: Vitaly Andrianov vita...@ti.com Tested-by: Nishanth Menon n...@ti.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/3] ARM: DRA72x: DDR3: Fix EMIF timings for 666MHz clock
On Mon, Feb 16, 2015 at 10:15:55AM +0530, Lokesh Vutla wrote: From: Angela Stegmaier angelaba...@ti.com DDR3 timing and latency paramenters were not configured correctly for 666MHz. Fixing the timing and latency values according to Data sheet. This fixes the random crashes seen on DRA72-evm. Signed-off-by: Angela Stegmaier angelaba...@ti.com Signed-off-by: Lokesh Vutla lokeshvu...@ti.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 1/2] gunzip: add gzwrite routine for extracting compresed images to block device
Initial filesystem images are generally highly compressible.
Add a routine gzwrite that allows gzip-compressed images to be
written to block devices.
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
V2 removes floating point references from u64 division
include/common.h | 39 +++
lib/gunzip.c | 195 ++-
2 files changed, 233 insertions(+), 1 deletion(-)
diff --git a/include/common.h b/include/common.h
index 9129454..f96baea 100644
--- a/include/common.h
+++ b/include/common.h
@@ -713,6 +713,45 @@ int gunzip(void *, int, unsigned char *, unsigned long *);
int zunzip(void *dst, int dstlen, unsigned char *src, unsigned long *lenp,
int stoponerr, int offset);
+/**
+ * gzwrite progress indicators: defined weak to allow board-specific
+ * overrides:
+ *
+ * gzwrite_progress_init called on startup
+ * gzwrite_progress called during decompress/write loop
+ * gzwrite_progress_finish called at end of loop to
+ * indicate success (retcode=0) or failure
+ */
+void gzwrite_progress_init(u64 expected_size);
+
+void gzwrite_progress(int iteration,
+u64 bytes_written,
+u64 total_bytes);
+
+void gzwrite_progress_finish(int retcode,
+u64 totalwritten,
+u64 totalsize,
+u32 expected_crc,
+u32 calculated_crc);
+
+/**
+ * decompress and write gzipped image from memory to block device
+ *
+ * @param src compressed image address
+ * @param len compressed image length in bytes
+ * @param dev block device descriptor
+ * @param szwritebuf bytes per write (pad to erase size)
+ * @param startoffs offset in bytes of first write
+ * @param szexpected expected uncompressed length
+ * may be zero to use gzip trailer
+ * for files under 4GiB
+ */
+int gzwrite(unsigned char *src, int len,
+ struct block_dev_desc *dev,
+ unsigned long szwritebuf,
+ u64 startoffs,
+ u64 szexpected);
+
/* lib/qsort.c */
void qsort(void *base, size_t nmemb, size_t size,
int(*compar)(const void *, const void *));
diff --git a/lib/gunzip.c b/lib/gunzip.c
index f469fcb..4128a18 100644
--- a/lib/gunzip.c
+++ b/lib/gunzip.c
@@ -11,7 +11,10 @@
#include image.h
#include malloc.h
#include u-boot/zlib.h
+#include div64.h
+#define HEADER0'\x1f'
+#define HEADER1'\x8b'
#defineZALLOC_ALIGNMENT16
#define HEAD_CRC 2
#define EXTRA_FIELD4
@@ -66,6 +69,196 @@ int gunzip(void *dst, int dstlen, unsigned char *src,
unsigned long *lenp)
return zunzip(dst, dstlen, src, lenp, 1, i);
}
+__weak
+void gzwrite_progress_init(u64 expectedsize)
+{
+ putc('\n');
+}
+
+__weak
+void gzwrite_progress(int iteration,
+u64 bytes_written,
+u64 total_bytes)
+{
+ if (0 == (iteration 3))
+ printf(%llu/%llu\r, bytes_written, total_bytes);
+}
+
+__weak
+void gzwrite_progress_finish(int returnval,
+u64 bytes_written,
+u64 total_bytes,
+u32 expected_crc,
+u32 calculated_crc)
+{
+ if (0 == returnval) {
+ printf(\n\t%llu bytes, crc 0x%08x\n,
+ total_bytes, calculated_crc);
+ } else {
+ printf(\n\tuncompressed %llu of %llu\n
+ \tcrcs == 0x%08x/0x%08x\n,
+ bytes_written, total_bytes,
+ expected_crc, calculated_crc);
+ }
+}
+
+int gzwrite(unsigned char *src, int len,
+ struct block_dev_desc *dev,
+ unsigned long szwritebuf,
+ u64 startoffs,
+ u64 szexpected)
+{
+ int i, flags;
+ z_stream s;
+ int r = 0;
+ unsigned char *writebuf;
+ unsigned crc = 0;
+ u64 totalfilled = 0;
+ lbaint_t blksperbuf, outblock;
+ u32 expected_crc;
+ u32 payload_size;
+ int iteration = 0;
+
+ if (!szwritebuf ||
+ (szwritebuf % dev-blksz) ||
+ (szwritebuf dev-blksz)) {
+ printf(%s: size %lu not a multiple of %lu\n,
+ __func__, szwritebuf, dev-blksz);
+ return -1;
+ }
+
+ if (startoffs (dev-blksz-1)) {
+ printf(%s: start offset %llu not a multiple of %lu\n,
+ __func__, startoffs, dev-blksz);
+ return -1;
+ }
+
+ blksperbuf = szwritebuf / dev-blksz;
+ outblock = lldiv(startoffs, dev-blksz);
+
+ /* skip header */
+ i = 10;
+ flags = src[3];
+ if (src[2] !=
[U-Boot] [PATCH 2/2] ARM: tegra: import latest Jetson TK1 pinmux
From: Stephen Warren swar...@nvidia.com
Syseng has revamped the Jetson TK1 pinmux spreadsheet, basing the content
completely on correct configuration for the board/schematic, rather than
the previous version which was based on the bare minimum changes relative
to another reference board.
The new spreadsheet sets TRISTATE for any input-only pins. This only works
correctly if the global CLAMP bit is not set, so the Jetson TK1 board code
has been adjusted accordingly. Apparently syseng have changed their mind
since the previous advice that this needed to be set:-/
This content comes from Jetson_TK1_customer_pinmux.xlsm (v09) downloaded
from https://developer.nvidia.com/hardware-design-and-development.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
board/nvidia/jetson-tk1/jetson-tk1.c | 2 +-
board/nvidia/jetson-tk1/pinmux-config-jetson-tk1.h | 303 +
2 files changed, 136 insertions(+), 169 deletions(-)
diff --git a/board/nvidia/jetson-tk1/jetson-tk1.c
b/board/nvidia/jetson-tk1/jetson-tk1.c
index daa74a4be02f..52425a8f6dea 100644
--- a/board/nvidia/jetson-tk1/jetson-tk1.c
+++ b/board/nvidia/jetson-tk1/jetson-tk1.c
@@ -22,7 +22,7 @@ DECLARE_GLOBAL_DATA_PTR;
*/
void pinmux_init(void)
{
- pinmux_set_tristate_input_clamping();
+ pinmux_clear_tristate_input_clamping();
gpio_config_table(jetson_tk1_gpio_inits,
ARRAY_SIZE(jetson_tk1_gpio_inits));
diff --git a/board/nvidia/jetson-tk1/pinmux-config-jetson-tk1.h
b/board/nvidia/jetson-tk1/pinmux-config-jetson-tk1.h
index de4eb355982c..863721b2a330 100644
--- a/board/nvidia/jetson-tk1/pinmux-config-jetson-tk1.h
+++ b/board/nvidia/jetson-tk1/pinmux-config-jetson-tk1.h
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2014, NVIDIA CORPORATION. All rights reserved.
+ * Copyright (c) 2015, NVIDIA CORPORATION. All rights reserved.
*
* SPDX-License-Identifier: GPL-2.0+
*/
@@ -15,77 +15,47 @@
static const struct tegra_gpio_config jetson_tk1_gpio_inits[] = {
/*gpio, init_val */
- GPIO_INIT(C7, IN),
- GPIO_INIT(G0, OUT0),
- GPIO_INIT(G1, OUT0),
+ GPIO_INIT(G0, IN),
+ GPIO_INIT(G1, IN),
GPIO_INIT(G2, IN),
GPIO_INIT(G3, IN),
+ GPIO_INIT(G4, IN),
GPIO_INIT(H2, OUT0),
- GPIO_INIT(H3, OUT0),
GPIO_INIT(H4, IN),
- GPIO_INIT(H5, OUT0),
- GPIO_INIT(H6, IN),
- GPIO_INIT(H7, OUT0),
+ GPIO_INIT(H7, IN),
GPIO_INIT(I0, OUT0),
- GPIO_INIT(I2, OUT0),
- GPIO_INIT(I4, OUT0),
- GPIO_INIT(I5, IN),
+ GPIO_INIT(I1, IN),
GPIO_INIT(I6, IN),
GPIO_INIT(J0, IN),
- GPIO_INIT(J2, IN),
GPIO_INIT(K1, OUT0),
GPIO_INIT(K2, IN),
- GPIO_INIT(K3, IN),
GPIO_INIT(K4, OUT0),
- GPIO_INIT(K5, OUT0),
GPIO_INIT(K6, OUT0),
GPIO_INIT(N7, IN),
- GPIO_INIT(O0, IN),
GPIO_INIT(O1, IN),
- GPIO_INIT(O2, IN),
- GPIO_INIT(O3, IN),
GPIO_INIT(O4, IN),
- GPIO_INIT(O5, IN),
- GPIO_INIT(O6, OUT0),
- GPIO_INIT(O7, IN),
- GPIO_INIT(P0, OUT0),
- GPIO_INIT(P1, OUT0),
GPIO_INIT(P2, OUT0),
GPIO_INIT(Q0, IN),
- GPIO_INIT(Q1, IN),
- GPIO_INIT(Q2, IN),
+ GPIO_INIT(Q3, IN),
GPIO_INIT(Q5, IN),
- GPIO_INIT(Q6, IN),
- GPIO_INIT(Q7, IN),
GPIO_INIT(R0, OUT0),
- GPIO_INIT(R1, OUT0),
GPIO_INIT(R2, OUT0),
GPIO_INIT(R4, IN),
- GPIO_INIT(R5, OUT0),
GPIO_INIT(R7, IN),
- GPIO_INIT(S0, IN),
- GPIO_INIT(S3, OUT0),
- GPIO_INIT(S4, OUT0),
- GPIO_INIT(S5, IN),
- GPIO_INIT(S6, OUT0),
+ GPIO_INIT(S7, IN),
GPIO_INIT(T0, OUT0),
- GPIO_INIT(T1, OUT0),
- GPIO_INIT(U0, OUT0),
+ GPIO_INIT(T1, IN),
+ GPIO_INIT(U0, IN),
GPIO_INIT(U1, IN),
GPIO_INIT(U2, IN),
- GPIO_INIT(U3, OUT0),
- GPIO_INIT(U4, OUT0),
+ GPIO_INIT(U3, IN),
+ GPIO_INIT(U4, IN),
GPIO_INIT(U5, IN),
GPIO_INIT(U6, IN),
GPIO_INIT(V0, IN),
GPIO_INIT(V1, IN),
- GPIO_INIT(W2, IN),
- GPIO_INIT(W3, IN),
- GPIO_INIT(X1, OUT0),
- GPIO_INIT(X3, IN),
- GPIO_INIT(X4, OUT0),
- GPIO_INIT(X5, IN),
- GPIO_INIT(X6, IN),
+ GPIO_INIT(X1, IN),
+ GPIO_INIT(X4, IN),
GPIO_INIT(X7, OUT0),
GPIO_INIT(BB3, OUT0),
GPIO_INIT(BB5, OUT0),
@@ -93,10 +63,7 @@ static const struct tegra_gpio_config
jetson_tk1_gpio_inits[] = {
GPIO_INIT(BB7, OUT0),
GPIO_INIT(CC1, IN),
GPIO_INIT(CC2, IN),
- GPIO_INIT(CC5, OUT0),
- GPIO_INIT(EE1, OUT0),
- GPIO_INIT(FF1, OUT0),
- GPIO_INIT(FF2, IN),
+ GPIO_INIT(EE2, OUT1),
};
#define
Re: [U-Boot] [PATCH] add example for file on VFAT filesystem usage
On Mon, Feb 16, 2015 at 05:59:09AM +0100, Waldemar Brodkorb wrote: For example on a raspberry pi the u-boot environment can be saved in a file on the first VFAT partition. This example illustrates how to use it with fw_printenv/fw_setenv. Signed-off-by: Waldemar Brodkorb w...@openadk.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] ARM: tegra: add function to clear pinmux CLAMPING bit
From: Stephen Warren swar...@nvidia.com
This is needed to correctly apply the new Jetson TK1 pinmux config.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
arch/arm/cpu/tegra-common/pinmux-common.c | 10 ++
arch/arm/include/asm/arch-tegra/pinmux.h | 3 ++-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/tegra-common/pinmux-common.c
b/arch/arm/cpu/tegra-common/pinmux-common.c
index 6e3ab0c14ca2..692de7629b9b 100644
--- a/arch/arm/cpu/tegra-common/pinmux-common.c
+++ b/arch/arm/cpu/tegra-common/pinmux-common.c
@@ -100,6 +100,16 @@ void pinmux_set_tristate_input_clamping(void)
val |= CLAMP_INPUTS_WHEN_TRISTATED;
writel(val, reg);
}
+
+void pinmux_clear_tristate_input_clamping(void)
+{
+ u32 *reg = _R(APB_MISC_PP_PINMUX_GLOBAL_0);
+ u32 val;
+
+ val = readl(reg);
+ val = ~CLAMP_INPUTS_WHEN_TRISTATED;
+ writel(val, reg);
+}
#endif
void pinmux_set_func(enum pmux_pingrp pin, enum pmux_func func)
diff --git a/arch/arm/include/asm/arch-tegra/pinmux.h
b/arch/arm/include/asm/arch-tegra/pinmux.h
index da477697bf02..ab764960fa7f 100644
--- a/arch/arm/include/asm/arch-tegra/pinmux.h
+++ b/arch/arm/include/asm/arch-tegra/pinmux.h
@@ -81,8 +81,9 @@ struct pmux_pingrp_config {
};
#if !defined(CONFIG_TEGRA20) !defined(CONFIG_TEGRA30)
-/* Set the pinmux CLAMP_INPUTS_WHEN_TRISTATED bit */
+/* Set/clear the pinmux CLAMP_INPUTS_WHEN_TRISTATED bit */
void pinmux_set_tristate_input_clamping(void);
+void pinmux_clear_tristate_input_clamping(void);
#endif
/* Set the mux function for a pin group */
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 12/12] tegra: Set CNTFRQ for secondary CPUs
On Tue, Feb 17, 2015 at 07:01:57AM +, Jan Kiszka wrote: On 2015-02-16 15:02, Jan Kiszka wrote: On 2015-02-16 14:51, Mark Rutland wrote: On Mon, Feb 16, 2015 at 01:44:36PM +, Jan Kiszka wrote: On 2015-02-16 14:37, Mark Rutland wrote: On Mon, Feb 16, 2015 at 12:54:49PM +, Jan Kiszka wrote: We only set CNTFRQ in arch_timer_init for the boot CPU. But this has to happen for all cores. Fixing this resolves problems of KVM with emulating the generic timer/counter. Signed-off-by: Jan Kiszka jan.kis...@siemens.com --- arch/arm/cpu/armv7/tegra-common/psci.S | 13 + 1 file changed, 13 insertions(+) diff --git a/arch/arm/cpu/armv7/tegra-common/psci.S b/arch/arm/cpu/armv7/tegra-common/psci.S index b7501fb..119c246 100644 --- a/arch/arm/cpu/armv7/tegra-common/psci.S +++ b/arch/arm/cpu/armv7/tegra-common/psci.S @@ -51,12 +51,25 @@ ENTRY(psci_arch_init) mrc p15, 0, r4, c0, c0, 5 @ MPIDR and r4, r4, #7 @ number of CPUs in cluster + + adr r5, _sys_clock_freq + cmp r4, #0 + + mrceq p15, 0, r7, c14, c0, 0 @ read CNTFRQ from CPU0 + streq r7, [r5] + + ldrne r7, [r5] + mcrne p15, 0, r7, c14, c0, 0 @ write CNTFRQ to CPU1..3 Is it not possible to have a hook that uses the same variable as arch_timer_init rather than doing a here copy? It seems a shame to duplicate the effort. The problem is related to the different address spaces. Here we run in the secure monitor, arch_timer_init - to my understanding - in non-secure mode. Didn't find a pattern so far how to transfer data (and that shouldn't be more complex than the above code). Surely arch_timer_init must be run in a secure mode in order to be allowed to write to CNTFRQ? Ah, right. If this is simply the easiest way of moving the data around then there's no real problem with it; it's just a shame that it only happens in the PSCI case. OK, I'll check again. Maybe it's easier than I thought. It isn't: the variable we would have to write - conditionally, i.e. not for the SPL build - is not yet where it will finally be. The monitor is copied later on, but the symbol points to the destination already. One can account for that, but the result won't get simpler and cleaner IMHO. Fair enough. As I mentioned earlier there's no real problem with the above, it just seemed a shame that this was only done in the PSCI case. I take it for the quoted sequence above that the primary CPU runs through this path before sending the secondaries through (and that either there's a DSB somewhere between the write and waking up secondaries or memory accesses are strongly ordered at this point). Thanks, Mark. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 08/11] Exynos542x: add L2 control register configuration
Hi,
On 03/02/15 17:18, Akshay Saraswat wrote:
This patch does 3 things:
1. Enables ECC by setting 21st bit of L2CTLR.
2. Restore data and tag RAM latencies to 3 cycles because iROM sets
0x3000400 L2CTLR value during switching.
3. Disable clean/evict push to external by setting 3rd bit of L2ACTLR.
We need to restore this here due to switching.
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
Reviewed-by: Simon Glass s...@chromium.org
Tested-by: Simon Glass s...@chromium.org
---
Changes since v1:
- Added Reviewed-by Tested-by.
arch/arm/cpu/armv7/exynos/lowlevel_init.c | 53
+++
arch/arm/cpu/armv7/exynos/soc.c | 7
2 files changed, 46 insertions(+), 14 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/lowlevel_init.c
b/arch/arm/cpu/armv7/exynos/lowlevel_init.c
index 1c70e54..9892e6b 100644
--- a/arch/arm/cpu/armv7/exynos/lowlevel_init.c
+++ b/arch/arm/cpu/armv7/exynos/lowlevel_init.c
@@ -68,24 +68,40 @@ static void enable_smp(void)
}
/*
+ * Enable ECC by setting L2CTLR[21].
+ * Set L2CTLR[7] to make tag ram latency 3 cycles and
+ * set L2CTLR[1] to make data ram latency 3 cycles.
+ * We need to make RAM latency of 3 cycles here because cores
+ * power ON and OFF while switching. And everytime a core powers
+ * ON, iROM provides it a default L2CTLR value 0x400 which stands
+ * for TAG RAM setup of 1 cycle. Hence, we face a need of
+ * restoring data and tag latency values.
+ */
+static void configure_l2_ctlr(void)
+{
+ uint32_t val;
+
+ mrc_l2_ctlr(val);
+ val |= (1 21);
+ val |= (1 7);
+ val |= (1 1);
+ mcr_l2_ctlr(val);
+}
+
+/*
* Set L2ACTLR[7] to reissue any memory transaction in the L2 that has been
* stalled for 1024 cycles to verify that its hazard condition still exists.
+ * Disable clean/evict push to external by setting L2ACTLR[3].
*/
-static void configure_l2actlr(void)
+static void configure_l2_actlr(void)
{
uint32_t val;
- /* Read MIDR for Primary Part Number */
- mrc_midr(val);
- val = (val 4);
- val = 0xf;
-
- /* L2ACTLR[7]: Enable hazard detect timeout for A15 */
- if (val == 0xf) {
- mrc_l2_aux_ctlr(val);
- val |= (1 7);
- mcr_l2_aux_ctlr(val);
- }
+ mrc_l2_aux_ctlr(val);
+ val |= (1 27);
+ val |= (1 7);
+ val |= (1 3);
+ mcr_l2_aux_ctlr(val);
}
/*
@@ -122,7 +138,16 @@ static void low_power_start(void)
/* Set the CPU to SVC32 mode */
svc32_mode_en();
- configure_l2actlr();
+
+ /* Read MIDR for Primary Part Number */
+ mrc_midr(val);
+ val = (val 4);
+ val = 0xf;
+
+ if (val == 0xf) {
+ configure_l2_ctlr();
+ configure_l2_actlr();
+ }
/* Invalidate L1 TLB */
val = 0x0;
@@ -175,7 +200,7 @@ static void power_down_core(void)
static void secondary_cores_configure(void)
{
/* Setup L2 cache */
- configure_l2actlr();
+ configure_l2_ctlr();
/* Clear secondary boot iRAM base */
writel(0x0, (CONFIG_EXYNOS_RELOCATE_CODE_BASE + 0x1C));
diff --git a/arch/arm/cpu/armv7/exynos/soc.c b/arch/arm/cpu/armv7/exynos/soc.c
index 7268b9b..ea201e7 100644
--- a/arch/arm/cpu/armv7/exynos/soc.c
+++ b/arch/arm/cpu/armv7/exynos/soc.c
@@ -10,8 +10,10 @@
#include asm/system.h
enum l2_cache_params {
+#ifndef CONFIG_EXYNOS5420
Please don't use ifdef.
CACHE_TAG_RAM_SETUP = (1 9),
CACHE_DATA_RAM_SETUP = (1 5),
+#endif
CACHE_TAG_RAM_LATENCY = (2 6),
CACHE_DATA_RAM_LATENCY = (2 0)
};
@@ -39,10 +41,15 @@ static void exynos5_set_l2cache_params(void)
asm volatile(mrc p15, 1, %0, c9, c0, 2\n : =r(val));
+#ifndef CONFIG_EXYNOS5420
val |= CACHE_TAG_RAM_SETUP |
CACHE_DATA_RAM_SETUP |
CACHE_TAG_RAM_LATENCY |
CACHE_DATA_RAM_LATENCY;
+#else
+ val |= CACHE_TAG_RAM_LATENCY |
+ CACHE_DATA_RAM_LATENCY;
+#endif
asm volatile(mcr p15, 1, %0, c9, c0, 2\n : : r(val));
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 06/12] virt-dt: Allow reservation of the secure region when it is in a RAM carveout.
[...] This is getting invasive: If I add carveouts via adjusting memory banks, I need to account for the case that an existing bank is split into two halves, creating additional banks this way. But then current fdt_fixup_memory_banks will no longer work due to its limitation to the number of physical banks. I could always add one spare bank to that service, ok, but then the next use case for carveouts will hit the wall again. So I better double that limit, or so. Yeah, not fun. If the code is position-independent then you might be able to simply carve out a sufficient proportion from the start of the first entry or the end of the last one, which would avoid splitting. If either of said regions are too small for the monitor code then it's questionable as to whether the OS can make use of it. The code /seems/ to be position-independent, but locations are so far hard-coded in those places that prepare it and move it around. Maybe we can decide about the location at runtime, maybe we can simply demand it to be at the end or the beginning of some bank. If it's possible to do so, it would seem like the nicest option to me. Also, are there any architectural or OS-implementation related restrictions on the alignment of bank start addresses and sizes? Just to make sure we don't stumble over some side effects of punching holes into that device tree node. I would guess that we need to at least pad the carevout to page-aligned to prevent any particular OS from mapping a page for the sake of a few bytes left unused by the monitor. From a quick look at the Linux arm_add_memory and memblock code it looks like Linux won't map partial pages, but I don't know what Xen and others do, and given we know that we want to keep the relevant pages exclusive to the monitor anyway padding to age boundaries seems like a sensible thing to do. My one concern would be early mappings; I believe that the initial page tables use (2MiB) section/block mappings to map the kernel and some initial memory (including the DTB) before the memory nodes are parsed, so the carevout would need to be placed away from where the kernel and DTB were loaded in order to prevent those early mappings from covering it. I'm unfortunately not sure on the full details there. That makes be wonder again if we are trying to solve real issues: What is the OS supposed to do with a memory reserve map, what does it have to avoid doing with it? Per ePAPR, memory reservation block entries may not be explicitly accessed by the operating system (unless told to elsewhere). The OS may map any reserved entries with cacheable attributes (potentially leading to the issues I described earlier) Is the semantic really so weak that we cannot use it here? In general, the semantic is too weak. In fact, it's not even strictly defined for the ARM architecture w.r.t. memory attributes, so we have very little guarantee as to what what an OS will do beyond that it will not perform any explicit accesses to the region. In practice, Linux will currently map the region as cacheable, and it may or may not map it shareable depending on SMP/UP (which could be a problem if you want to use a UP Linux to load and kexec an SMP kernel for some reason). It may be that on a given CPU/system implemetation that a memreserve entry is sufficient; but unfortunately this depends on IMPLEMENTATION DEFINED details. Thanks, Mark. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 07/11] Exynos542x: cache: Disable clean/evict push to external
Hi, On 03/02/15 17:18, Akshay Saraswat wrote: L2 Auxiliary Control Register provides configuration and control options for the L2 memory system. Bit 3 of L2ACTLR stands for clean/evict push to external. Setting bit 3 disables clean/evict which is what this patch intends to do. Signed-off-by: Akshay Saraswat aksha...@samsung.com Reviewed-by: Simon Glass s...@chromium.org Tested-by: Simon Glass s...@chromium.org --- Changes since v1: - Added Reviewed-by Tested-by. arch/arm/cpu/armv7/exynos/soc.c | 9 + 1 file changed, 9 insertions(+) diff --git a/arch/arm/cpu/armv7/exynos/soc.c b/arch/arm/cpu/armv7/exynos/soc.c index 8c7d7d8..7268b9b 100644 --- a/arch/arm/cpu/armv7/exynos/soc.c +++ b/arch/arm/cpu/armv7/exynos/soc.c @@ -45,6 +45,15 @@ static void exynos5_set_l2cache_params(void) CACHE_DATA_RAM_LATENCY; asm volatile(mcr p15, 1, %0, c9, c0, 2\n : : r(val)); + +#ifdef CONFIG_EXYNOS5420 I think you can use proid_is.. instead of ifdef + /* Read CP15 L2ACTLR value */ + asm volatile(mrc p15, 1, %0, c15, c0, 0 : =r (val)); + /* Disable clean/evict push to external */ + val |= (0x1 3); + /* Write new vlaue to L2ACTLR */ + asm volatile(mcr p15, 1, %0, c15, c0, 0 : : r (val)); +#endif } /* Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 11/14] usb: UniPhier: add UniPhier on-chip xHCI host driver support
On Tuesday, February 17, 2015 at 08:00:27 AM, Masahiro Yamada wrote:
Support xHCI host driver used on Panasonic UniPhier platform.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---
Hi Marek,
I want apply this patch onto u-boot-uniphier/master
to avoid conflicts.
If you are OK with it, could you issue your Acked-by tag, please?
[...]
+static int get_uniphier_xhci_base(int index, struct xhci_hccr **base)
+{
+ int offset;
+
+ for (offset = fdt_node_offset_by_compatible(FDT, 0, COMPAT);
+ offset = 0;
+ offset = fdt_node_offset_by_compatible(FDT, offset, COMPAT)) {
+ if (index == 0) {
+ *base = (struct xhci_hccr *)
+ fdtdec_get_addr(FDT, offset, reg);
Hi!
does it make sense to check if the value returned by fdtdec_get_addr() is
valid here?
Otherwise,
Acked-by: Marek Vasut ma...@denx.de
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2] image: Convert to use fdt_for_each_subnode macro
On Sat, Feb 07, 2015 at 09:12:39AM +0800, Axel Lin wrote: Use fdt_for_each_subnode macro to simplify the code a bit. Signed-off-by: Axel Lin axel@ingics.com Acked-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,v1] tools/imagetool: remove linker script
On Mon, Feb 09, 2015 at 12:06:10AM +0100, Andreas Bießmann wrote: Commit a93648d197df48fa46dd55f925ff70468bd81c71 introduced linker generated lists for imagetool which is the base for some host tools (mkimage, dumpimage, et al.). Unfortunately some host tool chains do not support the used type of linker scripts. Therefore this commit broke these host-tools for them, namely FreeBSD and Darwin (OS/X). This commit tries to fix this. In order to have a clean distinction between host and embedded code space we need to introduce our own linker generated list instead of re-using the available linker_lists.h provided functionality. So we copy the implementation used in linux kernel script/mod/file2alias.c which has the very same problem (cause it is a host tool). This code also comes with an abstraction for Mach-O binary format used in Darwin systems. Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com Cc: Guilherme Maciel Ferreira guilherme.maciel.ferre...@gmail.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 3/6] 85xx/kmp204x: read the IVM eeprom earlier
On Tue, Feb 10, 2015 at 05:10:15PM +0100, Valentin Longchamp wrote: This allows to define the ethaddr env variable according to the the IVM content by reading the IVM in misc_init_r. Later, when HUSH is available the content read earlier is analyzed to populate some non env variables. Signed-off-by: Valentin Longchamp valentin.longch...@keymile.com 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
