Re: [U-Boot] [PATCH V7] ARM: mx6: Add support for Kosagi Novena

2014-10-15 Thread Sean Cross 
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

2014-10-15 Thread Sean Cross 
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

2014-10-12 Thread Sean Cross 
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

2014-10-11 Thread Sean Cross 
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 V5] ARM: mx6: Add support for Kosagi Novena

2014-10-08 Thread Sean Cross 
On 08/10/2014 05:55, Nikolay Dimitrov wrote:
 Hi Marek,

 I'm marking only the critical issues that are left unfixed from
 previous conversations, to speed-up the process a little bit.
 I'll send later patches for the non-critical issues to spare you the
 extra work (and I'm sure my constructive criticism is already boring
 :D ).


 On 10/06/2014 07:02 PM, Marek Vasut wrote:
 +#define NOVENA_USB_HUB_RESETIMX_GPIO_NR(7, 12)
 ...
 +/*
 + * USB
 + */
 +#ifdef CONFIG_USB_EHCI_MX6
 +int board_ehci_hcd_init(int port)
 +{
 +/* Reset USB hub */
 +if (port == 1) {
 +gpio_set_value(NOVENA_USB_HUB_RESET, 0);
 +mdelay(2);
 +gpio_set_value(NOVENA_USB_HUB_RESET, 1);
 +}
 +return 0;
 +}
 +#endif

 As we previously discussed, this pin definition conflicts with
 NOVENA_PCIE_POWER_ON_GPIO (GPIO7_IO12 is connected to PCIE_PWRON), so
 by asserting it, you'll turn-off the wrong sub-system.

 Currently the USB hub is reset only by system reset (RESETBMCU
 asserted by the PMIC). I don't see how the CPU can selectively reset
 the USB hub via a GPIO, so it would be better to remove the reset code.

 @Sean - can you please confirm/reject this finding?


 +#define NOVENA_AUDIO_PWRONIMX_GPIO_NR(5, 17)
 ...
 +/*
 + * Audio
 + */
 +static iomux_v3_cfg_t audio_pads[] = {
 +/* AUD_PWRON */
 +MX6_PAD_DISP0_DAT23__GPIO5_IO17 | MUX_PAD_CTRL(NO_PAD_CTRL),
 +};

 The speaker amplifiers will still be disabled, as AUDIO_PWRON is not
 connected to them (R30A is marked as DNP). You need to add one more
 GPIO to enable the speaker amplifiers, here's the fix:

 #define NOVENA_AUDIO_PWRONIMX_GPIO_NR(5, 17)
 #define NOVENA_AUDIO_SPK_AMP_ONIMX_GPIO_NR(4, 9)

 /*
  * Audio
  */
 static iomux_v3_cfg_t audio_pads[] = {
 /* AUD_PWRON */
 MX6_PAD_KEY_ROW1__GPIO5_IO17 | MUX_PAD_CTRL(NO_PAD_CTRL),

 /* Speakers' amplifiers #SHDWN  */
 MX6_PAD_KEY_ROW1__GPIO4_IO09 | MUX_PAD_CTRL(NO_PAD_CTRL),
 };

 static void novena_spl_setup_iomux_audio(void)
 {
 imx_iomux_v3_setup_multiple_pads(audio_pads, ARRAY_SIZE(audio_pads));

 gpio_direction_output(NOVENA_AUDIO_PWRON, 1);
 gpio_direction_output(NOVENA_AUDIO_SPK_AMP_ON, 1);
 }


 Side comment: If someone needs to talk to the Audio Codec via I2C3 in
 U-Boot environment, don't be surprised if the codec doesn't respond to
 any I2C requests at all (I've had such issues with SGTL5000). The most
 probable reason is that the codec doesn't receive reference clock from
 imx6 GPIO0. This is not a critical issues as later the kernel muxes
 this GPIO0 properly, but keep this in mind if you want to hack the
 audio-codec at low level.

The audio codec ought to answer even when the reference clock isn't
active.  I actually can't recall, but I think the digital side still
works.  The audio codec needs to be turned on because otherwise it will
pull the SCL and SCK lines low, blocking I2C3 from working at all.

Actually, now that I'm looking at it, we just had to make an ECO to get
rid of SPK_AMP_ON.  It is now ganged to AUDIO_PWRON, because SPK_AMP_ON
was accidentally dual-purposed as a GPIO for the front button on the
desktop / laptop.  This change was made very recently (last Friday I
think), and we'll be switching resistors on the mainboard when they're
built in order to make the change.  That pin should still be muxed as a
GPIO, it's just an input now rather than an output.


Sean
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V5] ARM: mx6: Add support for Kosagi Novena

2014-10-08 Thread Sean Cross 
On 09/10/2014 07:59, Marek Vasut wrote:
 On Wednesday, October 08, 2014 at 05:35:44 PM, picmas...@mail.bg wrote:
 Hi Sean,
 Hi all,
Hello

 - Цитат от Sean Cross (x...@kosagi.com), на 08.10.2014 в 10:47 -

 On 08/10/2014 05:55, Nikolay Dimitrov wrote:
 Hi Marek,

 I'm marking only the critical issues that are left unfixed from
 previous conversations, to speed-up the process a little bit.
 I'll send later patches for the non-critical issues to spare you the
 extra work (and I'm sure my constructive criticism is already boring

 :D ).

 On 10/06/2014 07:02 PM, Marek Vasut wrote:
 +#define NOVENA_USB_HUB_RESETIMX_GPIO_NR(7, 12)
 ...

 +/*
 + * USB
 + */
 +#ifdef CONFIG_USB_EHCI_MX6
 +int board_ehci_hcd_init(int port)
 +{
 +/* Reset USB hub */
 +if (port == 1) {
 +gpio_set_value(NOVENA_USB_HUB_RESET, 0);
 +mdelay(2);
 +gpio_set_value(NOVENA_USB_HUB_RESET, 1);
 +}
 +return 0;
 +}
 +#endif
 As we previously discussed, this pin definition conflicts with
 NOVENA_PCIE_POWER_ON_GPIO (GPIO7_IO12 is connected to PCIE_PWRON), so
 by asserting it, you'll turn-off the wrong sub-system.

 Currently the USB hub is reset only by system reset (RESETBMCU
 asserted by the PMIC). I don't see how the CPU can selectively reset
 the USB hub via a GPIO, so it would be better to remove the reset code.

 @Sean - can you please confirm/reject this finding?
 @Sean: Do you have any comments on USB hub reset stuff? Should we ditch
 entirely the reset code, or should we modify it somehow to work properly?
 OK, so it's just this USB that remains, right ?

This is correct.  There is no GPIO-based way to reset the hub.


Sean
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V5] ARM: mx6: Add support for Kosagi Novena

2014-10-08 Thread Sean Cross 
Hi Nikolay,

On 08/10/2014 23:35, picmas...@mail.bg wrote:
 Hi Sean,

 - Цитат от Sean Cross (x...@kosagi.com), на 08.10.2014 в 10:47 -

 On 08/10/2014 05:55, Nikolay Dimitrov wrote:
 Hi Marek,

 I'm marking only the critical issues that are left unfixed from
 previous conversations, to speed-up the process a little bit.
 I'll send later patches for the non-critical issues to spare you the
 extra work (and I'm sure my constructive criticism is already boring
 :D ).


 On 10/06/2014 07:02 PM, Marek Vasut wrote:
 +#define NOVENA_USB_HUB_RESETIMX_GPIO_NR(7, 12)
 ...
 +/*
 + * USB
 + */
 +#ifdef CONFIG_USB_EHCI_MX6
 +int board_ehci_hcd_init(int port)
 +{
 +/* Reset USB hub */
 +if (port == 1) {
 +gpio_set_value(NOVENA_USB_HUB_RESET, 0);
 +mdelay(2);
 +gpio_set_value(NOVENA_USB_HUB_RESET, 1);
 +}
 +return 0;
 +}
 +#endif
 As we previously discussed, this pin definition conflicts with
 NOVENA_PCIE_POWER_ON_GPIO (GPIO7_IO12 is connected to PCIE_PWRON), so
 by asserting it, you'll turn-off the wrong sub-system.

 Currently the USB hub is reset only by system reset (RESETBMCU
 asserted by the PMIC). I don't see how the CPU can selectively reset
 the USB hub via a GPIO, so it would be better to remove the reset code.

 @Sean - can you please confirm/reject this finding?
 @Sean: Do you have any comments on USB hub reset stuff? Should we ditch
 entirely the reset code, or should we modify it somehow to work properly?


 +#define NOVENA_AUDIO_PWRONIMX_GPIO_NR(5, 17)
 ...
 +/*
 + * Audio
 + */
 +static iomux_v3_cfg_t audio_pads[] = {
 +/* AUD_PWRON */
 +MX6_PAD_DISP0_DAT23__GPIO5_IO17 | MUX_PAD_CTRL(NO_PAD_CTRL),
 +};
 The speaker amplifiers will still be disabled, as AUDIO_PWRON is not
 connected to them (R30A is marked as DNP). You need to add one more
 GPIO to enable the speaker amplifiers, here's the fix:

 #define NOVENA_AUDIO_PWRONIMX_GPIO_NR(5, 17)
 #define NOVENA_AUDIO_SPK_AMP_ONIMX_GPIO_NR(4, 9)

 /*
  * Audio
  */
 static iomux_v3_cfg_t audio_pads[] = {
 /* AUD_PWRON */
 MX6_PAD_KEY_ROW1__GPIO5_IO17 | MUX_PAD_CTRL(NO_PAD_CTRL),

 /* Speakers' amplifiers #SHDWN  */
 MX6_PAD_KEY_ROW1__GPIO4_IO09 | MUX_PAD_CTRL(NO_PAD_CTRL),
 };

 static void novena_spl_setup_iomux_audio(void)
 {
 imx_iomux_v3_setup_multiple_pads(audio_pads, ARRAY_SIZE(audio_pads));

 gpio_direction_output(NOVENA_AUDIO_PWRON, 1);
 gpio_direction_output(NOVENA_AUDIO_SPK_AMP_ON, 1);
 }


 Side comment: If someone needs to talk to the Audio Codec via I2C3 in
 U-Boot environment, don't be surprised if the codec doesn't respond to
 any I2C requests at all (I've had such issues with SGTL5000). The most
 probable reason is that the codec doesn't receive reference clock from
 imx6 GPIO0. This is not a critical issues as later the kernel muxes
 this GPIO0 properly, but keep this in mind if you want to hack the
 audio-codec at low level.
 The audio codec ought to answer even when the reference clock isn't
 active.  I actually can't recall, but I think the digital side still
 works.
 Well, that would be great if it works out this way. I just shared what
 happened with another audio codec, to spare some frustration to others.


 The audio codec needs to be turned on because otherwise it will
 pull the SCL and SCK lines low, blocking I2C3 from working at all.
 Agreed.


 Actually, now that I'm looking at it, we just had to make an ECO to get
 rid of SPK_AMP_ON.  It is now ganged to AUDIO_PWRON, because SPK_AMP_ON
 was accidentally dual-purposed as a GPIO for the front button on the
 desktop / laptop.  This change was made very recently (last Friday I
 think), and we'll be switching resistors on the mainboard when they're
 built in order to make the change.
 Well, all I have is the Novena schematic 
 (http://bunniefoo.com/novena/pvt2_release/novena_pvt2.PDF) so all my analysis 
 is based on this PDF. On page 14, R30A is
 DNP, and R28A is populated, this is why I suggested this modification to 
 enable
 speaker amps. If there are schematic changes, please publish the new version
 so we can use the proper schematic and reduce spam.

 @Marek: According to this latest update, there's no need for my fix for
 NOVENA_AUDIO_SPK_AMP_ON, as your original code will work just fine with the
 planned schematic changes. Please disregard the fix.

I'll be sure to have Bunnie post a new schematic when he returns
tomorrow.  For now, the ECO on our wiki is the authoritative source. 
This is curently the only ECO for the final PVT2 board:
http://www.kosagi.com/w/index.php?title=Novena_PVT2_ECO_List#ECO22:_swap_audio_control_option


Sean
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V5] ARM: mx6: Add support for Kosagi Novena

2014-10-07 Thread Sean Cross 
On 07/10/2014 00:02, 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

This patch looks good.  It resets the FPGA, muxes the correct UART
lines, and detects USB devices.  It doesn't have the newer FEC reset
sequence, but is the idea for Nikolay to submit that separately in order
to get credit for it?


Sean

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V4] ARM: mx6: Add support for Kosagi Novena

2014-10-06 Thread Sean Cross 

Hi Marek, Nikolay,

I thought I responded, but it might have gotten lost.  I'm sorry about that.

I've taken a closer look, and responded below.

On 24/9/2014 5:40 PM, Marek Vasut wrote:

On Wednesday, September 24, 2014 at 04:46:42 AM, Nikolay Dimitrov wrote:

Hi Marek,

Following are some comments about FEC Ethernet:

On 09/23/2014 01:18 PM, Marek Vasut wrote:

+#define ENET_PAD_CTRL  \
+   (PAD_CTL_PKE | PAD_CTL_PUE |\
+   PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED   | \
+   PAD_CTL_DSE_40ohm   | PAD_CTL_HYS)
+

PAD_CTL_SPEED_MED falls on reserved bits (7-6).

Special note: PAD_CTL_DSE_40ohm is defined as 0b110, which is documented
as 37/27 ohm @2.5V. I didn't saw any notes on the PHY spec or the
Novena schematic about the routing guidelines of the RGMII data lines,
but I can extrapolate that if the 125 MHz reference clock is routed as
50-ohm line (this one is documented in the datasheet), then the data
lines are probably routed in a similar way. So the DSE value should be
0b100, which is 57/43 ohm @ 2.5V, which in turn is defined in the
headers as PAD_CTL_DSE_60ohm (this is either a bug in the header, or I'm
reading an updated FSL PDF).

Sean, can you comment on this ?


The pads probably don't support setting speed, as they're a high-speed 
RG-MII pads are high-speed anyway.  PAD_CTL_SPEED_MED can be removed.


In a pre-release version of the FSL PDF I have, 0b110 is indeed 
documented as 40 ohm.  You're correct in that it should be 50 ohm, which 
the same version of the document doesn't have.  The closes is 48 ohm, 
which is 0b101.  The older doc says 0b100 is 60 ohm, and there are no 
distinctions about voltages as there are in Rev. 1 of the pdf, which is 
probably what you're looking at.




+static void novena_spl_setup_iomux_enet(void)
+{
+   imx_iomux_v3_setup_multiple_pads(enet_pads1, ARRAY_SIZE(enet_pads1));
+   imx_iomux_v3_setup_multiple_pads(enet_pads2, ARRAY_SIZE(enet_pads2));
+
+   gpio_direction_output(IMX_GPIO_NR(3, 23), 0);
+   gpio_direction_output(IMX_GPIO_NR(6, 30), 1);
+   gpio_direction_output(IMX_GPIO_NR(6, 25), 1);
+   gpio_direction_output(IMX_GPIO_NR(6, 27), 1);
+   gpio_direction_output(IMX_GPIO_NR(6, 28), 1);
+   gpio_direction_output(IMX_GPIO_NR(6, 29), 1);
+   gpio_direction_output(IMX_GPIO_NR(6, 24), 1);
+}

I think that setting the iomuxes immediately one after the other doesn't
achieve the intended goal. After the 2nd iomux setup, the pads are
connected to the FEC, not to the GPIOs.

There's one more issue here - when you get the PHY out of reset, you'll
have to both de-assert the RESET line while keeping the strapping
signals stable so the PHY can read them, but at the same time the PHY RX
pins are becoming outputs and driving the same lines, which is not good.
I'm giving a proposal how to fix this in the end.

   +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);
   +
   +return 0;
   +}

Getting the PHY out of reset at this point causes unpredictable reset
timing - e.g. you can't guarantee how much time the chip was held in
reset. The PHY datasheet is quite unclear about this reset timing, the
only mentioned time is min. 10ms after power-on, and nothing about RESET
assertion/de-assertion. I can throw a wild guess that the reset pulse
should have similar duration, e.g. 10ms.

Here's my proposal how to fix both (line driving conflict and reset
timing) issues:

#define ENET_PHY_CFG_PC \
(PAD_CTL_HYS | PAD_CTL_PUS_22K_UP | PAD_CTL_PUE | PAD_CTL_PKE)

static iomux_v3_cfg_t enet_pads1[] = {
MX6_PAD_ENET_MDIO__ENET_MDIO| MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_ENET_MDC__ENET_MDC  | MUX_PAD_CTRL(ENET_PAD_CTRL),

MX6_PAD_RGMII_TXC__RGMII_TXC| MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_RGMII_TD0__RGMII_TD0| MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_RGMII_TD1__RGMII_TD1| MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_RGMII_TD2__RGMII_TD2| MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_RGMII_TD3__RGMII_TD3| MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_RGMII_TX_CTL__RGMII_TX_CTL| MUX_PAD_CTRL(ENET_PAD_CTRL),
MX6_PAD_ENET_REF_CLK__ENET_TX_CLK | MUX_PAD_CTRL(ENET_PAD_CTRL),

/* pin 35, PHY_AD2 */
MX6_PAD_RGMII_RXC__GPIO6_IO30   | MUX_PAD_CTRL(ENET_PHY_CFG_PC),
/* pin 32, MODE0 */
MX6_PAD_RGMII_RD0__GPIO6_IO25   | MUX_PAD_CTRL(ENET_PHY_CFG_PC),
/* pin 31, MODE1 */
MX6_PAD_RGMII_RD1__GPIO6_IO27   | MUX_PAD_CTRL(ENET_PHY_CFG_PC),
/* pin 28, MODE2 */
MX6_PAD_RGMII_RD2__GPIO6_IO28   | MUX_PAD_CTRL(ENET_PHY_CFG_PC),
/* pin 27, MODE3 */
MX6_PAD_RGMII_RD3__GPIO6_IO29   | MUX_PAD_CTRL(ENET_PHY_CFG_PC),
/* pin 33, CLK125_EN */

Re: [U-Boot] [PATCH] ARM: mx6: Add support for Kosagi Novena

2014-10-02 Thread Sean Cross 
On 28/09/2014 04:19, Marek Vasut wrote:
 On Wednesday, September 24, 2014 at 06:57:06 PM, Sean Cross wrote:

 [...]
 +#define NOVENA_AUDIO_PWRON IMX_GPIO_NR(5, 17)
 +#define NOVENA_HDMI_GHOST_HPD  IMX_GPIO_NR(5, 4)
 +#define NOVENA_PCIE_RESET_GPIO IMX_GPIO_NR(3, 29)
 +#define NOVENA_PCIE_POWER_ON_GPIO  IMX_GPIO_NR(7, 12)
 +#define NOVENA_PCIE_WAKE_UP_GPIO   IMX_GPIO_NR(3, 22)
 +#define NOVENA_PCIE_DISABLE_GPIO   IMX_GPIO_NR(2, 16)
 Add NOVENA_FPGA_RESET_N_GPIO IMX_GPIO_NR(5, 7).  If the FPGA has a
 program loaded that doesn't let the I2C pins float, then the DDR3 SPD
 will be unable to be read.
 Added and I am now setting this GPIO to 0 so the FPGA is in reset throughout 
 the 
 SPL operation. It can be brought out of reset in U-Boot itself and only when 
 it's actually used, right ?

Correct.  You can leave the FPGA in reset forever.  If it is configured
in U-Boot, then it can be brought back out of reset.

 +
 +   /* UART clocks enabled and gd valid - init serial console */
 +   preloader_console_init();
 +
 +   /* Start the DDR DRAM */
 +   mx6dq_dram_iocfg(64, novena_ddr_ioregs, novena_grp_ioregs);
 +   mx6_dram_cfg(novena_ddr_info, novena_mmdc_calib, elpida_4gib_1600);
 +
 +   /* Clear the BSS. */
 +   memset(__bss_start, 0, __bss_end - __bss_start);
 +
 +   /* load/boot image from boot device */
 +   board_init_r(NULL, 0);
 +}
 +
 +void reset_cpu(ulong addr)
 +{
 +}
 [...]

 We just received final boards on Monday.  I will try this out and report
 back.
 You should try one of the never patches .
I have built it and gotten it working on Novena.  A few notes:

USB works, but appears to take a very long time to enumerate.  I suspect
one of the hubs is still in reset.  It finds the Asix Ethernet device,
but doesn't find a USB keyboard I have plugged in.  Instead, running
usb start gives EHCI timed out on TD - token=0x80008c80, and the
keyboard shows up as Hub (12 Mb/s, 40mA) -- Lite-On Tech USB 1.1 2 port
downstream low-p.

The Ethernet address is obtained correctly from the EEPROM.

HDMI works.

SATA works.

FEC Ethernet can get an IP address.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V4] ARM: mx6: Add support for Kosagi Novena

2014-09-27 Thread Sean Cross 
I asked Bunnie about this, and the routing is 50 ohms. 

On 24 September, 2014 5:40:59 pm GMT+08:00, Marek Vasut ma...@denx.de wrote:
On Wednesday, September 24, 2014 at 04:46:42 AM, Nikolay Dimitrov
wrote:
 Hi Marek,
 
 Following are some comments about FEC Ethernet:
 
 On 09/23/2014 01:18 PM, Marek Vasut wrote:
  +#define ENET_PAD_CTRL \
  +  (PAD_CTL_PKE | PAD_CTL_PUE |\
  +  PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED   | \
  +  PAD_CTL_DSE_40ohm   | PAD_CTL_HYS)
  +
 
 PAD_CTL_SPEED_MED falls on reserved bits (7-6).
 
 Special note: PAD_CTL_DSE_40ohm is defined as 0b110, which is
documented
 as 37/27 ohm @2.5V. I didn't saw any notes on the PHY spec or the
 Novena schematic about the routing guidelines of the RGMII data
lines,
 but I can extrapolate that if the 125 MHz reference clock is routed
as
 50-ohm line (this one is documented in the datasheet), then the data
 lines are probably routed in a similar way. So the DSE value should
be
 0b100, which is 57/43 ohm @ 2.5V, which in turn is defined in the
 headers as PAD_CTL_DSE_60ohm (this is either a bug in the header, or
I'm
 reading an updated FSL PDF).

Sean, can you comment on this ?

  +static void novena_spl_setup_iomux_enet(void)
  +{
  +  imx_iomux_v3_setup_multiple_pads(enet_pads1,
ARRAY_SIZE(enet_pads1));
  +  imx_iomux_v3_setup_multiple_pads(enet_pads2,
ARRAY_SIZE(enet_pads2));
  +
  +  gpio_direction_output(IMX_GPIO_NR(3, 23), 0);
  +  gpio_direction_output(IMX_GPIO_NR(6, 30), 1);
  +  gpio_direction_output(IMX_GPIO_NR(6, 25), 1);
  +  gpio_direction_output(IMX_GPIO_NR(6, 27), 1);
  +  gpio_direction_output(IMX_GPIO_NR(6, 28), 1);
  +  gpio_direction_output(IMX_GPIO_NR(6, 29), 1);
  +  gpio_direction_output(IMX_GPIO_NR(6, 24), 1);
  +}
 
 I think that setting the iomuxes immediately one after the other
doesn't
 achieve the intended goal. After the 2nd iomux setup, the pads are
 connected to the FEC, not to the GPIOs.
 
 There's one more issue here - when you get the PHY out of reset,
you'll
 have to both de-assert the RESET line while keeping the strapping
 signals stable so the PHY can read them, but at the same time the PHY
RX
 pins are becoming outputs and driving the same lines, which is not
good.
 I'm giving a proposal how to fix this in the end.
 
   +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);
   +
   + return 0;
   +}
 
 Getting the PHY out of reset at this point causes unpredictable reset
 timing - e.g. you can't guarantee how much time the chip was held in
 reset. The PHY datasheet is quite unclear about this reset timing,
the
 only mentioned time is min. 10ms after power-on, and nothing about
RESET
 assertion/de-assertion. I can throw a wild guess that the reset pulse
 should have similar duration, e.g. 10ms.
 
 Here's my proposal how to fix both (line driving conflict and reset
 timing) issues:
 
 #define ENET_PHY_CFG_PC \
  (PAD_CTL_HYS | PAD_CTL_PUS_22K_UP | PAD_CTL_PUE | PAD_CTL_PKE)
 
 static iomux_v3_cfg_t enet_pads1[] = {
  MX6_PAD_ENET_MDIO__ENET_MDIO| MUX_PAD_CTRL(ENET_PAD_CTRL),
  MX6_PAD_ENET_MDC__ENET_MDC  | MUX_PAD_CTRL(ENET_PAD_CTRL),
 
  MX6_PAD_RGMII_TXC__RGMII_TXC| MUX_PAD_CTRL(ENET_PAD_CTRL),
  MX6_PAD_RGMII_TD0__RGMII_TD0| MUX_PAD_CTRL(ENET_PAD_CTRL),
  MX6_PAD_RGMII_TD1__RGMII_TD1| MUX_PAD_CTRL(ENET_PAD_CTRL),
  MX6_PAD_RGMII_TD2__RGMII_TD2| MUX_PAD_CTRL(ENET_PAD_CTRL),
  MX6_PAD_RGMII_TD3__RGMII_TD3| MUX_PAD_CTRL(ENET_PAD_CTRL),
  MX6_PAD_RGMII_TX_CTL__RGMII_TX_CTL| MUX_PAD_CTRL(ENET_PAD_CTRL),
  MX6_PAD_ENET_REF_CLK__ENET_TX_CLK | MUX_PAD_CTRL(ENET_PAD_CTRL),
 
  /* pin 35, PHY_AD2 */
  MX6_PAD_RGMII_RXC__GPIO6_IO30   | MUX_PAD_CTRL(ENET_PHY_CFG_PC),
  /* pin 32, MODE0 */
  MX6_PAD_RGMII_RD0__GPIO6_IO25   | MUX_PAD_CTRL(ENET_PHY_CFG_PC),
  /* pin 31, MODE1 */
  MX6_PAD_RGMII_RD1__GPIO6_IO27   | MUX_PAD_CTRL(ENET_PHY_CFG_PC),
  /* pin 28, MODE2 */
  MX6_PAD_RGMII_RD2__GPIO6_IO28   | MUX_PAD_CTRL(ENET_PHY_CFG_PC),
  /* pin 27, MODE3 */
  MX6_PAD_RGMII_RD3__GPIO6_IO29   | MUX_PAD_CTRL(ENET_PHY_CFG_PC),
  /* pin 33, CLK125_EN */
  MX6_PAD_RGMII_RX_CTL__GPIO6_IO24| MUX_PAD_CTRL(ENET_PHY_CFG_PC),
 
  /* PHY nRST */
  MX6_PAD_EIM_D23__GPIO3_IO23 | MUX_PAD_CTRL(NO_PAD_CTRL),
 };
 
 static void novena_spl_setup_iomux_enet(void)
 {
  imx_iomux_v3_setup_multiple_pads(enet_pads1,
ARRAY_SIZE(enet_pads1));
 
  /* Assert Ethernet PHY nRST */
  gpio_direction_output(IMX_GPIO_NR(3, 23), 0);
 
  /* Using imx6 internal pull-ups to drive PHY config pins during PHY
 reset */
  gpio_direction_input(IMX_GPIO_NR(6, 30)); /* PHY_AD2 = 1 */
  gpio_direction_input(IMX_GPIO_NR(6, 25)); /* MODE0 = 1 */
  gpio_direction_input(IMX_GPIO_NR(6, 27)); /* MODE1

Re: [U-Boot] [PATCH] ARM: mx6: Add support for Kosagi Novena

2014-09-25 Thread Sean Cross 


On 29/8/2014 5:30 PM, 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
---
  arch/arm/Kconfig |   4 +
  board/kosagi/novena/Kconfig  |  23 ++
  board/kosagi/novena/Makefile |  11 +
  board/kosagi/novena/novena.c | 346 +
  board/kosagi/novena/novena_spl.c | 529 +++
  board/kosagi/novena/setup.cfg|  47 
  configs/novena_defconfig |   4 +
  drivers/video/ipu_common.c   |   2 +-
  include/configs/imx6_spl.h   |   2 +-
  include/configs/novena.h | 306 ++
  10 files changed, 1272 insertions(+), 2 deletions(-)
  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

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f01ff8f..56f29a3 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -536,6 +536,9 @@ config TARGET_GW_VENTANA
  config TARGET_HUMMINGBOARD
bool Support hummingboard
  
+config TARGET_KOSAGI_NOVENA

+   bool Support Kosagi Novena
+
  config TARGET_OMAP3_OVERO
bool Support omap3_overo
  
@@ -907,6 +910,7 @@ source board/karo/tk71/Kconfig

  source board/karo/tx25/Kconfig
  source board/keymile/km_arm/Kconfig
  source board/kmc/kzm9g/Kconfig
+source board/kosagi/novena/Kconfig
  source board/logicpd/am3517evm/Kconfig
  source board/logicpd/imx27lite/Kconfig
  source board/logicpd/imx31_litekit/Kconfig
diff --git a/board/kosagi/novena/Kconfig b/board/kosagi/novena/Kconfig
new file mode 100644
index 000..4e52be9
--- /dev/null
+++ b/board/kosagi/novena/Kconfig
@@ -0,0 +1,23 @@
+if TARGET_KOSAGI_NOVENA
+
+config SYS_CPU
+   string
+   default armv7
+
+config SYS_BOARD
+   string
+   default novena
+
+config SYS_VENDOR
+   string
+   default kosagi
+
+config SYS_SOC
+   string
+   default mx6
+
+config SYS_CONFIG_NAME
+   string
+   default novena
+
+endif
diff --git a/board/kosagi/novena/Makefile b/board/kosagi/novena/Makefile
new file mode 100644
index 000..f67bbc9
--- /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+
+#
+
+ifndef CONFIG_SPL_BUILD
+obj-y  := novena.o
+else
+obj-y  := novena_spl.o
+endif
diff --git a/board/kosagi/novena/novena.c b/board/kosagi/novena/novena.c
new file mode 100644
index 000..727ce1c
--- /dev/null
+++ b/board/kosagi/novena/novena.c
@@ -0,0 +1,346 @@
+/*
+ * Novena board support
+ *
+ * Copyright (C) 2014 Marek Vasut ma...@denx.de
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+

[...]

+
+int drv_keyboard_init(void)
+{
+   int error;
+   struct stdio_dev dev = {
+   .name   = button,
+   .flags  = DEV_FLAGS_INPUT | DEV_FLAGS_SYSTEM,
+   .start  = novena_gpio_button_init,
+   .getc   = novena_gpio_button_getc,
+   .tstc   = novena_gpio_button_tstc,
+   };
+
+   error = input_init(button_input, 0);
+   if (error) {
+   debug(%s: Cannot set up input\n, __func__);
+   return -1;
+   }
+   button_input.read_keys = novena_gpio_button_read_keys;
+
+   /* Register the device. init_tegra_keyboard() will be called soon */
This may have been answered already, but will the function named 
init_tegra_keyboard() be called?  Or is there some more generic name?

+   error = input_stdio_register(dev);
+   if (error)
+   return error;
+
+   return 0;
+}
+#endif
+

[...]

+int board_early_init_f(void)
+{
+#if defined(CONFIG_VIDEO_IPUV3)
+   setup_display();
+#endif
If board_early_init_f() gets called early, then this is where you should 
set DISP0_DAT13 (GPIO5 IO13) to low, in order to ensure the FPGA is in 
reset, so it isn't pulling the DDR3 I2C lines low.


This would also be a good time to bring the sound chip out of reset, by 
driving GPIO5 IO17 high,  When the sound chip is in reset, the EEPROM 
cannot be read.



+
+   /* Bring Ethernet PHY out of reset. */
+   gpio_set_value(IMX_GPIO_NR(3, 23), 1);
+
+   return 0;
+}
+
+int board_init(void)
+{
+   /* address of boot parameters */
+   gd-bd-bi_boot_params = PHYS_SDRAM + 0x100;
+
+#ifdef CONFIG_CMD_SATA
+   setup_sata();
+#endif
+
+   return 0;
+}
+
+int checkboard(void)
+{
+   puts(Board: Novena 4x\n);
+   return 0;
+}
+
+int dram_init(void)
+{
+   gd-ram_size = imx_ddr_size();
+   return 0;
+}
+
+/* setup board specific PMIC */
+int power_init_board(void)
+{
+   struct