...

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?

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

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.

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.

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.