Re: [U-Boot] [RFC PATCH 04/17] kconfig: add defconfig files for all boards
Hi Daniel, On Sat, 22 Mar 2014 18:14:23 +0100 Daniel Schwierzeck wrote: > 2014-03-21 19:05 GMT+01:00 Tom Rini : > > On Thu, Mar 20, 2014 at 02:17:07PM +0100, Daniel Schwierzeck wrote: > >> 2014-03-20 1:11 GMT+01:00 Masahiro Yamada : > >> > > >> > [3] > >> > How to select board directoy by using boolean macros. > >> > > >> > If we try to emulate arch/arm/Makefile of Linux, > >> > > >> > board-$(CONFIG_BOARD_VEXPRESS_AEMV8A) := vexpress_aemv8a > >> > board-$(CONFIG_BOARD_AXS101) := axs101 > >> > board-$(CONFIG_BOARD_ARCANGEL4) := arcangel4 > >> > > >> > Like this? > >> > > >> > >> how about this: > >> > >> Makefile: > >> ... > >> lib-y += boards/ > >> ... > >> > >> board/Makefile: > >> obj-$(CONFIG_BOARD_A3000) += a3000/ > >> ... > >> obj-$(CONFIG_VENDOR_NVIDIA) += nvidia/ > >> ... > >> > >> board/nvidia/Makefile: > >> obj-y += common/ > >> obj-$(CONFIG_BOARD_BEAVER) += beaver/ > >> obj-$(CONFIG_BOARD_CARDHU) += cardhu/ > >> ... > > > > Yes, would something like this be doable? Thanks! > > > > yes, I played with it and created a script to generate all necessary > board and vendor Makefiles from boards.cfg. If we tweak mkconfig, It > already works with the current mainline. > > The patches are pushed to: git://git.denx.de/u-boot-mips.git kconfig-support > > If you want I can post a patch series and also create patches for CPU > and SOC directories. Thanks for your effort. I think basicly we're going to the right direction. But I am afraind more careful check is necessary before posting the series. I did build test on your patches on kconfig-support branch. I noticed many boards would be broken: - ARM cm_t335 am335x_boneblack am335x_evm am335x_evm_nor am335x_evm_norboot am335x_evm_spiboot am335x_evm_uart1 am335x_evm_uart2 am335x_evm_uart3 am335x_evm_uart4 am335x_evm_uart5 am335x_evm_usbspl h2200 palmld palmtc palmtreo680 zipitz2 vpac270_ond_256 mx31ads lubbock - AVR32 favr-32-ezkit - Blackfin bf527-ad7160-eval - PowerPC MVBLUE hermes svm_sc8xx ESTEEM192E ELPT860 FPS850L FPS860L NSCU SM850 TK885D TQM823L TQM823L_LCD TQM823M TQM850L TQM850M TQM855L TQM855M TQM860L TQM860M TQM862L TQM862M TQM866M TQM885D TTTech virtlab2 wtk MVSMR GENIETV ) Could you run MAKEALL or buildman over all target boards and fix all errors? And I want you to also fix a strange Makefile, board/synopsys/Makefile obj-$(CONFIG_BOARD_AXS101) += axs101/ obj-$(CONFIG_BOARD_) += / Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/17] Version 0 of Kconfig for U-Boot
Hi Simon, > > For example, we can describe a board header file like this: > > > > #if defined(CONFIG_TPL_BUILD) > > # define CONFIG_FOO 100 > > #elif defined(CONFIG_SPL_BUILD) > > # define CONFIG_FOO 50 > > #else > > # define CONFIG_FOO 10 > > # define CONFIG_BAR > > #endif > > I wonder if we should drop this, and require that all have the same > options? That would involve requiring that board config files are not > permitted to use #ifdef CONFIG_SPL or #ifdef CONFIG_TPL. > > Does that seem like a bad restriction? The advantage is that we only > need one defconfig for each board. It seems to me that things are > going to get really painful if we have three different configs. > > Of course, this doesn't preclude #ifdefs in the Makefiles or actual > source code, but we already have SPL-specific feature options. > > I'm not 100% clear on the constraints here. It is true that 3 defconfigs per board are painful, but those constraints should not be required. Opposite. You are suggesting a better idea below. We should not treat SPL as a special case. In my opinion, CONFIG_SPL_* should be discontinued. For example, we can merge CONFIG_SPL_TEXT_BASE to CONFIG_SYS_TEXT_BASE. I mean, #ifdef CONFIG_SPL_BUILD # define CONFIG_SYS_TEXT_BASE0x #else # define CONFIG_SYS_TEXT_BASE0x1000 #endif rather than #define CONFIG_SPL_TEXT_BASE0x #define CONFIG_SYS_TEXT_BASE0x1000 Above will be transformed in Kconfig style. CONFIG_SYS_TEXT_BASE=0x (in foo_spl_defconfig) CONFIG_SYS_TEXT_BASE=0x1000 (in foo_defconfig) > > How to change the setting? > > -- > > > > We can modify configuration as we do in Linux Kernel. > > Of cource "make config" works in U-Boot too. > > But I think most of you prefer GUI interface of "make menuconfig". > > (In Linux Kernel, with thousands of CONFIGs, "make config" is already > > useless.) > > > > The difference from Linux Kernel is that the configuration is done > > on three levels at most. > > One thought for the future - we should also think about dropping > spl/tpl as special cases, and just have a general ability to build > U-Boot multiple times with different options. So we could perhaps have > 5 different builds with different prefixes (none,spl,tpl,qpl, etc.) I like your idea very much!!! I believe this is the right way. Many makefiles are very dirty because of ifdef CONFIG_SPL_BUILD ... else ... endif. We should stop doing like this. SPL is just one of general images. I absolutely agree. But I think we need more efforts to go there. I want Kconfig on the main line soon (hopefully, in the MW in next month) and leave your idea to the next stage. 2014.04 : Kconfig along this series 2014.07 : Treat SPL and TPL as generic cases How about this time line? > Another little point - I think there is a mkdir missing somwhere: > > make O=b/snow snow_defconfig > /bin/sh: line 0: cd: b/snow: No such file or directory > Makefile:128: *** output directory "b/snow" does not exist. Stop. > > > (previously it would just create the directory with mkdir -p) Sorry. This feature was lost when switching to Kconfig. I've posted a patch to re-add it. Please check this: http://patchwork.ozlabs.org/patch/332955/ > > A mountain of work to do in front of us > > --- > > > > This series is the beginning of our long long journey too. > > We have thousands of CONFIG macros. > > Moving them needs much efforts but I believe it is worthwile. > > But I cannot do that task alone. > > Hey, board maintainers, I need your help! > > > > And, when you add a new CONFIG macro, please create an entry in Kconfig. > > Please do not add it into a header file any more. > > We should probably have a script in the build system which knows about > all the existing CONFIG items, and produces an error if it spots a new > one. That encourage force people to stop adding new CONFIGs. Possibly can it be included in scripts/checkpatch.pl ? I'm not sure.. > > [1] How board maintainers information should be handled? > > > > About half a year ago, commit 27af930e9a merged boards.cfg and MAINTAINERS. > > > > Since then, board maintainer information has been described in the > > rightest field of boards.cfg. > > > > But Kconfig uses defconfig files for board configuration. > > boards.cfg is no longer necessary. > > > > Where should board maintainer info be moved to? > > > > Revive MAINTAINERS file? > > > > Or create a new enrty in Kconfig? > > > > I chose the latter in this version. > > > > You will find something like this: > > CONFIG_BOARD_MAINTAINER="Tom Rini " > > in configs/*_defconfig. > > This seems OK to me, but I wonder if the maintainer is actually not > really a CONFIG option, but rather a built-in feature of the board, > something that cannot be changed. That would argue for putting it in > its own file. > > But this is fine with me. This item has been discus
Re: [U-Boot] [PATCH v3 6/9] i2c, davinci: add support for multiple i2c buses
Hello Murali,
Am 21.03.2014 21:51, schrieb Murali Karicheri:
From: Vitaly Andrianov
Signed-off-by: Vitaly Andrianov
Signed-off-by: Murali Karicheri
---
drivers/i2c/davinci_i2c.c | 343 +++--
drivers/i2c/davinci_i2c.h | 27 ++--
2 files changed, 218 insertions(+), 152 deletions(-)
diff --git a/drivers/i2c/davinci_i2c.c b/drivers/i2c/davinci_i2c.c
index 6e5260c..c4a6c4d 100644
--- a/drivers/i2c/davinci_i2c.c
+++ b/drivers/i2c/davinci_i2c.c
@@ -1,8 +1,9 @@
/*
* TI DaVinci (TMS320DM644x) I2C driver.
*
- * Copyright (C) 2007 Sergey Kubushyn
- *
+ * (C) Copyright 2012-2014
+ * Texas Instruments Incorporated,
+ * (C) Copyright 2007 Sergey Kubushyn
*
*
* SPDX-License-Identifier: GPL-2.0+
@@ -12,14 +13,26 @@
#include
#include
#include
+#include
#include "davinci_i2c.h"
+DECLARE_GLOBAL_DATA_PTR;
+
+static struct i2c_regs __attribute__((section(".data"))) *i2c_base =
+ (struct i2c_regs *)I2C_BASE;
+
+#ifdef CONFIG_I2C_MULTI_BUS
+static unsigned int __attribute__((section(".data")))
+ bus_initialized[I2C_BUS_MAX] = { [0 ... (I2C_BUS_MAX-1)] = 0 };
+static unsigned int __attribute__((section(".data"))) current_bus;
+#endif
+
NACK. Please convert this driver to the new i2c multibus/multiadapter
framework, please use CONFIG_SYS_I2C, thanks!
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] kbuild: create a build directory automatically for out-of-tree build
Prior to Kbuild, the build system created a build directory, when it did not exist, for out-of-tree build. This feature was dropped when we switched to Kbuild because many of lines in makefiles were copied from Linux Kernel. (In Linux Kernel, we have to create a build directory by ourselves before starting build.) That feature seems worth reviving for less typing even if our code and Linux Kernel diverge. Signed-off-by: Masahiro Yamada Suggested-by: Simon Glass --- Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 538c3bf..0522ba8 100644 --- a/Makefile +++ b/Makefile @@ -124,7 +124,8 @@ ifneq ($(KBUILD_OUTPUT),) # Invoke a second make in the output directory, passing relevant variables # check that the output directory actually exists saved-output := $(KBUILD_OUTPUT) -KBUILD_OUTPUT := $(shell cd $(KBUILD_OUTPUT) && /bin/pwd) +KBUILD_OUTPUT := $(shell mkdir -p $(KBUILD_OUTPUT) && cd $(KBUILD_OUTPUT) \ + && /bin/pwd) $(if $(KBUILD_OUTPUT),, \ $(error output directory "$(saved-output)" does not exist)) -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Query on u-boot
Hi, I have a below query on u-boot bootup. When UBOOT does not detect NOR flash during bootup it throws up an error message that indicates that uboot did not detect NOR flash and stops there. But when uboot does not detect QSPI flash it just gives a warning message that uboot sf_probe_failed, and comes to the uboot prompt. Why is this behavior different for NOR flash and QSPI flash. Regards, DP ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/t4240: updated RCW and PBI for rev2.0
Please ignore this patch. Will send a new version. Best Regards, Shaohui Xie > -Original Message- > From: shh@gmail.com [mailto:shh@gmail.com] > Sent: Saturday, March 22, 2014 4:08 PM > To: u-boot@lists.denx.de > Cc: Xie Shaohui-B21989 > Subject: [PATCH] powerpc/t4240: updated RCW and PBI for rev2.0 > > From: Shaohui Xie > > Also, remove workaround of rev1.0. > > Signed-off-by: Shaohui Xie > --- > board/freescale/t4qds/t4_pbi.cfg | 17 +++-- > board/freescale/t4qds/t4_rcw.cfg | 6 +++--- > 2 files changed, 6 insertions(+), 17 deletions(-) > > diff --git a/board/freescale/t4qds/t4_pbi.cfg > b/board/freescale/t4qds/t4_pbi.cfg > index c598fb5..e592c45 100644 > --- a/board/freescale/t4qds/t4_pbi.cfg > +++ b/board/freescale/t4qds/t4_pbi.cfg > @@ -13,20 +13,9 @@ > 09000d00 > 09000d04 fff8 > 09000d08 8112 > -#workaround for IFC bus speed > -091241c0 f03f3f3f > -091241c4 ff003f3f > -09124010 0101 > -09124130 000c > -#workaround for SERDES A-006031 > -090ea000 064740e6 > -090ea020 064740e6 > -090eb000 064740e6 > -090eb020 064740e6 > -090ec000 064740e6 > -090ec020 064740e6 > -090ed000 064740e6 > -090ed020 064740e6 > +#MDIO workaround for rev2.0 > +095fc030 8148 > +095fd030 00808148 > #Configure alternate space > 0910 > 0914 ff00 > diff --git a/board/freescale/t4qds/t4_rcw.cfg > b/board/freescale/t4qds/t4_rcw.cfg > index 74df01a..0732b9a 100644 > --- a/board/freescale/t4qds/t4_rcw.cfg > +++ b/board/freescale/t4qds/t4_rcw.cfg > @@ -1,7 +1,7 @@ > #PBL preamble and RCW header > aa55aa55 010e0100 > #serdes protocol 1_28_6_12 > -120c0019 0c101915 > -04383063 30548c00 6c02 1d00 > +16070019 18101916 > +04383063 30548c00 ec108000 1d00 > eeee 000307fc > - 0020 > + 0028 > -- > 1.8.0 > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] usb/xhci: remove XHCI init code from other usb controllers
The patch with commit id "020bbcb76b5be0d5406d2ae7c26dbdb013ead812"
adds some init codes for XHCI but not for other usb controllers.
And it will causes a bug for EHCI.
so use macro "#ifdef CONFIG_USB_XHCI" to run it just for XHCI.
Signed-off-by: Zhao Qiang
---
common/usb_hub.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/common/usb_hub.c b/common/usb_hub.c
index ffac0e7..7f791f1 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -90,12 +90,16 @@ static void usb_hub_power_on(struct usb_hub_device *hub)
int i;
struct usb_device *dev;
unsigned pgood_delay = hub->desc.bPwrOn2PwrGood * 2;
+
+#ifdef CONFIG_USB_XHCI
ALLOC_CACHE_ALIGN_BUFFER(struct usb_port_status, portsts, 1);
unsigned short portstatus;
int ret;
+#endif
dev = hub->pusb_dev;
+#ifdef CONFIG_USB_XHCI
/*
* Enable power to the ports:
* Here we Power-cycle the ports: aka,
@@ -132,6 +136,7 @@ static void usb_hub_power_on(struct usb_hub_device *hub)
continue;
}
}
+#endif
for (i = 0; i < dev->maxchild; i++) {
usb_set_port_feature(dev, i + 1, USB_PORT_FEAT_POWER);
--
1.8.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] we don't went version control for .cmd files
Hi Pavel, > .cmd files should not be version-controlled. > > Signed-off-by: Pavel Machek > > diff --git a/.gitignore b/.gitignore > index a163728..77fb2c8 100644 > --- a/.gitignore > +++ b/.gitignore > @@ -15,6 +15,7 @@ > *.swp > *.patch > *.bin > +*.cmd > > # Build tree > /build-* Which files do you need this patch for? Could you give me an example, please? Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] raw data
Hi, >Is there a command to read raw data from a disk partition to memory? Nand / mmc command is ok. Best wishes, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCH v2 0/9] sunxi: initial upstreamining effort
fre 2014-03-21 klockan 21:54 + skrev Ian Campbell: > I've tried to give corect credit and S-o-b based upon: > git log --pretty='%aN' linux-sunxi/sunxi -- [PATHS] | sort -u > git log linux-sunxi/sunxi -- [PATHS] | grep -i signed.off.by | sort -u > Manual inspection As you noticed there is S-o-b lines missing on most of my commits in sunxi branch. This was corrected in the sunxi-patchqueue branch where previous patchset were prepared for mainlining. Please add an implicit S-o-b line on any arch/arm/cpu/armv7/sunxi/ or board/sunxi/ on patches including code I have committed. Regards Henrik ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH u-boot sunxi 3/4] sunxi: Implement reset_cpu
sön 2014-03-16 klockan 18:38 + skrev Ian Campbell: > Not sure why cmd_watchdog.c is sunxi, seems like in principal it could > be generic. In principal it could, but there is no common API for setting the watchdog timer, and no common API for disabling the watchdog once armed. Regards Henrik ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH u-boot sunxi 3/4] sunxi: Implement reset_cpu
sön 2014-03-16 klockan 14:53 +0100 skrev Hans de Goede:
> void reset_cpu(ulong addr)
> {
> + static const struct sunxi_wdog *wdog =
> + &((struct sunxi_timer_reg *)SUNXI_TIMER_BASE)->wdog;
> +
> + /* Set the watchdog for its shortest interval (.5s) and wait */
> + writel(WDT_MODE_RESET_EN | WDT_MODE_EN, &wdog->mode);
> + writel(WDT_CTRL_RESTART, &wdog->ctl);
> + while (1);
This code is incomplete and do not reload the watchdog if already
running. wdog->ctl is locked by a magic key. Should use
writel(WDT_CTRL_KEY | WDT_CTRL_RESTART, &wdog->ctl);
where
#define WDT_CTRL_KEY(0x0a57 << 1)
Unfortunatley Allwinner kindly omitted this little detail from the User
Manual.
Found out while trying to use the watchdog as a watchdog and not only
reset. Asked Tom while he still was at Allwinner and got clarification
on how to use the watchdog control register.
Regards
Henrik
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: mx6: Add PCIe on SabreSDP
On Sunday, March 23, 2014 at 10:20:16 PM, Marek Vasut wrote: > Add support for PCIe on MX6 SabreSDP board and enable the support > in the config file. > > Signed-off-by: Marek Vasut > Cc: Stefano Babic > Cc: Fabio Estevam > Cc: Liu Ying Please ignore, V2 on it's way. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] pci: mx6: Implement power callback
Implement a callback to toggle the slot power supply. The callback
can be overriden in case some more complex power supply for the slot
was implemented in hardware, yet for the usual case, one can define
a GPIO which toggles the power to the slot.
Signed-off-by: Marek Vasut
Cc: Stefano Babic
Cc: Fabio Estevam
Cc: Liu Ying
---
drivers/pci/pcie_imx.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/pcie_imx.c b/drivers/pci/pcie_imx.c
index 34377e9..8951a93 100644
--- a/drivers/pci/pcie_imx.c
+++ b/drivers/pci/pcie_imx.c
@@ -451,6 +451,17 @@ static int imx6_pcie_init_phy(void)
return 0;
}
+__weak int imx6_pcie_toggle_power(void)
+{
+#ifdef CONFIG_PCIE_IMX_POWER_GPIO
+ gpio_direction_output(CONFIG_PCIE_IMX_POWER_GPIO, 0);
+ mdelay(20);
+ gpio_set_value(CONFIG_PCIE_IMX_POWER_GPIO, 1);
+ mdelay(20);
+#endif
+ return 0;
+}
+
__weak int imx6_pcie_toggle_reset(void)
{
/*
@@ -496,7 +507,7 @@ static int imx6_pcie_deassert_core_reset(void)
{
struct iomuxc *iomuxc_regs = (struct iomuxc *)IOMUXC_BASE_ADDR;
- /* FIXME: Power-up GPIO goes here. */
+ imx6_pcie_toggle_power();
/* Enable PCIe */
clrbits_le32(&iomuxc_regs->gpr[1], IOMUXC_GPR1_TEST_POWERDOWN);
--
1.9.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 2/2] ARM: mx6: Add PCIe on SabreSDP
Add support for PCIe on MX6 SabreSDP board and enable the support
in the config file.
Signed-off-by: Marek Vasut
Cc: Stefano Babic
Cc: Fabio Estevam
Cc: Liu Ying
---
board/freescale/mx6sabresd/mx6sabresd.c | 11 +++
include/configs/mx6sabresd.h| 10 ++
2 files changed, 21 insertions(+)
V2: Use the default slot-power callback. This is a nicer and more generic
solution, which scales and produces less polution of the code.
NOTE: Please test with and without card, and schedule for v2014.07 .
Please note I just managed to test this on MX6DL SabreSDP.
diff --git a/board/freescale/mx6sabresd/mx6sabresd.c
b/board/freescale/mx6sabresd/mx6sabresd.c
index 12d8c56..d7d932e 100644
--- a/board/freescale/mx6sabresd/mx6sabresd.c
+++ b/board/freescale/mx6sabresd/mx6sabresd.c
@@ -135,6 +135,16 @@ static void setup_spi(void)
imx_iomux_v3_setup_multiple_pads(ecspi1_pads, ARRAY_SIZE(ecspi1_pads));
}
+iomux_v3_cfg_t const pcie_pads[] = {
+ MX6_PAD_EIM_D19__GPIO3_IO19 | MUX_PAD_CTRL(NO_PAD_CTRL),/*
POWER */
+ MX6_PAD_GPIO_17__GPIO7_IO12 | MUX_PAD_CTRL(NO_PAD_CTRL),/*
RESET */
+};
+
+static void setup_pcie(void)
+{
+ imx_iomux_v3_setup_multiple_pads(pcie_pads, ARRAY_SIZE(pcie_pads));
+}
+
iomux_v3_cfg_t const di0_pads[] = {
MX6_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK,/* DISP0_CLK */
MX6_PAD_DI0_PIN2__IPU1_DI0_PIN02, /* DISP0_HSYNC */
@@ -454,6 +464,7 @@ int overwrite_console(void)
int board_eth_init(bd_t *bis)
{
setup_iomux_enet();
+ setup_pcie();
return cpu_eth_init(bis);
}
diff --git a/include/configs/mx6sabresd.h b/include/configs/mx6sabresd.h
index 4919f53..5d02d23 100644
--- a/include/configs/mx6sabresd.h
+++ b/include/configs/mx6sabresd.h
@@ -48,4 +48,14 @@
#define CONFIG_IPUV3_CLK 26000
#define CONFIG_IMX_HDMI
+#define CONFIG_CMD_PCI
+#ifdef CONFIG_CMD_PCI
+#define CONFIG_PCI
+#define CONFIG_PCI_PNP
+#define CONFIG_PCI_SCAN_SHOW
+#define CONFIG_PCIE_IMX
+#define CONFIG_PCIE_IMX_PERST_GPIO IMX_GPIO_NR(7, 12)
+#define CONFIG_PCIE_IMX_POWER_GPIO IMX_GPIO_NR(3, 19)
+#endif
+
#endif /* __MX6QSABRESD_CONFIG_H */
--
1.9.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: mx6: Add PCIe on SabreSDP
Add support for PCIe on MX6 SabreSDP board and enable the support
in the config file.
Signed-off-by: Marek Vasut
Cc: Stefano Babic
Cc: Fabio Estevam
Cc: Liu Ying
---
board/freescale/mx6sabresd/mx6sabresd.c | 22 ++
include/configs/mx6sabresd.h| 9 +
2 files changed, 31 insertions(+)
NOTE: Please schedule for 2014.07 and please test properly with _AND_ without
PCIe card.
diff --git a/board/freescale/mx6sabresd/mx6sabresd.c
b/board/freescale/mx6sabresd/mx6sabresd.c
index 12d8c56..8305414 100644
--- a/board/freescale/mx6sabresd/mx6sabresd.c
+++ b/board/freescale/mx6sabresd/mx6sabresd.c
@@ -135,6 +135,27 @@ static void setup_spi(void)
imx_iomux_v3_setup_multiple_pads(ecspi1_pads, ARRAY_SIZE(ecspi1_pads));
}
+#ifdef CONFIG_CMD_PCI
+iomux_v3_cfg_t const pcie_pads[] = {
+ MX6_PAD_EIM_D19__GPIO3_IO19 | MUX_PAD_CTRL(NO_PAD_CTRL),/*
POWER */
+ MX6_PAD_GPIO_17__GPIO7_IO12 | MUX_PAD_CTRL(NO_PAD_CTRL),/*
RESET */
+};
+
+static void setup_pcie(void)
+{
+ imx_iomux_v3_setup_multiple_pads(pcie_pads, ARRAY_SIZE(pcie_pads));
+
+ /* Power down the PCIe slot */
+ gpio_direction_output(IMX_GPIO_NR(3, 19), 0);
+ mdelay(25);
+ /* Power up the PCIe slot */
+ gpio_set_value(IMX_GPIO_NR(3, 19), 1);
+ mdelay(25);
+}
+#else
+static inline void setup_pcie(void) {}
+#endif
+
iomux_v3_cfg_t const di0_pads[] = {
MX6_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK,/* DISP0_CLK */
MX6_PAD_DI0_PIN2__IPU1_DI0_PIN02, /* DISP0_HSYNC */
@@ -454,6 +475,7 @@ int overwrite_console(void)
int board_eth_init(bd_t *bis)
{
setup_iomux_enet();
+ setup_pcie();
return cpu_eth_init(bis);
}
diff --git a/include/configs/mx6sabresd.h b/include/configs/mx6sabresd.h
index 4919f53..8b94310 100644
--- a/include/configs/mx6sabresd.h
+++ b/include/configs/mx6sabresd.h
@@ -48,4 +48,13 @@
#define CONFIG_IPUV3_CLK 26000
#define CONFIG_IMX_HDMI
+#define CONFIG_CMD_PCI
+#ifdef CONFIG_CMD_PCI
+#define CONFIG_PCI
+#define CONFIG_PCI_PNP
+#define CONFIG_PCI_SCAN_SHOW
+#define CONFIG_PCIE_IMX
+#define CONFIG_PCIE_IMX_PERST_GPIO IMX_GPIO_NR(7, 12)
+#endif
+
#endif /* __MX6QSABRESD_CONFIG_H */
--
1.9.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: mx6: Disable PCIe on SABRE Lite/Nitrogen6x
On 22/03/2014 21:50, Thierry Bultel wrote: > When I communicated about the bug I had, > and said that my temporary workaround was to disable the PCIe, > my intention was not to make the suppression become a standard, > and I believe it is a little bit frustrating for Marek. > The issue is the missing reset line. PCIe can be enabled as default for boards with the correct reset line. Suppression is not a standard for all boards. 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] ARM: mx6: Disable PCIe on SABRE Lite/Nitrogen6x
On 22/03/2014 19:26, Marek Vasut wrote: > On Saturday, March 22, 2014 at 04:17:09 PM, Eric Nelson wrote: >> Use of PCIe on SABRE Lite and Nitrogen6x boards >> is atypical and requires the use of custom daughter >> boards. >> >> Use in U-Boot is even rarer, so this patch removes it from >> the standard configuration. >> >> Signed-off-by: Eric Nelson > > :-( > > Acked-by: Marek Vasut > Thanks all. I'll merge it for the release. 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 8/9] spi: davinci: add support for multiple bus and chip select
Hi,
On Sat, Mar 22, 2014 at 2:21 AM, Murali Karicheri wrote:
> Currently davinci spi driver supports only bus 0 cs 0.
> This patch allows driver to support bus 1 and bus 2 with
> configurable number of chip selects. Also defaults are
> selected in a way to avoid regression on other platforms
> that uses davinci spi driver and has only one spi bus.
>
> Signed-off-by: Rex Chang
> Signed-off-by: Murali Karicheri
> Acked-by: Tom Rini
> ---
> drivers/spi/davinci_spi.c | 60
> ++---
> drivers/spi/davinci_spi.h | 33 +
> 2 files changed, 90 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c
> index e3fb321..b682bc4 100644
> --- a/drivers/spi/davinci_spi.c
> +++ b/drivers/spi/davinci_spi.c
> @@ -32,7 +32,27 @@ struct spi_slave *spi_setup_slave(unsigned int bus,
> unsigned int cs,
> if (!ds)
> return NULL;
>
> - ds->regs = (struct davinci_spi_regs *)CONFIG_SYS_SPI_BASE;
> + ds->slave.bus = bus;
> + ds->slave.cs = cs;
> +
> + switch (bus) {
> + case SPI0_BUS:
> + ds->regs = (struct davinci_spi_regs *)SPI0_BASE;
> + break;
> +#ifdef CONFIG_SYS_SPI1
> + case SPI1_BUS:
> + ds->regs = (struct davinci_spi_regs *)SPI0_BASE;
> + break;
> +#endif
> +#ifdef CONFIG_SYS_SPI2
> + case SPI2_BUS:
> + ds->regs = (struct davinci_spi_regs *)SPI2_BASE;
> + break;
> +#endif
> + default: /* Invalid bus number */
> + return NULL;
> + }
> +
> ds->freq = max_hz;
>
> return &ds->slave;
> @@ -59,7 +79,7 @@ int spi_claim_bus(struct spi_slave *slave)
> writel(SPIGCR1_MASTER_MASK | SPIGCR1_CLKMOD_MASK, &ds->regs->gcr1);
>
> /* CS, CLK, SIMO and SOMI are functional pins */
> - writel((SPIPC0_EN0FUN_MASK | SPIPC0_CLKFUN_MASK |
> + writel(((1 << slave->cs) | SPIPC0_CLKFUN_MASK |
> SPIPC0_DOFUN_MASK | SPIPC0_DIFUN_MASK), &ds->regs->pc0);
>
> /* setup format */
> @@ -262,9 +282,43 @@ out:
> return 0;
> }
>
> +#ifdef CONFIG_SYS_SPI1
> +static int bus1_cs_valid(unsigned int bus, unsigned int cs)
> +{
> + if ((bus == SPI1_BUS) && (cs < SPI1_NUM_CS))
> + return 1;
> + return 0;
> +}
> +#else
> +static int bus1_cs_valid(unsigned int bus, unsigned int cs)
> +{
> + return 0;
> +}
> +#endif
> +
> +#ifdef CONFIG_SYS_SPI2
> +static int bus2_cs_valid(unsigned int bus, unsigned int cs)
> +{
> + if ((bus == SPI2_BUS) && (cs < SPI2_NUM_CS))
> + return 1;
> + return 0;
> +}
> +#else
> +static int bus2_cs_valid(unsigned int bus, unsigned int cs)
> +{
> + return 0;
> +}
> +#endif
> +
> int spi_cs_is_valid(unsigned int bus, unsigned int cs)
> {
> - return bus == 0 && cs == 0;
> + if ((bus == SPI0_BUS) && (cs < SPI0_NUM_CS))
> + return 1;
> + else if (bus1_cs_valid(bus, cs))
> + return 1;
> + else if (bus2_cs_valid(bus, cs))
> + return 1;
> + return 0;
> }
>
> void spi_cs_activate(struct spi_slave *slave)
> diff --git a/drivers/spi/davinci_spi.h b/drivers/spi/davinci_spi.h
> index 33f69b5..d4612d3 100644
> --- a/drivers/spi/davinci_spi.h
> +++ b/drivers/spi/davinci_spi.h
> @@ -74,6 +74,39 @@ struct davinci_spi_regs {
> /* SPIDEF */
> #define SPIDEF_CSDEF0_MASK BIT(0)
>
> +#define SPI0_BUS 0
> +#define SPI0_BASE CONFIG_SYS_SPI_BASE
> +/*
> + * Define default SPI0_NUM_CS as 1 for existing platforms that uses this
> + * driver. Platform can configure number of CS using CONFIG_SYS_SPI0_NUM_CS
> + * if more than one CS is supported and by defining CONFIG_SYS_SPI0.
> + */
> +#ifndef CONFIG_SYS_SPI0
> +#define SPI0_NUM_CS1
> +#else
> +#define SPI0_NUM_CSCONFIG_SYS_SPI0_NUM_CS
> +#endif
> +
> +/*
> + * define CONFIG_SYS_SPI1 when platform has spi-1 device (bus #1) and
> + * CONFIG_SYS_SPI1_NUM_CS defines number of CS on this bus
> + */
> +#ifdef CONFIG_SYS_SPI1
> +#define SPI1_BUS 1
> +#define SPI1_NUM_CSCONFIG_SYS_SPI1_NUM_CS
> +#define SPI1_BASE CONFIG_SYS_SPI1_BASE
> +#endif
> +
> +/*
> + * define CONFIG_SYS_SPI2 when platform has spi-2 device (bus #2) and
> + * CONFIG_SYS_SPI2_NUM_CS defines number of CS on this bus
> + */
> +#ifdef CONFIG_SYS_SPI2
> +#define SPI2_BUS 2
> +#define SPI2_NUM_CSCONFIG_SYS_SPI2_NUM_CS
> +#define SPI2_BASE CONFIG_SYS_SPI2_BASE
> +#endif
> +
> struct davinci_spi_slave {
> struct spi_slave slave;
> struct davinci_spi_regs *regs;
> --
> 1.7.9.5
This code looks more static, can you try get the bus and cs from sf probe and
according assign the reg_base.
fyi: look at drivers/spi/zynq_spi.c where based on the bus number we assign the
reg_base and prior to that we can do the same for bus an
