[U-Boot] Mainline u-boot SPL for socfpga
Hello I am trying to understand the state of the socfpga preloader in mainline u-boot. >From what I see, this is broken and perhaps has never worked. When I build the code in u-boot-socfpga I get a healthy working u-boot-spl.bin of approx 45kbytes. When I build the mainline u-boot code I get a broken u-boot-spl.bin of approx 3kbytes. It seems the mainline u-boot is missing stuff, including the all-critical sdram initialisation without which the SPL is useless. So, I have a few related questions: 1. The SDRAM init code, like other SocFPGA "hand-off" files is generated by the Altera tools. Since it is not hand written, and is not compliant with u-boot coding style. Is it more important to preserve coding style and have a broken SPL than it is to have a working SPL and broken code? 2. Is there a practical "half-way" compromise whereby the generated code is run through lindent and we just accept that this is as good as it gets? 3. Can we get some sort of coding style waiver, considering that this code is off in a board file and does not impact on anyone working on anything other than socfpga (indeed nobody even working on socfpga even reads it). Clearly significant hand editing generated code makes for a very broken workflow, but running it through an automated step like lindent is Ok from a workflow point of view. Unless this can be resolved we end up with a situation where people working on SocFPGA are forced to fork for practical reasons. Regards Charles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Mainline u-boot SPL for socfpga
Hi Charles, On Tue, 2014-05-06 at 12:22 +1200, Charles Manning wrote: > Hello > > > I am trying to understand the state of the socfpga preloader in > mainline u-boot. > > > From what I see, this is broken and perhaps has never worked. > > > When I build the code in u-boot-socfpga I get a healthy working > u-boot-spl.bin of approx 45kbytes. > > > When I build the mainline u-boot code I get a broken u-boot-spl.bin of > approx 3kbytes. > > > It seems the mainline u-boot is missing stuff, including the > all-critical sdram initialisation without which the SPL is useless. > > As of now, we have most of the drivers already upstreamed to main line. The missing piece here are the SDRAM driver. The SDRAM driver poses a big challenge as its now licensed under BSD-3 clause. I am still working with legal team to look into potential to make it GPL license. > So, I have a few related questions: > > > 1. The SDRAM init code, like other SocFPGA "hand-off" files is > generated by the Altera tools. Since it is not hand written, and is > not compliant with u-boot coding style. Is it more important to > preserve coding style and have a broken SPL than it is to have a > working SPL and broken code? > The SDRAM handoff files generated by tools is not compliance as the original code developer doesn't familiar with open source world. But if you look into the SDRAM handoff files within rocketboard.org git, the existing code already updated. I enhanced the code to ensure it meet with basic coding standard. But further enhancement is needed and on-going now. > > 2. Is there a practical "half-way" compromise whereby the generated > code is run through lindent and we just accept that this is as good as > it gets? > > The on-going plan now is to use the enhanced SDRAM handoff file at rocketboard.org. From there, we want to streamline the driver by removing unused code. Once its ready, we will upstream this file. > 3. Can we get some sort of coding style waiver, considering that this > code is off in a board file and does not impact on anyone working on > anything other than socfpga (indeed nobody even working on socfpga > even reads it). > > > Clearly significant hand editing generated code makes for a very > broken workflow, but running it through an automated step like lindent > is Ok from a workflow point of view. > > > Unless this can be resolved we end up with a situation where people > working on SocFPGA are forced to fork for practical reasons. I believe it would be tough to get the waiver. Nevertheless, we are further enhancing the handoff files to a state which is good for upstreaming. At same time, I am also working with tools team to ensure all these enhancement is putting back to original code. Thanks Chin Liang > > > Regards > > > Charles > > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Mainline u-boot SPL for socfpga
On Thu, May 8, 2014 at 10:24 PM, Chin Liang See wrote: > Hi Charles, > > > On Tue, 2014-05-06 at 12:22 +1200, Charles Manning wrote: > > Hello > > > > > > I am trying to understand the state of the socfpga preloader in > > mainline u-boot. > > > > > > From what I see, this is broken and perhaps has never worked. > > > > > > When I build the code in u-boot-socfpga I get a healthy working > > u-boot-spl.bin of approx 45kbytes. > > > > > > When I build the mainline u-boot code I get a broken u-boot-spl.bin of > > approx 3kbytes. > > > > > > It seems the mainline u-boot is missing stuff, including the > > all-critical sdram initialisation without which the SPL is useless. > > > > > As of now, we have most of the drivers already upstreamed to main line. > The missing piece here are the SDRAM driver. The SDRAM driver poses a > big challenge as its now licensed under BSD-3 clause. I am still working > with legal team to look into potential to make it GPL license. > > > > So, I have a few related questions: > > > > > > 1. The SDRAM init code, like other SocFPGA "hand-off" files is > > generated by the Altera tools. Since it is not hand written, and is > > not compliant with u-boot coding style. Is it more important to > > preserve coding style and have a broken SPL than it is to have a > > working SPL and broken code? > > > > The SDRAM handoff files generated by tools is not compliance as the > original code developer doesn't familiar with open source world. But if > you look into the SDRAM handoff files within rocketboard.org git, the > existing code already updated. I enhanced the code to ensure it meet > with basic coding standard. But further enhancement is needed and > on-going now. > What is really needed is that the hand-off files are actually generated as compliant code. Enhancing and hand-editing then checking in machine generated code is a broken work-flow because: 1) It has to be redone every time the code is regenerated. 2) There are so many changes that it is impossible to check for errors and diff for changes. > > > > > 2. Is there a practical "half-way" compromise whereby the generated > > code is run through lindent and we just accept that this is as good as > > it gets? > > > > > The on-going plan now is to use the enhanced SDRAM handoff file at > rocketboard.org. From there, we want to streamline the driver by > removing unused code. Once its ready, we will upstream this file. > > That might work if it is a once-off exercise that places the sdram code in arch/arm/cpu/armv7/socfpga The only stuff that should really be in a board/xxx directory is board-specific stuff and "tuning files". In other words: * sequence.c (a file of over 11000 lines of C code) should be in arch/.../scofpga * sequencer_auto_ac_init.c (300 lines of board-specific register config values) should be in board/.../socfpga > > 3. Can we get some sort of coding style waiver, considering that this > > code is off in a board file and does not impact on anyone working on > > anything other than socfpga (indeed nobody even working on socfpga > > even reads it). > > > > > > Clearly significant hand editing generated code makes for a very > > broken workflow, but running it through an automated step like lindent > > is Ok from a workflow point of view. > > > > > > Unless this can be resolved we end up with a situation where people > > working on SocFPGA are forced to fork for practical reasons. > > > I believe it would be tough to get the waiver. Nevertheless, we are > further enhancing the handoff files to a state which is good for > upstreaming. At same time, I am also working with tools team to ensure > all these enhancement is putting back to original code. > Maybe splitting the code better as I suggest above would make this far simpler. If the board specific part of the hand-offs is reduced to just header files and register config tables, then it is a trivial matter to run them through an extra **automated** step to produce a compliant file. Apart from gaining the mainstreaming, this would also make it far easier to create configs for different boards (eg. sockit board would just become a few hundred lines of register configs and not 13 thousand lines of code - most of that duplicated between platforms). Regards Charles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Mainline u-boot SPL for socfpga
Hi! > I am trying to understand the state of the socfpga preloader in mainline > u-boot. > > >From what I see, this is broken and perhaps has never worked. That's correct AFAICT. > When I build the code in u-boot-socfpga I get a healthy working > u-boot-spl.bin of approx 45kbytes. > > When I build the mainline u-boot code I get a broken u-boot-spl.bin of > approx 3kbytes. > > It seems the mainline u-boot is missing stuff, including the all-critical > sdram initialisation without which the SPL is useless. Are you able to build working u-boot proper from recent sources? I know u-boot SPL misses critical parts, but I was told that u-boot proper should have everything. Only... I was not able to get it to work. [I'm attempting to load recent u-boot from patched/old u-boot; I know this is not exactly recommended, but due to spl/proper split, it should work AFAIK... and does for old versions.] Any ideas? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Mainline u-boot SPL for socfpga
On Thursday 15 May 2014 04:42:58 Pavel Machek wrote: > Hi! > > > I am trying to understand the state of the socfpga preloader in mainline > > u-boot. > > > > >From what I see, this is broken and perhaps has never worked. > > That's correct AFAICT. > > > When I build the code in u-boot-socfpga I get a healthy working > > u-boot-spl.bin of approx 45kbytes. > > > > When I build the mainline u-boot code I get a broken u-boot-spl.bin of > > approx 3kbytes. > > > > It seems the mainline u-boot is missing stuff, including the all-critical > > sdram initialisation without which the SPL is useless. > > Are you able to build working u-boot proper from recent sources? > > I know u-boot SPL misses critical parts, but I was told that u-boot > proper should have everything. Only... I was not able to get it to > work. [I'm attempting to load recent u-boot from patched/old u-boot; I > know this is not exactly recommended, but due to spl/proper split, it > should work AFAIK... and does for old versions.] I have not tried booting u-boot proper from mainline. It just seemed pointless to me to be working from 2 source trees to make a single product. I will give it a go though. As Chin Liang See has said, there are two issues thwarting this: legal AND source conformance. The code we can fix, the legal can only be fixed by bending Altera - I am going to do that too. Regards Charles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Mainline u-boot SPL for socfpga
Hi, On Thu, 2014-05-15 at 07:01 +1200, Charles Manning wrote: > On Thursday 15 May 2014 04:42:58 Pavel Machek wrote: > > Hi! > > > > > I am trying to understand the state of the socfpga preloader in mainline > > > u-boot. > > > > > > >From what I see, this is broken and perhaps has never worked. > > > > That's correct AFAICT. Yup, Preloader without the SDRAM would not work correctly. > > > > > When I build the code in u-boot-socfpga I get a healthy working > > > u-boot-spl.bin of approx 45kbytes. > > > > > > When I build the mainline u-boot code I get a broken u-boot-spl.bin of > > > approx 3kbytes. > > > > > > It seems the mainline u-boot is missing stuff, including the all-critical > > > sdram initialisation without which the SPL is useless. > > > > Are you able to build working u-boot proper from recent sources? > > > > I know u-boot SPL misses critical parts, but I was told that u-boot > > proper should have everything. Only... I was not able to get it to > > work. [I'm attempting to load recent u-boot from patched/old u-boot; I > > know this is not exactly recommended, but due to spl/proper split, it > > should work AFAIK... and does for old versions.] > > I have not tried booting u-boot proper from mainline. It just seemed > pointless > to me to be working from 2 source trees to make a single product. > > I will give it a go though. Actually the U-Boot is working. You just need to #undef CONFIG_SOCFPGA_VIRTUAL_TARGET and build it. I loaded it using a working Preloader and I can reach the U-Boot console. U-Boot SPL 2013.01.01 (May 16 2014 - 10:42:39) BOARD : Altera SOCFPGA Cyclone V Board CLOCK: EOSC1 clock 25000 KHz CLOCK: EOSC2 clock 25000 KHz CLOCK: F2S_SDR_REF clock 0 KHz CLOCK: F2S_PER_REF clock 0 KHz CLOCK: MPU clock 925 MHz CLOCK: DDR clock 400 MHz CLOCK: UART clock 10 KHz CLOCK: MMC clock 5 KHz CLOCK: QSPI clock 37 KHz INFO : Watchdog enabled SDRAM: Initializing MMR registers SDRAM: Calibrating PHY SEQ.C: Preparing to start memory calibration SEQ.C: CALIBRATION PASSED SDRAM: 1024 MiB SDRAM: ECC Enabled ALTERA DWMMC: 0 reading u-boot.img reading u-boot.img U-Boot 2014.07-rc1-00079-g2072e72-dirty (May 16 2014 - 15:54:55) CPU : Altera SOCFPGA Platform BOARD : Altera SOCFPGA Cyclone5 Board DRAM: 1 GiB WARNING: Caches not enabled Using default environment In:serial Out: serial Err: serial Net: No ethernet found. Hit any key to stop autoboot: 0 Wrong Image Format for bootm command ERROR: can't get kernel image! SOCFPGA_CYCLONE5 # help ? - alias for 'help' base- print or set address offset bdinfo - print Board Info structure boot- boot default, i.e., run 'bootcmd' bootd - boot default, i.e., run 'bootcmd' bootm - boot application image from memory bootp - boot image via network using BOOTP/TFTP protocol cmp - memory compare coninfo - print console devices and information cp - memory copy crc32 - checksum calculation echo- echo args to console editenv - edit environment variable env - environment handling commands exit- exit script false - do nothing, unsuccessfully fatinfo - print information about filesystem fatload - load binary file from a dos filesystem fatls - list files in a directory (default /) fdt - flattened device tree utility commands go - start application at address 'addr' help- print command description/usage iminfo - print header information for application image imxtract- extract a part of a multi-image itest - return true/false on integer compare loadb - load binary file over serial line (kermit mode) loads - load S-Record file over serial line loadx - load binary file over serial line (xmodem mode) loady - load binary file over serial line (ymodem mode) loop- infinite loop on address range md - memory display mm - memory modify (auto-incrementing address) mw - memory write (fill) nfs - boot image via network using NFS protocol nm - memory modify (constant address) printenv- print environment variables reset - Perform RESET of the CPU run - run commands in an environment variable setenv - set environment variables showvar - print local hushshell variables sleep - delay execution for some time source - run script from memory test- minimal test like /bin/sh tftpboot- boot image via network using TFTP protocol true- do nothing, successfully version - print monitor, compiler and linker version SOCFPGA_CYCLONE5 # > > As Chin Liang See has said, there are two issues thwarting this: legal AND > source conformance. The code we can fix, the legal can only be fixed by > bending Altera - I am going to do that too. We are making some progress on this. Once we have final green light, we will start the upstreaming of SDRAM code. :) Thanks Chin Liang > > Regards > > Charles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Mainline u-boot SPL for socfpga
Hi! (Sorry for the delay) > > > I know u-boot SPL misses critical parts, but I was told that u-boot > > > proper should have everything. Only... I was not able to get it to > > > work. [I'm attempting to load recent u-boot from patched/old u-boot; I > > > know this is not exactly recommended, but due to spl/proper split, it > > > should work AFAIK... and does for old versions.] > > > > I have not tried booting u-boot proper from mainline. It just seemed > > pointless > > to me to be working from 2 source trees to make a single product. > > > > I will give it a go though. > > > Actually the U-Boot is working. You just need to #undef > CONFIG_SOCFPGA_VIRTUAL_TARGET and build it. I loaded it using a working > Preloader and I can reach the U-Boot console. Aha, you are right, I forgot about VIRTUAL_TARGET define. > U-Boot 2014.07-rc1-00079-g2072e72-dirty (May 16 2014 - 15:54:55) > > CPU : Altera SOCFPGA Platform > BOARD : Altera SOCFPGA Cyclone5 Board > DRAM: 1 GiB > WARNING: Caches not enabled > Using default environment > > In:serial > Out: serial > Err: serial > Net: No ethernet found. Do you have any hints how to get ethernet to work? Plus, for me it says: tertiary u-boot 13.760972 Warning: Your board does not use generic board. Please read tertiary u-boot 13.770775 doc/README.generic-board and take action. Boards not tertiary u-boot 13.779813 upgraded by the late 2014 may break or be removed. > > As Chin Liang See has said, there are two issues thwarting this: legal AND > > source conformance. The code we can fix, the legal can only be fixed by > > bending Altera - I am going to do that too. > > > We are making some progress on this. Once we have final green light, we > will start the upstreaming of SDRAM code. :) Looking forward :-). Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Mainline u-boot SPL for socfpga
Hi Pavel, On Tue, 2014-05-27 at 14:40 +0200, ZY - pavel wrote: > Hi! > > (Sorry for the delay) > > > > > I know u-boot SPL misses critical parts, but I was told that u-boot > > > > proper should have everything. Only... I was not able to get it to > > > > work. [I'm attempting to load recent u-boot from patched/old u-boot; I > > > > know this is not exactly recommended, but due to spl/proper split, it > > > > should work AFAIK... and does for old versions.] > > > > > > I have not tried booting u-boot proper from mainline. It just seemed > > > pointless > > > to me to be working from 2 source trees to make a single product. > > > > > > I will give it a go though. > > > > > > Actually the U-Boot is working. You just need to #undef > > CONFIG_SOCFPGA_VIRTUAL_TARGET and build it. I loaded it using a working > > Preloader and I can reach the U-Boot console. > > Aha, you are right, I forgot about VIRTUAL_TARGET define. > > > U-Boot 2014.07-rc1-00079-g2072e72-dirty (May 16 2014 - 15:54:55) > > > > CPU : Altera SOCFPGA Platform > > BOARD : Altera SOCFPGA Cyclone5 Board > > DRAM: 1 GiB > > WARNING: Caches not enabled > > Using default environment > > > > In:serial > > Out: serial > > Err: serial > > Net: No ethernet found. > > Do you have any hints how to get ethernet to work? > I yet to upstream the ethernet part yet. I plan to do that once I upstreamed all the minimum SPL code to run on dev kit. > Plus, for me it says: > > tertiary u-boot 13.760972 Warning: Your board does not use generic > board. Please read > tertiary u-boot 13.770775 doc/README.generic-board and take > action. Boards not > tertiary u-boot 13.779813 upgraded by the late 2014 may break or be > removed. > I believe your patch already resolved this :) > > > > As Chin Liang See has said, there are two issues thwarting this: legal > > > AND > > > source conformance. The code we can fix, the legal can only be fixed by > > > bending Altera - I am going to do that too. > > > > > > We are making some progress on this. Once we have final green light, we > > will start the upstreaming of SDRAM code. :) > > Looking forward :-). Yup, work in progress. It slightly time consuming especially removing some unused code :) Thanks Chin Liang > > Thanks, > Pavel > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Mainline u-boot SPL for socfpga
Hi!
> > > U-Boot 2014.07-rc1-00079-g2072e72-dirty (May 16 2014 - 15:54:55)
> > >
> > > CPU : Altera SOCFPGA Platform
> > > BOARD : Altera SOCFPGA Cyclone5 Board
> > > DRAM: 1 GiB
> > > WARNING: Caches not enabled
> > > Using default environment
> > >
> > > In:serial
> > > Out: serial
> > > Err: serial
> > > Net: No ethernet found.
> >
> > Do you have any hints how to get ethernet to work?
> >
>
> I yet to upstream the ethernet part yet.
> I plan to do that once I upstreamed all the minimum SPL code to run on
> dev kit.
I tried to get it to work, but did not succeed so far.
First, designware.c patches are for version before rewrite -- so I
reverted to that version. For some reason, it detects phy at all
possible places -- seems like the controller is not listening in the
address space?
Then, it seems ethernet address reading depends on i2c, so I added
that, and that in turn depends on clock framework.
This is what my current diff. If you have any ideas, let me know.
Best regards,
Pavel
diff --git a/arch/arm/include/asm/arch-socfpga/socfpga_base_addrs.h
b/arch/arm/include/asm/arch-socfpga/socfpga_base_addrs.h
index f564046..c8e925a 100644
--- a/arch/arm/include/asm/arch-socfpga/socfpga_base_addrs.h
+++ b/arch/arm/include/asm/arch-socfpga/socfpga_base_addrs.h
@@ -14,5 +14,8 @@
#define SOCFPGA_CLKMGR_ADDRESS 0xffd04000
#define SOCFPGA_RSTMGR_ADDRESS 0xffd05000
#define SOCFPGA_SYSMGR_ADDRESS 0xffd08000
+#define SOCFPGA_EMAC0_ADDRESS 0xff70
+#define SOCFPGA_EMAC1_ADDRESS 0xff702000
+
#endif /* _SOCFPGA_BASE_ADDRS_H_ */
diff --git a/board/altera/socfpga/socfpga_cyclone5.c
b/board/altera/socfpga/socfpga_cyclone5.c
index 33946b6..fd68aa9 100644
--- a/board/altera/socfpga/socfpga_cyclone5.c
+++ b/board/altera/socfpga/socfpga_cyclone5.c
@@ -7,11 +7,39 @@
#include
#include
#include
+#ifndef CONFIG_SPL_BUILD
+#include
+#include
+#include
+#include
+#include "../../../drivers/net/designware.h"
+#endif
#include
DECLARE_GLOBAL_DATA_PTR;
+static const struct socfpga_reset_manager *reset_manager_base =
+ (void *)SOCFPGA_RSTMGR_ADDRESS;
+
+#define RSTMGR_PERMODRST_EMAC0_LSB 0
+#define RSTMGR_PERMODRST_EMAC1_LSB 1
+
+#define CONFIG_SYSMGR_EMAC_CTRL(SOCFPGA_SYSMGR_ADDRESS + 0x60)
+
+/* Enumeration: sysmgr::emacgrp::ctrl::physel::enum*/
+#define SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_GMII_MII 0x0
+#define SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_RGMII 0x1
+#define SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_RMII 0x2
+#define SYSMGR_EMACGRP_CTRL_PHYSEL0_LSB 0
+#define SYSMGR_EMACGRP_CTRL_PHYSEL1_LSB 2
+#define SYSMGR_EMACGRP_CTRL_PHYSEL_MASK 0x0003
+
+/* EMAC controller and PHY used */
+#define CONFIG_EMAC_BASE CONFIG_EMAC1_BASE
+#define CONFIG_EPHY_PHY_ADDR CONFIG_EPHY1_PHY_ADDR
+#define CONFIG_PHY_INTERFACE_MODE SOCFPGA_PHYSEL_ENUM_RGMII
+
#if defined(CONFIG_DISPLAY_CPUINFO)
/*
* Print CPU information
@@ -64,8 +92,152 @@ int overwrite_console(void)
/*
* DesignWare Ethernet initialization
*/
+
+int designware_board_phy_init(struct eth_device *dev, int phy_addr,
+ int (*mii_write)(struct eth_device *, u8, u8, u16),
+ int (*dw_reset_phy)(struct eth_device *))
+{
+ struct dw_eth_dev *priv = dev->priv;
+ struct phy_device *phydev;
+ struct mii_dev *bus;
+
+ printf("Back to board file\n");
+
+ if ((*dw_reset_phy)(dev) < 0)
+ return -1;
+
+ bus = mdio_get_current_dev();
+ printf("Board file: bus %lx\n", bus);
+
+ /*
+struct phy_device *phy_find_by_mask(struct mii_dev *bus, unsigned phy_mask,
+phy_interface_t interface)
+ */
+
+ phydev = phy_connect(bus, phy_addr, dev,
+ priv->interface);
+
+ printf("Board file: bus %lx\n", phydev);
+ /* Micrel PHY is connected to EMAC1 */
+ if (strcasecmp(phydev->drv->name, "Micrel ksz9021") == 0 &&
+ ((phydev->drv->uid & phydev->drv->mask) ==
+ (phydev->phy_id & phydev->drv->mask))) {
+
+ printf("Configuring PHY skew timing for %s\n",
+ phydev->drv->name);
+
+ /* min rx data delay */
+ if (ksz9021_phy_extended_write(phydev,
+ MII_KSZ9021_EXT_RGMII_RX_DATA_SKEW,
+ getenv_ulong(CONFIG_KSZ9021_DATA_SKEW_ENV, 16,
+ CONFIG_KSZ9021_DATA_SKEW_VAL)) < 0)
+ return -1;
+ /* min tx data delay */
+ if (ksz9021_phy_extended_write(phydev,
+ MII_KSZ9021_EXT_RGMII_TX_DATA_SKEW,
+ getenv_ulong(CONFIG_KSZ9021_DATA_SKEW_ENV, 16,
+ CONFIG_KSZ9021_DATA_SKEW_VAL)) < 0)
+ return -1;
+ /* max rx/tx clock delay, min rx/tx control */
+ if (ksz9021_phy_extended_wri
