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>
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>
The virtual cable tester depends on the netlink interface for ethtool.
Thus, enable it in the generic kernel configuration.
Signed-off-by: David Bauer <mail@david-bauer.net>
In the current state, nvmem cells are only detected on platform device.
To quickly fix the problem, we register the affected problematic driver
with the of_platform but that is more an hack than a real solution.
Backport from net-next the required patch so that nvmem can work also
with non-platform devices and rework our current patch.
Drop the mediatek and dsa workaround and rework the ath10k patches.
Rework every driver that use the of_get_mac_address api.
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
bcm27xx-bcm2710 builds are stalling when compiled with V=s.
Explitily disable these unset symbols to avoid stalling
builds.
Signed-off-by: David Bauer <mail@david-bauer.net>
