Re: [U-Boot] [PATCH V7] ARM: mx6: Add support for Kosagi Novena
On Friday, October 17, 2014 at 01:27:10 AM, Fabio Estevam wrote: On Thu, Oct 16, 2014 at 8:02 PM, Marek Vasut ma...@denx.de wrote: So this discussion is related to a different thread ? I see ... We are talking about the need for the delay in the Ethernet PHY. Nikolay sent a patch adding such delay as a standard patch. OK, so we're discussing different patch here, thanks for clarifying. 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 V7] ARM: mx6: Add support for Kosagi Novena
On Saturday, October 11, 2014 at 11:04:58 PM, Fabio Estevam wrote: On Sat, Oct 11, 2014 at 11:21 AM, Sean Cross x...@kosagi.com wrote: Ok, understood. Just curious: which Ethernet PHY is used on the novena board? It's the same Micrel PHY used on the Sabrelite, the KSZ9021. nitrogen/sabrelite holds Ethernet PHY reset low for 10ms, which is in accordance with ksz9021 datasheet. Shouldn't we wait 10ms here as well? I checked the novena_spl.c and we do wait in novena_spl_setup_iomux_enet(). Is this what you have in mind ? 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 V7] ARM: mx6: Add support for Kosagi Novena
On Thu, Oct 16, 2014 at 7:21 AM, Marek Vasut ma...@denx.de wrote: I checked the novena_spl.c and we do wait in novena_spl_setup_iomux_enet(). Is this what you have in mind ? Nikolay added the delay in this patch: https://patchwork.ozlabs.org/patch/398920/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V7] ARM: mx6: Add support for Kosagi Novena
On Thursday, October 16, 2014 at 07:17:36 PM, Fabio Estevam wrote: On Thu, Oct 16, 2014 at 7:21 AM, Marek Vasut ma...@denx.de wrote: I checked the novena_spl.c and we do wait in novena_spl_setup_iomux_enet(). Is this what you have in mind ? Nikolay added the delay in this patch: https://patchwork.ozlabs.org/patch/398920/ So this discussion is related to a different thread ? I see ... 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 V7] ARM: mx6: Add support for Kosagi Novena
On Thu, Oct 16, 2014 at 8:02 PM, Marek Vasut ma...@denx.de wrote: So this discussion is related to a different thread ? I see ... We are talking about the need for the delay in the Ethernet PHY. Nikolay sent a patch adding such delay as a standard patch. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V7] ARM: mx6: Add support for Kosagi Novena
On Wed, Oct 15, 2014 at 11:38 PM, Sean Cross x...@kosagi.com wrote: My opinion is that, following the principle of least surprise, we should leave the delay in. If, sometime in the future, someone were to micro-optimize the boot sequence, they can strip it out then, but in that case it'd make more sense to load Linux directly from SPL. I say leave it in. Yes, I agree. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V7] ARM: mx6: Add support for Kosagi Novena
On 15/10/2014 12:47, Nikolay Dimitrov wrote: Hi Marek, On 10/15/2014 12:38 AM, Marek Vasut wrote: On Sunday, October 12, 2014 at 08:33:21 AM, Sean Cross wrote: On 12/10/2014 05:04, Fabio Estevam wrote: On Sat, Oct 11, 2014 at 11:21 AM, Sean Cross x...@kosagi.com wrote: Ok, understood. Just curious: which Ethernet PHY is used on the novena board? It's the same Micrel PHY used on the Sabrelite, the KSZ9021. nitrogen/sabrelite holds Ethernet PHY reset low for 10ms, which is in accordance with ksz9021 datasheet. Shouldn't we wait 10ms here as well? The reference manual for the PHY indicates that you should hold reset low for 10ms after the supply voltage stabilizes. So long as it takes at least 10msto get from the point at which the CPU starts executing its ROM code to the point at which the reset line is toggled, we will be fine. This definitelly is the case, so I presume we don't need the delay ? Well, here's how I see the case. After power on, the PHY unfortunately is out of reset (R20G is DNP, imx6 pin pulled high internally after reset). At some unknown point in time the CPU reaches novena_spl_setup_iomux_enet(). During all this time the PHY is still out of reset. Neither this complies with the recommended sequence, and even more doesn't comply if we remove the delay. If we leave the delay as it is currently implemented, the actual reset sequence is just delayed (by the time it takes the CPU to reach the PHY reset code). At this later point we enforce the proper reset sequence: supply rail is obviously now stable, and we keep the PHY reset low for the minimum specified time: 10ms. My understanding is that this is simple and efficient way to guarantee that for all different cases (different temperatures, different CPU silicon revisions, differently configured drivers/subsystems), the PHY reset timing is generated properly, and will be generated properly in the future when the code evolves. Please tell me if I'm missing something. I generally think we'd be fine without the delay, putting it into reset in the SPL and pulling it out of reset in U-Boot, but I can understand the need for future-proofing and clarity. If someone were to copy the code from Novena to a new board, they may find the PHY behaving unreliably If 10ms is the difference between we ought to be fine and we'll definitely be fine and not surprise anyone, then we should leave the delay in. Sean ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V7] ARM: mx6: Add support for Kosagi Novena
Hi Sean, guys, On 10/15/2014 10:47 AM, Sean Cross wrote: On 15/10/2014 12:47, Nikolay Dimitrov wrote: Hi Marek, On 10/15/2014 12:38 AM, Marek Vasut wrote: On Sunday, October 12, 2014 at 08:33:21 AM, Sean Cross wrote: On 12/10/2014 05:04, Fabio Estevam wrote: On Sat, Oct 11, 2014 at 11:21 AM, Sean Cross x...@kosagi.com wrote: Ok, understood. Just curious: which Ethernet PHY is used on the novena board? It's the same Micrel PHY used on the Sabrelite, the KSZ9021. nitrogen/sabrelite holds Ethernet PHY reset low for 10ms, which is in accordance with ksz9021 datasheet. Shouldn't we wait 10ms here as well? The reference manual for the PHY indicates that you should hold reset low for 10ms after the supply voltage stabilizes. So long as it takes at least 10msto get from the point at which the CPU starts executing its ROM code to the point at which the reset line is toggled, we will be fine. This definitelly is the case, so I presume we don't need the delay ? Well, here's how I see the case. After power on, the PHY unfortunately is out of reset (R20G is DNP, imx6 pin pulled high internally after reset). At some unknown point in time the CPU reaches novena_spl_setup_iomux_enet(). During all this time the PHY is still out of reset. Neither this complies with the recommended sequence, and even more doesn't comply if we remove the delay. If we leave the delay as it is currently implemented, the actual reset sequence is just delayed (by the time it takes the CPU to reach the PHY reset code). At this later point we enforce the proper reset sequence: supply rail is obviously now stable, and we keep the PHY reset low for the minimum specified time: 10ms. My understanding is that this is simple and efficient way to guarantee that for all different cases (different temperatures, different CPU silicon revisions, differently configured drivers/subsystems), the PHY reset timing is generated properly, and will be generated properly in the future when the code evolves. Please tell me if I'm missing something. I generally think we'd be fine without the delay, putting it into reset in the SPL and pulling it out of reset in U-Boot, but I can understand the need for future-proofing and clarity. If someone were to copy the code from Novena to a new board, they may find the PHY behaving unreliably If 10ms is the difference between we ought to be fine and we'll definitely be fine and not surprise anyone, then we should leave the delay in. Oops, I think my position on this topic seems to be too hard headed. I just wanted to justify why I wrote the patch this way, and I didn't wanted to look like an opposition. Sean, you're in the position of the oem, so I definitely appreciate your opinion, together with Marek's and Fabio's imx6 expertise. So guys, please advice - what should be the final value of this delay, and I'll re-send the patch if needed. Kind regards, Nikolay ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V7] ARM: mx6: Add support for Kosagi Novena
On 16/10/2014 03:16, Nikolay Dimitrov wrote: Hi Sean, guys, On 10/15/2014 10:47 AM, Sean Cross wrote: On 15/10/2014 12:47, Nikolay Dimitrov wrote: Hi Marek, On 10/15/2014 12:38 AM, Marek Vasut wrote: On Sunday, October 12, 2014 at 08:33:21 AM, Sean Cross wrote: On 12/10/2014 05:04, Fabio Estevam wrote: On Sat, Oct 11, 2014 at 11:21 AM, Sean Cross x...@kosagi.com wrote: Ok, understood. Just curious: which Ethernet PHY is used on the novena board? It's the same Micrel PHY used on the Sabrelite, the KSZ9021. nitrogen/sabrelite holds Ethernet PHY reset low for 10ms, which is in accordance with ksz9021 datasheet. Shouldn't we wait 10ms here as well? The reference manual for the PHY indicates that you should hold reset low for 10ms after the supply voltage stabilizes. So long as it takes at least 10msto get from the point at which the CPU starts executing its ROM code to the point at which the reset line is toggled, we will be fine. This definitelly is the case, so I presume we don't need the delay ? Well, here's how I see the case. After power on, the PHY unfortunately is out of reset (R20G is DNP, imx6 pin pulled high internally after reset). At some unknown point in time the CPU reaches novena_spl_setup_iomux_enet(). During all this time the PHY is still out of reset. Neither this complies with the recommended sequence, and even more doesn't comply if we remove the delay. If we leave the delay as it is currently implemented, the actual reset sequence is just delayed (by the time it takes the CPU to reach the PHY reset code). At this later point we enforce the proper reset sequence: supply rail is obviously now stable, and we keep the PHY reset low for the minimum specified time: 10ms. My understanding is that this is simple and efficient way to guarantee that for all different cases (different temperatures, different CPU silicon revisions, differently configured drivers/subsystems), the PHY reset timing is generated properly, and will be generated properly in the future when the code evolves. Please tell me if I'm missing something. I generally think we'd be fine without the delay, putting it into reset in the SPL and pulling it out of reset in U-Boot, but I can understand the need for future-proofing and clarity. If someone were to copy the code from Novena to a new board, they may find the PHY behaving unreliably If 10ms is the difference between we ought to be fine and we'll definitely be fine and not surprise anyone, then we should leave the delay in. Oops, I think my position on this topic seems to be too hard headed. I just wanted to justify why I wrote the patch this way, and I didn't wanted to look like an opposition. Sean, you're in the position of the oem, so I definitely appreciate your opinion, together with Marek's and Fabio's imx6 expertise. So guys, please advice - what should be the final value of this delay, and I'll re-send the patch if needed. My opinion is that, following the principle of least surprise, we should leave the delay in. If, sometime in the future, someone were to micro-optimize the boot sequence, they can strip it out then, but in that case it'd make more sense to load Linux directly from SPL. I say leave it in. Sean ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V7] ARM: mx6: Add support for Kosagi Novena
On Saturday, October 11, 2014 at 03:39:36 AM, Fabio Estevam wrote: Hi Marek, Fixed all, I dunno where my git-foo got wrong :/ Thanks! 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 V7] ARM: mx6: Add support for Kosagi Novena
On Sunday, October 12, 2014 at 08:33:21 AM, Sean Cross wrote: On 12/10/2014 05:04, Fabio Estevam wrote: On Sat, Oct 11, 2014 at 11:21 AM, Sean Cross x...@kosagi.com wrote: Ok, understood. Just curious: which Ethernet PHY is used on the novena board? It's the same Micrel PHY used on the Sabrelite, the KSZ9021. nitrogen/sabrelite holds Ethernet PHY reset low for 10ms, which is in accordance with ksz9021 datasheet. Shouldn't we wait 10ms here as well? The reference manual for the PHY indicates that you should hold reset low for 10ms after the supply voltage stabilizes. So long as it takes at least 10msto get from the point at which the CPU starts executing its ROM code to the point at which the reset line is toggled, we will be fine. This definitelly is the case, so I presume we don't need the delay ? 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 V7] ARM: mx6: Add support for Kosagi Novena
Hi Marek, On 10/15/2014 12:38 AM, Marek Vasut wrote: On Sunday, October 12, 2014 at 08:33:21 AM, Sean Cross wrote: On 12/10/2014 05:04, Fabio Estevam wrote: On Sat, Oct 11, 2014 at 11:21 AM, Sean Cross x...@kosagi.com wrote: Ok, understood. Just curious: which Ethernet PHY is used on the novena board? It's the same Micrel PHY used on the Sabrelite, the KSZ9021. nitrogen/sabrelite holds Ethernet PHY reset low for 10ms, which is in accordance with ksz9021 datasheet. Shouldn't we wait 10ms here as well? The reference manual for the PHY indicates that you should hold reset low for 10ms after the supply voltage stabilizes. So long as it takes at least 10msto get from the point at which the CPU starts executing its ROM code to the point at which the reset line is toggled, we will be fine. This definitelly is the case, so I presume we don't need the delay ? Well, here's how I see the case. After power on, the PHY unfortunately is out of reset (R20G is DNP, imx6 pin pulled high internally after reset). At some unknown point in time the CPU reaches novena_spl_setup_iomux_enet(). During all this time the PHY is still out of reset. Neither this complies with the recommended sequence, and even more doesn't comply if we remove the delay. If we leave the delay as it is currently implemented, the actual reset sequence is just delayed (by the time it takes the CPU to reach the PHY reset code). At this later point we enforce the proper reset sequence: supply rail is obviously now stable, and we keep the PHY reset low for the minimum specified time: 10ms. My understanding is that this is simple and efficient way to guarantee that for all different cases (different temperatures, different CPU silicon revisions, differently configured drivers/subsystems), the PHY reset timing is generated properly, and will be generated properly in the future when the code evolves. Please tell me if I'm missing something. Kind regards, Nikolay ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V7] ARM: mx6: Add support for Kosagi Novena
On 12/10/2014 05:04, Fabio Estevam wrote: On Sat, Oct 11, 2014 at 11:21 AM, Sean Cross x...@kosagi.com wrote: Ok, understood. Just curious: which Ethernet PHY is used on the novena board? It's the same Micrel PHY used on the Sabrelite, the KSZ9021. nitrogen/sabrelite holds Ethernet PHY reset low for 10ms, which is in accordance with ksz9021 datasheet. Shouldn't we wait 10ms here as well? The reference manual for the PHY indicates that you should hold reset low for 10ms after the supply voltage stabilizes. So long as it takes at least 10msto get from the point at which the CPU starts executing its ROM code to the point at which the reset line is toggled, we will be fine. Sean ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V7] ARM: mx6: Add support for Kosagi Novena
Hi Nikolay, On Sat, Oct 11, 2014 at 2:01 AM, Nikolay Dimitrov picmas...@mail.bg wrote: We had some discussions about the PHY reset sequence and timing, but still not a common opinion, so I suggested to leave this fix for a consequent patch. Ok, understood. Just curious: which Ethernet PHY is used on the novena board? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V7] ARM: mx6: Add support for Kosagi Novena
On 11/10/2014 21:56, Fabio Estevam wrote: Hi Nikolay, On Sat, Oct 11, 2014 at 2:01 AM, Nikolay Dimitrov picmas...@mail.bg wrote: We had some discussions about the PHY reset sequence and timing, but still not a common opinion, so I suggested to leave this fix for a consequent patch. Ok, understood. Just curious: which Ethernet PHY is used on the novena board? It's the same Micrel PHY used on the Sabrelite, the KSZ9021. Sean ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V7] ARM: mx6: Add support for Kosagi Novena
On Saturday, October 11, 2014 at 03:44:06 AM, Fabio Estevam wrote: On Fri, Oct 10, 2014 at 10:14 PM, Marek Vasut ma...@denx.de wrote: +/* PCI express */ +#undef CONFIG_CMD_PCI /* Disable to prevent Linux from hanging on MX6 */ This has been fixed recently by this commit: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/dri vers/pci/host/pci-imx6.c?id=3e3e406e3807235906ee0b7c697664ea6dfd88de Are you positive it is possible to completely fix the PCI on MX6 ? What is the latest official statement from FSL on the PCI in MX6 please? 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 V7] ARM: mx6: Add support for Kosagi Novena
On Sat, Oct 11, 2014 at 3:43 PM, Marek Vasut ma...@denx.de wrote: Are you positive it is possible to completely fix the PCI on MX6 ? What is the I don't see the hang with that patch applied. Do you? Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V7] ARM: mx6: Add support for Kosagi Novena
On Sat, Oct 11, 2014 at 11:21 AM, Sean Cross x...@kosagi.com wrote: Ok, understood. Just curious: which Ethernet PHY is used on the novena board? It's the same Micrel PHY used on the Sabrelite, the KSZ9021. nitrogen/sabrelite holds Ethernet PHY reset low for 10ms, which is in accordance with ksz9021 datasheet. Shouldn't we wait 10ms here as well? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V7] ARM: mx6: Add support for Kosagi Novena
Add support for the Kosagi Novena board. Currently supported are:
- I2C busses
- FEC Ethernet
- MMC0, MMC1, Booting from MMC
- SATA
- USB ports
- USB Ethernet
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Stefano Babic sba...@denx.de
Cc: Sean Cross x...@kosagi.com
Cc: Nikolay Dimitrov picmas...@mail.bg
---
arch/arm/Kconfig | 4 +
board/kosagi/novena/Kconfig | 18 ++
board/kosagi/novena/Makefile | 11 +
board/kosagi/novena/novena.c | 343
board/kosagi/novena/novena_spl.c | 556 +++
board/kosagi/novena/setup.cfg| 47
configs/novena_defconfig | 4 +
include/configs/imx6_spl.h | 2 +-
include/configs/novena.h | 302 +
9 files changed, 1286 insertions(+), 1 deletion(-)
create mode 100644 board/kosagi/novena/Kconfig
create mode 100644 board/kosagi/novena/Makefile
create mode 100644 board/kosagi/novena/novena.c
create mode 100644 board/kosagi/novena/novena_spl.c
create mode 100644 board/kosagi/novena/setup.cfg
create mode 100644 configs/novena_defconfig
create mode 100644 include/configs/novena.h
V2: - Drop the tegra_keyboard_init() comment altogether
- Immediatelly return from the SD controller probe function on failure
- Rename PFUZE100_PMIC to just PFUZE100
- Fix the IMX OTP support with CMD_FUSE
- Enabling LVDS clock is still in place, since this is coming soon.
V3: - Zap rootpath builtin env
V4: - Zap the checkpatch issues
- Update comments
V5: - Don't configure VGEN1
- Set FPGA into reset in SPL
- Drop ECSPI1 and add ECSPI3 mux
- Drop UART1 and add UART3, UART4 muxes
- Add separate mux option for the RGMII pins which doesn't set SPEED field
- Move the configuration of RGMII after they were configured in GPIO mode
V6: - Drop 'string' prop from Kconfig
- Zap uSD card detect
- Add bigSD write-protect detection
- Zap USB hub reset GPIO
V7: - Zap USB hub reset GPIO configuration
- Remove unnecessary zeroing of GD in SPL
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 106aed9..4da1923 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -411,6 +411,9 @@ config TARGET_GW_VENTANA
config TARGET_HUMMINGBOARD
bool Support hummingboard
+config TARGET_KOSAGI_NOVENA
+ bool Support Kosagi Novena
+
config TARGET_TQMA6
bool TQ Systems TQMa6 board
@@ -637,6 +640,7 @@ source board/imx31_phycore/Kconfig
source board/isee/igep0033/Kconfig
source board/jornada/Kconfig
source board/karo/tx25/Kconfig
+source board/kosagi/novena/Kconfig
source board/logicpd/imx27lite/Kconfig
source board/logicpd/imx31_litekit/Kconfig
source board/mpl/vcma9/Kconfig
diff --git a/board/kosagi/novena/Kconfig b/board/kosagi/novena/Kconfig
new file mode 100644
index 000..4ba6399
--- /dev/null
+++ b/board/kosagi/novena/Kconfig
@@ -0,0 +1,18 @@
+if TARGET_KOSAGI_NOVENA
+
+config SYS_CPU
+ default armv7
+
+config SYS_BOARD
+ default novena
+
+config SYS_VENDOR
+ default kosagi
+
+config SYS_SOC
+ default mx6
+
+config SYS_CONFIG_NAME
+ default novena
+
+endif
diff --git a/board/kosagi/novena/Makefile b/board/kosagi/novena/Makefile
new file mode 100644
index 000..6fba177
--- /dev/null
+++ b/board/kosagi/novena/Makefile
@@ -0,0 +1,11 @@
+#
+# Copyright (C) 2014 Marek Vasut ma...@denx.de
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+ifdef CONFIG_SPL_BUILD
+obj-y := novena_spl.o
+else
+obj-y := novena.o
+endif
diff --git a/board/kosagi/novena/novena.c b/board/kosagi/novena/novena.c
new file mode 100644
index 000..2361a3c
--- /dev/null
+++ b/board/kosagi/novena/novena.c
@@ -0,0 +1,343 @@
+/*
+ * Novena board support
+ *
+ * Copyright (C) 2014 Marek Vasut ma...@denx.de
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include asm/errno.h
+#include asm/gpio.h
+#include asm/io.h
+#include asm/arch/clock.h
+#include asm/arch/crm_regs.h
+#include asm/arch/imx-regs.h
+#include asm/arch/iomux.h
+#include asm/arch/mxc_hdmi.h
+#include asm/arch/sys_proto.h
+#include asm/imx-common/boot_mode.h
+#include asm/imx-common/iomux-v3.h
+#include asm/imx-common/mxc_i2c.h
+#include asm/imx-common/sata.h
+#include asm/imx-common/video.h
+#include fsl_esdhc.h
+#include i2c.h
+#include input.h
+#include ipu_pixfmt.h
+#include linux/fb.h
+#include linux/input.h
+#include malloc.h
+#include micrel.h
+#include miiphy.h
+#include mmc.h
+#include netdev.h
+#include power/pmic.h
+#include power/pfuze100_pmic.h
+#include stdio_dev.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define NOVENA_BUTTON_GPIO IMX_GPIO_NR(4, 14)
+#define NOVENA_SD_WP IMX_GPIO_NR(1, 2)
+#define NOVENA_SD_CD IMX_GPIO_NR(1, 4)
+
+/*
+ * GPIO button
+ */
+#ifdef CONFIG_KEYBOARD
+static struct input_config button_input;
+
+static int novena_gpio_button_read_keys(struct input_config *input)
+{
+ int key = KEY_ENTER;
+ if (gpio_get_value(NOVENA_BUTTON_GPIO))
+
Re: [U-Boot] [PATCH V7] ARM: mx6: Add support for Kosagi Novena
Hi Marek,
On Fri, Oct 10, 2014 at 10:14 PM, Marek Vasut ma...@denx.de wrote:
+int board_early_init_f(void)
+{
+#if defined(CONFIG_VIDEO_IPUV3)
+ setup_display();
+#endif
+
+ /* Bring Ethernet PHY out of reset. */
+ gpio_set_value(IMX_GPIO_NR(3, 23), 1);
No delay needed here prior to setting it to 1?
+/* System configurations */
+#define CONFIG_MX6
+#define CONFIG_SYS_MX6_HCLK2400
+#define CONFIG_SYS_MX6_CLK32 32768
These are the default values from
arch/arm/include/asm/arch-mx6/clock.h. You could just drop them.
+/* Extra U-Boot environment. */
+#define CONFIG_EXTRA_ENV_SETTINGS \
+ fdt_high=0x\0 \
+ initrd_high=0x\0 \
+ consdev=ttymxc1\0 \
+ baudrate=115200\0 \
+ bootdev=/dev/mmcblk0p1\0 \
+ rootdev=/dev/mmcblk0p2\0 \
+ netdev=eth0\0 \
+ rootpath=/opt/eldk-5.5/armv7a-hf/rootfs-qte-sdk\0 \
Hardcoded root path again? I thought we already discussed this in
previous versions of this patch.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V7] ARM: mx6: Add support for Kosagi Novena
On Fri, Oct 10, 2014 at 10:14 PM, Marek Vasut ma...@denx.de wrote: +/* PCI express */ +#undef CONFIG_CMD_PCI /* Disable to prevent Linux from hanging on MX6 */ This has been fixed recently by this commit: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/pci/host/pci-imx6.c?id=3e3e406e3807235906ee0b7c697664ea6dfd88de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V7] ARM: mx6: Add support for Kosagi Novena
Hi Fabio,
On 10/11/2014 04:39 AM, Fabio Estevam wrote:
Hi Marek,
On Fri, Oct 10, 2014 at 10:14 PM, Marek Vasut ma...@denx.de wrote:
+int board_early_init_f(void)
+{
+#if defined(CONFIG_VIDEO_IPUV3)
+ setup_display();
+#endif
+
+ /* Bring Ethernet PHY out of reset. */
+ gpio_set_value(IMX_GPIO_NR(3, 23), 1);
No delay needed here prior to setting it to 1?
We had some discussions about the PHY reset sequence and timing, but
still not a common opinion, so I suggested to leave this fix for a
consequent patch.
Regards,
Nikolay
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V7] ARM: mx6: Add support for Kosagi Novena
Hi Marek,
On 10/11/2014 04:14 AM, Marek Vasut wrote:
Add support for the Kosagi Novena board. Currently supported are:
- I2C busses
- FEC Ethernet
- MMC0, MMC1, Booting from MMC
- SATA
- USB ports
- USB Ethernet
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Stefano Babic sba...@denx.de
Cc: Sean Cross x...@kosagi.com
Cc: Nikolay Dimitrov picmas...@mail.bg
---
arch/arm/Kconfig | 4 +
board/kosagi/novena/Kconfig | 18 ++
board/kosagi/novena/Makefile | 11 +
board/kosagi/novena/novena.c | 343
board/kosagi/novena/novena_spl.c | 556 +++
board/kosagi/novena/setup.cfg| 47
configs/novena_defconfig | 4 +
include/configs/imx6_spl.h | 2 +-
include/configs/novena.h | 302 +
9 files changed, 1286 insertions(+), 1 deletion(-)
create mode 100644 board/kosagi/novena/Kconfig
create mode 100644 board/kosagi/novena/Makefile
create mode 100644 board/kosagi/novena/novena.c
create mode 100644 board/kosagi/novena/novena_spl.c
create mode 100644 board/kosagi/novena/setup.cfg
create mode 100644 configs/novena_defconfig
create mode 100644 include/configs/novena.h
V2: - Drop the tegra_keyboard_init() comment altogether
- Immediatelly return from the SD controller probe function on failure
- Rename PFUZE100_PMIC to just PFUZE100
- Fix the IMX OTP support with CMD_FUSE
- Enabling LVDS clock is still in place, since this is coming soon.
V3: - Zap rootpath builtin env
V4: - Zap the checkpatch issues
- Update comments
V5: - Don't configure VGEN1
- Set FPGA into reset in SPL
- Drop ECSPI1 and add ECSPI3 mux
- Drop UART1 and add UART3, UART4 muxes
- Add separate mux option for the RGMII pins which doesn't set SPEED field
- Move the configuration of RGMII after they were configured in GPIO mode
V6: - Drop 'string' prop from Kconfig
- Zap uSD card detect
- Add bigSD write-protect detection
- Zap USB hub reset GPIO
V7: - Zap USB hub reset GPIO configuration
- Remove unnecessary zeroing of GD in SPL
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 106aed9..4da1923 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -411,6 +411,9 @@ config TARGET_GW_VENTANA
config TARGET_HUMMINGBOARD
bool Support hummingboard
+config TARGET_KOSAGI_NOVENA
+ bool Support Kosagi Novena
+
config TARGET_TQMA6
bool TQ Systems TQMa6 board
@@ -637,6 +640,7 @@ source board/imx31_phycore/Kconfig
source board/isee/igep0033/Kconfig
source board/jornada/Kconfig
source board/karo/tx25/Kconfig
+source board/kosagi/novena/Kconfig
source board/logicpd/imx27lite/Kconfig
source board/logicpd/imx31_litekit/Kconfig
source board/mpl/vcma9/Kconfig
diff --git a/board/kosagi/novena/Kconfig b/board/kosagi/novena/Kconfig
new file mode 100644
index 000..4ba6399
--- /dev/null
+++ b/board/kosagi/novena/Kconfig
@@ -0,0 +1,18 @@
+if TARGET_KOSAGI_NOVENA
+
+config SYS_CPU
+ default armv7
+
+config SYS_BOARD
+ default novena
+
+config SYS_VENDOR
+ default kosagi
+
+config SYS_SOC
+ default mx6
+
+config SYS_CONFIG_NAME
+ default novena
+
+endif
diff --git a/board/kosagi/novena/Makefile b/board/kosagi/novena/Makefile
new file mode 100644
index 000..6fba177
--- /dev/null
+++ b/board/kosagi/novena/Makefile
@@ -0,0 +1,11 @@
+#
+# Copyright (C) 2014 Marek Vasut ma...@denx.de
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+ifdef CONFIG_SPL_BUILD
+obj-y := novena_spl.o
+else
+obj-y := novena.o
+endif
diff --git a/board/kosagi/novena/novena.c b/board/kosagi/novena/novena.c
new file mode 100644
index 000..2361a3c
--- /dev/null
+++ b/board/kosagi/novena/novena.c
@@ -0,0 +1,343 @@
+/*
+ * Novena board support
+ *
+ * Copyright (C) 2014 Marek Vasut ma...@denx.de
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include asm/errno.h
+#include asm/gpio.h
+#include asm/io.h
+#include asm/arch/clock.h
+#include asm/arch/crm_regs.h
+#include asm/arch/imx-regs.h
+#include asm/arch/iomux.h
+#include asm/arch/mxc_hdmi.h
+#include asm/arch/sys_proto.h
+#include asm/imx-common/boot_mode.h
+#include asm/imx-common/iomux-v3.h
+#include asm/imx-common/mxc_i2c.h
+#include asm/imx-common/sata.h
+#include asm/imx-common/video.h
+#include fsl_esdhc.h
+#include i2c.h
+#include input.h
+#include ipu_pixfmt.h
+#include linux/fb.h
+#include linux/input.h
+#include malloc.h
+#include micrel.h
+#include miiphy.h
+#include mmc.h
+#include netdev.h
+#include power/pmic.h
+#include power/pfuze100_pmic.h
+#include stdio_dev.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define NOVENA_BUTTON_GPIO IMX_GPIO_NR(4, 14)
+#define NOVENA_SD_WP IMX_GPIO_NR(1, 2)
+#define NOVENA_SD_CD IMX_GPIO_NR(1, 4)
+
+/*
+ * GPIO button
+ */
+#ifdef CONFIG_KEYBOARD
+static struct input_config button_input;
+
+static int novena_gpio_button_read_keys(struct input_config *input)
+{
