| Age | Commit message (Collapse) | Author |
|---|
|
This patch adds support for 10GBASE-R interface mode
Signed-off-by: Bo-Cun Chen <[email protected]>
Signed-off-by: Weijie Gao <[email protected]>
|
|
MT7629 need extra setting for gmac2 to work. So additional
capability is added for mt7629 to handle this case.
Signed-off-by: Weijie Gao <[email protected]>
|
|
Unlike other platforms, mt7622 has only one SGMII and it can be
attached to either gmac1 or gmac2. So the register field of the
sgmii selection differs from other platforms as newer platforms can
control each sgmii individually.
This patch adds a new capability for mt7622 to handle this case.
Signed-off-by: Weijie Gao <[email protected]>
|
|
The SYSCFG0 should be SYSCFG1 according to the programming guide.
Signed-off-by: Weijie Gao <[email protected]>
|
|
The register field for SGMII speed selection is a 2-bit field with
value 0 for 1Gbps and 1 for 2.5Gbps (2/3 are reserved).
So it's necessary to set both bits instead of just setting/clearing
only the lower bit.
Signed-off-by: Weijie Gao <[email protected]>
|
|
Add support for mapping C22 register access to C45-only PHYs.
This is mainly useful for 'mii info' command, which performs
C22 only access to determine PHY ID and link state and does
not work well with this driver so far.
Signed-off-by: Marek Vasut <[email protected]>
|
|
Implement C22 PHY access support in addition to C45 PHY access
support which is already present. This is used for PHYs which
do not support C45 access or which are C22 only.
The C22 access can be recognized when devad is set to -1 or
0xffffffff hex, which also matches MDIO_DEVAD_NONE macro. Test
for this special devad value and if it is set this way, perform
C22 access, otherwise perform C45 access.
Based on work by LUU HOAI <[email protected]>
Signed-off-by: Marek Vasut <[email protected]>
|
|
The Set Station Management Mode : Clause 45 setting of MFF bit in MPSM
register can be done in rswitch_mii_access_c45() once, instead of this
being done before each rswitch_mii_access_c45() call. Deduplicate the
bit setting into rswitch_mii_access_c45(). No functional change.
Signed-off-by: Marek Vasut <[email protected]>
|
|
Use clrsetbits_le32() to make this complicated construct simpler.
No functional change.
Signed-off-by: Marek Vasut <[email protected]>
|
|
Update the macro indent, replace multiple spaces with tabs proper.
No functional change.
Signed-off-by: Marek Vasut <[email protected]>
|
|
Replace enum rswitch_reg with plain #define REGISTER OFFSET macros.
The enum rswitch_reg was not referenced anywhere, so there was no
benefit of keeping it around. Include register block labels. Turn
all register offsets into lowercase hex values. No functional change.
Rename EATDQDC to EATDQDCR, GWTRC to GWTRCR, GWDCC to GWDCCR, FWPC0
to FWPC, FWPBFC to FWPBFCR, FWPBFCSDC to FWPBFCSDCR because there
are both register names which used to be part of this enum and also
macros with the same name, each used for slightly different purpose.
Make sure there is no collission.
Signed-off-by: Marek Vasut <[email protected]>
|
|
Prepare v2025.01-rc5
|
|
When FEC network card works as the prime one in u-boot, and is in
active status, kernel might crash during booting up stage, especially
working with grub. Because the DMA of FEC is still in active status, and
copy data into memory if there is network data received. In this case, if
kernel allocated a part of memory that has overlay with the memory
used by DMA, kernel memory may be destroyed and cause kernel crashes.
Because before kernel boots up really, u-boot dm_remove_devices_flags()
can call the remove callback of FEC driver with DM_FLAG_ACTIVE_DMA
flag. In fecmxc_remove(), phy power is disabled, so there is no data
received. In this way, it makes sure that there is no DMA action, so
that avoid kernel crashing occurs.
Signed-off-by: Meng Li <[email protected]>
|
|
In case an rswitch port is described as disabled in DT, do not
register it as ethernet device in U-Boot. This way, such ports
cannot be accessed from U-Boot command line.
Signed-off-by: Marek Vasut <[email protected]>
|
|
TFTP transfers of large files, for example 128 MiB, can sporadically
get stuck and the transfer slows down considerably.
This happens because the TX DMA descriptor in DRAM becomes out of sync
with the view of the TX DMA descriptor content from the CPU side, which
is viewed through the CPU caches. In order to guarantee these two views
are consistent, the cache over TX DMA descriptor that has possibly been
written by the rswitch hardware must first be invalidated, only then can
the descriptor be cleared and updated by the CPU, and finally the cache
over that area must be flushed back into DRAM to make sure the rswitch
hardware has consistent view of the updated descriptor content.
The very first invalidation operation was missing, which led to sporadic
corruption of the TX DMA descriptor. Fix it, add the missing invalidation
operation.
Reported-by: Enric Balletbo i Serra <[email protected]>
Signed-off-by: Marek Vasut <[email protected]>
Tested-by: Enric Balletbo i Serra <[email protected]>
|
|
Currently if a gigabit-capable PHY is connected to FEC via RMII or MII, it
will advertise 1000FULL and 1000HALF to a link partner.
Different problems may arise here:
- usually with (R)MII between MAC and PHY the PHY's connection to magnetics
would have only 2 pairs routed as well, otherwise a PHY can negotiate 1000
speed and there will be no traffic possible;
- but even if there is no way to negotiate 1000 speed in HW (only 2 signal
pairs routed), it may take a lot of time for PHY to figure this out; in
case of AD1300 it takes 17-20 seconds, which is waay longer than default
4s PHY_ANEG_TIMEOUT.
Use phy_set_supported() in such cases to disable gigabit advertised
options.
Signed-off-by: Alexander Sverdlin <[email protected]>
|
|
Prepare v2025.01-rc4
|
|
We can call dev_read_u32_default() instead of calling fdt_getprop() then
fdt32_to_cpu().
Signed-off-by: Paul Barker <[email protected]>
Reviewed-by: Marek Vasut <[email protected]>
|
|
probing on capricorn board (imx8qxp based) brings:
Can't find FEC0 clk rate: -19
Cause is that when probing fec_mxc driver, fec_mii_setspeed()
is called which calls fec_get_clk_rate().
fec_mii_setspeed() calls fec_get_clk_rate with NULL pointer
for udev and so as in IMX8QXP case CLK_CCF is enabled
udev gets searched with:
uclass_get_device_by_seq(UCLASS_ETH, idx, &dev);
but we do not have yet a UCLASS_ETH ! as we just probing it!
Prevent this by passing udev to fec_get_clk_rate()
Signed-off-by: Heiko Schocher <[email protected]>
|
|
They were added with commit 0e9d23945ce0 ("net: eqos: implement callbaks
to get interface and set txclk rate") but were not removed with
commit 5fc783b5d9c9 ("net: dwc_eth_qos: move i.MX code out") when i.MX
specific code was moved to a separate file.
Signed-off-by: Erik Schumacher <[email protected]>
|
|
The EQOS on i.MX93 fails to finish the reset procedure in RMII mode.
This is described in errata ERR051683. This patch implements the
provided workaround which sets the PS and FES bits after the SWR is set
by using the eqos_fix_soc_reset function.
Adapted from linux-kernel commit b536f32b5b03 ("net: stmmac: dwmac-imx:
use platform specific reset for imx93 SoCs")
Signed-off-by: Erik Schumacher <[email protected]>
|
|
This patch adds support for optional platform specific reset logic in
the dwc_eth_qos driver. This new function 'eqos_fix_soc_reset' is called
after the EQOS_DMA_MODE_SWR is set and before the driver waits for this
bit to clear.
Signed-off-by: Erik Schumacher <[email protected]>
|
|
This patch series by Hanyuan Zhao <[email protected]> provides a number of
improvements to the dc2114x driver.
Link: https://lore.kernel.org/r/[email protected]
|
|
bus"
Romain Naour <[email protected]> says:
We are using a custom board where an ethernet switch device KSZ9896 is
available. This family of devices can use several types of serial bus
as management interface: mdio, i2c or SPI. Due to board design
constraints and because we initially planned to use this device only
from Linux, the SPI bus was used.
Luckily we are using a recent enough u-boot release where KSZ9477
driver is available... but only for the i2c interface. Indeed, unlike
the kernel driver, the KSZ9477 driver doesn't use the regmap API to
access the underlying bus since the regmap API is limited to direct
memory access [1].
Until regmap API with bus support is available in U-boot, we introduced
struct ksz_phy_ops to store low-level ksz bus operations (I2C or SPI).
This series has been tested on the current master branch (after v2024.10
release).
[1] https://source.denx.de/u-boot/u-boot/-/blob/v2024.10-rc5/drivers/core/Kconfig?ref_type=tags#L188
Link: https://lore.kernel.org/r/[email protected]
|
|
Frank Sae <[email protected]> says:
YT8531 as Gigabit transceiver uses bit15:14(bit9 reserved default 0) as phy
speed mask, YT8821 as 2.5 Gigabit transceiver uses bit9 bit15:14 as phy
speed mask.
Be compatible to YT8821, reform phy speed mask and phy speed macro.
Based on update above, add YT8821 2.5G phy driver.
Link: https://lore.kernel.org/r/[email protected]
|
|
Some drivers do not behave properly when free_pkt() is called with a
length of zero. It is an issue I observed when developing the lwIP
series [1] (see "QEMU CI tests for r2dplus_i82557c, r2dplus_rtl8139"
in the change log) and which I fixed incorrectly by not calling
free_pkt() when recv() returns 0. That turned out to be wrong for two
reasons:
1. The DM documentation [2] clearly requires it:
"The **recv** function polls for availability of a new packet. [...]
If there is an error [...], return 0 if you require the packet to
be cleaned up normally, or a negative error code otherwise (cleanup
not necessary or already done).
If **free_pkt** is defined, U-Boot will call it after a received
packet has been processed [...]. free_pkt() will be called after
recv(), for the same packet [...]"
2. The imx8mp_evk platform will fail with OOM errors if free_pkt() is
not called after recv() returns 0:
u-boot=> tftp 192.168.0.16:50M
Using ethernet@30be0000 device
TFTP from server 192.168.0.16; our IP address is 192.168.0.48
Filename '50M'.
Load address: 0x40480000
Loading: #######################fecmxc_recv: error allocating packetp
fecmxc_recv: error allocating packetp
fecmxc_recv: error allocating packetp
...
Therefore, make recv() return -EAGAIN instead of 0 when no packet is
available and the driver doesn't expect free_pkt() to be called
subsequently.
[1] https://lists.denx.de/pipermail/u-boot/2024-August/562861.html
[2] doc/develop/driver-model/ethernet.rst
Signed-off-by: Jerome Forissier <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
The Microchip KSZ Gigabit Ethernet Switches support
SGMII/RGMII/MII/RMII with register access via SPI, I2C, or MDIO.
Since this driver is now able to check the underlying bus type,
handle the case when the SPI bus is used.
The SPI bus is only used for 8/16/32 wide access of registers.
Reword Kconfig option to include SPI bus support.
Signed-off-by: Romain Naour <[email protected]>
|
|
With the upcoming ksz9477 SPI support added, the I2C support
will be optional. Either the I2C or the SPI bus will be used.
For now, DM_I2C is still mandatory.
Signed-off-by: Romain Naour <[email protected]>
|
|
In order to support management bus other than the I2C, rename
ksz_i2c_probe() to ksz_probe() since this function is no longer
specific to the I2C bus.
Signed-off-by: Romain Naour <[email protected]>
|
|
The ksz9477 Linux kernel driver is based on regmap API to seamlessly
communicate to switch devices connected via different buses like SPI
or I2C. The current regmap implementation in U-Boot only supports
memory-mapped registers access [1].
Until regmap API with bus support is available in U-boot, introduce
struct ksz_phy_ops to store low-level ksz bus operations (I2C for now).
[1] https://lists.denx.de/pipermail/u-boot/2018-May/329392.html
Signed-off-by: Romain Naour <[email protected]>
|
|
In order to add ksz9477 SPI bus support, check parent bus
is an I2C bus before calling i2c_set_offset_len().
Doing so, ksz_i2c_probe() will now return an error (-EINVAL) if
the parent bus is not the one expected by the ksz-switch u-boot
driver.
Indeed, the DSA KSZ devicetree binding doesn't specify anything
about the underlying bus between the SoC and the DSA switch, so
the same "compatible" string can be used wathever the management
interface used (SPI or I2C).
The ksz-switch u-boot driver currently only support I2C interface
but will match a compatible "microchip,ksz9xxx" located under
under an SPI bus node.
Signed-off-by: Romain Naour <[email protected]>
|
|
The DSA KSZ devicetree binding doesn't specify anything about the
underlying bus between the SoC and the DSA switch, so the same
"compatible" string can be used wathever the management interface
used. The driver must be able to access the underlying bus without
any help from the compatible string (like for TPM2 TIS devices).
So, rename udevice_id tab to ksz_ids since it's not specific to i2c
bus.
Signed-off-by: Romain Naour <[email protected]>
|
|
Add support for the KSZ9896 6-port Gigabit Ethernet Switch to the
ksz9477 driver.
The KSZ9896 is similar to KSZ9897 but has only one configurable
MII/RMII/RGMII/GMII cpu port.
Signed-off-by: Romain Naour <[email protected]>
|
|
The ksz9477 is currently the only driver using dev_set_parent_priv()
outside of the driver model. Also, there was no explanation in the
commit adding ksz9477 driver and why dev_set_parent_priv() is
required.
Actually there is a typo in ksz_mdio_probe() while retrieving
the parent (switch@0) private data:
- priv->ksz = dev_get_parent_priv(dev->parent);
+ priv->ksz = dev_get_priv(dev->parent);
Printing the address of struct ksz_dsa_priv *priv allows
to notice the slight difference:
ksz_i2c_probe: ksz_dsa_priv *priv 0xfdf45768 // address of the saved priv
ksz_mdio_bind: ksz_dsa_priv *priv 0xfdf45798 // address returned by dev_get_parent_priv(dev->parent)
ksz_mdio_bind: ksz_dsa_priv *priv 0xfdf45768 // address returned by dev_get_priv(dev->parent)
The ksz_mdio driver get the wrong data and without
dev_set_parent_priv() the mdio driver fail to access the underlying
bus.
While it doesn't cause any issue with I2C bus, it override the
per-child data used by the SPI bus (struct spi_slave) and prevent
further bus access (even with sspi command).
Signed-off-by: Romain Naour <[email protected]>
|
|
struct ksz_dsa_priv *priv should be declared before dev_dbg()
Signed-off-by: Romain Naour <[email protected]>
|
|
Add a driver for the motorcomm YT8821 2.5G ethernet phy which works in
2500base-x mode.
Verify the driver on BPI-R3(with MediaTek MT7986(Filogic 830) SoC) evb.
Signed-off-by: Frank Sae <[email protected]>
|
|
YT8531 as Gigabit transceiver uses bit15:14(bit9 reserved default 0) as phy
speed mask, YT8821 as 2.5 Gigabit transceiver uses bit9 bit15:14 as phy
speed mask.
Be compatible to YT8821, reform phy speed mask and phy speed macro.
Signed-off-by: Frank Sae <[email protected]>
|
|
Remove the OMR_PM flag and choose 16 perfect filtering mode since in
modern networks there're plenty of multicasts and set ORM_PM flag will
increase the dc2114x's workload and ask the U-Boot to handle packets
not related to itself. And most of the time, U-Boot does not need this
feature.
Signed-off-by: Hanyuan Zhao <[email protected]>
|
|
Some IP cores of dc2114x or its variants do not comply so well with
the behaviors described by the official document. Originally this
driver uses only one tx descriptor and organizes it as a ring buffer,
which would lead to a problem that one packet would be sent twice.
This commit adds support to prevent this bug if you are using IP
cores with this issue, by using multiple tx descriptors and
organizing them as a real well-defined ring buffer.
Signed-off-by: Hanyuan Zhao <[email protected]>
|
|
Some IP cores of dc2114x or its variants do not comply so well with
the behaviors described by the official document. A packet could be
sent successfully but reported with No Carrier error. Latest drivers
of this IP core have not detect this error anymore.
Signed-off-by: Hanyuan Zhao <[email protected]>
|
|
This commit fixes a problem that even though the network card does not report
any issues in transmitting a setup frame, the driver prints the error status
every time. Let's set it for debug use.
Signed-off-by: Hanyuan Zhao <[email protected]>
|
|
the card
This commit adds support for the MIPS and LoongArch CPUs, which would use cache
after they jump into U-Boot. This commit requests the CPU to return the
addresses in uncached windows and flushes the cache in need, to make sure the
memory between the CPU and the network card is in consistency.
Signed-off-by: Hanyuan Zhao <[email protected]>
|
|
Otherwise the number might get kind of weird.
Signed-off-by: Hanyuan Zhao <[email protected]>
|
|
Let this old driver work like the other newer network card drivers, loading the
MAC address from environment, which could be more flexible to set.
Signed-off-by: Hanyuan Zhao <[email protected]>
|
|
There're a few ethernet IP cores which have the same functions with dc2114x,
and can be connected to CPU by AXI or other buses. This commit adds support
for the platforms that do not have PCI controllers, using MMIO to communicate
with the dc2114x IP core.
Signed-off-by: Hanyuan Zhao <[email protected]>
|
|
Add what it takes to enable NETDEVICES with NET_LWIP and enable DHCP as
well as the dhcp command. CMD_TFTPBOOT is selected by BOOTMETH_EFI due
to this code having an implicit dependency on do_tftpb().
Note that PXE is likely non-fonctional with NET_LWIP (or at least not
100% functional) because DHCP option 209 is not supported by the lwIP
library. Therefore, BOOTP_PXE_DHCP_OPTION cannot be enabled.
Signed-off-by: Jerome Forissier <[email protected]>
Tested-by: Ilias Apalodimas <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
|
|
Prepare the introduction of the lwIP (lightweight IP) TCP/IP stack by
adding a new net/lwip/ directory and the NET_LWIP symbol. Network
support is either NO_NET, NET (legacy stack) or NET_LWIP. Subsequent
commits will introduce the lwIP code, re-work the NETDEVICE integration
and port some of the NET commands and features to lwIP.
SPL_NET cannot be enabled when NET_LWIP=y. SPL_NET pulls some symbols
that are part of NET (such as arp_init(), arp_timeout_check(),
arp_receive(), net_arp_wait_packet_ip()). lwIP support in SPL may be
added later.
Similarly, DFU_TFTP and FASTBOOT are not compatible with NET_LWIP
because of dependencies on net_loop(), tftp_timeout_ms,
tftp_timeout_count_max and other NET things. Let's add a dependency on
!NET_LWIP for now.
SANDBOX can select NET_LWIP but doing so will currently disable the eth
dm tests as well as the wget tests which have strong dependencies on the
NET code.
Other adjustments to Kconfig files are made to fix "unmet direct
dependencies detected" for USB_FUNCTION_SDP and CMD_FASTBOOT when
the default networking stack is set to NET_LWIP ("default NET_LWIP"
instead of "default NET" in Kconfig).
The networking stack is now a choice between NO_NET,
NET and NET_LWIP. Therefore '# CONFIG_NET is not set' should be
'CONFIG_NO_NET=y'. Adjust the defconfigs accordingly.
Signed-off-by: Jerome Forissier <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
|
|
Introduce ETH_SANDBOX_LWIP which enables a mock driver similar to
ETH_SANDOX but without the dependencies on the legacy network stack
(NET) so that it may be enabled when the lwIP stack (NET_LWIP) is
introduced. The driver does nothing at this stage but its presence
will allow dm_test_iommu_noiommu [1] to pass.
[1] ./u-boot -T -c "ut dm dm_test_iommu_noiommu"
Signed-off-by: Jerome Forissier <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Simon Glass <[email protected]> says:
When the SPL build-phase was first created it was designed to solve a
particular problem (the need to init SDRAM so that U-Boot proper could
be loaded). It has since expanded to become an important part of U-Boot,
with three phases now present: TPL, VPL and SPL
Due to this history, the term 'SPL' is used to mean both a particular
phase (the one before U-Boot proper) and all the non-proper phases.
This has become confusing.
For a similar reason CONFIG_SPL_BUILD is set to 'y' for all 'SPL'
phases, not just SPL. So code which can only be compiled for actual SPL,
for example, must use something like this:
#if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD)
In Makefiles we have similar issues. SPL_ has been used as a variable
which expands to either SPL_ or nothing, to chose between options like
CONFIG_BLK and CONFIG_SPL_BLK. When TPL appeared, a new SPL_TPL variable
was created which expanded to 'SPL_', 'TPL_' or nothing. Later it was
updated to support 'VPL_' as well.
This series starts a change in terminology and usage to resolve the
above issues:
- The word 'xPL' is used instead of 'SPL' to mean a non-proper build
- A new CONFIG_XPL_BUILD define indicates that the current build is an
'xPL' build
- The existing CONFIG_SPL_BUILD is changed to mean SPL; it is not now
defined for TPL and VPL phases
- The existing SPL_ Makefile variable is renamed to SPL_
- The existing SPL_TPL Makefile variable is renamed to PHASE_
It should be noted that xpl_phase() can generally be used instead of
the above CONFIGs without a code-space or run-time penalty.
This series does not attempt to convert all of U-Boot to use this new
terminology but it makes a start. In particular, renaming spl.h and
common/spl seems like a bridge too far at this point.
The series is fully bisectable. It has also been checked to ensure there
are no code-size changes on any commit.
|
|
Use the new symbol to refer to any 'SPL' build, including TPL and VPL
Signed-off-by: Simon Glass <[email protected]>
|
