[U-Boot] Possible Denx m28evk ethernet problem + solution

[U-Boot] Possible Denx m28evk ethernet problem + solution

[Robert Deliën]

Hi Marek,

I'm currently working on U-Boot support for the Freescale i.mx28evk board. It started out as
an update of the old Freescale supplied U-Boot 2009.08, but it ended up in reconfiguring
your work on the Denx m28evk module. Today I stumbled upon a problem with Ethernet.

It turned out that communication with the PHYs didn't work, because the SoC isn't supplying
ENET_CLK. The Ethernet clock is configured properly by cpu_eth_init in
./arch/arm/cpu/arm926ejs/mx28/mx28.c. But later in the boot process, board_eth_init in
board/denx/m28evk/m28evk.c tries to configure the Ethernet clock again. Unfortunately that
second configuration is just disabling the clock:
	clrsetbits_le32(&clkctrl_regs->hw_clkctrl_enet,
		CLKCTRL_ENET_TIME_SEL_MASK | CLKCTRL_ENET_CLK_OUT_EN,
		CLKCTRL_ENET_TIME_SEL_RMII_CLK);
After removing this line, I measured a 25MHz clock, communication with the PHYs worked
and I successfully tftp'ed a kernel from my server.

Does Ethernet on your board work? Does you board have an external clock oscillator for
the PHYs? If not, do you agree with removing this line?

Cheers,

        Robert.

[U-Boot] Possible Denx m28evk ethernet problem + solution

[Marek Vasut]

> Hi Marek,
> 
> I'm currently working on U-Boot support for the Freescale i.mx28evk board.

This is already supported mainline.

> It started out as an update of the old Freescale supplied U-Boot 2009.08,
> but it ended up in reconfiguring your work on the Denx m28evk module.
> Today I stumbled upon a problem with Ethernet.
> 
> It turned out that communication with the PHYs didn't work, because the SoC
> isn't supplying ENET_CLK.

The DENX board is actually ok, working properly, you don't understand what's 
going on in there. The RMII mode of PHY supplies clock to CPU. Read the manual 
before you start doing some wild acusations please :-)

> The Ethernet clock is configured properly by
> cpu_eth_init in ./arch/arm/cpu/arm926ejs/mx28/mx28.c. But later in the
> boot process, board_eth_init in board/denx/m28evk/m28evk.c tries to
> configure the Ethernet clock again. Unfortunately that second
> configuration is just disabling the clock:
> 	clrsetbits_le32(&clkctrl_regs->hw_clkctrl_enet,
> 		CLKCTRL_ENET_TIME_SEL_MASK | CLKCTRL_ENET_CLK_OUT_EN,
> 		CLKCTRL_ENET_TIME_SEL_RMII_CLK);
> After removing this line, I measured a 25MHz clock, communication with the
> PHYs worked and I successfully tftp'ed a kernel from my server.

It's different -- M28EVK and MX28EVK are.
> 
> Does Ethernet on your board work?

Yes.

> Does you board have an external clock
> oscillator for the PHYs?

Yes.

> If not, do you agree with removing this line?

No.

> 
> Cheers,
> 
>         Robert.

M

[U-Boot] Possible Denx m28evk ethernet problem + solution

[Robert Deliën]

>> I'm currently working on U-Boot support for the Freescale i.mx28evk board.
> 
> This is already supported mainline.

Hm; my workspace is quite up-to-date, but I didn't find it. What configuration
should I use for the Freescale i.mx28evk board? m28evk_config boots the
board, but not much more. The difference between the Freescale i.mx28evk
board and the Denx m28evk modules are too big (eg. ssp2 for mmc1, etc.)

> The DENX board is actually ok, working properly,

I don't doubt the working of the Denx module; I'm sure it works fine, but I don't
have one laying around, so I cannot check. However, the configuration for the
Denx m28evk module doesn't work very well on the Freescale i.mx28evk board.

> you don't understand what's 
> going on in there.

No need to be harsh; I don't have a diagram of the Denx board, so I don't
know what clock configuration was chosen for it's design.

> The RMII mode of PHY supplies clock to CPU. Read the manual 
> before you start doing some wild acusations please :-)

On my board, there wasn't any clock signal between the SoC and the PHYs,
regardless of who's supposed to source it. I can lift R171 and check who's
supplying it after my modification, but I'm pretty sure it's the SoC. This situation
works, but may still be wrong; No argument there. But this is the same
situation as the old Freescale supplied u-boot 2009.08 does it.

I don't see how the LAN8720 PHY can supply a clock to the SoC. XTAL1 is
an output only and XTAL2 is only intended to drive a chrystal, and not
connected anyway. Are we talking about the same board?

>> The Ethernet clock is configured properly by
>> cpu_eth_init in ./arch/arm/cpu/arm926ejs/mx28/mx28.c. But later in the
>> boot process, board_eth_init in board/denx/m28evk/m28evk.c tries to
>> configure the Ethernet clock again. Unfortunately that second
>> configuration is just disabling the clock:
>> 	clrsetbits_le32(&clkctrl_regs->hw_clkctrl_enet,
>> 		CLKCTRL_ENET_TIME_SEL_MASK | CLKCTRL_ENET_CLK_OUT_EN,
>> 		CLKCTRL_ENET_TIME_SEL_RMII_CLK);
>> After removing this line, I measured a 25MHz clock, communication with the
>> PHYs worked and I successfully tftp'ed a kernel from my server.
> 
> It's different -- M28EVK and MX28EVK are.

Yes, I know. I'm working with the MX28EVK, not the M28EVK.

>> Does you board have an external clock
>> oscillator for the PHYs?
> 
> Yes.

Aha, so we are talking about different boards.

>> If not, do you agree with removing this line?
> 
> No.

I'm sorry; I asked the wrong question. What I should have asked was: Do you agree
with not copying this line to the MX28EVK configuration?

[U-Boot] Possible Denx m28evk ethernet problem + solution

[Marek Vasut]

> >> I'm currently working on U-Boot support for the Freescale i.mx28evk
> >> board.
> > 
> > This is already supported mainline.
> 
> Hm; my workspace is quite up-to-date, but I didn't find it. What
> configuration should I use for the Freescale i.mx28evk board?
> m28evk_config boots the board, but not much more. The difference between
> the Freescale i.mx28evk board and the Denx m28evk modules are too big (eg.
> ssp2 for mmc1, etc.)

make mx28evk_config? board/freescale/mx28evk
> 
> > The DENX board is actually ok, working properly,
> 
> I don't doubt the working of the Denx module; I'm sure it works fine, but I
> don't have one laying around, so I cannot check.

I did check, don't worry.

> However, the
> configuration for the Denx m28evk module doesn't work very well on the
> Freescale i.mx28evk board.

That's to be expected!
> 
> > you don't understand what's
> > going on in there.
> 
> No need to be harsh; I don't have a diagram of the Denx board, so I don't
> know what clock configuration was chosen for it's design.

Sorry, it wasn't meant to be too direct.
> 
> > The RMII mode of PHY supplies clock to CPU. Read the manual
> > before you start doing some wild acusations please :-)
> 
> On my board, there wasn't any clock signal between the SoC and the PHYs,
> regardless of who's supposed to source it. I can lift R171 and check who's
> supplying it after my modification, but I'm pretty sure it's the SoC. This
> situation works, but may still be wrong; No argument there. But this is
> the same situation as the old Freescale supplied u-boot 2009.08 does it.

Yes, it can go both ways.
> 
> I don't see how the LAN8720 PHY can supply a clock to the SoC. XTAL1 is
> an output only and XTAL2 is only intended to drive a chrystal, and not
> connected anyway. Are we talking about the same board?

The PHY doesn't supply clock on mx28evk, CPU does.
> 
> >> The Ethernet clock is configured properly by
> >> cpu_eth_init in ./arch/arm/cpu/arm926ejs/mx28/mx28.c. But later in the
> >> boot process, board_eth_init in board/denx/m28evk/m28evk.c tries to
> >> configure the Ethernet clock again. Unfortunately that second
> >> 
> >> configuration is just disabling the clock:
> >> 	clrsetbits_le32(&clkctrl_regs->hw_clkctrl_enet,
> >> 	
> >> 		CLKCTRL_ENET_TIME_SEL_MASK | CLKCTRL_ENET_CLK_OUT_EN,
> >> 		CLKCTRL_ENET_TIME_SEL_RMII_CLK);
> >> 
> >> After removing this line, I measured a 25MHz clock, communication with
> >> the PHYs worked and I successfully tftp'ed a kernel from my server.
> > 
> > It's different -- M28EVK and MX28EVK are.
> 
> Yes, I know. I'm working with the MX28EVK, not the M28EVK.
> 
> >> Does you board have an external clock
> >> oscillator for the PHYs?
> > 
> > Yes.
> 
> Aha, so we are talking about different boards.
> 
> >> If not, do you agree with removing this line?
> > 
> > No.
> 
> I'm sorry; I asked the wrong question. What I should have asked was: Do you
> agree with not copying this line to the MX28EVK configuration?

Yea ...

M28EVK: PHY supplies clock to CPU
MX28EVK: CPU supplies clock to PHY

Still, the support is already there.

M

[U-Boot] Possible Denx m28evk ethernet problem + solution

[Robert Deliën]

> make mx28evk_config? board/freescale/mx28evk

Are you sure you checked it in? I checked, but I couldn't find it.
(http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=tree;f=include/configs;h=fe894c3b95e3d154264c2f8731b668c410131f01;hb=HEAD)

> Yes, it can go both ways.

For the SoC I understand. But he PHYs on the Freescale don't, as
far as I know.
Anyway, the Denx module probably uses more advanced PHYs.

> The PHY doesn't supply clock on mx28evk, CPU does.

I'm glad we agree here.

> Yea ...
> 
> M28EVK: PHY supplies clock to CPU
> MX28EVK: CPU supplies clock to PHY

It's getting rather obvious, now you've given me a bit of insight in the
differences between both boards. Thanks.

> Still, the support is already there.

I figured that too; I expected you probably made that first before moving
on to the Denx module. But I couldn't find it.
At first I thought m28evk_config would support it (too). The similarity in
names suggests similarity in boards. But after patching too much code,
I figured to implement mx28evk_config and board/freescale/mx28evk
myself. What a waste of time.... At least it was a good exercise before
our product boards arrive next week.

I just pulled my git repository and Make can't find a rule to make
mx28evk_config, so it's really not there. Not even hidden in another
configuration.

Wasn't it removed, since the Freescale implementation in 2009.08
broke?

Robert.

[U-Boot] Possible Denx m28evk ethernet problem + solution

[Marek Vasut]

> > make mx28evk_config? board/freescale/mx28evk
> 
> Are you sure you checked it in? I checked, but I couldn't find it.
> (http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=tree;f=include/config
> s;h=fe894c3b95e3d154264c2f8731b668c410131f01;hb=HEAD)

It's in u-boot-imx tree.

> 
> > Yes, it can go both ways.
> 
> For the SoC I understand. But he PHYs on the Freescale don't, as
> far as I know.
> Anyway, the Denx module probably uses more advanced PHYs.

Different one, I dunno if it's more advanced or not.

> 
> > The PHY doesn't supply clock on mx28evk, CPU does.
> 
> I'm glad we agree here.
> 
> > Yea ...
> > 
> > M28EVK: PHY supplies clock to CPU
> > MX28EVK: CPU supplies clock to PHY
> 
> It's getting rather obvious, now you've given me a bit of insight in the
> differences between both boards. Thanks.

You're welcome

> 
> > Still, the support is already there.
> 
> I figured that too; I expected you probably made that first before moving
> on to the Denx module.

Fabio did (Cced), after DENX module was supported.

Please always Cc the mailing list etc.

> But I couldn't find it.
> At first I thought m28evk_config would support it (too). The similarity in
> names suggests similarity in boards. But after patching too much code,
> I figured to implement mx28evk_config and board/freescale/mx28evk
> myself. What a waste of time.... At least it was a good exercise before
> our product boards arrive next week.
> 
> I just pulled my git repository and Make can't find a rule to make
> mx28evk_config, so it's really not there. Not even hidden in another
> configuration.
> 
> Wasn't it removed, since the Freescale implementation in 2009.08
> broke?

No, see above.

M
> 
> Robert.

[U-Boot] Possible Denx m28evk ethernet problem + solution

[Fabio Estevam]

On Fri, Jan 6, 2012 at 3:54 PM, Robert Deli?n <robert@delien.nl> wrote:
> Hi Marek,
>
> I'm currently working on U-Boot support for the Freescale i.mx28evk board. It started out as
> an update of the old Freescale supplied U-Boot 2009.08, but it ended up in reconfiguring
> your work on the Denx m28evk module. Today I stumbled upon a problem with Ethernet.
>
> It turned out that communication with the PHYs didn't work, because the SoC isn't supplying
> ENET_CLK. The Ethernet clock is configured properly by cpu_eth_init in
> ./arch/arm/cpu/arm926ejs/mx28/mx28.c. But later in the boot process, board_eth_init in
> board/denx/m28evk/m28evk.c tries to configure the Ethernet clock again. Unfortunately that
> second configuration is just disabling the clock:
> ? ? ? ?clrsetbits_le32(&clkctrl_regs->hw_clkctrl_enet,
> ? ? ? ? ? ? ? ?CLKCTRL_ENET_TIME_SEL_MASK | CLKCTRL_ENET_CLK_OUT_EN,
> ? ? ? ? ? ? ? ?CLKCTRL_ENET_TIME_SEL_RMII_CLK);
> After removing this line, I measured a 25MHz clock, communication with the PHYs worked
> and I successfully tftp'ed a kernel from my server.
>
> Does Ethernet on your board work? Does you board have an external clock oscillator for
> the PHYs? If not, do you agree with removing this line?

Please use Stefano's imx git tree, which has support for mx28evk already.

m28evk and mx28evk differ in the way they driver their Ethernet PHYs.

Let me know if you have any issues.

Regards,

Fabio Estevam

[U-Boot] Possible Denx m28evk ethernet problem + solution

[Robert Deliën]

> Please use Stefano's imx git tree, which has support for mx28evk already.

Thanks for the heads-up. It's a bit confusing and unexpected to have a mainline spread across different git trees; Will Stefano's mainline be integrated into the main-mainline sometime?

> m28evk and mx28evk differ in the way they driver their Ethernet PHYs.

Yes, Marek has patiently explained that to me; It's all clear now. But it was a good exercise because our product board has a different phy too.

> Let me know if you have any issues.

I have a question: The auto-detected SDRAM size is parsed form SPL to U-Boot through both scrathch1 and scratch2, probably as a safeguard not to assume any value to be a valid one. Did you ever see the error or different scratch values occur? I never did. But what I do see occur every now and then is a value of 0 in both registers, mostly after obscure reset scenarios.

Can we agree on a different algo to determine the validity of SDRAM size? I'm thinking somewhere around the line of a power of 2 between 2MiB and 1GiB. Preferable I'd like to use only 1 scratch register for that. The other scratch register could then be used to store the boot-mode value during SPL stage. The boot mode value is useful for boards capable of booting from different MMC devices, like ours.

BTW: My version has both MMCs, both Ethernet intefaces and NAND working for the evk. I have also typed in regs-digctl.h. I can send you or Stefano my files, if they're any use to you.

Cheers,

         Robert.

[U-Boot] Possible Denx m28evk ethernet problem + solution

[Marek Vasut]

> > Please use Stefano's imx git tree, which has support for mx28evk already.
> 
> Thanks for the heads-up. It's a bit confusing and unexpected to have a
> mainline spread across different git trees; Will Stefano's mainline be
> integrated into the main-mainline sometime?

Not really ... that's how it all works. When Stefano sends pull RQ, it'll go 
mainline.
> 
> > m28evk and mx28evk differ in the way they driver their Ethernet PHYs.
> 
> Yes, Marek has patiently explained that to me; It's all clear now. But it
> was a good exercise because our product board has a different phy too.
> 
> > Let me know if you have any issues.
> 
> I have a question: The auto-detected SDRAM size is parsed form SPL to
> U-Boot through both scrathch1 and scratch2, probably as a safeguard not to
> assume any value to be a valid one. Did you ever see the error or
> different scratch values occur? I never did. But what I do see occur every
> now and then is a value of 0 in both registers, mostly after obscure reset
> scenarios.

I see no problems with the board DRAM detection on our board, no. I tested this 
quite thoroughly.

I don't see the registers differ either ... ever. I suspect your problem is with 
your DRAM configuration data -- if your DRAM chip is misconfigured, you'll get 
such memory problems.

> 
> Can we agree on a different algo to determine the validity of SDRAM size?
> I'm thinking somewhere around the line of a power of 2 between 2MiB and
> 1GiB. Preferable I'd like to use only 1 scratch register for that. The
> other scratch register could then be used to store the boot-mode value
> during SPL stage. The boot mode value is useful for boards capable of
> booting from different MMC devices, like ours.

RFC/patch is always welcome.
> 
> BTW: My version has both MMCs, both Ethernet intefaces and NAND working for
> the evk.

MX28EVK has no NAND if I understand it correctly.

> I have also typed in regs-digctl.h. I can send you or Stefano my
> files, if they're any use to you.

Make a patch and submit to the mailing list, like everyone else does please. 
Don't try to reinvent wheel ... square one this time even.
> 
> Cheers,
> 
>          Robert.

M

[U-Boot] Possible Denx m28evk ethernet problem + solution

[Robert Deliën]

> Not really ... that's how it all works. When Stefano sends pull RQ, it'll go 
> mainline.

Aha, so it's not mainline yet after all ;-) But I get it; It's available in Fabio's
repo and will be in Denx mainline soon.

> I see no problems with the board DRAM detection on our board, no. I tested this 
> quite thoroughly.
> 
> I don't see the registers differ either ... ever. I suspect your problem is with 
> your DRAM configuration data -- if your DRAM chip is misconfigured, you'll get 
> such memory problems.

It works beautifully; I have no reason to assume there's anything wrong with it.
When it detects 0 MiB SDRAM, it's been my own fault so far: Obscure reset
scenarios, incremental builds where a clean build was due, etc.

> RFC/patch is always welcome.

Great. I'll see what I can come up with.

> MX28EVK has no NAND if I understand it correctly.

It has one of these beautiful TSOP-48 footprint compatible ZIF sockets on board.
Standard it's empty, but with a Samsung K9G08UOM in it, it worked out-of-the-box
using your m28evk configuration.
However mx28evk NAND is mutually exclusive with the use of MMC1 socket
because of shared pins. So in my config, CMD_NAND is used to configure in
NAND and to configure out MMC1.

> Make a patch and submit to the mailing list, like everyone else does please. 
> Don't try to reinvent wheel ... square one this time even.

It's hardly worth a patch; Perhaps Fabio already typed his own. But I'll submit
one tomorrow anyway.

Robert.

[U-Boot] Possible Denx m28evk ethernet problem + solution

[Marek Vasut]

> > Not really ... that's how it all works. When Stefano sends pull RQ, it'll
> > go mainline.
> 
> Aha, so it's not mainline yet after all ;-) But I get it; It's available in
> Fabio's repo and will be in Denx mainline soon.

Stefano's ... but it's almost mainline, for imx development, that's what you 
should use anyway.

> 
> > I see no problems with the board DRAM detection on our board, no. I
> > tested this quite thoroughly.
> > 
> > I don't see the registers differ either ... ever. I suspect your problem
> > is with your DRAM configuration data -- if your DRAM chip is
> > misconfigured, you'll get such memory problems.
> 
> It works beautifully; I have no reason to assume there's anything wrong
> with it. When it detects 0 MiB SDRAM, it's been my own fault so far:
> Obscure reset scenarios, incremental builds where a clean build was due,
> etc.

Can you pinpoint the problem ? Your description is quite vague ...
> 
> > RFC/patch is always welcome.
> 
> Great. I'll see what I can come up with.
> 
> > MX28EVK has no NAND if I understand it correctly.
> 
> It has one of these beautiful TSOP-48 footprint compatible ZIF sockets on
> board. Standard it's empty, but with a Samsung K9G08UOM in it, it worked
> out-of-the-box using your m28evk configuration.

Muhehe, of course ... the code is state-of-the-art top-notch thing :-D

> However mx28evk NAND is mutually exclusive with the use of MMC1 socket
> because of shared pins. So in my config, CMD_NAND is used to configure in
> NAND and to configure out MMC1.
> 
> > Make a patch and submit to the mailing list, like everyone else does
> > please. Don't try to reinvent wheel ... square one this time even.
> 
> It's hardly worth a patch; Perhaps Fabio already typed his own. But I'll
> submit one tomorrow anyway.

Please do, thanks

M
> 
> Robert.