[U-Boot] mcf523x, issue in cpu_init
Hi,
looking on freescale files, i found this possible issue
line 65
out_be32(fbcs-cscr0, CONFIG_SYS_CS0_CTRL);
considering:
CONFIG_SYS_CS0_MASK for m5235evb board is
define CONFIG_SYS_CS0_CTRL 0x1D00
and
flexbus registers are as:
typedef struct fbcs {
u16 csar0; /* Chip-select Address */
u16 res1;
u32 csmr0; /* Chip-select Mask */
u16 res2;
u16 cscr0; /* Chip-select Control */
.
this line should not work, applying .
Best Regards,
Angelo Dureghello
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/7] fs: Add a Coreboot Filesystem (CBFS) driver and commands
Dear Simon, In message CAPnjgZ0k58-JG+MxvKp=6jxthmpb8pzhp+xfpdnb8jctamt...@mail.gmail.com you wrote: Yes I am now completely lost :-) Me too. Where have I changed the licensing model? Your original request was to remove the CREDITS line I think. I have done that in this patch: http://patchwork.ozlabs.org/patch/197314/ The above discussion about copyright message is separate to that. I Ah... I understood it was part of your intended changes. was looking around the code base for a possible replacement (shorter) message because I thought that was what you were looking for. I found the BSD one, but have not changed any code to use it. So yes, please can you explain what I am missing here? Maybe everything is clear to you, And I just did not understand. I just wanted to point out thatt he misc postings to this topic contained references to different licenses - starting from code under GPLv2+ metioning some BSD license to GPL again. If all this doesn't change the code, I suggest we ignore it all. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality. -- Albert Einstein ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/10] arm: Compile cache_disable() with -O2 to avoid failure
Dear Simon,
In message capnjgz38tzr2ztdq5d8fnfgcz9a+-vgjfv0saezjwiqbhh-...@mail.gmail.com
you wrote:
compiler to read the PC back from the stack after the dcache flush -
can you please explain what exactly this means, and which exact
problem it causes?
This is the code without the patch (armv7) using -O0:
0248 cache_disable:
248: e92d4810push{r4, fp, lr}
24c: e28db008add fp, sp, #8
250: e24dd01csub sp, sp, #28
254: e50b0020str r0, [fp, #-32]
258: ee114f10mrc 15, 0, r4, cr1, cr0, {0}
25c: e50b4014str r4, [fp, #-20]
260: e51b3014ldr r3, [fp, #-20]
264: e50b3010str r3, [fp, #-16]
268: eb69bl 14 cp_delay
26c: e51b3020ldr r3, [fp, #-32]
270: e3530004cmp r3, #4
274: 1a07bne 298 cache_disable+0x50
278: e51b3010ldr r3, [fp, #-16]
27c: e2033004and r3, r3, #4
280: e353cmp r3, #0
284: 0a0bbeq 2b8 cache_disable+0x70
288: e51b3020ldr r3, [fp, #-32]
28c: e3833001orr r3, r3, #1
290: e50b3020str r3, [fp, #-32]
294: ebfebl 0 flush_dcache_all
298: e51b3020ldr r3, [fp, #-32]
^
29c: e1e02003mvn r2, r3
2a0: e51b3010ldr r3, [fp, #-16]
2a4: e0023003and r3, r2, r3
2a8: e50b3018str r3, [fp, #-24]
2ac: e51b3018ldr r3, [fp, #-24]
2b0: ee013f10mcr 15, 0, r3, cr1, cr0, {0}
2b4: ea00b 2bc cache_disable+0x74
2b8: e1a0nop ; (mov r0, r0)
2bc: e24bd008sub sp, fp, #8
2c0: e8bd8810pop {r4, fp, pc}
this is the code with the patch:
0124 dcache_disable:
124: e92d4010push{r4, lr}
128: ebb4bl 0 cp_delay
12c: ee114f10mrc 15, 0, r4, cr1, cr0, {0}
130: e3140004tst r4, #4
134: 08bd8010popeq {r4, pc}
138: ebfebl 0 flush_dcache_all
13c: e3c44005bic r4, r4, #5
140: ee014f10mcr 15, 0, r4, cr1, cr0, {0}
144: e8bd8010pop {r4, pc}
I have marked with ^^ the line that I think it dies. I did not
spent a lot of time looking at it - just found the problem with an ICE
and then tried to fix it. I suspect it can be fixed with some sort of
dsb() in flush_dcache_all(), but I am not sure.
The code is actually pretty much different - note that the version
above contains calls to cache_disable() which are not visible in the
code below.
But then - the insn you mark is restoring r3 from the stack, after iut
was stored there right before calling flush_dcache_all(). Why should
this cause problems? And in which way is this read[ing] the PC back
from the stack ? r3 is not the PC, right?
OK. If I hit it again next time I will try a bit harder to root cause it.
Thanks, and sorry for insisting on a real explanation for obscure
problems.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Teenagers are people who express a burning desire to be different by
dressing exactly alike.
There are some strings. They're just not attached.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] tpm: Add casts for proper compilation
Dear Simon, In message capnjgz2p-re5hp13st-q2cup49azyzzxwnrzsafhr_iusgb...@mail.gmail.com you wrote: I accept that it has sat there for a while without a board config to use it. But I would very much like to keep this code and see no sense in removing it now that it is actually in use. Feel free to re-add it when there are any real users. I've posted a removal patch. Can you please explain what you mean by 'real users'? Are you looking for an entire verified boot implementation before you will accept the TPM driver? What exactly is this driver good for? Which function does it provide that can be used on any board in mainline? It looks to me that it's just sitting there, and does nothing good to anybody. I don't know if there are any other legitimate uses for a TPM driver in U-Boot, but if there are, none appear to be implemented by any mainline board, so why should we have this driver in mainline? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de While money can't buy happiness, it certainly lets you choose your own form of misery. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/8 v2] Add TMU support for Exynos5250 based SMDK5250
This patch series adds support for TMU driver using device tree for Exynos5250 based SMDK5250 board. This patch series is dependent on the patch series Add DT based ethernet driver for SMDK5250 by Hatim Ali Changes since v1: - Created new generic header file include/tmu.h - Removed GEN tag from subject in 2 patches - Changed description comments for couple of functions - Added Acked-by to all the patches Akshay Saraswat (6): EXYNOS5: FDT: Add TMU device node values EXYNOS5: TMU: Add driver for Thermal Management Unit EXYNOS5: Power down API for Thermal Management Unit Add a poll function to monitor events EXYNOS5: TMU: Add TMU status polling EXYNOS5: Config: Enable support for Exynos TMU driver Alim Akhtar (2): TMU: Add u-boot command to read current temp EXYNOS5: Config: Enable tmu command README|7 + arch/arm/cpu/armv7/exynos/power.c | 15 ++ arch/arm/dts/exynos5250.dtsi |5 + arch/arm/include/asm/arch-exynos/exynos-tmu.h | 58 + arch/arm/include/asm/arch-exynos/power.h |8 + board/samsung/dts/exynos5250-smdk5250.dts | 13 + board/samsung/smdk5250/smdk5250.c | 36 +++ common/Makefile |1 + common/cmd_tmu.c | 51 + common/console.c |5 + doc/device-tree-bindings/exynos/tmu.txt | 35 +++ drivers/power/Makefile|1 + drivers/power/exynos-tmu.c| 297 + include/common.h |6 + include/configs/exynos5250-dt.h |7 + include/fdtdec.h |1 + include/tmu.h | 46 lib/fdtdec.c |1 + 18 files changed, 593 insertions(+), 0 deletions(-) create mode 100644 arch/arm/include/asm/arch-exynos/exynos-tmu.h create mode 100644 common/cmd_tmu.c create mode 100644 doc/device-tree-bindings/exynos/tmu.txt create mode 100644 drivers/power/exynos-tmu.c create mode 100644 include/tmu.h -- 1.7.2.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/8 v2] EXYNOS5: FDT: Add TMU device node values
From: Akshay Saraswat aksha...@samsung.com
Fdt entry for Exynos TMU driver specific pre-defined values used for
calibration of current temperature and defining threshold values.
Signed-off-by: Akshay Saraswat aksha...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes since v1:
- Added Acked-by: Simon Glass
arch/arm/dts/exynos5250.dtsi |5
board/samsung/dts/exynos5250-smdk5250.dts | 13 ++
doc/device-tree-bindings/exynos/tmu.txt | 35 +
include/fdtdec.h |1 +
lib/fdtdec.c |1 +
5 files changed, 55 insertions(+), 0 deletions(-)
create mode 100644 doc/device-tree-bindings/exynos/tmu.txt
diff --git a/arch/arm/dts/exynos5250.dtsi b/arch/arm/dts/exynos5250.dtsi
index fa4d498..db22db6 100644
--- a/arch/arm/dts/exynos5250.dtsi
+++ b/arch/arm/dts/exynos5250.dtsi
@@ -28,4 +28,9 @@
#address-cells = 1;
#size-cells = 0;
};
+
+ tmu@1006 {
+ compatible = samsung,exynos-tmu;
+ reg = 0x1006 0x;
+ };
};
diff --git a/board/samsung/dts/exynos5250-smdk5250.dts
b/board/samsung/dts/exynos5250-smdk5250.dts
index b6fbb67..2d3ecca 100644
--- a/board/samsung/dts/exynos5250-smdk5250.dts
+++ b/board/samsung/dts/exynos5250-smdk5250.dts
@@ -26,4 +26,17 @@
phy-mode = mii;
};
};
+
+ tmu@1006 {
+ samsung,mux = 6;
+ samsung,min-temp= 25;
+ samsung,max-temp= 125;
+ samsung,start-warning = 95;
+ samsung,start-tripping = 105;
+ samsung,efuse-min-value = 40;
+ samsung,efuse-value = 55;
+ samsung,efuse-max-value = 100;
+ samsung,slope = 268470274;
+ samsung,dc-value= 25;
+ };
};
diff --git a/doc/device-tree-bindings/exynos/tmu.txt
b/doc/device-tree-bindings/exynos/tmu.txt
new file mode 100644
index 000..99e7164
--- /dev/null
+++ b/doc/device-tree-bindings/exynos/tmu.txt
@@ -0,0 +1,35 @@
+Exynos Thermal management Unit
+
+The device node for TMU that is a part of Exynos5250
+SOC is as described in the document Open Firmware Recommended
+Practic : Universal Serial Bus with the following modifications
+and additions:
+
+Required properties :
+ - compatible : Should be samsung,exynos-tmu for TMU
+ - samsung,mux : mux Address for the TMU to enable TMU core:
+ - samsung,min-temp : Minimum temperature, default is 25:
+ - samsung,max-temp : Maximum temperature, defalut set to 125:
+ - samsung,start-warning : temp at which TMU start giving warning:
+ - samsung,start-tripping : temp at which system will trip and shutdown:
+ - samsung,efuse-min-value : SOC efuse min value:
+ - samsung,efuse-value : SOC actual efuse value:
+ - samsung,efuse-max-value : SoC max efuse value:
+ - samsung,slope : Gain of amplifier, default is 268470274:
+ - samsung,dc-value : DC value of TMU, default is 25:
+
+Example:
+
+tmu@1006 {
+ compatible = samsung,exynos-tmu
+ samsung,mux = 6;
+ samsung,min-temp = 25;
+ samsung,max-temp = 125;
+ samsung,start-warning = 95;
+ samsung,start-tripping = 105;
+ samsung,efuse-min-value = 40;
+ samsung,efuse-value = 55;
+ samsung,efuse-max-value = 100;
+ samsung,slope = 268470274;
+ samsung,dc-value = 25;
+};
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 8f79f8a..180dfff 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -68,6 +68,7 @@ enum fdt_compat_id {
COMPAT_NVIDIA_TEGRA20_NAND, /* Tegra2 NAND controller */
COMPAT_SMSC_LAN9215,/* SMSC 10/100 Ethernet LAN9215 */
COMPAT_SAMSUNG_EXYNOS5_SROMC, /* Exynos5 SROMC */
+ COMPAT_SAMSUNG_EXYNOS_TMU, /* Exynos TMU */
COMPAT_COUNT,
};
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index d8103fd..8e5ed21 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -45,6 +45,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
COMPAT(NVIDIA_TEGRA20_NAND, nvidia,tegra20-nand),
COMPAT(SMSC_LAN9215, smsc,lan9215),
COMPAT(SAMSUNG_EXYNOS5_SROMC, samsung,exynos-sromc),
+ COMPAT(SAMSUNG_EXYNOS_TMU, samsung,exynos-tmu),
};
const char *fdtdec_get_compatible(enum fdt_compat_id id)
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/8 v2] EXYNOS5: TMU: Add driver for Thermal Management Unit
From: Akshay Saraswat aksha...@samsung.com
Adding Exynos Thermal Management Unit driver to monitor SOC
temperature and take actions corresponding to states of TMU.
System will shutdown if tripping temperature is reached.
Signed-off-by: Akshay Saraswat aksha...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes since v1:
- Added new generic header file include/tmu.h
- Added Acked-by: Simon Glass
arch/arm/include/asm/arch-exynos/exynos-tmu.h | 58 +
drivers/power/Makefile|1 +
drivers/power/exynos-tmu.c| 297 +
include/tmu.h | 46
4 files changed, 402 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/arch-exynos/exynos-tmu.h
create mode 100644 drivers/power/exynos-tmu.c
create mode 100644 include/tmu.h
diff --git a/arch/arm/include/asm/arch-exynos/exynos-tmu.h
b/arch/arm/include/asm/arch-exynos/exynos-tmu.h
new file mode 100644
index 000..adfaf0d
--- /dev/null
+++ b/arch/arm/include/asm/arch-exynos/exynos-tmu.h
@@ -0,0 +1,58 @@
+/*
+ * Copyright (c) 2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ * Akshay Saraswat aksha...@samsung.com
+ *
+ * EXYNOS - Thermal Management Unit
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef __ASM_ARCH_THERMAL_H
+#define __ASM_ARCH_THERMAL_H
+
+struct tmu_reg {
+ unsigned triminfo;
+ unsigned rsvd1;
+ unsigned rsvd2;
+ unsigned rsvd3;
+ unsigned rsvd4;
+ unsigned triminfo_control;
+ unsigned rsvd5;
+ unsigned rsvd6;
+ unsigned tmu_control;
+ unsigned rsvd7;
+ unsigned tmu_status;
+ unsigned sampling_internal;
+ unsigned counter_value0;
+ unsigned counter_value1;
+ unsigned rsvd8;
+ unsigned rsvd9;
+ unsigned current_temp;
+ unsigned rsvd10;
+ unsigned rsvd11;
+ unsigned rsvd12;
+ unsigned threshold_temp_rise;
+ unsigned threshold_temp_fall;
+ unsigned rsvd13;
+ unsigned rsvd14;
+ unsigned past_temp3_0;
+ unsigned past_temp7_4;
+ unsigned past_temp11_8;
+ unsigned past_temp15_12;
+ unsigned inten;
+ unsigned intstat;
+ unsigned intclear;
+ unsigned rsvd15;
+ unsigned emul_con;
+};
+#endif /* __ASM_ARCH_THERMAL_H */
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 6bf388c..192a7cb 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -30,6 +30,7 @@ COBJS-$(CONFIG_TPS6586X_POWER)+= tps6586x.o
COBJS-$(CONFIG_TWL4030_POWER) += twl4030.o
COBJS-$(CONFIG_TWL6030_POWER) += twl6030.o
COBJS-$(CONFIG_TWL6035_POWER) += twl6035.o
+COBJS-$(CONFIG_EXYNOS_TMU) += exynos-tmu.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/power/exynos-tmu.c b/drivers/power/exynos-tmu.c
new file mode 100644
index 000..ce71408
--- /dev/null
+++ b/drivers/power/exynos-tmu.c
@@ -0,0 +1,297 @@
+/*
+ * Copyright (c) 2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ * Akshay Saraswat aksha...@samsung.com
+ *
+ * EXYNOS - Thermal Management Unit
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include errno.h
+#include fdtdec.h
+#include tmu.h
+#include asm/arch/exynos-tmu.h
+
+#define TRIMINFO_RELOAD1
+#define CORE_EN1
+
+#define INTEN_RISE01
+#define INTEN_RISE1(1 4)
+#define INTEN_RISE2(1 8)
+#define INTEN_FALL0(1 16)
+#define INTEN_FALL1(1 20)
+#define INTEN_FALL2(1 24)
+
+#define TRIM_INFO_MASK 0xff
+
+#define INTCLEAR_RISE0 1
+#define INTCLEAR_RISE1 (1 4)
+#define INTCLEAR_RISE2 (1 8)
+#define INTCLEAR_FALL0 (1 16)
+#define INTCLEAR_FALL1 (1 20)
+#define INTCLEAR_FALL2 (1 24)
+#define INTCLEARALL(INTCLEAR_RISE0 | INTCLEAR_RISE1 | \
+INTCLEAR_RISE2 | INTCLEAR_FALL0 | \
+
Re: [U-Boot] [PATCH] USB: add arrow key support to usb_kbd
Dear Allen Martin, On Tue, Nov 06, 2012 at 02:56:37PM -0800, Marek Vasut wrote: Dear Simon Glass, Hi Marek, On Tue, Nov 6, 2012 at 2:49 PM, Marek Vasut ma...@denx.de wrote: Dear Allen Martin, Check for scancodes for arrow keys and map them to ^F/^B, ^N/^P. Control characters are used instead of ANSI sequence because the queueing code in usb_kbd doesn't handle the data increase when one keypress generates 3 keycodes. The real fix is to convert this driver to use the input subsystem and queue If it's the real fix, then why not go for the real fix right away? :-( Because it's a fair chunk of work Let's either do it properly or not at all ... if I let you do these semi- complete fixes, we'll end up with a stinking pile of crap like windows ... I'm definately on board with changing it over to use input, it seems like the right thing to do. I just wasn't signing up to do the work right now. I'm happy to help review patches though if someone else wants to jump in. Guys ... I have two things in my mind. You want to add features, that's fine with me. But then, the merge window is closed already, so you have crapload of time to work on it. Also, if you won't do it now, noone will ever do it later. Please, do it now. I don't see it being too much work. btw. do you remember we've been in such place once already with some other piece of u-boot? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/8 v2] EXYNOS5: Power down API for Thermal Management Unit
From: Akshay Saraswat aksha...@samsung.com
Adding API in power for system shutdown when tripping value is reached
in Exynos Thermal Management Unit.
Signed-off-by: Akshay Saraswat aksha...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes since v1:
- Changed description comment for power_shutdown function
- Added Acked-by: Simon Glass
arch/arm/cpu/armv7/exynos/power.c| 15 +++
arch/arm/include/asm/arch-exynos/power.h |8
2 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/power.c
b/arch/arm/cpu/armv7/exynos/power.c
index d4bce6d..725c2d3 100644
--- a/arch/arm/cpu/armv7/exynos/power.c
+++ b/arch/arm/cpu/armv7/exynos/power.c
@@ -95,3 +95,18 @@ void set_dp_phy_ctrl(unsigned int enable)
if (cpu_is_exynos5())
exynos5_dp_phy_control(enable);
}
+
+/*
+ * This function never returns.
+ * When called this function makes system hang and PAD driving value high
+ * which in turn makes system power down in case of cold reboot.
+ */
+void power_shutdown(void)
+{
+ struct exynos5_power *power =
+ (struct exynos5_power *)samsung_get_base_power();
+
+ clrbits_le32(power-ps_hold_control, POWER_PS_HOLD_CONTROL_DATA_HIGH);
+
+ hang();
+}
diff --git a/arch/arm/include/asm/arch-exynos/power.h
b/arch/arm/include/asm/arch-exynos/power.h
index d2fdb59..f069a0b 100644
--- a/arch/arm/include/asm/arch-exynos/power.h
+++ b/arch/arm/include/asm/arch-exynos/power.h
@@ -863,5 +863,13 @@ void set_usbhost_phy_ctrl(unsigned int enable);
void set_dp_phy_ctrl(unsigned int enable);
#define EXYNOS_DP_PHY_ENABLE (1 0)
+#define POWER_PS_HOLD_CONTROL_DATA_HIGH (1 8)
+
+/*
+ * This function never returns.
+ * When called this function makes system hang and PAD driving value high
+ * which in turn makes system power down in case of cold reboot.
+ */
+void power_shutdown(void) __attribute__ ((noreturn));
#endif
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/8 v2] Add a poll function to monitor events
From: Akshay Saraswat aksha...@samsung.com
Adding a generic polling function to continuously monitor events and
trigger actions corresponding to them.
Signed-off-by: Akshay Saraswat aksha...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes since v1:
- Removed GEN tag from subject
- Changed description comment for board_poll_devices function
- Added Acked-by: Simon Glass
README |7 +++
common/console.c |5 +
include/common.h |6 ++
3 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/README b/README
index 2572add..72b3b67 100644
--- a/README
+++ b/README
@@ -2814,6 +2814,13 @@ Configuration Settings:
the application (usually a Linux kernel) when it is
booted
+- CONFIG_BOARD_POLL
+ There are various scenarios in which parallel-thread like
+ polling is required to monitor status of variety of devices.
+ For such situations CONFIG_BOARD_POLL shall be enabled
+ and funtion call board_poll_devices() from console_tstc()
+ will then poll for the device status as defined inside function.
+
- CONFIG_SYS_BAUDRATE_TABLE:
List of legal baudrate settings for this board.
diff --git a/common/console.c b/common/console.c
index 1177f7d..d320b9b 100644
--- a/common/console.c
+++ b/common/console.c
@@ -117,6 +117,11 @@ static int console_tstc(int file)
int i, ret;
struct stdio_dev *dev;
+#if defined CONFIG_BOARD_POLL
+ /* Generic polling function */
+ board_poll_devices();
+#endif
+
disable_ctrlc(1);
for (i = 0; i cd_count[file]; i++) {
dev = console_devices[file][i];
diff --git a/include/common.h b/include/common.h
index b23e90b..70a348d 100644
--- a/include/common.h
+++ b/include/common.h
@@ -782,6 +782,12 @@ void clear_ctrlc (void); /* clear the Control-C
condition */
intdisable_ctrlc (int);/* 1 to disable, 0 to enable Control-C detect */
/*
+ * A generic polling function.
+ * This will be called form console_tstc() to poll for various events.
+ */
+void board_poll_devices(void);
+
+/*
* STDIO based functions (can always be used)
*/
/* serial stuff */
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/8 v2] EXYNOS5: TMU: Add TMU status polling
From: Akshay Saraswat aksha...@samsung.com
This adds call to tmu_init() and TMU status polling in board_poll_devices()
funtion to monitor temperature change of the SOC.
Signed-off-by: Akshay Saraswat aksha...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes since v1:
- Removed debug print under TMU_STATUS_NORMAL case
- Added Acked-by: Simon Glass
board/samsung/smdk5250/smdk5250.c | 36
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/board/samsung/smdk5250/smdk5250.c
b/board/samsung/smdk5250/smdk5250.c
index ac7346d..db2457b 100644
--- a/board/samsung/smdk5250/smdk5250.c
+++ b/board/samsung/smdk5250/smdk5250.c
@@ -32,15 +32,51 @@
#include asm/arch/pinmux.h
#include asm/arch/sromc.h
#include pmic.h
+#include tmu.h
+#include asm/arch/exynos-tmu.h
+#include asm/arch/power.h
DECLARE_GLOBAL_DATA_PTR;
+/*
+ * Polling various devices on board for details and status monitoring purposes
+ */
+void board_poll_devices(void)
+{
+#if defined CONFIG_EXYNOS_TMU
+ int temp;
+
+ switch (tmu_monitor(temp)) {
+ case TMU_STATUS_TRIPPED:
+ puts(EXYNOS_TMU: TRIPPING! Device power going down ...\n);
+ power_shutdown();
+ break;
+ case TMU_STATUS_WARNING:
+ puts(EXYNOS_TMU: WARNING! Temperature very high\n);
+ break;
+ case TMU_STATUS_INIT:
+ case TMU_STATUS_NORMAL:
+ break;
+ default:
+ debug(Unknown TMU state\n);
+ }
+#endif
+}
+
int board_init(void)
{
gd-bd-bi_boot_params = (PHYS_SDRAM_1 + 0x100UL);
#if defined(CONFIG_PMIC)
pmic_init();
#endif
+
+#if defined CONFIG_EXYNOS_TMU
+ if (tmu_init(gd-fdt_blob)) {
+ debug(%s: Failed to init TMU\n, __func__);
+ return -1;
+ }
+#endif
+
#ifdef CONFIG_EXYNOS_SPI
spi_init();
#endif
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 09/10] arm: Move bootstage record for board_init_f() to after arch_cpu_init()
Dear Simon, In message capnjgz0d4g4bk70vook3sykmzowlsypxdje2ycn3gvj1jav...@mail.gmail.com you wrote: NAK as is. Please make sure to keep all arhcitectures in sync. The long term goal iss till to merge the lib/board.c files into a single, common one. See my notes on the other patch, most of which apply here. http://patchwork.ozlabs.org/patch/196419/ I don't believe this affects other architectures, but it is a problem on at least exynos 5. Well, but if you just compare arch/arm/lib/board.c and arch/powerpc/lib/board.c, we are heading into pretty much deviation directions. I'd like to stop that. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It is impractical for the standard to attempt to constrain the behavior of code that does not obey the constraints of the standard. - Doug Gwyn ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] USB: add arrow key support to usb_kbd
Dear Stephen Warren, On 11/06/2012 03:56 PM, Marek Vasut wrote: Dear Simon Glass, Hi Marek, On Tue, Nov 6, 2012 at 2:49 PM, Marek Vasut ma...@denx.de wrote: Dear Allen Martin, Check for scancodes for arrow keys and map them to ^F/^B, ^N/^P. Control characters are used instead of ANSI sequence because the queueing code in usb_kbd doesn't handle the data increase when one keypress generates 3 keycodes. The real fix is to convert this driver to use the input subsystem and queue If it's the real fix, then why not go for the real fix right away? :-( Because it's a fair chunk of work Let's either do it properly or not at all ... if I let you do these semi- complete fixes, we'll end up with a stinking pile of crap like windows ... Marek, I find this attitude a little ridiculous. If everything was fixed completely the first time around, there would be no work left to do; we'd just stop developing U-Boot. Equally, if this small addition to the USB keyboard code is so bad it can't be allowed since the whole driver must be re-written instead, why was the existing code allowed into U-Boot in the first place? Because evil b*tch (=me) wasn't around in the first place ;-) Anyway ... I'll apply it (not because of your whining and stuff ... but because it's beneficial). Though, I'd be really glad if you invested time to rework the driver. Otherwise, it'll be me who'll end up doing the work and I'd prefer to delegate it to someone who brough the issue up sooner ;-) Incremental small patches are good; they allow small simple things to be implemented without causing massive disruption. That's great for locating any regressions. Is there anything actually technically wrong with this specific patch? I would say no; it's very simple, non-invasive, low-risk, doesn't appear to introduce any long-term maintenance burden, doesn't completely prevent or remotely hinder reworking the USB keyboard support in the future, etc. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/8 v2] EXYNOS5: Config: Enable support for Exynos TMU driver
From: Akshay Saraswat aksha...@samsung.com Enables TMU driver support for exynos5250 Signed-off-by: Akshay Saraswat aksha...@samsung.com Acked-by: Simon Glass s...@chromium.org --- Changes since v1: - Added Acked-by: Simon Glass include/configs/exynos5250-dt.h |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h index 12f555c..2f4315a 100644 --- a/include/configs/exynos5250-dt.h +++ b/include/configs/exynos5250-dt.h @@ -106,6 +106,12 @@ #define CONFIG_BOOTDELAY 3 #define CONFIG_ZERO_BOOTDELAY_CHECK +/* Generic Device Polling */ +#define CONFIG_BOARD_POLL + +/* Thermal Management Unit */ +#define CONFIG_EXYNOS_TMU + /* USB */ #define CONFIG_CMD_USB #define CONFIG_USB_EHCI -- 1.7.2.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/8 v2] TMU: Add u-boot command to read current temp
From: Alim Akhtar alim.akh...@samsung.com
Adds a new u-boot command to read current temprature from tmu driver.
Signed-off-by: Alim Akhtar alim.akh...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes since v1:
- Include new generic tmu header file
- Made printf()s consistent
- Added Acked-by: Simon Glass
common/Makefile |1 +
common/cmd_tmu.c | 51 +++
2 files changed, 52 insertions(+), 0 deletions(-)
create mode 100644 common/cmd_tmu.c
diff --git a/common/Makefile b/common/Makefile
index dca2f53..b56ffa2 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -159,6 +159,7 @@ COBJS-$(CONFIG_CMD_STRINGS) += cmd_strings.o
COBJS-$(CONFIG_CMD_TERMINAL) += cmd_terminal.o
COBJS-$(CONFIG_CMD_TIME) += cmd_time.o
COBJS-$(CONFIG_SYS_HUSH_PARSER) += cmd_test.o
+COBJS-$(CONFIG_CMD_TMU) += cmd_tmu.o
COBJS-$(CONFIG_CMD_TPM) += cmd_tpm.o
COBJS-$(CONFIG_CMD_TSI148) += cmd_tsi148.o
COBJS-$(CONFIG_CMD_UBI) += cmd_ubi.o
diff --git a/common/cmd_tmu.c b/common/cmd_tmu.c
new file mode 100644
index 000..7fbf845
--- /dev/null
+++ b/common/cmd_tmu.c
@@ -0,0 +1,51 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics
+ * Alim Akhtar alim.akh...@samsung.com
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include command.h
+#include tmu.h
+
+int do_tmu(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ int cur_temp;
+
+ if (argc 2)
+ return CMD_RET_USAGE;
+
+ if (strcmp(argv[1], curtemp) == 0) {
+ if (tmu_monitor(cur_temp) == -1)
+ printf(TMU is in unknown state, temperature is invalid
\n);
+ else
+ printf(Current temperature: %u degrees Celsius \n,
cur_temp);
+ } else {
+ return CMD_RET_USAGE;
+ }
+
+ return 0;
+}
+
+U_BOOT_CMD(
+ tmu, 2, 1, do_tmu,
+ Thermal Management Unit\n,
+ curtemp - show current CPU temperature in degrees Celsius\n
+);
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 8/8 v2] EXYNOS5: Config: Enable tmu command
From: Alim Akhtar alim.akh...@samsung.com This enables the tmu command to read the current SOC temperature with the help of TMU Signed-off-by: Alim Akhtar alim.akh...@samsung.com Acked-by: Simon Glass s...@chromium.org --- Changes since v1: - Added Acked-by: Simon Glass include/configs/exynos5250-dt.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h index 2f4315a..2b9271c 100644 --- a/include/configs/exynos5250-dt.h +++ b/include/configs/exynos5250-dt.h @@ -111,6 +111,7 @@ /* Thermal Management Unit */ #define CONFIG_EXYNOS_TMU +#define CONFIG_CMD_TMU /* USB */ #define CONFIG_CMD_USB -- 1.7.2.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] common: add ifdefs around bouncebuf.c body
Dear Stephen Warren, On 11/06/2012 03:57 PM, Marek Vasut wrote: Dear Stephen Warren, On 11/06/2012 03:43 PM, Marek Vasut wrote: Dear Stephen Warren, On 11/05/2012 05:54 PM, Marek Vasut wrote: Dear Stephen Warren, From: Stephen Warren swar...@nvidia.com If a U-Boot config file enables CONFIG_BOUNCE_BUFFER only for the main U-Boot build and not for the SPL, then config.mk will contain CONFIG_BOUNCE_BUFFER=y, so common/Makefile will build bouncebuf.c for both the SPL and main U-Boot, but config.h won't set CONFIG_BOUNCE_BUFFER for the SPL, so bouncebuf.h will provide static inline functions, which will conflict with the compiled bouncebuf.c. Solve this by guarding the body of bouncebuf.c with the ifdef to avoid conflicts. Uh, don't you want the bounce buffer not compiled in for SPL? Then maybe add CONFIG_SPL_BOUNCE_BUFFER to force BB to be compiled into SPL or something ... Not compiling bouncebuf.c for SPL would solve this too. I have no idea what build system contortions would be required to do this though. Do you think the build system should be fixed first rather than taking this series/patch? I guess we shouldn't need a separate CONFIG_SPL_BOUNCE_BUFFER option though; we should rather simply set CONFIG_SPL_BOUNCE_BUFFER appropriately for SPL and non-SPL, and have everything key off that one variable, right? How will you be able to configure it separately for spl and non-spl ? For example, include/configs/trimslice.h contains: /* SD/MMC */ #define CONFIG_MMC #define CONFIG_GENERIC_MMC #define CONFIG_TEGRA_MMC #define CONFIG_CMD_MMC However, we don't use MMC in our SPL, but don't want to pollute every Tegra board file with ifdefs for SPL, so include/configs/tegra-common-post.h (which is included at the end of trimslice.h) contains: #ifdef CONFIG_SPL_BUILD ... /* remove MMC support */ #ifdef CONFIG_MMC #undef CONFIG_MMC #endif #ifdef CONFIG_GENERIC_MMC #undef CONFIG_GENERIC_MMC #endif #ifdef CONFIG_TEGRA_MMC #undef CONFIG_TEGRA_MMC #endif #ifdef CONFIG_CMD_MMC #undef CONFIG_CMD_MMC #endif ... #endif And in the V1 patch I proposed to tegra-common-post.h, I added the following at the end: #ifdef CONFIG_TEGRA_MMC #define CONFIG_BOUNCE_BUFFER #endif Yet, this doesn't solve the problem with SPL ... since for SPL, you'd have to do ifdef CONFIG_SPL, no? Sorry, what problem with the SPL is this not solving? I think I was tired when replying (sorry, the conference is really heavy on me). I though you wanted to disable BB only for SPL, but now I see BB being enabled depends on tegra mmc. btw. shouldn't --gc-sections remove BB code if it's not used at all? Best regards, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] usb: ehci: Take advantage of the new multi-controller feature for MXC
Dear Lucas Stach, Dear Marek Vasut, Am Dienstag, den 06.11.2012, 23:35 +0100 schrieb Marek Vasut: Dear Lucas Stach, [...] What do you think? What about passing port private / platform data instead of ID ? The ID is already passed to ehci_hcd_init(), so we have to live with it if we don't want to change the newly introduced multi-controller infrastructure. Let's change it remove the ID and pass some generic pdata. I don't like the idea of passing around data at this level. It's breaking the abstraction, as we have to pass low-level usb information around in the higher USB stack levels. Good, what do you suggest we do when we apply driver model onto this stuff? Sadly I have not found the time to take a deeper look into the driver model. But see below. You might want to ... I suspect instead of passing ID, we should start passing some USB pdata. EHCI Pdata for ehci I guess ... The USB driver code should be able to do the virt-to-phys controller mapping on it's own. In the Tegra world Tegra is completely unimportant part of the usb ecosystem. I know that your views are centred around a different point, which is fine with me, but please don't make the mistake to downplay the importance of _any_ part of the ecosystem. On the contrary, I'm trying to avoid making the mistake of focusing on any SoC too much. we use the information we get from device tree to do so, but I don't see a reason why your USB host driver code wouldn't be able to just require an array with configuration data from the board file. I don't see how you transfer DT information into controller # ... There is really no need to pass this information through all the USB stack interfaces. Please explain. Tegra has a two step initialisation: 1. Init the driver at board_init time This is the step where we parse all the DT information and fill in all needed driver internal structures. At this point we do the virt to phys controller ID mapping. Hm ... thinking about it, maybe you can do generic USB Pdata which would contain the controller # and additional pdata (like mmap address etc). 2. For every controller that U-Boot really uses we activate host mode and do the real hardware initialisation at ehci_hcd_init time. Good. If I'm not completely mistaken such a model should align nicely with the upcoming driver model. The driver gets instantiated with information it gathers from global platform data, may it be device tree or any other form of driver related information. Yes, but you don't pass such data through the driver (yet). You need to do that and that's what I asked you to do. In this case the ehci_hcd_init|stop entry points are only used to init/stop one specific controller, which is completely different matter from the driver being instantiated and as such should not carry any platform data. IMHO all platform data should be contained in the boards global data. I believe you should be passing pdata to the ehci_hcd_init ... they might contain some register frobbing etc., but this is probably the part where we missed each ones point. Regards, Lucas Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] video: atmel: implement lcd_setcolreg funtion
Dear Bo Shen,
Hi Marek,
On 11/7/2012 6:54, Marek Vasut wrote:
Dear Andreas Bießmann,
From: Bo Shen voice.s...@atmel.com
Missing commit message
Signed-off-by: Bo Shen voice.s...@atmel.com
Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com
---
since v2:
* add this single patch
drivers/video/atmel_hlcdfb.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/video/atmel_hlcdfb.c b/drivers/video/atmel_hlcdfb.c
index beb7fa3..4110d4d 100644
--- a/drivers/video/atmel_hlcdfb.c
+++ b/drivers/video/atmel_hlcdfb.c
@@ -51,6 +51,12 @@ short console_row;
#define lcdc_readl(reg) __raw_readl((reg))
#define lcdc_writel(reg, val)__raw_writel((val), (reg))
+void lcd_setcolreg(ushort regno, ushort red, ushort green, ushort blue)
+{
+ lcdc_writel((red 16) | (green 8) | blue,
+ panel_info.mmio + ATMEL_LCDC_LUT(regno));
So this is RGB666? Or what are those magic numbers ?
This is a little different with the driver of atmel_lcdfb.c.
The register for LUT is layout as following:
RCLUT (24 ~ 16), GCLUT (15 ~ 8) and BCLUT (7 ~ 0).
So, use those magic numbers.
Good, can you define those magic offsets then please?
More information, you can get from [1] on page 1163.
1. http://www.atmel.com/Images/doc11053.pdf
[...]
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] usb: ehci: Take advantage of the new multi-controller feature for MXC
Dear Marek Vasut, Am Mittwoch, den 07.11.2012, 14:25 +0100 schrieb Marek Vasut: Dear Lucas Stach, Dear Marek Vasut, Am Dienstag, den 06.11.2012, 23:35 +0100 schrieb Marek Vasut: I don't see how you transfer DT information into controller # ... There is really no need to pass this information through all the USB stack interfaces. Please explain. Tegra has a two step initialisation: 1. Init the driver at board_init time This is the step where we parse all the DT information and fill in all needed driver internal structures. At this point we do the virt to phys controller ID mapping. Hm ... thinking about it, maybe you can do generic USB Pdata which would contain the controller # and additional pdata (like mmap address etc). 2. For every controller that U-Boot really uses we activate host mode and do the real hardware initialisation at ehci_hcd_init time. Good. If I'm not completely mistaken such a model should align nicely with the upcoming driver model. The driver gets instantiated with information it gathers from global platform data, may it be device tree or any other form of driver related information. Yes, but you don't pass such data through the driver (yet). You need to do that and that's what I asked you to do. We do pass this data to the driver in the form of gd-fdt_blob. This data is driver (not controller) specific, so why would you pass this in at ehci_hcd_init time? But while writing this I think I now see why we miss each others point: the Tegra EHCI driver is only instantiated once and used for all controllers. This probably has to be reworked for the driver model. Now I would still argue that we should keep the two step init model, first we instantiate the driver with some form of pdata (we can certainly come up with a one-struct-fits-all for this) and later when we are really going to use one specific controller we do the real hardware init. Now we seem to differ about the meaning of the usb stack functions. From your mails I see that you want ehci_hcd_init as the first init step where we instantiate the driver (and therefore need the pdata), where I treated it as the second step, because currently it is the point where the upper USB stack levels indicate that they are going to use a specific controller. We should probably come up with some consensus about this before going forward. Sadly my free time is really limited right now, so it's hard for me to keep up even with things I planned to do in the next few weeks, not to speak about playing around with the driver model. Regards, Lucas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] TPM: remove dead code
Dear Simon Glass, In message capnjgz2qyrjfjbjtr9mhcsquev933oawpjstvv-kfrhlcfj...@mail.gmail.com you wrote: OK, but I still don't quite get it. As I asked in the other thread, are you not interested in TPM functionality at all until we have a verified boot implementation, or are you happy to have things progress in stages? I'm will to work through this, and I have the time at present, but I believe that drivers for two common TPM chips are a useful addition to U-Boot regardless. I'm sorry, but I disagree - the drivers may be useful indeed, but as long as there are no users in U-Boot they are just dead weight. So far we have followed the rule not to add dead code - we always asked to add code (drivers) together with any consumers, i. e. other code that provides useful features (at least to one board) that actually needs and uses such drivers. With TPM we made an exception from this rule, based on the expectation that users would be added soon. Then a full year passed, and nothing happened. Really _nothing_. Now you suggest to progress in stages? You mean adding more and more code around, all of which will be unused, until one bright day in a non-foreseeable future some board might get added, that will then use this? This is not exactly a proposal that triggers enthusiasm to me. It's not obvious how to mainline this rather large feature except in pieces. For example, I think I can start on a feature to verify a kernel, but I do want to talk to the TPM as part of that. Instead of working bottom up (which will necessarily result in an approach trying to add unused code) you could do it top down: start indeed with a feature to verify a kernel (oh! we already have that as psrt of the image verification - with simple CRC in the leggacy images, and will optionally all other kinds in FIT images). This verification could initially be an empty function just returning a true value. No TPM is needed for that. Than work top down for there. That's going to be a big series but in contrast, display, SATA and GPIO patches are ok, but TPM is not? Ummm... are you telling me that contrast, display, SATA and GPIO patches all also add dead code that is not used anywhere? I have not looked closer there because I simply did not expoect this. But if so, the very same rules apply: we do not want to add dead code. I'll see what I can do here, but in principle I feel that adding a driver should be OK, provided a board uses it, without necessarily the high-level code that uses it. After all, we don't necessarily expect to mainline all the scripts that drive the actual boot. what exactly do you mean by a board uses it, without necessarily the high-level code that uses it? If uses for you means just conteining a function call reference so the code gets cimpiled and pulled in by the linker, then I have to tell you that this NOT my understanding of usage. For me, using some code means that it actually performs some _function_. As long as the code is not actually running on the system, it is not being used. And especially not after the experience with the TPM code so far, where my patience has been exhausted after more than a year of nothing happening. Well not nothing. Have been rather tied up getting a product out. I Sorry, but for U-Boot it is completely irrelevant what happens with your out of tree code. The code in mainline has just been sitting there, unused as ever. agree that things have been very quiet on verified boot - perhaps the original upstream author was exhausted after the effort of getting the driver into mainline and retired for a rest :-) Well, this experience has sunk in. Exactly what I feared has happened: the code was added, and it has been dead ever since, for more than a full year. It will be pretty difficult to talk me again into accepting unused code. However most of the common/ series is code that we depend on and I think might be generally useful. I do admit that in striving for a very high level of polish we have attacked problems that perhaps would not matter for many systems, and thus more patches. Mentioning that you depend on some specific code does not actually make me feel bad, if this is what you (subcounsciously) had in mind. Quote David Woodhouse: If you're out of tree, you don't exist. ( http://article.gmane.org/gmane.linux.kernel.embedded/3534 ) All this discussion confirmed my resolution not to allow for dead code. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The question of whether a computer can think is no more interesting than the question of whether a submarine can swim - Edsgar W. Dijkstra ___ U-Boot mailing list
Re: [U-Boot] [PATCH 00/46] Enhance spear support
Hi Vipin, On 11/02/2012 06:39 PM, Vipin Kumar wrote: This patchset is split in several pieces - Drivers: This is essentially a few new drivers and fixes in already exiasting drivers - Enhancement: This series enhances the already existing spear support - spear13xx: This is a totally new suppoort for spear13xx architecture Thanks for all these patches. This is a massive patch-set. I'll try to review at least some of them later this week. Please be patient. But this amount of patches does raise a question that I discussed a time ago. If you continue to work on upstream U-Boot, which we greatly appreciate, then its perhaps better to create/add an SPEAr U-Boot custodian responsible for the SPEAr related patches. Reviewing, collecting patches and pushing them to Alberts ARM repository. This would take a bit of work from Albert, since without such an custodian all those SPEAr patches would fall into his area. What do you guys think? Albert, what are your thoughts on this? Vipin, would you volunteer to eventually become this SPEAr U-Boot custodian? Or someone else? Just my thought, comments welcome! Thanks, Stefan DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] usb: ehci: Take advantage of the new multi-controller feature for MXC
Dear Lucas Stach, Dear Marek Vasut, Am Mittwoch, den 07.11.2012, 14:25 +0100 schrieb Marek Vasut: Dear Lucas Stach, Dear Marek Vasut, Am Dienstag, den 06.11.2012, 23:35 +0100 schrieb Marek Vasut: I don't see how you transfer DT information into controller # ... There is really no need to pass this information through all the USB stack interfaces. Please explain. Tegra has a two step initialisation: 1. Init the driver at board_init time This is the step where we parse all the DT information and fill in all needed driver internal structures. At this point we do the virt to phys controller ID mapping. Hm ... thinking about it, maybe you can do generic USB Pdata which would contain the controller # and additional pdata (like mmap address etc). 2. For every controller that U-Boot really uses we activate host mode and do the real hardware initialisation at ehci_hcd_init time. Good. If I'm not completely mistaken such a model should align nicely with the upcoming driver model. The driver gets instantiated with information it gathers from global platform data, may it be device tree or any other form of driver related information. Yes, but you don't pass such data through the driver (yet). You need to do that and that's what I asked you to do. We do pass this data to the driver in the form of gd-fdt_blob. This data is driver (not controller) specific, so why would you pass this in at ehci_hcd_init time? Sorry, I don't understand you. But while writing this I think I now see why we miss each others point: the Tegra EHCI driver is only instantiated once and used for all controllers. This probably has to be reworked for the driver model. What do you mean instantiated once? There ALWAYS has to be only a single instance per one controller. Now I would still argue that we should keep the two step init model, first we instantiate the driver with some form of pdata (we can certainly come up with a one-struct-fits-all for this) and later when we are really going to use one specific controller we do the real hardware init. Now we seem to differ about the meaning of the usb stack functions. From your mails I see that you want ehci_hcd_init as the first init step where we instantiate the driver (and therefore need the pdata) No, I don't care what you do in your ehci_hcd_init. And I don't care if you instantiate it there. But I suspect I understand your problem. I suspect the driver shall be instantiated from elsewhere and ehci_hcd_init() call shall only be used to fine-tune (or work around) controller bugs. where I treated it as the second step, because currently it is the point where the upper USB stack levels indicate that they are going to use a specific controller. We should probably come up with some consensus about this before going forward. Sadly my free time is really limited right now, so it's hard for me to keep up even with things I planned to do in the next few weeks, not to speak about playing around with the driver model. You're actually free to not work on that. Concensus is, I think the multi- controller thing is misdesigned and we rather fix it sooner than later. See my comment above about how I'd like to see it. Regards, Lucas Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SMSC LAN9514 on TI DM37x board
Dear Felix Radensky, !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN html head meta content=text/html; charset=ISO-8859-1 http-equiv=Content-Type /head [...] I cannot read this email, ignored, sorry. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mx5: Mark lowlevel_init board-specific code
On 05/11/2012 21:07, Benoît Thébaudeau wrote:
The mx5 lowlevel_init.S contains board-specific code based on the reference
design. Let's keep it since it avoids creating new lowlevel_init files and it
may be used by many boards. But add a config to make it optional in order not
to
cause issues on boards not following this part of the reference design.
Right, and it is correct that this initialisation is not done for all
boards.
Acked-by: Stefano Babic sba...@denx.de
Best regards,
Stefano Babic
Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com
Cc: Stefano Babic sba...@denx.de
Cc: Matt Sealey m...@genesi-usa.com
---
Note for mx51_efikamx and vision2 board maintainers: Check if
CONFIG_SYS_MAIN_PWR_ON should be defined or not for your hardware (I don't
have
your schematics). Anyway, this patch does not change the behavior for these
boards, but it allows to fix a possible existing issue for these boards if
they differ from the mx51evk on this point.
This patch supersedes http://patchwork.ozlabs.org/patch/177296/ .
Changes for v2:
- Rebase after other patch dropped in the original series (changes section
number in doc/README.imx5).
- Rebase after efikamx renamed to mx51_efikamx.
.../arch/arm/cpu/armv7/mx5/lowlevel_init.S|2 +-
{u-boot-imx-bad05afe.orig = u-boot-imx-bad05afe}/doc/README.imx5 |5
+
.../include/configs/mx51_efikamx.h|1 +
.../include/configs/mx51evk.h |1 +
.../include/configs/vision2.h |1 +
5 files changed, 9 insertions(+), 1 deletion(-)
diff --git u-boot-imx-bad05afe.orig/arch/arm/cpu/armv7/mx5/lowlevel_init.S
u-boot-imx-bad05afe/arch/arm/cpu/armv7/mx5/lowlevel_init.S
index 29ec957..6d9396a 100644
--- u-boot-imx-bad05afe.orig/arch/arm/cpu/armv7/mx5/lowlevel_init.S
+++ u-boot-imx-bad05afe/arch/arm/cpu/armv7/mx5/lowlevel_init.S
@@ -396,7 +396,7 @@ ENTRY(lowlevel_init)
mov r10, lr
mov r4, #0 /* Fix R4 to 0 */
-#if defined(CONFIG_MX51)
+#if defined(CONFIG_SYS_MAIN_PWR_ON)
ldr r0, =GPIO1_BASE_ADDR
ldr r1, [r0, #0x0]
orr r1, r1, #1 23
diff --git u-boot-imx-bad05afe.orig/doc/README.imx5
u-boot-imx-bad05afe/doc/README.imx5
index f7eab7d..e08941e 100644
--- u-boot-imx-bad05afe.orig/doc/README.imx5
+++ u-boot-imx-bad05afe/doc/README.imx5
@@ -15,3 +15,8 @@ i.MX5x SoCs.
mode), which causes the effect of this failure to be much lower (in terms
of frequency deviation), avoiding system failure, or at least decreasing
the likelihood of system failure.
+
+1.2 CONFIG_SYS_MAIN_PWR_ON: Trigger MAIN_PWR_ON upon startup.
+This option should be enabled for boards having a SYS_ON_OFF_CTL signal
+connected to GPIO1[23] and triggering the MAIN_PWR_ON signal like in the
+reference designs.
diff --git u-boot-imx-bad05afe.orig/include/configs/mx51_efikamx.h
u-boot-imx-bad05afe/include/configs/mx51_efikamx.h
index ffe771f..a056566 100644
--- u-boot-imx-bad05afe.orig/include/configs/mx51_efikamx.h
+++ u-boot-imx-bad05afe/include/configs/mx51_efikamx.h
@@ -261,5 +261,6 @@
#define CONFIG_SYS_DDR_CLKSEL0
#define CONFIG_SYS_CLKTL_CBCDR 0x59E35145
+#define CONFIG_SYS_MAIN_PWR_ON
#endif
diff --git u-boot-imx-bad05afe.orig/include/configs/mx51evk.h
u-boot-imx-bad05afe/include/configs/mx51evk.h
index 8cf59fe..122871f 100644
--- u-boot-imx-bad05afe.orig/include/configs/mx51evk.h
+++ u-boot-imx-bad05afe/include/configs/mx51evk.h
@@ -235,6 +235,7 @@
#define CONFIG_SYS_DDR_CLKSEL0
#define CONFIG_SYS_CLKTL_CBCDR 0x59E35100
+#define CONFIG_SYS_MAIN_PWR_ON
/*---
* FLASH and environment organization
diff --git u-boot-imx-bad05afe.orig/include/configs/vision2.h
u-boot-imx-bad05afe/include/configs/vision2.h
index 848df88..13c5702 100644
--- u-boot-imx-bad05afe.orig/include/configs/vision2.h
+++ u-boot-imx-bad05afe/include/configs/vision2.h
@@ -196,6 +196,7 @@
/* 166 MHz DDR RAM */
#define CONFIG_SYS_DDR_CLKSEL0
#define CONFIG_SYS_CLKTL_CBCDR 0x19239100
+#define CONFIG_SYS_MAIN_PWR_ON
#define CONFIG_SYS_NO_FLASH
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/13] mx35pdk: Add support for OTG
On 05/11/2012 21:13, Benoît Thébaudeau wrote: Add support for the OTG port on the mx35pdk Personality board. Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com Cc: Stefano Babic sba...@denx.de Cc: Marek Vasut ma...@denx.de --- Note: I have tested this on a similar board, but not on the mx35pdk itself. So please, someone test on mx35pdk. Stefano? Yes, I will do it. -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] microblaze: Remove asm/bitops.h from asm/posix_types.h
The patch include/linux/byteorder: import latest endian definitions from linux (sha1: eef1cf2d5cf1cae5fb76713e912263dedf110aeb) Introduced a lot of compilation failures with unknow types. include/linux/byteorder/big_endian.h:45:1: error: unknown type name '__le64' include/linux/byteorder/big_endian.h: In function '__cpu_to_le64p': include/linux/byteorder/big_endian.h:47:18: error: '__le64' undeclared (first use in this function) include/linux/byteorder/big_endian.h:47:18: note: each undeclared identifier is reported only once for each function it appears in include/linux/byteorder/big_endian.h:47:25: error: expected ';' before '__swab64p' include/linux/byteorder/big_endian.h: At top level: include/linux/byteorder/big_endian.h:49:1: error: unknown type name '__le64' include/linux/byteorder/big_endian.h:53:1: error: unknown type name '__le32' include/linux/byteorder/big_endian.h: In function '__cpu_to_le32p': include/linux/byteorder/big_endian.h:55:18: error: '__le32' undeclared (first use in this function) include/linux/byteorder/big_endian.h:55:25: error: expected ';' before '__swab32p' include/linux/byteorder/big_endian.h: At top level: include/linux/byteorder/big_endian.h:57:1: error: unknown type name '__le32' include/linux/byteorder/big_endian.h:61:1: error: unknown type name '__le16' ... Removing asm/bitops.h solved this problem. Signed-off-by: Michal Simek mon...@monstr.eu --- arch/microblaze/include/asm/posix_types.h |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/arch/microblaze/include/asm/posix_types.h b/arch/microblaze/include/asm/posix_types.h index 9a2cc66..38dc5aa 100644 --- a/arch/microblaze/include/asm/posix_types.h +++ b/arch/microblaze/include/asm/posix_types.h @@ -16,9 +16,6 @@ #ifndef __MICROBLAZE_POSIX_TYPES_H__ #define __MICROBLAZE_POSIX_TYPES_H__ -#include asm/bitops.h - - typedef unsigned int __kernel_dev_t; typedef unsigned long __kernel_ino_t; typedef unsigned long long __kernel_ino64_t; -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP4/Panda: u-boot upgrade v2012.04.01 - v2012.10 breaks RTC wakeups
Hi Sricharan, R Sricharan r.sricha...@ti.com writes: In the latest, pad mux and clocks for all non-essential modules at U-BOOT were removed. This might also cause the problem. We can bring this back in u-boot by adding the following macros and check if it works fine again. include/configs/omap4_common.h -- #define CONFIG_SYS_ENABLE_PADS_ALL #define CONFIG_SYS_CLOCKS_ENABLE_ALL Thanks for the pointer, that got things working again. It's actually CONFIG_SYS_ENABLE_PADS_ALL alone which got things working again. I'm glad to see u-boot going in this direction. In the kernel, we've also been trying to get rid of bootloader dependencies also, but it's clear we haven't got all of them yet. I'll keep digging to see what's missing in the kernel pads setup to get RTC working again. Kevin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/10] arm: Compile cache_disable() with -O2 to avoid failure
Hi Wolfgang,
On Wed, Nov 7, 2012 at 4:55 AM, Wolfgang Denk w...@denx.de wrote:
Dear Simon,
In message
capnjgz38tzr2ztdq5d8fnfgcz9a+-vgjfv0saezjwiqbhh-...@mail.gmail.com you
wrote:
compiler to read the PC back from the stack after the dcache flush -
can you please explain what exactly this means, and which exact
problem it causes?
This is the code without the patch (armv7) using -O0:
0248 cache_disable:
248: e92d4810push{r4, fp, lr}
24c: e28db008add fp, sp, #8
250: e24dd01csub sp, sp, #28
254: e50b0020str r0, [fp, #-32]
258: ee114f10mrc 15, 0, r4, cr1, cr0, {0}
25c: e50b4014str r4, [fp, #-20]
260: e51b3014ldr r3, [fp, #-20]
264: e50b3010str r3, [fp, #-16]
268: eb69bl 14 cp_delay
26c: e51b3020ldr r3, [fp, #-32]
270: e3530004cmp r3, #4
274: 1a07bne 298 cache_disable+0x50
278: e51b3010ldr r3, [fp, #-16]
27c: e2033004and r3, r3, #4
280: e353cmp r3, #0
284: 0a0bbeq 2b8 cache_disable+0x70
288: e51b3020ldr r3, [fp, #-32]
28c: e3833001orr r3, r3, #1
290: e50b3020str r3, [fp, #-32]
294: ebfebl 0 flush_dcache_all
298: e51b3020ldr r3, [fp, #-32]
^
29c: e1e02003mvn r2, r3
2a0: e51b3010ldr r3, [fp, #-16]
2a4: e0023003and r3, r2, r3
2a8: e50b3018str r3, [fp, #-24]
2ac: e51b3018ldr r3, [fp, #-24]
2b0: ee013f10mcr 15, 0, r3, cr1, cr0, {0}
2b4: ea00b 2bc cache_disable+0x74
2b8: e1a0nop ; (mov r0, r0)
2bc: e24bd008sub sp, fp, #8
2c0: e8bd8810pop {r4, fp, pc}
this is the code with the patch:
0124 dcache_disable:
124: e92d4010push{r4, lr}
128: ebb4bl 0 cp_delay
12c: ee114f10mrc 15, 0, r4, cr1, cr0, {0}
130: e3140004tst r4, #4
134: 08bd8010popeq {r4, pc}
138: ebfebl 0 flush_dcache_all
13c: e3c44005bic r4, r4, #5
140: ee014f10mcr 15, 0, r4, cr1, cr0, {0}
144: e8bd8010pop {r4, pc}
I have marked with ^^ the line that I think it dies. I did not
spent a lot of time looking at it - just found the problem with an ICE
and then tried to fix it. I suspect it can be fixed with some sort of
dsb() in flush_dcache_all(), but I am not sure.
The code is actually pretty much different - note that the version
above contains calls to cache_disable() which are not visible in the
code below.
But then - the insn you mark is restoring r3 from the stack, after iut
was stored there right before calling flush_dcache_all(). Why should
this cause problems? And in which way is this read[ing] the PC back
from the stack ? r3 is not the PC, right?
I wish I could easily repeat this, but I am not set up for it now, and
the code bases have moved on. I recall that the PC value read from the
stack (in one of the pop operations0 was wrong.
OK. If I hit it again next time I will try a bit harder to root cause it.
Thanks, and sorry for insisting on a real explanation for obscure
problems.
Well fair enough I think. Maybe someone else will hit it and this
thread will be useful for them to root cause. I find the need for -O0
is much reduced now that the tools are better.
Regards,
SImon
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Teenagers are people who express a burning desire to be different by
dressing exactly alike.
There are some strings. They're just not attached.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] microblaze: Fix compilation warning in ext2_find_next_zero_bit
On 10/05/2012 06:48 PM, Marek Vasut wrote:
Dear Michal Simek,
ext2_find_next_zero_bit must be also static if __swab32 is also static.
Warning:
include/asm/bitops.h:369:22: warning: '__fswab32' is static but
used in inline function 'ext2_find_next_zero_bit'
which is not static [enabled by default]
Signed-off-by: Michal Simek mon...@monstr.eu
---
arch/microblaze/include/asm/bitops.h |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/microblaze/include/asm/bitops.h
b/arch/microblaze/include/asm/bitops.h index e8c835f..eafa2b5 100644
--- a/arch/microblaze/include/asm/bitops.h
+++ b/arch/microblaze/include/asm/bitops.h
@@ -319,7 +319,8 @@ extern __inline__ int ext2_test_bit(int nr, const
volatile void * addr) #define ext2_find_first_zero_bit(addr, size) \
ext2_find_next_zero_bit((addr), (size), 0)
-extern __inline__ unsigned long ext2_find_next_zero_bit(void *addr,
unsigned long size, unsigned long offset) +static inline unsigned long
ext2_find_next_zero_bit(void *addr,
+ unsigned long size, unsigned long offset)
{
unsigned long *p = ((unsigned long *) addr) + (offset 5);
unsigned long result = offset ~31UL;
I'd rather see it done the other way -- drop the inline and let compiler decide.
What are the size penalties ?
With inline
textdata bss dec hex filename
361914 14698 232344 608956 94abc ./u-boot
without inline
textdata bss dec hex filename
361922 14698 232368 608988 94adc ./u-boot
But the problem is that I can see a lot of warnings that this function is
unused.
u-boot/include/asm/bitops.h:322:22: warning: 'ext2_find_next_zero_bit' defined
but not used [-Wunused-function]
FYI: I have just grepped source tree and I see that the same solution is used
by blackfin/mips and powerpc.
$ grep -rn ext2_find_next_zero_bit arch/ | grep static
arch/microblaze/include/asm/bitops.h:322:static inline unsigned long
ext2_find_next_zero_bit(void *addr,
arch/blackfin/include/asm/bitops.h:324:static __inline__ unsigned long
ext2_find_next_zero_bit(void *addr,
arch/mips/include/asm/bitops.h:830:static __inline__ unsigned long
ext2_find_next_zero_bit(void *addr, unsigned long size, unsigned long offset)
arch/powerpc/include/asm/bitops.h:344:static __inline__ unsigned long
ext2_find_next_zero_bit(void *addr,
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] microblaze: Fix compilation failure because of missing libdts
Microblaze platform can use CONFIG_OF_EMBED option
but also it is necessary to support boards
which don't want to use this option.
U-Boot doesn't compile dts/libdts.o for #undef CONFIG_OF_EMBED
case that's why it should be guarded by ifdef.
Signed-off-by: Michal Simek mon...@monstr.eu
---
v2: Change commit message
---
arch/microblaze/cpu/u-boot.lds |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/microblaze/cpu/u-boot.lds b/arch/microblaze/cpu/u-boot.lds
index 4297b93..fe3d97d 100644
--- a/arch/microblaze/cpu/u-boot.lds
+++ b/arch/microblaze/cpu/u-boot.lds
@@ -45,7 +45,9 @@ SECTIONS
.data ALIGN(0x4):
{
__data_start = .;
+#ifdef CONFIG_OF_EMBED
dts/libdts.o (.data)
+#endif
*(.data)
__data_end = .;
}
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/13] mx35pdk: Add support for OTG
On 05/11/2012 21:13, Benoît Thébaudeau wrote: Add support for the OTG port on the mx35pdk Personality board. Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com Cc: Stefano Babic sba...@denx.de Cc: Marek Vasut ma...@denx.de --- Note: I have tested this on a similar board, but not on the mx35pdk itself. So please, someone test on mx35pdk. Stefano? It works on mx35pdk, too ;-) Tested-by: Stefano Babic sba...@denx.de Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] TPM: remove dead code
Hi Wolfgang, On Wed, Nov 7, 2012 at 6:08 AM, Wolfgang Denk w...@denx.de wrote: Dear Simon Glass, In message capnjgz2qyrjfjbjtr9mhcsquev933oawpjstvv-kfrhlcfj...@mail.gmail.com you wrote: OK, but I still don't quite get it. As I asked in the other thread, are you not interested in TPM functionality at all until we have a verified boot implementation, or are you happy to have things progress in stages? I'm will to work through this, and I have the time at present, but I believe that drivers for two common TPM chips are a useful addition to U-Boot regardless. I'm sorry, but I disagree - the drivers may be useful indeed, but as long as there are no users in U-Boot they are just dead weight. So far we have followed the rule not to add dead code - we always asked to add code (drivers) together with any consumers, i. e. other code that provides useful features (at least to one board) that actually needs and uses such drivers. With TPM we made an exception from this rule, based on the expectation that users would be added soon. Then a full year passed, and nothing happened. Really _nothing_. Now you suggest to progress in stages? You mean adding more and more code around, all of which will be unused, until one bright day in a non-foreseeable future some board might get added, that will then use this? Please see my comment below. This is not exactly a proposal that triggers enthusiasm to me. Enthusiasm is a strong word... It's not obvious how to mainline this rather large feature except in pieces. For example, I think I can start on a feature to verify a kernel, but I do want to talk to the TPM as part of that. Instead of working bottom up (which will necessarily result in an approach trying to add unused code) you could do it top down: start indeed with a feature to verify a kernel (oh! we already have that as psrt of the image verification - with simple CRC in the leggacy images, and will optionally all other kinds in FIT images). This verification could initially be an empty function just returning a true value. No TPM is needed for that. Than work top down for there. OK I will see if I can do something there. The TPM is used to verify the kernel version to prevent rollback attacks. That's going to be a big series but in contrast, display, SATA and GPIO patches are ok, but TPM is not? Ummm... are you telling me that contrast, display, SATA and GPIO patches all also add dead code that is not used anywhere? I have not looked closer there because I simply did not expoect this. But if so, the very same rules apply: we do not want to add dead code. Let's take an example. We have AHCI/SATA support in U-Boot. There may be no board code in U-Boot that actually reads from a disk (I am not sure, but it is plausible, since hard-coded disk/fs access from a board's C code would be odd). Let's say this code exists only in commands that may or may not be executed by board scripts, which are out of tree. I'm sure this isn't considered dead code, but I want to understand the difference. If there is a TPM command which may or may not be executed by board scripts (also out of tree), what is the difference? Following this dead code argument, whole U-Boot subsystems are dead code since they are only used indirectly from the command line and not directly by any board code? So my thinking now is that I should: 1. Create a way of extracting verification information from a signed block (e.g. kernel hash, rollback info) 2. Add some commands to access this 3. Create a basic script which uses these commands Does this sound right? I'll see what I can do here, but in principle I feel that adding a driver should be OK, provided a board uses it, without necessarily the high-level code that uses it. After all, we don't necessarily expect to mainline all the scripts that drive the actual boot. what exactly do you mean by a board uses it, without necessarily the high-level code that uses it? If uses for you means just conteining a function call reference so the code gets cimpiled and pulled in by the linker, then I have to tell you that this NOT my understanding of usage. For me, using some code means that it actually performs some _function_. As long as the code is not actually running on the system, it is not being used. OK, see above, I think we are getting to the root of this. And especially not after the experience with the TPM code so far, where my patience has been exhausted after more than a year of nothing happening. Well not nothing. Have been rather tied up getting a product out. I Sorry, but for U-Boot it is completely irrelevant what happens with your out of tree code. The code in mainline has just been sitting there, unused as ever. agree that things have been very quiet on verified boot - perhaps the original upstream author was exhausted after the effort of getting the driver into mainline and retired for a rest
Re: [U-Boot] [PATCH 6/7] fs: Add a Coreboot Filesystem (CBFS) driver and commands
Hi Wolfgang, On Wed, Nov 7, 2012 at 4:38 AM, Wolfgang Denk w...@denx.de wrote: Dear Simon, In message CAPnjgZ0k58-JG+MxvKp=6jxthmpb8pzhp+xfpdnb8jctamt...@mail.gmail.com you wrote: Yes I am now completely lost :-) Me too. Where have I changed the licensing model? Your original request was to remove the CREDITS line I think. I have done that in this patch: http://patchwork.ozlabs.org/patch/197314/ The above discussion about copyright message is separate to that. I Ah... I understood it was part of your intended changes. was looking around the code base for a possible replacement (shorter) message because I thought that was what you were looking for. I found the BSD one, but have not changed any code to use it. So yes, please can you explain what I am missing here? Maybe everything is clear to you, And I just did not understand. I just wanted to point out thatt he misc postings to this topic contained references to different licenses - starting from code under GPLv2+ metioning some BSD license to GPL again. If all this doesn't change the code, I suggest we ignore it all. Sounds good. From my side it was just a discussion on the best license text to use. Regards, Simon Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality. -- Albert Einstein ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] tpm: Add casts for proper compilation
Hi Wolfgang, On Wed, Nov 7, 2012 at 5:06 AM, Wolfgang Denk w...@denx.de wrote: Dear Simon, In message capnjgz2p-re5hp13st-q2cup49azyzzxwnrzsafhr_iusgb...@mail.gmail.com you wrote: I accept that it has sat there for a while without a board config to use it. But I would very much like to keep this code and see no sense in removing it now that it is actually in use. Feel free to re-add it when there are any real users. I've posted a removal patch. Can you please explain what you mean by 'real users'? Are you looking for an entire verified boot implementation before you will accept the TPM driver? What exactly is this driver good for? Which function does it provide that can be used on any board in mainline? It looks to me that it's just sitting there, and does nothing good to anybody. I don't know if there are any other legitimate uses for a TPM driver in U-Boot, but if there are, none appear to be implemented by any mainline board, so why should we have this driver in mainline? I replied on the other thread - hopefully we can agree a plan to move this forward. Regards, Simon Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de While money can't buy happiness, it certainly lets you choose your own form of misery. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/13] mx35pdk: Add support for OTG
Hi Stefano, On Wednesday, November 7, 2012 5:16:47 PM, Stefano Babic wrote: On 05/11/2012 21:13, Benoît Thébaudeau wrote: Add support for the OTG port on the mx35pdk Personality board. Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com Cc: Stefano Babic sba...@denx.de Cc: Marek Vasut ma...@denx.de --- Note: I have tested this on a similar board, but not on the mx35pdk itself. So please, someone test on mx35pdk. Stefano? It works on mx35pdk, too ;-) Tested-by: Stefano Babic sba...@denx.de Great! Thanks for testing. Are you also OK with the other patches in this series? Can I send a v2 with just the change that Marek asked for 13/13? Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/13] mx31: Move EHCI definitions to ehci-fsl.h
On 05/11/2012 23:55, Marek Vasut wrote: Dear Benoît Thébaudeau, The EHCI definitions in i.MX31's imx-regs.h are MXC-generic, so move them to ehci-fsl.h so that all MXC SoCs can use them. Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com Cc: Marek Vasut ma...@denx.de Cc: Stefano Babic sba...@denx.de [...] I'll delegate review of this patchset to Stefano .. .Stefano, is it ok with you? Of course, it is. Best regards, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/13] mx35pdk: Add support for OTG
On 07/11/2012 17:27, Benoît Thébaudeau wrote: Hi Stefano, On Wednesday, November 7, 2012 5:16:47 PM, Stefano Babic wrote: On 05/11/2012 21:13, Benoît Thébaudeau wrote: Add support for the OTG port on the mx35pdk Personality board. Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com Cc: Stefano Babic sba...@denx.de Cc: Marek Vasut ma...@denx.de --- Note: I have tested this on a similar board, but not on the mx35pdk itself. So please, someone test on mx35pdk. Stefano? It works on mx35pdk, too ;-) Tested-by: Stefano Babic sba...@denx.de Great! Thanks for testing. Are you also OK with the other patches in this series? Can I send a v2 with just the change that Marek asked for 13/13? IMHO they are ok, I have not found relevant issues. Best regards, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] PCIe on the i.MX6?
Hi Carolyn, I saw your message on the Denx mailing list. I have the Novpek board with the MX6 quad on it and a full PCIe interface. I am working in the Freescale Linux kernel and to get the interface to work we had to change a clock source for the PCIe. We had to use the LVDS2 as SATA clock source rather than LVDS1 as SATA. This is controlled by the PMU_MISC1 register at offset 0x20c8160. In the reference manual it's section 49.7.6, page 4413. Set the LVDS2_CLK_SEL (bits 9-5) field to SATA (010011b). The original code set LVDS1_CLK_SEL (bits 4-0) to SATA(010011b). Hope this helps. Our current problem is getting a PCIe switch to work with the MX6. The upstream port config space is available but the down stream is not. 0x1f0 is exposed as the upstream config space but I expected the down stream to be at 0x1f1 but nothing there. Let me know if you have any ideas. Have you tried a PCIe switch yet? Thanks, Greg Topmiller Staff Software Engineer 240-404-2620 greg.topmil...@jdsu.com Yes, I have the PCI clocks on. I can read the config space and can see the PCIe bus traffic using a logic analyzer when I do so. When I try reading memory or I/O space, I don't see any bus traffic. Thanks, Carolyn On Thu, Nov 1, 2012 at 11:18 AM, Fabio Estevam festevam at gmail.com wrote: On Thu, Nov 1, 2012 at 2:32 PM, Carolyn Smith carolynsmi56 at gmail.com wrote: Hello, Does anyone have any experience with PCIe on an i.MX6 processor (in particular the i.MX6 Solo)? I can access the config space of my PCIe device but can't seem to get its BARs mapped in properly. I thought I had the viewports set up but when I try to access the space, I just get a processor lockup. Have you turned on the PCI clocks? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] common: add ifdefs around bouncebuf.c body
On 11/07/2012 06:21 AM, Marek Vasut wrote: Dear Stephen Warren, On 11/06/2012 03:57 PM, Marek Vasut wrote: Dear Stephen Warren, On 11/06/2012 03:43 PM, Marek Vasut wrote: Dear Stephen Warren, On 11/05/2012 05:54 PM, Marek Vasut wrote: Dear Stephen Warren, From: Stephen Warren swar...@nvidia.com If a U-Boot config file enables CONFIG_BOUNCE_BUFFER only for the main U-Boot build and not for the SPL, then config.mk will contain CONFIG_BOUNCE_BUFFER=y, so common/Makefile will build bouncebuf.c for both the SPL and main U-Boot, but config.h won't set CONFIG_BOUNCE_BUFFER for the SPL, so bouncebuf.h will provide static inline functions, which will conflict with the compiled bouncebuf.c. Solve this by guarding the body of bouncebuf.c with the ifdef to avoid conflicts. Uh, don't you want the bounce buffer not compiled in for SPL? Then maybe add CONFIG_SPL_BOUNCE_BUFFER to force BB to be compiled into SPL or something ... Not compiling bouncebuf.c for SPL would solve this too. I have no idea what build system contortions would be required to do this though. Do you think the build system should be fixed first rather than taking this series/patch? I guess we shouldn't need a separate CONFIG_SPL_BOUNCE_BUFFER option though; we should rather simply set CONFIG_SPL_BOUNCE_BUFFER appropriately for SPL and non-SPL, and have everything key off that one variable, right? How will you be able to configure it separately for spl and non-spl ? For example, include/configs/trimslice.h contains: /* SD/MMC */ #define CONFIG_MMC #define CONFIG_GENERIC_MMC #define CONFIG_TEGRA_MMC #define CONFIG_CMD_MMC However, we don't use MMC in our SPL, but don't want to pollute every Tegra board file with ifdefs for SPL, so include/configs/tegra-common-post.h (which is included at the end of trimslice.h) contains: #ifdef CONFIG_SPL_BUILD ... /* remove MMC support */ #ifdef CONFIG_MMC #undef CONFIG_MMC #endif #ifdef CONFIG_GENERIC_MMC #undef CONFIG_GENERIC_MMC #endif #ifdef CONFIG_TEGRA_MMC #undef CONFIG_TEGRA_MMC #endif #ifdef CONFIG_CMD_MMC #undef CONFIG_CMD_MMC #endif ... #endif And in the V1 patch I proposed to tegra-common-post.h, I added the following at the end: #ifdef CONFIG_TEGRA_MMC #define CONFIG_BOUNCE_BUFFER #endif Yet, this doesn't solve the problem with SPL ... since for SPL, you'd have to do ifdef CONFIG_SPL, no? Sorry, what problem with the SPL is this not solving? I think I was tired when replying (sorry, the conference is really heavy on me). I though you wanted to disable BB only for SPL, but now I see BB being enabled depends on tegra mmc. btw. shouldn't --gc-sections remove BB code if it's not used at all? Yes, I assume so. In v2 of the patch series I have simply enabled CONFIG_BOUNCE_BUFFER unconditionally on Tegra, which removes the need for any SPL-specific changes. Before enabling it: Configuring for trimslice board... textdata bss dec hex filename 2456259304 274968 529897 815e9 ./u-boot 14451 208 72 14731398b ./spl/u-boot-spl After enabling it: Configuring for trimslice board... textdata bss dec hex filename 2457429304 274964 530010 8165a ./u-boot 14451 208 72 14731398b ./spl/u-boot-spl SPL didn't change since, so this seems to be working fine. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx35pdk:Use IMX_GPIO_NR macro
Use IMX_GPO_NR macro Signed-off-by: Ashok Kumar Reddy ashokkourla2...@gmail.com --- board/freescale/mx35pdk/mx35pdk.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/freescale/mx35pdk/mx35pdk.c b/board/freescale/mx35pdk/mx35pdk.c index 7cb6b30..e9b3827 100644 --- a/board/freescale/mx35pdk/mx35pdk.c +++ b/board/freescale/mx35pdk/mx35pdk.c @@ -246,7 +246,7 @@ int board_late_init(void) mxc_request_iomux(MX35_PIN_COMPARE, MUX_CONFIG_GPIO); mxc_iomux_set_input(MUX_IN_GPIO1_IN_5, INPUT_CTL_PATH0); - gpio_direction_output(37, 1); + gpio_direction_output(IMX_GPIO_NR(2, 5), 1); } val = mc9sdz60_reg_read(MC9SDZ60_REG_GPIO_1) | 0x04; -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] configs:Remove unused macro CONFIG_DISCOVER_PHY
Remove unused macro CONFIG_DISCOVER_PHY from configs. Signed-off-by: Ashok Kumar Reddy ashokkourla2...@gmail.com --- include/configs/apx4devkit.h |1 - include/configs/sc_sps_1.h |1 - 2 files changed, 2 deletions(-) diff --git a/include/configs/apx4devkit.h b/include/configs/apx4devkit.h index 6764b47..73c66af 100644 --- a/include/configs/apx4devkit.h +++ b/include/configs/apx4devkit.h @@ -175,7 +175,6 @@ #define CONFIG_FEC_MXC_PHYADDR 0 #define IMX_FEC_BASE MXS_ENET0_BASE #define CONFIG_MII -#define CONFIG_DISCOVER_PHY #define CONFIG_FEC_XCV_TYPERMII #endif diff --git a/include/configs/sc_sps_1.h b/include/configs/sc_sps_1.h index f5dc393..6140d5b 100644 --- a/include/configs/sc_sps_1.h +++ b/include/configs/sc_sps_1.h @@ -160,7 +160,6 @@ #define CONFIG_FEC_MXC #define CONFIG_FEC_MXC_MULTI #define CONFIG_MII -#define CONFIG_DISCOVER_PHY #define CONFIG_FEC_XCV_TYPERMII #define CONFIG_PHYLIB #define CONFIG_PHY_SMSC -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx35pdk:Use IMX_GPIO_NR macro
On 07/11/2012 18:37, Ashok Kumar Reddy wrote: Use IMX_GPO_NR macro Signed-off-by: Ashok Kumar Reddy ashokkourla2...@gmail.com --- board/freescale/mx35pdk/mx35pdk.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/freescale/mx35pdk/mx35pdk.c b/board/freescale/mx35pdk/mx35pdk.c index 7cb6b30..e9b3827 100644 --- a/board/freescale/mx35pdk/mx35pdk.c +++ b/board/freescale/mx35pdk/mx35pdk.c @@ -246,7 +246,7 @@ int board_late_init(void) mxc_request_iomux(MX35_PIN_COMPARE, MUX_CONFIG_GPIO); mxc_iomux_set_input(MUX_IN_GPIO1_IN_5, INPUT_CTL_PATH0); - gpio_direction_output(37, 1); + gpio_direction_output(IMX_GPIO_NR(2, 5), 1); } val = mc9sdz60_reg_read(MC9SDZ60_REG_GPIO_1) | 0x04; Acked-by: Stefano Babic sba...@denx.de Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] configs:Remove unused macro CONFIG_DISCOVER_PHY
On 07/11/2012 18:39, Ashok Kumar Reddy wrote: Remove unused macro CONFIG_DISCOVER_PHY from configs. Signed-off-by: Ashok Kumar Reddy ashokkourla2...@gmail.com --- include/configs/apx4devkit.h |1 - include/configs/sc_sps_1.h |1 - 2 files changed, 2 deletions(-) diff --git a/include/configs/apx4devkit.h b/include/configs/apx4devkit.h index 6764b47..73c66af 100644 --- a/include/configs/apx4devkit.h +++ b/include/configs/apx4devkit.h @@ -175,7 +175,6 @@ #define CONFIG_FEC_MXC_PHYADDR 0 #define IMX_FEC_BASE MXS_ENET0_BASE #define CONFIG_MII -#define CONFIG_DISCOVER_PHY #define CONFIG_FEC_XCV_TYPE RMII #endif diff --git a/include/configs/sc_sps_1.h b/include/configs/sc_sps_1.h index f5dc393..6140d5b 100644 --- a/include/configs/sc_sps_1.h +++ b/include/configs/sc_sps_1.h @@ -160,7 +160,6 @@ #define CONFIG_FEC_MXC #define CONFIG_FEC_MXC_MULTI #define CONFIG_MII -#define CONFIG_DISCOVER_PHY #define CONFIG_FEC_XCV_TYPE RMII #define CONFIG_PHYLIB #define CONFIG_PHY_SMSC Acked-by: Stefano Babic sba...@denx.de Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SMSC LAN9514 on TI DM37x board
Hi Ilya, On 11/06/2012 01:01 PM, Ilya Yanok wrote: On Tue, Nov 6, 2012 at 9:24 AM, Felix Radensky fe...@embedded-sol.com mailto:fe...@embedded-sol.com wrote: Hi Marek, On 11/06/2012 12:57 AM, Marek Vasut wrote: Can you please avoid top-posting? Does U-Boot even support your USB device? Sorry about top-posting. My USB device is supported by smsc95xx.c driver in drivers/usb/eth. Judging by the portion of config you cited you don't have it enabled. But I don't think that's your current problem (you should see your device after usb start even if there is no driver for it). I'd verify PHY configuration if I were you. Regards, Ilya. Thanks for replying. I do have the following definitions as well: #define CONFIG_USB_HOST_ETHER #define CONFIG_USB_ETHER_SMSC95XX I'm going to compare u-boot and kernel PHY initializations. They are not the same, and in linux everything works. Felix. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] USB: add arrow key support to usb_kbd
On Wed, Nov 07, 2012 at 05:18:27AM -0800, Marek Vasut wrote: Dear Stephen Warren, On 11/06/2012 03:56 PM, Marek Vasut wrote: Dear Simon Glass, Hi Marek, On Tue, Nov 6, 2012 at 2:49 PM, Marek Vasut ma...@denx.de wrote: Dear Allen Martin, Check for scancodes for arrow keys and map them to ^F/^B, ^N/^P. Control characters are used instead of ANSI sequence because the queueing code in usb_kbd doesn't handle the data increase when one keypress generates 3 keycodes. The real fix is to convert this driver to use the input subsystem and queue If it's the real fix, then why not go for the real fix right away? :-( Because it's a fair chunk of work Let's either do it properly or not at all ... if I let you do these semi- complete fixes, we'll end up with a stinking pile of crap like windows ... Marek, I find this attitude a little ridiculous. If everything was fixed completely the first time around, there would be no work left to do; we'd just stop developing U-Boot. Equally, if this small addition to the USB keyboard code is so bad it can't be allowed since the whole driver must be re-written instead, why was the existing code allowed into U-Boot in the first place? Because evil b*tch (=me) wasn't around in the first place ;-) Anyway ... I'll apply it (not because of your whining and stuff ... but because it's beneficial). Though, I'd be really glad if you invested time to rework the driver. Otherwise, it'll be me who'll end up doing the work and I'd prefer to delegate it to someone who brough the issue up sooner ;-) Thanks Marek, I'd be happy to rework this driver if no one else wants to do it. I just can't sign up to do it right now as there are some tegra specific things (like USB gadget support, and enabling thumb) that are more important to me and my employer to do first, and I only work on u-boot on the side so I have limited bandwidth. It sounds like we're all in violent agreement that moving the driver to the input subsystem is the right thing to do, and if someone is eager to work on it before I have a chance to I'm happy to review patches. Incremental small patches are good; they allow small simple things to be implemented without causing massive disruption. That's great for locating any regressions. Is there anything actually technically wrong with this specific patch? I would say no; it's very simple, non-invasive, low-risk, doesn't appear to introduce any long-term maintenance burden, doesn't completely prevent or remotely hinder reworking the USB keyboard support in the future, etc. Best regards, Marek Vasut -Allen -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] TPM: remove dead code
Dear Simon, In message CAPnjgZ0V=MwiVYQ3H-dsVEpNVHMdOPx3Yh3qtPdje0=_Cz=s...@mail.gmail.com you wrote: This is not exactly a proposal that triggers enthusiasm to me. Enthusiasm is a strong word... I tried to find a strictly non-negative phrasing here, because I felt that would be somewhat better ;-) Let's take an example. We have AHCI/SATA support in U-Boot. There may be no board code in U-Boot that actually reads from a disk (I am not sure, but it is plausible, since hard-coded disk/fs access from a board's C code would be odd). Let's say this code exists only in commands that may or may not be executed by board scripts, which are out of tree. I'm sure this isn't considered dead code, but I want to As soon as I can type on the console something like ext2load sata 0:1 20 boot/uImage and this is actually capable of reading data from a S-ATA attached storage device, then this is perfectly fine: the driver provides a functionality, which can be used in U-Boot to perform certain actions on the real system. understand the difference. If there is a TPM command which may or may not be executed by board scripts (also out of tree), what is the difference? If there is a TPM command which actually communicates with the TPM hardware and can be used for example to verify an image checksum or such, then it provides a function. Following this dead code argument, whole U-Boot subsystems are dead code since they are only used indirectly from the command line and not directly by any board code? This is not what I mean. So my thinking now is that I should: 1. Create a way of extracting verification information from a signed block (e.g. kernel hash, rollback info) 2. Add some commands to access this 3. Create a basic script which uses these commands Does this sound right? 3. would actually not be needed, as long as 1. and 2. really work on some system. Comment for 1. (but not relateds to this thread, just a note while we are at it): I imagine such functionality should be integrated with the FIT image handling, i. e. like we are today able to verify - say - a sha256 checksum of an image, your code would be able to verify a TPM backed signature. Does this match your plans? So long as I can understand the definition then we should be fine. Can we agree on something like: code is considered to be used (in the sense of it is no dead code) when there is at least one board configuration in mainline where, either as part of the normal initialization sequence or as reaction to some interactive user command, said code will be executed and perform the specific function it was designed for ? As a side effect this means that there is at least one board configuration that will actually compile and link this piece of code. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Free markets select for winning solutions.- Eric S. Raymond ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] PCIe on the i.MX6?
Hi Greg, What is the exact value of your PMU_MISC1 register? Did you change the code to clear LVDSCLK2_IBEN and set LVDSCLK2_OBEN as well? We haven't tried a PCIe switch. We just have an FPGA directly connected to the i.MX6. Thanks, Carolyn On Wed, Nov 7, 2012 at 8:38 AM, Greg Topmiller greg.topmil...@jdsu.comwrote: Hi Carolyn, I saw your message on the Denx mailing list. I have the Novpek board with the MX6 quad on it and a full PCIe interface. I am working in the Freescale Linux kernel and to get the interface to work we had to change a clock source for the PCIe. We had to use the LVDS2 as SATA clock source rather than LVDS1 as SATA. This is controlled by the PMU_MISC1 register at offset 0x20c8160. In the reference manual it's section 49.7.6, page 4413. Set the LVDS2_CLK_SEL (bits 9-5) field to SATA (010011b). The original code set LVDS1_CLK_SEL (bits 4-0) to SATA(010011b). Hope this helps. Our current problem is getting a PCIe switch to work with the MX6. The upstream port config space is available but the down stream is not. 0x1f0 is exposed as the upstream config space but I expected the down stream to be at 0x1f1 but nothing there. Let me know if you have any ideas. Have you tried a PCIe switch yet? Thanks, Greg Topmiller Staff Software Engineer 240-404-2620 # greg.topmil...@jdsu.com Yes, I have the PCI clocks on. I can read the config space and can see the PCIe bus traffic using a logic analyzer when I do so. When I try reading memory or I/O space, I don't see any bus traffic. Thanks, Carolyn On Thu, Nov 1, 2012 at 11:18 AM, Fabio Estevam festevam at gmail.com wrote: On Thu, Nov 1, 2012 at 2:32 PM, Carolyn Smith carolynsmi56 at gmail.com wrote: Hello, Does anyone have any experience with PCIe on an i.MX6 processor (in particular the i.MX6 Solo)? I can access the config space of my PCIe device but can't seem to get its BARs mapped in properly. I thought I had the viewports set up but when I try to access the space, I just get a processor lockup. Have you turned on the PCI clocks? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] TPM: remove dead code
Hi Wolfgang, On Wed, Nov 7, 2012 at 11:35 AM, Wolfgang Denk w...@denx.de wrote: Dear Simon, In message CAPnjgZ0V=MwiVYQ3H-dsVEpNVHMdOPx3Yh3qtPdje0=_Cz=s...@mail.gmail.com you wrote: This is not exactly a proposal that triggers enthusiasm to me. Enthusiasm is a strong word... I tried to find a strictly non-negative phrasing here, because I felt that would be somewhat better ;-) Much appreciated :-) Let's take an example. We have AHCI/SATA support in U-Boot. There may be no board code in U-Boot that actually reads from a disk (I am not sure, but it is plausible, since hard-coded disk/fs access from a board's C code would be odd). Let's say this code exists only in commands that may or may not be executed by board scripts, which are out of tree. I'm sure this isn't considered dead code, but I want to As soon as I can type on the console something like ext2load sata 0:1 20 boot/uImage and this is actually capable of reading data from a S-ATA attached storage device, then this is perfectly fine: the driver provides a functionality, which can be used in U-Boot to perform certain actions on the real system. understand the difference. If there is a TPM command which may or may not be executed by board scripts (also out of tree), what is the difference? If there is a TPM command which actually communicates with the TPM hardware and can be used for example to verify an image checksum or such, then it provides a function. Following this dead code argument, whole U-Boot subsystems are dead code since they are only used indirectly from the command line and not directly by any board code? This is not what I mean. So my thinking now is that I should: 1. Create a way of extracting verification information from a signed block (e.g. kernel hash, rollback info) 2. Add some commands to access this 3. Create a basic script which uses these commands Does this sound right? 3. would actually not be needed, as long as 1. and 2. really work on some system. OK I think I understand this now. I will take a look at this and see what I can come up with. Comment for 1. (but not relateds to this thread, just a note while we are at it): I imagine such functionality should be integrated with the FIT image handling, i. e. like we are today able to verify - say - a sha256 checksum of an image, your code would be able to verify a TPM backed signature. Does this match your plans? That would be nice. That format seems almost infinitely flexible so we should be able to make it work. Still, I believe the FIT image itself needs to be signed. If we try to sign the components of the FIT image, then I think we will get into trouble because it will need multiple crypto operations to verify each piece (and there might be a lot of pieces if we have a lot of FDTs inside). If we try to put the whole-FIT-image signature inside the FIT image, then we have a chicken and egg problem - we cannot sign it until we know what is in it, but we can't know what is in it until we know the signature. One option would be to embed a FIT image inside a FIT image, like this: + Top Level FIT Image---+ | | |* Hash of embedded FIT image, signed with secret key | | | |+---Embedded FIT Image-+ | || | | || kernels | | || fdts| | || configs | | || | | |+--+ | | | +---+ But this is not ideal because we have to verify the whole image (including the large kernel) just to check its version / compatibility (we may have several kernel options and be trying to pick the best). Ideally we would be able to split the FIT image into a meta-data piece and a data piece, so we can verify the meta-data all at once with a single key, and the data only as needed when we decide we want to load a particular kernel. The FDT format sort-of does this, but I believe the kernel is embedded as a blob, so in practice we can't separate the two. Right? I will think about it some more. So long as I can understand the definition then we should be fine. Can we agree on something like: code is considered to be used (in the sense of it is no dead code) when there is at least one board configuration in mainline where, either as part of the normal initialization sequence or as reaction to some interactive user command, said code will be executed and perform the specific function it was designed for ? As a side
Re: [U-Boot] [Drivers PATCH 17/19] imls: Add support to list images in NAND device
On 11/06/2012 11:15:42 PM, Vipin Kumar wrote:
On 11/7/2012 5:00 AM, Scott Wood wrote:
On 11/02/2012 12:40:02 PM, Vipin Kumar wrote:
+#if defined(CONFIG_CMD_NAND)
+ printf(\n);
+ nand_info_t *nand;
+ image_header_t image_header;
+ image_header_t *header = image_header;
+ int nand_dev = nand_curr_device;
+ unsigned long img_size;
+ size_t hdr_size, read_len;
+ loff_t off;
+ unsigned int crc;
+ u_char *data;
+
+ /* the following commands operate on the current device */
+ if (nand_dev 0 || nand_dev = CONFIG_SYS_MAX_NAND_DEVICE) {
+ puts(\nNo NAND devices available\n);
+ return 0;
+ }
Please move the NAND and NOR code into their own functions.
You mean I can separate the NOR list images code in one routine and
NAND in another?
Yes.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 14/17] console: Call overwrite_console before searching for console devices
Hi Wolfgang, On Sat, Nov 3, 2012 at 8:32 AM, Wolfgang Denk w...@denx.de wrote: Dear Simon Glass, In message 1351902453-27956-15-git-send-email-...@chromium.org you wrote: From: Anton Staaf robot...@chromium.org Move the overwrite_console function call to before the search for the console devices. This lets the board specific function replace the environment variables and have that picked up by the console code. Can you please explain what replace the environment variables means, and how this is related to the console code? It allows the environment variables (e.g. stdin) to be changed by the overwrite_console function call. I have had another look at this, and I believe that Allen Warren's patch last week for Tegra does a similar thing: http://patchwork.ozlabs.org/patch/196412/ So I think we can drop this patch. Regards, Simon Or what exactly this patch is needed for? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Mike's Law: For a lumber company employing two men and a cut-off saw, the marginal product of labor for any number of additional workers equals zero until the acquisition of another cut-off saw. Let's not even consider a chainsaw. - Mike Dennison [You could always schedule the saw, though - ed.] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: add CONSOLE_MUX support to tegra-kbc
Hi Allen,
On Thu, Nov 1, 2012 at 4:41 PM, Allen Martin amar...@nvidia.com wrote:
Add support for CONSOLE_MUX to tegra-kbc driver. This requires
adding a flag to struct keyb to know the driver has already been
initialized so if we try to initialize it again we can just return
success. Also call into iomux_doenv() from drv_keyboard_init to
re-evaluate the stdin string.
Signed-off-by: Allen Martin amar...@nvidia.com
---
drivers/input/tegra-kbc.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/input/tegra-kbc.c b/drivers/input/tegra-kbc.c
index ab7a9e3..88471d3 100644
--- a/drivers/input/tegra-kbc.c
+++ b/drivers/input/tegra-kbc.c
@@ -63,6 +63,7 @@ static struct keyb {
struct kbc_tegra *kbc; /* tegra keyboard controller */
unsigned char inited; /* 1 if keyboard has been inited */
unsigned char first_scan; /* 1 if this is our first key scan */
+ unsigned char created; /* 1 if driver has been created */
/*
* After init we must wait a short time before polling the keyboard.
@@ -306,6 +307,10 @@ static void tegra_kbc_open(void)
*/
static int init_tegra_keyboard(void)
{
+ /* check if already created */
+ if (config.created)
+ return 0;
+
I think this code should go after the 'int node' declaration, shouldn't it?
#ifdef CONFIG_OF_CONTROL
int node;
@@ -349,6 +354,7 @@ static int init_tegra_keyboard(void)
config_kbc_gpio(config.kbc);
tegra_kbc_open();
+ config.created = 1;
debug(%s: Tegra keyboard ready\n, __func__);
return 0;
@@ -357,6 +363,8 @@ static int init_tegra_keyboard(void)
int drv_keyboard_init(void)
{
struct stdio_dev dev;
+ char *stdinname = getenv(stdin);
+ int error;
if (input_init(config.input, 0)) {
debug(%s: Cannot set up input\n, __func__);
@@ -372,5 +380,13 @@ int drv_keyboard_init(void)
dev.start = init_tegra_keyboard;
/* Register the device. init_tegra_keyboard() will be called soon */
- return input_stdio_register(dev);
+ error = input_stdio_register(dev);
+ if (error)
+ return error;
+#ifdef CONFIG_CONSOLE_MUX
+ error = iomux_doenv(stdin, stdinname);
+ if (error)
+ return error;
+#endif
+ return 0;
}
--
1.7.10.4
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] common: fix help command breakage
On Mon, Nov 5, 2012 at 9:44 PM, Henrik Nordström hen...@henriknordstrom.net wrote: mån 2012-11-05 klockan 19:51 -0600 skrev Kim Phillips: commit 199adb601ff34bdbbd0667fac80dfe0a87bffc2b common/misc: sparse fixes broke the help command trying to fix the sparse error command.c:44:38: error: bad constant expression. As Henrik points out, the fix was bad because the commit used CONFIG_SYS_MAXARGS whereas the code intended to use the maximum number of commands (not arguments to a command). this patch fixes both by making the allocation manually on the heap. Reported-by: Henrik Nordström hen...@henriknordstrom.net Signed-off-by: Kim Phillips kim.phill...@freescale.com Tested-by: Simon Glass s...@chromium.org Acked-by: Simon Glass s...@chromium.org Tested-by: Henrik Nordström hen...@henriknordstrom.net ___ 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] [RFC, PATCH] mmc: prepare SDHCI_HOST_CONTROL for SDMA operation
modification for commit 804c7f422169212e92530e1ddaf74bf1ca9ebfa1
The original patch contained a bug.
Using a char with sdhci_readl/sdhci_writel operation.
The adjacent bytes to SDHCI_HOST_CONTROL (specially SDHCI_POWER_CONTROL)
get mangled and can result in the controller entering an unstable state.
This patch also moves the process inside sdhci_init().
Signed-off-by: Rommel G Custodio sessya...@gmail.com
---
drivers/mmc/sdhci.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 7845f87..fae2169 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -82,13 +82,6 @@ static int sdhci_transfer_data(struct sdhci_host *host,
struct mmc_data *data,
unsigned int start_addr)
{
unsigned int stat, rdy, mask, timeout, block = 0;
-#ifdef CONFIG_MMC_SDMA
- unsigned char ctrl;
- ctrl = sdhci_readl(host, SDHCI_HOST_CONTROL);
- ctrl = ~SDHCI_CTRL_DMA_MASK;
- ctrl |= SDHCI_CTRL_SDMA;
- sdhci_writel(host, ctrl, SDHCI_HOST_CONTROL);
-#endif
timeout = 100;
rdy = SDHCI_INT_SPACE_AVAIL | SDHCI_INT_DATA_AVAIL;
@@ -386,6 +379,14 @@ int sdhci_init(struct mmc *mmc)
{
struct sdhci_host *host = (struct sdhci_host *)mmc-priv;
+#ifdef CONFIG_MMC_SDMA
+ unsigned int ctrl;
+ ctrl = sdhci_readl(host, SDHCI_HOST_CONTROL);
+ ctrl = ~SDHCI_CTRL_DMA_MASK;
+ ctrl |= SDHCI_CTRL_SDMA;
+ sdhci_writel(host, ctrl, SDHCI_HOST_CONTROL);
+#endif
+
if ((host-quirks SDHCI_QUIRK_32BIT_DMA_ADDR) !aligned_buffer) {
aligned_buffer = memalign(8, 512*1024);
if (!aligned_buffer) {
--
1.8.0
pgpQ5myWfhh7F.pgp
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/8 v2] TMU: Add u-boot command to read current temp
Hi Hatim,
On Wed, Nov 7, 2012 at 5:08 AM, Hatim Ali hatim...@samsung.com wrote:
From: Alim Akhtar alim.akh...@samsung.com
Adds a new u-boot command to read current temprature from tmu driver.
Signed-off-by: Alim Akhtar alim.akh...@samsung.com
Acked-by: Simon Glass s...@chromium.org
Sorry I missed this before, but I think you are supposed to update the
README and add to include/command_h.
Regards,
Simon
---
Changes since v1:
- Include new generic tmu header file
- Made printf()s consistent
- Added Acked-by: Simon Glass
common/Makefile |1 +
common/cmd_tmu.c | 51 +++
2 files changed, 52 insertions(+), 0 deletions(-)
create mode 100644 common/cmd_tmu.c
diff --git a/common/Makefile b/common/Makefile
index dca2f53..b56ffa2 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -159,6 +159,7 @@ COBJS-$(CONFIG_CMD_STRINGS) += cmd_strings.o
COBJS-$(CONFIG_CMD_TERMINAL) += cmd_terminal.o
COBJS-$(CONFIG_CMD_TIME) += cmd_time.o
COBJS-$(CONFIG_SYS_HUSH_PARSER) += cmd_test.o
+COBJS-$(CONFIG_CMD_TMU) += cmd_tmu.o
COBJS-$(CONFIG_CMD_TPM) += cmd_tpm.o
COBJS-$(CONFIG_CMD_TSI148) += cmd_tsi148.o
COBJS-$(CONFIG_CMD_UBI) += cmd_ubi.o
diff --git a/common/cmd_tmu.c b/common/cmd_tmu.c
new file mode 100644
index 000..7fbf845
--- /dev/null
+++ b/common/cmd_tmu.c
@@ -0,0 +1,51 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics
+ * Alim Akhtar alim.akh...@samsung.com
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include command.h
+#include tmu.h
+
+int do_tmu(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ int cur_temp;
+
+ if (argc 2)
+ return CMD_RET_USAGE;
+
+ if (strcmp(argv[1], curtemp) == 0) {
+ if (tmu_monitor(cur_temp) == -1)
+ printf(TMU is in unknown state, temperature is
invalid \n);
+ else
+ printf(Current temperature: %u degrees Celsius \n,
cur_temp);
+ } else {
+ return CMD_RET_USAGE;
+ }
+
+ return 0;
+}
+
+U_BOOT_CMD(
+ tmu, 2, 1, do_tmu,
+ Thermal Management Unit\n,
+ curtemp - show current CPU temperature in degrees Celsius\n
+);
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/8 v2] EXYNOS5: TMU: Add driver for Thermal Management Unit
Hi Hatim,
On Wed, Nov 7, 2012 at 5:08 AM, Hatim Ali hatim...@samsung.com wrote:
From: Akshay Saraswat aksha...@samsung.com
Adding Exynos Thermal Management Unit driver to monitor SOC
temperature and take actions corresponding to states of TMU.
System will shutdown if tripping temperature is reached.
Signed-off-by: Akshay Saraswat aksha...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes since v1:
- Added new generic header file include/tmu.h
- Added Acked-by: Simon Glass
arch/arm/include/asm/arch-exynos/exynos-tmu.h | 58 +
drivers/power/Makefile|1 +
drivers/power/exynos-tmu.c| 297
+
include/tmu.h | 46
4 files changed, 402 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/arch-exynos/exynos-tmu.h
create mode 100644 drivers/power/exynos-tmu.c
create mode 100644 include/tmu.h
diff --git a/arch/arm/include/asm/arch-exynos/exynos-tmu.h
b/arch/arm/include/asm/arch-exynos/exynos-tmu.h
new file mode 100644
index 000..adfaf0d
--- /dev/null
+++ b/arch/arm/include/asm/arch-exynos/exynos-tmu.h
@@ -0,0 +1,58 @@
+/*
+ * Copyright (c) 2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ * Akshay Saraswat aksha...@samsung.com
+ *
+ * EXYNOS - Thermal Management Unit
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef __ASM_ARCH_THERMAL_H
+#define __ASM_ARCH_THERMAL_H
Suggest renaming this to ASM_ARCH_TMU_H
+
+struct tmu_reg {
+ unsigned triminfo;
+ unsigned rsvd1;
+ unsigned rsvd2;
+ unsigned rsvd3;
+ unsigned rsvd4;
+ unsigned triminfo_control;
+ unsigned rsvd5;
+ unsigned rsvd6;
+ unsigned tmu_control;
+ unsigned rsvd7;
+ unsigned tmu_status;
+ unsigned sampling_internal;
+ unsigned counter_value0;
+ unsigned counter_value1;
+ unsigned rsvd8;
+ unsigned rsvd9;
+ unsigned current_temp;
+ unsigned rsvd10;
+ unsigned rsvd11;
+ unsigned rsvd12;
+ unsigned threshold_temp_rise;
+ unsigned threshold_temp_fall;
+ unsigned rsvd13;
+ unsigned rsvd14;
+ unsigned past_temp3_0;
+ unsigned past_temp7_4;
+ unsigned past_temp11_8;
+ unsigned past_temp15_12;
+ unsigned inten;
+ unsigned intstat;
+ unsigned intclear;
+ unsigned rsvd15;
+ unsigned emul_con;
+};
+#endif /* __ASM_ARCH_THERMAL_H */
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 6bf388c..192a7cb 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -30,6 +30,7 @@ COBJS-$(CONFIG_TPS6586X_POWER)+= tps6586x.o
COBJS-$(CONFIG_TWL4030_POWER) += twl4030.o
COBJS-$(CONFIG_TWL6030_POWER) += twl6030.o
COBJS-$(CONFIG_TWL6035_POWER) += twl6035.o
+COBJS-$(CONFIG_EXYNOS_TMU) += exynos-tmu.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/power/exynos-tmu.c b/drivers/power/exynos-tmu.c
new file mode 100644
index 000..ce71408
--- /dev/null
+++ b/drivers/power/exynos-tmu.c
@@ -0,0 +1,297 @@
+/*
+ * Copyright (c) 2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ * Akshay Saraswat aksha...@samsung.com
+ *
+ * EXYNOS - Thermal Management Unit
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include errno.h
+#include fdtdec.h
+#include tmu.h
+#include asm/arch/exynos-tmu.h
+
+#define TRIMINFO_RELOAD1
+#define CORE_EN1
+
+#define INTEN_RISE01
+#define INTEN_RISE1(1 4)
+#define INTEN_RISE2(1 8)
+#define INTEN_FALL0(1 16)
+#define INTEN_FALL1(1 20)
+#define INTEN_FALL2(1 24)
+
+#define TRIM_INFO_MASK 0xff
+
+#define INTCLEAR_RISE0 1
+#define INTCLEAR_RISE1 (1 4)
+#define INTCLEAR_RISE2 (1 8)
+#define INTCLEAR_FALL0
Re: [U-Boot] [PATCH 0/8 v2] Add TMU support for Exynos5250 based SMDK5250
Hi Hatim, On Wed, Nov 7, 2012 at 5:08 AM, Hatim Ali hatim...@samsung.com wrote: This patch series adds support for TMU driver using device tree for Exynos5250 based SMDK5250 board. This patch series is dependent on the patch series Add DT based ethernet driver for SMDK5250 by Hatim Ali Changes since v1: - Created new generic header file include/tmu.h - Removed GEN tag from subject in 2 patches - Changed description comments for couple of functions - Added Acked-by to all the patches Akshay Saraswat (6): EXYNOS5: FDT: Add TMU device node values EXYNOS5: TMU: Add driver for Thermal Management Unit EXYNOS5: Power down API for Thermal Management Unit Add a poll function to monitor events EXYNOS5: TMU: Add TMU status polling EXYNOS5: Config: Enable support for Exynos TMU driver Alim Akhtar (2): TMU: Add u-boot command to read current temp EXYNOS5: Config: Enable tmu command I reviewed this again and apart from two minor comments in two of the patches, it looks good. I replied to those patches separately. Regards, Simon README|7 + arch/arm/cpu/armv7/exynos/power.c | 15 ++ arch/arm/dts/exynos5250.dtsi |5 + arch/arm/include/asm/arch-exynos/exynos-tmu.h | 58 + arch/arm/include/asm/arch-exynos/power.h |8 + board/samsung/dts/exynos5250-smdk5250.dts | 13 + board/samsung/smdk5250/smdk5250.c | 36 +++ common/Makefile |1 + common/cmd_tmu.c | 51 + common/console.c |5 + doc/device-tree-bindings/exynos/tmu.txt | 35 +++ drivers/power/Makefile|1 + drivers/power/exynos-tmu.c| 297 + include/common.h |6 + include/configs/exynos5250-dt.h |7 + include/fdtdec.h |1 + include/tmu.h | 46 lib/fdtdec.c |1 + 18 files changed, 593 insertions(+), 0 deletions(-) create mode 100644 arch/arm/include/asm/arch-exynos/exynos-tmu.h create mode 100644 common/cmd_tmu.c create mode 100644 doc/device-tree-bindings/exynos/tmu.txt create mode 100644 drivers/power/exynos-tmu.c create mode 100644 include/tmu.h -- 1.7.2.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] Add stricmp() and strnicmp()
Hi, On Sun, Nov 4, 2012 at 2:47 PM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Simon, OK, messaged received loud and clear. It does require a change of process at my end - now I have to find relationships between commits in different series going to different maintainers and try to tie them together. Just one more thing to worry about. Consider a 'paradigm shift' here: instead of building series according to intended custodians, one builds them according to functional relationship. If a series needs one custodian more than the others, he'll take it and ask for the others' ack. If there's a tie, this can be resolved between custodians. If one foresees a tie, then one can proactively suggest a resolution. But I understand your concern that, in fact, if there is no user immediately forthcoming, then it will just sit there and no one will notice if it is dead code. BTW, is there any easy way to obtain build-coverage information for U-Boot? In other words, can we easily find code that is not enabled by any existing board? That might be an interesting investigation. Seconded -- with the added note that we need coverage across all architectures. This patch is needed by new exynos memory init code. I am copying Hatim so that he is aware that it will need to be sent as part of his memory init series, which I believe is coming soon. We can leave this for now. Regards, Simon Regards, Simon Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] md5: Fix gcc-4.7 build problem in md5
Hi, On Tue, Nov 6, 2012 at 2:30 PM, Marek Vasut ma...@denx.de wrote: Dear Pavel Machek, On Tue 2012-11-06 01:56:50, Marek Vasut wrote: Dear Pavel Machek, Hi! In message 20121105200340.GA15821@xo-6d-61-c0.localdomain you wrote: /* Append length in bits and transform */ - ctx-in32[14] = ctx-bits[0]; - ctx-in32[15] = ctx-bits[1]; + memcpy(ctx-in + 14 * sizeof(__u32), ctx-bits, 2 * sizeof(__u32)); Is there some alternate solution? The memcpy is really ugly... Plus... does it solve the issue? The code does not look like being compatible with strict pointer aliasing... and I don't think memcpy() helps. arch/nds32/config.mk:PLATFORM_RELFLAGS += -fno-strict-aliasing -fno-common -mrelax arch/x86/config.mk:PLATFORM_CPPFLAGS += -fno-strict-aliasing We should really do that globally. Were you even able to replicate this problem in the first place? Isn't this whole problem a problem of a broken (ubuntu/linaro) toolchain again? This is not something you can replicate. At least md5 code is unsafe with strict aliasing, probably most of u-boot, because low-level people write code like that. Thus we should do -fno-strict-aliasing. Otherwise compiler may decide in future to miscompile our code, even if it compiles it correctly now. Pavel I dont think -fno-strict-aliasing is the way to go, it'll only hide the problem, no? Yes I agree. I believe this problem might have been a mistake on my part. I think I incorrectly merged Marek's change 'b68d63c GCC47: Fix warning in md5.c' when I was testing. Or it could me that my compiler was broken, as for a while it was generating these errors when it should not. So I believe we can drop this patch as I am no longer seeing the warning. If so, sorry for the noise. Regards, Simon Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] common: fix help command breakage
Hi, On Mon, 5 Nov 2012 19:51:11 -0600 Kim Phillips kim.phill...@freescale.com wrote: commit 199adb601ff34bdbbd0667fac80dfe0a87bffc2b common/misc: sparse fixes broke the help command trying to fix the sparse error command.c:44:38: error: bad constant expression. As Henrik points out, the fix was bad because the commit used CONFIG_SYS_MAXARGS whereas the code intended to use the maximum number of commands (not arguments to a command). this patch fixes both by making the allocation manually on the heap. Reported-by: Henrik Nordström hen...@henriknordstrom.net Signed-off-by: Kim Phillips kim.phill...@freescale.com --- tested on an 8572ds board common/command.c | 21 - 1 file changed, 12 insertions(+), 9 deletions(-) Applied to staging/ag...@denx.de. Thanks! Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] S-o-b entries for bcm2708 SDHCI driver in the downstream R.Pi Linux kernel
On 11/6/2012 6:58 PM, Stephen Warren wrote: On 10/26/2012 10:54 PM, Stephen Warren wrote: (Sorry for the resend; I sent this to the wrong U-Boot mailing list the first time around) Dom, ddv2005, Gray, I'm trying to get Signed-off-by lines for all code in the Raspberry Pi Linux kernel trees related to the SDHCI driver (or just everything). The list of relevant commits for SDHCI is below. Can you please check Documentation/SubmittingPatches in the kernel source tree, and if you're able to, provide your Signed-of-by lines for all of the patches I list below that were either authored by you, or passed through you (the latter I assume mainly in the case of Dom who applied these to git). I've taken a closer look at the downstream Raspberry Pi kernel trees and I see that the very first bcm2708 commit in the rpi-3.6.y branch contains all the code that's been used by the U-Boot MMC driver port. commit f5b930be71d6de64c3264b2f9eff4a4079d50c14 Author: popcornmix popcorn...@gmail.com AuthorDate: Tue Jan 17 19:20:11 2012 + Commit: popcornmix popcorn...@gmail.com CommitDate: Mon Oct 8 16:25:24 2012 +0100 Main bcm2708 linux port Signed-off-by: popcornmix popcorn...@gmail.com This commit is actually already signed off by popcornmix, and Dom Cobley previously indicated that's him, and gave his permission to rewrite that S-o-b to his real name. Oleksandr, I believe that means that if you can give your S-o-b to the U-Boot patch you created based on Dom's kernel code, we will be good to go with the U-Boot patch I posted, and I can then repost it including fixes for the review feedback it received. I believe this is the only commit I made to SDHCI-related code: commit c78b8ea9ae717432770843b825ea8a1a77f223fc Author: Oleksandr Tymoshenko go...@bluezbox.com Date: Wed Jun 20 11:53:07 2012 -0700 Add driper for R-Pi eMMC controller Signed-off-by: Oleksandr Tymoshenko go...@bluezbox.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 0/7] SPL: Port SPL framework to powerpc
Hi, On Tue, 23 Oct 2012 10:28:28 +0200 Stefan Roese s...@denx.de wrote: ... Stefan Roese (7): powerpc: Extract EPAPR_MAGIC constants into processor.h SPL: Port SPL framework to powerpc env: Enable getenv_f() for SPL_BUILD mpc5200: Add SPL support mpc5200: Add a3m071 board support Makefile: Add possibility to set entry-point for u-boot.img Makefile: Add target for combined spl/u-boot.bin u-boot.img Applied this series to staging/ag...@denx.de, rebased patch 7/7 when applying. Thanks! Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 1/7] powerpc: Extract EPAPR_MAGIC constants into processor.h
On Tue, 30 Oct 2012 10:45:21 +0100 Stefan Roese s...@denx.de wrote: By extracting these defines into a header, they can be re-used by other C sources as well. This will be done by the SPL framework OS boot support. Signed-off-by: Stefan Roese s...@denx.de --- Changes in v6: - Fix compile warning: release.S:354:0: warning: EPAPR_MAGIC redefined arch/powerpc/cpu/mpc85xx/release.S | 1 - arch/powerpc/include/asm/processor.h | 6 ++ arch/powerpc/lib/bootm.c | 6 -- 3 files changed, 6 insertions(+), 7 deletions(-) Applied to staging/ag...@denx.de. Thanks! Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] patman: Issue empty change logs for unchanged patches
Hi, On Tue, 30 Oct 2012 09:15:16 -0700 Simon Glass s...@chromium.org wrote: Often a particular patch may change only for some versions of a series. For versions where there is no change, issue a change log indicating that (for example 'Changes in v4: None'). For such lines, don't add a blank line afterwards, to conserve space. Use list.insert() instead of list = [item] + list. Signed-off-by: Simon Glass s...@chromium.org --- tools/patman/series.py | 21 + 1 files changed, 13 insertions(+), 8 deletions(-) Applied to staging/ag...@denx.de. Thanks! Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/mpc8xxx: Fix compiling error caused in DDR driver
mpc86xx platforms should use CONFIG_SYS_MPC86xx_DDR2_ADDR in utils.c
if applicable.
Signed-off-by: York Sun york...@freescale.com
---
arch/powerpc/cpu/mpc8xxx/ddr/util.c |4
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/util.c
b/arch/powerpc/cpu/mpc8xxx/ddr/util.c
index 940..9a07d9d 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/util.c
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/util.c
@@ -152,7 +152,11 @@ void board_add_ram_info(int use_default)
#if CONFIG_NUM_DDR_CONTROLLERS = 2
if (!(sdram_cfg SDRAM_CFG_MEM_EN)) {
+#ifdef CONFIG_MPC86xx
+ ddr = (void __iomem *)CONFIG_SYS_MPC86xx_DDR2_ADDR;
+#else
ddr = (void __iomem *)CONFIG_SYS_MPC85xx_DDR2_ADDR;
+#endif
sdram_cfg = in_be32(ddr-sdram_cfg);
}
#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] [u-boot-release] [PATCH] powerpc/mpc8xxx: Fix compiling error caused in DDR driver
On Nov 7, 2012, at 5:47 PM, York Sun wrote:
mpc86xx platforms should use CONFIG_SYS_MPC86xx_DDR2_ADDR in utils.c
if applicable.
Signed-off-by: York Sun york...@freescale.com
---
arch/powerpc/cpu/mpc8xxx/ddr/util.c |4
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/util.c
b/arch/powerpc/cpu/mpc8xxx/ddr/util.c
index 940..9a07d9d 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/util.c
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/util.c
@@ -152,7 +152,11 @@ void board_add_ram_info(int use_default)
#if CONFIG_NUM_DDR_CONTROLLERS = 2
if (!(sdram_cfg SDRAM_CFG_MEM_EN)) {
+#ifdef CONFIG_MPC86xx
+ ddr = (void __iomem *)CONFIG_SYS_MPC86xx_DDR2_ADDR;
+#else
ddr = (void __iomem *)CONFIG_SYS_MPC85xx_DDR2_ADDR;
+#endif
Argh, I submitted a patch to fix this more completely, but haven't applied it,
yet. See: http://patchwork.ozlabs.org/patch/193611/
Andy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [u-boot-release] [PATCH] powerpc/mpc8xxx: Fix compiling error caused in DDR driver
On 11/07/2012 03:57 PM, Fleming Andy-AFLEMING wrote:
On Nov 7, 2012, at 5:47 PM, York Sun wrote:
mpc86xx platforms should use CONFIG_SYS_MPC86xx_DDR2_ADDR in utils.c
if applicable.
Signed-off-by: York Sun york...@freescale.com
---
arch/powerpc/cpu/mpc8xxx/ddr/util.c |4
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/util.c
b/arch/powerpc/cpu/mpc8xxx/ddr/util.c
index 940..9a07d9d 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/util.c
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/util.c
@@ -152,7 +152,11 @@ void board_add_ram_info(int use_default)
#if CONFIG_NUM_DDR_CONTROLLERS = 2
if (!(sdram_cfg SDRAM_CFG_MEM_EN)) {
+#ifdef CONFIG_MPC86xx
+ ddr = (void __iomem *)CONFIG_SYS_MPC86xx_DDR2_ADDR;
+#else
ddr = (void __iomem *)CONFIG_SYS_MPC85xx_DDR2_ADDR;
+#endif
Argh, I submitted a patch to fix this more completely, but haven't applied it,
yet. See: http://patchwork.ozlabs.org/patch/193611/
Thanks. You may want to add #else clause to catch errors. I'd rather see
compiling error than debugging run time error.
York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC, PATCH] mmc: prepare SDHCI_HOST_CONTROL for SDMA operation
Hi Rommel,
Looks good to me. Thank you.
Acked-by: Jaehoon Chung jh80.ch...@samsung.com
On 11/08/2012 06:46 AM, Rommel G Custodio wrote:
modification for commit 804c7f422169212e92530e1ddaf74bf1ca9ebfa1
The original patch contained a bug.
Using a char with sdhci_readl/sdhci_writel operation.
The adjacent bytes to SDHCI_HOST_CONTROL (specially SDHCI_POWER_CONTROL)
get mangled and can result in the controller entering an unstable state.
This patch also moves the process inside sdhci_init().
Signed-off-by: Rommel G Custodio sessya...@gmail.com
---
drivers/mmc/sdhci.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 7845f87..fae2169 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -82,13 +82,6 @@ static int sdhci_transfer_data(struct sdhci_host *host,
struct mmc_data *data,
unsigned int start_addr)
{
unsigned int stat, rdy, mask, timeout, block = 0;
-#ifdef CONFIG_MMC_SDMA
- unsigned char ctrl;
- ctrl = sdhci_readl(host, SDHCI_HOST_CONTROL);
- ctrl = ~SDHCI_CTRL_DMA_MASK;
- ctrl |= SDHCI_CTRL_SDMA;
- sdhci_writel(host, ctrl, SDHCI_HOST_CONTROL);
-#endif
timeout = 100;
rdy = SDHCI_INT_SPACE_AVAIL | SDHCI_INT_DATA_AVAIL;
@@ -386,6 +379,14 @@ int sdhci_init(struct mmc *mmc)
{
struct sdhci_host *host = (struct sdhci_host *)mmc-priv;
+#ifdef CONFIG_MMC_SDMA
+ unsigned int ctrl;
+ ctrl = sdhci_readl(host, SDHCI_HOST_CONTROL);
+ ctrl = ~SDHCI_CTRL_DMA_MASK;
+ ctrl |= SDHCI_CTRL_SDMA;
+ sdhci_writel(host, ctrl, SDHCI_HOST_CONTROL);
+#endif
+
if ((host-quirks SDHCI_QUIRK_32BIT_DMA_ADDR) !aligned_buffer) {
aligned_buffer = memalign(8, 512*1024);
if (!aligned_buffer) {
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] microblaze: Fix compilation warning in ext2_find_next_zero_bit
Dear Michal Simek,
On 10/05/2012 06:48 PM, Marek Vasut wrote:
Dear Michal Simek,
ext2_find_next_zero_bit must be also static if __swab32 is also static.
Warning:
include/asm/bitops.h:369:22: warning: '__fswab32' is static but
used in inline function 'ext2_find_next_zero_bit'
which is not static [enabled by default]
Signed-off-by: Michal Simek mon...@monstr.eu
---
arch/microblaze/include/asm/bitops.h |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/microblaze/include/asm/bitops.h
b/arch/microblaze/include/asm/bitops.h index e8c835f..eafa2b5 100644
--- a/arch/microblaze/include/asm/bitops.h
+++ b/arch/microblaze/include/asm/bitops.h
@@ -319,7 +319,8 @@ extern __inline__ int ext2_test_bit(int nr, const
volatile void * addr) #define ext2_find_first_zero_bit(addr, size) \
ext2_find_next_zero_bit((addr), (size), 0)
-extern __inline__ unsigned long ext2_find_next_zero_bit(void *addr,
unsigned long size, unsigned long offset) +static inline unsigned long
ext2_find_next_zero_bit(void *addr,
+ unsigned long size, unsigned long offset)
{
unsigned long *p = ((unsigned long *) addr) + (offset 5);
unsigned long result = offset ~31UL;
I'd rather see it done the other way -- drop the inline and let compiler
decide. What are the size penalties ?
With inline
text data bss dec hex filename
36191414698 232344 608956 94abc ./u-boot
without inline
text data bss dec hex filename
36192214698 232368 608988 94adc ./u-boot
But the problem is that I can see a lot of warnings that this function is
unused. u-boot/include/asm/bitops.h:322:22: warning:
'ext2_find_next_zero_bit' defined but not used [-Wunused-function]
FYI: I have just grepped source tree and I see that the same solution is
used by blackfin/mips and powerpc.
$ grep -rn ext2_find_next_zero_bit arch/ | grep static
arch/microblaze/include/asm/bitops.h:322:static inline unsigned long
ext2_find_next_zero_bit(void *addr,
arch/blackfin/include/asm/bitops.h:324:static __inline__ unsigned long
ext2_find_next_zero_bit(void *addr,
arch/mips/include/asm/bitops.h:830:static __inline__ unsigned long
ext2_find_next_zero_bit(void *addr, unsigned long size, unsigned long
offset) arch/powerpc/include/asm/bitops.h:344:static __inline__ unsigned
long ext2_find_next_zero_bit(void *addr,
DAMN :-( Maybe we should focus on --gc-sections for whole u-boot. Anyway, I'd
say apply this and then start working on the --gc-sections.
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] common: add ifdefs around bouncebuf.c body
Dear Stephen Warren, On 11/07/2012 06:21 AM, Marek Vasut wrote: Dear Stephen Warren, On 11/06/2012 03:57 PM, Marek Vasut wrote: Dear Stephen Warren, On 11/06/2012 03:43 PM, Marek Vasut wrote: Dear Stephen Warren, On 11/05/2012 05:54 PM, Marek Vasut wrote: Dear Stephen Warren, From: Stephen Warren swar...@nvidia.com If a U-Boot config file enables CONFIG_BOUNCE_BUFFER only for the main U-Boot build and not for the SPL, then config.mk will contain CONFIG_BOUNCE_BUFFER=y, so common/Makefile will build bouncebuf.c for both the SPL and main U-Boot, but config.h won't set CONFIG_BOUNCE_BUFFER for the SPL, so bouncebuf.h will provide static inline functions, which will conflict with the compiled bouncebuf.c. Solve this by guarding the body of bouncebuf.c with the ifdef to avoid conflicts. Uh, don't you want the bounce buffer not compiled in for SPL? Then maybe add CONFIG_SPL_BOUNCE_BUFFER to force BB to be compiled into SPL or something ... Not compiling bouncebuf.c for SPL would solve this too. I have no idea what build system contortions would be required to do this though. Do you think the build system should be fixed first rather than taking this series/patch? I guess we shouldn't need a separate CONFIG_SPL_BOUNCE_BUFFER option though; we should rather simply set CONFIG_SPL_BOUNCE_BUFFER appropriately for SPL and non-SPL, and have everything key off that one variable, right? How will you be able to configure it separately for spl and non-spl ? For example, include/configs/trimslice.h contains: /* SD/MMC */ #define CONFIG_MMC #define CONFIG_GENERIC_MMC #define CONFIG_TEGRA_MMC #define CONFIG_CMD_MMC However, we don't use MMC in our SPL, but don't want to pollute every Tegra board file with ifdefs for SPL, so include/configs/tegra-common-post.h (which is included at the end of trimslice.h) contains: #ifdef CONFIG_SPL_BUILD ... /* remove MMC support */ #ifdef CONFIG_MMC #undef CONFIG_MMC #endif #ifdef CONFIG_GENERIC_MMC #undef CONFIG_GENERIC_MMC #endif #ifdef CONFIG_TEGRA_MMC #undef CONFIG_TEGRA_MMC #endif #ifdef CONFIG_CMD_MMC #undef CONFIG_CMD_MMC #endif ... #endif And in the V1 patch I proposed to tegra-common-post.h, I added the following at the end: #ifdef CONFIG_TEGRA_MMC #define CONFIG_BOUNCE_BUFFER #endif Yet, this doesn't solve the problem with SPL ... since for SPL, you'd have to do ifdef CONFIG_SPL, no? Sorry, what problem with the SPL is this not solving? I think I was tired when replying (sorry, the conference is really heavy on me). I though you wanted to disable BB only for SPL, but now I see BB being enabled depends on tegra mmc. btw. shouldn't --gc-sections remove BB code if it's not used at all? Yes, I assume so. In v2 of the patch series I have simply enabled CONFIG_BOUNCE_BUFFER unconditionally on Tegra, which removes the need for any SPL-specific changes. Before enabling it: Configuring for trimslice board... text data bss dec hex filename 245625 9304 274968 529897 815e9 ./u-boot 14451 208 72 14731398b ./spl/u-boot-spl After enabling it: Configuring for trimslice board... text data bss dec hex filename 245742 9304 274964 530010 8165a ./u-boot 14451 208 72 14731398b ./spl/u-boot-spl SPL didn't change since, so this seems to be working fine. Good! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] USB: add arrow key support to usb_kbd
Dear Allen Martin, On Wed, Nov 07, 2012 at 05:18:27AM -0800, Marek Vasut wrote: Dear Stephen Warren, On 11/06/2012 03:56 PM, Marek Vasut wrote: Dear Simon Glass, Hi Marek, On Tue, Nov 6, 2012 at 2:49 PM, Marek Vasut ma...@denx.de wrote: Dear Allen Martin, Check for scancodes for arrow keys and map them to ^F/^B, ^N/^P. Control characters are used instead of ANSI sequence because the queueing code in usb_kbd doesn't handle the data increase when one keypress generates 3 keycodes. The real fix is to convert this driver to use the input subsystem and queue If it's the real fix, then why not go for the real fix right away? :-( Because it's a fair chunk of work Let's either do it properly or not at all ... if I let you do these semi- complete fixes, we'll end up with a stinking pile of crap like windows ... Marek, I find this attitude a little ridiculous. If everything was fixed completely the first time around, there would be no work left to do; we'd just stop developing U-Boot. Equally, if this small addition to the USB keyboard code is so bad it can't be allowed since the whole driver must be re-written instead, why was the existing code allowed into U-Boot in the first place? Because evil b*tch (=me) wasn't around in the first place ;-) Anyway ... I'll apply it (not because of your whining and stuff ... but because it's beneficial). Though, I'd be really glad if you invested time to rework the driver. Otherwise, it'll be me who'll end up doing the work and I'd prefer to delegate it to someone who brough the issue up sooner ;-) Thanks Marek, I'd be happy to rework this driver if no one else wants to do it. I just can't sign up to do it right now as there are some tegra specific things (like USB gadget support, and enabling thumb) that are more important to me and my employer to do first, and I only work on u-boot on the side so I have limited bandwidth. Honestly ... I think you should talk to your employer :-( It sounds like we're all in violent agreement that moving the driver to the input subsystem is the right thing to do, and if someone is eager to work on it before I have a chance to I'm happy to review patches. I suspect your employer needs to understand that it's imperative to get properly involved in project and not just throw scraps over the fence. Please understand that every open-source project quality is only as high as the quality of all the contributors ... so if you only throw scraps at u-boot, it will be a pile of scraps (and it'll be really crappy) ... on the other hand, if you contribute properly and cherish the code, it'll be really a good and thriving project. I'm pretty sure your employer already understands that you're getting a lot of code for free and contributing back would be a really nice way of kind-of payback. Incremental small patches are good; they allow small simple things to be implemented without causing massive disruption. That's great for locating any regressions. Is there anything actually technically wrong with this specific patch? I would say no; it's very simple, non-invasive, low-risk, doesn't appear to introduce any long-term maintenance burden, doesn't completely prevent or remotely hinder reworking the USB keyboard support in the future, etc. Best regards, Marek Vasut -Allen Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] video: atmel: implement lcd_setcolreg funtion
Hi Andreas,
On 11/7/2012 21:26, Marek Vasut wrote:
Dear Bo Shen,
Hi Marek,
On 11/7/2012 6:54, Marek Vasut wrote:
Dear Andreas Bießmann,
From: Bo Shen voice.s...@atmel.com
Missing commit message
Signed-off-by: Bo Shen voice.s...@atmel.com
Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com
---
since v2:
* add this single patch
drivers/video/atmel_hlcdfb.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/video/atmel_hlcdfb.c b/drivers/video/atmel_hlcdfb.c
index beb7fa3..4110d4d 100644
--- a/drivers/video/atmel_hlcdfb.c
+++ b/drivers/video/atmel_hlcdfb.c
@@ -51,6 +51,12 @@ short console_row;
#define lcdc_readl(reg) __raw_readl((reg))
#define lcdc_writel(reg, val)__raw_writel((val), (reg))
+void lcd_setcolreg(ushort regno, ushort red, ushort green, ushort blue)
+{
+ lcdc_writel((red 16) | (green 8) | blue,
+ panel_info.mmio + ATMEL_LCDC_LUT(regno));
So this is RGB666? Or what are those magic numbers ?
This is a little different with the driver of atmel_lcdfb.c.
The register for LUT is layout as following:
RCLUT (24 ~ 16), GCLUT (15 ~ 8) and BCLUT (7 ~ 0).
So, use those magic numbers.
Good, can you define those magic offsets then please?
Will you redo your patch series or do I need to implement this and send
the patch to you again?
Which do you prefer?
Best Regards,
Bo Shen
More information, you can get from [1] on page 1163.
1. http://www.atmel.com/Images/doc11053.pdf
[...]
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/46] Enhance spear support
On 11/7/2012 7:40 PM, Stefan Roese wrote: Hi Vipin, On 11/02/2012 06:39 PM, Vipin Kumar wrote: This patchset is split in several pieces - Drivers: This is essentially a few new drivers and fixes in already exiasting drivers - Enhancement: This series enhances the already existing spear support - spear13xx: This is a totally new suppoort for spear13xx architecture Thanks for all these patches. This is a massive patch-set. I'll try to review at least some of them later this week. Please be patient. But this amount of patches does raise a question that I discussed a time ago. If you continue to work on upstream U-Boot, which we greatly appreciate, then its perhaps better to create/add an SPEAr U-Boot custodian responsible for the SPEAr related patches. Reviewing, collecting patches and pushing them to Alberts ARM repository. This would take a bit of work from Albert, since without such an custodian all those SPEAr patches would fall into his area. What do you guys think? Albert, what are your thoughts on this? Vipin, would you volunteer to eventually become this SPEAr U-Boot custodian? Or someone else? Yes, I can volunteer to be the SPEAr U-Boot custodian.. Regards Vipin Just my thought, comments welcome! Thanks, Stefan DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/46] Enhance spear support
On 11/7/2012 7:40 PM, Stefan Roese wrote: Hi Vipin, On 11/02/2012 06:39 PM, Vipin Kumar wrote: This patchset is split in several pieces - Drivers: This is essentially a few new drivers and fixes in already exiasting drivers - Enhancement: This series enhances the already existing spear support - spear13xx: This is a totally new suppoort for spear13xx architecture Thanks for all these patches. This is a massive patch-set. I'll try to review at least some of them later this week. Please be patient. But this amount of patches does raise a question that I discussed a time ago. If you continue to work on upstream U-Boot, which we greatly appreciate, then its perhaps better to create/add an SPEAr U-Boot custodian responsible for the SPEAr related patches. Reviewing, collecting patches and pushing them to Alberts ARM repository. This would take a bit of work from Albert, since without such an custodian all those SPEAr patches would fall into his area. What do you guys think? Albert, what are your thoughts on this? Vipin, would you volunteer to eventually become this SPEAr U-Boot custodian? Or someone else? Yes, I volunteer to be the SPEAr U-Boot custodian.. Regards Vipin Just my thought, comments welcome! Thanks, Stefan DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/6] EXYNOS5: FDT Support for I2C
This patch set adds FDT support for I2C driver and API's to acess the bus number using the fdt node and also reset the port. Rajeshwari Shinde (6): EXYNOS5: FDT: Add I2C device node data EXYNOS5 : FDT: Add Aliases for I2C device EXYNOS5: FDT: Add compatible string for I2C FDT: Api to find compatible id for a given node I2C: Driver changes for FDT support SMDK5250: Populate I2C data using FDT. arch/arm/dts/exynos5250.dtsi | 64 + board/samsung/dts/exynos5250-smdk5250.dts | 11 board/samsung/smdk5250/smdk5250.c |7 ++- drivers/i2c/s3c24x0_i2c.c | 89 - drivers/i2c/s3c24x0_i2c.h |7 ++ include/fdtdec.h | 15 + include/i2c.h | 28 + lib/fdtdec.c | 13 8 files changed, 231 insertions(+), 3 deletions(-) -- 1.7.4.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/6] EXYNOS5: FDT: Add I2C device node data
Add I2C device node data for exynos
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
arch/arm/dts/exynos5250.dtsi | 64 ++
1 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/arch/arm/dts/exynos5250.dtsi b/arch/arm/dts/exynos5250.dtsi
index db22db6..e877e6c 100644
--- a/arch/arm/dts/exynos5250.dtsi
+++ b/arch/arm/dts/exynos5250.dtsi
@@ -33,4 +33,68 @@
compatible = samsung,exynos-tmu;
reg = 0x1006 0x;
};
+
+ i2c@12c6 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = samsung,s3c2440-i2c;
+ reg = 0x12C6 0x100;
+ interrupts = 0 56 0;
+ };
+
+ i2c@12c7 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = samsung,s3c2440-i2c;
+ reg = 0x12C7 0x100;
+ interrupts = 0 57 0;
+ };
+
+ i2c@12c8 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = samsung,s3c2440-i2c;
+ reg = 0x12C8 0x100;
+ interrupts = 0 58 0;
+ };
+
+ i2c@12c9 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = samsung,s3c2440-i2c;
+ reg = 0x12C9 0x100;
+ interrupts = 0 59 0;
+ };
+
+ i2c@12ca {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = samsung,s3c2440-i2c;
+ reg = 0x12CA 0x100;
+ interrupts = 0 60 0;
+ };
+
+ i2c@12cb {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = samsung,s3c2440-i2c;
+ reg = 0x12CB 0x100;
+ interrupts = 0 61 0;
+ };
+
+ i2c@12cc {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = samsung,s3c2440-i2c;
+ reg = 0x12CC 0x100;
+ interrupts = 0 62 0;
+ };
+
+ i2c@12cd {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = samsung,s3c2440-i2c;
+ reg = 0x12CD 0x100;
+ interrupts = 0 63 0;
+ };
};
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/6] EXYNOS5 : FDT: Add Aliases for I2C device
This patch adds aliases for I2C.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
board/samsung/dts/exynos5250-smdk5250.dts | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/board/samsung/dts/exynos5250-smdk5250.dts
b/board/samsung/dts/exynos5250-smdk5250.dts
index 2d3ecca..8722b36 100644
--- a/board/samsung/dts/exynos5250-smdk5250.dts
+++ b/board/samsung/dts/exynos5250-smdk5250.dts
@@ -16,6 +16,17 @@
model = SAMSUNG SMDK5250 board based on EXYNOS5250;
compatible = samsung,smdk5250, samsung,exynos5250;
+ aliases {
+ i2c0 = /i2c@12c6;
+ i2c1 = /i2c@12c7;
+ i2c2 = /i2c@12c8;
+ i2c3 = /i2c@12c9;
+ i2c4 = /i2c@12ca;
+ i2c5 = /i2c@12cb;
+ i2c6 = /i2c@12cc;
+ i2c7 = /i2c@12cd;
+ };
+
sromc@1225 {
bank = 1;
srom-timing = 1 9 12 1 6 1 1;
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/6] EXYNOS5: FDT: Add compatible string for I2C
Add required compatible information for I2C driver.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
include/fdtdec.h |1 +
lib/fdtdec.c |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 180dfff..f9aac31 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -69,6 +69,7 @@ enum fdt_compat_id {
COMPAT_SMSC_LAN9215,/* SMSC 10/100 Ethernet LAN9215 */
COMPAT_SAMSUNG_EXYNOS5_SROMC, /* Exynos5 SROMC */
COMPAT_SAMSUNG_EXYNOS_TMU, /* Exynos TMU */
+ COMPAT_SAMSUNG_S3C2440_I2C, /* Exynos I2C Controller */
COMPAT_COUNT,
};
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 8e5ed21..6e8c24c 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -46,6 +46,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
COMPAT(SMSC_LAN9215, smsc,lan9215),
COMPAT(SAMSUNG_EXYNOS5_SROMC, samsung,exynos-sromc),
COMPAT(SAMSUNG_EXYNOS_TMU, samsung,exynos-tmu),
+ COMPAT(SAMSUNG_S3C2440_I2C, samsung,s3c2440-i2c),
};
const char *fdtdec_get_compatible(enum fdt_compat_id id)
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/6] FDT: Api to find compatible id for a given node
This patch adds api to find compatible id for a given
FDT node
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
include/fdtdec.h | 14 ++
lib/fdtdec.c | 12
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index f9aac31..d501d7e 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -389,4 +389,18 @@ int fdtdec_get_byte_array(const void *blob, int node,
const char *prop_name,
*/
const u8 *fdtdec_locate_byte_array(const void *blob, int node,
const char *prop_name, int count);
+
+/**
+ * Find the compatible ID for a given node.
+ *
+ * Generally each node has at least one compatible string attached to it.
+ * This function looks through our list of known compatible strings and
+ * returns the corresponding ID which matches the compatible string.
+ *
+ * @param blob FDT blob to use
+ * @param node Node containing compatible string to find
+ * @return compatible ID, or COMPAT_UNKNOWN if we cannot find a match
+ */
+enum fdt_compat_id fdtdec_lookup(const void *blob, int node);
+
#endif
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 6e8c24c..dbfca1a 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -516,3 +516,15 @@ const u8 *fdtdec_locate_byte_array(const void *blob, int
node,
return NULL;
return cell;
}
+
+enum fdt_compat_id fdtdec_lookup(const void *blob, int node)
+{
+ enum fdt_compat_id id;
+
+ /* Search our drivers */
+ for (id = COMPAT_UNKNOWN; id COMPAT_COUNT; id++)
+ if (0 == fdt_node_check_compatible(blob, node,
+ compat_names[id]))
+ return id;
+ return COMPAT_UNKNOWN;
+}
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/6] I2C: Driver changes for FDT support
Functions added to get the I2C bus number and reset I2C bus using
FDT node.
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
drivers/i2c/s3c24x0_i2c.c | 89 -
drivers/i2c/s3c24x0_i2c.h |7
include/i2c.h | 28 ++
3 files changed, 123 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/s3c24x0_i2c.c b/drivers/i2c/s3c24x0_i2c.c
index 9bc4c7f..952f76c 100644
--- a/drivers/i2c/s3c24x0_i2c.c
+++ b/drivers/i2c/s3c24x0_i2c.c
@@ -27,6 +27,7 @@
*/
#include common.h
+#include fdtdec.h
#ifdef CONFIG_EXYNOS5
#include asm/arch/clk.h
#include asm/arch/cpu.h
@@ -60,7 +61,14 @@
#define I2C_TIMEOUT 1 /* 1 second */
-static unsigned int g_current_bus; /* Stores Current I2C Bus */
+/*
+ * For SPL boot some boards need i2c before SDRAM is initialised so force
+ * variables to live in SRAM
+ */
+static unsigned int g_current_bus __attribute__((section(.data)));
+static struct s3c24x0_i2c_bus i2c_bus[CONFIG_MAX_I2C_NUM]
+ __attribute__((section(.data)));
+static int i2c_busses __attribute__((section(.data)));
#ifndef CONFIG_EXYNOS5
static int GetI2CSDA(void)
@@ -507,4 +515,83 @@ int i2c_write(uchar chip, uint addr, int alen, uchar
*buffer, int len)
(i2c, I2C_WRITE, chip 1, xaddr[4 - alen], alen, buffer,
len) != 0);
}
+
+#ifdef CONFIG_OF_CONTROL
+unsigned int i2c_fdt_bus_values(const void *blob)
+{
+
+ int node_list[CONFIG_MAX_I2C_NUM];
+ int count, i;
+
+ count = fdtdec_find_aliases_for_id(blob, i2c,
+ COMPAT_SAMSUNG_S3C2440_I2C, node_list,
+ CONFIG_MAX_I2C_NUM);
+ for (i = 0; i count; i++) {
+ struct s3c24x0_i2c_bus *bus;
+ int node = node_list[i];
+
+ if (node 0)
+ continue;
+ bus = i2c_bus[i];
+ bus-regs = (struct s3c24x0_i2c *)
+ fdtdec_get_addr(blob, node, reg);
+ bus-node = node;
+ bus-bus_num = i2c_busses++;
+ }
+
+ return count;
+}
+
+static struct s3c24x0_i2c_bus *get_bus(int bus_idx)
+{
+ if (bus_idx i2c_busses)
+ return i2c_bus[bus_idx];
+ debug(Undefined bus: %d\n, bus_idx);
+ return NULL;
+}
+
+int i2c_get_bus_num_fdt(const void *blob, int node)
+{
+ enum fdt_compat_id compat;
+ fdt_addr_t reg;
+ int i;
+
+ compat = fdtdec_lookup(blob, node);
+ if (compat != COMPAT_SAMSUNG_S3C2440_I2C) {
+ debug(%s: Not a supported I2C node\n, __func__);
+ return -1;
+ }
+ reg = fdtdec_get_addr(blob, node, reg);
+ for (i = 0; i i2c_busses; i++) {
+ if (reg == (fdt_addr_t)(uintptr_t)i2c_bus[i].regs)
+ return i;
+ }
+
+ debug(%s: Can't find any matched I2C bus\n, __func__);
+ return -1;
+}
+
+int i2c_reset_port_fdt(const void *blob, int node)
+{
+ struct s3c24x0_i2c_bus *i2c;
+
+ int bus;
+
+ bus = i2c_get_bus_num_fdt(blob, node);
+ if (bus 0) {
+ debug(could not get bus for node %d\n, node);
+ return -1;
+ }
+ i2c = get_bus(bus);
+ if (!i2c) {
+ debug(get_bus() failed for node node %d\n, node);
+ return -1;
+ }
+
+ i2c_ch_init(i2c-regs, CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
+
+ return 0;
+}
+#endif
+
#endif /* CONFIG_HARD_I2C */
diff --git a/drivers/i2c/s3c24x0_i2c.h b/drivers/i2c/s3c24x0_i2c.h
index 2dd4b06..bdd5514 100644
--- a/drivers/i2c/s3c24x0_i2c.h
+++ b/drivers/i2c/s3c24x0_i2c.h
@@ -30,4 +30,11 @@ struct s3c24x0_i2c {
u32 iicds;
u32 iiclc;
};
+
+struct s3c24x0_i2c_bus {
+ int node; /* device tree node */
+ int bus_num;/* i2c bus number */
+ struct s3c24x0_i2c *regs;
+};
+
#endif /* _S3C24X0_I2C_H */
diff --git a/include/i2c.h b/include/i2c.h
index 16f099d..52be093 100644
--- a/include/i2c.h
+++ b/include/i2c.h
@@ -262,4 +262,32 @@ extern int get_multi_scl_pin(void);
extern int get_multi_sda_pin(void);
extern int multi_i2c_init(void);
#endif
+
+#ifdef CONFIG_OF_CONTROL
+/**
+ * Get FDT values for i2c bus.
+ *
+ * @param blob Device tree blbo
+ * @return the number of I2C bus
+ */
+unsigned int i2c_fdt_bus_values(const void *blob);
+
+/**
+ * Find the I2C bus number by given a FDT I2C node.
+ *
+ * @param blob Device tree blbo
+ * @param node FDT I2C node to find
+ * @return the number of I2C bus (zero based), or -1 on error
+ */
+int i2c_get_bus_num_fdt(const void *blob, int node);
+
+/**
+ * Reset the I2C bus represented by the given a FDT I2C node.
+ *
+ * @param blob Device tree blbo
+ * @param node FDT I2C node to find
+ * @return 0 if port was reset, -1 if not found
+ */
+int i2c_reset_port_fdt(const void *blob, int node);
+#endif
#endif /*
[U-Boot] [PATCH 6/6] SMDK5250: Populate I2C data using FDT.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
board/samsung/smdk5250/smdk5250.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/board/samsung/smdk5250/smdk5250.c
b/board/samsung/smdk5250/smdk5250.c
index db2457b..dfb7239 100644
--- a/board/samsung/smdk5250/smdk5250.c
+++ b/board/samsung/smdk5250/smdk5250.c
@@ -276,8 +276,11 @@ static int board_uart_init(void)
static int board_i2c_init(void)
{
int i, err;
-
- for (i = 0; i CONFIG_MAX_I2C_NUM; i++) {
+ int count = CONFIG_MAX_I2C_NUM;
+#ifdef CONFIG_OF_CONTROL
+ count = i2c_fdt_bus_values(gd-fdt_blob);
+#endif
+ for (i = 0; i count; i++) {
err = exynos_pinmux_config((PERIPH_ID_I2C0 + i),
PINMUX_FLAG_NONE);
if (err) {
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/5] EXYNOS5: FDT support for Sound
This patch adds FDT support for Sound driver. This patch is based on following patchset. EXYNOS5: FDT Support for I2C Rajeshwari Shinde (5): EXYNOS5: FDT: Add sound device node data EXYNOS5: FDT: Add sound and codec device node informations EXYNOS5: FDT: Add compatible strings for sound Sound: Add FDT support to driver Sound: Add FDT support to CMD. arch/arm/dts/exynos5250.dtsi |5 + board/samsung/dts/exynos5250-smdk5250.dts | 20 +++ common/cmd_sound.c|4 + drivers/sound/sound.c | 228 - include/fdtdec.h |3 + include/sound.h |9 + lib/fdtdec.c |2 + 7 files changed, 264 insertions(+), 7 deletions(-) -- 1.7.4.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5] EXYNOS5: FDT: Add sound device node data
Add sound device node data for exynos
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
arch/arm/dts/exynos5250.dtsi |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/dts/exynos5250.dtsi b/arch/arm/dts/exynos5250.dtsi
index e877e6c..3f750f0 100644
--- a/arch/arm/dts/exynos5250.dtsi
+++ b/arch/arm/dts/exynos5250.dtsi
@@ -97,4 +97,9 @@
reg = 0x12CD 0x100;
interrupts = 0 63 0;
};
+
+ sound@12d6 {
+ compatible = samsung,exynos-sound;
+ reg = 0x12d6 0x20;
+ };
};
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/5] EXYNOS5: FDT: Add sound and codec device node informations
Adds sound and codec device node parameters
Signed-off-by: R. Chandrasekar rcse...@samsung.com
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
board/samsung/dts/exynos5250-smdk5250.dts | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/board/samsung/dts/exynos5250-smdk5250.dts
b/board/samsung/dts/exynos5250-smdk5250.dts
index 8722b36..6a500e1 100644
--- a/board/samsung/dts/exynos5250-smdk5250.dts
+++ b/board/samsung/dts/exynos5250-smdk5250.dts
@@ -50,4 +50,24 @@
samsung,slope = 268470274;
samsung,dc-value= 25;
};
+
+ sound@12d6 {
+ samsung,i2s-epll-clock-frequency = 19200;
+ samsung,i2s-sampling-rate = 48000;
+ samsung,i2s-bits-per-sample = 16;
+ samsung,i2s-channels = 2;
+ samsung,i2s-lr-clk-framesize = 256;
+ samsung,i2s-bit-clk-framesize = 32;
+ };
+
+ sound@12d6 {
+ samsung,codec-type = wm8994;
+ };
+
+ i2c@12c7 {
+ soundcodec@1a {
+ reg = 0x1a;
+ compatible = wolfson,wm8994-codec;
+ };
+ };
};
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5] EXYNOS5: FDT: Add compatible strings for sound
Add required compatible information for sound driver.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
include/fdtdec.h |3 +++
lib/fdtdec.c |2 ++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index d501d7e..a8dacac 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -70,6 +70,9 @@ enum fdt_compat_id {
COMPAT_SAMSUNG_EXYNOS5_SROMC, /* Exynos5 SROMC */
COMPAT_SAMSUNG_EXYNOS_TMU, /* Exynos TMU */
COMPAT_SAMSUNG_S3C2440_I2C, /* Exynos I2C Controller */
+ COMPAT_SAMSUNG_EXYNOS5_SOUND, /* Exynos Sound */
+ COMPAT_WOLFSON_WM8994_CODEC,/* Wolfson WM8994 Sound Codec */
+ COMPAT_SAMSUNG_EXYNOS_SPI, /* Exynos SPI */
COMPAT_COUNT,
};
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index dbfca1a..624d55e 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -47,6 +47,8 @@ static const char * const compat_names[COMPAT_COUNT] = {
COMPAT(SAMSUNG_EXYNOS5_SROMC, samsung,exynos-sromc),
COMPAT(SAMSUNG_EXYNOS_TMU, samsung,exynos-tmu),
COMPAT(SAMSUNG_S3C2440_I2C, samsung,s3c2440-i2c),
+ COMPAT(SAMSUNG_EXYNOS5_SOUND, samsung,exynos-sound),
+ COMPAT(WOLFSON_WM8994_CODEC, wolfson,wm8994-codec),
};
const char *fdtdec_get_compatible(enum fdt_compat_id id)
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/5] Sound: Add FDT support to driver
This patch adds FDT support to the driver.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
drivers/sound/sound.c | 228 +++--
include/sound.h |9 ++
2 files changed, 230 insertions(+), 7 deletions(-)
diff --git a/drivers/sound/sound.c b/drivers/sound/sound.c
index 4c74534..3a845c9 100644
--- a/drivers/sound/sound.c
+++ b/drivers/sound/sound.c
@@ -24,6 +24,8 @@
#include malloc.h
#include common.h
#include asm/io.h
+#include libfdt.h
+#include fdtdec.h
#include i2c.h
#include i2s.h
#include sound.h
@@ -37,12 +39,225 @@
static struct i2stx_info g_i2stx_pri;
static struct sound_codec_info g_codec_info;
+
+#ifdef CONFIG_OF_CONTROL
/*
- * get_sound_fdt_values gets fdt values for i2s parameters
+ * get_sound_i2s_fdt_values gets fdt values for i2s parameters
*
* @param i2stx_info i2s transmitter transfer param structure
* @param blob FDT blob
*/
+static int get_sound_i2s_fdt_values(struct i2stx_info *i2s, const void *blob)
+{
+ int node;
+ int error = 0;
+ int base;
+
+ node = fdtdec_next_compatible(blob, 0,
+ COMPAT_SAMSUNG_EXYNOS5_SOUND);
+ if (node = 0) {
+ debug(EXYNOS_SOUND: No node for sound in device tree\n);
+ return -1;
+ }
+
+ /*
+* Get the pre-defined sound specific values from FDT.
+* All of these are expected to be correct otherwise
+* wrong register values in i2s setup parameters
+* may result in no sound play.
+*/
+ base = fdtdec_get_addr(blob, node, reg);
+ if (base == FDT_ADDR_T_NONE) {
+ debug(%s: Missing i2s base\n, __func__);
+ return -1;
+ }
+ i2s-base_address = base;
+
+ i2s-audio_pll_clk = fdtdec_get_int(blob,
+ node, samsung,i2s-epll-clock-frequency, -1);
+ error |= i2s-audio_pll_clk;
+ debug(audio_pll_clk = %d\n, i2s-audio_pll_clk);
+ i2s-samplingrate = fdtdec_get_int(blob,
+ node, samsung,i2s-sampling-rate, -1);
+ error |= i2s-samplingrate;
+ debug(samplingrate = %d\n, i2s-samplingrate);
+ i2s-bitspersample = fdtdec_get_int(blob,
+ node, samsung,i2s-bits-per-sample, -1);
+ error |= i2s-bitspersample;
+ debug(bitspersample = %d\n, i2s-bitspersample);
+ i2s-channels = fdtdec_get_int(blob,
+ node, samsung,i2s-channels, -1);
+ error |= i2s-channels;
+ debug(channels = %d\n, i2s-channels);
+ i2s-rfs = fdtdec_get_int(blob,
+ node, samsung,i2s-lr-clk-framesize, -1);
+ error |= i2s-rfs;
+ debug(rfs = %d\n, i2s-rfs);
+ i2s-bfs = fdtdec_get_int(blob,
+ node, samsung,i2s-bit-clk-framesize, -1);
+ error |= i2s-bfs;
+ debug(bfs = %d\n, i2s-bfs);
+ if (error == -1) {
+ debug(fail to get sound i2s node properties\n);
+ return -1;
+ }
+
+ return 0;
+}
+
+/*
+ * Gets fdt values for wm8994 config parameters
+ *
+ * @param pcodec_info codec information structure
+ * @param blob FDT blob
+ * @return int value, 0 for success
+ */
+static int get_sound_fdt_values(struct sound_codec_info *pcodec_info,
+ const void *blob, enum fdt_compat_id compat_id)
+{
+ enum fdt_compat_id compat;
+ int node;
+ int error = 0;
+ int parent;
+
+ /* Get the node from FDT for codec */
+ node = fdtdec_next_compatible(blob, 0, compat_id);
+ if (node = 0) {
+ debug(EXYNOS_SOUND: No node for codec in device tree\n);
+ debug(node = %d\n, node);
+ return -1;
+ }
+
+ parent = fdt_parent_offset(blob, node);
+ if (parent 0) {
+ debug(%s: Cannot find node parent\n, __func__);
+ return -1;
+ }
+
+ compat = fdtdec_lookup(blob, parent);
+ switch (compat) {
+ case COMPAT_SAMSUNG_EXYNOS_SPI:
+ debug(%s: Support not added for SPI interface\n, __func__);
+ return -1;
+ break;
+ case COMPAT_SAMSUNG_S3C2440_I2C:
+ pcodec_info-i2c_bus = i2c_get_bus_num_fdt(blob, parent);
+ error |= pcodec_info-i2c_bus;
+ debug(i2c bus = %d\n, pcodec_info-i2c_bus);
+ pcodec_info-i2c_dev_addr = fdtdec_get_int(blob, node,
+ reg, 0);
+ error |= pcodec_info-i2c_dev_addr;
+ debug(i2c dev addr = %d\n, pcodec_info-i2c_dev_addr);
+ break;
+ default:
+ debug(%s: Unknown compat id %d\n, __func__, compat);
+ return -1;
+ }
+
+ if (error == -1) {
+ debug(fail to get codec node properties\n);
+
[U-Boot] [PATCH 5/5] Sound: Add FDT support to CMD.
This patch adds FDT support to sound init.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
common/cmd_sound.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/common/cmd_sound.c b/common/cmd_sound.c
index 459d1eb..ad8669f 100644
--- a/common/cmd_sound.c
+++ b/common/cmd_sound.c
@@ -33,7 +33,11 @@ static int do_init(cmd_tbl_t *cmdtp, int flag, int argc,
char *const argv[])
{
int ret;
+#ifdef CONFIG_OF_CONTROL
+ ret = sound_init(gd-fdt_blob);
+#else
ret = sound_init();
+#endif
if (ret) {
printf(Initialise Audio driver failed\n);
return CMD_RET_FAILURE;
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] S-o-b entries for bcm2708 SDHCI driver in the downstream R.Pi Linux kernel
On 11/07/2012 01:47 PM, Oleksandr Tymoshenko wrote: On 11/6/2012 6:58 PM, Stephen Warren wrote: On 10/26/2012 10:54 PM, Stephen Warren wrote: (Sorry for the resend; I sent this to the wrong U-Boot mailing list the first time around) Dom, ddv2005, Gray, I'm trying to get Signed-off-by lines for all code in the Raspberry Pi Linux kernel trees related to the SDHCI driver (or just everything). The list of relevant commits for SDHCI is below. Can you please check Documentation/SubmittingPatches in the kernel source tree, and if you're able to, provide your Signed-of-by lines for all of the patches I list below that were either authored by you, or passed through you (the latter I assume mainly in the case of Dom who applied these to git). I've taken a closer look at the downstream Raspberry Pi kernel trees and I see that the very first bcm2708 commit in the rpi-3.6.y branch contains all the code that's been used by the U-Boot MMC driver port. commit f5b930be71d6de64c3264b2f9eff4a4079d50c14 Author: popcornmix popcorn...@gmail.com AuthorDate: Tue Jan 17 19:20:11 2012 + Commit: popcornmix popcorn...@gmail.com CommitDate: Mon Oct 8 16:25:24 2012 +0100 Main bcm2708 linux port Signed-off-by: popcornmix popcorn...@gmail.com This commit is actually already signed off by popcornmix, and Dom Cobley previously indicated that's him, and gave his permission to rewrite that S-o-b to his real name. Oleksandr, I believe that means that if you can give your S-o-b to the U-Boot patch you created based on Dom's kernel code, we will be good to go with the U-Boot patch I posted, and I can then repost it including fixes for the review feedback it received. I believe this is the only commit I made to SDHCI-related code: commit c78b8ea9ae717432770843b825ea8a1a77f223fc Author: Oleksandr Tymoshenko go...@bluezbox.com Date: Wed Jun 20 11:53:07 2012 -0700 Add driper for R-Pi eMMC controller Signed-off-by: Oleksandr Tymoshenko go...@bluezbox.com Thanks for that S-o-b. I also picked up some of the code from the following commit of yours: commit 1c2b43a634955661d6f7b69459de00ffd1c2d7a6 Author: Oleksandr Tymoshenko go...@bluezbox.com Date: Tue Jul 3 19:57:37 2012 -0700 Workaround insufficient timeouts in u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 2/4] ARM: rpi_b: use bcm2835 mbox driver to get memory size
The firmware running on the bcm2835 SoC's VideoCore CPU determines how
much of the system RAM is available for use by the ARM CPU. Previously,
U-Boot assumed that only 128MB was available, since this was the
smallest value configured by any public firmware. However, we can now
query the actual value at run-time from the firmware using the mbox
property protocol.
Signed-off-by: Stephen Warren swar...@wwwdotorg.org
---
v3: No change.
v2: Updated to use macros etc. added in v2 of mbox driver patch.
---
board/raspberrypi/rpi_b/rpi_b.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/board/raspberrypi/rpi_b/rpi_b.c b/board/raspberrypi/rpi_b/rpi_b.c
index 688b0aa..3c654a1 100644
--- a/board/raspberrypi/rpi_b/rpi_b.c
+++ b/board/raspberrypi/rpi_b/rpi_b.c
@@ -15,13 +15,32 @@
*/
#include common.h
+#include asm/arch/mbox.h
#include asm/global_data.h
DECLARE_GLOBAL_DATA_PTR;
+struct msg_get_arm_mem {
+ struct bcm2835_mbox_hdr hdr;
+ struct bcm2835_mbox_tag_get_arm_mem get_arm_mem;
+ u32 end_tag;
+};
+
int dram_init(void)
{
- gd-ram_size = CONFIG_SYS_SDRAM_SIZE;
+ ALLOC_ALIGN_BUFFER(struct msg_get_arm_mem, msg, 1, 16);
+ int ret;
+
+ BCM2835_MBOX_INIT_HDR(msg);
+ BCM2835_MBOX_INIT_TAG(msg-get_arm_mem, GET_ARM_MEMORY);
+
+ ret = bcm2835_mbox_call_prop(BCM2835_MBOX_PROP_CHAN, msg-hdr);
+ if (ret) {
+ printf(bcm2835: Could not query ARM memory size\n);
+ return -1;
+ }
+
+ gd-ram_size = msg-get_arm_mem.body.resp.mem_size;
return 0;
}
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 4/4] video: add a driver for the bcm2835
The firmware running on the bcm2835 SoC's VideoCore CPU manages the
display controller. Add a simple LCD driver that communicates with the
firmware using the property mailbox protocol. This configures the
display and frame-buffer to match whatever physical resolution the
firmware chosen when booting, which is typically the native resolution
of the attached display device, presumably unless otherwise specified
in config.txt on the boot media.
Enable this driver in the Raspberry Pi board configuration.
Signed-off-by: Stephen Warren swar...@wwwdotorg.org
---
v3: Re-license to GPL-v2 or later. Fix typo in commit description.
v2: New patch.
---
drivers/video/Makefile |1 +
drivers/video/bcm2835.c | 127 +++
include/configs/rpi_b.h | 16 ++
3 files changed, 144 insertions(+)
create mode 100644 drivers/video/bcm2835.c
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index ebb6da8..e6efda6 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -39,6 +39,7 @@ COBJS-$(CONFIG_S6E8AX0) += s6e8ax0.o
COBJS-$(CONFIG_S6E63D6) += s6e63d6.o
COBJS-$(CONFIG_SED156X) += sed156x.o
COBJS-$(CONFIG_VIDEO_AMBA) += amba.o
+COBJS-$(CONFIG_VIDEO_BCM2835) += bcm2835.o
COBJS-$(CONFIG_VIDEO_CT69000) += ct69000.o videomodes.o
COBJS-$(CONFIG_VIDEO_DA8XX) += da8xx-fb.o videomodes.o
COBJS-$(CONFIG_VIDEO_MB862xx) += mb862xx.o videomodes.o
diff --git a/drivers/video/bcm2835.c b/drivers/video/bcm2835.c
new file mode 100644
index 000..1e9a84a
--- /dev/null
+++ b/drivers/video/bcm2835.c
@@ -0,0 +1,127 @@
+/*
+ * (C) Copyright 2012 Stephen Warren
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include common.h
+#include lcd.h
+#include asm/arch/mbox.h
+#include asm/global_data.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* Global variables that lcd.c expects to exist */
+int lcd_line_length;
+int lcd_color_fg;
+int lcd_color_bg;
+void *lcd_base;
+void *lcd_console_address;
+short console_col;
+short console_row;
+vidinfo_t panel_info;
+char lcd_cursor_enabled;
+ushort lcd_cursor_width;
+ushort lcd_cursor_height;
+
+struct msg_query {
+ struct bcm2835_mbox_hdr hdr;
+ struct bcm2835_mbox_tag_physical_w_h physical_w_h;
+ u32 end_tag;
+};
+
+struct msg_setup {
+ struct bcm2835_mbox_hdr hdr;
+ struct bcm2835_mbox_tag_physical_w_h physical_w_h;
+ struct bcm2835_mbox_tag_virtual_w_h virtual_w_h;
+ struct bcm2835_mbox_tag_depth depth;
+ struct bcm2835_mbox_tag_pixel_order pixel_order;
+ struct bcm2835_mbox_tag_alpha_mode alpha_mode;
+ struct bcm2835_mbox_tag_virtual_offset virtual_offset;
+ struct bcm2835_mbox_tag_overscan overscan;
+ struct bcm2835_mbox_tag_allocate_buffer allocate_buffer;
+ u32 end_tag;
+};
+
+void lcd_ctrl_init(void *lcdbase)
+{
+ ALLOC_ALIGN_BUFFER(struct msg_query, msg_query, 1, 16);
+ ALLOC_ALIGN_BUFFER(struct msg_setup, msg_setup, 1, 16);
+ int ret;
+ u32 w, h;
+
+ debug(bcm2835: Query resolution...\n);
+
+ BCM2835_MBOX_INIT_HDR(msg_query);
+ BCM2835_MBOX_INIT_TAG_NO_REQ(msg_query-physical_w_h,
+ GET_PHYSICAL_W_H);
+ ret = bcm2835_mbox_call_prop(BCM2835_MBOX_PROP_CHAN, msg_query-hdr);
+ if (ret) {
+ printf(bcm2835: Could not query display resolution\n);
+ /* FIXME: How to disable the LCD to prevent errors? hang()? */
+ return;
+ }
+
+ w = msg_query-physical_w_h.body.resp.width;
+ h = msg_query-physical_w_h.body.resp.height;
+
+ debug(bcm2835: Setting up display for %d x %d\n, w, h);
+
+ BCM2835_MBOX_INIT_HDR(msg_setup);
+ BCM2835_MBOX_INIT_TAG(msg_setup-physical_w_h, SET_PHYSICAL_W_H);
+ msg_setup-physical_w_h.body.req.width = w;
+ msg_setup-physical_w_h.body.req.height = h;
+ BCM2835_MBOX_INIT_TAG(msg_setup-virtual_w_h, SET_VIRTUAL_W_H);
+ msg_setup-virtual_w_h.body.req.width = w;
+ msg_setup-virtual_w_h.body.req.height = h;
+ BCM2835_MBOX_INIT_TAG(msg_setup-depth, SET_DEPTH);
+ msg_setup-depth.body.req.bpp = 16;
+ BCM2835_MBOX_INIT_TAG(msg_setup-pixel_order, SET_PIXEL_ORDER);
+ msg_setup-pixel_order.body.req.order = BCM2835_MBOX_PIXEL_ORDER_BGR;
+ BCM2835_MBOX_INIT_TAG(msg_setup-alpha_mode, SET_ALPHA_MODE);
+ msg_setup-alpha_mode.body.req.alpha = BCM2835_MBOX_ALPHA_MODE_IGNORED;
+
[U-Boot] [PATCH V3 3/4] lcd: calculate line_length after lcd_ctrl_init()
When an LCD driver is actually driving a regular external display, e.g. an HDMI monitor, the display resolution might not be known until the display controller has initialized, i.e. during lcd_ctrl_init(). However, lcd.c calculates lcd_line_length before calling this function, thus relying on a hard-coded resolution in struct panel_info. Instead, defer this calculation until after lcd_ctrl_init() has had the chance to dynamically determine the resolution. This needs to happen before lcd_clear(), since the value is used there. grep indicates that no code outside lcd.c uses this lcd_line_length; in particular, no lcd_ctrl_init() implementations read it. Signed-off-by: Stephen Warren swar...@wwwdotorg.org -- v3: No change. --- common/lcd.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/common/lcd.c b/common/lcd.c index b6be800..1a20f85 100644 --- a/common/lcd.c +++ b/common/lcd.c @@ -333,8 +333,6 @@ int drv_lcd_init (void) lcd_base = (void *)(gd-fb_base); - lcd_line_length = (panel_info.vl_col * NBITS (panel_info.vl_bpix)) / 8; - lcd_init(lcd_base); /* LCD initialization */ /* Device initialization */ @@ -416,6 +414,7 @@ static int lcd_init(void *lcdbase) debug([LCD] Initializing LCD frambuffer at %p\n, lcdbase); lcd_ctrl_init(lcdbase); + lcd_line_length = (panel_info.vl_col * NBITS(panel_info.vl_bpix)) / 8; lcd_is_enabled = 1; lcd_clear(); lcd_enable (); -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 1/4] ARM: bcm2835: add mailbox driver
The BCM2835 SoC contains (at least) two CPUs; the VideoCore (a/k/a GPU)
and the ARM CPU. The ARM CPU is often thought of as the main CPU.
However, the VideoCore actually controls the initial SoC boot, and hides
much of the hardware behind a protocol. This protocol is transported
using the SoC's mailbox hardware module.
Here, we add a very simplistic driver for the mailbox module, and define
a few structures for the property messages.
Signed-off-by: Stephen Warren swar...@wwwdotorg.org
---
v3: Re-license to GPL-v2 or later.
v2:
* Added documentation to mbox.h.
* Implemented macros to set up headers and tags.
* Implemented error-checking of response bits in bcm2835_mbox_call_prop().
* Reworked tag structs based on experience writing LCD driver.
* Added a lot more video-related tag structs.
* Added debug spew and error messages to mbox.c; useful when debugging LCD.
* Removed __packed attributes from message structs.
* Removed stale FIXME comments.
---
arch/arm/cpu/arm1176/bcm2835/Makefile|2 +-
arch/arm/cpu/arm1176/bcm2835/mbox.c | 164
arch/arm/include/asm/arch-bcm2835/mbox.h | 407 ++
3 files changed, 572 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/cpu/arm1176/bcm2835/mbox.c
create mode 100644 arch/arm/include/asm/arch-bcm2835/mbox.h
diff --git a/arch/arm/cpu/arm1176/bcm2835/Makefile
b/arch/arm/cpu/arm1176/bcm2835/Makefile
index 95da6a8..135de42 100644
--- a/arch/arm/cpu/arm1176/bcm2835/Makefile
+++ b/arch/arm/cpu/arm1176/bcm2835/Makefile
@@ -17,7 +17,7 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(SOC).o
SOBJS := lowlevel_init.o
-COBJS := init.o reset.o timer.o
+COBJS := init.o reset.o timer.o mbox.o
SRCS := $(SOBJS:.o=.c) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS))
diff --git a/arch/arm/cpu/arm1176/bcm2835/mbox.c
b/arch/arm/cpu/arm1176/bcm2835/mbox.c
new file mode 100644
index 000..fd65e33
--- /dev/null
+++ b/arch/arm/cpu/arm1176/bcm2835/mbox.c
@@ -0,0 +1,164 @@
+/*
+ * (C) Copyright 2012 Stephen Warren
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include common.h
+#include asm/io.h
+#include asm/arch/mbox.h
+
+#define TIMEOUT (100 * 1000) /* 100mS in uS */
+
+int bcm2835_mbox_call_raw(u32 chan, u32 send, u32 *recv)
+{
+ struct bcm2835_mbox_regs *regs =
+ (struct bcm2835_mbox_regs *)BCM2835_MBOX_PHYSADDR;
+ ulong endtime = get_timer(0) + TIMEOUT;
+ u32 val;
+
+ debug(time: %lu timeout: %lu\n, get_timer(0), endtime);
+
+ if (send BCM2835_CHAN_MASK) {
+ printf(mbox: Illegal mbox data 0x%08x\n, send);
+ return -1;
+ }
+
+ /* Drain any stale responses */
+
+ for (;;) {
+ val = readl(regs-status);
+ if (val BCM2835_MBOX_STATUS_RD_EMPTY)
+ break;
+ if (get_timer(0) = endtime) {
+ printf(mbox: Timeout draining stale responses\n);
+ return -1;
+ }
+ val = readl(regs-read);
+ }
+
+ /* Wait for space to send */
+
+ for (;;) {
+ val = readl(regs-status);
+ if (!(val BCM2835_MBOX_STATUS_WR_FULL))
+ break;
+ if (get_timer(0) = endtime) {
+ printf(mbox: Timeout waiting for send space\n);
+ return -1;
+ }
+ }
+
+ /* Send the request */
+
+ val = BCM2835_MBOX_PACK(chan, send);
+ debug(mbox: TX raw: 0x%08x\n, val);
+ writel(val, regs-write);
+
+ /* Wait for the response */
+
+ for (;;) {
+ val = readl(regs-status);
+ if (!(val BCM2835_MBOX_STATUS_RD_EMPTY))
+ break;
+ if (get_timer(0) = endtime) {
+ printf(mbox: Timeout waiting for response\n);
+ return -1;
+ }
+ }
+
+ /* Read the response */
+
+ val = readl(regs-read);
+ debug(mbox: RX raw: 0x%08x\n, val);
+
+ /* Validate the response */
+
+ if (BCM2835_MBOX_UNPACK_CHAN(val) != chan) {
+ printf(mbox: Response channel mismatch\n);
+ return -1;
+ }
+
+ *recv = BCM2835_MBOX_UNPACK_DATA(val);
+
+ return 0;
+}
+
+#ifdef DEBUG
+void dump_buf(struct bcm2835_mbox_hdr *buffer)
+{
+ u32 *p;
+ u32
[U-Boot] [PATCH V2 1/2] mmc: add bcm2835 driver
This adds a simple driver for the BCM2835's SD controller. Workarounds are implemented for: * Register writes can't be too close to each-other in time, or they will be lost. * Register accesses must all be 32-bit, so implement custom accessors. This code was extracted from: git://github.com/gonzoua/u-boot-pi.git master which was created by Oleksandr Tymoshenko. Portions of the code there were obviously based on the Linux kernel at: git://github.com/raspberrypi/linux.git rpi-3.6.y commit f5b930b Main bcm2708 linux port signed-off-by Dom Cobley. swarren changed the following for upstream: * Removed hack udelay()s in bcm2835_sdhci_raw_writel(); setting SDHCI_QUIRK_WAIT_SEND_CMD appears to solve the issues. * Remove register logging from read*/write* functions. * Sort out confusion with min/max_freq values passed to add_sdhci(). * Use more descriptive variable names and calculations in IO accessors. * Simplified and commented twoticks_delay calculation. * checkpatch fixes. Signed-off-by: Oleksandr Tymoshenko go...@bluezbox.com Signed-off-by: Stephen Warren swar...@wwwdotorg.org --- This series is based on the previous bcm2835 patches I sent, to add the mbox and video drivers. Patch 1 should be independant, but patch 2 depends on those other patches. v2: * Use more descriptive variable names and calculations in IO accessors. * Add Oleksandr's S-o-b. * Rewrite commit description to note that the Linux code this was derived from was S-o-b Dom Cobley. --- arch/arm/include/asm/arch-bcm2835/sdhci.h | 24 drivers/mmc/Makefile |1 + drivers/mmc/bcm2835_sdhci.c | 177 + 3 files changed, 202 insertions(+) create mode 100644 arch/arm/include/asm/arch-bcm2835/sdhci.h create mode 100644 drivers/mmc/bcm2835_sdhci.c diff --git a/arch/arm/include/asm/arch-bcm2835/sdhci.h b/arch/arm/include/asm/arch-bcm2835/sdhci.h new file mode 100644 index 000..a4f867b --- /dev/null +++ b/arch/arm/include/asm/arch-bcm2835/sdhci.h @@ -0,0 +1,24 @@ +/* + * (C) Copyright 2012 Stephen Warren + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#ifndef _BCM2835_SDHCI_H_ +#define _BCM2835_SDHCI_H_ + +#define BCM2835_SDHCI_BASE 0x2030 + +int bcm2835_sdhci_init(u32 regbase, u32 emmc_freq); + +#endif diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile index a1dd730..6be36f2 100644 --- a/drivers/mmc/Makefile +++ b/drivers/mmc/Makefile @@ -43,6 +43,7 @@ COBJS-$(CONFIG_MXS_MMC) += mxsmmc.o COBJS-$(CONFIG_OMAP_HSMMC) += omap_hsmmc.o COBJS-$(CONFIG_PXA_MMC_GENERIC) += pxa_mmc_gen.o COBJS-$(CONFIG_SDHCI) += sdhci.o +COBJS-$(CONFIG_BCM2835_SDHCI) += bcm2835_sdhci.o COBJS-$(CONFIG_S5P_SDHCI) += s5p_sdhci.o COBJS-$(CONFIG_SH_MMCIF) += sh_mmcif.o COBJS-$(CONFIG_TEGRA_MMC) += tegra_mmc.o diff --git a/drivers/mmc/bcm2835_sdhci.c b/drivers/mmc/bcm2835_sdhci.c new file mode 100644 index 000..8f2137e --- /dev/null +++ b/drivers/mmc/bcm2835_sdhci.c @@ -0,0 +1,177 @@ +/* + * This code was extracted from: + * git://github.com/gonzoua/u-boot-pi.git master + * and hence presumably (C) 2012 Oleksandr Tymoshenko + * + * Tweaks for U-Boot upstreaming + * (C) 2012 Stephen Warren + * + * Portions (e.g. read/write macros, concepts for back-to-back register write + * timing workarounds) obviously extracted from the Linux kernel at: + * https://github.com/raspberrypi/linux.git rpi-3.6.y + * + * The Linux kernel code has the following (c) and license, which is hence + * propagated to Oleksandr's tree and here: + * + * Support for SDHCI device on 2835 + * Based on sdhci-bcm2708.c (c) 2010 Broadcom + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + */ + +/* Supports: + * SDHCI platform device - Arasan SD controller in BCM2708 + * + * Inspired by sdhci-pci.c, by Pierre Ossman + */ + +#include common.h +#include malloc.h +#include sdhci.h + +/* 400KHz is max freq for card ID etc. Use that as min */ +#define
[U-Boot] [PATCH V2 2/2] ARM: rpi_b: enable SD controller, add related env/cmds
Enable the SD controller driver for the Raspberry Pi. Enable a number
of useful MMC, partition, and filesystem-related commands. Set up the
environment to provide standard locations for loading a kernel, DTB,
etc. Provide a boot command that loads and executes boot.scr.uimg from
the SD card; this is written considering future extensibilty to USB
storage.
Signed-off-by: Stephen Warren swar...@wwwdotorg.org
---
arch/arm/include/asm/arch-bcm2835/mbox.h | 26
board/raspberrypi/rpi_b/rpi_b.c | 26
include/configs/rpi_b.h | 68 --
3 files changed, 117 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/arch-bcm2835/mbox.h
b/arch/arm/include/asm/arch-bcm2835/mbox.h
index 4752091..b07c4a0 100644
--- a/arch/arm/include/asm/arch-bcm2835/mbox.h
+++ b/arch/arm/include/asm/arch-bcm2835/mbox.h
@@ -144,6 +144,32 @@ struct bcm2835_mbox_tag_get_arm_mem {
} body;
};
+#define BCM2835_MBOX_TAG_GET_CLOCK_RATE0x00030002
+
+#define BCM2835_MBOX_CLOCK_ID_EMMC 1
+#define BCM2835_MBOX_CLOCK_ID_UART 2
+#define BCM2835_MBOX_CLOCK_ID_ARM 3
+#define BCM2835_MBOX_CLOCK_ID_CORE 4
+#define BCM2835_MBOX_CLOCK_ID_V3D 5
+#define BCM2835_MBOX_CLOCK_ID_H264 6
+#define BCM2835_MBOX_CLOCK_ID_ISP 7
+#define BCM2835_MBOX_CLOCK_ID_SDRAM8
+#define BCM2835_MBOX_CLOCK_ID_PIXEL9
+#define BCM2835_MBOX_CLOCK_ID_PWM 10
+
+struct bcm2835_mbox_tag_get_clock_rate {
+ struct bcm2835_mbox_tag_hdr tag_hdr;
+ union {
+ struct {
+ u32 clock_id;
+ } req;
+ struct {
+ u32 clock_id;
+ u32 rate_hz;
+ } resp;
+ } body;
+};
+
#define BCM2835_MBOX_TAG_ALLOCATE_BUFFER 0x00040001
struct bcm2835_mbox_tag_allocate_buffer {
diff --git a/board/raspberrypi/rpi_b/rpi_b.c b/board/raspberrypi/rpi_b/rpi_b.c
index 3c654a1..6b3e095 100644
--- a/board/raspberrypi/rpi_b/rpi_b.c
+++ b/board/raspberrypi/rpi_b/rpi_b.c
@@ -16,6 +16,7 @@
#include common.h
#include asm/arch/mbox.h
+#include asm/arch/sdhci.h
#include asm/global_data.h
DECLARE_GLOBAL_DATA_PTR;
@@ -26,6 +27,12 @@ struct msg_get_arm_mem {
u32 end_tag;
};
+struct msg_get_clock_rate {
+ struct bcm2835_mbox_hdr hdr;
+ struct bcm2835_mbox_tag_get_clock_rate get_clock_rate;
+ u32 end_tag;
+};
+
int dram_init(void)
{
ALLOC_ALIGN_BUFFER(struct msg_get_arm_mem, msg, 1, 16);
@@ -51,3 +58,22 @@ int board_init(void)
return 0;
}
+
+int board_mmc_init(void)
+{
+ ALLOC_ALIGN_BUFFER(struct msg_get_clock_rate, msg_clk, 1, 16);
+ int ret;
+
+ BCM2835_MBOX_INIT_HDR(msg_clk);
+ BCM2835_MBOX_INIT_TAG(msg_clk-get_clock_rate, GET_CLOCK_RATE);
+ msg_clk-get_clock_rate.body.req.clock_id = BCM2835_MBOX_CLOCK_ID_EMMC;
+
+ ret = bcm2835_mbox_call_prop(BCM2835_MBOX_PROP_CHAN, msg_clk-hdr);
+ if (ret) {
+ printf(bcm2835: Could not query eMMC clock rate\n);
+ return -1;
+ }
+
+ return bcm2835_sdhci_init(BCM2835_SDHCI_BASE,
+ msg_clk-get_clock_rate.body.resp.rate_hz);
+}
diff --git a/include/configs/rpi_b.h b/include/configs/rpi_b.h
index a709feb..4d834e1 100644
--- a/include/configs/rpi_b.h
+++ b/include/configs/rpi_b.h
@@ -50,6 +50,7 @@
#define CONFIG_SYS_MALLOC_LEN SZ_4M
#define CONFIG_SYS_MEMTEST_START 0x0010
#define CONFIG_SYS_MEMTEST_END 0x0020
+#define CONFIG_LOADADDR0x0020
/* Flash */
#define CONFIG_SYS_NO_FLASH
@@ -69,6 +70,13 @@
#define CONFIG_VIDEO_BCM2835
#define CONFIG_SYS_WHITE_ON_BLACK
+/* SD/MMC configuration */
+#define CONFIG_GENERIC_MMC
+#define CONFIG_MMC
+#define CONFIG_SDHCI
+#define CONFIG_MMC_SDHCI_IO_ACCESSORS
+#define CONFIG_BCM2835_SDHCI
+
/* Console UART */
#define CONFIG_PL011_SERIAL
#define CONFIG_PL011_CLOCK 300
@@ -84,12 +92,59 @@
/* Environment */
#define CONFIG_ENV_SIZESZ_16K
#define CONFIG_ENV_IS_NOWHERE
+#define CONFIG_ENV_VARS_UBOOT_CONFIG
#define CONFIG_SYS_LOAD_ADDR 0x100
#define CONFIG_CONSOLE_MUX
#define CONFIG_SYS_CONSOLE_IS_IN_ENV
-#define CONFIG_EXTRA_ENV_SETTINGS stdin=serial\0 \
- stderr=serial,lcd\0 \
- stdout=serial,lcd\0
+/*
+ * Memory layout for where various images get loaded by boot scripts:
+ *
+ * scriptaddr can be pretty much anywhere that doesn't conflict with something
+ * else. Put it low in memory to avoid conflicts.
+ *
+ * kernel_addr_r must be within the first 128M of RAM in order for the
+ * kernel's CONFIG_AUTO_ZRELADDR option to work. Since the kernel will
+ * decompress itself to 0x8000 after the start of RAM, kernel_addr_r
+ * should not overlap that area, or the kernel will have to copy itself
+
Re: [U-Boot] [PATCH 2/2] WIP: tegra: i2c: Enable new CONFIG_SYS_I2C framework
Hello Stephen, On 01.11.2012 18:03, Stephen Warren wrote: On 11/01/2012 01:42 AM, Heiko Schocher wrote: Hello Stephen, On 31.10.2012 17:25, Stephen Warren wrote: On 10/31/2012 09:56 AM, Simon Glass wrote: Hi Stephen, On Wed, Oct 31, 2012 at 8:41 AM, Stephen Warrenswar...@wwwdotorg.org wrote: On 10/31/2012 12:00 AM, Heiko Schocher wrote: [...] If all in-use I2C adapters must be specified statically in CONFIG_SYS_I2C_ADAPTERS, then since a board's DT could enable any arbitrary subset of Tegra's I2C adapters, then we must always set CONFIG_SYS_I2C_ADAPTERS to the list of all Tegra's I2C adapters. If we put some subset into CONFIG_SYS_I2C_ADAPTERS, then we're pre-defining the maximal set of I2C adapters that a board can enable, which means DT isn't specifying that, but rather the board config file is, and hence it's pointless to even use DT for this purpose. My current approach needs static specific adapters, yes. But I see not the problem, if we define all tegra adapters per default and ... Now, most boards won't use all I2C adapters, so presumably the Tegra I2C init routine will look for status=disabled (or the inverse) in DT, and only initialize if the DT node for the adapter is present and enabled. ... and it should here be possible to add the used i2c busses! dynamically from the info in the DT, or? Does the I2C adapter registration function call an I2C core function to dynamically register the actual buses that exist on the system? If so, then everything seems fine. However, your later responses re: CONFIG_SYS_I2C_BUSSES then would confuse me... We use in U-Boot not direct the i2c adapters, instead i2c busses ... so if we define all 4 tegra i2c adapters per default, but using on one board only adapter 1 and 3 we have two i2c busses: 0 (= adapter 1) and 1 (= adapter 3) ... no gaps between ...) However, this will leave entries in CONFIG_SYS_I2C_ADAPTERS that are not enabled, which will presumably influence the I2C bus numbering in the No, why? You can add all i2c adapters to the CONFIG_SYS_I2C_ADAPTERS define, without really use them in CONFIG_SYS_I2C_BUSSES. And it Oh, so CONFIG_SYS_I2C_ADAPTERS defines which adapters get initialized, CONFIG_SYS_I2C_ADAPTERS defines which i2c adapters (=drivers) (maybe) used on this board. and CONFIG_SYS_I2C_BUSSES statically defines which I2C buses exist, so CONFIG_SYS_I2C_BUSSES could end up not defining a bus that uses a particular adapter, or could end up defining multiple buses that use a particular bus (in the presence of a mux). That all seems fine, but... However, CONFIG_SYS_I2C_BUSSES sounds like a config variable defined at compile time, not something dynamic. If that's true, then I'll just re-state my previous comments but say CONFIG_SYS_I2C_BUSSES anywhere I said CONFIG_SYS_I2C_ADAPTERS... Yes, currently static ... should be possible (not yet coded, but tried in an older version) to add i2c busses after relocation, or while interpret DT ... something like I did in http://git.denx.de/?p=u-boot/u-boot-i2c.git;a=commitdiff;h=ccb680c8cf9002232bc459e4003e3b47db5e1bf4#patch13 I guess my question is: Why even have a CONFIG_SYS_I2C_ADAPTERS or CONFIG_SYS_I2C_BUSSES variable at all? Surely if we intend to make this dynamic in the long run we should just make it dynamic from the start as part of the API rework. If we don't, we'll just have to do another pass over all the drivers converting them to dynamic registration later anyway. This patchserie is thought only for static configuration (as current state is) ... But you can post patches for such a solution ... and we can move this way! I'd suggest having a CONFIG_SYS_I2C_DRIVERS variable at most, and each driver registers an arbitrary number of adapters and/or buses during its initialization. Why should an i2c driver register buses? That is board specific. We could probably even get away without CONFIG_SYS_I2C_DRIVERS at all; just have each driver define a structure that gets put into a special linker section, so that the I2C core can iterate over all linked drivers at boot time and call their initialization functions. Even if we don't get rid of CONFIG_SYS_I2C_ADAPTERS, I really think we should get rid of CONFIG_SYS_I2C_BUSSES and do that dynamically. How do we this, for example on some powerpc boards, which boot from NOR flash and read a SPD EEprom data for RAM initialization (Note: we have here not a lot of stack, nor RAM)? Maybe we should wait with this hole patchserie until DM is ready? (And maybe rework it completly?) BTW, isn't buses spelled buses not busses? Thunderbird's spell-checker certainly thinks so! function: int i2c_add_one_bus(char *buf) - while interpreting DT i2c info for above board will result in calling: i2c_add_one_bus(tegra-i2c-1); i2c_add_one_bus(tegra-i2c-3); and results in two new i2c busses 0 and 1 ... Maybe this is a way to go? Yes, that sounds like the right kind of direction. Ok. U-Boot shell; there will be I2C
Re: [U-Boot] [PATCH 2/2] WIP: tegra: i2c: Enable new CONFIG_SYS_I2C framework
Hello Simon, On 05.11.2012 21:39, Simon Glass wrote: Hi, On Thu, Nov 1, 2012 at 10:03 AM, Stephen Warrenswar...@wwwdotorg.org wrote: On 11/01/2012 01:42 AM, Heiko Schocher wrote: Hello Stephen, On 31.10.2012 17:25, Stephen Warren wrote: On 10/31/2012 09:56 AM, Simon Glass wrote: Hi Stephen, On Wed, Oct 31, 2012 at 8:41 AM, Stephen [...] should be possible (not yet coded, but tried in an older version) to add i2c busses after relocation, or while interpret DT ... something like I did in http://git.denx.de/?p=u-boot/u-boot-i2c.git;a=commitdiff;h=ccb680c8cf9002232bc459e4003e3b47db5e1bf4#patch13 I guess my question is: Why even have a CONFIG_SYS_I2C_ADAPTERS or CONFIG_SYS_I2C_BUSSES variable at all? Surely if we intend to make this dynamic in the long run we should just make it dynamic from the start as part of the API rework. If we don't, we'll just have to do another pass over all the drivers converting them to dynamic registration later anyway. I'd suggest having a CONFIG_SYS_I2C_DRIVERS variable at most, and each driver registers an arbitrary number of adapters and/or buses during its initialization. We could probably even get away without CONFIG_SYS_I2C_DRIVERS at all; just have each driver define a structure that gets put into a special linker section, so that the I2C core can iterate over all linked drivers at boot time and call their initialization functions. Even if we don't get rid of CONFIG_SYS_I2C_ADAPTERS, I really think we should get rid of CONFIG_SYS_I2C_BUSSES and do that dynamically. BTW, isn't buses spelled buses not busses? Thunderbird's spell-checker certainly thinks so! function: int i2c_add_one_bus(char *buf) - while interpreting DT i2c info for above board will result in calling: i2c_add_one_bus(tegra-i2c-1); i2c_add_one_bus(tegra-i2c-3); and results in two new i2c busses 0 and 1 ... Maybe this is a way to go? Yes, that sounds like the right kind of direction. Well it certainly is useful to have dynamic I2C, but it might be tricky until we have a pre-reloc malloc()? Yep ... not only this, we maybe have not enough RAM for it, because RAM is not initialized and we are using some SRAM, cache, ... for stack ... (/dreaming on Sometimes I think, we should switch completely to boot basically with SPL for all boards (in SPL we do not need mutliadapter/mutlibus support), so we could start U-Boot directly relocated in RAM from SPL with an arch independent board.c and all RAM availiable, which would solve some problems ... /dreaming off) We don't need to do everything at once. It would be nice to get the adapter parameter in there though, to avoid two steps of driver did this, see: http://git.denx.de/?p=u-boot/u-boot-i2c.git;a=shortlog;h=refs/heads/multibus_v2_20121030 change. But I would encourage you Heiko to get this tidied up a bit and merged, since it is already a big step forward. Ok, we should vote here, if we a) go ahead with this patchset b) wait for DM is ready c) rework this patchserie here completely new (dynamic registration) as stephen suggested U-Boot shell; there will be I2C busses that exist but cannot be used. Is this what we want? Perhaps it is in fact a good idea to always make the Now, this is wrong! You mix here i2c bus with i2c adapter! We have some i2c adapters which are defined but (maybe) not used ... U-Boot shell's I2C bus IDs be the same as the HW's, and hence leave gaps when some ports aren't enabled? That would be a departure from the way USB is handled today though. Hmm.. but is this possible? If we have a board with 2 (or more) different i2c adapters (which is now possible with the new framework), for example 2 i2c soft adapters + 4 tegra i2c adapter ... if we say the i2c tegra adapters are the first 4 i2c busses, so we cannot longer say the two soft i2c adapters are starting from 0 too (and vice versa) ... I was talking about the I2C HW in the SoC itself. There isn't any concept of an expected I2C bus/adapter ID for anything outside the SoC. Well the device tree should take care of this (in the alias section). The numbering of i2c ports should be done that way. See Tegra USB for how this works, as an example (board_usb_init() calls fdtdec_find_aliases_for_id(), then add_port() to add each of the ports it finds). bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] tegra: i2c: Add function to know about current bus
Hello Simon,
On 05.11.2012 21:43, Simon Glass wrote:
Hi Heiko,
On Tue, Oct 30, 2012 at 10:26 PM, Heiko Schocherh...@denx.de wrote:
Hello Simon,
On 30.10.2012 18:28, Simon Glass wrote:
Rather than using a variable in various places, add a single function,
tegra_i2c_get_bus(), which returns a pointer to information about a
bus.
This will make it easier to move to the new i2c framework.
Signed-off-by: Simon Glasss...@chromium.org
---
drivers/i2c/tegra_i2c.c | 78
--
1 files changed, 61 insertions(+), 17 deletions(-)
First question, did you tried the new i2c framework on some HW? Works it
for you?
Yes, it works fine. Tried on a seaboard.
Great, thanks for testing!
diff --git a/drivers/i2c/tegra_i2c.c b/drivers/i2c/tegra_i2c.c
index efc77fa..3e157f4 100644
--- a/drivers/i2c/tegra_i2c.c
+++ b/drivers/i2c/tegra_i2c.c
[...]
so the probe/read/write and set_bus_speed() functions gets now a
struct i2c_adapter pointer ... i2c driver internally, we need only
the struct i2c_adapter, which the i2c core passes to the i2c driver.
So this function would look like now:
+static struct i2c_bus *tegra_i2c_get_bus(struct i2c_adapter *adap)
Sounds good. Are you going to send a new patch?
Yes, want to do some more test ... and waiting for the result of the
vote, which direction we should go, see previous EMail ...
+{
+ struct i2c_bus *bus;
^^
maybe a rename to i2c_tegra_driver would be good?
+ bus =i2c_controllers[adap-hwadapnr];
+ if (!bus-inited) {
+ debug(%s: Bus %u not available\n, __func__, bus_num);
+ return NULL;
+ }
+
+ return bus;
+}
With this, we can get rid of i2c_bus_num in this driver.
Also the probe/read/write and set_bus_speed() functions needs to
be adapted. I can do this for you, and add this patchset to my
v2 post, if it is ok for you?
Of course.
Ok, do this ...
unsigned int i2c_get_bus_speed(void)
This function is not needed for the new framework!
[...]
Yes, I thought I removed it in 2/2, perhaps not.
int i2c_set_bus_speed(unsigned int speed)
{
- struct i2c_bus *i2c_bus;
+ struct i2c_bus *bus;
- i2c_bus =i2c_controllers[i2c_bus_num];
- i2c_bus-speed = speed;
- i2c_init_controller(i2c_bus);
+ bus = tegra_i2c_get_bus(i2c_bus_num);
+ if (!bus)
+ return 0;
+ bus-speed = speed;
+ i2c_init_controller(bus);
return 0;
}
@@ -426,7 +458,7 @@ void i2c_init(int speed, int slaveaddr)
[...]
Rest looks good to me.
Thanks!
Will await your further patch, and I am ready to test. Thanks.
Thanks!
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] video: atmel: implement lcd_setcolreg funtion
Hi Bo,
On 08.11.2012 04:06, Bo Shen wrote:
Hi Andreas,
On 11/7/2012 21:26, Marek Vasut wrote:
Dear Bo Shen,
Hi Marek,
On 11/7/2012 6:54, Marek Vasut wrote:
Dear Andreas Bießmann,
From: Bo Shen voice.s...@atmel.com
Missing commit message
Signed-off-by: Bo Shen voice.s...@atmel.com
Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com
---
since v2:
* add this single patch
drivers/video/atmel_hlcdfb.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/video/atmel_hlcdfb.c
b/drivers/video/atmel_hlcdfb.c
index beb7fa3..4110d4d 100644
--- a/drivers/video/atmel_hlcdfb.c
+++ b/drivers/video/atmel_hlcdfb.c
@@ -51,6 +51,12 @@ short console_row;
#define lcdc_readl(reg)__raw_readl((reg))
#define lcdc_writel(reg, val)__raw_writel((val), (reg))
+void lcd_setcolreg(ushort regno, ushort red, ushort green, ushort
blue)
+{
+lcdc_writel((red 16) | (green 8) | blue,
+panel_info.mmio + ATMEL_LCDC_LUT(regno));
So this is RGB666? Or what are those magic numbers ?
This is a little different with the driver of atmel_lcdfb.c.
The register for LUT is layout as following:
RCLUT (24 ~ 16), GCLUT (15 ~ 8) and BCLUT (7 ~ 0).
So, use those magic numbers.
Good, can you define those magic offsets then please?
Will you redo your patch series or do I need to implement this and send
the patch to you again?
can you please just send a v4 for this single patch? Add correct
in-reply-to header so we can see it belongs to the series. Thanks in
advance, I'm a bit busy currently.
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 1/4] microblaze: Fix compilation warning in ext2_find_next_zero_bit
On 11/08/2012 02:30 AM, Marek Vasut wrote:
Dear Michal Simek,
On 10/05/2012 06:48 PM, Marek Vasut wrote:
Dear Michal Simek,
ext2_find_next_zero_bit must be also static if __swab32 is also static.
Warning:
include/asm/bitops.h:369:22: warning: '__fswab32' is static but
used in inline function 'ext2_find_next_zero_bit'
which is not static [enabled by default]
Signed-off-by: Michal Simek mon...@monstr.eu
---
arch/microblaze/include/asm/bitops.h |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/microblaze/include/asm/bitops.h
b/arch/microblaze/include/asm/bitops.h index e8c835f..eafa2b5 100644
--- a/arch/microblaze/include/asm/bitops.h
+++ b/arch/microblaze/include/asm/bitops.h
@@ -319,7 +319,8 @@ extern __inline__ int ext2_test_bit(int nr, const
volatile void * addr) #define ext2_find_first_zero_bit(addr, size) \
ext2_find_next_zero_bit((addr), (size), 0)
-extern __inline__ unsigned long ext2_find_next_zero_bit(void *addr,
unsigned long size, unsigned long offset) +static inline unsigned long
ext2_find_next_zero_bit(void *addr,
+ unsigned long size, unsigned long offset)
{
unsigned long *p = ((unsigned long *) addr) + (offset 5);
unsigned long result = offset ~31UL;
I'd rather see it done the other way -- drop the inline and let compiler
decide. What are the size penalties ?
With inline
text data bss dec hex filename
361914 14698 232344 608956 94abc ./u-boot
without inline
text data bss dec hex filename
361922 14698 232368 608988 94adc ./u-boot
But the problem is that I can see a lot of warnings that this function is
unused. u-boot/include/asm/bitops.h:322:22: warning:
'ext2_find_next_zero_bit' defined but not used [-Wunused-function]
FYI: I have just grepped source tree and I see that the same solution is
used by blackfin/mips and powerpc.
$ grep -rn ext2_find_next_zero_bit arch/ | grep static
arch/microblaze/include/asm/bitops.h:322:static inline unsigned long
ext2_find_next_zero_bit(void *addr,
arch/blackfin/include/asm/bitops.h:324:static __inline__ unsigned long
ext2_find_next_zero_bit(void *addr,
arch/mips/include/asm/bitops.h:830:static __inline__ unsigned long
ext2_find_next_zero_bit(void *addr, unsigned long size, unsigned long
offset) arch/powerpc/include/asm/bitops.h:344:static __inline__ unsigned
long ext2_find_next_zero_bit(void *addr,
DAMN :-( Maybe we should focus on --gc-sections for whole u-boot. Anyway, I'd
say apply this and then start working on the --gc-sections.
I have passed this to our toolchain guy.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
