Re: [U-Boot] [PATCH V4 6/6] config: SMDK5420: Enable S2MPS11 pmic
On 06/01/14 20:49, Leela Krishna Amudala wrote: configure S2MPS11 pmic on SMDK5420 Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com Acked-by: Simon Glass s...@chromium.org --- include/configs/smdk5420.h |4 1 file changed, 4 insertions(+) diff --git a/include/configs/smdk5420.h b/include/configs/smdk5420.h index 447f8e5..46aeec0 100644 --- a/include/configs/smdk5420.h +++ b/include/configs/smdk5420.h @@ -53,4 +53,8 @@ #define CONFIG_MAX_I2C_NUM 11 +#define CONFIG_POWER +#define CONFIG_POWER_I2C already defined at exynos5-dt.h +#define CONFIG_POWER_S2MPS11 + #endif /* __CONFIG_5420_H */ Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 5/6] exynos: Add a common DT based PMIC driver initialization
On 06/01/14 20:49, Leela Krishna Amudala wrote:
Most of i2c PMIC drivers follow the same initialization sequence,
let's generalize it in a common file.
The initialization function finds the PMIC in the device tree, and if
found - registers it in the list of known PMICs and initializes it,
iterating through the table of settings supplied by the caller.
Signed-off-by: Vadim Bendebury vben...@chromium.org
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
Reviewed-by: Doug Anderson diand...@google.com
Acked-by: Simon Glass s...@chromium.org
---
board/samsung/common/board.c | 22 +
drivers/power/pmic/Makefile |1 +
drivers/power/pmic/pmic_common.c | 97
++
drivers/power/power_core.c | 14 ++
include/power/pmic.h | 34 +
5 files changed, 168 insertions(+)
create mode 100644 drivers/power/pmic/pmic_common.c
diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index b3b84c1..d23a7a6 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -23,6 +23,7 @@
#include power/pmic.h
#include asm/arch/sromc.h
#include power/max77686_pmic.h
+#include power/s2mps11_pmic.h
Do we need to include those two header files (max77686 and s2mps11) together?
DECLARE_GLOBAL_DATA_PTR;
@@ -160,6 +161,25 @@ static int board_init_cros_ec_devices(const void *blob)
}
#endif
+#ifdef CONFIG_POWER_S2MPS11
please move this block into #if defined(CONFIG_POWER).
+int board_init_s2mps11(void)
+{
+ const struct pmic_init_ops pmic_ops[] = {
+ {PMIC_REG_WRITE, S2MPS11_BUCK1_CTRL2, S2MPS11_BUCK_CTRL2_1V},
+ {PMIC_REG_WRITE, S2MPS11_BUCK2_CTRL2,
+ S2MPS11_BUCK_CTRL2_1_2625V},
+ {PMIC_REG_WRITE, S2MPS11_BUCK3_CTRL2, S2MPS11_BUCK_CTRL2_1V},
+ {PMIC_REG_WRITE, S2MPS11_BUCK4_CTRL2, S2MPS11_BUCK_CTRL2_1V},
+ {PMIC_REG_WRITE, S2MPS11_BUCK6_CTRL2, S2MPS11_BUCK_CTRL2_1V},
+ {PMIC_REG_UPDATE, S2MPS11_REG_RTC_CTRL,
+ S2MPS11_RTC_CTRL_32KHZ_CP_EN | S2MPS11_RTC_CTRL_JIT},
+ {PMIC_REG_BAIL}
+ };
+
+ return pmic_common_init(COMPAT_SAMSUNG_S2MPS11_PMIC, pmic_ops);
+}
+#endif
+
#if defined(CONFIG_POWER)
#ifdef CONFIG_POWER_MAX77686
static int max77686_init(void)
@@ -263,6 +283,8 @@ int power_init_board(void)
#ifdef CONFIG_POWER_MAX77686
ret = max77686_init();
+#elif defined(CONFIG_POWER_S2MPS11)
+ ret = board_init_s2mps11();
#endif
return ret;
diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
index 0b45ffa..5e236a3 100644
--- a/drivers/power/pmic/Makefile
+++ b/drivers/power/pmic/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
obj-$(CONFIG_POWER_MAX77686) += pmic_max77686.o
obj-$(CONFIG_POWER_TPS65217) += pmic_tps65217.o
obj-$(CONFIG_POWER_TPS65910) += pmic_tps65910.o
+obj-$(CONFIG_POWER) += pmic_common.o
diff --git a/drivers/power/pmic/pmic_common.c
b/drivers/power/pmic/pmic_common.c
new file mode 100644
index 000..3117ae2
--- /dev/null
+++ b/drivers/power/pmic/pmic_common.c
@@ -0,0 +1,97 @@
+/*
+ * Copyright (c) 2013 The Chromium OS Authors. All rights reserved.
Please write on the author of this file.
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+#include common.h
+#include fdtdec.h
+#include errno.h
+#include power/pmic.h
+#include power/s2mps11_pmic.h
+#include power/max77686_pmic.h
Why common driver need specific pmic's header file?
It is wrong architecture.
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static unsigned pmic_number_of_regs(enum fdt_compat_id pmic_compat)
+{
+ switch (pmic_compat) {
+ case COMPAT_SAMSUNG_S2MPS11_PMIC:
+ return S2MPS11_NUM_OF_REGS;
+ default:
+ break;
+ }
+ return 0;
+}
+
+int pmic_common_init(enum fdt_compat_id pmic_compat,
+ const struct pmic_init_ops *pmic_ops)
+{
+ const void *blob = gd-fdt_blob;
+ struct pmic *p;
+ int node, parent, ret;
+ unsigned number_of_regs = pmic_number_of_regs(pmic_compat);
+ const char *pmic_name, *comma;
+
+ if (!number_of_regs) {
+ printf(%s: %s - not a supported PMIC\n,
+__func__, fdtdec_get_compatible(pmic_compat));
+ return -1;
+ }
+
+ node = fdtdec_next_compatible(blob, 0, pmic_compat);
+ if (node 0) {
+ debug(PMIC: Error %s. No node for %s in device tree\n,
+ fdt_strerror(node), fdtdec_get_compatible(pmic_compat));
+ return node;
+ }
+
+ pmic_name = fdtdec_get_compatible(pmic_compat);
+ comma = strchr(pmic_name, ',');
+ if (comma)
+ pmic_name = comma + 1;
+
+ p = pmic_alloc();
+
+ if (!p) {
+ printf(%s: POWER allocation error!\n, __func__);
+
Re: [U-Boot] [PATCH 7/8] smdk5420: Correct the vbus gpio configuration for USB controller
On Tuesday, January 07, 2014 at 07:37:46 AM, Vivek Gautam wrote:
Hi Marek,
On Mon, Jan 6, 2014 at 9:22 PM, Marek Vasut ma...@denx.de wrote:
On Monday, January 06, 2014 at 10:29:42 AM, Vivek Gautam wrote:
On smdk5420 two availbale XHCI controllers require VBUS GPIO
to be configured, the EHCI however doesn't have any such VBUS
GPIO. So correcting the available board_usb_vbus_init() function
to the needs.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
board/samsung/smdk5420/smdk5420.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/board/samsung/smdk5420/smdk5420.c
b/board/samsung/smdk5420/smdk5420.c index 3ad2ad0..4f23000 100644
--- a/board/samsung/smdk5420/smdk5420.c
+++ b/board/samsung/smdk5420/smdk5420.c
@@ -18,14 +18,15 @@
DECLARE_GLOBAL_DATA_PTR;
-#ifdef CONFIG_USB_EHCI_EXYNOS
+#ifdef CONFIG_USB_XHCI_EXYNOS
static int board_usb_vbus_init(void)
{
- struct exynos5_gpio_part1 *gpio1 = (struct exynos5_gpio_part1 *)
-
samsung_get_base_gpio_part1(); + struct exynos5420_gpio_part4
*gpio4 = (struct exynos5420_gpio_part4 *) +
samsung_get_base_gpio_part4();
/* Enable VBUS power switch */
- s5p_gpio_direction_output(gpio1-x2, 6, 1);
+ s5p_gpio_direction_output(gpio4-g0, 5, 1);
+ s5p_gpio_direction_output(gpio4-g1, 4, 1);
This VBUS toggling should happen on per-port basis, right ?
No this VBUS gpio toggling is actually enabling the VBUS line of the
controller. And since we have 2 controllers on exynos5420, so added the
required 2 gpios for the purpose
(GPG0[5], and GPG1[4]).
So if I understand this correctly, it should happen on per-controller basis
then?
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 8/8] config: smdk5420: Enable support for multiple XHCI controllers
HI Marek, On Mon, Jan 6, 2014 at 9:24 PM, Marek Vasut ma...@denx.de wrote: Thanks for reviewing this. :-) On Monday, January 06, 2014 at 10:29:43 AM, Vivek Gautam wrote: Update USB_MAX_CONTROLLER_COUNT to be '2' to enable support for both usb 3.0 controllers on exynos5420. NOTE: To use EHCI on exynos5420, this change will need to be reverted, since there's only one EHCI controller available on exynos5420. OK, this I seriously dislike. Hence a question ... my feeling is the XHCI and EHCI code for handling multiple controllers and multiple ports is almost the same. Can this code be adjusted to handle both EHCI and XHCI controllers indiscriminately ? The controller count is actually used by the usb core (common/usb*) framework, right ? There's a need to add support for multiple controller types actually (so that EHCI and XHCI can be enabled simultaneously). Is that what you mean here ? This would result in having CONFIG_USB_MAX_CONTROLLER_COUNT 3 on this board and being able to use both EHCI and XHCI . Would this be possible for you to implement please ? Thanks ! Ok, so you mean get all the controllers present on the board (EHCI and XHCI) setup. I think right now, the way USB core handles the controller count is quite different, so that 'CONFIG_USB_MAX_CONTROLLER_COUNT' helps in probing multiple controllers of the same type. I had plans to add support to use controllers of different types (EHCI and XHCI etc) simultaneously. But haven't really put a code for that yet. Can you suggest some pointers about how would you like to see EHCI and XHCI or even OHCI work together :-) I can take up this. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- Best Regards Vivek Gautam Samsung RD Institute, Bangalore India ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/8] smdk5420: Correct the vbus gpio configuration for USB controller
On Tue, Jan 7, 2014 at 1:19 PM, Marek Vasut ma...@denx.de wrote:
On Tuesday, January 07, 2014 at 07:37:46 AM, Vivek Gautam wrote:
Hi Marek,
On Mon, Jan 6, 2014 at 9:22 PM, Marek Vasut ma...@denx.de wrote:
On Monday, January 06, 2014 at 10:29:42 AM, Vivek Gautam wrote:
On smdk5420 two availbale XHCI controllers require VBUS GPIO
to be configured, the EHCI however doesn't have any such VBUS
GPIO. So correcting the available board_usb_vbus_init() function
to the needs.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
board/samsung/smdk5420/smdk5420.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/board/samsung/smdk5420/smdk5420.c
b/board/samsung/smdk5420/smdk5420.c index 3ad2ad0..4f23000 100644
--- a/board/samsung/smdk5420/smdk5420.c
+++ b/board/samsung/smdk5420/smdk5420.c
@@ -18,14 +18,15 @@
DECLARE_GLOBAL_DATA_PTR;
-#ifdef CONFIG_USB_EHCI_EXYNOS
+#ifdef CONFIG_USB_XHCI_EXYNOS
static int board_usb_vbus_init(void)
{
- struct exynos5_gpio_part1 *gpio1 = (struct exynos5_gpio_part1 *)
-
samsung_get_base_gpio_part1(); + struct exynos5420_gpio_part4
*gpio4 = (struct exynos5420_gpio_part4 *) +
samsung_get_base_gpio_part4();
/* Enable VBUS power switch */
- s5p_gpio_direction_output(gpio1-x2, 6, 1);
+ s5p_gpio_direction_output(gpio4-g0, 5, 1);
+ s5p_gpio_direction_output(gpio4-g1, 4, 1);
This VBUS toggling should happen on per-port basis, right ?
No this VBUS gpio toggling is actually enabling the VBUS line of the
controller. And since we have 2 controllers on exynos5420, so added the
required 2 gpios for the purpose
(GPG0[5], and GPG1[4]).
So if I understand this correctly, it should happen on per-controller basis
then?
True, i thought of putting this in DT actually, similar to what we do
for exynos5250 as also available in the patch :
[PATCH 1/2] exynos5250: usb: Fix VBus gpio numbers for ehci and xhci
controllers (http://patchwork.ozlabs.org/patch/306553/)
But then the mathematics involved in gpio_direction_output() api
doesn't yield me the correct gpio pin (which actually gave in case of
Exynos5250).
So i thought of putting it in the board file only. I should have put
proper comment here although :-(
Best regards,
Marek Vasut
--
Best Regards
Vivek Gautam
Samsung RD Institute, Bangalore
India
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] boards.cfg: Delete the equivalent entries
There are some entries which produce the same binaries as other entries: - Lite5200 is equivalent to icecube_5200 - Lite5200_LOWBOOT is equivalent to icecube_5200_LOWBOOT - Lite5200_LOWBOOT08 is equivalent to icecube_5200_LOWBOOT08 - ep8248Eis equivalent to ep8248 - MPC8360ERDK_66 is equivalent to MPC8360ERDK - Adder87x/AdderUSB is equivalent to Adder - EVB64260_750CS is equivalent to EVB64260 Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- boards.cfg | 8 1 file changed, 8 deletions(-) diff --git a/boards.cfg b/boards.cfg index cb049aa..0726fc3 100644 --- a/boards.cfg +++ b/boards.cfg @@ -562,9 +562,6 @@ Active powerpc mpc5xxx- - icecube Active powerpc mpc5xxx- - icecube icecube_5200_DDR_LOWBOOT08 IceCube:SYS_TEXT_BASE=0xFF80,MPC5200_DDR - Active powerpc mpc5xxx- - icecube icecube_5200_LOWBOOT IceCube:SYS_TEXT_BASE=0xFF00 - Active powerpc mpc5xxx- - icecube icecube_5200_LOWBOOT08 IceCube:SYS_TEXT_BASE=0xFF80 - -Active powerpc mpc5xxx- - icecube Lite5200 IceCube - -Active powerpc mpc5xxx- - icecube Lite5200_LOWBOOT IceCube:SYS_TEXT_BASE=0xFF00 - -Active powerpc mpc5xxx- - icecube Lite5200_LOWBOOT08 IceCube:SYS_TEXT_BASE=0xFF80 - Active powerpc mpc5xxx- - icecube lite5200bIceCube:MPC5200_DDR,LITE5200B - Active powerpc mpc5xxx- - icecube lite5200b_LOWBOOT IceCube:MPC5200_DDR,LITE5200B,SYS_TEXT_BASE=0xFF00 - Active powerpc mpc5xxx- - icecube lite5200b_PM IceCube:MPC5200_DDR,LITE5200B,LITE5200B_PM - @@ -656,7 +653,6 @@ Active powerpc mpc8260- - cpu86 Active powerpc mpc8260- - cpu87 CPU87- - Active powerpc mpc8260- - cpu87 CPU87_ROMBOOTCPU87:BOOT_ROM - Active powerpc mpc8260- - ep8248 ep8248 - Yuli Barcohen y...@arabellasw.com -Active powerpc mpc8260- - ep8248 ep8248E ep8248 Yuli Barcohen y...@arabellasw.com Active powerpc mpc8260- - ids8247 IDS8247 - Heiko Schocher h...@denx.de Active powerpc mpc8260- - iphase4539 IPHASE4539 - Wolfgang Grandegger w...@denx.de Active powerpc mpc8260- - ispan ISPAN-
[U-Boot] [PATCH 1/3] cosmetic: boards.cfg: remove a trailing empty line
- Remove a trailing empty line - Add '#' to the empty line between two comment blocks Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- boards.cfg | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/boards.cfg b/boards.cfg index 0d655e4..5b6a150 100644 --- a/boards.cfg +++ b/boards.cfg @@ -31,7 +31,7 @@ # For any board without permanent maintainer, please contact # Wolfgang Denk w...@denx.de # And Cc: the u-boot@lists.denx.de mailing list. - +# # The list should be ordered according to the C locale. # # To keep the list formatted and sorted, script tools/reformat.py is available. @@ -1238,4 +1238,3 @@ Orphan powerpc mpc8xx - - genietv Orphan powerpc mpc8xx - - mbx8xx MBX - - Orphan powerpc mpc8xx - - mbx8xx MBX860T - - Orphan powerpc mpc8xx - - nx823 NX823- - - -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] Cleanup of boards.cfg
This series uses Fabio's patch as a prerequisite: boards.cfg: Keep the entries sorted http://patchwork.ozlabs.org/patch/305456/ Please apply it before this series. Masahiro Yamada (3): cosmetic: boards.cfg: remove a trailing empty line boards.cfg: Place - in the 8th field if it is the same as 7th boards.cfg: Delete the equivalent entries boards.cfg | 91 -- 1 file changed, 41 insertions(+), 50 deletions(-) -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/8] usb: xhci-exynos5: Add support for multiple USB 3.0 controllers
Hi Minkyu Kang,
On Tue, Jan 7, 2014 at 11:00 AM, Minkyu Kang mk7.k...@samsung.com wrote:
Dear Vivek Gautam,
On 06/01/14 18:29, Vivek Gautam wrote:
Add required support to use multiple USB 3.0 controllers available
on exynos5420 SoC.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/cpu/armv7/exynos/power.c| 18 --
arch/arm/include/asm/arch-exynos/cpu.h | 10
arch/arm/include/asm/arch-exynos/power.h |2 +-
drivers/usb/host/xhci-exynos5.c | 91
+-
drivers/usb/host/xhci.c |4 --
drivers/usb/host/xhci.h |4 ++
6 files changed, 91 insertions(+), 38 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/power.c
b/arch/arm/cpu/armv7/exynos/power.c
index 563abd7..0f8aa98 100644
--- a/arch/arm/cpu/armv7/exynos/power.c
+++ b/arch/arm/cpu/armv7/exynos/power.c
@@ -59,26 +59,34 @@ void set_usbhost_phy_ctrl(unsigned int enable)
exynos5_set_usbhost_phy_ctrl(enable);
}
-static void exynos5_set_usbdrd_phy_ctrl(unsigned int enable)
+static void exynos5_set_usbdrd_phy_ctrl(unsigned int enable, int dev_index)
{
struct exynos5_power *power =
(struct exynos5_power *)samsung_get_base_power();
+ /*
+ * Assuming here that the DRD_PHY_CONTROL registers
+ * are contiguous, so that :
+ * addressof(DRD_PHY1_CONTROL) = addressof(DRD_PHY_CONTROL) + 0x4;
+ * which is the case with exynos5420.
+ * For exynos5250 this should work out of box, since dev_index will
+ * always be '0' in that case
+ */
if (enable) {
/* Enabling USBDRD_PHY */
- setbits_le32(power-usbdrd_phy_control,
+ setbits_le32(power-usbdrd_phy_control + dev_index,
POWER_USB_DRD_PHY_CTRL_EN);
} else {
/* Disabling USBDRD_PHY */
- clrbits_le32(power-usbdrd_phy_control,
+ clrbits_le32(power-usbdrd_phy_control + dev_index,
POWER_USB_DRD_PHY_CTRL_EN);
}
}
-void set_usbdrd_phy_ctrl(unsigned int enable)
+void set_usbdrd_phy_ctrl(unsigned int enable, int dev_index)
{
if (cpu_is_exynos5())
- exynos5_set_usbdrd_phy_ctrl(enable);
+ exynos5_set_usbdrd_phy_ctrl(enable, dev_index);
}
static void exynos5_dp_phy_control(unsigned int enable)
diff --git a/arch/arm/include/asm/arch-exynos/cpu.h
b/arch/arm/include/asm/arch-exynos/cpu.h
index 718940b..d93cba9 100644
--- a/arch/arm/include/asm/arch-exynos/cpu.h
+++ b/arch/arm/include/asm/arch-exynos/cpu.h
@@ -54,6 +54,8 @@
#define EXYNOS4_USB_HOST_XHCI_BASE DEVICE_NOT_AVAILABLE
#define EXYNOS4_USB3PHY_BASE DEVICE_NOT_AVAILABLE
#define EXYNOS4_DMC_TZASC_BASE DEVICE_NOT_AVAILABLE
+#define EXYNOS4_USB_HOST_XHCI_1_BASE DEVICE_NOT_AVAILABLE
+#define EXYNOS4_USB3PHY_1_BASE DEVICE_NOT_AVAILABLE
/* EXYNOS4X12 */
#define EXYNOS4X12_GPIO_PART3_BASE 0x0386
@@ -93,6 +95,8 @@
#define EXYNOS4X12_USB_HOST_XHCI_BASEDEVICE_NOT_AVAILABLE
#define EXYNOS4X12_USB3PHY_BASE DEVICE_NOT_AVAILABLE
#define EXYNOS4X12_DMC_TZASC_BASEDEVICE_NOT_AVAILABLE
+#define EXYNOS4X12_USB_HOST_XHCI_1_BASE DEVICE_NOT_AVAILABLE
+#define EXYNOS4X12_USB3PHY_1_BASEDEVICE_NOT_AVAILABLE
/* EXYNOS5 */
#define EXYNOS5_I2C_SPACING 0x1
@@ -132,6 +136,8 @@
#define EXYNOS5_ADC_BASE DEVICE_NOT_AVAILABLE
#define EXYNOS5_MODEM_BASE DEVICE_NOT_AVAILABLE
#define EXYNOS5_DMC_TZASC_BASE DEVICE_NOT_AVAILABLE
+#define EXYNOS5_USB_HOST_XHCI_1_BASE DEVICE_NOT_AVAILABLE
+#define EXYNOS5_USB3PHY_1_BASE DEVICE_NOT_AVAILABLE
/* EXYNOS5420 */
#define EXYNOS5420_AUDIOSS_BASE 0x0381
@@ -153,6 +159,8 @@
#define EXYNOS5420_USBPHY_BASE 0x1213
#define EXYNOS5420_MMC_BASE 0x1220
#define EXYNOS5420_SROMC_BASE0x1225
+#define EXYNOS5420_USB_HOST_XHCI_1_BASE 0x1240
+#define EXYNOS5420_USB3PHY_1_BASE0x1250
No. we don't have to add phy_1 and xhci_1.
It looks weird.
please access phy1 and xhci1 by offset.
Ok, so you mean i should add offsets definitions for phy1 and xhci1
may be in the driver file or in
arch/arm/include/asm/arch-exynos/xhci-exynos.h file, and add these
offsets to xhci_base and
phy_base addresses ?
That should be fine, i will modify this accordingly.
#define EXYNOS5420_UART_BASE 0x12C0
#define EXYNOS5420_I2C_BASE 0x12C6
#define EXYNOS5420_I2C_8910_BASE 0x12E0
@@ -276,8 +284,10 @@ SAMSUNG_BASE(timer, PWMTIMER_BASE)
SAMSUNG_BASE(uart, UART_BASE)
SAMSUNG_BASE(usb_phy, USBPHY_BASE)
SAMSUNG_BASE(usb3_phy, USB3PHY_BASE)
+SAMSUNG_BASE(usb3_phy_1, USB3PHY_1_BASE)
SAMSUNG_BASE(usb_ehci, USB_HOST_EHCI_BASE)
SAMSUNG_BASE(usb_xhci,
Re: [U-Boot] [PATCH 7/8] smdk5420: Correct the vbus gpio configuration for USB controller
On Tuesday, January 07, 2014 at 10:03:01 AM, Vivek Gautam wrote:
On Tue, Jan 7, 2014 at 1:19 PM, Marek Vasut ma...@denx.de wrote:
On Tuesday, January 07, 2014 at 07:37:46 AM, Vivek Gautam wrote:
Hi Marek,
On Mon, Jan 6, 2014 at 9:22 PM, Marek Vasut ma...@denx.de wrote:
On Monday, January 06, 2014 at 10:29:42 AM, Vivek Gautam wrote:
On smdk5420 two availbale XHCI controllers require VBUS GPIO
to be configured, the EHCI however doesn't have any such VBUS
GPIO. So correcting the available board_usb_vbus_init() function
to the needs.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
board/samsung/smdk5420/smdk5420.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/board/samsung/smdk5420/smdk5420.c
b/board/samsung/smdk5420/smdk5420.c index 3ad2ad0..4f23000 100644
--- a/board/samsung/smdk5420/smdk5420.c
+++ b/board/samsung/smdk5420/smdk5420.c
@@ -18,14 +18,15 @@
DECLARE_GLOBAL_DATA_PTR;
-#ifdef CONFIG_USB_EHCI_EXYNOS
+#ifdef CONFIG_USB_XHCI_EXYNOS
static int board_usb_vbus_init(void)
{
- struct exynos5_gpio_part1 *gpio1 = (struct exynos5_gpio_part1
*) -
samsung_get_base_gpio_part1(); + struct exynos5420_gpio_part4
*gpio4 = (struct exynos5420_gpio_part4 *) +
samsung_get_base_gpio_part4();
/* Enable VBUS power switch */
- s5p_gpio_direction_output(gpio1-x2, 6, 1);
+ s5p_gpio_direction_output(gpio4-g0, 5, 1);
+ s5p_gpio_direction_output(gpio4-g1, 4, 1);
This VBUS toggling should happen on per-port basis, right ?
No this VBUS gpio toggling is actually enabling the VBUS line of the
controller. And since we have 2 controllers on exynos5420, so added the
required 2 gpios for the purpose
(GPG0[5], and GPG1[4]).
So if I understand this correctly, it should happen on per-controller
basis then?
True, i thought of putting this in DT actually, similar to what we do
for exynos5250 as also available in the patch :
[PATCH 1/2] exynos5250: usb: Fix VBus gpio numbers for ehci and xhci
controllers (http://patchwork.ozlabs.org/patch/306553/)
But then the mathematics involved in gpio_direction_output() api
doesn't yield me the correct gpio pin (which actually gave in case of
Exynos5250).
Ugh, does that mean we have a breakage in the GPIO or DT stuff ?
[...]
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 8/8] config: smdk5420: Enable support for multiple XHCI controllers
On Tuesday, January 07, 2014 at 09:55:37 AM, Vivek Gautam wrote: HI Marek, On Mon, Jan 6, 2014 at 9:24 PM, Marek Vasut ma...@denx.de wrote: Thanks for reviewing this. :-) On Monday, January 06, 2014 at 10:29:43 AM, Vivek Gautam wrote: Update USB_MAX_CONTROLLER_COUNT to be '2' to enable support for both usb 3.0 controllers on exynos5420. NOTE: To use EHCI on exynos5420, this change will need to be reverted, since there's only one EHCI controller available on exynos5420. OK, this I seriously dislike. Hence a question ... my feeling is the XHCI and EHCI code for handling multiple controllers and multiple ports is almost the same. Can this code be adjusted to handle both EHCI and XHCI controllers indiscriminately ? The controller count is actually used by the usb core (common/usb*) framework, right ? There's a need to add support for multiple controller types actually (so that EHCI and XHCI can be enabled simultaneously). Is that what you mean here ? Yes. That should not be too much of a problem though. This would result in having CONFIG_USB_MAX_CONTROLLER_COUNT 3 on this board and being able to use both EHCI and XHCI . Would this be possible for you to implement please ? Thanks ! Ok, so you mean get all the controllers present on the board (EHCI and XHCI) setup. Yes I think right now, the way USB core handles the controller count is quite different, so that 'CONFIG_USB_MAX_CONTROLLER_COUNT' helps in probing multiple controllers of the same type. The only problem is, that both EHCI and XHCI core implement: submit_control_msg() submit_bulk_msg() submit_int_msg() usb_lowlevel_init() usb_lowlevel_stop() How I'd do this: 1) Rename all these submit_*() functions to usb_submit_*() 2) Rename all five usb_*() functions to ehci_*() resp. xhci_*() 3) Implement translation layer, where the common code would still call usb_*() and the layer would determine whether to call ehci_*() or xhci_*() call. Surely, you'd need to change the probe() logic a bit, the controller drivers would have to call some usb_register_driver() function for each controller. This function would generate a new entry in a linked list of all controllers registered and would add a flag whether this controller is EHCI or XHCI. Effectively, this would even remove the need for CONFIG_USB_MAX_CONTROLLER_COUNT at all, since you'd be tracking all the USB controllers in the USB core code and in a linked list. I had plans to add support to use controllers of different types (EHCI and XHCI etc) simultaneously. But haven't really put a code for that yet. Can you suggest some pointers about how would you like to see EHCI and XHCI or even OHCI work together :-) I can take up this. Thank you, see above please. OHCI might be nastier, but should happen along these lines above as well. 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] avr32: move CONFIG_AVR32 definition to arch/avr32/config.mk
On 01/06/2014 07:45 AM, Masahiro Yamada wrote: Like other architectures, CONFIG_AVR32 can be defined in arch/avr32/config.mk rather than board header files. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Andreas Bießmann andreas.de...@googlemail.com Acked-by: Andreas Bießmann andreas.de...@googlemail.com --- arch/avr32/config.mk| 2 +- include/configs/atngw100.h | 1 - include/configs/atngw100mkii.h | 1 - include/configs/atstk1002.h | 1 - include/configs/atstk1003.h | 1 - include/configs/atstk1004.h | 1 - include/configs/atstk1006.h | 1 - include/configs/favr-32-ezkit.h | 1 - include/configs/grasshopper.h | 1 - include/configs/hammerhead.h| 1 - include/configs/mimc200.h | 1 - 11 files changed, 1 insertion(+), 11 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] config: smdk5420: Enable support for multiple XHCI controllers
On Tue, Jan 7, 2014 at 2:44 PM, Marek Vasut ma...@denx.de wrote: On Tuesday, January 07, 2014 at 09:55:37 AM, Vivek Gautam wrote: HI Marek, On Mon, Jan 6, 2014 at 9:24 PM, Marek Vasut ma...@denx.de wrote: Thanks for reviewing this. :-) On Monday, January 06, 2014 at 10:29:43 AM, Vivek Gautam wrote: Update USB_MAX_CONTROLLER_COUNT to be '2' to enable support for both usb 3.0 controllers on exynos5420. NOTE: To use EHCI on exynos5420, this change will need to be reverted, since there's only one EHCI controller available on exynos5420. OK, this I seriously dislike. Hence a question ... my feeling is the XHCI and EHCI code for handling multiple controllers and multiple ports is almost the same. Can this code be adjusted to handle both EHCI and XHCI controllers indiscriminately ? The controller count is actually used by the usb core (common/usb*) framework, right ? There's a need to add support for multiple controller types actually (so that EHCI and XHCI can be enabled simultaneously). Is that what you mean here ? Yes. That should not be too much of a problem though. True :-) This would result in having CONFIG_USB_MAX_CONTROLLER_COUNT 3 on this board and being able to use both EHCI and XHCI . Would this be possible for you to implement please ? Thanks ! Ok, so you mean get all the controllers present on the board (EHCI and XHCI) setup. Yes I think right now, the way USB core handles the controller count is quite different, so that 'CONFIG_USB_MAX_CONTROLLER_COUNT' helps in probing multiple controllers of the same type. The only problem is, that both EHCI and XHCI core implement: submit_control_msg() submit_bulk_msg() submit_int_msg() usb_lowlevel_init() usb_lowlevel_stop() exactly. How I'd do this: 1) Rename all these submit_*() functions to usb_submit_*() 2) Rename all five usb_*() functions to ehci_*() resp. xhci_*() This will happen in each controller drivers (ehci/xhci) which would eventually be called fro upper translation layer you mentioned below, right ? 3) Implement translation layer, where the common code would still call usb_*() and the layer would determine whether to call ehci_*() or xhci_*() call. Surely, you'd need to change the probe() logic a bit, the controller drivers would have to call some usb_register_driver() function for each controller. This function would generate a new entry in a linked list of all controllers registered and would add a flag whether this controller is EHCI or XHCI. Ok, i can understand this. Will try to put up code for this. Effectively, this would even remove the need for CONFIG_USB_MAX_CONTROLLER_COUNT at all, since you'd be tracking all the USB controllers in the USB core code and in a linked list. Yeah, right. We won't need the controller count in this case. I had plans to add support to use controllers of different types (EHCI and XHCI etc) simultaneously. But haven't really put a code for that yet. Can you suggest some pointers about how would you like to see EHCI and XHCI or even OHCI work together :-) I can take up this. Thank you, see above please. OHCI might be nastier, but should happen along these lines above as well. Ok, so first i will take up EHCI and XHCI then, and later 'll see the OHCI part. Best regards, Marek Vasut -- Best Regards Vivek Gautam Samsung RD Institute, Bangalore India ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] i.MX6: Ensure AHB clock is 132MHz in low freq boot mode
For low freq boot mode(ARM boot up with 396MHz), ROM
will not set AHB clock to 132MHz, and the reset value of
AHB divider is incorrect which will lead to wrong AHB
rate, need to correct it. To enable low freq boot mode,
need to set BOOT_CFG2[2] to high, tested on i.MX6Q/DL
SabreSD board and i.MX6SL EVK board.
Signed-off-by: Anson Huang b20...@freescale.com
---
arch/arm/cpu/armv7/mx6/soc.c | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
index a390296..edf3139 100644
--- a/arch/arm/cpu/armv7/mx6/soc.c
+++ b/arch/arm/cpu/armv7/mx6/soc.c
@@ -131,10 +131,30 @@ static void imx_set_wdog_powerdown(bool enable)
writew(enable, wdog2-wmcr);
}
+static void set_ahb_rate(u32 val)
+{
+ struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
+ u32 reg, div;
+
+ div = get_periph_clk() / val - 1;
+ reg = readl(mxc_ccm-cbcdr);
+
+ writel((reg (~MXC_CCM_CBCDR_AHB_PODF_MASK)) |
+ (div MXC_CCM_CBCDR_AHB_PODF_OFFSET), mxc_ccm-cbcdr);
+}
+
int arch_cpu_init(void)
{
init_aips();
+ /*
+* When low freq boot is enabled, ROM will not set AHB
+* freq, so we need to ensure AHB freq is 132MHz in such
+* scenario.
+*/
+ if (mxc_get_clock(MXC_ARM_CLK) == 39600)
+ set_ahb_rate(13200);
+
set_vddsoc(1200); /* Set VDDSOC to 1.2V */
imx_set_wdog_powerdown(false); /* Disable PDE bit of WMCR register */
--
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 5/8] usb: xhci-exynos5: Add support for multiple USB 3.0 controllers
On Mon, Jan 6, 2014 at 9:21 PM, Marek Vasut ma...@denx.de wrote:
On Monday, January 06, 2014 at 10:29:40 AM, Vivek Gautam wrote:
Add required support to use multiple USB 3.0 controllers available
on exynos5420 SoC.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/cpu/armv7/exynos/power.c| 18 --
arch/arm/include/asm/arch-exynos/cpu.h | 10
arch/arm/include/asm/arch-exynos/power.h |2 +-
drivers/usb/host/xhci-exynos5.c | 91
+- drivers/usb/host/xhci.c |
4 --
drivers/usb/host/xhci.h |4 ++
6 files changed, 91 insertions(+), 38 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/power.c
b/arch/arm/cpu/armv7/exynos/power.c index 563abd7..0f8aa98 100644
--- a/arch/arm/cpu/armv7/exynos/power.c
+++ b/arch/arm/cpu/armv7/exynos/power.c
@@ -59,26 +59,34 @@ void set_usbhost_phy_ctrl(unsigned int enable)
exynos5_set_usbhost_phy_ctrl(enable);
}
-static void exynos5_set_usbdrd_phy_ctrl(unsigned int enable)
+static void exynos5_set_usbdrd_phy_ctrl(unsigned int enable, int
dev_index) {
struct exynos5_power *power =
(struct exynos5_power *)samsung_get_base_power();
+ /*
+ * Assuming here that the DRD_PHY_CONTROL registers
+ * are contiguous, so that :
+ * addressof(DRD_PHY1_CONTROL) = addressof(DRD_PHY_CONTROL) + 0x4;
+ * which is the case with exynos5420.
+ * For exynos5250 this should work out of box, since dev_index will
+ * always be '0' in that case
+ */
Why don't you convert the entry for usbdrd_phy_control into an array in the
'struct exynos5_power' structure instead ? Then you could index it with
dev_index.
Aah, i should have been more careful here. There's already a structure
available for exynos5420 exynos5420_power,
which i can use. I just would need to use api proid_is_exynos5420()
or proid_is_exynos5250() to differentiate between
the two.
[...]
Do you think it'd be possible to split this patch into drivers/usb/ specific
part and CPU-specific part ? I'd like to see that to prevent merge conflicts.
Ok, i'll separate out the two parts.
[...]
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
--
Best Regards
Vivek Gautam
Samsung RD Institute, Bangalore
India
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] i.MX6: Ensure AHB clock is 132MHz in low freq boot mode
For low freq boot mode(ARM boot up with 396MHz), ROM
will not set AHB clock to 132MHz, and the reset value of
AHB divider is incorrect which will lead to wrong AHB
rate, need to correct it. To enable low freq boot mode,
need to set BOOT_CFG2[2] to high, tested on i.MX6Q/DL
SabreSD board and i.MX6SL EVK board.
Signed-off-by: Anson Huang b20...@freescale.com
---
arch/arm/cpu/armv7/mx6/soc.c | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
index a390296..edf3139 100644
--- a/arch/arm/cpu/armv7/mx6/soc.c
+++ b/arch/arm/cpu/armv7/mx6/soc.c
@@ -131,10 +131,30 @@ static void imx_set_wdog_powerdown(bool enable)
writew(enable, wdog2-wmcr);
}
+static void set_ahb_rate(u32 val)
+{
+ struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
+ u32 reg, div;
+
+ div = get_periph_clk() / val - 1;
+ reg = readl(mxc_ccm-cbcdr);
+
+ writel((reg (~MXC_CCM_CBCDR_AHB_PODF_MASK)) |
+ (div MXC_CCM_CBCDR_AHB_PODF_OFFSET), mxc_ccm-cbcdr);
+}
+
int arch_cpu_init(void)
{
init_aips();
+ /*
+* When low freq boot is enabled, ROM will not set AHB
+* freq, so we need to ensure AHB freq is 132MHz in such
+* scenario.
+*/
+ if (mxc_get_clock(MXC_ARM_CLK) == 39600)
+ set_ahb_rate(13200);
+
set_vddsoc(1200); /* Set VDDSOC to 1.2V */
imx_set_wdog_powerdown(false); /* Disable PDE bit of WMCR register */
--
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] i.MX6: Ensure AHB clock is 132MHz in low freq boot mode
Hi Anson,
On Mon, Jan 6, 2014 at 7:31 PM, Anson Huang b20...@freescale.com wrote:
int arch_cpu_init(void)
{
init_aips();
+ /*
+* When low freq boot is enabled, ROM will not set AHB
+* freq, so we need to ensure AHB freq is 132MHz in such
+* scenario.
+*/
+ if (mxc_get_clock(MXC_ARM_CLK) == 39600)
+ set_ahb_rate(13200);
+
set_vddsoc(1200); /* Set VDDSOC to 1.2V */
Your patch looks good, but please rebase it against the latest
u-boot-imx tree because I sent a recent patch that sets vddsoc to
1.175V.
After doing so, you can add:
Reviewed-by: Fabio Estevam fabio.este...@freescale.com
Regards,
Fabio Estevam
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i.MX6: Ensure AHB clock is 132MHz in low freq boot mode
-Original Message-
From: Anson Huang [mailto:b20...@freescale.com]
Sent: Tuesday, January 07, 2014 5:32 AM
To: sba...@denx.de; eric.nel...@boundarydevices.com;
troy.ki...@boundarydevices.com; Estevam Fabio-R49496; Liu Hui-R64343
Cc: u-boot@lists.denx.de
Subject: [PATCH] i.MX6: Ensure AHB clock is 132MHz in low freq boot mode
For low freq boot mode(ARM boot up with 396MHz), ROM will not set AHB
clock to 132MHz, and the reset value of AHB divider is incorrect which
will lead to wrong AHB rate, need to correct it. To enable low freq boot
mode, need to set BOOT_CFG2[2] to high, tested on i.MX6Q/DL SabreSD board
and i.MX6SL EVK board.
Signed-off-by: Anson Huang b20...@freescale.com
Looks good to me.
Acked-by: Jason Liu r64...@freescale.com
---
arch/arm/cpu/armv7/mx6/soc.c | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
index a390296..edf3139 100644
--- a/arch/arm/cpu/armv7/mx6/soc.c
+++ b/arch/arm/cpu/armv7/mx6/soc.c
@@ -131,10 +131,30 @@ static void imx_set_wdog_powerdown(bool enable)
writew(enable, wdog2-wmcr);
}
+static void set_ahb_rate(u32 val)
+{
+ struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
+ u32 reg, div;
+
+ div = get_periph_clk() / val - 1;
+ reg = readl(mxc_ccm-cbcdr);
+
+ writel((reg (~MXC_CCM_CBCDR_AHB_PODF_MASK)) |
+ (div MXC_CCM_CBCDR_AHB_PODF_OFFSET), mxc_ccm-cbcdr); }
+
int arch_cpu_init(void)
{
init_aips();
+ /*
+ * When low freq boot is enabled, ROM will not set AHB
+ * freq, so we need to ensure AHB freq is 132MHz in such
+ * scenario.
+ */
+ if (mxc_get_clock(MXC_ARM_CLK) == 39600)
+ set_ahb_rate(13200);
+
set_vddsoc(1200); /* Set VDDSOC to 1.2V */
imx_set_wdog_powerdown(false); /* Disable PDE bit of WMCR register
*/
--
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 5/8] usb: xhci-exynos5: Add support for multiple USB 3.0 controllers
On Tuesday, January 07, 2014 at 10:15:20 AM, Vivek Gautam wrote: [...] diff --git a/arch/arm/include/asm/arch-exynos/cpu.h b/arch/arm/include/asm/arch-exynos/cpu.h index 718940b..d93cba9 100644 --- a/arch/arm/include/asm/arch-exynos/cpu.h +++ b/arch/arm/include/asm/arch-exynos/cpu.h [...] @@ -153,6 +159,8 @@ #define EXYNOS5420_USBPHY_BASE 0x1213 #define EXYNOS5420_MMC_BASE 0x1220 #define EXYNOS5420_SROMC_BASE0x1225 +#define EXYNOS5420_USB_HOST_XHCI_1_BASE 0x1240 +#define EXYNOS5420_USB3PHY_1_BASE0x1250 No. we don't have to add phy_1 and xhci_1. It looks weird. please access phy1 and xhci1 by offset. Ok, so you mean i should add offsets definitions for phy1 and xhci1 may be in the driver file or in arch/arm/include/asm/arch-exynos/xhci-exynos.h file, and add these offsets to xhci_base and phy_base addresses ? That should be fine, i will modify this accordingly. #define EXYNOS5420_UART_BASE 0x12C0 #define EXYNOS5420_I2C_BASE 0x12C6 #define EXYNOS5420_I2C_8910_BASE 0x12E0 [...] Minor rant, please trim the email when replying so it contains only the relevant parts. Otherwise, the irrelevant noise might cause some of the relevant replies to get lost. 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 8/8] config: smdk5420: Enable support for multiple XHCI controllers
On Tuesday, January 07, 2014 at 10:37:24 AM, Vivek Gautam wrote: [...] How I'd do this: 1) Rename all these submit_*() functions to usb_submit_*() 2) Rename all five usb_*() functions to ehci_*() resp. xhci_*() This will happen in each controller drivers (ehci/xhci) which would eventually be called fro upper translation layer you mentioned below, right ? Yes. Actually, thinking of this some more, to make the transition more fine- grained, we might go about it like this even: 1) Rename all these submit_*() functions to usb_submit_*() - This one stay the same, just rename them all so they're consistent. 2) Rename all five usb_*() functions to ehci_*() resp. xhci_*() - In here, we should already have a fetus of the translation layer. My idea here would be to implement drivers/usb/host/usb_trans.c, which would implement all five usb_*() functions only as a wrappers. Each of the five function would contain #ifdef and call the respective xhci_*() or ehci_*() or [ou]hci_*() implementation depending on the configuration. This would preserve the current behavior, which would be nice. 3) Implement real translation layer - Here, the usb_trans.c would need to be extended to track all the controllers in a linked list. The usb core code would not change much, all of the logic would live in this usb_trans.c . - Here, the usb_trans.c will no longer contain any of the ifdefs from step 2), but it will likely turn out you would need to have ifdefs to prevent triggering GCC complaint about missing definition of a functions. I don't want to impose my ideas on you too hard, so please push back if you see some obvious flaws or have a much better idea! 3) Implement translation layer, where the common code would still call usb_*() and the layer would determine whether to call ehci_*() or xhci_*() call. Surely, you'd need to change the probe() logic a bit, the controller drivers would have to call some usb_register_driver() function for each controller. This function would generate a new entry in a linked list of all controllers registered and would add a flag whether this controller is EHCI or XHCI. Ok, i can understand this. Will try to put up code for this. Thank you, this is much appreciated ! Effectively, this would even remove the need for CONFIG_USB_MAX_CONTROLLER_COUNT at all, since you'd be tracking all the USB controllers in the USB core code and in a linked list. Yeah, right. We won't need the controller count in this case. Yes, nonexistent preprocessor symbol is a good preprocessor symbol :) I had plans to add support to use controllers of different types (EHCI and XHCI etc) simultaneously. But haven't really put a code for that yet. Can you suggest some pointers about how would you like to see EHCI and XHCI or even OHCI work together :-) I can take up this. Thank you, see above please. OHCI might be nastier, but should happen along these lines above as well. Ok, so first i will take up EHCI and XHCI then, and later 'll see the OHCI part. Don't forget UHCI too. I think you will need to tackle all four at once, but it should be mostly manual work, nothing too frightening. I think your predecessors rectified the API nicely already :) 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 5/8] usb: xhci-exynos5: Add support for multiple USB 3.0 controllers
On Tue, Jan 7, 2014 at 4:29 PM, Marek Vasut ma...@denx.de wrote: On Tuesday, January 07, 2014 at 10:15:20 AM, Vivek Gautam wrote: [...] Minor rant, please trim the email when replying so it contains only the relevant parts. Otherwise, the irrelevant noise might cause some of the relevant replies to get lost. Sure, will keep that in mind. -- Best Regards Vivek Gautam Samsung RD Institute, Bangalore India ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] mx6: clock: Pass the frequency as argument of enable_fec_anatop_clock()
Hi Fabio, On 06/01/2014 14:12, Fabio Estevam wrote: Hi Stefano, On Fri, Jan 3, 2014 at 3:55 PM, Fabio Estevam feste...@gmail.com wrote: From: Fabio Estevam fabio.este...@freescale.com Provide an argument to enable_fec_anatop_clock() to specify the clock frequency that will be generated. No changes are made to mx6slevk, which uses the default 50MHz fec clock. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Stefano, I don't have access to a mx6slevk board at the moment, but will test it on Monday. Wanted to submit it so that people could provide some feedback on the series. mx6slevk is using the default clock of 50MHz, so I kept it unchanged. Just tested on a mx6slevk and confirmed that FEC is functional after this patch. Thanks for testing - patch is ok for me. Acked-by: Stefano Babic sba...@denx.de Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/12] samsung: misc: Add LCD download menu.
Hello Minkyu,
Thank you for review.
On 01/06/2014 12:38 PM, Minkyu Kang wrote:
On 04/01/14 01:43, Przemyslaw Marczak wrote:
This simple LCD menu allows run one of download mode on device
without writing on console or for fast and easy upgrade.
This feature check user keys combination at boot:
- power key + volume up - download menu
- power key + volume down - thor mode (without menu)
New configs:
- CONFIG_LCD_MENU
- CONFIG_LCD_MENU_BOARD
which depends on: CONFIG_MISC_INIT_R
For proper effect this feature needs following definitions:
Power key:
- KEY_PWR_PMIC_NAME - (string) pmic which supports power key check
Register address:
- KEY_PWR_STATUS_REG
- KEY_PWR_INTERRUPT_REG
Register power key mask:
- KEY_PWR_STATUS_MASK
- KEY_PWR_INTERRUPT_MASK
Gpio numbers:
- KEY_PWR_INTERRUPT_MASK
- KEY_VOL_DOWN_GPIO
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
---
Changes v2:
- remove keys.h - definitions should be in boards headers
- add misc.h
- code cleanup
- extend commit msg by more informations
Changes v3:
- none
board/samsung/common/misc.c | 340 +++
board/samsung/common/misc.h | 18 +++
2 files changed, 358 insertions(+)
create mode 100644 board/samsung/common/misc.h
diff --git a/board/samsung/common/misc.c b/board/samsung/common/misc.c
index 3a91d62..93f766c 100644
--- a/board/samsung/common/misc.c
+++ b/board/samsung/common/misc.c
@@ -8,6 +8,341 @@
#include common.h
#include lcd.h
#include libtizen.h
+#include errno.h
+#include version.h
+#include asm/sizes.h
+#include asm/arch/cpu.h
+#include asm/arch/gpio.h
+#include asm/gpio.h
+#include linux/input.h
+#include lcd.h
+#include libtizen.h
+#include power/pmic.h
+#include mmc.h
+#include misc.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#ifdef CONFIG_LCD_MENU
+static int power_key_pressed(int reg)
u32 reg?
+{
+ struct pmic *pmic = pmic_get(KEY_PWR_PMIC_NAME);
+ u32 status = 0;
= 0 do not need.
please do not use initial value, if possible.
+ u32 mask;
please check return value of pmic_get
pmic = pmic_get(KEY_PWR_PMIC_NAME);
if !(pmic)
return 0;
+
+ if (pmic_probe(pmic))
+ return 0;
+
+ if (!pmic) {
+ printf(%s: Not found\n, KEY_PWR_PMIC_NAME);
+ return 0;
+ }
+
+ if (reg == KEY_PWR_STATUS_REG)
+ mask = KEY_PWR_STATUS_MASK;
+ else
+ mask = KEY_PWR_INTERRUPT_MASK;
+
+ if (pmic_reg_read(pmic, reg, status))
+ return 0;
+
+ return !!(status mask);
+}
+
+static int key_pressed(int key)
+{
+ int value = 0;
please do not use initial value, if possible.
instead, please add value = 0 at default statement.
+
+ switch (key) {
+ case KEY_POWER:
+ value = power_key_pressed(KEY_PWR_INTERRUPT_REG);
+ break;
+ case KEY_VOLUMEUP:
+ value = !gpio_get_value(KEY_VOL_UP_GPIO);
+ break;
+ case KEY_VOLUMEDOWN:
+ value = !gpio_get_value(KEY_VOL_DOWN_GPIO);
+ break;
+ default:
+ break;
+ }
+
+ return value;
+}
+
+static int check_keys(void)
+{
+ int keys = 0;
+
+ if (key_pressed(KEY_POWER))
+ keys += KEY_POWER;
+ if (key_pressed(KEY_VOLUMEUP))
+ keys += KEY_VOLUMEUP;
+ if (key_pressed(KEY_VOLUMEDOWN))
+ keys += KEY_VOLUMEDOWN;
+
+ return keys;
+}
+
+/*
+ * 0 BOOT_MODE_INFO
+ * 1 BOOT_MODE_THOR
+ * 2 BOOT_MODE_UMS
+ * 3 BOOT_MODE_DFU
+ * 4 BOOT_MODE_EXIT
+ */
+static char *
+mode_name[BOOT_MODE_EXIT + 1] = {DEVICE,
please move the DEVICE to next line.
+ THOR,
+ UMS,
+ DFU,
+ EXIT};
please move the brace to next line.
+
+static char *
+mode_info[BOOT_MODE_EXIT + 1] = {info,
+downloader,
+mass storage,
+firmware update,
+and run normal boot};
ditto.
+
+static char *
+mode_cmd[BOOT_MODE_EXIT + 1] = {,
+ thor 0 mmc 0,
+ ums 0 mmc 0,
+ dfu 0 mmc 0,
+ };
ditto.
+
+static void display_board_info(void)
+{
#ifdef CONFIG_GENERIC_MMC
+ struct mmc *mmc = find_mmc_device(0);
#endif
+ vidinfo_t *vid = panel_info;
+
+ lcd_position_cursor(4, 4);
+
+ lcd_printf(%s\n\t, U_BOOT_VERSION);
+ lcd_puts(\n\t\tBoard Info:\n);
+#ifdef CONFIG_SYS_BOARD
+ lcd_printf(\tBoard name: %s\n, CONFIG_SYS_BOARD);
+#endif
+#ifdef CONFIG_REVISION_TAG
+ lcd_printf(\tBoard rev: %u\n, get_board_rev());
+#endif
+ lcd_printf(\tDRAM banks: %u\n, CONFIG_NR_DRAM_BANKS);
+ lcd_printf(\tDRAM size: %u MB\n, gd-ram_size / SZ_1M);
Re: [U-Boot] [PATCH v3 11/12] trats2: add LCD download menu support
Hello, On 01/06/2014 12:37 PM, Minkyu Kang wrote: On 04/01/14 02:21, Przemyslaw Marczak wrote: Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com --- changes v2: - add definitions for check keys - cleanup config definitions Changes v3: - remove CONFIG_BOARD_NAME from include/configs/trats2.h include/configs/trats2.h | 26 ++ 1 file changed, 26 insertions(+) diff --git a/include/configs/trats2.h b/include/configs/trats2.h index 740ceb1..453a37e 100644 --- a/include/configs/trats2.h +++ b/include/configs/trats2.h @@ -19,6 +19,7 @@ #define CONFIG_S5P/* which is in a S5P Family */ #define CONFIG_EXYNOS4/* which is in a EXYNOS4XXX */ #define CONFIG_TIZEN /* TIZEN lib */ +#define CONFIG_TRATS2 #include asm/arch/cpu.h /* get chip and board defs */ @@ -315,6 +316,31 @@ int get_soft_i2c_sda_pin(void); /* Common misc for Samsung */ #define CONFIG_MISC_INIT_R +/* Download menu - Samsung common */ +#define CONFIG_LCD_MENU +#define CONFIG_LCD_MENU_BOARD + +/* Download menu - definitions for check keys */ +#ifndef __ASSEMBLY__ +#ifdef __COMMON_H_ why this ifdef(__COMMON_H_) is needed? There was some include conflict with pmic which breaks build and this macro resolve it. +#include power/pmic.h +#include power/max77686_pmic.h + +#define KEY_PWR_PMIC_NAME MAX77686_PMIC +#define KEY_PWR_STATUS_REG MAX77686_REG_PMIC_STATUS1 +#define KEY_PWR_STATUS_MASK(1 0) +#define KEY_PWR_INTERRUPT_REG MAX77686_REG_PMIC_INT1 +#define KEY_PWR_INTERRUPT_MASK (1 1) + +#define KEY_VOL_UP_GPIOexynos4x12_gpio_get(2, x2, 2) +#define KEY_VOL_DOWN_GPIO exynos4x12_gpio_get(2, x3, 3) +#endif /* __COMMON_H_ */ +#endif /* __ASSEMBLY__ */ + +/* LCD console */ +#define LCD_BPP LCD_COLOR16 +#define CONFIG_SYS_WHITE_ON_BLACK + /* LCD */ #define CONFIG_EXYNOS_FB #define CONFIG_LCD Thanks, Minkyu Kang. Regards -- Przemyslaw Marczak Samsung RD Institute Poland Samsung Electronics p.marc...@samsung.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 01/12] s5p: gpio: change gpio coding method for s5p gpio.
Hello, On 01/06/2014 12:37 PM, Minkyu Kang wrote: On 04/01/14 01:43, Przemyslaw Marczak wrote: Old s5p gpio coding method was not clean and was not working properly for all parts and banks. New method is clean and easy to extend. Gpio coding mask: 0x00ff - pin number 0x0000 - bank offset 0xff00 - part number Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com --- Changes v2: - none Changes v3: - fix merge conflict in arch/arm/include/asm/arch-exynos/gpio.h - add exynos5420 gpio coding - update file: board/samsung/trats2/trats2.c arch/arm/include/asm/arch-exynos/gpio.h | 245 +- arch/arm/include/asm/arch-s5pc1xx/gpio.h | 47 -- board/samsung/trats2/trats2.c|8 +- drivers/gpio/s5p_gpio.c | 15 +- include/configs/s5p_goni.h |4 +- include/configs/s5pc210_universal.h | 12 +- include/configs/trats.h |4 +- 7 files changed, 132 insertions(+), 203 deletions(-) diff --git a/arch/arm/include/asm/arch-exynos/gpio.h b/arch/arm/include/asm/arch-exynos/gpio.h index 2a19852..64bd23b 100644 --- a/arch/arm/include/asm/arch-exynos/gpio.h +++ b/arch/arm/include/asm/arch-exynos/gpio.h @@ -247,180 +247,81 @@ void s5p_gpio_set_rate(struct s5p_gpio_bank *bank, int gpio, int mode); /* GPIO pins per bank */ #define GPIO_PER_BANK 8 - -#define exynos4_gpio_part1_get_nr(bank, pin) \ - ((unsigned int) (((struct exynos4_gpio_part1 *) \ - EXYNOS4_GPIO_PART1_BASE)-bank)) \ - - EXYNOS4_GPIO_PART1_BASE) / sizeof(struct s5p_gpio_bank)) \ - * GPIO_PER_BANK) + pin) - -#define EXYNOS4_GPIO_PART1_MAX ((sizeof(struct exynos4_gpio_part1) \ - / sizeof(struct s5p_gpio_bank)) * GPIO_PER_BANK) - -#define exynos4_gpio_part2_get_nr(bank, pin) \ - (((unsigned int) (((struct exynos4_gpio_part2 *) \ - EXYNOS4_GPIO_PART2_BASE)-bank)) \ - - EXYNOS4_GPIO_PART2_BASE) / sizeof(struct s5p_gpio_bank)) \ - * GPIO_PER_BANK) + pin) + EXYNOS4_GPIO_PART1_MAX) - -#define exynos4x12_gpio_part1_get_nr(bank, pin) \ - ((unsigned int) (((struct exynos4x12_gpio_part1 *) \ - EXYNOS4X12_GPIO_PART1_BASE)-bank)) \ - - EXYNOS4X12_GPIO_PART1_BASE) / sizeof(struct s5p_gpio_bank)) \ - * GPIO_PER_BANK) + pin) - -#define EXYNOS4X12_GPIO_PART1_MAX ((sizeof(struct exynos4x12_gpio_part1) \ - / sizeof(struct s5p_gpio_bank)) * GPIO_PER_BANK) - -#define exynos4x12_gpio_part2_get_nr(bank, pin) \ - (((unsigned int) (((struct exynos4x12_gpio_part2 *) \ - EXYNOS4X12_GPIO_PART2_BASE)-bank)) \ - - EXYNOS4X12_GPIO_PART2_BASE) / sizeof(struct s5p_gpio_bank)) \ - * GPIO_PER_BANK) + pin) + EXYNOS4X12_GPIO_PART1_MAX) - -#define EXYNOS4X12_GPIO_PART2_MAX ((sizeof(struct exynos4x12_gpio_part2) \ - / sizeof(struct s5p_gpio_bank)) * GPIO_PER_BANK) - -#define exynos4x12_gpio_part3_get_nr(bank, pin) \ - (((unsigned int) (((struct exynos4x12_gpio_part3 *) \ - EXYNOS4X12_GPIO_PART3_BASE)-bank)) \ - - EXYNOS4X12_GPIO_PART3_BASE) / sizeof(struct s5p_gpio_bank)) \ - * GPIO_PER_BANK) + pin) + EXYNOS4X12_GPIO_PART2_MAX) - -#define exynos5_gpio_part1_get_nr(bank, pin) \ - ((unsigned int) (((struct exynos5_gpio_part1 *) \ - EXYNOS5_GPIO_PART1_BASE)-bank)) \ - - EXYNOS5_GPIO_PART1_BASE) / sizeof(struct s5p_gpio_bank)) \ - * GPIO_PER_BANK) + pin) - -#define EXYNOS5_GPIO_PART1_MAX ((sizeof(struct exynos5_gpio_part1) \ - / sizeof(struct s5p_gpio_bank)) * GPIO_PER_BANK) - -#define exynos5_gpio_part2_get_nr(bank, pin) \ - (((unsigned int) (((struct exynos5_gpio_part2 *) \ - EXYNOS5_GPIO_PART2_BASE)-bank)) \ - - EXYNOS5_GPIO_PART2_BASE) / sizeof(struct s5p_gpio_bank)) \ - * GPIO_PER_BANK) + pin) + EXYNOS5_GPIO_PART1_MAX) - -#define EXYNOS5_GPIO_PART2_MAX ((sizeof(struct exynos5_gpio_part2) \ - / sizeof(struct s5p_gpio_bank)) * GPIO_PER_BANK) - -#define exynos5_gpio_part3_get_nr(bank, pin) \ - (((unsigned int) (((struct exynos5_gpio_part3 *) \ - EXYNOS5_GPIO_PART3_BASE)-bank)) \ - - EXYNOS5_GPIO_PART3_BASE) / sizeof(struct s5p_gpio_bank)) \ - * GPIO_PER_BANK) + pin) + EXYNOS5_GPIO_PART2_MAX) - - -/* EXYNOS5420 */ -#define exynos5420_gpio_part1_get_nr(bank, pin) \ - ((unsigned int) (((struct exynos5420_gpio_part1 *)\ - EXYNOS5420_GPIO_PART1_BASE)-bank)) \ - - EXYNOS5420_GPIO_PART1_BASE) / sizeof(struct s5p_gpio_bank)) \ - * GPIO_PER_BANK) + pin) - -#define EXYNOS5420_GPIO_PART1_MAX ((sizeof(struct exynos5420_gpio_part1) \ -
Re: [U-Boot] [PATCH] i.MX6: Ensure AHB clock is 132MHz in low freq boot mode
Hi Anson,
On 06/01/2014 22:31, Anson Huang wrote:
For low freq boot mode(ARM boot up with 396MHz), ROM
will not set AHB clock to 132MHz, and the reset value of
AHB divider is incorrect which will lead to wrong AHB
rate, need to correct it. To enable low freq boot mode,
need to set BOOT_CFG2[2] to high, tested on i.MX6Q/DL
SabreSD board and i.MX6SL EVK board.
Signed-off-by: Anson Huang b20...@freescale.com
---
arch/arm/cpu/armv7/mx6/soc.c | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
index a390296..edf3139 100644
--- a/arch/arm/cpu/armv7/mx6/soc.c
+++ b/arch/arm/cpu/armv7/mx6/soc.c
@@ -131,10 +131,30 @@ static void imx_set_wdog_powerdown(bool enable)
writew(enable, wdog2-wmcr);
}
+static void set_ahb_rate(u32 val)
+{
+ struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
+ u32 reg, div;
+
+ div = get_periph_clk() / val - 1;
+ reg = readl(mxc_ccm-cbcdr);
+
+ writel((reg (~MXC_CCM_CBCDR_AHB_PODF_MASK)) |
+ (div MXC_CCM_CBCDR_AHB_PODF_OFFSET), mxc_ccm-cbcdr);
+}
+
int arch_cpu_init(void)
{
init_aips();
+ /*
+ * When low freq boot is enabled, ROM will not set AHB
+ * freq, so we need to ensure AHB freq is 132MHz in such
+ * scenario.
+ */
+ if (mxc_get_clock(MXC_ARM_CLK) == 39600)
+ set_ahb_rate(13200);
+
Are we sure that mxc_get_clock() returns *exactly* 39600 ?
As far as I see, this depends firstly from MXC_HCLK, that can be
configurable with CONFIG_SYS_MX6_HCLK and could have a different value
from the default 2400. I do not know if there is cases where
CONFIG_SYS_MX6_HCLK is useful, no boards at the moment are setting it.
But the test requires that the computed frequency is exactly 396Mhz. Is
this reliable or should we simply test if frequency is lower of a
defined threshold ?
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] Question: booting Linux from ext4 mmc partition
On Mon, Jan 6, 2014 at 8:56 AM, nidalpres nidalp...@gmail.com wrote: Hi all! I was following instructions from http://eewiki.net/display/linuxonarm/iMX233-OLinuXino in order to get mainline kernel to boot off of my olinuxino micro board. I have created two partitions on my SD card: Device Boot Start End Blocks Id System /dev/sde12048 67583 32768 53 OnTrack DM6 Aux3 /dev/sde2 67584 7829503 3880960 83 Linux and installed everything as per instructions. However on boot this is what I get on console: HTLLCLC U-Boot 2013.10-dirty (Jan 05 2014 - 19:38:28) CPU: Freescale i.MX23 rev1.4 at 454 MHz BOOT: SSP SD/MMC #0 DRAM: 64 MiB MMC: MXS MMC: 0 *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial Net: Net Initialization Skipped No ethernet found. Hit any key to stop autoboot: 0 mmc0 is current device SD/MMC found on device 0 221 bytes read in 149 ms (1000 Bytes/s) Importing environment from mmc (uEnv.txt)... Checking if uenvcmd is set ... Running default loadzimage ... MMC0: Data error with command 18 (status 0xf0302020)! ** ext4fs_devread read error - block = I couldn't find anywhere what ext4fs_devread read error - block means. Found message origin in ext4fs_devread() function in u-boot source after some time but I really can't get my head around on what it means just by reading code. I suspect it doesn't like block sizes or something, not sure. So I changed second partition to ext2 (instead of ext4) an changed env parameters to instruct uboot that it is ext2 partition, nothing changed. Then I changed source header file include/configs/mx23_olinuxino.h and removed #define CONFIG_CMD_EXT4 from it hoping it will remove ext4 support. I also changed hardcoded env parameters in same file from mmcrootfstype=ext4 to mmcrootfstype=ext2. Recompiled u-boot, dd it to sd card, rinse and repeat, got exactly the same response on console you see above. I give up for today after 3 hours of battling with it. I plan to make 3 partitions: amtrak, vfat (for kernel) and ext4 (for rootfs). But if ext4fs_devread persists to complain (and I apparently haven't removed it from code) I don't think it would work either. What is going on? Can anyone give me some pointers what to do next? Just for sanity sake, have you tried try a different (brand) microSD card? Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm: keep all sections in ELF file breaks Arndale
On 12/21/2013 11:46 AM, Albert ARIBAUD wrote: Hi Andre, On Wed, 18 Dec 2013 15:06:04 +0100, Andre Przywara andre.przyw...@linaro.org wrote: the Arndale board does not work anymore with current master HEAD. If I turn on the board, I see exactly nothing. I bisected it down to: 47ed5dd031d7d2c587e6afd386e79ccec1a1b7f7 is the first bad commit commit 47ed5dd031d7d2c587e6afd386e79ccec1a1b7f7 Author: Albert ARIBAUD albert.u.b...@aribaud.net Date: Thu Nov 7 14:21:46 2013 +0100 arm: keep all sections in ELF file Albert, Sorry for chiming in late. Did you try this? http://patchwork.ozlabs.org/patch/300928/ OK, got around to test this now, it indeed fixes the issue for me. In this original thread of yours you mentioned a v2, has this been sent out yet? Please make sure to push this patch into the release, otherwise we will have a regression with Arndale (and others). Thanks, Andre. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] usb: ums: wait for usb cable connection before enter ums mode
Before this change ums mode can not be entered when device
was using the same usb port for usb/uart communication.
Switching USB cable from UART to USB always causes ums exit.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
---
common/cmd_usb_mass_storage.c | 24
include/usb_mass_storage.h|3 +++
2 files changed, 27 insertions(+)
diff --git a/common/cmd_usb_mass_storage.c b/common/cmd_usb_mass_storage.c
index 99487f4..5f557d5 100644
--- a/common/cmd_usb_mass_storage.c
+++ b/common/cmd_usb_mass_storage.c
@@ -42,6 +42,30 @@ int do_usb_mass_storage(cmd_tbl_t *cmdtp, int flag,
g_dnl_register(ums);
+ /* Timeout unit: seconds */
+ int cable_ready_timeout = UMS_CABLE_READY_TIMEOUT;
+
+ if (!usb_cable_connected()) {
+ puts(Please connect USB cable.\n);
+
+ while (!usb_cable_connected()) {
+ if (ctrlc()) {
+ puts(\rCTRL+C - Operation aborted.\n);
+ goto exit;
+ }
+ if (!cable_ready_timeout) {
+ puts(\rUSB cable not detected.\n \
+Command exit.\n);
+ goto exit;
+ }
+
+ printf(\rAuto exit in: %.2d s., cable_ready_timeout);
+ mdelay(1000);
+ cable_ready_timeout--;
+ }
+ puts(\r\n);
+ }
+
while (1) {
usb_gadget_handle_interrupts();
diff --git a/include/usb_mass_storage.h b/include/usb_mass_storage.h
index 9df3adc..058dcf1 100644
--- a/include/usb_mass_storage.h
+++ b/include/usb_mass_storage.h
@@ -20,6 +20,9 @@
#define UMS_NUM_SECTORS0
#endif
+/* Wait at maximum 60 seconds for cable connection */
+#define UMS_CABLE_READY_TIMEOUT60
+
struct ums {
int (*read_sector)(struct ums *ums_dev,
ulong start, lbaint_t blkcnt, void *buf);
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] ARM: dra7_evm: read mac address properly from e-fuse
Byte offset of Ethernet mac address read from e-fuse are wrong so DHCP is
not working on some boards, modifying the offset to read properly.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
board/ti/dra7xx/evm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index 9ae88c5..1b60b8f 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -202,12 +202,12 @@ int board_eth_init(bd_t *bis)
/* try reading mac address from efuse */
mac_lo = readl((*ctrl)-control_core_mac_id_0_lo);
mac_hi = readl((*ctrl)-control_core_mac_id_0_hi);
- mac_addr[0] = mac_hi 0xFF;
+ mac_addr[0] = (mac_hi 0xFF) 16;
mac_addr[1] = (mac_hi 0xFF00) 8;
- mac_addr[2] = (mac_hi 0xFF) 16;
- mac_addr[3] = mac_lo 0xFF;
+ mac_addr[2] = mac_hi 0xFF;
+ mac_addr[3] = (mac_lo 0xFF) 16;
mac_addr[4] = (mac_lo 0xFF00) 8;
- mac_addr[5] = (mac_lo 0xFF) 16;
+ mac_addr[5] = mac_lo 0xFF;
if (!getenv(ethaddr)) {
printf(ethaddr not set. Validating first E-fuse MAC\n);
--
1.8.5.2.192.g7794a68
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] boards.cfg: Delete the equivalent entries
Dear Masahiro Yamada, In message 1389085642-28400-4-git-send-email-yamad...@jp.panasonic.com you wrote: There are some entries which produce the same binaries as other entries: - Lite5200 is equivalent to icecube_5200 - Lite5200_LOWBOOT is equivalent to icecube_5200_LOWBOOT - Lite5200_LOWBOOT08 is equivalent to icecube_5200_LOWBOOT08 - ep8248Eis equivalent to ep8248 - MPC8360ERDK_66 is equivalent to MPC8360ERDK - Adder87x/AdderUSB is equivalent to Adder - EVB64260_750CS is equivalent to EVB64260 I cannot comment for the other boards, but please do not delete the Lite5200* entries. This name is what is actually referenced in misc documentation, so we should keep it - very few users will actually remove the IceCube board today, and even fewer will know that they have to chose this name if they want to configure for a Lite5200 board. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Was heißt Windows auf Indianisch? - Weißer Mann, der auf Sanduhr wartet! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-mpc85xx master
On Fri, Jan 03, 2014 at 03:57:48PM -0800, York Sun wrote: Tom, The following changes since commit fef24f4f38eb685a6da29097930e6e49b378f8fb: ARM: Samsung: Change GONI and Universal_C210 maintainers. (2013-12-20 10:48:06 -0500) are available in the git repository at: git://git.denx.de/u-boot-mpc85xx.git master for you to fetch changes up to 8c618dd66adfab736b88a86f51c057b019988a90: board/t1040qds: Enable memory reset control (2014-01-02 14:10:14 -0800) Prabhakar Kushwaha (4): board/t1040qds: Fix typo in t1040_pbi.cfg file board/freescale:Remove use of CONFIG_SPL_NAND_MINIMAL board/t1040qds: Relax IFC FPGA timings board/t1040qds: Enable memory reset control Priyanka Jain (1): powerpc/mpc85xx: Add support for single source clocking Scott Wood (1): powerpc/cms700: limit NAND data structure size Shaohui Xie (2): powerpc/t4240: enable NAND boot support powerpc/b4860/pbl: fix rcw cfg Shengzhou Liu (1): powerpc/t208x: fix macro CONFIG_SYS_FSL_NUM_USB_CTRLS York Sun (2): powerpc/P1022DS: Define new nand_ecclayout structure macros powerpc/B4860QDS: Define new nand_ecclayout structure macros README|8 arch/powerpc/cpu/mpc85xx/speed.c | 25 +++-- arch/powerpc/include/asm/config_mpc85xx.h |3 ++- arch/powerpc/include/asm/immap_85xx.h |3 +++ board/freescale/b4860qds/b4_rcw.cfg |2 +- board/freescale/bsc9131rdb/tlb.c |2 +- board/freescale/bsc9132qds/tlb.c |2 +- board/freescale/p1010rdb/tlb.c|2 +- board/freescale/t1040qds/t1040_pbi.cfg|2 +- board/freescale/t1040qds/t1040qds.c |5 + boards.cfg|1 + include/configs/B4860QDS.h|2 ++ include/configs/BSC9131RDB.h |2 +- include/configs/BSC9132QDS.h |2 +- include/configs/CMS700.h |3 +++ include/configs/P1010RDB.h|2 +- include/configs/P1022DS.h |2 ++ include/configs/T1040QDS.h|3 ++- 18 files changed, 59 insertions(+), 12 deletions(-) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-onenand/master
On Tue, Dec 31, 2013 at 01:15:06PM +0100, Lukasz Majewski wrote: Hi Tom, Please find a tiny fix for onenand tree. I hope, that this fix will find its way to v2014.01. The following changes since commit fef24f4f38eb685a6da29097930e6e49b378f8fb: ARM: Samsung: Change GONI and Universal_C210 maintainers. (2013-12-20 10:48:06 -0500) are available in the git repository at: git://git.denx.de/u-boot-onenand.git master for you to fetch changes up to 9b56942f7d2f67e620662cfeb4269a9a938d55da: mtd: onenand: Fix unaligned access (2013-12-31 09:59:16 +0100) Marek Vasut (1): mtd: onenand: Fix unaligned access drivers/mtd/onenand/onenand_base.c |8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] UBIFS seeing corrupt blank pages when image flashed via u-boot
Hi Artem, I wanted to check the 'white-space-fixup' and re-reading your documentation before, so got delayed in replying. + my mail got moderated again by mailman.. From: Artem Bityutskiy [mailto:artem.bityuts...@linux.intel.com] [...] If you are worried about fragmentation, we can discuss this separately. You can find more about UBIFS journal in my very old UBIFS presentation, which explains basic ideas behind the UBIFS wandering journal: http://www.linux-mtd.infradead.org/doc/ubifs.html#L_documentation There is also Adrian's white paper with some design description there. Thanks much for reminding me about this. I had read your slides long back, but never dig deep into Adrian's slides. so, this was still in my 'To Read' list. But really appreciate your work and presentation. [...] I do not understand the question. There are no problems in your (b), neither in *_Case-2_ described. If you meant *_Case-1_, then yes, there is a piece of doc: http://www.linux-mtd.infradead.org/doc/ubi.html#L_flasher_algo Basically, ubiformat is the correct UBI-aware flasher, while u-boot's nand write seems to be a dumb flasher. I guess you have 2 options: 1. Teach u-boot's nand write to skip empty pages, or may be implement a separate clever flashing command. Yes, I'll try 'Stefano Babic' suggestion of using u-boot UBI tools. 2. Use UBIFS's space fixup feature. This will cause UBIFS to fix-up all empty pages by basically copying all partially-used PEBs to different PEBes with empty pages skipping. This will be done on the first mount, only once, and may cause considerable delays. See http://www.linux-mtd.infradead.org/faq/ubifs.html#L_free_space_fixup Though I had read about 'white-space-fixup' feature earlier too, But somewhere in back of my mind, I thought it was only for free PEBs (erased-blocks which had corrupted or no volume-header). But after re-reading the FAQ page, I realized that 'white-space-fixup' is done for all pages, whether in 'free-PEB' or 'used-PEB'. So, This solved my problem.. Thanks much.. P.S. Looking at the MTD web-site now, when I am not doing any UBI/UBIFS/MTD work anymore for few years, I am impressed how much stuff I actually documented there :-) Absolutely agree. Therefore your file-system is so popular.. Especially the MTD and UBI documentation is not only limited to 'how to use it', Instead I think, it has some advanced details, explanations and reasoning which were quite ahead of its time when it was written. This is something which you and other MTD/UBI/ UBIFS Authors and Maintainers should be proud of. Thanks again .. with regards, pekon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Question: booting Linux from ext4 mmc partition
Hi Robert! I have 4-5 microsd cards (Kingston, SanDisk, Samsung), 4 and 8GB in size, tried two, same thing. I also tried vfat partition and disabled support for ext2 AND ext4 completely in u-boot, and basically same thing happened. Then I tried to list/load files manually from vfat/ext4 partitions using u-boot command prompt. I can list vfat and ext4 partitions and load files from them into memory. However, once I load uImage file everything regarding mmc access and loading files breaks. I seems to me that loading one big file somehow corrupts something (hahah, very precise explanation). uImage is little over 4MB. I will send detailed messages from u-boot command prompt session regarding this when I get back to my workstation, since it looks like it might be some sort of a bug, or maybe just u-boot misconfiguration that didn't take into account loading large files? Thanks! Nidal. On Tue, Jan 7, 2014 at 7:58 AM, Robert Nelson robertcnel...@gmail.com wrote: On Mon, Jan 6, 2014 at 8:56 AM, nidalpres nidalp...@gmail.com wrote: Hi all! I was following instructions from http://eewiki.net/display/linuxonarm/iMX233-OLinuXino in order to get mainline kernel to boot off of my olinuxino micro board. I have created two partitions on my SD card: Device Boot Start End Blocks Id System /dev/sde12048 67583 32768 53 OnTrack DM6 Aux3 /dev/sde2 67584 7829503 3880960 83 Linux and installed everything as per instructions. However on boot this is what I get on console: HTLLCLC U-Boot 2013.10-dirty (Jan 05 2014 - 19:38:28) CPU: Freescale i.MX23 rev1.4 at 454 MHz BOOT: SSP SD/MMC #0 DRAM: 64 MiB MMC: MXS MMC: 0 *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial Net: Net Initialization Skipped No ethernet found. Hit any key to stop autoboot: 0 mmc0 is current device SD/MMC found on device 0 221 bytes read in 149 ms (1000 Bytes/s) Importing environment from mmc (uEnv.txt)... Checking if uenvcmd is set ... Running default loadzimage ... MMC0: Data error with command 18 (status 0xf0302020)! ** ext4fs_devread read error - block = I couldn't find anywhere what ext4fs_devread read error - block means. Found message origin in ext4fs_devread() function in u-boot source after some time but I really can't get my head around on what it means just by reading code. I suspect it doesn't like block sizes or something, not sure. So I changed second partition to ext2 (instead of ext4) an changed env parameters to instruct uboot that it is ext2 partition, nothing changed. Then I changed source header file include/configs/mx23_olinuxino.h and removed #define CONFIG_CMD_EXT4 from it hoping it will remove ext4 support. I also changed hardcoded env parameters in same file from mmcrootfstype=ext4 to mmcrootfstype=ext2. Recompiled u-boot, dd it to sd card, rinse and repeat, got exactly the same response on console you see above. I give up for today after 3 hours of battling with it. I plan to make 3 partitions: amtrak, vfat (for kernel) and ext4 (for rootfs). But if ext4fs_devread persists to complain (and I apparently haven't removed it from code) I don't think it would work either. What is going on? Can anyone give me some pointers what to do next? Just for sanity sake, have you tried try a different (brand) microSD card? Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Question: booting Linux from ext4 mmc partition
In this e-mail you can find a session with latest (from a day ago or
so) u-boot from git on mx23-olinuxino.
On boot I can access partition 3 on mmc card (ext4) and load files
(/boot/uEnv.txt) off of it into memory.
However, once I try to load zImage (4MB in size) error appears and
after that you can't do anything with mmc.
To get back on feet you have to do mmc rescan, access is restored,
but still loading zImage messes things up.
It may be a bug or just a build misconfiguration, I really don't know,
but I am hoping this might help you if it is a bug.
Regards,
Nidal.
Here is the full session (longest lines are cut, minicom terminal was
just that much wide :)
-- session start
--
HTLCLC
U-Boot 2014.01-rc2-00028-gfef24f4-dirty (Jan 06 2014 - 10:31:34)
CPU: Freescale i.MX23 rev1.4 at 454 MHz
BOOT: SSP SD/MMC #0
DRAM: 64 MiB
MMC: MXS MMC: 0
*** Warning - bad CRC, using default environment
In:serial
Out: serial
Err: serial
Net: Net Initialization Skipped
No ethernet found.
Hit any key to stop autoboot: 0
= version
U-Boot 2014.01-rc2-00028-gfef24f4-dirty (Jan 06 2014 - 10:31:34)
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.7.4
20130913 (release) [ARM/embedded-4_7-branch revi]
GNU ld (GNU Tools for ARM Embedded Processors) 2.22.0.20130913
= env print
baudrate=115200
boot_fdt=try
bootcmd=mmc dev ${mmcdev};if mmc rescan; then echo SD/MMC found on
device ${mmcdev};if run loadbootenv; then run;
bootdelay=1
bootfile=uImage
bootscript=echo Running bootscript from mmc ...; source
console=ttyAMA0
fdt_addr=0x4100
fdt_file=/dtbs/imx23-olinuxino.dtb
importbootenv=echo Importing environment from mmc (uenv.txt)...; env
import -t ${loadaddr} ${filesize}
ip_dyn=yes
loadaddr=0x4200
loadbootenv=load mmc ${mmcdev}:${mmcpart} ${loadaddr} /uenv.txt
loadbootscript=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};
loadfdt=load mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}
loaduimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}
loadzimage=load mmc ${mmcdev}:${mmcpart} ${loadaddr} /zimage
mmcargs=setenv bootargs console=${console},${baudrate} ${optargs}
root=${mmcroot} rootfstype=${mmcrootfstype} vi}
mmcboot=echo Booting from mmc ...; run mmcargs; bootz ${loadaddr} - ${fdt_addr}
mmcdefault=echo Booting from mmc ...; run mmcargs; if test ${boot_fdt}
= yes || test ${boot_fdt} = try; then if ;
mmcdev=0
mmcpart=2
mmcroot=/dev/mmcblk0p2 ro
mmcrootfstype=vfat rootwait fixrtc
netargs=setenv bootargs console=${console},${baudrate} root=/dev/nfs
ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tp
netboot=echo Booting from net ...; usb start; run netargs; if test
${ip_dyn} = yes; then setenv get_cmd dhcp; el;
script=boot.scr
stderr=serial
stdin=serial
stdout=serial
uimage=uImage
update_sd_firmware=if mmc rescan ; then if tftp
${update_sd_firmware_filename} ; then setexpr fw_sz ${filesize} i
update_sd_firmware_filename=u-boot.sd
ver=U-Boot 2014.01-rc2-00028-gfef24f4-dirty (Jan 06 2014 - 10:31:34)
Environment size: 2451/16380 bytes
= ls mmc 0:3 /boot
DIR 4096 .
DIR 4096 ..
221 uEnv.txt
4039976 zImage
DIR 4096 dtbs
DIR 4096 uboot
= load mmc 0:3 ${loadaddr} /boot/uEnv.txt
221 bytes read in 141 ms (1000 Bytes/s)
= md ${loadaddr}
4200: 65685423 61206573 74206572 64206568#These are the d
4210: 75616665 7320746c 69747465 2073676eefault settings
4220: 20726f66 656d6f73 65737520 206c7566for some useful
4230: 6f622d75 7620746f 61697261 73656c62u-boot variables
4240: 66230a3a 665f7464 3d656c69 6f6f622f:.#fdt_file=/boo
4250: 74642f74 692f7362 3332786d 696c6f2dt/dtbs/imx23-oli
4260: 6978756e 642e6f6e 200a6274 706f230anuxino.dtb. .#op
4270: 67726174 6f0a3d73 72617470 713d7367targs=.optargs=q
4280: 74656975 696e6920 6c2f3d74 732f6269uiet init=/lib/s
4290: 65747379 732f646d 65747379 6d0a646dystemd/systemd.m
42a0: 6f72636d 2f3d746f 2f766564 62636d6dmcroot=/dev/mmcb
42b0: 70306b6c 6f722033 636d6d0a 746f6f72lk0p3 ro.mmcroot
42c0: 79747366 653d6570 20347478 746f6f72fstype=ext4 root
42d0: 74696177 78696620 0a637472 e15a000await fixrtc...Z.
42e0: 9a13 e28aaa02 e3caa0ff e24f5064dPO.
42f0: e3c5501f e0469001 e289901f e3c9901f.PF.
= ls mmc 0:3 /boot
DIR 4096 .
DIR 4096 ..
221 uEnv.txt
4039976 zImage
DIR 4096 dtbs
DIR 4096 uboot
= load mmc 0:3 ${loadaddr} /boot/zImage
MMC0: Data error with command 18 (status 0xf0302020)!
** ext4fs_devread read error - block
= ls mmc 0:3 /boot
MMC0: Command 16 timeout (status 0xf0204020)
** Can't read partition table on 0:0 **
** Invalid partition 3 **
= md ${loadaddr}
4200: e1a0 e1a0 e1a0 e1a0
4210: e1a0 e1a0 e1a0 e1a0
4220: ea02 016f2818
Re: [U-Boot] Question: booting Linux from ext4 mmc partition
On Tue, Jan 7, 2014 at 1:26 PM, nidalpres nidalp...@gmail.com wrote: Hi Robert! I have 4-5 microsd cards (Kingston, SanDisk, Samsung), 4 and 8GB in size, tried two, same thing. I also tried vfat partition and disabled support for ext2 AND ext4 completely in u-boot, and basically same thing happened. Then I tried to list/load files manually from vfat/ext4 partitions using u-boot command prompt. I can list vfat and ext4 partitions and load files from them into memory. However, once I load uImage file everything regarding mmc access and loading files breaks. I seems to me that loading one big file somehow corrupts something (hahah, very precise explanation). uImage is little over 4MB. So if it's a failing at 4MB, at what size does it work as you maybe over writing memory.. Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] sandbox question
Hi Tiger, On 30 December 2013 17:42, tiger...@viatech.com.cn wrote: Hi, Simon: Sorry for some typo. I re-wrote this mail: I've been away, sorry for the delay. --- I have a question about compiling uboot sandbox branch: 1. It seems sandbox branch could be compiled by gcc compiler on a x86 platform. Not need to set cross compiler tool chains. And after finished compiling, it could be run on a x86 environment. So, my question is: The obj file for a same .C file by arm cross compiler tool chain is different with the obj file produced by a x86 gcc tool. (On my x86 platform, defaut gcc is a x86 version) So, for more precise test for non-platform code: User should compile sandbox branch with an arm cross compiler tool chain. And should run it on an arm linux environment? Well you could, but what benefit would that provide? It would not use any code from arch/arm if that is what you are thinking. Sandbox is its own 'architecture'? Regards, Simon Best wishes, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 1/2] powerpc:mpc85xx: Add ifc nand boot support for TPL/SPL
On Tue, 2014-01-07 at 11:37 +0800, Po Liu wrote: diff --git a/doc/README.SPL b/doc/README.SPL index 312a6a6..20d53fb 100644 --- a/doc/README.SPL +++ b/doc/README.SPL @@ -62,6 +62,7 @@ CONFIG_SPL_FAT_SUPPORT (fs/fat/libfat.o) CONFIG_SPL_LIBGENERIC_SUPPORT (lib/libgeneric.o) CONFIG_SPL_POWER_SUPPORT (drivers/power/libpower.o) CONFIG_SPL_NAND_SUPPORT (drivers/mtd/nand/libnand.o) +CONFIG_SPL_DRIVERS_MISC_SUPPORT (drivers/misc/fsl_ifc.o) This symbol is not specifically for fsl_ifc.o, it's for the entire drivers/misc directory (would have been drivers/misc/libmisc.o, but now they're all drivers/foo/built-in.o). -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Regression: SDP4430 - Fails to boot - bisect indicates i2c adaptation
Hi, I happened to try SDP4430 out a earlier today with tip of u-boot mainline and it refused to even bring up SPL logs. Last working tag happens to be v2013.10 Earliest fail tag happens to be v2014.01-rc1 A bisect showed the following: http://pastebin.mozilla.org/3962513 i2c, omap24xx: convert driver to new mutlibus/mutliadapter framework At commit 6789e84ecaa8f45d053084e08c381284a04abff7 it does indeed fail to boot up, git reset --hard HEAD^ allows the board to boot up successfully. -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] sandbox question
Hi, Simon: Thanks for your reply! Well you could, but what benefit would that provide? It would not use any code from arch/arm if that is what you are thinking. Sandbox is its own 'architecture'? For example: 1. i want to test fs/ext4 driver. They are architecture independent code. I means: (1) the obj files produced by arm gcc compiler are different with obj files produced by x86 gcc compiler. Maybe arm gcc compiler would introduce some arm architecture related optimizations for fs/ext4 drivers. Maybe x86 gcc compiler would introduce some x86 architecture related optimizations for fs/ext4 drivers. So, if sandbox's fs/ext4 drivers' test passed on an x86 platform,but these architecture related optimizations would cause some potential bugs on ARM platform. Is it a problem? Best wishes, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: rmobile: Add SH QSPI base register address
This adds base register address of SH QSPI. Currently, SH QSPI is used only from R8A7790 and R8A7791. Signed-off-by: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com --- arch/arm/include/asm/arch-rmobile/r8a7790.h | 1 + arch/arm/include/asm/arch-rmobile/r8a7791.h | 1 + 2 files changed, 2 insertions(+) diff --git a/arch/arm/include/asm/arch-rmobile/r8a7790.h b/arch/arm/include/asm/arch-rmobile/r8a7790.h index 42d65d3..d9ea71f 100644 --- a/arch/arm/include/asm/arch-rmobile/r8a7790.h +++ b/arch/arm/include/asm/arch-rmobile/r8a7790.h @@ -19,6 +19,7 @@ #define DBSC3_1_BASE 0xE67A #define TMU_BASE 0xE61E #defineGPIO5_BASE 0xE6055000 +#define SH_QSPI_BASE 0xE6B1 #define S3C_BASE 0xE6784000 #define S3C_INT_BASE 0xE6784A00 diff --git a/arch/arm/include/asm/arch-rmobile/r8a7791.h b/arch/arm/include/asm/arch-rmobile/r8a7791.h index 2afda0a..ff30180 100644 --- a/arch/arm/include/asm/arch-rmobile/r8a7791.h +++ b/arch/arm/include/asm/arch-rmobile/r8a7791.h @@ -19,6 +19,7 @@ #define DBSC3_1_BASE 0xE67A #define TMU_BASE 0xE61E #defineGPIO5_BASE 0xE6055000 +#define SH_QSPI_BASE 0xE6B1 #define S3C_BASE 0xE6784000 #define S3C_INT_BASE 0xE6784A00 -- 1.8.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] spi: sh_qspi: Add header file that defines the address of registers
Signed-off-by: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com --- drivers/spi/sh_qspi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/spi/sh_qspi.c b/drivers/spi/sh_qspi.c index edeb42d..77ede6b 100644 --- a/drivers/spi/sh_qspi.c +++ b/drivers/spi/sh_qspi.c @@ -10,6 +10,7 @@ #include common.h #include malloc.h #include spi.h +#include asm/arch/rmobile.h #include asm/io.h /* SH QSPI register bit masks REG_BIT */ @@ -170,7 +171,7 @@ struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs, return NULL; } - ss-regs = (struct sh_qspi_regs *)CONFIG_SH_QSPI_BASE; + ss-regs = (struct sh_qspi_regs *)SH_QSPI_BASE; /* Init SH QSPI */ sh_qspi_init(ss); -- 1.8.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/4] arm: koelsch: Add support QSPI device and enable boot from SPI flash
This supports SH-QSPI device on koelsch board, and enable booting from SPI flash. Signed-off-by: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com Signed-off-by: Nobuhiro Iwamatsu iwama...@nigauri.org --- v2: Remove address definition of SH QSPI Move CONFIG_SYS_TEXT_BASE from SPI section. include/configs/koelsch.h | 32 1 file changed, 28 insertions(+), 4 deletions(-) diff --git a/include/configs/koelsch.h b/include/configs/koelsch.h index f8cca5b..cc3c7a8 100644 --- a/include/configs/koelsch.h +++ b/include/configs/koelsch.h @@ -31,7 +31,16 @@ #define CONFIG_CMD_DHCP #define CONFIG_CMD_NFS #define CONFIG_CMD_BOOTZ + +#if defined(CONFIG_SYS_USE_BOOT_NORFLASH) #defineCONFIG_CMD_FLASH +#define CONFIG_SYS_TEXT_BASE 0x +#else +/* SPI flash boot is default. */ +#define CONFIG_CMD_SF +#define CONFIG_CMD_SPI +#define CONFIG_SYS_TEXT_BASE 0xE6304000 +#endif #defineCONFIG_CMDLINE_TAG #defineCONFIG_SETUP_MEMORY_TAGS @@ -101,7 +110,7 @@ #define CONFIG_SYS_BOOTMAPSZ (8 * 1024 * 1024) /* FLASH */ -#define CONFIG_SYS_TEXT_BASE 0x +#if defined(CONFIG_SYS_USE_BOOT_NORFLASH) #define CONFIG_SYS_FLASH_CFI #define CONFIG_SYS_FLASH_CFI_WIDTH FLASH_CFI_16BIT #defineCONFIG_FLASH_CFI_DRIVER @@ -117,13 +126,28 @@ #define CONFIG_SYS_FLASH_WRITE_TOUT3000 #define CONFIG_SYS_FLASH_LOCK_TOUT 3000 #define CONFIG_SYS_FLASH_UNLOCK_TOUT 3000 - /* ENV setting */ #define CONFIG_ENV_IS_IN_FLASH -#define CONFIG_ENV_OVERWRITE 1 -#define CONFIG_ENV_SECT_SIZE (256 * 1024) #define CONFIG_ENV_ADDR(CONFIG_SYS_FLASH_BASE + \ CONFIG_SYS_MONITOR_LEN) + +#else /* CONFIG_SYS_USE_BOOT_NORFLASH */ + +#define CONFIG_SYS_NO_FLASH +#define CONFIG_SPI +#define CONFIG_SH_QSPI +#define CONFIG_SPI_FLASH +#define CONFIG_SPI_FLASH_BAR +#define CONFIG_SPI_FLASH_SPANSION +/* ENV setting */ +#define CONFIG_ENV_IS_IN_SPI_FLASH +#define CONFIG_ENV_ADDR0xC + +#endif /* CONFIG_SYS_USE_BOOT_NORFLASH */ + +/* Common ENV setting */ +#define CONFIG_ENV_OVERWRITE +#define CONFIG_ENV_SECT_SIZE (256 * 1024) #define CONFIG_ENV_OFFSET (CONFIG_ENV_ADDR) #define CONFIG_ENV_SIZE(CONFIG_ENV_SECT_SIZE) #define CONFIG_ENV_SIZE_REDUND (CONFIG_SYS_MONITOR_LEN) -- 1.8.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/4] arm: lager: Add support QSPI device and enable boot from SPI flash
This supports SH-QSPI device on lager board, and enable booting from SPI flash. Signed-off-by: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com Signed-off-by: Nobuhiro Iwamatsu iwama...@nigauri.org --- v2: Remove address definition of SH QSPI Move CONFIG_SYS_TEXT_BASE from SPI section. include/configs/lager.h | 33 + 1 file changed, 29 insertions(+), 4 deletions(-) diff --git a/include/configs/lager.h b/include/configs/lager.h index 8932825..b6c1954 100644 --- a/include/configs/lager.h +++ b/include/configs/lager.h @@ -34,7 +34,15 @@ #define CONFIG_CMD_DHCP #define CONFIG_CMD_NFS #define CONFIG_CMD_BOOTZ -#defineCONFIG_CMD_FLASH + +#if defined(CONFIG_SYS_USE_BOOT_NORFLASH) +#define CONFIG_CMD_FLASH +#define CONFIG_SYS_TEXT_BASE 0x +#else +#define CONFIG_CMD_SF +#define CONFIG_CMD_SPI +#define CONFIG_SYS_TEXT_BASE 0xE808 +#endif #defineCONFIG_CMDLINE_TAG #defineCONFIG_SETUP_MEMORY_TAGS @@ -104,8 +112,8 @@ #define CONFIG_SYS_GBL_DATA_SIZE (256) #define CONFIG_SYS_BOOTMAPSZ (8 * 1024 * 1024) +#if defined(CONFIG_SYS_USE_BOOT_NORFLASH) /* USE NOR FLASH */ -#define CONFIG_SYS_TEXT_BASE 0x #define CONFIG_SYS_FLASH_CFI #define CONFIG_SYS_FLASH_CFI_WIDTH FLASH_CFI_16BIT #defineCONFIG_FLASH_CFI_DRIVER @@ -124,10 +132,27 @@ /* ENV setting */ #define CONFIG_ENV_IS_IN_FLASH -#define CONFIG_ENV_OVERWRITE 1 -#define CONFIG_ENV_SECT_SIZE (256 * 1024) #define CONFIG_ENV_ADDR(CONFIG_SYS_FLASH_BASE + \ CONFIG_SYS_MONITOR_LEN) + +#else /* CONFIG_SYS_USE_BOOT_NORFLASH */ + +/* USE SPI */ +#define CONFIG_SPI +#define CONFIG_SPI_FLASH_BAR +#define CONFIG_SH_QSPI +#define CONFIG_SPI_FLASH +#define CONFIG_SPI_FLASH_SPANSION +#define CONFIG_SYS_NO_FLASH + +/* ENV setting */ +#define CONFIG_ENV_IS_IN_SPI_FLASH +#define CONFIG_ENV_ADDR0xC +#endif + +/* Common ENV setting */ +#define CONFIG_ENV_OVERWRITE +#define CONFIG_ENV_SECT_SIZE (256 * 1024) #define CONFIG_ENV_OFFSET (CONFIG_ENV_ADDR) #define CONFIG_ENV_SIZE(CONFIG_ENV_SECT_SIZE) #define CONFIG_ENV_SIZE_REDUND (CONFIG_SYS_MONITOR_LEN) -- 1.8.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/4] arm: lager: Disable TMU0 before OS boots
On U-boot uses TMU0 as timer, but TMU0 does not use on linux kernel
and other.
This disables TMU0 at the request of from kernel user.
Signed-off-by: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com
Signed-off-by: Nobuhiro Iwamatsu iwama...@nigauri.org
---
v2: no changes.
board/renesas/lager/lager.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/board/renesas/lager/lager.c b/board/renesas/lager/lager.c
index cdd5b32..ad5289a 100644
--- a/board/renesas/lager/lager.c
+++ b/board/renesas/lager/lager.c
@@ -254,6 +254,12 @@ int board_early_init_f(void)
return 0;
}
+void arch_preboot_os(void)
+{
+ /* Disable TMU0 */
+ mstp_setbits_le32(MSTPSR1, SMSTPCR1, TMU0_MSTP125);
+}
+
DECLARE_GLOBAL_DATA_PTR;
int board_init(void)
{
--
1.8.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/4] arm: koelsch: Disable TMU0 before OS boots
On U-boot uses TMU0 as timer, but TMU0 does not use on linux kernel
and other.
This disables TMU0 at the request of from kernel user.
Signed-off-by: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com
Signed-off-by: Nobuhiro Iwamatsu iwama...@nigauri.org
---
v2: no changes.
board/renesas/koelsch/koelsch.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/board/renesas/koelsch/koelsch.c b/board/renesas/koelsch/koelsch.c
index 89f5c91..32d3b58 100644
--- a/board/renesas/koelsch/koelsch.c
+++ b/board/renesas/koelsch/koelsch.c
@@ -253,6 +253,12 @@ int board_early_init_f(void)
return 0;
}
+void arch_preboot_os(void)
+{
+ /* Disable TMU0 */
+ mstp_setbits_le32(MSTPSR1, SMSTPCR1, TMU0_MSTP125);
+}
+
/* LSI pin pull-up control */
#define PUPR5 0xe6060114
#define PUPR5_ETH 0x3FFC
--
1.8.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/3] boards.cfg: Delete the equivalent entries
There are some entries which produce the same binaries: - ep8248E is equivalent to ep8248 - MPC8360ERDK_66is equivalent to MPC8360ERDK - Adder87x/AdderUSB is equivalent to Adder - EVB64260_750CSis equivalent to EVB64260 I also notice - Lite5200 is equivalent to icecube_5200 - Lite5200_LOWBOOT is equivalent to icecube_5200_LOWBOOT - Lite5200_LOWBOOT08 is equivalent to icecube_5200_LOWBOOT08 But I am keeping them. (Wolfgang suggested to do so because Lite5200* are referenced in misc documents.) Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- Changes in v2: - Do not delete Lite5200* boards.cfg | 5 - 1 file changed, 5 deletions(-) diff --git a/boards.cfg b/boards.cfg index 37ae4b3..876e5f9 100644 --- a/boards.cfg +++ b/boards.cfg @@ -655,7 +655,6 @@ Active powerpc mpc8260- - cpu86 Active powerpc mpc8260- - cpu87 CPU87- - Active powerpc mpc8260- - cpu87 CPU87_ROMBOOTCPU87:BOOT_ROM - Active powerpc mpc8260- - ep8248 ep8248 - Yuli Barcohen y...@arabellasw.com -Active powerpc mpc8260- - ep8248 ep8248E ep8248 Yuli Barcohen y...@arabellasw.com Active powerpc mpc8260- - ids8247 IDS8247 - Heiko Schocher h...@denx.de Active powerpc mpc8260- - iphase4539 IPHASE4539 - Wolfgang Grandegger w...@denx.de Active powerpc mpc8260- - ispan ISPAN- Yuli Barcohen y...@arabellasw.com @@ -745,7 +744,6 @@ Active powerpc mpc83xx- freescale mpc8360emds Active powerpc mpc83xx- freescale mpc8360emds MPC8360EMDS_66_SLAVE MPC8360EMDS:CLKIN_66MHZ,PCI,PCISLAVE Dave Liu dave...@freescale.com Active powerpc mpc83xx- freescale mpc8360erdk MPC8360ERDK - Anton Vorontsov avoront...@ru.mvista.com Active powerpc mpc83xx- freescale mpc8360erdk MPC8360ERDK_33 MPC8360ERDK:CLKIN_33MHZ Anton Vorontsov avoront...@ru.mvista.com -Active powerpc mpc83xx- freescale mpc8360erdk MPC8360ERDK_66 MPC8360ERDK Anton Vorontsov avoront...@ru.mvista.com Active powerpc mpc83xx- freescale mpc837xemds MPC837XEMDS - Dave Liu dave...@freescale.com Active powerpc mpc83xx- freescale mpc837xemds MPC837XEMDS_HOST MPC837XEMDS:PCI Dave Liu dave...@freescale.com Active powerpc mpc83xx- freescale mpc837xerdb MPC837XERDB - Joe D'Abbraccio ljd...@freescale.com @@ -1001,9 +999,7 @@ Active powerpc
[U-Boot] [PATCH v2 0/3] Cleanup of boards.cfg
This series uses Fabio's patch as a prerequisite: boards.cfg: Keep the entries sorted http://patchwork.ozlabs.org/patch/305456/ Please apply it before this series. Changes in v2: - Do not delete Lite5200* Masahiro Yamada (3): cosmetic: boards.cfg: remove a trailing empty line boards.cfg: Place - in the 8th field if it is the same as 7th boards.cfg: Delete the equivalent entries boards.cfg | 88 +- 1 file changed, 41 insertions(+), 47 deletions(-) -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/3] cosmetic: boards.cfg: remove a trailing empty line
- Remove a trailing empty line - Add '#' to the empty line between two comment blocks Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- Changes in v2: None boards.cfg | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/boards.cfg b/boards.cfg index b815d05..5a0288d 100644 --- a/boards.cfg +++ b/boards.cfg @@ -31,7 +31,7 @@ # For any board without permanent maintainer, please contact # Wolfgang Denk w...@denx.de # And Cc: the u-boot@lists.denx.de mailing list. - +# # The list should be ordered according to the C locale. # # To keep the list formatted and sorted, script tools/reformat.py is available. @@ -1238,4 +1238,3 @@ Orphan powerpc mpc8xx - - genietv Orphan powerpc mpc8xx - - mbx8xx MBX - - Orphan powerpc mpc8xx - - mbx8xx MBX860T - - Orphan powerpc mpc8xx - - nx823 NX823- - - -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] boards.cfg: Delete the equivalent entries
Hello Wolfgang I cannot comment for the other boards, but please do not delete the Lite5200* entries. This name is what is actually referenced in misc documentation, so we should keep it - very few users will actually remove the IceCube board today, and even fewer will know that they have to chose this name if they want to configure for a Lite5200 board. Thanks for comments. I posted version2. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 11/12] trats2: add LCD download menu support
Dear Przemsyslaw Marczak, On 07/01/14 21:54, Przemyslaw Marczak wrote: Hello, On 01/06/2014 12:37 PM, Minkyu Kang wrote: On 04/01/14 02:21, Przemyslaw Marczak wrote: Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com --- changes v2: - add definitions for check keys - cleanup config definitions Changes v3: - remove CONFIG_BOARD_NAME from include/configs/trats2.h include/configs/trats2.h | 26 ++ 1 file changed, 26 insertions(+) diff --git a/include/configs/trats2.h b/include/configs/trats2.h index 740ceb1..453a37e 100644 --- a/include/configs/trats2.h +++ b/include/configs/trats2.h @@ -19,6 +19,7 @@ #define CONFIG_S5P/* which is in a S5P Family */ #define CONFIG_EXYNOS4/* which is in a EXYNOS4XXX */ #define CONFIG_TIZEN/* TIZEN lib */ +#define CONFIG_TRATS2 #include asm/arch/cpu.h/* get chip and board defs */ @@ -315,6 +316,31 @@ int get_soft_i2c_sda_pin(void); /* Common misc for Samsung */ #define CONFIG_MISC_INIT_R +/* Download menu - Samsung common */ +#define CONFIG_LCD_MENU +#define CONFIG_LCD_MENU_BOARD + +/* Download menu - definitions for check keys */ +#ifndef __ASSEMBLY__ +#ifdef __COMMON_H_ why this ifdef(__COMMON_H_) is needed? There was some include conflict with pmic which breaks build and this macro resolve it. What kind of conflict? I think it is not a solution. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] boards.cfg: Delete the equivalent entries
Hi There are some entries which produce the same binaries: - ep8248E is equivalent to ep8248 - MPC8360ERDK_66is equivalent to MPC8360ERDK - Adder87x/AdderUSB is equivalent to Adder - EVB64260_750CSis equivalent to EVB64260 Does anyone have any objection to remove these four? Unfortunately I cannot have contact with their maintainers. I CCed: Yuli Barcohen y...@arabellasw.com Maintainer of ep8248E/Adder87x/AdderUSB Anton Vorontsov avoront...@ru.mvista.com Maintainer of MPC8360ERDK_66 Eran Man e...@nbase.co.il Maintainer of EVB64260_750CS But all of these email have been bouncing. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] omap4_common: config: remove I2C for SPL mode
Commit 6789e84ecaa8f45d053084e08c381284a04abff7 (i2c, omap24xx: convert driver to new mutlibus/mutliadapter framework) intended to make I2C driver compatible with latest changes. It unfortunately has had a impact on size on SPL as well. For example on SDP4430, 32032 bytes before/MLO 35416 bytes after/MLO With this mentioned commit, MLO stops booting on SDP4430 as only 32K is accessible for non-secure (bootloader) s/w on GP devices and the size increase to 56K fails boot. On the latest u-boot commit e7be18225fbea76d1f0034b224f0d1e60f07cfcf, MLO is now at size 35592 bytes, However, I2C is not necessary for SPL to function as we use SR_I2C for controlling the PMIC. Disabling I2C reduces MLO to 32224 bytes which allows OMAP4 GP platform to boot up. Since this is common for all OMAP4 platforms, remove the need for I2C for SPL builds in the common config. Signed-off-by: Nishanth Menon n...@ti.com --- Though I originally reported this for SDP4430[1], a test on PandaBoard-ES also indicated fail to boot! Tested on PandaBoard-ES and SDP4430 Build result: http://pastebin.mozilla.org/3963101 Test log: SDP4430: http://pastebin.mozilla.org/3963123 PandaBoard-ES: http://pastebin.mozilla.org/3963134 [1] http://marc.info/?l=u-bootm=138914031918099w=2 include/configs/omap4_common.h |6 ++ 1 file changed, 6 insertions(+) diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h index ea56eeb..7cfd471 100644 --- a/include/configs/omap4_common.h +++ b/include/configs/omap4_common.h @@ -154,4 +154,10 @@ #define CONFIG_SPL_DISPLAY_PRINT #define CONFIG_SPL_LDSCRIPT $(CPUDIR)/omap-common/u-boot-spl.lds +#ifdef CONFIG_SPL_BUILD +/* No need for i2c in SPL mode as we will use SRI2C for PMIC access on OMAP4 */ +#undef CONFIG_SYS_I2C +#undef CONFIG_SYS_I2C_OMAP24XX +#endif + #endif /* __CONFIG_OMAP4_COMMON_H */ -- 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] sh: delete redundant CONFIG_SH definition
Hi,
Sorry, I misunderstand.
CONFIG_SH is used by driver, bdinfo and other.
I rejected this patch.
Best regards,
Nobuhiro
2014/1/7 Nobuhiro Iwamatsu iwama...@nigauri.org:
Hi,
Applied, thanks.
Best regards,
Nobuhiro
2014/1/7 Nobuhiro Iwamatsu iwama...@nigauri.org:
Hi,
Thanks for your patch.
2014/1/6 Masahiro Yamada yamad...@jp.panasonic.com:
CONFIG_SH is defined in arch/sh/config.mk.
It is not necessary to define it in each board
header config header file.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
Cc: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com
Acked-by: Nobuhiro Iwamatsu iwama...@nigauri.org
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sh: delete redundant CONFIG_SH definition
Hi, again.
And sorry
I made sure that there is no problem in your patch.
Applied, thanks!
Nobuhiro
2014/1/8 Nobuhiro Iwamatsu iwama...@nigauri.org:
Hi,
Sorry, I misunderstand.
CONFIG_SH is used by driver, bdinfo and other.
I rejected this patch.
Best regards,
Nobuhiro
2014/1/7 Nobuhiro Iwamatsu iwama...@nigauri.org:
Hi,
Applied, thanks.
Best regards,
Nobuhiro
2014/1/7 Nobuhiro Iwamatsu iwama...@nigauri.org:
Hi,
Thanks for your patch.
2014/1/6 Masahiro Yamada yamad...@jp.panasonic.com:
CONFIG_SH is defined in arch/sh/config.mk.
It is not necessary to define it in each board
header config header file.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
Cc: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com
Acked-by: Nobuhiro Iwamatsu iwama...@nigauri.org
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/2] usb: exynos5: arndale: Add network support
Arndale board has AX88760, which is USB 2.0 Hub USB 2.0 Ethernet Combo
controller, connected to HSIC Phy of USB host controller via USB3503 hub.
This patch uses board specific board_usb_init function to perform reset
sequence for USB3503 hub and enables the relevant config options for
network to work.
Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
---
board/samsung/arndale/arndale.c | 21 +
drivers/usb/host/ehci-exynos.c |2 ++
include/configs/arndale.h |4
3 files changed, 27 insertions(+)
diff --git a/board/samsung/arndale/arndale.c b/board/samsung/arndale/arndale.c
index 052fecd..9efc355 100644
--- a/board/samsung/arndale/arndale.c
+++ b/board/samsung/arndale/arndale.c
@@ -5,12 +5,33 @@
*/
#include common.h
+#include usb.h
#include asm/arch/pinmux.h
#include asm/arch/dwmmc.h
+#include asm/arch/gpio.h
#include asm/arch/power.h
DECLARE_GLOBAL_DATA_PTR;
+#ifdef CONFIG_USB_EHCI_EXYNOS
+int board_usb_init(int index, enum usb_init_type init)
+{
+ struct exynos5_gpio_part1 *gpio = (struct exynos5_gpio_part1 *)
+ samsung_get_base_gpio_part1();
+
+ /* Configure gpios for usb 3503 hub:
+* disconnect, toggle reset and connect
+*/
+ s5p_gpio_direction_output(gpio-d1, 7, 0);
+ s5p_gpio_direction_output(gpio-x3, 5, 0);
+
+ s5p_gpio_direction_output(gpio-x3, 5, 1);
+ s5p_gpio_direction_output(gpio-d1, 7, 1);
+
+ return 0;
+}
+#endif
+
int board_init(void)
{
gd-bd-bi_boot_params = (PHYS_SDRAM_1 + 0x100UL);
diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 88e6466..9356878 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -203,6 +203,8 @@ int ehci_hcd_init(int index, enum usb_init_type init,
setup_usb_phy(ctx-usb);
+ board_usb_init(index, init);
+
*hccr = ctx-hcd;
*hcor = (struct ehci_hcor *)((uint32_t) *hccr
+ HC_LENGTH(ehci_readl((*hccr)-cr_capbase)));
diff --git a/include/configs/arndale.h b/include/configs/arndale.h
index b7fb29e..eda0e4f 100644
--- a/include/configs/arndale.h
+++ b/include/configs/arndale.h
@@ -116,6 +116,10 @@
#define CONFIG_USB_EHCI_EXYNOS
#define CONFIG_USB_STORAGE
+#define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 3
+#define CONFIG_USB_HOST_ETHER
+#define CONFIG_USB_ETHER_ASIX
+
/* MMC SPL */
#define CONFIG_EXYNOS_SPL
#define CONFIG_SPL
--
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/2] usb: ehci: exynos: set/reset hsic phys
From: Inderpal Singh chander.kash...@linaro.org
The controller has 3 ports. The port0 is for USB 2.0 Phy, port1 and port2
are for HSIC phys. The usb 2.0 phy is already being setup. This patch
sets up the hsic phys.
Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
arch/arm/include/asm/arch-exynos/ehci.h | 14 +++
drivers/usb/host/ehci-exynos.c | 39 +++
2 files changed, 53 insertions(+)
diff --git a/arch/arm/include/asm/arch-exynos/ehci.h
b/arch/arm/include/asm/arch-exynos/ehci.h
index d79f25c..d2d70bd 100644
--- a/arch/arm/include/asm/arch-exynos/ehci.h
+++ b/arch/arm/include/asm/arch-exynos/ehci.h
@@ -29,6 +29,20 @@
#define EHCICTRL_ENAINCR8 (1 27)
#define EHCICTRL_ENAINCR16 (1 26)
+#define HSIC_CTRL_REFCLKSEL (0x2)
+#define HSIC_CTRL_REFCLKSEL_MASK(0x3)
+#define HSIC_CTRL_REFCLKSEL_SHIFT (23)
+
+#define HSIC_CTRL_REFCLKDIV_12 (0x24)
+#define HSIC_CTRL_REFCLKDIV_MASK(0x7f)
+#define HSIC_CTRL_REFCLKDIV_SHIFT (16)
+
+#define HSIC_CTRL_SIDDQ (0x1 6)
+#define HSIC_CTRL_FORCESLEEP(0x1 5)
+#define HSIC_CTRL_FORCESUSPEND (0x1 4)
+#define HSIC_CTRL_UTMISWRST (0x1 2)
+#define HSIC_CTRL_PHYSWRST (0x1 0)
+
/* Register map for PHY control */
struct exynos_usb_phy {
unsigned int usbphyctrl0;
diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 66b4de0..88e6466 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -88,6 +88,8 @@ static int exynos_usb_parse_dt(const void *blob, struct
exynos_ehci *exynos)
/* Setup the EHCI host controller. */
static void setup_usb_phy(struct exynos_usb_phy *usb)
{
+ u32 hsic_ctrl;
+
set_usbhost_mode(USB20_PHY_CFG_HOST_LINK_EN);
set_usbhost_phy_ctrl(POWER_USB_HOST_PHY_CTRL_EN);
@@ -112,6 +114,32 @@ static void setup_usb_phy(struct exynos_usb_phy *usb)
clrbits_le32(usb-usbphyctrl0,
HOST_CTRL0_LINKSWRST |
HOST_CTRL0_UTMISWRST);
+
+ /* HSIC Phy Setting */
+ hsic_ctrl = (HSIC_CTRL_FORCESUSPEND |
+ HSIC_CTRL_FORCESLEEP |
+ HSIC_CTRL_SIDDQ);
+
+ clrbits_le32(usb-hsicphyctrl1, hsic_ctrl);
+ clrbits_le32(usb-hsicphyctrl2, hsic_ctrl);
+
+ hsic_ctrl = (((HSIC_CTRL_REFCLKDIV_12 HSIC_CTRL_REFCLKDIV_MASK)
+HSIC_CTRL_REFCLKDIV_SHIFT)
+ | ((HSIC_CTRL_REFCLKSEL HSIC_CTRL_REFCLKSEL_MASK)
+HSIC_CTRL_REFCLKSEL_SHIFT)
+ | HSIC_CTRL_UTMISWRST);
+
+ setbits_le32(usb-hsicphyctrl1, hsic_ctrl);
+ setbits_le32(usb-hsicphyctrl2, hsic_ctrl);
+
+ udelay(10);
+
+ clrbits_le32(usb-hsicphyctrl1, HSIC_CTRL_PHYSWRST |
+ HSIC_CTRL_UTMISWRST);
+
+ clrbits_le32(usb-hsicphyctrl2, HSIC_CTRL_PHYSWRST |
+ HSIC_CTRL_UTMISWRST);
+
udelay(20);
/* EHCI Ctrl setting */
@@ -125,6 +153,8 @@ static void setup_usb_phy(struct exynos_usb_phy *usb)
/* Reset the EHCI host controller. */
static void reset_usb_phy(struct exynos_usb_phy *usb)
{
+ u32 hsic_ctrl;
+
/* HOST_PHY reset */
setbits_le32(usb-usbphyctrl0,
HOST_CTRL0_PHYSWRST |
@@ -133,6 +163,15 @@ static void reset_usb_phy(struct exynos_usb_phy *usb)
HOST_CTRL0_FORCESUSPEND |
HOST_CTRL0_FORCESLEEP);
+ /* HSIC Phy reset */
+ hsic_ctrl = (HSIC_CTRL_FORCESUSPEND |
+ HSIC_CTRL_FORCESLEEP |
+ HSIC_CTRL_SIDDQ |
+ HSIC_CTRL_PHYSWRST);
+
+ setbits_le32(usb-hsicphyctrl1, hsic_ctrl);
+ setbits_le32(usb-hsicphyctrl2, hsic_ctrl);
+
set_usbhost_phy_ctrl(POWER_USB_HOST_PHY_CTRL_DISABLE);
}
--
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 0/2] Add usb ethernet support for Arndale
Arndale board has AX88760, which is USB 2.0 Hub USB 2.0 Ethernet Combo controller, connected to HSIC Phy of USB host controller via USB3503 hub. This patchset adds support for this usb ethernet controllor. Changes in v2: - removed setting preboot environment in patch 2 Changes in v3: - used generic board_usb_init Inderpal Singh (2): usb: ehci: exynos: set/reset hsic phys usb: exynos5: arndale: Add network support arch/arm/include/asm/arch-exynos/ehci.h | 14 +++ board/samsung/arndale/arndale.c | 21 drivers/usb/host/ehci-exynos.c | 41 +++ include/configs/arndale.h |4 +++ 4 files changed, 80 insertions(+) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] fs/ext4: fix partition size get truncated in calculation
It may cause file system corruption when do a write operation. This issue only affects boards that use 32 bit lbaint_t. Signed-off-by: Ma Haijun mahaij...@gmail.com --- fs/ext4/dev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ext4/dev.c b/fs/ext4/dev.c index 787e041..e0b513a 100644 --- a/fs/ext4/dev.c +++ b/fs/ext4/dev.c @@ -41,7 +41,7 @@ void ext4fs_set_blk_dev(block_dev_desc_t *rbdd, disk_partition_t *info) get_fs()-dev_desc = rbdd; part_info = info; part_offset = info-start; - get_fs()-total_sect = (info-size * info-blksz) + get_fs()-total_sect = ((uint64_t)info-size * info-blksz) get_fs()-dev_desc-log2blksz; } -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] sandbox question
Hello Tiger, On Wed, Jan 8, 2014 at 6:22 AM, tiger...@viatech.com.cn wrote: Hi, Simon: Thanks for your reply! Well you could, but what benefit would that provide? It would not use any code from arch/arm if that is what you are thinking. Sandbox is its own 'architecture'? Your question seems a bit odd to me. My understanding of the sandbox feature, is to let someone play around with u-boot from an architecture independent perspective. Theoretically, this means that you should be able to cross-compile the sandbox application as an ARM executable and run it anywhere ... like on the Raspberry Pi (ARMv7, I think). Or you could just compile it and run on a standard x86 system. Obviously, the binary images produced for both architectures will be different, but the code should work the same. And naturally, running the application on an x86 system working at 2Ghz will be different from running it on an ARM system working at 700Mhz. The whole point of calling the code architecture independent is that it will work across all systems. So, if sandbox's fs/ext4 drivers' test passed on an x86 platform,but these architecture related optimizations would cause some potential bugs on ARM platform. If you really do find an odd bug where it does not work as expected (it can happen), then that's an exceptional case which should be investigated further. I'm not sure if investigating it in sandbox mode will help. -Abraham V. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/6] sh: sh3: remove CONFIG_SH3 definition from board config
CONFIG_SH3 was already defined in arch/sh/sh3/config.mk. This removes CONFIG_SH3 from board config files of SH3. Signed-off-by: Nobuhiro Iwamatsu iwama...@nigauri.org --- include/configs/mpr2.h | 1 - include/configs/ms7720se.h | 1 - include/configs/shmin.h| 1 - 3 files changed, 3 deletions(-) diff --git a/include/configs/mpr2.h b/include/configs/mpr2.h index 47ed694..8ae497c 100644 --- a/include/configs/mpr2.h +++ b/include/configs/mpr2.h @@ -24,7 +24,6 @@ #define CONFIG_VERSION_VARIABLE /* CPU and platform */ -#define CONFIG_SH3 1 #define CONFIG_CPU_SH7720 1 #define CONFIG_MPR21 diff --git a/include/configs/ms7720se.h b/include/configs/ms7720se.h index 029f0e7..585d68f 100644 --- a/include/configs/ms7720se.h +++ b/include/configs/ms7720se.h @@ -9,7 +9,6 @@ #ifndef __MS7720SE_H #define __MS7720SE_H -#define CONFIG_SH3 1 #define CONFIG_CPU_SH7720 1 #define CONFIG_MS7720SE1 diff --git a/include/configs/shmin.h b/include/configs/shmin.h index 4f333b0..f8155ef 100644 --- a/include/configs/shmin.h +++ b/include/configs/shmin.h @@ -9,7 +9,6 @@ #ifndef __SHMIN_H #define __SHMIN_H -#define CONFIG_SH3 1 #define CONFIG_CPU_SH7706 1 /* T-SH7706LAN */ #define CONFIG_SHMIN 1 -- 1.8.5.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/6] sh: sh3: Add CONFIG_SH3 definition to config.mk of SH3
Signed-off-by: Nobuhiro Iwamatsu iwama...@nigauri.org --- arch/sh/cpu/sh3/config.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/sh/cpu/sh3/config.mk b/arch/sh/cpu/sh3/config.mk index 5c77e5c..abd4b8d 100644 --- a/arch/sh/cpu/sh3/config.mk +++ b/arch/sh/cpu/sh3/config.mk @@ -11,5 +11,5 @@ # SPDX-License-Identifier: GPL-2.0+ # # -PLATFORM_CPPFLAGS += -m3 +PLATFORM_CPPFLAGS += -DCONFIG_SH3 -m3 PLATFORM_RELFLAGS += -ffixed-r13 -- 1.8.5.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/6] sh: sh4: remove CONFIG_SH4 definition from board config
CONFIG_SH4 was already defined in arch/sh/sh4/config.mk. This removes CONFIG_SH4 from board config files of SH4. Signed-off-by: Nobuhiro Iwamatsu iwama...@nigauri.org --- include/configs/MigoR.h | 1 - include/configs/ap325rxa.h | 1 - include/configs/ap_sh4a_4a.h | 1 - include/configs/ecovec.h | 1 - include/configs/espt.h | 1 - include/configs/ms7722se.h | 1 - include/configs/ms7750se.h | 1 - include/configs/r0p7734.h| 1 - include/configs/r2dplus.h| 1 - include/configs/sh7763rdp.h | 1 - 10 files changed, 10 deletions(-) diff --git a/include/configs/MigoR.h b/include/configs/MigoR.h index 47e3322..88df94f 100644 --- a/include/configs/MigoR.h +++ b/include/configs/MigoR.h @@ -10,7 +10,6 @@ #define __MIGO_R_H #undef DEBUG -#define CONFIG_SH4 1 #define CONFIG_CPU_SH7722 1 #define CONFIG_MIGO_R 1 diff --git a/include/configs/ap325rxa.h b/include/configs/ap325rxa.h index a3c6b2b..462b2e2 100644 --- a/include/configs/ap325rxa.h +++ b/include/configs/ap325rxa.h @@ -11,7 +11,6 @@ #define __AP325RXA_H #undef DEBUG -#define CONFIG_SH4 1 #define CONFIG_CPU_SH7723 1 #define CONFIG_AP325RXA1 diff --git a/include/configs/ap_sh4a_4a.h b/include/configs/ap_sh4a_4a.h index 7478386..0162c3b 100644 --- a/include/configs/ap_sh4a_4a.h +++ b/include/configs/ap_sh4a_4a.h @@ -10,7 +10,6 @@ #define __AP_SH4A_4A_H #undef DEBUG -#define CONFIG_SH4 1 #define CONFIG_SH4A1 #define CONFIG_CPU_SH7734 1 #define CONFIG_AP_SH4A_4A 1 diff --git a/include/configs/ecovec.h b/include/configs/ecovec.h index a8f6dc9..ee9bd07 100644 --- a/include/configs/ecovec.h +++ b/include/configs/ecovec.h @@ -23,7 +23,6 @@ */ #undef DEBUG -#define CONFIG_SH4 1 #define CONFIG_SH4A1 #define CONFIG_CPU_SH7724 1 #define CONFIG_BOARD_LATE_INIT 1 diff --git a/include/configs/espt.h b/include/configs/espt.h index 8493c24..de16be7 100644 --- a/include/configs/espt.h +++ b/include/configs/espt.h @@ -10,7 +10,6 @@ #ifndef __ESPT_H #define __ESPT_H -#define CONFIG_SH4 1 #define CONFIG_CPU_SH7763 1 #define CONFIG_ESPT1 #define __LITTLE_ENDIAN1 diff --git a/include/configs/ms7722se.h b/include/configs/ms7722se.h index 20f8226..1c8ada6 100644 --- a/include/configs/ms7722se.h +++ b/include/configs/ms7722se.h @@ -9,7 +9,6 @@ #ifndef __MS7722SE_H #define __MS7722SE_H -#define CONFIG_SH4 1 #define CONFIG_CPU_SH7722 1 #define CONFIG_MS7722SE1 diff --git a/include/configs/ms7750se.h b/include/configs/ms7750se.h index d7285fd..4cf8efe 100644 --- a/include/configs/ms7750se.h +++ b/include/configs/ms7750se.h @@ -9,7 +9,6 @@ #ifndef __MS7750SE_H #define __MS7750SE_H -#define CONFIG_SH4 1 #define CONFIG_CPU_SH7750 1 /* #define CONFIG_CPU_SH7751 1 */ /* #define CONFIG_CPU_TYPE_R 1 */ diff --git a/include/configs/r0p7734.h b/include/configs/r0p7734.h index 766d9b7..0bb7cc5 100644 --- a/include/configs/r0p7734.h +++ b/include/configs/r0p7734.h @@ -10,7 +10,6 @@ #define __R0P7734_H #undef DEBUG -#define CONFIG_SH4 1 #define CONFIG_SH4A1 #define CONFIG_CPU_SH7734 1 #define CONFIG_R0P7734 1 diff --git a/include/configs/r2dplus.h b/include/configs/r2dplus.h index 264abeb..24d0c34 100644 --- a/include/configs/r2dplus.h +++ b/include/configs/r2dplus.h @@ -3,7 +3,6 @@ #undef DEBUG -#define CONFIG_SH4 1 #define CONFIG_CPU_SH7751 1 #define CONFIG_CPU_SH_TYPE_R 1 #define CONFIG_R2DPLUS 1 diff --git a/include/configs/sh7763rdp.h b/include/configs/sh7763rdp.h index 0b19e05..2438318 100644 --- a/include/configs/sh7763rdp.h +++ b/include/configs/sh7763rdp.h @@ -10,7 +10,6 @@ #ifndef __SH7763RDP_H #define __SH7763RDP_H -#define CONFIG_SH4 1 #define CONFIG_CPU_SH7763 1 #define CONFIG_SH7763RDP 1 #define __LITTLE_ENDIAN1 -- 1.8.5.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/6] sh: sh4: Add CONFIG_SH4 definition to config.mk of SH4
Signed-off-by: Nobuhiro Iwamatsu iwama...@nigauri.org --- arch/sh/cpu/sh4/config.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/sh/cpu/sh4/config.mk b/arch/sh/cpu/sh4/config.mk index c357557..753580b 100644 --- a/arch/sh/cpu/sh4/config.mk +++ b/arch/sh/cpu/sh4/config.mk @@ -8,5 +8,5 @@ # SPDX-License-Identifier: GPL-2.0+ # # -PLATFORM_CPPFLAGS += -m4-nofpu +PLATFORM_CPPFLAGS += -DCONFIG_SH4 -m4-nofpu PLATFORM_RELFLAGS += -ffixed-r13 -- 1.8.5.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/6] sh: sh2: remove CONFIG_SH2 definition from board config
CONFIG_SH2 was already defined in arch/sh/sh2/config.mk. This removes CONFIG_SH2 from board config files of SH2. Signed-off-by: Nobuhiro Iwamatsu iwama...@nigauri.org --- include/configs/rsk7203.h | 1 - include/configs/rsk7264.h | 1 - include/configs/rsk7269.h | 1 - 3 files changed, 3 deletions(-) diff --git a/include/configs/rsk7203.h b/include/configs/rsk7203.h index d64579f..5920a26 100644 --- a/include/configs/rsk7203.h +++ b/include/configs/rsk7203.h @@ -11,7 +11,6 @@ #define __RSK7203_H #undef DEBUG -#define CONFIG_SH2 1 #define CONFIG_SH2A1 #define CONFIG_CPU_SH7203 1 #define CONFIG_RSK7203 1 diff --git a/include/configs/rsk7264.h b/include/configs/rsk7264.h index 62b0618..5338cf2 100644 --- a/include/configs/rsk7264.h +++ b/include/configs/rsk7264.h @@ -12,7 +12,6 @@ #define __RSK7264_H #undef DEBUG -#define CONFIG_SH2 1 #define CONFIG_SH2A1 #define CONFIG_CPU_SH7264 1 #define CONFIG_RSK7264 1 diff --git a/include/configs/rsk7269.h b/include/configs/rsk7269.h index 452f5b4..4796039 100644 --- a/include/configs/rsk7269.h +++ b/include/configs/rsk7269.h @@ -11,7 +11,6 @@ #define __RSK7269_H #undef DEBUG -#define CONFIG_SH2 1 #define CONFIG_SH2A1 #define CONFIG_CPU_SH7269 1 #define CONFIG_RSK7269 1 -- 1.8.5.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/6] sh: sh2: Add CONFIG_SH2 definition to config.mk of SH2
Signed-off-by: Nobuhiro Iwamatsu iwama...@nigauri.org --- arch/sh/cpu/sh2/config.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/sh/cpu/sh2/config.mk b/arch/sh/cpu/sh2/config.mk index 8a0de96..69273b4 100644 --- a/arch/sh/cpu/sh2/config.mk +++ b/arch/sh/cpu/sh2/config.mk @@ -12,7 +12,7 @@ PLATFORM_CPPFLAGS += -m2a -m2a-nofpu -mb -ffreestanding else # SH2 PLATFORM_CPPFLAGS += -m3e -mb endif -PLATFORM_CPPFLAGS += $(call cc-option,-mno-fdpic) +PLATFORM_CPPFLAGS += -DCONFIG_SH2 $(call cc-option,-mno-fdpic) PLATFORM_RELFLAGS += -ffixed-r13 PLATFORM_LDFLAGS += $(ENDIANNESS) -- 1.8.5.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] sh: sh2: Change CONFIG_SYS_HZ to CONFIG_SH_CMT_CLK_FREQ
CONFIG_SYS_HZ of SH2 is not used as frequency of base timer. This is the
correct clock of CMT.
This changes from CONFIG_SYS_HZ to CONFIG_SH_CMT_CLK_FREQ, in order to use
CONFIG_SYS_HZ as clock of CMT.
Signed-off-by: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com
---
arch/sh/lib/time_sh2.c| 2 +-
include/configs/rsk7203.h | 2 +-
include/configs/rsk7264.h | 2 +-
include/configs/rsk7269.h | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/sh/lib/time_sh2.c b/arch/sh/lib/time_sh2.c
index be3896c..4b1f47b 100644
--- a/arch/sh/lib/time_sh2.c
+++ b/arch/sh/lib/time_sh2.c
@@ -84,5 +84,5 @@ void __udelay(unsigned long usec)
unsigned long get_tbclk(void)
{
- return CONFIG_SYS_HZ;
+ return CONFIG_SH_CMT_CLK_FREQ;
}
diff --git a/include/configs/rsk7203.h b/include/configs/rsk7203.h
index acee4e8..c002bf7 100644
--- a/include/configs/rsk7203.h
+++ b/include/configs/rsk7203.h
@@ -87,7 +87,7 @@
#define CONFIG_SH_TMU_CLK_FREQ CONFIG_SYS_CLK_FREQ
#define CONFIG_SH_SCIF_CLK_FREQ CONFIG_SYS_CLK_FREQ
#define CMT_CLK_DIVIDER32 /* 8 (default), 32, 128 or 512 */
-#define CONFIG_SYS_HZ (CONFIG_SYS_CLK_FREQ / CMT_CLK_DIVIDER)
+#define CONFIG_SH_CMT_CLK_FREQ (CONFIG_SYS_CLK_FREQ / CMT_CLK_DIVIDER)
/* Network interface */
#define CONFIG_SMC911X
diff --git a/include/configs/rsk7264.h b/include/configs/rsk7264.h
index a5dbb64..adb5460 100644
--- a/include/configs/rsk7264.h
+++ b/include/configs/rsk7264.h
@@ -67,7 +67,7 @@
#define CONFIG_SH_TMU_CLK_FREQ CONFIG_SYS_CLK_FREQ
#define CONFIG_SH_SCIF_CLK_FREQ CONFIG_SYS_CLK_FREQ
#define CMT_CLK_DIVIDER32 /* 8 (default), 32, 128 or 512
*/
-#define CONFIG_SYS_HZ (CONFIG_SYS_CLK_FREQ / CMT_CLK_DIVIDER)
+#define CONFIG_SH_CMT_CLK_FREQ (CONFIG_SYS_CLK_FREQ / CMT_CLK_DIVIDER)
/* Network interface */
#define CONFIG_SMC911X
diff --git a/include/configs/rsk7269.h b/include/configs/rsk7269.h
index 9f54160..a8c6a8f 100644
--- a/include/configs/rsk7269.h
+++ b/include/configs/rsk7269.h
@@ -66,7 +66,7 @@
#define CONFIG_SH_TMU_CLK_FREQ CONFIG_SYS_CLK_FREQ
#define CONFIG_SH_SCIF_CLK_FREQ CONFIG_SYS_CLK_FREQ
#define CMT_CLK_DIVIDER32 /* 8 (default), 32, 128 or 512
*/
-#define CONFIG_SYS_HZ (CONFIG_SYS_CLK_FREQ / CMT_CLK_DIVIDER)
+#define CONFIG_SH_CMT_CLK_FREQ (CONFIG_SYS_CLK_FREQ / CMT_CLK_DIVIDER)
/* Network interface */
#define CONFIG_SMC911X
--
1.8.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] fs/ext4: fix calling put_ext4 with truncated offset
Curently, we are using 32 bit multiplication to calculate the offset,
so the result will always be 32 bit.
This can silently cause file system corruption when performing a write
operation on partition larger than 4 GiB.
This patch address the issue by simply promoting the terms to 64 bit,
and let compilers decide how to do the multiplication efficiently.
Signed-off-by: Ma Haijun mahaij...@gmail.com
---
fs/ext4/ext4_common.c | 34 +-
fs/ext4/ext4_journal.c | 8
fs/ext4/ext4_write.c | 14 +++---
3 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c
index 352943e..cff50d8 100644
--- a/fs/ext4/ext4_common.c
+++ b/fs/ext4/ext4_common.c
@@ -445,9 +445,9 @@ restart:
goto fail;
}
put_ext4(((uint64_t)
- (g_parent_inode-b.
+ ((uint64_t)g_parent_inode-b.
blocks.dir_blocks[direct_blk_idx] *
- fs-blksz)), zero_buffer, fs-blksz);
+ (uint64_t)fs-blksz)), zero_buffer,
fs-blksz);
g_parent_inode-size =
g_parent_inode-size + fs-blksz;
g_parent_inode-blockcnt =
@@ -864,8 +864,8 @@ long int ext4fs_get_new_blk_no(void)
for (i = 0; i fs-no_blkgrp; i++) {
if (bgd[i].free_blocks) {
if (bgd[i].bg_flags EXT4_BG_BLOCK_UNINIT) {
- put_ext4(((uint64_t) (bgd[i].block_id *
- fs-blksz)),
+ put_ext4(((uint64_t)
((uint64_t)bgd[i].block_id *
+
(uint64_t)fs-blksz)),
zero_buffer, fs-blksz);
bgd[i].bg_flags =
bgd[i].
@@ -929,8 +929,8 @@ restart:
if (bgd[bg_idx].bg_flags EXT4_BG_BLOCK_UNINIT) {
memset(zero_buffer, '\0', fs-blksz);
- put_ext4(((uint64_t) (bgd[bg_idx].block_id *
- fs-blksz)), zero_buffer, fs-blksz);
+ put_ext4(((uint64_t) ((uint64_t)bgd[bg_idx].block_id *
+ (uint64_t)fs-blksz)), zero_buffer,
fs-blksz);
memcpy(fs-blk_bmaps[bg_idx], zero_buffer, fs-blksz);
bgd[bg_idx].bg_flags = bgd[bg_idx].bg_flags
~EXT4_BG_BLOCK_UNINIT;
@@ -996,8 +996,8 @@ int ext4fs_get_new_inode_no(void)
bgd[i].free_inodes;
if (bgd[i].bg_flags EXT4_BG_INODE_UNINIT) {
put_ext4(((uint64_t)
- (bgd[i].inode_id *
- fs-blksz)),
+ ((uint64_t)bgd[i].inode_id *
+ (uint64_t)fs-blksz)),
zero_buffer, fs-blksz);
bgd[i].bg_flags = bgd[i].bg_flags
~EXT4_BG_INODE_UNINIT;
@@ -1037,8 +1037,8 @@ restart:
ibmap_idx = fs-curr_inode_no / inodes_per_grp;
if (bgd[ibmap_idx].bg_flags EXT4_BG_INODE_UNINIT) {
memset(zero_buffer, '\0', fs-blksz);
- put_ext4(((uint64_t) (bgd[ibmap_idx].inode_id *
- fs-blksz)), zero_buffer,
+ put_ext4(((uint64_t) ((uint64_t)bgd[ibmap_idx].inode_id
*
+ (uint64_t)fs-blksz)),
zero_buffer,
fs-blksz);
bgd[ibmap_idx].bg_flags =
bgd[ibmap_idx].bg_flags ~EXT4_BG_INODE_UNINIT;
@@ -1143,7 +1143,7 @@ static void alloc_single_indirect_block(struct ext2_inode
*file_inode,
}
/* write the block to disk */
- put_ext4(((uint64_t) (si_blockno * fs-blksz)),
+ put_ext4(((uint64_t) ((uint64_t)si_blockno *
(uint64_t)fs-blksz)),
si_start_addr, fs-blksz);
file_inode-b.blocks.indir_block = si_blockno;
}
@@ -1242,7 +1242,7 @@ static void alloc_double_indirect_block(struct ext2_inode
*file_inode,
break;
}
[U-Boot] [PATCH] sf: params: Removed flag SECT_4K for Micron N25Q128
Remove the flag SECT_4K for device N25Q128 as the 4K-byte
sub sector erase granularity is available only for top/bottom
8 sectors in some of the N25Q128 chips.
Signed-off-by: Siva Durga Prasad Paladugu siva...@xilinx.com
---
drivers/mtd/spi/sf_params.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
index 4cdb4c2..daf8fe7 100644
--- a/drivers/mtd/spi/sf_params.c
+++ b/drivers/mtd/spi/sf_params.c
@@ -73,8 +73,8 @@ const struct spi_flash_params spi_flash_params_table[] = {
{N25Q32A,0x20bb16, 0x0, 64 * 1024,64, RD_FULL,
WR_QPP | SECT_4K},
{N25Q64, 0x20ba17, 0x0, 64 * 1024, 128, RD_FULL,
WR_QPP | SECT_4K},
{N25Q64A,0x20bb17, 0x0, 64 * 1024, 128, RD_FULL,
WR_QPP | SECT_4K},
- {N25Q128,0x20ba18, 0x0, 64 * 1024, 256, RD_FULL,
WR_QPP | SECT_4K},
- {N25Q128A, 0x20bb18, 0x0, 64 * 1024, 256, RD_FULL,
WR_QPP | SECT_4K},
+ {N25Q128,0x20ba18, 0x0, 64 * 1024, 256, RD_FULL,
WR_QPP},
+ {N25Q128A, 0x20bb18, 0x0, 64 * 1024, 256, RD_FULL,
WR_QPP},
{N25Q256,0x20ba19, 0x0, 64 * 1024, 512, RD_FULL,
WR_QPP | SECT_4K},
{N25Q256A, 0x20bb19, 0x0, 64 * 1024, 512, RD_FULL,
WR_QPP | SECT_4K},
{N25Q512,0x20ba20, 0x0, 64 * 1024, 1024, RD_FULL,
WR_QPP | E_FSR | SECT_4K},
--
1.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] When will orphan boards removed?
Hello Tom, Albert. When will Orphan boards in boards.cfg removed? Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap4_common: config: remove I2C for SPL mode
Hi Nishanth, On Wednesday 08 January 2014 07:36 AM, Nishanth Menon wrote: Commit 6789e84ecaa8f45d053084e08c381284a04abff7 (i2c, omap24xx: convert driver to new mutlibus/mutliadapter framework) intended to make I2C driver compatible with latest changes. It unfortunately has had a impact on size on SPL as well. For example on SDP4430, 32032 bytes before/MLO 35416 bytes after/MLO With this mentioned commit, MLO stops booting on SDP4430 as only 32K is accessible for non-secure (bootloader) s/w on GP devices and the size increase to 56K fails boot. On the latest u-boot commit e7be18225fbea76d1f0034b224f0d1e60f07cfcf, MLO is now at size 35592 bytes, However, I2C is not necessary for SPL to function as we use SR_I2C for controlling the PMIC. Disabling I2C reduces MLO to 32224 bytes which allows OMAP4 GP platform to boot up. Since this is common for all OMAP4 platforms, remove the need for I2C for SPL builds in the common config. Signed-off-by: Nishanth Menon n...@ti.com --- Though I originally reported this for SDP4430[1], a test on PandaBoard-ES also indicated fail to boot! Tested on PandaBoard-ES and SDP4430 Build result: http://pastebin.mozilla.org/3963101 Test log: SDP4430: http://pastebin.mozilla.org/3963123 PandaBoard-ES: http://pastebin.mozilla.org/3963134 [1] http://marc.info/?l=u-bootm=138914031918099w=2 include/configs/omap4_common.h |6 ++ 1 file changed, 6 insertions(+) diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h index ea56eeb..7cfd471 100644 --- a/include/configs/omap4_common.h +++ b/include/configs/omap4_common.h @@ -154,4 +154,10 @@ #define CONFIG_SPL_DISPLAY_PRINT #define CONFIG_SPL_LDSCRIPT $(CPUDIR)/omap-common/u-boot-spl.lds +#ifdef CONFIG_SPL_BUILD +/* No need for i2c in SPL mode as we will use SRI2C for PMIC access on OMAP4 */ +#undef CONFIG_SYS_I2C +#undef CONFIG_SYS_I2C_OMAP24XX +#endif + #endif /* __CONFIG_OMAP4_COMMON_H */ correct. Thanks for the fix. Also with size remaining still as 32224 bytes OMAP4 HS devices might not boot up. Anyways thats separate and something more like this patch has to be removed. Reviewed-by: Sricharan R r.sricha...@ti.com Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Regression: SDP4430 - Fails to boot - bisect indicates i2c adaptation
Hi Nishanth, On Wednesday 08 January 2014 05:48 AM, Nishanth Menon wrote: Hi, I happened to try SDP4430 out a earlier today with tip of u-boot mainline and it refused to even bring up SPL logs. Last working tag happens to be v2013.10 Earliest fail tag happens to be v2014.01-rc1 A bisect showed the following: http://pastebin.mozilla.org/3962513 i2c, omap24xx: convert driver to new mutlibus/mutliadapter framework This is already reported and a patch is already sent for this. This patch is in u-boot-arm and ll soon get merged in u-boot. http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commit;h=dcc23576384dbb875a4427dcfa9ac8d237230d42 Thanks and regards, Lokesh At commit 6789e84ecaa8f45d053084e08c381284a04abff7 it does indeed fail to boot up, git reset --hard HEAD^ allows the board to boot up successfully. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] sh: sh4: Add CONFIG_SH4 definition to config.mk of SH4
Hi Nobuhiro. diff --git a/arch/sh/cpu/sh4/config.mk b/arch/sh/cpu/sh4/config.mk index c357557..753580b 100644 --- a/arch/sh/cpu/sh4/config.mk +++ b/arch/sh/cpu/sh4/config.mk @@ -8,5 +8,5 @@ # SPDX-License-Identifier: GPL-2.0+ # # -PLATFORM_CPPFLAGS += -m4-nofpu +PLATFORM_CPPFLAGS += -DCONFIG_SH4 -m4-nofpu PLATFORM_RELFLAGS += -ffixed-r13 Basically it looks good to me. But I have some comments. Before this patch series, include/configs/r7780mp.h include/configs/sh7752evb.h include/configs/sh7753evb.h include/configs/sh7757lcr.h include/configs/sh7785lcr.h defined not CONFIG_SH4, but CONFIG_SH4A. Now you are adding CONFIG_SH4 to them too. If we do not have to distinguish SH4A from SH4, can we delete CONFIG_SH4A? It looks like we can re-write #if defined(CONFIG_SH4) || defined(CONFIG_SH4A) as #if defined(CONFIG_SH4) in /arch/sh/include/asm/cache.h and /include/sh_tmu.h Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/5] imx: mx6q_4x_mt41j128.cfg: enable ecspi3 clocks
Signed-off-by: Christian Gmeiner christian.gmei...@gmail.com --- board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg b/board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg index bb6c60b..b9e107a 100644 --- a/board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg +++ b/board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg @@ -144,7 +144,7 @@ DATA 4 0x021b0404 0x00011006 /* set the default clock gate to save power */ DATA 4 0x020c4068 0x00C03F3F -DATA 4 0x020c406c 0x0030FC03 +DATA 4 0x020c406c 0x0030FC33 DATA 4 0x020c4070 0x0FFFC000 DATA 4 0x020c4074 0x3FF0 DATA 4 0x020c4078 0x00FFF300 -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5] fdt: add fdt_add_display_timings(..)
This new function is used to set all display-timings
properties based on fb_videomode.
display-timings {
timing0 {
clock-frequency = 2500;
hactive = 640;
vactive = 480;
hback-porch = 48;
hfront-porch = 16;
vback-porch = 31;
vfront-porch = 12;
hsync-len = 96;
vsync-len = 2;
};
};
Signed-off-by: Christian Gmeiner christian.gmei...@gmail.com
---
common/fdt_support.c | 23 +++
include/fdt_support.h |3 +++
2 files changed, 26 insertions(+)
diff --git a/common/fdt_support.c b/common/fdt_support.c
index 4e32b02..cf81a4b 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -11,6 +11,7 @@
#include stdio_dev.h
#include linux/ctype.h
#include linux/types.h
+#include linux/fb.h
#include asm/global_data.h
#include libfdt.h
#include fdt_support.h
@@ -1342,6 +1343,28 @@ err_size:
#endif
/*
+ * fdt_add_display_timings: add display-timings properties
+ *
+ * @fdt: ptr to device tree
+ * @noff: node to update
+ * @mode: ptr to b_videomode
+ */
+void fdt_add_display_timings(void *fdt, int noff, struct fb_videomode *mode)
+{
+ if (noff != -FDT_ERR_NOTFOUND) {
+ fdt_setprop_u32(fdt, noff, clock-frequency, mode-pixclock);
+ fdt_setprop_u32(fdt, noff, hactive, mode-xres);
+ fdt_setprop_u32(fdt, noff, vactive, mode-yres);
+ fdt_setprop_u32(fdt, noff, hback-porch, mode-left_margin);
+ fdt_setprop_u32(fdt, noff, hfront-porch, mode-right_margin);
+ fdt_setprop_u32(fdt, noff, vback-porch, mode-upper_margin);
+ fdt_setprop_u32(fdt, noff, vfront-porch, mode-lower_margin);
+ fdt_setprop_u32(fdt, noff, hsync-len, mode-hsync_len);
+ fdt_setprop_u32(fdt, noff, vsync-len, mode-vsync_len);
+ }
+}
+
+/*
* Verify the physical address of device tree node for a given alias
*
* This function locates the device tree node of a given alias, and then
diff --git a/include/fdt_support.h b/include/fdt_support.h
index 9871e2f..1c54880 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -82,6 +82,9 @@ int fdt_set_phandle(void *fdt, int nodeoffset, uint32_t
phandle);
unsigned int fdt_create_phandle(void *fdt, int nodeoffset);
int fdt_add_edid(void *blob, const char *compat, unsigned char *buf);
+struct fb_videomode;
+void fdt_add_display_timings(void *blob, int noff, struct fb_videomode *mode);
+
int fdt_verify_alias_address(void *fdt, int anode, const char *alias,
u64 addr);
u64 fdt_get_base_address(void *fdt, int node);
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH 0/5] SATA support for OMAP5 uevm
Aneesh,
Sorry for the late reply.
On 11/12/2013 12:36 AM, V, Aneesh wrote:
Roger,
-Original Message-
From: Quadros, Roger
Sent: Monday, November 11, 2013 5:16 AM
To: V, Aneesh
Cc: Enric Balletbo Serra; u-boot@lists.denx.de; Rini, Tom; Krishnamoorthy,
Balaji
T; rob.herr...@calxeda.com
Subject: Re: [U-Boot] [RFC][PATCH 0/5] SATA support for OMAP5 uevm
Aneesh,
On 11/07/2013 07:15 PM, V, Aneesh wrote:
Hi Roger,
-Original Message-
From: Quadros, Roger
Sent: Thursday, November 07, 2013 2:45 AM
To: Enric Balletbo Serra
Cc: u-boot@lists.denx.de; Rini, Tom; Krishnamoorthy, Balaji T;
rob.herr...@calxeda.com; V, Aneesh
Subject: Re: [U-Boot] [RFC][PATCH 0/5] SATA support for OMAP5 uevm
+Aneesh.
Hi Enric,
On 11/07/2013 10:52 AM, Enric Balletbo Serra wrote:
Hi Roger,
Thanks for the patches!
2013/11/6 Roger Quadros rog...@ti.com:
Hi,
This series adds SATA support for OMAP5 uevm board.
This is an RFC patchset for review only. Patches are based on
v2013.10.
cheers,
-roger
---
Roger Quadros (5):
ahci: Error out with message on malloc() failure
ARM: OMAP5: Add Pipe3 PHY driver
ARM: OMAP5: Add PRCM and Control information for SATA
ARM: OMAP5: Add SATA platform glue
ARM: omap5_uevm: Add SATA support
arch/arm/cpu/armv7/omap-common/Makefile| 7 +
arch/arm/cpu/armv7/omap-common/pipe3-phy.c | 233
+ arch/arm/cpu/armv7/omap-
common/pipe3-phy.h | 36 +
arch/arm/cpu/armv7/omap-common/sata.c | 78 ++
arch/arm/cpu/armv7/omap5/prcm-regs.c | 5 +
arch/arm/include/asm/arch-omap5/clock.h| 3 +
arch/arm/include/asm/arch-omap5/omap.h | 3 +
arch/arm/include/asm/arch-omap5/sata.h | 48 ++
arch/arm/include/asm/omap_common.h | 3 +
board/ti/omap5_uevm/evm.c | 7 +
drivers/block/ahci.c | 16 +-
include/configs/omap5_uevm.h | 10 ++
12 files changed, 447 insertions(+), 2 deletions(-) create mode
100644 arch/arm/cpu/armv7/omap-common/pipe3-phy.c
create mode 100644 arch/arm/cpu/armv7/omap-common/pipe3-phy.h
create mode 100644 arch/arm/cpu/armv7/omap-common/sata.c
create mode 100644 arch/arm/include/asm/arch-omap5/sata.h
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
I applied your patches and worked perfectly, however I've two small
issues.
The first issue is that I see the following error:
scanning bus for devices...
ERROR: v7_dcache_inval_range - start address is not aligned -
0xfee48618
ERROR: v7_dcache_inval_range - stop address is not aligned -
0xfee48818
I'm seeing this too. Not sure how to fix it.
Aneesh, any pointers?
The issue is that the dcache invalidation is requested for a buffer
that is not aligned to cache-line boundary. The cpu instructions for
cache invalidation operate on cache lines, so a cache line can not be
invalidated partially. So in this case the invalidation function will
refuse to
invalidate the first and last cache lines.
The solution is to align your DMA buffer correctly. Take a look at :
ALLOC_CACHE_ALIGN_BUFFER() and DEFINE_CACHE_ALIGN_BUFFER() in
include/common.h
Also, doc/README.arm-caches has instructions for handling cached buffers
for DMA.
Thanks for this tip, it helped.
One more thing. While I was looking at arch/arm/cpu/armv7/cache_v7.c I failed
to understand how you convert the cache line size from words to byte.
e.g.
static void v7_maint_dcache_level_setway(u32 level, u32 operation) {
u32 ccsidr;
u32 num_sets, num_ways, log2_line_len, log2_num_ways;
u32 way_shift;
set_csselr(level, ARMV7_CSSELR_IND_DATA_UNIFIED);
ccsidr = get_ccsidr();
log2_line_len = ((ccsidr CCSIDR_LINE_SIZE_MASK)
CCSIDR_LINE_SIZE_OFFSET) + 2;
/* Converting from words to bytes */
log2_line_len += 2;
Shouldn't this be
log2_line_len += 1;
I don’t remember the details of that calculation. But assuming 32-bit word and
this variable representing the log2 of the line length it should be +=2 right?
Let's say 32 bytes, which is the cache-line size of A15:
32 bytes = 8 words = 2^3 words
32 bytes = 2^5 bytes
Right, I mistook word to be 16-bit.
cheers,
-roger
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/5] imx6: add ot1200 mr board
This patch add support for one device of the Bachmann OT1200
series - the mr variant.
My first attemp was to use one u-boot binary for all OT1200
devices, but as I need to load a device-specific devicetree
I decided to go this way.
Following components are used:
+ ethernet
+ usb
+ i2c
+ display connected via ldb (init and usage in linux only)
+ emmc
Signed-off-by: Christian Gmeiner christian.gmei...@gmail.com
---
board/bachmann/ot1200/Makefile |9 ++
board/bachmann/ot1200/ot1200.c | 246
boards.cfg |1 +
include/configs/ot1200.h | 241 +++
4 files changed, 497 insertions(+)
create mode 100644 board/bachmann/ot1200/Makefile
create mode 100644 board/bachmann/ot1200/ot1200.c
create mode 100644 include/configs/ot1200.h
diff --git a/board/bachmann/ot1200/Makefile b/board/bachmann/ot1200/Makefile
new file mode 100644
index 000..1bd42e8
--- /dev/null
+++ b/board/bachmann/ot1200/Makefile
@@ -0,0 +1,9 @@
+#
+# Copyright (C) 2012-2013, Guennadi Liakhovetski l...@denx.de
+# (C) Copyright 2012-2013 Freescale Semiconductor, Inc.
+# Copyright (C) 2013, Boundary Devices i...@boundarydevices.com
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y := ot1200.o
diff --git a/board/bachmann/ot1200/ot1200.c b/board/bachmann/ot1200/ot1200.c
new file mode 100644
index 000..6a884c2
--- /dev/null
+++ b/board/bachmann/ot1200/ot1200.c
@@ -0,0 +1,246 @@
+/*
+ * Copyright (C) 2010-2013 Freescale Semiconductor, Inc.
+ * Copyright (C) 2013, Bachmann electronic GmbH
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include asm/arch/clock.h
+#include asm/arch/imx-regs.h
+#include asm/arch/iomux.h
+#include asm/arch/mx6-pins.h
+#include asm/imx-common/iomux-v3.h
+#include asm/imx-common/mxc_i2c.h
+#include mmc.h
+#include fsl_esdhc.h
+#include netdev.h
+#include i2c.h
+#include pca953x.h
+#include edid.h
+#include linux/fb.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define UART_PAD_CTRL (PAD_CTL_PUS_100K_UP | \
+ PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | \
+ PAD_CTL_SRE_FAST | PAD_CTL_HYS)
+
+#define USDHC_PAD_CTRL (PAD_CTL_PUS_47K_UP | \
+ PAD_CTL_SPEED_LOW | PAD_CTL_DSE_80ohm | \
+ PAD_CTL_SRE_FAST | PAD_CTL_HYS)
+
+#define ENET_PAD_CTRL (PAD_CTL_PUS_100K_UP | \
+ PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS)
+
+#define SPI_PAD_CTRL (PAD_CTL_HYS | PAD_CTL_SPEED_MED |\
+ PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST)
+
+#define I2C_PAD_CTRL (PAD_CTL_PUS_100K_UP | \
+ PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS | \
+ PAD_CTL_ODE | PAD_CTL_SRE_FAST)
+
+#define OUTPUT_40OHM (PAD_CTL_SPEED_MED|PAD_CTL_DSE_40ohm)
+
+int dram_init(void)
+{
+ gd-ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE);
+
+ return 0;
+}
+
+static iomux_v3_cfg_t const uart1_pads[] = {
+ MX6_PAD_CSI0_DAT10__UART1_TXD | MUX_PAD_CTRL(UART_PAD_CTRL),
+ MX6_PAD_CSI0_DAT11__UART1_RXD | MUX_PAD_CTRL(UART_PAD_CTRL),
+};
+
+static void setup_iomux_uart(void)
+{
+ imx_iomux_v3_setup_multiple_pads(uart1_pads, ARRAY_SIZE(uart1_pads));
+}
+
+static iomux_v3_cfg_t const enet_pads[] = {
+ MX6_PAD_KEY_ROW1__ENET_COL | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_KEY_COL3__ENET_CRS | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_ENET_MDIO__ENET_MDIO | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_ENET_MDC__ENET_MDC | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_GPIO_16__ENET_ETHERNET_REF_OUT | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_GPIO_18__ENET_RX_CLK | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_ENET_RXD0__ENET_RDATA_0 | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_ENET_RXD1__ENET_RDATA_1 | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_KEY_COL2__ENET_RDATA_2 | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_KEY_COL0__ENET_RDATA_3 | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_ENET_CRS_DV__ENET_RX_EN | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_ENET_REF_CLK__ENET_TX_CLK | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_ENET_TXD0__ENET_TDATA_0 | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_ENET_TXD1__ENET_TDATA_1 | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_KEY_ROW2__ENET_TDATA_2 | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_KEY_ROW0__ENET_TDATA_3 | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_ENET_TX_EN__ENET_TX_EN | MUX_PAD_CTRL(ENET_PAD_CTRL),
+};
+
+static void setup_iomux_enet(void)
+{
+ imx_iomux_v3_setup_multiple_pads(enet_pads, ARRAY_SIZE(enet_pads));
+}
+
+int board_early_init_f(void)
+{
+ setup_iomux_uart();
+ setup_iomux_enet();
+ return 0;
+}
+
+static iomux_v3_cfg_t const ecspi1_pads[] = {
+ MX6_PAD_DISP0_DAT3__ECSPI3_SS0 | MUX_PAD_CTRL(SPI_PAD_CTRL),
+ MX6_PAD_DISP0_DAT4__ECSPI3_SS1 | MUX_PAD_CTRL(SPI_PAD_CTRL),
+ MX6_PAD_DISP0_DAT2__ECSPI3_MISO |
[U-Boot] [PATCH 5/5] imx6: make use of lldiv(..)
Commit 762a88ccf8540948fbf8c31b40a29d1e0684a25b introduces a 64-bit division without using the lldiv() function, which pulls in previously unused libgcc stuff. Signed-off-by: Måns Rullgård m...@mansr.com Signed-off-by: Christian Gmeiner christian.gmei...@gmail.com --- arch/arm/cpu/armv7/mx6/clock.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c index 873d9d0..4eeb09b 100644 --- a/arch/arm/cpu/armv7/mx6/clock.c +++ b/arch/arm/cpu/armv7/mx6/clock.c @@ -5,6 +5,7 @@ */ #include common.h +#include div64.h #include asm/io.h #include asm/errno.h #include asm/arch/imx-regs.h @@ -123,7 +124,7 @@ static u32 mxc_get_pll_pfd(enum pll_clocks pll, int pfd_num) return 0; } - return (freq * 18) / ((div ANATOP_PFD_FRAC_MASK(pfd_num)) + return lldiv(freq * 18, (div ANATOP_PFD_FRAC_MASK(pfd_num)) ANATOP_PFD_FRAC_SHIFT(pfd_num)); } -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5] edid: add function to convert edid to fb_videomode
There may be some custom boards in the field which have
an seperate eeprom chip to store edid informations in it.
To make use of those edid information in the board code
this patch add a function to convert edid to fb_videomode.
Signed-off-by: Christian Gmeiner christian.gmei...@gmail.com
---
common/edid.c | 29 +
include/edid.h |3 +++
2 files changed, 32 insertions(+)
diff --git a/common/edid.c b/common/edid.c
index e66108f..8841c25 100644
--- a/common/edid.c
+++ b/common/edid.c
@@ -12,6 +12,7 @@
#include common.h
#include edid.h
+#include linux/fb.h
#include linux/ctype.h
#include linux/string.h
@@ -288,3 +289,31 @@ void edid_print_info(struct edid1_info *edid_info)
if (!have_timing)
printf(\tNone\n);
}
+
+void edid_to_fb_videomode(struct edid1_info *edid, struct fb_videomode *mode)
+{
+struct edid_monitor_descriptor *monitor =
edid-monitor_details.descriptor[0];
+unsigned char *bytes = (unsigned char *)monitor;
+struct edid_detailed_timing *timing = (struct edid_detailed_timing
*)monitor;
+
+uint32_t pixclock = EDID_DETAILED_TIMING_PIXEL_CLOCK(*timing);
+uint32_t h_blanking =
EDID_DETAILED_TIMING_HORIZONTAL_BLANKING(*timing);
+uint32_t h_active = EDID_DETAILED_TIMING_HORIZONTAL_ACTIVE(*timing);
+uint32_t h_sync_offset = EDID_DETAILED_TIMING_HSYNC_OFFSET(*timing);
+uint32_t h_sync_width =
EDID_DETAILED_TIMING_HSYNC_PULSE_WIDTH(*timing);
+uint32_t v_blanking = EDID_DETAILED_TIMING_VERTICAL_BLANKING(*timing);
+uint32_t v_active = EDID_DETAILED_TIMING_VERTICAL_ACTIVE(*timing);
+uint32_t v_sync_offset = EDID_DETAILED_TIMING_VSYNC_OFFSET(*timing);
+uint32_t v_sync_width =
EDID_DETAILED_TIMING_VSYNC_PULSE_WIDTH(*timing);
+
+mode-name = EDID;
+mode-pixclock = pixclock;
+mode-yres = v_active;
+mode-xres = h_active;
+mode-left_margin = h_blanking - h_sync_offset - h_sync_width;
+mode-right_margin = h_sync_offset;
+mode-upper_margin = v_blanking - v_sync_offset - v_sync_width;
+mode-lower_margin = v_sync_offset;
+mode-hsync_len = h_sync_width;
+mode-vsync_len = v_sync_width;
+}
diff --git a/include/edid.h b/include/edid.h
index 480a773..4423062 100644
--- a/include/edid.h
+++ b/include/edid.h
@@ -233,6 +233,9 @@ struct edid1_info {
*/
void edid_print_info(struct edid1_info *edid_info);
+struct fb_videomode;
+void edid_to_fb_videomode(struct edid1_info *edid, struct fb_videomode *mode);
+
/**
* Check the EDID info.
*
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
