[U-Boot] [PATCH 0/10] mx23/mxs pending patches
This patchset includes the pending patches we have in our tree. It fixes issues for mx23evk and mx23_olinuxino boards.
Otavio Salvador (10): mxs: Rename CONFIG_SPL_MX28_PSWITCH_WAIT to CONFIG_SPL_MXS_PSWITCH_WAIT mx23: Document the tRAS lockout setting in memory initialization mx23evk: Adjust DRAM control register to use full 128MB of RAM led: Use STATUS_LED_ON and STATUS_LED_OFF when calling __led_set mxs: Fix iomux.h to not break build during assembly stage mx23_olinuxino: Add support for status LED usb: mxs: Disable USB Port 1 for i.MX23 mx23evk: Enable USB support mx23_olinuxino: Enable USB support mx23_olinuxino: Add ethernet support
arch/arm/cpu/arm926ejs/mxs/mxs_init.h | 2 +- arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 1 + arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 2 +- arch/arm/include/asm/arch-mxs/iomux.h | 5 +++ board/freescale/mx23evk/spl_boot.c | 10 +++++ board/olimex/mx23_olinuxino/mx23_olinuxino.c | 13 ++++++ board/olimex/mx23_olinuxino/spl_boot.c | 8 ++++ common/cmd_led.c | 6 ++- drivers/usb/host/ehci-mxs.c | 2 + include/configs/mx23_olinuxino.h | 62 ++++++++++++++++++++++++++-- include/configs/mx23evk.h | 10 +++++ 11 files changed, 114 insertions(+), 7 deletions(-)
The power switch option is compatible with i.MX23 and i.MX28 so the configration option needs to reflect it. We choose 'CONFIG_SPL_MXS_PSWITCH_WAIT' for the option name.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br --- arch/arm/cpu/arm926ejs/mxs/mxs_init.h | 2 +- arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/mxs_init.h b/arch/arm/cpu/arm926ejs/mxs/mxs_init.h index 2ddc5bc..084def5 100644 --- a/arch/arm/cpu/arm926ejs/mxs/mxs_init.h +++ b/arch/arm/cpu/arm926ejs/mxs/mxs_init.h @@ -30,7 +30,7 @@ void early_delay(int delay);
void mxs_power_init(void);
-#ifdef CONFIG_SPL_MX28_PSWITCH_WAIT +#ifdef CONFIG_SPL_MXS_PSWITCH_WAIT void mxs_power_wait_pswitch(void); #else static inline void mxs_power_wait_pswitch(void) { } diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c index e9d6302..287c698 100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c +++ b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c @@ -921,7 +921,7 @@ void mxs_power_init(void) early_delay(1000); }
-#ifdef CONFIG_SPL_MX28_PSWITCH_WAIT +#ifdef CONFIG_SPL_MXS_PSWITCH_WAIT void mxs_power_wait_pswitch(void) { struct mxs_power_regs *power_regs =
Dear Otavio Salvador,
The power switch option is compatible with i.MX23 and i.MX28 so the configration option needs to reflect it. We choose 'CONFIG_SPL_MXS_PSWITCH_WAIT' for the option name.
Acked-by: Marek Vasut marex@denx.de
I'm missing cover letter for this large series.
Best regards, Marek Vasut
On Wed, Jan 30, 2013 at 12:11 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
The power switch option is compatible with i.MX23 and i.MX28 so the configration option needs to reflect it. We choose 'CONFIG_SPL_MXS_PSWITCH_WAIT' for the option name.
Acked-by: Marek Vasut marex@denx.de
I'm missing cover letter for this large series.
Hum, patman seems to be doing something wrong here. It should copy the cover to all Cced people I think. Simon?
-- Otavio Salvador O.S. Systems E-mail: otavio@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
Him
On Wed, Jan 30, 2013 at 7:29 AM, Otavio Salvador otavio@ossystems.com.br wrote:
On Wed, Jan 30, 2013 at 12:11 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
The power switch option is compatible with i.MX23 and i.MX28 so the configration option needs to reflect it. We choose 'CONFIG_SPL_MXS_PSWITCH_WAIT' for the option name.
Acked-by: Marek Vasut marex@denx.de
I'm missing cover letter for this large series.
Hum, patman seems to be doing something wrong here. It should copy the cover to all Cced people I think. Simon?
Yes - there is a pull request up to bring those patches into mainline, after which it will do this.
http://patchwork.ozlabs.org/patch/217308/
Regards, Simon
-- Otavio Salvador O.S. Systems E-mail: otavio@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
Add a comment about the tRAS lockout setting of HW_DRAM_CTL08 to enable the 'Fast Auto Pre-Charge' found in the memory chip. The setting is applied after memory initialization and it is worth document it.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br --- arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index f8392f6..37b50e9 100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c @@ -119,6 +119,7 @@ static void initialize_dram_values(void) writel(dram_vals[i], MXS_DRAM_BASE + (4 * i));
#ifdef CONFIG_MX23 + /* Enable tRAS lockout in HW_DRAM_CTL08 */ writel((1 << 24), MXS_DRAM_BASE + (4 * 8)); #endif }
Dear Otavio Salvador,
Add a comment about the tRAS lockout setting of HW_DRAM_CTL08 to enable the 'Fast Auto Pre-Charge' found in the memory chip. The setting is applied after memory initialization and it is worth document it.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br
arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index f8392f6..37b50e9 100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c @@ -119,6 +119,7 @@ static void initialize_dram_values(void) writel(dram_vals[i], MXS_DRAM_BASE + (4 * i));
#ifdef CONFIG_MX23
- /* Enable tRAS lockout in HW_DRAM_CTL08 */
This does not explain why it must be here and not in the dram_vals table. It would be nice to explain it here, since it'd prevent others from sending patch stuffing it into the dram_vals table without knowing it must definitelly be here.
But why does it have to be here? I wonder ...
writel((1 << 24), MXS_DRAM_BASE + (4 * 8)); #endif }
Best regards, Marek Vasut
On Wed, Jan 30, 2013 at 12:10 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
Add a comment about the tRAS lockout setting of HW_DRAM_CTL08 to enable the 'Fast Auto Pre-Charge' found in the memory chip. The setting is applied after memory initialization and it is worth document it.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br
arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index f8392f6..37b50e9 100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c @@ -119,6 +119,7 @@ static void initialize_dram_values(void) writel(dram_vals[i], MXS_DRAM_BASE + (4 * i));
#ifdef CONFIG_MX23
/* Enable tRAS lockout in HW_DRAM_CTL08 */This does not explain why it must be here and not in the dram_vals table. It would be nice to explain it here, since it'd prevent others from sending patch stuffing it into the dram_vals table without knowing it must definitelly be here.
Ok; I will extend the comment.
But why does it have to be here? I wonder ...
Yes; I don't know as well. We may try to find it out in future but for now let's keep it as is.
Will change it for v2.
-- Otavio Salvador O.S. Systems E-mail: otavio@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
Adjust HW_DRAM_CTL14 to enable the chip selects to allow usage of full 128MB of RAM.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br --- board/freescale/mx23evk/spl_boot.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/board/freescale/mx23evk/spl_boot.c b/board/freescale/mx23evk/spl_boot.c index 6007433..b6f4e7e 100644 --- a/board/freescale/mx23evk/spl_boot.c +++ b/board/freescale/mx23evk/spl_boot.c @@ -98,6 +98,16 @@ const iomux_cfg_t iomux_setup[] = { (MXS_PAD_4MA | MXS_PAD_3V3 | MXS_PAD_NOPULL), };
+#define HW_DRAM_CTL14 (0x38 >> 2) +#define CS_MAP 0x3 +#define INTAREF 0x2 +#define HW_DRAM_CTL14_CONFIG (INTAREF << 8 | CS_MAP) + +void mxs_adjust_memory_params(uint32_t *dram_vals) +{ + dram_vals[HW_DRAM_CTL14] = HW_DRAM_CTL14_CONFIG; +} + void board_init_ll(void) { mxs_common_spl_init(iomux_setup, ARRAY_SIZE(iomux_setup));
Dear Otavio Salvador,
Adjust HW_DRAM_CTL14 to enable the chip selects to allow usage of full 128MB of RAM.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br
Just enable the full set for all in the generic memory register set (dram_vals)?
board/freescale/mx23evk/spl_boot.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/board/freescale/mx23evk/spl_boot.c b/board/freescale/mx23evk/spl_boot.c index 6007433..b6f4e7e 100644 --- a/board/freescale/mx23evk/spl_boot.c +++ b/board/freescale/mx23evk/spl_boot.c @@ -98,6 +98,16 @@ const iomux_cfg_t iomux_setup[] = { (MXS_PAD_4MA | MXS_PAD_3V3 | MXS_PAD_NOPULL), };
+#define HW_DRAM_CTL14 (0x38 >> 2) +#define CS_MAP 0x3 +#define INTAREF 0x2 +#define HW_DRAM_CTL14_CONFIG (INTAREF << 8 | CS_MAP)
+void mxs_adjust_memory_params(uint32_t *dram_vals) +{
- dram_vals[HW_DRAM_CTL14] = HW_DRAM_CTL14_CONFIG;
+}
void board_init_ll(void) { mxs_common_spl_init(iomux_setup, ARRAY_SIZE(iomux_setup));
Best regards, Marek Vasut
On Wed, Jan 30, 2013 at 12:12 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
Adjust HW_DRAM_CTL14 to enable the chip selects to allow usage of full 128MB of RAM.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br
Just enable the full set for all in the generic memory register set (dram_vals)?
Per datasheet description it shouldn't be done for LQFP; so the safest setting is to the default we're using as it will work for new boards and the chip select can be adjusted when need.
board/freescale/mx23evk/spl_boot.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/board/freescale/mx23evk/spl_boot.c b/board/freescale/mx23evk/spl_boot.c index 6007433..b6f4e7e 100644 --- a/board/freescale/mx23evk/spl_boot.c +++ b/board/freescale/mx23evk/spl_boot.c @@ -98,6 +98,16 @@ const iomux_cfg_t iomux_setup[] = { (MXS_PAD_4MA | MXS_PAD_3V3 | MXS_PAD_NOPULL), };
+#define HW_DRAM_CTL14 (0x38 >> 2) +#define CS_MAP 0x3 +#define INTAREF 0x2 +#define HW_DRAM_CTL14_CONFIG (INTAREF << 8 | CS_MAP)
+void mxs_adjust_memory_params(uint32_t *dram_vals) +{
dram_vals[HW_DRAM_CTL14] = HW_DRAM_CTL14_CONFIG;+}
void board_init_ll(void) { mxs_common_spl_init(iomux_setup, ARRAY_SIZE(iomux_setup));
Best regards, Marek Vasut
-- Otavio Salvador O.S. Systems E-mail: otavio@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
Dear Otavio Salvador,
On Wed, Jan 30, 2013 at 12:12 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
Adjust HW_DRAM_CTL14 to enable the chip selects to allow usage of full 128MB of RAM.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br
Just enable the full set for all in the generic memory register set (dram_vals)?
Per datasheet description it shouldn't be done for LQFP;
LQFP package is missing pinmux for the other pins, so that's ok.
so the safest setting is to the default we're using as it will work for new boards and the chip select can be adjusted when need.
And since the block inside the CPU is the same, just missing the pinmux, it is also safe to enable all CS lines for default operation.
board/freescale/mx23evk/spl_boot.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/board/freescale/mx23evk/spl_boot.c b/board/freescale/mx23evk/spl_boot.c index 6007433..b6f4e7e 100644 --- a/board/freescale/mx23evk/spl_boot.c +++ b/board/freescale/mx23evk/spl_boot.c @@ -98,6 +98,16 @@ const iomux_cfg_t iomux_setup[] = {
(MXS_PAD_4MA | MXS_PAD_3V3 | MXS_PAD_NOPULL),};
+#define HW_DRAM_CTL14 (0x38 >> 2) +#define CS_MAP 0x3 +#define INTAREF 0x2 +#define HW_DRAM_CTL14_CONFIG (INTAREF << 8 | CS_MAP)
+void mxs_adjust_memory_params(uint32_t *dram_vals) +{
dram_vals[HW_DRAM_CTL14] = HW_DRAM_CTL14_CONFIG;+}
void board_init_ll(void) {
mxs_common_spl_init(iomux_setup, ARRAY_SIZE(iomux_setup));Best regards, Marek Vasut
-- Otavio Salvador O.S. Systems E-mail: otavio@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
Best regards, Marek Vasut
On Wed, Jan 30, 2013 at 1:38 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
On Wed, Jan 30, 2013 at 12:12 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
Adjust HW_DRAM_CTL14 to enable the chip selects to allow usage of full 128MB of RAM.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br
Just enable the full set for all in the generic memory register set (dram_vals)?
Per datasheet description it shouldn't be done for LQFP;
LQFP package is missing pinmux for the other pins, so that's ok.
so the safest setting is to the default we're using as it will work for new boards and the chip select can be adjusted when need.
And since the block inside the CPU is the same, just missing the pinmux, it is also safe to enable all CS lines for default operation.
If this is the case why they added the CS selector? The datasheet is clear about the different setting in BGA and LQFP. I'd prefer if someone from Freescale could check if it would be safe to enable them all or not. Fabio? :-)
-- Otavio Salvador O.S. Systems E-mail: otavio@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
Dear Otavio Salvador,
On Wed, Jan 30, 2013 at 1:38 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
On Wed, Jan 30, 2013 at 12:12 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
Adjust HW_DRAM_CTL14 to enable the chip selects to allow usage of full 128MB of RAM.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br
Just enable the full set for all in the generic memory register set (dram_vals)?
Per datasheet description it shouldn't be done for LQFP;
LQFP package is missing pinmux for the other pins, so that's ok.
so the safest setting is to the default we're using as it will work for new boards and the chip select can be adjusted when need.
And since the block inside the CPU is the same, just missing the pinmux, it is also safe to enable all CS lines for default operation.
If this is the case why they added the CS selector?
CS selector?
The datasheet is clear about the different setting in BGA and LQFP.
It'd be nice if you gave a ref. into the datasheet where I can find such information.
I'd prefer if someone from Freescale could check if it would be safe to enable them all or not. Fabio? :-)
According to table 12-36 and 37.4 , EMI has two CE lines max (CE0N and CE1N). If CE1 is not present on the smaller package, it's not a problem, since whenever asserted, the MUX won't let the signal go further. Moreover, the CE line is asserted only when particular memory area is accessed.
Thus, CS_MAP shall be 0x3 in default setup.
btw. this patch is misconfiguring INTAREF field which is not documented in the commit message.
Best regards, Marek Vasut
On Wed, Jan 30, 2013 at 1:55 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
On Wed, Jan 30, 2013 at 1:38 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
On Wed, Jan 30, 2013 at 12:12 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
Adjust HW_DRAM_CTL14 to enable the chip selects to allow usage of full 128MB of RAM.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br
Just enable the full set for all in the generic memory register set (dram_vals)?
Per datasheet description it shouldn't be done for LQFP;
LQFP package is missing pinmux for the other pins, so that's ok.
so the safest setting is to the default we're using as it will work for new boards and the chip select can be adjusted when need.
And since the block inside the CPU is the same, just missing the pinmux, it is also safe to enable all CS lines for default operation.
If this is the case why they added the CS selector?
CS selector?
The datasheet is clear about the different setting in BGA and LQFP.
It'd be nice if you gave a ref. into the datasheet where I can find such information.
I'd prefer if someone from Freescale could check if it would be safe to enable them all or not. Fabio? :-)
According to table 12-36 and 37.4 , EMI has two CE lines max (CE0N and CE1N). If CE1 is not present on the smaller package, it's not a problem, since whenever asserted, the MUX won't let the signal go further. Moreover, the CE line is asserted only when particular memory area is accessed.
Thus, CS_MAP shall be 0x3 in default setup.
btw. this patch is misconfiguring INTAREF field which is not documented in the commit message.
It is not changing the value of it but setting to the same used in default setup. So I did not include it in commit log.
I will give it a test in mx23_olinuxino and then if it does work fine I do the change for v2.
-- Otavio Salvador O.S. Systems E-mail: otavio@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
This fixes the gpio_led driver which needs to compare againt a STATUS_LED_ON to enable a led.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br --- common/cmd_led.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/common/cmd_led.c b/common/cmd_led.c index 7f5ab43..84f79fa 100644 --- a/common/cmd_led.c +++ b/common/cmd_led.c @@ -110,13 +110,15 @@ int do_led (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) if (led_commands[i].on) led_commands[i].on(); else - __led_set(led_commands[i].mask, 1); + __led_set(led_commands[i].mask, + STATUS_LED_ON); break; case LED_OFF: if (led_commands[i].off) led_commands[i].off(); else - __led_set(led_commands[i].mask, 0); + __led_set(led_commands[i].mask, + STATUS_LED_OFF); break; case LED_TOGGLE: if (led_commands[i].toggle)
This fixes the build failure when included in mx23_olinuxino.h board config; the addition of "asm/types.h" is due "u32" being otherwise undefined.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br --- arch/arm/include/asm/arch-mxs/iomux.h | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/arch/arm/include/asm/arch-mxs/iomux.h b/arch/arm/include/asm/arch-mxs/iomux.h index 7abdf58..4288715 100644 --- a/arch/arm/include/asm/arch-mxs/iomux.h +++ b/arch/arm/include/asm/arch-mxs/iomux.h @@ -21,6 +21,10 @@ #ifndef __MACH_MXS_IOMUX_H__ #define __MACH_MXS_IOMUX_H__
+#ifndef __ASSEMBLY__ + +#include <asm/types.h> + /* * IOMUX/PAD Bit field definitions * @@ -165,4 +169,5 @@ int mxs_iomux_setup_pad(iomux_cfg_t pad); */ int mxs_iomux_setup_multiple_pads(const iomux_cfg_t *pad_list, unsigned count);
+#endif /* __ASSEMBLY__ */ #endif /* __MACH_MXS_IOMUX_H__*/
On Wed, Jan 30, 2013 at 10:13 AM, Otavio Salvador otavio@ossystems.com.br wrote:
This fixes the build failure when included in mx23_olinuxino.h board
Which build failure? Can you post the error?
I think you can drop this patch from the series now that you do not pass the iomux definitions in patch 6/10.
On Wed, Jan 30, 2013 at 10:24 AM, Fabio Estevam festevam@gmail.com wrote:
On Wed, Jan 30, 2013 at 10:13 AM, Otavio Salvador otavio@ossystems.com.br wrote:
This fixes the build failure when included in mx23_olinuxino.h board
Which build failure? Can you post the error?
I think you can drop this patch from the series now that you do not pass the iomux definitions in patch 6/10.
Yes; we do not use this anymore.
Without this patch it fails badly as it try to use the functions in assembly. This fixes it anyway so I think it could go in anyway so if someone needs it in mx23evk or mx23_olinuxino board files it won't fail to build anymore.
-- Otavio Salvador O.S. Systems E-mail: otavio@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
This allow user to know if the bootloader is running, even without a serial console.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br --- board/olimex/mx23_olinuxino/mx23_olinuxino.c | 7 +++++++ board/olimex/mx23_olinuxino/spl_boot.c | 4 ++++ include/configs/mx23_olinuxino.h | 12 ++++++++++++ 3 files changed, 23 insertions(+)
diff --git a/board/olimex/mx23_olinuxino/mx23_olinuxino.c b/board/olimex/mx23_olinuxino/mx23_olinuxino.c index 6a6053b..2501417 100644 --- a/board/olimex/mx23_olinuxino/mx23_olinuxino.c +++ b/board/olimex/mx23_olinuxino/mx23_olinuxino.c @@ -28,6 +28,9 @@ #include <asm/arch/imx-regs.h> #include <asm/arch/clock.h> #include <asm/arch/sys_proto.h> +#ifdef CONFIG_STATUS_LED +#include <status_led.h> +#endif
DECLARE_GLOBAL_DATA_PTR;
@@ -67,5 +70,9 @@ int board_init(void) /* Adress of boot parameters */ gd->bd->bi_boot_params = PHYS_SDRAM_1 + 0x100;
+#if defined(CONFIG_STATUS_LED) && defined(STATUS_LED_BOOT) + status_led_set(STATUS_LED_BOOT, STATUS_LED_STATE); +#endif + return 0; } diff --git a/board/olimex/mx23_olinuxino/spl_boot.c b/board/olimex/mx23_olinuxino/spl_boot.c index 7def8bc..3bbf5ad 100644 --- a/board/olimex/mx23_olinuxino/spl_boot.c +++ b/board/olimex/mx23_olinuxino/spl_boot.c @@ -84,6 +84,10 @@ const iomux_cfg_t iomux_setup[] = { MX23_PAD_EMI_RASN__EMI_RASN | MUX_CONFIG_EMI, MX23_PAD_EMI_WEN__EMI_WEN | MUX_CONFIG_EMI,
+ /* Green LED */ + MX23_PAD_SSP1_DETECT__GPIO_2_1 | + (MXS_PAD_3V3 | MXS_PAD_4MA | MXS_PAD_NOPULL), + /* MMC 0 */ MX23_PAD_SSP1_CMD__SSP1_CMD | MUX_CONFIG_SSP, MX23_PAD_SSP1_DATA0__SSP1_DATA0 | MUX_CONFIG_SSP, diff --git a/include/configs/mx23_olinuxino.h b/include/configs/mx23_olinuxino.h index 7983c5d..968aec8 100644 --- a/include/configs/mx23_olinuxino.h +++ b/include/configs/mx23_olinuxino.h @@ -56,6 +56,7 @@ #define CONFIG_CMD_EXT2 #define CONFIG_CMD_FAT #define CONFIG_CMD_GPIO +#define CONFIG_CMD_LED #define CONFIG_CMD_MMC
/* @@ -112,6 +113,17 @@ #define CONFIG_BAUDRATE 115200 /* Default baud rate */
/* + * Status LED + */ +#define CONFIG_STATUS_LED +#define CONFIG_GPIO_LED +#define CONFIG_BOARD_SPECIFIC_LED +#define STATUS_LED_BOOT 0 +#define STATUS_LED_BIT 10 +#define STATUS_LED_STATE STATUS_LED_ON +#define STATUS_LED_PERIOD (CONFIG_SYS_HZ / 2) + +/* * MMC Driver */ #ifdef CONFIG_CMD_MMC
Dear Otavio Salvador,
This allow user to know if the bootloader is running, even without a serial console.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br
Uh oh, how does this know which GPIO to toggle to drive the led this time ?
board/olimex/mx23_olinuxino/mx23_olinuxino.c | 7 +++++++ board/olimex/mx23_olinuxino/spl_boot.c | 4 ++++ include/configs/mx23_olinuxino.h | 12 ++++++++++++ 3 files changed, 23 insertions(+)
diff --git a/board/olimex/mx23_olinuxino/mx23_olinuxino.c b/board/olimex/mx23_olinuxino/mx23_olinuxino.c index 6a6053b..2501417 100644 --- a/board/olimex/mx23_olinuxino/mx23_olinuxino.c +++ b/board/olimex/mx23_olinuxino/mx23_olinuxino.c @@ -28,6 +28,9 @@ #include <asm/arch/imx-regs.h> #include <asm/arch/clock.h> #include <asm/arch/sys_proto.h> +#ifdef CONFIG_STATUS_LED +#include <status_led.h> +#endif
DECLARE_GLOBAL_DATA_PTR;
@@ -67,5 +70,9 @@ int board_init(void) /* Adress of boot parameters */ gd->bd->bi_boot_params = PHYS_SDRAM_1 + 0x100;
+#if defined(CONFIG_STATUS_LED) && defined(STATUS_LED_BOOT)
- status_led_set(STATUS_LED_BOOT, STATUS_LED_STATE);
+#endif
- return 0;
} diff --git a/board/olimex/mx23_olinuxino/spl_boot.c b/board/olimex/mx23_olinuxino/spl_boot.c index 7def8bc..3bbf5ad 100644 --- a/board/olimex/mx23_olinuxino/spl_boot.c +++ b/board/olimex/mx23_olinuxino/spl_boot.c @@ -84,6 +84,10 @@ const iomux_cfg_t iomux_setup[] = { MX23_PAD_EMI_RASN__EMI_RASN | MUX_CONFIG_EMI, MX23_PAD_EMI_WEN__EMI_WEN | MUX_CONFIG_EMI,
- /* Green LED */
- MX23_PAD_SSP1_DETECT__GPIO_2_1 |
(MXS_PAD_3V3 | MXS_PAD_4MA | MXS_PAD_NOPULL),- /* MMC 0 */ MX23_PAD_SSP1_CMD__SSP1_CMD | MUX_CONFIG_SSP, MX23_PAD_SSP1_DATA0__SSP1_DATA0 | MUX_CONFIG_SSP,
diff --git a/include/configs/mx23_olinuxino.h b/include/configs/mx23_olinuxino.h index 7983c5d..968aec8 100644 --- a/include/configs/mx23_olinuxino.h +++ b/include/configs/mx23_olinuxino.h @@ -56,6 +56,7 @@ #define CONFIG_CMD_EXT2 #define CONFIG_CMD_FAT #define CONFIG_CMD_GPIO +#define CONFIG_CMD_LED #define CONFIG_CMD_MMC
/* @@ -112,6 +113,17 @@ #define CONFIG_BAUDRATE 115200 /* Default baud rate */
/*
- Status LED
- */
+#define CONFIG_STATUS_LED +#define CONFIG_GPIO_LED +#define CONFIG_BOARD_SPECIFIC_LED +#define STATUS_LED_BOOT 0 +#define STATUS_LED_BIT 10 +#define STATUS_LED_STATE STATUS_LED_ON +#define STATUS_LED_PERIOD (CONFIG_SYS_HZ / 2)
+/*
- MMC Driver
*/ #ifdef CONFIG_CMD_MMC
Best regards, Marek Vasut
On Wed, Jan 30, 2013 at 12:13 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
This allow user to know if the bootloader is running, even without a serial console.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br
Uh oh, how does this know which GPIO to toggle to drive the led this time ?
The problem wasn't the code but me. I wasn't able to find the right GPIO number at that time.
-- Otavio Salvador O.S. Systems E-mail: otavio@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
Dear Otavio Salvador,
On Wed, Jan 30, 2013 at 12:13 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
This allow user to know if the bootloader is running, even without a serial console.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br
Uh oh, how does this know which GPIO to toggle to drive the led this time ?
The problem wasn't the code but me. I wasn't able to find the right GPIO number at that time.
This is not my question. My question is how does this toggle the GPIO for the LED?
Moreover, you never set the LED GPIO as output.
Best regards, Marek Vasut
On Wed, Jan 30, 2013 at 1:39 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
On Wed, Jan 30, 2013 at 12:13 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
This allow user to know if the bootloader is running, even without a serial console.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br
Uh oh, how does this know which GPIO to toggle to drive the led this time ?
The problem wasn't the code but me. I wasn't able to find the right GPIO number at that time.
This is not my question. My question is how does this toggle the GPIO for the LED?
gpio_led driver (drivers/misc/gpio_led.c) does it.
... void __led_init(led_id_t mask, int state) { gpio_request(mask, "gpio_led"); gpio_direction_output(mask, state == STATUS_LED_ON); }
void __led_set(led_id_t mask, int state) { gpio_set_value(mask, state == STATUS_LED_ON); } ...
Moreover, you never set the LED GPIO as output.
The driver handles it by itself.
See above.
-- Otavio Salvador O.S. Systems E-mail: otavio@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
Dear Otavio Salvador,
On Wed, Jan 30, 2013 at 1:39 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
On Wed, Jan 30, 2013 at 12:13 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
This allow user to know if the bootloader is running, even without a serial console.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br
Uh oh, how does this know which GPIO to toggle to drive the led this time ?
The problem wasn't the code but me. I wasn't able to find the right GPIO number at that time.
This is not my question. My question is how does this toggle the GPIO for the LED?
gpio_led driver (drivers/misc/gpio_led.c) does it.
... void __led_init(led_id_t mask, int state) { gpio_request(mask, "gpio_led"); gpio_direction_output(mask, state == STATUS_LED_ON); }
void __led_set(led_id_t mask, int state) { gpio_set_value(mask, state == STATUS_LED_ON); } ...
Ok, this didn't explain much to me.
Moreover, you never set the LED GPIO as output.
The driver handles it by itself.
Oh ok.
Now that I did read through the code, I have few more questions:
Why can't STATUS_LED_BIT be the MX23_PAD_SSP1_DETECT__GPIO_2_1 now? Did you test CMD_LED, does it work when toggling the LED?
Best regards, Marek Vasut
On Wed, Jan 30, 2013 at 2:05 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
On Wed, Jan 30, 2013 at 1:39 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
On Wed, Jan 30, 2013 at 12:13 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
This allow user to know if the bootloader is running, even without a serial console.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br
Uh oh, how does this know which GPIO to toggle to drive the led this time ?
The problem wasn't the code but me. I wasn't able to find the right GPIO number at that time.
This is not my question. My question is how does this toggle the GPIO for the LED?
gpio_led driver (drivers/misc/gpio_led.c) does it.
... void __led_init(led_id_t mask, int state) { gpio_request(mask, "gpio_led"); gpio_direction_output(mask, state == STATUS_LED_ON); }
void __led_set(led_id_t mask, int state) { gpio_set_value(mask, state == STATUS_LED_ON); } ...
Ok, this didn't explain much to me.
Moreover, you never set the LED GPIO as output.
The driver handles it by itself.
Oh ok.
Now that I did read through the code, I have few more questions:
Why can't STATUS_LED_BIT be the MX23_PAD_SSP1_DETECT__GPIO_2_1 now?
It can but than we need to include the iomux-mx23.h header. It in the end is the same thing.
Did you test CMD_LED, does it work when toggling the LED?
It does. Of course I tested it :)
-- Otavio Salvador O.S. Systems E-mail: otavio@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
Dear Otavio Salvador,
On Wed, Jan 30, 2013 at 2:05 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
On Wed, Jan 30, 2013 at 1:39 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
On Wed, Jan 30, 2013 at 12:13 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
> This allow user to know if the bootloader is running, even without > a serial console. > > Signed-off-by: Otavio Salvador otavio@ossystems.com.br
Uh oh, how does this know which GPIO to toggle to drive the led this time ?
The problem wasn't the code but me. I wasn't able to find the right GPIO number at that time.
This is not my question. My question is how does this toggle the GPIO for the LED?
gpio_led driver (drivers/misc/gpio_led.c) does it.
... void __led_init(led_id_t mask, int state) {
gpio_request(mask, "gpio_led"); gpio_direction_output(mask, state == STATUS_LED_ON);}
void __led_set(led_id_t mask, int state) {
gpio_set_value(mask, state == STATUS_LED_ON);} ...
Ok, this didn't explain much to me.
Moreover, you never set the LED GPIO as output.
The driver handles it by itself.
Oh ok.
Now that I did read through the code, I have few more questions:
Why can't STATUS_LED_BIT be the MX23_PAD_SSP1_DETECT__GPIO_2_1 now?
It can but than we need to include the iomux-mx23.h header. It in the end is the same thing.
In the end, when I read the code in two hours, I'll be wondering what this magic junk is. Thus, we will go for this and apply the adjustment for iomux.
Best regards, Marek Vasut
On Wed, Jan 30, 2013 at 2:15 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
On Wed, Jan 30, 2013 at 2:05 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
On Wed, Jan 30, 2013 at 1:39 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
On Wed, Jan 30, 2013 at 12:13 PM, Marek Vasut marex@denx.de wrote: > Dear Otavio Salvador, > >> This allow user to know if the bootloader is running, even without >> a serial console. >> >> Signed-off-by: Otavio Salvador otavio@ossystems.com.br > > Uh oh, how does this know which GPIO to toggle to drive the led > this time ?
The problem wasn't the code but me. I wasn't able to find the right GPIO number at that time.
This is not my question. My question is how does this toggle the GPIO for the LED?
gpio_led driver (drivers/misc/gpio_led.c) does it.
... void __led_init(led_id_t mask, int state) {
gpio_request(mask, "gpio_led"); gpio_direction_output(mask, state == STATUS_LED_ON);}
void __led_set(led_id_t mask, int state) {
gpio_set_value(mask, state == STATUS_LED_ON);} ...
Ok, this didn't explain much to me.
Moreover, you never set the LED GPIO as output.
The driver handles it by itself.
Oh ok.
Now that I did read through the code, I have few more questions:
Why can't STATUS_LED_BIT be the MX23_PAD_SSP1_DETECT__GPIO_2_1 now?
It can but than we need to include the iomux-mx23.h header. It in the end is the same thing.
In the end, when I read the code in two hours, I'll be wondering what this magic junk is. Thus, we will go for this and apply the adjustment for iomux.
So in the end you prefer me to use the MUX name? I am fine in doing it for v2.
-- Otavio Salvador O.S. Systems E-mail: otavio@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
Dear Otavio Salvador,
On Wed, Jan 30, 2013 at 2:15 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
On Wed, Jan 30, 2013 at 2:05 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
On Wed, Jan 30, 2013 at 1:39 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
> On Wed, Jan 30, 2013 at 12:13 PM, Marek Vasut marex@denx.de wrote: > > Dear Otavio Salvador, > > > >> This allow user to know if the bootloader is running, even > >> without a serial console. > >> > >> Signed-off-by: Otavio Salvador otavio@ossystems.com.br > > > > Uh oh, how does this know which GPIO to toggle to drive the led > > this time ? > > The problem wasn't the code but me. I wasn't able to find the > right GPIO number at that time.
This is not my question. My question is how does this toggle the GPIO for the LED?
gpio_led driver (drivers/misc/gpio_led.c) does it.
... void __led_init(led_id_t mask, int state) {
gpio_request(mask, "gpio_led"); gpio_direction_output(mask, state == STATUS_LED_ON);}
void __led_set(led_id_t mask, int state) {
gpio_set_value(mask, state == STATUS_LED_ON);} ...
Ok, this didn't explain much to me.
Moreover, you never set the LED GPIO as output.
The driver handles it by itself.
Oh ok.
Now that I did read through the code, I have few more questions:
Why can't STATUS_LED_BIT be the MX23_PAD_SSP1_DETECT__GPIO_2_1 now?
It can but than we need to include the iomux-mx23.h header. It in the end is the same thing.
In the end, when I read the code in two hours, I'll be wondering what this magic junk is. Thus, we will go for this and apply the adjustment for iomux.
So in the end you prefer me to use the MUX name? I am fine in doing it for v2.
Yes, for my part, I'd prefer to use the mux name.
Best regards, Marek Vasut
The i.MX23 just one USB port so disable the second controller probe when building for i.MX23.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br --- drivers/usb/host/ehci-mxs.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/usb/host/ehci-mxs.c b/drivers/usb/host/ehci-mxs.c index 5062af5..28c8cde 100644 --- a/drivers/usb/host/ehci-mxs.c +++ b/drivers/usb/host/ehci-mxs.c @@ -50,10 +50,12 @@ int mxs_ehci_get_port(struct ehci_mxs *mxs_usb, int port) usb_base = MXS_USBCTRL0_BASE; phy_base = MXS_USBPHY0_BASE; break; +#ifdef CONFIG_MX28 case 1: usb_base = MXS_USBCTRL1_BASE; phy_base = MXS_USBPHY1_BASE; break; +#endif default: printf("CONFIG_EHCI_MXS_PORT (port = %d)\n", port); return -1;
Dear Otavio Salvador,
The i.MX23 just one USB port so disable the second controller probe when building for i.MX23.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br
drivers/usb/host/ehci-mxs.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/usb/host/ehci-mxs.c b/drivers/usb/host/ehci-mxs.c index 5062af5..28c8cde 100644 --- a/drivers/usb/host/ehci-mxs.c +++ b/drivers/usb/host/ehci-mxs.c @@ -50,10 +50,12 @@ int mxs_ehci_get_port(struct ehci_mxs *mxs_usb, int port) usb_base = MXS_USBCTRL0_BASE; phy_base = MXS_USBPHY0_BASE; break; +#ifdef CONFIG_MX28 case 1: usb_base = MXS_USBCTRL1_BASE; phy_base = MXS_USBPHY1_BASE; break; +#endif default: printf("CONFIG_EHCI_MXS_PORT (port = %d)\n", port); return -1;
This is not enough.
For example this portion will do something undefined on mx23:
98 writel(HW_DIGCTL_CTRL_USB0_CLKGATE | HW_DIGCTL_CTRL_USB1_CLKGATE, 99 &digctl_ctrl->reg_clr);
THis ehci-mxs.c needs full review for mx23.
Best regards, Marek Vasut
On Wed, Jan 30, 2013 at 12:17 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
The i.MX23 just one USB port so disable the second controller probe when building for i.MX23.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br
drivers/usb/host/ehci-mxs.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/usb/host/ehci-mxs.c b/drivers/usb/host/ehci-mxs.c index 5062af5..28c8cde 100644 --- a/drivers/usb/host/ehci-mxs.c +++ b/drivers/usb/host/ehci-mxs.c @@ -50,10 +50,12 @@ int mxs_ehci_get_port(struct ehci_mxs *mxs_usb, int port) usb_base = MXS_USBCTRL0_BASE; phy_base = MXS_USBPHY0_BASE; break; +#ifdef CONFIG_MX28 case 1: usb_base = MXS_USBCTRL1_BASE; phy_base = MXS_USBPHY1_BASE; break; +#endif default: printf("CONFIG_EHCI_MXS_PORT (port = %d)\n", port); return -1;
This is not enough.
For example this portion will do something undefined on mx23:
98 writel(HW_DIGCTL_CTRL_USB0_CLKGATE | HW_DIGCTL_CTRL_USB1_CLKGATE, 99 &digctl_ctrl->reg_clr);
THis ehci-mxs.c needs full review for mx23.
Ok; I will handle it for v2.
-- Otavio Salvador O.S. Systems E-mail: otavio@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
This enabled USB support for the mx23evk board.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br --- include/configs/mx23evk.h | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/include/configs/mx23evk.h b/include/configs/mx23evk.h index c44a8b8..8db6283 100644 --- a/include/configs/mx23evk.h +++ b/include/configs/mx23evk.h @@ -60,6 +60,7 @@ #define CONFIG_CMD_FAT #define CONFIG_CMD_GPIO #define CONFIG_CMD_MMC +#define CONFIG_CMD_USB #define CONFIG_CMD_BOOTZ
/* Memory configurations */ @@ -125,6 +126,15 @@ #define CONFIG_MXS_MMC #endif
+/* USB */ +#ifdef CONFIG_CMD_USB +#define CONFIG_USB_EHCI +#define CONFIG_USB_EHCI_MXS +#define CONFIG_EHCI_MXS_PORT 0 +#define CONFIG_EHCI_IS_TDI +#define CONFIG_USB_STORAGE +#endif + /* Boot Linux */ #define CONFIG_CMDLINE_TAG #define CONFIG_SETUP_MEMORY_TAGS
This enabled USB support for the mx23_olinuxino board.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br --- include/configs/mx23_olinuxino.h | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/include/configs/mx23_olinuxino.h b/include/configs/mx23_olinuxino.h index 968aec8..7e17809 100644 --- a/include/configs/mx23_olinuxino.h +++ b/include/configs/mx23_olinuxino.h @@ -58,6 +58,7 @@ #define CONFIG_CMD_GPIO #define CONFIG_CMD_LED #define CONFIG_CMD_MMC +#define CONFIG_CMD_USB
/* * Memory configurations @@ -138,6 +139,15 @@ */ #define CONFIG_APBH_DMA
+/* USB */ +#ifdef CONFIG_CMD_USB +#define CONFIG_USB_EHCI +#define CONFIG_USB_EHCI_MXS +#define CONFIG_EHCI_MXS_PORT 0 +#define CONFIG_EHCI_IS_TDI +#define CONFIG_USB_STORAGE +#endif + /* * Boot Linux */
This adds support to the LAN9512 chip included in the board and extend the environment to easy netboot use.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br --- board/olimex/mx23_olinuxino/mx23_olinuxino.c | 6 +++++ board/olimex/mx23_olinuxino/spl_boot.c | 4 +++ include/configs/mx23_olinuxino.h | 40 +++++++++++++++++++++++++--- 3 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/board/olimex/mx23_olinuxino/mx23_olinuxino.c b/board/olimex/mx23_olinuxino/mx23_olinuxino.c index 2501417..9ed7718 100644 --- a/board/olimex/mx23_olinuxino/mx23_olinuxino.c +++ b/board/olimex/mx23_olinuxino/mx23_olinuxino.c @@ -23,6 +23,7 @@ */
#include <common.h> +#include <asm/gpio.h> #include <asm/io.h> #include <asm/arch/iomux-mx23.h> #include <asm/arch/imx-regs.h> @@ -45,6 +46,11 @@ int board_early_init_f(void) /* SSP0 clock at 96MHz */ mxs_set_sspclk(MXC_SSPCLK0, 96000, 0);
+#ifdef CONFIG_CMD_USB + /* Enable LAN9512 */ + gpio_direction_output(MX23_PAD_GPMI_ALE__GPIO_0_17, 1); +#endif + return 0; }
diff --git a/board/olimex/mx23_olinuxino/spl_boot.c b/board/olimex/mx23_olinuxino/spl_boot.c index 3bbf5ad..a96c293 100644 --- a/board/olimex/mx23_olinuxino/spl_boot.c +++ b/board/olimex/mx23_olinuxino/spl_boot.c @@ -95,6 +95,10 @@ const iomux_cfg_t iomux_setup[] = { MX23_PAD_SSP1_DATA2__SSP1_DATA2 | MUX_CONFIG_SSP, MX23_PAD_SSP1_DATA3__SSP1_DATA3 | MUX_CONFIG_SSP, MX23_PAD_SSP1_SCK__SSP1_SCK | MUX_CONFIG_SSP, + + /* Ethernet */ + MX23_PAD_GPMI_ALE__GPIO_0_17 | + (MXS_PAD_3V3 | MXS_PAD_12MA | MXS_PAD_NOPULL), };
void board_init_ll(void) diff --git a/include/configs/mx23_olinuxino.h b/include/configs/mx23_olinuxino.h index 7e17809..42de557 100644 --- a/include/configs/mx23_olinuxino.h +++ b/include/configs/mx23_olinuxino.h @@ -53,11 +53,13 @@ #define CONFIG_DOS_PARTITION
#define CONFIG_CMD_CACHE +#define CONFIG_CMD_DHCP #define CONFIG_CMD_EXT2 #define CONFIG_CMD_FAT #define CONFIG_CMD_GPIO #define CONFIG_CMD_LED #define CONFIG_CMD_MMC +#define CONFIG_CMD_NET #define CONFIG_CMD_USB
/* @@ -148,6 +150,12 @@ #define CONFIG_USB_STORAGE #endif
+/* Ethernet */ +#ifdef CONFIG_CMD_NET +#define CONFIG_USB_HOST_ETHER +#define CONFIG_USB_ETHER_SMSC95XX +#endif + /* * Boot Linux */ @@ -173,6 +181,7 @@ /* * Extra Environments */ + #define CONFIG_EXTRA_ENV_SETTINGS \ "update_sd_firmware_filename=u-boot.sd\0" \ "update_sd_firmware=" /* Update the SD firmware partition */ \ @@ -189,6 +198,7 @@ "fdt_file=imx23-olinuxino.dtb\0" \ "fdt_addr=0x41000000\0" \ "boot_fdt=try\0" \ + "ip_dyn=yes\0" \ "mmcdev=0\0" \ "mmcpart=2\0" \ "mmcroot=/dev/mmcblk0p3 rw rootwait\0" \ @@ -214,6 +224,31 @@ "fi; " \ "else " \ "bootm; " \ + "fi;\0" \ + "netargs=setenv bootargs console=${console_mainline},${baudrate} " \ + "root=/dev/nfs " \ + "ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \ + "netboot=echo Booting from net ...; " \ + "usb start; " \ + "run netargs; " \ + "if test ${ip_dyn} = yes; then " \ + "setenv get_cmd dhcp; " \ + "else " \ + "setenv get_cmd tftp; " \ + "fi; " \ + "${get_cmd} ${uimage}; " \ + "if test ${boot_fdt} = yes; then " \ + "if ${get_cmd} ${fdt_addr} ${fdt_file}; then " \ + "bootm ${loadaddr} - ${fdt_addr}; " \ + "else " \ + "if test ${boot_fdt} = try; then " \ + "bootm; " \ + "else " \ + "echo WARN: Cannot load the DT; " \ + "fi;" \ + "fi; " \ + "else " \ + "bootm; " \ "fi;\0"
#define CONFIG_BOOTCOMMAND \ @@ -223,10 +258,9 @@ "else " \ "if run loaduimage; then " \ "run mmcboot; " \ - "else " \ - "echo ERR: Fail to boot from MMC; " \ + "else run netboot; " \ "fi; " \ "fi; " \ - "else exit; fi" + "else run netboot; fi"
#endif /* __MX23_OLINUXINO_CONFIG_H__ */
Dear Otavio Salvador,
This adds support to the LAN9512 chip included in the board and extend the environment to easy netboot use.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br
board/olimex/mx23_olinuxino/mx23_olinuxino.c | 6 +++++ board/olimex/mx23_olinuxino/spl_boot.c | 4 +++ include/configs/mx23_olinuxino.h | 40 +++++++++++++++++++++++++--- 3 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/board/olimex/mx23_olinuxino/mx23_olinuxino.c b/board/olimex/mx23_olinuxino/mx23_olinuxino.c index 2501417..9ed7718 100644 --- a/board/olimex/mx23_olinuxino/mx23_olinuxino.c +++ b/board/olimex/mx23_olinuxino/mx23_olinuxino.c @@ -23,6 +23,7 @@ */
#include <common.h> +#include <asm/gpio.h> #include <asm/io.h> #include <asm/arch/iomux-mx23.h> #include <asm/arch/imx-regs.h> @@ -45,6 +46,11 @@ int board_early_init_f(void) /* SSP0 clock at 96MHz */ mxs_set_sspclk(MXC_SSPCLK0, 96000, 0);
+#ifdef CONFIG_CMD_USB
- /* Enable LAN9512 */
- gpio_direction_output(MX23_PAD_GPMI_ALE__GPIO_0_17, 1);
+#endif
- return 0;
}
diff --git a/board/olimex/mx23_olinuxino/spl_boot.c b/board/olimex/mx23_olinuxino/spl_boot.c index 3bbf5ad..a96c293 100644 --- a/board/olimex/mx23_olinuxino/spl_boot.c +++ b/board/olimex/mx23_olinuxino/spl_boot.c @@ -95,6 +95,10 @@ const iomux_cfg_t iomux_setup[] = { MX23_PAD_SSP1_DATA2__SSP1_DATA2 | MUX_CONFIG_SSP, MX23_PAD_SSP1_DATA3__SSP1_DATA3 | MUX_CONFIG_SSP, MX23_PAD_SSP1_SCK__SSP1_SCK | MUX_CONFIG_SSP,
- /* Ethernet */
- MX23_PAD_GPMI_ALE__GPIO_0_17 |
(MXS_PAD_3V3 | MXS_PAD_12MA | MXS_PAD_NOPULL),};
void board_init_ll(void) diff --git a/include/configs/mx23_olinuxino.h b/include/configs/mx23_olinuxino.h index 7e17809..42de557 100644 --- a/include/configs/mx23_olinuxino.h +++ b/include/configs/mx23_olinuxino.h @@ -53,11 +53,13 @@ #define CONFIG_DOS_PARTITION
#define CONFIG_CMD_CACHE +#define CONFIG_CMD_DHCP #define CONFIG_CMD_EXT2 #define CONFIG_CMD_FAT #define CONFIG_CMD_GPIO #define CONFIG_CMD_LED #define CONFIG_CMD_MMC +#define CONFIG_CMD_NET #define CONFIG_CMD_USB
/* @@ -148,6 +150,12 @@ #define CONFIG_USB_STORAGE #endif
+/* Ethernet */ +#ifdef CONFIG_CMD_NET +#define CONFIG_USB_HOST_ETHER +#define CONFIG_USB_ETHER_SMSC95XX +#endif
/*
- Boot Linux
*/
Split the env from this patch into separate one ; merge the rest into the 09/10 as the SMC device is also a hub etc.
Best regards, Marek Vasut
On Wed, Jan 30, 2013 at 12:18 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
This adds support to the LAN9512 chip included in the board and extend the environment to easy netboot use.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br
board/olimex/mx23_olinuxino/mx23_olinuxino.c | 6 +++++ board/olimex/mx23_olinuxino/spl_boot.c | 4 +++ include/configs/mx23_olinuxino.h | 40 +++++++++++++++++++++++++--- 3 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/board/olimex/mx23_olinuxino/mx23_olinuxino.c b/board/olimex/mx23_olinuxino/mx23_olinuxino.c index 2501417..9ed7718 100644 --- a/board/olimex/mx23_olinuxino/mx23_olinuxino.c +++ b/board/olimex/mx23_olinuxino/mx23_olinuxino.c @@ -23,6 +23,7 @@ */
#include <common.h> +#include <asm/gpio.h> #include <asm/io.h> #include <asm/arch/iomux-mx23.h> #include <asm/arch/imx-regs.h> @@ -45,6 +46,11 @@ int board_early_init_f(void) /* SSP0 clock at 96MHz */ mxs_set_sspclk(MXC_SSPCLK0, 96000, 0);
+#ifdef CONFIG_CMD_USB
/* Enable LAN9512 */gpio_direction_output(MX23_PAD_GPMI_ALE__GPIO_0_17, 1);+#endif
return 0;}
diff --git a/board/olimex/mx23_olinuxino/spl_boot.c b/board/olimex/mx23_olinuxino/spl_boot.c index 3bbf5ad..a96c293 100644 --- a/board/olimex/mx23_olinuxino/spl_boot.c +++ b/board/olimex/mx23_olinuxino/spl_boot.c @@ -95,6 +95,10 @@ const iomux_cfg_t iomux_setup[] = { MX23_PAD_SSP1_DATA2__SSP1_DATA2 | MUX_CONFIG_SSP, MX23_PAD_SSP1_DATA3__SSP1_DATA3 | MUX_CONFIG_SSP, MX23_PAD_SSP1_SCK__SSP1_SCK | MUX_CONFIG_SSP,
/* Ethernet */MX23_PAD_GPMI_ALE__GPIO_0_17 |(MXS_PAD_3V3 | MXS_PAD_12MA | MXS_PAD_NOPULL),};
void board_init_ll(void) diff --git a/include/configs/mx23_olinuxino.h b/include/configs/mx23_olinuxino.h index 7e17809..42de557 100644 --- a/include/configs/mx23_olinuxino.h +++ b/include/configs/mx23_olinuxino.h @@ -53,11 +53,13 @@ #define CONFIG_DOS_PARTITION
#define CONFIG_CMD_CACHE +#define CONFIG_CMD_DHCP #define CONFIG_CMD_EXT2 #define CONFIG_CMD_FAT #define CONFIG_CMD_GPIO #define CONFIG_CMD_LED #define CONFIG_CMD_MMC +#define CONFIG_CMD_NET #define CONFIG_CMD_USB
/* @@ -148,6 +150,12 @@ #define CONFIG_USB_STORAGE #endif
+/* Ethernet */ +#ifdef CONFIG_CMD_NET +#define CONFIG_USB_HOST_ETHER +#define CONFIG_USB_ETHER_SMSC95XX +#endif
/*
- Boot Linux
*/
Split the env from this patch into separate one ; merge the rest into the 09/10 as the SMC device is also a hub etc.
In this case I'd prefer to add support for the hub only in the previous patch and left the ethernet support on this with the env.
Makes sense?
-- Otavio Salvador O.S. Systems E-mail: otavio@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
Dear Otavio Salvador,
On Wed, Jan 30, 2013 at 12:18 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
This adds support to the LAN9512 chip included in the board and extend the environment to easy netboot use.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br
board/olimex/mx23_olinuxino/mx23_olinuxino.c | 6 +++++ board/olimex/mx23_olinuxino/spl_boot.c | 4 +++ include/configs/mx23_olinuxino.h | 40
+++++++++++++++++++++++++--- 3 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/board/olimex/mx23_olinuxino/mx23_olinuxino.c b/board/olimex/mx23_olinuxino/mx23_olinuxino.c index 2501417..9ed7718 100644 --- a/board/olimex/mx23_olinuxino/mx23_olinuxino.c +++ b/board/olimex/mx23_olinuxino/mx23_olinuxino.c @@ -23,6 +23,7 @@
*/
#include <common.h>
+#include <asm/gpio.h>
#include <asm/io.h> #include <asm/arch/iomux-mx23.h> #include <asm/arch/imx-regs.h>
@@ -45,6 +46,11 @@ int board_early_init_f(void)
/* SSP0 clock at 96MHz */ mxs_set_sspclk(MXC_SSPCLK0, 96000, 0);+#ifdef CONFIG_CMD_USB
/* Enable LAN9512 */gpio_direction_output(MX23_PAD_GPMI_ALE__GPIO_0_17, 1);+#endif
return 0;}
diff --git a/board/olimex/mx23_olinuxino/spl_boot.c b/board/olimex/mx23_olinuxino/spl_boot.c index 3bbf5ad..a96c293 100644 --- a/board/olimex/mx23_olinuxino/spl_boot.c +++ b/board/olimex/mx23_olinuxino/spl_boot.c @@ -95,6 +95,10 @@ const iomux_cfg_t iomux_setup[] = {
MX23_PAD_SSP1_DATA2__SSP1_DATA2 | MUX_CONFIG_SSP, MX23_PAD_SSP1_DATA3__SSP1_DATA3 | MUX_CONFIG_SSP, MX23_PAD_SSP1_SCK__SSP1_SCK | MUX_CONFIG_SSP,
/* Ethernet */MX23_PAD_GPMI_ALE__GPIO_0_17 |(MXS_PAD_3V3 | MXS_PAD_12MA | MXS_PAD_NOPULL),};
void board_init_ll(void)
diff --git a/include/configs/mx23_olinuxino.h b/include/configs/mx23_olinuxino.h index 7e17809..42de557 100644 --- a/include/configs/mx23_olinuxino.h +++ b/include/configs/mx23_olinuxino.h @@ -53,11 +53,13 @@
#define CONFIG_DOS_PARTITION
#define CONFIG_CMD_CACHE
+#define CONFIG_CMD_DHCP
#define CONFIG_CMD_EXT2 #define CONFIG_CMD_FAT #define CONFIG_CMD_GPIO #define CONFIG_CMD_LED #define CONFIG_CMD_MMC
+#define CONFIG_CMD_NET
#define CONFIG_CMD_USB
/*
@@ -148,6 +150,12 @@
#define CONFIG_USB_STORAGE #endif
+/* Ethernet */ +#ifdef CONFIG_CMD_NET +#define CONFIG_USB_HOST_ETHER +#define CONFIG_USB_ETHER_SMSC95XX +#endif
/*
- Boot Linux
*/
Split the env from this patch into separate one ; merge the rest into the 09/10 as the SMC device is also a hub etc.
In this case I'd prefer to add support for the hub only in the previous patch and left the ethernet support on this with the env.
Makes sense?
The hub and the ethernet are the same chip, thus it makes no sense to have two patches for that.
Best regards, Marek Vasut
On Wed, Jan 30, 2013 at 1:40 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
On Wed, Jan 30, 2013 at 12:18 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
This adds support to the LAN9512 chip included in the board and extend the environment to easy netboot use.
Signed-off-by: Otavio Salvador otavio@ossystems.com.br
board/olimex/mx23_olinuxino/mx23_olinuxino.c | 6 +++++ board/olimex/mx23_olinuxino/spl_boot.c | 4 +++ include/configs/mx23_olinuxino.h | 40
+++++++++++++++++++++++++--- 3 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/board/olimex/mx23_olinuxino/mx23_olinuxino.c b/board/olimex/mx23_olinuxino/mx23_olinuxino.c index 2501417..9ed7718 100644 --- a/board/olimex/mx23_olinuxino/mx23_olinuxino.c +++ b/board/olimex/mx23_olinuxino/mx23_olinuxino.c @@ -23,6 +23,7 @@
*/
#include <common.h>
+#include <asm/gpio.h>
#include <asm/io.h> #include <asm/arch/iomux-mx23.h> #include <asm/arch/imx-regs.h>
@@ -45,6 +46,11 @@ int board_early_init_f(void)
/* SSP0 clock at 96MHz */ mxs_set_sspclk(MXC_SSPCLK0, 96000, 0);+#ifdef CONFIG_CMD_USB
/* Enable LAN9512 */gpio_direction_output(MX23_PAD_GPMI_ALE__GPIO_0_17, 1);+#endif
return 0;}
diff --git a/board/olimex/mx23_olinuxino/spl_boot.c b/board/olimex/mx23_olinuxino/spl_boot.c index 3bbf5ad..a96c293 100644 --- a/board/olimex/mx23_olinuxino/spl_boot.c +++ b/board/olimex/mx23_olinuxino/spl_boot.c @@ -95,6 +95,10 @@ const iomux_cfg_t iomux_setup[] = {
MX23_PAD_SSP1_DATA2__SSP1_DATA2 | MUX_CONFIG_SSP, MX23_PAD_SSP1_DATA3__SSP1_DATA3 | MUX_CONFIG_SSP, MX23_PAD_SSP1_SCK__SSP1_SCK | MUX_CONFIG_SSP,
/* Ethernet */MX23_PAD_GPMI_ALE__GPIO_0_17 |(MXS_PAD_3V3 | MXS_PAD_12MA | MXS_PAD_NOPULL),};
void board_init_ll(void)
diff --git a/include/configs/mx23_olinuxino.h b/include/configs/mx23_olinuxino.h index 7e17809..42de557 100644 --- a/include/configs/mx23_olinuxino.h +++ b/include/configs/mx23_olinuxino.h @@ -53,11 +53,13 @@
#define CONFIG_DOS_PARTITION
#define CONFIG_CMD_CACHE
+#define CONFIG_CMD_DHCP
#define CONFIG_CMD_EXT2 #define CONFIG_CMD_FAT #define CONFIG_CMD_GPIO #define CONFIG_CMD_LED #define CONFIG_CMD_MMC
+#define CONFIG_CMD_NET
#define CONFIG_CMD_USB
/*
@@ -148,6 +150,12 @@
#define CONFIG_USB_STORAGE #endif
+/* Ethernet */ +#ifdef CONFIG_CMD_NET +#define CONFIG_USB_HOST_ETHER +#define CONFIG_USB_ETHER_SMSC95XX +#endif
/*
- Boot Linux
*/
Split the env from this patch into separate one ; merge the rest into the 09/10 as the SMC device is also a hub etc.
In this case I'd prefer to add support for the hub only in the previous patch and left the ethernet support on this with the env.
Makes sense?
The hub and the ethernet are the same chip, thus it makes no sense to have two patches for that.
I'd like to have all changes of ethernet in a single commit so the enviroment and all the other changes for it in one logical change. I agree about the hub but the ethernet does not seem right to merge it there.
-- Otavio Salvador O.S. Systems E-mail: otavio@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
Dear Otavio Salvador,
[...]
In this case I'd prefer to add support for the hub only in the previous patch and left the ethernet support on this with the env.
Makes sense?
The hub and the ethernet are the same chip, thus it makes no sense to have two patches for that.
I'd like to have all changes of ethernet in a single commit so the enviroment and all the other changes for it in one logical change. I agree about the hub but the ethernet does not seem right to merge it there.
This will then be completely un-bisectable.
Best regards, Marek Vasut
On Wed, Jan 30, 2013 at 2:06 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
[...]
In this case I'd prefer to add support for the hub only in the previous patch and left the ethernet support on this with the env.
Makes sense?
The hub and the ethernet are the same chip, thus it makes no sense to have two patches for that.
I'd like to have all changes of ethernet in a single commit so the enviroment and all the other changes for it in one logical change. I agree about the hub but the ethernet does not seem right to merge it there.
This will then be completely un-bisectable.
I will prepare the patches for v2 and we check how it goes. :)
-- Otavio Salvador O.S. Systems E-mail: otavio@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
Dear Otavio Salvador,
On Wed, Jan 30, 2013 at 2:06 PM, Marek Vasut marex@denx.de wrote:
Dear Otavio Salvador,
[...]
In this case I'd prefer to add support for the hub only in the previous patch and left the ethernet support on this with the env.
Makes sense?
The hub and the ethernet are the same chip, thus it makes no sense to have two patches for that.
I'd like to have all changes of ethernet in a single commit so the enviroment and all the other changes for it in one logical change. I agree about the hub but the ethernet does not seem right to merge it there.
This will then be completely un-bisectable.
I will prepare the patches for v2 and we check how it goes. :)
Cool your jets already ... re-submit only upon request.
Best regards, Marek Vasut
participants (4)
-
Fabio Estevam -
Marek Vasut -
Otavio Salvador -
Simon Glass