Yocto imx7d sabresd and AT8031 - Kernel lock/crash on fec_probe when writel or readl is used - Help!

[edwardtyrrell]

Hi All,

As mentioned I have a Yocto based 4.1.44 kernel built for imx7d on a custom board. The only real difference to that of the evk is we're using an AT8031 on our board. The device tree has had a few adjustments but nothing too serious, the AT8031 bolted straight up. However when booted the debug will stop at the probing/loading of the phy in fec_main.c.

 Around the area of fec_get_mac and/or fec_set_mac_address is the fist time the writel and readl address functions are used, and at that point the system locks/dies whatever - debug ends.

In functions:

/* fec_set_mac_address */

........

writel(ndev->dev_addr[3] | (ndev->dev_addr[2] << 8) |
(ndev->dev_addr[1] << 16) | (ndev->dev_addr[0] << 24),
fep->hwp + FEC_ADDR_LOW);
writel((ndev->dev_addr[5] << 16) | (ndev->dev_addr[4] << 24),
fep->hwp + FEC_ADDR_HIGH);

/* fec_get_mac */

*((__be32 *) &tmpaddr[0]) = cpu_to_be32(readl(fep->hwp + FEC_ADDR_LOW));

As soon as either writel or readl tries to use the address point to by fep->hwp+ofset then it's game over.

In the device tree the fec is as per the documentation => fec1: ethernet@30be0000 and the correct address. Printing out fep->hwp I get  f5be0000, which I'm not sure if it's been remapped / virtual or just incorrect. Any case my system dies at this point. Please help as I'm out of ideas here!

I've tried Rocko andKrogoth builds - no difference.

Thanks.

[edwardtyrrell · Accepted solution]

Solved! The problem was an incorrect version of u-boot. The u-boot in my mfgtool was built without an FEC in the device tree, I suspect without it various hardware/peripherals/allocations weren't satisfied so when running up the kernel/dtb that did have an FEC things fell apart.

Thanks All.

[igorpadykov]

Hi Edward

lock reason may be in improper enet clocks, they are configured in IOMUXC_GPR_GPR1

register with ENETn_CLK_DIR,ENETn_TX_CLK_SEL bites. One can try with nxp kernel

linux-imx - i.MX Linux kernel 

linux/arch/arm/boot/dts/imx7d-sdb.dts

imx7d-sdb.dts\dts\boot\arm\arch - linux-imx - i.MX Linux kernel 

linux/drivers/net/ethernet/freescale/fec_main.c

fec_main.c\freescale\ethernet\net\drivers - linux-imx - i.MX Linux kernel 

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[edwardtyrrell]

Hi Igor,

It's the same as what I'm using. So I can understand a bit more of the imx7/eth internals could you provide a brief answer for each question please?

1) Using the AT8031 which way is the clock recommended to go, i.e the AT8031's clock is fed into the imx7/eth, AT8031 => CLK => imx7   OR     imx7 => CLK = AT8031? 

2) At this stage in the code there is no physical communication to the AT8031, all lines except reset are inactive so I cannot switch the clocks if I wanted too. The AT8031 defaults to output a clock on CLK_25M so should this be fed to the imx7?

3) Finally, since the eth1 phy is actually built in to the imx7 processor why doesn't simple addressed readl and writel work for basic registers like    30BE_0024 Ethernet Control Register (ENET1_ECR) for example?

Thanks! 

[igorpadykov]

Hi Edward

1. any option can be used, IOMUXC_GPR_GPR1 should be configured properly.

2. pelase use AT8031 datasheet for clock requirements and clock requirements

given in sect.4.10.3 Ethernet controller (ENET) i.MX7D Datasheet

http://cache.nxp.com/files/32bit/doc/data_sheet/IMX7DCEC.pdf
3. I do not think that eth phy is built into i.MX7D. readl and writel for i.MX7D ENET registers 

may not work without properly configured ENET module clocks.

Best regards
igor

[edwardtyrrell]

Hi Igor,

Thanks for your help. Finally, looking at other peoples boot debug I notice that => [  libphy: fec_enet_mii_bus: probed  ] gets performed before starting up any eth1, mine does not. Is this %100 necessary?

Thanks.