Since the nvmem-based approach for retrieving MAC addresses
appears to depend on the addresses being set up after the
partitions, it is no longer possible to keep the MAC address
setup in shared DTSI files while the partitions itself are
set up in DTS files for the individual devices.
In ath79 the firmware partition is typically located somewhere
"in the middle" of the partition table. Thus, it's not trivial
to share the partitions containing MAC address information in
a common DTSI (like we did in some cases on ramips).
In this commit, MAC address setup is thus moved to the relevant
partitions, and in most cases needs to be duplicated. While
the duplication is not really nice, it eventually provides a
cleaner and more tidy setup, making the DTS(I) file
fragmentation a bit more logical. This should also help
with adding new devices, as information is distributed across
less locations.
For consistency, this commit also moves the mtd-cal-data property
"down" together with the MAC address setup, so it's not based
on a partition before the latter is defined either. (This is
only done for those files touched due to nvmem conversion.)
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Convert most of the cases from mtd-mac-address to nvmem where
MAC addresses are set in the DTSI, but the partitions are only
located in the device DTS. This posed some problems earlier, since
in these cases we are using partitions before they are defined,
and the nvmem system did not seem to like that.
There have been a few different resolution approaches, based on
the different tradeoffs of deduplication vs. maintainability:
1. In many cases, the partition tables were identical except for
the firmware partition size, and the firmware partition was
the last in the table.
In these cases, the partition table has been moved to the
DTSI, and only the firmware partition's "reg" property has
been kept in the DTS files. So, the updated nvmem definition
could stay in the DTSI files as well.
2. For all other cases, splitting up the partition table would
have introduced additional complexity. Thus, the nodes to be
converted to nvmem have been moved to the DTS files where the
partitioning was defined.
3. For Netgear EX2700 and WN3000RP v3, the remaining DTSI file
was completely dissolved, as it was quite small and the name
was not really nice either.
4. The D-Link DIR-853 A3 was converted to nvmem as well, though
it is just a plain DTS file not taken care of in the first
wave.
In addition, some minor rearrangements have been made for tidyness.
Not covered (yet) by this patch are:
* Various unielec devices
* The D-Link DIR-8xx family
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The bootloader will look for a configuration section named ap.dk01.1-c2
in the FIT image. If this doesn't exist, the device won't boot.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
The mt76x8 subtarget is the only one in ramips that stores the
mediatek,mtd-eeprom property directly in the "root" mt7628an.dtsi.
This is not optimal for a few different reasons:
* If you don't really know it or are used to other (sub)targets,
the property will be set somewhat magically.
* The property is set based on &factory partition before (if at all)
this partition is defined.
* There are several devices that have different offset or even
different partitions to read from, which will then be overwritten
in the DTS files. Thus, definitions are scattered between root
DTSI and individual files.
Based on these circumstances, the "root" definition is removed and
the property is added to the device-based DTS(I) files where needed
and applicable. This should be easier to grasp for unexperienced
developers and will move the property closer to the partition
definitions.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
While an image layout based on MBR and 'bootfs' partition may be easy
to understand for users who are very used to the IBM PC and always have
the option to access the SD card outside of the device (and hence don't
really depend on other recovery methods or dual-boot), in my opinion
it's a dead end for many desirable features on embedded systems,
especially when managed remotely (and hence without an easy option to
access the SD card using another device in case things go wrong, for
example).
Let me explain:
* using a MSDOS/VFAT filesystem to store kernel(s) is problematic, as a
single corruption of the bootfs can render the system into a state
that it no longer boots at all. This makes dual-boot useless, or at
least very tedious to setup with then 2 independent boot partitions
to avoid the single point of failure on a "hot" block (the FAT index
of the boot partition, written every time a file is changed in
bootfs). And well: most targets even store the bootloader environment
in a file in that very same FAT filesystem, hence it cannot be used
to script a reliable dual-boot method (as loading the environment
itself will already fail if the filesystem is corrupted).
* loading the kernel uImage from bootfs and using rootfs inside an
additional partition means the bootloader can only validate the
kernel -- if rootfs is broken or corrupted, this can lead to a reboot
loop, which is often a quite costly thing to happen in terms of
hardware lifetime.
* imitating MBR-boot behavior with a FAT-formatted bootfs partition
(like IBM PC in the 80s and 90s) is just one of many choices on
embedded targets. There are much better options with modern U-Boot
(which is what we use and build from source for all targets booting
off SD cards), see examples in mediatek/mt7622 and mediatek/mt7623.
Hence rename the 'sdcard' feature to 'legacy-sdcard', and prefix
functions with 'legacy_sdcard_' instead of 'sdcard_'.
Tested-by: Stijn Tintel <stijn@linux-ipv6.be>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
This resolves incosnsitencies of the configured RX / TX flow control
modes between different boards or bootloaders.
Signed-off-by: David Bauer <mail@david-bauer.net>
The chip supports clock speeds up to 50 MHz, however it won't even read
the chip-id correctly at this frequency.
45 MHz however works reliable.
Signed-off-by: David Bauer <mail@david-bauer.net>
When a target configuration has unser Kconfig symbols, the build will
fail when OpenWrt is compiled with V=s and stdin is connected to a tty.
In case OpenWrt is compiled without either of these preconditions, the
build will uscceed with the symbols in question being unset.
Modify the kernel configuration in a way it fails on unset symbols
regardless of the aformentioned preconditions.
Signed-off-by: David Bauer <mail@david-bauer.net>
Calling free for the OF property can result in a kernel panic, as the
buffer in question might be referenced elsewhere. Also, it is not
removed from the tree.
Always allocate a new property and updating the tree with it fixes both
issues.
Fixes commit 91a52f22a1 ("treewide: backport support for nvmem on non platform devices")
Signed-off-by: David Bauer <mail@david-bauer.net>
The EXT4 driver also takes care of EXT2 and EXT3 file systems.
Activating the EXT2 driver kernel config options unlocked some other
ext2 driver related options which OpenWrt did not take care of.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The change which backported the of_get_mac_address() change broke some
patches in the layerscape target so the patches did not apply any more.
This commit makes them apply again and also fixes some other problems
related to this change.
Fixes commit 91a52f22a1 ("treewide: backport support for nvmem on non platform devices")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The code from ks8851.c was moved to ks8851_common.c, so it was not
backported. This broke the compile of the omap target which uses this
driver.
Fixes commit 91a52f22a1 ("treewide: backport support for nvmem on non platform devices")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This patch is backported from linux-arm-kernel [1] to improve situation, when
it was reported that 1.2 GHz variant is unstable with DFS.
It waits to be accepted upstream, however, it waits for Marvell people to respond.
[1] https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210630225601.6372-1-kabel@kernel.org/
Fixes: 7b868fe04a ("Revert "mvebu: 5.4 fix DVFS caused random boot crashes"")
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
Based on the discussion on the mailing list [1], the patch which was
reverted, it reverts only one patch without the subsequent ones.
This leads to the SoC scaling issue not using a CPU parent clock, but
it uses DDR clock. This is done for all variants, and it's wrong because
commits (hacks) that were using the DDR clock are no longer in the mainline kernel.
If someone has stability issues on 1.2 GHz, it should not affect all
routers (1 GHz, 800 MHz) and it should be rather consulted with guys, who are trying to
improve the situation in the kernel and not making the situation worse.
There are two solutions in cases of instability:
a) disable cpufreq
b) underclock it up to 1 GHz
This reverts commit 080a0b74e3.
[1] https://lists.openwrt.org/pipermail/openwrt-devel/2021-June/035702.html
Fixes: d379476817 ("mvebu: armada-37xx: add patch to forbid cpufreq for 1.2 GHz")
CC: Pali Rohár <pali@kernel.org>
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
This option is needed e.g. to use strongswan for IPSec.
BTW: This was the only target where this option was disabled.
Signed-off-by: Martin Schiller <ms@dev.tdt.de>
This uses "hdparm" (if present) to get the harddisk into low
power mode on NAS set-ups.
Cc: Adrian Schmutzler <mail@adrianschmutzler.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Based on the discussion on the mailing list [1], the patch which was
reverted, it reverts only one patch without the subsequent ones.
This leads to the SoC scaling issue not using a CPU parent clock, but
it uses DDR clock. This is done for all variants, and it's wrong because
commits (hacks) that were using the DDR clock are no longer in the mainline kernel.
If someone has stability issues on 1.2 GHz, it should not affect all
routers (1 GHz, 800 MHz) and it should be rather consulted with guys, who are trying to
improve the situation in the kernel and not making the situation worse.
There are two solutions in cases of instability:
a) disable cpufreq
b) underclock it up to 1 GHz
This reverts commit 080a0b74e3.
[1] https://lists.openwrt.org/pipermail/openwrt-devel/2021-June/035702.html
CC: Pali Rohár <pali@kernel.org>
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
Follow the recommendations stated in the Turris Omnia DTS for eth2:
"In case SFP module is present, U-Boot has to enable the sfp node above,
remove phy-handle property, and add managed = "in-band-status" property."
The boot script is written in a way, that it works for all U-Boot
versions deployed by the vendor so far (2015.10-rc2, 2019.07).
Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com>
Kernel 5.4 receives a reduced set, just to make the SFP cage work.
While we are at it, move the patches accepted upstream to the 0xx series.
Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com>
Kernel 5.10 receives the complete set of improvements from 5.11/5.12.
While we are at it, move the patches accepted upstream to the 0xx series.
Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com>
Add the missing CONFIG_KCSAN (disabled). Found while making kernel_oldconfig on
an x86-64 subtarget.
Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
Now that we have a generic sdcard upgrade method, which was copied from
the mvebu platform method, we can switch mvebu to the generic method.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Add a generic sdcard upgrade method instead of duplicating code in yet
another target, and add a feature flag to only install this upgrade
method in targets that set this flag. Copied from mvebu.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
kirkwood build broke due to missing include needed for ETH_ALEN.
Add patch (sent upstream as well) to address that.
Refresh patches for 5.4 and 5.10.
Fixes: 91a52f22a1 ("treewide: backport support for nvmem on non platform devices")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
As both the Mi Router 4A (100M) and the Mi Router 4C use the same
label-mac-device, the alias can be moved to the shared dtsi.
Signed-off-by: Fabian Bläse <fabian@blaese.de>
A superflus ')' character has slipped into commit 91a52f22a1. Remove it
to fix build.
Fixes: 91a52f22a1 ("treewide: backport support for nvmem on non platform devices")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
MT7622 provides are hardware RNG with upstream Linux driver. Enable
compilation of this driver to make use of the hardware RNG.
Signed-off-by: David Bauer <mail@david-bauer.net>
The GL-X300B is a industrial 4G LTE router based on the Qualcomm
QCA9531 SoC.
Specifications:
- Qualcomm QCA9531 @ 650 MHz
- 128 MB of RAM
- 16 MB of SPI NOR FLASH
- 2x 10/100 Mbps Ethernet
- 2.4GHz 802.11b/g/n
- 1x USB 2.0 (vbus driven by GPIO)
- 4x LED, driven by GPIO
- 1x button (reset)
- 1x mini pci-e slot (vcc driven by GPIO)
- RS-485 Serial Port (untested)
Flash instructions:
This firmware can be flashed using either sysupgrade from the GL.iNet
firmware or the recovery console as follows:
- Press and hold the reset button
- Connect power to the router, wait five seconds
- Manually configure 192.168.1.2/24 on your computer, connect to
192.168.1.1
- Upload the firmware image using the web interface
RS-485 serial port is untested and may depend on the following commit in
the GL.iNet repo:
202e83a32a
MAC addresses as verified by OEM firmware:
vendor OpenWrt address
WAN eth0 label
LAN eth1 label + 1
2g phy0 label + 2
The label MAC address was found in the art partition at 0x0
Based on vendor commit:
16c5708b20
Signed-off-by: John Marrett <johnf@zioncluster.ca>
Add the missing ARM_SCMI_PROTOCOL symbol. Apparently it was exposed
for 5.10.53 with a kernel dependency change.
Missing symbol observed with mediatek/7622 E8450/RT3200 router.
Signed-off-by: Hannu Nyman <hannu.nyman@iki.fi>
