This adds a hotplug script for distributing interrupts of eth0 and eth1
across different cores. Otherwise the forwarding performance between
eth0 and eth1 is severely affected.
The existing SMP distribution mechanic in OpenWrt can't be used here, as
the actual device IRQ has to be moved to dedicated cores. In case of
eth1, this is in fact the USB3 controller.
Signed-off-by: David Bauer <mail@david-bauer.net>
Some rockchip SoCs like the RK3399 and RK3328 exhibit an issue
where tx checksumming does not work with packets larger than 1498.
The default Programmable Buffer Length for TX in these GMAC's is
not suitable for MTUs higher than 1498. The workaround is to disable
TX offloading with 'ethtool -K eth0 tx off rx off' causing performance
impacts as it disables hardware checksumming.
This patch sets snps,txpbl to 0x4 which is a safe number tested ok for
the most popular MTU value of 1500.
For reference, see https://lkml.org/lkml/2019/4/1/1382.
Signed-off-by: Carlos de Paula <me@carlosedp.com>
Link: https://lore.kernel.org/r/20200218221040.10955-1-me@carlosedp.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: David Bauer <mail@david-bauer.net>
Hardware
--------
RockChip RK3328 ARM64 (4 cores)
1GB DDR4 RAM
2x 1000 Base-T
3 LEDs (LAN / WAN / SYS)
1 Button (Reset)
Micro-SD slot
USB 2.0 Port
Installation
------------
Uncompress the OpenWrt sysupgrade and write it to a micro SD card using
dd.
MAC-address
-----------
The vendor code supports reading a MAC address from an EEPROM connected
via i2c0 of the SoC. The EEPROM (address 0x51) should contain the MAC
address in binary at offset 0xfa. However, my two units didn't come with
such an EEPROM soldered on. The EEPROM should be placed between the SoC
and the GPIO pins on the board. (U10)
Generating rendom MAC addresses works around this issue. Otherwise, all
boards running the same image have identical MAC addresses.
Signed-off-by: David Bauer <mail@david-bauer.net>
Add support for select a bootscript depending on the device built. This
is necessary, as the FriendlyARM NanoPi R2S needs a different bootcmd in
order to produce output on the debug UART.
Signed-off-by: David Bauer <mail@david-bauer.net>
This adds a function for generating a valid random MAC address (unset MC
bit / set locally administered bit).
It is necessary for devices which do not have a MAC address programmed
by the manufacturer.
Signed-off-by: David Bauer <mail@david-bauer.net>
Update the U-Boot to version v2020.07. Also replace the Makefile rewrite
with a proper patch, explaining why this hack is needed.
Run-tested: FriendlyARM NanoPi R2S
Signed-off-by: David Bauer <mail@david-bauer.net>
also install the firmware for all the supported boards
Signed-off-by: Lucian Cristian <lucian.cristian@gmail.com>
[fix ATF blob path in uboot-rockchip]
Signed-off-by: David Bauer <mail@david-bauer.net>
This adds a hotplug script for distributing interrupts of eth0 and eth1
across different cores. Otherwise the forwarding performance between
eth0 and eth1 is severely affected.
The existing SMP distribution mechanic in OpenWrt can't be used here, as
the actual device IRQ has to be moved to dedicated cores. In case of
eth1, this is in fact the USB3 controller.
Signed-off-by: David Bauer <mail@david-bauer.net>
Some rockchip SoCs like the RK3399 and RK3328 exhibit an issue
where tx checksumming does not work with packets larger than 1498.
The default Programmable Buffer Length for TX in these GMAC's is
not suitable for MTUs higher than 1498. The workaround is to disable
TX offloading with 'ethtool -K eth0 tx off rx off' causing performance
impacts as it disables hardware checksumming.
This patch sets snps,txpbl to 0x4 which is a safe number tested ok for
the most popular MTU value of 1500.
For reference, see https://lkml.org/lkml/2019/4/1/1382.
Signed-off-by: Carlos de Paula <me@carlosedp.com>
Link: https://lore.kernel.org/r/20200218221040.10955-1-me@carlosedp.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: David Bauer <mail@david-bauer.net>
Update config with make kernel_oldconfig and copy/refresh patch.
Add CONFIG_WATCHDOG_CORE=y to fix the following error as done for
several targets already:
Package kmod-hwmon-sch5627 is missing dependencies for the following
libraries:
watchdog.ko
Directly switch to kernel 5.4.
This patch is compile-tested only. However, the target is essentially
pure upstream with a single patch, and it has been reported that
kernel 5.4 has been run on this target successfully already.
Note that in my local tests building with all packages/kmods failed
since openvswitch selects libunwind, which doesn't build for arc with
the following error:
checking if we should build libunwind-ptrace... yes
checking if we should build libunwind-setjmp... yes
checking for build architecture... x86_64
checking for host architecture... arc
checking for target architecture... arc
checking for target operating system... linux-gnu
checking for ELF helper width... configure: error: Unknown ELF target: arc
make[3]: *** [Makefile:65: /data/openwrt/build_dir/target-arc_arc700_uClibc/
libunwind-1.3.1/.configured_68b329da9893e34099c7d8ad5cb9c940] Error 1
Deselecting all kmod-openvswitch* packages will have the build run through.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This fixes a few cosmetic issues with partition offset and size
that are inconsistent probably due to copy/pasting.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This patch adds support for D-Link DIR-1960 A1. Given the similarity with
the DIR-1760/2660 A1, this patch also introduces a common DTSI which can
be shared with these devices, with support to be added in future commits.
Specifications:
* Board: AP-MTKH7-0002
* SoC: MediaTek MT7621AT
* RAM: 256 MB (DDR3)
* Flash: 128 MB (NAND)
* WiFi: MediaTek MT7615N (x2)
* Switch: 1 WAN, 4 LAN (Gigabit)
* Ports: 1 USB 3.0
* Buttons: Reset, WPS
* LEDs: Power (white/orange), Internet (white/orange), WiFi 2.4G (white),
WiFi 5G (white), USB 3.0 (white)
Notes:
* WiFi 2.4G and WiFi 5G LEDs are wired directly to the wireless chips
Installation:
* D-Link Recovery GUI: power down the router, press and hold the reset
button, then re-plug it. Keep the reset button pressed until the power
LED starts flashing orange, manually assign a static IP address under
the 192.168.0.xxx subnet (e.g. 192.168.0.2) and go to http://192.168.0.1
* Some modern browsers may have problems flashing via the Recovery GUI,
if that occurs consider uploading the firmware through cURL:
curl -v -i -F "firmware=@file.bin" 192.168.0.1
MAC addresses:
lan factory 0xe000 *:EB (label)
wan factory 0xe006 *:EE
2.4 factory 0xe000 +1 *:EC
5.0 factory 0xe000 +2 *:ED
Seems like vendor didn't replace the dummy entrys in the calibration data.
Signed-off-by: Josh Bendavid <joshbendavid@gmail.com>
[fix whitespace issues, create patch to merge DIR-1960 first, move
special WiFi MAC settings to DTS, extend commit message]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
In imx6, we currently use the model from DTS to derive a board name
manually in /lib/imx6.sh.
However, if we have individual DTS files anyway, we can exploit
generic 02_sysinfo and use the compatible as board name directly.
While at it, remove the wildcards from /lib/upgrade/platform.sh as
these might make code shorter, but are quite unpleasant when grepping
for a specific device.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
OpenWrt lately has harmonized device (definition) names to the
pattern vendor_model to improve overall consistency, also with
other values like the DTS compatible.
This patch applies that scheme to the layerscape target.
Since this (intentionally) creates a bigger overlap between DTS names,
compatible, and device definition name, it also moves DEVICE_DTS and
SUPPORTED_DEVICES definitions to the Device/Default blocks.
Apart from that, it also modifies several packages to use consistent
naming in order to keep the $(1) file references working.
While at it, remove one layer of complexity for the setup in
tfa-layerscape package.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Use "DEFAULT := n" to only disable devices for buildbots, but
keep them available for manual build.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
The kernel appears to have grown too large, breaking the build for the
entire target.
Disable the affected images for now until the situation is dealt with.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
This adds a full eMMC image including U-Boot, which means that the
kernel can inherit the true RAM size detected by the preloader.
As implemented in previous commits, sysupgrade to this image from
the legacy layout (and via that, from the vendor-installed image)
is supported.
Rename the legacy image for the 512MiB board, for clarity.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
As I buy more hardware and continue to work on consolidation, This will
apply to a lot of MediaTek platforms; rename it accordingly.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
This actually covers fairly much all the MediaTek platforms; they
only have different images because they don't include the preloader
and U-Boot, and rely on preinstalled stuff from the vendor.
So this script can slowly take over the world as we complete the
support for various other platforms, starting with UniElec U7623…
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Many MediaTek SoCs can be unbricked by using the SP Flash Tool from
http://spflashtool.com/ along with a "scatter list" file, which is
just a text file listing which image gets loaded where.
We use a trivial partition layout for the tool, with the whole eMMC
image as a single "partition", which means users just need to unzip
the sysupgrade image. Doing the real partition layout would be overly
complex and would require the individual partitions to be shipped
as artifacts — or users to extract them out of the sysupgrade image
just for the tool to put them adjacent to each other on the eMMC
anyway.
The tool does require a copy of the preloader in order to operate,
even when it isn't flashing the preloader to the eMMC boot region.
So drop that into the bin directory as an artifact too.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
bpi-r2 images are shipped with mainline u-boot which can extract lzma
with no problem.
remove custom kernel recipe to build lzma fit image instead of
uncompressed fit with zboot.
Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
