mirror of
https://github.com/Ysurac/openmptcprouter.git
synced 2025-03-09 15:40:20 +00:00
Update 6.12 kernel patches
This commit is contained in:
Ycarus (Yannick Chabanois)
parent
bdb9b0046f
commit
9d83c70ced
247 changed files with 53301 additions and 589 deletions
|
|
@ -0,0 +1,91 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/mtd/partitions/openwrt,uimage.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: OpenWrt variations of U-Boot Image partitions
|
||||
|
||||
maintainers:
|
||||
- Bjørn Mork <bjorn@mork.no>
|
||||
|
||||
description: |
|
||||
The image format defined by the boot loader "Das U-Boot" is often
|
||||
modified or extended by device vendors. This defines a few optional
|
||||
properties which can be used to describe such modifications.
|
||||
|
||||
# partition.txt defines common properties, but has not yet been
|
||||
# converted to YAML
|
||||
#allOf:
|
||||
# - $ref: ../partition.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- openwrt,uimage
|
||||
- const: denx,uimage
|
||||
|
||||
openwrt,padding:
|
||||
description: Number of padding bytes between header and data
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
default: 0
|
||||
|
||||
openwrt,ih-magic:
|
||||
description: U-Boot Image Header magic number.
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
default: 0x27051956 # IH_MAGIC
|
||||
|
||||
openwrt,ih-type:
|
||||
description: U-Boot Image type
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
default: 2 # IH_TYPE_KERNEL
|
||||
|
||||
openwrt,offset:
|
||||
description:
|
||||
Offset between partition start and U-Boot Image in bytes
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
default: 0
|
||||
|
||||
openwrt,partition-magic:
|
||||
description:
|
||||
Magic number found at the start of the partition. Will only be
|
||||
validated if both this property and openwrt,offset is non-zero
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
default: 0
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
#unevaluatedProperties: false
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
// device with non-default magic
|
||||
partition@300000 {
|
||||
compatible = "openwrt,uimage", "denx,uimage";
|
||||
reg = <0x00300000 0xe80000>;
|
||||
label = "firmware";
|
||||
openwrt,ih-magic = <0x4e474520>;
|
||||
};
|
||||
- |
|
||||
// device with U-Boot Image at an offset, with a partition magic value
|
||||
partition@70000 {
|
||||
compatible = "openwrt,uimage", "denx,uimage";
|
||||
reg = <0x00070000 0x00790000>;
|
||||
label = "firmware";
|
||||
openwrt,offset = <20>;
|
||||
openwrt,partition-magic = <0x43535953>;
|
||||
};
|
||||
- |
|
||||
// device using a non-default image type
|
||||
#include "dt-bindings/mtd/partitions/uimage.h"
|
||||
partition@6c0000 {
|
||||
compatible = "openwrt,uimage", "denx,uimage";
|
||||
reg = <0x6c0000 0x1900000>;
|
||||
label = "firmware";
|
||||
openwrt,ih-magic = <0x33373033>;
|
||||
openwrt,ih-type = <IH_TYPE_FILESYSTEM>;
|
||||
};
|
||||
|
|
@ -0,0 +1,110 @@
|
|||
-------
|
||||
|
||||
ADM6996FC / ADM6996M switch chip driver
|
||||
|
||||
|
||||
1. General information
|
||||
|
||||
This driver supports the FC and M models only. The ADM6996F and L are
|
||||
completely different chips.
|
||||
|
||||
Support for the FC model is extremely limited at the moment. There is no VLAN
|
||||
support as of yet. The driver will not offer an swconfig interface for the FC
|
||||
chip.
|
||||
|
||||
1.1 VLAN IDs
|
||||
|
||||
It is possible to define 16 different VLANs. Every VLAN has an identifier, its
|
||||
VLAN ID. It is easiest if you use at most VLAN IDs 0-15. In that case, the
|
||||
swconfig based configuration is very straightforward. To define two VLANs with
|
||||
IDs 4 and 5, you can invoke, for example:
|
||||
|
||||
# swconfig dev ethX vlan 4 set ports '0 1t 2 5t'
|
||||
# swconfig dev ethX vlan 5 set ports '0t 1t 5t'
|
||||
|
||||
The swconfig framework will automatically invoke 'port Y set pvid Z' for every
|
||||
port that is an untagged member of VLAN Y, setting its Primary VLAN ID. In
|
||||
this example, ports 0 and 2 would get "pvid 4". The Primary VLAN ID of a port
|
||||
is the VLAN ID associated with untagged packets coming in on that port.
|
||||
|
||||
But if you wish to use VLAN IDs outside the range 0-15, this automatic
|
||||
behaviour of the swconfig framework becomes a problem. The 16 VLANs that
|
||||
swconfig can configure on the ADM6996 also have a "vid" setting. By default,
|
||||
this is the same as the number of the VLAN entry, to make the simple behaviour
|
||||
above possible. To still support a VLAN with a VLAN ID higher than 15
|
||||
(presumably because you are in a network where such VLAN IDs are already in
|
||||
use), you can change the "vid" setting of the VLAN to anything in the range
|
||||
0-1023. But suppose you did the following:
|
||||
|
||||
# swconfig dev ethX vlan 0 set vid 998
|
||||
# swconfig dev ethX vlan 0 set ports '0 2 5t'
|
||||
|
||||
Now the swconfig framework will issue 'port 0 set pvid 0' and 'port 2 set pvid
|
||||
0'. But the "pvid" should be set to 998, so you are responsible for manually
|
||||
fixing this!
|
||||
|
||||
1.2 VLAN filtering
|
||||
|
||||
The switch is configured to apply source port filtering. This means that
|
||||
packets are only accepted when the port the packets came in on is a member of
|
||||
the VLAN the packet should go to.
|
||||
|
||||
Only membership of a VLAN is tested, it does not matter whether it is a tagged
|
||||
or untagged membership.
|
||||
|
||||
For untagged packets, the destination VLAN is the Primary VLAN ID of the
|
||||
incoming port. So if the PVID of a port is 0, but that port is not a member of
|
||||
the VLAN with ID 0, this means that untagged packets on that port are dropped.
|
||||
This can be used as a roundabout way of dropping untagged packets from a port,
|
||||
a mode often referred to as "Admit only tagged packets".
|
||||
|
||||
1.3 Reset
|
||||
|
||||
The two supported chip models do not have a sofware-initiated reset. When the
|
||||
driver is initialised, as well as when the 'reset' swconfig option is invoked,
|
||||
the driver will set those registers it knows about and supports to the correct
|
||||
default value. But there are a lot of registers in the chip that the driver
|
||||
does not support. If something changed those registers, invoking 'reset' or
|
||||
performing a warm reboot might still leave the chip in a "broken" state. Only
|
||||
a hardware reset will bring it back in the default state.
|
||||
|
||||
2. Technical details on PHYs and the ADM6996
|
||||
|
||||
From the viewpoint of the Linux kernel, it is common that an Ethernet adapter
|
||||
can be seen as a separate MAC entity and a separate PHY entity. The PHY entity
|
||||
can be queried and set through registers accessible via an MDIO bus. A PHY
|
||||
normally has a single address on that bus, in the range 0 through 31.
|
||||
|
||||
The ADM6996 has special-purpose registers in the range of PHYs 0 through 10.
|
||||
Even though all these registers control a single ADM6996 chip, the Linux
|
||||
kernel treats this as 11 separate PHYs. The driver will bind to these
|
||||
addresses to prevent a different PHY driver from binding and corrupting these
|
||||
registers.
|
||||
|
||||
What Linux sees as the PHY on address 0 is meant for the Ethernet MAC
|
||||
connected to the CPU port of the ADM6996 switch chip (port 5). This is the
|
||||
Ethernet MAC you will use to send and receive data through the switch.
|
||||
|
||||
The PHYs at addresses 16 through 20 map to the PHYs on ports 0 through 4 of
|
||||
the switch chip. These can be accessed with the Generic PHY driver, as the
|
||||
registers have the common layout.
|
||||
|
||||
If a second Ethernet MAC on your board is wired to the port 4 PHY, that MAC
|
||||
needs to bind to PHY address 20 for the port to work correctly.
|
||||
|
||||
The ADM6996 switch driver will reset the ports 0 through 3 on startup and when
|
||||
'reset' is invoked. This could clash with a different PHY driver if the kernel
|
||||
binds a PHY driver to address 16 through 19.
|
||||
|
||||
If Linux binds a PHY on addresses 1 through 10 to an Ethernet MAC, the ADM6996
|
||||
driver will simply always report a connected 100 Mbit/s full-duplex link for
|
||||
that PHY, and provide no other functionality. This is most likely not what you
|
||||
want. So if you see a message in your log
|
||||
|
||||
ethX: PHY overlaps ADM6996, providing fixed PHY yy.
|
||||
|
||||
This is most likely an indication that ethX will not work properly, and your
|
||||
kernel needs to be configured to attach a different PHY to that Ethernet MAC.
|
||||
|
||||
Controlling the mapping between MACs and PHYs is usually done in platform- or
|
||||
board-specific fixup code. The ADM6996 driver has no influence over this.
|
||||
Loading…
Add table
Add a link
Reference in a new issue