mx23/mxs pending patches

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.

Dear Otavio Salvador,

Quoted 3 lines

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 <[email protected]>

I'm missing cover letter for this large series.

Quoted 6 lines · Marek Vasut

Dear Otavio Salvador,

Quoted 3 lines

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.

Quoted 3 lines

Acked-by Marek Vasut <[email protected]>

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 at 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 <[email protected]>

---
 arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 1 +
 1 file changed, 1 insertion(+)

(quoted diff) +0 -0

b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index f8392f6..37b50e9 100644

Dear Otavio Salvador,

Quoted 17 lines

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 <[email protected]>

---
 arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 1 +
 1 file changed, 1 insertion(+)

(quoted diff) +0 -0

b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index f8392f6..37b50e9 100644

arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c +0 -0

@@ -119,6 +119,7 @@ static void initialize_dram_values(void)
              writel(dram_vals[i], MXS_DRAM_BASE + (4 * i));
 

arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c static void initialize_dram_values(void) · line 122

Quoted 2 lines

arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c +1 -0

 #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 ...

Adjust HW_DRAM_CTL14 to enable the chip selects to allow usage of full 128MB of RAM.

Signed-off-by Otavio Salvador <[email protected]>

---
 board/freescale/mx23evk/spl_boot.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

(quoted diff) +0 -0

b/board/freescale/mx23evk/spl_boot.c index 6007433..b6f4e7e 100644

board/freescale/mx23evk/spl_boot.c +3 -0

@@ -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

Dear Otavio Salvador,

Quoted 4 lines

Adjust HW_DRAM_CTL14 to enable the chip selects to allow usage of full 128MB of RAM.

Signed-off-by Otavio Salvador <[email protected]>

Just enable the full set for all in the generic memory register set (dram_vals)?

Quoted 12 lines

---
 board/freescale/mx23evk/spl_boot.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

(quoted diff) +0 -0

b/board/freescale/mx23evk/spl_boot.c index 6007433..b6f4e7e 100644

board/freescale/mx23evk/spl_boot.c +0 -0

@@ -98,6 +98,16 @@ const iomux_cfg_t iomux_setup[] = {
              (MXS_PAD_4MA | MXS_PAD_3V3 | MXS_PAD_NOPULL),
 };
 

board/freescale/mx23evk/spl_boot.c const iomux_cfg_t iomux_setup[] = { · line 113

Quoted 13 lines

board/freescale/mx23evk/spl_boot.c +10 -0

+#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

Quoted 5 lines

Dear Otavio Salvador,

Quoted 3 lines

Adjust HW_DRAM_CTL14 to enable the chip selects to allow usage of full 128MB of RAM.

Quoted 4 lines

Quoted 1 line

Signed-off-by Otavio Salvador <[email protected]>

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.

Quoted 26 lines

Quoted 26 lines

---

 board/freescale/mx23evk/spl_boot.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

(quoted diff) +0 -0

b/board/freescale/mx23evk/spl_boot.c index 6007433..b6f4e7e 100644

board/freescale/mx23evk/spl_boot.c +10 -0

@@ -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;
+}
+
 

Quoted 7 lines

Quoted 4 lines

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 at ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br

Dear Otavio Salvador,

Quoted 6 lines · Marek Vasut

Quoted 5 lines

Dear Otavio Salvador,

Quoted 3 lines

Adjust HW_DRAM_CTL14 to enable the chip selects to allow usage of full 128MB of RAM.

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

Signed-off-by Otavio Salvador <[email protected]>

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.

Quoted 3 lines

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.

Quoted 17 lines

Dear Otavio Salvador,

Quoted 6 lines · Marek Vasut

Quoted 5 lines

Dear Otavio Salvador,

Quoted 3 lines

Adjust HW_DRAM_CTL14 to enable the chip selects to allow usage of full 128MB of RAM.

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

Signed-off-by Otavio Salvador <[email protected]>

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.

Quoted 6 lines

Quoted 3 lines

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? :-)

Dear Otavio Salvador,

Quoted 18 lines · Marek Vasut

Quoted 17 lines

Dear Otavio Salvador,

Quoted 6 lines · Marek Vasut

Quoted 5 lines

Dear Otavio Salvador,

Quoted 3 lines

Adjust HW_DRAM_CTL14 to enable the chip selects to allow usage of full 128MB of RAM.

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

Signed-off-by Otavio Salvador <[email protected]>

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.

Quoted 8 lines

Quoted 6 lines

Quoted 3 lines

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?

Quoted 2 lines

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.

Quoted 3 lines

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.

This fixes the build failure when included in mx23_olinuxino.h board

Quoted 1 line · Otavio Salvador

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.

This allow user to know if the bootloader is running, even without a serial console.

Signed-off-by Otavio Salvador <[email protected]>

---
 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(+)

(quoted diff) +0 -0

b/board/olimex/mx23_olinuxino/mx23_olinuxino.c index 6a6053b..2501417 100644

board/olimex/mx23_olinuxino/mx23_olinuxino.c +7 -0

@@ -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;
 }

(quoted diff) +0 -0

b/board/olimex/mx23_olinuxino/spl_boot.c index 7def8bc..3bbf5ad 100644

board/olimex/mx23_olinuxino/spl_boot.c +4 -0

@@ -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,

(quoted diff) +0 -0

b/include/configs/mx23_olinuxino.h index 7983c5d..968aec8 100644

include/configs/mx23_olinuxino.h +5 -0

@@ -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

Dear Otavio Salvador,

Quoted 4 lines

This allow user to know if the bootloader is running, even without a serial console.

Signed-off-by Otavio Salvador <[email protected]>

Uh oh, how does this know which GPIO to toggle to drive the led this time ?

Quoted 5 lines

Dear Otavio Salvador,

Quoted 3 lines

This allow user to know if the bootloader is running, even without a serial console.

Quoted 4 lines

Quoted 1 line

Signed-off-by Otavio Salvador <[email protected]>

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.

Dear Otavio Salvador,

Quoted 8 lines · Marek Vasut

Quoted 7 lines

Dear Otavio Salvador,

Quoted 4 lines

This allow user to know if the bootloader is running, even without a serial console.

Signed-off-by Otavio Salvador <[email protected]>

Quoted 5 lines

Quoted 2 lines

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.

Quoted 10 lines

Dear Otavio Salvador,

Quoted 8 lines · Marek Vasut

Quoted 7 lines

Dear Otavio Salvador,

Quoted 4 lines

This allow user to know if the bootloader is running, even without a serial console.

Signed-off-by Otavio Salvador <[email protected]>

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

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);
}

...

Quoted 1 line

Moreover, you never set the LED GPIO as output.

The driver handles it by itself.

Dear Otavio Salvador,

Quoted 29 lines · Marek Vasut

Quoted 10 lines

Dear Otavio Salvador,

Quoted 8 lines · Marek Vasut

Quoted 7 lines

Dear Otavio Salvador,

Quoted 4 lines

This allow user to know if the bootloader is running, even without a serial console.

Signed-off-by Otavio Salvador <[email protected]>

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

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);
}

Quoted 5 lines

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.

Quoted 2 lines

Quoted 1 line

Moreover, you never set the LED GPIO as output.

Quoted 1 line

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?

Quoted 47 lines

Dear Otavio Salvador,

Quoted 31 lines · Marek Vasut

Quoted 10 lines

Dear Otavio Salvador,

Quoted 8 lines · Marek Vasut

Quoted 7 lines

Dear Otavio Salvador,

Quoted 4 lines

This allow user to know if the bootloader is running, even without a serial console.

Signed-off-by Otavio Salvador <[email protected]>

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

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);

}

Quoted 7 lines

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.

Quoted 3 lines

Quoted 1 line

Moreover, you never set the LED GPIO as output.

The driver handles it by itself.

Quoted 5 lines

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.

Dear Otavio Salvador,

Quoted 52 lines · Marek Vasut

Quoted 51 lines

Dear Otavio Salvador,

Quoted 31 lines · Marek Vasut

Quoted 10 lines

Dear Otavio Salvador,

Quoted 8 lines · Marek Vasut

Quoted 7 lines

Dear Otavio Salvador,

Quoted 4 lines

This allow user to know if the bootloader is running, even without a serial console.

Signed-off-by Otavio Salvador <[email protected]>

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

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);

}

Quoted 7 lines

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.

Quoted 3 lines

Quoted 1 line

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:

Quoted 4 lines

Quoted 1 line

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.

Quoted 59 lines

Dear Otavio Salvador,

Quoted 56 lines · Marek Vasut

Quoted 45 lines

Dear Otavio Salvador,

Quoted 31 lines · Marek Vasut

Quoted 10 lines

Dear Otavio Salvador,

Quoted 8 lines · Marek Vasut

Quoted 7 lines

Dear Otavio Salvador,

Quoted 4 lines

This allow user to know if the bootloader is running, even without a serial console.

Signed-off-by Otavio Salvador <[email protected]>

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

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);

}

Quoted 7 lines

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.

Quoted 2 lines

Quoted 1 line

Moreover, you never set the LED GPIO as output.

Quoted 7 lines

Quoted 1 line

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.

Quoted 3 lines

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.

The i.MX23 just one USB port so disable the second controller probe when building for i.MX23.

Signed-off-by Otavio Salvador <[email protected]>

---
 drivers/usb/host/ehci-mxs.c | 2 ++
 1 file changed, 2 insertions(+)

drivers/usb/host/ehci-mxs.c +0 -0

index 5062af5..28c8cde 100644
@@ -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;

Dear Otavio Salvador,

Quoted 15 lines

The i.MX23 just one USB port so disable the second controller probe when building for i.MX23.

Signed-off-by Otavio Salvador <[email protected]>

---
 drivers/usb/host/ehci-mxs.c | 2 ++
 1 file changed, 2 insertions(+)

drivers/usb/host/ehci-mxs.c +0 -0

index 5062af5..28c8cde 100644
@@ -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;

drivers/usb/host/ehci-mxs.c int mxs_ehci_get_port(struct ehci_mxs *mxs_usb, int · line 61

Quoted 10 lines

drivers/usb/host/ehci-mxs.c +2 -0

              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.

This adds support to the LAN9512 chip included in the board and extend the environment to easy netboot use.

Signed-off-by Otavio Salvador <[email protected]>

---
 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(-)

(quoted diff) +0 -0

b/board/olimex/mx23_olinuxino/mx23_olinuxino.c index 2501417..9ed7718 100644

board/olimex/mx23_olinuxino/mx23_olinuxino.c +6 -0

@@ -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;
 }
 

(quoted diff) +0 -0

b/board/olimex/mx23_olinuxino/spl_boot.c index 3bbf5ad..a96c293 100644

board/olimex/mx23_olinuxino/spl_boot.c +4 -0

@@ -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)

(quoted diff) +0 -0

b/include/configs/mx23_olinuxino.h index 7e17809..42de557 100644

include/configs/mx23_olinuxino.h +2 -0

@@ -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

Dear Otavio Salvador,

Quoted 73 lines

This adds support to the LAN9512 chip included in the board and extend the environment to easy netboot use.

Signed-off-by Otavio Salvador <[email protected]>

---
 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(-)

(quoted diff) +0 -0

b/board/olimex/mx23_olinuxino/mx23_olinuxino.c index 2501417..9ed7718 100644

board/olimex/mx23_olinuxino/mx23_olinuxino.c +6 -0

@@ -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;
 }
 

(quoted diff) +0 -0

b/board/olimex/mx23_olinuxino/spl_boot.c index 3bbf5ad..a96c293 100644

board/olimex/mx23_olinuxino/spl_boot.c +4 -0

@@ -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)

(quoted diff) +0 -0

b/include/configs/mx23_olinuxino.h index 7e17809..42de557 100644

include/configs/mx23_olinuxino.h +2 -0

@@ -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
 

include/configs/mx23_olinuxino.h line 161

Quoted 9 lines

include/configs/mx23_olinuxino.h +6 -0

+/* 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.

Quoted 102 lines

Dear Otavio Salvador,

Quoted 100 lines

This adds support to the LAN9512 chip included in the board and extend the environment to easy netboot use.

Signed-off-by Otavio Salvador <[email protected]>

---

 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(-)

(quoted diff) +0 -0

b/board/olimex/mx23_olinuxino/mx23_olinuxino.c index 2501417..9ed7718 100644

board/olimex/mx23_olinuxino/mx23_olinuxino.c +1 -0

@@ -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>

board/olimex/mx23_olinuxino/mx23_olinuxino.c +5 -0

@@ -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;

}

(quoted diff) +0 -0

b/board/olimex/mx23_olinuxino/spl_boot.c index 3bbf5ad..a96c293 100644

board/olimex/mx23_olinuxino/spl_boot.c +4 -0

@@ -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)

(quoted diff) +0 -0

b/include/configs/mx23_olinuxino.h index 7e17809..42de557 100644

include/configs/mx23_olinuxino.h +8 -0

@@ -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
+
 

Quoted 7 lines

Quoted 4 lines

include/configs/mx23_olinuxino.h +0 -0

 /*

* 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?

Dear Otavio Salvador,

Quoted 111 lines · Marek Vasut

Quoted 109 lines

Dear Otavio Salvador,

Quoted 102 lines

This adds support to the LAN9512 chip included in the board and extend the environment to easy netboot use.

Signed-off-by Otavio Salvador <[email protected]>

---

 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(-)

(quoted diff) +0 -0

b/board/olimex/mx23_olinuxino/mx23_olinuxino.c index 2501417..9ed7718 100644

board/olimex/mx23_olinuxino/mx23_olinuxino.c +1 -0

@@ -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>

board/olimex/mx23_olinuxino/mx23_olinuxino.c +5 -0

@@ -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;

}

(quoted diff) +0 -0

b/board/olimex/mx23_olinuxino/spl_boot.c index 3bbf5ad..a96c293 100644

board/olimex/mx23_olinuxino/spl_boot.c +4 -0

@@ -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)

(quoted diff) +0 -0

b/include/configs/mx23_olinuxino.h index 7e17809..42de557 100644

include/configs/mx23_olinuxino.h +8 -0

@@ -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
+
 
 /*

Quoted 2 lines

* 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.

Quoted 4 lines

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.

Quoted 5 lines

Quoted 4 lines

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?

Quoted 2 lines

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.

Dear Otavio Salvador,

[...]

Quoted 8 lines

Quoted 7 lines

Quoted 4 lines

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.

Quoted 4 lines

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.

Quoted 12 lines

Dear Otavio Salvador,

[...]

Quoted 8 lines

Quoted 7 lines

Quoted 4 lines

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.

Quoted 6 lines

Quoted 4 lines

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. :)